コミュニティが自ら作るプラットフォーム、エージェンティックコーディングとオープンプロトコル

2007年、Elggの「機能のない次期バージョン」発表

AIコーディングツールを使えば、小さな機能を自分で作ってみることが容易になりました。コミュニティ運営者も、自分のコミュニティに必要な掲示板や申し込み機能を作ってみることができます。それなら、コミュニティ全体を運営するプラットフォームも自分で作れるのでしょうか。Elgg共同創業者のベン・ワードミュラーの文章がこの可能性を扱っています。

彼は2026年4月の文章で、2007年9月のブライトン大学での講演を振り返っています。オープンソースのソーシャルネットワークであるElggの次期バージョンを紹介する場でした。聴衆の中には、数万から数十万人が利用するソーシャルネットワークを運営する人たちもいました。彼は空白のスライドを見せながら、こう言ったといいます。

「ない。次のバージョンには機能がない」

ワードミュラーの回想によれば、聴衆は驚きました。彼は、すべてのコミュニティに同じ機能を提供する代わりに、運営者が必要な機能を選んで構成できるようにしようという意味でこの言葉を発したのです。コミュニティのニーズを最もよく知る人に選択権を与えようという提案でした。

彼は約19年後の2026年、エージェンティックコーディング¹とオープンプロトコル²がこの構想を実現しやすくすると考えました。一方はソフトウェア制作を助け、もう一方は個別に作られたサービス同士をつなぐ規則を提供します。

大手プラットフォームが地域のニーズを見落とすとき

Facebook、Twitter、Instagram、TikTokのような大手プラットフォームは、共通の製品と運営方針をもとに複数の国でサービスを提供しています。地域ごとの機能や方針の調整はあるものの、小さなコミュニティが望む形に製品を直接変えることは難しいのが現状です。

特に通報やコンテンツ管理には、現地の言語と社会的文脈を理解する人が必要です。本社が遠く離れているという事実だけで問題を説明することはできませんが、地域の状況を把握して対応する人材が不足していれば、危険な投稿を見落とす可能性があります。

ミャンマーでFacebookを通じてロヒンギャに対する憎悪と暴力扇動が広がった事例が、その深刻さを示しています。2018年、国連の調査団はこの過程におけるソーシャルメディア、特にFacebookの役割を指摘しました。Facebookが同年公開した人権影響評価も、自社プラットフォームが分裂や暴力扇動に利用されるのを防ぐ対応が十分ではなかったと認めています。

この事例をもって、あらゆる問題の原因が画一的な設計にあると断定することはできません。ただし、現地のリスクを察知し対応する体制が重要であることは明らかです。コミュニティごとに身元公開のリスク、嫌がらせの手口、表現の文脈は異なり得るからです。

AIコーディングで作りやすくなったもの

コミュニティが既存プラットフォームの機能を変更したり、独自のサービスを作ったりするには開発力が必要です。AIコーディングツールはその作業の一部を助けてくれます。

ワードミュラーは、長年の開発経歴を持つジェシー・ヴィンセントとサイモン・ウィリソンがLLMを積極的に使っている点を紹介しています。ヴィンセントはPerl開発を主導した経験があり、ウィリソンはDatasetteを作った開発者です。二人の活用事例は、熟練した開発者にとってもAIツールが有用でありうることを示しています。ただし、この二人の事例だけで、あらゆる開発作業で生産性が高まると結論づけることはできません。

コミュニティの立場からすると、最初の一歩にかかる負担が軽くなり得る点が魅力的です。WordPressやElggを修正するために開発者を探さなければならなかった作業の一部を、運営者自身が試せるようになります。ただし、試作品を作ることと、会員情報・決済・通報機能を安定的に運用することの間には、依然として隔たりがあります。

私はここで、二種類の役割が共に必要になると考えています。

一つは、必要な機能を自ら具体化する現場の担当者です。 専門の開発者ではない人が業務用ツールを作ることを「市民開発」と呼びます。ローコード・ノーコード³ツールで使われてきた概念ですが、AIコーディングもこうした試みを後押しできます。コミュニティ運営者が機能の草案を作り、会員に見せて意見をもらう、という形です。

もう一つは、実装を検証し運用に責任を持つ開発者です。 生成されたコードが会員情報をきちんと保護しているか、アクセス権限が適切か、エラーが発生した際に復旧できるかを確認しなければなりません。AIがコードを書いたとしても、こうした判断と責任まで自動的に解決されるわけではありません。

運営者は会員の要求を説明し草案を試し、開発者は設計とセキュリティ・運用条件を検証する、という協業が可能です。役割が必ず二人に分かれる必要はありませんが、誰が何を確認するのかは決まっていなければなりません。

サービスを個別に作れば、接続の問題も生じます。それぞれに登録して投稿しなければならないとすれば、コミュニティ間の交流は煩雑になります。異なるサービス同士がアカウントや投稿をどのようにやり取りするかを決める必要があります。

