codex-consultation

Codex CLI 相談手順書

概要

相談先Agent（Codex CLI / OpenAI）にセカンドオピニオンを求め、その結果を要約してユーザーに報告する。 ユーザーはcodexの生出力を直接見る必要はない。相談元Agentがcodexの回答を咀嚼し、自分の見解と照らし合わせて報告する。

登場人物

本手順には3者が登場する:

• ユーザー: 相談を依頼する人間
• 相談元Agent: この手順を実行しているAgent自身。ユーザーからの要請を受けて相談先Agentと相談し、結果をユーザーに報告する
• 相談先Agent（Codex CLI）: セカンドオピニオンを提供する外部Agent

ユーザーへの報告時、見出しに自分のAgent名を使うこと（例: 「Claude Codeの見解」「Clineの見解」等）。

1. codexインストール確認

Bashツールで以下を実行する:

command -v codex

codexが見つからない場合は、ユーザーに「Codex CLIがインストールされていません」と報告して終了する。 それ以上の作業は行わない。

2. 相談の深さの確認

ユーザーが相談の深さを明示していない場合（「全力で」「深く」「よく」「軽く」等の指定がない場合）、 AskUserQuestionツールで以下の3択を提示する:

選択肢	往復回数	相談元Agentの仮見解	漏れ抜けの追求度
よく相談する（推奨）	必要に応じて2往復	相談元Agentが判断	漏れ抜けを確認して報告
全力で深く相談する	2往復を原則実施（明らかに不要な場合のみスキップ）	必ず含め、検討したが採用しない事があればその理由も書き、妥当性の検証を促す	積極的に反論・補完・追加追求
軽く相談する	1往復のみ	相談元Agentが判断	Codexの指摘を整理して報告

ユーザーが明示的に深さを指定している場合はこの確認を省略し、指定に従う。

3. プロンプトの設計

codexに渡すプロンプトを相談元Agentが設計する。以下の指針に従う:

プロンプト設計の指針

• 会話のコンテキストから「今何について相談すべきか」を判断する
• ユーザーが明示的にテーマを指定している場合はそれに従う
• 指定がない場合は、直前の議論や作業内容から適切なテーマを選ぶ

コンテキスト別のプロンプト例

未commitの変更をレビューしたいとき

「このリポジトリの未commitの変更をレビューしてください。コードの品質、設計の妥当性、潜在的なバグ、改善点を指摘してください。」

設計について相談したいとき

「以下の設計について意見をください。[設計の要約]。代替案やトレードオフがあれば提案してください。」

実装方針を相談したいとき

「[タスクの要約]を実装したい。このリポジトリのコードベースを踏まえて、最適な実装方針を提案してください。」

プロンプトの構成

1. プロジェクトの背景（簡潔に）
2. 相談したい具体的な内容
3. 相談元Agentの現時点での仮見解。「全力」モードでは必ず含め、他のモードでは状況に応じて含める
4. 指定観点以外も幅広く探索するよう依頼（常に含める）

相談元Agentの仮見解を含める場合のテンプレート

仮見解には、現時点の見解とその理由を書く。検討したが採用しない事がある場合は、その内容と採用しない理由も書き、相談先の検証対象にする。検討していない事を、採用しない事として書かない。

なお相談元Agent（[自分のAgent名]）は現時点で以下のように考えている:
- 現時点の見解: [見解とその理由]
- 検討したが採用しない事: [採用しない事とその理由]

見解に漏れや誤りが無いか、採用しない判断の理由・根拠・前提が妥当かを検証し、反論があれば示してほしい。
相談元Agentが検討していない選択肢があれば挙げてほしい。
指定した観点以外にも気になる点があれば積極的に報告してほしい。

幅広い探索の依頼（常にプロンプトに含める）

指定された観点はあくまで出発点であり、制約ではない。 リポジトリを自分で探索して気になる点があれば積極的に報告してほしい、という旨を必ずプロンプトに含める。

4. codexの実行

プロンプトを一時ファイルに書き出し、Bashツールで以下の形式で実行する:

