Codexの使い方 プロンプトの型からAGENTS.md・権限設定まで実践手順を解説

Codexを触ってはみたものの、思った修正が返ってこない、指示のたびに同じ前提を書き直している。そんな状態で止まっている方は少なくありません。

原因の多くは、能力ではなく渡し方にあります。何を目的とし、どこを見て、どうなれば完了なのかが伝わっていなければ、エージェントは推測で埋めるしかありません。

ここでは公式ドキュメントで示されている手順をもとに、指示の書き方から計画の立てさせ方、AGENTS.mdによる前提の共有、権限設定、レビューと自動化までを順に整理します。

確認したいポイント	結論	詳細
指示はどう書けばいい？	目的・文脈・制約・完了条件を書く	この4点をそろえるだけで前提の推測が減り、手戻りとレビューの負荷が下がる
AGENTS.mdには何を書く？	毎回伝えている前提を移す	構成・実行方法・テストコマンド・規約・禁止事項・完了の定義を書くと、指示を短くできる
権限設定はどうする？	既定のまま始めて後から緩める	承認モードとサンドボックスモードの2つで制御する。信頼できるリポジトリから順に範囲を広げる
うまくいかない原因は？	多くは指示ではなく設定側	作業ディレクトリの誤り、書き込み権限の不足、テストコマンド未共有が典型的な原因になる

この記事でわかること

• 結果が安定する指示の書き方と、推論レベルの選び分け
• 複雑なタスクで実装前に計画を立てさせる進め方
• AGENTS.mdに書く項目と、階層構造による使い分け
• 承認モードとサンドボックスモードによる権限の決め方
• レビューまで含めた回し方と、繰り返し作業の自動化

▼ AIエージェントの使いこなしを組織に広げたい方へ 個人が工夫して成果を出しても、やり方が共有されなければチーム全体の生産性は変わりません。 ネクストスケールでは、現場の使い方を標準化するところまで含めて支援しています。 ▶ 無料相談はこちら（株式会社ネクストスケール）

Codexの使い方は指示の書き方で結果が大きく変わる

公式ドキュメントは、指示が完璧でなくても十分に使えると説明しています。ただし、大きなコードベースや失敗の許されない作業では、書き方の差がそのまま結果の差になります。

4つの要素をそろえて指示を書く

推奨されているのは、次の4点を1つの指示に含める書き方です。

• 目的：何を変えたいのか、何を作りたいのか
• 文脈：どのファイル、フォルダ、資料、エラーが関係するのか
• 制約：従うべき規約、設計方針、安全上の要件は何か
• 完了条件：何が満たされれば終わりなのか

特に効くのが最後の完了条件です。テストが通ること、特定の挙動が変わること、不具合が再現しなくなることといった形で書いておくと、エージェント側が自分で確認まで行えます。

この4点をそろえるだけで推測の余地が減り、作業範囲が広がりすぎる問題も起きにくくなります。レビューする側にとっても、差分が意図どおりかを判断しやすくなります。

たとえば「ログイン処理を直して」だけでは、どのファイルのどの挙動を、どういう状態にしたいのかが伝わりません。対象のファイルを挙げ、既存の設計に合わせること、そして特定のテストが通れば完了、と書き添えるだけで結果は変わります。

指示の組み立て方はCodex公式ドキュメントの推奨事項にまとまっています。更新が続く領域のため、実際に運用する際は一次情報もあわせて確認してください。

ファイルを指定して文脈を絞る

関係するファイルは、アットマークを付けて名前を指定できます。探させるより先に渡したほうが速く、無関係な箇所まで読み込ませずに済みます。

エラーが出ているなら、そのメッセージをそのまま貼るのが確実です。要約して伝えると、判断に必要な情報が抜け落ちることがあります。

推論レベルをタスクに合わせる

Codexは推論の深さを選べます。範囲がはっきりした軽い作業なら低め、込み入った変更や原因調査なら中から高、長時間にわたる作業ならさらに上、というのが公式の目安です。

常に最も深い設定にすればよいというものではありません。 単純な作業では待ち時間が増えるだけになるため、作業の種類ごとに手応えを見ながら決めるのが現実的です。

エージェント型ツールの前提となる考え方はAIエージェントとは何かで整理しています。

関連記事：Claude Code hooksとは？設定方法とイベント一覧・実用例と注意点を解説

難しいタスクは実装前に計画を立てさせる

