◈ API / SDK/2026-07-01上級

IP が変わるサーバーで Gemini API キーの制限を効かせる — headless 自動処理の逃がし方

未制限キーの遮断後、IP が毎回変わる headless なサーバー自動処理では、HTTP リファラーもアプリ制限も IP 許可リストも素直には効きません。API 制限だけで凌ぐか、egress を固定 IP に集約するか、いっそ Vertex のサービスアカウント認証へ移すか。稼働を止めずに選ぶための判断軸と、動くコードを整理します。

Gemini API¹⁵⁹ APIキー³ セキュリティ⁶ 自動運用³ Vertex AI¹¹

✦ プレミアム記事

未制限キーが遮断されるようになって最初に困ったのは、ブラウザ向けのキーではなく、誰も見ていないところで動いているサーバー側の定期処理でした。個人開発で複数のサイトの更新処理を回していると、その大半は headless な環境で走ります。手元の PC ではなく、使い捨てに近い実行環境の上で起動して、終わったら消える。そういう作りにしていると、リクエスト元の IP アドレスが実行のたびに変わります。

ここに、今回のキー制限の面倒さが凝縮されています。ブラウザなら HTTP リファラー、モバイルアプリなら Android/iOS のアプリ制限が使えます。ところが「毎回 IP が変わる headless なサーバー処理」には、その手のアプリケーション制限がどれも素直に当てはまりません。IP 許可リストを設定した途端、次の実行では別の IP から来て自分で自分を弾く、という間の抜けた事故が起きます。

ここでは、その headless 自動処理に絞って、キーの制限をどう効かせるかを整理します。結論を先に言うと、当座は「API 制限」で最低ラインを満たしつつ、腰を据えるなら「サーバー処理は API キーを捨ててサービスアカウント認証へ移す」のが私自身の到達点です。順を追って、なぜそうなるかと、止めずに移す手順を書きます。

なぜサーバー自動処理では「アプリケーション制限」が効きにくいのか

Gemini API キーに設定できる制限は、大きく二層に分かれます。ひとつは、そのキーで叩ける API を絞る API 制限。もうひとつは、リクエスト元を絞る アプリケーション制限で、HTTP リファラー・IP アドレス・Android アプリ・iOS アプリの4種類があります。

問題は、アプリケーション制限の4種類がいずれも「呼び出し元が安定して識別できる」ことを前提にしている点です。ブラウザにはリファラーがあり、モバイルアプリにはパッケージ名と署名があります。ところが headless なサーバー処理には、そのどれもありません。残るのは IP アドレス制限だけですが、これが厄介です。

CI・サーバーレス・使い捨ての実行環境は、起動のたびに別のノードに割り当てられ、egress IP が変わります。
固定 IP を持たない構成では、そもそも許可リストに書く値が確定しません。
無理に広い CIDR を許可すると、制限をかけている意味が薄れます。

つまり headless 処理では、アプリケーション制限を諦めて API 制限だけで最低ラインを満たすか、egress を固定 IP に寄せて IP 制限を成立させるか、API キーという仕組みそのものから降りるか、の三択に自然と絞られます。以下、順に見ていきます。

まず現状を測る：キーに何の制限がついているか確かめる

選ぶ前に、いま自分のキーに何がついているかを機械的に把握します。手作業でコンソールを眺めるより、API Keys API で一覧を取ってしまうほうが、複数プロジェクトを横断していると確実です。以下は Service Usage / API Keys の管理 API を使い、キーごとの制限有無を棚卸しするコードです。認証にはサービスアカウント（後述）か、gcloud auth application-default login の資格情報を使います。

# キーの制限状況を棚卸しする（google-cloud-api-keys を使用）
# pip install google-cloud-api-keys
from google.cloud import api_keys_v2
 
def audit_keys(project_id: str) -> None:
    client = api_keys_v2.ApiKeysClient()
    parent = f"projects/{project_id}/locations/global"
 
    for key in client.list_keys(parent=parent):
        restrictions = key.restrictions
        api_targets = list(restrictions.api_targets) if restrictions else []
 
        # アプリケーション制限の種別を判定
        app = "none"
        if restrictions:
            if restrictions.browser_key_restrictions.allowed_referrers:
                app = "referrer"
            elif restrictions.server_key_restrictions.allowed_ips:
                app = "ip"
            elif restrictions.android_key_restrictions.allowed_applications:
                app = "android"
            elif restrictions.ios_key_restrictions.allowed_bundle_ids:
                app = "ios"
 
        api_ok = "restricted" if api_targets else "ALL-APIs"
        flag = "  <-- 未制限（遮断対象の可能性）" if app == "none" and not api_targets else ""
        print(f"{key.display_name:<28} app={app:<9} api={api_ok}{flag}")
 
