Microsoft Entra ID｜外部テナントIDから企業名・ドメインを特定する4つの方法（ポータル・Graph API・PowerShell・Lighthouse）

外部の企業とB2Bコラボレーションを進めていると、サインインログに出てくる「Resource Tenant ID（GUID）」だけでは相手先がどの企業なのか分からず、インシデント対応やレビューの手戻りが発生しがちです。本記事では、Azure AD（現 Microsoft Entra ID）の外部テナント ID からフレンドリ名（組織名）やプライマリドメインを素早く特定する実務的な方法を、GUI・Graph API・PowerShell・MSP向けの4パターンで体系的に整理します。運用に落とし込むためのベストプラクティスやスクリプト例、よくある落とし穴も網羅します。

質問概要

Microsoft Entra ID のサインインログや監査ログには、B2B コラボレーションで接続した先の外部組織について Resource Tenant ID（GUID） しか表示されないことがあります。そのため、「この GUID はどの企業のテナントなのか？プライマリドメインは？」 を即座に判定できず、調査が停滞します。ここでは、テナント ID から テナント名（フレンドリ名）／プライマリドメイン を導出する実用手段をまとめます。

解決策の全体像（比較表）

方法	必要ライセンス	特徴・手順	補足
① ポータル GUI で確認	無料（Azure AD Free）	Entra ID ポータル → 外部 ID → クロステナントアクセス設定「組織を追加」ボタンでテナント ID（GUID）を貼り付ける即座にフレンドリ名とプライマリドメインが自動解決過去に交流のある組織なら検索窓に GUID を入れても解決可	最も手軽。権限追加やスクリプト不要
② Microsoft Graph API `GET /tenantRelationships/findTenantInformationByTenantId(tenantId='{ID}')`	P1/P2 不要（アプリ権限が必要）	アプリ登録で `CrossTenantInformation.ReadBasic.All`（Application）を付与し管理者同意アクセストークンで上記エンドポイントを呼び出しレスポンスの `displayName` と `defaultDomainName` を取得	自動化・一括解決に最適。ジョブ化・CI/CDとも相性良し
③ PowerShell（MSIdentityTools） `Get-MsIdCrossTenantAccessActivity`	Entra ID P1/P2	必要モジュールをインストールコマンドに対象テナント ID を渡して実行出力にフレンドリ名／ドメインが含まれる	運用端末からのスポット照会に便利（要 P1/P2）
④ パートナーセンター / Azure Lighthouse	CSP / MSP 契約	マネージドサービス事業者はパートナーセンター上で紐づくテナント一覧を参照可能	一般組織には非現実的。MSP 向け

結論（最速でやるなら）

単発で素早く調べるだけなら「① ポータル GUI」が最短です。
一方で、継続的運用や自動化、ログ解析パイプラインに組み込みたいなら「② Graph API」がベスト。PowerShell は P1/P2 前提なので、組織のライセンス事情で使い分けるのが合理的です。

方法①：ポータル GUI でテナント名を即時解決

手順（数十秒）

管理ポータルで 外部 ID → クロステナントアクセス設定 に移動。
「組織を追加」をクリックし、表示されたテキストボックスに テナント ID（GUID） を貼り付け。
貼り付け直後に フレンドリ名 と プライマリドメイン が自動解決されます（入力途中でも解析されます）。
既に交流履歴のある外部組織は、上部の検索窓に GUID を入力しても同様に解決されます。

メリット

追加のロールや権限設定が不要。技術ハードルが最も低い。
管理者でなくても、該当ブレードの閲覧権限があれば利用可能。
誤入力を防げる（自動補完で視認性が高い）。

注意点

大量の GUID を一括で解決する用途には不向き（人手作業のため）。
追加画面で名前が解決されても、実際に保存しなければ設定は変わりません（確認だけで閉じればOK）。
一部の特殊 GUID（Microsoft 社内サービスなど）は 「Microsoft Services」 と表示されます（仕様。後述）。

