マルチエージェントはトークンばかり大量に消費してコンテキストもよく取りこぼす？ そこで『新聞編集局』構造を導入したLLM Wikiを作ってみました。

• 自律型マルチエージェントが最近たくさん出てきていますが、実際に回してみるとトークンだけ5〜10倍消費し、コンテキストも頻繁に取りこぼします。そこで新聞社の編集局を手本にして、マルチエージェントの構造を組みました。
• 5つのエージェント役割がありますが、LLMが自分で判断するエージェントはデスク（校閲）1つだけです。残りは文章作成の作業か、LLMではなくルールどおりに動くPythonの検査（lint）、そして作業の調整（オーケストレーション）です。
• LLM Wikiの考え方と同じく、原文書を読んでソースページを作り、そこから人物・概念の下書きを抜き出し、それを束ねてトピック別の概要・矛盾整理・総合ページへと積み上げていきます。保存は単なるMarkdownファイルとgitで、Pythonツールはすべてローカルで動きます。cloneするだけでAPIキーなしでもサンプルグラフをすぐに動かせます。
• 現在githubに入っているサンプルは「AIにおいてオープンソースとは何か」という議論を扱っていますが、フレームワーク自体はテーマを選びません。

---

なぜエージェントをただ複数放しておかなかったのか

• これを実際に何千ドルも使って回した人たちの感想は、おおむね同じ結論でした。トークンばかり大量に使い、エージェント同士でやり取りするうちにコンテキストを落とし、終わっていない仕事を終わったと表示してしまう、というものです。
• そこで、自動判断に任せる代わりに、定められたルールとコンテキスト分離のほうに重きを置きました。編集局という比喩を使ってはいますが、本当に自由に判断するLLMはデスクだけで、残りは決められた仕事だけをします。

出そうな反論に先回りして答えると

• 文書がどんどん膨らんで結局使えなくなる: いちばん現実的な懸念だと思います。そこで、書く役割と、通すかどうかを判定するデスクを完全に分けました。デスクには成果物と採点基準だけを見せ、書き手がどんな意図で書いたかは見えないようにしています。加えて、ルールベースのlintが、文書の肥大化や重複、方向性なく長引く記述を機械的にふるい落とします。それでも膨張を「防げた」とまでは言えません。
• 編集を繰り返すと誤りが蓄積し、自分で作ったフィードバックで自分を直すと結局もともとのパターンを繰り返すだけになる: 自己改善という話には常につきまとう疑いで、私ももっともだと思います。そこで、デスクが繰り返し見つける欠陥をガイドラインに再反映するとき、同じ試験問題にだけ慣れてしまうことを防ぐため、検証用の失敗事例を毎回新しいものに差し替えています。常に初見の事例で確認するわけです。総合ページ側には、出典の異なる内容をひとまとめにしていないか照合する検査も入れています。
• 結局、埋め込みを手動で変えたRAGではないのか: 検索が目的ならその通りです。違いがあるとすれば、成果物がベクトルインデックスではなく人がそのまま読めるつながった文書であること、そして出典同士で食い違う部分を覆い隠さず、別の矛盾ページとして表に出すことです。質問のたびに原文を再収集するのではなく、積み上がった判断が残ることを狙っています。

古い概念: Memex

• ヴァネヴァー・ブッシュのMemex（1945年に構想された連結型情報機械）や、リックライダーの『Man-Computer Symbiosis』のような流れを意識して作りました。
• そのため、ページとページをつなぐtrail（連想経路）と、意外なつながりを見つけてくれるdiscover機能を入れました。自動で索引を抜き出すのではなく、人が自分でたどって歩ける道を残そうとしているのです。

使用時の考慮事項

• 『APIキーが不要』という言い方は半分だけ正しいです: tools内のPythonはローカルで動くので外部キーは不要です。ただしエージェント自体はClaude Codeで動くため、そこは各自で自分のキーを使う必要があります（BYOK）。
• 公開リポジトリはアイデアと小さなサンプル程度です: 15ノードの英語サンプルが入っているので、cloneするだけで誰でも同じグラフを再現できます。私が日々回してきた約2,300ノードの実運用インスタンスは別に非公開としているので、公開リポジトリとは分けて見てください。
• 韓国語モード（WIKI_LANG=ko）: 本文と文書上部のメタデータ（frontmatter）だけを韓国語に変え、文書構造を表す表記（## Summary、[fact]のようなもの）はあえて英語のまま残します。つまり「完全な韓国語」ではありません。

作ったきっかけと現在の状態

• Karpathyが共有したLLM Wiki gistに実装を1つ載せてみたのが出発点でした。この概念自体は以前GeekNewsでも紹介されたことがあります: https://ja.news.hada.io/topic?id=28208
• 書く側と校閲する側を分けると本当に雑に通してしまうことが減るのか、自己改善ループが本当に役立つのかは、まだきちんと測定した結果ではなく実験中の仮説です。