要件が固まっていない作業をそのまま渡すと、方向がずれたまま大量のコードが生成されます。手戻りを避けるには、書き始める前に計画を挟むのが有効です。

プランモードを使う

最も簡単なのはプランモードです。 スラッシュコマンドで切り替えると、Codexは文脈を集め、不明点を質問したうえで、実装に入る前に計画を組み立てます。

/plan

計画の段階で認識のずれに気づければ、修正はプロンプトの1行で済みます。実装が終わってから気づくのとでは、かかる手間がまったく違います。

Codexに質問させる

やりたいことは漠然と見えているが、うまく言語化できないという場面もあります。この場合は、先に質問させるという指示が使えます。

前提を疑ってほしい、曖昧な点を具体化してほしいと伝えれば、対話を通じて要件が固まっていきます。自分の頭の整理に使えるという点で、仕様が定まっていない段階ほど効果があります。

実行計画をテンプレート化する

複数の工程にまたがる長い作業では、計画をファイルとして残す進め方もあります。手順の型を用意しておけば、担当者が変わっても進め方がぶれません。

計画から実装までの回し方は、自然言語で開発を進める考え方とも重なります。全体像はバイブコーディングの進め方で扱っています。

▼ 手戻りの多さに悩んでいる方へ 生成量が増えても、方向がずれていれば修正の工数が積み上がります。どこで確認を挟むかの設計が必要です。 開発フローのどこにレビューを置くか、一緒に設計します。 ▶ 無料相談はこちら（株式会社ネクストスケール）

関連記事：CodexとClaude Codeを比較｜料金・得意領域の違いと選び方・併用のコツ

繰り返し伝えている前提はAGENTS.mdに移す

指示が固まってきたら、次は毎回書く手間をなくす段階です。ここで使うのがAGENTS.mdという仕組みです。

AGENTS.mdに書く項目

AGENTS.mdは、エージェント向けのREADMEにあたるファイルです。セッションの開始時に自動で読み込まれるため、書いておけば毎回伝える必要がなくなります。

公式が挙げている内容は次のとおりです。

• リポジトリの構成と、重要なディレクトリ
• プロジェクトの起動方法
• ビルド、テスト、静的解析のコマンド
• 開発上の規約と、プルリクエストに求める水準
• 制約と、やってはいけないこと
• 完了とみなす条件と、その検証方法

テストコマンドを書いておくかどうかで、結果は大きく変わります。自分で検証できる状態にしておかないと、動作確認は人が全部引き受けることになります。

雛形を作ってから書き直す

ゼロから書く必要はありません。スラッシュコマンドで雛形を生成できます。

/init

ただし、生成された内容をそのまま使うのは避けてください。公式も、自分たちが実際にどう作り、テストし、レビューし、リリースしているかに合わせて書き直すよう案内しています。

長く書けばよいわけでもありません。曖昧なルールを並べた長文より、短くて正確な記述のほうが効きます。基本から始めて、実際にミスが起きた箇所だけ追記していくのが無理のない育て方です。

階層構造と優先順位

AGENTS.mdは複数の階層に置けます。個人の共通設定はホームディレクトリ配下、チームで共有する基準はリポジトリの直下、特定の領域だけのルールはサブディレクトリに置きます。

作業中のディレクトリに近いファイルの記述が優先されます。 全体の方針を上位に置き、例外を下位に置くという整理ができます。

同じミスが繰り返されたら更新する

運用のこつとして公式が挙げているのが、同じ間違いが2度起きたら振り返りを求め、その結果をAGENTS.mdに反映するという回し方です。

想像で書いたルールではなく、実際に起きた摩擦にもとづいて増やしていくため、内容が実務から離れません。ファイルが大きくなってきたら、本体は簡潔に保ち、詳細は別ファイルに切り出して参照させます。

関連記事：Claude Codeの連携方法まとめ｜MCP・GitHub・Slack連携の設定手順と注意点を解説

設定と権限をそろえて挙動を安定させる

セッションごとに挙動が変わると、使い方が定まりません。設定ファイルと権限の2つを押さえておくと、この揺れが減ります。

設定ファイルの置き場所と使い分け

設定は階層で管理します。個人の既定値はホームディレクトリ配下の設定ファイル、リポジトリ固有の挙動はプロジェクト内の設定ファイルに書き、コマンドラインでの上書きは一時的な用途に限る、という切り分けが推奨されています。

ここで決められるのは、使用するモデル、推論の深さ、サンドボックスの動作、承認の方針、外部ツールとの接続設定などです。デスクトップアプリからは設定画面を経由して同じファイルを開けます。

