Claude × Codex を覚醒させる究極のエージェント設計 [最新版]

「もっと具体的に指示して」と言われても、その“具体的なところ”から手伝ってほしい。

作りたいものはあるのに、AIに頼むための下調べで手が止まる。これは少し割に合わない。

たとえば、案件を登録して、期限が近い順に並べられるアプリが欲しいとする。そこまでは言える。でも、データの保存方法や不具合の確かめ方まで聞かれると、調べることが急に増える。

調べるうちに、最初は付けたかった機能を「今回はなくてもいいか」と削っていく。作るのが難しそうだからというより、何かあったときに自分で面倒を見られる範囲に収めたくなるからだ。

本当は、細かい指示を全部用意してから頼みたいわけではない。こちらが見落としていることも拾ってほしい。「この二つはどちらにしますか」と判断できる形で聞いてくれて、決まったところから作業を進めてくれると助かる。

この記事で組むのは、そんな頼み方に近づけるための、Claude CodeとCodexの開発チームだ。

• Claude Code：依頼の窓口。必要な確認と作業の分担を整理する
• Codex：実装や検査を受け持つ

案件管理アプリなら、画面を作る作業とは別に、確かめる作業も用意する。空欄のまま登録したらどうなるか。再読み込みしても記録が残るか。不具合が直らないときは、試した修正と残っている症状をまとめて、別の担当へ引き継ぐ。

人間がやるのは、途中で必要な判断をすることと、最後に実際の操作を確かめることだ。そのために、仕様・変更内容・検証結果がきちんと手元に戻ってくる形を作る。接続方法から、仕事の渡し方、止める条件まで、順に組み立てていこう。

Claudeを開いたまま、Codexに仕事を振る

以前の回答を別のAIへ貼り直さなくても、Claude CodeからCodexへ依頼を渡す方法がある。OpenAIが公開している「Codex plugin for Claude Code」だ。

公式の説明では、次のような使い方に対応している。

• 現在の変更を検査するレビュー
• 調査や修正の委任
• 会話の引き継ぎ

この記事では、2026年10月16日に確認した公式文書をもとに、ローカル環境のClaude Codeから使う手順を扱う。

最初に揃えるもの

• Claude Codeを利用できる環境
• Git
• Node.js（公式の要件は18.18以降）
• Codexに認証できるChatGPTアカウント、またはOpenAIのAPIキー

プラグインは手元のCodexを呼び出す仕組みだ。接続したからといって、Claude側の利用枠でCodexまで動くわけではない。Codexの利用はCodex側の利用枠から消費される。

また、手元のファイルを扱う構成だが、AIの推論までパソコン内で完結するわけではない。最初は機密情報を含まない練習用フォルダを使おう。

プラグインを入れる

Claude Codeの入力欄で、次のコマンドを上から一つずつ実行する。通常のターミナルにまとめて貼るものではなく、Claude Code内でプラグインを追加する操作だ。

1/plugin marketplace add openai/codex-plugin-cc
2/plugin install codex@openai-codex
3/reload-plugins
4/codex:setup

最後の /codex:setup で、Codexの導入状況と認証状態を確認できる。Codexが見つからず、npmが使える環境なら導入の案内が出るので、内容を確認して進めればよい。

未認証なら、ターミナルで codex login を実行して案内に従う。

Windowsでは、Claudeを動かしている環境とCodexを入れた環境が別になっていないかも確認しよう。「見つからない」と表示されたからといって、何度も入れ直さないようにする。

まずはレビューから試す

最初に試すのは、コードを書き換えないレビューだ。Gitで管理している練習用プロジェクトに小さな変更を用意して、次を実行する。

1/codex:review --background

• 進行状況の確認：/codex:status
• 完了した結果の確認：/codex:result

複数の依頼を出しているときは、表示されたジョブIDも指定する。別の仕事の結果を取り違えないためだ。

Amazonの公開サンプルは、仕事の振り方が参考になる

役割分担の参考にするのは、Amazonのクラウド事業を担うAWSが公開している開発用サンプルだ。GitHubのaws-samplesに、次の二つがある。

• sample-codex-agent-team（Codex向け）
• sample-claude-code-agent-team（Claude Code向け）

Codex版には六つの役割がある。

役割

担当

fullstack-agent

仕様と進行の整理

