この記事は、Claude CodeとCodexを業務に入れようとしている方、あるいは入れてみたものの運用で困っている方に向けたものです。
どちらが優れているかという比較ではありません。両方を毎日の業務で回している立場から、何をどちらに渡しているかと、運用してから実際に壊れたところを書きます。
比較記事は既にたくさんあります。ただ、そこに書かれているのはほとんどが導入前の話です。実際に業務へ組み込んで数か月動かすと、比較表には出てこない問題が出てきます。この記事はそちら側の話です。
読み終えたときに、自社で使うならどう分けるか、そして導入後にどこを見張っておけばいいかが分かる状態を目指します。
結論：Claude Codeをハブに、Codexを専門の作業役に置いた
先に結論から書きます。
CodeClimbでは、Claude Codeを日常の作業ハブに据え、Codexには得意な作業だけを渡すという形に落ち着きました。両方を対等に使い分けているわけではなく、片方を主、もう片方を専門職として扱っています。
理由は単純で、2つのツールを対等に併用すると、どちらで何をやったかが追えなくなるからです。
同じ作業をどちらでも試せてしまうため、作業履歴が分散します。すると後から「この修正はどっちで入れたのか」が分からなくなります。結果として起きたのは次のようなことでした。
- 直したはずの箇所が、別の作業で元に戻る
- 同じ調査を二度やる
- 片方で作った前提のもとに、もう片方が別の前提で修正を入れる
どれも、ツールの性能とは無関係な事故です。主従を決めていなかったこと自体が原因でした。
主従を決めると、この問題はほぼ消えます。迷ったらハブ側でやる、という判断で済むからです。専門側に渡すのは「これは明らかにこちらが得意」と言い切れる作業だけに限定します。
なお、どちらのツールも短期間で機能が増えています。ここに書く分担は2026年8月時点の運用であり、固定的な優劣を主張するものではありません。半年後には別の分担が正解になっている可能性があります。
2026年時点で、何をどちらに渡しているか
実際の割り振りは次のとおりです。
Claude Codeに任せているもの
- コードの実装と修正
- 既存システムの調査、不具合の原因特定
- ドキュメントや手順書の作成
- 複数ファイルにまたがる横断的な変更
- 業務の自動化スクリプト
- 調べもの、文章の下書き、資料の整理
Codexに渡しているもの
- 画像の生成
- 画像生成まわりで、サブスクの範囲内で完結させたい処理
一覧にすると偏って見えますが、意図的にこうしています。画像生成に関しては、Claude CodeからCodexを呼び出す形で連携させています。この構成にすると、追加のAPI課金を発生させずに済みます。具体的な手順はClaude CodeとCodexを連携させてGPT Image 2を使う方法にまとめました。
分担を決めるときの目安
分担の考え方としては、「判断や文脈が要る仕事はハブ側、単発で結果が返ってくる仕事は専門側」が目安になります。
画像生成は「こういう絵がほしい」と伝えれば結果が返ります。前後の文脈をほとんど必要としません。だから専門側に渡しやすい仕事です。
逆に、既存のコードを読んで、影響範囲を考えて、あちこち直す、という仕事は文脈を持ち続ける必要があります。これを二か所に分けると、片方が知らない前提でもう片方が動くことになり、事故が起きます。
判断の材料になるのは、次の3つです。
- その作業は、前の作業の続きか — 続きなら、前の文脈を持っている側でやる
- 結果を見て、その場で方針を変える必要があるか — あるならハブ側
- 同じ指示を渡せば、誰がやっても同じ結果になるか — なるなら専門側に渡せる
どちらか一方しか選べない場合
社内で1つに絞りたい、という相談もよく受けます。その場合の目安は「何に一番時間を使っているか」です。
コードを書く、既存システムを調べる、資料を作る、といった作業が中心なら、文脈を持ち続けられるツールをハブに据えるのが自然です。逆に、リポジトリのレビューやクラウド側での長時間処理が業務の中心なら、そちらに強いツールを選ぶことになります。
どちらも試用できるので、自社で一番時間を使っている作業を1つ決めて、それだけを両方でやってみるのが確実です。機能の一覧を比べるより早く結論が出ます。
ここから先が本題です。導入して終わりではなく、運用に入ってから実際に踏んだところを3つ書きます。
落とし穴①：自動で走らせるとモデルが勝手に決まる
症状
定期実行しているジョブの結果が、あるときから明らかに雑になりました。手元で同じ指示を出すとちゃんとした結果が返るのに、自動実行だけ質が落ちる。指示文もデータも変えていないのに、です。
原因
自動実行のコマンドで使用するモデルを明示していなかったことが原因でした。
対話で使うときは画面でモデルを選ぶので意識しません。ところがコマンドラインから非対話で走らせる場合、モデルを指定しないと設定ファイルの既定値が使われます。この既定値は、過去に誰かが（あるいは自分が）試しに変えたまま戻し忘れていることがあります。
このケースでは、意図していない軽量モデルで5週間動き続けていました。結果が返ってきていたので、誰も異常だと気づかなかったのです。
エラーが出ていれば発見できたはずですが、動いているけれど質が低い、という状態はいちばん見つかりにくい類の不具合です。監視は「落ちたら気づく」ようにできていても、「品質が落ちたら気づく」ようにはなっていないことがほとんどだからです。
同じことが起きていないか確かめる方法
定期実行しているコマンドを一覧で書き出し、モデル指定のオプションが付いているかどうかを見てください。付いていないものがあれば、そこは設定ファイルの既定に依存しています。
あわせて、設定ファイルの既定値が今どうなっているかも確認します。ここが意図した値になっていない場合、指定なしで動いているジョブは全部そのモデルで動いています。
対処
自動実行するコマンドでは、モデルを必ず明示的に指定するというルールにしました。設定ファイルの既定に依存しない、というのが要点です。
あわせて、定期ジョブが実際にどのモデルで動いたかを、実行ログから確認できるようにしました。人が気づく前にログで分かる状態にしておくのが確実です。
この落とし穴は、AIを業務に組み込むときの一般則にもつながります。自動化した処理は「動いているかどうか」だけでなく「意図した条件で動いているか」を見る必要がある、ということです。動作の成否だけを監視していると、静かに品質が落ちている状態を見逃します。
落とし穴②：会話が長いほど、1回の発言が高くなる
症状
作業自体は進んでいるのに、月の利用量が想定を超えました。特に、長時間かけて1つのテーマを詰めた日ほど消費が大きくなります。
原因
対話型のセッションでは、それまでの会話の全量が毎回まとめて送り直されています。つまり会話が長くなるほど、1回の発言のために送るデータが増え続けます。
自社のセッションを実測したところ、長時間続いたセッション1本で、入力だけで5億トークンに達していました。セッション開始時の文脈は77Kトークン程度でしたが、終盤には975Kトークンまで膨らんでいます。終盤の1発言は、序盤の12倍のコストを払っていた計算になります。
厄介なのは、作業している本人にこの感覚がまったくないことです。画面上は同じように1つ質問して1つ答えが返るだけなので、コストが増えている実感がありません。長く使うほど熱心に働いている感覚になるのに、単価は上がり続けているという構造です。
対処
3つ決めました。
- 大量の読み込みは分離する。大きなログや大量のファイルを調べる作業は、本体のセッションに読み込まず、別のプロセスに投げて結論だけ受け取ります。一度読み込んだものは、以降ずっと再送され続けるためです
- 中間の成果物は会話ではなくファイルに置く。長い調査結果や下書きをファイルに書き、会話には要点だけ残します。同じ内容を会話に貼り直さないのが要点です
- 一定量を超えたら引き継ぎメモを作って会話を切る。切る前に、何をやっていて次に何をするかをファイルに書き出しておけば、続きから再開できます
3つ目は抵抗があるかもしれません。せっかく積み上げた文脈を捨てることになるからです。ただ実際にやってみると、引き継ぎメモに書き出す作業そのものが、論点の整理になるという副次的な効果がありました。
ここは業務でAIを使うときの費用設計に直結します。「使った回数」ではなく「会話の長さ」がコストを決める、という点は、社内に展開する前に共有しておいたほうがいいところです。使う人が増えてから伝えると、既に習慣がついていて直りにくくなります。
落とし穴③：裏で動き続けるツールが枠を食う
症状
ディスクの空きが急に減り、定期実行のジョブが立て続けに失敗しました。調べると、利用枠の消費も想定より大きくなっていました。
原因
作業を補助するために常駐させていたツールが、バックグラウンドで動き続けてトークンを消費していました。1日あたり数千万トークン規模です。
さらに、そのツールが蓄積したデータが数十GB単位まで膨らみ、ディスクを圧迫していました。空き容量が尽きたことで、無関係な定期ジョブまで失敗する、という連鎖が起きていました。
最初は「定期ジョブが壊れた」という症状として現れたので、原因にたどり着くまで遠回りしました。AIまわりの不調が、実はディスク不足だったというのは、言われてみれば単純ですが、その場では思いつきにくい筋です。
対処
そのツールはいったん停止しました。そのうえで、次を運用ルールにしています。
- 常駐して動くものは、何をどれだけ消費しているかを定期的に確認する
- 補助ツールに主要な処理をさせない。動かすとしても、主戦力の枠とは別の経路に逃がします
- ディスク使用量も監視対象に入れる
便利そうなツールを足していくと、それぞれは小さくても合計で無視できない量になります。入れたものを定期的に棚卸しするところまでが運用です。導入は一度きりですが、棚卸しは続ける必要があります。
会社で使うなら、先に決めておくことがある
ここまでツールの話をしてきましたが、業務に入れるときに効いてくるのは、実はツール選びではありません。
どの業務を渡すか、どこまでを人が判断するかを先に決めておかないと、どちらのツールを選んでも同じところで止まります。実際、相談を受けるときに問題になるのはほとんどこちら側です。
特に、外部への送信、認証、課金、削除にかかわる操作は、人が最終確認を持つべき範囲です。この線引きはAI導入で任せない業務4分類で具体的に整理しています。
そのうえで、最初に渡す1業務をどう選ぶかについては、中小企業のAI導入のはじめ方にまとめました。頻度、入力資料、確認者という3つの観点で選ぶと、失敗しにくくなります。
よくある質問
両方契約する必要がありますか
必須ではありません。まずは片方を主として決めて、そこで足りない作業が出てきたときに、もう片方を専門の作業役として足すのが無理のない順番です。最初から両方を対等に使おうとすると、この記事の冒頭に書いた「どちらで何をやったか分からなくなる」状態になりやすくなります。
コストはどう見積もればいいですか
使用回数ではなく、1回の作業をどれくらい長く続けるかで見積もってください。短い作業を数多くこなす使い方と、1つのテーマを長時間詰める使い方では、同じ回数でも消費が大きく変わります。
社内に展開するとき、最初に伝えるべきことは何ですか
会話が長くなるほどコストが上がること、そして自動実行する処理では条件を明示すること、この2つです。どちらも、後から直すより最初に習慣づけるほうが早く済みます。
エンジニアがいない会社でも使えますか
使えますが、最初の設計は経験のある人と一緒にやったほうが安全です。特に、どの業務を渡すかの線引きと、人が最終確認を持つ範囲の決め方は、後から変えると影響が大きい部分です。
まとめ
Claude CodeとCodexの使い分けについて、運用して分かったことを整理します。
- 主従を決める。片方をハブ、もう片方を専門の作業役にする。対等に併用すると作業履歴が追えなくなる
- 判断や文脈が要る仕事はハブ側、単発で結果が返る仕事は専門側に渡す
- 自動実行ではモデルを明示する。指定しないと設定ファイルの既定が使われ、意図と違う条件で動き続ける
- コストは使用回数ではなく会話の長さで決まる。長い会話ほど1発言が高くなる
- 常駐ツールは定期的に棚卸しする。裏で動くものが枠とディスクを食う
どれも、導入前の比較記事では出てこない話です。実際に業務へ組み込んで、しばらく回してから表面化します。逆に言えば、ここを先に知っておけば避けられるものばかりです。
参考
各ツールの仕様は更新が続いています。設定項目やコマンドのオプションは、実行時点の公式ドキュメントで確認してください。
AIを入れたのに、社内で使われていないなら
ツールを契約して全社に配っても、実際に使うのは一部の人だけ、というのはよくあります。原因はツール選びではなく、どの業務をAIに渡すかが決まっていないことにあります。
CodeClimbは、自社の業務をAIに任せながら運用しています。
- 見積書・請求書づくりは、1件15分かかっていたのが1分もかからなくなりました
- 営業のアプローチは、朝2時間で15件だったのが、調査から文面までAIが用意し、確認して送るだけで30分かかりません
- 日報は、1時間以上かけて棚卸ししていたのが、今は話すだけでAIがまとめて30分です
- システム不具合の原因調査は、半日かかっていたのが10分ほどで特定できるようになりました
同じ考え方で、御社の業務を1つずつAIに任せる設計をお手伝いしています。まず、どの業務から渡すべきかを切り分けるところから始めます。
全国どこからでも対応しています。福島県須賀川市・郡山市の企業様からのご相談も承っています。
