Azure API Management（APIM）は、社内外に公開するAPIを一元的に管理するための、Microsoft AzureのフルマネージドなAPIゲートウェイです。この記事では、APIMでできることとApplication Gatewayとの違い、東日本リージョンの時間単価から計算したティア別の月額、Azure CLIとBicepでの作成からポリシー設定・公開までの手順を、2026年10月時点の公式情報で解説します。「Azure management」でAzure全体の管理機能を探していた方向けに、管理グループやAzure Resource Managerとの切り分けも1章設けました。
まとめ：APIMの要点と料金ティアの選び方
APIMは「APIの受付窓口」を一枚かぶせるサービスです。バラバラに作ったAPIを1つのエンドポイントに集約し、認証やレート制限をコードから切り離してゲートウェイ側で適用できます。
ティアの目安は、検証ならDeveloper（東日本で月約48ドル）、小さな本番はBasic v2（月約150ドル）かStandard v2（月約700ドル）、閉域と可用性ゾーンが要るならPremium系です。2026年10月時点で東日本はPremium v2に未対応で、国内で完全閉域を組むならclassicのPremiumになります。なおaz apim createはv2ティアを指定できないため、v2はBicepかポータルで作ります。
Azure API Management（APIM）とは：APIの手前に置くゲートウェイ
APIMは、APIの公開・保護・監視・分析を一括で行うAPI管理プラットフォームです。クライアントとバックエンド（Azure FunctionsやAKS、オンプレミスのAPIなど）の間に立ち、リクエストを転送しながら、その通り道で認証・流量制御・変換を適用します。
名前に「Management」と付くものの、実体はリクエストが必ず通るゲートウェイです。だからこそ認証やレート制限を1か所で強制でき、バックエンドのコードを汚さずに横断的なルールを当てられます。製品に依存しないAPI管理の考え方はAPI管理（APIマネジメント）の仕組みと構成要素の解説で、ゲートウェイ単体の役割はAPIゲートウェイとリバースプロキシの違いで整理しています。
Azure managementとAPI Managementの違い：管理グループとARM
「azure management」という検索語は2つの別物を指します。1つはこの記事の主題であるAPI Management、もう1つはサブスクリプションやリソースを統制するAzure全体の管理機能です。
ARMの4階層の管理スコープ：管理グループから個別リソースまでの継承
Azure Resource Manager（ARM）の公式概要によると、ポータル・Azure CLI・REST API・SDKのどこから送った要求も、ARMが認証と認可を済ませてから各サービスへ渡します。管理のスコープは管理グループ・サブスクリプション・リソースグループ・リソースの4階層で、上位の設定は下位へ継承される仕組みです。管理グループの公式ドキュメントでは、1ディレクトリあたり1万個まで、深さはルートとサブスクリプションを除いて6段までと定められています。
API Managementが受け持つ範囲：Azureの統制ではなくAPI呼び出しの統制
APIMが統制するのは「誰がどのAPIを何回呼べるか」というデータの通り道です。リソースの作成・削除権限はARMとAzure RBACが受け持ちます。実務では、APIMインスタンスの作成権限をリソースグループ単位のロールで絞り、APIの利用権限をサブスクリプションキーやJWT検証で絞る二重の線引きをする構成です。オンプレミスのサーバーまでARMの管理下に入れたい場合はAzure Arcの料金と導入手順が該当します。
API管理（APIM）でできること：認証・流量制御・キャッシュ・監視の5領域
APIを2〜3本だけ社内で使うなら、管理基盤は要りません。効いてくるのは、API本数が増えて「誰がどのAPIをどれだけ叩けるか」を制御したくなったときです。
| 領域 | できること |
|---|---|
| 認証・認可 | サブスクリプションキー・OAuth・JWT検証 |
| 流量制御 | レート制限・クォータ・スロットリング |
| 性能 | レスポンスキャッシュ・負荷分散 |
| 提供 | 開発者ポータルでドキュメント・キー発行 |
| 監視 | 利用状況の分析・ログ・アラート |
これらを各バックエンドへ個別に実装すると重複だらけになります。認証の既定はサブスクリプションキーで、サブスクリプションの公式解説のとおり、呼び出し側はOcp-Apim-Subscription-Keyヘッダーでキーを渡します。有効なキーが無い要求はゲートウェイが401で拒否し、バックエンドへは届きません。ここでの「サブスクリプション」はAzureの課金単位とは別物です。
APIMの構成要素：APIゲートウェイ・開発者ポータル・管理プレーンの分担
APIゲートウェイは、すべてのリクエストが通る実行エンジンで、ここでポリシー（後述）が適用されます。開発者ポータルはAPIを使う側の入口で、仕様書やサンプル、キーの取得画面を提供するものです。管理プレーン（旧パブリッシャーポータル相当）は、API提供者が登録・公開・監視を行う面で、AzureポータルやBicep、REST APIから操作します。
Application Gatewayとの違い：WAFを前段・APIMを後段に置く併用構成
「Azure ◯◯ Gateway」が複数あるため、APIMとApplication Gatewayはよく混同されます。結論は、レイヤーと目的が異なるので競合せず、前段後段で併用することが多い、です。
| 項目 | API Management | Application Gateway |
|---|---|---|
| 主目的 | APIの管理・公開・保護 | Webトラフィックの負荷分散 |
| レイヤー | L7（API単位） | L7（HTTP/URL単位） |
| 強み | 認証・流量制御・開発者ポータル | WAF・ルーティング・SSL終端 |
WAFで境界を守り、その内側でAPI単位の認証や流量制御をかけるなら、Application Gatewayを前段、APIMを後段に置きます。APIMを直接叩かせないには、VNetへの配置（Developer・Premium・Premium v2）か、受信のプライベートエンドポイント（Basic v2以外）で経路を絞る構成です。WAFの詳細はAzure Application Gatewayの構築手順の解説記事で扱っています。
APIMの料金プラン：東日本リージョンの月額目安とティア別の機能差
APIMには従来からのclassicティア（Developer・Basic・Standard・Premium）とConsumption、新世代のv2ティア（Basic v2・Standard v2・Premium v2）があります。
東日本リージョンの時間単価から計算した月額の目安：8ティア比較
公式の価格ページは金額がスクリプトで描画されるため、Azure Retail Prices APIから東日本の小売価格を2026年10月3日に取得し、1ユニット730時間で月額に換算しました。米ドル・税別の参考値です。
| ティア | 時間単価 | 月額の目安 | 含まれるコール |
|---|---|---|---|
| Consumption | なし（従量のみ） | 使った分だけ | 月100万まで無料 |
| Developer | 0.0658ドル | 約48ドル | 課金なし |
| Basic | 0.2016ドル | 約147ドル | 課金なし |
| Basic v2 | 0.20548ドル | 約150ドル | 1,000万 |
| Standard | 0.9407ドル | 約687ドル | 課金なし |
| Standard v2 | 0.9589ドル | 約700ドル | 5,000万 |
| Premium | 3.829ドル | 約2,795ドル | 課金なし |
| Premium v2 | 3.83562ドル | 約2,800ドル | 無制限 |
超過単価は1万コールあたり、Consumptionが0.0425ドル、Basic v2が0.03ドル、Standard v2が0.025ドルです。月500万コールならConsumptionは約17ドルに収まり、Standard v2で月1億コールなら約825ドルになります。classicティアはコール課金が無い代わりに、ユニットの処理能力が上限です。呼び出し料金だけならConsumptionは月約9,900万コールまでBasic v2より安い計算で、それでも本番でBasic v2以上を選ぶ理由は次の機能差にあります。
ティア選びで効く機能差：VNet・可用性ゾーン・セルフホステッドゲートウェイ
ティア別の機能比較表（2026年6月版）から、選定を左右する項目を抜き出しました。
| ティア | VNetへの配置 | 可用性ゾーン | 開発者ポータル | 組み込みキャッシュ |
|---|---|---|---|---|
| Consumption | 不可 | 不可 | なし | なし |
| Developer | 可（SLAなし） | 不可 | あり | 10MB |
| Basic v2 | 不可 | 不可 | あり | 250MB |
| Standard v2 | 送信側の統合のみ | 不可 | あり | 1GB |
| Premium | 可 | 可 | あり | 5GB |
| Premium v2 | 可 | 可 | あり | 5GB |
Consumptionは開発者ポータルが無く、Entra ID連携やLog Analyticsへの要求ログ送信にも対応しません。社外へAPIを配る用途やログ監査が要る業務では、安くても候補から外れます。Standard v2の「送信側の統合」は、VNet内のバックエンドへは届くが、ゲートウェイ自体は公開されたままという意味です。オンプレミスにゲートウェイを置くセルフホステッドゲートウェイは、DeveloperとclassicのPremiumだけが対応しています。
v2ティアの制約：classicからのアップグレード不可と東日本の対応状況
v2ティアの公式概要（2026年9月4日更新）では3ティアともGAで、Premium v2は2025年11月のGA発表で受信のPrivate Linkと可用性ゾーンに対応しました。一方、classicからv2へのアップグレード手段は無く、移るには新規作成が必要です。バックアップと復元・マルチリージョン展開・セルフホステッドゲートウェイ・固定IPもv2では使えません。
v2ティアの提供リージョン表（2026年9月28日更新）では、東日本はBasic v2とStandard v2のみ対応で、Premium v2は対象外です。価格APIには単価が載っていても、作成できるかはこの表で確かめてください。
APIMの使い方：Azure CLIでインスタンス作成からAPI公開までの手順
流れは「インスタンス作成 → API登録 → 製品にまとめて公開 → ポリシー設定 → 監視」です。CLIを入れたくない場合はAzure Cloud Shellの使い方の手順でブラウザから同じコマンドを実行できます。
az apim createでDeveloperを作成する手順と30〜40分の所要時間
CLIのクイックスタートに沿って、東日本にDeveloperティアを作ります。名前はゲートウェイのホスト名になるため、Azure全体で一意にします。
az group create --name rg-apim-sample --location japaneast
az apim create --name apim-sample-0001 --resource-group rg-apim-sample \
--publisher-name "Example Inc." --publisher-email [email protected] \
--sku-name Developer --no-wait
# 状態が Activating から Online になるまで待つ
az apim show --name apim-sample-0001 --resource-group rg-apim-sample --output tableDeveloperは有効化まで30〜40分かかるため、--no-waitで先に制御を返しています。az apimのリファレンスでは、--sku-nameの値はBasic・Consumption・Developer・Isolated・Premium・Standardの6つで、v2ティアは含まれません。
OpenAPI定義をaz apim api importで取り込み製品に追加する手順
Onlineになったら、手元のOpenAPI定義を取り込みます。az apim apiのリファレンスのとおり、形式はOpenApi・OpenApiJson・Swagger・Wadl・Wsdl・GraphQLから選びます。
az apim api import --resource-group rg-apim-sample --service-name apim-sample-0001 \
--api-id orders --path orders --display-name "Orders API" \
--specification-format OpenApi --specification-path ./openapi.yaml \
--service-url https://orders-backend.example.com
az apim product create --resource-group rg-apim-sample --service-name apim-sample-0001 \
--product-id partner --product-name "Partner" \
--subscription-required true --state published
az apim product api add --resource-group rg-apim-sample --service-name apim-sample-0001 \
--product-id partner --api-id orders
# 発行したキーで呼び出しを確認する
curl -H "Ocp-Apim-Subscription-Key: <キー>" \
https://apim-sample-0001.azure-api.net/orders/healthaz apim productのリファレンスでは--stateの既定がnotPublishedで、publishedにしないと開発者ポータルの一覧に出ません。キー自体を発行・確認するサブコマンドはaz apimに無いため、Azureポータルの「サブスクリプション」画面で取得します。バックエンドにはAzure FunctionsやAzure Container Appsがよく組み合わされます。
v2ティアをBicepで作成する方法：CLIのsku-nameがv2に未対応のため
v2ティアは、Microsoft.ApiManagement/serviceのテンプレートリファレンスでsku.nameにBasicV2・StandardV2・PremiumV2を指定して作ります。v2の機能はAPIバージョン2024-05-01以降で扱えると公式概要にあるため、そのバージョンを使います。
// main.bicep
param location string = resourceGroup().location
resource apim 'Microsoft.ApiManagement/service@2024-05-01' = {
name: 'apim-sample-v2-0001'
location: location
sku: {
name: 'StandardV2'
capacity: 1
}
properties: {
publisherEmail: '[email protected]'
publisherName: 'Example Inc.'
}
}az deployment group create --resource-group rg-apim-sample --template-file main.bicepBicepの基本はAzure Bicepのインストールからデプロイまでの手順で、Terraformで管理する場合はTerraformでAzureを構築する手順で扱っています。
ポリシーでできること：レート制限・JWT検証・キャッシュをXMLで設定する方法
APIMの中核はポリシーです。ゲートウェイ上でリクエスト/レスポンスに適用するXMLベースのルールで、バックエンドを変えずに振る舞いを足せます。適用範囲はグローバル・製品・API・操作の順に絞れ、下位で<base />を書くと上位の設定を引き継ぐ仕組みです。
rate-limit-by-keyでIPアドレス単位に1分10回へ制限する設定例
IPアドレス単位で1分10回までに絞るには、rate-limit-by-keyポリシーを次のように書きます。
<inbound>
<base />
<rate-limit-by-key calls="10" renewal-period="60"
counter-key="@(context.Request.IpAddress)" />
</inbound>上限を超えた呼び出しには429が返り、バックエンドへは転送されません。
validate-jwtでEntra IDのアクセストークンを検証する設定例
サブスクリプションキーで分かるのは「どのアプリか」までです。利用者単位で認可するなら、validate-jwtポリシーでMicrosoft Entra IDのトークンを検証します。
<inbound>
<base />
<validate-jwt header-name="Authorization" failed-validation-httpcode="401"
failed-validation-error-message="Unauthorized. Access token is missing or invalid.">
<openid-config url="https://login.microsoftonline.com/contoso.onmicrosoft.com/v2.0/.well-known/openid-configuration" />
<audiences>
<audience>api://orders-api</audience>
</audiences>
</validate-jwt>
</inbound>署名鍵はopenid-configのURLから1時間ごとに取得されキャッシュされます。VNet内に置いて外部DNSが引けない構成では、validate-connectivity="false"で接続確認を止めてください。アプリ登録の考え方はMicrosoft Entra ID（旧Azure AD）の解説を参照できます。接続文字列やキーはポリシーに直書きせず「名前付き値」に置き、実体をAzure Key Vaultから参照させると、ローテーション時にポリシーを触らずに済みます。
APIMの利用シナリオ：マイクロサービス集約・パートナー公開・AI Gateway
1つ目はマイクロサービスの集約で、複数サービスのAPIを1エンドポイントに束ねて認証とレート制限を一括で当てます。基盤にAKS（Azure Kubernetes Service）を使う構成と相性の良い領域です。2つ目は社外パートナー向けの公開で、開発者ポータルでドキュメントとキーを配り、製品単位でアクセス範囲を制御します。3つ目が生成AIのモデルを束ねるAI Gateway用途です。
llm-token-limitで生成AIのトークン消費を部門別に制限する設定例
Azure OpenAIなどをAPIMの後ろに置くと、モデルのキーを部門に配らずに済み、トークン消費もゲートウェイで抑えられます。llm-token-limitポリシーの公式リファレンス（2026年4月版）では、OpenAIのChat Completions・Responses API、Anthropic Messages API（v2ティアのみ）、Google Vertex AIのスキーマに対応し、Consumptionティアは対象外です。
<inbound>
<base />
<llm-token-limit counter-key="@(context.Subscription.Id)"
tokens-per-minute="5000"
token-quota="1000000" token-quota-period="Monthly"
estimate-prompt-tokens="false" />
</inbound>部門に発行したキーごとに毎分5,000トークン、月100万トークンを上限にする例です。毎分の上限を超えると429、月間の上限では403が返ります。同時に投げられた要求は一時的に上限を超えうると公式に明記されているので、厳密な予算管理には余裕を持たせた値にしてください。モデルと料金はAzure OpenAI Serviceの解説で、部門別の利用量はログをAzure MonitorとLog Analyticsへ送って集計できます。
APIMを採用すべき条件と見送る場面：API本数・利用者数・閉域要件で判断
月額のほかに、ポリシーの保守と、ゲートウェイを1段挟むことによる障害点の増加がコストとして乗ります。判断を条件で言い切ります。
採用する条件：社外公開・複数チーム・生成AIの共用のいずれかに該当
社外にAPIを配るなら採用します。キー発行・流量制限・ドキュメントを自前で作ると、それだけで小さなシステム1本分の工数になるためです。社内でも提供チームと利用チームが3つ以上に分かれ、利用量を請求や障害調査で説明する必要があるなら、分析とログで元が取れます。生成AIのモデルを複数部門で共用する場合も、キー秘匿とトークン上限のためだけに入れる価値があります。
見送る場面：単一アプリ専用のAPIとミリ秒単位の低遅延が最優先の処理
フロントエンドとバックエンドが1対1でつながるだけのAPIには入れません。認証はApp Serviceなどの組み込み認証、流量制御はWAFで足ります。ミリ秒単位で応答を詰める処理も、利点より遅延が勝ります。
よくある失敗は、閉域要件を後から知ってティアを選び直すパターンです。Basic v2は受信のプライベートエンドポイントにもVNetにも対応しません。東日本ではPremium v2も未対応なので、完全閉域が後から要件に入るとリージョンかティア系統の選び直しになります。閉域の要否は作成前に確定させてください。他社クラウドと比べて選ぶならGoogle CloudのApigeeの仕組みと料金が材料になります。
APIの設計から既存システムとの連携、ゲートウェイ構成の選定までをまとめて任せたい場合は、一創のAPI開発・システム連携サービスでご相談を受け付けています。
よくある質問
Azure API Managementの検討時によく寄せられる質問をまとめました。
Azure API Managementとは何ですか？
APIを公開・保護・監視するためのフルマネージドなAPIゲートウェイです。クライアントとバックエンドの間に立ち、認証・レート制限・キャッシュ・変換といった共通処理をゲートウェイ側で適用します。複数のAPIを1つの窓口に集約し、バックエンドを変えずに横断的なルールを効かせられる点が特徴で、APIゲートウェイ・開発者ポータル・管理プレーンの3つで構成されます。
APIMの料金プランはどれを選べばいいですか？
検証ならSLAのないDeveloper（東日本で月約48ドル）、小さな本番はBasic v2（月約150ドル・1,000万コール込み）、VNet内のバックエンドへつなぐ本番はStandard v2（月約700ドル・5,000万コール込み）が目安です。受信まで閉じる構成はPremium系ですが、東日本のPremium v2は2026年10月時点で未対応となっています。金額は2026年10月3日の価格APIの値なので、公式の価格ページで最終確認してください。
API ManagementとApplication Gatewayの違いは何ですか？
APIMはAPIの管理・公開・保護に特化し、Application GatewayはWebトラフィックの負荷分散とWAFに特化します。レイヤーと目的が異なるため競合せず、WAFのApplication Gatewayを前段、API制御のAPIMを後段に置く併用が一般的です。APIMを外部から直接呼べないようにするには、VNetへの配置かプライベートエンドポイントに対応したティアを選びます。
「Azure management」とAPI Managementは同じものですか？
別物です。「Azure management」はAzure Resource Managerや管理グループ、Azure Policy、RBACなど、サブスクリプションとリソースを統制するAzure全体の管理機能を指して使われます。API Managementはその上で動く1サービスで、APIの呼び出しを統制するものです。複数サブスクリプションに一括でポリシーを当てるなら管理グループ、APIの利用者と流量を制御するならAPIMが答えになります。
APIMに無料プランはありますか？
恒久的に無料の本番ティアはありません。Consumptionティアは月100万コールまで料金がかからず、超過分は東日本で1万コールあたり0.0425ドルです。ただし開発者ポータルやEntra ID連携が無いため、全機能を試すならDeveloperティア（月約48ドル・SLAなし）を使い、本番にはBasic v2以上を選ぶのが基本です。
関連記事
- API管理とは？APIマネジメントの仕組み・構成要素とゲートウェイとの違いを実装者向けに解説【2026年】：製品に依存しないAPI管理の全体像
- Azure Application Gatewayとは？L7負荷分散・WAF・料金とv2の構築手順【2026年版】：APIMの前段に置くWAF
- Apigeeとは？Google CloudのAPI管理プラットフォームの仕組み・料金・導入判断を実装者向けに解説【2026年】：他社クラウドのAPI管理
- AKS（Azure Kubernetes Service）とは｜できること・料金・始め方を解説【2026年版】：APIMの背後のマイクロサービス基盤
