Codexのカスタマイズ機能「features」とは？
OpenAI Codexを使う際、~/.codex/config.tomlの中で追加機能や実験的機能をオンオフできる[features]設定が用意されています。
公式ドキュメントに記載はありますが、あまり言及されることの少ない設定項目です。適切に有効化すると、エージェントに過去の会話コンテキストを引き継がせたり、コマンド実行の前後に独自のスクリプトを走らせたりといったカスタマイズができるようになります。
この記事では、知っておくと便利な[features]の主要な設定キーと、これらを活用した記述例、および再現性を重視した設定の考え方を整理します。
動作確認時の主要バージョン
- OS：Windows 11 (PowerShell 7)
- ツール：Codex v0.142.0
- ランタイム：Node.js v22
設定ファイルの優先順位と構成の全体像
Codexの設定は、ユーザー個人の環境とプロジェクトごとの設定で上書きの優先順位が決まっています。
基本的には、以下の優先順位に従って設定が評価されます。
flowchart TB
A[システム標準値] --> B["ユーザー共通設定 (~/.codex/config.toml)"]
B --> C["プロファイル指定設定 (--profile)"]
C --> D["プロジェクト固有設定 (.codex/config.toml)"]
D --> E["CLIフラグや--configによる一時指定"]
普段は、基本設定を~/.codex/config.tomlに書き、プロジェクト固有の特別な設定だけをプロジェクト配下の.codex/config.tomlで上書きする構成が扱いやすいでしょう。
Noteプロジェクト固有設定の読み込み制限
リポジトリ内の.codex/config.tomlは、そのプロジェクトがCodex側で信頼（trust）されている場合にのみ適用されます。外部の信頼できないリポジトリを開いた際に、悪意のある設定やコマンド実行フックが勝手に読み込まれるリスクを防ぐためです。
features設定キーの詳細と推奨値
OpenAI公式の構成リファレンスに掲載されている[features]の主要設定と、推奨される指定方法を整理しました。
2026年7月時点における公式リファレンスに基づいています。
| 設定キー | デフォルト | 成熟度 | 説明 | 推奨設定 |
|---|---|---|---|---|
apps | false | Experimental | ChatGPT Appsおよびコネクターのサポートを有効化。ローカル開発では未設定で問題ありません。 | 未設定 |
codex_git_commit | false | Experimental | 生成されたGitコミットやAttribution trailersを有効化。文責を厳密に分けたい場合に利用します。 | 未設定 |
hooks | true | Stable | ライフサイクルフックの有効化。hooks.jsonやインライン設定から読み込まれます。旧名のcodex_hooksは非推奨。 | true |
fast_mode | true | Stable | TUI上でFast modeまたは特定のサービスクラスを選べるようにします。 | デフォルトのまま |
memories | false | Stable | 過去スレッドから有用なコンテキストを引き継ぐためのMemories機能を有効化します。 | true |
multi_agent | true | Stable | 複数のサブエージェント（Subagents）の並列起用ツールを有効化します。 | デフォルトのまま |
personality | true | Stable | コミュニケーションスタイルを選択するための/personalityコマンド等を有効化します。 | デフォルトのまま |
shell_snapshot | true | Stable | シェル環境のスナップショットを用い、繰り返しコマンドの実行を高速化します。 | デフォルトのまま |
shell_tool | true | Stable | コマンド実行用の標準shellツールを有効化します。 | デフォルトのまま |
unified_exec | Windows以外はtrue | Stable | PTYベースのコマンド実行ツールを使います。Windowsでは動作が不安定になるため、未設定（またはfalse）を推奨。 | 未設定 |
undo | false | Stable | ターンごとのGitのスナップショットによる取り消し（Undo）機能を有効化します。 | 未設定 |
web_search | true | Deprecated | 旧式のトグル。現在はトップレベルのweb_searchによる指定が推奨されます。 | 使用しない |
web_searchはトップレベルでの指定が推奨
古いドキュメントやネットの記事では、[features]の下にweb_search = trueやweb_search_request = trueといったトグルを指定している例があります。しかし、これらは非推奨（Deprecated）の古い設定です。
現在Web検索をコントロールする場合は、以下のように[features]の外（トップレベル）で明示的に指定します。
# ~/.codex/config.toml
# cached: OpenAI管理の検索キャッシュを使用（デフォルト）
# live: 最新のリアルタイム検索結果をフェッチする
# disabled: 検索を無効化する
web_search = "cached"
通常はcachedで動作を安定させ、ライブラリの最新仕様や一時的なバグ情報を調べる必要がある場合のみ一時的にliveに切り替えるか、CLI側で--searchフラグを併用するのが効率的です。
チーム開発を想定した設定の考え方と構成
複数の開発メンバーや異なるエージェント環境が混在するプロジェクトでは、環境依存を減らし再現性を高める工夫が重要です。ここでは、設定ファイルとプロジェクト共有ルールの切り分けについて、推奨する整理方法を紹介します。
1. memoriesは個人の補助記憶にとどめる（AGENTS.mdなどでのルール共有を推奨）
過去の会話コンテキストを引き継ぐmemories = trueは便利ですが、構築される記憶はエージェント個人（特定のローカル環境）の範囲に閉じます。
そのため、プロジェクト独自のコーディング規約や設計ルールなどの「必ず守るべき規約」を会話の中で記憶させる（Memoriesに依存する）のは避けるべきです。他の開発メンバーや、別のエージェント環境で作業する際、前提知識が引き継がれず再現性が失われる原因になります。
共通ルールやコーディング規約は、個人のmemoriesに学習させるのではなく、AGENTS.mdなどで明文化し、Git管理してチームで共有する方が環境を選ばず確実に動作します。
2. デフォルトがtrueのstable機能はあえて記述しない
multi_agentやshell_snapshotなど、すでに安定版（Stable）かつデフォルトでtrueになっているキーは、設定ファイルに明示的に記述する必要はありません。
設定ファイルが肥大化すると、「意図して変更した設定」と「デフォルト値」の区別がつかなくなり、環境移行やトラブルシューティング時のノイズになります。
3. hooksによる自動化は共有スクリプトと組み合わせる
セッション開始時やコマンド実行前後に処理を実行できるhooksは便利ですが、設定や挙動がローカル環境に依存しやすくなります。
個人の環境だけで動く複雑なフック処理を書くよりも、呼び出すスクリプト自体をリポジトリ内に用意し、フックからはそれを実行するだけにしておけば、チーム全員で同じチェックが実行できます。
config.tomlの実用的な記述例
上記の方針を踏まえた、~/.codex/config.tomlの具体的な記述例です。
# ~/.codex/config.toml
# 2026年6月末の旧モデル廃止に伴い、フラッグシップのgpt-5.5を指定
model = "gpt-5.5"
model_reasoning_effort = "medium"
# サンドボックスとコマンド承認の基本方針
approval_policy = "on-request"
sandbox_mode = "workspace-write"
# 検索は不要なトークン消費を抑えるためキャッシュを標準とする
web_search = "cached"
# 応答スタイル
personality = "pragmatic"
[features]
# 文脈の継続（個人の作業履歴の補助）
memories = true
# フック機能を有効化（実際の実行スクリプトはプロジェクト側で共有）
hooks = true
# stableかつデフォルトがtrueの項目はコメントアウト
# multi_agent = true
# shell_snapshot = true
# shell_tool = true
# Windows環境における管理者権限の明示
[windows]
sandbox = "elevated"
まとめ：個人設定と共通ルールの使い分け
Codexの[features]には便利な実験的機能が多く含まれていますが、その設定を個人のconfig.tomlやmemoriesに任せきりにすると、環境による再現性が失われてしまいます。
開発環境をチームで共有し、複数のメンバーや別々のエージェントが参加しても問題なく自律動作するリポジトリにするためには、以下のような役割分担をイメージすると分かりやすいでしょう。
flowchart TB
A["個人の設定 (~/.codex/config.toml)"] -->|主に制御するのは| B[権限・モデル・個人用補助記憶]
C["共有の構成 (AGENTS.md / docs/)"] -->|主に規定するのは| D[プロジェクト規約・開発フロー・共通スキル]
- 個別の環境設定（
config.toml）は、モデル選択やサンドボックスのセキュリティレベル、featuresの有効化といったシステム側の動作を制御するために使う（※featuresのオン・オフ設定などはAGENTS.mdに記述しても機能しないため、必ずconfig.tomlで行います）。 - プロジェクト固有のコーディング規約やエージェントに期待する役割は、リポジトリに明文化された「共有のドキュメント（
AGENTS.md）」で規定する。
この2層を整理しておくことで、ツールのアップデート時の影響を最小限に抑えられます。まずはローカル設定で好みの応答や補助機能を試しつつ、プロジェクトで守りたい規約は共通ドキュメントに寄せていく構成を推奨します。
コメント