Codex のウェブ検索 — 有効化と cached/live の使い分け
Codex に「最新のライブラリ仕様を調べてから直して」と頼んでも、学習データだけでは情報が古く、誤った前提のまま手が止まることがある。これを補うのが Codex 標準のウェブ検索だ。2026年6月3日に発表された「新しい Codex」で Goal Mode が正式版となり、長時間の自律タスクほど最新情報を取り込む価値が高まっている。本記事では、ウェブ検索が既定でどう動くか、cached と live の違い、--search と config.toml での切り替え、そして検索範囲を絞る設定までを順に整理する。
Codex のウェブ検索は、モデルに外部の最新情報を取りに行かせる標準ツールだ。Codex CLI のローカルタスクでは既定で有効になっており、追加設定なしでも、まずは OpenAI が管理する検索キャッシュ（cached）から結果を返す。ライブでページを取りに行くのではなく索引を引く設計なので、速度と再現性を保ちながら学習データの鮮度不足をある程度補える（出典: https://developers.openai.com/codex/cli/features ）。
より新しいデータが要るときはライブ取得（live）に切り替える。単発なら codex --search、既定値を変えるなら ~/.codex/config.toml の web_search = "live" を使う。--yolo などフルアクセスのサンドボックス設定では自動的に live が既定になり、逆に検索を切りたい場合は web_search = "disabled" でツールごと外せる（出典: https://developers.openai.com/codex/config-reference ）。
検索の粒度は tools.web_search のオブジェクト指定で調整でき、context_size や allowed_domains、おおよその地域まで絞り込める。Goal Mode が正式版となり長時間タスクを任せる場面が増えた今、古い前提で走り続けるリスクを抑える意味で、ウェブ検索のモード選択は地味だが効く初期設定になる。
目次 (7)
Codex のウェブ検索とは — 既定で動く「最新情報」の窓口
Codex には第一級のウェブ検索ツールが標準で組み込まれている。OpenAI の公式ドキュメントは「Codex はファーストパーティのウェブ検索ツールを同梱しており、Codex CLI のローカルタスクでは既定でウェブ検索を有効化し、検索キャッシュから結果を返す」と明記している（出典: https://developers.openai.com/codex/cli/features ）。つまり、利用者が何も設定しなくても、モデルは必要だと判断したタイミングで自分から検索を呼び出す。返ってくる結果は既定では OpenAI が管理する検索インデックスからのもので、その場でウェブページを取りに行くわけではない。
この「既定でオン・既定はキャッシュ」という設計は、速度と再現性を確保しつつ、学習データだけでは届かない鮮度を補うための妥協点だ。ライブ取得は最新だが遅く、ネットワークアクセスを伴うぶん実行環境への要求も上がる。一方でキャッシュは索引を引くだけなので速く、同じ問い合わせなら結果がぶれにくい。Codex はまずこの安全側の既定から始め、利用者が必要に応じてライブへ引き上げられるようになっている。
なぜ今ウェブ検索なのか — Goal Mode 正式版で鮮度が効く
2026年6月3日、OpenAI は「新しい Codex」を発表し、長時間タスクを自律実行する Goal Mode が正式版となった（出典: https://openai.com/codex/ ）。エージェントが数十分から数時間にわたって動くほど、途中で参照する情報が古いと、誤った API 仕様や廃止済みの手順を前提に作業が積み上がってしまう。走り始める前ではなく作業中に最新の一次情報を引けるウェブ検索は、長時間の自律実行と組み合わせたときに効果が大きい。だからこそ、どのモードで検索させるかを最初に決めておく価値がある。
cached と live の違い — キャッシュ索引か実時間取得か
ウェブ検索の挙動を決めるのは、トップレベルの web_search 設定だ。値は disabled / cached / live の三つを取り、既定は cached になっている（出典: https://developers.openai.com/codex/config-reference ）。cached は OpenAI が管理するインデックスを使い、ライブのページ取得は行わない。速度と再現性に優れ、日常的な「だいたい最近の情報を踏まえたい」用途にはこれで足りることが多い。
live は最新データをその場でウェブから取得するモードで、--search フラグと同じ動作にあたる。リリース直後の変更点や、キャッシュにまだ載っていない情報を確実に踏まえたいときに使う。公式リファレンスによれば、--yolo などフルアクセスのサンドボックス設定を使っている場合は web_search の既定が live に切り替わる。disabled を指定すると検索ツールそのものがモデルから外れるため、外部参照を完全に断ちたい環境ではこれを選ぶ。三者の違いを表にまとめると次のようになる。
| 値 | 取得元 | 主な用途 |
|---|---|---|
cached（既定） |
OpenAI 管理の検索インデックス | 速度・再現性を優先する日常作業 |
live |
その場でウェブから取得 | リリース直後など最新性が必須の調査 |
disabled |
検索しない（ツールを外す） | 外部参照を遮断したい閉じた環境 |
ウェブ検索を有効化・切り替える方法
既定で有効とはいえ、用途に応じてモードを切り替えるのが実践のコツだ。設定の入口は次の三つに整理できる。
- 単発で最新情報を取りに行く: その実行だけライブ取得したいなら
codex --searchを付けて起動する。既定のcached設定はそのままに、その回の作業に限ってウェブから最新データを引ける。リリース直後の仕様確認のように「今だけ最新がほしい」場面に向く。 - 既定モードを config.toml で固定する: 常にライブで動かしたい、あるいは常に検索を切りたい場合は、
~/.codex/config.tomlにweb_search = "live"（または"disabled"）を書く。プロジェクトの性格に合わせて既定値を一度決めておけば、毎回フラグを付け直す手間がなくなる。 - 旧来の features. キーから移行する*: 以前は
features.web_searchやfeatures.web_search_requestといったトグルで制御していたが、これらは現在は非推奨だ。公式リファレンスは「トップレベルのweb_search設定を使うこと」を推奨しており、features.web_search_cachedはcachedに、features.web_search_requestはliveに対応づけられる（出典: https://developers.openai.com/codex/config-reference ）。古い設定が残っているなら、この機会にトップレベルへ寄せておくと混乱が減る。
いずれの方法でも、検索を呼び出すかどうかの最終判断はモデル側が文脈に応じて行う。利用者が決めるのは「どのモードで検索を許すか」という枠組みであり、--search や web_search はその枠を切り替えるスイッチだと捉えると分かりやすい。
検索の範囲と精度を絞る tools.web_search
検索のオン・オフだけでなく、検索の中身を細かく制御したい場合は tools.web_search を使う。公式リファレンスによれば、この設定は従来のブール値（true / false）に加えて、オブジェクト形式での詳細指定を受け付ける（出典: https://developers.openai.com/codex/config-reference ）。オブジェクト形式では、検索コンテキストの大きさを示す context_size（low / medium / high）、参照を許可するドメインを並べる allowed_domains、そしておおよその利用地域を表す location（country / region / city / timezone）を指定できる。
実務上は、allowed_domains に公式ドキュメントや信頼できる一次情報のドメインだけを並べると、ノイズの多い二次情報に引っ張られにくくなる。context_size を上げれば一度に取り込む検索文脈が増えるぶん精度は上がるが、トークン消費も増えるため、調査の重さに応じて調整するのが現実的だ。location は地域差のある情報（料金表記や提供範囲など）を扱うときに効く。レガシーのブール指定も引き続き受け付けられるので、まずは既定のまま使い、必要になった段階でオブジェクト形式へ移行すればよい。
安全に使うときの注意点 — サンドボックスと結果の扱い
ライブ取得はネットワークアクセスを前提とするため、サンドボックス設定との関係を理解しておきたい。live がフルアクセス時に既定となるのは、実時間取得が外部通信を必要とするからだ。逆に言えば、閉じた環境で再現性を重視するなら cached、外部参照を一切断ちたいなら disabled という選び分けになる。長時間の自律タスクを任せるほど、どこまで外に出てよいかをあらかじめ決めておくことが、想定外の挙動を避ける近道になる。
検索結果そのものの扱いにも注意が要る。ウェブ上の情報には誤りや古い記述が混ざるため、モデルが拾った内容を鵜呑みにせず、重要な判断は公式ドキュメントなど一次情報で裏取りする姿勢が前提になる。allowed_domains で参照先を絞るのは、この裏取りの手間を構造的に減らす一手だ。Codex 自身の挙動や設定キーの最新仕様についても、openai/codex の公式ドキュメントとリポジトリ（https://github.com/openai/codex ）を起点に確認しておくと、版による差異に振り回されにくい。
まとめ — モード選択を最初に決めておく
Codex のウェブ検索は、既定で有効・既定は cached という安全側の設計から始まり、必要に応じて live へ引き上げ、不要なら disabled で外すという三段の選択肢を持つ。単発なら --search、恒常的に変えるなら config.toml の web_search、さらに絞り込むなら tools.web_search のオブジェクト指定、というように、求める鮮度と制御の細かさに応じて使い分けられる。Goal Mode が正式版となり長時間タスクを任せる場面が増えた今こそ、最初にモードを決めておくことが、古い前提で走り続けるリスクを抑える最短ルートになる。
