2026 Outlook Actionable Messages旧認証失効後、どう検収する？

2026年6月8日、MicrosoftはActionable MessagesのEAT認証からMicrosoft Entra IDトークン認証への移行を完了しました。旧認証はサポートされていないため、現在は新しい認証方式へ切り替え、受信・カード表示・トークン検証・操作結果を分けて検収してください。(Microsoftの移行案内)

旧Actionable Messages連携を移行する開発者は、提供者登録から順に確認できます。QA担当者は、メール到達とカード表示、操作要求の成否を切り分けるために活用してください。Microsoft 365のテスト環境を管理するチームは、受信者の適格性と公開範囲の確認にも使えます。

最終更新：2026年10月25日。認証の移行日と旧方式のサポート状況は、Microsoft Learnの移行案内および登録ガイドで確認しています。 Microsoftが認証要件、登録範囲、テスト対象者またはクライアント対応を変更した場合は、該当箇所を再確認してください。

Outlook Actionable Messagesの2026年認証移行テストは、故障の種類を分けるところから始めます

最初に、現行環境がEATとMicrosoft Entra IDのどちらを使っているかを、提供者登録とサーバーのトークン検証処理の両方で確認します。設定画面だけが新方式でも、受信側の検証コードが旧方式のままなら移行完了とはいえません。

次に、症状を別々に記録します。メールが届かない、メールは届くがカードが描画されない、カードのボタンを押しても操作が完了しない、サーバーがトークンを拒否する、という各状態は異なる確認経路です。ひとつの「メール機能の不具合」として扱うと、原因の層を取り違えます。

移行前の基準として、提供者登録、アクションURL、送信者の識別情報、トークン検証ロジックを棚卸しします。チームが変更できるコンポーネントと、Microsoft 365の管理者承認が必要な範囲も分けてください。以前の設定へ戻す必要に備え、現在の設定値と変更履歴を保存します。ただし、旧認証への復帰を解決策として見込まず、サポート対象の新方式で検証します。

これは段階別の確認表であり、メールの到達やカード表示だけで認証の安全性まで証明できるという意味ではありません。受信状況を記録する際は、メールが届いた事実を確認する方法のように、送信側の記録と受信側で観察できた結果を区別します。

登録範囲とテスト受信者は、認証設定より先に照合します

Microsoft Entra IDトークン認証への切替では、アプリ登録、アプリ識別情報、必要なAPI権限を確認し、Actionable Messagesの提供者登録にも対応する認証情報を設定します。登録や承認がどの範囲に適用されるかは、テストユーザー、組織内の範囲、より広い範囲で異なる場合があります。前提を推測せず、Actionable Messages Developer Dashboardの登録手順と現在の組織設定を照合してください。

テスト対象は、適用される登録範囲に合った、組織で認可されたMicrosoft 365受信者にします。一時メールアドレスを組織のテストユーザーと同等だと仮定してはいけません。受信箱がメールを受け取れたとしても、それはMicrosoft 365のテストユーザー資格や提供者登録の適合性を示しません。

受信に成功しても、送信者認証やサーバー側の安全なトークン検証を代替することはできません。メール、カード、操作要求、サーバー処理の証拠は、別々の項目として保存してください。

テストデータに個人情報を混ぜない運用も必要です。社内担当者の個人用メールアドレスや実在顧客の情報を使わず、環境ごとに識別できるテストデータを用意します。受信先を隔離する方法を比較する場合は、一時メールとメールエイリアスの違いも確認し、長期利用が必要なアカウントには継続して管理できる受信方法を選んでください。

トークン検証は、画面上の操作ではなくサーバーで判定します

設定変更後は、まず自社の操作エンドポイントを制御された要求で検査します。トークンの署名と、発行元・対象などの適用条件を公式要件に沿って検証し、検証に通った場合だけ許可された業務処理へ進めます。Microsoftのアクセス トークン検証に関する説明とActionable Messagesのセキュリティ要件を参照し、独自の前提で受け入れ条件を緩めないようにします。

テストケースは、正常な要求、無効なトークン、必要な権限と一致しない要求、業務ルールで拒否する要求に分けます。それぞれについて、受け入れまたは拒否の判断、返却された結果、業務データが変更されたかを確認します。ボタンが見えること、クリックできること、HTTP要求が届くことだけでは、サーバーが認証に成功した証拠になりません。

サーバーログには、秘密情報やトークンそのものを不用意に残さず、検証結果を追跡できる安全な記録方法を採用します。権限不足と業務上の拒否も区別してください。前者は認証・認可設定の問題、後者は処理対象や業務条件の問題かもしれず、同じエラーとして扱うと再現確認が難しくなります。

受信、カード描画、端点の結果をそろえてから公開範囲を広げます

認証設定を反映したら、適用範囲に合ったテスト受信者へ自社サービスからメールを送信します。送信結果だけでなく、実際に受信したか、カードが描画されたか、ボタンを操作できたか、操作端点が正しい結果を返したかを別々に記録します。

