Claude Code の答えに ChatGPT がダメ出し｜Codex に聞くカスタムコマンドの作り方

Claude Code が出した答えに、ChatGPT の Codex が反対意見を出す。 私が毎日使っている、自作のコマンドの話です。

私は Claude Code に出会ってから、今では作業の95%を Claude Code でやっています。 それでも、技術の問題がどうしても解決できないときや、絶対に失敗したくない判断のときは、ほかの意見も聞きたくなります。

以前は、Web のチャットを開いて、ChatGPT、Claude、Gemini、Grok の4つにそれぞれ聞いていました。 それすら面倒になって、Claude Code から直接ほかの AI に聞けるようにしたのが、今回のコマンドです。

この記事では、動画で話した内容に加えて、4つのコマンドの全文、実際に Codex から返ってきた意見の原文、それで台本と題名がどう変わったかを載せています。 コマンドはコピーして、そのまま使えます。

動画でも解説しています。

なぜ別の会社の AI にダメ出しさせるのか

AI に自分の答えを見直させても、同じ所を見落としやすいのです。 人の仕事でも同じで、作った本人のチェックだけでは穴が残ります。

27年、IT とビジネスの仕事をしてきて、作る人と確かめる人を分けるのが、品質の基本でした。

そこで、Claude が作った答えを、別の会社の AI に見せて反対意見を出させます。 その意見を読んで、直すかどうかは Claude が決めます。 Claude が上司、ChatGPT が部下という分け方です。

全体の流れ

手順は3つです。 使うのは、いつもの Claude のチャットの画面ではなく、Claude Code です。

コマンドが動くと、裏ではこう進みます。

1. Claude が、Codex 向けの質問を自分で書き起こし、ファイルに保存する 2. Claude が、codex exec でその質問を Codex に渡す（裏で実行） 3. 終わるまで15秒ごとに様子を見る 4. Codex の出力から、最後の答えの部分だけを抜き出す 5. Claude が要約して、反対された点を省かずに私に伝える

私が打つのは、最初の1行だけです。

手順1　Codex CLI を入れてログインする

Codex は ChatGPT の OpenAI が出している、文字で操作する AI です。 OpenAI の公式の手順では、macOS と Linux はこの1行で入ります。

curl -fsSL https://chatgpt.com/codex/install.sh | sh

入れたら、codex と打って起動します。 初めて動かすときに「Sign in with ChatGPT」（ChatGPT でサインイン）を選びます。

codex

公式には、codex login と打ってブラウザで手続きを済ませる方法も載っています。

codex login

ここは API キーではなく、ChatGPT のアカウントでログインします。 OpenAI の公式は、ログインの方法を2つに分けています。

• ChatGPT でサインイン：契約しているプランの枠で使う
• API キーでサインイン：使った分だけ API の料金がかかる

公式には「API キーでの利用は、OpenAI Platform のアカウントを通じて、通常の API の料金で請求される」と書いてあります。 いつものプランの枠で使いたいなら、アカウントでログインです。

手順2　自分専用のコマンドを作る

Claude Code には、自分でコマンドを追加できる仕組みがあります。 .claude の中の commands というフォルダに、Markdown のファイルを1つ保存するだけです。

ファイルの名前が、そのままコマンドの名前になります。 Anthropic の公式の表には「.claude/commands/deploy.md → /deploy」と載っています。 ask-codex.md なら、/ask-codex です。

私はホームの中の ~/.claude/commands/ に保存しています。 フォルダが無ければ、先に作ります。

mkdir -p ~/.claude/commands

そこに、下の全文を ask-codex.md という名前で保存します。

なお、公式の今の説明では、カスタムコマンドは「スキル」に統合されています。 .claude/commands/deploy.md と .claude/skills/deploy/SKILL.md は、どちらも /deploy を作り、同じように動く。 今ある .claude/commands/ のファイルはそのまま動く、と書いてあります。

ファイルの頭の3行

ファイルの最初の、--- で挟んだ部分は設定です。

本文に出てくる $ARGUMENTS には、/ask-codex のあとに打った言葉がそのまま入ります。

中身は5つ

本文は、普通の日本語の指示です。 Claude への仕事の頼み方を書いておく、と考えてください。 私の ask-codex.md に書いてあるのは、大きく5つです。

