修正の無限ループから脱出！CodexのMain/Side Chat二刀流でアプリ開発が驚くほどラクになった話【プロンプト付】

はじめに

CodexとWebアプリを作り始めたころ、作業は進んでいるのに、私が欲しかった使い方からずれていくことがありました。説明を足して修正してもらっても、次の報告を読むと、また別のところで認識がずれている。どこまで任せてよくて、どこで私が確認すればいいのか、最初はよく分かりませんでした。

例えば、「申込フォームへのリンクを付けて」と頼むだけでは、ログイン前の人にも見せたいのか、申し込んだ時点で使えるのか、誰が承認するのかまでは伝わりません。「実装とレビューが終わった」と報告されても、利用者が実際の画面から申し込めるかは、もう一段確認が必要です。

そこで、最初にCodexと要件を話し合い、画面を変えるときは変更前と変更案を並べ、触ってよい範囲と承認が必要な操作を決めるようにしました。なかでも使いやすかったのが、メインchatで開発を進めながら、side chatで「今なぜこの作業をしているのか」を聞く方法です。

この進め方は、Codexだけで始められます。作業が増えてからは、メインchatのCodexに取りまとめを任せ、Claudeへ実装の一部を、Geminiへ文言レビューを依頼させる形も使いました。複数のAIを使う方法は、後半の上級編に分けています。

💡 この記事のプロンプトで楽になること

• 着手前に完成イメージをすり合わせ、意図と違う実装を修正する手間を減らせる。
• 作業を離れても、保存した記録と再開用プロンプトから、次にやることを確認できる。
• ClaudeやGeminiへの依頼、成果の確認、本体への統合をCodexに任せ、必要な承認は自分で判断できる。

初めて試すなら、Codexで対象のプロジェクトを開き、基本編の最初のプロンプトをそのまま貼ってください。やりたいことをまだ伝えていなければ、「ログイン前の画面に申込ボタンを付けたい」のように一文で答えれば始められます。

🔰 基本編｜まずはCodexだけで始める

1. 要件定義から始める

最初は「こうしたい」という一文で十分です。Codexと話し合いながら、誰が、どの画面から、何をできれば完成かを具体化します。

話し合うこと	申込フォームの例
誰がどこから使うか	利用希望者が、ログイン前または未承認時の画面から操作する
何ができればよいか	既存の申込フォームを開ける
誰が利用を承認するか	運営者が申請内容を確認し、個別に承認する
何を維持するか	承認済みアカウントだけが保護された機能を利用できる
完成をどう確かめるか	検証環境でリンクの遷移と、未承認アカウントへのアクセス拒否を確認する

この開発では、話し合う中で「フォームを80回答で締め切る」と「条件を満たした人を最大80人まで承認する」が別の要件だと分かりました。前者は受付件数、後者は利用権限の管理です。ここを先に整理すると、フォームとアプリのどちらで何を制御するか決められます。

最初にメインchatへ貼る

これからアプリの要件を一緒に整理してください。
まず、これまでの会話と、参照できる現行の画面、実装、プロジェクトのルールを確認してください。

今回の要望が会話にあればそれを使い、まだなければ、
私が利用者に何をできるようにしたいかを一つ質問してください。
判断が必要な点は、選択肢とそれぞれの違いを示してください。

話し合った結果を、目的、利用者の操作、今回の範囲、維持する機能、
禁止事項、承認が必要な操作、完成条件に整理してください。
確定事項と提案を区別し、私が確認できる要件案を出してください。
この段階の作業は、読み取り調査と要件の整理です。

2. デザインは「変更前・変更案・実装後」で見る

UIの変更は、同じ画面サイズ、言語、ログイン状態で比較します。

画面	変更前	変更案
ログイン前	ログインボタンがある	近くに「利用を申し込む」を置く
未承認時	利用できないことが表示される	理由と申込先を示す

実装前は、モックや簡単な配置図で判断できます。実装後は、同じ条件で実画面を確認します。スクリーンショットに「申込ボタンを押してフォームが開いた」「未承認者は保護機能に入れなかった」といった操作結果を添えると、見た目と動作の両方を確認できます。

3. 禁止事項・承認・中断の基準を決める