coding-agent

実装

devops-agent

環境や配布

review-agent

検査

review-lite-agent

軽量版の検査

sa-agent

構成や運用の相談

登録画面をどう作るかと、大量の利用に耐えられるか、維持費はいくらかを考えるのは、別の仕事だ。機能の実装と運用の相談を分けておくと、担当へ渡す問いも具体的になる。

軽量レビューも、問題がありそうな変更を適当に済ませる担当ではない。文書の修正や機械的な置換など、範囲とリスクを絞れる仕事を、毎回大掛かりな検査にかけないための分け方だ。

仕事の受け渡し方も、二つのサンプルで違う。

• Claude Code版：共有の作業一覧から、各担当が仕事を取得する（実験的機能のエージェントチームを使い、追加の設定も必要）
• Codex版：担当ファイルを分けた作業計画に沿って進める

両者は別々のサンプルだ。二つを入れれば自動で一つのチームに合体する、という仕組みではない。

また、Codex版には、公開されていない接続先の設定を前提にしたモデル指定が含まれる。誰のアカウントでもそのまま動く設定ではないと、サンプル自身が明記している。会社の重要なプロジェクトへ丸ごとコピーするより、役割の分け方だけを取り入れ、自分が使える環境に合わせたほうがよい。

この記事では、Claude Codeを窓口にして、Codexへ限定した実装や検査を渡す小さな構成から始める。

なお、これは公開サンプルを参考にした独自の運用例だ。AWSがClaudeとCodexの統合を保証している製品でも、一連の動作を実測したレポートでもない。

「保存できる」の意味を、作る前に揃える

作りたいものを細かく説明できないときは、すぐに実装を始めない。まずClaudeに確認事項を整理してもらう。技術用語を全部知っている必要はなく、自分が答えられる問いに変えてもらえばよい。

個人で使う案件管理アプリを作りたいので、まず必要な仕様を整理し、判断が必要なことを一問ずつ聞いてください。技術的な選択肢は、利用者への影響とおすすめの理由を短く説明してください。私が承認するまで、実装は始めないでください。

たとえば保存について。同じブラウザで記録が残ればよいのか、スマホとパソコンで共有したいのか。この二つは必要な仕組みがまったく違う。黙ってどちらかを選ばせると、あとで作り直す原因になる。

今回の練習では、範囲をこう絞る。

• 対象：同じパソコンの同じブラウザで使い、再読み込み後も記録が残る
• 対象外：複数端末での同期、ログイン、外部公開、顧客の実データ

完成条件も「使いやすく」ではなく、操作した結果で書く。

• 案件を登録できる
• 期限順に並ぶ
• 対応状況を変更できる
• 空欄で登録すると、理由が表示される
• 再読み込み後も内容が残る

仕様書と作業依頼を、ファイルに残す

決めた内容は docs/spec.md に保存し、全員が参照する仕様書にする。ファイル名はこの記事で決めた例だ。作っただけでAI全員に自動で配られるわけではないので、依頼するたびに「これを読んで」と指定する。

決定した仕様と完成条件、今回作らない機能をdocs/spec.mdに保存してください。未決定事項は確定したように書かないでください。実装を止める必要があるものと、仮の設定で進められるものを分けてください。

続いて、実装担当へ渡す作業依頼を docs/tasks.md にまとめる。仕事の名前だけでは足りない。読む資料、触ってよいファイル、変更しない部分、確認方法、返してほしい結果まで入れる。

仕様を実装できる単位に分け、各作業の担当ファイル、先に終わっている必要がある作業、確認方法をdocs/tasks.mdに書いてください。画面と保存処理で共有する項目は先に決めてください。同じファイルを二つの担当が同時に編集する計画にはしないでください。

両方のAIに、同じ仕様書を見させる

継続的な案内は、Claude側は CLAUDE.md、Codex側は AGENTS.md に書ける。どちらも各社の公式文書で説明されている仕組みだ。ただし、一方のファイルが他方にも同じ意味で効くとは考えない。両方から同じ仕様書を参照させる。

二つの案内に書くのは、短くこれだけでよい。

• 仕様書の場所
• 依頼外の変更をしないこと

仕様そのものを両方に複製すると、片方だけ古い指示になりやすい。それを避けるためだ。