承認モードとサンドボックスモード

権限を決めるつまみは2つあります。承認モードはコマンド実行の前に許可を求めるかどうか、サンドボックスモードは読み書きできる範囲を決めるものです。

エージェント型ツールに慣れていないうちは、既定のまま始めるのが公式の推奨です。 承認とサンドボックスを厳しめに保ち、必要が明確になった信頼できるリポジトリからだけ緩めていきます。

いきなり全権限を与えるのは、公式が挙げるよくある失敗のひとつに数えられています。挙動を理解する前に範囲を広げると、想定外の変更に気づくのが遅れます。

提供形態をまたいで設定は共通

押さえておきたいのは、CLI、IDE拡張、デスクトップアプリが同じ設定の層を共有している点です。どれか1つで整えれば、他の形態にも反映されます。

デスクトップアプリの位置づけと始め方についてはCodex appとはで詳しく扱っています。ターミナル側の詳細はCodex CLIの公式ドキュメントを参照してください。

▼ チームで設定をそろえたい方へ 各自が独自の設定で使っている状態では、成果もトラブルも属人化します。標準を決めることが最初の一歩です。 設定の標準化から権限設計まで、まとめてご相談いただけます。 ▶ 無料相談はこちら（株式会社ネクストスケール）

テストとレビューまで含めて一往復にする

変更を作らせて終わりにすると、確認の負担が人側に残ります。検証まで一続きの作業として渡すのが、結果的にいちばん速くなります。

完了の条件を検証させる

何をもって良しとするかが伝わっていれば、Codexは検証まで自分で回せます。 依頼に含めておきたいのは次のような内容です。

• 変更に対応するテストを書く、または更新する
• 該当するテストを実行する
• 静的解析や書式、型のチェックを通す
• 最終的な挙動が依頼どおりかを確認する
• 差分を見直し、不具合や危うい書き方がないか点検する

この基準は、毎回プロンプトに書いてもよいですし、AGENTS.mdに残しておくこともできます。頻度が高いなら後者のほうが手間は少なくなります。

レビュー用のコマンドを使う

差分の点検には専用のコマンドが用意されています。

/review

比較する対象は選べます。ベースとなるブランチと比べる、未コミットの変更だけを見る、特定のコミットを対象にする、独自の観点を指定する、といった使い分けができます。

デスクトップアプリでは差分パネルを開いて手元で確認でき、特定の行に対して指摘を書き込むと、その内容が次のやり取りに引き継がれます。指摘を口頭で伝え直す手間がなくなるぶん、往復が短くなります。

GitHubを使っている場合は、プルリクエストのレビューを自動で走らせる設定も用意されています。常時レビューさせる形にも、必要なときだけ呼び出す形にもできます。

レビュー基準をファイルに残す

チームでレビュー観点をそろえたい場合は、基準をまとめたファイルを用意し、AGENTS.mdから参照させる方法があります。担当者やリポジトリが変わっても、同じ観点でレビューが行われる状態を作れます。

なおOpenAI社内では、すべてのプルリクエストをCodexがレビューしていると説明されています。人の目を置き換えるというより、見落としを減らす層を1つ増やすという位置づけです。

繰り返す作業はスキルと定期実行に変える

同じ指示を何度も書いている、同じ修正を毎回入れている。そう感じ始めたら、作業そのものを部品にする段階です。

MCPで外部の情報につなぐ

必要な情報がリポジトリの外にある場合は、外部ツールとの接続を使います。毎回コピーして貼り付けている情報があるなら、それは接続に置き換えられる可能性があります。

公式が接続を勧めているのは、情報が頻繁に変わる場合や、複数人で同じ連携を再現したい場合です。逆に、使っているツールを片端からつなぐのは避けるよう案内されています。

接続規格そのものについてはMCP（Model Context Protocol）とは、コードベースの解析を効率化する具体例はSerena MCPの導入方法で扱っています。

スキルで手順を部品にする

同じプロンプトを使い回している、同じ直し方を毎回指示している。そういう作業は、スキルという形にまとめられます。

1つのスキルは1つの仕事に絞るのがこつです。 最初から例外まで作り込まず、代表的なケースを1つ動かしてから広げるほうが失敗しません。

向いている作業として挙げられているのは、ログの切り分け、リリースノートの下書き、チェックリストに沿ったレビュー、移行計画の作成、障害の要約、決まった手順のデバッグなどです。

