ClaudeとCodexの使い分け｜併用が遅くなる境界

ClaudeとCodex、2つのコーディングエージェントを併用する現場が増えています。併用の運用設計は工程を分ければ速く進みますが、同じ成果物へ同時にアクセスさせると衝突し、かえって遅くなります。本記事は、制作・レビュー・機械作業の3工程での役割分担と、併用が遅くなる境界を、自社の運用記録から整理します。

01結論：併用の運用設計は工程を分けると速くなる

結論は3点です。

1. 併用の内訳は、Claude Codeが制作とレビューの主戦場、Codexが画像生成などの機械作業と独立したレビューという役割分担です。実際の運用で機能しています。
2. 併用が遅くなるのは、同じ成果物へ2つのエンジンが同時に書き込む場面です。ここでは衝突と手戻りが起きます。
3. 併用が速くなるのは、片方が作った成果物をもう片方が読み取り専用でレビューする場面です。書き込み範囲が重ならないためです。

この境界を分けずに「両方使えば速い」と考えると、工程の後半で作り直しが発生します。以下、根拠と判断軸を示します。

02Claude Codeが担う工程｜併用の起点は制作とレビュー

WEBMARKSは2026-06-24に7部署・30体のAI社員を定義しました。併用する2エンジンのうち、実務で下書き・調査・編集の主担当になっているのはClaude Codeです。制作の起点をここに置く理由は、1セッション内で複数の作業を安全に分担できる仕組みがあるためです。

Claude Codeの公式ドキュメントは、サブエージェントが専用のコンテキストウィンドウとツール権限を持つと説明しています。独立して作業した結果だけを、本流のセッションへ返す設計です（出典: Claude Code公式ドキュメント）。同じ文書は、多くのセッションを並列で監視する用途は別の仕組み（background agents）に分け、サブエージェントは1セッション内で完結させる設計だと明記しています。

WEBMARKSはこの設計を、ディレクター役（Fable）が構成・レビュー・統合だけを担当する体制として運用しています。下書きや調査は、実働のサブエージェント（jp-writer・vault-researcher・bulk-processor）へ並列で渡します。実働ワーカーには送信・削除・pushの実行手段を渡さないため、人間ゲートは構造として保たれます。

Anthropicは、中央のLLMがタスクを動的に分解し、ワーカーLLMへ委譲する設計を「オーケストレーター・ワーカー」パターンと呼んでいます（出典: Anthropic公式）。結果を統合するのも中央のLLMの役目です。Fableとサブエージェントの関係は、この型に沿っています。

ここで押さえるべき境界が1つあります。サブエージェントの並列は「1セッション内」に閉じた仕組みです。セッションをまたいで別エンジンが同じファイルへ触れる状況は、この安全設計の対象外になります。境界の詳細は次の見出しで扱います。

03Codexは何が違うのか｜併用の運用設計は機械作業から任せる

Codexを併用する主な理由は、画像生成（gpt-image-2）のように、Claude Code単体では完結しない機械作業があるためです。WEBMARKSはスライド・バナー資料の生成をCodex経由のImage 2.0に統一しています。過去にHTML生成と画像生成を1つの資料内で混在させた結果、フォントとレイアウトの基準がずれ、資料全体を作り直した経験があるためです。

Codexにはもう1つの使い道があります。Claudeが作った成果物を、書き込み権限を持たない読み取り専用の立場でレビューさせる使い方です。Anthropicは、一方のモデルが応答を生成し、もう一方が評価とフィードバックを繰り返す設計を「評価者・最適化者」パターンとして説明しています（出典: Anthropic公式）。ClaudeとCodexが互いの成果物を批評し合う運用は、この型に対応します。

以下の表は、併用時に2つのエンジンがどう役割分担しているかを比較軸ごとに示します。

Codex CLIの公式ドキュメントは、承認方針とサンドボックスを別の設定として管理すると説明しています（出典: OpenAI公式ドキュメント）。承認方針は「いつ確認を求めるか」、サンドボックスは「技術的に何ができるか」を決める軸だと分けています。Claude Codeのallow・ask・denyとは軸の切り方が違うため、同じ「書いてよい範囲」でも、エンジンをまたぐとそのままでは通じません。

