自分のサイトに投稿し、他所へ配信する（POSSE）

 (indieweb.org)
3 ポイント 投稿者 GN⁺ 2026-03-24 | 1件のコメント | WhatsAppで共有
  • 個人がコンテンツを自分のウェブサイトに先に投稿し、そのコピーやリンクをソーシャルメディアなど外部プラットフォームへ配信する方式
  • 元の投稿には正規URLとpermashortlinkを含め、コピーからでも元記事へ直接アクセスできる
  • この構造により、コンテンツ所有権の確保、検索エンジン最適化、外部サービス障害からの独立性を同時に実現する
  • Twitter、Facebook、Medium、Mastodon などさまざまなプラットフォームで自動または半自動のPOSSE実装例が存在する
  • IndieWebムーブメントの中核概念として、分散的な投稿と人間中心のつながりを実現する重要なアプローチ

POSSE 概要

  • POSSE(Publish on your Own Site, Syndicate Elsewhere) は、個人が自分のサイトにコンテンツを先に投稿し、そのコピーやリンクをソーシャルメディアなど第三者プラットフォームへ配信する方式
    • 各コピーには元の投稿へのリンク(original post link) を含め、利用者が元記事と直接やり取りできるようにする
    • IndieWebムーブメントの中核概念として、個人がコンテンツの所有権とアクセス経路を制御できるようにする

POSSE の目的

  • 友人が自分の好むプラットフォームで投稿を読めるよう支援し、Instagram、Tumblr、Twitter、Neocities など多様なソーシャルメディアのサイロ(silo) を通じてアクセス可能にする
  • 現在の人間関係の維持を優先し、技術的な連合よりも人間中心のつながりを重視する
  • 単一文化(monoculture) 的なアプローチとは異なり、ブログや特定プラットフォーム中心ではない分散型の投稿構造を志向する

一般的な理由

  • 第三者依存の低減: 自分のサイトで直接投稿するため、外部サービス障害の影響を受けない
  • コンテンツ所有権の確保: 自分のドメインに原本が存在するため、利用規約(TOS) に縛られない
  • 正規URL(canonical URL) を維持し、コピーが原本を引用することで検索効率を向上できる
  • バックフィード(backfeed) により外部サービスの反応を逆方向に取り込め、ソーシャルネットワーク効果を活用しつつ原本は自分のサイトに保存できる

原本リンクを含める重要性

  • 原本コンテンツの発見性向上: コピーからpermashortlinkを通じて原本へアクセスできる
  • スパム複製の防止: コピーが再投稿されても原本リンクも一緒に複製されるため、原本の露出が増える
  • 検索エンジン順位の向上: コピーが原本へリンクすることで検索エンジンがそれを認識し、原本の順位上昇につながる

実装方法

  • 投稿ソフトウェアはコンテンツを自分のサイトに投稿した後、選択したサイロ(silo) にもコピーを投稿する必要がある
    • コピーには元の投稿リンク(permashortlink または permashortcitation) を含める
  • 元の投稿にはposts-elsewhere セクションを追加し、各サイロ上のコピーへのリンクを提供する

  • ユーザーインターフェース

    • 理想的な UI は自動的で予測可能かつ目立たない形であること
    • 投稿前プレビュー(Preview) 機能を提供し、各プラットフォームでどう投稿されるか確認できる

主要プラットフォーム別の実装例

  • Twitter

    • 最も一般的な POSSE の対象プラットフォームであり、自分のサイトで書いたノートを Twitter に POSSE することでデータ所有権を確保できる
    • API による投稿が可能だが、2022年11月以降は新しい API へのアクセスが制限されている
    • ウェブアクションエンドポイントをサポートし、半自動投稿の実装が容易

  • Facebook

    • 手動クロスポスト、またはBridgy ブラウザー拡張による半自動 POSSE が可能

  • Medium

    • Posts API または Import Post 機能により、原本 URL の rel-canonical リンクを維持できる
    • WordPress 用 Medium プラグイン、Jekyll 用 crosspost プラグインなど多様なツールが存在する
    • 大量移行(mass POSSE) 機能で既存投稿も移行可能

  • WordPress

    • WordPress Crosspost プラグインを使い、セルフホスト版 WordPress から WordPress.com へ POSSE できる

  • Ghost

    • GitHub オープンソースツールにより、Ghost の webhook で新規投稿を JSON 形式で受け取り、Mastodon、Bluesky に同期する

  • Plain Text Notes

    • SMS やプッシュ通知など純粋なテキストベースの宛先向けの変換が必要
    • h-entry_to_text 方式で HTML をテキストへ変換する