並列で任せるなら、先に作業場所を分ける

複数のAIが動いていると、それだけで作業が速そうに見える。けれど、同じファイルを別々の方針で書き換えていたら、最後に人間がほどく仕事が増えるだけだ。

最初の並列作業は、「画面を作る担当」と「仕様から必要なテストを考える担当」の組み合わせが扱いやすい。保存形式が固まっていない段階で画面と保存処理を別々に実装すると、つなぎ目の食い違いまで増えてしまう。

Git worktreeで作業フォルダを分ける

ここで使えるのがGit worktreeだ。Gitの公式機能で、同じプロジェクトに別々の作業用フォルダを用意し、それぞれで異なる変更を進められる。

作る前に、仕様と共通の土台がGitに記録（コミット）されていることを確認する。コミットしていない作りかけのファイルは、新しい作業場所へそのまま付いてくるとは限らない。ブランチ名と作成先のフォルダが未使用であることも確認しておく。

1git worktree add -b feature/ui ../case-app-ui
2git worktree add -b feature/storage ../case-app-storage
3git worktree list

注意点が三つある。

1. フォルダを作っただけでは、AIの作業場所は変わらない。 各フォルダを作業ディレクトリにして別々のセッションを開き、開始前に実際の場所と担当ブランチを確認させる。
2. プラグインは、呼び出し元と同じ作業環境を使う。 ClaudeとCodexを接続しただけで自動的に隔離されるわけではない。最初は「一つの場所では一人だけが編集する」形で十分だ。
3. worktreeで分かれるのは、主にファイルの作業場所だ。 同じデータベースや同じ起動ポートを使えば、別の衝突が起きる。検証用の保存先とポートも分けるか、起動を順番にする。

Codex内の同時作業数を絞る

Codexの中で専門担当（サブエージェント）を増やす場合は、同時に開く数を絞れる。サブエージェントとは、親のAIから限定した仕事を受け取る別の作業担当のことだ。現行の公式設定では、.codex/config.toml に次のように書く。

1[agents]
2enabled = true
3max_concurrent_threads_per_session = 2

• 同じ項目を重複して書かない
• 内容を確認して、信頼したプロジェクトでだけ使う（プロジェクトの設定は、信頼済みのプロジェクトでのみ読み込まれる）
• この上限は「主担当を除く、そのCodexセッション内の同時スレッド数」。Claude側や別セッションを含めた合計の上限ではない

AWSサンプルの14スレッドも、そのサンプルが選んだ値にすぎない。全員が14まで増やすべきという意味ではない。サンプルが使っている max_threads は、現行文書では互換用の別名として残っている項目だ。新しく書くなら、現行の項目名に揃えよう。

実装担当を、毎回ゼロから説明しない

Codexでは、.codex/agents フォルダにTOML形式のファイルを置くと、独自の担当を定義できる。今回は task-builder.toml を作り、実装担当に必要な条件だけを書く。

1name = "task-builder"
2description = "確定した仕様から、担当範囲だけを実装する"
3developer_instructions = """
4最初にdocs/spec.mdとdocs/tasks.mdを読む。
5依頼された担当範囲だけを実装し、仕様変更が必要なら止まって報告する。
6他の担当の変更を巻き戻さず、秘密情報を読まず、外部公開しない。
7変更ファイル、実行したテスト、その結果、未確認事項を返す。
8"""

モデル名は、ここではあえて固定しない。指定しなければ、親の設定を引き継ぐ。公開サンプルに書かれたモデルが自分の契約で使えるとは限らず、使えない名前を固定すると、役割の説明以前に起動で止まってしまうからだ。

ファイルを置いたら、新しいCodexセッションで担当が認識されているか確認し、小さな仕事を委任してみる。Claudeから頼むなら、Codex側でtask-builderを使うことまで指定する。

Codexへ、docs/tasks.mdの保存処理だけをtask-builderに委任するよう依頼してください。開始前に、担当が認識されていることと実際の作業フォルダを確認してください。利用できない場合は、別の方法へ黙って切り替えず報告してください。

なお、指示文に「変更しない」と書くことと、書き込み権限をなくすことは別物だ。公式文書でも、Codexの子担当は親の権限（サンドボックス設定など）を引き継ぐと説明されている。担当ファイルの中で権限を変えることはできない。役割名をreviewerにしただけで、安全な読み取り専用環境になるわけではない。

