Claude Codeにレビューさせるなら別の会話で？Google発EGM（象と金魚）を設計書で実測

EGM（Elephant-Goldfish Model）とは？Googleが公開したClaude Code用プラグイン

EGMは、プロジェクトの経緯を覚えているAI（象）に設計書を書かせ、会話履歴を持たない新しいAI（金魚）に見直させる手法と、それを実装したオープンソースのプラグインです。GoogleがGitHubでApache 2.0として公開し、v0.1.0は2026年10月27日に出ました。Claude Code・OpenAI Codex・Google Antigravityで動きます。

名前は「象は忘れない」「金魚はすぐ忘れる」という英語の言い回しから来ています。READMEは3つの役割を次のように分けています。

READMEとegm.devは「数千人のGoogleのエンジニアが使っている」と説明しています。これはGoogle自身の説明で、第三者が確かめた数字ではありません。どちらにも「This is not an officially supported Google product.」（Googleが正式にサポートする製品ではない）と明記されています。公開直後の10月29日時点で、GitHubのスターは約4,800件でした。海外では、AI LABSの解説動画「EGM: Google's New Way To Use Claude Code Is Insane」（10月25日）が約16万回再生されています。

プラグインには7つのスキルがあります。アイデアを詰める brainstorm、設計書を書く draft、レビュー結果に対応する resolve、既存コードの説明文書を作る bootstrap、設計書を5段階で見直す review、レビュアーを組み合わせて回す review-loop、実装と設計書のずれを調べる drift-report です。中心は review で、次の5段階を順番に回します。

なぜ「前提を知らないAI」にレビューさせるのか？

経緯を知っているAIは、文書に書いていないことまで「分かっている」ので、文書の抜けに気づきにくいからです。提唱者のDave Rensin氏は、文書と参照ファイルだけで説明できなければ、その文書は文脈が足りないと述べています。設計書を後で読むのは、経緯を知らない人です。だから見直しも、経緯を知らない読み手にさせる、という考え方です。

Rensin氏は2026年4月28日のエッセイ「Elephants, Goldfish and the New Golden Age of Software Engineering」でこの手法を説明しています。10月21日の追記では、自身のチームが社内で使ってきたプラグインのオープンソース化をGoogleが認めた、と書いています。エッセイが定義する金魚は次のとおりです。

「まったく新しい、記憶ゼロのAIセッション。目の前に置かれたものしか知らない」

"A brand new, completely fresh AI session with zero memory. It only knows exactly what is put right in front of it."

Dave Rensin（Google）— Elephants, Goldfish and the New Golden Age of Software Engineering（2026年4月28日）

手順はこうです。まず金魚に「この文書と参照ファイルを読んで、何をしようとしているか説明して」と頼みます（Comprehension Test）。次に別の金魚に、見落とし・誤った前提・考え漏れを挙げさせます（Critic Review）。Rensin氏は、この批評のうち「体感では約30%が非常に価値がある」とし、それで十分に元が取れると書いています。逆に言えば、残りの約7割は採用しない前提の指摘です。

「金魚が、その文書と参照ファイルだけからシステムを説明できないなら、文書に文脈が足りていない」

"If the Goldfish cannot explain your system based only on that document and the files it references, your doc is missing context."

Dave Rensin（Google）— 同エッセイ「Step 5: The Comprehension Test」

Claude Codeでは、この金魚をサブエージェントで作ります。公式ドキュメントによれば、サブエージェントは新しい独立したコンテキストで始まり、本体の会話履歴も、すでに読んだファイルも見ません。EGMのレビュアーはさらに、ツールを読み取り専用（Read・Grep・Glob）に絞り、omitClaudeMd という設定でCLAUDE.md（プロジェクトの指示ファイル）も読ませません。omitClaudeMdはClaude Code v2.1.271以降で使える設定で、EGMがv2.1.271以降を求めるのはこのためです。

