マルチエージェント

Claude Code を使って1,255体ものAIペルソナを動かし、歌舞伎町の夜（22:00〜02:00）を丸ごとシミュレーションするという実験が話題になっています。AIエージェント研究者の「すぐる」さん（@SuguruKun_ai）が実施したこの試みは、マルチエージェントAIによる社会シミュレーションの新たな可能性を示しています。 実験の概要 実験のセットアップはシンプルながら規模が大きいものです。 使用ツール: Claude Code AIエージェント数: 1,255体 シミュレーション対象: 歌舞伎町（新宿）の夜 シミュレーション時間: 22:00〜02:00（4時間） 実行方式: 240分を1分刻みで回す（タイムステップ方式） 各AIエージェントには固有のペルソナが与えられ、「それぞれの人生を抱えて歌舞伎町を彷徨う」という設定です。観光客、ビジネスマン、地元住民など、異なる背景を持つ人物像がリアルな夜の繁華街を動き回ります。 驚きのシミュレーション結果 240分のシミュレーションを実行した結果、現実の歌舞伎町を彷彿とさせるリアルな数値が出ました: 指標 結果 予算超過率 53.7% 客引き遭遇 224件 ぼったくり被害者 23人（観光客の11.5%） 総消費額 ¥29,517,700 特に「観光客の11.5%がぼったくり被害に遭う」という数値は、現実の繁華街リスクと照らし合わせても説得力があります。予算超過率53.7%は、夜の歌舞伎町での出費が予想外に膨らみやすいという現実を的確に捉えています。 なぜこの実験が面白いのか AIエージェントによる社会現象の再現 従来の社会シミュレーションは、統計モデルやルールベースのシステムで行われてきました。しかし今回の実験では、LLM（大規模言語モデル）ベースのエージェントが「意思決定」を行います。各ペルソナが自分の「人生」に基づいて行動するため、事前にプログラムしていなかった社会現象（ぼったくりの被害パターン、予算オーバーの傾向など）が創発（個々のルールには存在しないのに全体として現れる現象）として観察されます。 スケールの壁を超えたClaude Code 1,255体のエージェントを同時に動かすには、大量の並列処理が必要です。Claude Code のエージェントオーケストレーション能力を活用することで、こうした大規模マルチエージェントシミュレーションが個人の研究レベルで実現できるようになっています。 「1分刻み」のタイムステップ設計 240分（4時間）を1分ごとに区切って処理する設計は、「リアルタイム性」よりも「因果の連鎖」を追うための工夫です。ある時間帯の客引き遭遇が、次の分の意思決定に影響を与えるという連鎖が、リアルな消費行動を生み出します。 社会シミュレーションの応用可能性 この種の実験は、歌舞伎町という特定シナリオにとどまらず、幅広い応用が考えられます: 都市計画: 新しい施設や道路が人の流れに与える影響を事前シミュレーション 防災・安全対策: 緊急時の避難行動パターンの予測 経済政策: 価格変動や規制変更が消費者行動に与える影響分析 マーケティング: 特定の顧客層がどのような意思決定プロセスを経るかの理解 技術的なポイント ペルソナ設計の重要性 1,255体のAIに「それぞれの人生」を持たせるには、多様なペルソナ定義が必要です。年齢、職業、予算感、リスク許容度、アルコール耐性など、現実の人間の多様性を反映したパラメータ設定が、シミュレーションの精度を決定します。 LLMの「常識」を活用する ルールベースのシミュレーションと異なり、LLMベースのエージェントは「客引きに声をかけられたらどうするか」という判断を、事前に全パターンを列挙しなくても処理できます。モデルが持つ常識的知識と推論能力が、複雑な社会的相互作用を自然に再現します。 まとめ Claude Code × 1,255体のAIによる歌舞伎町シミュレーションは、マルチエージェントAIが社会科学的な研究ツールとして機能することを示した好例です。現実社会のリスク分布（ぼったくり被害11.5%・予算超過53.7%）を定量的に再現した点が、この実験の最大の価値といえます。 LLMの「個々の判断能力」と「大規模並列実行」を組み合わせることで、これまで計算コストや設計コストが高すぎて実現できなかった社会シミュレーションが、個人の研究者レベルで実行可能になってきています。 元の X スレッドでは順を追った詳細解説も公開されているので、技術的な実装に興味がある方はぜひチェックしてみてください。 参照: 元ツイート: https://x.com/SuguruKun_ai/status/2048692949282889870 著者: すぐる | ChatGPTガチ勢 𝕏 (@SuguruKun_ai)

