「Codex全振り」を経て辿り着いたClaude Code＋Codex併用の安定運用

医療DX領域でTypeScript / Python を中心としたシステム開発をしています。Claude Code（Opus）をメインに使い込んでいく中で、以下の課題が積み重なりました。

• Context Windowの圧迫: 複数ファイルにまたがるドメインロジックの実装で、途中からモデルが前半の文脈を忘れる
• 使用量上限による作業中断: 集中して使い込む日に5時間ローリングウィンドウの制限に当たり、週に2〜3回は30分〜1時間の強制待ちが発生
• アウトプットの不安定さ（当時のモデル）: 「どこからその話は来たんや」というコードが生成されることが増え、レビューのストレスも上がっていた

当時は3つ目をモデルの問題だと思っていました。今でも時々は起きますが、Knowledge-baseとspecs、そしてhooksの整備で大幅に抑え込めています。後述しますが、仕様起点の開発フロー（Specify → Plan → Tasks → Implement → Knowledge）とKnowledge-base(略：KB)を整備した結果、Claude CodeでもCodexでもアウトプットは安定するようになっています。

どのような状態を目指していたか

AIコーディングツールに求める基準を3つ定義しました。

1. 品質安定したアウトプット — 待ち時間やリミットで開発体験の一貫性が損なわれないこと
2. ノウハウを貯められる＆再利用できる体制 — ツール特有のrule構成よりKnowledge-baseを単独に構築し、ツールが変わっても知見が活きること
3. レビュー可能 — 医療領域のシステムである以上、人間のレビューは必須。ただし全コードを目視するのではなく、重要な部分に限定した人間レビュー＋AIを活用したレビューの組み合わせで品質を担保すること

テックリード視点で見た導入の背景

AIコーディングツールは過渡期にあります。イノベーションがまだ続く中、単一のツールにこだわり過ぎないように、ツールに依存しないKnowledge-baseをチーム資産として育てていくことが重要だと考えています。

• Claude Code

主にClaude CodeとCodexを比較しました。

比較検討にあたっては、同じタスク・同じ依頼をClaude CodeとCodexそれぞれに投げて、過程と結果を比較しました。種類の違うタスク、違う言語（TypeScript、Python、Ruby）での生成結果、Knowledge更新まで正しく実行されるかも意図的に検証しています。

結果、KBをちゃんと構築した前提では、アウトプットの品質に決定的な差はありませんでした。どちらもspecsとKBに沿った精度の高いコードを生成でき、差が出るのは品質よりも上述の比較軸（トークン効率、制限など）の方でした。

一度「Codex全振り」を経験した上での判断

実は2025年秋に、チーム全体でCodexに全振りした時期がありました（Zenn記事にも書いています）。当時はClaude Codeの制限とアウトプットの不安定さに我慢の限界が来て、CursorのCodexプラグインでgpt-5-codex-highモデルを使う運用に移行しました。

仕様起点の開発フローとKnowledge-baseの組み合わせで、Codexだけでも十分な品質が出せることは実証できました。待ち時間やリミットのストレスもなく、チーム2つをCodexで安定運用まで持っていけました。

ただ、その後のモデル進化（Claude Opus 4.6のリリース等）を経て、Claude Codeの計画立案や複雑な要件整理での優位性が再び明確になりました。特にドメインロジックの設計議論では、行間を読む力がまだClaude Codeの方が強い。

最終的に、CCで設計・計画・実装、Codexでレビューという併用に落ち着きました。全振りを経験したからこそ、それぞれの得意領域がはっきり見えた形です。

決め手になったのは、両ツールで共通のKBを育てやすい点です。spec.mdやplan.mdはただのMarkdownなので、CLAUDE.mdとAGENTS.mdのどちらからでも参照できます。ツール固有の設定ファイルは別々でも、チームの知見そのものはツール非依存で蓄積できる構造にしました。

正直に言うと、2025年秋にCodexに全振りした時点では「Claude Codeのモデルが不安定だからCodexに変えた」と思っていました。しかしKBとspecs＋hooksを整備していく過程で気づいたのは、不安定さの大部分はモデルではなくコンテキストの与え方に起因していたということです。今でも時々は起きますが、KBが育った今ではCCでもCodexでもかなり安定しています。

ツール切り替えを前提にすると、「AIに口頭で説明する」のではなく「mdファイルに書いておく」方が合理的になります。チームで運用している5フェーズのフロー（Specify → Plan → Tasks → Implement → Knowledge）に沿って、以下のようなKBファイルがリポジトリ内に自然と育っていきました。

KB蓄積前は類似機能を作るたびにゼロベースで要件説明していましたが、蓄積後は過去の設計判断をAIが参照できるため、見積もりが2〜3割短くなった実感があります。

また、KBの副次効果として、チームの暗黙知の可視化が進みました。AIへの説明用に書いたつもりのspec.mdが、そのまま新メンバーのオンボーディング資料として機能しています。

自分はClaude Code大好きで使い続け、Codex全振りも経験し、今は併用に落ち着いています。この変遷を通じて確信したのは、ツール選びより先にKnowledge-baseの構築を始めてほしいということです。

振り返ると、「Claude Codeの制限が多い、アウトプットが不安定だ」と思ってCodexに移行したのですが、原因の大部分はKBの不足でした。KBとspecs＋hooksが育った今、どちらのツールでもアウトプットはかなり安定しています。ツールを変えても解決しない問題は、ツールの問題ではありません。

どんなに優秀なAIコーディングツールを使っても、KBが育っていないと毎回ゼロベースの説明になります。spec.mdやplan.mdをリポジトリ内でチームメンテナンスしながら、以下のサイクルを回してみてください。

Claude Codeで設計・実装 → Codexでレビュー → KBを更新 → 次のタスクでKBを参照

Claude Codeをメインにしたいチームは多いと思いますが、レビュー強化と制限リスクのヘッジとしてCodexを$20/月で持っておくのはコスパが良いです。

AIのアウトプットは必ずレビューしてください。production環境で動くコードです。リスクがあります。レビュー！レビュー！レビュー！

そして、ツールは半年で変わりますが、蓄積したナレッジは残ります。