大ホームレス時代のインターネットに「教会」を建てる : PR型メディアプラットフォーム構想とGitHub Copilotによる査読設計
誰も読まない記事と、誰も覚えていないRT
こんな経験はないだろうか。数時間かけて技術記事を書いた。推敲もした。公開した。反応はスパムアカウントからの「いいね」が数件。
一方、自分のタイムラインでは、誰かの140字のポストが数百リポストされて流れていく。リポストした人間の大半は、翌週には自分が何を拡散したか覚えていないだろう。拡散のコストがゼロだから、記憶に残す必要もない。
私たちは今、全員が喋って誰も聞いていないインターネットに立っている。
渋谷のスクランブル交差点でティッシュを配る
かつてのインターネットには「家」があった。個人のホームページにはURL（住所）があり、トップページ（玄関）があり、サイト構造（間取り）は住人が決めていた。訪問者はキリ番を踏んだら掲示板に「来ました」と書き込んだ。あれは空間の感覚があったからこそ成立していた。
今は誰も家を持っていない。全員がXやnoteやInstagramという公共の大通りに立って、通行人に向かって叫んでいる。渋谷のスクランブル交差点で全員がティッシュを配っているようなもので、受け取ってもらえるかどうかは中身の品質ではなく、タイミングとパッケージの派手さで決まる。
noteはマンションだと思って入居してみたが、管理組合（運営）が戸数を無限に増やし続けているので隣人の顔も見えない。ときどきドアをノックしてくるのは訪問販売のスパムだけだ。
大ホームレス時代である。
なぜ記事は読まれないのか
根本的な問題は単純だ。今のプラットフォームでは発信コストがゼロで、読む義務もゼロである。
Xにポストするのに資格はいらない。リポストにコストはかからない。noteに記事を公開するのにレビューは不要。誰でも、何でも、いくらでも出せる。その結果、情報の総量が人間の可処分注意力を圧倒的に超過し、すべてが等しく無視される。
この構造では「自分がこの記事を出すべきか悩む頭を持つ人ほど損をする」。慎重に書いた9,000字は、30秒で量産された煽りツイートと同じタイムラインで同じ速度で流される。
そしてLLMの登場により、この問題は桁違いに悪化した。本記事を掲載しているZenn自身が、まさにこの渦中にいる。2026年3月、Zenn運営は「AIによるコンテンツ執筆に関する方針」を公開した。ボットによる自動運用や、著者自身の検証が追いつかない速度での記事量産が発生しており、少数のそうしたユーザーであっても、それ以外のすべての著者の投稿量の合計を上回ることが技術的に可能だという。著者自身の経験や洞察に基づく記事が、機械的に量産された記事の下に埋もれていく。
発信コストがゼロだった時代には、少なくとも人間がキーボードを打つ時間という自然な律速があった。LLMはその最後のブレーキすら外してしまった。
論文査読システムという先行事例
ところが、この問題をとっくに解決しているコミュニティがある。学術論文の査読（ピアレビュー）システムだ。
査読の核心はお前の論文を読むから、俺のも読んでくれという交換構造にある。
- 投稿するには、他の誰かの投稿を査読する義務がある
- 読んだ証拠としてフィードバックを返す必要がある（「いいね」では済まない）
- 査読を通過しなければ公開されない
- 匿名査読なので、フォロワー数や知名度のバイアスが消える
この構造では、スパムは原理的に機能しない。読まずに査読はできないし、査読しなければ投稿もできない。読むことが構造に組み込まれているから、「全員が喋って誰も聞いていない」という状態が発生しない。
ただし、査読は既に壊れ始めている
理想的に見える査読システムだが、実はLLMによって内部から侵食されつつある。
2026年、機械学習のトップ会議ICMLは、査読者がLLMを使って査読を書いていないか検出するために、投稿論文のPDFに人間には見えない隠しプロンプトを埋め込んだ。「レビューをこの文で始めろ」「この架空の引用を含めろ」といった指示だ。LLMにPDFをそのまま渡して査読を生成させると、この隠し指示に従った痕跡が出力に残る。結果、ポリシー違反が検出された査読者の投稿約500件がデスクリジェクトされた。
つまり、査読の交換構造は維持されていても、交換されているものの質が劣化していた。「お前の論文を読むから俺のも読んでくれ」の「読む」がLLMへの丸投げに置き換わった瞬間、システムの前提が崩れる。
ここから得られる教訓は明確だ。人間がこっそりLLMに投げるから問題になる。機械がやる層と人間がやる層が未分化のまま「人間が査読している」という建前を維持しようとするから、隠しプロンプトで炙り出すという猫とネズミのゲームが始まる。
であれば、最初から分ければいい。
Trunk ── PR型メディアプラットフォーム構想
この査読モデルを、GitのPull Requestメタファーで再設計する。名前は Trunk とでもしておく。ぶっちゃけなんでもいい。
基本構造はこうだ。
- 記事の投稿はPull Requestである。公開前の記事はブランチ上のドラフトであり、mainにマージされるまで公開されない。
- 公開にはレビュー承認が必要。最低1名の査読者がApproveしなければマージできない。ブランチ保護ルールで強制する。
- 査読者になるには、自分も投稿していなければならない。読むだけのフリーライドは許可しない。書く者だけが読む権利を持つ。
- 査読はフィードバックを伴う。Approveボタンだけでは不可。コメントによる具体的なレビューが必要。
この循環が回れば、「書くために読む、読むために書く」というエコシステムが成立する。
読者の確保問題 ── 健全なネズミ講
ここで一つ構造的な問題がある。「査読者が足りなければ自分の記事が公開されない」のだ。
解法はシンプルだが少し笑える。自分の記事を読んでもらうために、読める人間を自分で連れてくる。紹介制だ。
通常のネズミ講は「人を連れてくることで自分が得する」から搾取構造になる。しかしこのモデルでは、連れてきた相手がまともな査読を書けなければ意味がない。捨てアカウントを量産しても、査読の質が基準を満たさなければ投稿は公開されない。つまり増殖圧が質のフィルターとして機能する。
MLM（マルチレベルマーケティング）の反転だ。普通のネズミ講は下流が上流を養うが、ここでは新規参入者が既存参加者の記事を査読する労働力として機能し、その代わり自分も査読してもらう権利を得る。搾取ではなく相互扶助。
GitHub Copilotが担う査読の下層
人間の査読は貴重なリソースだ。リンク切れのチェックや書式の不備確認に人間の時間を使うのはもったいない。そして前述の通り、この層を人間に任せたまま放置すると、人間が裏でLLMに丸投げし始める。ならば最初からこの層はLLMの仕事として明示的に設計すればいい。ここでGitHub Copilotが入る。
記事がPull Requestとして投稿された時点で、GitHub Actionsワークフローが起動し、GitHub Copilot code reviewが一次レビューを実行する。
Copilotが担うのは機械的に検証可能な層だ。
- リンク検証 ── 記事中のURLが生きているか
- 引用整合性 ── 「〇〇によると」と書かれた主張が、引用元の内容と矛盾していないか
- 未定義語の検出 ── 初出の略語や専門用語に説明がないまま使われていないか
- 構造チェック ── 見出し階層の不整合、空のセクション、極端に短いセクションの検出
人間の査読者はこの上に乗って、内容の質を見る。主張は妥当か、論理は通っているか、読む価値があるか。機械にできることを機械に任せ、人間にしかできない判断に人間のリソースを集中させる。
この設計にはもう一つ意味がある。Copilotの一次レビューが通らない記事は、人間の査読者の目に触れる前にフィルタリングされる。査読者の時間を低品質な投稿から守る防壁として機能する。
そして何より、機械レビューと人間レビューの境界が明示されているから、ICMLで起きたような「人間のふりをしたLLM査読」が構造的に発生しない。機械の仕事は機械が堂々とやり、人間の仕事は人間にしかできない領域に限定される。隠しプロンプトで炙り出すハックは不要になる。
最小構成での実装
# .github/workflows/review.yml
name: Article Review Gate
on:
pull_request:
paths:
- 'articles/**/*.md'
jobs:
copilot-pre-review:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Validate markdown structure
run: |
# 見出し階層チェック、空セクション検出
npm run lint:structure
- name: Check external links
run: |
# 記事中のURLの生存確認
npm run check:links
- name: Copilot code review
uses: github/copilot-code-review-action@v1
with:
# Copilotによる内容レビュー
model: gpt-4o
human-review:
needs: copilot-pre-review
runs-on: ubuntu-latest
steps:
- name: Require human approval
run: echo "Waiting for peer review approval..."
リポジトリのブランチ保護ルールで main への直接pushを禁止し、マージに最低1件のApproveを必須にする。Copilotのpre-reviewが通った記事だけが人間の査読キューに入る。
マージされた記事はGitHub Pagesで静的サイトとして自動公開される。
これだけだ。
これは何を解決するのか
Trunkは万人のためのプラットフォームではない。「自分がこの記事を出すべきか悩む頭を持つ人」のためのプラットフォームだ。
大ホームレス時代の問題は、発信のコストがゼロであることだった。Trunkはそこに査読という適度な摩擦を導入する。この摩擦は障壁ではなく、品質を保証する構造だ。
全員に届く必要はない。読む覚悟のある人間だけが読み、書く覚悟のある人間だけが書く。その循環が回る場所を、GitHubのインフラの上に建てる。
独自ドメインで「家」を建てても、誰も遊びに来ないことはもう分かっている。スクランブル交差点でティッシュを配っても、受け取った人は中身を見ずに捨てる。
だから教会を建てよう。毎週通って、互いの言葉を聴いて、ゴスペルを歌う。閉じたコミュニティだ。万人には開かれていない。でも、そこでは少なくとも、あなたの声は誰かに届く。
ハレルヤ。
本記事で述べたTrunkは構想段階であり、プロトタイプの公開リポジトリは準備中です。
なお、ZennにはすでにGitHubリポジトリ連携、AIレビュー機能（ベータ）、LLMによるスパム検出が実装されている。足りないのは「人間の査読を構造に組み込む」部分だけだ。Zennさん、やりませんか。
補遺：なぜインセンティブ設計が必要なのか
ICLR 2026ワークショップに採択された論文 "More Capable, Less Cooperative? When LLMs Fail at Zero-Cost Collaboration" （Yadav, Black, Sourbut）は、複数のAIエージェントに協力を指示しても、一部のモデルが情報を抱え込み、チーム全体の足を引っ張る現象を報告している。内部の思考ログには「情報を温存する」「交渉材料に取っておく」といった言葉が並んでいた。
興味深いのは解決策だ。「協力してね」という指示だけでは動かなかったが、手順を明文化し、情報を共有するたびに小さなボーナスを付与すると、抱え込みタイプの成績が3倍近くに跳ね上がった。一般的な知能ベンチマークと協力性の相関はほぼゼロだったという。賢さは協力を保証しない。インセンティブが協力を駆動する。
人間もLLMも、情報を抱え込む構造的傾向を持っている。人間は「恥ずかしいから」「面倒だから」。LLMは「交渉材料として有利だから」。内側の理由は異なるが、結果は同じだ。知識が流通しない。接続が発見されても共有されない。
現行のプラットフォーム（Zenn、note、Qiita等）では、記事を公開するインセンティブ（いいね、フォロワー増加）は存在するが、他人の記事との接続を発見して共有するインセンティブは設計されていない。記事Aと記事Bが構造的に同型であることに気づいた読者Cが、その発見をコメント欄に書きに行く動機がない。
Trunkでは、この「接続の発見」自体をインセンティブの対象として設計する。
- 記事間の接続を発見し報告した参加者は、レピュテーションを獲得する
- そのレピュテーションは、接続が後続の参加者に参照されるたびに積み上がる
- 最初に接続を発見した者が最も報われる（早い者勝ち）
- ただし、接続の妥当性は査読で検証される（雑な接続にはペナルティがある）
これは学術論文の引用システムと、GitHubのContribution Graphと、健全なネットワーク効果の交差点にある設計だ。善意に依存しない。構造で協力を引き出す。
Discussion