生成AI関連
AI時代の設計書の在り方を考える
AIと相談して設計書をまとめたとき、会話の中で決めたことが、文書にも十分に残っているとは限りません。設計したAIは経緯を知っていても、後から実装を担当する人や別のAIには伝わらない場合があります。
Elephant-Goldfish Model（EGM）は、設計の経緯を持つAIと、その経緯を持たないレビュー役を分け、実装前に設計書を点検する手法です。Googleは2026年10月22日、この手法を支援するプラグインのオープンソース公開を発表しました。
本記事では、EGMの役割分担と公開プラグインの流れを紹介します。後半では、小さな会議室予約機能を題材に、CodexでEGMプラグインを使い、相談から設計書の初稿作成、レビューまで進めた例を紹介します。
EGMの「Model」は、AIを使った開発の進め方を指します。設計書を作ってレビューし、承認された仕様に沿って実装へ進む、仕様駆動開発を支援します。
Googleの発表では、社内で開発・利用していたプラグインを公開したと説明しています。公開物には、AIに作業手順を渡すSkills、レビュー担当の役割定義、設計書を点検する基準などが含まれます。公開リポジトリのライセンスはApache 2.0で、Googleの公式サポート製品ではない旨も記載されています。
記事で扱うのは、要件を整理し、設計書を作り、実装に進む前に抜けを点検する流れです。プラグインには、既存コードから文書を作る機能や、設計書とコードのずれを調べる機能もありますが、まずは設計とレビューの分担から理解すると取り組みやすいでしょう。
設計書に判断の理由や前提を残す重要性は、以下の記事でも解説しています。
EGMでは、設計をまとめるElephant（象）と、別の視点で点検するGoldfish（金魚）が役割を分担します。人は両者のやり取りを踏まえ、指摘への対応や実装に進むかを判断します。
| 役割 | 参照する情報 | 主な仕事 |
|---|---|---|
| Elephant | 要件、相談の経緯、設計上の決定 | 設計をまとめ、指摘を受けて修正する |
| Goldfish | 設計書、必要な参照資料、レビュー基準 | 経緯を知らない立場から不足や矛盾を指摘する |
| 人 | 要件、設計書、レビュー結果 | 前提を確認し、採否と実装へ進むかを判断する |
Elephantは、プロジェクトの背景や相談の経緯を持つ設計役です。何を作るのか、何を対象外にするのか、なぜその構成にするのかを人と整理し、設計書にまとめます。
会議室予約なら、「予約が重複しないこと」「社員本人がキャンセルできること」といった要件に加え、採用する構成や確認すべき動作も記録します。相談の履歴は設計を進める助けになりますが、実装に必要な決定事項は文書にも残す必要があります。
Goldfishは、Elephantの会話履歴を引き継がない、新しい文脈で動くレビュー役です。設計書や明示されたソースコードを読み、未定義の用語、説明不足、設計上の矛盾などを調べます。
ここでいう「文脈を持たない」とは、設計書も渡さないという意味ではありません。設計時の会話を知らなくても、渡された資料から理解できるかを確認します。Goldfishの役割定義にも、新しく参加したメンバーのように読み、暗黙の前提を受け入れないことが指示されています。
たとえば「既存のログインを使う」とだけ書かれていても、実装担当者には、どの情報から利用者を識別するか分からないかもしれません。Goldfishに期待するのは、こうした説明の不足を具体的な確認事項にすることです。
会話を分けても、AIの見落としがなくなるわけではありません。同じモデルなら似た判断をする可能性もあります。Goldfishの指摘を、別の読み手から得られたレビューとして確認する姿勢が必要です。
EGMの基本的な入口は、相談、設計書作成、レビューの3つです。以下は公開READMEにある代表的なSkillsです。呼び出し方は利用環境によって異なります。
| Skill名 | Command | 主な用途 |
|---|---|---|
| Brainstorm | /egm-brainstorm | 解決したい問題と要件、案を整理する |
| Draft | /egm-draft | 相談内容をもとに、設計書を節ごとに作る |
| Review | /egm-review | Goldfishによる複数段階のレビューを進める |
公開されているレビュー設計では、全体を5段階で点検します。
| 段階 | 確認すること |
|---|---|
| 最初の全体確認 | 解くべき問題に合っているか、不要な機能を増やしていないか |
| 理解の確認 | 前提を知らない読み手にも説明が通じるか |
| 設計の批評 | 障害時の動作や境界条件、設計上のリスクを扱っているか |
| 再度の全体確認 | 指摘への対応で設計が過剰に複雑になっていないか |
| 実装準備の確認 | 変更するファイルや検証方法が具体的になっているか |
指摘を増やすだけでなく、対応後に設計を見直す工程がある点も特徴です。すべての懸念に機能追加で答えると、当初は小さかった開発が大きくなってしまうためです。
導入方法は、利用環境ごとの手順をまとめた公式の導入ガイドをご覧ください。
Skillsそのものの仕組みは、以下の記事で紹介しています。
今回は、Codexに導入したEGMプラグインを使い、会議室予約アプリの要件を相談して、設計書の初稿をレビューしました。進め方は、公式READMEの「Try your first design」を参考にしています。
Brainstorm、Draft、Reviewの順にSkillを指定し、質問や確認に答えながら進めます。今回使用したのはCodex CLI v0.164.0、モデルはGPT-6-Astra（推論設定low）、EGMは0.1.0です。実施日は2026年10月27日です。
最初は $egm-brainstorm を指定し、社員約30人・会議室3室の予約アプリを作りたいと伝えました。空き状況の確認、予約、本人によるキャンセルができ、重複予約を防ぎたいという依頼です。技術はPython/FastAPIとPostgreSQLを想定し、まずは設計まで進めることにしました。
詳細な手順をこちらで指定しなくても、Skillが予約ルールや既存ログインとの接続について質問してくれます。今回は6回ほどの質問に答える形で、要件を整理していきました。
実際に聞かれたのは、次の6つです。一度に回答するのではなく、こちらの回答を受けて次の質問へ進む形でした。
たとえば、最初の質問に30分単位、1回30分〜2時間、平日9時〜18時、当日から30日先までと答えると、その内容を整理してから、次のログイン方式の質問へ進みました。機能の話だけでなく、共有表からの引き継ぎや先行公開中の運用まで確認してくれています。
会話で決めた内容は、後の設計書に次のように反映されました。
| 項目 | 整理した内容 |
|---|---|
| 予約時間 | 日本時間の平日9時〜18時。開始・終了は30分刻みで、長さは30分〜2時間 |
| 予約できる日 | 当日から30日後まで。日をまたぐ予約は対象外 |
| ログイン | 既存の社員ログインにOIDCで接続し、ログイン情報から予約者を設定する |
| キャンセル | 本人が終了時刻前まで操作でき、利用中のキャンセルも認める |
| 運用の切り替え | 11月中に公開し、11月30日までの利用分は共有表、12月1日以降は新システムで管理する |
OIDCは、既存の認証サービスと連携してログインするための仕組みです。接続先の具体的な情報など、まだ分からない点は未確定事項として残しました。
続いて $egm-draft を指定し、「ここまで相談した内容をもとに、会議室予約アプリの設計書を日本語で作成してください」と依頼しました。
すると、概要・課題・目標・対象外をまとめた初稿が作成されました。予約時間のルールだけでなく、本人によるキャンセルや12月利用分からの切り替えも反映されています。
ここで、技術構成・データ構造・APIの設計へ進んでよいか確認されました。Draftは節ごとに内容を確認する進め方なので、この時点では設計書の前半までです。今回は、この作成途中の初稿をReviewに渡しました。
実際の初稿では、アプリの概要や解決したい課題に続き、会話で決めた予約ルールが表に整理されています。
$egm-review と設計書のパスを指定し、「指摘を確認しながら、どれを修正するか相談したい」と依頼しました。追加で読ませたい資料があるか聞かれたため、今回は追加資料なしで進めています。
次に、レビューの進め方を選ぶ質問がありました。段階ごとに相談する方法などもありましたが、指摘をまとめて確認したかったため、2番の「全観点をまとめてレビューし、最後に相談する」を選びました。
レビューの役割や評価基準をプロンプトに細かく書くことはせず、プラグインの案内に沿って進めました。今回の対象には実装計画がなかったため、実装準備の評価は未実施です。
レビュー報告書には、重複を整理した6件の相談項目がまとまりました。内訳は、重要な確認事項を示すMajorが4件、表現の整理を示すNitが2件です。要件整理を直ちに止めるBlockerはありませんでした。
| ID | 優先度 | 指摘・相談したいこと | 提案された対応 |
|---|---|---|---|
| R1 | Major | 共有表にある12月以降の予約をどう扱うか | 既存予約の有無を確認し、ある場合の扱いと旧表での受付終了を決める |
| R2 | Major | 競合や開始時刻超過で予約できなかったときに何を伝えるか | 未成立と理由を表示し、最新状況を見て選び直せるようにする |
| R3 | Major | 有効な予約の定義と、キャンセル済み予約の表示 | 重複判定からキャンセル済みを除き、通常の予約状況から非表示にする案を検討する |
| R4 | Major | 予約状況を閲覧できる日付 | 当日から30日後までを表示する案を検討し、過去履歴を対象外にするか決める |
| R5 | Nit | 予約対象になる日と、実際の受付開始日が分かりにくい | 30日前という条件と、公開後に受付を始める条件を分けて書く |
| R6 | Nit | 「確認待ち」「確定した要件」「本会話」の関係が曖昧 | 会話の要件を転記した状態と、設計書としての承認状態を分けて記載する |
これらは修正候補であり、すべて採用が決まったわけではありません。特にキャンセル後の表示（R3）や閲覧範囲（R4）は、利用者と相談して決める案として提示されています。
分かりやすかったのが、R1の運用切り替えに関する指摘です。初稿では、次の方針を決めていました。
しかし、共有表に12月以降の予約がすでに入っているかは、設計書に書かれていませんでした。もし入っていれば、新システムの予約同士が重ならなくても、共有表の予約者と新システムの予約者が同じ会議室を使おうとする可能性があります。
報告書では、既存予約がなければ、その前提と共有表での受付終了を明記すればよいと整理されています。予約がある場合は、本人による再予約などの方法に加え、既存予約をどう優先するかも相談が必要です。単に再予約を求めるだけでは、受付順によって元の枠を失うおそれがあるためです。
自動移行機能を追加するという結論に飛ばず、まず実際の予約の有無を確認する提案になっていました。今回のレビューでは、システムの機能に加えて、共有表から切り替える際の運用上の抜けも確認できました。
報告書を作成した後、Codexは、設計書をまだ変更しておらず、アプリも実装していないことを伝えたうえで、次の質問を返しました。
日本語のレビュー報告書 (consolidated_review_report.md)に、修正候補6件と具体案をまとめました。
主な確認点は、既存予約の切り替え、予約失敗時の案内、キャンセル後の表示、閲覧できる日付です。設計書は変更しておらず、アプリも実装していません。実装準備の評価は、計画未作成のため未実施です。
まず、二重予約につながり得る切り替え方針から相談したいです。共有表には、12月1日以降の予約がすでに入っていますか？（ある／ない／未確認）
指摘を一覧にして終わるのではなく、優先したい確認事項から、具体的な修正方針を決める対話へ進んでいます。ここから予約の有無を回答し、提案の採否を判断しながら設計書を補っていく流れです。
今回のデモは、この修正相談の入口までとしています。設計書の修正、技術設計・実装計画の完成、アプリの実装は行っていません。6件という件数よりも、次に何を確認して決めればよいかが具体的になった点が、今回の結果です。
EGMは、設計の経緯を持つElephantと、その経緯を引き継がないGoldfishで、設計書の作成と点検を分担する手法です。公開プラグインには、相談から設計書作成、複数段階のレビューまでの手順が用意されています。
今回のデモでは、各Skillを指定して質問に答えることで、要件の相談から設計書の初稿作成、6件のレビュー項目の整理まで進められました。特に、共有表に残る予約の扱いは、運用を切り替える前に確認すべき点として示されました。
最初から詳細なレビュー手順を用意しなくても、プラグインの案内に沿って設計を具体化できます。まずは小さな機能を題材に、Brainstormで相談し、Draftで文書化して、Reviewがどのような確認事項を返すか試してみてください。
Tech Funでは、お客様のフェーズに合わせ、生成AI活用に向けた様々な支援をご提供しています。
生成AIに限らず、Web・業務システム開発やインフラ設計など、技術領域を問わずご相談を承っています。「何から始めれば良いか分からない」という段階でも構いませんので、ぜひお気軽にお問い合わせください。
