実装特化AI「Codex 5.2 High」と計画屋「Opus」の使い分け戦略

1. Brutal Reality Check: 圧倒的な「実装力」の差
- 📊 具体的な数値による「勝敗」
2. 独自の比喩で理解する「モデルの性格」
- 🐢 Opus: 「口だけのジュニアエンジニア」
- 🐇 Codex 5.2 High: 「実直なシニアエンジニア」
3. 推奨ワークフロー: "The Hybrid Approach"
- 🔄 The "Architect & Builder" Pattern
- 🛠️ 具体的な実践テクニック
4. 逆説的な洞察と警鐘
- ⚠️ "Vibe Coding" の罠
- 🧩 コンテキストの重要性
5. 言及されたツール・エコシステム

NOTE

Source: Codex 5.2 High vs Opus: A Brutal Reality Check

このノートは、Redditスレッドでの議論を元に、AIモデル「Codex 5.2 High」と「Opus」の性能差、役割分担、そして最適なワークフローについて独自の比喩や数値を抽出・整理したものです。

1. Brutal Reality Check: 圧倒的な「実装力」の差

スレッド内で提示された最も衝撃的な事実は、「計画する能力」と「実装して完遂する能力」の乖離です。Opusは賢いが「手を動かすと失敗する」傾向があり、Codex 5.2 Highは「圧倒的な馬力で解決する」という対比が描かれています。

📊 具体的な数値による「勝敗」

議論の中で提示された具体的な数値は、Opusの非効率さとCodexの解決能力を残酷なほど明確に示しています。

「24時間 vs 2時間」:
- Opus: Max200プランで24時間かけても解決できず、バグを増やし続けた。
- Codex 5.2 High: 同じ問題をわずか2時間で、ワンショット（一発）で解決した。
「6000行 → 1000行」:
- Pythonコード6,000行を、Codex 5.2 Highが約1,000行にリファクタリング完了。Opusでは計画止まりだったタスクを完遂。
「1週間で417テスト」:
- Rust AIメモリアプリケーション（417のテストとドキュメント付き）を、Codex主体で1週間で開発完了。

IMPORTANT

「速くても壊れていれば無意味」
投稿者は、Opusの出力に対して厳しい評価を下しています。どれだけもっともらしい計画を立てても、実装段階でバグを混入させるなら、その時間は「浪費」でしかないという現実です。

2. 独自の比喩で理解する「モデルの性格」

スレッド内では、両モデルの性質を人間になぞらえた興味深い比喩が多用されています。

🐢 Opus: 「口だけのジュニアエンジニア」

「ガイダンスが必要なジュニアエンジニア」: 指示待ちであり、自律的に動くと間違った方向に進む。
「悪い決定のループ (Bad Decision Loop)」: 一度ミスをすると、その修正のためにさらに悪いコードを書き、泥沼にはまる傾向がある。
「ハードウェアのせいにしたがる」: 組み込み開発において、自身のピン設定ミスを認めず「ボードのバグだ」と主張し続けたエピソードは、Opusの「幻覚に対する自信過剰さ」を象徴しています。

🐇 Codex 5.2 High: 「実直なシニアエンジニア」

「経験豊富なシニアエンジニア」: 黙々とタスクをこなし、複雑な依存関係や型システム（Rust/SwiftUI）を正確に処理する。
「ワンショット・ソルバー」: 試行錯誤せず、最初の一手で正解に近いコードを出力する。
「補助輪 (Training Wheels)」: （批判的な文脈だが）努力なしで良い結果が出てしまうため、ユーザーが思考停止するリスクがあるほど強力。

3. 推奨ワークフロー: "The Hybrid Approach"

議論の結論として、「どちらか一方を使うのではなく、適材適所で組み合わせる」ことが最強の解であると合意形成されています。

🔄 The "Architect & Builder" Pattern

TIP

成功の方程式: Opus (計画) + Codex (実装) + Review (相互監視)

Architect (Opus):
- 全体設計、仕様策定を行う。
- .md ファイル（Markdown）で計画書を出力させる。
- コードは書かせない。
Review (Codex):
- Opusが書いた計画をCodexにレビューさせる。「この計画で実装可能か？」をチェック。
Builder (Codex):
- 承認された計画に基づき、Codex 5.2 Highがコードを実装する。
- 「ワンショット」での実装を目指す。
Verification (Opus/Claude):
- Codexが書いたコードを、再びOpusやClaudeがチェックする。

🛠️ 具体的な実践テクニック

「敵対的エージェント洗練ループ (Adversarial Agent Refinement Loop)」:
- 片方が「完了した」と言っても信じず、もう片方のモデルに「本当に完了しているか？テストは通るか？」と検証させることで、LLM特有の「やったふり（幻覚）」を防ぐ。
「CLIコマンドによるレビュー依頼」:
- Claude CodeのCLIから、直接Codexを呼び出してレビューさせる自動化。

4. 逆説的な洞察と警鐘

議論の中には、単なるツール批判に留まらない、エンジニアリングの本質に関わる洞察が含まれています。

⚠️ "Vibe Coding" の罠

「Codexを使えばワンショットで動く」という利便性の裏には、「コードを理解せずに書く (Vibe Coding)」というリスクが潜んでいます。

WARNING

「スキル不足」はAIのせいか？
Opusで失敗するユーザーに対し、「それはプロンプトエンジニアリングや計画スキルの欠如（ユーザーエラー）だ」という厳しい指摘もあります。

Opusを使いこなすには、「問題を適切に定義し、分割する能力」が必要。
Codexはそれを「隠蔽」して解決してしまうため、ユーザーが成長しない可能性がある。

🧩 コンテキストの重要性

「Opusが失敗するのはモデルのせいではなく、コンテキストのせい」という指摘も重要です。

CLAUDE.md やドキュメントが肥大化し、ノイズになっている可能性がある。
「関連ドキュメントの読み込み不足」が、Opusの判断ミスを誘発している。

5. 言及されたツール・エコシステム

議論内で言及された、開発効率を上げるための周辺ツール群。

GSD (Get-Shit-Done): 開発フローを強制的に完了させるためのスクリプト/ツールと思われる（GitHubリポジトリ言及あり）。
Spec Kitty: 仕様書作成支援ツール？
Context7: 関連ドキュメントを適切に引き出し、コンテキストウィンドウを最適化するツール。
skills.sh: Rust等の特定言語に特化したスキルセットを提供するリソース。

結論

「Opusにコードを書かせるな、Codexに計画をさせるな」

このRedditスレッドの教訓は、AIモデルの「知能（Planning）」と「技能（Coding）」を明確に分離し、パイプラインとして接続することの重要性を説いています。2026年の開発において、単一モデルへの依存はリスクであり、「モデル間分業（Multi-Model Orchestration）」こそが、生産性を最大化する鍵となります。