Codexの設定方法｜利用形態の選び方から権限・おすすめ構成まで

Codexとは｜OpenAIのAIコーディングエージェント

Codexとは、OpenAIが提供するAIコーディングエージェント（自律的にコードを書き進めるAI）で、コードの記述・レビュー・デバッグを支援します。

ここでいうAIエージェントとは、指示に対して単に文章を返すだけでなく、ファイルの編集やコマンドの実行まで自分で進めるAIを指します。従来のチャット型AIが「回答を返す」役割だったのに対し、Codexは「手を動かして作業する」役割まで担う点が特徴です。

Codexでできること

Codexは、自然言語での指示をもとに、既存コードの修正・新機能の追加・バグ調査・テスト作成といった開発作業を進めます。単発の質問応答ではなく、複数ステップにまたがる作業を一連の流れで処理できるため、定型的な実装や調査の下ごしらえを任せやすいのが強みです。ただし、実行する範囲や権限は設定でコントロールする前提になっており、この後で解説する設定を理解しておくことが、安心して使うための土台になります。

ChatGPTや生成AIとの位置づけの違い

ChatGPTのような対話型の生成AIは、ブラウザやアプリ上でテキストのやり取りを行うのが基本です。一方Codexは、ターミナルやエディタ、クラウド上で実際にコードを操作します。同じOpenAIのサービスでも、「相談相手」としての生成AIと、「作業者」としてのCodexという役割の違いを押さえておくと、設定の意味も理解しやすくなります。

Codexの3つの利用形態と始め方

Codexには複数の利用形態があり、どれを使うかによって設定の入り口が変わります。ここではまず、代表的な3つの形態と選び方を整理します。

Codexは、ターミナルで動く「Codex CLI」、エディタに組み込む「IDE拡張」、OpenAIの管理環境で動く「クラウド版」という形で利用できます。それぞれ得意な場面が異なるため、自分の使い方に近いものから始めるのがおすすめです。

Codex CLI（ターミナルで使う）

Codex CLIは、CLI（Command Line Interface、コマンド操作でツールを動かす方式）でCodexを利用する形態です。手元の環境にインストールして使うため、ローカルのファイルやコマンドを直接扱えるのが特徴です。設定ファイルもこのローカル環境に置くため、後述するconfig.tomlやAGENTS.mdによる細かい制御と最も相性が良い形態と言えます。まずは小さなリポジトリで試し、挙動を確認してから本格的に使い始めると、設定の勘所をつかみやすくなります。

IDE拡張（VS Codeなどで使う）

IDE（Integrated Development Environment、統合開発環境）向けの拡張機能として提供される形態です。VS Codeなどのエディタ上でCodexを呼び出せるため、普段の開発画面を離れずに指示を出せます。コードを見ながら対話的に修正を依頼したい場合に向いています。CLIと同じ設定ファイルの考え方が使えるため、両方を併用しても設定の知識を流用できます。

クラウド版・アプリ版（隔離環境で使う）

クラウド版は、OpenAIが管理する隔離されたコンテナ内でCodexが動く形態です。手元の環境を直接触らせたくない場合や、複数の作業を並行させたい場合に向いています。このほか、macOS・Windows向けのデスクトップアプリやWeb・モバイルからの利用も提供されており、Codexは幅広い入り口から使えるようになっています。まずは自分の開発スタイルに近い形態を1つ選び、そこから設定に慣れていくのがおすすめです。

Codexの基本設定｜config.tomlとAGENTS.mdの役割

Codexの設定の中心になるのが、「config.toml」と「AGENTS.md」という2つのファイルです。役割がはっきり分かれているため、それぞれ何を書く場所なのかを理解しておくと、設定で迷いにくくなります。

config.tomlはCodexの動作そのものを決める設定ファイル、AGENTS.mdはCodexにプロジェクトの前提や作業ルールを伝える説明書、という住み分けです。以下でそれぞれの役割と書き方の要点を見ていきます。

config.tomlの役割と置き場所