区分	私の運用例
承認した範囲で進める	読み取り調査、指定領域での実装、許可済みのテスト
実行前に人間が判断する	外部への送信、課金API、実ユーザーの登録、本番公開
禁止する	原本の削除・上書き、鍵や実利用者情報の共有、担当範囲外の編集

「検証してよいですか？」と聞かれるより、**「検証環境でこの版を1回起動し、テストアカウント一つでログインを確認する」**まで具体化されているほうが判断しやすいです。操作に応じて、実行先、影響、費用や回数、戻し方も確認します。

同じエラーが続く場合の区切りも決めます。例えば、同じ原因を想定した修正は2回までにして、解消しなければ、その作業を止めてエラー、試したこと、差分、次に必要な判断を記録します。2回は運用例です。課金や外部への書き込みで結果が分からなくなった場合は、まず実行済みかを確認します。

方向がずれたときは、git status や git diff で何が変わったかを確認します。差分を残し、戻す必要があれば、今回の変更と以前からあった変更を区別して対象を決めます。

ルールと進捗は別のファイルに置く

ファイル	内容
AGENTS.md	作業範囲、禁止事項、テスト方針、進捗ファイルの場所
PROGRESS.md	合意した要件、対象版、確認結果、未完作業、次の一手
SIDE-NOTES.md	side chatでの決定と理由、未決事項、メインへの伝達状況

すでに正式な進捗ファイルがあるプロジェクトでは、それを使います。この記事では、共通の進捗ファイルを PROGRESS.md と呼びます。更新担当はメインchatのCodexです。

進捗は、例えばこのくらいの粒度で残します。

## 申込フォームへの導線

- 完了条件：検証環境でフォームが開き、未承認者が保護機能に入れない。
- 現在地：実装と独立レビューを完了。検証環境への配置はこれから。
- 根拠：対象の差分とレビュー記録。
- 次の一手：同じ版を検証環境で起動し、申込リンクの遷移を確認する。

4. 合意した要件で実装し、一連の操作を通す

機能が複数ある場合は、最初に利用者の操作を一つ選び、同じ版で最後まで通すと、部品ごとの確認では見えなかった問題を拾えます。申込導線なら、画面の表示、リンクの遷移、未承認時の制限までを確認します。

要件に合意した後、メインchatへ貼る

このメインchatで直近に合意した要件を実装してください。
適用されるAGENTS.md、現行計画、最新の進捗記録を確認し、
対象のリポジトリ、版、機能、完了条件を特定してください。
要件が確定していない場合は、実装に必要な判断を私に確認してください。

UI変更は、変更前と変更案を同じ条件で比較してください。
確認済みの変更案を実装し、実装後は同条件の実画面と操作結果を示してください。

会話とプロジェクトのルールで認められた範囲で作業してください。
追加承認が必要な操作は、対象、実行先、影響、上限、戻し方を示してください。

既存の正式な進捗記録を使ってください。なければPROGRESS.mdを使い、
対象版、実装、レビュー、統合、起動、実操作の結果を分けて記録してください。
同じ原因を想定した修正試行は2回までとし、解決しなければ該当作業を止め、
エラー、試行結果、保持した差分、次に必要な判断を記録してください。
結果が不明な外部操作は、実行済みかを照合してから次の判断に進んでください。

一工程ごとに止まる作業にはGoalモードを使う

通常の依頼で開発を進めていたときは、一つの工程が終わるたびに報告が入り、私が「次の検証も進めて」と送り直すことがありました。申込ボタンを実装したところで返答が終わり、検証環境での画面確認は次の依頼になる、といった具合です。

複数の工程を通す作業では、メインchatにGoalを設定して、何を確認したら完了かを持たせると進めやすくなります。合意した要件があり、新しくGoalを設定する場面では、次を貼れます。

/goal このメインchatで合意した要件を実装し、合意済みの検証環境と手順で受入条件を確かめる。実装・レビュー・統合・実操作の結果を対象版とともに進捗記録へ残す。中間工程の報告後も承認済みの範囲で進め、合意済みの中断基準に達したときや追加の承認・情報が必要なときは、未完条件と次に必要な判断を示す。

既存のGoalがある場合は、その目標を確認してから作業指示を追加します。/goal が使えない環境では、進捗記録に目標と完了条件を書き、応答が一区切りついたら「進捗記録を読み、次の未完項目を進めてください」と送ります。

5. side chatで進捗を読み、決めたことをメインchatへ戻す

