Microsoft Graph Delta Queries を使いこなす完全ガイド
By Mirko Peters ·
Microsoft Graph Delta Queries は、Microsoft 365 アプリケーションにおけるデータ同期のあり方を大きく変えます。データセット全体をダウンロードする代わりに、変更内容を効率よく追跡し、前回の更新以降に変更された分だけを要求できます…
Automatically translated with AI from the original post. Read the English original
Microsoft Graph Delta Queries は、Microsoft 365 アプリケーションにおけるデータ同期のあり方を大きく変えます。データセット全体をダウンロードする代わりに、変更内容を効率よく追跡し、前回の更新以降に変更された分だけを要求できます。このアプローチはネットワークトラフィックを抑えるだけでなく、アプリケーションのパフォーマンスも向上させます。開発者や IT 担当者は、API の使用量を減らし、ユーザー体験を高められます。Delta Queries を使えば、システムに過度な負荷をかけることなく、アプリケーションを応答性が高く最新の状態に保てます。
重要なポイント
- Microsoft Graph Delta Queries を使うと、データをすべて再ダウンロードすることなく、変更を追跡できます。
- Delta Queries を使うとネットワークトラフィックが減り、アプリケーションの高速化と効率化につながります。
- Delta Queries によって API の使用量が減り、コストの削減とパフォーマンスの向上に役立ちます。
- アプリケーションからユーザーへの更新を素早く提供でき、ユーザー体験が向上します。
- Delta Queries を実装すると増分更新が可能になり、変更された部分だけを更新できます。
- Delta Queries の利用を始めるには、Azure Active Directory でアプリを作成して承認します。
- 変更の追跡を効率よく続けるため、最初のリクエストの後に必ず deltaLink を保存してください。
- Delta Queries と webhook を組み合わせると、リアルタイムな更新とパフォーマンスの向上が得られます。
Delta Queries の概要
Microsoft Graph Delta Queries の主な機能
Microsoft Graph Delta Queries は、リソース全体を取得することなく、リソースの変更を照会できる強力な仕組みです。この機能は、追加、削除、更新などの変更を効率よく追跡する場合に特に役立ちます。Delta Queries を使うと、データ同期のプロセスを効率化し、アプリケーションのパフォーマンスを高められます。
同期に Microsoft Graph Delta Queries を使う利点は、次のように数多くあります:
効率性: Delta Queries を使うと、前回のリクエスト以降の変更分だけを取得できます。取得するデータ量を大幅に減らせるため、頻繁な更新が必要なアプリケーションで特に有効です。
API 使用量の削減: 取得するデータを最小限に抑えることで、API の使用量を減らせます。これによりコストを削減でき、アプリケーションは関連する変更の処理に集中できるため、パフォーマンスも向上します。
ユーザー体験の向上: Delta Queries を使えば、アプリケーションの応答性を保てます。ユーザーはより早く更新を受け取れるため、全体的な体験が向上します。これは、Microsoft Teams のようなコラボレーションツールや、SharePoint のようなドキュメント管理システムなど、リアルタイムのデータが重要な環境で特に重要です。
増分更新: Delta Queries では増分更新を実装できます。データセット全体を再読み込みする代わりに、変更された部分だけを効率よく更新できます。この機能は、システムに負荷をかけずに最新のデータを維持するうえで欠かせません。
エンタープライズ環境では、変更の即時通知が不要な場合に Delta Queries が特に有効です。新規または更新されたオブジェクトのみを効率よく取得できます。たとえば、SharePoint Online の Teams のような一覧を表示する必要がある場合、不要なオーバーヘッドを避けながら、必要なメタデータを取得できます。
さらに、デルタクエリを使うと、前回のチェック以降に変更された項目だけを照会できるため、従来のポーリング方式よりも効率的です。変更イベントをすぐにプッシュするWebhook通知と組み合わせると、リソースを大量に消費する全件スキャンを行わずに、最新のセマンティックキャッシュを維持できます。
Microsoft Graph デルタクエリの設定