1. Codex は会話を知らないので、背景、いまの案、聞きたい点を全部書いて渡す 2. 聞きたい点は、箇条書きで3つから5つに絞る 3. 「忖度は不要。賛成できない点は明確に反対してください」と必ず書く 4. 「結論を先に書くこと」、日本語、2000字以内 5. Codex を呼び出す命令そのもの（質問をファイルに書く、裏で実行する、答えの所だけを読む）

いちばん大事なのは3つ目です。 AI は、放っておくと相手に合わせてしまいます。

返ってきた意見の扱い方も書いてあります。 反対された点は省かずに伝える。 そして、鵜呑みにもしない。 根拠を確かめてから決めます。

ask-codex.md の全文

note の仕組みの都合で、ファイルの中のコードの枠（バッククォート3つで挟んだ部分）は、行頭を4字下げる書き方に置き換えて載せています。 Claude Code での動きは同じです。 元の書き方のままの全文は、動画の固定コメントに載せています。

---
description: codex（別LLM）にCLI経由で意見を聞く。設計・戦略・コードレビューのセカンドオピニオン用
argument-hint: "<聞きたいこと> 省略時は直近の議論について意見を求める"
allowed-tools: Bash(codex:*), Bash(cat:*), Bash(awk:*), Bash(sed:*), Bash(mkdir:*), Bash(sleep:*), Bash(pgrep:*), Bash(wc:*), Bash(nohup:*), Bash(sh:*), Bash(rm:*), Write, Read
---

# Ask codex

別のLLMである `codex` にCLI経由で質問し、セカンドオピニオンを得る。自分（Claude）の判断が正しいか検証したいとき、設計・戦略の妥当性を第三者に確認したいときに使う。

## 質問内容の決定

- 引数 `$ARGUMENTS` が**ある**場合: それを質問の主旨とする。ただしそのまま投げず、**codex が単体で理解できる自己完結したプロンプトに書き起こす**こと。codex はこの会話の文脈を一切持っていないため、前提・背景・現在の状況を必ず補って書く。
- 引数が**無い**場合: 直近の議論の論点を自分で要約し、それについて意見を求めるプロンプトを組み立てる。

## プロンプトの書き方

セカンドオピニオンの価値は「忖度しないこと」にあるので、必ず次を含める。

- 前提となる背景（codex は文脈ゼロである前提で書く）
- 現在検討している案、または自分が出した結論
- 判断してほしい具体的な論点（箇条書きで3〜5点）
- 「忖度は不要。賛成できない点は明確に反対してください」という指示
- 「結論を先に書くこと」という指示
- 出力言語（原則 日本語）と字数上限（原則 2000字以内）

ファイルの内容をレビューさせる場合は、**絶対パス**をプロンプト内に書けばよい（codex はファイルを読める）。既に他のLLMのレビュー結果がある場合は、そのファイルパスも渡して「既出の指摘は繰り返さず、まだ潰せていない穴を指摘してほしい」と依頼すると重複を避けられる。

## 実行手順

1. スクラッチパッドにプロンプトをファイルとして書き出す。長文をシェル引数に直接埋めるとクォート事故が起きるため、**必ずファイル渡し**にする。

    D="${SCRATCHPAD:-/tmp}"; mkdir -p "$D"
    # プロンプトは Write ツールで "$D/ask_codex_prompt.txt" に書き出す

2. バックグラウンドで実行する。サブコマンドは `exec`（非対話）。git リポジトリ外でも動くよう `--skip-git-repo-check` を必ず付ける。

    nohup sh -c "codex exec --skip-git-repo-check \"\$(cat '$D/ask_codex_prompt.txt')\" > '$D/ask_codex_out.txt' 2>&1" >/dev/null 2>&1 &

3. 完了までポーリングする。

    for i in $(seq 1 10); do
      sleep 15
      pgrep -f "codex exec" >/dev/null || break
    done

4. **出力から最終回答だけを抽出する。** codex の出力は作業ログ・読み込んだファイルの中身・トークン数が大量に混ざるため、そのまま読むとコンテキストを浪費する。最終回答は `codex` だけの行より後ろに出る。

    awk '/^codex$/{f=NR} {l[NR]=$0} END{for(i=f+1;i<=NR;i++) print l[i]}' "$D/ask_codex_out.txt" \
      | sed '/^tokens used/,+1d' | awk 'NF||p{print;p=1}'