方法②：Microsoft Graph API で確実・自動化

最もスケーラブルな方法です。バッチ処理や SOAR、SIEM 連携、ETL の途中で GUID → displayName / defaultDomainName を解決できます。

必要な準備

アプリ登録（自組織テナント）
CrossTenantInformation.ReadBasic.All（Application）の許可を追加し、管理者同意
クライアント資格情報（シークレットまたは証明書）

呼び出しエンドポイント

GET /v1.0/tenantRelationships/findTenantInformationByTenantId(tenantId='{GUID}')

完全な URL 例（自動リンク防止のため一部エスケープ）：
https://graph.microsoft.com/v1.0/tenantRelationships/findTenantInformationByTenantId(tenantId='{GUID}')

cURL の例

# アプリ資格情報でアクセストークンを取得（OAuth 2.0 Client Credentials）
# 取得済みのアクセストークンを {TOKEN} にセットして実行
curl -s -H "Authorization: Bearer {TOKEN}" \
  "https:&#47;&#47;graph.microsoft.com&#47;v1.0&#47;tenantRelationships&#47;findTenantInformationByTenantId(tenantId='{GUID}')" | jq .

サンプル応答（整形済み）

{
  "tenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "displayName": "Contoso Ltd.",
  "defaultDomainName": "contoso.onmicrosoft.com"
}

PowerShell（アプリ資格情報）の例

# 前提：アプリに CrossTenantInformation.ReadBasic.All（Application）を付与し管理者同意済み
$TenantId   = "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"  # 自組織（トークン発行側）のテナント
$ClientId   = "11111111-2222-3333-4444-555555555555"
$ClientSecret = (Read-Host -AsSecureString "Client Secret") | ConvertFrom-SecureString -AsPlainText

$body = @{
client_id     = $ClientId
client_secret = $ClientSecret
scope         = "[https://graph.microsoft.com/.default](https://graph.microsoft.com/.default)"
grant_type    = "client_credentials"
}

$token = Invoke-RestMethod -Method Post -Uri "[https://login.microsoftonline.com/$TenantId/oauth2/v2.0/token](https://login.microsoftonline.com/$TenantId/oauth2/v2.0/token)" -Body $body
$auth  = @{ Authorization = "Bearer $($token.access_token)" }

$TargetTenantId = "ffffffff-1111-2222-3333-444444444444"  # 解決したい外部テナントの GUID
$url = "[https://graph.microsoft.com/v1.0/tenantRelationships/findTenantInformationByTenantId(tenantId='$TargetTenantId')](https://graph.microsoft.com/v1.0/tenantRelationships/findTenantInformationByTenantId%28tenantId='$TargetTenantId'%29)"

$result = Invoke-RestMethod -Headers $auth -Uri $url -Method Get
$result | Format-List

一括解決（CSV → CSV）サンプル

ログから抽出した GUID リスト（列名 TenantId）を入力し、TenantId,DisplayName,DefaultDomain の CSV を出力します。

# input.csv（例）
# TenantId
# ffffffff-1111-2222-3333-444444444444
# aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee

$in  = Import-Csv ".\input.csv"
$out = @()

foreach ($row in $in) {
$tid = $row.TenantId
$url = "[https://graph.microsoft.com/v1.0/tenantRelationships/findTenantInformationByTenantId(tenantId='$tid')](https://graph.microsoft.com/v1.0/tenantRelationships/findTenantInformationByTenantId%28tenantId='$tid'%29)"
try {
$res = Invoke-RestMethod -Headers $auth -Uri $url -Method Get
$out += [pscustomobject]@{
TenantId       = $tid
DisplayName    = $res.displayName
DefaultDomain  = $res.defaultDomainName
}
} catch {
$out += [pscustomobject]@{
TenantId       = $tid
DisplayName    = "N/A"
DefaultDomain  = "N/A"
}
}
}

$out | Export-Csv ".\resolved-tenants.csv" -NoTypeInformation -Encoding UTF8

