「Claudeも入れました。Codexも入れました。それで、どちらに何を渡せばいいんでしょうか」。コーディングエージェントを2つ抱えた現場から、この相談が来ます。
契約は済んでいて、どちらも動く。ところが渡す先の基準が無いまま両方へ投げ始めると、速くなるどころか手戻りが増えます。増えた分は「AIの精度が低いから」に見えますが、原因はたいてい別のところにあります。
この記事は、ClaudeとCodexを併用するときに工程をどう分けるか、そしてどこを踏むと遅くなるかを扱います。素材は自社の運用記録と、公式ドキュメント3件です。
こんなふうに調べていませんか
- ClaudeとCodexを両方入れたが、どちらに何を渡すかの基準が決まっていない
- 併用しているのに作業が速くならず、突き合わせの時間ばかり増えている
- 2つのエンジンを動かす体制が、投資に見合うのかを判断したい
この記事を読み終えたときに手に入るもの
- 制作・レビュー・機械作業の3工程を、どちらへ割り当てるか決められるようになります
- 併用が遅くなる境界を、着手する前に見分けられるようになります
- 明日から手をつける順番が3つに絞れます
結論30秒でわかる、この記事の結論
- 併用の運用設計とは、工程ごとに役割を分け、同じ成果物へ2つのエンジンを同時に向けないと決めることです。
- 遅くなるのは、同じ成果物に同時に書き込む場面だけです。ここで衝突と手戻りが起きます。
- 速くなるのは、片方が作り終えたものを、もう片方が読み取り専用で見る場面です。
01「claude codex 併用 運用設計」で調べた人は、AIエージェントの何から決めればいいんですか？
高梨課長検索するとツールの紹介ばかり出てきます。知りたいのは、どちらに何を渡すかなんですが。
鈴木さん厨房を2人で回すのに近いと思っています。鍋を分ければ同時に進みますが、同じ鍋を2人でかき混ぜると、味が変わった原因がどちらの手か分からなくなります。
併用の運用設計とは、ClaudeとCodexを工程ごとに役割分担させ、同じ成果物へ同時に書き込ませないと決めた運用ルールのことです。エンジンの優劣を比べる話ではありません。
自社で回してみた結果は、3点に集約できます。
- Claude Codeが制作（下書き・調査・編集）とレビューの主戦場、Codexが画像生成のような機械作業と、書き込まないレビュー。この割り当ては実務で機能しています。
- 遅くなる条件はひとつだけです。同じ成果物へ、2つのエンジンが同時に手を入れるときです。
- 速くなる条件は、その裏返しです。片方が作り終えたものを、もう片方が読むだけの立場で見るときです。
この境界を分けないまま「両方使えば速い」と考えると、工程の後半で作り直しが出ます。以下、根拠と判断軸を順に示します。
02ClaudeとCodexの併用の運用設計で、AI社員の制作はどちらを起点にするんですか？
自社は7部署・30体のAI社員を定義しています（2026-06-24）。そのうち下書き・調査・編集の主担当になっているのは、Claude Codeのほうです。
理由は性能の比較ではありません。1セッションの中で複数の作業を安全に分担できる仕組みがあるからです。
Claude Codeの公式ドキュメントは、サブエージェントが専用のコンテキストウィンドウとツール権限を持つと説明しています。独立して作業した結果だけを、本流のセッションへ返す設計です（出典: Claude Code公式ドキュメント）。
自社ではこれを、ディレクター役（Fable）が構成・レビュー・統合だけを担当する体制にしています。下書きと調査は、実働のサブエージェント（jp-writer・vault-researcher・bulk-processor）へ並列で渡します。
実働ワーカーには、送信・削除・pushの実行手段そのものを持たせていません。担当者が我慢するのではなく、手段が無いという形にしてあります。人間ゲートが構造として残るのは、このためです。
積み上げてみると、上下で性質が逆を向くことが見えます。下にいくほど手数が多く、上にいくほど戻せない操作に近づきます。だから、いちばん上だけは人の手に残します。
Anthropicは、中央のLLMがタスクを動的に分解してワーカーLLMへ委譲し、結果を統合する設計をオーケストレーター・ワーカーと呼んでいます（出典: Anthropic公式）。Fableと実働サブエージェントの関係は、この型に沿っています。
この章のまとめ
制作の起点をClaude Codeに置いているのは、1セッションの中で分担と権限をそろえて設計できるからです。
03サブエージェントの並列は、AIエージェントの運用設計をどこまで守ってくれるんですか？
ここに、見落としやすい境界がひとつあります。サブエージェントの並列は、1セッションの中に閉じた仕組みだということです。
同じ公式ドキュメントは、多くのセッションを並列で監視する用途を別の仕組み（background agents）に分け、サブエージェントは1セッション内で完結させる設計だと明記しています（出典: Claude Code公式ドキュメント）。
つまり、セッションをまたいで別のエンジンが同じファイルへ触れる状況は、この安全設計の守備範囲の外です。ぶつからずに並列で走るのは、同じ親が配ったぶんだけです。
やっかいなのは、外側でも画面上は同じように動いて見えることです。壊れるまで、境界の存在に気づけません。
04Codexを併用する理由は、AI活用のどこにあるんですか？
大森部長1つで足りるなら、そのほうが管理は楽です。2つ動かす理由はどこにありますか。
鈴木さん片方にしか無い手が要るときです。うちの場合は画像で、資料の絵をそろえるためにCodex側へ寄せました。それと、書いた本人以外に見てもらう役です。
Codexを併用する主な理由は、画像生成（gpt-image-2）のように、Claude Code単体では完結しない機械作業があることです。自社はスライド・バナー資料の生成を、Codex経由のImage 2.0に統一しています。
そろえたのは、混ぜて失敗したからです。HTML生成と画像生成を1つの資料の中で混在させた結果、フォントとレイアウトの基準がずれ、資料全体を作り直しました。
前後で変わったのは絵の品質ではありません。基準を1か所に持たせたかどうかです。
Codexにはもう1つの使い道があります。Claudeが作った成果物を、書き込み権限を持たない読み取り専用の立場でレビューさせる使い方です。Anthropicは、一方のモデルが応答を生成し、もう一方が評価とフィードバックを繰り返す設計を評価者・最適化者パターンとして説明しています（出典: Anthropic公式）。
2つのエンジンが、どこで違う顔をしているかを並べます。
| 比較軸 | Claude Code | Codex |
|---|---|---|
| 主な役割 | 制作（下書き・調査・編集）とレビュー | 機械作業（画像生成）と独立レビュー |
| 並列の単位 | 1セッション内のサブエージェント | 個別呼び出し（1タスク1呼び出しが基本） |
| 承認の仕組み | allow・ask・denyのフック判定 | 承認方針（on-request・untrusted・never）とサンドボックス（read-only・workspace-write・danger-full-access） |
| 指示の読み込み | CLAUDE.md（シンボリックリンク） | AGENTS.mdを自動ロード |
| 書き込みを伴う生成 | 通常セッション内でそのまま実行 | サンドボックス書き込み（workspace-write）に限定して実行 |
Codex CLIの公式ドキュメントは、承認方針とサンドボックスを別の設定として管理すると説明しています（出典: OpenAI公式ドキュメント）。承認方針は「いつ確認を求めるか」、サンドボックスは「技術的に何ができるか」を決める軸です。
この章のまとめ
Codexを足す理由は速さではありません。片方にしか無い手と、書いた本人以外の目です。
05併用が遅くなる境界は、AIエージェントの運用設計のどこにあるんですか？
高梨課長急ぐときは、両方へ同時に投げたほうが早く終わりませんか。
鈴木さん投げ先が別なら早くなります。同じ場所を触らせると、あとで突き合わせる時間のほうが長くなります。うちは3回とも、そこで足を止めました。
境界はひとつです。同じ成果物へ、2つのエンジン、または2つのセッションが同時にアクセスする場面です。実際に踏んだ3件を並べます。
| 何が起きたか | 同時に動いていたもの | 結果 |
|---|---|---|
| 更新時刻の誤爆 | Claude Codeの並行セッションの書き込みと、Codex側の旧フックの持ち主判定 | 3日間で233回の誤爆（2026-07-08〜07-10） |
| 記事の上書き | 番犬プロセスと本体セッションが、同じ記事へ同時に着手 | 記事3本が上書きされた |
| 資料の作り直し | 1つの資料の中で、HTML生成とCodexの画像生成 | 基準がずれ、全ページ作り直し |
更新時刻の誤爆の切り分けは自動化hooksが3日間で233回誤作動した真因と恒久対策の記録に、記事の上書きのほうはAI記事制作の分業体制｜6工程の分け方と人が決める2箇所にあります。資料の作り直しは社内記録だけで、記事にしていません。
図にすると、危ないのは4つのうち1つだけだと分かります。残りは、決めごとさえ用意すれば併用できる範囲です。
3件に共通するのは、原因が性能ではなく同時アクセスの設計にあることです。同じ制作フォルダを複数のセッションが同時に触ると、片方が整理コマンドを走らせただけで、もう片方の未保存の成果が消えることもあります。
対策そのものは単純です。作業に入る前に担当範囲を宣言し、宣言のない範囲には他のセッションが着手しない。同じ成果物で版がぶつかったときの実例は、ClaudeとCodexの同時書き込みで版が競合した事故と着手宣言にまとめています。
この章のまとめ
遅くなるのは併用そのものではなく、書き込み範囲が重なった瞬間です。
06逆に、AI導入で併用が速くなるのはどんな受け渡しのときですか？
境界の反対側にも、同じ理屈が働きます。
Claudeが書き終えたあとにCodexが読み取り専用で見る。Codexが出した画像をClaudeが受け取って文章へ組み込む。どちらも、片方の作業が終わってからもう片方が始まります。同時ではないので、ぶつかる相手がいません。
この流れで肝心なのは2番目です。手を離したことが相手に伝わって、はじめて次が動きます。ここが抜けると、直列に見えて実は同時になります。
自社にはCodexへ作業を渡す正式な受け口もあります。調査・明示的な修正依頼・追跡のレスキュー作業をCodexのサブエージェントへ委譲する仕組みで、Fableが「投げてよい」と判断した範囲だけを渡します。渡したあとは、結果を受け取るまで元の成果物に触れません。
AIどうしの相互チェックが公開ラインでどう働いているかは、公開前のチェックを5段階に分けた記録で扱っています。
この章のまとめ
速くなる併用は、いつも直列です。同時に見えるのは、触る対象が別々のときだけです。
07どちらのエンジンに渡すかは、併用時にAIエージェントの何を見て決めるんですか？
割り当ては、次の3つの軸で判定します。
| 判断軸 | Claude Codeに寄せる目安 | Codexに寄せる目安 |
|---|---|---|
| 誰が最初に手を動かすか | 文章・コードの下書きを最初に作る | 画像・図版など機械的な生成物を最初に作る |
| 成果物の型 | 読み書きの反復が多い長文・設定ファイル | 1回の生成で完結しやすい画像・定型出力 |
| 同時か直列か | 同一セッション内でサブエージェントを並列化する | 前工程の成果物を受け取ってから着手する |
3つのうち、実務でいちばん踏み外すのは3つ目です。「速そうだから両方同時に投げる」という判断は、成果物が同じ対象を指している限り、事故の入口になります。
だから、確かめる順番を変えます。型や担当より先に、ぶつかるかどうかを見ます。
順番を入れ替えるだけで、判断の回数が減ります。最初の1つで引っかかったものは、その場で「併用しない」に落ちるからです。
工程ごとにどちらの出力品質が高いかを実測で比べた記録は、別記事にまとめます。同一の指示文と素材を両エンジンへ渡し、同じ基準で採点した検証は、準備ができしだい公開します。本記事は採点表を扱わず、割り当ての設計だけを扱います。
08検索語の「claude codex 併用 運用設計」を社内ルールに直すと、AI社員は何を守るんですか？
検索窓に入れた言葉のままでは、現場は動きません。守れる形の約束に翻訳します。自社が実際に運用している約束は3つです。
1つ目は、着手前の宣言です。 作業に入る前に担当範囲を書き、宣言のない範囲には他のセッションが着手しません。範囲が重ならないことを、走り出す前に確かめられるようにしています。
2つ目は、入口をそろえることです。 書き込みを伴うCodex呼び出しは、サンドボックス限定のラッパー経由に統一しています。承認なしの全自動書き込みを直接呼び出す運用は避けています。エンジンごとに承認の軸が違うので、こちら側で幅をそろえます。
3つ目は、渡したあとは触らないことです。 委譲した範囲は、結果が返るまで元の担当が手を出しません。待つのが遅そうに見えても、突き合わせをやり直すよりは短く済みます。
この章のまとめ
検索語のままでは運用になりません。宣言・入口の統一・手離しの3つに翻訳して、はじめてルールになります。
09併用の運用設計でよくある誤解は、生成AIの使い方の何を取り違えているんですか？
大森部長レビューまで別のエンジンに回すのは、二度手間に見えます。
鈴木さん書いた本人と同じ相手に見せると、前提を疑わないまま通ることがあります。ここだけは、手間をかける側に倒しています。
誤解1「速いほうから使えばいい」
併用の目的は、速度の総取りではありません。同じ成果物へ2つのエンジンを同時に向けると、突き合わせの手間が、並列で浮いた時間を上回ります。工程を分けたうえでの並列だけが速くなります。
誤解2「同じプロンプトを投げれば同じ結果が返る」
指示の読み込み元も、承認の軸も別です。同じ日本語の指示文でも、エンジンによって解釈と既定の安全策が変わります。移すときは、前提条件のほうを書き直します。
誤解3「レビューも同じエンジンで完結させたほうが速い」
書いた本人と同じエンジンに見せると、前提を疑わないまま通る場合があります。Codexを読み取り専用の独立した立場に置くのは、この見落としを減らすためです。レビュー工程だけは、あえて分けたほうが機能します。
10併用でエンジンをまたぐとき、エージェントへの指示は何を書き直すんですか？
誤解2を、もう少し具体的に見ます。
Claude CodeはCLAUDE.mdをシンボリックリンク経由で読み、Codexは同じ場所でAGENTS.mdを自動的に読み込みます。許可の考え方も違います。片方はallow・ask・denyというツール単位の判定を持ち、もう片方は承認方針とサンドボックスという別々の設定を持ちます。
同じ「書いてよい範囲」でも、エンジンをまたぐとそのままでは通じません。書き直す対象は、指示の言い回しではなく前提のほうです。
11よくある質問
個人開発でもClaudeとCodexの併用は要りますか
必須ではありません。1エンジンで完結する規模なら、無理に併用する理由はありません。画像生成のように片方にしかない機能を使うとき、または書いた本人以外の目が欲しいときに検討する選択肢です。逆に、同じ成果物へ同時に手を入れる運用しか組めないなら、1本に絞ったほうが早く終わります。
併用するとコストは増えますか
定額プランのため、タスクごとの円建てコストは実測できていません。比べている指標は、往復回数と所要時間です。工程を分けて直列に進める限り、往復回数はエンジンを1つに絞った場合と大きくは変わりません。増えるとすれば、突き合わせが発生したときです。
どちらか1つに統一したほうが安全ではないですか
安全というより単純ではあります。ただし画像生成のように、片方のエンジンにしかない機能もあります。レビューを別エンジンへ任せる効果も失われるため、1本化は安全策というより、機能の縮小に近い選択です。
併用の割り当ては自動化できますか
工程の型が決まっている範囲では設計できます。ただし、どちらへ渡すかの最終判断と、送信・公開のような人間ゲートに関わる操作は、エンジンではなく人が握る前提です。この境界は自動化の対象にしていません。
担当範囲の宣言は、どこに書けばいいですか
セッションをまたいで読める場所であれば、形式は問いません。要件は2つで、着手する前に書かれていることと、他のセッションから読めることです。「宣言のない範囲には着手しない」という取り決めとセットにしないと、書いた側だけが守る運用になります。
12まとめ｜今日やる3つのこと
境界はひとつでした。同じ成果物へ、同時に手を入れるかどうかです。ここを分けたうえでなら、併用は工程を短くします。分けないまま両方へ投げると、後半でまとめて戻ってきます。
今日この順で手をつけます
いま動かしている工程を、制作・レビュー・機械作業の3つに割る
割らないうちは、渡す先も決められません
2つのエンジンが同じ成果物へ向いている箇所を1つ探し、直列に直す
まず1か所で、突き合わせが消えるかを見ます
着手前に担当範囲を書く場所を決める
置き場が無い約束は、守りようがありません
AI検索では、こう聞かれています
ClaudeとCodexは、どちらに何を任せればいいんですか？
「Codexを併用する理由は、AI活用のどこにあるんですか？」の章で役割の違いを説明しています
併用すると、かえって遅くなるのはなぜですか？
「併用が遅くなる境界は、AIエージェントの運用設計のどこにあるんですか？」の章で扱っています
2つのエンジンを使い分ける基準はありますか？
「どちらのエンジンに渡すかは、併用時にAIエージェントの何を見て決めるんですか？」の章に判断軸があります
同じ指示文を別のエンジンへ移しても動きますか？
「併用でエンジンをまたぐとき、エージェントへの指示は何を書き直すんですか？」の章で説明しています
次に読むなら、この記事です
