Codex設定を増やす前に決めること

3行まとめ

config

実行の初期値。

permissions

許可と確認。

rules

command制御。

AGENTS

repo作業契約。

MCP/skills

拡張と手順。

設定を増やす前に、どこへ置くかを決めます。

• Codex設定は、config.toml、permissions、rules、AGENTS.md、MCP、skillsを同じ場所へ詰め込まず、役割で分けます。
• config.tomlは個人環境の初期値、permissionsとrulesは実行境界、AGENTS.mdはrepoの作業契約として扱うと散らかりにくくなります。
• MCPやskillsを足す前に、接続先、許可command、報告形式、チーム共有の範囲を決めます。

この記事では、OpenAI公式のConfig basics、Advanced Configuration、Configuration Reference、Permissions、Rules、AGENTS.md、MCP、Skills docsを確認し、2026年6月1日時点の情報として整理しています。設定項目や既定値は変わり得るため、導入時には最新docsと手元のCodex設定を再確認してください。

この記事でわかること

Personal

個人設定。

Shared

repo共有。

Enforced

強制境界。

Guidance

自然言語指示。

自然言語の指示と実行権限を混ぜないことが出発点です。

• Codex設定をどこに置くべきか
• config.tomlに入れるものと入れないもの
• permissionsとrulesで実行境界を作る考え方
• AGENTS.mdへ移すべきrepo固有ルール
• MCPやskillsを追加する前の確認項目
• 個人設定とチーム共有設定を混ぜない方法
• 導入初週に整理する順番

Codexを使い始めると、設定を足したくなる場面が増えます。モデルを変えたい、sandboxを緩めたい、特定commandを許可したい、AGENTS.mdに注意事項を書きたい、MCP serverを足したい、skillで手順を固定したい。どれも自然な流れです。

ただし、設定が増えるほど「どこに何を書いたか」が見えにくくなります。個人の便利設定とrepoの作業契約、自然言語の指示と実行を止める境界、外部tool接続と作業手順を混ぜると、後から直しにくくなります。

前提知識

項目	内容	見方
Config		TOMLとprofiles。
Permissions		approvalとsandbox。
Rules		command match。
AGENTS.md		repo指示。
MCP/Skills		拡張。

画面や項目は更新されるため、導入時に最新docsを確認します。

CodexのConfig basics docsでは、CodexがTOML形式の設定ファイルを使い、モデル、sandbox、approval、profilesなどの設定を扱えることが説明されています。Advanced ConfigurationとConfiguration Referenceでは、より細かい項目やprofiles、tool、MCP、projectsなどの設定が確認できます。

一方、Permissions docsやRules docsは、何を許可し、何を確認し、何を止めるかに関わる設定です。AGENTS.md docsは、repo内でCodexに読ませたい作業指示を扱います。MCPとSkillsは、外部toolや再利用手順を足す入口です。

公式情報で確認する範囲

確認先	見ること
Config basics	config.toml、基本設定、profiles
Advanced Configuration	詳細設定、project、MCP、tool関連
Configuration Reference	設定項目の一覧と意味
Permissions / Rules	approval、sandbox、command制御
AGENTS.md	repoごとの作業指示
MCP / Skills	外部tool接続と手順の再利用

注意点

この記事は、特定の設定値をそのまま推奨するものではありません。team、repo、機密性、CI、network方針、利用するpluginやMCPによって安全な初期値は変わります。ここでは、設定を増やす前に置き場所を分けるための手順として扱います。

また、AGENTS.mdや自然言語の指示は強制境界ではありません。危険な操作を止めたい場合は、permissions、rules、sandbox、network policy、branch protection、human reviewのような仕組みへ落とします。

まず設定の置き場所を分ける

項目	内容	見方
User config		個人の初期値。
Repo docs		共有の作業契約。
Rules		実行制御。
Tools		外部接続。

どこに書くかを決めると、設定が増えても追いやすくなります。

最初に、Codex設定を4つへ分けます。

置き場所	役割	例
個人設定	自分の実行初期値	model、profile、sandbox初期値
repo共有	チームの作業契約	AGENTS.md、テスト手順
実行境界	許可、確認、拒否	permissions、rules、network
拡張	toolや手順の追加	MCP、skills、plugins