5. 結果を読んで**ユーザーに要約して伝える**。原文をそのまま貼り付けない。特に次を明示する。
   - codex が自分の結論に**反対した点**（ここが最も価値がある。省略しない）
   - 自分が**見落としていた論点**
   - 自分の判断を**変えるべきかどうか**の自分なりの結論

## 注意

- codex は「その主張は直前に立てた原則と矛盾している」といった**論理の一貫性の破れ**を指摘するのが得意。方針を改訂した直後のレビューに向く。
- codex の意見は参考であって決定ではない。反対されたら鵜呑みにせず、根拠が妥当かを自分で検証してから採否を決める。ただし**自分に都合の悪い指摘を握り潰さない**こと。反対意見は必ずユーザーに伝える。
- 重要な判断でレビューを取った場合は、抽出後の回答をプロジェクトのドキュメント配下（プロジェクトのフォルダ等）に `第三者レビュー_codex_<YYYYMMDD>.md` として保存する。

呼び出しの部分で使っている Codex の機能

5つ目の呼び出しには、codex exec を使っています。 OpenAI の公式によると、codex exec は、対話の画面を開かずに Codex を動かすための非対話モードです。

--skip-git-repo-check にも理由があります。 公式には、Codex は破壊的な変更を防ぐために Git のリポジトリの中で動くことを求める、とあります。 この確認を外すのが --skip-git-repo-check で、公式は「環境が安全だと確信できる場合に」使うように書いています。 ask-codex.md は、Git のリポジトリの外でも呼べるように、これを付けています。

手順3　/ask-codex と打つ

あとは、Claude Code の入力欄に打つだけです。

/ask-codex 聞きたいこと

聞きたいことを省くと、Claude が直近の議論の論点を自分でまとめて聞きます。

ファイルを見てほしいときは、質問の中にそのファイルの場所を書けば、Codex が読みに行きます。 ほかの AI のレビューが既にあるなら、その場所も渡して「既出の指摘は繰り返さず、まだ潰せていない穴を指摘してほしい」と頼むと、重なりが減ります。 ここまで ask-codex.md に書いてあるので、私が打つのは1行だけです。

ふだんは、技術の問題で行き詰まったときや、新しい製品の名前、サイトの作りの判断に使っています。

実例1　この動画の台本にダメ出しさせた

この動画の台本も、書いてすぐ /ask-codex にかけました。 返ってきた1行目は、これです。

「結論：企画の核は良いですが、現状の「完全版」には反対です。初心者が再現するための手順が抜け、複数AIの効果も言い切りすぎています。説明を増やすより、実演を先に置き、再現に必要な情報を補うべきです。」

初心者がつまずく所、言い過ぎの所を、台本の行の番号つきで指摘してきました。 指摘と、直した後の台本を並べます。

ほかに、agy を使ったあとに Mac が熱くなった話も、「対処を再現できないなら削る」と言われて外しました。

採らなかった指摘もあります。 Codex は冒頭の「精度が上がる」という言い方も、実測が無いなら言い換えるよう求めていました。 動画の第一声は「Claude を ChatGPT の上司にすると、AI の答えの精度が上がります。」のまま残しています。 反対された点は全部聞いたうえで、採るかどうかは自分で決める。 コマンドに書いた扱い方のとおりです。

どれも、私と Claude だけでは気づかなかった所です。

実例2　/ask-all で題名を3つの AI に聞いた

題名は、/ask-all で3つの AI に同時に聞きました。 実際に投げた質問の全文です。

【背景】
日本の YouTube チャンネル（AI を活用したい人、SNS で発信している人向け。語り手は IT とビジネスの経験27年以上の経営者）で、8分前後の解説動画の題名を決めます。
中身：語り手が実際に使っている Claude Code の自作コマンド（/ask-codex で ChatGPT の Codex に Claude の答えへ反対意見を出させる。同じ形で Gemini・Grok に聞くコマンドと、3つの AI に同時に聞いて一致と対立をまとめる /ask-all）の作り方と実演。動画の冒頭では、この動画の台本そのものを Codex に見せて「いまの完全版には反対です」と返ってきた実例を見せる。
直前に出した同じ題材のショートの題名は「Claude を ChatGPT の上司にすると、AI の答えの精度が上がる」。

【候補】
A「Claude を ChatGPT の上司にする　AI に反対意見を出させるコマンドの作り方」
B「AI の答え、別の AI にダメ出しさせてますか？　Claude Code の自作コマンド4つ」
C「この台本、ChatGPT に『反対です』と言われました　Claude を上司にする使い方」

