CLAUDE.mdを削ったら、AIが指示を守りはじめた。──Claude CodeとCodex、9月の使い分けは「決める人・作るAI・見るAI」

2026年9月25日 08:31

Claude CodeとCodexを両方使い始めると、最初に迷うのは「どっちが賢いか」です。でも、ここ数か月の自分の失敗を振り返ると、成果を分けたのはモデル選びより、仕事の渡し方でした。方針と完了条件は人間が決める。実装と検証のループはエージェントに回させる。ルールファイルは短く強く。そして、作ったAIとは別の目でレビューする。2026年9月時点で私がClaude CodeとCodexをどう分担させているかを、公式の推奨と自分の失敗談の両方からお話しします。

なぜ今、Claude CodeとCodexの使い分けを書き直すのか

2026年9月は、AIエージェントの前提が短い間にいくつも動いた月でした。

一つ目はOpenAIの発表です。9月22日、GPT-6 SolとGPT-6 LunaがCodex・ChatGPT・APIで公開されました。発表によれば、Solは日常の複雑なコーディングやエージェント作業向け、Lunaはさらに安く速い大量処理向けで、最上位にはGPT-6 Astraが控えます。API価格はGPT-5.6のプロモ価格と比べて50%引き下げとされています。

二つ目は退役の予定です。GPT-5.5は10月14日にChatGPTとCodexから退役します（APIは対象外）。ChatGPTのアカウントでログインしてCodexを使っている場合は、Sol系への切り替えが案内されています。「いつもの設定のまま」動かしている方は、今のうちに確認しておくと安心です。

三つ目がAnthropicの研究「How Claude Code is used in practice」です。2025年10月から2026年4月までの約40万セッション、約23.5万人の利用を分析したもので、計画に関わる意思決定の約70%は人が、実行に関わる意思決定の約80%はClaudeが担っていました。検証済みの成功率は、初心者と判定された人で約15%、中級〜熟練者で約28〜33%。つまずいたセッションから立て直して成功した割合は、約4%から約15%まで開きます。途中で投げ出してしまう割合も、初心者は約19%、それ以外は約5〜7%でした。

研究が示した差は、才能やモデルの差というより、計画を立てる、検証する、途中で軌道修正する、という習慣の差でした。モデルが入れ替わる月だからこそ、モデルに左右されない「渡し方」を書き直しておきたい。これが本記事の動機です。

この記事では、柱を3本に絞ります。一つ目は、方針と完了条件は人間が持ち、実装と検証のループはエージェントに回させること。二つ目は、CLAUDE.mdやAGENTS.mdといったルールファイルを短く強く保つこと。三つ目は、作る係と見る係を分けること。前半で私自身の失敗と立て直しを、後半で公式の推奨とすぐ使える依頼文を、合わせて20本のコードブロックでお渡しします。

「いい感じに直して」で夜が溶けていた頃

正直に書きます。Claude Codeを使い始めた頃の私は、典型的な丸投げ型でした。

社内の業務ツールを直したいとき、ターミナルに打ち込むのは「ここ、いい感じに直して」の一言。Claudeはすぐにファイルを読み、編集し、「修正しました」と返してくれます。ところが動かしてみると、別の箇所が壊れている。もう一度「こっちも直して」。今度はまた別の場所が変わる。気づくと同じセッションの中で何十往復もしていて、画面をさかのぼっても、最初に何を頼んだのかが分からない。そんな夜が何度もありました。

厄介なのは、毎回の返事がそれらしく見えることです。「修正しました」「動作を確認しました」と書かれていると、こちらも安心してしまう。実際に画面を開いて初めて、直っていないこと、あるいは別の場所が崩れていることに気づく。その確認をするのは、いつも私でした。AIが作業し、私が確かめ、また頼む。今思えば、私自身が検証ループの一部に組み込まれていたわけです。

当時の私は、うまくいかない原因をモデルの性能だと考えていました。もっと賢いモデルなら一発で直るはずだ、と。

でも振り返ると、何を直せば終わりなのかを私自身が決めていなかったし、終わったかどうかを確かめる手段も渡していなかったし、同じ会話に前の失敗の残骸が積み上がっていくのも放置していたので、AIにとってはゴールのないマラソンだったはずです。

依頼の中に「どうなったら完了か」が一行もない。テストのコマンドも、確認すべき画面も伝えていない。会話は長くなる一方で、最初の目的は何十もの修正依頼の下に沈んでいく。この三つがそろえば、どんなに優秀なエンジニアでも迷子になります。人間の部下に同じ頼み方をしていたら、私はとっくに信頼を失っていたと思います。

人に仕事を頼むなら、目的と期限と「何ができたら完了か」を伝えるのは当たり前のことです。ところがAIが相手になると、私はその当たり前をきれいに忘れていました。相手が機械だから、察してくれるだろう。賢いのだから、言わなくても分かるだろう。その甘えが、夜を溶かしていたのだと思います。

後から公式のベストプラクティスを読んで、少し笑ってしまいました。そこには、Claudeに仕事を任せるときは同僚に任せるつもりで、状況と完了条件を渡せ、と書いてあったからです。人に対してはできていたことを、AIに対してもやる。出発点は、拍子抜けするほど単純なところにありました。

ルールを11本から7本へ。削らずに「分けた」日

丸投げをやめようと決めた私が次にやったのは、ルールを書くことでした。CLAUDE.md（Claude Codeが毎回最初に読む、プロジェクトの取扱説明書のようなファイル）に、「こうしてほしい」「これはやめて」を足していく。失敗するたびに1行足す。さらに、CLAUDE.mdから常に読み込ませる別のルールファイルも、1本、また1本と増えていきました。