この分類を持つだけで、設定の迷子がかなり減ります。「これは自分だけの好みか」「チームで共有すべき作業契約か」「実行を止めたい境界か」「外部toolを足しているのか」を分けて考えられるからです。

個人設定とrepo共有

個人設定は、自分の作業しやすさのためのものです。モデル、profile、sandboxの既定値、表示やログの好み、よく使うprovider設定などが入ります。

repo共有は、チームで同じように守りたい作業契約です。テストcommand、触ってよいpath、レビュー観点、報告形式、禁止したい大きな変更などです。

repoに残すべきもの

repoに残す候補は、次のようなものです。

項目	理由
必須test	誰が作業しても同じ検証が必要
architecture rule	repo固有の設計判断
review観点	domain上の見落としを減らす
変更範囲	触ってよい場所を共有する

逆に、個人のmodel preferenceや一時的なdebug設定はrepoへ入れません。

強制境界と作業指示

強制境界は、Codexが実行してよいこと、確認が必要なこと、止めることを決める設定です。作業指示は、Codexへ「こう進めてほしい」と伝える文脈です。

たとえば、「secretを表示しないで」は作業指示として書けます。ただし、secretを絶対に出したくないなら、表示できない権限、secret scan、ログ制御、rules、review gateを組み合わせます。

この分け方は、Codexに限りません。AIコーディングエージェント全般で、自然言語のお願いと実行境界を混ぜると危なくなります。

config.tomlは実行環境の初期値にする

Model

使うmodel。

Sandbox

既定の権限。

Approval

確認方針。

Profiles

用途別切替。

repoの作業契約を全部configへ入れないようにします。

config.tomlは、Codexを動かすときの初期値を置く場所です。Config basics docsでは、TOMLファイルでモデルやsandbox、approvalなどの設定を行えることが説明されています。Advanced Configurationではprofilesを使った切り替えも扱われています。

ここにrepo固有の長い作業ルールをすべて書くと、個人設定が肥大化します。config.tomlは、実行環境の初期値に寄せます。

modelやsandboxの初期値

config.tomlへ入れる候補は、次のようなものです。

項目	使いどころ
model	普段使うモデルの初期値
approval policy	確認を求める方針
sandbox mode	fileやnetworkの初期権限
projects	projectごとの既定値
MCP	接続するserverの定義

たとえば、普段は安全寄りのprofileを使い、必要なときだけ広い権限のprofileへ切り替える、という運用です。

configに入れないほうがよいもの

次のようなものは、config.tomlだけに閉じ込めないほうがよいです。

項目	置き場所の候補
repo固有のtest手順	AGENTS.md、README、CI
domain rule	AGENTS.md、docs
チームのreview基準	AGENTS.md、PR template
secret値	secret manager、環境変数管理

個人のconfigにしか書かれていないルールは、他の人やCIに伝わりません。

profilesで用途を分ける

profilesは、作業の種類で設定を切り替えるために使います。たとえば、調査用、実装修正用、広いrefactor用、外部通信ありの調査用を分けます。

profile	初期値の考え方
research	read-only寄り、networkは必要時のみ
edit	workspace内の変更を許可
review	diff確認と報告重視
risky	承認を厚くし、広い操作を避ける

profile名は、かっこよさより用途が分かる名前にします。チームで共有するなら、名前の意味もdocsへ残します。

permissionsとrulesで実行境界を作る

項目	内容	見方
Allow		常に許可。
Ask		確認する。
Deny		止める。
Rules		command単位。

危険操作は、お願い文ではなく設定で止める方向に寄せます。

Permissions docsとRules docsは、Codexの実行境界を考えるときに重要です。自然言語で「やらないで」と書くだけでなく、どのcommandを許可し、どのcommandを確認し、どのcommandを拒否するかを分けます。

deny/allow/askを分ける

最初に、操作を3つへ分けます。

扱い	例
allow	git diff, npm test, rg, ls
ask	npm install, dependency update, migration生成
deny	secret表示、deploy、本番DB操作、破壊的削除

