【2026年6月版】OpenAI Codexの使い方完全ガイド：個人開発で実装・テスト・レビューを効率化

OpenAI Codexは、質問にコードを返すだけのAIではありません。

プロジェクトのファイルを読み、コードを編集し、コマンドを実行し、テスト結果を確認するところまで進められる「コーディングエージェント」です。うまく使えば、個人開発における調査、実装、デバッグ、レビューの時間を大きく減らせます。

一方で、何でも丸投げすればよいわけではありません。Codexが実力を発揮するには、必要な情報を渡し、作業範囲を決め、最後に検証することが重要です。

この記事では、個人開発者がCodexを使いこなすために必要なポイントを、初心者にも分かる順番で解説します。

OpenAI Codexとは

Codexはコードを書くだけのAIではない

通常のチャットAIに「この関数を書いて」と頼むと、回答欄にコードが表示されます。実際のファイルへの反映、テスト、エラー対応は、自分で行うことが多いと思います。

Codexは指定したプロジェクトを作業場所として、次のような一連の作業を進められます。

• コードを読んで構造を把握する
• 関係するファイルを探す
• コードを追加・修正する
• テスト、Lint、ビルドなどを実行する
• エラーの原因を調査して再修正する
• Gitの差分を確認して変更内容を説明する

つまり、コードの提案だけでなく「作業と検証」まで担当できるのが大きな違いです。

ChatGPTでコードを質問する場合との違い

ChatGPTは、技術の説明、設計相談、コード例の作成などに向いています。Codexは、それに加えてローカルのファイルや開発ツールを扱い、実際のプロジェクトを変更することに特化しています。

使い分けを難しく考える必要はありません。

• 一般的な技術質問やアイデア整理　⇒　通常のチャットでも十分
• 手元のプロジェクトを読ませたい　⇒　Codex
• 複数ファイルを修正してテストしたい　⇒　Codex
• Git差分をレビューしてほしい　⇒　Codex

Codexができること

[公式の概要]では、Codexの主な用途として、コード作成、コードベースの理解、レビュー、デバッグ、反復作業の自動化が挙げられています。

個人開発では、特に次の場面で効果を感じやすいと思います。

• 新しいライブラリや既存コードの調査
• 小さな機能追加
• 再現可能なバグの修正
• テスト不足の補完
• リファクタリング前の影響調査
• READMEや変更履歴の更新

最初から大規模な開発を任せるより、結果を確認しやすい小さな作業から始めるのがおすすめです。

Codexを使いこなすためのロードマップ

Codexの機能をすべて覚えてから使い始める必要はありません。次の順番で利用範囲を広げると、失敗を抑えながら慣れることができます。

コードの理解、小さな修正、実装とテスト、ルール化、自動化の順に利用範囲を広げます。

ステップ1：コードについて質問する

最初はファイルを変更させず、コードの説明や影響範囲の調査に使います。

このプロジェクトでユーザー認証を処理しているファイルを探してください。
ログイン要求からセッション保存までの流れを、ファイル名付きで説明してください。
コードは変更しないでください。

Codexがどのようにファイルを探し、根拠を示すかを確認できます。

ステップ2：小さな修正を任せる

次に、文言修正、型エラーの解消、単純なUI変更など、差分を確認しやすい作業を任せます。

設定画面の保存ボタンを「更新する」に変更してください。
関係のないファイルは変更しないでください。
変更後に差分を要約してください。

ステップ3：実装からテストまで任せる

慣れてきたら、実装だけでなく検証まで依頼します。

検索フォームに入力内容をクリアするボタンを追加してください。
既存のUIパターンに合わせ、必要ならテストも追加してください。
実装後に関連するテストとLintを実行し、結果を報告してください。

ここで重要なのは「コードを書いて」で終わらず、テストや確認方法まで指定することです。

ステップ4：プロジェクト固有のルールを覚えさせる

