Microsoft AZ-204: Azure API Management — 学習ガイド

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

こちらの一部です： Microsoft Azure Developer Associate AZ-204 — 学習ガイド. 検証済みの解答で練習： Microsoft試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

Azure API Management (APIM) は、多様なバックエンドサービスに対する統一されたファサードを提供し、高性能なゲートウェイ、設定可能なポリシーエンジン、開発者オンボーディング、そして完全な管理プレーンを組み合わせたものです。これにより、REST、SOAP、GraphQL の各バックエンド全体で、一貫したセキュリティ、スロットリング、変換、可観測性、ライフサイクル管理が可能になります。APIM は、トラフィックのランタイムゲートウェイであると同時に、Azure portal、ARM/Bicep/CLI、または CI/CD を介して管理する構成駆動型のシステムでもあります。リクエストパイプライン、ポリシー機能、バージョン/リビジョン、サブスクリプションモデル、レベルの特性を理解することは、堅牢で安全な API を大規模に構築するための基本です。

アーキテクチャ、レベル、およびコアコンポーネント

ゲートウェイはデータプレーンです。クライアント接続を終端し、決定論的な順序でポリシーを適用し、バックエンドにルーティングして、応答を返します。組み込みのキャッシュ、JWT 検証、相互 TLS、コンテンツ変換をラインレートでサポートします。ゲートウェイは、リージョンごとに Microsoft がホストすることも、自己ホスト型（コンテナ化）にしてオンプレミスやエッジのワークロードの近くで実行しつつ、一元管理を維持することもできます。ゲートウェイはトレースとメトリクスを公開し、分散テレメトリのために Application Insights と統合します。

開発者ポータルは、API の発見、ドキュメント、サブスクリプション管理のための、コンシューマー向けの体験を提供します。OpenAPI/GraphQL ドキュメントをレンダリングし、インタラクティブな「試用」コンソールを提供し、ブラウザ内で OAuth 2.0 フローを処理し、カスタムブランディングと ID プロバイダーをサポートします。開発者はここで製品のサブスクリプションをセルフサービスで取得し、キーをローテーションします。

管理プレーンは、構成とガバナンスのインターフェースです。API、操作、ポリシー、製品、ユーザー/グループ、バックエンド、証明書、診断設定を保存します。Azure portal、ARM/Bicep/CLI/PowerShell、Management REST API、Git ベースの構成同期を介してアクセスできます。このプレーンは、デプロイ、バージョン管理、リビジョン、RBAC を調整します。

APIM のレベルは、スケール、機能、ネットワーク能力を決定します：

Consumption はサーバーレスで、呼び出しごとに課金されます。自動でスケールし、スパイク状の/低スループットのシナリオに最適で、ほとんどのコアポリシーをサポートします。組み込みの応答キャッシュは含まれず、高度なネットワーク機能やマルチリージョン機能がありません。
Developer は非本番環境向けです。SLA なし、本番規模のスループットなしで、ほぼすべての機能を提供します。
Basic と Standard は、予測可能なスループット、スケールアウトユニット、組み込みの応答キャッシュを備えた、専用の単一リージョン本番環境向けレベルです。マルチリージョンや高度なネットワークを必要としない多くのエンタープライズワークロードに適しています。
Premium は、マルチリージョンデプロイ、高度なネットワーク（VNet 統合を含む）、より高いスケール、サポートされているリージョンでの可用性ゾーン、自己ホスト型ゲートウェイのライセンスを追加します。グローバルなミッションクリティカルなデプロイやプライベートネットワークには Premium を選択します。

ポリシーとリクエストパイプライン

APIM ポリシーは、受信 (inbound)、バックエンド (backend)、送信 (outbound)、エラー時 (on-error) の4つのセクションにわたって厳密な順序で実行される宣言的なステートメントです。

受信ポリシーは、リクエストがバックエンドに転送される前に実行されます。主なタスクには、サブスクリプションキーの要求または検証、JWT の検証（発行者、オーディエンス、署名の強制）、クライアント IP のチェック、レート制限とクォータの適用、ヘッダーの正規化、URI の書き換え、ペイロードの変換などがあります。条件に応じて異なるバックエンドにルーティングしたり、後のステージで使用する変数を設定したりできます。

バックエンドセクションでは、アップストリームサービスへの呼び出しを構成および変更します。バックエンドエンティティの選択、クライアント資格情報（Basic 認証、クライアント証明書、または Azure AD で保護されたバックエンドのためのマネージド ID 経由で取得したトークン）の添付、タイムアウトの設定、リトライの有効化、サーキットブレーカーの適用に使用します。バックエンドへの相互 TLS は、ゲートウェイが提示するクライアント証明書を関連付けることで、ここで構成されます。