よくあるエラーと対処

403 Forbidden / insufficient privileges：アプリに CrossTenantInformation.ReadBasic.All（Application）が無い、または管理者同意が未実行。
404 Not Found：GUID のタイプミス、もしくは無効／削除済みテナント。
Microsoft Services と表示：Microsoft 社内サービス（例：共有チャットや一部のマルチテナントサービス）を示す GUID。仕様です。

方法③：PowerShell（MSIdentityTools）で対話的に解決

PowerShell モジュール MSIdentityTools を用いると、運用端末から手早く照会できます。P1/P2 ライセンス前提のため、組織の契約と合わせて検討してください。

インストール例

# 管理者権限の PowerShell
Install-Module Microsoft.Graph.Authentication -Scope AllUsers -Force
Install-Module MSIdentityTools -Scope AllUsers -Force

実行例

# 対象 GUID を一件解決
$tid = "ffffffff-1111-2222-3333-444444444444"
Get-MsIdCrossTenantAccessActivity -TenantId $tid | Format-List

# 複数 GUID（配列）を一括解決

$ids = @(
"ffffffff-1111-2222-3333-444444444444",
"aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"
)
$ids | ForEach-Object {
Get-MsIdCrossTenantAccessActivity -TenantId $_
}

向いている使い方

運用チームが都度ログから拾った GUID を対話的に確認する。
調査端末に PowerShell 環境が既に整っている。

注意点

P1/P2 ライセンスが必要（手元検証でも必須）。ライセンスが無い場合は方法①か②を選択。
モジュールのバージョン差異によりコマンド名・パラメータが変わることがあります。運用前にテスト環境で整合性確認を。

方法④：パートナーセンター / Azure Lighthouse（MSP向け）

マネージドサービスプロバイダー（CSP/MSP）はパートナーセンターや Azure Lighthouse を通じ、委任管理中の顧客テナントに関するメタデータを参照できます。これにより、顧客側テナント ID → 顧客名 の突合が容易です。ただし一般組織には適用できないため、MSP 業務限定の選択肢と考えてください。

運用上のポイント・注意事項

ライセンス不足時の迂回策

PowerShell が使えない／P1/P2 が無い場合は、方法①（GUI）か方法②（Graph API）で回避可能です。単発なら GUI、継続なら Graph API を選びましょう。

「Microsoft Services」と解決されるケース

GUID が Microsoft の共通サービスを示す場合、テナント名は Microsoft Services と返ります。ログ解析時に企業特定はできませんが、悪性の兆候ではなく仕様です。ノイズとして台帳に明記しておくと再調査を省けます。

シングルファクタでの成功サインインが見える理由

外部テナント側で MFA が強制されていない。
トークンキャッシュ／セッションが有効で、追加要素が省略された。

自社側で 条件付きアクセス（CA）を構成し、信頼できる外部組織のみ許可＋MFA 要件の強制 を組み合わせることで、外部依存のリスクを補完できます。

GUID 管理のベストプラクティス

頻出する外部テナントは GUID ⇔ 企業名 ⇔ プライマリドメイン を台帳管理（スプレッドシートや CMDB）。
ログ基盤（SIEM/Sentinel など）に ルックアップテーブル をプリロードし、可読化を自動化。
例外（Microsoft Services など）はタグを付与して誤検知を抑制。

実装ノウハウ（現場で差がつくポイント）

ログ可観測性：Home/Resource の両方を見分ける

サインインログには Home Tenant（ユーザーの所属元）と Resource Tenant（アクセス先）が登場します。企業名の解決は通常 Resource 側に対して実施しますが、異常判定やアクセス経路の追跡では 両方の GUID を台帳と突合して俯瞰するのが有効です。

ルールベース可視化：ダッシュボードの変換規則

可視化ツール上で GUID → 名前 をリアルタイム置換する式（カスタム関数）を用意し、初見の GUID は API で遅延解決→キャッシュ の流れを自動化します。API 呼び出しはレートリミットを考慮し、結果を24～72時間キャッシュする設計が現実的です。