audit_keys("your-project-id")
# 出力例:
# cron-gemilab-pipeline        app=none      api=ALL-APIs  <-- 未制限（遮断対象の可能性）
# web-demo-key                 app=referrer  api=restricted

app=none かつ api=ALL-APIs のキーが、今回の遮断でいちばん危ないキーです。headless 処理で使っているキーがここに並んでいたら、次のいずれかで手当てします。

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること

✦IP が毎回変わる headless 環境で 403 に詰まっていた人が、自分の構成に効く制限のかけ方を選べるようになる

✦API 制限だけ・固定 IP egress・Vertex サービスアカウント認証の3択を、コストと運用負荷で比較して判断できる

✦稼働中のサーバー処理を API キーから OAuth 認証へ、止めずに切り替える手順を手に入れる

Stripe による安全な決済 · いつでもキャンセル可能

✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または

メンバーシップなら全記事が読み放題 →

選択肢A：API 制限だけで最低ラインを満たす

いちばん摩擦の少ない当座の手当ては、アプリケーション制限は空のまま、API 制限だけを付けることです。キーで叩ける API を「Generative Language API」一本に絞ります。これだけでも、キーが流出したときに他の Google API へ横展開される被害を止められますし、未制限キーの遮断ポリシーの観点でも「制限あり」の側に入ります。

# キーの API 制限を「Generative Language API」だけに絞る
from google.cloud import api_keys_v2
from google.cloud.api_keys_v2 import Key, Restrictions, ApiTarget
 
def restrict_to_gemini(project_id: str, key_id: str) -> None:
    client = api_keys_v2.ApiKeysClient()
    name = f"projects/{project_id}/locations/global/keys/{key_id}"
 
    key = Key(
        name=name,
        restrictions=Restrictions(
            api_targets=[ApiTarget(service="generativelanguage.googleapis.com")]
        ),
    )
    # update_mask で restrictions だけを差し替える（他項目は温存）
    op = client.update_key(key=key, update_mask="restrictions")
    op.result()  # 反映まで待つ
    print("API 制限を generativelanguage.googleapis.com に限定しました")
 
restrict_to_gemini("your-project-id", "your-key-id")

ただしこれは「最低ライン」です。API 制限だけのキーは、盗まれれば依然として誰の環境からでも Gemini を叩けます。個人開発で費用を自分で被る立場だと、ここで止めるのは正直こわい。もう一歩、リクエスト元を縛りたくなります。

選択肢B：egress を固定 IP に集約して IP 制限を効かせる

headless 処理でも、出口の IP を一箇所に固める構成にできれば、IP 制限が成立します。実行環境そのものの IP は変わっても、その手前に固定 IP を持つ中継点（NAT ゲートウェイや固定 IP の転送プロキシ）を置き、すべての Gemini リクエストをそこ経由にするやり方です。

# 固定 IP を持つ転送プロキシ経由で Gemini を叩く
# 実行環境の IP は毎回変わっても、キーには「プロキシの固定 IP」だけを許可すればよい
import os
from google import genai
 
# HTTPS_PROXY にプロキシを指定すると、SDK 下の httpx が経由してくれる
os.environ["HTTPS_PROXY"] = "http://PROXY_HOST:PROXY_PORT"
 
client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])
resp = client.models.generate_content(
    model="gemini-flash-latest",
    contents="このリクエストは固定 IP のプロキシを経由して届きます。",
)
print(resp.text)
# キー側には server_key_restrictions.allowed_ips にプロキシの固定 IP だけを登録する

この構成の利点は、キーの仕組みを変えずに「元を縛れる」ことです。欠点は、固定 IP を維持する中継点そのものが運用対象として増えること。NAT ゲートウェイは時間課金が積み上がりますし、自前プロキシは可用性を自分で守る必要があります。処理の本数が少ない個人運用だと、この中継点のコストと手間が、守りたいものに見合うかは微妙なところです。私は一時これを使いましたが、維持の面倒さから次の選択肢へ移りました。

選択肢C：サーバーは API キーを捨て、サービスアカウント認証へ移す

腰を据えるなら、これが本命だと考えています。そもそも headless なサーバー処理に API キーは向いていません。 API キーは「持っている人＝誰でも使える」共有シークレットで、リクエスト元を縛る手立てが弱い。サーバー間通信には、短命のトークンを都度発行する OAuth 2.0（サービスアカウント）認証のほうが素直です。

