このエントリは2025/09/10現在の情報に基づいています。将来の機能追加や変更に伴い、記載事項からの乖離が発生する可能性があります。
問い合わせ
以下の記事を読んだ方から、以下のような問い合わせが届いた。
現在Azure OpenAI Service (AOAI) をAzure API Management (APIM) の背後に置いて、プロンプトログを取得するように構成している。このたび、他社のLLMを試すことになったので、同様にAPIMの背後に配置しようと考えている。このとき、
- 他社LLMでもプロンプトログは取得できるか?
- 同一ログテーブルに格納できるか?
回答
これは非常に明快で、いずれも実現可能。同一テーブルに格納できる。ログテーブルはApiManagementGatewayLogsで、フォーマットは以下のドキュメントに従う。
ApiManagementGatewayLogs
https://learn.microsoft.com/azure/azure-monitor/reference/tables/apimanagementgatewaylogs
具体的には以下のような感じで取得できる。

では試してみる。
環境
以下の条件で構成した。もちろん、APIMのSKUやLLMは何を使ってもよい。
| リソース | 利用したもの | 備考 |
|---|---|---|
| APIM | Standard V2 | 他のSKUでも実現可能 診断設定は構成済み |
| LLM | Gemini (Google Cloud) | 通常のREST APIを利用 https://ai.google.dev/api?_gl=1 OpenAI互換もあるが、今回は使わない https://ai.google.dev/gemini-api/docs/openai?_gl=1 |
Geminiの場合、OpenAPI Specが取得できるので、それを使ってAPIMにAPIを登録する。このとき、API Keyが必要なので、API Keyを作成しておく。
OpenAPI spec File
https://discuss.ai.google.dev/t/openapi-spec-file/36911/2
あとはAPIMへのOpenAPI Specのインポートを実施するだけなので、特に難しいことはない。
OpenAPI 仕様のインポート / Import an OpenAPI specification
https://learn.microsoft.com/azure/api-management/import-api-from-oas
API KeyはBackendsで設定してもよいし、ポリシーで設定してもよい。API Keyを設定するにあたり、Header keyはapi-keyではなく、x-goog-api-keyなので注意が必要。
x-goog-api-key: $GEMINI_API_KEY
OpenAI互換APIを使う場合、api-keyではなく、Authorizationを使う必要がある(しかもBearer を付けないといけない)。
authorization: Bearer $GEMINI_API_KEY
これでおしまい。
試してみる
Azure Portalからでも、REST API Clientからでもよい。まずはStreamingを使わない場合。いずれのケースでもGemini 2.5 Flashを使っている。

応答は以下のよう。今回は(今回も?)応答の是非は重要ではない。
{
"candidates": [
{
"content": {
"parts": [
{
"text": "Google Cloudは、量子コンピュータによる将来的な暗号解読のリスクに備えるため、PQC (Post Quantum Cryptography) への対応を積極的に進めています。\n\n現在の主な対応状況と今後の方向性は以下の通りです。\n\n### 1. 全体的なアプローチ\n\n* **NIST標準の追随:** 米国国立標準技術研究所 (NIST) が選定したPQC標準アルゴリズム (特にCRYSTALS-KyberとCRYSTALS-Dilithium) に基づいて実装を進めています。\n* **ハイブリッドモードの採用:** 既存の古典的な暗号 (例: ECDH、RSA) とPQCアルゴリズムを組み合わせた「ハイブリッドモード」を初期段階で採用しています。これにより、PQCアルゴリズムの安全性がまだ完全に証明されていない段階でのリスクを軽減し、既存システムの互換性を維持しながら段階的に移行します。\n* **「Crypto Agility (暗号アジリティ)」の重視:** 将来的に新たな暗号アルゴリズムが登場したり、既存のものが危殆化したりした場合に、迅速かつ柔軟に対応できるアーキテクチャを構築することを目指しています。\n\n### 2. 主要なサービスにおける対応状況\n\n#### a. ネットワーク通信 (Encryption in Transit)\n\nGoogle CloudにおけるPQC対応の最も先行している領域です。\n\n* **Google Cloud Load Balancers (特にExternal HTTPS Load Balancer):**\n * 2023年頃から、一部のExternal HTTPS Load Balancerにおいて、クライアントとのTLSハンドシェイクでPQCハイブリッドモード(例: X25519 + CRYSTALS-Kyber)の試験的なサポートが開始されました。\n * これにより、Load Balancerを経由する外部からのトラフィックに対して、将来の量子コンピュータによる解読リスクへの耐性を提供し始めています。\n* **Cloud VPN (HA VPN):**\n * 2023年後半には、HA VPNにおいてIKEv2 (Internet Key Exchange v2) プロトコルでのPQCハイブリッドモード (例: X25519 + CRYSTALS-Kyber) のサポートが導入されました。\n * これにより、オンプレミス環境とGoogle Cloud間のVPN接続のセキュリティを量子耐性のあるものに強化できます。\n* **内部ネットワーク通信:** Googleは、自社のグローバルネットワーク内のサービス間通信においてもPQCへの移行を進めており、最終的には全ての内部トラフィックが量子耐性を持つことを目指しています。\n\n#### b. 鍵管理 (Key Management)\n\nPQCにおける鍵管理は、より複雑で長期的な課題ですが、Googleもこれに取り組んでいます。\n\n* **Cloud Key Management Service (KMS) / Cloud HSM:**\n * 現時点では、KMSやCloud HSMが生成・管理する鍵そのものが直接的にPQCアルゴリズムで保護されているわけではありませんが、GoogleはこれらのサービスにおけるPQCの適用を研究・計画しています。\n * 最終的には、鍵の生成、保管、利用、暗号化・復号処理にPQCアルゴリズムを適用することを目指します。\n * 特に、長期的なデータ保護が必要な「Encryption at Rest (保管時の暗号化)」において、PQC対応は不可欠となります。\n\n#### c. その他のサービス\n\n* **Google Kubernetes Engine (GKE), Compute Engineなど:** これらのサービス自体が直接PQCアルゴリズムを実装するというよりは、上記のLoad BalancerやVPN、KMSなどのインフラレイヤーでPQCが適用されることで、利用するアプリケーションやデータが保護される形になります。\n* **認証・認可 (IAM):** ユーザー認証やサービスアカウントの認証における基盤となる暗号技術も、将来的にはPQCへの移行が検討される領域です。\n\n### 3. 利用者側への影響と今後の展望\n\n* **多くの場合、自動的に恩恵を受ける:** Google Cloudのマネージドサービスを利用している場合、PQCの移行はGoogleによってインフラレベルで進められるため、利用者が直接的な操作を求められることは少ないでしょう。特に、Load BalancerやVPNのPQC対応は、設定を変更することなく自動的に適用される可能性があります (ただし、クライアント側がPQCハイブリッドに対応している必要があります)。\n* **カスタムな暗号実装の場合:** 独自の暗号ライブラリやプロトコルを使用している場合、PQCへの移行計画を立て、NIST標準に準拠したPQCアルゴリズムへのアップデートを検討する必要があります。\n* **継続的な進化:** PQCはまだ進化中の分野であり、NISTの標準化プロセスも継続しています。Google Cloudの対応も、新しい標準や脅威の状況に応じて進化していくことが予想されます。\n\n### 参考情報\n\nGoogle CloudのPQCに関する最新情報は、公式ブログやドキュメントで随時公開されています。\n「Google Cloud post-quantum cryptography」などのキーワードで検索すると、最新の発表を見つけることができます。\n\n例:\n* [Google Cloudがポスト量子暗号で顧客のセキュリティを強化](https://cloud.google.com/blog/ja/products/identity-security/google-cloud-strengthens-customer-security-with-post-quantum-cryptography) (2023年5月)\n* [Google Cloud VPN now supports post-quantum cryptography](https://cloud.google.com/blog/products/networking/google-cloud-vpn-now-supports-post-quantum-cryptography) (2023年10月)\n\nGoogle CloudはPQC移行の最前線にいるプロバイダの一つであり、その動向は業界全体のPQC採用の指標ともなります。"
}
],
"role": "model"
},
"finishReason": "STOP",
"index": 0
}
],
"usageMetadata": {
"promptTokenCount": 17,
"candidatesTokenCount": 1223,
"totalTokenCount": 2649,
"promptTokensDetails": [
{
"modality": "TEXT",
"tokenCount": 17
}
],
"thoughtsTokenCount": 1409
},
"modelVersion": "gemini-2.5-flash",
"responseId": "QBPBaOyWHOOzqtsPhNW9WA"
}
Tokenの利用量も含まれていることがわかる。

続いてStreamingを使う場合。リクエストパラメータが変わる(generateContentからstreamGenerateContent)。応答は以下のよう。
[
{
"candidates": [
{
"content": {
"parts": [
{
"text": "Google Cloudは、ポスト量子暗号(PQC: Post Quantum Cryptography)への移行に非常に積極的であり、研究開発、標準化への貢献、そして実際のサービスへの導入を段階的に進めています。\n\n現在の主要"
}
],
"role": "model"
},
"index": 0
}
],
"usageMetadata": {
"promptTokenCount": 17,
"candidatesTokenCount": 48,
"totalTokenCount": 1329,
"promptTokensDetails": [
{
"modality": "TEXT",
"tokenCount": 17
}
],
"thoughtsTokenCount": 1264
},
"modelVersion": "gemini-2.5-flash",
"responseId": "ERXBaIzaKs-Fz7IPyd3lgA8"
},
...,
{
"candidates": [
{
"content": {
"parts": [
{
"text": "的に導入が進められるでしょう。\n\n最新の情報は、Google Cloudの公式ブログやセキュリティに関する発表を定期的に確認することをお勧めします。"
}
],
"role": "model"
},
"finishReason": "STOP",
"index": 0
}
],
"usageMetadata": {
"promptTokenCount": 17,
"candidatesTokenCount": 910,
"totalTokenCount": 2191,
"promptTokensDetails": [
{
"modality": "TEXT",
"tokenCount": 17
}
],
"thoughtsTokenCount": 1264
},
"modelVersion": "gemini-2.5-flash",
"responseId": "ERXBaIzaKs-Fz7IPyd3lgA8"
}
]
では、Log Analytics WorkspaceでApiManagementGatewayLogsを確認すると、先ほど紹介したような形で格納されていることを確認できる。

Request/Responseのログを拡大すると、以下のよう。