個人用として作ったスキルは、リポジトリに置けばチームで共有できます。新しく入った人が同じやり方をすぐ再現できるという点で、教育の負担も下がります。

定期実行に載せる

手順が安定してきたら、決まった間隔で自動的に走らせられます。デスクトップアプリからは、対象、指示内容、頻度、実行環境を指定して登録します。

候補として挙がっているのは、直近のコミットの要約、不具合の走査、リリースノートの下書き、ビルド失敗の確認、進捗のまとめといった作業です。

順序を間違えないでください。 手作業で安定していないものを先に自動化すると、確認の手間だけが増えます。スキルが方法を決め、定期実行が頻度を決める、という関係で捉えると整理しやすくなります。

▼ 定型業務の自動化を検討している方へ 自動化して効果が出る作業と、まだ人が判断すべき作業の線引きが、投資対効果を左右します。 対象業務の棚卸しから、優先順位づけまでお手伝いします。 ▶ 無料相談はこちら（株式会社ネクストスケール）

うまくいかないときに見直す落とし穴

結果が安定しないとき、指示の書き方ばかり調整しても解決しないことがあります。公式が挙げているよくある失敗を、原因別に整理します。

指示ではなく設定が原因のことが多い

品質の問題に見えるものの多くは、実は環境の問題です。 作業ディレクトリが違う、書き込み権限がない、モデルの既定値が想定と異なる、必要なツールがつながっていない、といった原因が典型です。

あわせて多いのが、ビルドやテストの実行方法を伝えていないケースです。自分の作ったものを確認する手段がなければ、動作を保証できないまま作業が終わります。

恒久的なルールを毎回のプロンプトに詰め込むのも避けたい形です。AGENTS.mdやスキルに移せるものは移し、その場の依頼だけを書くようにします。

会話の単位を分ける

1つのプロジェクト全体を1つの会話で進めると、文脈が膨らんで結果が落ちていきます。1つのまとまった成果に対して1つの会話、という単位で分けるのが推奨されています。

同じ問題を追っている間は同じ会話に留まるほうが、判断の経緯が残るぶん有利です。作業が本当に枝分かれしたときだけ分けます。

会話が長くなってきたら、それまでの内容を要約する操作も用意されています。探索やテストのような区切りのある作業は、別の担当に切り出す仕組みを使う方法もあります。

権限と並行実行の扱い

挙動を理解する前に全権限を与えるのは避けてください。あわせて、複数の作業を同じファイル上で並行させるのも衝突のもとになります。作業ごとに分離した領域を用意する仕組みを使います。

もうひとつ、逐一見張ってしまうという失敗もよく挙げられます。任せたうえで自分は別の作業を進めるという使い方に切り替えないと、時間の節約になりません。

社内で使い方をそろえる

独立行政法人情報処理推進機構のDX動向2025では、日本企業の85.1%でDXを推進する人材が不足していると報告されています。ツールを配ることと、使える人を増やすことは別の課題です。

ここまで挙げた内容は、個人が覚えるより、組織の設定として持つほうが早く効きます。AGENTS.mdの雛形、設定ファイルの標準、レビュー基準のファイルを用意しておけば、新しく入った人も同じ水準から始められます。

業務で使う際の情報管理は生成AI利用時のセキュリティ対策、組織全体の底上げは法人向け生成AI研修で整理しています。他社ツールと比較検討している場合はClaude Codeのインストール方法もあわせてご覧ください。

まとめ

Codexの使い方でまず押さえたいのは、目的・文脈・制約・完了条件という4点をそろえた指示の書き方です。要件が固まっていない作業では、実装の前に計画を立てさせる工程を挟むと手戻りが減ります。

毎回書いている前提はAGENTS.mdに移し、設定と権限は階層で管理します。承認とサンドボックスは既定のまま始め、必要が見えたリポジトリから緩めていくのが公式の推奨です。

そのうえで、テストとレビューまでを一続きの依頼にし、繰り返す作業はスキルと定期実行に載せ替えていきます。結果が安定しないときは指示より先に設定を疑う、という順序を覚えておくと解決が早くなります。

▼ AI開発環境の整備をご検討中の方へ 使い方の標準化は、ツールの選定と同じくらい成果を左右します。現場に定着する形での設計をお手伝いします。 課題の整理から運用の立ち上げまで、まずは無料相談でお聞かせください。 ▶ 無料相談はこちら（株式会社ネクストスケール）