毎回伝えているコマンドや規約は、AGENTS.mdにまとめます。これにより、Codexがプロジェクトを開いた時点で、テスト方法や変更時の注意事項を把握できます。

ステップ5：繰り返す作業を効率化する

最後に、Worktree、Skills、MCP、サブエージェント、codex execなどを必要に応じて導入します。

ただし、高度な機能は目的ではありません。普段の作業で同じ手順を繰り返すようになってから自動化すれば十分です。

CLI・IDE・Codex Appのどれを使うべきか

Codexには複数の利用環境があります。主な違いは操作方法と周辺機能なので、作業スタイルに合わせて入口を選びます。

左から、ターミナル中心のCLI、エディタ内で使うIDE Extension、複数タスクを管理するCodex Appのイメージです。

IDE Extension

[Codex IDE Extension]は、VS Code、Cursor、WindsurfなどのVS Code互換エディタ内で利用できます。JetBrains IDE向けの連携も案内されています。

IDEでは、開いているファイルや選択中のコードをコンテキストとして渡しやすいため、短い指示でも意図が伝わりやすいのが利点です。

向いている人：

• 普段のエディタから離れたくない
• 選択したコードをすぐに説明・修正してほしい
• 変更を見ながら対話したい

初めてCodexを使う人には、最も分かりやすい選択肢です。

Codex CLI

[Codex CLI]は、ターミナルからCodexを操作するツールです。

codex

プロジェクトのルートで起動すれば、対話しながらファイルの調査、編集、コマンド実行を依頼できます。

向いている人：

• ターミナル操作に慣れている
• 実行されたコマンドやログを細かく確認したい
• ショートカットやスラッシュコマンドを活用したい
• 将来的にcodex execで自動化したい

Codex App

[Codex App]は、複数のプロジェクトやスレッドをまとめて扱えるデスクトップアプリです。2026年6月時点ではmacOSとWindowsに対応しています。

Git差分の確認、統合ターミナル、Worktree、Webページのプレビューなど、Codexを中心に開発を進めるための機能がそろっています。

向いている人：

• 複数の依頼を並行して進めたい
• Codexが変更した差分を画面上でレビューしたい
• Worktreeを使って作業を分離したい
• Webアプリの表示確認まで任せたい

初心者におすすめの選び方

迷った場合は、次の基準で決めるのが良いと思います。

最初から全部を使う必要はありません。まず一つに慣れ、必要になったら別の環境を試してみましょう。

共有される設定とスレッドの違い

CLI、IDE Extension、Codex Appは、モデル、Sandbox、Approval、MCPなどの設定をconfig.toml経由で共有します。CLIとIDE Extensionは、保存されたログイン情報も共有します。

一方、すべての会話が無条件に全環境へ同期されるわけではありません。Codex AppとIDE Extensionは同じプロジェクトで連携できますが、ローカルスレッド、クラウドスレッド、作業ディレクトリには違いがあります。

「設定は共有されやすいが、会話と実行環境はスレッドごとに確認する」と覚えておくと安全です。

最初に覚えたい基本操作

Codexのインストールとログイン

CodexはChatGPTアカウント、またはOpenAI APIキーで利用できます。利用可能なプランや上限は変更される可能性があるため、[料金・プランの公式ページ]を確認してください。

CLIのインストール方法はOSや配布方式によって異なります。2026年6月14日時点で公式マニュアルに案内されているインストールコマンドは次の通りです。

macOS・Linux：

curl -fsSL https://chatgpt.com/codex/install.sh | sh

Windows：

irm https://chatgpt.com/codex/install.ps1 | iex

配布方法は変更される可能性があるため、実行前に[Codex CLIの公式ページ]で最新の手順を確認してください。インストール後は、次のコマンドで起動できます。

codex

有効なログイン情報がなければ、通常はChatGPTへのサインインが案内されます。明示的にログインする場合は次を使います。

codex login

ChatGPTアカウントとAPIキーの違い