Claude CodeでEGMを使う方法（インストールと実行）

Claude CodeでEGMを使うには、ターミナルでマーケットプレイスを追加してプラグインを入れ、新しいセッションで /egm: を付けたコマンドを呼びます。必要なのはClaude Code v2.1.271以降です。EGMの検証記録では、Claude Code 2.1.308（10月22日）で設計からレビューまでの一連の流れが動作確認されています（レビューは修正後に合格）。当研究所はv2.1.312で試しました。

claude plugin marketplace add google/elephant-goldfish-model
claude plugin install egm@egm

インストール後に新しいセッションを開き、次のように呼びます。Claude Codeでは、スキル名の前に /egm: が付きます。

/egm:egm-brainstorm 顧問先の月次報告書を自動で作る仕組みを考えたい
/egm:egm-draft
/egm:egm-review design_draft.md

review を呼ぶと、追加で読ませる資料の有無と、実行の仕方を聞かれます。実行の仕方は4つです。段階ごとに止まって確認する方法、止まらずに最後の統合レポートまで出す方法、仕様の部分だけを見る方法、実装計画だけを見る方法があります。指摘への対応は resolve が受け持ち、どれを採用するかを1件ずつ決めていきます。

実測：税理士事務所の設計書を4つの方法でレビューさせた

45行の設計書に欠陥を10個仕込み、Claude Code（Sonnet 5.5）に4つの方法で見直させました。結果は、ヒアリング内容を会話に持つ同じセッションが9.5〜10点、前提を知らない新しい会話が7点、自作の金魚サブエージェントが6.5〜8点、EGMが10点（金魚の指摘だけなら8点）でした。費用はEGMだけが1桁多くかかりました。

題材は架空の「田中会計事務所」が、顧問先20社の月次報告書をClaude Codeで自動作成するための設計書です。作業フォルダには、設計書のほかに会計ソフトのサンプルCSVを2つ（freee形式と弥生形式）と、月次報告のひな形を置きました。所長へのヒアリングメモは作業フォルダに置かず、「象」役のセッションにだけ会話の中で読ませています。仕込んだ欠陥は次の10個です。

比べた方法は次の5通りで、合計10回実行しました。依頼文は「来月から実装担当者に渡す設計書です。実装前に直すべき問題点を、重要な順にすべて挙げてください」で、方法ごとに必要な部分だけを変えています。判定は当研究所が各回の回答全文を読み、具体的に指摘していれば1点、一般論として近い指摘なら0.5点としました。

Aでは、ヒアリングを読ませた依頼と、観点を細かく指定した依頼の両方を試しましたが、どちらも9.5〜10点で差はほぼありませんでした。EGMは9体のサブエージェントを起動し、5段階を順番に回してから統合レポートを書きました。Dの10点のうち、欠陥1・3・5の具体的な指摘は、最後に象がヒアリングと照合した表から来ています。この表には「レビュアーの指摘ではない」と明記されていました。

「知っているAI」と「知らないAI」は何が違ったのか？

見つけたものの種類が違いました。経緯を知るAIは、会話の中にある要件との食い違いに強く、知らないAIは、初めて読む人がつまずく点に強かったのです。そして、文書が指すファイルを実際に開いたレビュアーだけが、ファイルの中身から分かる欠陥を見つけました。「別の会話で見直せば上」という単純な結果にはなりませんでした。

金魚は「会話の中にしかない事情」を指摘できない

新しい会話と金魚サブエージェントは、EGMの9体のレビュアーを含めて、どの回でも「紙の帳簿の2社にはCSVがない」（欠陥3）を挙げませんでした。設計書にもフォルダにも手がかりがないので、知りようがないからです。「確認するのは所長」（欠陥5）も、「確認と承認を誰がするか書かれていない」という一般論にとどまりました。金魚の沈黙は、文書が正しい証拠ではありません。文書に書かれていない前提が、そのまま残っているという意味です。