Gemini は Vertex AI 経由で呼ぶと、API キーではなくサービスアカウントの資格情報で認証できます。同じ google-genai SDK のまま、vertexai=True に切り替えるだけで、呼び出しコードの大部分はそのまま使えます。

# API キーではなくサービスアカウント認証で Gemini を呼ぶ（Vertex AI 経由）
# 環境変数 GOOGLE_APPLICATION_CREDENTIALS にサービスアカウント鍵の JSON パスを設定
from google import genai
 
client = genai.Client(
    vertexai=True,
    project="your-project-id",
    location="global",
)
 
resp = client.models.generate_content(
    model="gemini-flash-latest",
    contents="サービスアカウント認証で届いたリクエストです。API キーはもう使いません。",
)
print(resp.text)
# 認証は Application Default Credentials 経由。
# 実行環境に紐づくサービスアカウントを使えば、鍵ファイルすら配らずに済む

こうすると、リクエスト元の縛りは「どのサービスアカウントに、どの IAM ロールを与えるか」に移ります。IP という不安定な軸ではなく、ID という安定した軸で権限を管理できます。鍵ファイルを配る運用が嫌なら、実行環境に結び付いたサービスアカウントを使い、Application Default Credentials に任せれば、資格情報そのものを持ち歩かずに済みます。未制限キーの遮断という今回の変更は、私にとっては「サーバー処理をこの形へ寄せる」きっかけになりました。

止めずに移すときは、次の順で進めると事故が起きにくいです。

移行先のサービスアカウントに Vertex AI User 相当のロールを付け、同じ環境から一度だけ疎通を取ります。
定期処理のうち一本だけを Vertex 経由に切り替え、数回分のログで 403 や 404 が出ないかを見ます。
問題がなければ残りを順に移し、最後に旧 API キーを無効化します。無効化は最後にするのが肝心で、切り戻せる余地を残しておきます。

移行の判断基準

どこまでやるかは、処理の性質と、費用を誰が被るかで決まります。私自身の判断はおおむね次の表のとおりです。

構成	元の縛り	運用の重さ	向いている場面
A: API 制限のみ	弱い（誰の環境からでも叩ける）	軽い	試作・短命の検証・すぐ捨てるキー
B: 固定 IP egress + IP 制限	中（プロキシ経由に縛れる）	重い（中継点の維持）	キーの仕組みを変えられない既存資産
C: サービスアカウント認証	強い（ID と IAM で管理）	中（初期移行はあるが以後は軽い）	継続して回す本番の headless 処理

使い捨てのキーで一度きりの検証をするだけなら A で十分です。一方、Dolice Labs のように毎日いくつもの定期処理を回す前提なら、初期の移行コストを払ってでも C に寄せたほうが、後々の点検が楽になります。B は「キーを前提にした既存コードをすぐには書き換えられない」場合の中間解として位置づけると収まりが良いです。

切り替え中に踏みやすい落とし穴

Vertex 経由へ移すとき、いくつか静かに躓く箇所があります。

モデル名の指定は同じでも、対応状況が微妙に違う場合があります。 切り替え直後は、実際に使うモデルで一度疎通を取り、404 や NOT_FOUND が出ないか確かめてください。エイリアス（gemini-flash-latest のような別名）が指す実体は時期で動きます。
location の指定を取り違えると、そのリージョンで空振りします。 グローバルエンドポイントを使うなら location="global" を明示します。
サービスアカウントに必要なロールが足りないと 403 PERMISSION_DENIED が返ります。 見た目は未制限キー遮断の 403 とそっくりなので、原因の取り違えに注意してください。Vertex 側では Vertex AI User 相当のロールが要ります。
API キーとサービスアカウントを両方渡すと、SDK がどちらを優先するかで迷子になります。 移行中は環境変数を片方だけに絞り、GEMINI_API_KEY を残したまま vertexai=True にしない、と決めておくと切り分けが楽です。

いずれも、切り替えの瞬間に一度だけ疎通確認を挟めば、大半は回避できます。私は移行のたびに、本番運用の定期処理を有効化する前に、同じ環境から一発だけ呼ぶ確認ステップを必ず通すようにしています。

次の一手

まずは選択肢Aの棚卸しコードを回して、app=none かつ api=ALL-APIs のキーが headless 処理に紛れていないかだけ確認してください。そこにサーバー処理のキーが一本でもいたら、それが次に静かに止まる候補です。棚卸しの結果を見てから、AでしのぐかCへ移すかを決めれば、順番を間違えずに済みます。

同じように自動処理を回している方の、点検の入口になれば嬉しいです。