Azure API Managementとは？基本からメリット・使い方まで徹底解説！

Azure
2025.03.25

「Azure API Management（以下、APIM）」という名前は、Azureを触っていると必ず一度は目にします。ただ、公式の説明を読むと「APIゲートウェイ」「開発者ポータル」「ポリシー」といった言葉が並び、結局これは何をしてくれるサービスなのかが掴みにくい——最初にそう感じる人は多いはずです。

APIをいくつか作ったんだけど、公開するとなると認証やアクセス制限を毎回自前で書くのがしんどい…。APIMを挟むと何が楽になるの？

この記事は、そのモヤモヤを実際にAPIMを構築・運用した立場から解きほぐすことを目的にしています。私自身、Azure Functionsで作った複数のAPIを1つの窓口にまとめる場面や、社内でCodex（AIコーディングエージェント）をAzure経由で使うためにAPIMを挟む場面で、このサービスを実務投入してきました。教科書的な機能説明だけでなく、「実際どこで詰まるのか」まで含めて書いていきます。各セクションの末尾には「ここが説明できればOK」という自己チェックを置くので、理解度の確認にも使ってください。

APIMとは？ ひとことで言うと「APIの総合受付」

APIMは、APIを公開・管理・保護するためのAzureのマネージドサービス（PaaS）です。イメージとしては、バックエンドで動いている実際のAPI群と、それを使うクライアント（Webアプリ、モバイルアプリ、外部のパートナー）のあいだに立つ「総合受付」だと思ってください。

クライアントは、バックエンドのAPIに直接アクセスするのではなく、まずAPIMに来ます。APIMはそこで「あなたは誰か（認証）」「呼びすぎていないか（流量制御）」を確認し、問題なければ後ろのAPIへリクエストを流す。逆に言えば、認証・アクセス制限・ログ・キャッシュといった「どのAPIでも共通で必要になる面倒ごと」を、APIM側にまとめて肩代わりさせられる——これがAPIMを挟む一番の価値です。

APIが1本しかないうちは、正直この恩恵は薄いです。ありがたみが出てくるのは、APIが増えてきて「どのAPIがどこにあるのか」「誰がどれだけ使っているのか」が把握しきれなくなってきたとき。バージョン管理、アクセス権の管理、利用状況の可視化といった課題が同時多発するタイミングで、APIMという「1つの入口」に集約できることが効いてきます。

【ここが説明できればOK①】
「APIMは、クライアントとバックエンドAPIのあいだに立つAPIゲートウェイで、認証・流量制御・ログといった共通処理を肩代わりしてくれるPaaSである」——これを自分の言葉で言えれば、1つ目のチェックはクリアです。

APIMを構成する3つのプレーン

APIMは大きく3つの顔を持ちます。「実際にトラフィックを捌く部分（ゲートウェイ）」「APIを使う開発者向けの窓口（開発者ポータル）」「管理者が設定する部分（管理プレーン）」の3つです。ここを分けて理解しておくと、後の設定でどこを触っているのか迷いません。

① APIゲートウェイ — リクエストが必ず通る「門番」

ゲートウェイはAPIMの中核で、クライアントからのすべてのリクエストがここを通ります。単に後ろへ転送するだけでなく、通り道で認証・認可（APIキー、OAuth 2.0、JWT検証）、流量制御、リクエスト/レスポンスの変換、キャッシュ、ログ記録といった処理を挟み込めます。これらを個々のAPI側に実装せず、ゲートウェイに集約できるのがポイントで、後述する「ポリシー」がこの挙動を定義する仕組みです。

② 開発者ポータル — APIを使う人のための入口

開発者ポータルは、公開したAPIを利用する開発者向けのWebサイトです。ここではAPIのドキュメントが自動生成され、ブラウザ上で実際にAPIを叩いて動作を試せる「テストコンソール」も用意されます。開発者はポータルでサインアップし、APIを呼ぶためのサブスクリプションキーを受け取って利用を始めます。外部にAPIを公開するなら、この開発者ポータルの存在がそのまま「API提供者としての体裁」になります。逆に社内利用だけなら、ここはあまり使い込まないこともあります。

③ 管理プレーン — 管理者が設定する場所