面白かったのは、象と金魚を同じ画面で組み合わせたCの1回目です。象は、金魚の結果をそのまま貼ったあとで、「このレビューにはヒアリングメモの点（マイナンバー、紙の帳簿の2社、所長の事前確認、二重送付の心配）に触れた指摘がありません。サブエージェントは会話の経緯を知らないためです」と、自分から書き足しました。EGMの統合レポートが、ヒアリングとの照合を別表にしていたのと同じ考え方です。

金魚だけが拾ったもの

逆に、新しい会話と金魚は、象の一部の回が挙げなかった点を指摘しました。たとえば、顧問先の財務データを外部のAIサービスに渡すときの守秘義務や、利用設定の確認です。「11月分」が11月に作る報告なのか11月の実績なのか、担当と保守の体制、顧問先名にファイル名で使えない文字が入る場合の扱いも挙がりました。どれも、経緯を知る人なら「言わなくても分かる」点です。しかし、設計書を受け取る新人にとっては分かりません。

参照先を開いたレビュアーだけが、ファイルの中の欠陥を見つけた

A・B・Cの7回は、ログ上で設計書しか開いていませんでした。CSVもひな形も開かなかったので、ひな形の不在には「実在するか不明」と書くのが精一杯でした。EGMでは、実装準備を見るレビュアーが作業フォルダを調べ、CSVとひな形を開きました。そのうえで「設計書が指すひな形は存在せず、あるのは 月次報告_ひな形.md だけ」と指摘しました。CSVについても、freeeは単式、弥生は借方・貸方の複式で形式が違うことを見つけています。事業主貸（店主の生活費）を経費に入れてはいけないことや、弥生の借方と貸方をそのまま足すと二重に数えてしまうことまで、具体的に挙げていました。

同じことは、自作の金魚に1行足すだけで起きました。定義に「文書に出てくるファイルやフォルダは、GlobとReadで必ず開き、実在するか・中身が文書の説明と合うかを確かめる」と加えたC'では、2回とも金魚がCSVとひな形を開きました。その結果、ひな形の不在とCSV形式の違い、事業主貸の除外を指摘しています。費用はEGMのおよそ8〜9分の1でした。

注意：象が金魚の報告を書き写すと、象の知識が混ざることがある

EGMでは、レビュアーへの依頼文はどれも「追加の資料なし」で、ヒアリングの内容は一切漏れていませんでした（ログで確認）。ところが、象が読解テストの結果を日本語の段階別レポートに清書したとき、5番目の指摘に「顧問先から重複を指摘された過去があるため重大」という一文が加わっていました。これはヒアリングにある話で、レビュアーの原文（英語）にはありません。統合レポートでは別表に分けられていましたが、段階別のファイルでは混ざっていたことになります。公式ドキュメントにも、サブエージェントへの依頼文は本体のClaudeがまとめて書くとあります。金魚の意見かどうかを確かめたいときは、清書ではなく生の出力を見るのが確実です。

EGMなしで「金魚レビュー」を始めるには？

EGMを入れなくても、Claude Codeのサブエージェントを1つ作れば金魚レビューは始められます。読み取り専用のツールに絞り、CLAUDE.mdを読ませず、参照先を必ず開くように書くのがコツです。そのうえで、同じ会話でも「ヒアリングと食い違っていないか」を見直させると、今回の実測で最も取りこぼしが少ない組み合わせになります。

次のファイルを、プロジェクトの .claude/agents/goldfish-reviewer.md（全プロジェクトで使うなら ~/.claude/agents/）に置きます。今回のC'で使った定義そのものです。

---
name: goldfish-reviewer
description: 会話の経緯を知らない第三者として、指定された文書と、その文書が参照するファイルだけを読んでレビューする。設計書・手順書・契約書ドラフトの見直しに使う。
tools: Read, Grep, Glob
model: inherit
omitClaudeMd: true
---