対応するCodexでは、メインchatから /side で質問用の会話を開けます。私はメインchatで実装を進め、side chatでは「この報告は何を確認したという意味か」「次に何を判断すれば進むか」を聞きます。

メインchatは PROGRESS.md を更新し、side chatは参照できる最新の記録を読みます。 side chatからファイルを開けない場合は、私がメインchatの最新報告や必要な箇所を貼ります。/side が使えない環境でも、別のチャットに必要な文脈を渡して、読み取りと説明を依頼できます。

side chatで仕様を検討したら、私が採用した決定を、変更範囲と確認方法と一緒にメインchatへ伝えます。

side chatを開いて貼る

このside chatでは、メインchatで進んでいる開発の状況を説明してください。
既存の正式な進捗記録、またはPROGRESS.mdを読み取りで参照してください。
参照できない場合は、必要なメインchatの報告を私に求めてください。

全体の工程、現在地、前回から進んだこと、その根拠、次の節目を示してください。
実装済みの項目と、実際の操作確認が残る項目を分けてください。
達成率は、合意済みの受入項目と計算方法がある場合に示してください。

確認できた時点を明記してください。
ここで仕様が決まったら、決定内容、変更範囲、確認方法を、
メインchatに貼り付けられる短い指示にしてください。

6. 中断・再開は、メインchatとside chatで別々に行う

メインchatには実装を再開するための作業記録を、side chatには相談を再開するためのメモを残します。次回は、まず PROGRESS.md と SIDE-NOTES.md を開けば、作業と相談の両方を追えます。

相談だけ中断する日はside用を使い、開発も中断する日はメイン用も使います。

中断時にメインchatへ貼る

ここで開発を中断します。新しい作業の開始を止め、
現在の作業と各担当の状態を確認し、安全に区切れるところで停止してください。

対象版、差分、完了分、未完分、検証結果、実行中または結果が不明な処理、
承認の使用状況、再開に必要な条件を、既存の進捗記録またはPROGRESS.mdに保存してください。

停止を確認できた範囲、記録の場所、再開時の最初の作業を示してください。
Goalや予約などで続く作業がある場合は、その状態と中断に必要な操作も示してください。

中断時にside chatへ貼る

ここで相談を中断します。再開用のメモをMarkdownで作ってください。

日時、対象のメインchat、参照した進捗記録、確定した決定と理由、
未決事項、メインchatに伝達済みの内容をまとめてください。
末尾に、再開時に最初に読む記録と、次に確認することを書いてください。

許可済みのSIDE-NOTES.mdや既存の相談メモがあれば追記してください。
保存先を決めていない場合は、私が保存できる本文を出してください。

再開時にメインchatへ貼る

前回の開発を再開します。既存の正式な進捗記録、またはPROGRESS.mdを読み、
現在の対象版、差分、担当の状態、実行結果、承認の有効範囲を照合してください。
このchatに追加の決定が伝えられていれば、それも確認してください。

完了済みの作業を引き継ぎ、結果が不明な処理は先に状態を確認してください。
現在地と最初の作業を示し、承認済みの範囲で未完分から進めてください。
必要な記録が参照できなければ、どの記録が必要かを具体的に示してください。

再開時にside chatへ貼る

前回の相談を再開します。参照できるSIDE-NOTES.mdまたは既存の相談メモと、
最新のメインchatの報告・進捗記録を照合してください。

前回から変わったこと、引き続き未確認のこと、
メインchatに伝えていない決定や提案を分けてください。
現在地と、私が次に確認することを一つ示してください。
記録を参照できない場合は、必要な箇所を私に求めてください。

🚀 上級編｜Codexを「元請け」にしてClaude・Geminiに仕事を任せる

機能が増えると、実装、コードレビュー、画面文言の確認を並行して進められる場面が出てきます。そこで、メインchatのCodexに、作業を切り出し、ClaudeとGeminiに依頼し、成果を受け取って判断するところまで任せます。

たとえるなら、Codexが元請け、ClaudeとGeminiが担当範囲を持つ下請けです。私が決めるのは要件と許可範囲です。誰に何を渡すか、何が返ってきたか、どの成果を採用するかは、メインchatのCodexが整理します。

Codexから依頼し、返答まで受け取る

申込フォームの例では、Codexに次のように切り分けてもらいます。