個人が対話的に使うなら、まずChatGPTアカウントでのログインが分かりやすいです。ChatGPTプランに応じたCodex利用枠を使え、APIキー認証では利用できないクラウド連携機能もあります。

APIキーでは、OpenAI PlatformのAPI料金に基づいて従量課金されます。CLI、IDE、Codex Appでのローカル作業や、スクリプト、CIなどのプログラム実行に利用できますが、Codex Cloudなど一部の機能は利用できません。

APIキーを使う場合は、プロンプトやソースコードに直接書かず、公式のログイン機能や環境変数など、適切な秘密情報管理を利用してください。

プロジェクトを開いてCodexを起動する

CLIでは、対象プロジェクトのディレクトリへ移動してから起動します。

cd /path/to/your-project
codex

Codexが意図した場所で動いているか不安な場合は、/statusで作業ディレクトリ、モデル、権限などを確認できます。

ファイルや選択範囲を指定する

依頼時に対象ファイルを明示すると、調査の精度が上がり、余計なファイルを読む量も減らせます。

@src/components/SearchForm.tsx を確認し、
検索処理がどこで実行されているか説明してください。

CLIでは@によるパス補完や/mentionを利用できます。IDEでは、開いているファイルや選択範囲をスレッドへ追加できます。

スクリーンショットやエラーを渡す

UI崩れやエラーダイアログは、画像を添付すると説明しやすくなります。CLIでは画像ファイルを指定して起動することもできます。

codex -i screenshot.png "このレイアウト崩れの原因を調べてください"

エラーを渡す場合は、メッセージだけでなく「どの操作で発生したか」「本来どうなるべきか」も添えましょう。

モデルと推論レベルを選ぶ

2026年6月時点の[モデル案内]では、複雑な作業にはgpt-5.5、軽量な作業にはgpt-5.4-miniが推奨されています。ただし、利用できるモデルはプランや時期によって変わります。

モデル選びで迷ったら、基本はデフォルトのままで構いません。

推論レベルは以下の基準で選ぶと良いです。

• 小さく明確な修正：低めから中程度の推論
• 複数ファイルの実装：中程度
• 原因が分からないバグや設計変更：高め

推論レベルを高くすると、複雑な問題に強くなる一方、時間と利用量が増えます。常に最大へ設定するより、難しい作業だけ上げる方が効率的です。

スレッドを継続・再開する

一つの目的に対する会話は、同じスレッドで続けると文脈を保てます。

先ほどの修正に、入力が空の場合のテストも追加してください。

CLIで過去のスレッドを再開する場合は、次のコマンドを使えます。

codex resume
codex resume --last

別の方針を試したいときは/fork、関係のない作業を始めるときは新しいスレッドを使います。同じ会話へ無関係な依頼を詰め込みすぎないことが重要です。

よく使うスラッシュコマンド

すべて暗記する必要はありません。最初は次のコマンドだけで十分です。

利用できるコマンドは更新されるため、入力欄で/を入力して一覧を確認してください。

良い結果を得る依頼の書き方

Codexへの依頼で大切なのは、長い文章を書くことではありません。判断に必要な情報を、抜けなく渡すことです。

依頼の中心に、目的・背景・制約・完了条件の4要素をそろえると、Codexが判断しやすくなります。

「目的・背景・制約・完了条件」を伝える

[公式のベストプラクティス]では、依頼に次の4要素を含める方法が推奨されています。

1. 目的：何を実現したいか
2. 背景：関係するファイル、エラー、現在の仕様
3. 制約：変更してはいけないもの、守る規約
4. 完了条件：何が確認できれば終わりか

例えば、次の依頼は情報が足りません。

ログインのバグを直してください。

次のようにすると、Codexが迷いにくくなります。

目的：
ログインに失敗したとき、画面にエラーメッセージを表示してください。

背景：
対象は @src/pages/Login.tsx と @src/api/auth.ts です。
現在はAPIが401を返してもローディング表示のままになります。

制約：
APIのレスポンス形式は変更しないでください。
既存の通知コンポーネントを使用してください。