概要 多数の AI エージェントを仮想空間で自律的に行動させ、エージェント間の相互作用から生まれる創発的な社会現象を観察・分析する研究手法。都市計画・安全保障・宇宙開発など広範な領域への応用が期待される。 仮想渋谷シミュレーション スペースデータ社（佐藤航陽氏）が取り組む事例では、AI エージェントを仮想の渋谷に解き放ち、AI 同士が自律的に飲みに行く・LINE する・遊ぶといった社会的行動を行う人工生態系を構築している。Stanford 大学の「Generative Agents」研究の大規模・都市特化版と位置づけられる。 創発の観察価値 個々のエージェントのルールは単純でも、多数が相互作用することで予測不能なパターン（創発）が生まれる: 人が集まりやすい「ホットスポット」の自然発生 情報が口コミのように広がる速度・経路の可視化 緊急事態（災害）時の群衆行動のシミュレーション 3 つの応用領域 領域 活用例 都市開発 施設建設後の人流シミュレーション、交通渋滞予測 安全保障 情報拡散・デマ・プロパガンダの影響モデリング 月面開発 閉鎖環境でのリソース配分と長期コミュニティ維持 先行研究 Generative Agents（Stanford 大、2023年）: 25 体の LLM エージェントが自律的に行動する「Smallville」実験。会話・計画・記憶を持つエージェントが社会的パターンを自発的に形成することを示した。仮想渋谷シミュレーションはこの発展版と見なせる。 関連ページ AI エージェント — シミュレーションの構成単位 マルチエージェント調整パターン — 複数エージェントの協調設計 ソース記事 仮想渋谷に AI エージェントを解き放つ — 社会シミュレーションが都市・安全保障・月面開発に活きる理由 — 2026-04-15

