APIMを入れたのに、事故は止まらなかった話

山崎行政書士事務所
5月2日
読了時間: 21分

― Azure API Managementにおける「入口対策」から「API統制・監査証跡・説明責任」への転換 ―

※本稿は、Azure API Management、API公開、監視、ログ、契約・規程・責任分界の整理を目的とする一般的情報提供です。個別紛争、訴訟対応、代理交渉、個別の法的判断は弁護士等の専門領域となる場合があります。山崎行政書士事務所のクラウド法務としては、行政書士業務の範囲を守りつつ、Azure現場の技術実態を契約・規程・監査証跡・運用手順へ落とし込む観点から論じます。

要旨

Azure API Management、以下APIMを導入すると、API公開の入口は整ったように見える。認証、サブスクリプションキー、レート制限、クォータ、JWT検証、IP制限、ログ出力、Application Insights連携など、API公開に必要な機能が一通り揃うためである。Microsoft Learnでも、API ManagementのゲートウェイはAPIキーやJWT、証明書などの資格情報を検証し、使用量クォータとレート制限を適用し、要求・応答の変換、キャッシュ、ログ・メトリック・トレース出力を担うと説明されている。

しかし、APIMを入れても事故は止まらない。むしろ、APIM導入後に本当に問われるのは、「入口を置いたか」ではなく、「APIごとの認可ポリシーが統一されているか」「ログを契約・監査に基づき保管し提出できるか」「利用者、アプリ、サブスクリプション、API、操作単位で追跡できるか」である。

ある現場では、API公開に合わせてAPIMを導入し、認証と流量制御も設定していた。ところが、障害時に「誰が・どのAPIを・どれだけ呼んだか」を説明できず、調査に丸2日を要した。原因はAPIMの機能不足ではない。ポリシー、ログ、利用者識別、契約、提出手順を統制として設計していなかったことにある。

本稿の結論は明確である。APIMは玄関ではない。API統制面である。 API公開は接続の話ではない。制御と説明責任の設計である。

キーワード： Azure API Management、APIM、API統制、認可ポリシー、KQL、ApiManagementGatewayLogs、監査証跡、クラウド法務、情シス、セキュリティ

1. 序論：APIMを入れた瞬間に、現場は安心してしまう

API公開のプロジェクトでは、APIM導入が一つの節目になる。

バックエンドAPIを直接インターネットに出さず、APIMを前段に置く。サブスクリプションキーを要求する。JWT検証を入れる。レート制限を設定する。OpenAPI定義をインポートする。開発者ポータルを用意する。監視ダッシュボードを見る。

この時点で、会議ではよくこう言われる。

「入口は固めました」「API Gatewayを入れました」「認証も流量制御もあります」「APIM経由なので安全です」

しかし、ここで止まると危険である。

APIMは、API公開の入口を作るだけの製品ではない。Microsoft Learnは、API Managementについて、APIを安全に公開し、保護、高速化、監視を行い、APIライフサイクル全体を支援するプラットフォームとして説明している。さらに、ゲートウェイはバックエンドのファサードとして、ルーティング、セキュリティ、調整、キャッシュ、可観測性の一貫した構成を可能にする。

つまり、APIMは「APIの玄関」ではあるが、それだけではない。本質は、APIごとの制御条件、利用者識別、ログ、追跡、証跡提出、責任分界をそろえる統制面である。

2. 事例：入口は固めた。しかし中身が崩れていた

ある現場で、外部パートナー向けAPIを公開することになった。要件は明確だった。

外部からAPIを使わせたい。ただし、利用者は限定したい。呼び出し過多を防ぎたい。障害時には利用状況を追いたい。契約上、利用ログを一定期間保存し、必要時に提出したい。

そこでAPIMを導入した。製品を作り、APIを割り当て、サブスクリプションキーを発行し、JWT検証を入れた。呼び出し数を抑えるためのレート制限も設定した。Azure Monitorにもメトリックが出ている。APIMの画面上では要求数やエラー率も見える。

だが、本番運用後に問題が起きた。