codex exec --ephemeral -s workspace-write -c sandbox_workspace_write.network_access=true < /path/to/prompt.md

重要なオプション

• --ephemeral は必須。セッションを保存しない
• -s workspace-write -c sandbox_workspace_write.network_access=true は必須。デフォルトではサンドボックスがネットワークアクセスをブロックするため、ghやcurlなどの外部通信コマンドが失敗する
• ユーザーや呼び出し元のskillがCodexのmodelやreasoning effortを指定している時は、-m <model> と -c model_reasoning_effort=<effort> で上書きする。reasoning effortには専用のフラグが無く、設定値の上書きで渡す。指定が無い時は上書きせず、codexコマンドの既定設定をそのまま使う
• -m に渡すのはmodel IDである。「Astra」のように表示名や別名で指定された時は、codex debug models が出すmodelカタログで表示名からIDを解決する。同じ名前で世代だけが違うmodelが複数ある時は、version番号が最も新しいものを選ぶ。「Daybreakに対応する中で最新のSol」のようにユーザーが条件を付けていれば、その条件を満たす中で最も新しいものを選ぶ。カタログにはmodelごとに対応するreasoning effortも載っている
• ユーザーや呼び出し元のskillがDaybreakを指定している時は、--cyber-access-program daybreak_blue を付ける。Redを指定された時は値を daybreak_red にする。Daybreakはmodelではなく、Codexの提供元がサイバーセキュリティの作業向けに承認制で提供するアクセスprogramで、このフラグで1回の実行ごとに有効になる
• Daybreakに対応するmodelは限られる。Daybreakを使う時のmodelは、指定があればそれ、無ければcodexコマンドの既定設定のmodelである。実行の前に、そのmodelがDaybreakに対応するかをmodelカタログで確かめる。カタログにはmodelごとに利用できるアクセスprogramが載っている。対応していなければ実行せず、カタログからDaybreakに対応するmodelを集めてユーザーに提示し、選んでもらう
• ワーキングディレクトリはカレントディレクトリがそのまま使われる
• カレントディレクトリがgitリポジトリ内でないと、codexは起動せずに終了する。エラーメッセージはtrust設定の問題に見えるが、判定条件はgitリポジトリ内かどうかだけ。非gitディレクトリで相談する時は --skip-git-repo-check を付ける
• プロンプトはstdinから渡す。CLI引数で渡すと、stdinがpipe状態のときcodexが追加入力を <stdin> ブロックとして読みEOFまで待つためhangする
• プロンプトファイルはリポジトリの作業ツリー外に置く。作業ツリー内に置くと未commitの変更として現れ、レビュー対象を汚染する

タイムアウト

codexの実行には時間がかかる場合がある。Bashツールのtimeoutを900000（15分）に設定する。

出力の扱い

出力は、標準出力と標準エラー出力のどちらも欠落なく保持する。回答は標準出力に出るので、要約はそこから行う。標準エラー出力には、Codex CLIのversion、model、reasoning effortを示すヘッダが冒頭に出て、その後にcodexの作業の経過が続く。報告の実行環境の行はこのヘッダから取り、コマンド失敗の兆候は経過からも確かめる。ヘッダにDaybreakの状態は出ない。対応しないmodelはエラーで止まるので、フラグ付きで成功した事を有効になった根拠にする。tail で末尾だけを見るとヘッダを失う。

追加往復の判断

「全力」モードでは、1往復目の結果を受け取った後、2往復目を原則実施する。明らかに追加の深掘りが不要な場合（1往復目で十分網羅的な回答が得られた場合）のみスキップする。

「よく」モードでは、1往復目の結果を受け取った後、以下のいずれかに該当する場合は2往復目を実施する:

• さらに深掘りすべき重要なポイントがCodexの指摘に含まれている
• Codexの指摘に相談元Agentが反論・補完したいことがある
• 十分に探索されていない領域があると相談元Agentが判断できる

2往復目を判断する前に、1往復目の出力にコマンド失敗の兆候がないか確認する。失敗を検知した場合は、まず相談元Agentが正しい情報を取得・補正してから2往復目の要否を判断する（詳細はセクション5「codexのコマンド失敗を検知した場合」を参照）。