スペースデータ社長の佐藤航陽氏が、興味深い社会シミュレーション実験を紹介している。大量のAIエージェントを仮想の渋谷に解き放ち、AI同士が遊んだりLINEしたり飲みに行ったりと自律的に暮らす「人工生態系」を構築するというプロジェクトだ。 大量のAIエージェントを仮想の渋谷に解き放って活動させる社会シミュレーション。AI同士が遊んだりLINEしたり飲みに行ったりと好き勝手に暮らす人工生態系。AI同士の相互作用と創発を観察することで、都市開発・安全保障・月面開発にも活きる。 — 佐藤航陽（さとうかつあき）@ka2aki86 仮想渋谷のAIエージェント生態系とは このシミュレーションの特徴は、AIエージェントを「タスク実行マシン」ではなく「社会的な存在」として扱う点にある。 自律的な意思決定: 各エージェントが自分の判断で行動を選択する 社会的な相互作用: AI同士が会話し、グループを形成し、関係性を構築する 日常的な活動: 飲みに行く、LINEする、遊ぶといった人間の行動を模倣する 渋谷という舞台: 実在の都市を仮想空間に再現し、リアリティを持たせる マルチエージェントシミュレーションとしては「Generative Agents」（Stanford大の研究）が先駆的な成果として知られるが、渋谷という具体的な都市空間を舞台にした大規模版という位置付けとなる。 なぜ「創発」の観察が重要なのか 個々のAIエージェントに与えるルールは単純でも、多数が相互作用することで予測不能なパターン（創発）が生まれる。これがこのシミュレーションの核心だ。 たとえば： 特定のエリアに人が集まりやすい「ホットスポット」が自然発生する 情報が口コミのように広がる速度・経路が可視化できる 緊急事態（災害など）の際、群衆がどう動くかをシミュレートできる こうした現象を観察・分析することで、現実世界の都市設計や政策立案に役立つデータが得られる。 3つの応用領域 佐藤氏が挙げる応用領域は、一見すると無関係に見えるが、いずれも「多数の人間（またはエージェント）が限られた空間でどう行動・協調するか」という共通テーマでつながっている。 都市開発 新しい施設を建てた場合の人流シミュレーション 商業エリアの最適配置の検証 交通渋滞や混雑を事前に予測するモデリング 安全保障 情報拡散（デマ・プロパガンダ含む）のシミュレーション サイバー攻撃時の社会的影響のモデリング 危機時の住民行動予測と対応策の検討 月面開発 スペースデータが手がける宇宙開発の文脈では特に重要だ。月面基地のような閉鎖環境での人間（またはロボット）の行動最適化、限られたリソース配分のシミュレーション、長期的なコミュニティ維持のモデルなど、地球上での社会シミュレーションが直接活用できる。 マルチエージェント研究の潮流 2026年現在、AIエージェント研究はツール呼び出しや単一タスク完結から、複数エージェントが協調・競合する「マルチエージェントシステム」へと急速にシフトしている。 Anthropicの「Claude」やOpenAIの「GPT-4o」などの大規模言語モデルをベースにしたエージェントは、複雑な状況判断や自然言語コミュニケーションを自律的に行えるようになった。これを多数並列稼働させることで、従来のルールベースシミュレーションでは再現できなかった「人間らしい」社会ダイナミクスの再現が可能になっている。 まとめ 仮想渋谷でのAIエージェント社会シミュレーションは、単なる技術的な面白さを超えて、現実世界への応用価値を持つ研究だ。AI同士の相互作用から生まれる創発現象を観察・分析することで、都市計画から宇宙開発まで、広範な領域で人間の意思決定を支援するツールになり得る。 佐藤氏のビジョン──「宇宙の民主化」を目指しながら地球上の社会シミュレーションを積み重ねるアプローチ──は、AIエージェント技術の一つの未来像を示している。

Claude Code を使って、20カ国それぞれにAIエージェントを配置し、自律的に外交・貿易・紛争をシミュレートする「世界AIシミュレーター」を作っている開発者が話題になっています。放っておくと日米AI同盟が自然発生したり、中国AIがレアアース輸出制限を発動したりと、リアルな地政学ドラマがAIによって自動生成される面白い試みです。 「世界AIシミュレーター」とは すぐる氏（@SuguruKun_ai）が Claude Code を使って開発中のプロジェクトで、世界20カ国それぞれにAIエージェントを配置し、各国AIが自律的に外交判断を下して動く「世界AIシミュレーター」です。 主な特徴は以下の通りです: 20カ国のAIエージェント: それぞれの国を担当するAIエージェントが独立して意思決定する 自律外交: 同盟、貿易協定、技術共有、紛争まで全部自動でAIが判断 3Dビジュアライゼーション: 3D地球儀上でリアルタイムにビームが飛び交う タイプライター演出: 外交チャットがタイプライター効果でリアルに流れる ライブニュース速報: 画面下部にニュース速報がLIVE表示される Claude Code でマルチエージェント地政学シミュレーション このプロジェクトの技術的なポイントは、Claude Code を使ってマルチエージェントシステムを構築している点です。各国エージェントは以下のような判断を自律的に行います: 外交アクション 同盟締結: 他国AIと交渉して軍事・経済同盟を形成 貿易協定: 輸出入条件を自律交渉して協定を締結 技術共有: AI・半導体・エネルギー等の技術移転協議 経済制裁: 対立国へのレアアースや輸出制限の発動 リアルで面白い展開 実際に動かすと予想外のドラマが生まれるとのことです: 「放っておくと勝手に日米AI同盟が組まれたり、中国AIがレアアース輸出制限を発動したりして普通に面白いです笑」 （すぐる氏 @SuguruKun_ai） 現実の地政学的文脈を反映したかのような判断をAIが自律的に下す様子は、単なるランダムなシミュレーションを超えて、実際の国際関係の力学を模倣しているようにも見えます。 マルチエージェントシステムの設計パターン このような「複数AIエージェントが自律的に相互作用するシステム」を Claude Code で構築する際の一般的なパターンを整理します。 エージェント間通信の設計 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 # 各国エージェントの基本構造（概念的な例） class CountryAgent: def __init__(self, country_name: str, context: dict): self.country = country_name self.context = context # 国の状況・価値観・戦略 def evaluate_proposal(self, proposal: dict, from_country: str) -> dict: """外交提案を評価して応答を返す""" prompt = f""" あなたは{self.country}の外交担当AIです。 {from_country}から以下の提案が届きました: {proposal} 現在の国際情勢: {self.context} この提案を受け入れるか、修正提案を出すか、拒否するかを判断してください。 """ # Claude API でエージェントの判断を生成 return call_claude(prompt) def decide_action(self, world_state: dict) -> dict: """現在の世界情勢を見て次のアクションを決定""" # 外交提案・経済制裁・同盟申請などを自律生成 ... リアルタイムビジュアライゼーション 3D地球儀上でのリアルタイム表示には、実際の使用技術は公開されていませんが、以下のような構成が一般的です: ...