送信ポリシーは、バックエンドの応答を受信した後に実行されます。一般的に、応答の変換（例：JSON から XML、またはその逆）、ヘッダーの書き換え、データシェーピング、内部詳細のマスキング、応答のキャッシュなどを行います。ここは、コンテンツネゴシエーションによる変換を適用したり、ステータスコードを正規化したりする場所でもあります。

エラー時ポリシーは、バックエンド呼び出しを含む、それ以前のセクションで例外が発生した場合に実行されます。このセクションを使用して、バックエンドのエラーを標準化された API エラーの形式にマッピングし、適切なステータスコードを設定し、機密メッセージを編集し、相関 ID を追加し、フォールバック応答を提供します。

一般的なポリシーパターン：

レート制限は、バーストスループットを制御し、バックエンドを保護します。rate-limit-by-key は、サブスクリプションキー、JWT クレーム、IP などのキーを使用して、ID ごとのスロットルを強制します。より長い期間に対しては、quota-by-key と組み合わせて、日次または月次の使用量を制限します。
IP フィルタリングは ip-filter を使用して、クライアント IP または CIDR 範囲に基づいてトラフィックをブロックまたは許可します。コストと露出を最小限に抑えるため、多くの場合、受信セクションの早い段階に配置されます。
validate-jwt による JWT 検証は、OpenID Connect のパラメータを強制します。OpenID 構成 URL または発行者を構成し、受け入れられるオーディエンス/スコープを定義し、必須のクレームを選択し、クロックスキューとトークンの有効期間チェックを調整します。匿名呼び出しが許可されていないすべての操作に対して有効なトークンを要求することで、匿名アクセスを拒否します。
変換には rewrite-uri、set-header、set-query-parameter、set-body、find-and-replace が含まれます。xml-to-json または json-to-xml を使用して、コードを変更することなく、クライアントとバックエンドの不一致なフォーマットを橋渡しします。
キャッシュでは cache-lookup と cache-store を利用して、パス、クエリ、ヘッダー、JWT クレームを含むことができるキーに基づいて、応答全体をキャッシュします。トークンのキャッシュなど、ポリシー内でキー/バリューをキャッシュするには cache-lookup-value/cache-store-value を使用します。Consumption レベルでは、組み込みの応答キャッシュは利用できないことに注意してください。

セキュリティ、ID、サブスクリプション

フロントエンドのクライアントからゲートウェイへのセキュリティと、バックエンドのゲートウェイからサービスへのセキュリティの両方に対処する必要があります。

フロントエンドのセキュリティでは、Azure AD を使用した OAuth 2.0 が主要なパターンです。クライアントは Azure AD からトークンを取得し、ゲートウェイに提示します。APIM は、Azure AD の OpenID Connect メタデータ (テナントの well-known エンドポイント) を参照する validate-jwt を使用して、トークンの要件を強制します。ポリシーは、トークンが正しい API を対象としていることを確認するための audience (対象者) チェック、呼び出し元が適切な権限を持っていることを確認するための scope (スコープ) クレーム、およびアプリロールなどのオプションのクレームを強制できます。匿名呼び出しを排除するため、validate-jwt はすべての操作に適用する必要があります。開発者ポータルは Azure AD で構成でき、テスト中のトークン取得を簡素化します。

クライアント証明書と相互 TLS (mTLS) については、APIM は呼び出し元からのインバウンドクライアント証明書を要求し、validate-client-certificate を使用して発行者/サブジェクト/有効期限、およびオプションで CRL/OCSP ステータスを検証できます。これは、B2B や高保証のインテグレーションに適しています。ゲートウェイからバックエンドへの mTLS の場合、クライアント証明書を APIM にアップロードし、それをバックエンドエンティティまたは set-backend-service に関連付けます。すると APIM は、TLS ハンドシェイク中にそれを提示してバックエンドに対して認証を行います。このアプローチは、セキュリティで保護された App Service や、証明書認証を強制するカスタムサービスでしばしば要求されます。

Azure AD で保護されたバックエンドの場合、backend セクションで authentication-managed-identity を使用して、APIM のシステム割り当てまたはユーザー割り当てのマネージド ID でアクセストークンを取得します。このポリシーは、バックエンド呼び出しのために Authorization ヘッダーを挿入します。これにより、シークレットの保存が不要になり、最新のゼロトラスト要件を満たすことができます。