完了条件：
401の場合にメッセージが表示され、関連テストが通ること。
実装後にテストとLintを実行してください。

見出しを毎回付ける必要はありません。4要素が伝われば、自然な文章でも問題ありません。

関係するファイルを具体的に示す

大きなプロジェクトで「決済処理を直して」とだけ依頼すると、Codexは広い範囲を調べる必要があります。

入口となるファイル、エラーが出たファイル、似た実装の場所を示すと、速く正確になります。

@src/features/profile/EditProfile.tsx に、
@src/features/account/EditAccount.tsx と同じ入力検証を追加してください。

場所が分からない場合は、最初に調査だけ頼みます。

プロフィール更新処理に関係するファイルを探し、
変更候補と影響範囲を説明してください。まだ編集しないでください。

バグ修正は再現手順を伝える

バグ修正では、推測より再現が重要です。

不具合：
商品一覧の2ページ目でカテゴリーを変更すると、
商品が存在するカテゴリーでも「該当する商品はありません」と表示されます。

再現手順：
1. npm run devを実行
2. /productsを開く
3. 一覧の2ページ目へ移動する
4. サイドバーから別のカテゴリーを選ぶ

期待する結果：
カテゴリー変更時にページ番号が1へ戻り、対象商品が表示されること。
まず不具合を再現し、原因を特定してから最小限の修正を行ってください。

再現できない場合も、Codexに推測で変更させず、分かったことと追加で必要な情報を報告させる方が安全です。

テストと確認まで依頼する

Codexは「実装して」と言われると、コードの変更を終点だと解釈する場合があります。完了条件に検証を含めましょう。

変更後に、関連するテスト、Lint、型チェックを実行してください。
失敗した場合は、今回の変更が原因か既存の問題かを分けて報告してください。
最後に変更ファイルと検証結果を要約してください。

複雑な作業ではPlan modeを使う

複数の機能に影響する変更や、要件がまだ曖昧な作業では、いきなり実装させずPlan modeを使います。

/plan
このアプリにオフライン対応を追加したいです。
現在の構成を調査し、変更対象、リスク、段階的な実装手順を提案してください。

計画を確認した後で、範囲を調整して実装へ進めます。実装方針に複数の選択肢がある場合にも有効です。

そのまま使えるプロンプト例

コードの説明：

@src/services/payment.ts の役割を説明してください。
入力から外部API呼び出し、結果の保存までを順番に整理し、
変更時に注意すべき点を3つ挙げてください。コードは変更しないでください。

機能追加：

商品一覧に価格順の並べ替えを追加してください。
既存のフィルターUIとデザインを合わせ、URLのクエリに状態を保存してください。
関連テストを追加し、テストとLintが通るところまで確認してください。
関係のないリファクタリングは行わないでください。

レビュー：

現在の未コミット変更をレビューしてください。
バグ、仕様の抜け、セキュリティ、テスト不足を優先し、
問題がある場合はファイルと理由を示してください。
コードは変更しないでください。

個人開発で役立つ実践的な使い方

初めて見るコードを説明してもらう

新しいリポジトリや、しばらく触っていなかった個人プロジェクトでは、いきなり「全部説明して」と頼むより、利用者の操作やデータの流れを一つ選びます。

ユーザーが投稿を作成してから一覧に表示されるまでの処理を追ってください。
関係するファイル、データの受け渡し、保存先を順番に説明してください。

最後にファイル一覧や簡単な図を作らせると、理解を確認しやすくなります。

新しい機能を実装してもらう

機能追加では、既存パターンに合わせるよう指示することが重要です。

既存のユーザー削除機能を参考に、投稿削除機能を追加してください。
確認ダイアログ、API呼び出し、成功・失敗メッセージの形式を既存実装に合わせてください。

Codexが新しい仕組みを発明する前に、プロジェクト内の類似実装を探させると、コードの一貫性を保ちやすくなります。