異なるサービスをつなぐオープン規格

オープンプロトコルとは、ソフトウェアが通信するための規則を公開したものです。サービスごとに内部の実装が異なっていても、やり取りするメッセージの形式と処理方法をそろえることができます。

ウェブでは、HTTPのような通信プロトコルとHTMLのような文書形式がこの役割を担っています。ソーシャルサービスでは、ActivityPubとATProtoが代表的なオープン規格です。この二つの規格は、設計や適用範囲が異なります。

ActivityPubは、W3Cが2018年に勧告標準として採択したプロトコルです。異なるサーバーのユーザー同士が投稿をやり取りしたり、フォローしたりする機能などを定義しています。Mastodon、Ghost、Threadsがこれを活用していますが、各サービスが対応する機能や接続条件は異なります。

ATProtoは、Blueskyが使用するオープンプロトコルです。アカウントの身元とデータを特定のホスティング事業者だけに縛りつけない構造を目指しています。アカウントサーバーを移転しても、身元とつながりを維持できるように設計されています。ただし、異なるアプリの機能やデータまで自動的に同じになるわけではありません。

誰でもこの規格をもとに新しいサービスを作ることができます。しかし、仕様を参考にしたというだけで、既存のサービスとすぐに完全に互換性を持つわけではありません。対応する機能やデータ形式、認証・権限処理などをそろえ、実際のサービス同士で検証する必要があります。ActivityPubとATProtoも互いに異なる規格であるため、両者をつなぐには別途の実装が必要です。

ワードミュラーは、カスタムアプリが増えるほど、こうした共通規格がより重要になると見ています。今もさまざまな種類のアプリをつないでいますが、今後はコミュニティが自ら作ったより多様なアプリが同じ規格を活用できるようになるという見通しです。それを容易に実装できるツールとドキュメントが併せて整備される必要があります。

通報とブロック、データ利用のルールは誰が決めるのか

プラットフォームが動くからといって、安全に運営されているとは限りません。特に、会員同士が被害を与え合ったり、個人情報が露出したりする状況に備える必要があります。

コンテンツの審査、通報とブロック、悪用防止は運営者が継続的に対応すべき業務です。コミュニティの文脈を理解していることは助けになりますが、小さなコミュニティも人員や経験が不足している場合があります。独自プラットフォームを作るという事実だけで、大手プラットフォームの運営上の問題が解決するわけではありません。

ワードミュラーは、安全確保のためのツールもオープン規格でつなぐ方策を提案しています。運営者が外部の通報・審査ツールを使ったり、複数のコミュニティが人員と費用を分担して共同運営したりする方式です。これはあり得る設計の方向性であって、すでにすべてのコミュニティがすぐに使える完成された体制という意味ではありません。

AIに機能を作らせる際にも、会員の要求を正確に説明し、結果を確認する必要があります。

AIは、学習データや開発過程の偏りを結果に反映してしまう可能性があります。例えば、身元を必ず公開させたり、特定の表現を一律に遮断したりするデフォルト設定が、そのコミュニティに適しているかを検討する必要があります。こうしたルールは運営者と会員が決め、生成されたコードがその決定に従っているかを検証すべきです。

地域の言語や共同体のニーズを反映するAI研究も存在します。小型言語モデル（SLM）⁴を特定の言語に合わせて調整する試みや、MilaのFLAIRプロジェクトのように先住民コミュニティと共同で音声認識技術を開発する試みがその例です。音声認識とコード生成は異なる作業ですが、利用当事者がデータと目的を決めるプロセスに参加している点は参考になります。

2025年11月に正式発足したMozilla Data Collectiveも、データ提供者が利用条件を定められるよう設計されています。発足時の資料では、286言語にわたる300以上のデータセットが紹介されました。こうした参加型の構造があるからといって、モデルの偏りが自動的に消えるわけではありませんが、データを提供した共同体が活用方法を決められる余地は広がります。

Oswarldの視点

GTM戦略コンサルタントとして、私はコミュニティが自ら作れる機能が増えていく点に関心があります。制作コストが下がれば、既存プラットフォームが対応してこなかった小さなニーズも試せるようになるからです。ただし、既存プラットフォームにはすでにユーザーと運用インフラが集まっています。コード作成が容易になったという理由だけで、この強みが消えるわけではありません。

チャネル戦略においても選択肢が増える可能性があります。コミュニティが機能と運営ルールを自ら決め、オープン規格を通じて他のサービスと交流できれば、特定プラットフォームの方針変更への対応がしやすくなるかもしれません。その代わり、ホスティング費用や障害対応、会員サポートを誰が担うのかを決めなければなりません。

