精度が出ないのはモデルのせいじゃなかった — Claude Code と Codex を分業させた話

これは「レガシー移行で学んだこと」シリーズの第3回です。前回は 実装するAIとレビューするAIを分けた話 を参照ください。

前回、OrchestratorとSub Agentで役割を分ける話を書きました。今回はその延長で、どのAIにどのレーンを任せるか の話です。同じプロジェクトでClaude CodeとCodexを併用していて、やっと落ち着いた使い分けが見えてきました。

はじめは「どっちが強い」で見ていた

最初、私は単純に「Claude CodeとCodexのどちらが画面移行で強いか」で比較していました。けれど、どちらを使っても似たような問題が出続けました。

• 元画面にあるフォームより、移行後の画面のフォーム数が少ない
• ラベル文言が微妙にズレている
• 編集可否（readonly / disabled）が一致しない
• グリッド列が欠けている
• 検索ダイアログの条件が減っている
• イベントや自動反映の仕様が抜けている

どちらのモデルで書かせても、数十％の要件漏れが起きました。「モデルの精度を上げれば解決する」と思っていたうちは、ずっとこの状態を繰り返していました。 ※ネストが深く、Moduleが大量にあるプロジェクトだった、、、という前提でもあるのですが、正直なところ、ClaudeCodeは達成度5%くらいを90％完了と自己評価し、Codexは達成度40％くらいで自己評価は諦める、、、という状況でしたｗ

主因はモデルじゃなく「工程」だった

ある時気づいたんですが、実装前に元画面を構造化して固定する工程が、そもそも無かった んです。

私は「この画面をBlazorに移行して」とだけ依頼して、実装エージェントが元のVB画面を勝手に読み、勝手に解釈して実装していました。元画面に15項目の検索条件があっても、エージェントが「たぶん10項目あれば足りる」と判断すれば、そのまま10項目になります。 ※実際は2項目しか拾われなかったわけですが、、、

つまり、精度問題の主因はモデル性能ではなく、要件を数で固定する工程が抜けている ことでした。この構造で走る限り、どのモデルを使っても似たような漏れが出るわけです。

役割分担: Claude Code = 実装、Codex = 棚卸し・差分検査

そこで、2つのツールを以下のように使い分けることにしました。

ツール	担当
Claude Code	Blazor Server / API の実装、既存コードへの組み込み、ビルドエラー修正、画面・API の追加
Codex	元画面の棚卸し、実装前の要件固定、実装後の差分レビュー、漏れ・ズレの指摘、チェックリスト更新

体感として、Claude Codeは「広くすばやく動くものを作る」のが得意で、Codexは「細かく数える」「差分を検出する」のが得意、という印象です。速さと精度を同じモデルに求めるのではなく、得意なところだけをそれぞれにやらせる 形に切り替えました。

3フェーズのフロー

運用としては、画面移行のたびに3フェーズを回します。

Phase 1: Codexによる実装前棚卸し

Claude Codeに「作って」と投げる前に、まずCodexに元画面の構造を洗い出させます。

• 画面上のフォーム数と、各フォームの項目名 / 型 / 編集可否 / 初期値 / 必須フラグ / イベント / 自動反映元
• グリッド列一覧（列名・表示順・編集可否・自動反映列・削除ボタン有無）
• ボタン一覧、タブ一覧、ダイアログ検索条件の一覧
• 保存先テーブル / 列

ここで 「元画面にあるものを数で固定する」 のが最重要です。たとえば「検索ダイアログAは検索条件15項目を持つ」と一度固定されれば、以降の実装はこの15という数字を下回れなくなります。

Phase 2: Claude Codeによる実装

Claude Codeには「この画面を作って」ではなく、Phase 1で作った棚卸し結果を前提条件として渡します。

依頼文には必ず以下を含めます。

• 元画面にある入力項目を減らさないこと
• ラベル文言は元画面に合わせること
• 編集可否は元画面に合わせること
• グリッド列を減らさないこと
• 検索ダイアログの条件を減らさないこと
• 未実装にする項目がある場合は、必ず一覧化して理由を書くこと

これでClaude Codeが勝手に要件を減らすことを防ぎます。

Phase 3: Codexによる差分レビュー

Claude Codeの実装完了後、Codexに棚卸し結果と実装の差分を検査させます。

観点はこの5分類で返してもらいます。

• 不足項目
• 文言ズレ
• 編集可否ズレ
• イベント漏れ
• 保存仕様ズレ

「なんとなくレビューして」ではなく、事前に数で固定されているものとの差分 を見るので、Codexの指摘が具体的になります。「項目が2つ足りない」「編集可否が3箇所違う」のような、数字で反論できない指摘が返ってきます。

特にこのフローが効く画面

すべての画面でPhase 1の棚卸しをやるのはコスト的に重すぎるので、私は以下の条件に当てはまる画面だけで必須化しています。

• 検索ダイアログ
• 複数タブ画面
• グリッド中心画面
• 自動反映が多い画面（コード入力 → 関連名称・属性が自動展開されるもの）
• 保存先テーブルが複数ある画面

逆にシンプルな詳細画面なら、Claude Code単独でもそこまで事故りません。

わかったこと

• 「どちらのモデルが精度が高いか」は、実は工程の差の前では小さな話だった
• Claude Codeの精度問題の多くは、実装前の要件構造化が無い ことに由来していた
• Codexに「数える / 差分を出す」を任せると、実装エージェントが勝手に要件を減らすのを防げる
• 速さはClaude Code、精度はCodex、という分業のほうが、どちらか一方で精度を追いかけるより結果が良い

次にやること

ここまでは運用の話でした。次からは、実際にこのフローで踏んだ具体的な事故を書きます。次回は、フォーカス（Tab / blur）に依存した値反映のバグ の話です。WinForms世代のUIをそのままWebに移すと、ほぼ必ずどこかで踏む落とし穴です。

おまけ

SNSのX上でも「ClaudeCodeとCodexを使い分けるのは有効である」という主張はいくらか見られます。 いっぽうで「わざわざ２つを併用する必要あるの？どっちか一つに絞れないの？？」という気持ちがある方には、 大規模マイグレーション に関しては、私はCodexを推します。 実は、実装 —> Review —> 再実装 —>再ReviewのワークフローにおいてCodexに全工程をやらせてみると「トータルのReview指摘事項はClaudeCodeよりも少なく収まる」という結果が出ています。 ClaudeCode-opus4.6にもgpt-5.3-Codexにも同等のSkillとAgentTeam, Scriptを持たせて検証した結果、そういう結論に至りました。