Codex レベルの使い方

約10分

Codex を単発のコード生成ではなく、実務の実装・検証・PR 作成に使いたい開発者

Codex を使い始めると、最初は「このコードを直して」と頼むだけでも便利に感じます。しかし実務で安定して使うには、単発のコード生成ではなく、作業の分け方、検証方法、レビュー方法まで含めて設計する必要があります。

Codex レベルは、その成熟度を段階的に整理するための見取り図です。Level 0 は相談、Level 1 はリポジトリ理解、Level 2〜3 はローカルでの編集と検証、Level 4〜6 は文脈・GitHub・ハーネス設計、Level 7 以降は外部ツール・並列化・定常運用・基盤設計へ進みます。

Codex レベルとは

Codex レベルは「Codex にどこまで任せるか」を決めるための段階です。重要なのは、レベルが上がるほど人間が不要になるわけではない点です。むしろ、レベルが上がるほど人間は実装の細部から、仕様、検証、権限、レビューの設計へ移ります。

段階	Codex の使い方	人間が設計するもの
Level 0	リポジトリ外のコード相談	前提、質問、利用判断
Level 1	ファイル読み取り、コード調査	対象範囲、調査観点
Level 2〜3	限定編集、テスト実行、小さな機能の完成	変更範囲、受け入れ条件、検証コマンド
Level 4〜6	AGENTS.md、GitHub 協業、ハーネス	作業契約、レビュー責任、禁止事項、承認条件
Level 7〜8	ブラウザ、MCP、外部ツール、並列作業	ツール権限、担当範囲、競合回避
Level 9〜10	CI、定期実行、組織運用	運用ルール、監査、品質基準

この表はスキル判定ではなく、委任範囲を広げるためのチェックリストとして使います。

公式ドキュメントから見る基本原則

OpenAI の Codex ドキュメントでは、Codex はプロンプトを受け取り、ファイル読み取り、ファイル編集、ツール呼び出しを行いながら作業を進めるエージェントとして説明されています。つまり、Codex は「答えを返すチャット」ではなく、作業環境の中で行動する相手です。

そのため、指示には次の情報を含めます。

変更したい対象ファイルや機能
再現手順や現状のエラー
期待する動作
実行してほしい検証コマンド
変更してはいけない範囲
完了時に報告してほしい証拠

たとえば、次のように依頼します。

src/app/projects/[slug]/page.tsx のプロジェクト詳細ページを修正してください。

条件:
- 既存の ProjectCard コンポーネントは変更しない
- featured: false のプロジェクトを詳細ページで表示する
- tests/projects/slug.test.ts に失敗ケースを追加する
- 変更後に npm test -- tests/projects/slug.test.ts を実行する
- 未検証の点があれば最後に明記する

「直して」だけでは、Codex は何をもって完了と判断すべきか分かりません。完了条件を入れることで、Codex の作業と人間のレビューが同じ方向を向きます。

公開事例から見える実践パターン

LinkedIn や X などの公開投稿では、Codex を使いこなしている人ほど「長い魔法のプロンプト」ではなく、作業環境を整えることに時間を使っています。よく見られる実践は次の 4 つです。

Issue のように依頼を書く
AGENTS.md を短い目次にし、詳細ルールは別ファイルに分ける
1 タスクを 1 時間程度、または数百行以内の変更に収める
完了報告にテスト結果、差分、未検証事項を含める

これは公式ドキュメントの方針とも一致します。Codex は、検証できる作業、小さく分けられた作業、具体的なコンテキストがある作業で品質が安定します。

Level 0〜1: まず相談からリポジトリ理解へ

最初の段階では、Codex にいきなり大きな実装を任せるのではなく、コードベースの理解に使います。

このリポジトリでログイン処理がどこに実装されているか説明してください。
関連ファイル、主要な関数、テストファイルを表で整理してください。
まだ変更はしないでください。

この使い方は、OpenAI が紹介している Ask mode に近い考え方です。大きな変更の前に、まず構造を説明させ、計画を作らせます。理解が合っていることを確認してから Code mode や CLI で編集に進むと、手戻りが減ります。

Level 2〜3: 検証込みで小さな機能を任せる

次の段階では、Codex に「実装」だけでなく「検証」まで任せます。ただし、任せる範囲は小さくします。

