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

Transcript

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

• 0:00
  マイクロソフト365、コパイロット、AI、Azure、そして働き方の未来を築く人々が集う10日間への準備はできていますか?
• 0:07
  この1月、M365コンが帰ってきます。さらに規模を拡大して開催します。
• 0:12
  世界中のMVPや業界の専門家によるライブセッション、実践的なデモ、役立つ知識をぜひ体験してください。
• 0:18
  ありきたりなスライドや、終わりのない専門用語の羅列はありません。
• 0:22
  コパイロットスタジオ、AIエージェント、ファブリック、セキュリティ、ガバナンス、自動化といった真の課題に取り組みます。
• 0:29
  ITプロフェッショナル、開発者、ビジネスリーダーの皆様、それぞれの役割に合わせたセッションをご用意しています。
• 0:35
  10日間にわたる充実したプログラムで、多様な技術を探求し、世界中のコミュニティとつながりましょう。
• 0:40
  ライブ視聴で実践的な洞察を得て、ぜひ所属組織にお持ち帰りください。
• 0:45
  2027年1月、10日間、一つのマイクロソフトコミュニティ。
• 0:49
  登録受付中です。
• 0:51
  m365コン.NETにアクセスして、今すぐ参加枠を確保しましょう。
• 0:55
  繰り返しですが、m365コン.NETです。
• 0:59
  m365コン.NETから今すぐご登録ください。
• 1:02
  1月のライブセッションでお会いしましょう。
• 1:05
  今日のトピックは、マイクロソフト365で開発を行う人なら誰もが一度は耳にしたことがあるものです。
• 1:09
  しかし、その仕組みが裏側でどうなっているのかを本当に理解している人は多くありません。
• 1:13
  マイクロソフトグラフの変更通知についてお話しします。
• 1:15
  一体それは何なのか、なぜ注目すべきなのでしょうか。
• 1:18
  まずは、それが解決する課題から見ていきましょう。
• 1:20
  マイクロソフト365で何か変更があった際に、それを検知する必要があるアプリを構築すると想像してみてください。
• 1:24
  新しいメールの受信や、シェアポイント上のファイル更新、あるいは会社ディレクトリへの新規ユーザー追加などです。
• 1:29
  アプリはどうやってそれを知るのでしょうか。
• 1:31
  従来のやり方は、ポーリングです。
• 1:33
  アプリが数分おきにマイクロソフトグラフへリクエストを送り、最後にチェックしてから何か新しいことはありましたか。
• 1:37
  と尋ねます。
• 1:38
  何も変わっていなければ、リクエストを無駄にしたことになります。
• 1:41
  もしチェックの5秒後に変更があった場合、次のサイクルまでそれを知ることはできません。
• 1:45
  頻繁にチェックすればリソースの無駄遣いでスロットリングのリスクがあり少なければ情報の見落としが発生します。
• 1:50
  実際、マイクロソフトはポーリングが過度なアプリに対してスロットリング、制限を行います。
• 1:53
  開発者はこれをグラフジェール、グラフの刑務所と呼び、過剰なリクエストによりアプリが一定期間ブロックされてしまいます。
• 1:58
  そこで、もっと良い方法はないのかという疑問が生まれます。
• 2:00
  アプリが常に、何か新しいことは?と尋ねるのではなく、変更があった時にシステム側から教えてくれるとしたらどうでしょうか。
• 2:06
  それこそが、まさに変更通知の役割です。
• 2:09
  マイクロソフトグラフの変更通知とは何でしょうか。
• 2:11
  最もシンプルな定義はこうです。
• 2:13
  変更通知を使えば、アプリが絶えず確認しなくても、マイクロソフト365のイベントに即座に反応できます。
• 2:19
  郵便受けのモーションセンサーのようなものだと考えてください。
• 2:22
  1時間おきに覗きに行く代わりに、郵便が届いた瞬間に通知してくれるセンサーを設置するのです。