初回リクエストと同期
Microsoft Graph デルタクエリを使い始める前に、いくつかの前提条件を満たす必要があります。次の作業を行ってください。
- アプリを作成する: このアプリが、アプリケーションから Microsoft Graph を呼び出すためのインターフェースになります。
- アプリを承認する: 同期したいデータにアクセスするために必要なアクセス許可がアプリにあることを確認してください。
- Azure でアプリを確認する: アプリが Azure に正しく登録され、構成されていることを確認してください。
- フローを計画する: データ同期のプロセスをどのように処理するかを決めてください。
- ストレージを構成する: 取得した変更を追跡するためのストレージを設定してください。
これらの前提条件が整ったら、デルタクエリの初回リクエストに進めます。まず、Azure Active Directory にアプリケーションを登録します。登録後、サンプルアプリケーションを正しく構成するために、appsettings.json ファイルにクライアント ID を設定してください。
初回の同期では、ユーザー アカウントやグループなど、特定のスキーマの種類に対してクエリを実行します。このクエリは、スキーマの種類の完全な一覧と、クエリ実行時点のデータの状態を反映したステート トークンを返します。以降のクエリでは、このステート トークンを使って、前回のリクエスト以降に変更されたオブジェクトのみを取得します。この方法により効率的な増分同期が可能になり、アプリケーションは必要な更新だけを処理できます。
Microsoft Graph デルタクエリを設定する際は、認証とアクセス許可も検討する必要があります。以下は重要なセキュリティに関する考慮事項です。
| トピック | HTTP エラー コード | ベスト プラクティス |
|---|---|---|
| ユーザーにアクセス権がない | 403 | 権限のないユーザーには、汎用的な「アクセスが拒否されました」というエラーを表示します。 |
| 見つからない | 404 | 存在しない、または削除されたリソースも考慮してください。 |
| スロットリング | 429 | スロットリングの応答には必ず対処し、バックオフ戦略を実装してください。 |
これらの手順とベスト プラクティスに従うことで、Microsoft Graph デルタクエリを効果的に設定できます。この設定により、アプリケーションはデータを効率的に同期でき、パフォーマンスとユーザー体験の向上につながります。
グループのデルタ変更に対するデルタクエリの実行
Microsoft Graph での変更の追跡
グループのデルタ変更を効果的に追跡するには、後続のリクエストを実行するための構造化されたプロセスに従う必要があります。まず、次のエンドポイントを使用して、グループメンバーシップの変更に対するデルタクエリを開始します。
https://graph.microsoft.com/v1.0/groups/delta?$select=membersInvoke-MgGraphRequest メソッドを使用すると、このリクエストを実行して結果を取得できます。このメソッドを使うと、Microsoft Graph API をスムーズに操作できます。
最初のリクエストの後、応答には @odata.nextLink と @odata.deltaLink という 2 つの重要なリンクが含まれる場合があります。これらのリンクの扱い方は次のとおりです。
@odata.nextLinkは、さらにページのデータがあることを示します。すべての項目を取得するには、このリンクをたどり続けてください。@odata.deltaLinkは、最後のページのデータを受け取った後に保存してください。このリンクにより、次の同期を前回の終了位置から開始できます。グループ全体の再同期を避けるために、deltaLink を永続的なストレージに保存しておくことが重要です。これこそがデルタクエリを使う主な目的です。
後続のリクエストでは、前回の応答にあった @odata.deltaLink を使って変更の追跡を続けてください。この方法により、前回の同期以降の変更だけを取得でき、データ取得のプロセスが最適化されます。
応答を処理する際は、さまざまな形式に遭遇することがあります。一般的な応答形式は次のとおりです。
- ユーザー コレクション オブジェクトとともに、
200 OKの応答コードが返されます。 @odata.nextLinkURL が存在する場合、データの追加ページがあることを示します。@odata.deltaLinkURL は、利用可能なデータの終わりを示します。
デルタ クエリで返される変更の量を効率的に管理するために、次のベスト プラクティスの実装を検討してください。
- サービスの中断を避けるために、適切なレート制限とスロットリングの仕組みを実装してください。
- 429 エラーが発生した後のリクエストの再試行には、指数バックオフを使用してください。
- バッチ要求を使用して複数の操作を 1 つの要求にまとめ、API 呼び出しの回数を減らしてください。
- キューの仕組みを作成して要求を管理し、許可された上限内に収まるようにしてください。
- 頻繁にアクセスされるデータをキャッシュして、API 呼び出しを減らし、応答性を高めてください。
$selectや$filterなどのクエリ パラメーターを最適化して、ペイロード サイズを最小限に抑えてください。
これらの戦略に従うことで、アプリケーションがグループのデルタ変更を効率的に処理し、最適なパフォーマンスを維持できるようになります。
デルタ クエリでよくある課題
Microsoft Graph のデルタ クエリを使用すると、アプリケーションのパフォーマンスと信頼性に影響するいくつかの課題に直面することがあります。これらの課題を理解しておくと、効果的な解決策を実装しやすくなります。
よくある問題の 1 つは、デルタ トークンの有効期間が限られていることです。トークンは期限切れになることがあり、同期が複雑になります。アプリケーションがトークンを適時に更新しないと、重要な変更を見逃す可能性があります。また、SharePoint のユーザー スキルなど、メインのデータ ストア外に保存されているプロパティへの変更は、デルタ クエリでは追跡されません。この制限により、データの同期が不完全になる可能性があります。
もう 1 つの課題は、処理の遅延です。変更が発生してから、それがデルタ クエリの応答に表示されるまでに遅れが生じることがあります。この遅延により、アプリケーションが古い情報に基づいて動作し、ユーザーを混乱させる可能性があります。さらに、アプリケーションは変更の再送信も考慮して処理する必要があります。同じ変更が複数の応答に含まれ、不要な処理が発生する場合があります。
これらの課題に対処するために、次のベスト プラクティスを検討してください。
再試行ロジックの実装: アプリケーションには必ず再試行ロジックを組み込んでください。この方法は、
429 Too Many Requests応答を効果的に処理するのに役立ちます。API に過剰な負荷をかけないよう、指数バックオフを使用してください。エラーのログ記録: エラーを追跡するログ システムを設定してください。これにより、パターンを特定し、繰り返し発生する問題にすばやく対処できます。
Graph Explorer でのテスト: アプリケーションを展開する前に、Graph Explorer で API 呼び出しをテストしてください。この手順により、要求が期待どおりに動作することを確認できます。
エラー処理の標準化: エラー メッセージの形式を一貫させてください。この一貫性により、ユーザーは何が問題だったのか、そしてどのように修正すればよいのかを理解しやすくなります。
デルタ リンクの活用: Microsoft Graph から返される
deltaLinkを使用して、前回の同期以降の変更のみを要求してください。この方法により、データ転送量を抑えられ、パフォーマンスが向上します。Webhook とデルタ クエリの組み合わせ: 最適なパフォーマンスを得るには、Webhook を使用して変更の通知をすばやく受け取ってください。通知を受け取ったら、デルタ クエリを使用して正確な変更内容を取得します。この組み合わせにより、API 呼び出しを過剰に増やすことなく、アプリケーションを最新の状態に保てます。
デルタ クエリを使用する際に直面する可能性のある制限の概要は、次のとおりです。
| 制限 説明 | 詳細 |
|---|---|
$select クエリ パラメーター | 返されるデータを制御するために、最初の要求に含める必要があります。変更の追跡対象になるのは $select に含まれるプロパティのみです。 |
| 状態トークン | 最初の要求には状態トークンが含まれません。状態トークンは後続の要求で使用されます。 |
| 要求の変更 | 後続の要求は変更できません。 |
これらの課題を理解し、提案された解決策を実装することで、Microsoft Graph のデルタ クエリを最適に活用できます。この積極的なアプローチにより、アプリケーションのパフォーマンスが向上し、ユーザーがタイムリーな更新を受け取れるようになります。
Microsoft Graph Delta Queriesは、現代のアプリケーション開発で重要な役割を果たします。変更されたデータだけを効率よく追跡できるため、データセット全体を繰り返し取得する必要がなくなります。これにより、アプリケーションのパフォーマンスが向上し、リソース消費も抑えられます。Delta Queriesによるリアルタイムの更新は、デジタルトランスフォーメーションの取り組みに欠かせません。
さらに詳しく見るには、Delta Queriesを使い、全件読み取りをせずにUser、Group、Messageなどのエンティティの変更を検出することを検討してください。このクエリを効果的に実装するのに役立つドキュメントやビデオチュートリアルなどの追加情報もあります。Microsoft Graph Delta Queriesを採用すると、データの重複を最小限に抑え、ネットワークトラフィックを減らし、アプリケーション全体のパフォーマンスを改善できます。このテーマをさらに深く理解するには、関連するポッドキャストエピソードMicrosoft Graph Delta Queries - Simply Explainedもぜひご覧ください。このエピソードでは、これらの概念をすべて解説し、実装を成功させるための実践的な戦略を紹介しています。
よくある質問
Microsoft Graph における Delta Queries とは何ですか?
Delta Queries を使うと、データセット全体を取得せずにデータの変更を追跡できます。前回の同期以降の変更だけを要求できるため、効率が向上します。
Delta Queries の利用を始めるにはどうすればよいですか?
まず Azure Active Directory でアプリを作成します。アプリに認可を付与し、同期したいデータにアクセスできるよう Microsoft Graph API を構成します。
deltaLink とは何ですか?
deltaLink は、最初の要求の後に Microsoft Graph から提供される一意の URL です。前回の同期以降に行われた変更だけを取得できます。
すべての Microsoft Graph リソースで Delta Queries を使用できますか?
すべてのリソースが Delta Queries に対応しているわけではありません。この機能を利用できるリソースを確認するには、Microsoft Graph のドキュメントを参照してください。
Delta Query の要求はどのくらいの頻度で行うべきですか?
アプリケーションの要件に応じて要求の頻度を決めてください。更新が頻繁なデータでは定期的な要求が必要になる場合がある一方、更新の少ないデータはより低い頻度で問い合わせて構いません。
deltaLink の有効期限が切れた場合はどうなりますか?
deltaLink の有効期限が切れた場合は、完全な同期を再度実行し、データセット全体を取得し直す必要があります。この問題を避けるため、トークンの有効期限を定期的に確認してください。
API 使用時のスロットリングはどのように処理すればよいですか?
指数バックオフを用いた再試行ロジックを実装してください。このアプローチにより、429 Too Many Requests の応答を効果的に処理でき、アプリケーションの応答性を保てます。
Delta Queries を使用するうえでのベストプラクティスはありますか?
あります。deltaLink を使ってデータ転送量を最小限に抑え、リアルタイムの更新には Webhook と Delta Queries を組み合わせ、ペイロードサイズを減らすようクエリを最適化してください。
🎧 あわせて聴きたいエピソード
- Microsoft Graph Change Notifications – Simply Explainedでは、次の実践的な学習ステップとして、このテーマに役立つ補足情報を紹介しています。
- Microsoft Graph Connectors – Simply Explainedでは、次の実践的な学習ステップとして、このテーマに役立つ補足情報を紹介しています。
- AI Agents – Simply Explainedでは、次の実践的な学習ステップとして、このテーマに役立つ補足情報を紹介しています。
最終レビュー日: 2026年7月。