Codexは「別の目」がよかった。Claudeの下書きをレビューさせてみた
Claude Codeで仕事を進めていると、ひとつ困ることがあります。
Claudeの利用枠のほうが、先に尽きてしまうんです。
一方で、ChatGPTのアカウントで使えるCodexの枠は、わりと余っている。
だったら、Codexにも仕事を手伝ってもらえばいいんじゃないか。そう思って、Claude CodeからCodexに作業を頼む仕組みを作りました。
ところが、使ってみていちばんよかったのは、節約のほうではありませんでした。
この記事に書いてあること
Claude CodeからCodexに仕事を頼む仕組みを作った話
いちばんよかった「別の目」でのレビューと、実際に出た指摘
作ったスキルの説明書の中身と、設定するときの注意
今回は、Codexを「手足」として使うつもりが、「別の目」として役に立った話をお届けしたいと思います。
Claudeの枠が、先に尽きる
私は、中小企業でAI活用を進めている非エンジニアの担当者です。
ふだんの仕事は、ほとんどClaude Codeに手伝ってもらっています。調べもの、資料の下書き、データの集計。
それを、並行していくつも頼んでいます。
そうすると、どうしてもClaudeの利用枠が足りなくなってくるんですよね。
一方で、Codexも使える状態にはなっているのに、こちらはそこまで使い切っていない。
片方だけが先に尽きて、もう片方が余っている。これは、もったいないなと思っていました。
Codexを「手足」にするスキルを作った
そこで、Claude Codeのスキルとして、Codexに仕事を頼む仕組みを作りました。
考え方はシンプルです。
Claudeが司令塔、Codexが手足。
Claudeが仕事を分けて、Codexへの指示書を書く。Codexはその指示書どおりに、ファイルを読んだり、下書きを作ったりする。
返ってきた結果は、Claudeが確かめて仕上げます。
たくさん読む作業や、何度も試す作業をCodexに寄せれば、Claudeは指示と確認だけで済む。そういう狙いでした。
実際に、同じ指示書で、社内の問い合わせ記録の調査と、説明用スライドの作成をClaudeとCodexの両方にやらせて、比べてもみました。
いちばんよかったのは「別の目」だった
このスキルには、Codexにもうひとつ役を持たせています。
Claudeが作ったものを、Codexに見てもらう「別の目」の役です。
同じモデルだけで作って、同じモデルだけで確認すると、どうしても見方が固まります。違うモデルに見てもらえば、違うところに気づいてくれるかもしれない。
やってみて、私がいちばんよかったと感じたのは、これでした。
作る役とは別に、確認する役がいる。
人の仕事でも、作った本人がいちばん見落としに気づきにくいですよね。AIでも、同じことが言えそうです。
最初に見てもらったのは、スキル自体
最初のレビューの対象は、このスキルの手順書そのものでした。
使い始める前に、Claudeが書いた手順書をCodexに読んでもらったんです。
返ってきた指摘は、6件ありました。
たとえば、手順書の中の食い違い。
「レビューは1往復で終える」と決めたのに、Codexへの依頼文には「次の往復で、修正結果を再判定します」という説明が残っていました。
これだと、使う側は、ここで終わりなのか、もう一回確認に回すのかが分かりません。
もうひとつは、報告の見本の誤りです。
人の判断を待つ項目が残っているのに、残りの件数が「0件」になっていました。
どちらも、大きな構想への反論ではありません。でも、実際に使うと確実に迷うところです。
Claudeが自分で書いて、自分で読み返しているだけだと、こういう細かいズレはなかなか見つからないんですよね。
指摘は、全部は採らない
ただ、出てきた指摘を全部そのまま直したわけではありません。
6件のうち、採用が4件、一部採用が1件、見送りが1件でした。
見送ったのは、「4往復目、5往復目のときのルールがない」という指摘です。そこまで何度も往復することはめったにないので、規則を増やすほどではない、と判断しました。
Codexの指摘は、正しいことが多いんです。ただ、かなり真面目で、細かいところまでつついてきます。
全部反映すると、注意書きや例外だらけの、硬い手順書になってしまう。
指摘をもらったあと、目的に効くものを選ぶところまでがレビュー。
なので、このスキルでは、採るかどうかは必ずClaudeが決めるようにしました。見送るときは、理由を1行だけ残します。
あとから見たときに、見落としたのか、考えたうえで採らなかったのかが分かるようにするためです。
そして、レビューは基本1往復で終えます。じっくり見てほしいときだけ、往復を増やします。
使ってみて、分かったこと
「手足」のほうも、いくつか分かったことがあります。
まず、Codexは時間がかかります。比較したときは、Claudeの中で別の作業担当に頼むより、Codexのほうが遅くなりました。
急ぐ仕事や、待っている間に自分がやることがない仕事は、Codexに回さないほうがいいかもしれません。
それから、同じ指示書を渡しても、同じ答えが返るわけではありませんでした。問い合わせ記録の調査では、拾った件数やテーマの分け方に違いが出ています。
どちらが正しいというより、何を数えたのかが違ったんです。
Claudeの節約がどれくらいになったかは、まだ目安でしか見ていません。Codex側でもトークンは使っているので、全体の費用が減ったという話でもないです。
このあたりは、使いながら記録して、見直していくつもりです。
作ったスキルの中身
同じようにClaude CodeとCodexを両方使っている方向けに、どう設計したかも書いておきます。
作ったスキルの説明書（SKILL.md）から、全体の考え方が分かるところだけ抜き出しておきます。社内の情報は抜いてあります。
実際には、この下に、Codexを動かすためのスクリプトや、手足・別の目それぞれの細かい手順書がぶら下がっています。全部載せると重たくなるので、ここでは入口だけです。
# codex-bridge：Claude が司令塔、Codex は手足・別の目・外注先
Claude Code を主に使いながら、Codex（ユーザー本人の ChatGPT アカウント）の力を3つの形で借りるスキル。Codex に何かを任せるときは、このスキル1つで扱う。
| 目的 | Codex の役 | 何を任せるか | モード | 手順書 |
|---|---|---|---|---|
| **① トークン管理**（Claude の枠は先に尽きやすく、Codex の枠は余りやすい） | **手足** | 読む・書く・試す作業：大量のファイル・チャットなどの調査、集計、実装とテスト、資料（PowerPoint・Word・Excel）の下書き。Luna／Terra／Sol／Astra に振り分ける | `general`（書く作業は `--sandbox workspace-write`） | `references/delegate.md` |
| **② 別の視点**（同じモデルだけだと視点が固まる） | **別の目** | 資料・企画案・文章・設計・コードのレビュー、別案出し・反論役・検算 | `review`（別案出しは `general`） | `references/review.md` |
| **③ 外注**（Claude が苦手なもの） | **外注先** | 画像（イラスト・写真風・アイキャッチ・アイコン・バナー）、図解・インフォグラフィックの画像化 | `image` / `visual` | `references/image.md`・`references/visual.md` |
Codex は `codex exec`（画面を出さずに実行するモード）でバックグラウンド起動し、結果はファイルで受け取る。
## 司令塔（Claude）の原則
- **分解・指示・判断・仕上げは Claude**。Codex の出力は「材料」であって正解ではない。最終判断・反映・ユーザーへの報告は必ず Claude が行う。
- **採るかどうかは Claude が決める**。Codex の指摘や成果物は正しいことが多いが、真面目すぎて細部をつつく傾向がある。全部反映すると、注意書きや例外だらけの硬い成果物になり、元の狙い（簡潔さ・トーン・読みやすさ）が崩れる。目的に効くものだけ採り、細かすぎる指摘は理由を1行残して見送る（基準は `references/review.md` §5）。
- **足すより削る**。反映で分量が大きく増えるなら、採りすぎを疑う。
- **Claude のトークンを守る**。大きなファイルや長いログは Claude が開かず、Codex に読ませて要点だけ受け取る。検証は報告の根拠を突く安い方法で行う。使うには、次の準備が要ります。
Claude Codeが使えること
Codex（CLI）をPCに入れて、ChatGPTのアカウントでログインしておくこと
Node.jsが入っていること
準備ができたら、スキルのフォルダをClaude Codeのスキルの置き場所に入れて、最初に環境チェックを1回走らせる。私はこの順番で動かしています。
ただ、正直に書いておくと、そのまま動くとは限りません。
私の環境では、設定のところでかなり試行錯誤しました。
たとえばWindowsでは、Codexがファイルを読もうとして失敗し、何も読まないまま空のレビューを返してくることがありました。今は、レビューしてほしい本文を指示の中に直接貼って渡す形で避けています。
PCの環境や、使えるCodexのモデルによっても変わると思います。なので、説明書の考え方を参考に、自分の環境に合わせて作ってもらうのがいいと思います。
Claude Codeにこの説明書を見せて、「自分の環境用に作りたい」と相談するところから始めるのがおすすめです。
作業環境を分けた話は、AIを回すためにPCを2台に分けた記事にも書いています。
まとめ：あなたの下書きは、誰が確認していますか？
Claudeの枠を節約したくて、Codexを「手足」にする仕組みを作りました。
でも、いちばんよかったのは、Claudeが作ったものを、別の目でレビューしてくれることでした。
指摘をもらって、全部は採らずに、目的に効くものを選んで直す。そこまでをひと続きにすると、ちょうどいい確認の役になってくれます。
AIに作ってもらっているものがあれば、別のAIに一度見てもらうところから、試してみてはいかがでしょうか。
あとがき
この連載自体も、ClaudeとCodexで作っています。その話は、連載をAIで書いた記事に書きました。
そのときは、文章と画像を分担していましたが、今回は「作る」と「確かめる」を分けてみた形です。
長く使ってみての効果は、これからです。また何か分かったら書きます。
あわせて読みたい
同じように社内でAI活用を推進している方の話が、一番参考になります。
「うちはこうだった」があれば、ぜひコメントで教えてください。
このnoteでは、横浜の中小企業でAI活用を進めるなかで、
うまくいったことも、うまくいかなかったことも、そのまま書いています。
よかったらフォローして、次回も読んでいただけると嬉しいです。