POSSE 関連ソフトウェア

  • PHP: php-helpers の POSSE 名前空間に HTML→plaintext 変換およびシンジケーション関数を含む
  • Python:
    • SiloRider: コマンドラインツールとして Twitter、Mastodon などの POSSE をサポート
    • Feed2Toot: RSS フィードを ActivityPub ベースのサービス(Mastodon、Pleroma など)へ投稿
  • Docker: POSSE Party はセルフホスト可能な POSSE ソフトウェア

POSSE サービス

  • Bridgy Publish: POSSE-as-a-service 形式で Twitter、Flickr、GitHub、Mastodon をサポート
    • ウェブインターフェースまたはwebmention APIで利用可能
  • Mugged Tweets: ノートをマグカップに POSSE する実験的サービス
  • IFTTT: RSS/Atom フィードをもとに Twitter、Tumblr、Facebook などへ自動再投稿
  • EchoFeed: 追加のシンジケーションサービス

投稿フロー

  • Client → Site → Silo

    • 利用者がクライアントでコンテンツを作成 → サーバーへ投稿 → サーバーが各サイロへコピーを投稿
    • 利点: 利用者は自分のサイトだけ扱えばよく、サーバーが自動でシンジケーションを実行する

  • Client → Site & Silo

    • 利用者がコンテンツ作成後にサーバーへ投稿 → クライアントがサーバーから URL を取得 → 利用者が投稿先プラットフォームを選択
    • 利点: コピーの内容とタイミングを利用者が直接制御できる
    • 欠点: 毎回手動ステップが必要で、クライアントが各サイロへ直接接続する必要がある

IndieWeb 実装例

  • Tantek.com (2010)

    • Falcon ベースで POSSE を実装し、PuSH v0.4 + h-feed によるリアルタイムシンジケーションを実現
    • Twitter、Facebook へ自動コピーし、permashortlink 引用リンクを含める
    • Bridgy により Facebook の RSVP や「いいね」(like) を反映

  • Waterpigs.co.uk (2012)

    • Client → Server → 3rd Party フローを使用
    • Twitter、Facebook へシンジケーション
    • Taproot システムで更新時に追加の POSSE ツイートを生成
    • Bridgy により更新ツイートの反応も逆シンジケーション

  • BrennanNovak.com (2012)

    • Twitter、Facebook へコピーを投稿

  • AaronParecki.com (2012)

    • Twitter にpermashortlink を含むツイートを投稿
    • すべてのコレクションが PuSH 購読可能

  • Sandeep.io (2012)

    • Facebook、Twitter、Google+ の共有リンクを手動でクリックする方式で POSSE
    • API 統合の不安定さを避けるため、単純な手動アプローチを維持

  • Werd.io (2013)

    • idno プラットフォームのプラグイン構造で POSSE を実装
    • Twitter、Facebook、Flickr、Foursquare などへコンテンツ種別ごとにシンジケーション

  • Veganstraightedge.com (2013)

    • Dark Matter ベースの手動 POSSE
    • Medium、WordPress、Twitter、Vine などへ rel-syndication マークアップ付きで投稿

  • GlennJones.net (2014)

    • transmat.io システムを使って POSSE を実装
    • 現在はノート(note)投稿のみ Twitter へシンジケーション