最初はよく効きました。ところが増え続けるうちに、今度は指示が効きにくくなってきたのです。書いてあるはずのことを守らない。大事な1行が、大量の説明の中に埋もれている。ルールを足すほど、ルールが届かなくなる感覚でした。

2026年9月16日、私は常時読み込んでいるルールファイルを11本から7本に減らしました。削除はしていません。長い説明や具体例は、その作業をするときだけ読み込まれる別ファイルへ分けました。

作業の中身は地味です。1本ずつ開いて、「この説明は毎回読ませる必要があるか」を問い直す。背景の経緯や例文は、必要な場面でだけ開く別冊に移す。常に頭に入れておくのは、守らなければ事故になる短いルールだけにする。

削除でなく分離にしたのには理由があります。長い説明や例文にも、それぞれ価値はあります。過去にどんな失敗があって、なぜそのルールができたのか。その経緯は、関連する作業をするときには役に立つ。問題は、関係のない作業のときにまで毎回読ませていたことでした。料理をする人に、毎朝、家じゅうの家電の取扱説明書を全部読ませていたようなものです。

残したのは、守られなければ事故になる種類のルールです。たとえば、削除や外部への送信の前には必ず確認を取る、といったもの。逆に、「こういう経緯でこう決めた」という説明や、良い例・悪い例の並びは、関係する作業のときだけ開く別ファイルに移しました。ルールの文そのものは短く残し、理由と例は必要なときに取りに行ける場所へ置く。この形に落ち着きました。

分けたあとは、「書いてあるのに守らない」と感じる場面が確かに減りました。守ってほしい1行が、説明の山に埋もれなくなったからだと思います。

この作業をしてみて気づいたのは、ルールを増やすのは簡単で、減らすのは難しい、ということです。1行足すときは、目の前の失敗が理由になる。でも1行消すときは、「これを消しても、もう同じ失敗はしないか」を自分で判断しなければならない。消すことには、書いた本人の覚悟が要ります。だから放っておくと、ルールは増える一方になります。

余談ですが、自分の会社の就業規則も、たぶん同じ病気にかかっています。

7枚の画像が全部落ちた日と、別の目で見る仕組み

もう一つの転機は、その少し前の9月7日です。この記事もそうですが、私はnote記事の図解画像をCodexで生成しています。その日も7枚まとめて作ろうとしたところ、7枚すべてが失敗しました。エラーは「新しいバージョンが必要」という趣旨のもの。調べると、Codex側の更新で既定のモデルが切り替わっていて、手元の環境がそれに追いついていなかったのです。

対処はシンプルで、実行時に使うモデル名を明示する運用に変えました。既定値に任せていると、提供側の都合で中身が入れ替わったとき、こちらは理由も分からないまま止まります。モデルは「おまかせ」にせず、名前で指定する。これが一つ目の教訓でした。

7枚が1枚ずつ落ちるのでなく、すべて同じ理由で一斉に落ちた、というのが印象的でした。自分の手元では何も変えていないのに、昨日まで動いていたものが今日は動かない。既定値とは、つまり自分以外の誰かが決めた値です。便利な反面、その誰かが値を変えれば、こちらの仕事も黙って変わります。

同じことはClaude Code側でも起きていました。サブエージェント（本体から切り出して、別の文脈で仕事をさせる小さなAI）に作業を任せるとき、モデルを指定し忘れると、本体と同じ高いモデルで動いてしまいます。反対に、コストを気にして1万字記事の執筆を安いモデルに回したら、品質がはっきり落ちたこともありました（2026年7月）。高すぎても、安すぎても失敗する。だから今は、役割ごとにモデルを明示しています。

今の体制はこうです。本体（司令塔）はClaude Codeの上位モデルで、設計・判断・レビューを受け持つ。実作業はサブエージェントに渡し、SonnetやHaikuが担当する。画像生成はCodex。この記事の図解も、Codexで作っています。

そして、いちばん効いたのが「書いた本人に自己採点させない」というルールです。同じAIが同じ文脈のまま「できました、問題ありません」と言っても、それを完了の証拠として扱わない、と決めました。完了報告も、ツールの「成功」表示ではなく、ファイルが本当にあるか、サイズはいくつか、テストの出力は何と言っているか、という別の経路で確かめます。

なぜ本人の採点を信じないのか。書いた本人は、自分が何を意図して書いたかを知っています。だからこそ、意図どおりに動いていない箇所を、意図のほうで補って読んでしまう。これは人間の書き手でもまったく同じで、自分の文章の誤字を自分では見つけにくいのと似ています。新しい文脈で見る別のAIは、書いたときの思い込みを持っていません。

作るAIと見るAIを分けてから、「終わったはずなのに終わっていなかった」が目に見えて減りました。そして、私が画面を開いて一つずつ確かめる時間も減りました。確かめるのをやめたのではなく、確かめる役をAIどうしの間に移し、私は最後の差分と仕様だけを見るようにした、という変化です。

この考え方は、コードに限らず使っています。たとえば記事の原稿も、書いたAIとは別の工程で、文字数や表記のルールを機械的に確かめてから私の手元に届くようにしています。書いた本人の「できました」ではなく、数えた結果を見る。仕事の種類が変わっても、作る係と見る係を分けるという骨組みは同じでした。

公式が最初に置く3つの制約

Anthropicの公式ベストプラクティスを読むと、細かい機能の説明より先に、いくつかの前提が書かれています。私なりに3つに整理すると、次のとおりです。