config.tomlは、使用するモデルや承認ポリシー、サンドボックス（sandbox、外部への影響を隔離した実行環境）の設定などを記述する、TOML（設定を記述するためのファイル形式）のファイルです。ユーザー全体に効く設定は~/.codex/config.tomlに置き、プロジェクトごとに変えたい設定はリポジトリ内の.codex/config.tomlで上書きする、という階層構造になっています。設定は優先順位を持って解決され、コマンド実行時のフラグ指定が最も優先され、続いてプロジェクト設定、ユーザー設定、標準の初期値という順で適用されます。まずはユーザー設定に基本を書き、プロジェクト固有の事情だけをリポジトリ側で上書きすると、管理がすっきりします。

主に設定できる代表的な項目は次のとおりです。

• model：既定で使用するモデルを指定する
• approval_policy：コマンド実行前に承認を求めるタイミングを制御する
• sandbox_mode：コマンド実行時に許可する操作の範囲を制御する
• mcp_servers：MCP（Model Context Protocol、AIに外部ツール連携を追加する仕組み）サーバーの接続設定を行う

これらのうち、特にapproval_policyとsandbox_modeは安全性に直結するため、次のセクションで重点的に解説します。まずはmodelだけを指定して動かし、慣れてきたら権限系の項目を調整していく流れがおすすめです。

AGENTS.mdの役割と書き方

AGENTS.mdは、Codexに対する「プロジェクトのREADME（説明書）」のような役割を持つMarkdownファイルです。ここには、セットアップ手順・ビルドやテストの方法・コーディング規約・触ってほしくない領域といった、作業の前提になる情報を書きます。Codexはこの内容を踏まえて作業を進めるため、プロジェクト固有のルールを明文化しておくと、指示のたびに同じ説明を繰り返さずに済みます。

AGENTS.mdは階層的に扱われ、編集中のファイルに近い場所のAGENTS.mdが優先され、上位のファイルはフォールバック（補完）として機能します。リポジトリ全体の共通ルールはルートに置き、特定の領域だけの細かいルールはその領域のフォルダに追加する、という使い分けが向いています。内容が長くなりすぎる場合は、別のドキュメントに分けてAGENTS.mdからリンクすると読みやすさを保てます。なお、その場の指示（プロンプト）はAGENTS.mdの記述より優先されるため、一時的な例外はプロンプトで伝えれば問題ありません。

関連記事：AGENTS.mdとは？Codexにプロジェクト規約を守らせる設定と書き方

おすすめの最小構成から始める

最初から多くの項目を詰め込むと、どの設定が効いているのか分からなくなりがちです。おすすめは、config.tomlにmodelと権限系（approval_policy・sandbox_mode）の3項目だけを書き、AGENTS.mdにはビルド・テストの実行方法と「触ってほしくないディレクトリ」だけを短く書く、という最小構成から始める方法です。ここから使いながら、必要になった項目を1つずつ足していくと、各設定の役割を実感しながら整えられます。

権限とサンドボックスの設定でCodexを安全に使う

Codexはコマンドを実行できるからこそ、権限まわりの設定が安全に使うための要になります。ここではapproval_policyとsandbox_modeの2つを押さえます。

承認ポリシーは「どのタイミングで人間の確認を挟むか」を、サンドボックスは「そもそも何を実行できるか」を決める設定です。この2つを組み合わせて、自分が許容できるリスクの範囲を決めていきます。

承認モード（approval_policy）

承認ポリシーは、Codexが生成したコマンドを実行する前に、どのタイミングで停止して人間の承認を求めるかを制御します。代表的な値には、信頼できないコマンドの前に確認を求めるuntrusted、サンドボックスの範囲を超えるときに確認を求めるon-request、確認を求めずに進めるneverなどがあります。使い始めのうちは、実行内容を都度確認できる設定にしておくと、想定外の操作を早い段階で止められます。慣れて挙動が読めるようになってから、確認の頻度を下げていくのが安全な進め方です。

サンドボックス（sandbox_mode）

サンドボックスは、Codexがコマンドを実行する際に、技術的に何を許可するかをOS側で制限する仕組みです。代表的な値として、ファイルの閲覧のみ許可するread-only、作業ディレクトリ内での編集や通常のコマンド実行を許可するworkspace-write、制限を外すdanger-full-accessがあります。名前のとおりdanger-full-accessは制限がなくなるため、必要な場面に限って慎重に使うべき設定です。多くの場合はworkspace-writeを基本にし、まず様子を見たいときはread-onlyから始めると、リスクを抑えながら使えます。書き込みを許可するディレクトリをさらに絞り込む設定も用意されているため、扱うプロジェクトに応じて範囲を狭めておくと安心です。

