Azure API Management入門｜APIゲートウェイの基本設計からポリシー設定・料金まで現場で使える実践ガイド

クラウド上でAPIを公開し始めると、「バックエンドのURL変更のたびに呼び出し元を直す手間」「誰がどのAPIを何回叩いているか把握できない」「レート制限をバックエンドごとに個別実装している」といった管理の煩雑さが積み重なってくる。オンプレミスでnginxやF5を使ってきたエンジニアなら、「ゲートウェイで一元管理すべき」という感覚はすぐに来るはずだ。

Azure API Management（APIM）は、まさにその役割をAzureのマネージドPaaSとして担うサービスだ。複数のバックエンドAPIの前段に置き、認証・レート制限・変換・ログ収集を統合管理する。

この記事では、Azure API Managementの基本構造からティア選択の判断基準、ポリシー設定の実例、料金の読み解き方まで、現場エンジニアが実務で使えるレベルで体系的に解説する。

Azure API Managementの全体像と3つのコンポーネント

Azure API Managementは、大きく3つのコンポーネントで構成されている。

APIMの位置づけは「クライアントとバックエンドの間のインテリジェントな仲介者」だ。バックエンドはAzure App ServiceでもAzure Functionsでも、外部REST APIでも、オンプレのWebサービスでも、APIMからはすべて「バックエンドURL」として抽象化される。

バックエンドが変わっても呼び出し元のクライアントはAPIMのURLを叩き続ければよい。この疎結合がAPIMの最大の価値のひとつだ。

なぜAPI Managementが必要なのか？直接公開との比較

「バックエンドAPIを直接外部公開すればいいのでは？」という疑問は自然だ。しかし直接公開には次のリスクが積み重なる。

・認証の分散実装: バックエンドごとに認証ロジックを実装すると、漏れや実装差異が生まれる
・レート制限なし: 悪意ある過剰アクセスや設計ミスによる大量リクエストをブロックできない
・バックエンドURL露出: Azure App ServiceのデフォルトURLが外部に知られると、APIMを回避した直接アクセスが可能になる
・ログの分散: 誰がどのAPIをいつ叩いたかが統合して追跡できない
・バージョン管理なし: APIの変更が後方互換性を壊しても気づかない

APIMを前段に置くと、これらをすべてゲートウェイ層で一括管理できる。

AWSのAmazon API Gatewayとの比較では、APIMは複数バックエンドの統合管理とエンタープライズ向けポリシーエンジンが特徴で、Lambda統合に特化したAWS側とは性質が異なる。

ティア選定の判断基準

APIMには複数のティア（サービスレベル）があり、選択ミスがコスト過大または機能不足につながる。以下が執筆時点（2026年7月）の主要ティアの概要だ。

選定の実務的な判断軸を整理する。

・Consumptionは本番用途に使えるか: SLAは99.95%あるが、VNet統合・組み込み開発者ポータル・Standard以上のキャッシュ機能が使えない。スタートアップのシンプルなAPIや社内向けAPIには十分だが、エンタープライズ要件には不向き
・Developerは本番禁止: SLAがないため開発・テストに限定する。本番で使うのは明確な設計ミス
・BasicとStandardの境目: キャッシュ容量（Basic: 10MB / Standard: 50MB）と1ユニットあたりのスループット上限が主な違い。APIレスポンスを積極的にキャッシュしたいならStandard以上を選ぶ
・Premiumの適用条件: VNet内のバックエンドへのプライベート接続、マルチリージョン展開、可用性ゾーン対応が必要な場合に限る。コストが大幅に上がるため要件が明確でない限り選ばない

なお、Basic v2・Standard v2・Premium v2という新世代ティアも展開中だ。v2は起動時間の短縮やスケーリングの柔軟性が改善されているため、新規導入時は公式サイトでv2ティアの提供状況を合わせて確認すること。

APIの登録と基本設定の流れ

APIMへのAPI登録はAzureポータルから行う。OpenAPI（Swagger）仕様書があれば最もスムーズだ。

1. APIMインスタンスの作成

Azureポータルで「API Management services」を検索し、新規作成する。主な設定項目は次のとおりだ。