ある日の朝、バックエンドDBの負荷が急上昇し、一部APIがタイムアウトした。業務部門からは「取引先Aの連携だけ遅い」「一部のデータ登録が二重に見える」「誰が大量に叩いたのか確認してほしい」と連絡が来た。

現場はAPIMのログを開いた。たしかにログはある。要求数も見える。エラーも出ている。しかし、調査は進まなかった。

APIごとにポリシーが違う。あるAPIは製品スコープでレート制限。別のAPIはAPIスコープでJWT検証。一部の操作だけ操作スコープで例外。一部のAPIはサブスクリプション必須が外れている。ログは出ているが、保管期間と提出ルールが決まっていない。利用者単位の識別が、サブスクリプションキーなのか、JWTのsubなのか、アプリIDなのか、取引先コードなのか統一されていない。

障害会議で問われた。

「誰が呼びましたか」「どのAPIを呼びましたか」「何回呼びましたか」「正常と異常は何件ですか」「契約上、相手先に提出できるログはどれですか」「このログは何日残りますか」「同じ条件で再抽出できますか」

答えられなかった。

APIMは入っていた。しかし、統制は入っていなかった。

3. APIMのポリシーは、API統制の仕様書である

APIMのポリシーは、単なる設定ではない。APIごとに「何を許可し、何を拒否し、どの条件で変換し、どの範囲まで利用を許すか」を記述する仕様書である。

Microsoft Learnでは、APIMのポリシーは、APIの要求または応答に対して順に実行されるステートメント群であり、XMLからJSONへの変換や、呼び出しレート制限などを実現すると説明されている。また、ポリシーはグローバル、ワークスペース、製品、API、操作といった異なるスコープに適用できる。

ここが重要である。

APIMの事故は、「ポリシーがない」だけで起きるわけではない。「ポリシーがあるが、どこにあるかわからない」ことで起きる。「ポリシーがあるが、APIごとに違う」ことで起きる。「親スコープを継承していない」ことで起きる。「製品スコープで設定したつもりが、APIスコープのサブスクリプションでは適用されていない」ことで起きる。

Microsoft Learnは、複数スコープにポリシーが構成されると要求・応答に複数のポリシーが適用される可能性があり、base要素によって親スコープのポリシー継承と評価順序が決まると説明している。さらに、ポリシーフラグメントを使うことで、複数APIで共通のポリシー構成を再利用できる。

つまり、APIMのポリシー設計では、次の問いが必要になる。

認証・認可はグローバル、製品、API、操作のどこで定義するのか
JWT検証は全API共通か、APIごとに違うのか
レート制限はサブスクリプション単位か、ユーザー単位か、IP単位か
例外APIはどこに定義され、誰が承認しているのか
base継承を壊していないか
共通ポリシーはフラグメント化されているか
有効ポリシーを計算してレビューしているか

「APIMを入れた」は入口の話である。「どのスコープで、どのポリシーが、どの順序で適用されるかを説明できる」は統制の話である。

4. サブスクリプションキーは、認証ではあるが万能の利用者識別ではない

APIMでは、サブスクリプションキーを使ってAPIアクセスを制御できる。Microsoft Learnは、公開されたAPIを使う開発者は、有効なサブスクリプションキーをHTTP要求に含める必要があり、有効なキーがない場合、APIMゲートウェイが要求を拒否し、バックエンドには転送しないと説明している。

しかし、ここにも落とし穴がある。

サブスクリプションキーは、必ずしも「個人」や「実際の利用者」を表すわけではない。チームで共有されることもある。システム間連携で一つのキーを複数サーバーが使うこともある。スタンドアロンのサブスクリプションとして、開発者アカウントに関連付かないキーを配布することもできる。Microsoft Learnも、所有者を割り当てないスタンドアロンサブスクリプションを作成でき、複数の開発者やチームがサブスクリプションを共有するシナリオに役立つと説明している。

また、APIMにはサブスクリプションキーの有効期限設定や自動ローテーションの組み込み機能はなく、必要に応じてAzure PowerShellやSDK等で自動化ワークフローを作る必要があるとされている。

現場で起きる問題は、ここである。

取引先Aにキーを渡した。しかし、取引先Aのどのシステムが使っているか分からない。本番用キーを検証環境でも使っている。キーを再発行した履歴がない。キーの有効期限が契約と一致していない。退職者、委託先、再委託先に渡ったキーの棚卸しができていない。

この状態で障害が起きると、「誰が呼んだか」は説明しにくい。

APIMのサブスクリプションキーは、API利用の入口制御として有効である。しかし、契約・監査上の利用者追跡には、サブスクリプションID、ユーザーID、JWTのクレーム、アプリケーションID、取引先コード、IP、Correlation IDを組み合わせる必要がある。

5. 「製品スコープで守っているつもり」が崩れる危険

APIMの実務で非常に重要な点がある。製品スコープで設定したポリシーが、すべての呼び出しに必ず適用されるとは限らないという点である。

Microsoft Learnは、APIスコープ、すべてのAPIスコープ、または組み込みのすべてのアクセス許可を持つサブスクリプションを使う場合、製品スコープで構成されたポリシーは、そのサブスクリプションからの要求には適用されないと説明している。

これは、現場ではかなり危険である。

たとえば、製品スコープに次を入れていたとする。

取引先別レート制限
JWT検証
IP制限
ヘッダー検証
監査用ヘッダー付与
バックエンド向け認証付与

ところが、一部の利用者がAPIスコープのサブスクリプションで呼んでいた場合、製品スコープのポリシーが適用されない可能性がある。これにより、「この製品に入っているAPIはすべて同じ統制です」と説明していた前提が崩れる。

この事故は、ポータル画面だけでは見えにくい。設計書にも「製品にポリシー設定」とだけ書かれていることが多い。しかし、実際の呼び出しコンテキストでは別のポリシーが適用される。

だからAPIMでは、設定を見るだけでなく、有効ポリシーとサブスクリプションスコープの対応関係をレビューする必要がある。

6. 認証と認可：JWT検証を入れただけでは足りない

APIMでは、Microsoft Entra IDとOAuth 2.0を使ってAPIを保護できる。Microsoft Learnは、クライアントがMicrosoft Entra IDからトークンを取得し、APIMへのAPI要求のAuthorizationヘッダーに追加し、APIM側でvalidate-jwtポリシーを使ってトークンを検証する流れを説明している。有効なトークンがなければAPIMが要求をブロックし、有効なトークンがあればバックエンドへ転送できる。

だが、JWT検証を入れただけでは、認可設計は完成しない。

見るべきは、次である。

issuerは正しいか
audienceはAPI単位で正しいか
tenantは想定通りか
app roleまたはscopeを検証しているか
ユーザー委任か、アプリケーション権限か
取引先ごとに許可APIを分けているか
操作単位で許可範囲が違う場合、どこで制御しているか
バックエンドに渡すべきクレームと、渡してはいけない情報を分けているか

APIMの認可事故は、「トークンがあるか」ではなく、「そのトークンでこのAPI操作を呼んでよいのか」が曖昧なときに起きる。

特に、外部パートナー連携では、契約上「A社は参照APIのみ」「B社は登録APIも可」「C社は月間上限あり」といった差が出る。これをAPIMポリシー、サブスクリプション、製品、JWTクレーム、ログ抽出条件まで落とし込まなければ、契約と実装がズレる。

7. 流量制御：レート制限は“障害対策”であり“契約条件”でもある

APIMにはレート制限やクォータのポリシーがある。Microsoft Learnでは、rate-limitポリシーは指定期間あたりの呼び出しレートを指定数に制限し、超過時に呼び出し元へ429 Too Many Requestsを返すと説明されている。なお、分散アーキテクチャの性質上、レート制限は完全に正確になるとは限らないとも注意されている。

また、OWASP API Security Top 10を軽減するMicrosoft Learnの記事では、rate-limit-by-keyポリシーを使って、ユーザーID、IPアドレス、その他の値に基づきAPI使用の急増を制限することが推奨されている。

ここで重要なのは、レート制限は単なる性能対策ではないという点である。

契約で「1分あたり100リクエストまで」と書いたなら、APIMポリシーでそれを表現する必要がある。「超過時は429を返す」と決めたなら、障害報告書にも契約にもその前提を書く必要がある。「重要APIは取引先別に上限を変える」と決めたなら、counter-key設計とログ抽出条件をそろえる必要がある。

