「IP を固定する」とは？
「接続元 IP を固定する」とは、①自分（呼び出す側）がいつも同じ送信元 IP アドレスから外に出るようにし、②相手のサービス側の『IP 許可リスト（allowlist）』に『このアドレスからだけ通す』と登録すること。多くのサービスで“任意のオプション”として用意されています（Azure・Google の API キー・OpenAI・Stripe、DB では Neon の上位プランなど）。既定はたいてい『どこからでも（ただし鍵は必須）』です。
大前提として、通信は TLS で暗号化＋接続先の確認がされ、相手は API キー/トークン/mTLS で『誰か』を確認します。これが“土台”で、世界中のほとんどの API はこれだけで運用されています。IP の固定はこの土台を置き換えるものではなく、上に重ねる“もう一枚”（多層防御）です。だから『固定しないと危険』でも『固定すれば安心』でもなく、足すかどうかは費用対効果で選ぶ話になります。
各ブロックや矢印をクリックすると、その仕組みの説明がここに表示されます。
認証＋TLS で機密性・なりすましは守れる。ただし鍵が漏れれば世界中どこからでも即・悪用されうる。
この図をテキストで読む
構成図「固定しない / オプションで固定 — 何が変わる？」。ブロック6個、つながり4本。 枠: 固定しない（認証＋TLS のみ）（ブロック3個）、オプションで IP を固定（＋許可リスト）（ブロック3個）。 【ブロック】 - 認証＋TLS（土台）: 誰か＋暗号化 - 送信元はどこでも OK: 鍵が合えば世界中から - 鍵漏洩＝即・無差別に悪用: どこからでも使われる - 認証＋TLS（同じ土台）: ここは変わらない - 許可した IP だけ通す: 認証の手前で一枚 - 鍵漏洩でも他 IP は弾く: 被害を局所化 【図の符号】青の囲み枠=境界の囲み 【流れ】 - 固定しない: 認証＋TLS（土台） → 送信元はどこでも OK → 鍵漏洩＝即・無差別に悪用 - オプションで固定: 認証＋TLS（同じ土台） → 許可した IP だけ通す → 鍵漏洩でも他 IP は弾く
固定しない / オプションで固定 — 差の一覧
各セルをクリックすると、その意味や詳しい説明がここに表示されます。
この図をテキストで読む
比較表。2列 × 6行。 【列】 1. 固定しない（認証＋TLS のみ（標準）） 2. オプションで固定（＋IP 許可リスト） 【比較】（観点ごとに） ■ 通信の暗号化・改ざん防止 - 固定しない: TLS で担保 / 差なし - オプションで固定: TLS で担保 / 差なし ■ なりすまし防止（認証） - 固定しない: 鍵 / トークンで担保 - オプションで固定: 同じ / IP は認証の代わりにならない ■ 鍵・パスワードが漏れたとき - 固定しない: どこからでも即・無差別に悪用 - オプションで固定: 許可 IP 以外からは弾く / 被害を局所化（最大の差） ■ 無差別スキャン・総当り - 固定しない: 認証層まで到達 / 弾くのは認証 - オプションで固定: 認証の手前で遮断 / L3/L4 で拒否 ■ 運用コスト・壊れやすさ - 固定しない: 追加なし / 動的 IP でも動く - オプションで固定: 固定の送信元 IP が要る / 静的 egress/NAT の費用＋保守・動的だと事故 ■ 向く相手 - 固定しない: 低〜中価値の公開 API / 多くの SaaS の標準 - オプションで固定: 高価値な鍵・DB・管理系・規制要件 / プライベート接続ならさらに強い
API と DB で温度感が違う
同じ『IP の固定』でも、対象で重みが変わります。ステートレスで公開前提の API は、認証＋TLS が標準ベースラインで、IP 許可リストは任意の上乗せ（OpenAI・Google API キー・Stripe などが提供、Anthropic のように持たない API も）。一方 DB は大量データを抱える高価値な資産なので、『そもそも公衆網に晒さない／接続元を絞る』ことが“事実上の標準”寄りです。実装は2系統 ── ①公開エンドポイント＋IP 許可リスト（Neon の IP Allow・RDS のセキュリティグループ・Cloud SQL の Authorized Networks）と、②公衆網を通らないプライベート接続（PrivateLink / Private Service Connect / プライベート IP）。後者の方が強い隔離で、単なる IP フィルタの上位互換です。
「十分さ」の見極め — 足すかは天秤で決める
認証＋TLS は“不十分”ではありません（世界中の API がこれで動いています）。IP を足すかどうかは、守る対象の価値 × 鍵が漏れる起きやすさ（＝リスク）と、固定 IP の出口（NAT・静的 IP）を持つ費用・運用（＝コスト）の天秤で決めます。目安は、低〜中価値の公開 API なら土台だけで十分／高価値な鍵・DB・管理系・規制要件なら足す（可能ならプライベート接続へ）。IP に依存して認証を弱めるのは本末転倒です。
「IP は詐称で破られる」は基本ノー — 弱点は別のところ
TCP＋TLS はサーバからの応答（SYN-ACK）が“本物の IP の持ち主”に返るため、単純な送信元 IP の詐称だけでは接続を最後まで張れません。だから IP 許可リストは L3/L4 の関所として実際に機能します。現実的な弱点は“詐称”ではなく、①共有 IP（同じ出口を使う他人まで暗黙に信頼してしまう）②動的 IP で運用が壊れる③許可ネットワーク内部の乗っ取り／SSRF で許可ホストを踏み台にされる、の 3 つ。だから IP は“信頼の唯一の根拠”にはせず（ゼロトラストの考え方）、あくまで認証の上の一枚として使います。
押さえておきたい用語
- IP 許可リスト（allowlist）
- 送信元 IP を固定（静的 egress）
- 多層防御（defense in depth）
- ブラスト半径
- プライベート接続
- mTLS（相互 TLS）
- ゼロトラスト