【聞きたい点】
1. 検索とおすすめの両方で、最もクリックされそうなのはどれか。1つ選び、理由を述べる
2. 各候補の弱点
3. 3つより良い題名があれば1つ出す
4. 全員が見落としている論点があれば指摘してください

忖度は不要です。明確にどれが良いか述べてください。結論を先に書くこと。日本語・800字以内。

ところが、答えが返ってきたのは Codex だけでした。 残りの2つは、利用枠の上限で止まりました。

Codex の答えの要点です。

• 選ぶならB。「別のAIにダメ出し」で用途と意外性が伝わり、「Claude Code」「自作コマンド」で検索意図も拾える
• Aの弱点：「上司」が指示役なのか評価役なのか曖昧
• Bの弱点：「させてますか？」が少し説教調。「4つ」は本数の説明にすぎない。検索語が後半にある
• Cの弱点：初見の人は「あなたの台本」にまだ関心がない。コマンド作成動画だと伝わりにくい

そして出してきた改善案が、「Claude Codeの答えにChatGPTがダメ出し｜自作コマンドの作り方」です。 これを、そのまま動画の題名にしました。

最後の「全員が見落としている論点」には、こう返ってきました。

「見落とされがちなのは、反対意見が出ることと、精度が上がることは別という点です。反対を求めれば不要な批判も出ます。「反対です」の後に、何を採用し、台本がどう良くなったかまで示すことが説得力になります。」

これも、その通りです。 だから動画でも、この記事でも、直した所まで全部お見せしています。

同じ形の3つのコマンド

同じ考え方で、あと3つ作っています。

ファイルの書き方は同じですが、それぞれの AI を入れて、ログインする手間は別にかかります。 agy と grok の入れ方は、それぞれの公式の手順に従ってください。

ask-agy.md の全文

---
description: agy（別LLM）にCLI経由で意見を聞く。設計・戦略・コードレビューのセカンドオピニオン用
argument-hint: "<聞きたいこと> 省略時は直近の議論について意見を求める"
allowed-tools: Bash(agy:*), Bash(cat:*), Bash(mkdir:*), Bash(sleep:*), Bash(pgrep:*), Bash(wc:*), Bash(nohup:*), Bash(sh:*), Bash(rm:*), Write, Read
---

# Ask agy

別のLLMである `agy` にCLI経由で質問し、セカンドオピニオンを得る。自分（Claude）の判断が正しいか検証したいとき、設計・戦略の妥当性を第三者に確認したいときに使う。

## 質問内容の決定

- 引数 `$ARGUMENTS` が**ある**場合: それを質問の主旨とする。ただしそのまま投げず、**agy が単体で理解できる自己完結したプロンプトに書き起こす**こと。agy はこの会話の文脈を一切持っていないため、前提・背景・現在の状況を必ず補って書く。
- 引数が**無い**場合: 直近の議論の論点を自分で要約し、それについて意見を求めるプロンプトを組み立てる。

## プロンプトの書き方

セカンドオピニオンの価値は「忖度しないこと」にあるので、必ず次を含める。

- 前提となる背景（agy は文脈ゼロである前提で書く）
- 現在検討している案、または自分が出した結論
- 判断してほしい具体的な論点（箇条書きで3〜5点）
- 「忖度は不要。賛成できない点は明確に反対してください」という指示
- 「結論を先に書くこと」という指示
- 出力言語（原則 日本語）と字数上限（原則 2000字以内）

ファイルの内容をレビューさせる場合は、**絶対パス**をプロンプト内に書けばよい（agy はファイルを読める）。

## 実行手順

1. スクラッチパッドにプロンプトをファイルとして書き出す。長文をシェル引数に直接埋めるとクォート事故が起きるため、**必ずファイル渡し**にする。

    D="${SCRATCHPAD:-/tmp}"; mkdir -p "$D"
    # プロンプトは Write ツールで "$D/ask_agy_prompt.txt" に書き出す

2. バックグラウンドで実行する。応答まで30〜120秒かかるため、フォアグラウンドで待つとタイムアウトしやすい。

    nohup sh -c "agy -p \"\$(cat '$D/ask_agy_prompt.txt')\" > '$D/ask_agy_out.txt' 2>&1" >/dev/null 2>&1 &

