Codexにインターネットアクセスを許可する前に：web search・allowlist・MCP外部通信の分け方

3行まとめ

Search

調査用途のweb searchとcommand通信を分けます。

Allowlist

必要なdomainとmethodだけ許可します。

Audit

許可、拒否、承認、実行結果を記録します。

外部通信は便利さではなく、必要な範囲と監査で判断します。

• Codexにインターネットアクセスを許可するときは、web search、command network、MCP、connectorを同じ「外部通信」として扱わず、経路ごとに許可範囲を分けます。
• 最初から unrestricted にせず、必要なdomain、HTTP method、tool、secret、ログ項目を決め、allowlist外通信では止まる設計にします。
• CIや自動実行では、外部POST、secret疑い、未知domain、MCP write tool要求を完了扱いにせず、人間レビューへ戻します。

本文の事実確認には、OpenAI Codex関連ドキュメント、openai/codex README、OpenAIの安全運用記事を使っています。2026年5月31日時点で確認した内容に基づくため、導入時には利用中のCodex環境と最新Docsを再確認してください。Xで伸びているCodex自動化や権限設計の投稿は需要シグナルとして扱い、本文の根拠にはしていません。

この記事でわかること

通信種別

web search、command network、MCPを分けます。

許可範囲

domain、method、secretを分けます。

停止条件

想定外の接続要求で止めます。

監査

ログに残す項目を決めます。

ネットワーク許可は、作業単位で小さく決めます。

• Codexで混同しやすい4種類の外部通信
• web searchとcommand networkを分ける理由
• domain allowlistを小さく作る手順
• MCPサーバー接続をtool権限として見る考え方
• CIや自動実行で外部通信を止める条件
• 社内ネットワークやprivate registryを扱う前の確認項目

前提知識

項目	内容	見方
Codex Cloud		internet accessやdomain allowlistの考え方を確認します。
CLI/App		workspace-writeではnetwork accessを別に扱います。
安全運用		OpenAIの運用例ではopen-ended outbound accessを避けています。
MCP		外部tool接続は別の権限境界として扱います。

導入時には利用形態ごとの最新Docsを確認します。

Codexは、ローカル、CLI、Cloud、app、IDE拡張など利用形態によって、外部通信の扱いが変わります。OpenAIの公開情報では、Codexはsandboxや承認、ネットワークアクセス制御と組み合わせて使う前提で説明されています。openai/codexのREADMEでも、sandbox方針やcodex exec、MCP client/server、設定ファイルの存在が案内されています。

OpenAIの「Running Codex safely」では、open-endedな外部アクセスを避け、既知のworkflowを広いネットワーク権限なしに完了できるようにする運用が説明されています。これは、社内導入でもかなり重要です。外部通信を許可するかどうかは、便利さではなく、必要な接続先、承認、ログ、失敗時の停止条件で判断します。

ネットワークアクセスは1つのスイッチではない

「インターネットを許可する」と言っても、実際には複数の経路があります。検索、shell command、MCP tool、ブラウザ/connectorでは、送信される情報、権限、監査のしかたが違います。

条件

最初は、何のために通信が必要かを1つに絞ります。たとえば「npm packageのversion確認」「GitHub release notes確認」「社内registryからread-onlyで依存取得」のように、用途単位で許可します。

注意点

外部通信を許可すると、コード、ログ、設定、依存関係名、内部URL、secret疑いの文字列が外へ出る可能性があります。AIに任せる前に、出してよい情報と出してはいけない情報を分けます。

Codexの外部通信を4種類に分ける

web search

調査用の検索です。

command network

shellやscriptが外へ出る通信です。

MCP

toolやresource経由の接続です。

connector

ブラウザやアプリ連携の操作です。

経路ごとに許可、承認、ログの扱いを変えます。

Codexで見るべき外部通信は、少なくとも4種類あります。

種類	例	主なリスク
web search	公式Docs、release notes、npm情報の検索	古い情報、検索結果の取り違え
command network	npm install、curl、test scriptのAPI接続	secret送信、未知domain、再現不能
MCP	外部tool、Resources、社内API接続	write tool、副作用、権限過多
connector/browser	ログイン済みサービスの操作	セッション権限、誤投稿、個人情報

まず検索だけで足りるかを見る

仕様確認やバージョン確認なら、web searchや公式Docsの確認だけで足りる場合があります。shellから外部通信を許可する前に、検索だけで判断できるかを見ます。

command networkは副作用も見る

npm viewのような読み取り中心の通信と、外部APIへのPOST、deploy、Issue作成は危険度が違います。commandが外へ出る場合は、domainだけでなくmethod、payload、secret、ログも確認します。

評価基準

外部通信を許可した理由を、通信経路、接続先、送信情報、期待する結果、失敗時の停止条件で説明できるなら、レビューしやすい状態です。

web searchとcommand networkを混同しない

項目	内容	見方
web search		情報収集に使い、commandの外部通信とは別に扱います。
cached search		事前indexやcacheを使う場合があります。
command network		npm、curl、test scriptなどが外部へ出ます。
承認		command通信は副作用やsecret送信の可能性を見ます。

