LLMアプリのAPIゲートウェイ・セキュリティ設計

LLMアプリを本番運用していると、「既存のAPIゲートウェイをそのまま使えばいい」と思いがちです。しかし、従来のREST APIと比べてLLMには特有の課題がある。リクエスト数ではなくトークン消費量がコストに直結する、ユーザーが入力した個人情報が外部LLMに送られるリスクがある、プロンプト・レスポンス全体を証跡として残さないと後から調査できない——こうした問題は、従来型ゲートウェイでは対処しきれません。

本記事では LLMアプリのAPIゲートウェイ層に特化し、①トークン消費量ベースのレート制限、②ユーザー・チーム・エージェント単位のアクセス制御とAPIキー仮想化、③プロンプト送信前のPII自動検出・マスキング、④監査ログ設計の4パターンをApache APISIXとlmgateの実装例で解説します。

多層防御における本記事の位置付けを先に整理しておきます。当ブログでは「入力フィルタリング」としてAzure AI Content Safety の Prompt Shields 実装を、「ランタイムガードレール」（NeMo Guardrails）の記事も別途扱っています。本記事が担うのはゲートウェイ層です。入力がLLMに到達する前にコスト制御・PII保護・認証認可をインフラレベルで処理するのがゲートウェイ層の役割で、アプリコードには手を入れずに横断的に適用できます。

---

LLM固有のゲートウェイ要件とは

従来のAPIゲートウェイが提供するレート制限は「1分あたりリクエスト数（RPM）」の制御が中心です。しかしLLM APIのコストはトークン消費量に比例します。100件のリクエストでも、1件で10万トークンを消費するリクエストと1件で100トークンのリクエストでは、コストも負荷も100倍以上変わります。

さらに、LLMアプリでは次の問題が加わります。

コスト爆発と乱用 LLM APIキーが漏洩した場合、リクエスト数制限をかけていても、1回のリクエストで大量のトークンを消費するスクリプトを実行されると被害は甚大です。2024〜2025年にかけて、GitHubやCI環境に誤ってコミットされたAPIキーが数時間以内に大量消費される事例が相次いでいます。

機密情報のLLMへの送信 ユーザーが業務システムのチャット欄にメールアドレス、電話番号、クレジットカード番号などを入力し、それがそのままOpenAIやAnthropicのAPIに送られるケースがあります。OWASP LLM Top 10 for LLMs 2025の**LLM02:2025「Sensitive Information Disclosure（機密情報漏洩）」**は、LLMへの入力段階でのPII混入を主要リスクとして定義しています。

監査証跡の欠如 LLMアプリのセキュリティインシデントや誤動作を後から調査するには、プロンプトとレスポンスの両方をログとして保存しておく必要があります。しかし、アプリのログだけでは不十分で、ゲートウェイ層でインフラとして記録しておくことで改ざんや漏れを防げます。NIST AI Risk Management Framework（AI RMF）のManage機能では、AIシステムの動作に対するモニタリングと記録の維持を継続的な要件として定めています。

---

パターン1：トークン消費量ベースのレート制限

RPM制限だけでは不十分な理由

典型的なREST API向けレート制限は「1ユーザーあたり60リクエスト/分」のようなリクエスト数管理です。LLMでは、1リクエストで「論文全文を要約して」という入力と100万トークンのコンテキストを送ることができるため、RPM制限だけでは月次コストの爆発を防げません。

必要なのはトークン消費量ベースのバジェット管理です。

TokenRateLimitPolicy の設計

Apache APISIXや類似のAI Gatewayプラグインでは、次の単位でトークンバジェットを設定できます。

# Apache APISIX の ai-token-ratelimit プラグイン設定例
plugins:
  ai-token-ratelimit:
    count: 100000          # バジェット（トークン数）
    time_window: 3600      # 集計ウィンドウ（秒）: ここでは1時間
    key: "consumer_name"   # 集計キー: consumer=認証済みユーザー単位
    rejected_code: 429
    rejected_msg: "トークン使用量の上限に達しました。1時間後に再試行してください。"

集計キーの設計方針

集計キー	適用ケース
consumer_name（ユーザーID）	エンドユーザーごとの使用量管理
service_id（サービスID）	機能・マイクロサービス単位の管理
route_id（エンドポイント）	API用途別（要約、翻訳など）の管理

コスト爆発の多くは単一ユーザーまたは単一サービスの暴走なので、少なくともconsumer_name単位での制限は必須です。

