- POSSE(Publish on your Own Site, Syndicate Elsewhere) は、個人サイトにまず公開した後、ソーシャルメディアなど外部プラットフォームに複製やリンクを配信する コンテンツ自律配信方式
- この方式は コンテンツの所有権とオリジナルURL を維持しながら、友人やフォロワーが使うプラットフォームからアクセス できるようにする
- POSSEには サードパーティサービスへの依存を減らし、検索効率とオリジナルコンテンツの可視性 を高める利点がある
- 実装は手動・半自動・自動の方式で可能で、Bridgy, IFTTT, SiloRider, POSSE Party などさまざまなツールやAPIが活用される
- IndieWebコミュニティはPOSSEを Webの独立性と分散ソーシャル生態系の中核戦略 とみなしている
POSSE 概要
- POSSE は「自分のサイトに公開し、他所に配信する」の略で、個人サイトにまずコンテンツを載せ、その複製やリンクを ソーシャルメディア(silo) などへ共有する方式
- 各複製には オリジナル投稿リンク(original post link) を含め、読者が原文へ直接移動できるようにする
- この概念は IndieWeb運動の中核要素 であり、単なるブログ運営を超えて コンテンツ主権と分散投稿構造 を実現する
POSSEの目的と必要性
- 友人たちが使うプラットフォームで読めるよう支援 し、現在の関係を維持しながら自分のサイトを中心にコンテンツを管理する
- federation のような技術的理想よりも 人間関係中心の接続性 を優先する
- サードパーティサービス依存の低減: 自分のサイトから直接公開するため、外部サービス障害と無関係にコンテンツを維持できる
- 所有権の確保: オリジナル投稿の 正規URL(canonical URL) が自分のドメイン上に存在する
- 検索効率の向上: 自分のサイトで検索でき、外部プラットフォームの制限された検索機能に依存しない
- 複製がオリジナルを引用 することで、検索エンジンがオリジナルをより高く評価する
オリジナルリンクの重要性
- POSSEの複製には permashortlink などでオリジナルを接続する
- これにより オリジナルコンテンツの発見性(discovery) が高まり、スパム複製の防止 および 検索順位の向上 の効果がある
- 複製が再投稿されるたびにオリジナルへのリンクが広がり、トラフィックと信頼性が向上 する
実装方法
- 投稿ソフトウェアがコンテンツを公開する際、選択した ソーシャルプラットフォーム(silo) へ複製を自動送信し、オリジナルリンク を含める
- オリジナル投稿には posts-elsewhere セクションを追加して外部複製を明示する
- UI設計 では自動化・予測可能性・透明性を重視し、公開前の プレビュー(preview) 機能を提供できる
主なプラットフォーム別実装
- Twitter: 最も一般的なPOSSE対象。API経由でツイート投稿とオリジナルリンクの追加が可能
- Facebook: 手動クロスポスト、または Bridgyブラウザ拡張 による半自動配信をサポート
- Medium: APIまたは「Import Post」機能でPOSSE可能、rel-canonical リンクを維持
- WordPress: プラグイン（例: WordPress Crosspost）で自動POSSEをサポート
- Plain Text Notes: SMSやプッシュ通知向けに h-entry_to_text 変換方式を使用
対応ソフトウェアとサービス
- PHP:
php-helpers のPOSSEネームスペース
- Python:
SiloRider, Feed2Toot などのコマンドラインツール
- Docker:
POSSE Party セルフホストソリューション
- サービス型ツール:
Bridgy Publish, IFTTT, EchoFeed などが自動配信をサポート
投稿フローの種類
- Client → Site → Silo: サーバーが自動で複製を配信し、ユーザー操作を最小化
- Client → Site & Silo: ユーザーが各プラットフォーム向け投稿内容を直接調整でき、細かな制御が可能
IndieWebの実装事例
- Tantek.com: 2010年からFalconベースのPOSSEを実装し、Twitter・Facebookへ自動複製
- Waterpigs.co.uk: TaprootシステムでTwitter・Facebookへ同時配信
- Aaronparecki.com: permashortlinkを含むツイート複製
- Veganstraightedge.com: Medium・WordPress・Twitter・Vineなど複数プラットフォームへの手動POSSE
- Adactio.com: 写真やノートをTwitter・Flickrへ自動複製
- Molly White (2024) : Twitter・Mastodon・Bluesky向け自動POSSEを構築
他のアプローチとの比較
- COPE(Create Once, Publish Everywhere) : オリジナルサイトの概念がなく 正規URLが存在せず、POSSEより分散性が低い
- POSE(Publish Once, Syndicate Everywhere) : POSSEの前身で、ソーシャルプラットフォーム中心の投稿も含む
- PESOS(Post Elsewhere, Syndicate to Own Site) : 外部サービスに先に投稿し、その後個人サイトへ複製
- PESETAS: すべてのコンテンツを特定プラットフォーム（例: Twitter）へ集中的に複製
CRUD拡張アイデア
- POSSEは基本的に Create(投稿) 中心だが、Read・Update・Delete 機能への拡張議論がある
- Read: 複製上のアクティビティ（コメント、いいね等）を backfeed としてオリジナルに反映
- Update: 編集可能なプラットフォームには変更を同期し、不可能な場合は削除後に再投稿
- Delete: オリジナル削除時に複製も一緒に削除し、アクティビティ有無を確認して処理
FAQ 要約
- 検索エンジンの重複問題: 複製がオリジナルリンクを含んでいれば重複と見なされない
- バックリンク(backlink) : POSSE複製には常にオリジナルリンクを含めることが推奨される
- 順序: 「まずPOSSE、その次にWebmention送信」が原則
背景と歴史
- 2010年、Tantek Çelik が「自分のサイトに公開して外部へ配信せよ」という概念を提示
- 2012年にPOSSEという用語が公式化され、その後IndieWebCampのセッションで発展
- 2013〜2024年にかけてさまざまな記事や事例を通じて Web独立性回復戦略 として広がった
非Web環境への適用
- GitリポジトリPOSSE: 個人サーバーからGitHub・GitLabなどへ自動複製が可能
関連資料
- Bridgy, Micropub, Webmention, rel-canonical, syndication formats など、POSSE実装に必要な標準
- Cory Doctorow, Molly White, Jeremy Keith など多くのWebジャーナリストがPOSSEを コンテンツ自律性回復戦略 として言及
1件のコメント
Hacker Newsの意見
自分のWebサイトには、ぜひ RSSまたはAtomフィード を用意しておくことを勧める
RSSは死んだと言われることが多いが、自分のサイトのトラフィックの大半はいまもRSSから来ている
昔作った小さなゲームの1つも、RSSフィード経由でHNに共有されて人気を集めた
サーバーログを見ると、主なトラフィック元は3つある
詳しくは 自分のブログ記事 にまとめてある
RSSフィードのあるブログは、単に PVや広告 よりもコンテンツそのものに集中する傾向がある
RSSリーダーではPVを収益化しにくいので、自然な結果だと思う
linkタグ以外に何をすべきなのか気になるページ内でRSSを 視覚的に表示 するよい慣習があるのかも知りたい
以前はRSSアイコンを追加していたが、非技術系ユーザーがXMLを開いて混乱するのではと思って外した
Atomには利点の大半があるように見えるが、もし 互換性の問題 以外にRSSを維持する理由があるだろうか
複数のブログをRSSリーダーにまとめておけば、更新頻度の低いブログでも忘れずに見られる
リーダーアプリには スタイルの統一 や オフライン読書 のような機能もあって便利だ
他のWebコンテンツにもこうした標準があればよいのにと思う
昔、非営利団体でこの方式を使っていた
コミュニティが常に私たちのWebサイトを 最新情報の中心 と認識するように育て、
ソーシャルメディアのプラットフォームがアカウントを停止したり閉鎖したりしても、コミュニティとのつながりが切れないようにしていた
また、サードパーティープラットフォームのアカウントがなくても誰でもアクセスできるようにした
各ブログ記事は1つのテーマだけを扱うようにし、ニュースレターではそれを要約した
こうすることで 検索エンジンへのインデックス とコミュニティ参加が大きく改善した
リンクを押したらFBやIGに飛ばされるのは本当に うんざりする体験 だ
FacebookがRSS連携機能をなくしたのは、歴史上最大級の 後退 の1つだった
以前は外部RSSフィードをFacebookアカウントで購読し、自動投稿できた
しかしその機能が消えたことで、コンテンツは必ずFacebook内部で作成されなければならなくなり、
これは オープンWebへの攻撃 だった
Discordも同じように閉鎖的だ。コンテンツをプラットフォーム外からアクセスできないようにしている
BlueskyやMastodonにもRSSのような機能があればいいのにと思う
そうすれば静的ホスティングで 配信と収集を同時に できそうだ
去年ブログを再開したが、すべてのコンテンツをまず自分のブログに載せている
その結果、トラフィックは約 8倍に増えた
GoogleのAI Overviewによるzero-clickの影響はあったが、
現在のトラフィックの大半はRSSリーダーから来ている
詳しくは 自分の記事 にある
2025年にあなたはHNで9番目に人気のブロガーで、RSS購読者は約500人だと言っていた
HNからの訪問者のほうがずっと多かったはずだ
関連統計は このリンク を参照
自分も今年仕事を辞めてコンテンツ制作に集中しようと思っていて、
ブログで可能ならYouTubeの代わりに検討する価値がある
この戦略はPESOS(Publish Elsewhere, Syndicate to Own Site)の代替だ
IndieWebの記事 を見ると、
federationよりも 友人関係 のほうが重要だと強調している
PESOSでは外部サイトに複数の原本が生まれ、所有者が制御しにくい
PESOSで外部で直接作成されたコンテンツを再び取り込めばよい
自分もこの哲学を何年も実践している
すべてのコンテンツをまず自分のサイトに載せ、
Mastodon、Bluesky、Twitter、LinkedIn、Substackなどにリンクを配布している
ただし 自動化 は必要だ。BlueskyとMastodonは簡単だが、TwitterとLinkedInは難しい
Atomフィードさえあれば複数のプラットフォームと連携できる
HNであなたが見せる 誠実な活動 は地域特派員のように感じられる
こういう丁寧なアプローチは目を引く
URIベースのアイデンティティ体系を維持していたなら、メールのように完全に 分散されたソーシャルグラフ を作れただろう
Facebookがあまりに早く中央集権化へ押し進めてしまったが、
それでも可能性はある — ただし シンプルさと使いやすさ に集中しなければならない
自分もすべての投稿にこの方式を適用している
Mastodonにだけ同期しているが、サイトではRSSとJSONフィードをそれぞれのコンテンツタイプごとに提供している
（記事、リンク、本、映画、コンサート、ステータス更新など）
また ICSカレンダー でアルバム発売日程を購読できる
投稿時にMastodonへ自動送信でき、
各コンテンツタイプに対応した oEmbedエンドポイント も提供している
自分が読むすべてのコンテンツはfreshRSSで購読し、
リンクはlinkdingに保存したあと TTSポッドキャスト に変換してaudiobookshelfへ送っている
動画コンテンツにもPOSSE方式を適用したい
静的ランディングページ、サムネイル、文字起こし(transcript)、ダウンロードボタン、
そして外部プラットフォームへのリンクをまとめて提供し、サーバー費用を抑える構成を考えている
こうした 動画向けPOSSE について扱った記事があるのか気になる
自分が作っている opal editor も似た哲学だ
サイトはブラウザ内に保存される静的な Markdownベースの構造 でできていて、
HTMLにコンパイルしてVercel、GitHub、Cloudflare、Netlifyなどへ簡単に配布できる
CORSプロキシを使ってサーバー依存を減らした
opaledx.com と GitHubリポジトリ を参照
MITオープンソースで、まもなくドキュメントも公開予定だ