Codex CLI ベストプラクティス — 設計・変更・検証を小さく速く¶

原則（4点）¶

計画先行: まず update_plan で5–7手に分解。反復で更新。
差分最小: apply_patch は1コミット相当。無関係変更は避ける。
近接検証: 変更点の“直近”をテスト→広げる（ビルド/リンク/簡易E2E）。
透明性: 昇格/破壊/外部I/Oは1アクション=1メッセージで事前合意。

プロンプトの4要素と推論レベル¶

Codexへの依頼は以下の4要素を明確にすることで、結果の信頼性が劇的に向上する：

Goal: 何を変更または構築したいか
Context: どのファイル、ドキュメント、エラーメッセージが関連するか（@ファイル名 も活用）
Constraints: 従うべきアーキテクチャ、規約、安全要件は何か
Done when: 何をもって完了とするか（テストの通過、新機能の動作確認、バグ修正など）

推論レベルの設定: タスクの難易度に応じて推論の深さを変更する。 - Low: 高速でスコープの狭いタスク向け - Medium/High: 複雑な変更や複数ファイルにまたがるデバッグ向け - Extra High: エージェント的な自律思考や長時間の検証が必要なタスク向け

計画（Plan）フェーズの高度な活用¶

難易度の高いタスクや曖昧な課題の場合、いきなりコードを書かせるのではなく、事前の計画立案を徹底する。

Planモード: /plan または Shift+Tab でPlanモードに切り替え、コード実装前にアプローチを合意する。
逆質問（Interview You）: 要件がふわっとしている場合、「実装の前に、要件を明確にするために私に質問してください」「私の前提を疑ってください」とプロンプトに含め、アイデアを具体化させてから進める。
PLANS.mdの活用: 複数ステップにわたる大規模作業や定型業務手順の場合、リポジトリに PLANS.md や実行テンプレートを配置し、Codexにその手順通りに行動させる。

ひな型（例）¶

1) Plan: ○○を実装（境界/例外を明記）
2) Read: 関連ファイル 200行以内で段階確認
3) Patch: 変更点のみ適用（コメントは最小限）
4) Verify: テスト/ビルド/静的解析を近接→広域の順
5) Document: README/AGENTS.md/コメントを軽量更新

実例（小規模修正）¶

Plan: ホームのリンク .md → / に変更（2箇所）
Read: docs/index.md の該当箇所
Patch: aタグのhrefを修正
Verify: mkdocs build, ローカル遷移確認
Document: 変更理由をコミットメッセージに明記

よくある落とし穴と回避¶

パッチ肥大: 機能追加・整理・スタイル修正を一緒にしない。別計画に分割。
失敗の隠蔽: 失敗ログを示し、代替案/ロールバックを即提案。
"ついで修正": 目的にない修正はTODO化し、別PR/別タスクに回す。

効率化モード（危険モード）¶

開発効率を最大化したい場合、以下のコマンドで承認プロンプトを完全にスキップできます：

# 最重要：インタラクティブセッション開始（Claude Codeの--dangerously-skip-permissions相当）
codex --dangerously-bypass-approvals-and-sandbox
# → セッション開始後、すべての操作が自動承認される
# → 複数タスクを対話的に連続実行可能

# より安全な代替（推奨）
codex --full-auto  # バランス型自動実行セッション
codex -a never -s workspace-write  # ワークスペース内のみ自動実行

注意: --dangerously-bypass-approvals-and-sandboxは全ての安全機構を無効化します。本番環境では使用せず、開発環境でのみ使用してください。

検証リスト（このリポジトリ事例）¶

MkDocs: mkdocs build --strict（ローカル） / CIは非ブロッキング→将来厳格化
リンク: pytest --check-links docs/ -q（外部は夜間ジョブで要約）
翻訳対: JP/EN記事ペア検証スクリプトを実行（AI-Daily-Newsは除外）

コストと上限¶

ChatGPT連携時は追加API課金なし。モデル/利用上限はプランと利用条件に準拠。
ベンチはローカルで計測（壁時計時間・トークン数・成功率）。結果はIssueへ記録して継続評価。