・リソース名: APIMのサブドメインになる（例: `contoso.azure-api.net`）
・リージョン: バックエンドと同じリージョン（または近いリージョン）を選ぶ。データ転送コストとレイテンシを最小化するため
・ティア: 前節の判断基準で選択
・仮想ネットワーク: バックエンドがVNet内にある場合はPremiumティアでVNet統合を設定

Basic/Standard/PremiumではAPIMインスタンスの作成に30～45分程度かかる。Consumptionは数分で完了する。

2. APIの登録

インスタンス作成後、「APIs」から「+ Add API」を選ぶ。

・OpenAPI仕様書から取り込む（推奨）: Swagger JSONまたはYAMLをアップロードすると、エンドポイント・パラメータ・レスポンス定義が自動生成される
・HTTP APIとして手動登録: バックエンドURLとHTTPメソッド・パスを手動で定義する（既存のAPIドキュメントがない場合）
・Azure Functionsから取り込む: Azure Functions連携の場合、Functions側でAPI定義を公開していれば「Azure Function App」から直接インポートできる

Azure Functionsをバックエンドにする場合は、Azure Functions入門の記事も合わせて参照してほしい。

3. バックエンドURLの設定とアクセス制限

APIを登録したら、「Backend」設定でバックエンドサービスのURLを指定する。APIMはクライアントから受け取ったリクエストをここで指定したURLに転送する。

重要: バックエンドがAzure App ServiceやAzure Functionsの場合、デフォルトの `*.azurewebsites.net` ドメインへの直接アクセスをAPIMのパブリックIPアドレスからのみ許可するよう制限すること。これがないとAPIMのポリシーを完全に回避した直接アクセスが可能になる。APIMの送信IPアドレスはAzureポータルの「Network」→「Public IP addresses」で確認できる。

ポリシーで実現するアクセス制御・変換処理

APIMの真価はポリシー（Policy）にある。ポリシーはXML形式で記述し、リクエストとレスポンスの処理を細かく制御できる。

ポリシーは4つのセクションで構成される。

・inbound: クライアントからのリクエストを受け取った後、バックエンドに転送する前の処理
・backend: バックエンドへの転送方法の制御（ロードバランシングなど）
・outbound: バックエンドからのレスポンスをクライアントに返す前の処理
・on-error: エラー発生時の処理

よく使うポリシーの実例を示す。

レート制限（過剰アクセスの防御）

# inboundセクションに記述
# 1つのサブスクリプションキーにつき10秒間に5回まで許可
<rate-limit calls="5" renewal-period="10" />

# IPアドレス単位でのレート制限（より柔軟な条件分岐が可能）
<rate-limit-by-key calls="100" renewal-period="60"
    counter-key="@(context.Request.IpAddress)" />

JWTトークンの検証（Entra IDとの連携）

# inboundセクション
# AuthorizationヘッダーのBearerトークンをEntra IDのJWKS URIで検証
<validate-jwt header-name="Authorization"
    failed-validation-httpcode="401"
    failed-validation-error-message="Unauthorized">
    <openid-config url="https://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration" />
    <audiences>
        <audience>{your-app-client-id}</audience>
    </audiences>
</validate-jwt>

Microsoft Entra IDとの統合についてはMicrosoft Entra ID入門も参照してほしい。APIMとEntra IDを組み合わせると、サブスクリプションキーなしの完全トークンベース認証が実現できる。

レスポンスキャッシュ（Standard以上）

# inboundセクション（キャッシュ確認）
<cache-lookup vary-by-developer="false"
    vary-by-developer-groups="false" />

# outboundセクション（レスポンスをキャッシュ）
<cache-store duration="300" />
# duration: 秒単位。この例は5分間キャッシュ

読み取り頻度が高く変化の少ないAPIレスポンス（商品カテゴリ一覧・マスタデータなど）にはキャッシュが効果的だ。バックエンドへの負荷削減と応答速度改善を同時に実現できる。

リクエスト変換（バックエンドURL・ヘッダーの書き換え）

# inboundセクション
# APIMでは /api/v2/users に見せてバックエンドでは /internal/users に変換
<rewrite-uri template="/internal/users" />

# バックエンドへの秘密のAPIキーをヘッダーに付与
<set-header name="X-Internal-API-Key" exists-action="override">
    <value>{{internal-api-key}}</value>
</set-header>