追加実装例

  • Jeremy Keith

    • 2014年にカスタム CMS を使って POSSE を実装し、ノートは自分のサイトへ先に投稿してから外部へ複製
    • 写真は Twitter と Flickr に同時投稿される

  • Shane Hudson

    • 2014年にCraft CMSを使って Twitter への POSSE を実装
    • 返信コンテキスト機能を手動で処理し、写真 POSSE の自動化を計画中

  • Ravi Sagar

    • 2018年にDrupalベースのブログで POSSE を実装
    • 「Share」タグの付いた投稿をRSS フィード + Rebrandly + Zapierで Twitter、LinkedIn に自動共有

  • Ludovic Chabant

    • 2018年にPieCrust CMSとSiloRiderを使って Twitter、Mastodon への POSSE を実装
    • Microformats マークアップを基盤として動作し、写真投稿にも対応

  • Adam Dawkins

    • 2019年にカスタム CMS で POSSE を実装し、最初のノートを自分のサイトへ投稿してから Twitter へ複製

  • Shaun Ewing

    • 2020年にJekyllとカスタム API で POSSE を実装し、現在は手動同期状態

  • capjamesg

    • 自分のサイトのノートをTwitter(brid.gy)、micro.blog(feed polling)、Fediverse(fed.brid.gy) へ自動同期

  • Wojtek Powiertowski

    • 2026年にGhost ブログで書いた投稿をMastodon、Blueskyへ自動同期
    • セルフホストした posse クライアントを使い、新規投稿作成時に自動同期

部分 POSSE サイト

  • Hupili.net

    • 一部コンテンツだけを POSSE する部分 POSSE モデルを実装
    • SNSAPIで複数 SNS のデータ構造を統合し、SNSRouterでタイムラインを統合取得
    • 現状では原本とコピーの区別が難しいが、将来的には各ステータス更新ごとに固有のパーマリンクページを生成する予定

他のアプローチ

  • COPE (Create Once, Publish Everywhere)

    • 一度書いて複数箇所へ投稿するが、自分のサイトへ先に投稿しない
    • 原本パーマリンクの不在により、読者が複数プラットフォームへ分散する

  • POSE (Publish Once Syndicate Everywhere)

    • POSSE の前身で、特定のソーシャルプラットフォーム(silo) に一度投稿してから他プラットフォームへ複製する

  • PESOS (Post Elsewhere, Syndicate to Own Site)

    • POSSE の逆アプローチで、外部サービスへ先に投稿してから個人サイトへ複製する
    • コピーに原本リンク(permalink) を含める必要があり、そうして初めて POSSE と区別できる

  • PESETAS

    • PESOS に似ているが、すべてのコンテンツを特定プラットフォームへ複製する
    • Tumblr は多様なコンテンツ形式をサポートしており、PESETAS の宛先として適している

POSSE 拡張アイデア (CRUD モデル)

  • Create

    • 自分のサイトでコンテンツを作成し、外部へ配信する

  • Read

    • u-syndication リンクでコピーの場所を保存し、逆方向同期(backfeed) を可能にする

  • Update

    • 外部プラットフォームが更新機能をサポートしている場合、原本修正時にコピーも更新する
    • 修正不可の場合は削除して再投稿(delete/repost) 方式を使う

  • Delete

    • 原本削除時にコピーも一緒に削除できる
    • コメントやリツイートが存在する場合は削除再確認 UI が必要
    • Grant Richmond は 2018年から Twitter で POSSE 削除機能をサポート

FAQ

  • 検索エンジン重複防止のため、コピーには必ず原本リンクを含め、可能なら rel-canonical を使用する
  • バックリンクのない POSSEは最後の手段であり、posse-post-discovery 機能で補完できる
  • POSSE と Webmention の順序は、POSSE を先に、Webmention を後にする

背景

  • 2010年にTantek Çelikが「自分のサイトに投稿し、他サイトへ配信せよ」という概念として POSSE を提示
  • 2011年の IndieWebCamp で概念が拡張され、2012年6月に POSSE 用語が正式定義された
  • POSE が POSSE より先に存在したが、POSSE は「自分のサイト」中心の構造を明示した