同じ修正が続いたら、担当を交代する

AIが修正のたびに「原因が分かりました」と言うのに、同じ操作でまた止まる。そんなときは、次の修正を急ぐより、何を変えて何が変わらなかったかを残したほうがよい。そのほうが別の担当へ渡しやすい。

公式プラグインには、Codexへ調査や修正を委任する rescue という入口がある。名前は「救援」だが、不具合対応に限らず、範囲を決めた仕事を渡すためにも使える。

調査だけなら「読み取り専用」と明示する

原因だけを調べてもらうなら、書き換えないことをはっきり書く。公式の内部手順では、rescueは読み取り専用を指定しない限り、書き込み可能な実行を選ぶ。調査と修正を曖昧にしないほうがよい。

1/codex:rescue --fresh 再読み込みすると登録内容が消える原因を、読み取り専用で調査してください。docs/spec.mdと現在のコードを照合し、再現手順、根拠のある原因候補、追加確認が必要なことを返してください。ファイルは変更しないでください。

--fresh は新しい依頼として始める指定、--resume は前回の続きとして再開する指定だ（どちらも付けないと、直前の依頼を続けるか聞かれることがある）。続きを頼むときは、何を許可するのかも書く。調査結果から修正に進むなら、対象範囲を決めて渡す。

1/codex:rescue --resume 原因の根拠を確認できた保存処理だけを、最小限の変更で修正してください。画面や仕様は変えないでください。修正前に失敗する確認方法と、修正後の結果を示してください。

会話ごとCodexへ移すなら transfer

• 仕事だけを渡す → rescue
• 会話を持ってCodex側で続ける → transfer

1/codex:transfer

公式の説明では、現在のClaude Codeの会話から、続きができるCodexのスレッドを作り、再開用のコマンドを表示する。古いCodexでは使えないので、「対応していない」と表示されたらCodexを更新する。

ただし、会話を引き継ぐことは、パソコンの状態を丸ごと移すことではない。未保存の変更、外部サービスの認証、実行中のアプリの状態まで同じになるとは考えない。再開先で、対象ファイルと作業状況を確認しよう。

「できました」のあとに、別のAIで確かめる

実装したAIがテストまでしてくれるのは助かる。けれど、仕様を読み違えたままテストを作っていたら、テストが通っても欲しかった動きにはならない。

そこで、検査担当には実装の説明ではなく、人間が確認した仕様と実際の変更を渡す。先に「完璧に直ったらしい」と評価を伝えず、何を満たしているかを自分で調べてもらう。

docs/spec.mdと実際の変更を独立して照合し、完成条件を満たさない箇所と、その根拠を調べてください。実装担当の自己評価を前提にしないでください。再現できた問題、可能性だけの懸念、確認できなかったことを分けてください。今は修正しないでください。

組み合わせは、実装した側と逆にする。

• Claudeが実装した → Codexの通常レビューを別の確認として挟む
• Codexが実装した → Claudeに検査を頼み、必要ならCodexの新しいレビューでも確認する

通常レビューと、前提を疑うレビュー

通常レビューは /codex:review で呼び出す。変更済みのブランチとmainを比べるなら、次のように指定する。

1/codex:review --base main

mainがないプロジェクトでは、実際の比較元のブランチ名を使う。レビュー中は、対象の変更を動かさない。

注意したいのは、通常レビューの後ろに「保存だけ見て」と自由文を付けられないことだ。公式仕様では、通常レビューに重点指示は渡せない。設計上の前提や特定のリスクを問い直したいときは、adversarial-review を使う。

1/codex:adversarial-review --background 保存失敗を成功と表示していないか、二つのタブから編集したときに記録が失われないか、現在の設計の前提を確認してください。

これは口調を厳しくする命令ではなく、選んだ方式や前提そのものを疑うレビューだ。どちらのレビューも指摘するための機能で、コードは直さない。修正は結果を確認してから、別の依頼として渡す。

各指摘に、該当する完成条件、利用者への影響、確認方法を付けて整理してください。仕様を変えないと解決しないものは勝手に直さず、選択肢とその違いを人間に戻してください。

レビューゲートは、最初は使わない

