Google公開の「EGM」、設計書を記憶のない別のAIにレビューさせる

Claude CodeやCodex CLIに機能の設計書を書かせると、読み返したときは筋が通って見える。ところが実装を進めてから、「配信が失敗したときはどうするのか」「同じ処理が二重に走ったらどうするのか」といった抜けに気づくことがある。

Googleが公開したオープンソースのプラグイン「EGM(Elephant-Goldfish Model)」は、この抜けを見つける役を、書いた本人ではなく別のAIに任せる。しかも相手は、会話の記憶を一切持たない。どこが曖昧かを一つずつ探すのではない。自分の理解をいったん言い換えさせ、その言い換えが間違っていること自体を欠落の証拠にする(GitHub README、2026-11-09確認)。

書いた本人が欠落に気づけない理由

AIに設計書を書かせたあと、普通は書いたAIにそのまま読み返させる。同じ会話の続きで「これで合っている?」と聞くやり方だ。だがこの聞き方には限界がある。書いた本人は、文章の裏にある理由や前提をすでに知っているので、説明が抜けていても頭の中で勝手に補って読んでしまう。

EGMはこの構造を、2つの役に分けて解決する。設計書を書く役を「Elephant(象)」、読み直して欠落を探す役を「Goldfish(金魚)」と呼ぶ。Elephantはプロジェクトの文脈・要件・それまでの決定を持ったまま仕様を起草する。Goldfishは、その設計書と参照元の資料だけを渡され、それまでの会話をいっさい見ずに、新しく加わったメンバーのつもりで読む。トレードオフを判断し、最終的に設計書を承認するのは人間の役目として残る(GitHub README、2026-11-09確認)。

同じAIモデルを使っていても、会話の記憶を持ったまま読み返すのと、記憶を持たずに初見で読むのとでは見える景色が変わる。Elephantは自分が書いた文章の背後にある前提を知っているぶん、抜けに気づきにくい。Goldfishはその前提を持たないので、書いてあることだけを頼りに理解を組み立てる。では、Goldfishは具体的に何を、どうやって確認しているのか。

言い換えが指摘になる仕組み

/egm-reviewを実行すると、Goldfishは5段階に分かれて設計書を検証する(skills/egm-review/SKILL.md、2026-11-09確認)。

1. 高所からの単純さの確認(過剰な設計になっていないか)
2. 理解の確認(文書を正しく理解できるか)
3. 設計・構造・文体への指摘
4. 高所からの再確認
5. 実装可能性の確認

中でも2番目の「理解の確認」を担当するGoldfishの手続きが、この仕組みの核心にある。担当するAIの人格定義には、「このプロジェクトについて事前知識を持たない、新しく加わったメンバーとして振る舞う」とある。そのうえで最初にやる作業は決まっている。「文書が何を提案しているか、既存の仕組みがどう動くかを、自分の言葉で言い換えて書く」ことだ(agents/comprehension.md、2026-11-09確認)。

たとえばREADMEが例に挙げるのは、webhook配信機能を追加する設計書だ。配信が失敗したときはどうするのか、同じイベントが二重に届いたときはどうするのか。この手の判断が、設計書にきちんと書き込まれているかが問われる(GitHub README、2026-11-09確認)。

自分はてっきり、曖昧な用語を一つずつ洗い出す方法のほうが確実だろうと思っていた。予想は外れた。人格定義は、その方法をあえて避ける理由を明記していた。「未定義語の一覧では、用語はすべて定義されているのに部分同士がつながらない文書は見つけられない。言い換えはそれを見つける」。言い換えが書けない節があれば、それ自体をBlocker(重大な指摘)として報告する、という指示だ(agents/comprehension.md、2026-11-09確認)。

言い換えが、検査そのものになっている。

つまりGoldfishが確かめているのは、用語がすべて定義されているかどうかではなく、何も知らない読み手が書いてある通りに理解を組み立て直せるかどうかだ。組み立て直せなければ、曖昧な一文を個別に指摘するより先に、その理解のズレ自体が欠落として記録される。

自分の環境でそのまま使えるか

EGMはプラグインとして配布されていて、主要なAIコーディングエージェントに2行のコマンドで導入できる(GitHub README、2026-11-09確認)。

導入後は新しいセッションを開始する必要がある。使い方の基本は3コマンドだ。/egm-brainstormでアイデアを練り、/egm-draftで設計書にし、/egm-reviewでレビューする(GitHub README、2026-11-09確認)。

ここには一つ前提がある。Goldfishのレビューは、AIエージェントが新しいサブエージェント(それまでの会話を持たない、独立したAIセッション)を作れる環境を必要とする。作れない環境では、EGM自身がレビューを停止する(GitHub README、2026-11-09確認)。Claude Code・Codex CLI・Antigravity CLIはこの条件を満たして動作が確認されているが、サブエージェントを作れない環境では、そもそも試せない。

公開からはまだ2週間ほどだ。最初のタグ付きリリース(v0.1.0)が2026年10月27日、直近のv0.1.1が11月6日に出ている。GitHub上ではStarが15.1k、Forkが1.1kに達している(いずれも2026-11-09確認時点のスナップショット)(elephant-goldfish-model Releases)。ライセンスはApache 2.0で無料。リポジトリはGoogleの組織名義で公開されているが、「Googleが公式にサポートする製品ではない」と明記されている(GitHub README、2026-11-09確認)。

「文脈ゼロ」はどこまで守られるか

ここまでの仕組みは、Goldfishが本当に「会話の記憶を持たない状態」で読んでいることが前提になる。この前提は、ホストとなるツールによっては完全に守られているわけではない。

EGM自身のドキュメントは、この漏れを正直に記録している。Codex CLI(0.166.0)はfork_turns: "none"という分離設定を使っていても、プロジェクトやユーザーの指示ファイル(AGENTS.md)がレビュアーの文脈に紛れ込んでいた。Antigravity CLIでも同様で、AGENTS.mdやGEMINI.mdがレビュアーに渡っていた(docs/harnesses.md、2026-11-09確認)。

自分には、この漏れをIssue番号付きで公式ドキュメントに残している点が意外だった。「文脈を持たない」という前提そのものに、公式ドキュメント自身が留保を付けている。

ドキュメント自身は、これを「それ以前の会話が漏れた証拠ではない」と区別して記録している。会話そのものの分離とは別に、指示ファイルの扱いはツールによって検証の進み方が異なる、という整理だ。Claude Codeはレビュアー用のアダプターで指示ファイルを明示的に除外している(docs/harnesses.md、2026-11-09確認)。

導入前に確認しておきたい点は、次の2つに絞られる。

• サブエージェントを作れる環境か。作れない環境ではEGM自身がレビューを停止する(GitHub README)
• 使っているツールで、指示ファイルの分離がどこまで検証されているか。Claude Codeは明示的に除外しているが、Codex CLI・Antigravity CLIは既知の漏れが報告済み(docs/harnesses.md)

まとめ

EGMは、AIに書かせた設計書の欠落を、書いた本人ではなく、会話の記憶を持たない別のAIに見つけさせるプラグインだ。中心にあるのは、Goldfishが自分の理解をまず言い換えて書き、その言い換えが間違っていること自体を指摘にする手続きだ。未定義語を数える方法では拾えない「理解のつながりの崩れ」を、この手続きなら見つけられる。

Claude CodeやCodex CLIなら2行のコマンドで導入でき、/egm-brainstorm→/egm-draft→/egm-reviewの3つで試せる。

設計書を書く前に何を決めておくかは、以前の記事で扱った。EGMは、その先——書き上がった設計書の抜けをどう見つけるか、という一歩先の問いに答える。