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活用を進めるなかで、
うまくいったことも、うまくいかなかったことも、そのまま書いています。

よかったらフォローして、次回も読んでいただけると嬉しいです。