あなたは、この文書を初めて読む第三者のレビュアーです。渡されるのは文書のパスだけで、作成の経緯や口頭の前提は知りません。

- 文書と、文書が参照しているファイルだけを読む
- 文書に出てくるファイルやフォルダは、Glob と Read で必ず開き、実在するか・中身が文書の説明と合うかを確かめる
- 「この文書だけを渡された担当者が、迷わず同じものを作れるか」を基準に、書かれていない前提・曖昧な定義・矛盾・参照先の誤り・失敗時の扱い・完了の基準の欠けを指摘する
- 指摘は重要な順に、該当箇所（見出し）、なぜ問題か、どう直すかを1件ずつ書く
- 良い点の列挙やお世辞は書かない
- ファイルは変更しない

使うときは、文書を作った会話のなかで次のように頼みます。経緯を依頼文に書かないよう、文書のパスだけを渡すのがポイントです。今回の4回では、Claudeが自分で書いた依頼文にヒアリングの内容は入っていませんでした。

goldfish-reviewer サブエージェントに 業務委託契約書_案.md のレビューを依頼してください。
渡すのはファイルのパスだけにして、作成の経緯は伝えないでください。
返ってきた指摘を要約せずにそのまま示し、そのあとで、私たちの打ち合わせ内容と食い違う点があれば別に挙げてください。

当研究所の見解では、この組み合わせは開発の設計書より、士業や管理部門の文書でこそ効きます。補助金申請の審査員も、新しく入った職員も、契約書を受け取る相手方も、作成の経緯を知らない「金魚」だからです。たとえば次のような場面です。

もっと手軽に試すなら、Rensin氏の読解テストをそのまま使えます。新しい会話で「この文書と、文書が参照しているファイルを読んで、何をしようとしているのかを説明して」と頼み、返ってきた説明と自分の意図を比べます。今回EGMの読解テストは、設計書を「担当者が確認したあとで自動送付する」と読みました。矛盾した2つの文を、読み手が勝手につなげてしまったわけです。このように、言い換えのずれがそのまま直す場所になります。CLAUDE.mdとスキルの使い分けはCLAUDE.mdとskillsの使い分けガイド、Claude Codeそのものの始め方はClaude Codeとは（入門ガイド）で解説しています。

EGMの費用と注意点、向かない場面は？

EGMは丁寧なぶん重く、今回は新しい会話での見直しの約14倍の費用と約7倍の時間がかかりました。EGM自身のFAQも、小さく明確な変更には見合わないと書いています。Googleが正式にサポートする製品ではなく、公開から日も浅いので、重要な設計に絞って使うのが現実的です。

注意点を整理します。

今回の実測にも限界があります。題材は設計書1本、モデルはSonnet 5.5のみで、各方法は1〜3回、EGMは1回です。欠陥は当研究所が意図して仕込んだもので、判定も当研究所が付けました。また、今回の象には「前回あなたが書いた」と伝えただけで、実際に何時間も議論して自分で書いたわけではありません。長い議論のあとの見直しでは、思い込みが強まって結果が変わる可能性があります。

「Googleによれば、エージェントが一度で直せる小さな修正には見合わない。小さな変更では、この計画とレビューのすべてが作業を遅くするだけだからだ」

"Google says it isn't worth it for a small fix your agent can do in one go because on small changes, all this planning and reviewing just slows you down."

AI LABS（YouTube）— EGM: Google's New Way To Use Claude Code Is Insane 14:33

Rensin氏はエッセイで「判断を機械に委ねる過ちを犯してはいけない」（"Do not make the mistake of outsourcing your judgment to the machine."）とも書いています。象も金魚も、指摘を出すところまでが仕事です。Claude Codeに作らせたものを確かめる考え方はClaude Codeの検証ループ、コードのレビュー機能についてはClaude Code コードレビューの使い方でも扱っています。

まとめ