Azure Activity LogのappidがGraphで引けない原因と調べ方｜ResourceNotFound対策とEntraサインインログ活用

Azure の Activity Log やトークンの claims に出てくる appid（GUID）を見て「どのアプリの操作？」と調べたら、Microsoft Graph の /applications や /servicePrincipals が ResourceNotFound…。この記事では、appid の意味、Graphで引ける/引けない境界、サインインログ等での追跡方法を具体例つきで整理します。

まず押さえる：Activity Log に出てくる「appid」は何を指すのか

Azure の Activity Log（操作ログ）や、Azure Portal 操作時のトークン claims に含まれる appid は、多くのケースで 「その操作を実行したクライアント（呼び出し元）アプリの Application ID（Client ID）」 を意味します。つまり、ユーザーが Portal から操作していても、裏では「Azure Portal というアプリ」があなたの代わりに管理 API を呼び出しており、そのクライアント ID が appid として残る、という構図です。

この “アプリ＝犯人” の見方ができる一方で、appid を Graph で引いた瞬間に詰まるのは、appid がディレクトリの「Object ID」ではないこと、そして 常にあなたのテナント内に「アプリ登録」として存在するとは限らないことが原因です。

項目	よく出る場所	意味	実務での使いどころ
appid	トークン claims / Activity Log の claims	呼び出し元アプリの Application ID（client_id）	「どのクライアント経由で実行された操作か」を特定する
aud	トークン claims	呼び出し先（リソース）	「どこに向けたトークンか」を確認し、Portal/管理系かアプリ系かを切り分ける
tid	トークン claims	発行元テナント ID	どのテナントで発行されたトークンか（B2B/外部要素の検討に使う）
oid / upn	トークン claims	実行主体（ユーザー等）	「誰が」実行したかを確認し、appid（どのアプリ経由）とセットで追う

特に aud が「https://management.core.windows.net/」のような管理系リソースになっている場合、appid は “あなたのアプリ” ではなく Azure Portal や内部クライアントであることが多く、/applications で「アプリ登録の詳細」を引けないケースが出やすくなります。

切り分けの第一歩：テナント内に実体があるかを確認する

Graph を叩く前に、まずは GUI で「そもそも自分のテナントにその appid が存在するのか」を確認します。ポイントは App registrations と Enterprise applications（サービスプリンシパル）の両方を見に行くことです。

Microsoft Entra 管理センター → 「アプリの登録（App registrations）」→ 「すべてのアプリケーション」→ Application (client) ID で検索
Microsoft Entra 管理センター → 「エンタープライズアプリケーション（Enterprise applications）」→ Application ID で検索

なぜ両方なのかというと、Entra ID には大きく分けて次の 2 種類のディレクトリオブジェクトがあり、目的が違うからです。

オブジェクト	代表的な場所	役割	appid との関係
Application	App registrations	アプリの設計図（同意要求、リダイレクト URI、証明書、アプリロール等）	appId プロパティとして Application ID（client_id）を持つ
Service principal	Enterprise applications	そのテナントでの “実体”（同意・割り当て・利用の結果として作られる）	こちらも appId を持つ。外部（マルチテナント）アプリは「Service principal だけ存在」しやすい

App registrations で見つからなくても、Enterprise applications で見つかることは珍しくありません。SaaS 連携やマルチテナントアプリ、Microsoft 提供アプリの多くはこのパターンです。

基本の取得方法：テナント内に実体がある場合（Graph で引ける）

テナント内に実体がある場合、Microsoft Graph（Graph Explorer でも可）で appid から詳細情報を引けます。ここでは「Application を引く」と「Service principal を引く」の 2 ルートを紹介します。

Application（App registrations）を appid から取得する

App registrations に存在するアプリであれば、Application オブジェクトを取得できます。ここで一番多いハマりは、appid（client_id）と id（Object ID）を混同することです。

やりたいこと	正しい考え方	よくある失敗
「appid から Application を引きたい」	appid は Application の appId プロパティ	/applications/{appid} に入れて 404（{appid} ではなく Object ID が必要）

