Codex やコーディングエージェントを初めて使う方に向けて、短時間でよりよい結果を得るための方法を紹介します。CLI、IDE 拡張機能、ChatGPT デスクトップアプリのいずれでも Codex を効果的に使えるよう、プロンプトの書き方や計画の立て方から、検証、MCP、スキル、スケジュール済みタスクまで、日々の作業に取り入れたい習慣を取り上げます。
Codex の力を最も引き出せるのは、単発の依頼をこなすアシスタントとして使うよりも、チームの一員として作業に合う設定を整え、使いながら改善していくときです。
まず、タスクに必要なコンテキストを渡します。継続的に使う指示は AGENTS.md にまとめ、普段のワークフローに合わせて Codex を設定します。外部システムとの接続には MCP を使い、繰り返す作業はスキルにまとめます。手順が安定したら自動化します。
初回から役立つコンテキストとプロンプト
プロンプトが完璧でなくても、Codex は十分に役立ちます。難しい問題でも、わずかな準備で任せてよい結果を得られることは少なくありません。プロンプトの書き方を工夫しなくても Codex は使えますが、指示が明確であれば結果はより安定します。特に、コードベースが大きい場合や、失敗したときの影響が大きいタスクでは差が出ます。
大規模または複雑なリポジトリでは、タスクに必要なコンテキストを Codex に渡し、依頼内容を整理して伝えることが最も効果的です。
プロンプトには、次の 4 点を含めるとよいでしょう。
- 目標： 何を変更したいですか。何を作りたいですか。
- コンテキスト： このタスクに関係するファイル、フォルダー、ドキュメント、例、エラーはどれですか。特定のファイルは @ メンションでコンテキストに追加できます。
- 制約： Codex が従うべき基準、アーキテクチャ、安全要件、規約はありますか。
- 完了条件： テストが通る、動作が変わる、バグが再現しなくなるなど、どのような状態になればタスクは完了ですか。
この 4 点を伝えると、Codex は推測に頼る場面が減り、依頼した範囲に絞って作業できます。作業結果もレビューしやすくなります。
お使いのアカウントとクライアントで GPT-6.1 Sol を利用できる場合は、このモデルを選び、まずはクライアントの既定の推論強度を使います。GPT-6 Luna では高、GPT-6 Astra では軽量（設定値は low）から始め、タスクと結果に応じて調整します。利用できる推論強度はモデルを参照してください。
- 低：範囲が明確で、短時間で済ませたいタスク
- 中程度または高：複雑な変更やデバッグ
- 超高：エージェントが長時間にわたって自律的に進め、高度な推論を必要とするタスク
コンテキストを手早く伝えるには、ChatGPT デスクトップアプリの音声入力を使ってみてください。Codex に依頼したいことを、キーボードで入力する代わりに話して伝えられます。
難しいタスクの事前計画
タスクが複雑な場合、要件が曖昧な場合、あるいはうまく説明できない場合は、コードを書き始める前に計画を立てるよう Codex に依頼します。
次のような方法があります。
プランモードの利用： 多くのユーザーにとって、最も手軽で効果的な方法です。プランモードでは、Codex がコンテキストを集め、不明点を質問し、実装前に計画を練ることができます。/plan または Shift+Tab で切り替えます。
Codex からの質問： やりたいことは大まかに決まっていても、うまく説明できない場合は、まず必要なことを質問してほしいと Codex に伝えます。コードを書く前に、前提に無理がないか問い直し、曖昧なアイデアを具体化するよう依頼します。
PLANS.md テンプレートの利用： より高度なワークフローでは、長時間かかる作業や複数のステップを伴う作業で PLANS.md や実行計画のテンプレートに従うよう Codex を設定できます。詳しくは、実行計画ガイドを参照してください。
AGENTS.md を使った指示の再利用
効果のあったプロンプトの書き方が見つかったら、毎回同じ指示を入力する手間を省きましょう。そこで役立つのが AGENTS.md です。
AGENTS.md は、エージェント向けのオープンな形式の README と考えてください。コンテキストに自動で読み込まれるため、リポジトリで Codex にどう作業してほしいか、自分やチームの方針を記しておくのに最適です。
AGENTS.md には、次の内容をまとめると役立ちます。
- リポジトリの構成と主要なディレクトリ
- プロジェクトの実行方法
- ビルド、テスト、lint の各コマンド
- 開発規約と PR に求めること
- 制約と禁止事項
- 完了条件と作業結果の検証方法
CLI のスラッシュコマンド /init を使うと、現在のディレクトリに AGENTS.md のひな形をすぐに作成できます。これを出発点に、チームが実際にコードをビルド、テスト、レビュー、リリースする手順に合わせて編集してください。
AGENTS.md は複数の階層に配置できます。個人の既定の指示はグローバルな AGENTS.md として ~/.codex に、チーム共通の規約はリポジトリのルートに、各サブディレクトリに固有のルールはそのサブディレクトリに置きます。現在のディレクトリにより近い階層に、より具体的な指示があれば、そちらが優先されます。
実際の作業に役立つ内容に絞ります。曖昧なルールが並ぶ長いファイルより、短く正確な AGENTS.md の方が有用です。まずは基本事項をまとめ、同じミスが繰り返されるようになってから新しいルールを追加します。
AGENTS.md が長くなってきたら、メインのファイルは簡潔に保ち、計画、コードレビュー、アーキテクチャなどの詳細は、タスク別の Markdown ファイルを参照する形にします。
Codex が同じミスを 2 回したら、作業を振り返るよう依頼し、AGENTS.md を更新します。実際につまずいた点をもとに、役立つ指示を残せます。
Codex の動作をそろえる設定
セッションや利用環境が変わっても Codex の動作をそろえるには、設定が重要です。たとえば、モデル、推論強度、サンドボックスモード、承認ポリシー、プロファイル、MCP の設定について既定値を指定できます。
まずは次のように設定を分けます。
- 個人の既定値は
~/.codex/config.tomlに保存（ChatGPT デスクトップアプリでは 設定 > 構成 > config.toml を開く） - リポジトリ固有の動作は
.codex/config.tomlに記述 - CLI を使う場合、コマンドラインでの上書きは一度限りの変更に限定
config.toml では、MCP サーバー、マルチエージェント構成、機能フラグなど、継続的に使う設定を定義します。プロファイル固有の上書き設定は、それぞれ別の $CODEX_HOME/profile-name.config.toml ファイルに記述します。
Codex には OS レベルのサンドボックスが組み込まれており、主に 2 つの設定を調整できます。承認モードは、Codex がコマンドを実行する際にどのタイミングで許可を求めるかを決めます。サンドボックスモードは、Codex がディレクトリ内で読み取りや書き込みを行えるかどうかと、アクセスできるファイルの範囲を決めます。
コーディングエージェントを初めて使う場合は、既定の権限から始めます。通常は承認とサンドボックスの制限を厳しく保ち、必要性が明確になった段階で、信頼できるリポジトリや特定のワークフローに限って権限を広げます。
CLI、IDE 拡張機能、ChatGPT デスクトップアプリは、いずれも同じ設定の階層を使用します。詳しくは設定例を参照してください。
実際に使う環境に合わせて、早めに Codex を設定してください。結果の品質に問題があるように見えても、作業ディレクトリや既定のモデルが違う、書き込み権限がない、必要なツールやコネクタがないなど、設定に原因があることは少なくありません。
テストとレビューによる信頼性の向上
Codex に変更を依頼したら、必要に応じてテストを作成し、関連するチェックを実行して結果を確かめるところまで任せます。変更を受け入れる前に、作業内容のレビューも依頼してください。
Codex はこの一連の作業を実行できます。そのためには、どのような結果なら合格かを伝える必要があります。基準はプロンプトか AGENTS.md に記述できます。
たとえば、次のような作業を指定できます。
- 変更に対応するテストの作成または更新
- 適切なテストスイートの実行
- lint、フォーマット、型チェックの結果の確認
- 最終的な動作が依頼内容と一致することの確認
- バグ、リグレッション、リスクのある実装パターンがないかの差分レビュー
ChatGPT デスクトップアプリで差分パネルを開くと、ローカルで直接変更をレビューできます。該当する行をクリックしてフィードバックを入力すると、Codex が次のターンでその内容をコンテキストとして使用します。
コードのレビューには、スラッシュコマンド /review が便利です。次の方法から選べます。
- ベースブランチとの差分を対象にした PR 形式のレビュー
- 未コミットの変更のレビュー
- 特定のコミットのレビュー
- 独自のレビュー指示の使用
チームに code_review.md ファイルがある場合は、AGENTS.md から参照することで、Codex はレビュー時にもその指示に従えます。複数のリポジトリや開発者の間でレビューの進め方をそろえたいチームに適した方法です。
Codex の役割はコードの生成にとどまりません。適切な指示があれば、テスト、チェック、レビューにも活用できます。
GitHub Cloud を使っている場合は、Codex が PR のコードレビューを行うよう設定できます。OpenAI では、Codex が PR の 100% をレビューしています。自動レビューを有効にすることも、@Codex とメンションしてレビューを依頼することもできます。
MCP を使った外部コンテキストの取得
Codex に必要なコンテキストがリポジトリの外にあるときは、MCP を使います。普段使っているツールやシステムに Codex を接続できるため、最新の情報を毎回プロンプトにコピーして貼り付ける手間が省けます。
Model Context Protocol（MCP）は、Codex を外部のツールやシステムに接続するためのオープン標準です。
MCP は次のような場合に適しています。
- 必要なコンテキストがリポジトリの外にある場合
- データが頻繁に変わる場合
- 貼り付けた指示に頼らず、Codex にツールを使ってほしい場合
- 複数のユーザーやプロジェクトで同じ連携を繰り返し利用したい場合
Codex は、STDIO サーバーと、OAuth を利用できる Streamable HTTP サーバーの両方に対応しています。
ChatGPT デスクトップアプリの 設定 > MCP サーバー で、カスタムサーバーと推奨サーバーを確認できます。必要なサーバーのインストールも、多くの場合は Codex に依頼するだけで進められます。CLI の codex mcp add コマンドで、名前や URL などを指定してカスタムサーバーを追加することもできます。
ツールを追加するのは、実際に必要なワークフローを実現できるときに限ります。普段使うツールを最初からすべて接続する必要はありません。まずは、よく繰り返す手作業を確実に省けるツールを 1 つか 2 つ選び、そこから増やしていきます。
繰り返す作業のスキル化
同じ手順で作業を進められるようになったら、長いプロンプトや何度ものやり取りに頼る必要はありません。スキルを使って、SKILL.md ファイルに記述した指示と、Codex が毎回使うコンテキストや補助ロジックをひとまとめにします。スキルは CLI、IDE 拡張機能、ChatGPT デスクトップアプリのいずれでも使えます。
各スキルの役割は 1 つに絞ります。まず具体的な使用例を 2～3 件挙げ、入力と出力を明確にします。説明には、スキルで何ができるか、いつ使うかを記載します。呼び出しのきっかけとなる、ユーザーが実際に使いそうな言い回しも含めます。
最初からすべての例外に対応しようとせず、まずは代表的なタスクを 1 つ選びます。それがうまくいくようになったら、そのワークフローをスキルにして改善を重ねます。スクリプトや追加のアセットは、信頼性の向上に役立つ場合にだけ含めます。
同じプロンプトを何度も使ったり、同じワークフローを繰り返し修正したりしているなら、スキル化を検討する目安です。
スキルは、特に次のような定期的な作業に役立ちます。
- ログのトリアージ
- リリースノートの下書き
- チェックリストに沿った PR レビュー
- 移行計画の作成
- テレメトリやインシデントの要約
- 標準的な手順に沿ったデバッグ
スキルの初版を作るには、$skill-creator スキルでひな形を用意するのがおすすめです。試行錯誤している間はローカルに置き、広く共有する準備ができたらプラグインとしてパッケージ化します。スキルの中でも特に重要なのが説明です。そのスキルで何ができるか、いつ使うかを明記してください。
個人用スキルは $HOME/.agents/skills に保存します。チームで共有するスキルは、リポジトリ内の .agents/skills にチェックインできます。新しいメンバーがチームの作業手順を覚える際に特に役立ちます。
スケジュール済みタスクによる定期実行
ワークフローが安定したら、Codex がバックグラウンドで実行するようスケジュールを設定できます。ChatGPT デスクトップアプリのスケジュール済みタスクでは、定期的な作業に使うプロジェクト、プロンプト、実行頻度、実行環境を選べます。
スケジュール済みページからスケジュール済みタスクを作成します。プロジェクト、プロンプト、実行頻度を指定し、専用の Git Worktree とローカル環境のどちらで実行するかを選びます。プロンプトからスキルを呼び出すこともできます。詳しくは Git Worktree を参照してください。
定期実行に向いている作業には、次のようなものがあります。
- 最近のコミットの要約
- バグが疑われる箇所の検出
- リリースノートの下書き
- CI の失敗の確認
- スタンドアップミーティング用の要約作成
- 同じ手順で行う分析の定期実行
スキルで作業手順を定め、スケジュール済みタスクで実行時期を定めると整理しやすくなります。まだ頻繁に指示を出す必要があるワークフローは、先にスキルにまとめます。結果が予測できるようになってから定期実行に移すと、時間を節約できます。
スケジュール済みタスクは、作業の実行に加え、振り返りやメンテナンスにも活用できます。最近のチャットを見直し、繰り返しつまずいた点をまとめ、プロンプトや指示、ワークフローの設定を少しずつ改善します。
長期間続くチャットの整理
チャットには、やり取りを重ねるにつれてコンテキストや決定事項、実行した作業の履歴が蓄積されます。そのため、チャットの管理方法は結果の品質に大きく影響します。
ChatGPT デスクトップアプリでは、チャットをピン留めしたり、Worktree を作成したりできます。CLI を使う場合は、次のスラッシュコマンドが特に便利です。
/experimental：実験的機能の有効・無効を切り替え、設定をconfig.tomlに追加/resume：保存したチャットを再開/fork：元の会話履歴を保持したまま、新しいチャットを作成/compact：チャットが長くなり、それまでのコンテキストを要約したいときに使います。Codex はチャットのコンパクションを自動でも行います。/subagents：現在のチャットにあるサブエージェントのスレッドを切り替え/theme：構文ハイライトのテーマを選択/apps：Codex から ChatGPT アプリを直接利用/status：現在のセッションの状態を確認
ひとまとまりの作業には、チャットを 1 つ使います。同じ問題に引き続き取り組む場合は、それまでの推論の流れを保てるため、同じチャットを使う方がよいことが多いです。作業が実際に分岐したときだけフォークします。
Codex のサブエージェントを使うと、範囲の明確な作業をメインスレッドから切り離して任せられます。メインエージェントは中心となる問題に集中させ、調査、テスト、トリアージなどはサブエージェントに任せます。
よくある失敗
Codex を使い始めたときに避けたい失敗には、次のようなものがあります。
- 継続的に使うルールを
AGENTS.mdやスキルに移さず、プロンプトに詰め込むこと - ビルドやテストのコマンドを適切に実行する方法を詳しく伝えず、エージェントが自分の作業結果を確認できない状態にすること
- 複数のステップを伴うタスクや複雑なタスクで計画を省くこと
- ワークフローを理解する前に、コンピューターへのフルアクセスを Codex に許可すること
- Git Worktree を使わず、同じファイルを対象に複数のタスクを同時に実行すること
- 手動で安定して実行できるようになる前に、タスクを定期実行にすること
- 自分の作業と並行して Codex を活用せず、各ステップを逐一見守ること
- ひとまとまりの成果ごとにチャットを分けず、プロジェクト全体で 1 つのチャットを使うこと。コンテキストが膨らみ、次第に結果の品質が低下します。