Codexが依頼する先	渡す内容	受け取る成果
Claude	合意した要件、許可された入力、担当範囲、確認項目	実装案や差分、自己検証の結果、残っている確認
Gemini	「申込を受け付けました。審査後にご連絡します」などの架空文言	初見でどう読めるか、誤解しやすい表現、日英の代案
Codexのサブエージェント	対象の版と差分、守るべき承認条件	問題の箇所、再現条件、確認できた範囲

CodexからClaudeやGeminiへ実際に依頼を送るには、その環境で使える連携手段と、送信の許可が必要です。許可されたアプリ操作や接続手段があれば、メインchatのCodexが依頼の送信、回答の回収、結果の確認まで担当します。接続手段がなければ、Codexが貼り付け用の依頼文を用意し、私が回答を持ち帰ります。

Claudeに文章だけを渡せる場合は、実装方針や差分案を受け取ります。Claude Codeに作業環境へのアクセスを許可している場合は、専用の作業領域で実装と自己検証まで任せられます。Geminiには、共有を許可した架空の文言だけを渡します。

両方のサブエージェントを一つの担当表で管理する

CodexとClaude Codeの両方がサブエージェントを使うときは、親AIをまたいで一つの担当表にします。

例えば、Codex側の子は「既存の認証経路の調査」と「差分の独立レビュー」、Claude Code側の子は「担当画面の実装」と「その画面のテスト観点の調査」を受け持ちます。書き込みできるファイル、依存関係、成果物を表で確認し、同じファイルの編集者を一人にします。

メインchatのCodexは、返ってきた成果を確認して採否を決めます。Claudeの自己検証結果は差分と照合し、Geminiの案は画面文言に採用するか判断します。本体への統合と、利用者と同じ手順での動作確認は、メインchatが引き受けます。

複数のAIを使いたいときに、メインchatへ追加で貼る

この開発では、メインchatのCodexであるあなたが取りまとめを担当してください。
私が各AIに毎回指示を出さなくて済むよう、合意した要件から独立して進められる
作業を切り出し、許可された範囲でClaudeとGeminiに依頼してください。

Claudeには範囲を限定した実装案・差分・自己検証を依頼してください。
Claude Codeに編集を任せる場合は、指定された専用の作業領域を使わせてください。
Geminiには共有を許可した架空のUI文言だけを渡し、初見の理解と日英表現を確認してください。

利用できる連携手段と送信許可を確認し、条件がそろっていれば、
あなたが依頼文の作成、送信、回答の回収、内容の確認まで行ってください。
連携手段がなければ、私が貼り付けられる依頼文を出してください。

CodexとClaude Codeの両方でサブエージェントを使う場合は、
全員の担当、対象版、書き込み範囲、依存関係、成果物、確認方法を一つの表にしてください。
同じファイルの書き込み担当は一人です。
外部の担当に共有する情報は、許可された内容だけに絞ってください。

依頼案の作成、送信、受領、着手、成果の受け取りを区別して記録してください。
応答が途切れた場合は、元の依頼の状態を確認してから再送や再割当を判断してください。
返ってきた成果を独立に確認し、採用する差分だけを本体に統合してください。
統合後の検証結果と未確認の項目を、既存の進捗記録またはPROGRESS.mdへ残してください。

💡 お役立ちミニTips

• 最初はCodexだけでボタン一つを変える。 要件定義、変更前後の比較、実装、操作確認を一周すると、自分の開発に合う進め方が見えてきます。
• 進捗は「どの版を、どこで、どう確認した？」と聞く。 レビューが済んだ範囲と、実際に使えることを確認した範囲が分かります。
• 「Claudeに依頼済み」の次を聞く。 「依頼文を作った」「送信した」「返答を受け取った」「成果を確認した」を分けると、どこで待っているかが分かります。
• 承認待ちは、操作まで書いてもらう。 「検証環境でこの版を1回起動する」まで分かれば、許可する範囲を判断できます。
• Goalの停止状態も確かめる。 対応する環境では /goal pause や /goal resume でGoalを管理できます。開発を中断する際は、実行中の処理や担当の状態も確認します。
• 再開メモの最後に、具体的な一手を書く。 「認証を続ける」より「検証環境で未承認アカウントが拒否された結果を読む」と残すと、翌日に何から始めるか迷いません。