appid で引く例（placeholder 版）：

GET https://graph.microsoft.com/v1.0/applications(appId='{appid}')

appid で引く例（実値サンプル）：

GET https://graph.microsoft.com/v1.0/applications(appId='dc807dec-d211-4b3f-bc8a-43b3443c4874')

または、コレクションに対してフィルターする方法も使えます。

GET https://graph.microsoft.com/v1.0/applications?$filter=appId eq 'dc807dec-d211-4b3f-bc8a-43b3443c4874'

取得できたら、まずは次のプロパティを見ると「どのアプリか」の当たりが付きます。

displayName：人間が読む名称
publisherDomain / verifiedPublisher：発行元の手がかり
signInAudience：シングルテナントかマルチテナントか
web / spa / publicClient：アプリ種別のヒント

Service principal（Enterprise applications）を appid から取得する

Activity Log に出てくる appid は、実務上は Service principal 側で追えることが多いです。特に、外部アプリ（マルチテナント）や Microsoft 提供アプリは「Application がテナント内に無い」ことがある一方で、同意や利用実績により Service principal が作られているケースが多いからです。

GET https://graph.microsoft.com/v1.0/servicePrincipals(appId='dc807dec-d211-4b3f-bc8a-43b3443c4874')

フィルターでも可能です。

GET https://graph.microsoft.com/v1.0/servicePrincipals?$filter=appId eq 'dc807dec-d211-4b3f-bc8a-43b3443c4874'

Service principal が取れたら、次を確認します。

displayName：アプリの表示名（サインインログの “アプリケーション” と一致しやすい）
servicePrincipalType：Application / ManagedIdentity / Legacy などの区分
appOwnerOrganizationId：所有元テナントのヒント（外部アプリの場合に効く）
tags：統合アプリを示すタグが付くことがある

Graph で見るときの最小権限の考え方

Graph でアプリ情報を読むには、概ね次のような権限が必要になります（実際の運用では組織ポリシーに合わせてください）。

目的	代表的に必要になる Graph 権限（例）	補足
アプリ（Application）を読む	Application.Read.All	管理者同意が必要なことが多い
サービスプリンシパル（Enterprise app）を読む	Application.Read.All または Directory.Read.All	テナントの設定次第でより広い権限が求められる
サインインログを読む	AuditLog.Read.All	運用監査用途。ログ保持期間にも注意

ここが核心：Request_ResourceNotFound が意味すること

/applications(appId=’…’) や /servicePrincipals(appId=’…’) が Request_ResourceNotFound になるとき、典型パターンは次のいずれかです。

パターン	何が起きているか	起こりやすい場面	次にやること
テナント内にオブジェクトが存在しない	その appid の Application / Service principal があなたのテナントに無い	Microsoft の内部アプリ、テナント外アプリが介在、まだ同意・利用がない	サインインログ／監査ログで “ログから追う” に切り替える
探している対象が違う	appid はクライアントで、実際に知りたいのはリソース側（aud）	Portal 経由の管理操作（aud が management など）	aud と operationName を見て、Azure 側のサービス（Resource Provider）を特定する
権限不足	存在はするが読む権限がなく、結果として見えない	Graph Explorer の委任権限が不足	必要スコープの付与・管理者同意の確認
ログに出ている appid が “代理” のもの	実行主体（ユーザー）と呼び出し元アプリ（Portal 等）が分離している	「人が操作したはずなのに見慣れない appid」が出る	サインインログでユーザーと app をセットで確認し、相関 ID で紐付ける

特に 1 行目が多く、これが質問の「Graph で引けなくて詰む」正体です。Activity Log に出る appid は、あなたが作ったアプリだけとは限りません。Azure Portal の UI 操作に伴って裏で呼ばれるサービスや、Microsoft のファーストパーティアプリ、さらにはテナント外アプリが登場することがあります。

Graph で引けないときの現実解：ログから appid を逆引きする

