Codex のインターネットアクセス制限と Web 検索の使い方
「Codex で npm install は動くのに、外部 API を呼び出すコードを実行すると失敗する」「最新ドキュメントを確認した上で実装してほしいのに、情報が古い」——こうした疑問の根本は Codex のサンドボックス設計にある。Codex は各タスクをネットワーク分離されたクラウド環境で実行しており、デフォルトではインターネット接続を持たない。本記事では、その理由と仕組み、そして情報収集が必要な場面でどう対処するかを整理する。
Codex はタスクを実行するとき、Docker ベースの隔離サンドボックスと呼ばれるクラウド環境上で動作する。この環境はデフォルトでインターネットへのアウトバウンド通信を遮断しており、外部サーバーへ HTTP リクエストを送信したり、一般の Web サイトにアクセスしたりすることはできない。これはセキュリティ設計の一環であり、エージェントが意図せず外部にデータを送信するリスクや、予期しないパッケージを取り込むリスクを最小化するための措置だ。
一方、Codex には組み込みの Web 検索ツールが用意されており、プロンプトで指示するかプロジェクト設定ファイルに記述することで、サンドボックス外から Web の情報を取得できる。Web 検索はモデルがネットに「直接アクセス」するのではなく、OpenAI 側が管理するツール経由で安全に結果を返す仕組みだ。AGENTS.md にツールの使用方針を記述することで、Codex が積極的に情報収集を行うよう動作を調整できる。
外部 API の疎通確認やサードパーティ SDK の動作確認など、ネットワーク接続が必要なユースケースでは、事前に収集した情報をコンテキストとして渡すか、ローカルのモックサーバーを使う方法が実践的だ。「Codex がネットに繋がらない」のは仕様であり、制限を正確に把握した上で設計することが Codex を有効活用する第一歩となる。
目次 (17)
- Codex のサンドボックスとネットワーク分離の仕組み
- なぜネット接続をデフォルトで遮断するのか
- Web 検索ツールの使い方
- Web 検索を有効にするプロンプトの書き方
- Web 検索でできること・できないこと
- ネット接続が必要な場面への代替策
- アプローチ 1: コンテキストに情報を直接渡す
- アプローチ 2: モックサーバーをリポジトリ内に用意する
- アプローチ 3: 環境変数でエンドポイントを切り替える
- codex.yaml の network_access 設定
- setup スクリプトとの使い分け
- よくある疑問と確認事項
- Q: Codex はリアルタイムで最新情報を持っているか？
- Q: Codex が「外部 API をテストした」と言っているが、実際に通信したのか？
- Q: npm、PyPI などのパッケージレジストリにはアクセスできるか？
- Q: Codex CLI とアプリ版でネットワーク制限に違いはあるか？
- まとめ
Codex のサンドボックスとネットワーク分離の仕組み
Codex が 1 件のタスクを処理するとき、その実行はユーザーのローカル環境ではなく、OpenAI が管理するクラウド上のコンテナ環境で行われる。このコンテナは毎回クリーンな状態で起動し、リポジトリのクローン・依存関係のインストール・コードの実行という一連の工程を隔離された環境内でこなす。
こうした設計を「サンドボックス」と呼ぶ。Codex のサンドボックスには次のような制約が設けられている。
- アウトバウンド HTTP/HTTPS 通信の遮断: デフォルトでは外部 API・一般 Web サイトへのリクエストはブロックされる
- パッケージインストール時の制限: npm、pip、cargo など主要なパッケージマネージャは
codex.yamlのsetupスクリプトで事前に構成することで利用可能 - ファイルシステムの揮発: サンドボックスはタスク終了後に破棄され、次のタスクには引き継がれない
OpenAI の公式情報では、このサンドボックスがコードエージェントの安全性を担保する核心的な設計だと説明されている（出典: https://openai.com/index/codex/）。
なぜネット接続をデフォルトで遮断するのか
インターネットへの自由なアクセスを持ったエージェントは、意図せずリスクのある動作を引き起こす可能性がある。たとえば、リポジトリ内の設定ファイルに含まれる認証情報を外部に送信したり、悪意のあるパッケージを自動でインストールしたりするシナリオが考えられる。
ネットワークを分離することで、Codex の動作範囲をリポジトリ内のコード変更に限定し、予測可能でレビュー可能な結果を保証している。また、外部リソースへの依存を排除することで、同じプロンプトに対して毎回同様の結果が得られる再現性も向上する。外部 API の仕様変更やサービスの一時停止がタスクの失敗原因になることを防ぐ効果もある。
Web 検索ツールの使い方
Codex が「インターネットに接続できない」と言っても、情報収集の手段がまったくないわけではない。OpenAI は Codex 向けに組み込みの Web 検索ツールを提供しており、これを活用することで外部の情報をコンテキストに取り込める。
Web 検索ツールはエージェントがサンドボックスの外から安全に情報を取得するための橋渡し役だ。ユーザーの端末やサンドボックス自体がネットに接続するのではなく、OpenAI のバックエンドが検索クエリを処理して結果だけを返す設計になっている（出典: https://openai.com/index/codex/）。
Web 検索を有効にするプロンプトの書き方
Codex の Web 検索は、プロンプトで明示的に指示するか、AGENTS.md に使用を促す記述を追加することで活性化される。単純に次のように書くだけでも Web 検索が発動する。
Web で最新の FastAPI のバージョンを調べてから、requirements.txt を更新してください。
より継続的に Web 情報を参照させたい場合は、プロジェクトルートに置く AGENTS.md に次のような一節を追記する。
## Web 検索のガイドライン
外部ライブラリのバージョン確認や公式ドキュメントの参照が必要な場合は、
Web 検索ツールを積極的に使用してください。
公式ドキュメント（docs.python.org、docs.fastapi.tiangolo.com 等）を優先してください。
Web 検索でできること・できないこと
| できること | できないこと |
|---|---|
| 公式ドキュメントの最新内容を確認する | 外部 API への実際のリクエストを送信する |
| ライブラリの最新バージョンを調べる | ログインが必要なページを閲覧する |
| GitHub 上のコード例を参照する | ローカルネットワーク内サービスにアクセスする |
| エラーメッセージを検索して解決策を探す | バイナリファイルをダウンロード・保存する |
Web 検索はテキスト情報の取得に特化しており、外部サービスとの実際の「通信」ではない。この点を押さえた上で使い分けることが重要だ。
ネット接続が必要な場面への代替策
業務で Codex を活用しようとすると、「外部 API と通信するコードを書いてもらいたい」「リアルタイムデータを取得する処理をテストしてほしい」といったユースケースに直面する。こうした場合のアプローチを 3 つ整理する。
アプローチ 1: コンテキストに情報を直接渡す
最もシンプルな方法は、Codex への指示に外部情報を直接含めることだ。API の仕様書、エンドポイント一覧、レスポンスの JSON サンプルをプロンプトに貼り付ければ、Codex はネット検索なしにコードを生成できる。
以下の API 仕様に基づいてクライアントコードを書いてください：
POST /api/v1/users
Content-Type: application/json
Request: {"name": "string", "email": "string"}
Response: {"id": "string", "created_at": "ISO8601"}
エラー時は 4xx ステータスをキャッチして CustomAPIError を raise してください。
外部ドキュメントの内容をあらかじめ AGENTS.md の context セクションに記載しておく方法も、繰り返し参照するケースで有効だ（出典: https://platform.openai.com/docs/codex）。
アプローチ 2: モックサーバーをリポジトリ内に用意する
結合テストや API クライアントの動作確認が目的の場合、モックサーバーをリポジトリ内にあらかじめ用意しておく方法が効果的だ。json-server（JavaScript）や responses（Python）のようなツールを使えば、Codex が実行する環境内でサンドボックスが通信できるローカルサーバーを立てられる。
ポイントは、実際の外部エンドポイントではなく localhost にリクエストを向けることだ。Codex のサンドボックスはループバックアドレスへの通信は可能なため、モックサーバーとの通信は問題なく行える。
アプローチ 3: 環境変数でエンドポイントを切り替える
本番コードが実際の外部サービスを叩く場合でも、環境変数による切り替えを設けておくことで、Codex が動作できる範囲でコードを検証できる。
import os
API_BASE = os.getenv("API_BASE_URL", "http://localhost:8080")
このように実際の URL を localhost にフォールバックさせると、Codex のサンドボックス環境でも動作確認が通る。本番環境と開発環境の切り替えにも役立ち、一石二鳥の設計といえる。
codex.yaml の network_access 設定
Codex には codex.yaml を通じてサンドボックスの動作を調整するオプションがある。network_access キーはその代表的なものだ。
# codex.yaml
sandbox:
network_access: false # デフォルト: インターネットアクセス無効
network_access: true に変更すると、サンドボックスからアウトバウンド通信が許可される。ただし、この設定はセキュリティ上のリスクを伴うため、信頼できるリポジトリ・管理された環境でのみ使用することが推奨されている（出典: https://openai.com/index/codex/）。
企業導入の文脈では、内部の依存関係ストアや社内 API サーバーへのアクセスを許可しつつ、外部への通信はネットワークポリシーでブロックするという構成が採られることが多い。
setup スクリプトとの使い分け
network_access: false のままでも、codex.yaml の setup セクションでパッケージのインストールを事前に済ませられる。
# codex.yaml
setup: |
npm install
pip install -r requirements.txt
setup は Codex のタスク開始前に一度だけ実行される初期化スクリプトで、この段階では依存関係のダウンロードに限り通信が許可される実装になっている。実際の作業タスクとネットワーク利用を分離することで、安全性と利便性のバランスを取っている。
よくある疑問と確認事項
Q: Codex はリアルタイムで最新情報を持っているか？
A: Codex が使用するモデルには学習データのカットオフ日時がある。最新の情報が必要な場合は、Web 検索ツールを明示的に使用するようプロンプトで指示することが必要だ。Web 検索を指示しない限り、モデルは学習時点の知識のみで回答する。
Q: Codex が「外部 API をテストした」と言っているが、実際に通信したのか？
A: デフォルト設定では外部への通信はできない。Codex が「テストした」と報告する場合、実際には API クライアントのコードを構文的に生成・検証したのみである可能性が高い。network_access: true が設定されていないサンドボックスでは、実際の HTTP リクエストは送信されていない。
Q: npm、PyPI などのパッケージレジストリにはアクセスできるか？
A: setup スクリプトの実行中であれば、主要なパッケージレジストリへのアクセスは可能だ。ただし、これはパッケージのインストールに限定されており、実際のタスク実行中は追加のリモートアクセスは行えない。
Q: Codex CLI とアプリ版でネットワーク制限に違いはあるか？
A: 基本的なサンドボックスの動作は同じだ。CLI とアプリ版のいずれも、タスクはリモートのクラウドサンドボックスで実行され、同じネットワーク制限が適用される。ローカルマシン上で実行しているように見えても、実際のコード実行はクラウド側で完結している。
まとめ
Codex のインターネットアクセスに関する要点を整理する。
- デフォルトではインターネット接続は遮断されており、これはセキュリティ設計による意図的な制限
- Web 検索ツールを使えばプロンプトから外部の情報を参照できる
- 外部 API との通信が必要な場合は、コンテキストへの情報の直接記載・モックサーバーの活用・環境変数による切り替えで対応できる
codex.yamlのnetwork_access: trueでサンドボックスのネット接続を有効化できるが、セキュリティリスクを伴うsetupスクリプトではパッケージのインストールに限り、ネット接続が許可される
Codex を「ネットに繋がらないエージェント」として制約の中に閉じ込めるのではなく、「ネット接続の代わりに何を渡せばよいか」を設計することが、コーディングエージェントとして最大限に活用する鍵となる（出典: https://platform.openai.com/docs/codex）。