管理プレーンは、Azureポータルやコマンドライン（Azure CLI、PowerShell）、あるいはIaC（Terraformなど）からAPIM自体を設定する部分です。APIの定義・インポート、ポリシーの適用、複数APIを束ねる「製品（Product）」の作成、ユーザー管理、監視設定などをここで行います。実務ではこの管理プレーンの操作を、後述するようにTerraformでコード化しておくのが定石です。

【ここが説明できればOK②】
「APIMはゲートウェイ（トラフィックを捌く）／開発者ポータル（APIを使う人の窓口）／管理プレーン（設定する場所）の3つで構成される」——これを言えれば2つ目クリアです。

【実例】複数のFunctionsを、APIMで1本のAPIに束ねる

ここで、私が実際にやった使い方を紹介します。機能ごとにAzure Functionsをいくつか立て、それらをAPIMで1つのAPIとしてまとめて公開する、という構成です。これはAPIMの典型的な使いどころで、いわゆるマイクロサービスの前段ゲートウェイ、あるいはBFF（Backend For Frontend）的な役割になります。

個別のFunctionは、それぞれ別々のURL（func-a.azurewebsites.net、func-b.azurewebsites.net…）を持っています。これをそのままクライアントに触らせると、呼ぶ側は「どの機能がどのURLか」を全部知っていなければならず、認証キーも機能ごとにバラバラになってしまう。ここでAPIMを前に置くと、クライアントから見える窓口は https://<サービス名>.azure-api.net/ の1つだけになります。/orders はFunction A、/inventory はFunction B、というように、パスごとに背後のFunctionへ振り分ける。クライアントは裏側に何本Functionがあるかを気にせず、1つのAPIを使う感覚で済みます。

この構成の何が嬉しいかというと、認証・流量制御・ログといった共通処理を、Functionごとに書かずにAPIMに一本化できる点です。各Functionはビジネスロジックだけに集中し、「誰が呼んでいいか」「呼びすぎていないか」の判断はAPIMのポリシーに任せる。Functionを1本追加したくなっても、APIM側でパスを1つ増やして紐づけるだけで、窓口の見え方は変わりません。実際にやってみると、この「窓口を1つに固定できる」効果は思っていた以上に運用を楽にしてくれました。

ちなみにAPIをインポートするとき、AzureポータルやTerraformからAzure Functions / App Service / Logic Apps を直接指定して取り込めるので、Functionの構成であれば連携はスムーズです。OpenAPI（Swagger）定義を持っていれば、それをインポートするのが一番きれいに入ります。

【ここが説明できればOK③】
「複数のFunctions（マイクロサービス）をAPIMの後ろに置くと、クライアントから見える窓口を1つに統一でき、認証・流量制御・ログをAPIM側に集約できる」——これを説明できれば3つ目クリアです。

一番ハマったのは「ポリシー」だった

APIMを触っていて、私が一番つまずいたのがポリシーの設定です。ポリシーは、ゲートウェイでリクエスト/レスポンスに対して行う処理（認証、流量制御、ヘッダー書き換え、キャッシュなど）を定義する仕組みで、APIMの柔軟さの核心でもあります。ただ、この柔軟さの裏返しで、最初は「どこに何を書けば効くのか」が本当に分かりにくい。

つまずきポイントを、実感した順に挙げておきます。同じ場所で悩む人は多いはずなので、ここは箇条書きで整理します。

  • ポリシーはXMLで書く。GUIのフォームもありますが、細かいことをやろうとすると結局XMLを直接編集することになります。ここで「コードで設定を書く」感覚に切り替わらないと戸惑います。
  • 書く「場所（スコープ）」が4段階ある。グローバル → 製品 → API → 操作、の順に階層があり、上位で書いたポリシーは下位にも継承されます。「効かないな？」と思ったら、上の階層で書いたつもりが下の階層に無かった、あるいはその逆、というのが最初の定番の詰まりでした。
  • <inbound> / <backend> / <outbound> / <on-error> の区別。「クライアントから受け取った直後（inbound）」に書くのか、「バックエンドへ渡す時（backend）」なのか、「レスポンスを返す直前（outbound）」なのか。認証や流量制御はinbound、レスポンスヘッダーの加工はoutbound、と用途で置く場所が決まっていて、間違った区画に書くと当然効きません。
  • <base /> の位置。これは「上位スコープから継承したポリシーをここで実行する」という差し込み口です。自分が書いたポリシーを <base /> の前に置くか後に置くかで、継承ポリシーとの実行順が変わる。ここを意識していないと、順番の問題で挙動が読めなくなります。