関連記事：Codexのサンドボックスとは？仕組み・3つのモード・安全な設定を整理

Codexの料金プラン｜無料でどこまで使える？

Codexを設定する前に、自分のプランで何がどこまで使えるかを把握しておくと、設定の判断がしやすくなります。

Codexは、ChatGPTのサブスクリプションに組み込まれており、Free・Plus・Pro・Business・Edu・Enterpriseの各プランで利用できます（2026年7月時点、出典: openai.com）。無料のFreeプランでも、WebアプリやCLI、IDE拡張などからCodexを試せますが、利用範囲は限定的です。本格的に使う場合は、有料プランで利用枠を広げるのが一般的です。主なプランの位置づけは次のとおりです。

上記は2026年7月時点の目安です（出典: openai.com）。利用量はクレジット（利用枠）として計測され、一定時間ごとの枠内で使う仕組みが導入されています。最新の料金や利用枠は変更されることがあるため、契約前に必ずOpenAI公式の料金ページで確認してください。なお、APIキー経由でモデルを直接利用する場合は、サブスクリプションとは別に、使ったトークン量に応じた従量課金となります。

CodexとClaude Code・Gemini CLIの設定の違い

Codexの設定に慣れてくると、他のAIコーディングエージェントとの違いも気になってきます。ここでは代表的なClaude Code・Gemini CLIと、設定の考え方を比べます。

いずれもターミナルで動くAIエージェントですが、設定ファイルの形式やプロジェクトへの指示の与え方に違いがあります。下表は、設定ファイル・プロジェクト指示・権限管理の3つの観点で3者を整理したものです。移行や併用を検討する際は、それぞれの流儀を押さえておくと迷いにくくなります。

Codexは、承認ポリシーとサンドボックスによる制御を前面に出し、実行の安全性を細かく調整できる設計になっています。一方でClaude CodeやGemini CLIは、JSON形式の設定ファイルを中心に据えています。たとえば複数のエージェントを併用する場合は、この「TOMLかJSONか」「指示ファイルの名前は何か」という違いを把握しておくと、設定を移し替える際の混乱を減らせます。

関連記事：Claude Code と Codex の違い｜5 つの観点で整理し用途別に選び分ける

すぐ使えるCodexおすすめ設定チェックリスト

ここまでの内容を踏まえ、Codexを安全かつ効率的に使い始めるためのおすすめ設定を、チェックリストにまとめます。設定に着手する前や、見直しのタイミングで活用してください。

• 利用形態（CLI／IDE拡張／クラウド版）を1つ選び、そこから始めているか
• config.tomlはユーザー設定（~/.codex/config.toml）を基本にし、プロジェクト固有の事情だけをリポジトリ側で上書きしているか
• config.tomlはmodelと権限系（approval_policy・sandbox_mode）から最小構成で書き始めているか
• 使い始めは承認ポリシーを都度確認できる設定にし、挙動を見ながら緩めているか
• サンドボックスはworkspace-writeを基本にし、必要に応じてread-onlyから様子を見ているか
• 書き込みを許可するディレクトリを、扱うプロジェクトに応じて絞り込んでいるか
• AGENTS.mdにビルド・テストの方法と「触ってほしくない領域」を短く明記しているか
• 自分のプランで使える利用枠を把握したうえで運用しているか

このチェックリストをひととおり満たしていれば、想定外の操作を避けながら、Codexの効率を引き出しやすくなります。すべてを一度に完璧にする必要はなく、使いながら1項目ずつ整えていく形で問題ありません。

Codexを業務に取り入れるときに陥りがちな3つの落とし穴

CodexのようなAIエージェントを実務に取り入れるとき、設定以前の進め方でつまずくケースがよくあります。ここでは、多くの現場で見られる3つの落とし穴を整理します。

落とし穴1：いきなり全ての工程を任せようとする

最初から広い範囲の作業を一気に任せようとすると、AIの挙動を把握しきれず、かえって確認や手戻りが増えてしまいます。範囲を欲張るほど、権限設定も緩めがちになり、リスクも大きくなります。

落とし穴2：壮大な活用構想から入って最初の設定で止まる

「開発全体をAIで効率化する」といった大きな構想から始めると、設定すべき項目が膨らみ、最初の一歩を踏み出す前に手が止まりがちです。理想像を描くこと自体は悪くありませんが、着手の入り口としては重すぎます。