現場でよくある悪い例は、こうである。

契約書には月間上限がある。APIMには分単位のレート制限だけある。月間クォータは誰も見ていない。障害時に「契約上の上限超過だったのか、システム障害だったのか」が分からない。

この状態では、流量制御は技術設定にとどまり、契約統制になっていない。

8. ログ：出ていることと、提出できることは違う

本件で最も大きな問題は、「ログは出ていたが、保管・提出ルールがなかった」ことである。

APIMの監視では、Azure Monitorを使ってメトリック、アラート、アクティビティログ、リソースログを確認できる。Microsoft Learnでは、要求メトリックはAPIMサービスを通過するAPIトラフィックの分析に役立ち、応答コード、場所、ホスト名、エラーでフィルターできると説明している。また、アクティビティログではAPIMサービスで発生した書き込み操作について「いつ誰が何を」行ったかを確認できる。

さらに、APIMのリソースログは、監査とトラブルシューティングに重要なAPIMの操作とエラーについての豊富な情報を提供し、診断設定を通じて有効化すると、APIMゲートウェイが受信・処理したAPI要求に関する情報を収集できる。ログはLog Analyticsワークスペースへ送信したり、ストレージアカウントへアーカイブしたり、Event Hubsへストリーミングしたりできる。

しかし、これでも足りない。

「ログを出しています」は、監査回答としては弱い。「どのログを、何日間、どこに保存し、誰が、どの条件で抽出し、誰に提出できるか」が必要である。

Log Analyticsワークスペースのデータ保持について、Microsoft Learnは、既定では多くのテーブルが30日間保持され、AnalyticsプランではAnalytics保持期間を最長2年間、合計保持期間を最長12年間まで延長できると説明している。

したがって、契約で「API利用ログを1年間保存」と書くなら、APIMの診断設定、Log Analyticsのテーブル保持、ストレージアーカイブ、検索手順、提出範囲、マスキング条件まで整合させる必要がある。

9. APIMログの限界：ペイロードを取ればよい、ではない

APIMログで注意すべき点は、要求・応答本文を安易に記録しないことである。

Microsoft Learnは、APIMの診断設定を作成すると既定の設定でログ記録が有効になるが、既定では要求や応答本文などの詳細は含まれないと説明している。また、APIMではAzure Monitorに送信されるログエントリのサイズに32KBの制限があり、ゲートウェイログでは要求または応答ペイロードはそれぞれ最大8,192バイト、全属性合計が32KBを超える場合は本文やトレースコンテンツが削除される場合がある。

つまり、「原因調査のために全部ログに出せばよい」という考え方は危険である。

ペイロードには個人情報、秘密情報、トークン、取引情報、内部IDが含まれる可能性がある。ログサイズ制限により、肝心な部分が残らない可能性もある。本文ログを有効化すると、性能やコストに影響する可能性もある。

Application Insights連携でも、API単位またはすべてのAPIでログを有効にでき、サンプリングやエラー常時記録などを設定できるが、Microsoft Learnはペイロードバイト数の既定値をオーバーライドして値を0以外にすると、APIのパフォーマンスが大幅に低下する可能性があると警告している。

したがって、ログ設計では次を分ける必要がある。

通常監視で必要な項目
障害調査で必要な項目
監査提出に必要な項目
契約上保存すべき項目
保存してはいけない、またはマスキングすべき項目
一時的な詳細ログを有効化する手順
詳細ログを無効化する手順
本文ログの承認者

ログは多ければよいわけではない。提出できる形で、必要最小限かつ再現可能に残すことが重要である。

10. 利用者単位のトレース：誰が、どのAPIを、どれだけ呼んだか

APIMのリソース固有テーブルであるApiManagementGatewayLogsには、APIMサブスクリプションID、API ID、ProductId、OperationId、CallerIpAddress、CorrelationId、ResponseCode、TotalTime、UserIdなど、利用者・API・操作・結果を追跡するための列が含まれる。