プロンプトトークン数の事前チェック

リクエストが来た時点でプロンプトのトークン数を概算し、バジェットを超えるなら即時拒否するプリフライトチェックも有効です。tiktoken（OpenAI）やAnthropicのカウントAPIを利用します。

import tiktoken

def estimate_tokens(text: str, model: str = "gpt-4o") -> int:
    """プロンプトのトークン数を概算する"""
    enc = tiktoken.encoding_for_model(model)
    return len(enc.encode(text))

def check_token_budget(user_id: str, prompt: str, budget: int = 10000) -> bool:
    """ゲートウェイ層でのプリフライトチェック"""
    estimated = estimate_tokens(prompt)
    if estimated > budget:
        raise ValueError(f"プロンプトが上限 {budget} トークンを超えています（推定: {estimated}）")
    return True

---

パターン2：ユーザー・エージェント単位のアクセス制御とAPIキー仮想化

「生のAPIキー」を渡さない設計

LLMアプリでよく見られる問題は、OpenAIやAnthropicのAPIキーをそのままクライアントアプリやエージェントに渡すことです。これは次のリスクをもたらします。

• APIキーが漏洩した場合、即座に悪用される
• どのユーザー・エージェントがどれだけ使ったかの追跡が困難
• キーのローテーションがアプリ全体に影響する

APIキー仮想化はこの問題を解決します。ゲートウェイが仮想キー（スコープ付き・有効期限付き）を発行し、実際のプロバイダーキーはゲートウェイ内部に隠蔽します。

クライアント → [仮想キー] → APIゲートウェイ → [実キー] → OpenAI/Anthropic
                              ↑
                  認証・認可・レート制限・ログをここで処理

AIエージェントのアイデンティティ管理記事で詳述したJITエフェメラル認証情報の考え方と同じ原則です。ゲートウェイはエージェントごとにタスクスコープ付きの仮想キーを発行し、タスク完了後に無効化します。

Apache APISIXのconsumer管理

Apache APISIXではconsumerオブジェクトを使ってユーザー・サービスごとの認証と制限を一元管理できます。

# consumerの作成（ユーザーIDに対応）
curl -X PUT http://localhost:9180/apisix/admin/consumers \
  -H 'X-API-KEY: your-admin-key' \
  -d '{
    "username": "user_alice",
    "plugins": {
      "key-auth": {
        "key": "vk-alice-20260528-abc123"
      }
    }
  }'

この設計により、特定ユーザーの仮想キーを即座に無効化しても他ユーザーには影響がなく、キーローテーションのリスクを局所化できます。

---

パターン3：PII自動検出・マスキング（OWASP LLM02:2025対応）

プロンプト内のPII混入リスク

OWASP LLM02:2025は、LLMが訓練データや入力から機密情報を意図せず開示するリスクをカバーしています。特にユーザー入力に含まれるPIIをそのまま外部LLMに送ることは、このリスクの典型的な実現経路です。

「顧客の鈴木太郎さん（090-xxxx-xxxx）の問い合わせに答えて」のようなプロンプトが、OpenAIのAPIに送信されることを想定してください。LLMが回答に個人情報を含めてログに記録されたり、モデルの微調整データに混入したりするリスクがあります。

ゲートウェイ層でのPII検出・マスキング実装

ゲートウェイで送信前にプロンプトをスキャンし、PIIをマスクする処理を挟みます。Pythonベースの実装例としてpresidio（Microsoft製のオープンソースPIIアナライザー）を使用します。

from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine
from presidio_anonymizer.entities import OperatorConfig

analyzer = AnalyzerEngine()
anonymizer = AnonymizerEngine()

def mask_pii_in_prompt(prompt: str, language: str = "en") -> tuple[str, list]:
    """
    プロンプトからPIIを検出しマスクする。
    戻り値: (マスク済みプロンプト, 検出されたPIIエンティティのリスト)
    """
    results = analyzer.analyze(
        text=prompt,
        entities=["PHONE_NUMBER", "EMAIL_ADDRESS", "CREDIT_CARD", "PERSON"],
        language=language,
    )
    
    # 監査ログ用にエンティティタイプと位置を記録
    pii_found = [{"type": r.entity_type, "score": r.score} for r in results]
    
    # マスキング処理
    anonymized = anonymizer.anonymize(
        text=prompt,
        analyzer_results=results,
        operators={
            "PHONE_NUMBER": OperatorConfig("replace", {"new_value": "<PHONE>"}),
            "EMAIL_ADDRESS": OperatorConfig("replace", {"new_value": "<EMAIL>"}),
            "CREDIT_CARD": OperatorConfig("replace", {"new_value": "<CARD>"}),
            "PERSON": OperatorConfig("replace", {"new_value": "<NAME>"}),
        },
    )
    
    return anonymized.text, pii_found

日本語PIIへの対応

presidioは日本語のPII（電話番号の書式、住所、マイナンバーなど）には標準対応していません。日本語環境では、spaCyの日本語モデル（ja_core_news_sm）と正規表現ベースのカスタムレコグナイザーを組み合わせるか、Prediction GuardのようなPII検出サービスを利用します。

lmgateを使った軽量ゲートウェイ構成

より軽量な構成として、オープンソースのlmgate（GitHub: hkdb/lmgate）はLLM API向けのリバースプロキシとして機能し、認証・ロギング・フィルタリングをシンプルに実装できます。小規模チームやPoC環境でのゲートウェイ構築に適しています。

---

パターン4：監査ログ設計（NIST AI RMF Manage対応）

なぜLLMの監査ログは特別か

NIST AI RMFのManage機能は、AIシステムが引き起こすリスクを継続的にモニタリング・記録し、問題発生時に対応できる体制を維持することを求めています。LLMアプリの監査ログで特別なのは、「何を入力したか（プロンプト）」と「何が返ってきたか（レスポンス）」を両方記録しなければ、インシデント時に原因を遡れないことです。

一方で、プロンプト全文を素のままログに保存すると、今度はそのログ自体がPIIの溜まり場になります。PIIをマスクした後のプロンプトを記録するか、ログへのアクセスを厳格に制御する設計が必要です。

監査ログに含めるべき項目

{
  "timestamp": "2026-05-28T10:30:00Z",
  "request_id": "req_abc123",
  "user_id": "user_alice",
  "virtual_key_id": "vk-alice-20260528-abc123",
  "model": "gpt-4o",
  "endpoint": "/v1/chat/completions",
  "prompt_tokens": 450,
  "completion_tokens": 312,
  "total_tokens": 762,
  "pii_detected": ["EMAIL_ADDRESS"],
  "pii_masked": true,
  "security_actions": ["pii_masked"],
  "latency_ms": 1240,
  "status_code": 200,
  "prompt_hash": "sha256:abc...",
  "response_hash": "sha256:def..."
}

プロンプト・レスポンス全文のログ保存

全文保存が必要な規制環境（金融・医療など）では、ログストアへのアクセスを最小権限に絞り（例：書き込み専用のサービスアカウント）、保存前にPIIマスキングを適用します。保存期間はデータ保護規制（個人情報保護法・GDPR等）に従い設定します。

プロンプト・レスポンスのハッシュ記録

全文保存が不要な場合でも、プロンプトとレスポンスのSHA-256ハッシュを記録します。後から「このログに対応するプロンプトは何だったか」を確認できる証跡として機能し、改ざん検知にも使えます。

---

4パターンをまとめた多層防御アーキテクチャ

ここまで解説した4パターンは個別に導入することもできますが、組み合わせることで相互補完します。

ユーザー/エージェント
    ↓
[ゲートウェイ層: 本記事のスコープ]
  1. 認証・APIキー仮想化（パターン2）
  2. トークンバジェット確認（パターン1）
  3. PIIマスキング（パターン3）
  4. 監査ログ記録（パターン4）
    ↓
[入力フィルタリング層]
  Azure AI Content Safety Prompt Shields
  （プロンプトインジェクション検知）
    ↓
[LLM推論]
    ↓
[ランタイムガードレール層]
  NeMo Guardrails
  （出力トピック制限・グラウンディング検証）
    ↓
アプリケーション / ユーザー

この3層構造のうち、**ゲートウェイ層が担うのは「コスト管理・認証認可・PIIの前処理・証跡記録」**です。プロンプトインジェクション検知（Azure AI Content Safety）やランタイムポリシー制御（NeMo Guardrails）とは役割が異なり、アプリケーションコードへの変更なしにインフラレベルで横断適用できる点が特徴です。

---

関連記事

• Azure AI Content Safety Prompt Shields 実装ガイド — プロンプトインジェクション検知のゲートウェイ上流層。本記事のゲートウェイ設計と組み合わせる2層目の防御
• AIエージェントのアイデンティティ管理：JITエフェメラル認証情報 — マルチエージェントでのAPIキー仮想化をより詳しく知りたい場合の参照記事
• 社内RAGのベクターDB権限設計チェックリスト — RAGパイプラインのデータアクセス制御層。ゲートウェイ層とは異なる設計軸を解説
• LLMエージェントの「過剰権限」を排除する：OWASP LLM06:2025 準拠の最小権限設計 — ゲートウェイで制御しきれないエージェントのツール権限問題への補完

---

FAQ

LLMゲートウェイ・セキュリティ設計 よくある質問

実装時の疑問をまとめました

Q Apache APISIXとLiteLLM Proxyはどう使い分けますか？

A

Apache APISIXは汎用APIゲートウェイとしてHTTPトラフィック全般を処理でき、LLM以外のバックエンドとの統合が必要な場合や既存のAPIゲートウェイを置き換えたくない場合に適しています。LiteLLM Proxyは100以上のLLMプロバイダーへの統一インターフェースを提供し、複数プロバイダーを切り替えたい場合に向いています。どちらもトークンレート制限・ログ機能を持ちますが、既存インフラとの親和性で選ぶのが現実的です。

Q PIIマスキングはLLMの回答精度を下げませんか？

A

用途によります。「田中さんの予定を確認して」のような固有名詞が不可欠なタスクでは精度が落ちます。一方、「このメールの要約を作って」のような内容処理タスクでは、送信者情報をマスクしても精度にほぼ影響しません。PIIマスキングの適用粒度（エンティティタイプの選択）を用途ごとに調整し、過剰なマスキングを避けることが実務上のバランスです。

Q 小規模なLLMアプリでもAPIゲートウェイは必要ですか？

A

チーム内のみで使う試作品ならゲートウェイなしでも問題ありません。ただし、「外部ユーザーが使う」「個人情報を含むデータを処理する」「コスト管理が必要」の3条件のうち1つでも該当するなら、最小構成（APIキー仮想化＋トークン制限）だけでも導入する価値があります。lmgateのような軽量ツールであれば1〜2時間で立ち上げられます。

Q OWASP LLM02:2025への対応はPIIマスキングだけで十分ですか？

A

PIIマスキングはLLM02:2025（機密情報漏洩）への部分的な対処です。OWASP LLM02:2025はさらに「LLMが訓練データから機密情報を出力する」リスクも含んでいます。ゲートウェイ層での対策はプロンプト入力側に効果を発揮しますが、モデル自体の訓練データ汚染や、モデルが出力する内容の検証はゲートウェイの外で対処が必要です。完全な対応には、出力側のコンテンツフィルタリング（Azure AI Content Safety）との組み合わせが有効です。

Q 監査ログのプロンプト全文保存は法的リスクがありますか？

A

個人情報を含むプロンプトを全文保存する場合、個人情報保護法の第三者提供制限や保存期間規制に注意が必要です。クラウドサービスのログ保存が「委託」に該当するかも確認が必要です。実務上は、プロンプト全文ではなくハッシュ値とメタデータ（トークン数、タイムスタンプ、ユーザーID、PIIフラグ）の記録を基本とし、法的根拠がある場合のみ全文保存の検討をおすすめします。

---

参考リンク

• OWASP LLM02:2025 Sensitive Information Disclosure — 機密情報漏洩リスクの定義と対策
• OWASP Top 10 for LLMs 2025 PDF — LLMアプリの脅威トップ10全文
• Apache APISIX: AI Gateway Security and Compliance — APISIXのAI Gateway機能解説
• Rate Limiting AI Agents: Preventing LLM API Exhaustion — トークンレート制限の設計
• Manage AI Resource Use with TokenRateLimitPolicy — Red HatによるTokenRateLimitPolicy解説
• PII Detection and Redaction in LLM Pipelines — 規制業界でのPII対策実例
• lmgate: LLM API Gateway（GitHub） — 軽量LLMゲートウェイのOSSツール

---

次に読むおすすめ

LLMアプリのセキュリティ設計を深めたいなら、ゲートウェイ層の実装と並行して、実際に現場で使われているAIツールの選び方や活用の勘どころも知っておくと、設計判断に役立ちます。自腹で5つの主要AIツールを検証し、用途別の使い分けを整理したnote記事がおすすめです。

【2026年最新】主要AIツール5つに自腹課金して徹底比較！生産性が劇的に変わる「用途別・最強の1つ」の選び方（noteで続きを読む）