検索を許可しても、任意の外部通信を許可したことにはしません。

web searchは、情報を調べるための機能です。command networkは、shellやscriptが外部サービスへ通信する機能です。この2つを同じ許可として扱うと、必要以上に広い権限になります。

web searchで足りるケース

• 公式DocsのURLを確認する
• release notesの変更点を読む
• packageの公開バージョンを確認する
• 料金ページやセキュリティページを参照する

command networkが必要なケース

• npm ciで依存関係を取得する
• private registryからpackageを読む
• テストが外部API sandboxへ接続する
• MCP serverが社内APIへ接続する

注意点

web searchを許可したからといって、shellから任意のcurlやnpm installを許可したことにはしません。調査用の検索と、実行環境からの外部通信は別の承認にします。

allowlistは最初に小さく作る

1. 1用途

   何のために接続するか決めます。

2. 2domain

   必要なdomainを限定します。

3. 3method

   GETだけかPOSTも必要か分けます。

4. 4review

   ログで想定外通信を確認します。

許可範囲は、タスク後に見直せる形で残します。

allowlistは、あとから広げる前提で小さく作ります。最初から「全部許可」にすると、失敗時にどの接続が必要だったのか分からなくなります。

allowlistに入れる単位

項目	例	見ること
domain	api.github.com、registry.npmjs.org	本当に必要か
method	GET、HEAD、POST	読み取りか副作用か
tool	npm、gh、curl、MCP tool	実行主体は何か
payload	package名、issue番号、diff	secretが混ざらないか

denylistよりallowlistを優先する

危険なdomainをdenylistで足していく方式は漏れやすいです。最初はallowlistで必要な接続先だけを許可し、未知domainが出たら止めます。

確認項目

通信ログを見て、allowlist外の接続要求、POST要求、redirect先、失敗した名前解決、timeoutを確認します。許可したdomainが実際に使われているかも見ます。

MCPサーバー接続はtool権限として扱う

Tools

副作用があるtoolを分けます。

Resources

読ませる情報を制限します。

Prompts

作業型を固定します。

Approval

write toolや外部POSTは承認制にします。

MCPをつなぐことは、外部操作の入口を増やすことです。

MCPサーバー接続は、単なるネットワーク接続ではありません。Tools、Resources、Promptsを通じて、AIが外部機能や社内情報へ触れる入口になります。

MCPで分けるもの

• Tools: 実行できる関数。writeや外部POSTは承認制にする
• Resources: 読ませる情報。secretや顧客情報を混ぜない
• Prompts: 作業型。暗黙の権限昇格にしない
• Transport: stdio、HTTPなど。通信経路ごとにログを分ける

read-onlyから始める

最初のMCP接続は、read-only Resourcesやread-only Toolsから始めます。Issue検索、PR一覧、ドキュメント参照などは入口として扱いやすいです。PRコメント投稿、Issue更新、DB更新、deployは別toolにし、人間承認と監査ログを必須にします。

注意点

MCP serverをallowlistしただけで、そのserverが提供するtoolを全部許可したことにしないでください。server単位の通信許可と、tool単位の実行許可を分けます。

CIや自動実行では外部通信を止める条件を決める

項目	内容	見方
未知domain		allowlist外なら止めます。
POST要求		事前承認がなければ止めます。
secret疑い		入力やログへの混入時に止めます。
依存取得失敗		再試行回数を制限します。

CIでは、便利な通信より停止条件が大事です。

CodexをCIで動かす場合、外部通信の失敗はそのまま自動修正の品質に影響します。未知domainやsecret疑いが出たら、続行ではなく停止にします。

止める条件

条件	止める理由	残す情報
allowlist外domain	目的外通信の可能性	domain、tool、必要理由
未承認POST	副作用の可能性	endpoint、method、payload分類
secret疑い	情報漏えいの可能性	公開しない検出ログ
private registry失敗	再現性がない	registry、scope、認証方式
MCP write要求	権限昇格	tool名、引数、承認要否

再試行を増やしすぎない

外部通信エラーは一時的なこともありますが、無制限に再試行すると費用と時間が増えます。再試行回数、timeout、失敗時の報告形式を固定します。

評価基準

CIの完了条件には、テスト結果だけでなく、allowlist外通信なし、secret混入なし、MCP write tool未承認実行なし、ログ保存ありを入れます。

社内ネットワークやprivate registryを扱う前に

registry

npmやcontainer registryのscopeを分けます。

VPN

不要な社内segmentへ入れません。

token

read-only tokenから始めます。

logs

内部URLやpackage名の公開範囲を確認します。

private接続は、公開internetより強い情報境界が必要です。

社内ネットワーク、private npm registry、private GitHub Enterprise、artifact registry、クラウド管理APIへつなぐ場合は、公開internetより慎重に扱います。

private registryの注意点

依存関係取得のためにregistry tokenが必要な場合でも、そのtokenをAIに読ませる必要はありません。CIのpackage managerが使うsecretと、AIが読むpromptやログを分けます。

社内APIの注意点

