Elephant-Goldfish Model（EGM）とは。ゾウと金魚と人で設計書を見直す流れを整理

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。今回は、GitHubで公開されているオープンソース（中身が誰でも見られる形で公開されたソフト）のElephant-Goldfish Model、略してEGMを紹介します。AIに設計書を書かせて、会話を知らない別のAIに見直させる道具です。

取り上げるのは、私が保存したブックマークの1つだからです。作った会話を渡さない検収の決め方と、同じ向きに読める道具でした。GitHubの文書には、入れ方から限界まで書いてあります。

読む順番は、EGMとは、入れ方、60秒で試す、新しい設計の流れ、金魚が働く条件、レビューは代わりにならない、試す前に決める事の順に並べています。私はEGMを動かして確かめたわけではなく、GitHubの文書を読んで整理した記事です。

GitHub README（役割）より（筆者訳）

ゾウ（Elephant）はプロジェクトの文脈を持ち、仕様書を下書きします。金魚（Goldfish）のレビュアーは、それまでの会話を持たずに、下書きと参照先の資料を調べ、書かれていない前提や盲点を明らかにします。

ゾウは文脈を持って設計書を下書きする役で、金魚は会話を持たずに書類だけを読む役。引用が言っているのは、その分け方です。

GitHubのgoogle/elephant-goldfish-modelは、AIアシスタント向けのオープンソース（中身が公開されたソフト）のプラグインです。

プラグインは、AIの道具箱に後から足す部品のこと。ライセンスはApache-2.0で、READMEの末尾には、Googleが公式にサポートする製品ではない、と書いてあります。

役割は、ゾウ・金魚・人の順に見ていきます。ゾウは、プロジェクトの文脈・要件・これまでの決定を持ち、問題を探って仕様書を下書きします。仕様書は、何をどう作るかを書いた設計書のこと。

金魚は、それまでの会話を持たず、書類と参照先の資料だけを読み、足りない前提や実装のリスクを探します。人は、トレードオフ（あちらを立てればこちらが立たない選び方）を決め、設計を承認します。

READMEの標語は「ゾウと設計し、金魚でレビューする」。リポジトリの作成は2026年9月14日、最新の更新は11月11日、v0.1.1は11月7日です。どれも日本時間のGitHubの情報。

2026年11月12日に読んだ時点で、スターは約1万7千でした。まだ版番号が0.1台の、若い道具です。

AI氣道『GitHubで話題のAIツール7選を任せる所と自分の目で確かめる所に分ける』より

「作った会話を渡さない。ここが、金魚の役割と同じ向きなんです。」

EGMの役割分担を動画の語りから紹介した記事を、私は『GitHubで話題のAIツール7選を任せる所と自分の目で確かめる所に分ける』で書いています。

そこでは動画の語りを整理しただけでした。今回はGitHubのREADMEとdocsを直接読み、入れ方・試し方・使える条件・限界まで順に整理します。

私は、これは書く役と見直す役を分ける話だと考えています。道具の名前は新しくても、考え方は仕事の見直しにも通じます。

GitHub docs/harnesses.md（入れ方）より（筆者訳）

プラグインは丸ごと入れてください。skills/だけをコピーする導入方法はEGMを壊します。スキルは実行時にagents/とresources/document_standards/を読むからです。

プラグインは中身を丸ごと入れる前提の道具だ、という意味です。

READMEは、使うコーディングエージェント（AIがコードを書く道具）ごとに入れ方を示しています。

Claude Codeは、claude plugin marketplace add google/elephant-goldfish-model を実行し、続けて claude plugin install egm@egm を実行します。

Codex CLIは、codex plugin marketplace add google/elephant-goldfish-model を実行し、続けて codex plugin add egm@egm を実行します。

Antigravity CLIは、agy plugin install https://github.com/google/elephant-goldfish-model の1行です。

入れたら、新しい会話を始めます。

ChatGPTとCodexのデスクトップ版は、公開されているEGMのプラグインのページから入れます。デスクトップ版のみの掲載です。

docs/harnesses.mdの表には、ほかにClaude Cowork、omp、Museも載っています。

プラグインは丸ごと入れます。skills/のフォルダだけをコピーする入れ方は、EGMを壊すんです。docsにそう書いてあります。

スキルが実行時に、agents/にあるレビュアーの指示書と、resources/document_standards/にある書類の基準を読むからです。

入れる前に、使っているAIがサブエージェント（本体のAIが別の作業役を立ち上げる機能）を使えるかも確かめます。詳しくは第5章です。

GitHub README（60秒の使い方）より（筆者訳）

既存の設計書、README、PRの計画を、動いているコードに照らして確認します。新しい仕様書を書く必要はありません。

新しい設計書を書かなくても、今ある書類をコードと突き合わせて見直せる。引用の言うとおりです。

READMEは、設計を新しく書く前に試せる60秒の使い方を、いちばん先に出しています。見直す対象は、既存の設計書、README、PRの計画のMarkdown（記号で書式を付けた文書）です。