バグの原因を調べて修正してもらう

良いバグ修正の流れは次の通りです。

1. 再現する
2. 原因を絞る
3. 最小限の修正を行う
4. 回帰テストを追加する
5. 同じ手順で直ったことを確認する

依頼にもこの順番を含めましょう。

まずテストまたはローカル実行で問題を再現してください。
原因を説明した後、最小限の修正を実装してください。
可能なら、この不具合を再現するテストを追加してください。
最後に同じ手順で修正を確認してください。

テストを追加してもらう

テスト対象だけでなく、守りたい挙動を伝えます。

@src/utils/normalizeName.ts のテストを追加してください。
通常入力、前後の空白、空文字、Unicodeを含む名前を確認してください。
既存のテスト命名と記述スタイルに合わせてください。

Codexに既存テストを先に読ませることで、使用ライブラリや書き方のズレを防げます。

リファクタリングを任せる

リファクタリングでは「何を変えないか」を明確にします。

このモジュールの重複した検証処理を整理してください。
公開API、エラーメッセージ、動作は変更しないでください。
作業前後で同じテストを実行し、挙動が変わっていないことを確認してください。

大規模な整理は、調査、計画、実装を別のステップに分ける方が安全です。

/reviewで変更点を確認してもらう

実装したエージェントとは別の視点で、変更をレビューさせることができます。

/review

CLIでは未コミット変更、特定のコミット、ベースブランチとの差分などを選べます。Codex Appではレビュー結果を差分上で確認できます。

ただし、レビュー結果も自動的に正しいとは限りません。指摘の根拠を読み、必要なら次のように再確認します。

1つ目の指摘について、実際に問題が発生する入力例を示してください。
既存テストで守られていないかも確認してください。

ドキュメントやREADMEを更新してもらう

コード変更後の説明更新もCodexが得意な作業です。

今回追加した検索オプションについてREADMEを更新してください。
実際のコマンドと現在の実装を確認し、存在しない設定は書かないでください。

「コードを情報源にする」「実在するコマンドを確認する」と伝えると、古い説明や想像による記述を減らせます。

AGENTS.mdで毎回の説明を減らす

AGENTS.mdとは何か

AGENTS.mdは、Codexが作業前に読み込むプロジェクト向けの指示書です。人間向けのREADMEに対して、エージェント向けの作業ガイドと考えると分かりやすいでしょう。

主に次の情報を置きます。

• プロジェクトの構成
• 開発サーバーの起動方法
• テスト、Lint、ビルドのコマンド
• コーディング規約
• 変更してはいけないもの
• 作業完了時に確認すること

/initでひな型を作る

CLIでは、プロジェクトのルートで次を実行すると、AGENTS.mdのひな型を作成できます。

/init

生成された内容をそのまま使うのではなく、実際のプロジェクトに合わせて修正します。

個人開発向けのシンプルなテンプレート

# AGENTS.md

## Project
- これは、React と Vite を使用した TypeScript アプリケーションです。
- アプリケーションのコードは `src/` ディレクトリ内にあります。
- テストコードは、対象ファイルと同じディレクトリに保存されています。

## Commands
- 依存関係をインストールする: `npm install`
- 開発サーバーを起動する: `npm run dev`
- テストを実行する: `npm test`
- lintを実行する: `npm run lint`
- 型チェックを実行する: `npm run typecheck`

## Working Rules
- 新しい抽象化を導入する前に、既存のパターンに従うこと。
- タスク上必要でない限り、パブリックAPIの構造を変更しないこと。
- 事前に確認せずに、本番環境への依存関係を追加しないこと。
- 変更は依頼されたタスクの範囲内に限定すること。

## Done
- 動作が変更された場合は、テストを追加または更新する。
- 関連するテストのうち、最小限のものを実行する。
- 必要に応じて、lintや型チェックを実行する。
- 変更されたファイルと検証結果をまとめる。

ルールを増やしすぎない