たとえば、障害時に最低限必要なのは次のようなKQLである。実際の列名やテーブル名は、リソース固有テーブルに保存しているか、AzureDiagnosticsに保存しているかで調整が必要である。

let startTime = datetime(2026-05-01T00:00:00Z);let endTime   = datetime(2026-05-02T00:00:00Z);ApiManagementGatewayLogs| where TimeGenerated between (startTime .. endTime)| summarize    Calls = count(),    FailedCalls = countif(ResponseCode >= 400),    P95_TotalTimeMs = percentile(TotalTime, 95),    Max_TotalTimeMs = max(TotalTime)  by    UserId,    ApimSubscriptionId,    ProductId,    ApiId,    OperationId,    CallerIpAddress| order by FailedCalls desc, Calls desc

このKQLで初めて、次が見える。

誰が呼んだのか。どのサブスクリプションで呼んだのか。どの製品・API・操作だったのか。何回呼んだのか。失敗は何件か。遅延はどの程度か。どのIPから来たのか。

障害報告書には、「APIMの画面上で確認」ではなく、「この期間、このKQLで、利用者・サブスクリプション・API・操作単位に集計した」と書ける。

これが、見える監視と、説明できる監視の違いである。

11. トレースの扱い：便利だが、機密情報の漏えいに注意する

APIMの要求トレースは、デバッグには有効である。しかし、トレースは安易に開放してよいものではない。

Microsoft Learnは、APIMではOcp-Apim-Traceヘッダーによる従来のサブスクリプションベースのトレースをサポートしなくなったと説明している。現在は、APIのセキュリティを高めるため、トレースを個々のAPIレベルで有効化し、APIM REST APIを使って時間制限付きトークンを取得して要求に渡す方式が案内されている。また、トレースデータには機密情報が含まれる可能性があるため、適切なセキュリティ対策が必要とされている。

これは、2026年時点のAPIM運用では非常に重要な更新ポイントである。

障害時に「とりあえずトレースを有効化しましょう」と言うだけでは不十分である。誰が有効化するのか。どのAPIだけにするのか。有効期間は何分か。トレースに含まれる機密情報を誰が扱えるのか。取得したトレースをどこに保管するのか。取引先へ提出できる範囲はどこまでか。終了後に無効化した証跡はあるか。

ここまで決めなければ、トレースは調査の武器であると同時に、情報漏えいの入口にもなり得る。

12. コンテンツ検証：入口を通った後の“中身”を見ているか

ユーザーの原文にある「問題になったのは“中身”でした」という点は極めて重要である。

APIの事故は、認証を通過した後にも起きる。

形式が不正なJSON。想定外のプロパティ。過大なペイロード。仕様外のヘッダー。業務上許されないパラメーター。バックエンドへ渡してはいけないURL。

Microsoft Learnでは、APIMのvalidate-contentポリシーにより、要求または応答本文のサイズやコンテンツをJSON/XML/SOAPスキーマに対して検証できると説明している。また、検証エラーを検出または防止するアクションを設定でき、preventにした場合は要求または応答の処理をブロックできる。

OWASP API Security Top 10を軽減するMicrosoft Learnの記事でも、ヘッダーやパラメーターの検証、IP制限、rate-limit-by-key、バックエンドURLやsend-request、rewrite-urlでクライアント提供URLを不用意に使わないこと、検証ポリシーで要求・応答をサニタイズすることなどが推奨されている。

つまり、APIMの「入口統制」は、認証だけではない。

誰が呼ぶか
どのAPIを呼べるか
どの範囲で呼べるか
どの形式の要求を受けるか
どの大きさまで許すか
どの値を拒否するか
どのレスポンスを外へ返すか
エラー時に何を漏らさないか

ここまでが、API公開の統制である。

13. 障害報告で必要になるAPIM証跡

APIM事故の障害報告書では、次の項目を最低限そろえるべきである。