一つ目は、文脈（コンテキスト）が最重要の資源だということ。会話が長くなるほど、最初の指示は薄まります。別件に移るなら /clear で会話をリセットし、肥大したら /compact で要約する。脱線しそうになったら Esc で止めて軌道修正する。同じ問題で2回以上修正してもうまくいかないなら、/clear して学びを反映した良いプロンプトで出直す、というのが公式の推奨です。

二つ目は、検証手段を渡すこと。公式が最も効くと位置づける点で、Claudeは「できたように見える」ところで止まりがちです。テスト、ビルド、lint（コードの書き方チェック）、スクリーンショット比較など、合否を出せるチェックを渡せば、Claudeが自分でループを回します。判定の基準がないと、人間が目視のループになってしまいます。

止め方の強さは4段階あります。①同じ依頼の中で「実行して直せ」と言う。②/goal で完了条件を設定し、別の評価器に毎ターン再チェックさせる。③Stop hook（スクリプトが通るまでターンを終わらせない仕組み）を置く。公式によれば、連続8回ブロックするとClaude Codeが打ち切ります。④検証用サブエージェントに、新しい文脈で反論させる。今日すぐ使えるのは①で、無人で回すなら②③を検討します。

②の /goal に書く完了条件は、機械的に判定できる形にしておきます。無人で長く走らせるときに私が使う型です。

/goal 次の条件をすべて満たしたら完了とする。
- 【ここにテストコマンド】を実行し、失敗が0件である
- 【ここに型チェックのコマンド】がエラーなしで終わる
- 変更したファイルは【ここに対象フォルダ】の中だけである
- 最終報告に、実行したコマンドとその出力の末尾を貼っている
条件を満たしていない場合は、原因を調べて修正を続けること。
同じエラーで3回失敗したら作業を止め、仮説と試したことを報告すること。

最後の2行が大切で、止まる条件を書いておかないと、無人のまま同じ失敗を繰り返し続けることがあります。

三つ目は、探索→計画→実装→コミットの順番です。

Shift+TabでPlan Mode（コードを書かず、読むことと計画だけを行うモード）に切り替え、まず関係するファイルを読ませる。最初から計画モードで起動するなら claude --permission-mode plan です。計画が出たらCtrl+Gでエディタを開いて直し、Plan Modeを解除して実装とテスト、最後に説明付きでコミットします。ただし毎回やる必要はありません。公式の基準は「差分を一文で言えるなら計画は飛ばしてよい」。typo修正やログ追加まで計画させるのは過剰です。検証しやすい変更なら、先にテストを書くやり方も相性が良いとされています。

社内ツールの改修を頼むときの、私の依頼文の型を置いておきます。複数ファイルに触れそうなときに、Plan Modeでそのまま貼ってください。

目的: 【ここに改修の目的。例: 見積ツールに割引率の入力欄を追加する】
背景: 【ここに誰が困っているか・なぜ今やるか】
制約:
- 既存の計算ロジックと画面の構成は壊さない
- 新しいライブラリは追加しない
対象: 【ここに関係しそうなフォルダ】を先に読んでから計画すること
完了条件:
- 【ここに追加・更新するテスト】が通る
- 変更ファイルは必要な範囲だけにする
- 影響範囲とリスクを計画に書く
まだコードは書かないでください。計画だけを出してください。

計画を承認して実装に進むときは、検証を依頼文に組み込みます。

承認した計画どおりに実装してください。
1. 実装後、【ここにテストコマンド】で該当するテストだけ実行する
2. 失敗したら原因を調べて直し、再実行する
3. すべて通ってから報告する
守ること:
- 「直した」と書くのでなく、実行したコマンドと出力をそのまま見せる
- エラーを握りつぶす修正（例外の無視、テストの削除や緩和）はしない
- 根本原因が分からない場合は、推測で直さず仮説を報告して止まる

これで「直った？」と聞き続ける役を、人間が降りられます。権限の確認を毎回押し続けているなら、それは許可リストが足りていない合図です。/permissions で信頼できる操作を先に許可しておくと、確認の嵐から解放されます。

依頼文は「同僚に任せる」つもりで書く

公式ベストプラクティスには、曖昧な依頼を具体的な依頼に書き換えるBefore/Afterがいくつも並んでいます。共通しているのは、手順を逐一指示するのでなく、状況と完了条件を渡すこと。優秀な同僚に仕事を任せるときと同じ書き方です。

たとえば「テストを追加して」ではなく、どのファイルの、どんな場面のテストか、モックを使うかどうかまで書く。「カレンダーを追加して」ではなく、既存の似た部品を見本として指し、同じ作りで追加させる。ファイルは @ で指定し、画像は貼り、ログはパイプで渡す。探索の段階なら「このファイルで改善できる点は？」のような開いた質問も、公式はむしろ勧めています。

検証の渡し方も、Before/Afterで示されています。「入力チェックの関数を作って」なら、正しい例と誤った例を具体的に書き、実装後にテストを実行させる。「画面を良くして」なら、目標のデザイン画像を渡し、スクリーンショットを撮って差分を比べながら直させる。「ビルドが落ちる」なら、エラーをそのまま貼り、根本原因を直してビルドが通るところまで確認させる。どれも、合否を判定できる材料を先に渡している点が共通しています。

不具合の依頼で私がいちばん使うのは、症状と場所の見当を書き、直す前に「失敗するテスト」を先に書かせる型です。再現できないまま直すと、たまたま症状が消えただけで終わるからです。

不具合を直してください。
症状: 【ここに何をしたら何が起きるか。例: 締め日の翌日に集計すると前月分が0件になる】
期待する動き: 【ここに本来どうなるべきか】
場所の見当: 【ここに怪しいファイルや関数】の周辺
進め方:
1. まず、この症状を再現する失敗テストを書いて、失敗することを確認する
2. 根本原因を特定し、原因を1〜2行で説明する
3. 原因を直し、書いたテストと既存テストが通ることを確認する
症状だけを隠す修正（条件分岐での回避、例外の握りつぶし）はしないでください。

