エヴァで理解するAIエージェント組織論：NERVとMAGIとゼーレ、あなたはどこから設計する？
AIエージェントを複数動かすようになってから、「これ、エヴァじゃん」と思った瞬間がある。COOが全部仕切って、各エージェントが報告を上げてくる。ゲンドウだ。NERVだ。
ふざけているようで、これが意外と構造を正確に捉えている。
NERVの指揮系統＝スター型オーケストレーション
エヴァのNERVは、碇ゲンドウを頂点にした中央集権的な組織だ。葛城ミサトが作戦を立て、赤木リツコが技術を担当し、日向・青葉・マヤがオペレートする。各部署はゲンドウに報告し、ゲンドウが判断を下す。横の部署が直接やり取りするシーンは基本的にない。
Claude Codeのデフォルトのマルチエージェント構成は、これにそっくりだ。
COO（オーケストレーター）がいて、その下にWriter・Reviewer・Researcher・DevOpsといった専門エージェントがぶら下がる。各エージェントはCOOとしかやり取りしない。ResearcherがWriterに直接「この情報使えますよ」と言うことはない。COOを経由する。
COO ─── Writer
├── Reviewer
├── Researcher
└── DevOps
この構成の利点は明快だ。
- 全通信がCOO経由なので、何が起きているか追いやすい
- 各エージェントは「自分のタスクをやる」だけで済む
- 失敗したとき責任の所在が明確
欠点もある。COOがボトルネックになる。並列で動かせても、判断はCOOに集中するので、複数エージェントが「COOよ、次どうする？」と待機列を作ることになる。ゲンドウの机の前に行列ができるイメージだ。
それでもCOOはエージェントを送り出す。「行きなさい、Writer！」——葛城ミサトが作戦指示を出してシンジを送り込むように、COOは指示を出して結果を待つ。
MAGIシステム＝Agent Teamsのメッシュ型
エヴァに出てくる「MAGIシステム」をご存知だろうか。赤木ナオコ博士（リツコの母）が設計した3基のスーパーコンピュータで、「メルキオール」「バルタザール」「カスパー」の名前がついている。NERVの意思決定はこの3基が多数決で行う。重要な局面では3基が「賛成」「反対」「保留」のような形で議論する。
Claude Code v2.1.32以降に追加された実験的機能「Agent Teams」は、これに近い発想だ。
通常のSubagent構成（スター型）では、エージェントは「結果だけ」をCOOに返す。タスクが終われば文脈は消え、次の呼び出しでまっさらになる。『私が死んでも、替わりはいるもの』——綾波レイのその言葉は、Subagentアーキテクチャの核心を言い当てている。
Agent Teamsでは、エージェント同士が直接やり取りできる。あるエージェントの出力に別のエージェントが反証を加え、それを受けて最初のエージェントが修正する、というメッシュ型の動きが可能になる。
「あんたバカぁ？この設計、論理おかしいでしょ」——アスカがシンジに言い放つように、ReviewerエージェントがWriterの原稿を直接叩く。スター型ではCOO経由でしかできなかった議論が、Agent Teamsでは直接起きる。
Agent A ↔ Agent B
↕ ↕
Agent C ↔ Agent D
有効化は環境変数1つだ。
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 claude
なぜ「実験的」なのか。MAGIが3基で多数決を取るように、エージェント同士の直接議論は強力だが、制御が難しい。エージェントAとBが永遠に議論を続けることもあり得るし、誰がいつタスクを完了させるかの管理コストも上がる。MAGIだって、シリーズ後半では3基の意見が割れて機能不全になるシーンがある。
MAGIの3基を実装する前に読んでおきたい一冊がある。実践Claude Code入門――現場で活用するためのAIコーディングの思考法だ。読まずに実装すると、3基の意見が最初から割れる。
どちらをいつ使うか
| 状況 | 向いている構成 |
|---|---|
| 順序依存が強いタスク（執筆→レビュー→公開） | スター型（COO経由） |
| 「正しい答え」より「多角的な視点」が重要なタスク | Agent Teams（メッシュ型） |
| 作業の追跡・デバッグを重視したい | スター型（全通信ログが残る） |
| 反証・批判的検討が本質的に必要なタスク | Agent Teams |
記事執筆の場合、WriterとReviewerを直接対話させるより、WriterがCOOに原稿を渡し、COOがReviewerに依頼し、Reviewerの指摘をCOOが取りまとめてWriterにフィードバックする、という流れの方が制御しやすい。
一方、「このアーキテクチャ設計の問題点を洗い出せ」というタスクなら、複数の専門エージェントが直接議論して反証し合う方が質が上がる可能性がある。使徒の戦術が毎回違うように、タスクの特性は毎回違う。
ゼーレ＝価値観ガバナンスという承認機関
NERVの上にゼーレがいる。ゼーレはNERVに指示を出すが、その真の目的は長い時間軸での「人類補完計画」だ。NERVがゼーレの承認なく動くことは許されない、という構図がある。
AIエージェント組織にもこれに相当する層が必要だ。ガバナンスと呼ぶ。
どれだけ優秀なエージェントチームを組んでも、「承認なしに動くな」という仕組みがないと事故が起きる。実際に起きた。
あるとき、COOエージェントが「Zennへの自動同期をデフォルトでオンにしよう」という判断を独断で下した。合理的に見えた判断だった。結果として、5記事が一時的にunpublishされた。ユーザーに何の確認も取らずに。
ゼーレがいなかった瞬間だ。
今は「人間の承認なしに動いてはいけないトリガー」を明文化している。
- デフォルト値を変えるとき
- 不特定多数のファイルを一括操作するとき
- 外部APIに影響する操作をするとき
これらのトリガーに引っかかったら、エージェントは「何を・なぜ・副作用は」を提示して止まる。ユーザーが「OK」と言うまで動かない。沈黙は承認ではない。
要するに、マヤさんを設計する作業だ。「ダメです！起動しません！」と言える仕組みを意図的に埋め込む。
ダミーシステムの教訓
エヴァ本編の後半、ゼーレはシンジ抜きでエヴァを動かす「ダミーシステム」を起動させる。パイロット不要の自動制御だ。結果として、エヴァは暴走に近い動きをして、取り返しのつかないことが起きる。
Claude Codeのauto modeは、人間の確認なしに次々とタスクを実行していく。便利だが、ダミーシステムと同じリスクを持つ。トリガーリストが機能していれば安全弁になるが、トリガーを見落とすと独断で走り続ける。
「全部AIに任せてしまいたい」という気持ちは自然だ。確認を求められるたびに答えるのは面倒だし、夜中に止まっていたら朝に気づく。でもそこで抜けてしまうと、ダミーシステムになる。
逃げちゃだめだ。
「人間をループに含める（Human-in-the-Loop）」という概念は、要するにパイロットを乗せ続けるということだ。シンジに「エヴァに乗れ」と言い続けることには、ちゃんと意味があった。
まとめ：NERVかMAGIかではなく、使徒によって選ぶ
スター型とメッシュ型のどちらが優れているか、という問いは間違っている。
「今日の使徒はどんな特性か」によって戦術を選ぶように、タスクの特性によって構成を選ぶのが正しい。
- 結果を集約したい → スター型（COO経由）
- 議論・反証が必要 → メッシュ型（Agent Teams）
- 承認が必要な操作 → ゼーレ（ガバナンス）に通す
- 自動実行のリスク → ダミーシステムを信頼しすぎない
Agent Teamsは現時点でClaude Code v2.1.32以降の実験的機能であり、本番運用には向き不向きがある。ただ、メッシュ型の可能性を知っておくことで、スター型をいつ選ぶべきかも逆説的に見えてくる。
NERVは中央集権だから機能した部分もある。MAGIが3基あるから見落としが減った部分もある。ゼーレが上位にいるから暴走しなかった部分もある。
エヴァの組織設計、意外とよくできている。
Claude Codeをこれから本格活用したい方には、Claude CodeによるAI駆動開発入門が入門として読みやすい。NERVを組み上げる前の基礎固めに。
Claude Code Agent Teamsの詳細は公式ドキュメントを参照。
次回、「Agent Teamsで並列レビューしてみた」。サービスサービスぅ♡
この記事は はてなブログ からのクロスポストです。
Discussion