項目	記載すべき内容
対象API	API ID、Operation ID、バージョン、リビジョン
対象利用者	UserId、ApimSubscriptionId、取引先、アプリID
対象期間	UTC/JSTを明記した集計期間
呼び出し数	成功、4xx、5xx、429、タイムアウト件数
流量制御	適用されたrate-limit、quota、counter-key
認可条件	JWT、scope、role、audience、IP制限等
有効ポリシー	グローバル、製品、API、操作スコープの適用関係
ログ根拠	Log AnalyticsのKQL、実行者、実行日時
保管場所	Log Analytics、Storage Archive、チケット、報告書
提出範囲	契約上提出可能な列、マスキング対象
再発防止	ポリシー標準化、ログ台帳、レート上限見直し等

これがないと、障害報告書は「APIM上で確認」「ログ上では増加」といった弱い表現になる。

監査で問われるのは、APIMがあるかどうかではない。APIMが、説明可能な証跡を出せる設計になっているかである。

14. 契約・規程上の論点：API利用規約とAPIM設定を一致させる

APIMは、契約実務と直結する。

API利用規約に「利用者は第三者にキーを共有してはならない」と書くなら、サブスクリプションキー発行台帳とローテーション手順が必要である。「月間呼び出し上限」を書くなら、APIMのクォータまたは集計KQLが必要である。「障害時に利用ログを提示する」と書くなら、保存期間、提出範囲、マスキングルール、提出期限が必要である。「不正利用時にAPIを停止できる」と書くなら、サブスクリプション停止、キー再生成、IPブロック、JWTクライアント無効化の手順が必要である。

Microsoft Learnは、APIMのサブスクリプション状態を中断、キャンセル、削除してAPIアクセスを防ぐことができると説明している。

したがって、契約書には抽象的に「当社は必要に応じてAPI提供を停止できる」と書くだけでは不十分である。実装上、どの単位で止められるのかを把握する必要がある。

サブスクリプション単位で止めるのか
ユーザー単位で止めるのか
取引先単位で止めるのか
API単位で止めるのか
操作単位で止めるのか
IP単位で止めるのか
Entraアプリ単位で止めるのか

契約上の停止単位と、APIM上の停止単位が一致していなければ、いざという時に運用が詰まる。

15. NIST CSF 2.0の観点：APIMはProtectだけではなくGovernである

APIM導入は、一見するとProtect、すなわち防御の施策である。認証、認可、流量制御、検証、IP制限を行うからである。

しかし、本件の本質はGovernである。

NIST CSF 2.0は、Govern、Identify、Protect、Detect、Respond、Recoverの6機能を通じて、サイバーセキュリティリスクを管理するための高レベルな成果分類を提供する枠組みである。

APIMに当てはめると、次のようになる。

CSF機能	APIMで問われること
Govern	API公開責任者、ポリシー承認者、ログ提出責任者、契約条件を誰が決めるか
Identify	どのAPIが外部公開され、どのデータ・業務に接続しているか
Protect	JWT検証、サブスクリプション、レート制限、IP制限、スキーマ検証
Detect	ApiManagementGatewayLogs、Application Insights、アラート、KQL
Respond	異常利用時のキー停止、IP遮断、取引先連絡、ログ保全
Recover	API復旧、バックエンド復旧、契約上の報告、再発防止

APIMを入れただけでは、Protectの一部にすぎない。APIMを統制面として使うには、GovernとDetectとRespondまで設計する必要がある。

16. 山崎行政書士事務所のクラウド法務として整備すべき文書

山崎行政書士事務所のクラウド法務×Azure技術支援では、Azureのアーキテクチャ、ID、ログ、バックアップ、DR、AI、委託、監査、インシデント対応を、契約・規程・説明資料・運用手順として一貫した言葉に翻訳することが本質であると整理されている。

APIM案件で整備すべき文書は、少なくとも次である。

16.1 API公開台帳

API名、API ID、Operation ID、バージョン、リビジョン、公開先、利用者、データ分類、業務重要度、バックエンド、認可方式を一覧化する。

16.2 APIMポリシー設計書

グローバル、製品、API、操作の各スコープで、どのポリシーを適用するかを定義する。base継承、有効ポリシー、ポリシーフラグメント、例外ポリシーを含める。

16.3 認可マトリクス

取引先、アプリ、ユーザー、サブスクリプション、JWTクレーム、API、操作を対応付ける。誰が何を呼べるかを、人間が読める表にする。

16.4 ログ・証跡設計書