もう一つ、大きな機能に取りかかる前には、いきなり計画させるのでなく、Claudeに私へインタビューさせます。私の頭の中にしかない前提を、先に文章にしてもらうためです。

【ここに作りたい機能の概要を2〜3行で】を作りたいと考えています。
実装に入る前に、私にインタビューしてください。
- 質問は、仕様が決まらないと実装で迷う難所だけに絞る
- 一度に聞くのは3問まで。答えを踏まえて次の質問をする
- 聞き終えたら SPEC.md にまとめる
SPEC.md には次を必ず入れてください。
- 目的と利用者 / 画面や処理の流れ
- 今回やらないこと（範囲外）
- 最後に行う通しの確認（E2E検証）の手順と合格条件
SPEC.md ができたら、ここで止まってください。

SPEC.mdができたら、そのセッションは閉じ、新しいセッションで「SPEC.mdを読んで実装して」と頼みます。インタビューのやり取りで膨らんだ文脈を、実装に持ち込まないためです。

Claude Code：CLAUDE.mdは「消したら間違える行」だけ残す

CLAUDE.mdは毎回読まれる永続的な文脈です。公式は長すぎると本物の指示が無視されると注意していて、判定の基準は1行ごとに「この行を消したら、Claudeは間違えるか？」。答えが「いいえ」なら削ります。

入れるのは、コードを読んでも推測できないことだけです。正しい実行コマンド、チーム独自の「これは使う・これは使わない」、自動生成ファイルの手編集禁止や本番環境への接触禁止といった硬い制約、一度ハマった落とし穴。入れないのは、プログラミングの一般常識、ファイル一覧の説明、すぐ古くなる情報、守っていない理想論です。/init で下書きを作ってから削るのが最短で、たまにしか使わない手順はスキル（必要なときだけ読み込まれる手順書）へ逃がします。

強調のIMPORTANTは、どうしても守られない1行にだけ付けてください。全部を強調すると、何も目立たなくなります。/doctor に削れる箇所を提案させるのも手です。長い資料は本文に貼らず、@docs/〜の形で参照させます。チームで使うCLAUDE.mdはgitで管理し、変更履歴が残るようにしておきます。

チームで共有するリポジトリ直下のCLAUDE.mdは、たとえば次の形です。

# 【ここにプロジェクト名】
【ここに何のシステムかを1〜2行で。例: 営業チーム向けの案件管理ツール】

### Commands
- 起動: 【ここに起動コマンド】
- テスト（1ファイル）: 【ここに単体テストの実行コマンド】
- 型チェック / lint: 【ここにコマンド】

### Architecture
- 【ここに自動生成フォルダ】は手で編集しない
- 画面から直接データベースを触らない。取得は【ここに担当フォルダ】経由

### Rules
- IMPORTANT: 本番データベースと秘密情報のファイルには触れない
- main に直接 push しない。ブランチを切ってPRにする
- 依存を追加するときは先に理由を説明する

### Done means
- 触ったテストと型チェックが通り、その出力を見せている

### Gotchas
- 【ここに一度ハマった落とし穴】

これとは別に、自分だけの癖はホーム配下の ~/.claude/CLAUDE.md に書きます。全プロジェクトに効く短いルールだけにとどめます。

# 個人の既定ルール
- 報告は日本語で短く、結論から書く
- 仕様が曖昧なら、コードを書く前に質問する
- 複数ファイルに及ぶ変更は Plan Mode で計画してから実装する
- 既存の書き方に合わせ、ついでの全体整理はしない
- 削除・push・本番操作は実行前に確認を取る
- 完了報告には、実行したコマンドと出力を添える

リポジトリには共有したくないけれど、そのプロジェクトだけで使う個人設定は CLAUDE.local.md に書いて .gitignore に入れます。

モノレポ（複数のアプリを1つのリポジトリで管理する構成）なら、ルートには共通ルールだけを書き、各アプリの配下に個別のCLAUDE.mdを置く階層にします。フロントの作業中に、バックエンドの細かい決まりで文脈が埋まるのを防げます。

# ===== ルートの CLAUDE.md =====
# 【ここにリポジトリ名】
パッケージ管理は【ここにツール名】。各アプリの詳細は配下の CLAUDE.md を見ること。
共通コマンドはルートの設定ファイルにあるものを使う。
Git の運用ルールは @docs/【ここにGit運用の文書名】.md を参照。

# ===== apps/web/CLAUDE.md =====
# apps/web
ここは画面側のみ。API の契約は【ここに共有フォルダ】を変えない。
新しいエンドポイントを安易に増やさず、既存の取得経路を使う。
画面の確認手順は @docs/【ここに確認手順の文書名】.md を参照。

運用のコツは、同じ失敗を2回したら1行足し、もう言わなくても守るようになったら消すこと。足す側の話は以前の記事で詳しく書いたので、ここでは消す側を忘れないことだけを強調しておきます。

Codex：モデルを割り当て、AGENTS.mdで同じ土俵に乗せる

Codexは、CLI・IDE・デスクトップアプリ・クラウドにまたがって動くOpenAIのエージェントです。複数の依頼を投げておいて、あとで差分を受け取る使い方や、ブラウザやPCの画面を操作する仕事に強みがあります。9月のモデル更新で、仕事の性質に合わせた割り当ても組みやすくなりました。

