Microsoft Graphの「What’s new in Microsoft Graph」でまず押さえるべき結論は、今回の更新が単なる新APIの追加ではなく、Microsoft Entraの認証・デバイス管理、Microsoft 365グループ運用、Exchange Onlineメールボックス連携、Microsoft Defenderのアラート分析、Teams関連アプリ管理に影響する点です。
特に重要なのは、一般提供された機能とプレビュー機能を分けて判断することです。v1.0で提供された機能は本番設計への反映を検討できますが、プレビュー機能は仕様変更の可能性があり、本番アプリでの利用は避けるべきです。Microsoft Learnでも、Microsoft Graphのプレビュー機能は予告なく変更される可能性があり、本番アプリでは使わないよう明記されています。(Microsoft Learn)
この記事では、2026年5月上旬に公開・更新された公式情報を基に、「What’s new in Microsoft Graph – Microsoft Graph」の変更点、影響範囲、管理者・開発者が確認すべき設定や移行時の注意点を実務目線で整理します。
Microsoft Graphの「What’s new」は何を確認するページなのか
Microsoft Graphは、Microsoft 365、Windows、Enterprise Mobility + Securityなどのデータへアクセスするための統一されたプログラミングモデルです。公式の「What’s new in Microsoft Graph」では、Microsoft Graph API、SDK、ドキュメント、関連リソースの新機能や変更点がまとめられています。より細かいAPI単位の変更は、Microsoft Graph API changelogで確認する位置づけです。(Microsoft Learn)
実務では、このページを「新機能紹介」として読むだけでは不十分です。次の観点で確認すると、影響範囲を判断しやすくなります。
| 確認観点 | 見るべきポイント | 実務上の判断 |
|---|---|---|
| 提供状態 | v1.0か、betaか | v1.0は本番検討、betaは検証・PoC中心 |
| 対象サービス | Entra、Teams、Exchange、Defenderなど | 自社の利用サービスと照合する |
| APIの性質 | 新規追加、プロパティ追加、非推奨、制限変更 | 既存コードや運用手順への影響を確認する |
| 権限・認証 | 新しい権限、管理者同意、認証方式への影響 | アプリ登録、同意、条件付きアクセスを確認する |
| データ構造 | 新しいリソース型、列挙値、プロパティ | パーサー、SDK、SIEM連携の修正要否を見る |
今回の主な変更点の全体像
2026年5月の更新では、一般提供された機能として、Agent関連、Verified ID、Microsoft 365グループ、デバイス登録ポリシー、証明書ベース認証、メールボックスのインポート・エクスポート、セキュリティアラート証拠情報、Shiftsのテーマ色追加などが掲載されています。プレビューでは、Microsoft 365のクロステナントアクセス制御、プロフィールカード表示制御、Teamsアプリのインストールスコープ情報などが追加されています。(Microsoft Learn)
| 分野 | 提供状態 | 主な変更 | 影響を受けやすい担当者 |
|---|---|---|---|
| Agents | 一般提供 | agentUserリソースなど、エージェントユーザーID管理に関する追加 | AIエージェント開発者、Entra管理者 |
| Microsoft Entra Verified ID | 一般提供・プレビュー | Verified IDプロファイル、クレーム検証、カスタム拡張関連の追加 | ID管理者、認証基盤担当者 |
| Microsoft 365グループ | 一般提供 | ownerlessGroupPolicyがv1.0に追加 | Microsoft 365管理者、Teams管理者 |
| デバイス登録 | 一般提供 | deviceRegistrationPolicyで登録制限や追加認証を管理 | Entra管理者、端末管理担当者 |
| 証明書ベース認証 | 一般提供 | CA単位・グループ単位のスコープ制御、issuer hints制御 | 認証基盤担当者、セキュリティ管理者 |
| Exchange Online | 一般提供 | メールボックスのインポート・エクスポートAPI | メール移行、アーカイブ、連携アプリ開発者 |
| Microsoft Defender | 一般提供・プレビュー | alertEvidenceの派生リソース追加 | SOC、SIEM/SOAR開発者 |
| Teams / Shifts | 一般提供・プレビュー | Shiftsテーマ色追加、TeamsアプリのscopeInfo追加 | Teams管理者、Teamsアプリ開発者 |
| クロステナント連携 | プレビュー | Microsoft 365のクロステナント機能制御 | Entra管理者、外部コラボレーション管理者 |
管理者が優先して確認すべき変更点
Microsoft 365グループの所有者不在対策がAPIで管理しやすくなる
今回の更新で、ownerlessGroupPolicyがv1.0エンドポイントに追加されました。これは、唯一の所有者が退職・無効化などで不在になったMicrosoft 365グループに対し、アクティブなメンバーへ所有者になるよう促す通知を構成するためのリソースです。通知期間、通知対象メンバー数、対象グループなどを設定できます。(Microsoft Learn)
ownerlessGroupPolicyのリソース説明では、所有者を失ったMicrosoft 365グループに対し、アクション可能な通知メールを送信できること、通知期間や最大通知人数、セキュリティグループを使った所有者候補の制御が可能であることが示されています。(Microsoft Learn)
管理者が確認すべきポイントは次のとおりです。
| 確認項目 | 推奨アクション |
|---|---|
| 対象範囲 | 全グループに適用する前に、重要度の高いグループから段階的に確認する |
| 通知人数 | maxMembersToNotifyを業務規模に合わせて設定する |
| 通知期間 | notificationDurationInWeeksを短すぎず長すぎない範囲で決める |
| 所有者候補 | セキュリティグループで対象者を制御できるか確認する |
| メール文面 | 「なぜ所有者が必要か」「承認後に何をすべきか」が伝わる内容にする |
注意したいのは、isEnabledをfalseに設定すると、他のポリシーパラメーターがクリアされる点です。既存設定を変更する前に、必ず現在の構成を取得してバックアップしておくべきです。(Microsoft Learn)
デバイス登録ポリシーは更新時の値消失に注意する
deviceRegistrationPolicyは、Microsoft EntraテナントにおけるデバイスID登録のクォータ制限、追加認証、承認ポリシーを管理するためのリソースです。Microsoft Learnでは、Microsoft Entra joinやMicrosoft Entra registeredの登録制御、MFA構成、ユーザーごとのデバイス上限などがプロパティとして示されています。(Microsoft Learn)
実務で特に注意すべきなのは、userDeviceQuotaです。既定値は50とされていますが、ポリシー更新時にこのプロパティを指定しない場合、0にリセットされ、新しいデバイス参加が許可されない状態になる可能性があります。(Microsoft Learn)
更新時は、次の流れで作業すると事故を防ぎやすくなります。
| 手順 | 作業内容 |
|---|---|
| 現状取得 | 既存のdeviceRegistrationPolicyを取得し、JSONで保存する |
| 差分確認 | 変更したい項目だけでなく、保持すべき項目も確認する |
| テスト更新 | 検証テナントまたは限定範囲で動作を確認する |
| 本番反映 | userDeviceQuotaなど重要プロパティを明示して更新する |
| 反映後確認 | 新規デバイス参加、MFA要求、登録上限の挙動を確認する |
端末登録は、ユーザーのPC展開、Intune運用、条件付きアクセスに直結します。Graph APIで自動化する場合は、単なる設定変更ではなく、端末展開プロセス全体への影響として扱うべきです。
証明書ベース認証は「誰が、どのCAの証明書で認証できるか」を見直す
x509CertificateAuthenticationMethodConfigurationでは、Microsoft Entraの証明書ベース認証に関する構成を管理できます。今回の更新では、特定の証明機関にスコープを絞る機能や、証明書ピッカーに表示される証明書を絞り込むissuer hintsの制御が重要なポイントです。(Microsoft Learn)
リソース説明では、CBAの有効・無効、利用できるユーザーやグループ、証明書をMicrosoft Entraユーザー属性へバインドする設定、特定CAの証明書利用を許可するスコープ、issuer hints構成などが示されています。(Microsoft Learn)
管理者は次の観点で確認しましょう。
- すべてのユーザーにCBAを開放していないか
- 利用を許可するCAとユーザーグループの対応が明確か
- 退職者・異動者の証明書失効やCRL確認の運用が整っているか
- クライアント証明書の選択画面で不要な証明書が表示されないか
- 条件付きアクセスや多要素認証ポリシーとの整合性があるか
証明書ベース認証は便利ですが、誤設定すると「認証できないユーザー」と「認証できてはいけないユーザー」の両方を生みます。まずは一部のグループで検証し、証明書ライフサイクル管理とセットで展開するのが安全です。
開発者が確認すべきAPI変更と実装上の注意点
メールボックスのインポート・エクスポートAPIはバックアップ用途と混同しない
メールボックスのインポート・エクスポートAPIは、Exchange Onlineメールボックスのコンテンツをアプリケーションからインポート・エクスポートするためのAPIです。メールボックス内のフォルダーやアイテムを統一された形式で扱え、フルフィデリティでエクスポートできます。ユーザーのプライマリ、共有、アーカイブメールボックスに対応することも示されています。(Microsoft Learn)
ただし、このAPIはMicrosoft 365のメールボックスバックアップ・復元用途として設計されたものではありません。公式情報でも、バックアップと復元にはMicrosoft 365 BackupやMicrosoft 365 Backup storage in Microsoft Graphを参照するよう案内されています。(Microsoft Learn)
活用シーンとしては、次のような用途が考えられます。
| 用途 | 適しているか | 理由 |
|---|---|---|
| メールアイテムの移行補助 | 適している | アイテムを別メールボックスへ取り込むワークフローに使える |
| 業務アプリとのメール連携 | 適している | メールボックス内データを一定の形式で扱える |
| 長期バックアップ | 適さない | バックアップ・復元用APIではない |
| コンプライアンス調査 | 条件付きで適している | Purviewや保持ポリシーとの役割分担を確認する必要がある |
開発時は、APIの権限、対象メールボックス、データ保持、監査ログ、エクスポートデータの保護をセットで設計してください。特に、メールデータは個人情報や機密情報を含みやすいため、エクスポート後の保存場所とアクセス権限を明確にする必要があります。
セキュリティアラート連携は新しいevidence型に対応する
Microsoft Graphのセキュリティ領域では、alertEvidenceを拡張する新しいリソースが追加されています。dnsEvidence、fileHashEvidence、GitHub関連のevidence、malwareEvidence、networkConnectionEvidence、sasTokenEvidence、servicePrincipalEvidence、submissionMailEvidenceなどが追加され、アラートに関わる証拠情報をより細かく表現できるようになります。(Microsoft Learn)
alertEvidenceは、アラートに関連する証拠を表す基底型です。公式説明では、攻撃者のIPアドレス、クラウドアプリ、侵害されたメールボックスなどを証拠として追跡できる例が示されています。(Microsoft Learn)
SIEMやSOAR、独自のセキュリティダッシュボードをMicrosoft Graphと連携している場合は、次の点を確認してください。
| 確認項目 | 失敗しやすいポイント |
|---|---|
| JSONパース | 未知のevidence型で処理が落ちる |
| 型分岐 | switch文や型判定が既存型だけを前提にしている |
| ログ保存 | 新しい証拠情報を保存せず破棄してしまう |
| アラート相関 | GitHub、SASトークン、サービスプリンシパルなどクラウド固有の証拠を相関対象に含めていない |
| 表示UI | 新しいフィールドが管理画面に表示されない |
実装では、未知の派生型を受け取っても処理を継続できる設計にしておくことが重要です。Microsoft Graphは継続的にリソース型やプロパティが追加されるため、「知らない型はエラー」ではなく、「知らない型は汎用表示・保存する」という方針が保守性を高めます。
Teamsアプリ管理ではインストールスコープの扱いを見直す
プレビューでは、teamsAppInstallationにscopeInfoプロパティが追加されています。これは、Teamsアプリがどのスコープにインストールされているかの詳細を取得するための情報です。teamsAppInstallation自体は、チーム、チャット、ユーザーの個人スコープにインストールされたTeamsアプリを表すリソースです。(Microsoft Learn)
Teamsアプリの棚卸しや権限監査を行っている開発者・管理者にとって、スコープ情報は重要です。同じアプリでも、個人スコープ、チャット、チームでは影響範囲が異なります。
| スコープ | 確認すべきこと |
|---|---|
| 個人スコープ | 特定ユーザーだけが利用するアプリか、権限が過剰でないか |
| チャット | 外部ユーザーを含むチャットで利用されていないか |
| チーム | チーム全体に影響するボットやタブが追加されていないか |
| 管理対象外アプリ | 組織のアプリ管理ポリシーと整合しているか |
ただし、scopeInfoはプレビュー情報として扱われているため、本番の監査基盤で必須項目として依存するのは避け、検証環境でデータ構造と取得結果を確認してから採用判断を行いましょう。
プレビュー機能で注目すべきポイント
クロステナントアクセス制御は外部コラボレーション設計に影響する
プレビューでは、Microsoft 365クロステナントアクセスに関する機能が追加されています。crossTenantAccessPolicyConfigurationDefaultやcrossTenantAccessPolicyConfigurationPartnerに、Microsoft 365のクロステナント機能を管理するm365Capabilities関係が追加され、プロファイル共有、カレンダー共有、移行、メールヒント、Places予約などを制御できる内容が示されています。(Microsoft Learn)
crossTenantAccessPolicyConfigurationDefaultの説明では、クロステナントアクセスやテナント制限の既定構成を表し、B2BコラボレーションやB2B direct connectの受信・送信設定を含むことが示されています。また、beta APIは変更される可能性があり、本番利用はサポートされないと明記されています。(Microsoft Learn)
確認すべき対象は、次のような組織です。
- 外部組織とのTeams共同作業が多い
- グループ会社や取引先とのカレンダー共有を行っている
- テナント統合・分割・移行を計画している
- Placesやメールヒントなど、Microsoft 365体験の共有範囲を管理したい
- B2Bコラボレーションとデータ漏えい対策を両立したい
プレビュー段階では、まず「既定設定」と「パートナー別設定」を分けて設計することが重要です。全社一律で許可・拒否するのではなく、取引先、グループ会社、委託先などの関係性に応じて制御方針を作ると、後の本番展開に移行しやすくなります。
プロフィールカードの表示制御は個人情報管理にも関わる
profileCardPropertyには、isVisibleプロパティが追加されています。これは、指定したディレクトリプロパティをユーザーのプロフィールカードに表示するかどうかを示すプロパティです。profileCardPropertyでは、Microsoft Entra IDの組み込み属性やカスタム属性をMicrosoft 365のプロフィールカードに表示できます。(Microsoft Learn)
プロフィールカードは、Outlook、Teams、Microsoft 365の各所でユーザー情報を確認する導線になります。そのため、表示項目の追加・非表示は単なるUI設定ではなく、個人情報や組織情報の公開範囲に関わります。
確認すべき項目は次のとおりです。
| 項目 | 確認内容 |
|---|---|
| 表示する属性 | 電話番号、住所、部署、カスタム属性などが業務上必要か |
| 非表示にすべき属性 | 個人情報、内部管理用コード、機密性の高い属性が含まれていないか |
| 多言語表示 | 表示名やラベルが日本語環境で分かりやすいか |
| 削除時の影響 | プロフィールカード設定を削除しても、Entra ID側の属性自体は削除されない点を理解しているか |
人事情報や組織情報をMicrosoft 365上で見せる範囲は、現場の利便性とプライバシーのバランスが重要です。APIで自動化する場合も、人事・法務・セキュリティ部門と表示方針を合わせておくとトラブルを防げます。
移行・展開前に確認すべきチェックリスト
今回の「What’s new in Microsoft Graph」を受けて、管理者と開発者は次の順番で確認すると効率的です。
| 優先度 | 確認項目 | 対象者 | 具体的なアクション |
|---|---|---|---|
| 高 | v1.0とbetaの切り分け | 開発者、管理者 | 本番利用中のAPIがv1.0かbetaか棚卸しする |
| 高 | 認証・デバイス登録設定 | Entra管理者 | CBA、deviceRegistrationPolicy、条件付きアクセスとの整合性を確認する |
| 高 | 所有者不在グループ | Microsoft 365管理者 | 重要グループの所有者状況を確認し、ownerlessGroupPolicyの適用範囲を検討する |
| 高 | セキュリティ連携 | SOC、開発者 | alertEvidenceの新しい派生型を受け取っても処理が落ちないか確認する |
| 中 | メールボックス連携 | Exchange管理者、開発者 | import/export APIをバックアップ用途と混同していないか確認する |
| 中 | Teamsアプリ管理 | Teams管理者 | アプリのインストールスコープを監査できる設計にする |
| 中 | SDK・型定義 | 開発者 | 新リソースや新プロパティを扱う場合、SDK更新や型定義の見直しを行う |
| 低 | UI表示・運用文書 | 情シス、ヘルプデスク | 通知メール、手順書、問い合わせ対応の文面を更新する |
特に、Microsoft Graphを使った自動化スクリプトや社内ツールは、一度作って放置されがちです。新しいプロパティや型がレスポンスに加わったときに、想定外のエラーが起きないかを確認しておくと、将来の変更にも強くなります。
よくある疑問
すべての組織がすぐ対応する必要はあるか
すぐに全項目へ対応する必要はありません。まずは、自社が利用している領域に絞って確認しましょう。
優先度が高いのは、Microsoft Entra、Teams、Exchange Online、Microsoft Defender、Microsoft 365グループをGraph APIで管理・連携している組織です。特に、認証、端末登録、セキュリティアラート、外部コラボレーションは業務影響が大きいため、早めに確認する価値があります。
プレビュー機能は使ってもよいか
検証やPoCで使うのは問題ありませんが、本番アプリで前提にするのは避けるべきです。Microsoft Graphのbeta APIは変更される可能性があり、本番アプリでの利用はサポートされないとされています。(Microsoft Learn)
本番展開を考える場合は、次のルールを決めておくと安全です。
- beta APIは検証環境でのみ使う
- 本番コードではv1.0を優先する
- beta APIに依存する場合は、仕様変更時の回避策を用意する
- APIのバージョン、権限、レスポンス形式を設計書に残す
SDKを更新すれば対応は完了するか
SDK更新だけでは不十分です。新しいリソースやプロパティを扱えるようになる場合でも、実際の影響はアプリのロジック、権限、例外処理、保存先スキーマ、UI表示に及びます。
たとえば、セキュリティアラートのevidence型が増えた場合、SDKが型を認識しても、社内ダッシュボードがその情報を表示しなければ運用上は活用できません。SDK更新後は、取得、保存、表示、通知、監査ログまで一連の流れで確認しましょう。
既存のAPI利用が突然壊れる可能性はあるか
今回の一般提供された新機能追加だけで、既存実装が必ず壊れるとは限りません。ただし、新しい列挙値、派生リソース、プロパティが追加されると、厳密すぎる型判定や固定スキーマの処理で問題が起きることがあります。
安全な実装にするには、次の考え方が有効です。
- 未知の列挙値を受け取っても処理を継続する
- 未知のプロパティを破棄せずログに残す
- 型分岐にデフォルト処理を用意する
- APIレスポンスの契約テストを定期的に実行する
- 重要な自動化処理は本番前にGraph APIの最新レスポンスで検証する
最初に取るべき行動
今回の「What’s new in Microsoft Graph」は、Microsoft Graphを使っている組織にとって、認証・端末・グループ・メール・セキュリティ・Teams連携を見直すきっかけになります。すべてを一度に対応するのではなく、次の順番で進めるのが現実的です。
- 自社で利用しているMicrosoft Graph APIを棚卸しする
- v1.0とbetaの利用箇所を分ける
- Microsoft Entra、Teams、Exchange、Defender関連の影響を優先確認する
- 新しいリソース型・プロパティに対するアプリの耐性を確認する
- 管理者向け設定は検証テナントまたは限定範囲で試す
- 本番反映前に権限、監査、ロールバック手順を文書化する
Microsoft Graphの更新は、開発者だけでなく管理者にも影響します。今回の変更を「新機能の追加」として読むのではなく、「自社のMicrosoft 365運用とAPI連携のどこに影響するか」を確認することが、実務で最も重要な対応です。
コメント