すべてをaskにすると、作業が止まりがちです。すべてをallowにすると、事故時の影響範囲が広がります。安全な確認commandはallowし、差分や外部影響が出る操作はask、絶対に避けたい操作はdenyへ寄せます。

最初にdenyへ寄せる操作

最初のdeny候補は、次のようなものです。

操作	理由
secret表示	一度出ると回収が難しい
deploy	本番影響が大きい
production DB	data破壊や漏えいにつながる
destructive delete	復旧不能になりやすい
broad chmod/chown	local環境を壊しやすい

この一覧はrepoごとに変わります。大事なのは、危険操作を「気をつける」ではなく、設定で止める候補にすることです。

command単位で止める

Rules docsでは、commandや動作をmatchして制御する考え方が説明されています。チーム導入では、rulesを「禁止事項の文章」ではなく「実行前に止める条件」として扱います。

たとえば、git push、deploy command、production endpointへ向くcurl、secret fileをcatする操作などは、rulesでaskまたはdenyへ寄せる候補です。

Codex CLIをCIや自動実行へ持ち込む場合は、公開済み記事のCodex CLIをCIで回す前にも参考になります。自動実行ほど、rulesとapprovalの意味が大きくなります。

AGENTS.mdはrepoの作業契約にする

Tests

必須command。

Scope

触る範囲。

Review

見る観点。

Report

報告形式。

チームで共有したい作業ルールはrepo側に残します。

AGENTS.md docsでは、repo内にCodex向けのcustom instructionsを置く考え方が説明されています。ここに向いているのは、repo固有の作業契約です。

AGENTS.mdは、自然言語の指示です。実行境界ではありません。ただし、Codexが作業前に読む文脈としては非常に有効です。

テストやレビュー観点を書く

AGENTS.mdには、次のようなものを書きます。

Tests:

- Frontend changes: npm test and npm run typecheck.
- API changes: npm run test:api.
- If tests are not run, explain why.

Review focus:

- Check auth, tenant boundary, billing, and PII logs.
- Keep PRs small and report migration risk separately.

このように、作業後に人間が確認したい情報を先に固定します。

AGENTS.mdへ寄せるもの

AGENTS.mdへ寄せる候補は次の通りです。

項目	例
test command	package別の検証
architecture	触ってよい層、避ける層
reporting	変更、test、未検証、risk
review focus	security、billing、tenant

公開済み記事のチーム向けAGENTS.mdテンプレートでは、AGENTS.mdを権限、テスト、レビュー基準に分けて残す型を整理しています。

pathごとに近い指示を置く

大きなmonorepoでは、rootのAGENTS.mdだけでは足りないことがあります。auth package、billing package、admin app、mobile appで注意点が違うなら、近いdirectoryへ短いAGENTS.mdを置きます。

ただし、AGENTS.mdを増やしすぎると、どれが効いているか追いにくくなります。共通方針はroot、domain固有の注意は近いpath、という程度に留めます。

MCPとskillsは拡張の入口にする

項目	内容	見方
MCP		tool接続。
Skills		作業手順。
Plugins		配布単位。
Audit		権限確認。

便利な拡張ほど、接続先と使い方を分けて見ます。

MCPとskillsは、Codexの作業範囲を広げる強力な入口です。MCPは外部toolやdata sourceを接続し、skillsは繰り返し作業の手順をまとめます。便利な分、最初に境界を決めます。

外部toolを足す前に権限を見る

MCP serverを追加する前に、次を確認します。

観点	見ること
接続先	どのserviceやdataを見るか
操作	readだけか、writeもあるか
認証	token、scope、有効期限
ログ	何が記録されるか
失敗時	rollbackや再実行の扱い

MCP更新時の確認は、公開済み記事のMCP更新で壊さないための確認手順でも整理しています。Codex設定にMCPを足すときも、仕様、SDK、認可、Toolsの差分を分けて見ます。

繰り返し手順はskillへ寄せる

skillsは、毎回同じ説明をpromptへ書かないために使います。たとえば、WordPress公開、TestFlight upload、PR review、benchmark実行、監査レポート作成のような作業です。