• 2:27
  空振りを確認する時間をなくし、配達を見逃すこともなくなります。
• 2:30
  それが、変更通知があなたのアプリにもたらすメリットです。
• 2:33
  新しいメール、更新されたファイル、カレンダーのイベントなどに変更があった場合、マイクロソフトグラフは自動的にアプリへ通知を送信します。
• 2:39
  ポーリングは不要です。
• 2:41
  このシステムは、サブスクリプションと通知という2つの要素で構成されており、これらが連携して動作します。
• 2:45
  サブスクリプションとは、監視したい対象をマイクロソフトグラフに伝えるためのものです。
• 2:49
  例えば、この受信トレイに新しいメッセージが届いたら教えて、といった設定を行います。
• 2:53
  あるいは、このシェアポイントライブラリのファイルが更新されたら教えて、といった具合です。
• 2:56
  興味のある対象を登録すると、グラフがそれを記録します。
• 2:58
  通知は、その次に行われる動作です。
• 3:00
  変更が発生すると、グラフは指定したエンドポイントへHTTPPOSTを送信します。
• 3:04
  アプリはそのポストを受け取って変更を検知し、データの取得、ワークフローの起動、データベースの更新といった次のアクションを決定できます。
• 3:12
  これがポーリングとの決定的な違いです。
• 3:15
  通知は自動的に配信されます。
• 3:17
  アプリが問い合わせる必要はなく、何かが起きた瞬間にシステムが情報をプッシュします。
• 3:20
  これこそが魔法のような仕組みです。
• 3:22
  マイクロソフトグラフは、幅広いリソースの変更通知をサポートしています。
• 3:25
  メッセージイベント、連絡先、ユーザー、グループ、ファイル、チームのメッセージセキュリティアラートなど、グラフを通じてアクセスできるほぼすべてのリソースを監視対象にできます。
• 3:33
  では、実際にどのように設定するのでしょうか。
• 3:35
  監視対象と通知先をどのようにグラフに伝えるのでしょうか。
• 3:38
  それは、サブスクリプションを作成して監視対象を伝えることです。
• 3:40
  では、サブスクリプションとは何でしょうか。
• 3:42
  単なる登録リクエストにすぎません。
• 3:44
  アプリが、このイベントが起きたら教えて、と伝えます。
• 3:46
  そして、そのリクエストをマイクロソフトグラフAPIに送ります。
• 3:48
  グラフはそれを保存して待ちます。
• 3:50
  そのリクエストにはいくつか詳細情報を指定する必要があります。
• 3:52
  1つ目は、監視したいリソース、つまりデータへのパスです。
• 3:55
  例えば、ユーザーアカウントの変更を監視するなら、ユーザーズを指定します。
• 3:59
  新しいメールを知りたい場合は、Me My Mail Folders、Inbox Messagesを指定します。
• 4:03
  2つ目は、変更の種類です。
• 4:05
  作成、更新、削除のどれを知りたいかを指定します。
• 4:07
  1つだけ選ぶことも、3つすべてを指定することも可能です。
• 4:15
  公開されているHTTPSエンドポイントである必要があります。
• 4:18
  省略はできません。
• 4:19
  4つ目は、有効期限です。
• 4:21
  サブスクリプションは永久には続きません。
• 4:23
  サブスクリプションが終了する未来の日時を指定します。
• 4:25
  ただし、リソースごとに最大有効期間が異なります。
• 4:28
  アウトルックのメッセージは最長で7日間です。
• 4:30
  チームのチャットメッセージは最大3日間となります。
• 4:32
  シェアポイントのファイルは約30日間保持されます。
• 4:34
  プレゼンス情報はどうでしょうか。
• 4:36
  こちらはわずか1時間で期限切れになります。
• 4:38
  具体的な例を挙げましょう。
• 4:39
  社内の誰かが役職を変更したときに通知を受け取りたいとします。
• 4:42
  ユーザーズリソースに対して、