Anthropic が 2026 年 4 月 10 日に公開したブログ記事「Multi-agent coordination patterns: Five approaches and when to use them」では、複数のAIエージェントを協調させるための 5 つのパターンが紹介されています。 それぞれのパターンを整理してみます。 1. Generator-Verifier（生成・検証） 概要: 一方のエージェントが出力を生成し、もう一方のエージェントが明示的な基準に照らして検証します。検証が失敗した場合、フィードバックが生成エージェントに戻り、条件を満たすか最大反復回数に達するまでループします。 向いているケース: コード生成＋テスト実行のような、品質が最重要でかつ評価基準を明確に定義できるタスク。 注意点: 検証の質は定義した基準の質に完全に依存します。評価基準の設計を省略すると、「品質管理をしているという幻想」だけが残ってしまいます。 2. Orchestrator-Subagent（オーケストレーター・サブエージェント） 概要: リーダー役のエージェントが作業を計画し、専門化されたサブエージェントに明確な境界付きのタスクを委任します。サブエージェントは作業を実行し、結果をオーケストレーターに返します。オーケストレーターは各結果を統合して最終的なアウトプットを生成します。 向いているケース: セキュリティ・テストカバレッジ・スタイルをそれぞれ別エージェントが担当するコードレビューのように、サブタスクの依存関係が少ない明確なタスク分解ができる場合。 注意点: サブエージェント同士で発見した情報に依存関係が生じると、オーケストレーターが「情報のボトルネック」になります。また、明示的に並列化しない限り、サブエージェントは逐次実行されるためスループットが制限されます。 推奨: Anthropic は「大半のユースケースでまず試すべきパターン」としてこのパターンを位置づけています。最も問題の幅広さをカバーしつつ、調整のオーバーヘッドが最小限です。 3. Agent Teams（エージェントチーム） 概要: コーディネーターがキューからタスクを取得する 永続的な ワーカーエージェントを生成します。ワーカーは複数のステップにわたって自律的に作業し、担当コンポーネントのドメイン知識を蓄積します。 向いているケース: 大規模コードベースのサービス移行のように、エージェントが担当範囲に習熟しながら並列で長期間実行するタスク。 Orchestrator-Subagent との違い: サブエージェントが単発タスクで消えるのに対し、チームワーカーはアサインをまたいで生存し続けるため、ドメイン知識が蓄積される。 注意点: タスク間の独立性が必要で、エージェント同士が中間結果を共有しにくい。タスク時間がばらつく場合、完了検知が難しくなります。 4. Message Bus（メッセージバス） 概要: エージェントが共有ルーターを介してトピックをパブリッシュ・サブスクライブします。ルーターはマッチングメッセージを配信しますが、実行順序はあらかじめ決まっていません。 向いているケース: セキュリティアラートが多段階の調査を動的にトリガーするようなイベント駆動パイプラインで、どのエージェントが関与するかがリアルタイムに決まる場合。 注意点: イベントが複数エージェントを連鎖的にトリガーすると、トレーサビリティが困難になります。ルーターがイベントを誤分類すると、エラーが静かに発生します。 5. Shared State（共有ステート） 概要: 中央コーディネーターを置かず、エージェントが永続ストレージに直接読み書きします。エージェントは他エージェントの発見をリアルタイムで参照しながら協調的な知識を蓄積します。 向いているケース: 一方の調査結果が即座に他方のエージェントの探索方向に影響する、協調型のリサーチタスク。単一障害点がなくなるというメリットもあります。 注意点: 収束条件がないとエージェントが際限なく反応し合い、トークンを無駄に消費します。「時間予算・収束閾値・終了エージェントの指定」のいずれかによる明示的な終了条件が必須です。 ...