3. 完了までポーリングする。

    for i in $(seq 1 10); do
      sleep 15
      pgrep -f "agy -p" >/dev/null || break
    done

4. 結果を読んで**ユーザーに要約して伝える**。原文をそのまま貼り付けない。特に次を明示する。
   - agy が自分の結論に**反対した点**（ここが最も価値がある。省略しない）
   - 自分が**見落としていた論点**
   - 自分の判断を**変えるべきかどうか**の自分なりの結論

## 注意

- agy の意見は参考であって決定ではない。反対されたら鵜呑みにせず、根拠が妥当かを自分で検証してから採否を決める。ただし**自分に都合の悪い指摘を握り潰さない**こと。反対意見は必ずユーザーに伝える。
- 重要な判断でレビューを取った場合は、原文をプロジェクトのドキュメント配下（プロジェクトのフォルダ等）に `第三者レビュー_agy_<YYYYMMDD>.md` として保存する。

ask-grok.md の全文

---
description: grok（別LLM）にCLI経由で意見を聞く。設計・戦略・コードレビューのセカンドオピニオン用
argument-hint: "<聞きたいこと> 省略時は直近の議論について意見を求める"
allowed-tools: Bash(grok:*), Bash(cat:*), Bash(mkdir:*), Bash(sleep:*), Bash(pgrep:*), Bash(wc:*), Bash(nohup:*), Bash(sh:*), Bash(rm:*), Write, Read
---

# Ask grok

別のLLMである `grok` にCLI経由で質問し、セカンドオピニオンを得る。自分（Claude）の判断が正しいか検証したいとき、設計・戦略の妥当性を第三者に確認したいときに使う。

## 質問内容の決定

- 引数 `$ARGUMENTS` が**ある**場合: それを質問の主旨とする。ただしそのまま投げず、**grok が単体で理解できる自己完結したプロンプトに書き起こす**こと。grok はこの会話の文脈を一切持っていないため、前提・背景・現在の状況を必ず補って書く。
- 引数が**無い**場合: 直近の議論の論点を自分で要約し、それについて意見を求めるプロンプトを組み立てる。

## プロンプトの書き方

セカンドオピニオンの価値は「忖度しないこと」にあるので、必ず次を含める。

- 前提となる背景（grok は文脈ゼロである前提で書く）
- 現在検討している案、または自分が出した結論
- 判断してほしい具体的な論点（箇条書きで3〜5点）
- 「忖度は不要。賛成できない点は明確に反対してください」という指示
- 「結論を先に書くこと」という指示
- 出力言語（原則 日本語）と字数上限（原則 2000字以内）

ファイルの内容をレビューさせる場合は、**絶対パス**をプロンプト内に書けばよい（grok はファイルを読める）。

## 実行手順

1. スクラッチパッドにプロンプトをファイルとして書き出す。長文をシェル引数に直接埋めるとクォート事故が起きるため、**必ずファイル渡し**にする。

    D="${SCRATCHPAD:-/tmp}"; mkdir -p "$D"
    # プロンプトは Write ツールで "$D/ask_grok_prompt.txt" に書き出す

2. バックグラウンドで実行する。3者の中で最も時間がかかる傾向があり、90〜150秒みておく。`-p` が単発実行フラグ（`--single` のエイリアス）。

    nohup sh -c "grok -p \"\$(cat '$D/ask_grok_prompt.txt')\" > '$D/ask_grok_out.txt' 2>&1" >/dev/null 2>&1 &

3. 完了までポーリングする。

    for i in $(seq 1 12); do
      sleep 15
      pgrep -f "grok -p" >/dev/null || break
    done

4. 結果を読んで**ユーザーに要約して伝える**。原文をそのまま貼り付けない。特に次を明示する。
   - grok が自分の結論に**反対した点**（ここが最も価値がある。省略しない）
   - 自分が**見落としていた論点**
   - 自分の判断を**変えるべきかどうか**の自分なりの結論

## 注意

- grok は表形式や条件分岐での回答を好み、「どの条件ならどちらが正しいか」という形の整理が得意。数値や上限を問う質問と相性が良い。
- grok の意見は参考であって決定ではない。反対されたら鵜呑みにせず、根拠が妥当かを自分で検証してから採否を決める。ただし**自分に都合の悪い指摘を握り潰さない**こと。反対意見は必ずユーザーに伝える。
- 重要な判断でレビューを取った場合は、原文をプロジェクトのドキュメント配下（プロジェクトのフォルダ等）に `第三者レビュー_grok_<YYYYMMDD>.md` として保存する。