社内APIをMCP tool化すると、AIが実行できる業務操作になります。read-only APIでも、顧客名、売上、障害情報、内部URLが返るなら、Resourcesやtool resultのマスクが必要です。

条件

最初は、read-only token、限定scope、限定domain、短い有効期限、監査ログありで試します。write APIや本番APIは、承認UIとrollback手順ができるまで渡しません。

ログと監査で見る項目

項目	内容	見方
request		domain、method、tool名を残します。
decision		allow、deny、approvalを残します。
actor		誰が許可したかを残します。
result		成功、失敗、timeoutを残します。

ログがない外部通信は、あとから安全性を説明できません。

外部通信を許可するなら、ログが必要です。ログがない通信は、あとから安全性を説明できません。

残す項目

• 実行したtoolまたはcommand
• 接続先domain
• HTTP methodまたは操作種別
• allow/deny/approvalの判断
• 承認者と時刻
• 成功、失敗、timeout
• secret疑いの有無
• 未検証範囲

ログに残さないもの

secret値、認証header、private token、顧客データ全文、.env、未公開の内部URL全文は残さないようにします。必要ならhash、ID、要約へ変換します。

確認項目

監査ログは、セキュリティ担当だけでなく、レビュー担当者が読める形にします。通信が必要だった理由、許可した範囲、失敗時の判断が追えることが重要です。

失敗時に止める条件

allowlist外

未知の接続先を要求した場合。

secret混入

prompt、log、artifactに秘密情報疑いがある場合。

外部POST

承認なしで送信しようとした場合。

再現不能

通信依存で結果を再現できない場合。

止めた理由を残すことも成果物です。

Codexが「完了」と言っても、外部通信まわりでは完了扱いにしない条件があります。

条件	対応
allowlist外domainが必要だった	追加許可せず、理由を報告する
secret疑いが出た	公開ログへ出さず、jobを失敗にする
外部POSTが必要だった	人間承認へ戻す
MCP write toolを要求した	tool引数とリスクを監査に回す
private registryに失敗した	registry設定と認証方式を確認する

失敗ログを成果物にする

外部通信で止まった場合も、無駄ではありません。どのdomainが必要だったか、なぜ必要だったか、代替できるか、read-onlyで済むかを記録します。

注意点

失敗ログを公開artifactへ入れると、内部domainやpackage名が漏れることがあります。公開範囲に応じてマスクします。

実務で使うなら

1. 1日目

   web searchだけで調査します。

2. 2日目

   allowlist案を作ります。

3. 3日目

   read-only通信を試します。

4. 5日目

   MCPやCI通信を承認制で試します。

通信許可は一気に広げず、ログを見ながら増やします。

最初の1週間は、次の順序が現実的です。

1. web searchだけで公式Docs確認を行う
2. command networkを使わずに計画と差分レビューだけ試す
3. allowlist案を作る
4. registry.npmjs.orgやapi.github.comなど必要domainだけread-onlyで許可する
5. MCPはread-only toolから始める
6. CIではallowlist外通信で止める
7. ログを見てdomain、method、toolを見直す

導入を急がないケース

次の場合は、外部通信を広げないほうがよいです。

• secret管理が曖昧
• 監査ログがない
• private registry tokenをAIが読める
• MCP toolのread/writeが分かれていない
• CIで外部POSTを止める条件がない

FAQ

全部許可

最初の選択肢にはしません。

web search

command networkとは別に扱います。

MCP

tool権限として確認します。

CI

allowlist外通信で止めます。

迷ったら、通信を狭めてレビューへ戻します。

Codexに全部のインターネットアクセスを渡してよいですか

最初の選択肢にはしません。必要なdomainとmethodを絞り、ログで確認しながら広げます。特にCIや自動実行では、未知domainで止まる設計にします。

web searchを許可すればnpm installもできますか

別物として扱います。web searchは調査用、npm installやcurlはcommand networkです。依存取得にはregistry、token、lockfile、再現性の確認が必要です。

MCP serverを信頼済みにすればtoolも全部使ってよいですか

いいえ。MCP serverへの接続許可と、各toolの実行許可は分けます。write tool、外部POST、DB更新、Issue更新は承認制にします。

社内APIをCodexから呼ばせてもよいですか

read-only、限定scope、短いtoken、監査ログ、マスク済みレスポンスから始めます。本番write APIは、承認UIとrollback手順ができるまで渡さないほうが安全です。

参照した主な情報源

• Codex Cloud agent internet access
• Codex permissions
• Codex config basic
• Codex config advanced
• Codex config reference
• openai/codex GitHub README
• openai/codex codex-rs README
• Running Codex safely at OpenAI
• Codex CLI Getting Started – OpenAI Help Center

次に読むなら

更新履歴

1. 2026年5月31日

   OpenAI Codex関連Docs、openai/codex README、OpenAI安全運用記事を確認して初版を作成しました。

導入時には最新Docsと利用環境の設定を再確認します。

• 2026年5月31日：OpenAI Codex関連Docs、openai/codex README、OpenAI安全運用記事を確認して初版を作成。