Codex・Claude Codeの使い分け｜比べるのをやめて、任せ方を決めた
CodexとClaude Codeのどちらがいいか。弊社も最初はそれを比べようとしました。
いまは比べていません。2つを役割で分けてほぼ毎日動かすうちに、決め手になったのは性能とは別のところだと分かったからです。
決め手は「そのAIが出したものを、誰が確かめるか」でした。これは能力の話ではありません。同じ仕事でも、成果物の形式が変わると確かめ方が変わります。
枠の配り方（残量が減ってきたときにどちらを使うか）は別の話なので、Codex・Claude Codeの利用制限に分けました。この記事は「何を任せるか」のほうです。
弊社の分担表
先に、いまの割り振りを出します。2026年8月2日に始めた体制で、この形になったのは8月21日からです。
| Claude Code | Codex | |
|---|---|---|
| 主な担当 | 記事・文章 | 管理・開発・検証 |
| 具体的に | 構成案、競合調査、執筆、リライト、文章品質 | 進行管理、納品ファイルの生成と実機確認、コーディング、根拠の独立レビュー |
| 成果物の形式 | Markdown | ファイル・スクリプト・記録 |
Claudeが出すのはテキストまで。それをクライアントへ渡すファイルの形にする工程は、Claudeから外しました。
たとえば記事なら、本文と見出しと出典の妥当性はClaudeが書き、Wordファイルに変換して実際のWordで開いて確認するところはCodexです。同じ記事という仕事でも、途中で担当が変わります。
表を見て、根拠の独立レビューがCodex側にあるのを不思議に思われたかもしれません。レビューの成果物はテキストなので、形式だけで切るならClaude側です。ここは形式ではなく、書いた人と確かめる人を分けるという別の理由で相手側へ渡しています。この2本立てが、弊社の線の引き方です。
なお自社サイトの記事は例外で、公開までを記事側が持っています。壊れても自分たちで直せて、相手に届く前に気づけるからです。線を引いたのは、直せない場所のほうでした。
この線を引くことになったのは、次の事故があったからです。
Wordファイルを2回壊して、担当を移しました
2026年8月21日に、Wordファイルの生成と編集をClaudeの担当から外しました。きっかけは、8月20日と21日に続けてWordファイルを壊したことです。
1回目は、そもそも検査を持っていませんでした。 既存のファイルを複製して中身を差し替える方式で作ったところ、コメント同士をつなぐ内部の識別子が6件、参照先を失っていました。あわせて、XMLの子要素の並び順の違反が64件。
LibreOfficeでは開けるので、そこでは検出できません。気づいたあとに、並び順を検査するスクリプトを新しく書きました。
2回目は、その新しい検査を通りました。 翌日、コメント欄の文言を整理するためにXMLを書き戻したところ、いちばん外側のタグに書かれている名前空間の宣言が、35個のうち31個消えました。新設した並び順の検査は通過し、LibreOfficeでも正常に開いて表示され、テキスト抽出も通ります。
それでも、実際のWordで開くと「破損しています」と出ました。
さらに厄介なことがありました。担当を移したあとにCodexが検査を拡張して調べ直すと、こちらが「Wordで確認済み」と思っていた控えのファイルまで、同じ症状を持っていたのです。壊れていない版を作り直すために、結局は文言のもとになるテキストから組み立て直しました。
どちらも社内の作業中に見つけて作り直したので、壊れたファイルが外へ出たことはありません。ただ、見つけられたのは最後に人が実物を開いたからで、機械の検査では素通りしていました。
問題は壊れたこと自体ではありません。検査を1本足しても、次の壊れ方には追いつかなかったことです。
ひとつ補足がいります。実際のWordを開いて修復ダイアログを見る手順は、弊社の設定ではCodex側にだけ通してあります。技術的にはどちらでも組めます。
ただ、両方に持たせると、壊れたときにどちらの確認が甘かったのか切り分けられません。確認の窓口を1つにしたうえで、その窓口を持つ側へ担当を寄せた、という順番です。
このルールに例外は作っていません。1文字だけ直す場合も、コメントを1行消すだけの場合も、Codexへ回します。弊社がそう決めたのは、例外を1つ作ると、次に同じ壊れ方をしたときに原因を切り分けられなくなるからです。
テキストなら安全、という話ではない
先回りしておきます。テキストも、書いた本人が読み返すだけでは足りません。自分が書いたものを自分で点検すると見落としが残るので、記事の本文も検証は書いたのとは別のセッションに回しています。
テキストとファイルの違いは、そこから先にあります。テキストは見落としても、あとから読み返せば直せます。ファイルは、開けない状態で相手に届いたら、もう直せません。
取り返しがつかない側から順に、確かめる担当を決めました。これが「成果物の形式で線を引く」の中身です。
得意分野で分けると、更新のたびに決め直しになる
「Codexの得意なこと」「Claude Codeの得意なこと」は、調べれば比較記事もベンチマークも出てきます。弊社はそれで分担を決めませんでした。
公開されている評価で測っているのは、その課題を解けるかどうかです。弊社が知りたいのは、自社の原稿を任せたときに何回書き直しになるか。しかもモデルは更新され、そのたびに順位が入れ替わります。
そこで、順位が入れ替わっても動かないものを基準にしました。成果物の形式と、確かめる担当が決まっているかどうかです。確認の手段は増えることがありますが、そのときは増えた側へ担当を移すだけで、決め方そのものは変えずに済みます。
弊社が見ている数字は、合格するまでのやり直し回数と、人が確認に使った時間です。モデルの使い分けも同じ基準で決めていて、安いモデルに替えて書き直しが増えるなら、その置き換えは損になります。
記事51では、この分担を「品質と権限で決めている」と一行で書きました。その中身が、いま書いた成果物の形式と確認の担当です。同じ線が他社に当てはまるとは限りません。扱う仕事の形が違えば、線を引く場所も変わります。
併用が成立する条件は3つでした
担当を分けても、2つを同時に動かすと別の壊れ方をします。しかも壊れ方の種類は同じでした。上書きも取り合いも、起きたことが画面に出ません。
正確に言うと、分けている単位は会社よりも細かいところにあります。書く担当と、確かめる担当です。弊社の場合はそれがたまたま2社にまたがっていますが、同じAIの別セッションでも同じ形は作れます。弊社が先に決めたのは3つです。
1. 書ける人を1人に固定する
同じファイルを2つが書けると、片方の変更をもう片方が上書きします。だから対象ごとに「書ける人」を1人だけ決め、相手の領域に手を入れたくなったら、直接直さずに依頼を1行書くことにしました。
2. 共有する記録は追記だけにする
履歴のファイルは両方が書きます。ここは追記のみにして、過去の行は編集しません。訂正が必要なときも、前の行を直さずに新しい行を足します。上書きを許すと、消えたことに誰も気づけません。
3. 着手前に「いま何を触るか」を宣言する
2026年8月12日に、同じサイトを2つのセッションが同時に触りかけました。片方が本番へ反映している最中に、もう片方が同じ作業に着手しかけたものです。相手は同じAIの、別のスレッドでした。この事故は、2つ契約していなくても起きます。
原因は2つありました。現在地を書いたファイルが古かったことと、先に書いてあった宣言の行を、着手する側が見ていなかったことです。それ以降は、着手前に作業対象と時間帯を履歴へ1行書き、読むときも、まとめのファイルは古いことがある前提で、本番の現物とこの宣言の行を先に見ています。
弊社がやっていない使い分け
記事の中身を残量で移すこと。 Claudeの枠が減ったからといって、本文をCodexへ移すことはしません。理由は利用制限の記事に書いたとおりです。
ただし記録の更新や下調べのように、どちらへ振っても仕上がりが変わらない仕事は、その日に余力のある側へ回しています。
2つのAIを互いに呼び出してつなぐこと。 片方からもう片方を呼ぶ構成は技術的にはできますが、弊社では組んでいません。どちらが何をしたかの記録が追いにくくなり、上の3つの約束が守れなくなるためです。
人が間に入って渡しています。必要になれば組む可能性はありますが、いまは記録が追えることを優先しています。
自分の現場で線を引くときの3つの質問
弊社の分け方をそのまま持ち帰っても、たぶん合いません。代わりに、線を引くときに使った質問を残します。
- その成果物は、何の形式で相手に渡るか。 テキストのまま渡るなら、確かめ方は読み返しで足ります。ファイルやデータとして渡るなら、そのファイルを開ける環境が要ります
- 壊れたとき、届く前に気づけるか。 気づけるなら、あとから直せます。気づけないなら、渡す前に実物を開く人を決めておきます
- その確認を、誰が持っているか。 手順を全員に配らず、1か所に寄せます。寄せた先が、その仕事の担当になります
3つ目が効いたのは、弊社の場合はWordでした。御社の場合は、動くコードかもしれませんし、請求書の金額かもしれません。
Codex・Claude Codeの使い分けについてよくある質問
結局、どっちがいいですか
1つだけ選ぶなら、比較記事の順位より、自分の主な成果物が何の形式かと、その正しさを誰が確かめるかで決めるほうが、あとで作り直しになりません。弊社の場合はテキストがClaude、ファイル化と実機確認がCodexという分かれ方になりました。
得意分野で分けるのは間違いですか
弊社は、得意分野を分担の土台にせず、作業単位の判断に使っています。得意分野は数か月で入れ替わりますが、成果物の形式と確認の担当は動きません。動かないほうを土台にしておくと、モデルが更新されても社内の決めごとを作り直さずに済みます。
同じAIの別セッションで確かめれば、2つ契約しなくてもいいのでは
そのとおりで、書く担当と確かめる担当を分けるだけなら1契約でできます。弊社も記事の検証は同じAIの別セッションでやっています。2つ契約している理由は分担とは別で、片方が止まったときに仕事が止まらないことです。2社の枠はそれぞれ別に数えられるため、締切があって待てない仕事があるなら、2つ目は保険として働きます。
片方から片方へ乗り換えるか、両方使うかで迷っています
判断材料は2つあると思います。1つは、自分の仕事の成果物が1種類か複数かです。テキストで完結するなら1つで足ります。もう1つは、止まったときに待てるかどうかです。
検査を1本足せば、担当を移さなくても済んだのでは
弊社もそう考えて、1回目のあとに検査を新設しました。2回目はその検査を通り抜けています。壊れ方が変わるたびに検査を足す運用にすると、足し忘れた種類だけが素通りします。最後に実物を開く人を決めるほうが、壊れ方の種類が増えても効きました。
小さい会社や個人でも、この分け方は必要ですか
1人で1つのAIを使っているなら、分担のルールは要りません。必要になるのは、2つ以上のAIか、2つ以上のセッションを同時に動かし始めたときです。弊社も、同じ持ち場を取り合う事故が起きてから決めました。先に全部を整えるより、事故が起きた場所から順に決めるほうが現実的だと思います。
まとめ：任せる前に、確かめ方のほうを決める
CodexとClaude Codeのどちらが優れているかは、弊社には答えられません。測っていないからです。
代わりに分かったのは、分担を決めるときに先に見るものでした。そのAIが出したものを、誰がどうやって確かめるかです。確かめる人が決まっていない領域に任せると、失敗が見えないまま先へ進みます。
弊社がWordファイルで経験したのは、まさにそれでした。検査を足しても追いつかず、最後に効いたのは実物を開く人を決めたことです。
今日ひとつ試すなら、いま任せている仕事を1つ選んで、その結果を誰がどうやって確かめているかを書き出してみてください。書けない仕事があれば、そこが次に事故が起きる場所です。担当を変えるか、確かめる人を先に決めるか、どちらかになります。
枠や仕様を確認したい方へ
この記事の分担の決め方は、各社の仕様に依存しない形にしています。本文で公式の仕様に触れているのは、2社の枠がそれぞれ別に数えられるという点だけです。前提を確認するときは、確認日を添えて原文をご覧ください。
- OpenAI Help Center「Using Codex with your ChatGPT plan」（2026年9月8日確認）
- Claude Help Center「Use Claude Code with your Pro or Max plan」（2026年9月9日確認）
記録の取り方については、測れないものを測れないと書く型をAI検索の効果測定にまとめています。弊社の体制と拠点は会社概要にあります。