コマンドは /egm:egm-review docs/designs/webhooks.md の形。パスは、自分の設計書か、Markdownで保存したPRの計画に替えます。

例のwebhooks.mdは、出来事を別のシステムへ自動で知らせる仕組み、Webhookの設計書を想定したものです。まっさらなレビュアーが、設計、分かりやすさ、コードとの合い方、実装計画を見ます。

別の1つが /egm:egm-drift-report docs/designs/ です。フォルダの中の各書類を現在のソースコードと比べて、食い違う所を報告します。

ドリフトは、時間がたつと書類とコードがずれること。直すのは書類かコードか、人が決めます。getting_started.mdは、週に1回の習慣にすることを勧めています。

コマンドの前置きは使うAIで違います。AntigravityとClaude Codeでは/egm:の前置きを付け、Codexでは、スキルの選択画面から対応するEGMのスキルを選びます。

READMEによると、agy CLI 1.4.10では前置きなしの名前が補完されますが、1.4.8では補完されないので、前置きは付けておきます。

レビューは、1つの設計書を5つの段階で見ていく作りです。

手元に設計書が無い人は、自分のプロジェクトのREADMEを1枚選んで試すのが入り口かな。入れ方の1行に比べて、試す1行はさらに短い。迷うのは、どの書類を選ぶかだけです。

GitHub docs/getting_started.md（簡単な修正）より（筆者訳）

簡単なバグ修正を一発で直せると思うなら、設計を先に書く手順を無理に使わないでください。仕事に合った道具を使います。

簡単なバグ修正なら、設計書から始めなくてよい、と言っています。

新しい機能を設計する時の中心の流れは、getting_started.mdが5つの段階で示しています。1つ目は /egm-brainstorm。

ブレインストーム（案を出し合って考えを整理すること）の段階で、まっさらな複数の視点の金魚の群れが案を試し、合意した方向をconcepts_brief.mdに保存します。

2つ目は /egm-draft。概要をdocs/designs/の下の設計書に、節ごとに区切って下書きします。各節の後で、チャットで感想を聞いて止まります。3つ目は /egm-review。

まっさらなセッションで、完全さ、分かりやすさ、実装の準備ができているかを見ます。

指摘は、設計上たくさん返ってきます。関係があるものを取り、残りは無視してよい、とdocsは書いています。

4つ目は人のレビューで、設計をプルリクエスト（変更案を別の人に見てもらう依頼）で別の人に送ります。5つ目は実装で、AIに設計書どおりに作らせます。

小さな間違いは自分で直すか、点の修正を頼みます。大きくずれたら、設計書を直してやり直す。

READMEの例は、Webhookの配信を足す設計です。失敗した時や、同じ出来事が2回届いた時にどうするかを決める題材になっています。

順番は処方箋ではなく、入れ替えて使ってよい、ともdocsは書いています。使う道具は、いま詰まっている所に合うものを選びます。

既存のコードには /egm-bootstrap、レビュー結果の整理には /egm-resolve、設計以外の書類には /egm-review-loop があります。

READMEが対象と書くのは、ソフトウェアの仕様です。見積書や提案書を見直したい人は、その点を先に押さえてください。

GitHub docs/harnesses.md（金魚が働く条件）より（筆者訳）

金魚のレビューには、まっさらな文脈が要ります。ハーネスにサブエージェントの道具がなければ、レビューのスキルは同じ文脈で動かさず、止まります。

同じ会話の中で見直させても金魚にならないので、別の作業役を立てられない環境では動かさない、という意味です。

READMEは、金魚のレビューには新しい（まっさらな）サブエージェントの文脈が要ると書いています。作れない時は、EGMはレビューを止めます。

docs/harnesses.mdは、使うAIの名前から決めつけず、実際に道具が使えるかを確かめるよう書いています。

対応は表で読めます。Antigravity CLI、Claude Code、Codexは、インストールと流れの自動テストを通っています。

Antigravityのスタンドアロン版のIDEは、サブエージェントの道具が使えないため、対応していません。

Claude CoworkとChatGPT Workは、入れる道はあるものの、クラウド上での確認に未完の所があります。

Museでは2026年10月30日に、ブレインストーム、下書き、中断なしのレビュー（15人のまっさらなレビュアー）の流れが通っています。

名前付きの金魚は呼べず、汎用のサブエージェントに指示書を読ませる代わりの方法になります。

次の記述も大事です。まっさらな会話は、AIの指示ファイル（CLAUDE.mdやAGENTS.md）まで消えるという意味ではありません。

docsは、課題#237で、Codex CLI 0.166.0がプロジェクトとユーザーのAGENTS.mdを渡したこと、Antigravity CLIでもプロジェクトのAGENTS.mdとGEMINI.mdが入ったことが報告されている、と書きます。

これは指示ファイルが渡った報告で、会話が漏れた証拠ではない、ともdocsは書いています。Claudeのレビュアーは、omitClaudeMd: trueの設定でCLAUDE.mdを外します。

CodexとAntigravityには、外す設定が確かめられていません。