• 4:43
  変更タイプをアップデーテッドに設定したサブスクリプションを作成します。
• 4:46
  通知用URLを指定し、有効期限を数日後に設定します。
• 4:50
  誰かがAzure Adでプロファイルを更新すると、
• 4:52
  グラフが通知ペイロードをエンドポイントにポストします。
• 4:55
  そのペイロードにはユーザーIDが含まれ、変更内容が通知されます。
• 4:58
  アプリ側でその情報を受け取り、
• 5:00
  人事システムの更新や上司への通知など、必要な処理を行います。
• 5:03
  グラフはサブスクリプションのリクエストに対し、サブスクリプションIDで応答します。
• 5:06
  このIDは、5のサブスクリプションの管理、更新、削除などで必要になります。
• 5:10
  しかし、注意点があります。
• 5:12
  グラフは通知を送る前に、エンドポイントが実際に稼働し、
• 5:15
  待機しているかを確認する必要があります。
• 5:17
  それにはハンドシェイクが必要です。
• 5:19
  ハンドシェイクの検証トークンについて解説します。
• 5:21
  サブスクリプションを作成する際、
• 5:23
  マイクロソフトグラフはエンドポイントを無条件には信頼しません。
• 5:26
  まず、テスト用のピンである検証リクエストが送信されます。
• 5:29
  そのピンには、ランダムな文字列である検証トークンが含まれています。
• 5:32
  エンドポイントはそのトークンを受け取り、
• 5:34
  10秒以内にプレーンテキストとして返送しなければなりません。
• 5:37
  配達員が荷物を置く前に、ドアベルを鳴らして在宅を確認するようなものです。
• 5:41
  誰も応答しなければ、配達員は何も残さずに去ります。
• 5:43
  これと同じです。
• 5:44
  エンドポイントが検証トークンを正しく返さなければ、
• 5:47
  グラフは通知を送信しません。
• 5:49
  レスポンスはJSONやXMLではなく、
• 5:51
  正のトークン文字列のみのプレーンテキストである必要があります。
• 5:53
  形式が異なると、ハンドシェイクは失敗します。
• 5:56
  これはセキュリティチェックです。
• 5:57
  エンドポイントが稼働し、待機状態であり、
• 5:59
  あなたの管理下にあることを証明します。
• 6:01
  他人の通知を傍受しようと、
• 6:03
  所有していないURLにサブスクリプションを向ける行為を防ぎます。
• 6:06
  ハンドシェイクが成功しなければ、
• 6:07
  サブスクリプションは作成されません。
• 6:08
  グラフは作成リクエストを拒否し、
• 6:10
  エラーが返されます。
• 6:11
  エンドポイントを修正して、
• 6:12
  もう一度試してください。
• 6:13
  ハンドシェイクが成功すれば、
• 6:14
  サブスクリプションが有効になり、
• 6:16
  通知が届き始めます。
• 6:17
  しかし、ここがポイントです。
• 6:18
  通知は永遠には続きません。
• 6:20
  接続を維持する方法について、
• 6:22
  サブスクリプションの更新、
• 6:23
  全てのサブスクリプションには有効期限があります。
• 6:25
  作成時に有効期限を設定します。
• 6:27
  グラフがそれを強制します。
• 6:28
  期限が来ると、サブスクリプションは停止します。
• 6:30
  通知は届かなくなります。
• 6:32
  パーキングメーターを想像してください。
• 6:34
  時間を設定し、
• 6:35
  時間が切れるとメーターのフラグが倒れます。
• 6:37
  リソースによって制限時間が異なります。
• 6:40
  アウトルックメッセージは7日間、
• 6:41
  チームチャットは3日間、
• 6:43
  シェアポイントファイルは約30日間、
• 6:45
  プレゼンス情報はわずか1時間です。
• 6:47
  アプリでサブスクリプションを作成したら、
• 6:49
  そのまま放置してはいけません。
• 6:50
  有効に保つためのプロセスが必要です。