テナント内に実体がない appid は「アプリ登録の詳細を引く」よりも「ログ上で何者として扱われているか」を把握するのが正攻法です。ここからは、運用で効く追跡ルートを具体例で紹介します。

Entra のサインインログで “アプリ名” を確定させる

サインインログは、appid と アプリの表示名（Application name） が同時に見えるため、最短で「正体」を掴めます。GUI で追う場合は次の観点で絞り込みます。

時間帯（Activity Log の発生時刻±数分）
ユーザー（Activity Log の caller / もしくは claims の oid）
Application ID（appid）
IP アドレス、User-Agent（わかる場合）

プログラムで追う場合は Graph のサインインログ取得を使います（環境によって利用可否・保持期間は変わります）。

GET https://graph.microsoft.com/v1.0/auditLogs/signIns?$filter=appId eq 'dc807dec-d211-4b3f-bc8a-43b3443c4874'

時刻で絞るなら、createdDateTime を合わせます（例）。

GET https://graph.microsoft.com/v1.0/auditLogs/signIns?$filter=appId eq 'dc807dec-d211-4b3f-bc8a-43b3443c4874' and createdDateTime ge 2025-12-01T00:00:00Z and createdDateTime le 2025-12-02T00:00:00Z

サインインログで次の項目が見えると、調査が一気に進みます。

appDisplayName：アプリ名（これが欲しかった情報）
resourceDisplayName：アクセス先（aud に相当）
correlationId：他ログとの突合に使える
conditionalAccessStatus：条件付きアクセスの影響有無
clientAppUsed / deviceDetail：端末やクライアントの手がかり

Activity Log と “相関 ID” でつなぐ

Azure Activity Log には、イベントごとに correlationId（あるいは operationId など）が含まれます。サインインログ側にも correlationId があるため、時間帯だけでなく ID で紐付けできると調査の精度が上がります。

実務では、次の順に突合すると迷いにくいです。

Activity Log でイベントを開き、発生時刻・caller（ユーザー）・claims の appid・correlationId を控える
サインインログで 同時刻帯 かつ 同一ユーザー を検索
サインインログに appid が載っていれば、そのアプリ名を確認
correlationId が一致するか確認（一致すれば確度が高い）

「Activity Log には appid しかなくて、Graph で引けない」という状況でも、サインインログに行けば アプリ名・リソース名・条件付きアクセス結果 まで取れることが多いのが強みです。

Microsoft Graph PowerShell で追う（スクリプト向け）

GUI だと調査が属人化しやすいため、運用では PowerShell で “同じ手順を自動化” するのがおすすめです。ここでは代表例として、サービスプリンシパルの検索と、サインインログの検索を載せます。

# 例：必要なスコープで接続（環境に応じて最小化してください）
Connect-MgGraph -Scopes "Application.Read.All","AuditLog.Read.All"

# Service principal を appId で検索（テナント内にある場合）
Get-MgServicePrincipal -Filter "appId eq 'dc807dec-d211-4b3f-bc8a-43b3443c4874'" |
  Select-Object Id,AppId,DisplayName,ServicePrincipalType

# Application を appId で検索（App registrations にある場合）
Get-MgApplication -Filter "appId eq 'dc807dec-d211-4b3f-bc8a-43b3443c4874'" |
  Select-Object Id,AppId,DisplayName,SignInAudience

# サインインログから逆引き（時間帯も併用）
Get-MgAuditLogSignIn -Filter "appId eq 'dc807dec-d211-4b3f-bc8a-43b3443c4874'" -Top 20 |
  Select-Object CreatedDateTime,AppDisplayName,UserDisplayName,IpAddress,ResourceDisplayName,CorrelationId

出力を CSV 化して “appid → アプリ名” のマッピングを残すだけでも、次回以降の調査コストが激減します。

Log Analytics / Sentinel を使っているなら KQL で一気に絞る

Activity Log と Entra サインインログを Log Analytics ワークスペースに送っている場合、KQL で横断検索できます。例えば、appid と時間帯で Activity Log を拾い、近い時間帯の SigninLogs を併記する例です（テーブル名は環境で異なることがあります）。

