Microsoft Teamsの「Microsoft Teams Build 2026 updates add new admin and developer questions」は、単なる新機能紹介ではなく、Teams管理者・アプリ開発者・セキュリティ担当者が確認すべき項目が同時に増えた更新群として捉えるのが実務的です。特に2026年6月3日の公式更新では、TeamsモバイルでのQueuesアプリ対応と、外部ドメインとの異常なやり取りを把握するレポートが追加され、管理者は外部コラボレーション、Teams Phone、アプリガバナンスの見直しが必要になります。(Microsoft Learn)
一方、Build 2026前後のTeams Platform更新では、Teams SDK、Teams Developer CLI、エージェント向けのスラッシュコマンド、ターゲットメッセージ、リアクション、共有／プライベートチャネル対応など、開発者側の確認ポイントも増えています。この記事では、何が変わるのか、誰に影響するのか、管理者・開発者がどの順番で確認すべきかを、実務目線で整理します。(Microsoft Learn)
Microsoft Teams Build 2026 updatesは何が変わるのか
今回のポイントは、Teamsが「チャット・会議ツール」から、エージェント、業務アプリ、外部コラボレーション、電話業務まで含む業務ハブとしてさらに広がっていることです。
Teams管理者にとっては、外部組織とのやり取りやアプリ利用状況をどう監視するかが重要になります。開発者にとっては、Teams上で動くエージェントやアプリを、ユーザーの会話文脈に自然に組み込む設計が求められます。
| 対象者 | 主な変更点 | まず確認すべきこと |
|---|---|---|
| Teams管理者 | Queuesアプリのモバイル対応、外部ドメイン異常レポート | Teams Phone、外部アクセス、アプリ管理ポリシー |
| セキュリティ担当者 | 外部組織との異常なコミュニケーション可視化 | 外部ドメイン許可／拒否、監査、対応フロー |
| Teamsアプリ開発者 | Teams SDK、CLI、エージェント機能、マニフェスト更新 | SDKバージョン、manifest.json、プレビュー機能の扱い |
| 現場部門 | モバイルでのキュー対応、エージェント操作の変化 | 業務フロー、ユーザー教育、問い合わせ窓口 |
重要なのは、すべての機能をすぐ有効化することではありません。自社のTeams利用範囲に関係する更新だけを棚卸しし、管理ポリシー・アプリ権限・ユーザー影響を確認してから段階展開することが安全です。
2026年6月3日の管理者向け更新で押さえるべき点
2026年6月3日のTeams管理者向け公式リリースノートでは、主に2つの更新が示されています。1つ目はTeamsモバイルでQueuesアプリを利用できるようにする更新、2つ目は外部ドメインとの異常なやり取りを検出するExternal Domains Anomalies Reportです。(Microsoft Learn)
QueuesアプリのTeamsモバイル対応
QueuesアプリのTeamsモバイル対応により、移動中の担当者でもキューの状態確認、キューへの参加・離脱、リアルタイム指標の確認ができるようになります。公式情報では、顧客対応を効率化し、外出中でも応答性を維持するための機能として説明されています。(Microsoft Learn)
この更新の影響を受けやすいのは、次のような組織です。
- コールセンターや問い合わせ窓口でTeams Phoneを使っている
- 店舗、医療、製造、フィールドサポートなど、PCの前に常駐しない担当者がいる
- 業務時間中に担当者が場所を移動しながら顧客対応する
- 応答率、待ち時間、キュー状況を現場で確認したい
管理者が確認すべきなのは、「使えるようになったか」だけではありません。モバイルでキュー参加・離脱ができるようになると、現場の運用ルールも変わります。
| 確認項目 | 実務で見るポイント |
|---|---|
| 対象ユーザー | モバイルでキュー対応する必要がある職種に限定する |
| 通知設計 | 業務時間外や休憩中に通知が過剰にならないか確認する |
| 参加・離脱ルール | 担当者が勝手に離脱して応答率が下がらないよう運用ルールを決める |
| サポート体制 | モバイルアプリの操作手順、トラブル時の問い合わせ先を用意する |
| レポート確認 | キュー指標を誰が、どの頻度で確認するか決める |
特に注意したいのは、モバイル対応によって「いつでも対応できる」と誤解されることです。現場負荷を増やさないために、勤務時間、シフト、通知、キュー参加条件を明文化してから展開しましょう。
External Domains Anomalies Reportの追加
External Domains Anomalies Reportは、Teamsで外部組織とのやり取りが増える中で、通常とは異なる外部ドメインとのコミュニケーションを管理者が把握しやすくする機能です。公式情報では、急な通信量の増加、新しいドメイン、異常なエンゲージメントパターンなどを分析し、データ共有やセキュリティ上のリスクを早期に可視化する目的が説明されています。(Microsoft Learn)
この機能は、外部コラボレーションを禁止するためのものではなく、安全に外部連携を続けるための検知・確認手段として考えるべきです。
たとえば、次のようなケースで役立ちます。
- 取引実績のない外部ドメインとのやり取りが急に増えた
- 特定部門だけが未知の外部組織と頻繁に会話している
- プロジェクト終了後も外部ユーザーとのやり取りが続いている
- 外部共有の棚卸しを手作業だけで行うのが難しい
管理者は、レポートを見て終わりにせず、次のような運用フローに落とし込む必要があります。
| ステップ | 実施内容 |
|---|---|
| 検知 | External Domains Anomalies Reportで異常な外部ドメインを確認する |
| 確認 | 該当ドメインが正規の取引先・委託先・一時的なプロジェクト関係者か調べる |
| 判断 | 業務上必要な通信か、誤共有・不要な外部連携かを部門責任者に確認する |
| 対応 | 必要に応じて外部アクセス設定、ゲストアクセス、共有ポリシーを見直す |
| 記録 | 調査結果と対応内容を監査用に残す |
失敗しやすいのは、異常検知を「すべて危険」と扱ってしまうことです。営業、採用、広報、パートナー連携では、外部ドメインとの接触が一時的に増えることがあります。大切なのは、検知結果を業務文脈と照らし合わせ、必要な連携と不要なリスクを切り分けることです。
Build 2026前後の開発者向け更新で重要なポイント
Teams Platformの公式「What’s new for developers」では、Teams開発者向けの一般提供機能とDeveloper Preview機能が整理されています。2026年4月にはPrompt startersが一般提供として示され、2026年5月にはスラッシュコマンドやエージェントリアクションなどがDeveloper Previewとして追加されています。(Microsoft Learn)
ここで管理者と開発者が混同してはいけないのが、一般提供とDeveloper Previewの違いです。Developer Previewは検証や早期評価に向きますが、本番業務に全面展開する場合は、サポート状況、仕様変更リスク、テナント設定、監査要件を確認する必要があります。
Teams Developer CLIとTeams SDKの確認
Teams SDKのQuickstartでは、Teams Developer CLIを使ってTeams SDKの開発を始める流れが示されています。前提条件として.NET 8以上、Python 3.12以上、Node.js 20以上が挙げられており、CLIはTeamsアプリのスキャフォールディング、登録、管理を行うコマンドラインツールとして説明されています。(Microsoft Learn)
開発チームがまず確認すべきなのは、以下の3点です。
| 確認項目 | 判断基準 |
|---|---|
| ランタイム | .NET、Python、Node.jsのバージョンが公式要件を満たしているか |
| CLIの扱い | Preview表記のあるCLIを本番CI/CDに組み込むか、検証環境に限定するか |
| 既存アプリへの影響 | 既存のTeamsアプリ、Bot、Message Extensionを新SDKへ移行する必要があるか |
特にCLIをCI/CDで使う場合は、バージョンを固定せずに常に最新版を取得する構成は避けるべきです。Preview段階のツールは仕様や挙動が変わる可能性があるため、検証用パイプラインで動作確認してから本番リリースに組み込みましょう。
Teams SDK v1からの移行で注意すること
Teams SDK v1からの移行ガイドでは、メッセージハンドラー、認証、ActionPlannerなどを含む移行ポイントが説明されています。新しいTeams SDKのインストールは既存のSDKを直ちに置き換えるものではなく、移行完了後に既存のteams-aiや@microsoft/teams-ai依存関係を削除する流れが示されています。(Microsoft Learn)
移行時に見落としやすいのは、単なるパッケージ更新では済まない点です。公式ガイドでは、Applicationクラスから新しいAppクラスへの移行、タスクモジュールがDialogsへ名称変更されていること、ActionPlannerがより軽量な仕組みに置き換えられることなどが説明されています。(Microsoft Learn)
移行計画では、次の順番で確認すると安全です。
- 現行アプリが使っている機能を棚卸しする
Bot、タブ、Message Extension、認証、Adaptive Cards、フィードバック機能を一覧化します。 - SDK v2で変更が必要な箇所を分類する
メッセージ処理、認証、Dialogs、ActionPlanner、フィードバック処理を分けて確認します。 - 既存SDKと新SDKを並行検証する
いきなり置き換えるのではなく、検証ブランチや検証テナントで動作を比較します。 - マニフェストと権限を再確認する
機能追加だけでなく、不要な権限が残っていないかも確認します。 - 本番展開前に管理者レビューを入れる
アプリ登録、Graph権限、RSC権限、外部ユーザーへの影響を管理者と確認します。
エージェント機能は「便利さ」と「プライバシー」をセットで見る
Build 2026前後のTeams更新では、エージェントをTeams内で使いやすくする機能が目立ちます。ただし、グループチャット、チャネル、会議チャットの中でエージェントが動く場合、ユーザーは「何が全員に見えて、何が自分だけに見えるのか」を誤解しやすくなります。
スラッシュコマンドは発見しやすいが、実装は自動ではない
スラッシュコマンドは、Teamsのメッセージ入力欄から/でアプリやエージェントのコマンドを呼び出せる機能です。公式ドキュメントでは、名前付きコマンドをTeamsの入力欄から発見・実行しやすくするものとして説明され、ターゲットメッセージ、エージェントスラッシュコマンド、Message Extensionのスラッシュコマンドが扱われています。(Microsoft Learn)
開発者が注意すべきなのは、マニフェストにコマンドを追加しただけでは業務ロジックは完成しないことです。公式情報でも、設定はTeamsクライアント上にコマンドを表示するだけで、実際の解釈や処理はエージェント側のメッセージハンドラーで実装する必要があると説明されています。(Microsoft Learn)
実務では、次のように設計すると使いやすくなります。
| 良い設計 | 避けたい設計 |
|---|---|
/help、/summarize、/settingsのように短く動詞中心 | 長い自然文をそのままコマンド名にする |
| コマンド説明に入力例を書く | コマンド名だけで何が起きるか分からない |
| 個人向け結果はターゲットメッセージで返す | 機密性のある結果をチャネル全体に投稿する |
| 失敗時のメッセージを用意する | 権限不足や入力ミスで無反応になる |
ターゲットメッセージは便利だが、永続情報には向かない
ターゲットメッセージは、チャネル、グループチャット、会議チャットの中で、ユーザーとエージェントが1対1で非公開にやり取りできる機能です。公式ドキュメントでは、他の参加者には見えないメッセージとして説明され、1対1チャットでは利用できないこと、ユーザーと単一エージェント間でのみ利用できることが示されています。(Microsoft Learn)
重要なのは、ターゲットメッセージが24時間後にTeamsクライアントから消える点です。ただし、組織の保持ポリシーに応じて安全なストレージに保持される可能性もあると説明されています。(Microsoft Learn)
この仕様から、適した用途と避けるべき用途が分かれます。
| 向いている用途 | 向いていない用途 |
|---|---|
| 認証フローの補助 | 契約条件や正式承認の保存 |
| 個人向けエラー通知 | 長期的に参照すべき業務記録 |
| 会議中の個別リマインダー | 全員に共有すべき決定事項 |
| エージェントの下書き確認 | 監査上、明示的な記録が必要な指示 |
管理者は、ターゲットメッセージを「見えないから安全」と単純に考えないことが大切です。ユーザーから見ると非公開でも、組織の保持・監査ポリシーとの関係は別途確認が必要です。
エージェントリアクションは通知疲れを減らすために使う
エージェントリアクションは、エージェントがテキスト返信だけでなく、メッセージにリアクションを付けられる機能です。公式情報では、通知疲れを抑えながらアクションを効率的に伝える目的が説明され、リアクションの追加・削除、レスポンスコード、絵文字のスキントーン選択などが扱われています。(Microsoft Learn)
便利な一方で、使いすぎると逆効果です。公式のベストプラクティスでも、ユーザー体験の向上に使うこと、過剰利用を避けること、文脈に合うリアクションにすることが推奨されています。(Microsoft Learn)
たとえば、次のような使い方が現実的です。
- エージェントが依頼を受け付けたことをリアクションで示す
- 処理完了後に短い確認リアクションを付ける
- エラーや要確認の場合だけテキストで詳しく返す
- 連続リアクションを避け、同じメッセージに複数の反応を付けない
「返信文を減らすための機能」として使えば効果がありますが、「エージェントを目立たせるための装飾」として使うと、チャットのノイズが増えます。
Prompt startersとSuggested actionsはユーザー定着に効く
Prompt startersは、ユーザーがBotやエージェントとの会話を始めやすくするための提案コマンドです。公式ドキュメントでは、Teamsチャット内に表示されるコマンドとして説明され、Prompt startersは会話開始、Suggested actionsは会話継続を助けるものとされています。(Microsoft Learn)
特に初心者向けの社内エージェントでは、Prompt startersの有無で利用率が変わります。何を聞けばよいか分からないエージェントは、機能が優れていても使われません。
実務では、次のようなPrompt startersが有効です。
| エージェントの用途 | Prompt starter例 |
|---|---|
| 社内FAQ | 「経費精算の締切を教えて」 |
| 会議支援 | 「この会議の決定事項を整理して」 |
| 営業支援 | 「この顧客の次回提案に必要な情報をまとめて」 |
| 情シス窓口 | 「Teams会議の録画が見つからない場合の対処を教えて」 |
注意点として、Prompt startersを使う場合は歓迎メッセージとの併用に気を付ける必要があります。公式ドキュメントでは、BotはPrompt starterまたはWelcome messageのどちらかを使えるとされ、Prompt starterを使う場合はWelcome messageを送らないよう説明されています。(Microsoft Learn)
また、マニフェストの変更は再展開が必要です。Prompt startersを頻繁に変える運用にするなら、開発・承認・展開の流れをあらかじめ決めておきましょう。(Microsoft Learn)
共有チャネル・プライベートチャネル対応で起きやすい落とし穴
Teamsアプリの共有チャネル対応は一般提供、プライベートチャネル対応はDeveloper Previewとして説明されています。公式ドキュメントでは、共有チャネルは組織内外のメンバーと文脈を変えずに共同作業でき、プライベートチャネルは選ばれたメンバーだけで機密性の高い内容を扱う場として整理されています。(Microsoft Learn)
ここで最も危険なのは、標準チャネルと同じ前提でアプリを動かすことです。
公式情報では、共有／プライベートチャネルではアプリを各チャネルに追加する必要があること、チームメンバーシップとチャネルメンバーシップを同一視してはいけないこと、標準チャネルとはSharePointサイトの扱いが異なることなどが説明されています。(Microsoft Learn)
開発者は、少なくとも次の点を確認してください。
| 確認項目 | なぜ重要か |
|---|---|
| チームメンバーとチャネルメンバーを分けて扱う | プライベートチャネルの情報をチーム全体に漏らさないため |
| 外部ユーザーのテナントIDを確認する | クロステナント利用時の権限誤判定を防ぐため |
| SharePointサイトURLを正しく使う | ファイル取得失敗や不正アクセスを防ぐため |
| チャネル単位でデータをスコープする | 分析や通知で機密情報を混在させないため |
supportsChannelFeaturesを確認する | アプリが共有／プライベートチャネルに対応していることを示すため |
共有チャネルやプライベートチャネルは、外部連携や機密情報を扱う場になりやすいため、アプリの不具合がそのまま情報漏えいにつながる可能性があります。単に「動くか」ではなく、「見せてよい人にだけ見えているか」をテストしましょう。
管理者が確認すべき設定・ポリシー
Teams管理者は、今回の更新を受けて次の設定を優先的に確認するとよいでしょう。
| 領域 | 確認する設定・画面 | 確認内容 |
|---|---|---|
| 外部コラボレーション | Teams管理センターの外部アクセス、ゲストアクセス関連設定 | 外部ドメインの許可／拒否、部門別ポリシー、不要な外部連携 |
| 外部ドメイン監視 | External Domains Anomalies Report | 急増ドメイン、新規ドメイン、異常な通信パターン |
| Teams Phone | キュー、通話ポリシー、モバイル利用対象者 | モバイルでのキュー参加・離脱、通知、現場ルール |
| アプリ管理 | Teams管理センターのアプリ許可、ブロック、認定アプリ設定 | サードパーティアプリ、カスタムアプリ、エージェントの許可範囲 |
| 開発者機能 | Developer Preview、カスタムアプリアップロード | 検証テナントと本番テナントを分けているか |
| 監査・保持 | Microsoft Purview、監査ログ、保持ポリシー | ターゲットメッセージや外部連携の記録方針 |
同時期のTeams管理者向けリリースでは、Microsoft 365認定SaaSアプリを組織全体のサードパーティアプリ設定から有効化できる機能や、アプリとエージェントのTrust Scoreを自動評価する仕組みも示されています。アプリ導入のスピードを上げる一方で、権限・プライバシー・コンプライアンスの確認を省略しない運用が必要です。(Microsoft Learn)
開発者が確認すべきmanifest.jsonと権限
Teamsアプリやエージェントを開発している場合、manifest.jsonの確認は必須です。今回の更新では、スラッシュコマンド、ターゲットメッセージ、共有／プライベートチャネル対応など、マニフェスト設定が関係する項目が多いためです。
特に確認したいのは、次の項目です。
| 機能 | 確認するマニフェスト・権限 |
|---|---|
| スラッシュコマンド | bots[].commandLists[]、triggers、composeExtensions[].commands[] |
| ターゲットメッセージ | エージェントの受信対応設定、supportsTargetedMessages関連 |
| 共有／プライベートチャネル | supportsChannelFeatures: tier1、チャネル単位のインストール |
| 会議イベント | team、groupChatスコープ、必要なRSC権限 |
| メンバーシップ監視 | ChannelMember.Read.GroupなどのRSC権限 |
| Prompt starters | commands、title、description、type、prompt |
会議イベントを扱うBotでは、manifest.jsonにteamとgroupChatスコープを含めること、必要なResource-Specific Consent権限を指定すること、Developer PortalでMeeting Event Subscriptionsを有効にすることが求められます。(Microsoft Learn)
権限設定で失敗しやすいのは、「動作確認のために広い権限を付け、そのまま本番に残す」パターンです。検証後は、実際に必要なスコープとRSC権限だけに絞り、管理者承認の記録を残しましょう。
展開前に使えるチェックリスト
今回のTeams Build 2026 updatesを自社環境に反映する前に、次のチェックリストで影響範囲を確認してください。
| チェック項目 | 管理者 | 開発者 | セキュリティ |
|---|---|---|---|
| Teams管理センターで6月3日更新に関係する機能を確認した | ✅ | ✅ | |
| Queuesアプリを使う対象部門とユーザーを特定した | ✅ | ||
| 外部ドメイン異常レポートの確認担当者を決めた | ✅ | ✅ | |
| 外部アクセス・ゲストアクセス設定を棚卸しした | ✅ | ✅ | |
| カスタムアプリとサードパーティアプリを一覧化した | ✅ | ✅ | ✅ |
| Developer Preview機能を本番で使わないルールを決めた | ✅ | ✅ | |
| SDK、CLI、Node.js、Python、.NETのバージョンを確認した | ✅ | ||
| manifest.jsonの変更点をレビューした | ✅ | ✅ | ✅ |
| ターゲットメッセージの保持・監査方針を確認した | ✅ | ✅ | ✅ |
| 共有／プライベートチャネルで情報漏えいテストをした | ✅ | ✅ | ✅ |
| 利用者向けの簡易マニュアルを用意した | ✅ | ||
| サポート窓口に想定問い合わせを共有した | ✅ | ✅ |
最初から全社展開する必要はありません。まずは影響の大きい部門を1つ選び、検証テナントまたは限定ユーザーで試すのが安全です。
よくある疑問
すぐにTeamsの設定変更が必要ですか？
すぐに全社設定を変更する必要はありません。ただし、Teams Phoneのキュー運用、外部コラボレーション、カスタムアプリ、エージェント開発を行っている組織では、早めに影響範囲を確認すべきです。
特にExternal Domains Anomalies Reportは、外部連携の実態を把握するきっかけになります。見つかった異常をすぐ遮断するのではなく、業務上必要な連携かどうかを確認する運用から始めましょう。
Developer Preview機能は本番で使ってよいですか？
原則として、Developer Previewは検証用として扱うのが無難です。スラッシュコマンド、ターゲットメッセージ、エージェントリアクションなどは魅力的ですが、仕様変更やクライアント差異が起きる可能性があります。
本番利用を検討する場合は、対象ユーザーを限定し、管理者承認、利用規約、監査、サポート対応を整えてから展開してください。
エンドユーザーには何を伝えるべきですか？
ユーザーには、細かい技術仕様よりも「操作がどう変わるか」を伝えるべきです。
たとえば、Queuesアプリを使う現場担当者には、モバイルでのキュー参加・離脱、通知、応答ルールを説明します。エージェントを使うユーザーには、スラッシュコマンドの使い方、非公開で返るメッセージと全員に見えるメッセージの違いを伝えると混乱を防げます。
開発者が最初に着手すべきことは何ですか？
まず、既存Teamsアプリの棚卸しです。Bot、タブ、Message Extension、会議アプリ、社内エージェントを一覧化し、どのアプリが新SDK、マニフェスト更新、共有／プライベートチャネル、ターゲットメッセージに関係するかを分類します。
そのうえで、SDKやCLIの検証、manifest.jsonの更新、権限レビューを進めると、不要な手戻りを減らせます。
まずは「影響範囲の棚卸し」から始める
Microsoft Teams Build 2026 updatesで見るべきポイントは、単に新機能を試すことではありません。管理者は外部コラボレーション、Teams Phone、アプリガバナンスを見直し、開発者はTeams SDK、CLI、エージェント機能、マニフェスト、権限設計を確認する必要があります。
最初に行うべきことは、次の3つです。
- 自社で使っているTeams機能を棚卸しする
Teams Phone、外部アクセス、ゲスト、カスタムアプリ、エージェント、共有チャネルを確認します。 - 公式情報で一般提供とプレビューを分ける
すぐ本番展開できるものと、検証にとどめるものを分類します。 - 管理者・開発者・セキュリティ担当でレビューする
Teams更新は単独部門では完結しません。機能、権限、監査、ユーザー教育をまとめて確認しましょう。
今回の更新は、Teamsをより便利にする一方で、管理対象も広げます。新機能を急いで有効化するよりも、まずは影響範囲を把握し、小さく検証し、ポリシーと運用を整えてから展開することが、失敗しない進め方です。
コメント