Latest / M365.FM – Microsoft 365・Copilot・AI ポッドキャスト（日本語） / Microsoft Graph Webhook をやさしく解説：ポーリングをやめてリアルタイム通知へ（AI吹き替え）

Transcript

Microsoft Graph Webhook をやさしく解説：ポーリングをやめてリアルタイム通知へ（AI吹き替え） · M365.FM – Microsoft 365・Copilot・AI ポッドキャスト（日本語）

0:00
マイクロソフト365、コパイロット、AI、アジュール、そして働き方の未来を築く人々が集う10日間、準備はいいですか?
0:07
この1月、M365コンがさらにパワーアップして帰ってきます。
0:12
世界中のMVPや業界エキスパートによるライブセッション、実践的なデモ、役立つ知識を体験しましょう。
0:18
ありきたりなスライドや、中身のない流行語は一切ありません。
0:22
コパイロットスタジオ、AIエージェント、ファブリック、セキュリティ、ガバナンス、自動化など、真の課題に取り組みます。
0:29
ITプロフェッショナル、開発者、ビジネスリーダーなど、あらゆる方に向けたセッションを用意しています。
0:35
10日間にわたり、様々な技術を探求し、世界中のコミュニティとつながることができます。
0:40
ライブで視聴し、実践的な知見を組織に持ち帰りましょう。
0:44
2027年1月、10日間、一つのマイクロソフトコミュニティ。
0:49
参加登録受付中です。
0:51
m365コン.NETにアクセスして、今すぐ参加枠を確保しましょう。
0:55
繰り返しになりますが、m365コン.NETです。
0:59
m365コン.NETから今すぐ登録して、1月のライブイベントでお会いしましょう。
1:05
皆さんこんにちは。
1:06
M365FMのマイクロソフトナレッジナゲット、へようこそ。
1:10
ホストのミルコピーターズです。
1:11
今日のトピックは、マイクロソフト365で開発を行う誰もが耳にしたことはあっても、説明できる人は少ないものです。
1:17
グラフウェブフックとは一体何でしょうか?
1:19
なぜ従来のやり方ではなく、これを使うべきなのでしょうか?
1:21
重要な手紙を待っているところを想像してください。
1:23
郵便受けを見に行きますが、空です。
1:25
家に戻ります。
1:26
10分後、また確認しに行きます。
1:27
まだ何も届いていません。
1:28
これを1日中繰り返して、時間とエネルギーを無駄にします。
1:30
それがポーリングです。
1:31
では、別の世界を想像してみてください。
1:33
手紙が届いた瞬間に、郵便配達員が玄関のチャイムを鳴らしてくれます。
1:35
自分で確認に行く必要はありません。
1:37
チャイムが鳴るのを待つだけです。
1:38
それがウェブフックです。
1:39
このエピソードの終わりには、グラフウェブフックとは何か、なぜ絶え間ない確認を不要にするのか、そして仕組みが理解できるようになります。
1:45
ポーリングの問題点。
1:46
詳しく見ていきましょう。
1:47
ウェブフックが重要である理由を知るには、なぜポーリングが弊害となるのかを理解する必要があります。
1:51
現在のほとんどのアプリはこのような仕組みです。
1:53
アプリが回答を必要としています。
1:54
マイクロソフトグラフに、ねえ、新しいユーザーはいる?と尋ねます。
1:57
グラフはいいえと答えます。
1:59
そこでアプリは少し待ってから、もう一度、新しいユーザーは増えた?と尋ねます。
2:02
まだ答えは、いいえ、です。
2:03
何度も繰り返すこのプロセスがポーリングです。
2:05
友人にニュースがあるかどうか、しつこく電話をかけ続けるようなものです。
2:08
電話し、相手が出れば尋ね、相手が、ない、と言い、電話を切ります。
2:11
そして5分後にまた電話をかけ、さらに繰り返します。
2:13
相手と自分の時間を浪費しています。
2:15
おそらく相手をイライラさせているでしょう。
2:17
さて、何千ものアプリが同時にマイクロソフトグラフに対してこれを行っていると想像してみてください。
2:20
すべてのアプリが数分おきにポーリングし、同じ質問をして、同じ答えを得る。
2:24
これはかなりのノイズになります。
2:25
マイクロソフトは、過剰にポーリングを行うことを、スロットリングと呼びます。
2:29
一部の開発者はこれを、グラフの牢獄と呼んでいます。
2:31
あまりに多くのリクエストを送ると、マイクロソフトは、はい、しばらくの間お休みです、と言います。
2:35
アプリが行える呼び出しの回数が制限されるのです。
2:37
スロットリングされると、すべてが遅くなります。
2:39
正当なリクエストまでもが滞留してしまいます。
2:40
アプリが正常に動作しなくなります。
2:42
いつ開放されるのかも検討がつきません。
2:44
どれほどの数のリクエストが問題なのでしょうか?
2:45
仮に、アプリがユーザーの変更を5分おきにポーリングするとします。
2:48
これは1時間あたり12回のリクエストになります。
2:50
1日では288回のリクエストになり、これは単一のリソースだけでこの数です。
2:54
グループ、ファイル、メッセージカレンダーのイベントもポーリングしていれば、1日あたり何千もの不要なリクエストが積み上がります。
3:00
そのほとんどは、変更なし、という結果ですが、それでも呼び出しは言っているのです。
3:04
しかも、5分おきにポーリングしても、リアルタイムの更新は得られません。
3:08
最後のポーリングから1分後に変更が発生するかもしれません。
3:11
その事実に気づくのは、さらに4分後になります。
3:13
リソースを浪費し、タイミングも逃しているのです。
3:15
では、イベント駆動型のアプローチと比較してみましょう。
3:18
数分おきにマイクロソフトグラフを呼び出すのではなく、グラフから呼び出されるのを待つのです。
3:21
リスナーをセットアップします。
3:23
何かが変わると、グラフが通知を送ってくれます。
3:25
自分からダイヤルする必要はありません。
3:26
電話が鳴ったら受話器を取るだけです。
3:28
Webhookとは何でしょうか?
3:29
では、Webhookとは正確には何でしょう?
3:31
最もシンプルな定義はこうです。
3:32
Webhookとは、何かが起きた時に自動的に送信されるHTTPリクエストのことです。
3:36
自分から要求せずとも、サーバーがプッシュしてくれます。
3:39
ドアベルを想像してみてください。
3:40
数分おきに外を確認しに行く必要はありません。
3:42
ドアベルを設置すればいいのです。
3:44
誰かが来たら、ベルを鳴らしてくれます。
3:46
ベルの音を聞いて横対すれば良いのです。
3:47
ドアベルがあなたに代わって監視してくれます。
3:49
Webhookは逆APIと呼ばれることもあります。
3:52
通常のAPIでは、アプリからリクエストを送り、サーバーが応答します。
3:55
アプリが主導権を握っています。
3:56
Webhookでは、サーバーがアプリにリクエストを送ります。
3:59
サーバーが主導権を握り、要求を待たずにデータをプッシュします。
4:02
マイクロソフトグラフもWebhookを使用していますが、マイクロソフトはこれを変更通知と呼んでいます。
4:07
名前が違うだけで、同じものです。
4:09
マイクロソフト365で何かが変わると、グラフは指定したURLにHTTPPOSTを送信します。
4:14
そのポストには、何が変更されたかという情報が含まれています。
4:18
通知を受け取れる事象はたくさんあります。
4:20
テナントでの新しいユーザー作成、シェアポイントでのファイル更新、チームでのメッセージ送信、予定表イベントの変更、グループへの新規メンバー追加など、これらは全て通知をトリガーする可能性があります。
4:30
実際の例を見てみましょう。
4:32
近代管理システムを運営している会社を想定します。
4:34
新しい従業員が入社した時に、自動的にアカウントを作成したいとします。
4:37
Webhookがなければ、ユーザーエンドポイントを数分おきにポーリングして、新しい人が増えていないか確認する必要があります。
4:41
Webhookを使えば、ユーザー作成イベントをサブスクライブできます。
4:44
誰かが入社すると、グラフがアプリに通知を送信します。
4:47
アプリがそれを受け取り、検証してアカウントを作成するまで、わずか数秒です。
4:51
ポーリングは不要で、無駄なリクエストも発生しません。
4:53
別の例を挙げます。
4:55
領収書がアップロードされるシェアポイントドキュメントライブラリがあるとします。
4:57
Webhookがなければ、ライブラリを常にポーリングし続けることになります。
5:00
Webhookを使えば、ファイルが追加された瞬間にグラフが通知してくれます。
5:03
アプリがそれを取り込み、領収化かどうかを確認して自動的に処理します。
5:06
それがWebhookの力です。
5:08
アプリが絶えず、何か新しいことはある?と尋ねるのではなく、何かが起きたときにシステムから通知を受け取るようにします。
5:13
より効率的で信頼性が高く、はるかに高速です。
5:16
Microsoft Graph Webhookの仕組み
5:18
これでWebhookとは何か、なぜポーリングが問題なのかが分かりました。
5:21
Microsoft Graph Webhookが実際にどのように機能するのかを見ていきましょう。
5:24
そのフローは思ったよりもシンプルです。
5:26
それは、サブスクリプション、通知、エンドポイントの3つに集約されます。
5:30
まず、サブスクリプションを作成します。
5:32
Microsoft Graphに、この特定の項目が変更されたら教えてほしいと伝えます。
5:36
グラフに何を監視し、どこに通知を送るべきかという詳細情報を渡します。
5:39
アラートにサインアップするようなものだと考えてください。
5:41
関心のある内容をシステムに伝え、連絡先情報を渡します。
5:44
次に、Microsoft Graphがそのリソースを監視します。
5:46
変更がないか監視を続けます。
5:48
ユーザー作成、ファイル更新、メッセージ到着などのイベントが発生すると、グラフがそれを検知します。
5:52
3番目に、グラフが通知を送信します。
5:54
指定されたURLに向けてHTTPPOSTを送信します。
5:57
そのポストには、何が変更されたかという情報が含まれています。
6:00
あなたのエンドポイントがそれを受信し、アプリケーションが処理を実行します。
6:02
つまり、大まかな流れは非常にシンプルです。
6:04
サブスクライブし、グラフが監視し、変更があればグラフがポストを送る。
6:08
これら3つの構成要素をもう少し詳しく掘り下げてみましょう。
6:10
サブスクリプションとは、通知を受け取るためのリクエストです。
6:13
テナントに新しいユーザーが追加されたら教えてほしい、というようなものです。
6:16
そのリクエストをMicrosoft Graphに送信すると、グラフがそれを保存します。
6:19
その時点から、グラフがあなたの代わりに監視を行ってくれます。
6:22
通知とはアラートそのものであり、グラフがあなたのエンドポイントに送信するHTTPPOSTのことです。
6:26
ポストボディには、どのリソースが変更されたか、どのような変更が起きたか、いつ起きたかといった変更の詳細が含まれます。
6:31
あなたのエンドポイントは、あなたが開けておくドアのようなものです。
6:34
これは、これらのポストリクエストを受け取るように構成されたサーバー上のURLです。
6:37
必要なのは、リクエストを待ち受け、素早く応答することだけです。
6:39
それだけです。
6:40
受信側に複雑なロジックは必要ありません。
6:42
通知を受け取り、確認し、処理するだけです。
6:44
では、これをポーリングと比較してみましょう。
6:46
ポーリングでは、何か新しいことはある?と尋ねるゲットリクエストを何百回も送信することになります。
6:50
ほとんどの場合、答えは、いいえ、です。
6:52
Webhookなら、通知というポストが1回あるだけです。
6:55
それだけです。
6:56
何百回ものメッセージではなく、1回で済みます。
6:58
効率の差は非常に大きく、エンドポイントを複雑にする必要はありません。
7:01
公開アクセスが可能で、HTTPSに対応し、素早く応答できれば十分です。
7:05
素早く、が何を意味するかは、後で説明します。
7:07
しかし、確信となる考え方はシンプルです。
7:09
エンドポイントが待ち受け、グラフが呼び出し、あなたが応答して完了です。
7:13
サブスクリプションの作成
7:15
では、実際にどのようにセットアップするのでしょうか。
7:17
サブスクリプションの作成手順を順を追って説明しましょう。
7:20
まずは、マイクロソフトグラフの特定のURLにHTTPPOSTリクエストを送信することから始めます。
7:24
そのURLは、https//graph、microsoft.com//v1、0、サブスクリプションズです。
7:29
サブスクリプションズエンドポイントに直接ポストします。
7:32
そのリクエストボディの中に、サブスクライブしたい内容の詳細を含めます。
7:35
提供する必要がある重要なフィールドは4つあります。
7:37
1つ目は、のちフィカチオンURLです。
7:39
これはあなたのエンドポイントのURLであり、マイクロソフトグラフが通知を送信する場所です。
7:43
グラフがインターネット経由でアクセスする必要があるため、httpsであること、そして公開アクセスが可能である必要があります。
7:47
2つ目は、リソースです。
7:49
これは、何を監視したいかをグラフに伝えます。
7:51
マイクロソフトグラフのリソースパスを指定します。
7:53
例えば、ユーザーの変更を監視したいならユーザーズ、受信トレイの新しいメールを監視したいならミーワイメールホルダーズ、インボックスメッセージスと指定します。
8:00
リソースによって、あなたが何を重要視しているかをグラフに明確に伝えます。
8:03
3つ目は、チェンジタイプです。
8:04
これは、どのような種類の変更を通知してほしいかをグラフに伝えます。
8:07
クリエイテッド、作成、アップデーテッド、更新、デリーテッド、削除、またはそれらの組み合わせを指定できます。
8:11
そのため、新しいユーザーの作成のみに関心がある場合は、チェンジタイプをクリエイテッドに設定します。
8:15
更新も重要であれば、クリエイテッド、アップデーテッドのように設定します。
8:17
4つ目は、エクスピレーションデートタイムです。
8:19
サブスクリプションには有効期限があるため、これは期限切れのタイミングを指定します。
8:23
日時を設定すると、その時点以降、グラフは通知の送信を停止します。
8:27
最大期間は、監視するリソースによって異なります。
8:29
ユーザーやグループの場合、最大期間は約3日間です。
8:32
シェアポイントやワンドライブのドライブアイテムであれば、最大30日間となります。
8:35
リソースの種類ごとにドキュメントを確認する必要があります。
8:38
言及しておくべきオプションのフィールドに、クライアントステート、クライアント状態があります。
8:41
これは、自分で作成する秘密の文字列です。
8:43
どのようなものでも構いません。
8:45
ランダムな文字列やGUIDなど、好きなものを選べます。
8:48
マイクロソフトグラフは通知を送るたびにこの値を含めるため、
8:51
これを使って通知が自身のサブスクリプションから来たものかを検証できます。
8:55
もし誰かが偽の通知をエンドポイントに送ろうとしても、クライアントステートが一致しないためすぐに拒否できます。
9:00
単純なセキュリティ対策ですが、重要なものです。
9:03
サブスクリプションの作成は、新聞の定期公読を申し込むようなものです。
9:07
新聞社に住所を伝えます。
9:08
それが通知URLに当たります。
9:10
公読したいセクション、リソースと変更の種類を伝え、どれくらいの期間配達を続けるかも伝えます。
9:15
それが有効期限となります。
9:17
あとは新聞社が対応してくれます。
9:19
しかし、注意点があります。
9:20
サブスクリプションには期限があるのです。
9:22
一度作成して放置することはできません。
9:24
有効期限を過ぎると、グラフは通知を停止し、サブスクリプションは消滅します。
9:29
通知を受け取り続けるには、新しい有効期限を設定してサブスクリプションエンドポイントにパッチリクエストを送り、期限を更新する必要があります。
9:36
つまり、サブスクリプションの作成は第一歩であり、最後ではないということです。
9:39
ライフサイクルを管理しなければなりません。
9:41
これについては後ほど詳しく説明します。
9:43
検証のハンドシェイクです。
9:44
サブスクリプションが有効になる前に、スキップできない手順が一つあります。
9:47
マイクロソフトグラフは、サブスクリプションリクエストを受け取ってすぐに通知を送信するわけではありません。
9:51
まず、エンドポイントが実在し、通知を受け取れる状態にあることを確認する必要があります。
9:55
仕組みは以下の通りです。
9:56
サブスクリプション作成のポストリクエストを送ると、マイクロソフトグラフは即座にテスト用のポストを通知URLへ送信します。
10:02
そのテストポストには、バリデーショントークンというクエリパラメータが含まれています。
10:06
これは単なるランダムな文字列です。
10:08
エンドポイントでそのトークンを取得し、プレーンテキストのレスポンスとして10秒以内に返送する必要があります。
10:12
宅配便が荷物を届ける場面を想像してください。
10:14
配達員がドアを叩き、ここはお間違いありませんか?と尋ねます。
10:17
確認していただけますか?と、受け取りのサインをしなければなりません。
10:20
サインがなければ、配達員は立ち去ってしまいます。
10:21
宅配便は荷物を置いていきません。
10:23
ただ去っていくだけです。
10:24
ここでも全く同じことが起きています。
10:26
マイクロソフトグラフは、これから重要な通知を送る、と言っています。
10:29
正しい住所にいる本人であることを証明してくださいと。
10:32
エンドポイントは検証トークンをそのまま送り返すことで、グラフに対して、はい、私はここにいますと伝えます。
10:38
準備はできています。通知を送ってください。
10:40
さて、ここで多くの開発者がつまずきます。
10:43
検証トークンはプレーンテキストで返す必要があります。
10:45
JSONやHTMLではなくプレーンテキストです。
10:48
また、レスポンスのコンテンツタイプヘッダーはテキスト、プレーンに設定しなければなりません。
10:51
JSONでラップしたり何らかの方法でエンコードして返すと、検証は失敗します。
10:55
サブスクリプションは作成されません。
10:57
マイクロソフトグラフはエラーを返し、原因がわからず悩むことになります。
11:00
もう一つ知っておくべき技術的な詳細があります。
11:02
マイクロソフトグラフの検証サービスはTLS1.3を確実にはサポートしていません。
11:06
TLS1.2でネゴシエーションを行います。
11:08
そのため、エンドポイントがTLS1.3接続のみを受け入れる設定だと、アプリケーションコードが動く前に検証のハンドシェイクが失敗します。
11:14
少なくとも検証ステップにおいては、エンドポイントがTLS1.2をサポートしていることを確認する必要があります。
11:19
その後であれば、実際の通知に対しては希望する任意のTLSバージョンを適用できます。
11:23
幸いなことに、この検証ハンドシェイクはサブスクリプションごとに1回だけ行われます。
11:27
通知が届くたびにエンドポイントで処理する必要はなく、初回のみです。
11:31
一度グラフがエンドポイントの存在を確認すれば、そのサブスクリプションの有効期間中はずっと信頼されます。
11:36
つまり、この設定を正しく行うのは一度だけでいいのです。
11:39
通知の処理とセキュリティについて
11:40
検証ハンドシェイクが完了しサブスクリプションが有効になると、マイクロソフトグラフは通知の送信を開始します。
11:46
では、実際にはどのような通知が届くのでしょうか。
11:49
何かが変更されると、グラフはHTTPPOSTをエンドポイントに送り、そのボディにはJSONオブジェクトが含まれます。
11:54
そのオブジェクトには、変更されたリソース、作成、更新、削除といった変更の種類、そしてタイムスタンプが含まれます。
12:00
また、サブスクリプション作成時に設定したクライアント状態、クリエントステートの値も含まれます。
12:04
これはあなたの秘密の文字列であり、メッセージが本物であるかを確認するための手段です。
12:07
そこで、通知が届いた時に最初に行うべきことがこちらです。
12:09
クライアント状態を検証することです。
12:11
通知内の値とサブスクリプション作成時に保存した秘密の文字列を比較します。
12:15
一致しない場合は直ちに破棄してください。
12:17
偽物の可能性があり、誰かが不正なデータを処理させようとしているかもしれないからです。
12:21
これは重要です。
12:22
なぜなら、あなたのエンドポイントはパブリックインターネット上に存在するからです。
12:25
URLを知っている人なら誰でも、そこにポストを送ることができます。
12:27
クライアント状態の検証なしでは、本物のマイクロソフトグラフ通知と偽物を見分ける方法がありません。
12:32
簡単なチェックですが、これが最初の防衛戦となります。
12:35
通知が正規のものだと確認できたら、速やかに応答する必要があります。
12:39
マイクロソフトグラフは、3秒以内に200番台のHTTPレスポンスを求めています。
12:43
応答に時間がかかると、グラフはそれを検知します。
12:45
頻繁に発生する場合、グラフの扱いが変わります。
12:48
スロットリングの仕組みは以下の通りです。
12:50
10分間に10%以上の応答が3秒を超えると、マイクロソフトグラフはエンドポイントを、低速、とみなします。
12:56
そうなると、新しい通知は10分間遅延します。
12:59
いずれ通知は届きますが、リアルタイム性は失われます。
13:03
さらに状況が悪化し、15%以上の応答が10秒を超えると、グラフはエンドポイントを、ドロップ、状態にします。
13:09
この状態では、10分間通知が完全に破棄されます。
13:12
ここからが怖い話です。
13:13
破棄された通知を復旧することはできません。
13:15
完全に失われ、二度と戻ってくることはありません。
13:17
話中の電話回線を想像してください。
13:19
すぐに出なければ、発信者は後でかけ直してきます。
13:22
しかし、いつまでも出なければ、発信者は最終的に諦めてしまいます。
13:24
マイクロソフトグラフが発信者で、あなたのエンドポイントが電話です。
13:27
素早く応答しないと、メッセージを失うリスクがあります。
13:30
では、ベストプラクティスは何でしょうか?
13:32
すぐに受け取り、非同期で処理することです。
13:34
エンドポイントはクライアントの状態を検証し、通知を受け取ったら、可能な限り早く200または202の応答を返すべきです。
13:41
その後、通知をQに入れてバックグラウンドで処理します。
13:44
Azure Q、サービスバス、あるいは単純なデータベーステーブルでも構いません。
13:47
ポイントは、応答サイクルを素早く終了させ、重い処理はバックグラウンドのワーカーに任せることです。
13:52
セキュリティに関する重要な注意点として、エンドポイントは例外なくhttpsである必要があります。
13:56
マイクロソフトグラフは、httpエンドポイントには通知を送信しません。
13:59
また、エンドポイントは公開アクセス可能である必要があります。
14:02
ファイアウォールやvpnの内側にあると、グラフは到達できません。
14:05
開発時は、グロックのようなツールを使用して、ローカルマシンへのパブリックトンネルを作成できます。
14:09
しかし本番環境では、グラフから見つけられる場所にエンドポイントを配置する必要があります。
14:13
通知のライフサイクルを維持する。
14:15
サブスクリプションの設定が完了し、通知が流れてきて、すべて順調に見えますね。
14:19
しかし、多くの人が見落としがちな点があります。
14:22
サブスクリプションには有効期限があります。
14:24
永久に続くわけではありません。
14:25
監視対象のリソースにもよりますが、最大有効期間は通常3から7日間です。
14:30
シェアポイントのドライブアイテムなど、一部のリソースでは最大30日間設定できます。
14:33
重要なのは、永続的ではないということです。
14:36
サブスクリプションを作成したら終わり、ではありません。
14:38
雑誌の定期購読のようなものだと考えてください。
14:40
申し込めば雑誌が届き、すべてがうまくいきます。
14:43
しかし、期間が切れる前に更新しなければ、雑誌は届かなくなります。
14:46
これと同じことです。
14:47
サブスクリプションの有効期限が切れると、マイクロソフトグラフは通知の送信を停止します。
14:50
何も起きないことに気づくまで、その事実に気づかないかもしれません。
14:53
そのため、更新戦略が必要になります。
14:55
更新方法はシンプルです。
14:56
サブスクリプションIDを使用してサブスクリプションエンドポイントにパッチリクエストを送信し、有効期限を未来の日時に更新します。
15:02
これでサブスクリプションの寿命が伸びます。
15:04
現在の有効期限が切れる前であれば、何度でもこれを行うことができます。
15:08
ここで、マイクロソフトグラフは、ライフサイクル通知という機能でサポートしてくれます。
15:13
サブスクリプションを作成する際、ライフサイクル通知URLと呼ばれる別のURLを指定できます。
15:18
特定のイベントが発生すると、マイクロソフトグラフはそのURLにアラートを送信します。
15:22
例えば、サブスクリプションの期限が近い時や、アクセストークンの有効期限が切れる前、またはアプリの権限が変更された時などです。
15:27
これらのライフサイクル通知は、事前の警告として役立ちます。
15:30
サブスクリプションがいつ終了するかを推測する必要はありません。
15:32
グラフが、サブスクリプションが数時間後に切れますと教えてくれます。
15:35
更新が必要かもしれません。
15:37
雑誌の出版社から高読終了の通知を受け取るようなものです。
15:41
注意していれば非常に役立ちます。
15:42
しかし、万が一問題が発生した場合はどうでしょうか。
15:45
エンドポイントが一時的にダウンしたり、処理が遅れて通知が破棄されたりすることもあります。
15:48
その場合はどうすればいいでしょう?
15:50
そこで登場するのがデルタクエリです。
15:52
これは、前回確認した時から何が変わったか?
15:54
お問い合わせるマイクロソフトグラフの独立した機能です。
15:56
そして、変更点のみが返され、それ以外は返されません。
15:59
仕組みはこうです。
16:00
リソース、例えばユーザー、に対して初めてデルタクエリを実行すると、グラフはテナント内のすべてのユーザーを返します。
16:05
しかし同時に、デルタリンクと呼ばれる特別なリンクも追加で返されます。
16:08
そのリンクを保存しておきます。
16:09
次に同じクエリを実行するときは、そのデルタリンクを使用します。
16:12
すると、すべてのユーザーを再度取得する代わりに、前回の要求から変更されたユーザーのみが取得されます。
16:16
新しいユーザー、更新されたユーザー、削除されたユーザーなどです。
16:19
これだけです。
16:20
毎回百科辞典全体を読むのではなく、最新の更新リストを読むようなものだと考えてください。
16:24
はるかに高速で、データ量も少なくて済みます。
16:26
さて、これが賢いパターンです。
16:28
Webhookとデルタクエリを組み合わせます。
16:30
何かが変わったときにWebhookで通知を受け取り、デルタクエリを使って具体的に何が変わったかを確認します。
16:34
なぜそれが重要なのかを説明しましょう。
16:35
Webhookは高速ですが、完璧ではありません。
16:37
通知が紛失したり、サブスクリプションが期限切れになったり、エンドポイントがダウンしたりすることがあります。
16:41
しかし、デルタクエリは信頼性が高いのです。
16:43
いつでも実行でき、前回のチェック以降のすべての変更リストを取得できます。
16:46
そのため、通知を見逃した場合でも、後から追いつくことができます。
16:49
典型的なフローは次の通りです。
16:51
ユーザー変更用のWebhookサブスクリプションを設定します。
16:53
最初のデルタクエリを実行してベースライン状態を取得し、デルタリンクを保存します。
16:57
ユーザーの変更を知らせるWebhookが届いたら、保存しておいたデルタリンクを使ってデルタクエリを実行します。
17:01
それにより、正確な変更内容が得られます。
17:03
それを処理し、その応答から新しいデルタリンクを保存します。
17:06
次にWebhookが届いた時も、同じプロセスを繰り返します。
17:09
通知を見逃したり、サブスクリプションの有効期限が切れたりしても、デルタクエリを再度実行するだけです。
17:13
見逃したすべての情報を取得できます。
17:15
これがセーフティネットです。
17:16
Webhookはスピードを、デルタクエリは信頼性をもたらします。
17:19
この2つを組み合わせることで、強力な連携が可能になります。
17:22
実際の例と次のステップについて見ていきましょう。
17:24
明日、新しい従業員が会社に入社するとします。
17:27
人事担当者がマイクロソフトエントラーIDでアカウントを作成すると、その1つのアクションが連鎖反応を引き起こします。
17:32
ユーザー変更用のWebhookサブスクリプションを設定していれば、マイクロソフトグラフが即座に検知し、エンドポイントへポストリクエストを送信します。
17:38
その後に起こることは次の通りです。
17:40
エンドポイントが通知を受け取り、クライアント状態を検証します。
17:43
シークレットと一致すれば、正当な通知だとわかります。
17:46
3秒以内に2002アクセプテッドレスポンスを返して通知を受領し、バックグラウンドワーカーがそれを受け取ります。
17:52
ワーカーはユーザーが作成されたことを確認しますが、通知には詳細が含まれないため、保存したデルタリンクを使ってデルタクエリを実行します。
17:59
これにより、名前、メールアドレス、部署、役職、マネージャーなど、必要な新ユーザーの全情報が返されます。
18:05
次に、ワーカーはその情報を使って、サードパーティーの勤怠管理システムに新入社員のアカウントを作成します。
18:10
ウェルカムメールを送信します。
18:12
適切な配付リストに追加します。
18:14
これらすべてが、人事がエントラーIDでアカウントを作成してから数秒以内に行われます。
18:17
ポーリングは不要です。
18:19
手動のステップも不要です。
18:20
遅延も発生しません。
18:21
代わりの方法について考えてみてください。
18:23
ウェブフックがなければ、数分おきにユーザーエンドポイントをポーリングする必要があり、1日数百回のリクエストが必要になります。
18:28
それでも、新ユーザーの検知に数分かかる場合があります。
18:30
ウェブフックなら、即座に実行されます。
18:32
通知は1回、デルタクエリも1回、これで完了です。
18:34
これこそが真の価値です。
18:35
システムはより高速かつ効率的になり、スロットリング制限に達する可能性も低くなります。
18:39
常にグラフへ更新を問い合わせるのではなく、何かが起きた時にグラフから通知を受け取るようにします。
18:43
これは、統合を構築する際の本質的な転換です。
18:45
そこで、皆さんに試していただきたいことがあります。
18:47
現在ポーリングを行っているプロセスを1つ選んで考えてみてください。
18:49
共有メールボックスに新しいメールが届いていないか確認しているかもしれません。
18:52
シェアポイントライブラリのファイルの変更を監視しているかもしれません。
18:55
人事システムのユーザー更新情報をチェックしているかもしれません。
18:57
そのポーリングをWebhookで置き換えられるのではないでしょうか?
18:59
多くの場合、答えはイエスです。
19:00
全てを自作する必要はありません。