コツを一言でまとめると、「ポリシーは”どのスコープの・どの区画に・どの順で”書くか、の3点セットで考える」ということです。ここさえ腹落ちすれば、あとは rate-limit-by-key（流量制御）、validate-jwt（トークン検証）、set-header（ヘッダー操作）、cache-lookup（キャッシュ）といった個々のポリシーを組み合わせていくだけなので、一気に扱いやすくなります。逆に言うと、機能の一覧を暗記するより先に、この「場所と順序」の感覚を掴むのが最短ルートでした。

「スコープ（どこに）・区画（inbound等）・順序（base の前後）」の3点セット。ポリシーで迷ったらこれを思い出すと、大体は場所の問題だよ。

【ここが説明できればOK④】
「ポリシーはXMLで書き、グローバル→製品→API→操作の4スコープで継承され、inbound/backend/outbound/on-errorの区画と<base />の位置で実行順が決まる」——ここまで言えれば、ポリシーの土台は固まっています。

【実例】Codexをチームで使うためにFoundry + APIM

もう一つ、最近の実務での使い方を紹介します。社内でCodex（AIコーディングエージェント）をAzure経由で使うにあたり、Azure AI Foundry / Azure OpenAI の前にAPIMを挟む構成です。

AIコーディングツールをチームで共有すると、必ず「誰かが使いすぎてトークン（＝コスト）が想定外に膨らむ」という問題が出てきます。全員が同じキーで叩いていると、誰がどれだけ使ったのかも分からない。ここでAPIMを前段に置き、メンバーごとにサブスクリプションキーを発行し、キー単位でトークンのレート制限をかけることで、使用量の見える化と暴走の遮断を同時に実現できます。前段でポリシーを効かせる、というAPIMの本領がそのまま活きる構成です。

この「AIエージェントをチームで安全に共有する運用設計」については、トークン上限の算出ロジックやコスト試算まで含めて別記事で詳しく書いています。APIMのポリシー（llm-token-limit）を実際にどう組むかまで踏み込んでいるので、AI×Azureの文脈で読みたい方はあわせてどうぞ。

➡️ Codex / Claude Codeをチームで安全に使う｜Azure APIM + AI Foundryでレート制限（トークン上限）を設計する

APIMを使うメリット（実務目線で3つ）

機能を延々と並べるより、実際に使って「これは効く」と感じた点を3つに絞ります。

1つ目は、共通処理の一本化です。 認証・流量制御・ログ・キャッシュを、APIごとに実装せずAPIMのポリシーに寄せられる。これはFunctionsを束ねた実例で書いたとおりで、バックエンド側のコードがビジネスロジックだけになり、シンプルに保てます。

2つ目は、セキュリティの集約です。 APIキー、OAuth 2.0、Microsoft Entra ID連携、JWT検証、IP制限といったアクセス制御を、前段のAPIMで一括してかけられます。通信はクライアント〜ゲートウェイ間、ゲートウェイ〜バックエンド間ともにTLSで暗号化され、Web攻撃対策はWAF（Application Gateway等）と組み合わせて強化できます。「守りの入口を1つにできる」というのは、運用上とても安心感があります。

3つ目は、公開と可視化のしやすさです。 開発者ポータルでドキュメントを自動生成し、外部にAPIを公開する体裁が整う。利用状況はダッシュボードやApplication Insightsで追え、「誰がどれだけ使っているか」が見えるようになります。前述のCodexの例のように、キー単位で使用量を把握したいケースでは、この可視化がそのまま制御の土台になります。

料金プランは「まず小さく、必要になったら上げる」

APIMには複数の価格レベル（サービス階層）があります。細かい金額は変動するので最新は必ず公式の料金ページで確認してほしいのですが、選び方の考え方は変わりません。ざっくり「どれを選べばいいか」を表にまとめます。

階層向いている用途ポイント
Consumptionお試し・小規模・サーバーレス呼び出し回数ベースの従量課金。VNet統合など高度な機能は不可。まず触るならここ
Developer開発・学習・検証機能は豊富だがSLAなし。本番非推奨。ポリシーの検証環境として優秀
Basic小規模の本番SLAあり。機能とコストのバランス型エントリー
Standard中規模の本番Basicより機能・スループットが上。VNet統合の一部に対応
Premium大規模・ミッションクリティカルマルチリージョン、完全なVNet統合、セルフホストゲートウェイ。高SLA