概要 Anthropic が 2026年4月に公開した、複数 AI エージェントを協調させるための5つの設計パターン。「まず Orchestrator-Subagent から始め、観察した制約に応じて発展させる」という設計哲学が基本。 5 つのパターン 1. Generator-Verifier（生成・検証） 一方のエージェントが出力を生成し、もう一方が明示的な基準で検証。不合格なら生成エージェントにフィードバックが戻り、合格か最大反復回数に達するまでループ。 向いているケース: コード生成＋テスト実行など、品質基準が明確なタスク 注意点: 検証基準の設計が甘いと「品質管理の幻想」になる 2. Orchestrator-Subagent（オーケストレーター・サブエージェント） リーダーエージェントが計画を立て、専門化されたサブエージェントにタスクを委任。Anthropic 推奨のデフォルト出発点。 向いているケース: セキュリティ・テストカバレッジ・スタイルを分担するコードレビュー等 注意点: サブエージェント間の依存が高いと情報ボトルネックになる 3. Agent Teams（エージェントチーム） コーディネーターが永続的なワーカーエージェントを生成。ワーカーはアサインをまたいで生存し、ドメイン知識を蓄積する点が Orchestrator-Subagent との違い。 向いているケース: 大規模コードベースの長期・並列マイグレーション 注意点: タスク間の独立性が必要。完了検知が難しい 4. Message Bus（メッセージバス） エージェントが共有ルーター経由でパブリッシュ・サブスクライブ。実行順序があらかじめ決まらないイベント駆動型。 向いているケース: セキュリティアラートが動的に多段階調査をトリガーするようなパイプライン 注意点: イベント連鎖のトレーサビリティが低下しやすい 5. Shared State（共有ステート） 中央コーディネーターなしに、エージェントが永続ストレージを直接読み書き。他エージェントの発見をリアルタイムに参照できる。 向いているケース: 一方の調査が即座に他方の探索方向に影響する協調リサーチ 注意点: 収束条件が必須。なければ際限なくトークンを消費する 選択の目安 パターン 向いているケース Orchestrator-Subagent 多くのユースケースの出発点 Generator-Verifier 品質基準が明確で反復検証が必要 Agent Teams 並列・長期・ドメイン蓄積が必要 Message Bus イベント駆動で動的にワークフローが変化 Shared State エージェント間でリアルタイムに知識を共有したい 実際のプロダクションでは複数パターンを組み合わせることも多い。 関連ページ Claude Managed Agents エージェントメモリのロックイン ハーネスエンジニアリング ソース記事 Anthropic が解説するマルチエージェント調整パターン 5 選 — 2026-04-11 Claude Managed Agents のアーキテクチャ: Brain / Session / Hands の分離設計 — 2026-04-10