対策もdocsにあります。毎回の前提は指示ファイルに書き、金魚に疑ってほしい前提は、レビューの基準として明示的に書く。

GitHub README（レビューの限界）より（筆者訳）

レビューは、テストや人の判断の代わりにはなりません。

レビューのほかに、テストで動作を確かめることと、人が判断することが残る、という意味です。

getting_started.mdも、EGMは人の監督の代わりにならず、むしろ促す、人のレビューは長期の製品の一貫性と優先順位に欠かせない、と書いています。

金魚は設計上、たくさんの指摘を返します。全部を直す話ではありません。関係があるものを取り、残りは無視する。採る所を決めるのは人です。

レビューを通ったことと、作ったものが動くことは別の話。実装のあとには、テストと、人が見る所が残ります。

docs/harnesses.mdは、検証の範囲にも触れています。

Codexのテストと記録されたAntigravityの実行は、親の会話が渡らないことだけを確かめていて、指示ファイルが外れているかは確かめていません。

Claude CoworkとChatGPT Workも、クラウド上の確認に未完の所があります。

流れの中でも、金魚の次に人が来る順番です。4つ目が人のレビューで、5つ目が実装でした。金魚は穴を探す係で、穴をふさぐかどうかを決める係ではありません。

AI氣道『AIチームビルディング｜AIの出力をそのまま出す人はサボりか。けんすうさんと篠塚孝哉さんの対談を私の運用の数字で確かめた』より

「作ったAIも、検収したCodexも見落としたんです。見比べでOKとされた中に、見比べていない物があったんです。」

作ったAIも検収したAIも見落とした図の見比べの話を、私は『AIチームビルディング｜AIの出力をそのまま出す人はサボりか。けんすうさんと篠塚孝哉さんの対談を私の運用の数字で確かめた』で書いています。

別のAIに見せても、見ていない物は見落とします。私の経験は図とレビューの話で、ソフトウェアの設計とは別です。ただ、レビュアーが何を見てOKにしたかを確かめる所は、同じ向きだと思っています。

読み手の仕事に置くなら、提案書を金魚役のAIに読ませても、出た指摘を採るのは自分、という形です。

GitHub docs/getting_started.md（指摘の扱い）より（筆者訳）

これは設計上、たくさんの指摘を返します。関係があると思うものを取り、残りは無視してください。

指摘は全部直さず、関係あるものだけ採ればよい、という意味です。

docs/getting_started.mdは、最初は核になる考え方から始めるよう勧めています。会話の手順を1〜2回通すと、AIの癖が見えて感覚が身につく、とも書いています。

そのうえで、試す前に私が決めることを、私の考えとして書きます。1つ目は、どの設計書で試すか。新しい仕様ではなく、今ある書類を1枚選びます。簡単な修正には使いません。

2つ目は、金魚に疑ってほしい前提を、指示ファイルではなく、レビューの依頼の文に書くこと。第5章のとおり、指示ファイルは渡る前提で考えます。

3つ目は、指摘を採る人を決めること。全部直さず、関係あるものだけ採り、残りは無視します。決めるのは人です。

AI氣道『説明責任は任せられない、AIエージェントに作業を任せる時に人が持つ習慣を動画から整理する』より

「私は、AIに任せるほど「頼む前に線を引く」ことが大事になる、と思っている側です。」

頼む前に線を引く考え方を、私は『説明責任は任せられない、AIエージェントに作業を任せる時に人が持つ習慣を動画から整理する』で書いています。

頼む前に線を引く、は、EGMでは、設計書を金魚に読ませる前に、見てほしい所と採る人を決めることだと考えます。

それから、使うAIがサブエージェントを使えるかを、入れる前に確かめます。使えないと、金魚のレビューは止まります。

この点を決める前に、READMEの60秒の使い方を、自分の設計書1枚で眺めてもよいかもしれません。READMEは、新しい仕様書を書かなくてよいと説明しています。

週に1回のドリフトの確認も、習慣にする候補です。getting_started.mdが勧めているのは、設計書とコードのずれを週に1回探すことです。

決めたことを紙に書いてから入れる、が私のおすすめの順番です。私はこのガイドを読んで整理しました。手元で試す順番は、ここまでの7つの章のとおりです。

EGMは、ゾウが設計書を書き、金魚が会話を知らずに見直し、人が決める道具でした。GitHubのREADMEとdocsを読んで、入れ方から限界までを順に整理しました。

入れ方は、使うAIごとに1行です。プラグインは丸ごと入れます。まずは手元の設計書1枚を60秒で見直させるのが、いちばん軽い一歩です。

金魚が働くには、AIがサブエージェントを使える必要があります。指示ファイルは金魚にも渡ると報告されているので、疑ってほしい前提はレビューの依頼に書きます。レビューはテストや人の判断の代わりにはなりません。

この記事は、READMEとdocsを2026年11月12日に読んで整理したものです。試す時は、書類、疑う前提、指摘を採る人を先に決めてから入れてください。

この記事で学んだことを誰かに教えて恩送りして学びを深めよう！