実務での基本方針はシンプルで、「まずConsumptionかDeveloperで作り、ポリシーの検証を済ませてから、本番要件（SLA・VNet統合・可用性）に合わせて上位へ移す」という進め方が失敗しにくいです。特にVNet統合やマルチリージョンが要るかどうかで、Standard以上／Premiumの線引きが決まります。最初からPremiumを選んで持て余す、というのが一番もったいないパターンです。

なお、Consumption以外は時間単位の固定料金（インスタンス料金）がかかり、スケールアウト（ユニット追加）すると増えます。加えて送信データ転送量が別途かかる点も頭に入れておきましょう。

Terraformで作るのが実務の定石

デプロイ手順は、Azureポータルからでも作れます。「リソースの作成」でAPI Managementを選び、サブスクリプション・リソースグループ・リージョン・リソース名・組織名・管理者メール・価格レベルを設定すれば、あとはAzureがインスタンスを立ててくれます。ただデプロイ完了までは階層によって数十分かかることがある（ConsumptionやDeveloperは比較的速い）ので、そこは待つものだと思っておいてください。ここは最初ちょっと面食らうポイントです。

とはいえ、実務ではポータルのポチポチではなくIaC（Terraform）でコード化しておくのが定石です。再現性が出ますし、ポリシーやAPI定義まで含めてGitで管理できます。最小構成のインスタンス作成はこれだけです。

resource "azurerm_resource_group" "rg" {
  name     = "rg-apim-demo"
  location = "japaneast"
}

resource "azurerm_api_management" "apim" {
  name                = "apim-demo-0303"          # 世界で一意（*.azure-api.net になる）
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  publisher_name      = "AIT Engineer"            # 開発者ポータルに表示される組織名
  publisher_email     = "admin@example.com"       # 通知先メール
  sku_name            = "Developer_1"             # 例: Developer層×1ユニット。本番はStandard_1 等
}

ポリシーもTerraformで管理できます。たとえばAPI単位で「サブスクリプションキーごとに、60秒間に10回まで」という流量制御を入れるなら、azurerm_api_management_api_policy にXMLを渡します。ここで、先ほど説明した「区画（inbound）」と「<base /> の位置」がそのまま出てきます。

resource "azurerm_api_management_api_policy" "example" {
  api_name            = azurerm_api_management_api.example.name
  api_management_name = azurerm_api_management.apim.name
  resource_group_name = azurerm_resource_group.rg.name

  xml_content = <<XML
<policies>
  <inbound>
    <base />
    <rate-limit-by-key calls="10" renewal-period="60"
      counter-key="@(context.Subscription.Id)" />
  </inbound>
  <backend><base /></backend>
  <outbound><base /></outbound>
  <on-error><base /></on-error>
</policies>
XML
}

この <inbound> の中に流量制御を書いている点、そして4つの区画がそれぞれ <base /> を持っている点に注目してください。記事の前半で「ポリシーは場所と順序」と書いた話が、コードにするとこうして目に見える形になります。ポリシーの構造が腹落ちしていれば、このXMLはもう怖くないはずです。

APIを取り込むときは、OpenAPI（Swagger）定義のインポートが一番きれいに入ります。手元のFunctionsやApp Serviceなら、Azureリソースとして直接インポートも可能です。取り込んだあとは、APIを「製品（Product）」に紐づけ、その製品を「公開済み」にして、サブスクリプションを有効化する——ここまでやって初めて、開発者ポータルからキーを取得して呼べる状態になります。

まとめ

APIMは、複数のAPIを1つの窓口に集約し、認証・流量制御・ログといった共通処理を前段に肩代わりさせるためのAPIゲートウェイです。APIが1本のうちは恩恵は薄いですが、Functionsを何本も束ねる場面や、AIエージェントをチームで共有する場面のように「入口を1つにして、そこで制御をかけたい」ケースで真価を発揮します。

触ってみて一番の勘所はポリシーでした。「どのスコープに・どの区画に・どの順序で書くか」——ここさえ掴めば、あとは個々のポリシーを組み合わせるだけです。まずはConsumptionかDeveloperで小さく作り、Terraformでコード化しながらポリシーを試す。このやり方が、APIMと仲良くなる一番の近道だと思います。

タイトルとURLをコピーしました