skillへ寄せる候補は次の通りです。

項目	例
入力	article path、PR URL、target app
手順	調査、変更、検証、報告
tool	GitHub、browser、shell、API
成果物	report、diff、URL、QA結果

CodexのSkills、Plugins、Subagents、MCPの分担は、公開済み記事のCodexのSkills・Plugins・Subagents・MCPをチームで使う前にで詳しく整理しています。

導入初週の進め方

1. 1日目

   既存設定を棚卸し。

2. 2日目

   config初期値を整理。

3. 3日目

   rulesを追加。

4. 5日目

   AGENTS.mdへ移す。

5. 7日目

   MCP/skillsを見直す。

設定は増やすより、置き場所を揃えることを優先します。

Codex設定は、最初から完璧にしようとすると肥大化します。1週間で少しずつ整理するほうが安全です。

日	やること	見ること
1日目	既存configとAGENTS.mdを棚卸し	重複や古い設定
2日目	config.tomlを初期値に寄せる	repo固有ルールが混ざっていないか
3日目	permissionsとrulesを追加する	危険操作が止まるか
4日目	AGENTS.mdへ作業契約を移す	testと報告形式が明確か
5日目	MCP接続を棚卸しする	read/writeとtoken scope
7日目	skills化する手順を選ぶ	繰り返し作業だけに絞る

初週の目的は、設定を増やすことではありません。置き場所を揃えることです。設定が少なくても、どこに何を書くかが揃っていれば、後から安全に増やせます。

継続判断の基準

次の4つを満たすなら、チーム導入へ進めます。

判断	継続条件
分離	個人設定とrepo共有が分かれている
境界	危険操作がrulesやpermissionsで止まる
再現性	AGENTS.mdやskillsで手順が共有される
監査	MCPや外部toolの接続先が説明できる

満たさない場合は、新しいMCPやskillを足す前に、既存設定を削ります。設定は、増やすより見える状態に保つほうが重要です。

FAQ

Config?

個人初期値。

Rules?

実行境界。

AGENTS?

repo契約。

MCP?

tool接続。

迷ったら、強制したいのか、伝えたいのかを分けます。

config.tomlとAGENTS.mdの違いは何ですか

config.tomlはCodex実行環境の初期値です。AGENTS.mdはrepo固有の作業指示です。モデルやsandboxの既定値はconfig、テスト手順やレビュー観点はAGENTS.mdへ寄せると分かりやすくなります。

AGENTS.mdに禁止事項を書けば十分ですか

十分ではありません。AGENTS.mdは作業指示です。危険操作を止めたい場合は、permissions、rules、sandbox、network policy、branch protection、人間reviewへ落とします。

rulesはいつ必要ですか

特定commandを止めたい、確認させたい、常に許可したいときです。deploy、production DB、secret表示、破壊的削除、git pushなどはrulesで扱う候補です。

MCPはconfigに入れれば終わりですか

終わりではありません。接続先、認証、scope、read/write、ログ、失敗時の扱いを確認します。MCPは便利なtool接続ですが、外部権限を増やす入口でもあります。

skillsはAGENTS.mdの代わりになりますか

代わりではありません。AGENTS.mdはrepoの作業契約、skillは作業種類ごとの手順です。WordPress公開やPRレビューのような横断workflowはskill、repo固有のテストや設計ルールはAGENTS.mdへ寄せます。

次に読むなら

参照した主な情報源

• https://developers.openai.com/codex/config-basic
• https://developers.openai.com/codex/config-advanced
• https://developers.openai.com/codex/config-reference
• https://developers.openai.com/codex/permissions
• https://developers.openai.com/codex/rules
• https://developers.openai.com/codex/guides/agents-md
• https://developers.openai.com/codex/config/mcp
• https://developers.openai.com/codex/config/skills

更新履歴

1. 2026年6月1日

   OpenAI公式Codex docsを確認して初版を作成しました。

設定前には最新のCodex docsと手元のconfigを確認してください。

• 2026年6月1日: OpenAI公式Codex docsを確認し、config.toml、permissions、rules、AGENTS.md、MCP、skillsの置き場所を分ける記事として初版を作成しました。