WEBMARKSでは、併用時にこの違いを吸収するため、書き込みを伴うCodex呼び出しをサンドボックス限定のラッパー経由に統一しています。承認なしの全自動書き込みをそのまま直接呼び出す運用は避けています。

04併用はどこで遅くなるのか｜同じ成果物への同時書き込みという境界

併用が遅くなる境界は明確です。同じ成果物へ、2つのエンジン、または2つのセッションが同時にアクセスする場面です。実際に起きた3つの事例を並べます。

3件に共通するのは、原因が「AIの性能」ではなく「同時アクセスの設計」にある点です。同じ制作フォルダを複数のセッションが同時に触ると、片方が整理コマンドを実行しただけで、もう片方の未保存の成果が消えることもあります。この対策は、作業に入る前に担当範囲を宣言し、宣言のない範囲には他のセッションが着手しないという単純な約束です。

境界の反対側、つまり併用が速くなる場面にも同じ論理が働きます。Claudeが書き終えた後にCodexが読み取り専用でレビューする、Codexが生成した画像をClaudeが受け取って文章に組み込む。どちらも、片方の作業が終わってからもう片方が始まる直列の受け渡しです。同時ではないため、衝突する対象がありません。

05使い分けの判断基準｜工程を分けるか、レビューだけ挟むか

併用する工程をどちらのエンジンに割り当てるかは、次の3つの軸で判定します。

3つの軸のうち、実務で最も踏み外しやすいのは3つ目です。「速そうだから両方同時に投げる」という判断は、成果物が同じ対象を指している限り、事故の起点になります。

工程ごとにどちらの出力品質が高いかを実測で比較した記録は、別記事にまとめます。同一の指示文と素材を両エンジンへ渡し、同じ基準で採点した検証は『同じ制作タスクをClaudeとCodexに投げて比べた出力品質の実測』で公開する予定です。本記事では、その採点表を再掲せず、工程を割り当てる設計だけを扱います。

Codexへ作業を渡す正式な受け口も用意されています。調査・明示的な修正依頼・追跡のレスキュー作業をCodexのサブエージェントへ委譲する仕組みで、Fableが「投げてよい」と判断した範囲だけを渡します。ここでも、渡した後は結果を受け取るまで元の成果物には触れないという直列の原則が守られています。

こうしたAIどうしの相互チェックが公開ラインでどう機能しているかは『AIが書いた記事をAIが差し戻す｜公開前チェック5段階の中身』で扱っています。

06併用でつまずきやすい点｜起きやすい3つの誤解

誤解1「速いほうから使えばいい」

併用の目的は速度の総取りではありません。同じ成果物に2つのエンジンを同時に向けると、統合にかかる手間が並列化で浮いた時間を上回ります。工程を分けたうえでの並列化だけが速くなります。

誤解2「同じプロンプトを投げれば同じ結果が返る」

ClaudeとCodexは、指示の読み込み元（CLAUDE.mdとAGENTS.md）も、承認の軸（allow/ask/denyと承認方針/サンドボックス）も別です。同じ日本語の指示文でも、エンジンごとに解釈と既定の安全策が異なります。移植するときは前提条件を書き直す必要があります。

誤解3「レビューも同じエンジンで完結させたほうが速い」

書いた本人と同じエンジンにレビューさせると、前提を疑わないまま通してしまう場合があります。Codexを読み取り専用の独立した立場に置くのは、この見落としを減らすためです。レビュー工程だけは、あえて併用したほうが機能します。

07チェックリスト

• 併用する工程を制作・レビュー・機械作業に分け、それぞれの主担当エンジンを決めたか
• 同じ成果物へ2つのエンジンが同時に書き込む設計になっていないか
• レビューは書き込み権限を持たない独立した立場に置いているか
• エンジンを乗り換えるとき、指示の読み込み元と承認の軸が違うことを踏まえたか
• 複数セッションが同じ制作フォルダを触るとき、担当範囲を先に宣言しているか
• 資料の作り直しが起きないよう、1つの成果物の中でエンジンを混在させていないか

08FAQ