2往復目のプロンプト構成:

注意: codex execは単発実行のため、2往復目のCodexは1往復目の記憶を持っていない。最初から文脈を全て含める必要がある。

1. 元の相談内容の再提示（背景/目的/制約/評価観点を落とさず構造化して含める）
2. 1往復目のCodexの回答サマリー
3. 相談元Agentの反論・補完・追加質問
4. さらに掘り下げてほしい観点

往復は原則2回まで。3回以上はユーザーに確認してから実施する。

5. 結果の要約と報告

codexの出力を読み取り、以下の構成でユーザーに報告する:

報告の構成

codexへの相談内容

codexの実行環境を、標準エラー出力の冒頭のヘッダから読み取り、Codex CLI v0.153.4 (gpt-6-astra, reasoning effort: high) の形式で1行記載する。Daybreakを指定した時は、ヘッダに出ないDaybreakを Codex CLI v0.163.0 (gpt-6-sol, reasoning effort: high, Daybreak Blue) のように末尾に書き足す。続けてcodexに送ったプロンプトの概要を1-2文で説明する。

codexの回答サマリー

codexの主な指摘・提案を箇条書きで要約する。

[自分のAgent名]の見解

• codexの指摘のうち、同意するもの
• codexの指摘のうち、異なる意見を持つもの（理由付き）
• codexが見落としていると考えるポイント
• 2往復目を実施した場合は、その理由と2往復目で何が明らかになったか

見解の姿勢:

• codexの指摘を安易に受け入れない。相談元Agentとして検証を試みてから報告する
• codexが探索しなかった可能性がある領域を意識的に探す
• codexと相談元Agentの見解が食い違う場合は、その食い違いを価値ある情報として積極的に伝える

次のアクション提案

ユーザーと相談すべき事項や、推奨する次のステップを示す。

報告のスタイル

• 簡潔にまとめる。冗長な引用は避ける
• codexと相談元Agentの見解が異なる場合は、両方の理由を説明してユーザーが判断できるようにする
• ユーザーが次に何をすべきか明確にする

codexの回答が大きすぎる場合

codexの回答が長く、要約や処理が困難だと判断した場合は、以下の手順に従う:

1. まずユーザーに「codexの回答が非常に長かった」旨を報告する
2. 回答のうち読めた範囲の概要だけを伝える
3. ユーザーと相談して対処方法を決める（例: 観点を絞って再実行、プロンプトに出力量の制約を追加、など）

事前にプロンプトで出力量を制限しない。制限すると重要な情報が欠落するリスクがある。

codexのコマンド失敗を検知した場合

codexの出力を読む際、コマンド実行の失敗の兆候がないか注意深く確認する。 兆候の例: エラーメッセージ、「取得できなかった」「失敗した」「permission denied」「not found」など。

失敗を検知した場合は、以下の手順に従う:

1. まず、相談元Agentが正しい情報を自分で取得する。codexが失敗したコマンド（例: gh pr view）をBashツールで実行し、結果を確認する
2. 次に、取得した情報でcodexの分析を補正する。情報不足で的外れになった指摘を特定し、正しい文脈で再評価する
3. 最後に、報告の見解セクションで情報不足を明示する。欠落情報と、その影響を受けた指摘を具体的に説明する

Codexの提供元のフィルタで相談が止められた場合

Codexの提供元は、サイバーセキュリティに関わる依頼をフィルタで止める事がある。止められた時は、標準エラー出力に、内容がサイバーセキュリティ上のリスクの可能性で止められた旨のエラーが出て、最終回答が無いままexit code 1で終わる。相談の依頼そのものが止められている。

止められた事と、送ったプロンプトの要旨を報告する。言い換えて再依頼するか、Daybreakを有効にしてやり直すかは、ユーザーや呼び出し元のskillが決める。

6. 改善提案

codexが何らかの失敗をしたパターンを認識したら、次回以降の改善策をユーザーに進言する。