サブスクリプションは、粒度の粗いアクセスおよび収益化モデルを提供します。製品 (Product) は、利用規約、承認、および使用制限によって管理される API のバンドルです。開発者は製品をサブスクライブして、Ocp-Apim-Subscription-Key ヘッダーまたはクエリパラメーター経由で使用されるサブスクリプションキー (プライマリおよびセカンダリ) を取得します。デュアルキーのおかげで、キーはダウンタイムなしでローテーションできます。サブスクリプションのスコープは、キーが適用される場所 (すべての API、単一の API、または特定の製品) を決定します。サブスクリプションベースのアクセスは OAuth 2.0 を補完するものです。両方を必須にすることができ、認証はトークンに依存させつつ、個別のスロットリング/アカウンティングを可能にします。製品は、操作ごとのポリシーとは独立して、サブスクリプションごとのクォータとレート制限を適用でき、階層的な保護とガバナンスを提供します。

バックエンド、回復性、バージョン管理、リビジョン

APIMのバックエンドは、ターゲットサービスのベースURL、プロトコル、資格情報、TLS設定、ヘッダーテンプレート、プロキシ構成をカプセル化する、第一級の再利用可能なエンティティです。APIや操作をバックエンドに関連付けることで、ルーティングをポリシーから分離し、接続の詳細を一元管理します。ポリシー内でバックエンドIDを指定して set-backend-service を使用することで、URLをハードコーディングすることなくリクエストをルーティングでき、開発、テスト、本番環境へのプロモーションを簡素化します。

回復性は、リトライとサーキットブレーカーで強化されます。指数バックオフ付きのリトライは、一時的な障害を軽減できます。リトライは、べき等な操作にスコープを限定し、増幅を防ぐために妥当なタイムアウトで制限する必要があります。サーキットブレーカーポリシーは、サンプリングウィンドウ内で、失敗率、連続した失敗、またはレイテンシーが設定されたしきい値を超えると開き、定義された遮断期間中はリクエストをショートサーキットさせます。開いている状態の間、ポリシーは即座にフォールバック応答を返すか、スタンバイバックエンドにルーティングできます。ハーフオープンの状態では、限定された数の試行リクエストがバックエンドの正常性を調査してからサーキットを閉じます。これにより、バックエンドが保護され、クライアントエクスペリエンスが向上し、部分的な障害が発生しているシステムが安定します。

負荷分散とルーティングは、ポリシーレイヤーで実装できます。choose を使用した条件付きルーティングにより、ユーザーセグメント、地域、リクエストコンテンツ、またはヘルスシグナルによってトラフィックを振り分けることができます。加重ルーティングは、希望する重みに従ってバックエンドを疑似ランダムに選択するポリシー式によって実現でき、カナリアリリースと段階的なロールアウトを可能にします。リージョンをまたいだアクティブ/アクティブのバックエンドは、PremiumティアのマルチリージョンAPIMデプロイメントと、最も近い正常なリージョンへの条件付きルーティングを組み合わせることで対応できます。あるいは、グローバルなレイヤー7負荷分散のためにAzure Front Doorと統合し、APIMが認証と変換を処理することもできます。

バージョン管理とリビジョンはAPIのライフサイクルを管理します。バージョンセットは、パス、クエリストリング、またはヘッダーのバージョン管理スキームを使用して、複数のAPIバージョンをクライアントにどのように公開するかを定義します。破壊的変更にはバージョンを使用します。各バージョンは、同じバージョンセットに関連付けられた個別のAPIエンティティです。非破壊的で反復的な変更は、リビジョンとして実装されます。リビジョンはAPIの可変スナップショットであり、以前のリビジョンが現在の本番リビジョンとして残っている間に、テストのために（リビジョンサフィックスを介して）明示的に呼び出すことができます。検証後、バージョン識別子を変更することなく、新しいリビジョンを現在（current）に昇格させます。この分離により、安全で段階的なデリバリーが可能になります。非破壊的な更新にはリビジョンを、破壊的変更にはバージョンを使用し、それらは開発者ポータルでの明確な検出とドキュメントを通じて公開されます。

最後に、監視と統制を行います。トレースを有効にし、相関IDを設定し、診断をApplication Insightsにエクスポートして、エンドツーエンドの可視性を確保します。ARM/BicepまたはAPIM DevOps Resource Kitを介して構成を管理し、再現可能なデプロイを実現し、管理プレーンにRBACを適用してAPI作成者、発行者、運用者の職務を分離します。

実践的な問題シナリオ

スターバックスは、2つのAzureリージョンにまたがるマイクロサービスを集約する、モバイルオーダーリングのための一元化された公開APIを公開する必要があります。このAPIは、匿名アクセスをブロックし、不正なクライアントをスロットリングし、リージョナルバックエンドを連鎖的な障害から保護し、v1クライアントを壊すことなくv2オーダーのスキーマを段階的にロールアウトできるようにする必要があります。

