なぜ大規模なPythonモノリスにおいてCodexが依然としてClaude Codeに勝るのか

過去1年間、複雑なPythonモノリスに取り組む開発者は主にCodexを使用してきた。Opus 4.6と4.7を搭載したClaude Codeを1ヶ月テストした後も、このコードベースではCodexを好んでいる。このアプリケーションは単純なCRUDサーバーではなく、新しいDDD風のレイヤー、古くても構造化されたコード、そして脆弱なレガシースパゲッティコードが混在している。チームは、必要がない限り古い部分の書き換えを避けている。

Codexの主な利点

• ハーネスエンジニアリングの原則： Codexは、明示的な指示がなくても ハーネスエンジニアリングのワークフロー を確実に遵守する。Claudeは、AGENTS.md に「exec_plan.mdを読んで従え」といった指示が含まれている場合のみそうする。
• 既存のツールとパターンを再利用： Claudeは、コードベースで既存のものを検索する代わりに、新しいツールを作成することが多い。プロジェクト固有のヘルパーが多いコードベースでは、再利用が重要である。
• 優れた計画性とコンテキスト認識： Claudeは、新しい機能を配置する前に読む量が少なすぎることがよくある。開発者は何度も次のように修正しなければならなかった。

「この機能はコントローラーではなく、モジュールAに配置してください。」
「リクエストで送信したステータスを使ってレスポンスオブジェクトを構築しないでください。APIは既に更新されたオブジェクトを返しています。そのレスポンスを使用してください。」
「この境界を所有する同じモジュールで検証してください。」

Codexは、アーキテクチャの変更を行う前に、欠落しているコンテキストに気づき、質問を明確にすることがより頻繁にある。

Claudeが優れている点

フロントエンド作業では、Opus 4.6はCodex 5.3やGPT-5.4よりも はるかに優れていた。現在、開発者はUIタスクではClaudeを好んでいる。GPT-5.5はUI中心の作業ではまだテストしていない。

ツール設定

両方のLLMは、Docker Composeの起動と停止、およびコンテナ内でテストを実行するためのコマンドという、1つの共有スキルを使用している。

---

これはベンチマークではなく、1つの本番コードベースでの日常的な使用経験です。