let targetAppId = "dc807dec-d211-4b3f-bc8a-43b3443c4874";
let t0 = datetime(2025-12-01 00:00:00Z);
let t1 = datetime(2025-12-02 00:00:00Z);

AzureActivity
| where TimeGenerated between (t0 .. t1)
| where Claims has targetAppId
| project TimeGenerated, OperationName, ResourceId, Caller, CorrelationId, Claims
| join kind=leftouter (
    SigninLogs
    | where TimeGenerated between (t0 .. t1)
    | where AppId == targetAppId
    | project TimeGenerated, AppDisplayName, ResourceDisplayName, UserPrincipalName, IPAddress, CorrelationId
) on CorrelationId
| order by TimeGenerated desc

「Graph で引けない appid」ほど、ログ基盤に載せて横断検索できる価値が大きくなります。調査対象が増える組織ほど、まずログを集約し、KQL で調査できる状態を作るのが王道です。

補足：Managed Identity っぽい appid を見分けるコツ

Activity Log の appid が “自動化っぽい” と感じたら、Managed Identity（マネージド ID）の可能性も疑います。Managed Identity の場合、Service principal の servicePrincipalType が ManagedIdentity になっていることが多く、Graph で引ければ正体が分かります。

ただし、Graph で取れない／情報が薄い場合でも、claims に次のような “追加の手掛かり” が入っていることがあります。

xms_mirid のような値：Azure リソース ID（どのリソースの MI か）の手掛かりになることがある
実行時刻・呼び出し元 IP・操作対象リソース：MI の利用箇所を推定する材料になる

Managed Identity を疑うときは、Azure 側の対象リソース（VM、Functions、Automation、AKS など）の「ID」設定も合わせて確認し、appid の client ID と一致しないか突き合わせるとスムーズです。

見方のコツ：appid と aud をセットで読むと “背景” が見える

appid を追う目的は「誰が何をしたか」を知ることですが、appid だけでは “誰（アプリ）” は分かっても “何（どこに対する操作）” が曖昧なことがあります。そこで重要になるのが aud（リソース）です。

よくある状況	appid（クライアント）	aud（リソース）	読み取りのポイント
Azure Portal からの管理操作	Portal 系のアプリ（Microsoft 提供）	Azure 管理 API（management など）	“人が操作した” でも appid は Portal になりがち。caller とセットで解釈する
自作アプリから Graph を呼ぶ	自作アプリの appid	Microsoft Graph	appid を引けば App registrations の詳細に直結しやすい
自動化（CI/CD / スクリプト）	登録済みアプリ or マネージド ID	管理 API / 対象サービス	servicePrincipalType を見て ManagedIdentity か確認し、紐付くリソースも追う

特に Activity Log の調査では、「appid だけで犯人探しをしない」のがコツです。caller（ユーザー）と aud（リソース）と operationName（何をしたか）を 1 セットで見ると、Portal 由来なのか、自動化なのか、外部アプリなのかを判断しやすくなります。

よくある詰まりポイントと対処チェックリスト

最後に、現場でよく遭遇する “ハマりどころ” をチェックリスト化します。該当する症状から潰していくと、調査が一直線になります。