メールは受信できたのにカードが表示されない場合は、受信者が提供者登録の対象に含まれているか、登録が反映されているか、使用中のクライアントが対象機能をサポートしているかを確認します。メールアドレスだけに原因を求めず、登録状態とクライアント条件を先に照合します。メールの受信を確認する場合も、受信箱で確認できる情報と確認できない情報を区別し、表示記録を認証成功の代用にしないでください。

受信・描画・サーバー検証・操作結果がそろったら、チームの承認手順に従って有効化範囲を段階的に広げます。各段階で権限、送信者の識別情報、操作URL、提供者登録を再確認します。設定の版、テストメールのサンプル、トークン検証の結果、操作端点の応答を保存してください。これらはテスト範囲で得た証拠であり、広範な受信能力や本番メールの到達を保証するものではありません。

公開範囲を広げる判断条件

• 登録範囲に合った認可済みテスト受信者を確保でき、提供者登録が確認できた場合は、その範囲で検収を進めます。受信者の資格が不明なら、拡大せず管理者に登録・承認条件を確認します。
• サーバーが有効なトークンだけを受け入れ、無効な要求や権限不一致を拒否できた場合は、操作端点の検収へ進みます。画面上の操作しか確認できていない場合は、認証合格と判定しません。
• メール到達、カード描画、操作応答、サーバー検証を個別に説明できる記録がそろった場合は、承認済みの手順で公開範囲を広げます。どれかの結果が欠ける場合は、原因が明確になるまで現在の範囲に留めます。

よくある確認事項

旧EAT認証が使えなくなった後の最初の作業

提供者登録とサーバー実装の認証方式を確認し、EAT依存が残っていないか調べます。Microsoftは2026年6月8日に移行を完了し、旧方式はサポートしていません。メール未着、カード非表示、操作失敗を別々に記録して、新方式の設定と検証処理を確認します。

テストユーザー範囲でのトークン認証確認

適用される登録範囲に合った認可済みテストユーザーを使い、テストメールと操作要求を確認します。カード表示の確認だけでなく、サーバーがトークンを検証し、正当な要求だけを処理することが必要です。テスト範囲や承認条件は最新のMicrosoft公式情報に照らします。

メール受信後にカードが見えない場合

受信者の適格性、提供者登録の状態、使用クライアントの対応状況を順に照合します。受信した事実とカードの描画結果は別の記録として扱い、受信先だけを原因と決めつけないことが重要です。

ボタンの要求がサーバーで検証されたかの判断

HTTP要求が届いたことではなく、サーバーが公式要件に沿ってトークンを検証し、不正な要求を拒否した記録で判断します。検証後に業務処理が期待どおり完了したかも確認します。ボタンの表示やクリックだけでは認証の合格を証明できません。

受信先の隔離は補助手段として扱います

一時的なメール受信先は、許可された範囲でテスト用メールを分離したい場合の補助手段にはなります。ただし、Microsoft 365の組織テストユーザー資格、提供者登録、送信者認証、サーバー検証の代わりにはなりません。継続的な受信やアカウント復旧が必要な用途には、長期管理できる受信先を選んでください。

自社サービスの一時的な登録やメール確認を、組織の受信者要件に合う範囲で切り分けたい場合は、BoxTmpの一時受信サービスを補助的な選択肢として検討できます。実際の適用可否を先に確かめ、Microsoft 365の認証移行とサーバー側の検収は、ここで示した手順と公式要件に基づいて進めてください。

よくある質問

旧EAT認証が使えなくなったら、最初に確認することは何ですか？

まず自社の提供者登録とサーバー実装がどの認証方式を使っているか確認します。Microsoftは2026年6月8日にMicrosoft Entra IDトークン認証への移行を完了し、旧方式をサポートしていません。メール未着、カード非表示、操作失敗を別々の事象として記録してから、登録情報と検証処理を見直してください。

テストユーザーでMicrosoft Entra IDトークン認証をどう検証しますか？

適用範囲に合った提供者登録と、組織で許可されたテストユーザーを用意し、自社サービスからテストメールを送ります。カード表示だけで合格にせず、操作リクエストに含まれるトークンをサーバー側で検証し、許可された要求だけが業務処理に進むことを確認します。登録範囲や承認条件は最新の公式手順に従います。

メールは届いたのにActionable Messageのカードが表示されない場合は？

受信とカード描画は別の確認項目です。テストユーザーが登録範囲に合っているか、提供者登録が有効か、使用中のクライアントが対象機能をサポートしているかを確認します。受信先だけを原因と決めつけず、同じメールの受信結果、表示結果、登録状態を分けて記録すると切り分けやすくなります。

ボタンを押してリクエストが届けば、サーバー検証も成功ですか？

いいえ。ボタンが表示されたことやHTTPリクエストが到着したことだけでは、認証成功の証拠になりません。サーバーが承認された発行元や対象など、公式要件に沿ってトークンを検証し、無効なトークンや権限不一致の要求を拒否することを確認してください。業務処理の結果も別に記録します。