• 6:52
  更新は簡単です。
• 6:53
  サブスクリプションIDを指定してパッチリクエストを送信します。
• 6:56
  新しい有効期限を含めてください。
• 6:57
  現在の有効期限が切れる前に更新すれば、
• 6:59
  グラフがサブスクリプションを延長します。
• 7:01
  ここで私がお勧めするベストプラクティスを紹介します。
• 7:03
  受信するすべての通知で有効期限のタイムスタンプを確認しましょう。
• 7:06
  期限が近づいていたら、
• 7:07
  例えば残り1日以内であれば、その場で更新します。
• 7:09
  そうすれば、サブスクリプション管理のためだけのバックグラウンドジョブは不要です。
• 7:13
  マイクロソフトはライフサイクル通知も追加しました。
• 7:15
  このアラートは、サブスクリプションが切れる前に警告してくれます。
• 7:18
  サブスクリプションの終了時期や、アクセストークンの再認証が必要な時期を通知します。
• 7:22
  これに登録しておけば、問題が発生する前にアプリで更新を行えます。
• 7:25
  では、エンドポイントがダウンしたり、更新ウィンドウを逃したりした場合はどうなるでしょうか。
• 7:29
  そこでセーフティネットの出番です。
• 7:30
  問題が発生した時のための信頼性とセーフティネットについてです。
• 7:34
  サブスクリプションは有効、エンドポイントは待機中、通知は順調に流れています。
• 7:37
  すべて順調に見えますが、何か問題が発生した時はどうなるでしょうか。
• 7:40
  エンドポイントのメンテナンスによる停止やネットワーク障害による通知の欠落、あるいは単純に更新期限を逃して期限切れになることもあります。
• 7:46
  こうしたことは起こり得ます。
• 7:47
  問題は、どうやって復旧するかです。
• 7:49
  マイクロソフトグラフは、Webhookエンドポイントが3秒以内に迅速に応答することを期待しています。
• 7:53
  それ以上時間がかかると、グラフはそれを定速とみなします。
• 7:56
  10分間に応答の10%以上が3秒を超えると、グラフは通知を10分間遅延させます。
• 8:01
  復旧したか確認するために、ごく少量のサンプルのみが送信されます。
• 8:04
  さらに悪化する場合もあります。
• 8:05
  15%以上の応答が10秒の再試行タイムアウトを超えると、グラフはエンドポイントをドロップとみなします。
• 8:09
  通知が10分間完全に停止します。
• 8:11
  もう通知は届きません。
• 8:12
  取り戻すことも不可能です。
• 8:14
  つまり、エンドポイントは高速かつ信頼性が高くなければなりません。
• 8:16
  全ての通知を3秒以内に処理しなければならない、という意味ではありません。
• 8:20
  200にアクセプテッド応答で素早く受信を通知し、その後で非同期に処理すれば良いのです。
• 8:24
  急に入れましょう。
• 8:25
  後で処理するのです。
• 8:26
  重要なのは、その迅速な応答です。
• 8:28
  完璧なエンドポイントであっても、問題は起こり得ます。
• 8:30
  サブスクリプションは期限切れになります。
• 8:32
  ネットワークの一時的な不調も起こります。
• 8:33
  稀なケースですが、マイクロソフトグラフ自体が通知を見逃す可能性もあります。
• 8:36
  だからこそ、セーフティネットとしてデルタクエリが必要なのです。
• 8:39
  こう考えてみてください。
• 8:40
  変更通知は火災放置機です。
• 8:41
  今まさに何かが起きていることを知らせてくれます。
• 8:43
  デルタクエリはスプリンクラーシステムです。
• 8:45
  放置機が逃したものをすべてカバーします。
• 8:47
  これらは連携して機能します。
• 8:48
  通知があればリアルタイムで状況を把握できます。
• 8:50
  デルタクエリがあれば、いつでも消耗可能な全体像を把握できます。
