エヴァで理解する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基の意見が割れて機能不全になるシーンがある。

どちらをいつ使うか

状況	向いている構成
順序依存が強いタスク（執筆→レビュー→公開）	スター型（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基あるから見落としが減った部分もある。ゼーレが上位にいるから暴走しなかった部分もある。

エヴァの組織設計、意外とよくできている。

種明かしをすると、ここまで書いてきた「スター型かメッシュ型か」「承認機関をどこに置くか」という問いは、ソフトウェア組織論そのものだ。『エンジニアリング組織論への招待』は、不確実性をどう減らすか・権限をどう委譲するか・コミュニケーションコストをどう設計するかを、NERV・MAGI・ゼーレの役割分担とほぼ同じ構造で扱っている。AIエージェント組織を設計していて「これ、人間の組織論と同じでは」と感じた人には、答え合わせとして読んでほしい一冊だ。

Claude Code Agent Teamsの詳細は公式ドキュメントを参照。

次回、「Agent Teamsで並列レビューしてみた」。サービスサービスぅ♡

エヴァ式の組織設計をAIチームで実装した実践記録は、電子書籍にまとめています。

コードを書けない私が、AIに「チーム」を持たせるまで（序章・第1部無料）

この記事のテーマを深掘りした本

コードを書けない私がClaude Codeで「AIチーム」を回すまで 「作る」の次。運用・三層品質ゲート・事故対応の設計（序章無料）

シリーズ全6冊: Vol.1 作るまで／ Vol.2 回すまで／ Vol.3 書き続けるまで／ Vol.4 仕組みを渡すまで／ Vol.5 仕事を任せるまで／ Vol.6 1人エージェントチーム

コードを書かないSE日誌

SE歴26年。コードを書かずにClaude Codeで8体のAIエージェントチームを動かしています。AIエージェント・自動化・GTDの実験日誌。