さらに自動化する手段として、公式プラグインには「レビューゲート」がある。Claudeが応答を終えようとするたびに、Codexのレビューを挟む仕組みだ。/codex:setup --enable-review-gate で有効にできる。

ただし公式は、ClaudeとCodexの間で長い修正ループが起きて、利用枠を急速に消費するおそれがあると警告している。

だから最初は手動でレビューし、どんな指摘が出るかを把握してから使う。目を離すときは有効にしない。止めるときは /codex:setup --disable-review-gate を実行し、進行中の依頼が残っていないかも確認する。

うまくいった頼み方を、次の仕事にも残す

毎回長い指示を貼り直すより、うまくいった手順を保存しておきたい。そこで使えるのがSkillsだ。特定の仕事の進め方をファイルにして、再利用する仕組みである。

Anthropicの公式文書では、プロジェクト内の .claude/skills に手順を置ける。ここでは team-brief というフォルダを作り、その中の SKILL.md に、作業を渡す前の確認手順を保存する。

1---
2name: team-brief
3description: 仕様から担当範囲と検証方法を整理する
4disable-model-invocation: true
5---
6docs/spec.mdとdocs/tasks.mdを読み、今回の変更だけを対象にしてください。
7担当範囲、変更禁止箇所、前提作業、完成条件、検証方法を整理してください。
8各担当に渡す依頼文を作り、未決定事項は人間への確認として残してください。
9この手順ではコード変更、外部公開、Codexの起動は行わないでください。

Claude Codeで次のように呼び出すと、仕様の確認と依頼文の準備に使える。

1/team-brief 期限順の並べ替えを追加したい

これはこの記事で作る独自コマンドで、最初から標準搭載されているものではない。

disable-model-invocation: true にしているのは、呼び出すタイミングを人間が選ぶためだ。Claudeが自分の判断でこの手順を始めることはなくなる。手順を書いただけで別のAIの起動や検査まで強制されるわけではないので、最初は「準備だけを再利用する」形で試そう。

大きな仕事には Dynamic workflows

さらに大きな仕事なら、Claude CodeにはDynamic workflowsがある。Anthropicが2026年5月に発表した、複数の担当をスクリプトで動かす機能だ。現行の公式文書では、有料プランやAPI利用などで提供されている。

• 通常の会話：その都度Claudeが次の仕事を選ぶ
• Dynamic workflows：分岐や結果の回収をスクリプトに持たせ、再実行できる形にする

たとえば、完成済みの複数画面について、保存の失敗、入力チェック、表示の崩れを別々に調べ、指摘を照合する仕事が考えられる。最初の小さなアプリから大量の担当を起動するのではない。同じ検査を広い範囲へ適用する段階で検討したい。

検証対象の画面を分けて調査し、各指摘を別の担当が確認するDynamic workflowを作ってください。まず対象と担当数、終了条件を提示してください。コードは変更せず、私の承認後に小さな範囲で実行してください。

使い方のポイントは三つ。

• Proプランでは、/config からDynamic workflowsを有効にする
• 実行中は /workflows で進行状況や使用量を確認でき、途中で止めることもできる
• /config で規模の目安（smallなど）を選べる。ただし公式はこれを厳密な上限ではなく「目安」と説明している。設定しただけで担当数が保証されるとは考えない

また、この機能が動かすのはClaude側の担当だ。Codexが自動的に一員になるわけではない。まずはClaude内の調査や検証に使い、Codexへの委任とは別の段階として考えよう。

案件管理アプリを、最後まで動かして確かめる

ここまでの部品を、一つのアプリ作りにつなげてみよう。以下は説明用の開発例だ。実際に完成させた体験談ではなく、読者が自分の環境で検証するための進め方として読んでほしい。

作るもの

• 登録する項目：案件名、期限、対応状況、メモ
• 対応状況：未着手／進行中／完了の三つ
• 案件名で検索できる
• 未完了の案件を期限順に確認できる

最初の依頼

Claudeに次のように渡す。既存の大切なプロジェクトではなく、練習用の新しいフォルダを対象にする。

練習用フォルダに個人向けの案件管理アプリを作りたいので、まず環境と必要な仕様を確認してください。案件名、期限、対応状況、メモの登録と編集、検索、期限順の並べ替え、再読み込み後の保存を対象とします。ログイン、同期、外部公開は含めないでください。