長いAGENTS.mdほど高性能になるわけではありません。曖昧な理念や、ほとんど発生しない例外を大量に書くと、重要な指示が埋もれます。

最初は次の3つだけでも十分です。

1. よく使うコマンド
2. 必ず守る制約
3. 完了時の確認方法

Codexが同じ失敗を繰り返したときに、再発防止のルールを1行追加して育てていきます。

ファイルを置く場所

リポジトリのルートに置いたAGENTS.mdは、プロジェクト全体に適用されます。特定のディレクトリだけ別のルールが必要なら、そのディレクトリ内にも配置できます。作業場所に近い指示が優先されます。

個人の全プロジェクトへ共通して適用したい指示は、~/.codex/AGENTS.mdに置きます。ただし、プロジェクト固有のコマンドや規約は、リポジトリ側に書く方が管理しやすいです。

詳しい読み込み順は、[AGENTS.mdの公式ガイド]で確認できます。

安全に使うための最低限の設定

Codexはファイルを編集し、コマンドを実行できます。便利さと安全性の両方を理解して使う必要があります。

SandboxとApprovalの意味

Codexでは、ファイル編集やコマンド実行をどこまで許可するかを「権限モード」として選びます。最初に覚えるべき代表的なモードは、次の3つです。

ここでいう「workspace」は、Codexに作業させているプロジェクトフォルダのことです。たとえば/path/to/your-projectでCodexを起動した場合、基本的にはそのプロジェクト内を作業範囲として扱います。

この権限モードは、主に2つの仕組みで制御されています。

• Sandbox：技術的にどこまで操作できるか
• Approval：どの操作でユーザーの許可を求めるか

Sandboxは「Codexが触れる範囲」を決める仕組みです。Approvalは「その範囲を超えそうな操作の前に、ユーザーへ確認するか」を決める仕組みです。

たとえばworkspace-writeでは、Codexは基本的に現在のプロジェクト内を編集できます。一方で、プロジェクト外のファイルやネットワークへアクセスする場合は、設定に応じて許可を求めます。

基本はworkspace-writeを使う

個人のローカル開発では、次の組み合わせが扱いやすい設定です。個人設定は通常、~/.codex/config.tomlに記述します。

sandbox_mode = "workspace-write"
approval_policy = "on-request"

この設定では、Codexはプロジェクト内の通常作業を進めつつ、範囲外の操作が必要なときに確認を求めます。

コードを変更させず相談だけしたい場合は、read-onlyへ切り替えます。CLIでは/permissionsから変更できます。

Full Accessを常用しない

Full Accessでは、ファイルシステムやネットワークの制約が大幅に弱くなります。確認の手間は減りますが、誤ったコマンド、悪意のある依存関係、Webページ上のプロンプトインジェクションなどの影響が大きくなります。

外部で十分に隔離された環境など、明確な理由がある場合を除き、通常の個人開発では常用しない方が安全です。

Gitで変更を戻せる状態にしておく

Codexに編集を任せるプロジェクトは、Gitで管理しましょう。

作業前に次を確認しておくと安心です。

git status

自分の未コミット変更がある場合、Codexの変更と混ざる可能性があります。重要な作業は先にコミットするか、後述するWorktreeで分離します。

Codex Appのレビュー画面やCLIの/diffを使い、変更を受け入れる前に差分を確認してください。

ネットワークアクセスを必要なときだけ許可する

ローカルのworkspace-writeでは、コマンドのネットワークアクセスは既定で無効です。パッケージのインストール、外部APIへの接続、最新情報の取得などで必要になったときだけ許可します。

CodexのWeb検索機能と、シェルコマンドのネットワークアクセスは別物です。調査だけなら、広いネットワーク権限を与えずWeb検索を使える場合があります。

検索結果やWebページは、信頼できない入力として扱う必要があります。ページ内に書かれた「以前の指示を無視して秘密情報を送れ」といった文章へ従わせないよう、Codexの操作範囲を狭く保ちましょう。