組織名の揺れ対策

displayName は企業のリブランディング等で変更される可能性があります。
defaultDomainName（*.onmicrosoft.com）は比較的安定。台帳キーは両者を保持するのがおすすめです。
独自カスタムドメイン（contoso.com など）は後付け・削除があり得るため、プライマリ（onmicrosoft）を主キーに据えると頑健です。

テナント種別の見分け（B2C / National Cloud）

Azure AD B2C の GUID を解決すると、displayName が B2C 用の名称で返ることがあります。外部 SaaS と誤認しないよう台帳に種別フィールドを。
National Cloud（政府系） はエンドポイントやポリシーが異なる場合があります。グローバルクラウド前提の自動化を流用する際は十分に分離検証を。

セキュリティ設計：信頼できる外部組織のみ許可する

外部コラボレーションを安全に保つには、クロステナントアクセス設定 と 条件付きアクセス を組み合わせ、以下のような方針を採ると堅牢です。

目的	推奨設定	ポイント
外部組織のホワイトリスト化	クロステナントアクセスの組織ごとの既定で許可／拒否を明示	GUID が判明していれば事前登録し、未知の組織をデフォルト拒否へ
MFA 要件の担保	CA ポリシーで外部ユーザーに MFA と準拠デバイス／条件を要求	相手先の MFA 依存を避け、自社側でガードレールを確立
アプリごとの制御	ミッションクリティカルなアプリは外部アクセスを信頼組織のみに限定	ワークロード単位の最小権限化でリスク限定

トラブルシューティング集

名前が解決しない／空で返る

GUID が無効（削除済みテナント）や誤っている。
Graph の権限不足。アプリ許可と管理者同意を再確認。
一時的なエラー。指数バックオフで再試行実装を。

レートリミットを踏む

バッチ処理に スロットリング制御と 結果キャッシュを実装。
1ジョブあたり N レコードを上限に分割し、夜間窓で処理。

GUI と API で名前が違う

displayName の更新タイミング差。時間をおいて再確認。
キャッシュ済み台帳が古い。TTL ルールで自動更新を。

運用テンプレート（コピペで使える）

台帳の基本列

列名	説明	例
TenantId	外部テナント GUID（主キー）	ffffffff-1111-2222-3333-444444444444
DisplayName	フレンドリ名	Contoso Ltd.
DefaultDomain	プライマリ（`*.onmicrosoft.com`）	contoso.onmicrosoft.com
Aliases	独自カスタムドメイン（任意）	contoso.com; contoso.co.jp
Type	種別（企業／B2C／MS Services など）	Enterprise
LastVerifiedAt	最終検証日時	2025-10-01T09:00:00Z
Note	補足（契約情報や窓口など）	パートナー部門経由

Sign-in ログからの抽出 → 解決 → 可視化の流れ

SIEM で ResourceTenantId を抽出しユニーク化。
Graph API バッチで解決し、ルックアップテーブルを更新。
ダッシュボードで GUID 表示を DisplayName に置換（未解決は自動解決キューへ）。

KQL 例（Sentinel などでの疑似処理イメージ）

// 疑似ルックアップ例（Lookup テーブル名: TenantDirectory）
SigninLogs
| summarize by ResourceTenantId
| join kind=leftouter TenantDirectory on $left.ResourceTenantId == $right.TenantId
| project ResourceTenantId, DisplayName, DefaultDomain

FAQ（よくある質問）

Q. GUID が「Microsoft Services」になるのは異常？

A. 仕様です。マルチテナントの Microsoft サービスに紐づく GUID で、特定の企業を表していません。台帳に例外として登録しましょう。

Q. B2C テナントや検証用テナントも解決できる？

A. できます。displayName が B2C 用の名称で返ることがあるため、Type 列で区別してください。

Q. ドメインをキーに企業同定はできる？