保存には、ブラウザ内に記録する localStorage を使う案が候補になる。別の端末への同期やバックアップの仕組みはないので、ブラウザのデータを消すと記録も消える。失って困る本番情報は入れない。

土台を作り、共有部分を決める

土台を作る担当は一人にする。アプリが起動し、何も登録していない画面が表示されるところまで確認する。そこで仕様と土台をGitに記録してから、必要な場合だけ作業場所を分ける。

• 画面担当へ渡すもの：表示する項目、どの操作で何を呼ぶか
• 保存担当へ渡すもの：記録の形、読み込み・追加・更新の方法、保存に失敗したときの扱い

どちらの担当にも、項目名を勝手に決めさせない。たとえば対応状況の項目を status と決めたなら、画面側も保存側もそれを使う。実装しやすいからと片方だけ state に変えるのではなく、共有部分の変更はClaudeへ戻して調整する。

Codexへの実装依頼

Codexへ頼むときは、書いてよい場所だけでなく、返してほしい証拠も指定する。

1/codex:rescue --fresh docs/spec.mdとdocs/tasks.mdを読み、割り当て済みの保存処理とそのテストだけを実装してください。変更ファイル、実行コマンド、テスト結果、未確認事項を返してください。仕様変更や他担当の編集が必要になったら、止まって報告してください。

この間、Claudeは同じファイルを横から修正しない。完成条件の確認や検査用データの準備に回り、結果が戻ってから次の仕事を決める。

検証用のデータを用意する

• 期限が昨日の「未着手」案件
• 期限が今日の「進行中」案件
• 期限が来週の「完了」案件
• 同じ期限の案件が複数
• 長い案件名

これだけ揃えると、並び順や画面の表示を具体的に確認できる。

細部のルールも仕様に残しておく。

• 並び順：同じ期限なら登録順にする
• 未入力：案件名と期限は必須。メモは空欄でも登録できる。不足している項目を画面に表示する
• 日付：いつ日付が切り替わる想定かを決める。日付だけを扱うつもりのアプリで、時刻や時差の扱いによって前日にずれてしまうと、見た目が整っていても仕事には使いにくい

ルールを先に書いておくのは、実装後に担当ごとに違う答えで検査しないためだ。

統合して、テストで確かめる

実装が揃ったら、Claudeに変更一覧とテスト結果を読ませ、統合する内容を確認する。worktreeを使った場合は、各担当の変更を一つの確認用ブランチに集める。個別の場所で通ったテストも、統合後にもう一度実行する。

画面の確認には、ブラウザ操作を自動化するPlaywrightを使える。Playwrightの現行の案内では、AIエージェントから操作するためのCLIとSkillsも紹介されていて、MCP接続だけが唯一の方法ではない。

ただし、「AIにブラウザを触らせる仕組み」と「同じ確認を何度でも繰り返せるテスト」は分けて用意する。今回はPlaywright Testで、登録から再読み込みまでを再実行できるようにしておく。

Playwright Testで、案件登録、空欄の拒否、検索、状態変更、期限順表示、再読み込み後の保存を確認するテストを作ってください。起動設定とテスト用データは分けてください。テストを通すために、アプリの動作や完成条件を都合よく変更しないでください。

Playwrightをまだ入れていない練習用プロジェクトなら、公式手順の次のコマンドで準備できる。すでに導入済みなら二重に設定せず、既存の起動方法とテスト設定を確認してから追加する。

1npm init playwright@latest

テスト用ブラウザが入っていることを確認し、アプリを起動する設定も用意してから、次で実行する。

1npx playwright test
2npx playwright show-report

大切なのは、テストが一件も見つからない状態や、全部スキップされた状態を「合格」として扱わないことだ。

失敗したら、原因を切り分ける。保存処理の不具合なのか、テスト側が存在しないボタン名を探しているのか。テストを削除して緑色にするのではなく、最初の仕様に照らして、直す対象を決める。

最後は、自分の目と手で確かめる

見た目は実画面で確認する。文字が隠れていないか。期限の近い案件を見つけやすいか。テストが通ったという報告だけで、この使い心地まで検査済みだとは考えない。

最後にClaudeから受け取るのは、長い作業日記ではなく、次の四つだ。

• 起動方法
• 確認済みの動作
• 残った制約
• 次に直す候補