発表内容と各モデルの性格から、向き不向きは次のように整理できます。Lunaは、lint修正、テスト追加、定型的なリファクタリングのように範囲が狭く量が多い仕事。Solは、複数ファイルにまたがる実装やデバッグ、長めのエージェント作業。Astraは、ブラウザ操作や複数アプリをまたぐ作業、調べものを含む成果物づくりのような判断の重い仕事です。逆に、Astraに小さな修正を連打させたり、Solに単純作業を任せたりするのはもったいない。量の多い単純作業ほど、Lunaに寄せるとコストの面でも無理がありません。なお、モデルの正式な表記は環境によって変わりうるので、/model の一覧に出る名前で指定してください。

Codexは作業の前に AGENTS.md を読みます。Claude CodeのCLAUDE.mdに当たるファイルで、個人用は ~/.codex/AGENTS.md、チーム用はリポジトリ直下、特定フォルダだけのルールはサブフォルダに置く階層です。/init で雛形を出し、実際に使っているコマンドに直すところから始めます。Claude CodeはAGENTS.mdも読み込めるので、共通部分はAGENTS.mdに寄せ、CLAUDE.mdから参照させると二重管理を避けられます。

# AGENTS.md
### 構成
- 【ここに主要フォルダと役割を3行以内で】
### コマンド
- テスト: 【ここにコマンド】 / lint: 【ここにコマンド】
### 規約
- 既存のパターンに合わせ、新しい抽象化を増やさない
- PRには変更理由と確認方法を書く
### やってはいけないこと
- 【ここに触れてはいけないフォルダやファイル】を編集しない
- 秘密情報を読まない・出力しない
### 完了の定義
- 該当テストとlintが通り、その出力を報告に含めている

# ---- ここから CLAUDE.md（共通化する場合）----
@AGENTS.md
### Claude Code だけのルール
- 【ここに慎重さが要る領域】を触るときは必ず Plan Mode で始める

Codexへの依頼は、目的・前提・制約・完了条件を分けて書くと通りがよくなります。複雑な仕事は /plan で計画から入り、仕様が曖昧なら「先に質問して仕様を固めて」と添えます。実装後は /review で、未コミットの差分を見させます。

Goal: 【ここに目的。例: 請求データの取り込みで、失敗時に再試行する】
Context: 【ここに読むべきファイル】と既存のテストを先に確認すること
Constraints:
- 公開している関数の引数と戻り値は変えない
- 新しい依存は追加しない
Done when:
- 【ここに追加するテスト】を追加し、該当テストが通る
- /review で回帰が指摘されない
まず計画を出してください。承認するまでファイルは編集しないでください。
仕様が曖昧な点があれば、計画の前に質問してください。

出てきた計画を読み、やる・やらないを決めてから承認する。この一手間で、預けたあとに想定外の差分が返ってくることを減らせます。

もう一つ、Codexはサンドボックス（作業できる範囲を区切る仕組み）と承認の設定が強めです。最初は workspace-write（作業フォルダ内の書き込みだけを許す設定）から始め、フル自動は自分が管理しているリポジトリの作業に限ります。出どころの分からないリポジトリで、権限を全開放しないでください。

使い心地の違いを一言で言うなら、Claude Codeは隣に座ってペアで進める相棒、Codexは依頼を預けて後で結果をレビューする相手、という感覚です。複数のチケットをまとめて投げて後から差分を受け取る、APIのない画面操作を任せる、といった使い方はCodexに向いています。どちらが上ということでなく、仕事の渡し方の違いとして使い分けています。

作る係と見る係を分ける

ここからが、私がいちばん効いたと感じている部分です。

実践のルーチンは5段です。①Claude Codeで読んで設計する（仕様の穴、影響範囲、リスク、テスト方針）。②人間が「やる・やらない」を決め、計画を短く固める。③実装を仕事の性質で振り分ける。大きく慎重さが要るものはClaude Code、明確で量が多いものはCodexとLuna、やや複雑なものはCodexとSol、画面確認や外部操作を含むものはCodexとAstra。④実装したのとは別のエージェントでレビューする。⑤人間は差分と仕様だけを見る。

同じモデルに作らせて、同じモデルに褒めさせるのは弱い。公式も、別セッションで書く係とレビューする係を分けるパターンを紹介しています。新しい文脈は、書いたコードに引きずられないからです。ただしレビュアーに「欠陥を探せ」とだけ言うと、健全なコードでも何かしら挙げてきます。正しさと要件に関わる指摘だけに絞らせ、それ以外は任意扱いにすると、過剰な手直しを防げます。

⑤の「人間は差分と仕様だけを見る」も、具体的に決めておくと楽になります。私が見るのは、変更されたファイルの一覧が計画と合っているか、完了条件に書いたテストの出力が付いているか、仕様として決めたことが守られているか、の3点です。書き方の好みやコメントの言い回しまでは追いません。そこはレビュー係の仕事で、私の仕事は「やると決めたことが、やると決めた範囲で終わったか」を確かめることです。

Claude Code側でレビュー係を固定するなら、サブエージェントの定義ファイルを置きます。ポイントは、書き込みの道具を渡さないこと。レビュー係に書き込み権限を渡すと「直しながらレビュー」になり、誰が何を変えたのか追えなくなります。

---
name: code-reviewer
description: 実装後の差分レビュー担当。正しさ・破壊的変更・テスト不足だけを指摘する。コード変更の後に使う。
tools: Read, Grep, Glob
model: sonnet
permissionMode: plan
---
あなたはレビュー専任です。コードは書かず、修正もしません。
指摘は重大度の高い順に並べ、各指摘に次の4点を書いてください。
- ファイルパスと該当箇所
- 何が問題か
- 根拠（要件・既存仕様・テスト結果のどれに反するか）
- 修正方針（1〜2行）
正しさと要件に関わらない好みの指摘は「任意」として末尾にまとめてください。

