Surface
App / CLI / IDE / Cloud のどこで走らせるかを先に決める。
OpenAI Codex Field Guide 2026
App・CLI・IDE・Cloud の使い分けから、AGENTS.md、MCP、skills、worktree、automation、review 運用まで。公式 docs と GitHub 実例をもとに、実務で崩れにくい使い方へ整理した日本語ガイドです。
4
surface choices
7
workflow recipes
5
operation layers
13
sections
1
AGENTS system
Mobile Nav
全て / 13 セクション表示
Codex を使いこなすための最短地図
Codex は「チャットで質問する道具」ではなく、コードを読み、編集し、検証し、必要なら複数の作業面に分割して進める実務用エージェントです。強いのは回答の美しさより、手順の再現性と運用の積み上げです。
App / CLI / IDE / Cloud のどこで走らせるかを先に決める。
Goal・Context・Constraints・Done を揃えて依頼する。
会話ではなく AGENTS.md に恒常ルールを書く。
MCP と skills で「触れられる世界」と「再利用知識」を増やす。
worktree・review・automation で並列運用と安全性を設計する。
App / CLI / IDE / Cloud の使い分け
複数スレッド管理、worktree、automation、レビュー整理まで含めて運用したいとき。
端末中心で速く回したいとき。ローカルコマンド実行や小さな修正に強い。
編集中のファイルを軸に対話したいとき。既存エディタ導線を崩したくないチーム向け。
バックグラウンド実行や PR 単位の作業に寄せたいとき。ローカルを閉じても流せる。
使い分けの基準
最初に「どこで回すか」を決めるだけで、プロンプト・権限・検証方法が一気に整理されます。Codex は万能 UI ではなく、作業モードごとに最適面が違う道具です。
初回セットアップでやることを固定する
初回はコードを書かせるより、リポジトリの制約を認識させる方が重要です。インストール後すぐに実装依頼へ行くと、プロジェクト前提のない雑な差分が増えます。
最初の 30 分で叩く流れ
bash
codex
# まずは現状把握
> このリポジトリの構成、ビルド方法、主要な制約を要約してください
# ルールを外出し
touch AGENTS.md
# 次に AGENTS.md の初稿作成を依頼
> このリポジトリ向けに AGENTS.md の初稿を作ってください。
> 含めたいのは coding rules、test command、deploy 禁止事項、review 観点です。Goal / Context / Constraints / Done で書く
何を実現したいか。機能追加か、バグ修正か、レビューかを明示する。
対象ファイル、関連仕様、既存制約、周辺機能を先に渡す。
触ってよい範囲、触ってはいけない範囲、使ってよい技術を指定する。
完了条件と検証方法を書く。lint、type-check、手動確認もここに入れる。
Codex に渡す最初の依頼の型
markdown
Goal:
会員ダッシュボードの請求カードに「次回請求日」を表示したい
Context:
- Next.js App Router
- 対象は src/components/dashboard/BillingCard.tsx
- 既存 API は変更しない
Constraints:
- UI の大幅改変はしない
- 型 safety を崩さない
- 既存の loading / error 状態を維持する
Done when:
1. 表示ロジックが追加されている
2. type-check が通る
3. 影響範囲を短く説明できる恒常ルールは会話でなくファイルに置く
OpenAI 公式 docs でも、Codex の継続運用は AGENTS.md が中心です。会話に毎回書くと抜け落ちるルールを、ホームディレクトリ・プロジェクト root・配下ディレクトリの階層で管理します。
~/.codex/AGENTS.md。個人の共通作法や言語設定を書く。
repo root の AGENTS.md。テストコマンド、レビュー観点、禁止事項を書く。
特定ディレクトリだけ別ルールがあるときに配下へ追加する。
一時的に上書きしたいなら AGENTS.override.md を使う。
最初の AGENTS.md テンプレート
markdown
# Project Rules
- Use TypeScript and preserve existing App Router patterns
- Prefer small diffs over broad rewrites
- Run `npm run type-check` after touching app code
- Do not change deploy scripts or production env files
# Review Checklist
- Check loading / empty / error states
- Keep metadata and navigation intact
- Do not edit unrelated files
# Communication
- Explain impact before editing
- Summarize changed files and verification at the end代表的な依頼をレシピ化する
構成整理、依存関係、危険箇所の把握。
再現条件、原因仮説、最小修正の流れ。
対象コンポーネントと維持条件を固定する。
何を担保したいかを先に決める。
挙動不変と差分範囲を明記する。
変更内容より、リスクと回帰を探させる。
コード差分と docs のズレを埋める。
バグ修正レシピ
markdown
Goal:
特定条件でモーダルが閉じない不具合を修正したい
Context:
- 再現手順: ...
- 対象候補: src/components/.../Modal.tsx
- 関連 state: isOpen, pendingAction
Ask:
1. 原因仮説を 3 つ
2. 最も筋の良い修正方針
3. 影響範囲
4. 修正後に実行する確認項目
Code only after the plan is accepted.権限は最小から始める
Codex の品質はモデルだけでなく、approval mode と sandbox 設計に大きく依存します。便利さを優先して最初から広い権限を与えると、事故が起きたときに再現不能になります。
コマンド実行や外部アクセスの承認をどう扱うか。最初は慎重寄りがよい。
どこまでファイルやネットワークを触らせるか。用途ごとに変える。
深い推論が必要な場面だけ上げる。常時最大にしない。
生成より検証が重要。type-check、lint、manual QA を先に決める。
repo の外へ安全に触れさせる
MCP は Codex の知能を上げるものではなく、アクセスできる世界を広げる仕組みです。だから導入の判断基準は「便利そう」ではなく「手動ループをどれだけ消せるか」で考えるべきです。
最新仕様や SDK docs を引かせたいとき。ライブラリ更新の影響調査に強い。
画面確認や DOM/console の確認を Codex から行いたいとき。
Figma やデザインソースから UI 情報を取る導線に向く。
DB、社内 docs、外部システムなど限定的なデータ参照に使う。
MCP 導入時に先に決めること
markdown
1. 何の手作業を消すのか
2. 読み取り専用で足りるか
3. どの surface から使うか
4. 失敗時に人間がどう介入するか
5. AGENTS.md に利用方針を書くか繰り返す知識を部品化する
常に読むべきルール。
特定タスクでだけ呼び出す再利用知識。
外部ツールやデータへの接続。
切り分けの原則
全員が毎回知るべきことは AGENTS.md。ある種の仕事でだけ効く知識は skill。repo 外に触れる必要があるなら MCP。ここを混ぜると運用が破綻します。
skill 化しやすいテーマ
text
- design review
- migration checklist
- API contract review
- accessibility pass
- deployment verification
- analytics QA複数エージェントを物理的に分ける
同じ checkout 上で複数の Codex セッションを同時に動かすと、どの差分がどの意図で入ったか追えなくなります。並列運用するなら、最初から worktree で作業面を分ける方が安全です。
仕様確認と統合作業。ここで最終判断を持つ。
調査だけを切り離す。依存更新や仕様把握向け。
機能追加や UI 改修など、差分を作る面。
別視点でリスク確認を回す。確証バイアスを減らせる。
worktree の最小パターン
bash
git worktree add ../quadnewweb-review codex/review-pass
git worktree add ../quadnewweb-feature codex/dashboard-billing
# review 用 Codex
cd ../quadnewweb-review && codex
# implementation 用 Codex
cd ../quadnewweb-feature && codex定型タスクを夜間・定時運用へ移す
Automation は「便利だから入れる」ものではなく、既に手動で安定している手順を定期実行に移すための層です。いきなり本番タスクを自動化するのではなく、まずはレビューや整理のような低リスク業務から始めるべきです。
前日の PR、issue、失敗ジョブを朝に整理する。
main への変更と deploy 手順の齟齬を検査する。
コードと docs のズレを洗い出す。
automation に向く依頼文の型
markdown
対象:
昨日 merge された変更
やること:
1. 差分を要約
2. リスクを 3 点抽出
3. docs 更新漏れを確認
4. 必要なら inbox item を作る
禁止:
- 自動 commit しない
- deploy しない
- 本番設定を変えない実装役とレビュー役を分ける
Codex は生成 agent としてだけでなく、レビュー agent としても強いです。特に GitHub 上の変更を前提に「壊れやすい箇所」「仕様に対する欠落」「テスト不足」を見つけさせる使い方が有効です。
変更差分を読ませて回帰と設計崩れを確認する。
意図、影響範囲、要確認点を短く再構成する。
変更に対して不足しているテスト観点を洗い出す。
本番フローに影響する変更かどうかを事前判定する。
レビュー依頼のテンプレート
markdown
この変更をコードレビューしてください。
重点観点:
1. バグや回帰
2. 型・状態管理の不整合
3. エッジケース漏れ
4. テスト不足
出力形式:
- Findings を重要度順に
- Open questions
- 変更概要は最後に短くCodex 導入が崩れる典型パターン
毎回長文で説明し、恒常ルールを AGENTS.md に出していない。
計画なしで手を動かさせ、差分が太くなる。
検証設計より先にフルアクセスを与える。
複数タスクが混線してレビュー不能になる。
崩れない運用の本質
Codex の失敗はモデル性能より、運用境界の曖昧さから起きます。どこまで任せるか、何を固定化するか、どう検証するかを先に決めるだけで品質は大きく変わります。