Microsoft Graph APIの利用状況をテナント単位で把握したい場合、Azure Monitorの「Microsoft Graph activity logs」を使うと、アプリやユーザーがMicrosoft Graphへ送信したHTTPリクエストをLog Analytics、Azure Storage、Event Hubsへ転送できます。
2026年7月4日の公式ドキュメント更新で重要なのは、機能やライセンス条件が変わったことではありません。パスワード、アクセストークン、接続文字列などの機密情報を、Microsoft Graphから参照できるディレクトリ属性へ保存してはならないという警告が明確に追加されました。RequestUriなどのリクエスト情報がログに記録され、Log AnalyticsやSIEMにも転送される可能性があるためです。(マイクロソフトラーニング)
すでにMicrosoft Graph activity logsを利用している組織は、設定変更よりも先に、ディレクトリ属性への機密情報の保存状況と、ログ転送先のアクセス権を確認する必要があります。まだ利用していない組織は、Microsoft Graphを使う業務アプリ、AIクライアント、外部SaaSが増えているかを基準に導入要否を判断するとよいでしょう。
2026年7月4日の更新で何が変わったのか
公式ページの更新履歴では、2026年7月3日のコミットによって、監査可能なディレクトリオブジェクトへ機密情報を保存しないよう警告が追加されています。Microsoft Learn上の最終更新日は2026年7月4日です。差分は警告文の追加が中心で、ログのスキーマ、提供先、ライセンス条件を変更する内容ではありません。(GitHub)
| 確認項目 | 2026年7月4日の更新内容 | 利用者への影響 |
|---|---|---|
| 新機能の追加 | 確認されていない | 新しい設定を直ちに有効化する必要はない |
| ログ項目の変更 | 確認されていない | 既存のKQLやSIEM連携への直接的な変更はない |
| ライセンス変更 | 確認されていない | 従来どおりMicrosoft Entra ID P1またはP2が必要 |
| セキュリティ警告 | 機密情報をディレクトリ属性などへ保存しないよう明記 | データ設計、ログ閲覧権限、転送先を再点検する必要がある |
| 推奨する保存先 | Azure Key Vaultなどの専用シークレットストアを案内 | アプリの資格情報管理方法を見直す必要がある |
今回の更新を「Azure Monitorに新しいログ機能が追加された」と解釈するのは正確ではありません。実務上のポイントは、監視機能を有効にすると、誤って配置した機密情報が複数のログ保存先へ広がる可能性があるとMicrosoftが明示したことです。
なぜ機密情報の保存場所が問題になるのか
Microsoft Graph activity logsには、RequestUriを含むAPIリクエストの情報が記録されます。さらに、ログはテナント管理者だけでなく、転送先のLog Analyticsワークスペース、Azure Storage、SIEMへアクセスできる担当者からも参照される可能性があります。(マイクロソフトラーニング)
たとえば、次のような設計は見直し対象です。
- ユーザーやグループなどの属性にパスワードやAPIキーを保存している
- URLのクエリ文字列へアクセストークンや接続文字列を含めている
- アプリの設定値として使うシークレットを、Microsoft Graphで取得できる属性へ格納している
- ログ転送先のSIEMやストレージへ、必要以上に広い閲覧権限を付与している
資格情報やシークレットは、Azure Key Vaultなど、アクセス制御と監査を前提とした専用サービスへ保存する必要があります。
Microsoft Graph activity logsで何を監視できるのか
Microsoft Graph activity logsは、テナント内のリソースに対してMicrosoft Graphが受信・処理したHTTPリクエストの監査証跡です。
対象には、組織内で開発した業務アプリ、APIクライアント、Microsoft Graph SDK、AIクライアント、Outlook、Microsoft Teams、Microsoft管理ポータルなどからのリクエストが含まれます。Microsoft MCP Server for Enterpriseへのリクエストも対象となり、該当するRequestUriには/enterpriseが含まれます。(マイクロソフトラーニング)
このログを利用すると、次のような調査が可能になります。
- どのアプリがMicrosoft Graphへ大量のリクエストを送っているか
- 401、403エラーが多発しているアプリはどれか
- 429エラーによるスロットリングが発生していないか
- 特定のユーザーやサービスプリンシパルが、どのリソースへアクセスしたか
- 不審なユーザーがMicrosoft Graph経由で実行した処理
- 想定していないアプリやAPIクライアントからのアクセス
- AIクライアントがMicrosoft Graphへ送信したリクエスト
- Microsoft Graphのリクエストとサインイン情報の関連
Azure Activity LogやMicrosoft Entraログとの違い
Microsoft Graph activity logsは、Azure Activity LogやMicrosoft Entraの監査ログを置き換えるものではありません。それぞれ監視対象が異なるため、必要に応じて組み合わせます。(マイクロソフトラーニング)
| ログ | 主に分かること | 代表的な用途 |
|---|---|---|
| Microsoft Graph activity logs | Microsoft GraphへのAPIリクエスト | アプリ利用状況、APIエラー、過剰アクセス、不審なGraph操作の調査 |
| Microsoft Entraサインインログ | ユーザー、サービスプリンシパル、マネージドIDなどの認証 | サインイン失敗、条件付きアクセス、認証元の調査 |
| Microsoft Entra監査ログ | ユーザー、グループ、アプリ、ライセンスなどの変更 | 設定変更や管理操作の追跡 |
| Azure Activity Log | Azureリソースに対するコントロールプレーン操作 | 仮想マシン作成、ポリシー変更、デプロイ失敗などの追跡 |
たとえば、サービスプリンシパルのサインインログだけでは、認証後にMicrosoft GraphのどのURIへアクセスしたかまでは十分に把握できません。Microsoft Graph activity logsを同じLog Analyticsワークスペースへ送ることで、認証とAPI利用の両方を確認しやすくなります。
対象ユーザーと対応優先度
Microsoft Graph activity logsは、Microsoft 365を利用するすべての組織で必須というわけではありません。Microsoft Graphを利用するアプリの数、監査要件、インシデント対応体制によって優先度が変わります。
| 組織の状況 | 導入・対応優先度 | 推奨する対応 |
|---|---|---|
| すでにログを収集しており、ディレクトリ属性へ機密値を保存している可能性がある | 最優先 | 属性を調査し、資格情報を失効・再発行して専用シークレットストアへ移行する |
| Microsoft Graphを利用する業務アプリや外部SaaSが多い | 高い | Log Analyticsへの試験転送を開始し、アプリ別の利用量を把握する |
| Microsoft Sentinelや外部SIEMでテナントを監視している | 高い | Event HubsまたはLog Analytics連携を検討する |
| AIエージェントやMCP Server for Enterpriseを利用している | 高い | /enterpriseを含むリクエストとAIクライアントのAppIdを監視する |
| Graph APIの403や429エラーを調査したい | 高い | Log Analyticsへ送信してKQLで原因を特定する |
| Microsoft Graphをほとんど利用していない小規模環境 | 中～低 | まずアプリ登録と管理者同意済みアプリを棚卸しする |
| Microsoft Entra ID P1またはP2を利用していない | 導入不可 | ライセンス費用と監視要件を比較して判断する |
ログ収集の優先度が低い組織でも、今回追加された「ディレクトリ属性へ機密情報を保存しない」という注意点は適用されます。ログを現在有効化していないことは、機密情報を属性へ保存してよい理由にはなりません。
Microsoft Graph activity logsの提供条件
Microsoft Graph activity logsを利用するには、Microsoft Entra ID、Azureサブスクリプション、ログ転送先を準備する必要があります。(マイクロソフトラーニング)
| 項目 | 条件 |
|---|---|
| テナントライセンス | Microsoft Entra ID P1またはP2 |
| 診断設定を行う管理者 | 最小権限としてSecurity Administrator |
| Azure環境 | Azureサブスクリプション |
| 分析先 | Azure Log Analyticsワークスペース |
| 長期保管先 | Azure Storageアカウント。設定時にはList Keys権限が必要 |
| 外部SIEMとの連携 | Azure Event Hubs名前空間 |
| データ利用権限 | 各転送先に対する適切なアクセス権 |
| 提供クラウド | グローバル、米国政府L4、米国政府L5、21Vianet運用の中国クラウド |
Azureサブスクリプション自体を用意しても、Log Analyticsへのデータ取り込み、Storageの使用量、Event Hubsの処理には料金が発生します。Microsoft Entra ID P1またはP2のライセンスだけで、ログの保存・分析費用まで含まれるわけではありません。(マイクロソフトラーニング)
ログに記録される主なデータ
Log Analyticsでは、Microsoft Graph activity logsがMicrosoftGraphActivityLogsテーブルへ格納されます。公開されているスキーマには、アプリ、ユーザー、リクエストURI、HTTPステータスコード、処理時間、IPアドレスなどが含まれます。(マイクロソフトラーニング)
| 列 | 内容 | 実務での使い方 |
|---|---|---|
TimeGenerated | リクエストを受信した日時 | 時系列調査、急増時間の特定 |
AppId | アプリケーションID | 問題を起こしたアプリの特定 |
ServicePrincipalId | サービスプリンシパルID | テナント内のエンタープライズアプリとの照合 |
UserId | リクエストを行ったユーザーID | ユーザー単位の操作追跡 |
RequestMethod | GET、POST、PATCH、DELETEなど | 参照系と変更系の切り分け |
RequestUri | リクエスト先URI | アクセスされたリソースやAPIの確認 |
ResponseStatusCode | HTTP応答コード | 401、403、404、429、5xxの調査 |
DurationMs | 処理時間 | 遅いAPIやタイムアウト原因の分析 |
IPAddress | クライアントのIPアドレス | 不審な接続元や利用地域の確認 |
Scopes | トークンのスコープ | 委任されたアクセス許可の確認 |
Roles | トークンに含まれるロール | アプリケーション権限の確認 |
SignInActivityId | サインイン活動との関連ID | Microsoft Entraサインインログとの突合 |
UserAgent | クライアント情報 | SDK、ブラウザ、独自クライアントの識別 |
ResponseSizeBytes | 応答データ量 | 大量データ取得の傾向把握 |
公開スキーマ上は、APIのリクエスト本文全体を保存する列が示されているわけではありません。一方でMicrosoftは、RequestUriなどのリクエスト情報や監査対象リソースを通じて機密値が記録される可能性を明示しています。「本文がログ列に見当たらないから安全」と判断せず、機密情報をMicrosoft Graphで監査可能な属性へ置かないことが重要です。(マイクロソフトラーニング)
導入・運用前に確認すべきポイント
ディレクトリ属性に機密情報が入っていないか
最優先で確認すべきなのは、Microsoft Graphから参照できる属性やリソースに、次のような値を保存していないかです。
- パスワード
- クライアントシークレット
- APIキー
- アクセストークン
- リフレッシュトークン
- 接続文字列
- 外部サービスの認証情報
該当する値が見つかった場合は、単に属性から削除するだけでは不十分です。すでにログへ記録・転送された可能性を考慮し、資格情報を失効またはローテーションしたうえで、Log Analytics、Storage、SIEMの保存状況とアクセス履歴も確認します。
ログの利用目的に合った転送先を選ぶ
Microsoft Graph activity logsは、複数の転送先へ送信できます。目的を決めずにすべての転送先を使うと、費用と管理対象が増えます。(マイクロソフトラーニング)
| 転送先 | 向いている用途 | 注意点 |
|---|---|---|
| Log Analytics | KQLによる検索、アラート、ダッシュボード、インシデント調査 | 取り込み量と保持期間に応じて費用が発生する |
| Azure Storage | 長期保存、監査証跡、コンプライアンス対応 | 日常的な検索や横断分析には追加処理が必要 |
| Azure Event Hubs | 外部SIEM、SOC基盤、独自分析システムへのストリーミング | SIEM側の取り込み費用やスループット設計が必要 |
日常的にクエリやアラートを使うならLog Analytics、長期保管が中心ならAzure Storage、既存の外部SIEMへ集約するならEvent Hubsが基本的な選択肢です。
ログ量と費用を事前に見積もる
Microsoftの参考値では、ユーザー数1,000人のテナントでAzure Monitor Logsへのデータ量が月約15GiB、10万人のテナントでは月約1,200GiBになる例が示されています。ただし、実際の量はユーザー数だけでなく、アプリ数やMicrosoft Graphへのリクエスト頻度に大きく左右されます。(マイクロソフトラーニング)
| テナントのユーザー数 | Storageの参考値 | Event Hubsメッセージ数 | Azure Monitor Logsの参考値 |
|---|---|---|---|
| 1,000人 | 月14GiB | 月62,000件 | 月15GiB |
| 100,000人 | 月1,000GiB | 月4,800,000件 | 月1,200GiB |
実務では、最初から年間費用を固定的に見積もるより、試験用の転送先へ1～2日程度送信し、実測した日次データ量から月額を推計する方が確実です。Microsoftも、短期間のデータを取得して実際の費用を見積もる方法を案内しています。(マイクロソフトラーニング)
Log Analyticsの費用を抑える方法としては、ワークスペース変換による不要レコード・列の除外や、MicrosoftGraphActivityLogsテーブルをBasicログプランへ変更する方法があります。同テーブルは取り込み時変換とBasicログに対応しています。ただし、Basicログでは利用できる分析機能が制限されるため、アラートや高度な分析に使う場合は事前検証が必要です。(マイクロソフトラーニング)
ログ閲覧権限を最小化する
Microsoft Graph activity logsには、ユーザーID、アプリID、IPアドレス、アクセス先URI、権限スコープ、ロールなどが含まれます。単なるシステム稼働ログではなく、組織の利用状況やアクセス構造が分かるセキュリティデータです。(マイクロソフトラーニング)
少なくとも次のアクセス権を確認します。
- Log Analyticsワークスペースを閲覧できるユーザー
- Azure Storageのデータを読み取れるユーザーやサービス
- Event Hubsからログを受信できるコンシューマー
- SIEM上で生ログを表示できるSOC担当者
- ログをエクスポートできるユーザー
- 退職者や異動者の権限が残っていないか
診断設定を作成できる権限と、転送後のログを閲覧できる権限は別に管理します。
初回反映と通常配信の時間差を考慮する
診断設定を作成した直後は、ログが転送先に表示されるまで最大3日かかる場合があります。運用開始後の通常配信は、多くのリージョンで30分以内ですが、まれに最大2時間かかる可能性があります。(マイクロソフトラーニング)
そのため、設定直後にデータが表示されなくても、すぐに設定ミスと判断しないことが重要です。一方、運用開始後に2時間を超えて継続的にデータが届かない場合は、診断設定、転送先、権限、対象ログカテゴリーを確認します。
マルチテナントアプリの可視範囲を理解する
Microsoft Graph activity logsで収集できるのは、基本的にログを有効化したリソーステナント内の活動です。自社が提供するマルチテナントアプリであっても、別の顧客テナント内で行われたMicrosoft Graphアクセスを、自社テナントのログから確認することはできません。(マイクロソフトラーニング)
SaaS事業者が顧客テナントでの利用状況を監視したい場合は、顧客側でログ収集や共有の仕組みを用意する必要があります。
また、Microsoft Graph activity logsは診断設定の段階ではフィルタリングできません。特定のAppIdだけを選んで転送する、といった設定はできないため、必要に応じてLog Analyticsのワークスペース変換やSIEM側のフィルターを利用します。(マイクロソフトラーニング)
Azure MonitorでMicrosoft Graph activity logsを設定する手順
Log Analyticsへ送信する場合は、次の流れで設定します。メニュー名は、利用するポータルによって若干異なる場合があります。(マイクロソフトラーニング)
- Microsoft Entra ID P1またはP2が利用できることを確認します。
- Azureサブスクリプション内にLog Analyticsワークスペースを作成します。
- Security Administrator以上の権限でMicrosoft Entra管理センターへサインインします。
- 「Entra ID」から「監視と正常性」「診断設定」を開きます。
- 「診断設定を追加」を選択します。
- 分かりやすい診断設定名を入力します。
- ログカテゴリーから
MicrosoftGraphActivityLogsを選択します。 - 転送先として「Log Analyticsワークスペースに送信」を選択します。
- 対象のサブスクリプションとワークスペースを指定します。
- 設定を保存します。
Azure StorageやEvent Hubsへ送信する場合も、事前に転送先を作成したうえで、同じ診断設定画面から選択します。診断設定は複数作成できるため、分析用のLog Analyticsと長期保存用のStorageへ同時に送る構成も可能です。(マイクロソフトラーニング)
最初にログが届いているか確認するKQL
Log Analyticsで、次のクエリを実行します。
MicrosoftGraphActivityLogs
| where TimeGenerated >= ago(24h)
| project
TimeGenerated,
AppId,
ServicePrincipalId,
UserId,
RequestMethod,
RequestUri,
ResponseStatusCode,
DurationMs,
IPAddress
| order by TimeGenerated desc
| take 100データが表示されたら、AppId、ServicePrincipalId、UserIdが想定したアプリやユーザーと一致しているか確認します。
401・403エラーが多いアプリを特定するKQL
認証エラーやアクセス許可不足を調査する場合は、次のように集計できます。
MicrosoftGraphActivityLogs
| where TimeGenerated >= ago(3d)
| where ResponseStatusCode in (401, 403)
| summarize FailedRequests = dcount(RequestId)
by AppId, ServicePrincipalId, UserId
| top 20 by FailedRequests desc401が多い場合は、トークンの有効性や認証処理を確認します。403が多い場合は、Microsoft Graphのアクセス許可、管理者同意、対象リソース側の権限を確認します。
429スロットリングを確認するKQL
Microsoft Graphの呼び出し回数が多すぎるアプリは、HTTP 429を返されることがあります。
MicrosoftGraphActivityLogs
| where TimeGenerated >= ago(3d)
| where ResponseStatusCode == 429
| summarize ThrottledRequests = count()
by AppId, RequestMethod, bin(TimeGenerated, 1h)
| order by ThrottledRequests desc429が継続している場合は、単純な再試行を繰り返すのではなく、アプリ側の取得頻度、差分取得、キャッシュ、バックオフ処理を見直します。
運用開始後に見るべき監視項目
Microsoft Graph activity logsは、収集するだけでは効果がありません。組織の通常状態を把握し、異常時に通知できる状態を作る必要があります。
| 頻度 | 確認項目 | 判断の例 |
|---|---|---|
| 随時・アラート | 401、403の急増 | 資格情報期限切れ、権限変更、不正アクセスの可能性 |
| 随時・アラート | 429の急増 | アプリの過剰なAPI呼び出し |
| 随時・アラート | 未承認AppIdからのアクセス | 想定外のアプリ追加や管理者同意 |
| 日次 | リクエスト数上位のアプリ | 異常なトラフィック増加やループ処理 |
| 日次 | 変更系メソッドの増加 | POST、PATCH、DELETEの異常な増加 |
| 週次 | 応答時間の悪化 | アプリ側の性能問題や大量取得 |
| 月次 | 取り込みデータ量と費用 | 保存期間、ログプラン、変換ルールの見直し |
| 四半期 | ログ閲覧権限 | 異動・退職者、過剰権限の整理 |
アラートのしきい値は、すべての組織で同じ値にするのではなく、通常時のリクエスト数を1～2週間測定してから設定します。たとえば、通常は1時間当たり10件未満の403エラーしかないアプリで100件発生した場合と、日常的に大量処理を行うアプリで100件発生した場合では、重要度が異なります。
今回の更新を受けて取るべき対応
2026年7月4日の更新は、Microsoft Graph activity logsの新機能追加ではなく、ログへ機密情報が残るリスクを明確化したものです。すでに利用している組織は、診断設定そのものより、データの保存場所とログの公開範囲を優先して確認してください。
具体的には、Microsoft Graphから参照できる属性へパスワード、トークン、接続文字列などを保存していないかを調査します。該当する値がある場合は、Azure Key Vaultなどへ移し、資格情報をローテーションします。あわせて、Log Analytics、Azure Storage、Event Hubs、SIEMの閲覧権限と保持期間も確認します。
まだMicrosoft Graph activity logsを利用していない場合は、Microsoft Graphを使うアプリ、外部SaaS、AIクライアントの一覧を作成し、監査やトラブル調査の必要性を判断します。必要性が高い場合は、まずLog Analyticsへ短期間送信して、ログ量、費用、通常のアクセス傾向を把握してから本番運用へ移行するのが現実的です。
コメント