さまざまな規模の企業戦略を策定する中で、私は新しいツールが業務を直接遂行できる人の範囲を広げるケースを見てきました。実務において、草案を作る作業と検証する作業を分けて設計した経験もあります。AIコーディングで作られたコミュニティ機能にも、この方式を適用できると考えています。運営者が素早く試しつつ、実際の会員に公開する前には権限や個人情報の取り扱いなどを検証する、というやり方です。

オープン規格を使ったからといって、サービス運営の権限が自動的に分散されるわけでもありません。多くのコミュニティが同じホスティング・検索・認証サービスに依存すれば、その事業者に再び影響力が集中する可能性があります。会員の意見がルールに反映されているか、他の運営者へ移行できるかまで見極める必要があります。

おわりに

コミュニティが独自プラットフォームを検討するなら、次の点を併せて確認する必要があります。

必要な機能をまず決める必要があります。 既存サービスで解決されないニーズが何かを把握してこそ、自ら作るコストと運用負担を判断できます。

制作と接続を検証する必要があります。 AIコーディングで機能を作れるとしても、コードの安全性を検討し、他のサービスと必要な機能が実際に互換性を持つかを確認しなければなりません。

運営を担う人と手順が必要です。 通報に誰が対応し、ルールをどう改定し、障害やデータ流出にどう対処するかを決めなければなりません。

ワードミュラーの文章から私が受け取った提案は、制作が容易になった分、何を誰のために作るのかをより具体的に議論しようということです。コミュニティの構成員がその決定に参加できれば、新しいツールを使う意味もより明確になるはずです。

参考資料と関連リンク

主要出典

• Ben Werdmüller, “One size fits none: let communities build for themselves”, werd.io, 2026年4月14日。今回のニュースレターの原文です。オープンソースソーシャルネットワークの先駆者の視点から、エージェンティックコーディング×オープンプロトコルの可能性を論じた文章です。
• The Fediverse Report, “A conceptual model of ATProto and ActivityPub”, 2024年。：ActivityPubとATProtoの概念的な違いを、専門家でなくても理解できるように説明した記事です。二つのプロトコルが「分散化」をまったく異なる形で解釈している点が印象的です。

背景知識

• Brookings Institution, “Can small language models revitalize Indigenous languages?”, 2025年。：SLMが先住民言語の保存にどう活用されているか、そしてコミュニティ主導のAI開発における倫理的フレームワークを扱っています。
• Mozilla Foundation, “Mozilla Data Collective Redefines How AI Data Is Created, Shared, and Who Benefits”, 2025年。：コミュニティが自らのデータに対する主権を持つ、新しいAIデータエコシステムのモデルです。
• Harvard Law School Systemic Justice Project, “Facebook and Genocide”, 2022年。：Facebookのミャンマー事例を、ビジネスモデルと構造的失敗の観点から分析した論文です。

筆者のアン・グァンソプ（安光涉）は、世宗大学校経営学科教授であり、INLEVEL9のリードコンサルタントである。大学では経営データ管理、ビジネスアナリティクスなど統計およびデータ分析を教える一方、現場ではGTM戦略とAI戦略コンサルティングを主導し、技術とビジネスの接点を設計している。AI対話システムの記憶アーキテクチャ（HEMA）研究で学術論文を発表したほか、毎日グローバルなAI論文をキュレーションするDaily Arxivプロジェクトを運営している。高麗大学校技術経営専門大学院の修士課程とKMBAを修了した。著書に『考えを委ねる人々：ホモ・ブレインレス』がある。

著者 アン・グァンソプ（Oswarld） は世宗大学校 兼任教授、INLEVEL9 戦略コンサルタントです。経歴、研究、著書、最近の活動は著者紹介で更新しています。 最近の活動 · 2026年7月：HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI。

각주

1. エージェンティックコーディング（Agentic Coding）：AIがコードの作成・修正やツールの実行など、複数の開発作業を連続して行う方式です。実行範囲は権限やツールによって異なり、人が要求事項と結果を確認する必要があります。Claude Codeのようなツールが代表例です。 ↩

2. オープンプロトコル（Open Protocol）：ソフトウェア同士が通信する方法についての公開された取り決めです。HTTPがウェブブラウザとサーバーの間の取り決めであるように、ActivityPubはソーシャルプラットフォーム同士の取り決めです。誰でもこの取り決めに従えばエコシステムに参加できます。 ↩

3. ローコード・ノーコード（Low-code/No-code）：複雑なプログラミングなしに、ドラッグ・アンド・ドロップや視覚的インターフェースでソフトウェアを作れる開発方式です。エージェンティックコーディングの登場により、自然言語で指示するだけでもコードを生成できるようになり、市民開発者の可能性がさらに広がっています。 ↩

4. 小型言語モデル（Small Language Model、SLM）：パラメータ規模が比較的小さい言語モデルです。特定の作業や言語に合わせて調整でき、実行に必要な資源を減らせますが、小型モデルだからといって自動的に少ない学習データで済んだり、偏りがなかったりするわけではありません。 ↩