2025年12月、OpenAIから「GPT-5.2-Codex」が発表されました。その後、2026年1月に入ってAPIの提供もはじまり、GitHub CopilotやCursorといった一部AI開発ツールでもCodex系モデルを選択できる環境が出てきています。
今回のモデルをきっかけに、CLI・IDE・Cloudといった複数の利用形態を横断して使える流れが明確になり、エディタ内でのAI提案やコードレビュー、ローカルとクラウドを行き来する作業などが、実用的な選択肢として見え始めました。
一方で、機能が強化されるほど、実務で使う際にはモードや権限、作業範囲を事前にどう設定するかがこれまで以上に重要になります。
本記事では、以前開催した社内勉強会「Codexの始め方」の内容をベースに、使い始める際に押さえておきたいポイントをお伝えします。 なお、Codex のインストールやセットアップ手順については、環境や利用形態（IDE / CLI / Cloud）によって異なるため、本記事では扱いません。 公式ドキュメントを参照してセットアップしてください。
最初につまずかないための使い方と設定
Codexを組織で触り始める際に一番大事なのは、「どういう前提で使い始めるか」の認識を揃えることです。 ここを間違えると、「想定以上に勝手に動く」「怖くて使えない」という体験になりがちです。
社内勉強会では、まず安全な進め方を明確にしました。
IDE / CLI / Cloud の考え方
【IDE】
VSCode系エディタ内でCodexを使用して、チャット、編集、変更内容のプレビューをシームレスに行えます。
エディタ内での対話・編集・差分確認を中心に、実装とレビューを行き来しながら作業を進めるのに向いています。
【CLI】
ターミナルから Codex を起動し、ローカル環境を拠点にコードの読み取り・変更・コマンド実行を行います。
1つの作業環境をベースに、横断的な判断や実行を含むタスクを継続的に進めたい場合に向いています。
【Cloud】
クラウド上の専用環境で Codex を実行し、タスク単位で環境を分けながら作業を進めます。
並列タスクや大規模変更を切り出しやすく、コードレビューを前提とした運用と相性が良いのが特徴です。
勉強会では、最初は IDE か CLI のどちらか一つに絞ることをおすすめしました。
| 利用形態 | 入門段階での用途・位置づけ |
|---|---|
| IDE | まず触ってみる選択肢として最も分かりやすい。 Codexの挙動を把握しやすい。 |
| CLI | Codexを作業エージェントとして扱う感覚を掴みやすい。 実行内容や変更範囲を手元で確認しやすい。 |
| Cloud | 影響範囲が広いため最初から使う必要はない。 挙動や判断の癖を理解してから使う方が安心。 |
モードは「エージェント」で、ただし権限は絞る
Codexには チャット/ エージェント / フルアクセス といったモードがありますが、入門時に選ぶのは エージェントで問題ありません。
エージェントモードでは、作業ディレクトリ内のファイルを読み取り・編集し、必要に応じてコマンドを実行できます。
一方、作業ディレクトリ外へのアクセスやネットワークを伴う処理については、デフォルトでユーザーの承認が求められる挙動になっています。
入門段階では、作業ディレクトリ内の操作は許可しつつ、ディレクトリ外へのアクセスやネットワーク処理のみ承認を求める設定のまま使うのが無難です。
ローカル実行/ クラウド実行 は「まず ローカル実行」
Codexは入門段階ではローカル実行から始めるのがおすすめです。
- Codexの挙動を手元で確認できるため「どう任せるとどう動くか」を体感しやすい
- 実行されるコマンドや変更内容を把握しやすい
という理由から、挙動を理解するフェーズではローカルで実行しましょう。
最初は“任せる範囲”を意図的に狭くする
Codexを作業エージェントとして使う際に重要なのは、「どこまでを任せるか」 を先に決めることです。
この“任せる範囲”は、1つの指示だけで制御するものではありません。
勉強会では、以下の 3つのレイヤーで考えることを共有しました。
1. 行動範囲を決める（config.toml）
Codexの設定ファイルです。
ローカル環境では、通常 ~/.codex/config.toml に配置されます。
入門段階ですべてを理解する必要はありませんが、AgentにWEB検索をさせたい場合は以下を設定しておきましょう。
[features]
web_search_request = true
この設定を入れていない場合、Codexは外部情報を参照せず、ローカルのコードや与えられた文脈だけを前提に判断します。
2. 常に守ってほしい前提・制約を決める（AGENTS.md ）
AIコーディングエージェントがプロジェクトを効果的に作業できるよう、必要なコンテキストと指示を提供するためのいわば「README」「前提指示書」ファイルです。
AGENTS.md には、以下のような内容を書きます。
- プロジェクトの前提
- 守ってほしいルール
- 思考や実装の方針
- やってほしくないこと
AGENTS.md は複数階層に配置でき、グローバル → リポジトリ → 作業ディレクトリの順にマージされます。 より局所的な指示ほど優先されるため、作業内容に応じた制御が可能です。
- グローバルに適用したい場合 ： ~/.codex/AGENTS.md
- プロジェクト内に絞りたい場合： リポジトリのルートにある AGENTS.md
- 一部の領域にのみ絞りたい場合： （作業サブディレクトリ）内の AGENTS.md
3. 今回のタスクで任せるスコープを決める（プロンプト）
config.toml や AGENTS.md で Codex の行動範囲や前提を定めた上で、各タスクごとに Codexにどこまでを任せるかはプロンプトで明示します。
勉強会では、最初のタスクとして以下のようなものを勧めました。
- 1ファイルだけの軽微な修正
- 既存コードのリファクタリング
- テストコードの追加
これらはいずれも、
- 対象ファイル（今回どこを触るのか）
- 触ってよい範囲（どこまで判断してよいか）
- やらないこと（今回やってほしくないこと）
といった内容を、プロンプトに落とし込みやすいためです。
常に守ってほしいルールはAGENTS.md、タスクごとに変わるルールはプロンプトで指示を管理しましょう。
実務で使うと見えてくる落とし穴と対処
Codexを実務で使い始めると、遅かれ早かれ「便利だけど、ちょっと怖い」という感覚にぶつかります。 勉強会では、実際によく起きがちな落とし穴と、その対処方法もいくつか共有しました。
指示していない箇所まで修正される
config.toml や AGENTS.md などで設定していても「ついでにリファクタリングされた」「関係なさそうなファイルにも変更が入った」
など、最もよくあるのがこのパターンです。
これは、Codexがコード全体を見て判断できる分、「改善した方がよさそうな箇所」を善意で直しに行くためです。
<対処法＞
この場合に有効なのは、タスク単位、つまりプロンプトで「やらないこと」を明示することです。
- 振る舞いは変えない
- 指定ファイル以外は触らない
- 最適化や整理は行わない
といった指示を与えるだけで、変更範囲はかなり安定します。
テストが「成功するテスト」しか書かれない
テストコードを任せた際に、
- エッジケースが抜けている
- 実装に依存したテストになる
と感じることがある人も多いと思います。
これはCodex が 「現在の実装が正しく動くこと」 を前提に、もっとも通りやすいテストを優先して書こうとするためです。
<対処法＞
この場合も、テストで何を検証したいかをプロンプトで明示するのが有効です。
テストコード自体を直接書かせる前に、
- 仕様として守りたい振る舞い
- 想定される失敗ケースも含めてテスト条件を列挙
といったような「どんな観点のテストが必要か」をCodeXに言語化させるのも効果的です。
作業途中のコードを消そうとする
エージェントモードで作業させていると、「このコードやコメントは不要」と判断され、作業途中のコードを消そうとするケースもあります。
これは、Codexが完成形をゴールとして最短経路を選ぼうとするためです。
<対処法＞
この場合、途中段階のコードを残すことを明示するのが有効です。
- ファイル削除は禁止
- コメントアウトや TODO は残す
- 途中段階のコードは保持する
といった制約も最初の指示に含めておきましょう。
まとめ
Codexが横断的に見られる範囲・判断できる範囲が広がった一方で、人間側の設計が甘いと影響範囲も一気に広がります。
「何をどう進めるか」を決める役割は、依然として人間にあります。
入門段階で意識しておきたいポイント3点
- まずは ローカル 環境で、小さなタスクから始める
- エージェントモードを使いつつ、権限は絞る
- 対象ファイル・触ってよい範囲・やらないことを明示する
はしっかり押さえておきましょう。