Claude Code のエージェントを40体つくり、役割を分けてルールを書いて階層もつくった。1ヶ月後、ぜんぶやめた。こはく氏（@Kohaku_NFT）の実体験レポートから、AIエージェント大量運用が構造的に壊れる理由と、そこから見えた「壊れない設計」の考え方を整理する。 やったこと Claude Code の Max プラン（月$200）1アカウントで検証 リーダー、ライター、リサーチャー、コーダー、レビュアーなど40体のエージェントを構築 役割分担、ルール、階層、性格設定まで丸2日かけて設計 最初の3日間は動いた。指示を出せばちゃんと返ってくる。SNS でスクショをあげようとした矢先に崩壊が始まった。 壊れる3つの構造的理由 理由1: Context Rot（記憶の腐敗） Context Rot とは、コンテキストウィンドウに情報が溜まるほど古い情報の精度が落ちる現象のこと。Anthropic の公式ドキュメントにも「トークン数が増えるほど、精度と想起（思い出す力）が劣化する」と明記されている。 1000ページの社内マニュアルと同じ構造 — 人間が全ページを暗記できないように、AIも情報が多すぎると処理しきれなくなる 「100万トークン入る」と「安定して使える」は別物 — 公式でさえ「文脈は大きければいいわけではない」と警告している こはく氏の実測では、10万トークンを超えるとブレが目立ち始めた ルール、コード、会話履歴が積み上がるほど再現性は低下する。 理由2: Compaction 後に構成が崩れる 長時間運用すると、コンテキストウィンドウの容量を確保するために前半の会話内容が自動で要約・圧縮される仕様（compaction）がある。Claude Code の公式リリースノートにも「圧縮後に一部のエージェントが消えたり、重複して生成される不具合」が明記されている。 会話の流れの中だけで役割や引き継ぎを設定していると、圧縮が走った瞬間にその前提ごと消え去る 会社でいうと「引き継ぎなしの二重配属」 — 過去の議事録を読まずに中途配属され、すでに同じ業務をしている人がいることも知らない状態 40人体制で3時間回せば、ほぼ確実に圧縮が走る。そのたびに「今、誰が消えた？」を人間が確認するハメになる 理由3: テキストのルールは絶対命令じゃない 「自分で作業するな。指示だけ出せ」と書いても、Claude が毎回きれいに従うとは限らない。 LLM にとってルール文は、絶対命令ではなく、文脈の一部として処理される。履歴、途中のやりとり、直前の出力に引っ張られて解釈がズレる。 最近の評価研究でも、LLM は「どの指示を優先するか」の判断や長い文脈での安定した instruction following に弱さがあると報告されている。ルールが増えて競合し始めるほどズレる前提で見たほうがいい。 厳密に書けば書くほど、今度はルールが長くなって context rot が進む。この構造そのものが、人数を増やしたときの壁になる。 「育てれば良くなる」は順番の問題 「使い込むほど育つ」とよく聞くが、ここで否定しているのは育成そのものではなく順番の話。 guidelines を育てるということは、ファイルが増えるということ。ファイルが増えるということは、コンテキストが重くなるということ。つまり context rot が加速するだけ。 壊れやすい仕組みの上に知識を積んでも、崩れやすくなるだけだ。 人間の会社で考えても同じ: エスカレーションルールがない トラブル時の判断基準がない 報告のかたちもない そんな会社は人を増やすほど混乱する。AI組織もまったく同じ構造。 エージェントには視野がない ここが核心。 ...

