Microsoft Teams のチャットやチャネル投稿を監査、バックアップ、移行、eDiscovery連携などで取り出したい場合、確認すべき中心機能が Microsoft Teams Export APIs です。2026年6月29日に更新された公式ドキュメントでは、1対1チャット、グループチャット、会議チャット、チャネルメッセージに加え、会議録画・会議トランスクリプト、保持ポリシー対象メッセージ、削除済みユーザーや削除済みチームへの対応範囲が整理されています。(Microsoft Learn)
今回のポイントは、「Teams管理センターで新機能をオンにする」というより、Microsoft Graph 経由でTeamsコンテンツを安全に大量エクスポートするための前提条件・権限・取得範囲・制限を再確認する更新です。特に、APIを使うアプリ登録、アプリケーション権限、管理者同意、保持ポリシー、削除データの取得期限、スロットリング、DLPライセンスの扱いを見直す必要があります。
Microsoft Teams Export APIsとは何か
Microsoft Teams Export APIsは、Microsoft Graphを通じてTeams内のメッセージや会議関連コンテンツをプログラムでエクスポートするためのAPI群です。対象は、1対1チャット、グループチャット、会議チャット、チャネルメッセージで、チャットメッセージはルートメッセージだけでなく、replyToIdで関連付けられた返信スレッドも含めて扱えます。(Microsoft Learn)
実務では、次のような用途で使われます。
| 用途 | 具体例 | 注意点 |
|---|---|---|
| コンプライアンスアーカイブ | Teamsメッセージを日次で外部アーカイブへ保存 | 重複取得を避けるため日付範囲を必ず設計する |
| 監査・調査 | 特定ユーザーやチームのメッセージ履歴を抽出 | 管理者同意と最小権限の設計が必要 |
| 移行 | Teamsテナント移行や外部保管のために履歴を取得 | 取得順序は保証されないため後処理で並べ替える |
| バックアップ・復元補助 | 削除済みチームや保持対象メッセージを確認 | 削除後に取得できる期間には上限がある |
| 会議記録の管理 | 会議録画やトランスクリプトのリンクを取得 | 会議の種類や既知の制限を確認する |
重要なのは、Export APIsはTeamsの画面操作を自動化するものではなく、Microsoft GraphでTeamsデータを取り出すための管理者・開発者向けAPIである点です。単に「Teamsの履歴をダウンロードする機能」と捉えると、権限設計や取得漏れ、重複取得でつまずきやすくなります。
2026年6月29日更新で管理者が押さえるべき変更点
2026年6月29日更新の公式情報では、Teams Export APIsで扱えるデータ範囲、ライセンス要件、会議録画・トランスクリプト、保持メッセージ、Copilot関連の記述が整理されています。Microsoft Learn上でも当該ページの最終更新日は2026年6月29日と示されています。(Microsoft Learn)
取得対象はチャットだけではない
Teams Export APIsは、チャットメッセージだけでなく、チャネルメッセージ、共有チャネル、リアクション、添付ファイル情報、制御メッセージ、編集履歴、会議録画、会議トランスクリプトなども対象に含みます。(Microsoft Learn)
特に見落としやすいのは、ユーザーが入力した本文以外の情報です。たとえば「ユーザーAがユーザーBをチャットに追加した」といったシステム生成の制御メッセージも、監査上は重要な証跡になります。ただし、会議関連の制御メッセージは現在サポート対象外とされています。(Microsoft Learn)
DLPライセンス前提で考えすぎない
今回の確認ポイントとして大きいのが、ライセンス要件の整理です。公式ドキュメントでは、Microsoft Teams Export APIsを使うには、エクスポート対象ユーザーに有効なMicrosoft Teamsライセンスが割り当てられている必要がある一方、Microsoft Purview DLPサービスプランや追加のDLPライセンスは不要と説明されています。(Microsoft Learn)
過去にTeams APIのメータリング、model=Aやmodel=B、DLPライセンスを前提に設計していた環境では、最新ドキュメントに合わせて設計書と運用手順を見直す価値があります。Microsoftは、2025年8月25日以降、対象Teams APIはメータリング対象ではなくなり、modelクエリパラメーターは不要で、指定されても無視されると案内しています。(Microsoft Learn)
削除データには取得できる期限がある
Teams Export APIsは、削除済みデータも一定範囲で取得できます。ただし、無期限に取得できるわけではありません。ユーザーがTeamsクライアントから削除したメッセージは削除時点から最大21日、削除済みチームや削除済みの標準・プライベート・共有チャネルのメッセージは削除日から最大30日、削除済みユーザーや非アクティブユーザーのメッセージも条件付きで最大30日とされています。(Microsoft Learn)
このため、インシデント調査や退職者対応で「必要になったら後で取得する」という運用は危険です。退職、チーム削除、チャネル削除、保持ポリシー変更の直後に、誰が、どのAPIで、いつまでに確認するかを運用手順に落とし込む必要があります。
影響範囲：誰が確認すべきか
この更新の影響を受けるのは、Teamsを利用する一般ユーザーというより、Teamsデータを外部システムへ連携する管理者、開発者、セキュリティ部門、コンプライアンス部門です。
| 役割 | 確認すべき内容 |
|---|---|
| Microsoft 365管理者 | 対象ユーザーのTeamsライセンス、管理者同意、アプリ登録の棚卸し |
| Teams管理者 | チーム・チャネル削除時の取得期限、共有チャネルの扱い |
| セキュリティ担当 | 監査ログやSIEM連携で取得すべきメッセージ範囲 |
| コンプライアンス担当 | 保持ポリシー、削除メッセージ、編集履歴の取得要件 |
| 開発者 | Graph APIの権限、ページング、フィルター、スロットリング対応 |
| グローバル運用担当 | 利用クラウド、地域要件、テナント間運用の差分 |
グローバル向けに特に注意したいのは、すべてのMicrosoftクラウド環境で同じように使えるわけではない点です。users/{id}/chats/getAllMessagesやteams/{id}/channels/getAllMessagesのMicrosoft Graph APIドキュメントでは、Global serviceは対応、US Government L4、US Government L5、21Vianet運営の中国クラウドは非対応と示されています。(Microsoft Learn)
必要な権限と設定変更
Teams Export APIsを使うには、Microsoft Entra IDでアプリを登録し、Microsoft Graphのアプリケーション権限を付与し、管理者が同意する流れになります。アプリがサインインユーザーなしでGraphを呼び出す場合は、クライアント資格情報フローを使い、アプリケーション権限を構成します。Microsoftのドキュメントでも、アプリケーション権限は常に管理者同意が必要とされています。(Microsoft Learn)
主なアプリケーション権限
| 取得したいデータ | 主な権限 |
|---|---|
| 1対1チャット、グループチャット、会議チャット | Chat.Read.All |
| チャネルメッセージ | ChannelMessage.Read.All |
| テナント内ユーザー一覧 | User.Read.All |
| 会議トランスクリプト | OnlineMeetingTranscript.Read.All |
| 会議録画 | OnlineMeetingRecording.Read.All |
公式ドキュメントでは、Teams Export APIsに必要な権限として、Chat.Read.All、ChannelMessage.Read.All、User.Read.All、OnlineMeetingTranscript.Read.All、OnlineMeetingRecording.Read.Allが挙げられています。(Microsoft Learn)
実務では、いきなり広い権限を付与するのではなく、目的ごとにアプリを分ける設計が安全です。たとえば、チャットアーカイブ用アプリ、会議トランスクリプト取得用アプリ、検証環境用アプリを分ければ、不要な権限を本番アプリに持たせずに済みます。
APIで取得する基本パターン
Teams Export APIsの代表的な呼び出しは、ユーザー単位のチャット取得と、チーム単位のチャネルメッセージ取得です。
GET https://graph.microsoft.com/v1.0/users/{id}/chats/getAllMessagesGET https://graph.microsoft.com/v1.0/teams/{id}/channels/getAllMessages日次バッチや差分取得に近い運用では、lastModifiedDateTimeで期間を絞るのが基本です。
GET https://graph.microsoft.com/v1.0/users/{id}/chats/getAllMessages?$top=50&$filter=lastModifiedDateTime gt 2026-06-01T00:00:00Z and lastModifiedDateTime lt 2026-06-02T00:00:00ZGET https://graph.microsoft.com/v1.0/teams/{id}/channels/getAllMessages?$top=50&$filter=lastModifiedDateTime gt 2026-06-01T00:00:00Z and lastModifiedDateTime lt 2026-06-02T00:00:00Z公式例でも、ユーザーまたはチームの全メッセージ取得、日付範囲と$topを指定した取得、会議録画・会議トランスクリプトの取得例が示されています。(Microsoft Learn)
ただし、$topは「最大件数のヒント」であり、必ず指定件数が返るわけではありません。複数の基盤メールボックスやフォルダーからメッセージを取得する仕組み上、要求件数より少ない結果と@odata.nextLinkが返る場合があります。(Microsoft Learn)
実装時に失敗しやすいポイント
取得順序が保証されない
Export APIsの応答は、createdDateTimeやlastModifiedDateTimeの順に必ず並ぶわけではありません。公式ドキュメントでも、メッセージの応答順は日時でソートされる保証がないと説明されています。(Microsoft Learn)
そのため、保存先のデータベースやアーカイブシステム側で、id、chatId、channelIdentity、createdDateTime、lastModifiedDateTimeなどを使って並べ替え・重複排除を行う設計が必要です。
全ユーザーを順番に取得すると重複しやすい
ユーザー単位のchats/getAllMessagesは、そのユーザーが送信・受信したチャットメッセージを取得します。全ユーザーに対して同じチャットスレッドを取得すると、同じメッセージを複数回取り込む可能性があります。公式ドキュメントでも、チャットスレッド内の全ユーザーに対してAPIを呼び出すと、重複エクスポートが発生し得ると説明されています。(Microsoft Learn)
実装では、次のような対策を入れると安全です。
| 課題 | 対策 |
|---|---|
| 同じメッセージを複数回取得する | idとchatIdなどで一意性を管理する |
| 日次取得で過去分を再取得する | lastModifiedDateTimeの範囲を固定し、取得済み水位を保存する |
| システムメッセージが混ざる | messageType eq 'systemEventMessage'の扱いを設計する |
| 特定送信者だけ取りたい | from/user/idやfrom/application/applicationIdentityTypeで絞る |
添付ファイルは本文中のURLだけに頼らない
Teamsメッセージにファイルが含まれる場合、Export APIsは添付ファイル情報を含みます。ただし、本文に埋め込まれたURLがそのままアクセス可能とは限らないため、attachmentsコレクションを使って添付ファイルを処理する必要があります。(Microsoft Learn)
アーカイブ製品や自社システムに取り込む場合は、本文、添付ファイルメタデータ、実ファイルの取得可否を分けて設計してください。「本文が取れたから添付も取れている」と判断すると、監査時に証跡不足になる可能性があります。
会議録画・トランスクリプトの扱い
Teams Export APIsでは、指定ユーザーが開催者であるスケジュール済みオンライン会議の録画やトランスクリプトのリンクを取得できます。公式ドキュメントでは、会議録画・会議トランスクリプトはいずれも、現在はプライベートなスケジュール済み会議をサポートすると説明されています。(Microsoft Learn)
代表的な呼び出し例は次の通りです。
GET https://graph.microsoft.com/v1.0/users/{id}/onlineMeetings/getAllRecordings?$filter=MeetingOrganizer/User/Id eq '{id}'GET https://graph.microsoft.com/v1.0/users/{id}/onlineMeetings/getAllTranscripts?$filter=MeetingOrganizer/User/Id eq '{id}'トランスクリプトは既定でVTT形式ですが、Acceptヘッダーにapplication/vnd.openxmlformats-officedocument.wordprocessingml.documentを指定することでDOCX形式も取得できます。(Microsoft Learn)
注意点として、Microsoft Graphの既知の問題では、getAllRecordingsが文字起こしの有効でない会議の録画を返さないこと、getAllRecordingsやgetAllTranscriptsで$topを使うと、さらに取得対象があっても@odata.nextLinkが返らない場合があることが案内されています。(Microsoft Learn)
保持ポリシーとRetained Messages API
Teamsに保持ポリシーが設定されている場合、Export APIsは編集履歴や保持対象メッセージの取得に関係します。公式ドキュメントでは、保持ポリシーが設定されたテナントで、個人チャット、グループチャット、パブリックチャネル、共有チャネルの投稿やコメントの編集履歴を取得できると説明されています。(Microsoft Learn)
保持対象メッセージを取得するAPIの例は次の通りです。
GET https://graph.microsoft.com/v1.0/users/{id}/chats/getAllRetainedMessagesGET https://graph.microsoft.com/v1.0/teams/{id}/channels/getAllRetainedMessagesただし、getAllRetainedMessagesでも万能ではありません。削除済みチャネルメッセージの取得は、チームやチャネルがハード削除されるまでの最大30日という制限があります。(Microsoft Learn)
保持ポリシーは、API利用のためだけに設定するものではありません。法務、セキュリティ、情報管理の要件に基づき、Teamsのチャットとチャネルでどの期間保持するか、削除後に何を調査可能にするかを先に決める必要があります。
スロットリングと性能設計
大量エクスポートでは、スロットリング対策が欠かせません。Microsoft GraphのTeamsサービス制限では、teams/{team-id}/channels/getAllMessagesやusers/{user-id}/chats/getAllMessagesについて、アプリ・テナント単位、アプリ全体単位のリクエスト制限が示されています。(Microsoft Learn)
実装では、単純に並列数を増やすのではなく、次の観点で制御します。
| 設計項目 | 推奨される考え方 |
|---|---|
| 並列処理 | テナント全体、アプリ単位、チーム・チャット単位の制限を分けて制御 |
| ページング | @odata.nextLinkがある限り追跡し、途中失敗時に再開可能にする |
| 日付範囲 | 1日単位、数時間単位など、取得量に応じて分割 |
| 再試行 | 429や一時エラーに対して指数バックオフを実装 |
| 重複排除 | メッセージID、チャットID、チームID、チャネルIDで一意性を管理 |
| 監視 | 取得件数、失敗件数、再試行回数、最終成功時刻を記録 |
特にグローバル企業では、タイムゾーンが異なる拠点のメッセージをUTCで扱う点にも注意が必要です。Graph APIの日時はUTC形式で扱うため、レポートや監査画面ではローカルタイムへの変換ルールを明確にしておきましょう。
移行期限はあるのか
今回の「Export content with the Microsoft Teams Export APIs」の更新自体について、Teams管理者が特定日までに設定変更や移行作業を完了しなければならない、という明確な移行期限は示されていません。したがって、緊急の強制移行というより、既存のExport API利用環境を最新条件に合わせて点検する更新と捉えるのが現実的です。
一方で、古い料金・ライセンスモデルを前提にした設計には注意が必要です。MicrosoftはTeams APIの支払いモデルに関するドキュメントで、2025年8月25日以降、対象Teams APIはメータリング対象外となり、請求設定は不要、modelパラメーターは不要かつ指定しても無視されると説明しています。(Microsoft Learn)
そのため、移行期限として見るべきなのは「いつまでに何かを切り替えるか」ではなく、次のような棚卸し期限です。
| いつまでに | やること |
|---|---|
| すぐ | 既存アプリがTeams Export APIsを使っているか確認 |
| 1〜2週間以内 | 権限、管理者同意、対象ユーザーのTeamsライセンスを棚卸し |
| 次回リリース前 | modelパラメーターや旧料金前提の設定を見直し |
| 次回監査前 | 削除データ、保持データ、会議録画・トランスクリプトの取得手順を検証 |
| 定期運用 | 429エラー、取得漏れ、重複件数、最終成功時刻を監視 |
管理者が確認すべきチェックリスト
Teams Export APIsを本番運用している、または今後利用する場合は、次の順番で確認すると抜け漏れを減らせます。
| 確認項目 | 判断基準 |
|---|---|
| 利用目的 | 監査、アーカイブ、移行、バックアップ、会議記録管理のどれか |
| 対象データ | チャット、チャネル、会議録画、トランスクリプト、保持メッセージ |
| 対象クラウド | Global serviceで利用する前提か、政府系・中国クラウドで使う予定がないか |
| アプリ登録 | Microsoft Entra IDのアプリ登録が本番用・検証用で分離されているか |
| 権限 | Chat.Read.Allなど必要最小限のアプリケーション権限か |
| 管理者同意 | 権限変更後に再同意が行われているか |
| ライセンス | エクスポート対象ユーザーに有効なTeamsライセンスがあるか |
| 保持ポリシー | 編集履歴や保持メッセージの要件に合っているか |
| 削除データ | 21日・30日の取得期限を運用手順に反映しているか |
| 実装 | ページング、並べ替え、重複排除、再試行が実装されているか |
| 監視 | API失敗、取得件数、最終成功時刻を追跡できるか |
まとめ：まずは既存API利用状況と権限を棚卸しする
Microsoft Teams Export APIsは、Teamsのチャットやチャネルメッセージを外部に取り出すための重要なMicrosoft Graph APIです。2026年6月29日更新の公式情報では、取得対象、会議録画・トランスクリプト、保持メッセージ、削除済みデータ、ライセンス要件、DLPライセンス不要の扱いなど、管理者が確認すべきポイントが整理されています。(Microsoft Learn)
まず行うべきことは、既存アプリがTeams Export APIsを使っているか、どの権限で、どのユーザー・チーム・会議データを取得しているかの棚卸しです。そのうえで、削除後21日・30日の取得期限、保持ポリシー、グローバルクラウド対応、スロットリング、会議録画・トランスクリプトの既知の制限を運用手順に反映してください。
特に、監査やインシデント対応で使う場合は、APIが動くことだけでなく、「必要なデータを、必要な期間内に、重複や欠落なく、説明可能な形で保存できるか」が重要です。Teams Export APIsは強力ですが、設計を誤ると取得漏れや過剰権限につながります。最新の公式情報を前提に、権限・保持・取得ロジック・監視をセットで見直しましょう。
コメント