目次
0. はじめに
はじめまして、AI事業本部 極AIでMLエンジニアをしている吉原 (X:@sou_squared) です。
僕は普段からAIを活用した開発効率向上に興味を持っており、いろいろ試行錯誤をしております。そんな中、Codex MCPに設計や実装案を任せ、なるべく自分はコーディングしないようにしていたら、いつのまにかCodex利用率社内3位にランクインしていました。本稿では、その背景と具体的な活用方法、実際のワークフロー、そして得られた知見について詳しく解説します。
1.なぜCodex MCPを活用するのか
AI Codingを用いた開発に置いて責務を分離するためです。
僕はメインエディタとしてCursorを使用しています。そこで、計画やgithub管理をCursor (モデルはなんでもいい；Composer1など) 側に任せて、設計や実装案をCodex MCPに任せることで、それぞれの責務を分離し、なおかつ適切なコンテキストでCodex MCPに指示を出すことができるようになります。特に計画やgithub管理はCursorである必要はないです。ここでは計画と設計を別のAIに任せるという部分がポイントになります。
Codex MCPを活用することで、以下のようなメリットが得られます：
- 設計の質が上がる ー 複数の観点から評価された提案が得られる
- 実装前に設計の合意が取れるので、手戻りが少ない
- 提案根拠が分かりやすい ー 評価点と理由が明確に示される
一方で、以下のような課題もあります：
- Codex MCPの処理時間がかかる（数分）
- AGENTS.mdの全てを毎回汲んでくれるわけじゃない（後述します）
2. Codex MCPの活用方法
2.1 基本的なワークフロー
僕のCodex MCP活用方法は簡単で、CursorからCodex MCPを呼んで、設計や実装案をCodex MCPに、計画・実装・github管理をCursorに任せています。
具体的には以下のような役割分担を行っています：
- Cursor：実装計画の立案、実装、GitHub管理
- Codex MCP：設計案の検討、レビュー、評価
2.2 プロンプト例
CursorなどのCoding Agentsに渡すプロンプトは以下のようになっています。
作業の際に、Codex MCP や Context7 MCP, Serena MCP, kiri MCP を使って、調査させて、まとめて報告して。 あなたは MCP の調査結果をレビューして、あらゆる観点から評価して点 数と理由をつけて MCP に返答して。 点数が 80 点以上になったら、PR や Issue を作成 or 修正して。
80点の根拠はパレートの法則に基づいています。全体の成果の8割は重要な2割の要素で決まるという経験則です。80点以上なら十分な成果が期待できるためこの基準としています。
実際にCodex MCPが動作している様子は、上記の画像の通りです。複数のMCPを連携させて調査を行い、その結果を評価する一連の流れが自動化されています。
3. 知識ドキュメントの重要性
3.1 AGENTS.mdや知識ドキュメントを育てる
Codex MCPやCoding Agentsを効果的に活用するためには、プロジェクトの知識を適切にドキュメント化することが重要です。そこで、AGENTS.mdが参照する知識ドキュメントを管理しています。
2026年1月現在は以下のような構造で知識ドキュメントを管理しています（この構成は試行錯誤中なので、変更される可能性は大いにあります）：
AGENTS.md
.docs/
├── core-principles.md # エンジニアリング原則
│
├── coding-standards/ # コーディング規約
│ ├── naming-conventions.md # 命名規則
│ └── code-structure.md # コード構造
│
├── workflow/ # ワークフロー・プロセス
│ ├── pr-workflow.md # PR作成ワークフロー
│ ├── git-workflow.md # Gitワークフロー
│ └── tdd-ddd-workflow.md # TDD・DDDワークフロー
│
└── reference/ # リファレンス情報
├── security.md # セキュリティ
├── build-test.md # ビルド＆テスト
└── checklists.md # チェックリスト・コマンド例
このような知識ドキュメントを育てることで、Codex MCPやCoding Agentsがプロジェクトの文脈を理解し、より適切な提案を行えるようになります。
しかし、毎回必要なファイルを参照してくれるわけではないので、必要に応じて以下のようにファイルを指定したプロンプトを渡すこともあります。
.docs/01-coding-standards/naming-conventions.md を参考に、関数名を修正してください。
この辺はもっと自動で必要なファイルを見に行ってくれるような機構が必要かもしれません。
Pythonプロジェクト用のテンプレートは以下のリポジトリで公開しています：
https://github.com/sousquared/agentsmd-template-python
4. 実際の活用例
4.1 設計フェーズ（Codex MCP活用）
設計フェーズでは、Codex MCPに設計案を検討させ、最終的な設計をIssueコメントに一元化することで、後からその設計意図を追えるようにしています。
重要なポイントは、ローカルに実装計画や設計のmdを残すのは禁止し、最終設計を一元化するために、特定のコメントのIDを更新する形で作業を進めることです。
これにより、設計の履歴が追跡可能になり、チーム全体で最新の設計を共有できます。
プロンプト例は以下です：
localに実装計画や設計のmdを残すのは禁止です 最終設計を一元化するために、特定のコメントのIDを更新する形で作業を進めてください。
設計の履歴や差分を残したかったら、設計用PRを作って、そこで設計を更新し、最終版をIssueコメントにアップする方法も考えられます。この方法により、設計の変更履歴をGitで管理でき、レビューも行いやすくなります。
4.2 実装フェーズ（Cursor活用）
実装フェーズでは、採用された設計を踏まえて、実装計画を立てます。実装計画はIssueコメントを更新する形で記録します。実装プランをブレイクダウンさせてチェックボックスつくることで、Coding Agentsのコンテキストを最適に管理できますし、実装の進捗がわかりやすくなります。
プロンプト例は以下です：
採用された設計を踏まえて、実装計画を立ててください。issueコメントを更新する形で計画を記録してください - 可能な限りブレイクダウンする - 実装事項の進捗が一目瞭然なようにチェックリスト式フォーマット [ ] を使用する - 終了したらチェックリストを完了（[x]）にするように、冒頭に指示を書いておく
実装を開始する際は、作業をなるべく小さな単位に分けてレビューしやすくします。必要ならば全体のepic issueによる管理や、小さい単位でブランチ&PRを管理するようにします。
プロンプト例は以下です：
実装を開始してください。 作業をなるべく小さな単位に分けてレビューしやすること、必要ならば全体の epic issue による管理や、小さい単位でブランチ&PR を管理するようにして（sub issue は必ずしも作る必要はない）。
4.3 レビューフェーズ（Codex MCP活用）
レビューフェーズでは、実装されたコードに対して、Codex MCPに評価と改善案を提案させます。
プロンプト例は以下です：
〇〇の方がいいと思うけど...<略> Codex MCP に聞いて 80 点以上の案のみ提案して
通常、3個くらい提案してくれるし、推奨案も出てきます。これにより、複数の観点からコードを評価でき、より良い実装を選択できます。
5. 活用の成果と今後の展望
5.1 得られた成果
Codex MCPを活用することで、以下のような成果が得られました：
- 設計の質が向上：複数の観点から評価された提案により、より良い設計が選択できるようになった
- 手戻りの削減：実装前に設計の合意が取れるため、後から大幅な変更が必要になることが減った
- 提案根拠の明確化：評価点と理由が明確に示されるため、意思決定がしやすくなった
- 開発効率の向上：AIに任せられる部分を任せることで、より重要な作業に集中できるようになった
5.2 今後の展望
Codex MCPの活用をさらに進めるため、以下のような改善を検討しています：
- 知識ドキュメントの充実：より多くのプロジェクト知識をドキュメント化し、Codex MCPの理解度を向上させる
- 評価基準の最適化：プロジェクトの特性に応じて、評価基準を調整する
- ワークフローの自動化：設計から実装、レビューまでの一連の流れをより自動化する
Codex MCPの活用は、単なるツールの使用ではなく、開発プロセス全体の最適化を目指す取り組みです。今後も、AIと人間の協働による開発手法を追求し、より良いソフトウェア開発を実現していきたいです。