APIM Premiumインスタンスを2つのリージョンに立ち上げ、マルチリージョンデプロイメントを有効にします。Premiumが選択される理由は、マルチリージョンゲートウェイの存在、高度なネットワーキング、エンタープライズ規模のスケールのためです。リージョナルゲートウェイは、モバイルクライアントのレイテンシーを削減し、アクティブ/アクティブの回復性を提供します。
両リージョンのApp Serviceインスタンスを含むバックエンドサービスを、APIMのバックエンドエンティティとしてインポートします。バックエンドエンティティは、ベースURL、TLS、資格情報の設定を一元管理し、クリーンなルーティングポリシーと環境の可搬性を可能にします。
Azure AD OAuth 2.0でクライアントからゲートウェイまでを保護し、インバウンドセクションで validate-jwt を使用してトークンを強制します。Azure ADは、一元化されたID、条件付きアクセス、および強力なトークン検証を提供します。validate-jwt により、正しいオーディエンス/スコープを持つ認証された呼び出し元のみがAPIを呼び出せるようになります。
製品のサブスクリプションを要求し、パートナーアプリごとにサブスクリプションキーを発行します。これにより、OAuthとは独立したガバナンスとメータリングのレイヤーが追加され、パートナーごとのクォータ、簡単なキーローテーション、ポータルベースのセルフサービスオンボーディングが可能になります。
インバウンドで、サブスクリプションキーをキーとして rate-limit-by-key と quota-by-key を設定します。スロットリングはバックエンドをスパイクから保護し、パートナーごとに差別化されたSLAを可能にします。サブスクリプションキーを識別子として使用することで、ビジネス契約に沿った強制が可能になります。
IPフィルタリングを実装して、既知の悪意のある範囲をブロックし、管理用にスターバックス所有の企業範囲を許可します。ip-filter は、パイプラインの早い段階で攻撃対象領域を削減し、ダウンストリームのリソースを節約します。
クライアント証明書をAPIMにアップロードし、関連するバックエンドエンティティにバインドすることで、機密性の高いサービスに対してバックエンドの相互TLSを設定します。mTLSは、バックエンドが証明書を要求する場合に強力なサービス間認証を提供し、内部のセキュリティポリシーを満たします。
Azure ADで保護されたサービスのために、バックエンドセクションに authentication-managed-identity を追加します。APIMのマネージドIDがバックエンドのアクセストークンを取得し、シークレットを排除し、Azure RBACや条件付きアクセスと統合します。
バックエンドセクションに、リトライとフォールバックを備えたサーキットブレーカーを実装します。時間枠内で繰り返し失敗した場合、サーキットを開き、リクエストを正常なリージョナルバックエンドにルーティングします。両方がダウンしている場合は、標準化されたキャッシュ済みのフォールバック応答を返します。これにより、劣化したサービスが保護され、障害発生時にも予測可能な動作が提供されます。
条件付きルーティングを使用して、読み取りを最も近いリージョンに負荷分散し、ヘルスシグナルに基づいてフェイルオーバーします。ポリシー式は、カスタムヘッダーまたはIPジオロケーションを検査してローカルリージョンを選択します。ヘルスプローブは、ルーティング決定のための変数を設定します。これにより、低レイテンシーとリージョン障害時の継続性が提供されます。
Orders APIにパスベースのバージョン管理（/v1, /v2）を持つバージョンセットを導入します。テスト用にv2の新しいリビジョンを作成し、リビジョン固有のURLを呼び出して一部のクライアントで検証し、その後、それを現在（current）に昇格させます。バージョンセットは破壊的変更を明確に伝え、リビジョンは安全で非破壊的なイテレーションを可能にします。
読み取り負荷の高いエンドポイント（メニュー/カタログ）に対して、アウトバウンドセクションで cache-lookup と cache-store を使用して応答キャッシュを有効にし、ロケールとデバイスタイプによって区別します。キャッシングは、バックエンドからの繰り返しのフェッチをオフロードし、モバイルパフォーマンスを向上させます。Premiumはこれらの機能を大規模にサポートします。

この設計は、認証され、スロットリングされ、回復力があり、進化可能なAPIを提供します。APIM Premiumはグローバルでセキュアなゲートウェイを提供し、ポリシーはアイデンティティ、スロットリング、変換、回復性を強制します。バックエンドエンティティとマネージドIDは接続を保護し、分離します。バージョンセットとリビジョンは、クライアントを中断させることのない継続的デリバリーのための規律あるライフサイクルを提供します。

← Azure の認証、承認、およびセキュリティ · すべてのドメイン · Azure のイベントベースとメッセージングソリューション →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →