Microsoft Graph に関する既知の問題

この記事では、Microsoft Graph に関する既知の問題について説明します。

既知の問題を報告するには、Microsoft Graph サポート ページを参照してください。

Microsoft Graph API の最新の更新プログラムについては、「Microsoft Graph の変更ログ」を参照してください。

アプリケーション

アプリケーションおよび servicePrincipal リソースにはいくつかの制限が適用されます

現在、アプリケーションservicePrincipal リソースに対する変更が開発中です。 現在の制限事項と開発中の API 機能の概要を次に示します。

現在の制限事項:

  • 一部のアプリケーション プロパティ (appRoles、addIns など) は、すべての変更が完了するまで利用できません。
  • 登録できるのは、マルチ テナント アプリだけです。
  • アプリの更新は、初期ベータ更新後に登録されたアプリに限定されます。
  • Azure Active Directory ユーザーは、アプリの登録と所有者の追加を行えます。
  • OpenID Connect と OAuth プロトコルをサポートします。
  • アプリケーションへのポリシーの割り当てが失敗します。
  • アプリ ID を必要とする ownedObjects に対する操作 (たとえば、users/{id|userPrincipalName}/ownedObjects/{id}/...) が失敗します。

開発中:

  • 単一テナント アプリを登録する機能。
  • servicePrincipal に対する更新。
  • 更新されたモデルへの既存の Azure AD アプリへの移行。
  • appRoles、事前承認済みクライアント、オプションのクレーム、グループ メンバーシップのクレーム、ブランド化のサポート。
  • Microsoft アカウント (MSA) ユーザーによるアプリの登録。

Azure AD V2.0 エンドポイントは CSP アプリではサポートされていません

クラウド ソリューション プロバイダー (CSP) アプリは、パートナーが管理する顧客で Microsoft Graph を正常に呼び出すために、Azure AD (v1) エンドポイントからトークンを取得する必要があります。 現在、新しい Azure AD v2.0 エンドポイントを介したトークンの取得はサポートされていません。

状況によっては、クラウド ソリューション プロバイダー (CSP) アプリの事前同意が一部の顧客テナントで機能しない可能性があります。

  • 委任されたアクセス許可を使用するアプリでは、新しい顧客テナントで初めてアプリを使用すると、サインイン後に次のエラーを受信する可能性があります: AADSTS50000: There was an error issuing a token
  • アプリケーションのアクセス許可を使用するアプリでは、アプリはトークンを取得できますが、Microsoft Graph を呼び出すときに予期せずにアクセス拒否メッセージを受け取ります。

事前同意をすべての顧客テナントで機能させるために、できるだけ早くこの問題を解決するべく取り組んでいます。

それまでの間、開発とテストのブロックを解除するために次の回避策を取ってください。

注:

これは永続的なソリューションではなく、開発のブロックを解除するためのものです。 問題が解決され後は、この回避策は必要なくなります。 修正プログラムの適用後に、この回避策を元に戻す必要はありません。

  1. Azure AD v2 PowerShell セッションを開き、サインイン ウィンドウに customer 管理者の資格情報を入力してテナントに接続します。 Azure AD PowerShell V2 は、 ここからダウンロードしてインストールできます。

    Connect-AzureAd -TenantId {customerTenantIdOrDomainName}
    
  2. Microsoft Graph サービス プリンシパルを作成します。

    New-AzureADServicePrincipal -AppId 00000003-0000-0000-c000-000000000000
    

Bookings

bookingBusinesses のクエリ時のエラー

組織が複数のビジネスを予約しており、要求を発行するアカウントが管理者でない場合に、bookingBusinesses のリストを取得しようとすると、次のエラー コードのエラーになります:

{
  "error": {
    "code": "ErrorExceededFindCountLimit",
    "message":
      "The GetBookingMailboxes request returned too many results. Please specify a query to limit the results.",
  }
}

回避策としては、query パラメーターを含めることによって、要求から返されるビジネスのセットを制限できます。たとえば:

GET https://graph.microsoft.com/beta/bookingBusinesses?query=Fabrikam

カレンダー

共有された予定表にアクセス時のエラー

別のユーザーによって共有されている予定表で、次の操作によってイベントにアクセスするとします。

GET /users/{id}/calendars/{id}/events

エラー コード ErrorInternalServerTransientErrorで HTTP 500 を取得できます。 エラーは次の理由で発生します。

  • 従来、予定表共有を実装するための 2 つの方法がありました。それらを区別するために、"古い" アプローチと "新しい" アプローチと呼びます。
  • 新しいアプローチは、表示または編集のアクセス許可による予定表の共有に使用できますが、委任のアクセス許可には使用できません。
  • 予定表が新しいアプローチによって共有されている場合のみ、予定表 REST API を使用して、共有された予定表を表示または編集できます。
  • 予定表が古いアプローチによって共有されている場合、予定表 REST API を使用して、このような予定表を表示または編集することはできません。

予定表が表示または編集のアクセス許可で共有されていても、古いアプローチを使用している場合、エラーを回避して手動で予定表共有をアップグレードし、新しいアプローチを使用することができます。 時間の経過とともに、Outlook では共有されているすべての予定表が、委任アクセス許可で共有されている予定表を含め、新しいアプローチを使用できるように自動的にアップグレードされます。

新しいアプローチを使用できるように共有されている予定表を手動でアップグレードするには、以下の手順を実行します。

  1. 受信者は、それまで共有されていた予定表を削除します。
  2. 予定表の所有者は、Outlook on the web、iOS 版 Outlook または Android 版 Outlook で予定表を再共有します。
  3. 受信者は、Outlook on the webを使用して共有予定表を再承認します。 (他の Outlook クライアントをすぐに使用できるようになります)。
  4. 受信者は、新しいアプローチを使用して iOS 版 Outlook または Android 版 Outlook で共有されている予定表を表示可能にすることで、予定表が正しく再共有されていることを確認します。

新しい方法で共有されている予定表は、メールボックス内の別の予定表として表示されます。 予定表 REST API を使用すると、自分の予定表であるかのように、共有予定表のイベントを表示または編集できます。 次に例を示します。

GET /me/calendars/{id}/events

ユーザーのメールボックスでの ICS ベースの予定表の追加とアクセスの部分的なサポート

現在、インターネット予定表サブスクリプション (ICS) に基づく予定表は、部分的にしかサポートされていません。

  • UI を経由して ICS ベースの予定表をユーザーのメールボックスに追加できますが、Microsoft Graph API を経由してこれを行うことはできません。
  • ユーザーの予定表を一覧表示すると、ユーザーの既定の予定表グループ内の各予定表の名前ID プロパティ、または ICS ベースの予定表を含む指定した予定表グループを取得できます。 予定表リソースの ICS URL を保存したり、アクセスしたりすることはできません。
  • また、ICS ベースの予定表のイベントを一覧表示することもできます。

イベントへの大容量ファイル添付時のエラー

委任された権限を持つアプリは、共有または委任されたメールボックスにある Outlook メッセージまたはイベントに大容量ファイルを添付しようとすると HTTP 403 Forbidden を返します。 委任された権限では、メッセージまたはイベントがサインインしているユーザーのメールボックスにある場合にのみ createUploadSession が成功します。

onlineMeetingUrl プロパティは、Microsoft Teams ではサポートされていません

現時点では、Skype 会議 eventonlineMeetingUrl プロパティは、オンライン会議の URL を示します。 ただし、Microsoft Teams の会議イベントの onlineMeetingUrl プロパティは Null に設定します。

ベータ版には回避策が用意されており、イベントonlineMeetingProvider プロパティを使用して、プロバイダーが Microsoft Teams であるかどうかを確認できます。 イベントonlineMeeting プロパティを介して、joinUrl にアクセスできます。

変更通知

ユーザーの作成時とソフト削除時に更新通知が発生する

changeType が [更新済み] に設定されたユーザーの変更に対するサブスクリプションも、changeType の通知を受信します: ユーザーの作成と回復可能な削除を更新しました。

グループの作成時とソフト削除時に更新通知が発生する

changeType が [更新済み] に設定されたグループの変更に対するサブスクリプションも、changeType の通知を受信します: グループの作成と回復可能な削除を更新しました。

チャネル

チャネルを作成する

チャネルを作成するときに、チャネル名に特殊文字を使用する場合、 Get filesFolder API はエラー応答を 400 Bad Request 返します。 チャネルを作成するときは、チャネルの displayName で次のことが行われません。

  • 次のいずれかの特殊文字を含めます: ~ # % & * { } + / \ : <> ? | ‘ ”.
  • アンダースコア (_) またはピリオド (.) で始まるか、ピリオド (.) で終わる。

クラウド コミュニケーション

Microsoft Teams クライアントで [会議の詳細メニューの表示] が使用できない

Microsoft Teams クライアントには、クラウド通信 API を介して作成されたチャネル会議の [ 会議の詳細の表示 ] メニューは表示されません。

連絡先

GET 操作で既定の連絡先フォルダーが返されない

/v1.0 バージョンでは、GET /me/contactFolders にユーザーの既定の連絡先フォルダーは含まれません。

修正プログラムが用意される予定です。 それまでは、回避策として次の連絡先一覧表示クエリと parentFolderId プロパティを使用して、既定の連絡先フォルダーのフォルダー ID を取得できます。

GET https://graph.microsoft.com/v1.0/me/contacts?$top=1&$select=parentFolderId

この要求では、次の処理を行います:

  1. /me/contacts?$top=1 は既定の連絡先フォルダーの連絡先のプロパティを取得します。
  2. &$select=parentFolderId を追加すると、連絡先の parentFolderId プロパティ (既定の連絡先フォルダーの ID) のみが返されます。

ベータ版の連絡先フォルダーから連絡先にアクセスする

以下の 2 つのシナリオで示されているように、/beta バージョンでは、REST 要求 URL で親フォルダーを指定して 連絡先 にアクセスすることができないという問題が発生しています。

ユーザーの最上位レベルの contactFolder からの連絡先にアクセスする:

GET /me/contactfolders/{id}/contacts/{id}
GET /users/{id | userPrincipalName}/contactfolders/{id}/contacts/{id}

contactFolder の子フォルダーに含まれている連絡先にアクセスする:

GET /me/contactFolders/{id}/childFolders/{id}/.../contacts/{id}
GET /users/{id | userPrincipalName}/contactFolders/{id}/childFolders/{id}/contacts/{id}

前の例は、入れ子のレベルの 1 つを示していますが、連絡先は子の子などに入れることができます。

あるいは、以下に示すように、ID を指定するだけで連絡先を 取得 することもできます。これは、/beta バージョンの GET /contacts が、ユーザーのメールボックス内のすべての連絡先に適用されるためです。

GET /me/contacts/{id}
GET /users/{id | userPrincipalName}/contacts/{id}

デルタ クエリ

OData コンテキストが正しく返されない

リレーションシップの追跡では、誤った OData コンテキストが返されることがあります。

スキーマ拡張機能は select と共に返されません

スキーマ拡張機能 (レガシ) は、 $select ステートメントでは返されませんが、$select なしでは返されます。

クライアントはオープン拡張機能を追跡できません。

クライアントはオープン拡張機能または登録済みスキーマ拡張機能の変更を追跡できません。

デバイスとアプリ | デバイスの更新プログラム (Windows 更新プログラム)

展開対象ユーザーへのアクセスと更新はサポートされていません

Intune 経由で作成された 展開 リソースの展開対象ユーザーへのアクセスと更新は、現在サポートされていません。

拡張機能

変更履歴はサポートされていません

変更の追跡 (デルタ クエリ) はオープン拡張機能またはスキーマ拡張機能のプロパティではサポートされていません。

リソースとオープン拡張機能を同時に作成することはできない

管理単位デバイスグループ組織、またはユーザーのインスタンスを作成するのと同時に、オープン拡張機能を指定することはできません。 最初にインスタンスを作成し、次にそのインスタンスの後続の POST 要求でオープン拡張機能データを指定する必要があります。

リソースのインスタンスを作成し、同時にスキーマ拡張機能データを追加することはできない

連絡先イベントメッセージ投稿のインスタンスを作成する場合と同じ操作では、スキーマ拡張機能を指定できません。 リソースのインスタンスを作成してから、そのインスタンスにPATCH 操作を行い、スキーマ拡張機能とカスタム データを追加する必要があります。

スキーマ拡張機能のプロパティ値はリソースのインスタンスごとに 100 に制限されています。

現在、デバイスグループユーザーなどのディレクトリ リソースでは、1 つのリソース インスタンスで設定可能なスキーマ拡張機能のプロパティ値の合計数が 100 に制限されています。

Microsoft Graph エクスプローラーを使用して schemaExtension 定義を更新する場合は、所有者を指定する必要があります

PATCHを使用して、Graph Explorer を使用した schemaExtension を更新する場合は、所有者プロパティを指定し、それを現在の appId 値に設定する必要があります(所有するアプリケーションのappIdである必要があります)。 これは、appId所有者と同じではないクライアント アプリケーションにも当てはまります。

スキーマ拡張プロパティによるフィルター処理はすべてのエンティティ タイプでサポートされているわけではありません

スキーマ拡張プロパティによるフィルター処理 ($filter 式を使用する) は、Outlook エンティティ タイプ - contacteventmessage、または post ではサポートされません。

ファイル (OneDrive)

ユーザーがアクセスする前にユーザーのドライブにアクセスすると、エラーが発生します

ユーザーが自分の個人用サイトにブラウザーでアクセスする前に、Microsoft Graph でユーザーの個人ドライブに初めてアクセスした場合、401 応答になります。

グループ

Microsoft Graph では、グループと Microsoft Teams API にアクセスするために 2 つのアクセス許可 (Group.Read.AllGroup.ReadWrite.All) を公開します。 これらのアクセス許可には、管理者による同意が必要です。 将来的には、ユーザーが同意するグループとチームのための新しいアクセス許可を追加する予定です。

委任またはアプリ専用のアクセス許可をサポートしないグループ API がある

委任されたアクセス許可またはアプリ専用のアクセス許可を使用するアクセスは、コア グループの管理と管理用の API でのみサポートされます。 グループ API の他のすべての機能は、委任されたアクセス許可のみサポートします。

委任されたアクセス許可およびアプリ専用のアクセス許可をサポートするグループの機能の例:

  • グループの作成と削除
  • グループの管理とマネージメントに関するグループ プロパティの取得と更新
  • グループのディレクトリ設定、型、同期
  • グループの所有者とメンバーシップ
  • グループの会話とスレッドの取得

委任されたアクセス許可だけをサポートするグループ機能の例:

  • グループ イベント、写真
  • 外部の送信者、承認済みまたは拒否された送信者、グループのサブスクリプション
  • ユーザーのお気に入り、見えないカウント

Microsoft Graph は Outlook on the web を通して構成されたグループ ポリシーをバイパスする

Microsoft Graph を使用して Microsoft 365 グループを作成および名前付けすると、Outlook on the web で構成されたすべての Microsoft 365 のグループ ポリシーがバイパスされます。

allowExternalSenders プロパティは、統合グループでのみアクセスできます

現在、/v1.0/beta の両方で、POST または PATCH 操作の際にグループの allowExternalSenders プロパティを設定できないという問題が発生しています。

allowExternalSendersプロパティには、統合グループでのみアクセスできます。 GET 操作を含むセキュリティ グループでこのプロパティにアクセスすると、エラーが発生します。

グループ所有者を削除すると、ユーザーもグループ メンバーとして削除されます

チームに関連付けられているグループに対してDELETE /groups/{id}/owners を呼び出すと、[/groups/{id}/members] 一覧からもユーザーが削除されます。 この問題を回避するには、所有者とメンバーの両方からユーザーを削除してから 10 秒待ち、その後メンバーにユーザーを再度追加することをお勧めします。

ID とアクセス

現在、conditionalAccessPolicy API には、POST メソッドと PATCH メソッドを呼び出すための Policy.Read.All 権限への同意が必要です。 将来的には、Policy.ReadWrite.ConditionalAccess 権限により、ディレクトリからポリシーを読み取ることができるようになります。

claimsMappingPolicy API では、次のように、LIST /policies/claimsMappingPolicies メソッドと GET /policies/claimsMappingPolicies/{id} メソッドの Policy.Read.All アクセス許可と Policy.ReadWrite.ConditionalAccess アクセス許可の両方への同意が必要になる場合があります。

  • LIST 操作で取得できる claimsMappingPolicy オブジェクトがない場合、このメソッドを呼び出すにはいずれかのアクセス許可で十分です。
  • 取得する claimsMappingPolicy オブジェクトがある場合、アプリは両方のアクセス許可に同意する必要があります。 同意しない場合は、403 Forbidden エラーが返されます。

将来的には、どちらの権限でも両方のメソッドを呼び出すのに十分になります。

Windows 以外のデバイスは、アプリケーションのアクセス許可を持つアプリによって更新できません

アプリケーションのアクセス許可を持つアプリが 、operationSystem プロパティが ではない Windowsデバイス オブジェクトのプロパティを 、extensionAttributes プロパティとは別に更新しようとすると、 Update device API からエラー コードが返され、"ExtendedAttribute1 以外のプロパティ" というエラー メッセージが返 400 Bad request されます。15 は Windows デバイスでのみ変更できます。 委任されたアクセス許可を使用して、Windows 以外のデバイスのプロパティを更新します。

JSON バッチ処理

入れ子になったバッチはサポートされていません。

JSON のバッチ要求には、入れ子になったバッチは一切含めることはできません。

個々の要求はすべて同期要求とします。

バッチ要求に含まれるすべての要求は同期して実行する必要があります。 存在する場合、respond-async の設定は無視されます。

要求のトランザクション処理はサポートされていません

現在、Microsoft Graph では、個々の要求のトランザクション処理はサポートされていません。 個々の要求の atomicityGroup プロパティは無視されます。

URI は相対 URI である必要があります。

バッチ要求では、常に相対 URI を指定します。 次に、Microsoft Graph では、バッチ URL に含まれるバージョン エンドポイントを使用して、これらの URL を絶対 URL にします。

バッチ サイズが制限されている

現段階では、JSON バッチ要求は 20 個までの個別要求に限られています。

  • バッチ要求の API 部分に応じて、基盤となるサービスは、Microsoft Graph を使用してそれらにアクセスするアプリケーションに影響を与える独自のスロットリング制限を課します。
  • バッチ内の要求は、スロットリング制限に対して個別に評価され、要求が制限を超えると、状態 429 で失敗します。

詳細については、「スロットリングとバッチ処理」をご覧ください。

要求の依存関係が制限されている

個々の要求は、他の個々の要求に依存する場合があります。 現時点では、要求は他の 1 つの要求にのみ依存でき、次の 3 つのパターンのいずれかに従う必要があります。

  • 並列 - 個々の要求は、dependsOn プロパティの依存関係を示しません。
  • 直列 - 個々の要求のすべてが前の個々の要求に依存します。
  • 同じ - dependsOn プロパティの依存関係を示す個々の要求はすべて、同じ依存関係を示します。 : このパターンを使用して行われた要求は順番に実行されます。

JSON バッチ処理が完成に近づくにつれて、これらの制限は削除されます。

メール (Outlook)

委任されたアクセス許可をのあるメッセージに大きなファイルを添付すると失敗する可能性があります

委任された権限を持つアプリは、共有または委任されたメールボックスにある Outlook メッセージまたはイベントに大容量ファイルを添付しようとすると HTTP 403 Forbidden を返します。 委任された権限では、メッセージまたはイベントがサインインしているユーザーのメールボックスにある場合にのみ createUploadSession が成功します。

下書きを作成するためのコメント パラメーターがメッセージ本文の一部にならない

返信または転送用の下書きを作成するためのコメント パラメーター (createReplycreateReplyAllcreateForward) は、結果メッセージの下書き本文の一部にはなりません。

Microsoft Teams でのメッセージ返信チャットの GET

v1.0 エンドポイントとベータ エンドポイントの両方で、 への GET /users/id/messages 応答には、チームまたはチャネルの範囲外で発生したユーザーの Microsoft Teams チャットが含まれます。 これらのチャット メッセージの件名は「IM」です。

レポート

Azure AD アクティビティ レポートのライセンス チェック エラー

有効な AzureAD Premium ライセンスがあり、directoryAuditsignIn、または provisioning Azure AD アクティビティ レポート API を 呼び出すと、次のようなエラー メッセージが表示される場合があります。

{
    "error": {
        "code": "Authentication_RequestFromNonPremiumTenantOrB2CTenant",
        "message": "Neither tenant is B2C or tenant doesn't have premium license",
        "innerError": {
            "date": "2021-09-02T17:15:30",
            "request-id": "73badd94-c0ca-4b09-a3e6-20c1f5f9a307",
            "client-request-id": "73badd94-c0ca-4b09-a3e6-20c1f5f9a307"
        }
    }
}

このエラーは、ユーザー リソースの signInActivity プロパティを取得するときにも発生する可能性があります。たとえば、https://graph.microsoft.com/beta/users?$select=signInActivityです。

このエラーは、断続的なライセンス チェックのエラーが原因で、現在修正に取り組んでいます。 一時的な回避策として、Directory.Read.All アクセス許可を追加します。 この一時的な回避策は、問題が解決された場合は必要ありません。

セキュリティ

Identity Protection セキュリティ アラートは userPrincipalName プロパティを返しません

userPrincipalName プロパティは、Azure AD Identity Protection セキュリティ プロバイダーからのアラート API に対する GET 操作要求への応答で返されなくなりました。 この問題は、他のセキュリティ プロバイダーには影響しません。

回避策として、ユーザー プリンシパル名 (UPN) を取得します。

  1. セキュリティ アラートを要求するか、セキュリティ アラートを一覧表示します。 応答の各セキュリティ アラート レコードの Azure AD ユーザー識別子を抽出します。
  2. Microsoft Graph を呼び出して、Azure AD ユーザー識別子を UPN に解決します。 これにより、アプリケーションに追加のアクセス許可が付与される必要があります。
  3. 結果をマージして、UPN と共にセキュリティ アラート応答の詳細を取得します。 結果をページングする場合は、結果のページごとに手順を繰り返します。

この回避策は、クライアント アプリケーションと PowerShell スクリプトで使用できます。 アラート API を呼び出すクライアント アプリケーションはテナントごとに機能するため、セキュリティ リスクは最小限です。

手順 1: Identity Protection プロバイダーのセキュリティ アラートを取得し、Azure AD ID を抽出する

要求

GET https://graph.microsoft.com/v1.0/security/alerts?$filter=vendorInformation/provider eq 'IPC'&$top=10 

Response

この例では、応答はプロバイダーからのアラートのコレクションです。

注: ここに示す応答オブジェクトは、読みやすさのために短縮されています。

HTTP/1.1 200 OK
Content-type: application/json

{ 
    "value": [ 
    { 
      "activityGroupName": "activityGroupName-value", 
      "assignedTo": "assignedTo-value", 
      "azureSubscriptionId": "azureSubscriptionId-value", 
      "azureTenantId": "azureTenantId-value", 
      "category": "category-value", 
      "closedDateTime": "datetime-value", 
      "userStates": [ 
             { 
                    "aadUserId":"84b80893-8749-40a3-97b7-68513b600544"
              } 
        ]
    }, 
    { 
      "activityGroupName": "activityGroupName-value 2", 
      "assignedTo": "assignedTo-value 2", 
      "azureSubscriptionId": "azureSubscriptionId-value", 
      "azureTenantId": "azureTenantId-value", 
      "category": "category-value", 
      "closedDateTime": "datetime-value", 
      "userStates": [ 
             { 
                    "aadUserId":"5d6059b6-368d-45f8-91e1-8e07d485f1d0" 
              } 
       ] 
     } 
   ] 
} 

応答から、 aadUserIds のコレクションを作成します。 これは、次の手順で要求本文に必要になります。

[ 
        "84b80893-8749-40a3-97b7-68513b600544", 
        "5d6059b6-368d-45f8-91e1-8e07d485f1d0"
]

手順 2: ユーザーの Azure AD ID を UPN に解決する

注:

API を呼び出すには、アプリケーションに追加のアクセス許可を付与する必要があります。 アプリで委任されたアクセス許可を使用している場合は、アクセス許可を付与します User.ReadBasic.All 。 アプリがアプリのアクセス許可を使用している場合は、アクセス許可を付与します User.Read.All

ユーザー ID は、一度に 1 つずつ、または一括で解決できます。 アラートを一覧表示し、それらの結果をページングする場合は、ID を一括で解決することをお勧めします。

単一の aadUserId を解決する

次の例に示すように、 Get user API を使用して、1 つのユーザー オブジェクトとその UPN を取得します。

要求

GET https://graph.microsoft.com/v1.0/users/84b80893-8749-40a3-97b7-68513b600544?$select=id,userPrincipalName 

Response

HTTP/1.1 200 OK
Content-type: application/json

{
    "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#users(id,userPrincipalName)/$entity",
    "id": "84b80893-8749-40a3-97b7-68513b600544",
    "userPrincipalName": "MeganB@contoso.com"
}
一括操作を使用して複数の aadUserIds を解決する

directoryObject: getByIds API を使用して、要求本文の Azure AD ユーザー ID の一覧に基づいて複数のユーザー オブジェクトを取得します。 この例では、手順 1 の aadUserId コレクションを要求本文として使用します。 この一括操作には、最大 999 個の ID を含めることができます。

要求

POST https://graph.microsoft.com/v1.0/directoryObjects/getByIds?$select=id,userPrincipalName
Content-type: application/json   

{
    "ids": [
        "84b80893-8749-40a3-97b7-68513b600544",
        "5d6059b6-368d-45f8-91e1-8e07d485f1d0"
    ]
}

Response

HTTP/1.1 200 OK
Content-type: application/json

{
    "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#directoryObjects(id,userPrincipalName)",
    "value": [
        {
            "@odata.type": "#microsoft.graph.user",
            "id": "84b80893-8749-40a3-97b7-68513b600544",
            "userPrincipalName": "MeganB@contoso.com"
        },
        {
            "@odata.type": "#microsoft.graph.user",
            "id": "5d6059b6-368d-45f8-91e1-8e07d485f1d0",
            "userPrincipalName": "AdeleV@contoso.com"
        }
    ]
}

手順 3: 結果をマージする

手順 1 と手順 2 の応答をマージして ID (アラート応答の aadUserIdgetByIds 応答の ID) に参加し、UPN を含むアラート コレクションを作成できるようになりました。

注:

ベスト プラクティスとして、Microsoft Graph API の調整制限に注意してください。 詳細については、「 Microsoft Graph の調整 guidane」を参照してください。

サイトとリスト (SharePoint)

フォロー/フォロー解除のサイトが SharePoint と同期していない

Microsoft Graph を使用して フォローしているサイト に対してクエリを実行すると、応答の結果が正しくなく、その結果が SharePoint の次のコンテンツの結果と一致しない可能性があります。 一時的な回避策として、 次のユーザーとコンテンツ REST API を使用できます。

チームワーク (Microsoft Teams)

役割でチーム メンバーをフィルター処理することはできません。

他のフィルター GET /teams/team-id/members?$filter=roles/any(r:r eq 'owner') and displayName eq 'dummy' と共に役割クエリ フィルターが機能しない場合があります。 サーバーが BAD REQUESTで返信する場合があります。

役割によってチーム メンバーをフィルター処理する要求には、パラメーターが必要です

役割によってチーム メンバーをフィルター処理する要求は、すべて skipToken パラメーターまたは要求の top パラメターのいずれかを想定しており、両方は必要ありません。 両方のパラメーターが要求で渡された場合、top パラメーターは無視されます。

GET 要求への応答でチャット メンバーの一部のプロパティが見つからない可能性がある

場合によっては、チャットの個々のメンバーの tenantId / email / displayName プロパティが GET /chats/chat-id/members または GET /chats/chat-id/members/membership-id リクエストで入力されないことがあります。

ユーザーが参加しているチームのリストにプロパティがない

me/joinedTeams の API 呼び出しは、チームIDdisplayName、および description プロパティのみを返します。 すべてのプロパティを取得するには、 Get team 操作を使用します。

次の API 呼び出しは、リソース固有の同意権限を必要とするアプリのインストールをサポートしていません。

要求 URL に tenants/{cross-tenant-id} が含まれていると、テナント間共有チャネルにアクセスできない

teams/{team-id}/incomingChannels および teams/{team-id}/allChannels に対する API 呼び出しによって、@odata.id プロパティが返されます。このプロパティを使用すると、チャネルにアクセスしたり、channel オブジェクトで他の操作を実行したりできます。 @odata.id プロパティによって返された URL を呼び出すと、要求がテナント間共有チャネルにアクセスしようとするときに次のエラーで失敗します。

GET /tenants/{tenant-id}/teams/{team-id}/channels/{channel-id}
{
    "error": {
        "code": "BadRequest",
        "message": "TenantId in the optional tenants/{tenantId} segment should match the tenantId(tid) in the token used to call Graph.",
        "innerError": {
            "date": "2022-03-08T07:33:50",
            "request-id": "dff19596-b5b2-421d-97d3-8d4b023263f3",
            "client-request-id": "32ee2cbd-27f8-2441-e3be-477dbe0cedfa"
        }
    }
}

この問題を解決するには、呼び出しによって API がテナント間共有チャネルにアクセスする前に、URL から /tenants/{tenant-id} 部分を削除します。

TeamworkAppSettings のアクセス許可が Azure ポータルに表示されない

TeamworkAppSettings.Read.All と TeamworkAppSettings.ReadWrite.All のアクセス許可は現在ロールアウトされており、Azure Portal ではまだ表示されない可能性があります。 これらのアクセス許可に同意するには、次のように承認要求を使用してください。

GET https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/authorize?client_id={client-app-id}&response_type=code&scope=https://graph.microsoft.com/TeamworkAppSettings.ReadWrite.All

ユーザー

userPrincipalName の番号 (#) 記号をエンコードする

Azure AD B2B を通じて追加されたゲスト ユーザーの userPrincipalName には、多くの場合、番号 (#) 文字が含まれています。 # 記号を含む userPrincipalName (GET /users?$filter=userPrincipalName eq 'AdeleV_contoso.com#EXT#@fabrikam.com' など) で $filter を使用すると、400 Bad request HTTP エラー応答が返されます。 userPrincipalName でフィルター処理するには、UTF-8 相当 (%23)、たとえば GET /users?$filter=userPrincipalName eq 'AdeleV_contoso.com%23EXT%23@fabrikam.com' を使用して # 文字をエンコードします。

作成後にユーザー リソースへのアクセスが遅れる

ユーザーは、ユーザー エンティティの POST ですぐに作成できます。 Microsoft 365 サービスにアクセスするには、まず Microsoft 365 ライセンスをユーザーに割り当てる必要があります。 その場合でも、サービスの分散の性質上、ファイル、メッセージ、およびイベント エンティティが Microsoft Graph APIを通じてこのユーザーに使用できるようになるまで 15 分かかる場合があります。 この間、アプリは HTTP エラー応答を 404 Not Found 受け取ります。

ユーザーのプロフィール写真へのアクセスが制限されている

  1. ユーザーのプロフィール写真の読み取りと更新は、ユーザーがメールボックスを持っている場合にのみ使用できます。 写真の読み取りまたは更新が失敗すると、この例では次のエラーが発生します。

    {
      "error": {
        "code": "ErrorNonExistentMailbox",
        "message": "The SMTP address has no mailbox associated with it."
      }
    }
    
  2. 以前 thumbnailPhoto プロパティを使用して (Azure AD Graph API (非推奨) または AD Connect 同期を使用して) 保存されたいかなる写真もユーザー リソースの Microsoft Graph の写真プロパティを使用してアクセスできなくなります。

  3. Microsoft Graph API の profilePhoto リソース経由でのユーザーの写真の管理は、現時点では Azure AD B2C テナントでサポートされていません。

サインイン セッションの無効化で正しくない HTTP コードが返される

ユーザー: revokeSignInSessions API では、無効化が成功した場合に 204 No content の応答が返され、要求に何かしらの問題がある場合には HTTP エラー コード (4xx または 5xx) が返される必要があります。 ただし、サービスの問題により、この API では 200 OK と常に true のブール値が返されます。 これが修正されるまで、 2xx リターン コードを、単にこの API の成功として受け取ってください。

getByIds リクエストを使用しているときに不完全なオブジェクトが返される

ID のリストからディレクトリ オブジェクトを取得するを使用してオブジェクトを要求することにより、完全なオブジェクトが返される必要があります。 ところが、現在の v1.0 エンドポイントの ユーザー オブジェクトでは、制限された一部のプロパティで返されます。 一時的な回避策として、 $select クエリ オプションと組み合わせて操作を実行すると、より完全な ユーザー オブジェクトが返されます。 この動作は、OData の仕様に従っていません。 この動作は将来的に更新される可能性があるので、関心があるすべてのプロパティを $select= に提供する場合か、将来の重大な変更でこの回避策が許容されている場合のみ、この回避策を使用します。

showInAddressList プロパティが Microsoft Exchangeと同期していません

Microsoft Graphを使用してユーザーにクエリを実行する場合、showInAddressList プロパティは、Microsoft Exchangeに示されているのと同じ状態を示さない場合があります。 この機能は、Microsoft 365 管理センターを使用して Microsoft Exchangeで直接管理し、Microsoft Graphではこのプロパティを使用しないことをお勧めします。

クエリ パラメーター

クエリ パラメーターにいくつかの制限が適用される

クエリ パラメーターには、次の制限が適用されます:

  • 複数の名前空間はサポートされていません。
  • $ref の GET とキャストはユーザー、グループ、デバイス、サービス プリンシパル、アプリケーションではサポートされていません。
  • @odata.bind はサポートされていません。 つまり、グループの acceptedSenders または rejectedSenders ナビゲーション プロパティを適切に設定することはできません。
  • @odata.id は最低限のメタデータを使用する場合、非包含構造のナビゲーション (メッセージなど) には存在しません。
  • $expand:
    • 最大 20 個のオブジェクトを返します。
    • @odata.nextLink はサポートされていません。
    • 1 レベルを超える展開はサポートされていません。
    • 余分なパラメーターはサポートされていません ($filter$select)。
  • $filter:
    • /attachments エンドポイントは、フィルターをサポートしていません。 存在する場合、$filter パラメーターは無視されます。
    • ワークロード間でのフィルターはサポートされていません。
  • $search:
    • フルテキスト検索はメッセージなどのエンティティのサブセットに対してのみ使用できます。
    • ワークロード間での検索はサポートされていません。
    • Azure AD B2C テナントでは検索はサポートされていません。
  • $count:
    • Azure AD B2C テナントではサポートされていません。
    • ディレクトリ リソースに対してクエリを実行するときに $count=true クエリ文字列を使用すると、@odata.count プロパティはページングされたデータの最初のページにのみ表示されます。
  • 要求で指定されたクエリ パラメーターは警告なしで失敗する可能性があります。 これは、クエリ パラメーターがサポートされていない場合や、クエリ パラメーターの組み合わせがサポートされていない場合に起こり得ます。

Office 365 REST と Azure AD Graph API でのみ使用可能な機能 (非推奨)

Microsoft Graph では一部の機能はまだ利用できません。 探している機能が表示されない場合は、エンドポイント固有の Office 365 REST API を使用することができます。 Azure AD Graph については、「Azure Active Directory (Azure AD) Graph アプリを Microsoft Graph に移行する」を参照してください。