ポリシーを組み合わせることで、バックエンドの実装を変えずにAPIの振る舞いをゲートウェイ層で柔軟に制御できる。ポリシーのスコープは「Global → Product → API → Operation」の4階層で管理でき、細かい粒度での適用が可能だ。

料金体系とコスト試算シナリオ

APIMの料金は主に「ユニット時間課金」で構成される（Consumptionのみ呼び出し数課金）。

コスト試算の具体例（2026年7月時点・東日本リージョン。詳細は公式料金ページで最新情報を確認すること）：

コスト最適化のポイントを3点挙げる。

・Consumptionの高トラフィック時のコスト逆転に注意: 月500万リクエストを超えるとConsumptionの従量課金がBasicの時間課金を上回ることがある。試算して比較すること
・キャッシュで呼び出し数を削減: Standard以上でキャッシュを活用すると、バックエンドへの転送数が大幅に減り、バックエンドの料金（Azure FunctionsやApp Serviceの実行コスト）も合わせて削減できる
・開発環境はDeveloper（またはConsumption）で共用: 本番APIMを開発テストで使うと無駄なコストがかかる。開発環境は別インスタンスで運用すること

よくある設計ミスとトラブル対処

【設計ミス1】バックエンドの直接アクセスを塞いでいない

APIMを導入しても、バックエンドのAzure App ServiceやAzure FunctionsへのIPアドレス制限を設定しないと、APIMのポリシーを完全に迂回した直接アクセスが可能なままになる。

対策: Azure App Serviceの「アクセス制限」でAPIMの送信IPアドレスからのみ許可に設定する。APIMのパブリックIPアドレスはAzureポータルの「Network」→「Public IP addresses」で確認できる。

【設計ミス2】全APIに同一ポリシーをGlobalスコープで適用する

Globalスコープ（すべてのAPIに適用）でレート制限を設定すると、影響範囲が広すぎて柔軟性が失われる。管理APIと公開APIで異なるレート制限が必要なケースは多い。

対策: ポリシースコープは「Global → Product → API → Operation」の4階層で管理できる。レート制限はProductレベルで設定し、サブスクリプションプランごとに差別化するのが典型的なパターンだ。

【設計ミス3】サブスクリプションキーをURLクエリに含める

`?subscription-key=xxxx` という形でURLにキーを含めると、アクセスログ・ブラウザ履歴・リファラーヘッダーにキーが露出する。

対策: `Ocp-Apim-Subscription-Key` リクエストヘッダーで渡す（APIMのデフォルト動作）。URLクエリへのキー渡しはAPIM側で設定可能だが、セキュリティ上は非推奨と認識しておくこと。

【設計ミス4】開発者ポータルを放置する

APIMには開発者ポータルが自動で作成されるが、社内向けAPIの場合、意図せず外部からAPIカタログを閲覧できる状態になっていることがある。

対策: 開発者ポータルの公開設定と認証（Entra ID連携など）を確認し、不要な場合はポータルのパブリックアクセスを無効化する。

【トラブル】フロントエンドSPAからCORSエラーが発生する

APIMをReact/VueなどのSPAのAPIゲートウェイとして使う場合、CORSポリシーの設定が必要だ。バックエンドのCORSヘッダーとAPIMのCORSポリシーが競合し、ブラウザが二重のCORSヘッダーを受け取ってエラーになるケースが多い。

対策: APIMのinboundポリシーにCORSポリシーを追加し、outboundポリシーでバックエンド側のCORSヘッダーを削除する。CORSの制御はAPIM側で完結させるのが原則だ。

本記事のまとめ

Azure API Managementは、単なるプロキシではなく「APIの統合管理基盤」として機能するサービスだ。

ティア選択は「Consumption（小規模・従量）→ Basic（低コスト本番）→ Standard（中規模・キャッシュ）→ Premium（VNet統合・エンタープライズ）」の軸で判断する。Developerティアは本番禁止であることを必ず押さえておこう。

ポリシーの組み合わせによって、バックエンドの改修なしにAPIの振る舞いをゲートウェイ層で制御できる点がAPIMの最大の特徴だ。まずConsumptionかDeveloperで試してポリシーの動作感を掴み、本番要件に合わせてティアを選定するのが実践的な進め方だ。

運用フェーズに入ったら、Azure Monitorとの連携でAPIのリクエスト数・レイテンシ・エラー率をアラート設定し、継続的な品質管理に役立ててほしい。