ApiManagementGatewayLogs、Application Insights、Activity Log、KQL、保存期間、アーカイブ先、提出範囲、マスキング条件を定義する。

16.5 API利用規約・契約別紙

利用上限、禁止行為、キー管理、ログ保存、障害時の通知、利用停止、再発防止協力、監査・ログ提出の範囲を明記する。

16.6 障害対応手順書

異常利用時に、どのKQLを実行し、どのサブスクリプションを停止し、どの取引先へ連絡し、どのログを保全するかを定義する。

16.7 監査説明資料

「APIMを使っています」ではなく、「このAPIはこの認可条件、このレート制限、このログ、この保存期間、この提出ルールで統制されています」と説明できる資料を作る。

17. 実務チェックリスト

APIMを導入した現場で、情シス・経営層・監査担当が確認すべき項目は次である。

観点	確認項目
API台帳	すべての公開API・操作が一覧化されているか
ポリシースコープ	グローバル、製品、API、操作の適用関係が明確か
継承	base要素と有効ポリシーを確認しているか
標準化	共通ポリシーをフラグメント化しているか
認証	JWT、サブスクリプション、証明書、IP制限の役割を分けているか
認可	scope、role、appId、取引先単位でAPI操作を制御しているか
流量制御	契約上の上限とAPIMポリシーが一致しているか
匿名アクセス	サブスクリプション不要APIが意図せず存在しないか
キー管理	キーの所有者、配布先、ローテーション、停止手順があるか
ログ	診断設定、Log Analytics、アーカイブが有効か
保持期間	契約・監査要求とLog Analytics保持期間が一致しているか
KQL	利用者別・API別・操作別の抽出クエリが保存されているか
トレース	時間制限付きトークン、機密情報対策、無効化手順があるか
提出	取引先に提出可能なログ範囲とマスキング条件が決まっているか
障害対応	異常利用時に誰が止め、誰が説明するか決まっているか
契約	API利用規約・SOW・運用保守契約とAPIM設定が一致しているか

18. 考察：APIMは“入れる製品”ではなく“運用する統制”である

APIMを導入しただけでAPI事故が止まるわけではない。

APIごとにポリシーが違えば、統制は崩れる。ログが出ていても、提出ルールがなければ監査で詰まる。サブスクリプションキーがあっても、利用者単位で追跡できなければ障害調査は遅れる。JWT検証があっても、scopeやroleを見ていなければ認可は弱い。レート制限があっても、契約上の利用上限と一致していなければ説明できない。トレースがあっても、機密情報を保護しなければ別の事故になる。

APIMは、単なる玄関ではない。APIという業務接点を、契約・監査・運用・セキュリティの言葉で統制する面である。

19. 結論：API公開は接続の話ではない。制御と説明責任の設計である

本稿の結論は、次の一文に尽きる。

APIMを入れたことは、API統制の開始であって、完了ではない。

入口は固めた。しかし中身がバラバラだった。ログは出ていた。しかし提出できなかった。認証はあった。しかし利用者単位で追えなかった。レート制限はあった。しかし契約上の上限と結びついていなかった。

この状態では、APIMは事故を止める統制面にならない。

必要なのは、次である。

認可ポリシーをAPI単位で統一する
ポリシースコープと有効ポリシーをレビューする
サブスクリプション、JWT、ユーザー、取引先を対応付ける
ログをLog Analyticsやアーカイブへ保存する
KQLで利用者別・API別・操作別に再抽出できるようにする
契約に基づき、ログ保存・提出・マスキング範囲を決める
障害時の停止、連絡、保全、報告の手順を整える
API利用規約、責任分界、監査資料とAPIM設定を一致させる

山崎行政書士事務所のクラウド法務・Azure技術支援は、この「APIMを導入した」と「API統制を説明できる」の隙間を埋める支援である。APIM、Azure Monitor、Application Insights、Log Analytics、KQL、契約、利用規約、責任分界、監査証跡を一つの設計として整理し、情シスと経営層が同じ言葉で説明できる状態を作る。

APIMは玄関ではなく、統制面。API公開は接続の話ではなく、制御と説明責任の設計である。