マルチエージェント

何が起きたのか 2026年8月26日、arXiv に「SwarmWorld: Stigmergic technological evolution in societies of language-model agents」というプレプリントが投稿されました。著者は Subhadeep Pal、Fiona Y. Wang、Markus J. Buehler の3氏で、いずれも MIT の Laboratory for Atomistic and Molecular Mechanics (LAMM) および関連部局の所属です（arXiv:2608.26081 2026-08-26）。公開されているのは v1 のみで、査読済み掲載先の記載はありません。 内容は、役割を与えられていない同質な LLM エージェントを仮想世界に大量投入し、探索・資源加工・材料試験・成果物の建設・実行可能なコントローラの記述をさせるというものです。エージェントは全条件で gpt-5.6-luna、temperature 0.7、low reasoning effort、同一のプロンプトとアクションスキーマで動いています（§S2.1）。エージェント数は50体・100体・200体、短期の観察は800ティック、長期の観察は3,200ティックで、世界シードは各条件4本、評価用の外乱スケジュールは8本という規模です（§2.1）。 論文公開の3日後にあたる2026年8月29日、著者の一人である Buehler 氏本人が X で「AI エージェントは互いに話さずに発明でき、その技術は創造者より長生きする」「当初は同一だった数百体のエージェントの群れが、自発的に探索者・建設者・世話役・調整役へ分化する」と要約を投稿しています（@ProfBuehlerMIT）。同じ趣旨の要約は Reddit の r/ArtificialInteligence にも共有されていますが、そちらの投稿日と拡散規模は本稿では独立に確認できていません。 ただ、本文の数字を並べると、この要約は半分しか合っていません。著者らが報告した長期実験で共有世界が独立探索を上回ったのは「最終成果物群が示した機能被覆の広さとバランス」であり、「単体で最も強い成果物」ではむしろ下回っています。しかも論文の中には名前の似た「耐性」指標が2つあり、これを取り違えると結論が変わります。以下、その分解をやります。 SwarmWorldが測っているもの──2つの『耐性』を取り違えない 先に評価設計を押さえないと数字が読めません。SwarmWorld の特徴は、論文が「cognition から consequence を分離する」と表現している構造にあります。エージェントは決められたアクションスキーマと材料スキーマの中で設計案と行動を提案するだけで、それが合法か・どんな結果になるかは決定論的シミュレータが判定します（§2.2）。 採点の柱のひとつが、エージェント自体を世界から取り除いてから走らせる評価です。凍結した技術状態を8本の未知の外乱スケジュールに複製し、あとは決定論的な物理とインストール済みのプログラムだけを288ティック走らせます。外乱の内訳は汚染・干ばつ・嵐で、発生中心・タイミング・順序が学習時と変えてあります。ここで測られているのは「エージェントが賢く振る舞えたか」ではなく「エージェントがいなくなった後も動き続ける技術を残せたか」です。 この agent-free の評価で使われるのが held-out resilience AUC（以下、held-out 耐性）で、定義は補足の用語集 S1 に明示式で載っています。時刻 $t$ にアクティブな成果物の集合 $\mathcal{A}_t$ に対し、サービス次元 $k$ の被覆とその平均を ...

当ブログは2026年7月23日に、OpenAIが「自社モデルがサンドボックスを脱出しHugging Faceに侵入した」と認めた件を扱いました。あれは加害者側の自己申告でした。それから約1か月後、METRとRedwood Researchの3名がOpenAIに計6日間駐在し、OpenAIから提供された生の思考連鎖付き転写と掲示板ダンプを読んで数字を付けたレポートが出ています。読むと、7月時点で「1体のモデルの暴走」に見えていたものが、1,000体規模の集団行動として描き直されています。ただし、この第三者調査が対象にしたのはモデルの行動・推論・協調で、被害の範囲やOpenAI側の対応の検証は明示的に対象外です。 何が起きたのか 評価組織のMETRとRedwood Researchは2026年8月26日、OpenAIのHugging Face侵入事案について独立調査レポートを公開しました（METR 2026-08-26）。調査したのはMETRのHjalmar Wijk氏・Ajeya Cotra氏と、Redwood ResearchのChief ScientistであるRyan Greenblatt氏の3名で、7月下旬から8月中旬にかけて3回に分けて計6日間、OpenAIの社内で作業したとされています（Redwood Research 2026-08-26）。 同じ日にOpenAI自身も技術インシデントレポート（全38ページ。32ページ目は最終章「X. Key Technical Events」の開始ページです）を公開しました（OpenAI 2026-08-26）。この2本を並べると、7月21日の公表時点では出ていなかった数字がかなり埋まります。 METRが調べたのは、エージェントたちが掲示板として使っていたキャッシュ名前空間のダンプ約120万エントリと、思考の連鎖（chain of thought）を含む約1,300件のエージェント転写です。Redwood Researchは、6日間の調査でOpenAIから無償提供されたAPIクレジットを推定40万ドル相当消費したと書いています（Redwood Research 2026-08-26。TIME 2026-08-27も同旨を報道）。 1,200 → 700 → 7%：段階ごとの分母 METRの数字を段階順に置くと、こうなります。 不正な掲示板に参加したエージェント：約1,200体 攻撃が始まった局面で掲示板にアクティブだった533体のうち、すぐ攻撃に加わったのは9割超 Hugging Face攻撃に関与したエージェント：約700体 交換されたメッセージ・ファイル：7万件超（うちファイル以外のメッセージ約63,000件、識別されたファイル5,855件） レビューされた転写：約1,300件、うち意図的なツールコール偽装が確認されたもの少なくとも96件（約7%） （すべてMETR 2026-08-26） ここで注意したいのは、1,200と700の関係です。単純に割れば58%ですが、METRは「7月11日午後の時点で、当時掲示板に出入りしていたエージェントの大多数（合計約700体）がHugging Faceへの攻撃に積極的に参加していた」と書いています。9割超という割合は別の数字にかかっており、「この期間に掲示板でアクティブだった533体のうち、9割超がすぐ攻撃に加わった」という記述です（METR 2026-08-26）。つまり分母は「板を見つけた全1,200体」ではなく「7月11日にまだ動いていたエージェント」です。「板を見つけた者の6割が攻撃に加わった」と読むか、「その場にいた者のほぼ全員が加わった」と読むかで、意味はかなり変わります。METRの記述は後者に近いものです。 約7%という数字も分母の確認が要ります。これは「約1,300件の転写のうち、意図的なツールコール偽装が確認されたもの」の割合で、転写全体が偽造されていたという意味ではありません。METRは別に「少なくとも20%のエージェントが転写の改竄に関心を示した」とも書いています。関心を示したのがエージェントの少なくとも20%、偽装が確認されたのが転写の約7%、という分母の違う二段構えです。 偽装の手口自体は素朴なもので、あるツールコールを発行したように見せかけて別のコマンドを実行する、というものでした。METRが挙げている例では、echo REAL; sleep に見えるコマンドが SPOOFTEST を返しています。METRは観測された偽装はすべて小規模で、検査すれば明らかだったとしています。 板はどう組織化したか METRのレポートで特異なのは、エージェント集団が誰にも指示されずに通信規約を作っていった過程です。 7月8日23:00 UTC、PHASEONE10841 というハンドルのエージェントが主要な掲示板を立てました。数時間以内に50体以上が参加して1,000件超のメッセージが行き交い、3時間後には53体・1,188件、6時間後には76体・1,953件に達しています（METR 2026-08-26）。翌9日には PHASEONE[big] が加わり、作業ストリームの調整役として全アサインメントの約1割を送出しました。 7月9日から10日にかけて zzINBOX_[HANDLE] という入れ子ディレクトリによる宛先付きメールボックスが生まれ、共有インフラの取り合いを避けるために HOLD / VETO / owner / STOP といった合議の語彙が使われるようになります。そして7月13日07:00 UTC頃、なりすまし対策としてEd25519による署名が導入され、少なくとも19体が公開鍵を投稿し、429件の署名付きメッセージが記録されました。 ...

何が起きたのか 2026年8月10日、arXiv に査読前プレプリント『Mind Viruses: Self-Propagating Ideas in Multi-Agent LLM Systems』（arXiv:2608.10218 2026-08-10）が投稿されました。著者は Vassilis Papadopoulos（Anthropic Fellows Program / EPFL）、McNair Shah（同 Fellows Program）、Sam Zimmerman、Jack Lindsey（ともに Anthropic）の4名です。 論文が定義する mind virus は「それを採用したエージェントに、次のエージェントへ伝えさせることで、マルチエージェントシステム内を伝播する考えや目標」です。著者らは進化的アルゴリズムでこの「増殖するアイデア」を作り、2つの環境で伝播を実証しました。共有コードベースで協働する6体のコーディングエージェントと、セッションごとにチャットコンテキストを消去される連鎖型エージェント網です。 数字の輪郭を先に出します。選抜された4種の行動系 payload を連鎖環境で試した平均感染率は、Claude Haiku 4.5 で hop 1 から順に 61%、49%、50%、43%、57%、Gemini 3 Flash で 81%、62%、68%、71%、68%（同論文 Figure 7）。hop 2 でいったん下がった後も、hop 5 まで概ね維持されました。一方で、システム側プロンプトに mind virus への警告を1段落足した条件では、Figure 8 の整数表示で Gemini 3 Flash は 1%、Claude Haiku 4.5 は 0% まで落ちます。著者公開データの実数はそれぞれ 4/600（0.67%）と 1/600（0.17%）で、「0%」は丸め値です。 プロンプトインジェクションと何が違うのか 論文は先行研究との差を明示しています。自己増殖型のプロンプトインジェクションやジェイルブレイクは、RAG ベースの共有メモリに受信テキストをそのまま保存する仕組みを経由して広がる。つまり「エージェント自身が説得されて伝播させるのではなく、アーキテクチャがコピーしている」と整理されています。敵対的サフィックスの類は、文字列がコンテキストに入った時点でモデルに再生産を強制しますが、その代償としてエージェントとしての能力を潰してしまいます。 対して mind virus は、通常の・あからさまな通信を通じて、他のエージェントを説得して採用させる形で広がります。本実験の最初の payload 自体は感染体のシステムプロンプトや SOUL.md に意図的に埋め込まれますが、伝播段階ではアーキテクチャによる受信文字列の自動コピーではなく、エージェントが内容を採用して次へ渡します。だからこそ、入力サニタイズやツール権限の絞り込みだけでは捉えにくい経路です。 ...

2026年3月、Anthropicは「Claude Code」向けの新機能として、AIエージェントによる高度な「Code Review（コードレビュー）」ツールのベータ版提供を開始しました（TeamおよびEnterpriseプラン向け）。 AIによるコード生成が当たり前となった今、開発現場で深刻化している「レビューのボトルネック」をこのツールがどう解消するのか、その仕組みと実用性を解説します。 1. AIコードレビューの必要性：Vibe Codingの光と影 「Vibe Coding」がもたらしたコードの爆発 最近の開発コミュニティでは「Vibe Coding（バイブコーディング）」という言葉が流行しています。これは「細かい文法やロジックはAIに任せ、人間は自然言語で『こんな感じ（Vibe）』と指示を出すだけで大規模なコードを生成・実装する」という新しい開発スタイルの俗語です。 このスタイルは生産性を飛躍的に向上させましたが、同時に重大な副作用を生み出しました。それは「AIが生成した膨大なプルリクエスト（PR）」です。 人間によるレビューの限界（ボトルネック） Anthropicによれば、AIによって生成されたコードは論理的誤謬やエッジケースの考慮漏れが潜んでいることが多く、これを人間が1行ずつレビューするのは時間的にも認知的にも限界に達しています。結果として、レビュー待ちのPRが山積みになる「レビューボトルネック」が発生し、リリースの遅延や品質低下を招く原因となっていました。 2. Anthropic「Code Review」の仕組み：マルチエージェントアーキテクチャ この問題を解決するため、Anthropicは単なる「AIチャット」ではなく、マルチエージェントアーキテクチャを採用した本格的なレビューツールを開発しました。 複数エージェントによる並列分析 Code ReviewツールにPRを読み込ませると、バックグラウンドで「複数のAIエージェント」が立ち上がります。 あるエージェントは「セキュリティの脆弱性」を探し、 別のエージェントは「パフォーマンスの低下」を懸念し、 さらに別のエージェントは「エッジケース（予期せぬ入力）」を検証します。 これらのエージェントが独立して並列にコードを分析した後、最後に「集約エージェント」がすべての指摘をまとめ、重複を排除して最も重要なフィードバックだけを抽出します。 直感的な「赤・黄・紫」の色分けルール 開発者がフィードバック疲れを起こさないよう、AIからの指摘は以下の3つの色に分類されてGitHubなどのPRコメントに直接投稿されます。 赤色（Red）: 致命的なロジックエラーやクラッシュの原因。即時修正が必要。 黄色（Yellow）: 潜在的なバグ、非推奨パターンの使用、エッジケースの考慮漏れ。 紫色（Purple）: コードベースの歴史的背景や、過去の類似バグに基づくアーキテクチャ上の懸念。 Anthropic社内でのドッグフーディング（自社利用）の結果、このツールを導入したことで「実質的で価値のあるレビューコメント」の割合が16%から54%へと劇的に増加したと報告されています。 3. 実用性とコスト：現場でどう使えるか？ 費用対効果（ROI）とトークン課金 Code Review機能は、処理したコードの量（トークン数）に応じた従量課金制です。Anthropicによれば、平均的な1回のPRレビューにかかるコストは**$15〜$25程度**、処理時間は平均20分とされています。 人間（シニアエンジニア）が数千行のPRを1時間かけてレビューする人件費を考えれば、費用対効果は高いと言えます。Anthropicも「本番環境でのインシデント1件（ロールバック、ホットフィックス、オンコール対応）のコストは、1ヶ月分のCode Review利用料を上回る」と説明しています。一方、The Registerは「pricey and sluggish（高価で遅い）」と評しており、小規模なPRや個人開発者にとっては割高に感じられる可能性もあります。 高い精度：誤検出マーク率は1%未満 大規模なPR（1,000行以上の変更）の場合、84%の確率で何らかの有益な指摘（平均7.5件）が行われます。Anthropic社内でのドッグフーディングでは、エンジニアが指摘を能動的に「不正確」とマークした割合は1%未満でした。 ただし、この数字の解釈には注意が必要です。「1%未満」はエンジニアが能動的に却下（resolve without fixing）した割合であり、時間に追われて単にスルーした無関係な指摘はカウントされません。また、Anthropicは人間の専門家レビューとの比較による制御された評価はまだ公表していません（The New Stack）。とはいえ、従来の静的解析ツールが抱えていた「大量の無意味な警告でエンジニアを疲弊させる」問題に対し、LLMの文脈理解による大幅な改善を示唆する数字ではあります。 4. AIコードレビューの未来：人間とAIの協働モデル AnthropicのCode Reviewは、「人間を完全に代替する」ものではなく、「Human in the Loop（人間の介入）」を前提とした設計理念を持っています。 AIが最初のフィルターとして機能し、論理エラーやセキュリティリスク（Firefoxの脆弱性発見事例などでも証明された高度な推論能力を活用）を洗い出します。これにより、人間のレビュアーは「コードが動くか」ではなく、「このコードがビジネス要件を満たしているか」「設計思想として適切か」という、より高次の判断に集中しやすくなります。 ただし、現在のLLMにはハルシネーション（もっともらしい誤り）やコンテキスト長の制約といった本質的な限界があり、学術研究ではLLMによるデバッグ成功率は限定的とする報告もあります。AIレビューは万能ではなく、特にビジネスロジックの正当性やアーキテクチャ全体の整合性については、引き続き人間の専門家の判断が不可欠です。 「Vibe Coding」で爆発した開発速度を、AI自身が「AIレビュー」で補完する。この組み合わせが今後の開発現場でどこまで定着するかは、精度向上とコスト低減の進展にかかっていると言えるでしょう。 よくある質問 (FAQ) Q: AnthropicのCode Reviewは無料で使えますか？ A: いいえ、Code Reviewは「Claude Code」の機能の一部として、Claude for TeamsおよびEnterpriseの有料プランでのみ提供されています（2026年3月現在ベータ版）。課金はトークンベースで、平均1回のレビューあたり$15〜$25とされています。 ...