秘密情報を貼り付けない

次の情報をプロンプトやソースコードへ直接貼り付けないでください。

• APIキー
• パスワード
• アクセストークン
• 秘密鍵
• 本番環境の個人情報

.envを利用していても、Codexにファイル内容を表示させる必要があるかは慎重に判断します。.gitignore、OSの資格情報ストア、利用サービスのSecret管理機能などを使いましょう。

Codexのログイン情報がファイル保存される設定では、~/.codex/auth.jsonをパスワードと同様に扱い、Gitへコミットしたり共有したりしないでください。

最後は自分でも確認する

Codexが「テストに成功しました」と報告しても、次を確認しましょう。

• 実行したコマンドは適切だったか
• 本当に必要なテストを実行したか
• 変更範囲が広がっていないか
• 仕様を誤解していないか
• セキュリティやデータ損失のリスクがないか

Codexは作業を速くする道具ですが、採用する変更の責任まで自動化されるわけではありません。

慣れてきたら使いたい便利機能

ここからは発展機能です。基本操作、依頼の書き方、検証の流れに慣れてから、必要なものだけ導入してください。

優先して覚えたい機能

Worktree

Worktreeは、同じGitリポジトリに別の作業場所を作る仕組みです。Codex Appでは、スレッドをWorktreeで開始することで、普段の作業ディレクトリを変更せず、独立した変更を進められます。

向いている用途：

• 現在の作業を止めずに別機能を試す
• 複数のCodexタスクを並行して進める
• 大きな変更を安全に試す

同じブランチを複数のWorktreeで同時にチェックアウトできないなどGit固有の制約はありますが、Codex AppのHandoff機能を使えば、Worktreeとローカル作業の間を移動できます。

Web検索

ライブラリの最新仕様、エラー、公式ドキュメントを調べる場合に使います。

通常のローカルタスクでは、Web検索は既定でキャッシュされた検索結果を利用します。最新情報が必要な場合は、CLIの--searchまたは設定のweb_search = "live"を使用します。Full Accessでは、Web検索の既定がライブ検索になるため注意してください。

codex --search

プロンプトでも「公式ドキュメントを優先し、確認した日付とURLを示してください」と指定すると、情報の出所を確認しやすくなります。

In-app Browser

Codex AppのIn-app Browserでは、ローカル開発サーバーやログイン不要の公開ページを、Codexと一緒に確認できます。Codexにページを直接操作させるBrowser useを利用するには、Browser pluginのインストールと有効化が必要です。

@Browserを使って http://localhost:3000/settings を開き、
モバイル幅でボタンがはみ出す問題を再現して修正してください。
修正後に同じ画面を再確認してください。

ログイン状態、普段のCookie、ブラウザ拡張機能は引き継がれません。認証済みページにはChrome Extensionなど別の方法が必要です。

Skills

[Skills]は、繰り返し使う作業手順をまとめる仕組みです。指示、参考資料、必要に応じてスクリプトを一つのフォルダにできます。

例えば、次のような手順をSkillにできます。

• リリース前チェック
• ブログ記事の校正
• DBマイグレーションの確認
• コミット前のレビュー

プロジェクトで継続して守るルールはAGENTS.md、特定の作業で再利用する手順はSkill、と分けると整理しやすくなります。そのスレッドだけに必要な条件は、プロンプトで伝えます。

必要になったら使いたい機能

MCP

[MCP]は、CodexをGitHub、Figma、Sentry、ドキュメントサービスなどの外部ツールへ接続する仕組みです。

ローカルファイルだけでは完結しない作業が増えたときに役立ちます。

Sentryのエラーを確認し、関係するコードを特定して修正案を作る

MCPサーバーには読み取りだけでなく、外部サービスを変更するツールもあります。接続先、認証方法、実行権限を確認してから導入してください。

サブエージェント

サブエージェントは、調査やレビューを複数のエージェントへ分担する機能です。

現在の変更を並列にレビューしてください。
1人はバグ、1人はセキュリティ、1人はテスト不足を担当し、
全員の結果を待って重要度順にまとめてください。

読み取り中心の調査やレビューは並列化しやすい一方、複数エージェントに同じファイルを編集させると競合しやすくなります。また、利用量も増えるため、大きな作業に限定するのが現実的です。

codex exec

codex execは、対話画面を開かずにCodexを実行するコマンドです。

codex exec "このリポジトリの構成と注意点を要約してください"

定型的なチェックや、コマンド出力の整理に向いています。通常はGitリポジトリ内で実行する必要があります。Git管理されていない場所で実行する場合は--skip-git-repo-checkを指定できますが、作業場所が安全であることを確認してから使用してください。

npm test 2>&1 \
 | codex exec "失敗したテストの原因候補と次の調査手順をまとめてください"

自動実行ではユーザーが途中確認できないため、必要最小限の権限にします。まず手動のスレッドでプロンプトを試し、結果が安定してから自動化してください。

よくある失敗と改善方法

「いい感じに直して」と丸投げする

問題：Codexが何を優先すべきか判断できず、変更範囲が広がります。

改善：対象、制約、完了条件を短く指定します。

この画面の余白だけを修正してください。
コンポーネント構造と色は変更しないでください。

完了条件を伝えない

問題：コードを書いた時点で作業が終わり、テストや表示確認が抜けます。

改善：

関連テストとLintが成功し、再現手順で問題が起きないことを確認したら完了です。

一度に大きすぎる変更を依頼する

問題：文脈が増え、レビューも難しくなります。

改善：調査、計画、実装、検証に分割します。大規模な作業ではPlan modeを使います。

Codexの回答を確認せず採用する

問題：動作はしても、プロジェクトの設計と合わない実装や、不要な変更が混ざる可能性があります。

改善：/diffやレビュー画面で差分を読み、疑問点は根拠を説明させます。

テストを実行せずに終える

問題：構文上は正しくても、既存機能が壊れている可能性があります。

改善：プロンプトとAGENTS.mdの両方に、実行すべきテストを書きます。

長く曖昧なAGENTS.mdを作る

問題：重要なルールが埋もれ、矛盾した指示が入りやすくなります。

改善：頻繁に使うコマンド、必須ルール、完了条件に絞ります。繰り返し発生した失敗だけを追加します。

複数のスレッドで同じファイルを同時に編集する

問題：変更が上書きされたり、異なる前提で実装が進んだりします。

改善：並列作業は対象ファイルを分けます。同じリポジトリで複数の変更を進める場合はWorktreeを使い、最後に一つずつ統合します。

まとめ：Codexを使いこなす5つの原則

Codexを使いこなすために、すべての機能を覚える必要はありません。まず次の5つを意識してください。

1. 小さな作業から始める
   説明、調査、小さな修正から始め、結果を確認しながら任せる範囲を広げます。
2. 必要な背景と完了条件を伝える
   目的、関係するファイル、制約、検証方法を伝えると、結果が安定します。
3. 実装だけでなく検証まで任せる 
   テスト、Lint、型チェック、再現手順までを一つの作業として依頼します。
4. 繰り返す説明はAGENTS.mdに残す
   プロジェクト固有のコマンドやルールを蓄積し、毎回の説明を減らします。
5. 最終判断は自分で行う
   差分と検証結果を確認し、採用する変更に責任を持ちます。

Codexの価値は、単にコードを速く生成することではありません。調査、実装、検証、レビューという開発の流れを、対話しながら前へ進められることにあります。

最初の一歩として、今使っている小さなプロジェクトで、次のように依頼してみてください。

このプロジェクトの構成を確認し、
開発サーバー、テスト、Lintの実行方法を説明してください。
コードは変更しないでください。
最後に、Codex向けの短いAGENTS.md案を作ってください。

この依頼から、Codexとの共同作業に必要な「理解させる、任せる、確認する」という基本の流れを体験できます。