• 8:53
  推奨されるパターンはシンプルです。
• 8:55
  変更通知を使用して、即座に変更を把握します。
• 9:06
  実際のユースケース、構築できるものでは、実際に何が可能になるのでしょうか。
• 9:12
  いくつか実際の例を見てみましょう。
• 9:13
  人事の自動化を例に挙げます。
• 9:15
  明日、誰かがあなたの会社に入社すると想像してください。
• 9:17
  エントラーIDが新しいユーザーを作成した瞬間に、変更通知が送信されます。
• 9:21
  アプリがそのプロファイルを読み取り、人事プラットフォームのアカウント作成、
• 9:23
  勤怠管理、建物へのアクセス権付与をすべて数秒で行います。
• 9:26
  ホーリングも遅延もありません。
• 9:28
  セキュリティアラートの場合、例えばユーザーアカウントが無効化されたとします。
• 9:31
  変更通知がワークフローをトリガーし、不審な変更がないかチェックしてセキュリティチームに警告します。
• 9:35
  以前なら、数分おきにポーリングしていたでしょう。
• 9:38
  今では、即座に実行されます。
• 9:39
  コンテンツ処理も同様の仕組みで機能します。
• 9:41
  シェアポイントドキュメントライブラリにファイルが追加されたとき、それが請求化かどうかを知りたいとします。
• 9:45
  通知によって、新しいファイルが存在することがわかります。
• 9:47
  アプリがファイルを取得し、AIで分類して適切な経費生産システムへ送信します。
• 9:51
  すべて自動です。
• 9:52
  リアルタイムダッシュボードなら、数時間前のデータではなく、発生した瞬間の分析結果を確認できます。
• 9:56
  変更通知により、データバースとファブリックが即座に同期されます。
• 9:59
  Power BIダッシュボードがほぼリアルタイムで更新されます。
• 10:02
  興味深い例がもう一つあります。
• 10:04
  コパイロットコネクタです。
• 10:05
  マイクロソフトはWebhookを通じてリアルタイム同期を追加しているため、AIエージェントはデータ変更の瞬間に応答します。
• 10:10
  ダイナミクス365で顧客レコードが更新されると、コパイロットエージェントが即座にフォローアップを生成し、待ち時間はありません。
• 10:17
  これらの例には共通点があります。
• 10:19
  変更通知が登場する前は、1時間ごとや1日ごとのスケジュールジョブを構築していました。
• 10:24
  機能はしましたが、低速で非効率、かつ壊れやすいものでした。
• 10:27
  変更通知はそのモデルを大きく変えます。
• 10:29
  リアルタイムでイベント駆動、そして即時性が特徴です。
• 10:32
  適切な配信チャンネルの選択。
• 10:34
  すべてのアプリに同じ配信方法が必要なわけではありません。
• 10:36
  オプションを見ていきましょう。
• 10:37
  Webhookが最もシンプルです。
• 10:39
  グラフがエンドポイントへHTTPPOSTを送信し、アプリがそれを処理します。
• 10:43
  1時間あたり数百件程度の低、中程度のボリュームであればこれで十分です。
• 10:46
  しかし、より大規模なシステムを構築する場合はどうでしょうか。
• 10:48
  毎秒数千件の通知は単一のエンドポイントを過負荷にする可能性があります。
• 10:52
  より強力なツールが必要です。
• 10:53
  イベントHUBSは毎秒数100万件のイベントを処理できます。
• 10:56
  グラフが通知を一つずつ送信する代わりに、ハブへ通知を送信します。
• 10:59
  アプリは独自のペースで読み取ることができパンクするリスクも低くなります。
• 11:02
  これは、何千ものシェアポイントサイトや何百万ものメールボックスを抱える大規模エンタープライズ向けです。
• 11:06
  そして、サーバーレスなオプションであるイベントグリッドがあります。
• 11:09
  Azure FunctionsやLogic Appsに通知を送信し、リトライやデッドレター処理を自動的に行います。