A. defaultDomainName（*.onmicrosoft.com）は安定ですが、表示名は変更され得ます。TenantId を唯一の主キーにし、名前・ドメインは属性として保持しましょう。

Q. 権限は最小化できる？

A. CrossTenantInformation.ReadBasic.All のみで十分です（アプリ権限）。読み出し専用であり、最小権限の原則に沿います。

Q. 大量解決のベストプラクティスは？

A. 24～72 時間のキャッシュ、指数バックオフ、ジョブ分割、構成管理（結果の再現性）を組み合わせると安定運用できます。

サンプル：GUI と API を組み合わせた“現実解”

運用チームは日常調査で GUI を使い、即時確認。
セキュリティ基盤は毎晩のバッチで Graph API による未解決 GUID の一括解決を実行。
結果を台帳へ反映し、ダッシュボードはフレンドリ名表示をデフォルトに。
例外（Microsoft Services やエラー）は キューに送り、翌バッチで再試行。

付録：Graph SDK（.NET）の呼び出し例

// 依存関係：Microsoft.Graph, Microsoft.Kiota.Abstractions など
// App-only（Client Credentials）でトークンを取得する前提
var result = await graphClient
  .TenantRelationships
  .FindTenantInformationByTenantIdWithTenantId("{GUID}")
  .GetAsync();

Console.WriteLine($"{result?.DisplayName} / {result?.DefaultDomainName}");

付録：運用チェックリスト

［　］ 台帳の主キーは TenantId（displayName は従属性）
［　］ GUI／API／PS の 3レーンを用意（役割ごとに使い分け）
［　］ API 呼び出しは 権限最小化＋管理者同意の棚卸し
［　］未解決 GUID の 自動解決キューと 再試行（指数バックオフ）
［　］ Microsoft Services の特例運用を明記
［　］ CA ポリシーで外部組織＋MFA を担保
［　］ルックアップ結果の TTL と再検証（24～72h）

まとめ

最速で確認したいなら ポータル GUI（外部 ID → 組織追加） がベスト。
自動化したいなら Graph API。P1/P2 不要でジョブ化に向く。
PowerShell は P1/P2 前提。運用端末からのスポット照会に便利。
いずれの方法でも テナント ID さえ分かれば企業名は取得可能。台帳化・可視化・CA の三点セットで、ログ解析とセキュリティ対応を加速できます。

参考スニペット：よく使う文字列

用途	文字列（自動リンク防止のため一部エスケープ）
Graph ベース URL	`https://graph.microsoft.com/`
トークン発行 URL（v2.0）	`https://login.microsoftonline.com/{TenantId}/oauth2/v2.0/token`
テナント情報解決	`/v1.0/tenantRelationships/findTenantInformationByTenantId(tenantId='{GUID}')`

補足：安全な検証手順（変更加速に強い）

本記事の手順は変更に強い抽象度で記載していますが、運用前に次の流れで事前検証することを推奨します。

テスト用サンドボックスでアプリ登録・権限付与を再現。
複数の既知 GUID（自社／検証用／Microsoft Services）を用意して期待結果を定義。
GUI・API・PS の 3系統すべてで同じ結果になることを確認。
本番テナントでは最小権限・監査ログ記録・ローテーション（シークレット/証明書）を徹底。

最後に：すぐ使える“導入キット”

GUI 手順カード：外部 ID → クロステナント → 組織を追加 → GUID 貼付 → 名前確認 → 閉じる
API 手順カード：アプリ登録 → CrossTenantInformation.ReadBasic.All（App）→ 管理者同意 → client credentials → GET 呼び出し
PS 手順カード：モジュール導入 → Get-MsIdCrossTenantAccessActivity → GUID 入力 → 確認
台帳テンプレート：TenantId／DisplayName／DefaultDomain／Type／LastVerifiedAt／Note

これらをチーム内でカード化・標準手順として共有しておけば、誰が当番でも同じ品質で判定・記録ができ、インシデント時の初動を平準化できます。

この記事を書いた人

佐藤健司

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