このファイルを .claude/agents/code-reviewer.md に置けば、本体から呼び出せます。claude --agent code-reviewer のように、セッション全体をこの役割で始めることもできます。

Claude CodeとCodexをまたぐときは、3段のリレーにします。3つを別々のウィンドウに貼る形で使えます。

【1. Claude Code（計画役）】
【ここに不具合の症状】の原因と修正方針を出してください。コードはまだ変えないでください。
影響するファイル、テスト方針、やってはいけない変更も書いてください。

【2. Codex（実装役・/model で Sol 系を選択）】
次の計画どおりに実装し、該当テストを通してから差分を出してください。
計画にない変更はしないでください。
【ここに1.の計画を貼る】

【3. Claude Code（別セッションのレビュー役）】
次の差分をレビューしてください。指摘は「過剰実装」「破壊的変更」「テスト不足」の3点だけに絞ってください。
【ここに2.の差分を貼る】

リレーの要は、各段が前の段の成果物だけを受け取ることです。計画役の長い調査ログを実装役に渡さない。実装役の試行錯誤をレビュー役に見せない。渡すのは計画と差分だけ。こうすると、それぞれが自分の仕事に集中でき、レビュー役も作り手の言い訳に引きずられません。

サブエージェントは、本体の文脈を守るために使う

サブエージェントの本命の価値は、作業の分担より、本体の文脈を汚さないことにあります。サブエージェントは別の文脈で仕事をし、要約だけを本体に返します。判断の基準は一つで、あとで参照しない検索結果やログ、ファイル全文が本体に流れ込みそうなら委譲します。

組み込みのサブエージェントには、読み取り専用で探索するExplore、Plan Mode中の調査を担うPlan、探索と編集を組み合わせるGeneral-purposeなどがあります。Exploreには、探索の深さ（quick・medium・very thorough）を指定できます。最近のバージョンではExploreが本体のモデルを引き継ぐので、安く回したいなら同じ名前のカスタムExploreをHaikuで定義して上書きする、という手もあります。

効く仕事は、コードベースの探索、バグ原因の当たりをつける調査、実装後のレビュー、セキュリティや書き方の並行チェック、テスト追加の下調べ。向かないのは、本体が編集中のファイルの細かい続き、会話にすでに載っている内容への質問、1ファイルの明らかな修正です。

調査係の定義はこうです。書き込みの道具を持たせず、安いモデルで回し、全文を返させないのがポイントです。

---
name: researcher
description: コードベースの調査専任。原因の当たりや影響範囲を調べて要約だけ返す。大きな調査の前に使う。
tools: Read, Grep, Glob, Bash
disallowedTools: Write, Edit
model: haiku
---
あなたは調査専任です。ファイルの編集はしません。
報告は次の順で、合計20行以内にまとめてください。
1. 結論（1〜3行）
2. 重要なファイルのパスと、その役割（各1行）
3. 本体が次にやるべきこと
読んだファイルの全文や探索の途中経過は返さないでください。
確信が持てない点は「未確認」と明記してください。

「20行以内」のように長さの上限を書いておくと、本体に戻ってくる情報が自然に絞られます。

実装係には、編集の道具を渡す代わりに、計画の範囲を越えないことを約束させます。

---
name: implementer
description: 承認済みの計画を実装する担当。計画の範囲だけを変更し、テスト結果を報告する。
tools: Read, Edit, Write, Bash, Grep, Glob
model: sonnet
---
あなたは実装担当です。渡された計画の範囲だけを変更してください。
計画にない改善や整理は、提案として報告に書くだけにとどめます。
実装後は【ここにテストコマンド】で該当テストを実行し、失敗があれば直してください。
完了時の報告:
- 変更したファイルの一覧
- 実行したテストのコマンドと出力の末尾
- 計画から外れた点があればその理由

定義ファイルは、そのリポジトリ専用なら .claude/agents/、全プロジェクトで使うなら ~/.claude/agents/ に置きます。新しくフォルダを作った直後は、Claude Codeの再起動が必要です。CLAUDE.mdには中身を書かず、「大きな調査はresearcherに任せる」「実装後は必ずcode-reviewerを通す」と、いつ使うかだけを書いておきます。

実務の型は、本体が方針を決め、サブエージェントが調べ、本体が判断し、別のサブエージェントがレビューする、という連鎖です。探索を頼むときと、連鎖させるときの依頼文をまとめておきます。

【探索だけを頼むとき】
Explore サブエージェントを使い、thoroughness は medium で調べてください。
調べること: 【ここに調べたいこと。例: 権限チェックがどこで行われているか】
返すのは結論と重要なファイルのパスだけ。まだコードは変えないでください。

【調査→実装→レビューを連鎖させるとき】
1. researcher で【ここに不具合】の原因を要約する
2. その要約だけを implementer に渡し、計画の範囲で実装させる
3. 実装後、差分だけを code-reviewer に渡してレビューさせる
各段は前の段の完了を待ってから始めてください。

連鎖では「前の段を待つ」と明記するのが肝心です。書かないと、調査が終わる前に実装が走り出すことがあります。

失敗しやすいのは、サブエージェントを増やしすぎて、その説明文だけで本体の文脈を食ってしまうこと。レビュー係に書き込みを渡して「直しながらレビュー」になること。調査結果の全文を本体に戻させること。どれも、本体を薄く保つという目的に反しています。

並列とAgent Teamsは、依存のない仕事だけに

並列化にも守るべき線があります。同時に投げてよいのは、依存のない仕事だけ。かかる時間はいちばん遅い1本で決まる一方、トークンは本数分かかります。3本並べれば、ほぼ3倍です。Aの結論がBの入力になるもの、同じファイルを複数が編集するもの、反論しながら方針を決めるものは直列にします。

並列してよいのは、別モジュールの調査、互いに独立したレビュー、依存のないファイル群の機械的な修正。依頼するときは「並列でやって」と明示し、独立したタスクと、返してほしい形式をセットで渡します。

次の3つを、別々のサブエージェントで並列に調べてください。互いの結果を待つ必要はありません。
- 【ここに領域1。例: 認証とセッション更新の流れ】
- 【ここに領域2。例: 請求テーブルと移行スクリプト】
- 【ここに領域3。例: 外部公開している窓口と利用制限】
条件:
- 各サブエージェントは読み取り専用
- 返すのは「結論 / 重要ファイル / リスク」の3項目だけ
- ファイルの全文引用や探索ログは本体に戻さない
3つそろったら、本体は3つの間の矛盾点だけを要約してください。

レビューも観点ごとに並列にできます。その間、テストはバックグラウンドのサブエージェントで回し、本体は別の作業を続けます。

次の2つを同時に進めてください。
【並列レビュー】差分を3つの観点で、別々のサブエージェントにレビューさせる
- style: 命名と既存パターンからの逸脱
- security: 認証漏れ、秘密情報、危険なコマンド
- test-coverage: 足りないテスト
各担当は実装しない。指摘は正しさと要件に関わるものだけ、重大度順で。
重複した指摘は本体がまとめる。
【テスト】【ここにテストコマンド】をバックグラウンドのサブエージェントで実行し、
失敗したテスト名とエラーの要点だけを報告させる。
その間、本体は【ここに並行して進める作業】を続けてください。

編集を並列にするなら、git worktree（同じリポジトリを別フォルダに展開して作業場所を分ける仕組み）で隔離します。サブエージェントの定義に isolation: worktree と書いて、隔離を自動にすることもできます。機械的な並列はHaikuで、判断が要る1本だけ上位モデルで。結果を長く戻させると本体が太るので、結論・パス・リスクだけを返させます。

もう一つ、議論しながら方針を決めたい仕事にはAgent Teamsという選択肢があります。複数の独立したClaude Codeセッションを、リードと同僚のチームとして動かす仕組みです。サブエージェントが「本体が投げて、要約が戻ってくる」星形の関係なのに対し、Agent Teamsはメンバーが共有のタスクリストとメールボックスで直接やり取りし、互いの発見を共有して反論し合います。複数の視点での調査、競合する仮説を並べたデバッグ、観点の違うレビューなどに向きます。

ただし、これは実験機能で既定はオフです。有効にするには環境変数の設定が必要で、コストは人数分かかります。メンバーはworktreeで自動的に隔離されないので、誰がどのディレクトリを持つかを人が先に分けておく必要があります。今の完成度なら、日常の実装ループの主役にはせず、方針を決めるための議論に絞って使うのが現実的です。使うときは、最初に役割と担当範囲と統合の仕方を書いてから始めます。

# settings.json に追加（実験機能を有効にする）
"env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" }

# 起動時の依頼文
エージェントチームを作り、【ここに決めたいこと】について方針案を出してください。
メンバーは3人です。
- UX担当: 利用者の操作の流れから検討する。担当は【ここにフォルダA】
- 設計担当: 構造と保守性から検討する。担当は【ここにフォルダB】
- 反対担当: あえて反対の立場から、他の2人の案の弱点を指摘する
ルール: 同じファイルを複数人で編集しない。担当外のフォルダは読むだけ。
議論は自由にしてよい。最後にリードが3人の意見を統合し、推奨案を1つにまとめること。

最後に、ターミナルでよく使う小技をまとめておきます。

# 変更したファイルだけを、セキュリティの観点でレビューさせる
git diff main --name-only | claude -p "変更ファイルのセキュリティ上の問題を重大度順に挙げて"

# ログの末尾から異常だけを抜き出す
tail -200 【ここにログファイル名】 | claude -p "エラーと異常な挙動だけを抽出し、原因の仮説を3つ挙げて"

# 最初から Plan Mode で起動する（読む・計画するだけ）
claude --permission-mode plan

# Codex をモデル名を明示して起動する（既定に任せない）
codex --model 【ここに /model の一覧に出るモデル名】

どれもコピーしてすぐ使えるので、まずは差分レビューの1行目から、日々の作業に混ぜてみてください。

丸投げの巨大セッションから、分けて検証する運用へ

以前の私の作業は、1つの巨大なセッションで始まり、そのまま終わっていました。「いい感じに」で頼み、動かし、壊れ、また頼む。ルールファイルは膨らみ続け、モデルは既定のまま。完了の判断は、AIの「できました」と私の目視だけでした。

今は違います。依頼は目的と完了条件から書き始め、複雑なものは計画だけを先に出させる。常に読ませるルールは絞り、長い説明はその作業のときだけ読ませる。モデルは役割ごとに名前で指定する。調査はサブエージェントに任せて要約だけを受け取り、作ったAIとは別の目でレビューし、完了はファイルやテスト出力で確かめる。

変わったのは……いや、正確に言うと、AIのほうは大して変わっていないんですよね。変わったのは、私の渡し方と確かめ方でした。

Anthropicの研究が示した初心者と熟練者の差を、私は自分の中で追体験したのだと思います。1回の依頼でClaudeが取る行動の数は、研究によれば初心者で約5、熟練者で約12。任せる範囲が広がったのは、AIを信頼したからというより、確かめる仕組みを先に置いたからでした。

もう一つ変わったのは、私の頭の使い方です。以前は、AIの出力を一行ずつ追いかけることに時間を使っていました。今は、何をやるか、何をやらないか、どうなったら完了か、を考える時間のほうが長い。考える場所が、手元の差分から、仕事の入口と出口へ移ったのだと思います。

とはいえ、人間の出番がなくなったわけでもありません。微妙な仕様の判断、たとえば「この例外的な顧客の扱いをどうするか」のような問いは、今も私が決めています。生成された差分を読まずに取り込むこともしません。任せる範囲が広がった分、最後に見る数か所の重みは、むしろ増しました。

最初の1週間でやること、経営者として決めること

これから本格的に使う方、あるいは使っているのに手応えが薄い方は、次の1週間でここまでやってみてください。一度に全部でなく、1日に1〜2項目ずつで十分です。

順番にも意味があります。最初の2日でルールファイルを置いて削り、土台を整える。次の2日で、計画から入る習慣と、完了条件を書く習慣をつける。残りの日で、モデルを名前で指定し、作る係と見る係を分ける。土台がないまま並列やサブエージェントに手を出すと、散らかった指示が何倍にも増えるだけなので、この順を崩さないのがおすすめです。

- [ ] リポジトリ直下に短い CLAUDE.md と AGENTS.md を置いた
- [ ] テスト・lint・型チェックの「正しいコマンド」を両方に書いた
- [ ] CLAUDE.md の全行に「消したら間違えるか？」を問い、不要な行を削った
- [ ] 複数ファイルに及ぶ仕事は Plan Mode（Codex は /plan）から始めると決めた
- [ ] 依頼文に「完了条件」と「出力を見せること」を必ず入れた
- [ ] サブエージェントと Codex で、使うモデルを名前で指定した
- [ ] 実装用とレビュー用を worktree または別セッションに分けた
- [ ] レビュー係に書き込み権限を渡していないことを確認した

チームで取り組むなら、このリストを共有して、週の終わりに全員でチェックが埋まったかを見るだけでも効果があります。

経営者や事業責任者の方にお伝えしたいのは、エージェントに任せるほど、人間の仕事は「決めること」に寄っていくということです。何をやるか、何をやらないか、どうなったら完了か。ここを曖昧にしたまま高いモデルを契約しても、夜が溶けるだけです。逆にここさえ言葉にできれば、少人数のチームでも、実装と検証のループをAIに預けられます。

チームに導入するなら、ツール選定より先に「完了の定義」と「レビューの分担」を決めてください。完了の定義はCLAUDE.mdとAGENTS.mdの一番下に書き、レビューの分担は「作ったAIとは別のAIが見る。最後に人が差分と仕様を見る」と一文で決めておく。これだけで、メンバーごとのばらつきがかなり抑えられます。どのモデルを使うかは、来月また変わります。決め方は変わりません。

差分と仕様だけを見る朝へ

今の私の朝は、エージェントが出してきた差分と、それぞれの検証結果を眺めるところから始まります。テストの出力、生成されたファイルのサイズ、レビュー係の指摘。見るのは差分と仕様だけ。細かな書き方に口を出すことは、ほとんどなくなりました。

「いい感じに直して」と打ち込んでいた頃の私に、今の朝を見せたら驚くと思います。AIが急に賢くなったからというより、決める人、作るAI、見るAIの線を引き直したからです。

モデルは毎月のように入れ替わります。今月はSolとLunaが出て、来月にはGPT-5.5がChatGPTとCodexから退役します。そのたびに振り回されそうになりますが、方針と完了条件を人が決め、作るAIと見るAIを分け、ルールを短く保つ。この形さえ手元にあれば、新しいモデルは脅威というより、新しく加わる頼もしいメンバーです。

決めるのは人。作るのも、確かめるのもAI。その役割分担を一度組み立てれば、AIエージェントは少人数の会社にとって、いちばん心強い同僚になってくれるはずです。まずは今日、自分のCLAUDE.mdを開いて、1行だけ消してみてください。

AI活用のご相談はこちら

AIをどの業務から始めるべきか迷っている、営業や資料作成を効率化したい、AIエージェントを導入したい。そんな課題があれば、株式会社コミクスの問い合わせフォームからご相談ください。「その他」欄に「noteを見た」と、いま困っている業務を一つご記載いただくと、相談内容を具体的に共有できます。必要に応じて記事名も添えてください。

株式会社コミクスの問い合わせフォームを開く

▶ 30 問で自社の経営課題を診断する（無料・3 分）

あわせて読みたい

Claude CodeかCodexか。今週から、その質問は古くなりました。

https://note.com/comix_ceo162230/n/ndf1a632b8227

なぜあなたのClaude Codeは、2回目も同じミスをするのか？

https://note.com/comix_ceo162230/n/n9d8888b26a34

「便利」を入れる前に、AIに全権限を渡していませんか。──Claude Code／Codex、導入初日に決める3つの線引き

https://note.com/comix_ceo162230/n/n6981d56006f9

自己紹介

株式会社コミクス代表取締役の鈴木章裕です。営業の叩き上げで25年、会社を創業して18年、これまでのお取引は1,825社になりました。いまは「生成AI活用顧問」として、経営者の隣でAIの選び方から現場への定着までを伴走しています。自社でもClaude CodeとCodexを毎日使い、社長の仕事をどこまでAIに渡せるかを実験し続けています。フルマラソン完走71回、100kmウルトラマラソン完走17回。「続けること」がいちばんの武器だと思っています。

▶ 鈴木章裕の自己紹介ページはこちら

鈴木章裕

株式会社コミクス代表取締役