3つに同時に聞く /ask-all

いちばん強いのが、/ask-all です。 3つの AI に、同じ質問を、同時に投げます。

ask-all.md の決まりは、こうです。

• 3つに投げる質問は、完全に同じにする。書き分けると比べる意味がなくなる
• 対立している立場は、全部並べる。自分の案だけ有利に書かない
• 質問の最後に「全員が見落としている論点があれば指摘してください」と入れる
• 3つは同時に起動する。順番に聞くと3倍待つ
• 答えを並べて貼らない。Claude が読んで、まとめてから伝える

まとめ方も決めてあります。

1. 全員一致した点 2. 自分の結論に反対された点（何人が反対したかも書く） 3. 意見が割れた点（まず自分の裁定を書く） 4. 全員が指摘した見落とし 5. それを受けて、判断をどう変えるか

ファイルの中には「3者が一致して反対したなら自分の判断はほぼ間違っている」と書いてあります。 動画では、上の Codex の指摘を受けて「判断を止めて、根拠を確かめ直します」と言い方を改めました。

ask-all.md の全文

---
description: agy・codex・grok の3つのLLM全員に同じ論点を投げて意見を集約する（壁打ち）
argument-hint: "<聞きたいこと> 省略時は直近の議論について3者の意見を求める"
allowed-tools: Bash(agy:*), Bash(grok:*), Bash(codex:*), Bash(cat:*), Bash(awk:*), Bash(sed:*), Bash(mkdir:*), Bash(sleep:*), Bash(pgrep:*), Bash(wc:*), Bash(nohup:*), Bash(sh:*), Bash(cp:*), Bash(rm:*), Write, Read
---

# Ask all（3者壁打ち）

`agy` / `codex` / `grok` の3つのLLMに**同一のプロンプト**を並列で投げ、意見を集約する。重要な設計判断・戦略判断で、自分（Claude）ひとりの結論を鵜呑みにさせたくないときに使う。

単独の `/ask-agy` `/ask-codex` `/ask-grok` との違いは、**3者の一致点と対立点が見える**こと。3者が一致して反対したなら自分の判断はほぼ間違っている。3者で割れたなら、それは本質的に判断が分かれる論点であり、ユーザーが決めるべき事項である。

## プロンプトの組み立て

**3者に投げるプロンプトは完全に同一にする。** 個別に書き分けると比較の意味が失われる。

引数 `$ARGUMENTS` があればそれを主旨とし、無ければ直近の議論の論点を要約する。いずれの場合も、3者は**この会話の文脈を一切持っていない**ため、プロンプトは自己完結させる。必ず次を含める。

- 前提となる背景（誰が・何をしようとしているか）
- 対立している立場を**すべて併記**する。自分の案だけ有利に書かない。他者の主張を要約する際は、その主張が最も強く見える形で書く（藁人形にしない）
- 判断してほしい論点を箇条書きで3〜5点
- 「忖度は不要。明確にどの立場が正しいか述べてください」
- 「全員が見落としている論点があれば指摘してください」（これが最も価値のある回答を引き出す）
- 「結論を先に書くこと」
- 日本語・1500〜2000字以内

論争の裁定を求める場合は、立場をA/B/Cのようにラベル付けして提示すると、回答が比較しやすくなる。

## 実行手順

1. 共通プロンプトを1ファイルに書き出す（Write ツールで `$D/debate.txt`）。

2. **3者を並列で起動する。** 直列に実行すると3倍待つことになる。

    D="${SCRATCHPAD:-/tmp}"; mkdir -p "$D"
    nohup sh -c "agy -p \"\$(cat '$D/debate.txt')\" > '$D/d_agy.txt' 2>&1" >/dev/null 2>&1 &
    nohup sh -c "grok -p \"\$(cat '$D/debate.txt')\" > '$D/d_grok.txt' 2>&1" >/dev/null 2>&1 &
    nohup sh -c "codex exec --skip-git-repo-check \"\$(cat '$D/debate.txt')\" > '$D/d_codex.txt' 2>&1" >/dev/null 2>&1 &

3. 全員の完了を待つ。最長で150秒程度みておく（grok が最も遅い傾向）。

    for i in $(seq 1 12); do
      sleep 15
      n=$(pgrep -f "agy -p|grok -p|codex exec" | wc -l | tr -d ' ')
      echo "[$i] 実行中=$n"
      [ "$n" = "0" ] && break
    done