そして自分でも一件登録し、再読み込みして、記録が残っていることを確かめる。ここまでできたら、今回の完成とする。

直し続けるAIを、どこで止めるか

チームに任せる範囲を広げるほど、終わり方も決めておきたい。同じ不具合を何度も直しているのか、別の問題を順番に片付けているのか。それが分からない状態では、追加の指示も出しにくい。

止める目安を決める

今回は、「同じ問題への修正は二回まで」を一つの目安にする。これは公式の推奨回数ではなく、進んでいないときに人へ判断を戻すための運用例だ。

同じ不具合への修正を二回行っても解消しない場合は、追加の変更を止めてください。試したこと、変わったこと、残っている症状、次に必要な判断を整理してください。別機能の修正へ広げないでください。

もちろん、指示文だけで確実に止まる保証はない。利用状況を確認し、不要なバックグラウンド依頼は /codex:cancel で止める。各担当が本当に止まったことまで確認しよう。

費用は、ClaudeとCodexで別々に見る

ChatGPT認証で使うCodexの利用枠と、APIキーで使うときの料金は別物だ。並列の担当がそれぞれ推論やツール操作を行えば、その分の使用量がかかる。

軽い文言修正まで、毎回二つのAIと大きなレビューに通す必要はない。

• 一人で終わる仕事
• 別の視点が欲しい仕事
• 独立して並べられる仕事

この三つを使い分けたほうが、どこに手間と利用枠を使うかを決めやすい。

古いモデル指定に注意する

古いモデル指定も、動かない原因になる。OpenAIの公式更新では、日本時間2026年10月15日午前4時に、ChatGPT認証のCodexでGPT-5.5の提供が終了した。APIキー認証は対象外だ。

以前作った設定や役割ファイルに古い指定が残っていたら、現在そのアカウントで使えるモデルに更新する。新しい名前に書き換えるだけでなく、選べるモデルと、そのモデルが受け付ける推論設定も確認しておこう。

権限とHookを確認する

Claude側で許可したことが、Codex側にも同じ制限で伝わるとは限らない。双方の実行権限を確認しよう。練習では本番の認証情報を渡さない。削除、外部公開、課金を伴う操作は、別途承認する対象にする。

公開サンプルに含まれるHookも、中身を確認してから使う。Hookは決まったタイミングで処理を自動実行する仕組みだ。便利な追加指示ではなく、実際に何を動かすのかを見る必要がある。

「速く作れたか」の測り方

速く作れたかを評価するときは、生成が終わるまでの時間だけを比べない。

• 自分が説明し直した回数
• 統合や修正に使った時間
• 完成条件に対して残った不具合

ここまで含めて、次の仕事でも同じ分担を使うかを決めよう。

まずは、毎週使う小さな道具から

非エンジニアにとって試しやすいのは、結果の正しさを自分で判断できる仕事だ。

• 問い合わせの対応管理
• 発注の納期確認
• いつも同じ並べ替えをしているCSVの整形

こうした、使う場面を自分で説明できるものから始めたい。

納期が近いものだけ先に見たい。対応済みを一覧から外したい。入力漏れがあれば知らせてほしい。普段の仕事で感じるこうした要望は、そのままAIへ渡す完成条件になる。

コードの書き方をすべて覚えてからでなくても、その条件をもとに小さな試作品を作り、実際に使って直すところから始められる。ただし、顧客情報を扱う仕組みや外部に公開するサービスは、試作品が動いたこととは別に、専門的な確認が必要だ。

最初のチームなら、ここからで十分だ。

1. Claudeに仕様を整理してもらう
2. Codexへ一つの作業を渡す
3. 戻ってきた結果を、別の視点で確認する

そこで役に立った依頼文と検証方法を残しておけば、次のアプリを作るとき、また全部を説明し直す必要はなくなる。

最後まで読んでくれてありがとうございます。

LINEオープンチャット「にくのAI爆速攻略」で、無料8点セットを配っています。

• Codex・Claude Code導入ガイド
• コピペで使える指示文
• 早見表
• ミニアプリ50本
• 画像プロンプト50本
• yomiyasuの入れ方
• タイトルジェネレーター
• X収益化までの流れと金額

受け取りはこちらから👇 https://x.gd/VtPmw