関連記事と引用

  • 2013〜2024年の間にさまざまな媒体で POSSE 概念が紹介された
    • Ars Technica は POSSE を「ひとつの原本からすべてのプラットフォームへ配信する方式」と説明
    • Molly White、Cory Doctorow などは POSSE をコンテンツ所有権を取り戻す戦略として強調
    • 2024年以降、POSSE はBluesky、Mastodon、Fediverse など分散型ネットワークとの関連で再評価されている

POSSE の拡張適用

  • Git リポジトリの POSSE: 個人の Git リポジトリを GitHub、GitLab などへ複製する形に拡張可能
  • POSSE セッション記録: 2011年から2024年まで IndieWeb コミュニティで POSSE 関連セッションが継続開催

脚注およびライセンス情報

  • 文書の出典はIndieWeb ウィキページ(https://indieweb.org/wiki/index.php?title=POSSE&oldid=107734)
  • ページはbuilding-blocks および syndication カテゴリに含まれる
  • 最終更新日は2026年1月16日 17:04
  • コンテンツはCC0 パブリックドメイン献呈(CC0 public domain dedication) の下で提供される
  • 追加リンクとしてPrivacy policy、About IndieWeb、Code of Conduct などを含む
  • 下部にはCreative Commons パブリックドメインおよびMediaWiki関連リンクが表示される

関連記事

1件のコメント

 
GN⁺ 2026-03-24
Hacker Newsのコメント

  • 私はこのやり方を一貫して続けている。投稿プロセスは手動だが、意図は良いし、あちこちのフォーラムでスパム的なブログ宣伝さえしなければ、かなりうまく機能する
    私のブログ（rednafi.com）には意図的にコメント欄を設けていない。文章を書くのは有償の仕事ではないし、コメント管理にあまりにも多くのエネルギーがかかるからだ
    以前、Hugo サイトに Disqus を付けていたが、実際に議論が長くなるとスケーラビリティの問題が深刻だった
    記事が有用なら、たいてい HN や Reddit に自然に投稿されるので、私はその議論へのリンクを記事に張り返す。それで十分だと思っている

    • 私も同じやり方で運用している。たとえば この記事 のように、複数プラットフォームのリンクバックを管理している
      ソーシャル URL は YAML frontmatter にキーとして入れ、standard.site を通じて ATProto エコシステムにも登録している
      長文は rogue-scholar.org で DOI を取得してメタデータを追加している
      いつかこれらすべてを 1 つの静的コメントスレッドにまとめるのが目標だが、ネットワーク間の会話はほとんどないので、今のようにリンクだけ置くのが現実的だ
    • 私は HN をコメントプラットフォームとして使っている。Hugo shortcode で HN コメントをキャッシュし、7日以内の記事だけ新しく取得するようにしている
      体裁もかなりきれいで、この記事の下部 で確認できる
    • Mastodon アカウントがあれば、その投稿のすべての返信スレッドをサイトに埋め込める
      実装例は この記事 を参照
    • ブログを楽しく読んだ。特に Splintered Failure Modes の記事が印象的だった。一度読んだだけですぐ記憶に残った

  • 私はこのアプローチを取っている。自分が作った場所を自分で所有したいからだ
    うまく機能するが、自動化は難しく、結局は手動でクロスポストしなければならない。コミュニティごとに反応が違うのでトラフィックは少ないが、公開作業のやり方としては素晴らしい

    • 自動化が難しい理由は、ソーシャルメディアが意図的に自動投稿を難しくしているからだ
      Facebook は外部リンクを含む投稿の表示優先度を下げることもある。だから「リンクはコメント欄に」といった小技が生まれたのだ
    • 私は同意しない。micro.blog のようなサービスは、複数のソーシャルへの自動クロスポストを手軽にサポートしている
      トラフィックよりも、さまざまなコミュニティで活動することが目的なら十分に価値がある
    • 各プラットフォームで文化と読者層が違うので、議論の質感も異なる。どこにでも同じものを投稿するのは、少しスパムっぽく感じられることもある
      だからクロスポストの有用性は人によって違う
    • Buffer.co のような投稿サービスを使ったことがあるか気になる

  • 私はさまざまなプラットフォームで POSSE をよく目にする立場だが、このやり方が無機質でスパム的に感じられることがある
    理由はわかるが、対話というより「とにかく出す（ship it）」型のアプローチに見える。年齢のせいかもしれない

    • standard.site のようなatproto ベースのパブリッシングは、多くのチャネルに投稿しなくてもコンテンツを簡単に見つけられるようにする方向へ発展している
    • 何が無機質に感じられるのか気になる。むしろ読者に特定のプラットフォームを強制しない点が利点だと思う

  • スモールウェブ向けの素敵な機能を想像してみる

    1. 好きなブログを RSS で購読する
    2. 新しい記事が出たら、RSS リーダーで HN、Reddit、Twitter などの議論リンクも一緒に確認する
    3. クリックしてそこで会話に参加する
      単純な版としては、記事の下に関連する議論へのリンクを置くことだ
    • 私も同意する。RSS リーダーで記事を読みたいのであって、ソーシャルフィードに無差別に投げ込まれたいわけではない
      単に「新しい記事を公開しました」式の投稿はスパムっぽく感じる。
      外部の議論を探すのは面倒だが、本当に関心があるなら URL 検索で十分だ。permashortlink はむしろ邪魔になる
    • これを可能にするには、WebMentions がもともとその役割を果たすよう設計されていたはずだ

  • こういう記事がたまに上がってくるたびに本当にうれしくなる。誰もが自分のコンテンツを自分で所有すべきだ
    indieweb コミュニティの哲学は称えられるべきだ。
    可能なら Homebrew Website Club に行って、自分だけのウェブ空間を作る話をしてみることを勧める。技術への愛情をもう一度感じられるはずだ

  • 最初はこの記事がビッグテックの宣伝文のように感じられた。「どうせ大企業が勝つのだから、どこにでもばらまけ」というニュアンスに思えた
    でも、なぜわざわざ Facebook しか使わない友人に私のブログを見せなければならないのかわからない。
    私は自分の原則に共感する人たちとだけ共有したい

    • 興味深い見方だ。できるだけ多くの人に文章を見せたい人もいれば、静かに共有したい人もいる
      年を取るほどオンラインに文章を載せることに慎重になる。自己認識と成熟の表れかもしれない — 誰もが私の文章を読みたいわけではないのだから

  • 私は記事を読むとき、HN や Reddit の主要な議論へのリンクが一緒にあるのが好きだ
    ブログコメントはたいてい静かで、数日遅れて読んでも他の人の考えを追いやすい

    • 「主要な議論」という概念そのものが悲しい。インターネットが**アプリ化(appification)**されるにつれ、私たちは閉じた庭園の中の思考様式に慣らされてしまった
      ブラウザーが自分で関連リンクを見つけて表示する構造になるべきだ。
      ActivityPub や Linked Data を扱っていると、多くのプロジェクトが依然として閉鎖型 SNS を模倣しようとしている点にもどかしさを感じる

  • RSS は単純で信頼できる方法で、アルゴリズムによるキュレーションに振り回されず、自分が見たいものを自分でコントロールできるようにしてくれる

  • 私もこのやり方を採っている。自分のサイトはプロフィールに載せてある
    permashortlink は省き、短くて意味のある元のリンクを維持している。
    リンクを見るだけでどんなコンテンツか見当がつくし、POSSE のおかげでこうした個人的な好みを簡単に反映できる

    • 私も permashortlink は不要な概念だと思う。
      indieweb.org/permashortlink に理由が並んでいるが、大半は説得力に欠ける
      メールでより安定する、短いから入力しやすいといった主張にはあまり意味がない
      むしろ管理コストとドメイン分散の問題が生じるだけだ。単に既存の URL 構造を改善したほうがよいと思う

  • 私は逆に**PESOS(Publish Elsewhere, Syndicate to Own Site)**方式を使っている
    自動化システムのおかげで、ウェブ全体での活動を自分のサイトに集約し、必要なときに簡単に参照できる。とてもおすすめだ

    • vale.rocks のサイトを見たが、本当に刺激を受けた。良い一日を