良い依頼:

プロジェクトカードに技術スタックのバッジ表示を追加してください。

範囲:
- components/ProjectCard.tsx
- app/projects/page.tsx
- tests/project-card.test.tsx

完了条件:
- tags 配列の最初の3つをバッジで表示する
- 既存のカードサイズとレイアウトは変えない
- npm test -- tests/project-card.test.tsx が通る

この段階で重要なのは、Codex の報告をそのまま信じないことです。差分を読み、実行されたコマンドを確認し、テストが本当に対象範囲を検証しているかを見ます。

Level 4〜6: AGENTS.md とハーネスを作る

Codex を継続的に使うなら、毎回同じ説明をプロンプトに書くのは非効率です。AGENTS.md にリポジトリの作業契約を書きます。

# AGENTS.md

## Repository Rules

- 実装前に関連ファイルと既存パターンを確認する
- 変更は最小限にし、無関係なリファクタリングをしない
- TypeScript 変更後は npx tsc --noEmit を実行する
- UI 変更後は next dev でブラウザ表示確認する
- 秘密情報、API キー、個人情報をファイルに書かない
- 完了時は変更点、検証結果、未検証事項を報告する

AGENTS.md は長ければよいわけではありません。長すぎる文書は、Codex にとっても人間にとっても扱いにくくなります。実務では、ルートの AGENTS.md を目次にし、テスト、セキュリティ、UI、GitHub などの詳細ルールを別ファイルに分けると管理しやすくなります。

Level 6 では、AGENTS.md に加えて検証コマンド、禁止コマンド、承認が必要な操作、CI のチェックを明文化します。これがハーネス設計です。

Level 7〜8: ツール連携と並列作業を使う

Codex は CLI、IDE、web、app など複数の入口で使えます。ローカルスレッドは自分の作業ツリーを読み書きし、クラウドスレッドは GitHub 上のリポジトリを隔離環境で扱います。並列作業を始めるときは、同じファイルを複数のスレッドで同時に変更しないことが基本です。

並列化しやすい作業:

A ブランチで API のテスト追加
B ブランチでドキュメント更新
C ブランチで依存関係の影響調査

並列化しにくい作業:

同じコンポーネントの UI 修正を複数スレッドで行う
同じ migration ファイルを複数スレッドで編集する
仕様が未確定のまま複数案を同時に実装する

Codex app や cloud thread は、背景で作業を進めるのに向いています。一方で、レビューと統合は人間が担当します。

Level 9〜10: 運用に組み込む

高いレベルでは、Codex を日常の開発フローに組み込みます。例として、低カバレッジのテスト追加、依存関係更新の影響調査、Issue の一次分類、PR レビューの下書き、ドキュメント更新などがあります。

ただし、自動化するほど権限設計が重要になります。

項目	確認すること
権限	Codex が読めるリポジトリ、書けるブランチ、実行できるコマンド
監査	どの指示で、どの差分が作られ、どの検証が行われたか
レビュー	人間が確認する境界、レビュー必須のファイル
失敗時	CI 失敗、競合、未検証事項をどう扱うか

Level 10 は「Codex に全部任せる」段階ではありません。Codex が安全に作業できる環境、ルール、検証、レビューの仕組みを設計する段階です。

今日から使えるレベルアップ手順

既存リポジトリで Codex に構造を説明させる
小さな修正を 1 つ選び、対象ファイルと完了条件を書く
実装後に実行してほしい検証コマンドを指定する
差分、テスト結果、未検証事項を報告させる
繰り返し使うルールを AGENTS.md に移す

この順序で進めると、Codex の使い方は「便利なコード生成」から「検証可能な開発ワークフロー」に変わります。

参考情報

まとめ

Codex レベルは、Codex への委任範囲を段階的に広げるための考え方
レベルを上げる中心は、長いプロンプトではなく、完了条件、検証、AGENTS.md、レビュー設計
小さく分けたタスク、具体的なファイル指定、検証コマンドが Codex の品質を安定させる
並列化や自動化に進むほど、権限、監査、失敗時の扱いを先に決める

このページの外部仕様・背景情報は、参考文献を参照してください。[1][2]

参考文献

OpenAI, Codex documentation
OpenAI, OpenAI API documentation

クイズ