症状	ありがちな原因	対処
/applications に appid を入れても 404	Object ID と appid を混同している	applications(appId='{appid}’) または $filter=appId eq ‘{appid}’ を使う
App registrations に無い	外部アプリ／Microsoft アプリで、テナント内に Application が無い	Enterprise applications（service principal）側を検索する
servicePrincipals でも見つからない	テナント内に実体が無い（ログ上だけ出ている）	サインインログ・監査ログで appid を検索し、表示名を確定する
Graph は成功するが情報が薄い	必要な情報が Application 側にある／もしくは同意していない	Application と Service principal の両方を取得し、差分を埋める
同じ appid が頻繁に出てノイズに見える	Portal/管理系の “共通クライアント” が使われている	aud と operationName、caller を組み合わせて意味のあるイベントに絞る

運用のすすめ：appid 調査を “毎回ゼロから” にしない

appid の調査は、1 回で終わりません。運用を回すほど「この appid はまた出る」「同じパターンの問い合わせが来る」が増えます。そこで、次の 3 点を仕組みにしておくと楽になります。

よく出る appid のマッピング表を作る

最低限、次の列があると運用が回りやすいです。

appid
推定アプリ名（サインインログの appDisplayName）
用途（Portal / 自動化 / SaaS / 監視など）
関係者（所有チーム、連絡先）

これをスプレッドシートでも Wiki でも良いので残すと、次回以降の調査が「照合」で済みます。

サインインログと Activity Log を Log Analytics に集約する

Graph や GUI は “その場の調査” には向きますが、横断検索や長期分析はログ基盤が強いです。監査要件がある組織ほど、Activity Log とサインインログを同じ基盤で扱えるようにしておくと、インシデント対応が速くなります。

「appid を引く」から「操作を説明できる」へ

最終的に欲しいのは appid の正体だけでなく、その操作が正当か／誰の意図か／再発防止は何かまで説明できる状態です。そのためには、appid だけでなく、caller・aud・操作対象リソース・条件付きアクセス結果・IP/端末情報など、複数の証拠を束ねて判断するのが安全です。

Activity Log の appid が Graph で引けないときほど焦りがちですが、「テナント内に実体があるか」を切り分け、無いならログから逆引きする、という流れを作れば詰まりません。調査手順をテンプレ化しておくと、問い合わせ対応もインシデント対応も安定します。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Azure Activity LogのappidがGraphで引けない原因と調べ方｜ResourceNotFound対策とEntraサインインログ活用

まず押さえる：Activity Log に出てくる「appid」は何を指すのか

切り分けの第一歩：テナント内に実体があるかを確認する

基本の取得方法：テナント内に実体がある場合（Graph で引ける）

Application（App registrations）を appid から取得する

Service principal（Enterprise applications）を appid から取得する

Graph で見るときの最小権限の考え方

ここが核心：Request_ResourceNotFound が意味すること

Graph で引けないときの現実解：ログから appid を逆引きする

Entra のサインインログで “アプリ名” を確定させる

Activity Log と “相関 ID” でつなぐ

Microsoft Graph PowerShell で追う（スクリプト向け）

Log Analytics / Sentinel を使っているなら KQL で一気に絞る

補足：Managed Identity っぽい appid を見分けるコツ

見方のコツ：appid と aud をセットで読むと “背景” が見える

よくある詰まりポイントと対処チェックリスト

運用のすすめ：appid 調査を “毎回ゼロから” にしない

よく出る appid のマッピング表を作る

サインインログと Activity Log を Log Analytics に集約する

「appid を引く」から「操作を説明できる」へ

この記事を書いた人

コメント

コメントするコメントをキャンセル

Azure Activity LogのappidがGraphで引けない原因と調べ方｜ResourceNotFound対策とEntraサインインログ活用

まず押さえる：Activity Log に出てくる「appid」は何を指すのか

切り分けの第一歩：テナント内に実体があるかを確認する

基本の取得方法：テナント内に実体がある場合（Graph で引ける）

Application（App registrations）を appid から取得する

Service principal（Enterprise applications）を appid から取得する

Graph で見るときの最小権限の考え方

ここが核心：Request_ResourceNotFound が意味すること

Graph で引けないときの現実解：ログから appid を逆引きする

Entra のサインインログで “アプリ名” を確定させる

Activity Log と “相関 ID” でつなぐ

Microsoft Graph PowerShell で追う（スクリプト向け）

Log Analytics / Sentinel を使っているなら KQL で一気に絞る

補足：Managed Identity っぽい appid を見分けるコツ

見方のコツ：appid と aud をセットで読むと “背景” が見える

よくある詰まりポイントと対処チェックリスト

運用のすすめ：appid 調査を “毎回ゼロから” にしない

よく出る appid のマッピング表を作る

サインインログと Activity Log を Log Analytics に集約する

「appid を引く」から「操作を説明できる」へ

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル