Azure API Management 完全ガイド
はじめに
Azure API Management（APIM） は、Azure が提供するフルマネージドの API ゲートウェイサービスです。クライアントとバックエンドの間に介在し、セキュリティ・流量制御・変換・監視・ドキュメント公開といった横断的関心事をコードを変更せずに実現できます。
インフラの基本（VNet、マネージド ID、ロールなど）はある程度知っているけれど APIM には触れたことがない ── そういった方を主な対象として、機能の全体像からユースケース、Azureサービスとの統合パターンまでをまとめます。
関連記事
APIM の立ち位置：クライアントとバックエンドの間
APIM の核心は「クライアントとバックエンドの間に立つ」ことです。
クライアント
│ ① リクエスト
▼
┌────────────────────────────────────────┐
│ APIM（API ゲートウェイ） │
│ │
│ ┌──────────────────────────────────┐ │
│ │ ポリシーエンジン │ │
│ │ inbound → backend → outbound │ │
│ │ 認証・制限・変換・キャッシュ... │ │
│ └──────────────────────────────────┘ │
└────────────────────────────────────────┘
│ ② 転送（バックエンド認証付き）
▼
バックエンド（App Service / Functions / LLM 等）
クライアントは APIM のエンドポイントだけを知ればよく、バックエンドの実装詳細（URL・構造・認証情報）は隠蔽されます。そのためバックエンドをリファクタリングしても API コンシューマーに影響が出ません。
ポリシーが間に挟まる
APIM の動作は ポリシー によって制御されます。ポリシーは XML で定義し、リクエスト処理の各フェーズに差し込めます。
<policies>
<inbound> <!-- クライアント → ゲートウェイ（受信時） -->
<rate-limit calls="100" renewal-period="60" />
<validate-jwt header-name="Authorization" ... />
</inbound>
<backend> <!-- ゲートウェイ → バックエンド（転送前） -->
<authentication-managed-identity resource="..." />
</backend>
<outbound> <!-- バックエンド → クライアント（応答時） -->
<json-to-xml apply="always" />
</outbound>
<on-error> <!-- エラー発生時 -->
<return-response> ... </return-response>
</on-error>
</policies>
ポリシーは グローバル → 製品 → API → オペレーション の順にスコープが絞られ、<base /> で親スコープのポリシーを継承します。75 以上のビルトインポリシーが用意されており、バックエンドのコードを変更せずに認証・変換・流量制御を追加できます。
APIM の 3 大コンポーネント
APIM は次の 3 つのコンポーネントで構成されます。
| コンポーネント | 役割 | 操作者 |
|---|---|---|
| API ゲートウェイ | リクエスト受付・ルーティング・ポリシー適用 | 実際の API 利用者（クライアント） |
| 管理プレーン | API 定義・ポリシー・ユーザー管理 | API プロバイダー（開発者・運用チーム） |
| 開発者ポータル | API ドキュメント公開・サブスクリプション申請 | API コンシューマー（外部/内部開発者） |
サービスティア（SKU）の選び方
APIM はいくつかのティアを提供しており、ネットワーク要件・スケール・コストによって選びます。
主な違いの軸
| 軸 | 内容 |
|---|---|
| ネットワーク分離 | VNet インジェクション（APIM を VNet 内に配置）は Premium / Premium v2 のみ対応 |
| プライベートバックエンド接続 | Standard v2 / Premium v2 は VNet 外部統合でプライベートバックエンドへ到達可能 |
| 可用性・SLA | Developer は SLA なし（検証専用）。本番は Basic 以上を選択 |
| マルチリージョン | Premium のみ複数リージョンへのゲートウェイ展開が可能 |
| 課金モデル | Consumption（従量課金）はリクエスト数に比例。スパイキーなトラフィックや FaaS 連携向け |
| プロビジョニング速度 | クラシックティア（Developer / Basic / Standard / Premium）はプロビジョニングに数十分〜数時間かかる場合がある。v2 ティア（Basic v2 / Standard v2 / Premium v2）は高速にプロビジョニングされるため、迅速な環境構築が可能 |
ユースケース別の目安
- 開発・検証のみ： Developer または Basic v2（高速プロビジョニング）
- シンプルな本番公開： Standard v2（VNet 外部統合でプライベートバックエンドにも到達可）
- エンタープライズ / 完全プライベート： Premium v2（VNet インジェクション・可用性ゾーン対応）
- スパイキーな FaaS 連携： Consumption（開発者ポータル・セルフホステッドゲートウェイは非対応）
詳細な機能比較は Azure API Management レベルの機能に基づく比較 を参照してください。
機能一覧とユースケース
1. API ゲートウェイ（ルーティング・ファサード）
概要： クライアントからのリクエストを受け取り、適切なバックエンドサービスへ転送します。バックエンドの実装詳細（URL や構造）をクライアントから隠蔽し、バックエンドを変更しても API コンシューマーに影響を与えません。
ユースケース：
- 複数のマイクロサービスを単一の API エンドポイントとして公開（API アグリゲーション）
- レガシーシステムをモダンな REST/GraphQL API として公開
- バックエンドのリファクタリング時に URL 変更をクライアントに隠蔽
2. ポリシーエンジン
概要： APIM の中核機能です。75 以上のビルトインポリシーを XML で定義し、API の動作をコード変更なしに制御できます。
主なポリシーカテゴリとユースケース：
| カテゴリ | 代表的なポリシー | ユースケース |
|---|---|---|
| アクセス制限 |
rate-limit / quota / ip-filter
|
DoS 対策・特定 IP のブロック・従量プランの流量管理 |
| 認証・認可 |
validate-jwt / validate-azure-ad-token
|
Entra ID トークンの検証・外部 IdP との連携 |
| 変換 |
set-header / rewrite-uri / xml-to-json
|
ヘッダー追加・URL リライト・プロトコル変換 |
| キャッシュ |
cache-lookup / cache-store
|
レスポンスキャッシュで応答速度改善・バックエンド負荷軽減 |
| ルーティング |
forward-request / set-backend-service
|
動的なバックエンド切り替え・A/B テスト |
| モック | mock-response |
バックエンド未実装時のスタブ応答 |
| ログ・監視 |
log-to-eventhub / emit-metric
|
カスタムメトリクスの発行・イベントストリーミング |
ポリシー式（C# 式）： ポリシーの値に @(context.User.Id) のような C# 式を使用でき、リクエストコンテキストに応じた動的な制御が可能です。
<!-- 例1: JWT クレームからテナント ID を取得し、バックエンド URL を動的に書き換え -->
<set-backend-service
base-url="@("https://" + context.Request.Headers
.GetValueOrDefault("Authorization","")
.AsJwt()?.Claims["tenant_id"]?.FirstOrDefault()
+ ".backend.example.com")" />
<!-- 例2: リクエストボディの内容に応じてカスタムヘッダーを付与 -->
<set-header name="X-Request-Category" exists-action="override">
<value>@{
var body = context.Request.Body.As<JObject>(preserveContent: true);
return body["priority"]?.ToString() == "high" ? "premium" : "standard";
}</value>
</set-header>
注意： ポリシー式は強力ですが、複雑なロジックはゲートウェイのパフォーマンスに影響を与える可能性があります。また、利用できる .NET 型には制限があり（
System.String、System.Linqなど一部の型のみ）、任意のライブラリは使用できません。重い処理はバックエンド側に委ねるのが推奨です。詳細は ポリシー式 を参照してください。
3. レート制限・クォータ管理
概要： 単位時間あたりの呼び出し数やデータ量に上限を設けます。API の安定運用・不正利用防止・プランによる差別化に使います。
レート制限とクォータの違い
「レート制限」と「クォータ」は混同されがちですが、目的と適用スケールが異なります。
| 観点 | レート制限（Rate Limit） | クォータ（Quota） |
|---|---|---|
| 目的 | 瞬間的なバースト（急増）を抑制し、バックエンドを保護する | 一定期間の総利用量を制限し、ビジネス上の使用枠を管理する |
| 時間スケール | 短い（秒〜分単位） | 長い（時間〜日〜月単位） |
| カウンター | 時間ウィンドウ終了でリセット | 指定期間の終了でリセット（月初など） |
| 制限対象 | 呼び出し回数 | 呼び出し回数 または データ転送量（帯域） |
| 超過時の応答 |
429 Too Many Requests（短時間待てばリトライ可能） |
403 Forbidden（期間終了まで利用不可。プランアップグレードを促す） |
例で理解する： あるAPI製品で「1 分あたり 100 リクエスト」のレート制限と「月間 10,000 リクエスト」のクォータを同時に設定した場合、レート制限は瞬間的な集中を防ぎ（DDoS 的なアクセスの緩和）、クォータは月間の総利用量を管理します（無料プランの上限管理）。両者は補完関係にあり、組み合わせて使うのが一般的です。
ポリシー一覧
| ポリシー | 制限の単位 | 特徴 |
|---|---|---|
rate-limit |
呼び出し回数 / 時間ウィンドウ | 短期間の急増を抑制 |
rate-limit-by-key |
カウンターキー（IP・ユーザー等）ごと | クライアントごとに独立した制限 |
quota |
呼び出し回数 or データ量 / 長期間 | 月間上限など長期クォータ |
quota-by-key |
カウンターキーごと | クライアントごとに独立したクォータ |
rate-limit/quota（キーなし版）はサブスクリプション単位で制限されます。*-by-key版はポリシー式でカウンターキーを自由に指定でき、IP アドレス・ユーザー ID・カスタムヘッダーなど任意の粒度で制限をかけられます。
ユースケース：
- レート制限： バックエンドの処理能力に合わせた流量制御、単一クライアントが全帯域を占有するのを防止、DDoS 的なリクエスト集中の緩和
- クォータ： フリーミアムモデルで無料プランは月 1,000 回まで・有料プランは月 100,000 回まで、SaaS の利用プランごとの使用量上限管理、パートナーごとの月間 API コール数の契約管理
4. 可観測性（Observability）
概要： API のトラフィック・パフォーマンス・エラーを監視・分析するための機能群です。
| 機能 | 提供先 |
|---|---|
| メトリクス | Azure Monitor（リクエスト数・レイテンシ・エラー率等） |
| リクエストログ | Azure Monitor / Log Analytics でのリクエスト詳細記録 |
| Application Insights 連携 | エンドツーエンドトレース・リアルタイム監視 |
| API インスペクター | 個別リクエストのポリシー実行トレース（デバッグ用途） |
| 組み込みダッシュボード | Azure Portal 上でのビジュアル分析 |
ユースケース：
- SLA の遵守状況監視（エラー率・レイテンシアラート）
- API ごとの使用量把握・課金根拠データ取得
- パフォーマンス問題のボトルネック特定
その他の APIM 機能
APIM は上記のほかにも、以下の機能を提供しています。
| 機能 | 概要 |
|---|---|
| キャッシュ | レスポンスを組み込みキャッシュまたは外部 Redis にキャッシュし、バックエンド負荷を軽減 |
| API バージョニング | URL パス・ヘッダー・クエリパラメータで v1/v2 を分岐。後方互換を保ちながら API を進化させる |
| リビジョン | 同一バージョン内での非破壊的な変更履歴管理。本番に影響させずに変更テストが可能 |
| 開発者ポータル | OpenAPI 仕様から自動生成されるドキュメント・インタラクティブなコンソール・API キー管理 |
| 製品（Product）とサブスクリプション | 複数 API を製品としてまとめ、レート制限・クォータ・アクセス制御をまとめて設定 |
| ワークスペース | 複数チームが同一 APIM インスタンスで独立した管理環境を持てるフェデレーションモデル（Premium 系限定） |
| セルフホステッドゲートウェイ | ゲートウェイコンポーネントをオンプレミス/他クラウドで動作させ、設定は Azure 上で一元管理 |
| マルチリージョンデプロイ | 複数 Azure リージョンにゲートウェイを展開してグローバルな低レイテンシを実現（Premium 限定） |
| API 種別サポート | REST・GraphQL・WebSocket・gRPC・SOAP・OData など多様なプロトコルをサポート |
AI ゲートウェイ機能
生成 AI（LLM）の普及に合わせ、APIM には AI API を管理するための専用機能群「AI ゲートウェイ」が組み込まれています。
注意： AI ゲートウェイは機能の追加・変更が活発な領域です。以下は概要レベルの説明にとどめています。詳細や最新の GA 状況は必ず公式ドキュメントを参照してください。
対応エンドポイントとポリシーの制限
AI ゲートウェイが管理できる主なエンドポイントは以下のとおりです。
| エンドポイント種別 | AI ゲートウェイポリシーの適用 |
|---|---|
| Azure OpenAI / AI Foundry（Azure OpenAI API 形式） | フル活用可能（azure-openai-* 系・llm-* 系ポリシー両方） |
| OpenAI 互換エンドポイント（サードパーティ推論等） |
llm-* 系ポリシーを中心に適用可能 |
| 非互換エンドポイント（Amazon Bedrock 等） | パススルー（ワイルドカードオペレーション）として登録は可能だが、AI ゲートウェイ固有のポリシー（トークン制限・セマンティックキャッシュ等）はほぼ適用できない |
非互換エンドポイントを APIM 経由で公開することは技術的には可能ですが、AI ゲートウェイとしての機能はほぼ使えず、実質的にはパススルーのリバースプロキシに近い状態になります。
ポリシー系統：azure-openai-* と llm-*
AI ゲートウェイ向けのポリシーは大きく 2 系統あります。
| 系統 | 主な対象 | 例 |
|---|---|---|
azure-openai-* |
Azure OpenAI in Foundry Models（Azure OpenAI API 形式） |
azure-openai-token-limit、azure-openai-emit-token-metric、azure-openai-semantic-cache-*
|
llm-* |
Azure AI Model Inference API 経由のモデル・OpenAI 互換モデル全般 |
llm-token-limit、llm-emit-token-metric、llm-semantic-cache-*、llm-content-safety
|
両系統は機能的に類似していますが、適用できる API の種類が異なります。詳細は公式ポリシーリファレンスを参照してください。
主な AI ゲートウェイ機能（概要）
- トークン単位の制限： リクエスト回数ではなくトークン消費量で制限。サブスクリプション・IP・カスタムキーごとに設定可能
- セマンティックキャッシュ： 過去のプロンプトとベクトル類似度を比較し、意味的に近い質問のレスポンスをキャッシュから返す（Azure Managed Redis / RediSearch を使用）
-
LLM 向けロードバランシング・サーキットブレーカー： 複数 LLM エンドポイントへの重み付き分散と、
Retry-Afterヘッダーに基づく動的なサーキットブレーカー - トークンメトリクス出力： プロンプト/補完/合計トークンを Azure Monitor に送信し、チーム別コスト配賦に活用
- コンテンツセーフティ： Azure AI Content Safety と連携してプロンプト/応答を自動モデレート
- MCP サーバー管理： REST API を MCP サーバーとして公開したり、外部 MCP サーバーを APIM 経由でガバナンス（詳細は変化が激しいため公式確認推奨）
- A2A プロトコルサポート： AI エージェント間通信（Agent-to-Agent）の管理（プレビュー段階）
この領域の注意点： 各機能の GA/プレビュー状況、エンドポイント種別ごとのポリシー対応可否は頻繁に更新されます。本番利用前に AI gateway in Azure API Management で最新状況を確認してください。
Azure サービスとの統合
APIM はさまざまな Azure サービスと連携して利用します。それぞれの責務分担を以下に整理します。
セキュリティ・ネットワーク
| Azure サービス | APIM との役割分担 |
|---|---|
| Microsoft Entra ID | Entra ID がトークン発行・IDプロバイダーを担当。APIM は validate-azure-ad-token ポリシーでトークンを検証・アクセス制御 |
| Azure Key Vault | 証明書・シークレットの保管を Key Vault が担当。APIM は参照するだけで機密情報を直接持たない |
| Azure VNet / プライベートエンドポイント | ネットワーク分離は VNet・NSG・プライベートエンドポイントが担当。APIM はその境界内に配置して通信を制御 |
| Application Gateway | WAF（Web アプリケーションファイアウォール）・L7 ロードバランシングは App GW が担当。APIM を Internal VNet に配置し、App GW を前段に置く構成でゼロトラスト的なアーキテクチャを実現 |
| Azure Front Door | グローバルな HTTP ロードバランシング・CDN・DDoS 対策は Front Door が担当。APIM は API ゲートウェイとしての処理に集中 |
| Microsoft Defender for APIs | API に対するランタイムセキュリティ監視・脅威検出を担当。APIM との統合で API トラフィックの異常を検知 |
| Azure DDoS Protection | ネットワーク層の DDoS 対策を担当。APIM は上位レイヤーのレート制限を担当 |
監視・ログ
| Azure サービス | APIM との役割分担 |
|---|---|
| Azure Monitor / Log Analytics | ログ・メトリクスの収集・保管・クエリを担当。APIM は診断設定で Monitor に対してリクエストログ・メトリクスを送信 |
| Application Insights | エンドツーエンドのトレース・ライブメトリクスを担当。APIM はリクエストごとの詳細な計装データを送信 |
| Azure Event Hubs | 高スループットなイベントストリーミングを担当。log-to-eventhub ポリシーで APIM のリクエストデータをリアルタイムに Event Hubs へ送信、ストリーム処理パイプラインに接続 |
バックエンド・統合
| Azure サービス | APIM との役割分担 |
|---|---|
| Azure Functions | ビジネスロジックを Functions が実装。APIM は Functions を API として公開・保護 |
| Azure Logic Apps | ワークフロー・システム統合を Logic Apps が担当。APIM は Logic Apps を API として標準化・保護 |
| Azure App Service | Web アプリ・API アプリのホスティングを App Service が担当。APIM はその前段でゲートウェイとして機能 |
| Azure OpenAI / AI Foundry | LLM 推論・モデルホスティングを担当。APIM の AI ゲートウェイ機能でトークン制限・ロードバランシング・セマンティックキャッシュを適用 |
| Azure Cache for Redis / Azure Managed Redis | 高性能キャッシュ基盤を担当。APIM から外部キャッシュとして利用し、通常キャッシュとセマンティックキャッシュ双方で活用 |
| Azure Cosmos DB | NoSQL データ保管を担当。APIM のポリシーから中間コンピューティングなしに直接 CRUD 操作を実行するユースケースも可能 |
ガバナンス・検索
| Azure サービス | APIM との役割分担 |
|---|---|
| Azure API Center | 組織全体の API インベントリ・検索・ガバナンスを担当。APIM で管理している API を API Center に同期し、組織横断での API 発見・再利用を促進 |
| Power Platform | ローコード/ノーコード開発を担当。APIM からカスタムコネクタとして API をエクスポートし、Power Automate・Power Apps で活用 |
VNet との組み合わせ
APIM のネットワーク構成は、API の公開範囲とバックエンドの保護レベルを決定する重要な設計ポイントです。ティアによって利用できるネットワーク機能が異なるため、要件に合わせた選択が必要です。
ネットワーク統合モデルの全体像
APIM には大きく 3 つのネットワーク統合モデルがあります。
| モデル | 概要 | 対応ティア |
|---|---|---|
| パブリック（デフォルト） | APIM のゲートウェイがインターネットに公開され、バックエンドへもパブリック経由で通信 | 全ティア |
| VNet 統合（外部統合） | APIM 自体はパブリックだが、VNet 内のプライベートバックエンドへ到達可能 | Standard v2 / Premium v2 |
| VNet インジェクション（External/Internal） | APIM 自体を VNet 内に配置。External モードは外部公開あり、Internal モードは完全プライベート | Premium（クラシック） / Premium v2 |
VNet 統合（外部統合）── バックエンドだけをプライベートに
Standard v2 / Premium v2 で利用できるモデルです。APIM のゲートウェイはパブリックに公開されたまま、VNet 内のサブネットに「腕を伸ばす」形でプライベートバックエンドにアクセスします。
インターネット
│
▼
APIM（パブリック）
│ VNet 統合（委任サブネット経由）
▼
┌─────────────── VNet ───────────────┐
│ App Service（プライベート EP） │
│ Azure OpenAI（プライベート EP） │
│ VM / AKS │
└────────────────────────────────────┘
特徴：
- APIM のゲートウェイ URL はパブリックにアクセス可能
- バックエンドはプライベートエンドポイントで保護できる
- VNet インジェクションほどのネットワーク制御は不要だが、バックエンドを閉域化したい場合に最適
- NSG でサブネットの送受信を制御可能
ユースケース： 外部向け API を公開しつつ、バックエンド（Azure OpenAI や App Service）はインターネットに露出させたくない場合。多くのケースではこの構成で十分です。
VNet インジェクション ── APIM 自体を VNet 内に配置
Premium（クラシック）/ Premium v2 で利用できるモデルです。APIM のゲートウェイ自体が VNet 内の専用サブネットにデプロイされます。
External モード
ゲートウェイにはパブリック IP が付与され、インターネットからアクセスできます。ただし APIM 自体は VNet 内にあるため、バックエンドとの通信はすべてプライベートネットワーク内で完結します。
インターネット
│ パブリック IP 経由
▼
┌─────────────── VNet ───────────────┐
│ APIM（External モード） │
│ │ │
│ ▼ │
│ バックエンド群（プライベート） │
└────────────────────────────────────┘
Internal モード
ゲートウェイにはプライベート IP のみが付与され、インターネットから直接アクセスできません。VPN / ExpressRoute / Application Gateway 経由でのみ到達可能です。
インターネット
│
▼
Application Gateway（WAF + パブリック IP）
│
▼
┌─────────────── VNet ───────────────┐
│ APIM（Internal モード） │
│ │ プライベート IP のみ │
│ ▼ │
│ バックエンド群（プライベート） │
└────────────────────────────────────┘
External モードと Internal モードの使い分け：
| 観点 | External | Internal |
|---|---|---|
| ゲートウェイの公開 | インターネットからアクセス可能 | VNet 内 / VPN / ExpressRoute からのみ |
| 前段の構成 | 必須ではない | Application Gateway や Front Door を前段に置くのが一般的 |
| 代表的な用途 | 外部 API 公開 + バックエンド完全プライベート | 社内 API / 金融・医療等のコンプライアンス要件 |
プライベートエンドポイント（インバウンド）
VNet インジェクションとは別に、APIM のゲートウェイに対して プライベートエンドポイント を作成し、VNet 内からのみアクセスさせる方法もあります。
- Standard v2 / Premium v2 / Basic v2 で利用可能
- VNet インジェクションほどの構成の複雑さがなく、インバウンドのプライベート化だけが目的なら手軽
┌─────────────── VNet ───────────────┐
│ 社内クライアント │
│ │ │
│ ▼ │
│ APIM プライベートエンドポイント │
└────────────────────────────────────┘
│ Azure バックボーン
▼
APIM（パブリックインフラ上）
│
▼
バックエンド
DNS の考慮事項
VNet 内に APIM を配置する場合（特に Internal モード）、DNS の構成が重要になります。
- Internal モードでは APIM のゲートウェイ URL がプライベート IP に解決される必要がある
- ゲートウェイだけでなく、管理（scm）エンドポイントや開発者ポータルの DNS レコードも必要。これらを忘れると Azure Portal からの管理操作や開発者ポータルへのアクセスが失敗する
- Azure プライベート DNS ゾーン（
azure-api.net）を作成し、VNet にリンクするのが一般的 - VPN / ExpressRoute 経由のオンプレミスクライアントには、条件付き DNS フォワーダーの構成が必要。ハイブリッド環境では Azure DNS Private Resolver を活用すると、オンプレミスと Azure 間の DNS 解決を一元管理しやすい
- カスタムドメインを使用する場合は、証明書管理（Key Vault 連携）も併せて設計する
NSG・UDR の構成
VNet インジェクション時には、APIM が正常に動作するためのネットワークルールを正しく構成する必要があります。
| 設定項目 | ポイント |
|---|---|
| NSG | APIM の管理トラフィック（ポート 3443）の許可が必須。また、Azure インフラへのアウトバウンド通信も必要。ApiManagement サービスタグを使用すると、個別の IP アドレスを管理する必要がなく NSG ルールを簡潔に構成できる |
| UDR | 強制トンネリング（すべてのトラフィックをオンプレミスに転送）を行う場合は、APIM 管理トラフィックをバイパスするルートが必要 |
必要なポートや IP の詳細は VNet に接続された API Management のネットワーク リソースの構成 を参照してください。
補足： Premium v2 の VNet インジェクション（VNet v2）では、クラシック Premium と比較して管理トラフィックの要件が簡素化されており、NSG・UDR の構成負荷が軽減されています。
どのモデルを選ぶか ── 判断フロー
バックエンドをプライベートにしたい？
├─ No → パブリック（デフォルト）で OK
└─ Yes
├─ APIM 自体もプライベートにしたい？
│ ├─ No → VNet 統合（Standard v2 / Premium v2）
│ └─ Yes
│ ├─ インバウンドだけプライベート化？ → プライベートエンドポイント
│ └─ 完全なネットワーク制御が必要？ → VNet インジェクション（Premium）
└─ （External モード / Internal モードの選択は公開要件による）
よくある構成パターン
パターン 1：外部 API 公開（B2B）
Internet
│
▼
Azure Front Door（DDoS・CDN）
│
▼
APIM（認証・レート制限・変換）
│
▼
App Service / Functions（ビジネスロジック）
外部パートナーへの API 公開。APIM が認証（API キー / JWT）・レート制限・ドキュメント公開を一手に担います。
パターン 2：エンタープライズ内部 API（プライベートネットワーク）
社内クライアント / VPN
│
▼
Application Gateway（WAF）
│
▼
APIM（Internal VNet）
│
▼
プライベートバックエンド群
APIM を Internal モード（VNet インジェクション）で配置し、前段に Application Gateway（WAF）を置くことで、インターネット公開しつつバックエンドはすべてプライベートネットワーク内に閉じる構成です。
パターン 3：AI API 管理
AI アプリ / エージェント
│
▼
APIM AI ゲートウェイ
（トークン制限・ロードバランシング
セマンティックキャッシュ・コンテンツセーフティ）
│
├─ Azure OpenAI（PTU インスタンス）
├─ Azure AI Foundry（Pay-as-you-go）
└─ その他 OpenAI 互換エンドポイント
複数の LLM エンドポイントを APIM で一元管理。PTU インスタンスを優先利用し、超過分を従量課金にスピルオーバーさせる構成が代表例です。
まとめ
Azure API Management は単なるリバースプロキシではなく、API ライフサイクル全体を支えるプラットフォームです。主要機能を再掲します。
| 機能カテゴリ | 提供価値 |
|---|---|
| ゲートウェイ・ルーティング | バックエンド隠蔽・プロトコル変換 |
| ポリシーエンジン | コード変更なしの動作制御（75+ ポリシー） |
| セキュリティ | インバウンド/アウトバウンド両方の認証・JWT クレームによる認可・ネットワーク分離 |
| 流量制御 | レート制限・クォータ管理 |
| キャッシュ | バックエンド負荷軽減・高速化 |
| 可観測性 | メトリクス・ログ・トレースの一元化 |
| AI ゲートウェイ | LLM API のトークン管理・セマンティックキャッシュ・MCP/A2A 対応 |
API の種類・利用者・セキュリティ要件に合わせてポリシーを積み上げていく設計が APIM の真髄です。まずは Developer ティアで試してみることをおすすめします。
免責事項： Azure API Management は機能の追加・GA/プレビュー状態の変更が活発なサービスです。本記事の内容は執筆時点の情報に基づいています。ティアの機能差やネットワーク統合の対応状況は変わりうるため、設計・導入時には必ず公式ドキュメントで最新情報を確認してください。
参考リンク
Discussion