Anthropic の研究者 Prithvi Rajasekaran 氏が、Claude を使ってフルスタックアプリケーションを自律的に構築する「3エージェント・ハーネス」アーキテクチャを公開しました。人間の介入なしに6時間でプレイ可能なゲームエディタを完成させた事例とともに、その設計思想を解説します。 「ハーネス設計」とは何か 「ハーネス（harness）」とは、AI モデルを単体で走らせるのではなく、モデルの外側に構築する制御構造・オーケストレーションロジック全体を指します。具体的には、どのエージェントがどの順番で何を担当するか（役割分離）、エージェント間でどう情報をやり取りするか（契約の交渉）、いつ次に進みいつやり直すか（判定ループ）、何を使ってテストするか（ツール選択）といった設計要素が含まれます。 モデル自体の性能向上とは別の軸で、この制御層をどう設計するかが自律開発の品質を左右します。 背景: AI は自分に甘すぎる このアーキテクチャが生まれた核心的な課題は、AI モデルが自分の出力に対して甘い評価をしがちであるという点です。 「自分が生成した成果物を評価させると、エージェントは自信を持ってそれを称賛する傾向がある —— 人間の目から見れば明らかに品質が低い場合でさえ」（Rajasekaran 氏） この問題は、デザインのような正解/不正解が明確でない領域で特に顕著です。コードにおいても、理論上は正しさを検証できるはずですが、AI エージェントは自分のエラーをスルーしてしまいがちです。 解決策として採用されたのが、GAN（Generative Adversarial Network: 敵対的生成ネットワーク）に着想を得た分離アプローチ —— 「作る役割」と「評価する役割」を完全に分けるという設計です。 3エージェント・アーキテクチャ 最終的に構築されたハーネスは、以下の3つの専門エージェントで構成されるアーキテクチャになっています。 エージェント 役割 Planner 1〜4文のアイデアを完全な製品仕様に展開 Generator 機能ごとにスプリント方式で実装 Evaluator 実行中のアプリを Playwright でテスト・採点 flowchart TD A["ユーザー\n1〜4文のアイデア"] --> B["Planner\n製品仕様に自動展開"] B --> C["スプリント契約の交渉\n終了条件の事前合意"] C --> D["Generator\nReact/Vite/FastAPI で実装"] D --> E["Evaluator\nPlaywright MCP で実アプリテスト"] E -->|"採点: 製品深さ・機能性\nデザイン・コード品質"| F{合格?} F -->|"不合格\nバグ報告 + 改善指示"| D F -->|"合格"| G{次のスプリント?} G -->|"あり"| C G -->|"なし"| H["完成アプリ"] Planner: 仕様の自動展開 初期バージョンでは、生のプロンプトを渡すとモデルがタスクを過小評価する問題がありました。十分に考える前にビルドを開始してしまい、機能の薄いアプリが生成されていたのです。Planner はこの問題を解決するために追加されたエージェントで、短いアイデアを詳細な製品仕様に自動展開します。 ...

Claude Code に「Agent Teams」機能が追加されました。複数のセッションがメッセージをやり取りしながら協調作業できる機能です。 従来のサブエージェントは親セッションに結果を返すだけでしたが、Agent Teams ではエージェント同士が直接コミュニケーションを取りながらタスクを進められます。 Agent Teams とは Agent Teams は Claude Code v2.1.32 以降で利用できる実験的機能です。1つのセッションがチームリーダーとなり、複数のチームメイト（それぞれ独立した Claude Code インスタンス）を起動して並列に作業を進めます。 各チームメイトは独自のコンテキストウィンドウを持ち、共有タスクリストを通じて自律的に連携します。 サブエージェントとの違い 比較項目 サブエージェント Agent Teams コンテキスト 独自のコンテキスト、結果を呼び出し元に返却 独自のコンテキスト、完全に独立 コミュニケーション 親エージェントへの一方向のみ チームメイト同士で直接メッセージ送受信 調整方法 親エージェントが全体を管理 共有タスクリストで自己調整 適した用途 結果だけが必要な集中タスク 議論・協調が必要な複雑な作業 トークンコスト 低い（結果が親コンテキストに要約される） 高い（各チームメイトが個別の Claude インスタンス） SendMessage によるエージェント間通信 Agent Teams の中核となるのが SendMessage ツールです。2つの通信方式が用意されています。 directed message: 特定のチームメイトにメッセージを送信 broadcast: 全チームメイトにメッセージを一斉送信 メッセージは各チームメイトの受信ボックスに JSON として追記されます。受信ボックスのパスは ~/.claude/teams/<project>/inboxes/<name>.json です。メッセージは次のターンで読み取られ、会話履歴に新しいユーザーターンとして注入されます。 有効化と使い方 Agent Teams はデフォルトで無効です。~/.claude/settings.json で環境変数を設定して有効化します。 1 2 3 4 5 { "env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" } } 有効化後は、自然言語でチーム構成を指示するだけで起動できます。 ...