4. 出力を読む。**codex だけは最終回答の抽出が必要**（作業ログが大量に混ざるため）。

    awk '/^codex$/{f=NR} {l[NR]=$0} END{for(i=f+1;i<=NR;i++) print l[i]}' "$D/d_codex.txt" \
      | sed '/^tokens used/,+1d' | awk 'NF||p{print;p=1}'

## 集約して報告する

3者の回答を並べて貼るのは禁止。**必ず自分で読んで集約する。** 報告には次を必ず含める。

1. **全員一致した点** … 3者が同じ結論なら、それはほぼ確定と扱ってよい
2. **自分の結論に反対された点** … 何人が反対したかを明示する。自分に不利でも省略しない
3. **3者で意見が割れた点** … どちらが正しいか自分の裁定を述べたうえで、ユーザーの判断が要るなら明示する
4. **全員が指摘した「見落としていた論点」** … 独立した3者が同じ見落としを指摘したなら、それが最重要
5. **これを踏まえて自分の判断をどう変えるか**

数値や上限を問うた場合は、3者の数字を並べて**収束点**を示す（例: agy 7〜10 / grok 5前後 / codex 3〜5 → 収束点は5前後）。

## 保存

重要な判断で壁打ちした場合は、3者の回答をプロジェクトのドキュメント配下（プロジェクトのフォルダ等）に保存する。

    第三者レビュー_agy_<YYYYMMDD>.md
    第三者レビュー_grok_<YYYYMMDD>.md
    第三者レビュー_codex_<YYYYMMDD>.md

そのうえで、集約結果と自分の最終判断を本体ドキュメントに反映する。**どの指摘を受けて何を変えたかを必ず記録する**こと。後から「なぜこの方針になったか」を辿れるようにするため。

## 注意

- 3者が一致して反対したときに、自分の案に固執しない。ただし根拠が弱い反対（単なる保守的な定説の反復など）であれば、その旨を述べて退けてよい。**多数決ではなく根拠で判断する。**
- 3者の意見が割れた論点は、ユーザーに丸投げせず**まず自分の裁定を示す**。そのうえでビジネス判断が必要な部分だけユーザーに委ねる。

使い分けと注意

使い分けは、ふだんは /ask-codex、お金や公開に関わる大きな判断は /ask-all です。

注意は2つあります。

1つ目は、それぞれの AI のプランの枠を使うことです。 実例2のように、枠が切れると答えが返りません。 大事な判断のために、枠を残しておきます。 何でもかんでも聞かないことです。

2つ目は、お客さんの個人情報を質問に入れないことです。 これは、どの AI でも同じです。

この記事で確かめていないこと

• Windows での入れ方。この記事で確かめたのは、macOS と Linux 向けの公式のインストーラーだけです
• API キーで動かした場合の動き。この記事の手順は、ChatGPT のアカウントでのログインを前提にしています
• /ask-all で3つ全部の答えがそろった例。この記事の実例は、Codex だけが答えた回です
• 反対意見で答えがどれだけ良くなるかの数字。測っていません。Codex 自身も「反対意見が出ることと、精度が上がることは別」と書いています

まとめ

作るのは Claude、ダメ出しはほかの AI。 上司と部下に分けるだけで、見落としが見つかります。

手順は3つです。

1. Codex CLI を入れて、ChatGPT のアカウントでログインする 2. ~/.claude/commands/ に ask-codex.md を保存する 3. Claude Code で /ask-codex と打つ

コマンドのファイルには、次の3つを書いておきます。

• Codex は会話を知らないので、背景を全部書いて渡す
• 「忖度は不要。賛成できない点は明確に反対してください」
• 反対された点は省かずに伝え、鵜呑みにもしない

出どころ

OpenAI 公式 Codex CLI https://learn.chatgpt.com/docs/codex/cli

OpenAI 公式 Codex のログイン方法 https://learn.chatgpt.com/docs/auth

OpenAI 公式 Codex の非対話モード（codex exec） https://learn.chatgpt.com/docs/non-interactive-mode

Anthropic 公式 Claude Code のスキルとカスタムコマンド https://code.claude.com/docs/en/slash-commands

内容は2026年11月3日の時点の公式ドキュメントに基づきます。