OpenAI PlatformのIP許可リストは、複数作成して組織全体またはプロジェクト単位へ適用できるようになった。ネットワーク境界を業務単位へ分けられる一方、実際の送信元IPを把握せずに切り替えると、本番APIを一斉に遮断する危険がある。

何が変わったか

OpenAIは、IP許可リストを複数管理し、それぞれを組織全体または個別プロジェクトへ適用できるようにした。従来のように全用途の送信元を一つの境界へまとめる必要がなくなり、本番API、検証環境、社内分析、外部委託などの接続元を分離できる。

この変更は認証方式を置き換えるものではない。APIキーやWorkload Identity Federationによる本人確認に加え、許可されたネットワークからの接続だけを受け付ける防御層を細分化する機能である。

変更前後の差

項目単一リスト中心の運用複数リスト・スコープ適用
接続境界組織内の用途を混在用途・プロジェクト別に分離
変更影響1件の追加・削除が全体へ波及対象プロジェクトへ限定
委託先社内IPと同じリストへ追加しがち委託先専用リストを割り当て可能
緊急遮断全体停止になりやすい影響範囲を限定しやすい
監査IPと利用目的の対応が不明瞭リスト名と責任者を紐付け可能

誰に影響するか

固定IPを持つ企業ネットワーク、Cloud NATやNAT Gatewayを経由するワークロード、GitHub ActionsなどのCI/CD、VPNやVDI経由の開発者、外部ベンダーへOpenAI API利用を委託する組織に影響する。動的IPの個人端末から直接APIへ接続する運用では、許可リストを厳格化すると可用性が大きく下がるため、先に共通出口を整備する必要がある。

期限

強制移行期限はない。既存の許可リストを直ちに分割しなくてもAPI利用は継続できる。ただし、現在のリストに本番・開発・委託先が混在している場合は、次回のネットワーク変更前に分離する方が事故を減らせる。

必要な対応

全APIトラフィックの実際の送信元を、設定台帳ではなくNAT、Firewall、Proxy、CI runnerのログから確認する。各IPについて、所有者、用途、対象プロジェクト、期限、IPv4・IPv6、変更連絡先を記録する。その上で「本番」「非本番」「管理系」「委託先」など、障害時に同時停止してよい単位でリストを分割する。

適用前には、未登録IPから拒否されることと、登録IPから正常に呼び出せることの両方を試験する。

実装・移行手順

  1. OpenAI APIを呼ぶ全ワークロードと人手操作を列挙する。
  2. 実通信ログから外向きIPを取得し、設定資料との差を洗い出す。
  3. プロジェクト単位で許可リスト案を作り、重複IPの理由を確認する。
  4. 低リスクな検証プロジェクトへ先に適用する。
  5. 正常系、未許可IP、NAT切替、フェイルオーバーを試験する。
  6. 本番へ段階適用し、拒否件数と接続元を監視する。
  7. IP変更時の申請、承認、削除期限、緊急解除を運用手順へ追加する。

失敗しやすい点

クラウドワークロードのプライベートIPを登録する、NATの待機系IPを忘れる、GitHub-hosted runnerなど変動IPのサービスを固定IPだと扱う、IPv6経路を見落とす、委託終了後もIPを残すことが典型的な失敗である。また、許可リストを「認証の代わり」と考え、長期APIキーを共有したままにしてはいけない。

リスク

誤ったIP削除による本番停止、広すぎるCIDRによる境界の形骸化、NAT変更時の切替失敗、障害対応のために一時追加したIPの恒久残存がある。組織全体へ適用するリストは影響範囲が大きいため、プロジェクト向け変更より厳しい承認と二者確認を設けるべきである。

評価方法

  • 許可IPごとの所有者・用途・期限の記録率
  • プロジェクト間で不要に共有されるIP数
  • 未許可IPからの拒否試験成功率
  • NATフェイルオーバー時のAPI成功率
  • IP変更申請から反映までの時間
  • 期限切れ委託先IPの残存件数
  • 緊急解除後に元の状態へ戻すまでの時間

ロールバック

新しいリスト適用で通信が止まった場合は、原因が分かるまで組織全体の制御を解除するのではなく、対象プロジェクトだけ旧リストへ戻す。旧設定の内容と適用範囲を事前に記録し、復旧後は拒否ログ、DNS、NAT、IPv6経路を確認する。一時的にIPを追加した場合は削除日時を同時に設定する。

編集部分析

複数リスト化の価値は、IPの数を整理することではなく、変更の爆発半径を小さくすることにある。プロジェクトごとのAPIキーや予算を分けても、ネットワーク境界が全社共通なら一つの誤変更で全プロジェクトが止まる。認証、予算、保持設定、IP境界を同じプロジェクト単位で揃えると、責任範囲と障害対応が明確になる。

実務チェックリスト

  • [ ] 実ログから全送信元IPを確認した
  • [ ] 本番・非本番・委託先を別リストにした
  • [ ] NATの主系・待機系とIPv6を確認した
  • [ ] 未許可IPからの拒否試験を行った
  • [ ] 組織全体リストの変更を二者承認にした
  • [ ] 一時追加IPに削除期限を設定した
  • [ ] 旧設定へ戻す手順を記録した

一次情報