落とし穴3：既製の汎用AIのままでは業務フローに組み込めない

汎用のチャット型AIをそのまま使おうとすると、自社の手順やルールに合わせた作り込みが難しく、実務で任せられる質に届かないことがあります。設定やルールでカスタマイズできる余地があるかどうかは、定着を左右する分かれ目になります。

スモールスタートで1つの工程から任せるのがポイント

これらの落とし穴を避ける近道は、スモールスタートです。まずは1つの定型作業や1つの工程だけをCodexに任せ、承認ポリシーやサンドボックスを絞った状態で挙動を確かめます。そこで得た手応えをもとに、任せる範囲を少しずつ広げていくと、無理なく実務に定着させられます。

自社業務でAIエージェント活用を進めたい方へ

ここまで紹介してきた「1つの工程から小さく始める」という進め方を、自社の業務で実践したいとお考えの方もいらっしゃるかもしれません。

GiftXでは、業務に合わせたAIエージェントの構築支援サービス「GiftX AIエージェント構築支援」を提供しています。1業務単位のスモールスタートから、実際の業務フローに組み込めるレベルのAIエージェント構築までを伴走します。

詳細はGiftX AIエージェント構築支援のサービスサイトでご覧いただけます。

Codexの設定に関するよくある質問

Codexの設定を進めるうえで、多くの方が抱きやすい疑問をまとめます。

Codexの初期設定では何をすればいいですか？

まず利用形態を1つ選び、config.tomlにmodelと権限系（approval_policy・sandbox_mode）を書くところから始めるのがおすすめです。あわせてAGENTS.mdに、ビルド・テストの方法と触ってほしくない領域を短く記しておくと、以降の指示がスムーズになります。

Codexは無料で使えますか？

ChatGPTのFreeプランでも、限定的な範囲でCodexを試せます（2026年7月時点、出典: openai.com）。本格的に使う場合は、Plusなどの有料プランで利用枠を広げるのが一般的です。最新の条件は公式の料金ページで確認してください。

権限設定を間違えると危険ですか？

サンドボックスのdanger-full-accessのように制限を外す設定は、意図しない操作を許してしまうおそれがあります。使い始めはread-onlyやworkspace-writeなど範囲を絞った設定にし、承認ポリシーで実行前の確認を挟んでおくと、リスクを抑えられます。

CodexとClaude Codeの違いは何ですか？

設定ファイルの形式が異なり、Codexはconfig.toml（TOML形式）とAGENTS.md、Claude Codeはsettings.json（JSON形式）とCLAUDE.mdを使います。Codexは承認ポリシーとサンドボックスによる実行制御を前面に出している点が特徴です。

まとめ

Codexの設定は、利用形態を1つ選び、config.tomlとAGENTS.mdの役割を理解し、承認ポリシーとサンドボックスで安全な範囲を決める、という順で押さえると迷いにくくなります。最初から全項目を完璧にする必要はなく、最小構成から始めて使いながら整えていくのがおすすめです。そして実務への定着で最も大切なのは、いきなり全体を任せようとせず、1つの工程から小さく始めることです。スモールスタートで手応えを確かめながら、少しずつ任せる範囲を広げていきましょう。

AIエージェントの活用・構築をご検討の方へ

本記事で紹介したCodexのようなAIエージェントを、自社の業務でも具体的に活用したい・相談したいとお考えの方は、ぜひGiftX AIエージェント構築支援までお問い合わせください。

GiftX AIエージェント構築支援では、貴社の業務に合わせて1業務単位のスモールスタートから本番運用まで、AIエージェント構築をワンストップで支援します。ユースケースの洗い出しから、試験導入、本番運用、社内へのナレッジ定着まで伴走します。

AI活用にご関心のある方は、ぜひ一度ご相談ください。

▶ GiftX AIエージェント構築支援の詳細・お問い合わせはこちら

関連記事

• Codex の環境構築｜CLI・IDE 拡張・クラウドの選び方とセットアップ手順
• Codex CLI とは？できること・料金・Claude Code との違いを整理
• Codexの料金はいくら？ChatGPTプラン別の使える範囲とAPI従量課金を整理
• VSCode での Codex の使い方｜インストール手順・料金・CLI との違い