背景
Claude Codeサービス提供以来ずっと下記の理由で大好きでMaxプランを利用して、一緒にたくさんの価値を創りました。
Claude Codeを好きな理由
1. Default状態でアウトプットの質が高い
依頼Prompt以外、何にも用意しない状態で相談することで、専門家レベルの議論ができます。
Knowledge-baseやCLAUDE.mdちゃんと用意すれば、意図した通りcodingができます。
2. 仕事が早い
thinkがあっても体感的に速い動きができています。
3. モデル性能と機能面最先端
Sonnet3.5から今最新の4.5までcoding領域のモデル性能が最強。
機能面もMCPからSubAgent、最新のSkillまで業界の提案者であり、豊富でした。
一方、最近自分自身とチーム全体でClaude Codeの利用からCodexに移りました。
その理由と過程及び（現状の）結果を共有します。
モチベーション
Claude Codeのリミットとアウトプットの不安定さに飽きてしまったのが全てです。
8月からのこの数ヶ月で下記に悩まされる経験、Claude Codeのユーザーなら感じたことがあるでしょう！？
- 相談依頼開始なのにContext Windowが30%以上すでに利用された
- 頻繁に5時間Limitに引っかかって、作業を一時中止することに
- SDD(Spec-Driven Development)前提ですが、アウトプットの質が不安定。多くの場合以前と比べると下がっている。どこからその話は来たんやというのが書かれてしまう。
ちょうどCodexがリリースされ、X上の評判を多く目にするから一度試してみることに。
なお、さすがに自分の開発にここまで浸透されたから改めて自分が求めるAI Codingのツールの基準を確認しました。
AI Codingツールに求めたい基準
1. 品質安定したアウトプット
業界の進化早いため一定のWatchですが、
これらのツールの利用目的はプログラミングを効率よく行うこと
ツールを何回も何回も調整したり、待ち時間が長い、日中の開発を、リミットが原因で中断されたり、高い頻度で開発体験の一貫性を損なうことはチーム開発に於いて本末転倒です。
2. ノウハウを貯めせる＆再利用できる体制
今年4月以降は、チーム全体でCursorと（５月以降）Claude Codeで統一できましたが、
それまではチーム内で利用するツールがバラバラでした。
イノベーションがまだ続く中、単一のツールにこだわり過ぎないように、"ツール特有のrule構成よりKnowledge-baseを単独に構築"した上で、
ツール特有のrule内でKnowledge-baseを適切に引用できるように努力していました。
Knowledge-baseを継続に活用できる、更新できる体制を維持したいです。
*Knowledge-baseの構築については下記の記事に書いてあります。ご興味があれば、この記事を読み終わった後にぜひご覧になってください。
3. レビュー可能
AIのアウトプットを鵜呑みにすることが禁断。
何ができたのかちゃんと自分の目で確かめられる、確かめることが必須。
チーム開発でproduction環境に送り出すコードは
夜8時間AIに稼働させて、朝になったら簡単なチェックでpushすることを夢見たいですが、現時点自分には怖すぎでリスクを感じています。
これらを基準に設定した上で、Codexを実験的に導入し始めました。
結果
自分が見ている2チームのうち、Codex Proプランで
1チーム安定運用済み、もう1チームは先週導入と運用し始めました。
CursorのCodexPluginで利用。モデルは gpt-5-codex-high。
利用するMCPは contex7と chrome-devtools-mcp(必要時のみ有効)
1. 品質安定したアウトプット
SDD(Spec-Driven Development)とKnowledge-baseで複雑な医療用サービスでも精度がとても高いCodingが実現できました。
待ち時間やリミットのストレスもありません。
2. ノウハウを貯めせる＆再利用できる体制
今まで貯めたKnowledge-baseをFull活用できています。
またタスクごとにspec.md, plan.md, tasks.md, quickstart.mdを生成することによって
Knowledge-baseの管理をタスクレベルとRepoレベルで分けられて、抽象度と解析度を両立した管理を実現できました。
3. レビュー可能
どこからその話は来たんやというのが書かれてしまうことがないので、レビューのストレスが減りました。
また、CodexのpluginにTrace Diff機能があり、コード生成しながら差分をその場でレビューできることは助かっています。
GitHubにも連携して、PRの自動レビューして貰って、人間レビュー時の参考にもなるようにしています。
移行手順
Claude CodeからCodexに移行までのFlowを簡単に紹介します。
[個人] SDD用PromptをAGENTS.mdで構築
SDDのPromotをAGENTS.mdで構築しました。
以下は抜粋：
# (略) AGENTS.md — AIエージェント開発・運用ガイド
このドキュメントは、AIアシスタント（コーディングエージェント）がxxxで一貫性のある開発を行うためのプロンプト基準と進め方を定義します。目的は二つです。
- 目的1（Promptガイド）: PJTの構成・規約に沿った開発ができる具体的なプロンプトを提供
- 目的2（進め方ガイド）: 依頼から仕様化・計画・タスク分解・実装・ナレッジ更新までのプロセスを定義
本ガイドは以下のフェーズで進めます。
1. Phase 1: Specify（仕様定義）
2. Phase 2: Plan（技術計画）
3. Phase 3: Tasks（タスク分解）
4. Phase 4: Implement（実装）
5. Phase 5: Knowledge（ナレッジ更新）
!!!Phase 1とPhase 2はBest-of-Nで一個の要求に対して複数のバージョンを走らせて、ベストなやつを選べる!!!
---
## リポジトリ前提・不変条件（Invariants）
（略）
- 重要パス:
（略）
- ナレッジ（全体）: `docs/`（特に `docs/architecture-specification.md`）
---
## 使い方
- 依頼は次のコマンド型で行います（いずれも日本語でOK）。
- 生成物は `specs/[feature-number]-[feature-name]/` 配下に保存し、実装時のコンテキストとして参照します。
!!!ユーザーは「確認不要」で指定しない限り、次のPhaseを実行する前にユーザーに確認するようにしてください!!!
```text
/specify [課題や実現したい体験の説明...]
/plan [技術スタック、制約、アーキテクチャ方針...]
/tasks [実装に落とすための分解指示。優先度/独立性/テスト容易性を考慮]
/implement [取り掛かるタスクID or タスク内容。編集対象と完成条件を明記]
```
ディレクトリ構成（機能別コンテキスト）:
(以下略)
```
[個人][1週間] 同じタスクをClaude CodeとCodexに依頼＆アウトプット比較
同じタスクで同じ依頼でClaude CodeとCodexそれぞれ依頼して、過程と結果を比較しました。
モデルの得意と不得意もあるため、種類の違うタスクの検証や、違う言語（Ts、Python、Ruby）のcoding結果も意図的に比較しました。
また最後のKnowledge更新までもちゃんと実行されるかどうか、内容の正確性も比較しました。
作業のリポジトリは関わりの少ないrepoからメイン開発repoまでのflowを踏みました。
結果、Codex優勝でした。
[個人][1週間] Codexのみで日常業務
Codexのみで設計、開発、テストと相談など個人の日常業務でFull活用してみて、問題点と改善策を探りました。
結果、元々AI Firstの業務Flow実現できているお陰でそこまで苦労しなかった。
[個人] Codexの整備をチーム用に整備
チーム利用に環境整備。
元々Knowledge-baseのため、開発環境の整備は個人実験時でできたものをそのまま利用。
GitHubとの連携
予算確保とアカウントアップグレードはメンバーによってケアを多少必要。
[チーム][1週間] チーム全員Codex使ってみて促進
弊社ではWeeklyでAIペアプロの時間を設けています。
そこで個人実験で得られたノウハウと成果とともに実際にタスク一個demoすることでメンバーの理解をつくりました。
その後、少しづつ使ってみての煩いリマインドを1週間やりました。
[チーム]全員Codex本番利用
全員利用開始、各自のノウハウをdailyとAIペアプロで共有し合います。
実践Tips
ここまでClaude CodeからCodex移行した背景から手順まで説明しました。
せっかくなので、有用なTipsにも共有します。
1. 曖昧ありを前提に
AI使っている以上ハルシネーションが生じます。
起きる理由としては、AIは曖昧であっても「正解」をとりあえず出すように訓練されているというのが原因だと言われています。
これも求めないアウトプットができてしまう原因の一つ。
そのため、下記のようにSpecの段階から曖昧なことに対してはユーザーに確認するように要求しています。
## Phase 1: Specify — 仕様定義（ユーザー価値に集中）
技術ではなく、ユーザージャーニーと成功の定義に集中します。
- 出力（最低限）
- ユーザーストーリー（As/When/Then）
- 機能要件（機能・非機能）
- 受け入れ基準（テスト観点での合否条件）
- 曖昧さの明確化マーカー（[NEEDS CLARIFICATION]）
テンプレート:
```text
/specify [機能名 or 課題名]
コンテキスト:
- 現在の痛み/目的:
- 対象ユーザー/役割:
- 利用シーン（ユーザージャーニー）:
ユーザーストーリー:
- As a [role], When [situation], I want [goal] so that [outcome].
機能要件:
- [ ] 要件1
- [ ] 要件2
非機能要件:
- 性能/信頼性/セキュリティ/運用…
受け入れ基準（テスト観点）:
- [ ] 観点1
- [ ] 観点2
曖昧さ/前提（[NEEDS CLARIFICATION] を付ける）:
- [NEEDS CLARIFICATION] 〜〜
2. より「思考」させる
Best-of-Nを要求する。
複数解決策を生成＆比較することでより正解に近づく
3. DoDを定義する
各タスクのDoD（Definition of Done: 完了条件）を明記するように要求。
tasksの定義：
## Phase 3: Tasks — タスク分解（小さく独立・テスト可能に）
1タスク = 1つの明確な成果物。レビュー/テスト可能単位に分割します。
- 分解の観点
- スキーマ変更/マイグレーション
- リポジトリ実装/テスト
- API契約/エンドポイント実装
- 型生成/変換レイヤ
- UI/クライアント（該当時）
- セキュリティ/監査/ロール
テンプレート（コピペ可）:
```text
/tasks
タスク一覧（優先度・独立性・テスト容易性込み）:
1. [DB] DrizzleスキーマにXを追加しマイグレーション生成
2. [Repo] PatientRepositoryにYクエリを追加（PHI/監査対応）
3. [API] Zエンドポイント/Protoを追加（契約テスト付き）
4. [Gen] 型/Protoのコード生成コマンドを更新
5. [Test] 単体/統合テストの整備
6. [Docs] `specs/...`と`docs/`更新
各タスクのDoD（Definition of Done）を明記:
- 例: 「DBマイグレーションがCI/ローカルで適用でき、後方互換である」
4. 例を提供する
Learning in Context という概念から指示の中に参考例を提供することがとても良い効果を得られます。
例：
## 例：よくある依頼のひな形
### 例1: 患者検索の要件定義
```text
/specify 患者検索（氏名・生年月日・施設ID）
コンテキスト: 往診受付が患者を素早く特定したい
ユーザーストーリー: As a receptionist, When I input filters, I want a list of patients.
機能要件:
- [ ] 名前前方一致/完全一致切替
- [ ] 生年月日（日付型）
- [ ] 施設IDフィルタ + 索引利用
受け入れ基準:
- [ ] 100ms p95 以内で上位20件
5. Knowledgeを育成
上にも触れたように、Knowledgeの形成を大事に。
AI Codingに必要のcontext提供できるほか、チームでの暗黙知や属人化への対策にもなります。
6. MCP利用は最小限
無駄にContext Length増やすことでハルシネーション、処理速度低下の原因にもなるから利用を慎重に。
セキュリティの面に置いてもできるだけ公式のもの利用すること。
7. 外出時ChatGPTのAppでCodex利用
GitHubのリポジトリと連携＆CodexのEnvを設定すれば、
外出時でも携帯のAppから相談、実装、レビューができます。
詳細は下記の記事ぜひご覧ください。
8. 過度に期待しない
Context Window制限がある以上一気に0から機能やシステム丸ごとを作ってくれるような期待をやめましょう。
タスクを分解して、より確実なコードを生成しましょう。
9. レビュー必須
production環境で動くコード生成しているから！
リスクがあるから！
人間のレビュー！レビュー！レビュー！
Discussion