Microsoft Teams documentation update: Start blog post for 2.1 preview の要点は、Teams SDK for .NET 2.1 Preview に関する告知・Agent 365・Bot Framework移行の情報が、1本の包括的な告知記事に整理されたことです。Teamsの一般ユーザー向けに即時の画面変更が入る更新ではなく、Teams botやTeamsアプリを開発・運用している管理者、開発者、セキュリティ担当者が確認すべきドキュメント更新です。
特に重要なのは、Teams SDK 2.0からの移行ポイント、Bot Framework v4 botの互換移行、Agent 365を前提にしたagentic identityの扱いです。既存のTeams botを運用している場合は「プレビューだから後で見る」ではなく、NuGetパッケージ、認証設定、権限、ログ・監査、展開手順に影響がないかを早めに棚卸ししておくと安全です。公式PRでは、3本に分かれていたブログ投稿を1本に統合し、Teams SDK 2.0からの移行セクションを追加し、「Agents 365」表記を「Agent 365」に修正したことが示されています。(GitHub)
Microsoft Teams documentation update: Start blog post for 2.1 previewで何が変わったのか
今回の更新は、Microsoft Teamsそのものの利用画面を変えるアップデートというより、Teams SDK for .NET 2.1 Previewの説明と移行導線を整理するドキュメント更新です。対象は、Teams bot、Teamsアプリ、Bot Framework v4 bot、Teams SDK 2.0ベースの実装を扱う開発・運用チームです。
公式リポジトリ上のPR「Start blog post for 2.1 preview」では、1ファイルのブログ記事が追加され、Teams SDK for .NET 2.1 Previewの主な変更として、ASP.NET Core統合、Agent 365によるagentic identity、Bot Framework v4からの移行、Teams SDK 2.0からの移行がまとめられています。追加されたブログ記事のメタデータでは、タイトルが「Announcing Teams SDK for .NET 2.1 Preview」、日付が2026年5月19日とされています。(GitHub)
変更点を実務目線で整理すると、次のようになります。
| 変更点 | 何が変わるか | 確認すべき担当者 |
|---|---|---|
| 3本のブログ投稿を1本に統合 | 告知、Agent 365、Bot Framework移行の情報を同じ記事内で確認できる | 開発リード、技術広報、運用担当 |
| Teams SDK 2.0移行セクションを追加 | 後方互換API、破壊的変更、削除パッケージの把握がしやすくなる | .NET開発者、アーキテクト |
| Agent 365表記とリンクを修正 | Microsoftの正式な製品・概念名に沿った参照に統一される | 管理者、セキュリティ担当 |
| Bot Framework v4移行を明記 | 既存のIBot実装を活かした移行方針が分かる | Bot Framework利用チーム |
| プレビュー提供を前提に説明 | 本番適用前の検証、フィードバック、変更追跡が必要になる | 管理者、QA、SRE |
影響を受けるのは誰か
今回のMicrosoft Teams documentation updateは、Teamsを使って会議やチャットをしている一般ユーザーには、直接の影響はほとんどありません。影響が大きいのは、Teams上で動くbotやAIエージェントを作っている組織です。
影響が大きいケース
次のいずれかに当てはまる場合は、内容を確認する価値があります。
| 対象 | 確認すべき理由 |
|---|---|
| Teams SDK 2.0でTeams botを開発している | 名前空間、OAuthイベント、削除パッケージなどの移行ポイントがある |
| Bot Framework v4のbotをTeamsで運用している | 互換パッケージを使った移行パターンが示されている |
| .NETでTeamsアプリを開発している | ASP.NET Core標準のDI、Logging、Configurationに寄せた構成を検討できる |
| Agent 365やAI teammateを検証している | agentic identityによる権限・監査・ID管理の見直しが必要になる |
| Teamsアプリの審査・展開を管理している | プレビューSDK採用時の検証範囲、ロールバック、権限承認を整理する必要がある |
影響が限定的なケース
単にTeamsクライアントを利用しているだけのユーザー、標準機能だけを管理している小規模環境、独自Teams botを使っていない組織では、すぐに作業が必要になる可能性は低いです。ただし、今後Agent 365やTeams上のAIエージェントを導入する予定がある場合は、今回の内容を早めに読んでおくと設計判断がしやすくなります。
Teams SDK for .NET 2.1 Previewの主なポイント
追加された告知記事では、Teams SDK for .NET 2.1 Previewを使うことで、Teams botアプリをASP.NET Coreアプリとして扱いやすくなること、Agent 365のagentic identityに対応すること、Bot Framework v4 botを互換レイヤーで移行できることが示されています。インストール例として、Microsoft.Teams.Appsパッケージを--prerelease付きで追加するコマンドも掲載されています。(GitHub)
dotnet add package Microsoft.Teams.Apps --prereleaseここで注意したいのは、--prereleaseである点です。プレビュー版は、正式リリース前に機能を試し、フィードバックを返すための位置づけです。本番環境の主要botにいきなり適用するのではなく、検証用テナント、検証用Azure環境、ステージング環境で動作確認してから判断するのが現実的です。
ASP.NET Core統合で開発・運用がどう変わるか
Teams SDK for .NET 2.1 Previewでは、Teams botをASP.NET Coreの標準的な構成に近づける方向が強調されています。AddTeamsBotApplication()でSDKに必要なサービスをDIに登録し、UseTeamsBotApplication()でASP.NET Coreのパイプラインに組み込む流れです。認証設定はappsettings.jsonのAzureAdセクションで扱い、MSALをベースに、クライアントシークレット、マネージドID、フェデレーションID資格情報をサポートすると説明されています。(GitHub)
実務上のメリットは、Teams専用の独自構成を覚える範囲が減り、既存の.NETアプリ開発・運用の知識を使いやすくなることです。
たとえば、次のような運用がしやすくなります。
| 観点 | 期待できる効果 | 注意点 |
|---|---|---|
| DI | 既存サービス、Graphクライアント、独自リポジトリを注入しやすい | ライフタイム設定を誤ると状態共有やメモリ使用量の問題が起きる |
| Logging | ILoggerベースでログ収集基盤に統合しやすい | agentic identity利用時は誰の操作として記録するかを明確にする |
| Configuration | appsettings.jsonや環境変数で環境別設定を管理しやすい | 旧Bot Framework形式のキーを残したままにしない |
| 認証 | MSALベースでAzure AD設定に寄せられる | クライアントシークレットの保管、ローテーション、マネージドID化を検討する |
特に開発チームが確認すべきなのは、設定ファイルの形式です。旧来のBot Framework構成では、MicrosoftAppId、MicrosoftAppPassword、MicrosoftAppTenantIdのようなフラットなキーを使っていたケースがあります。一方、今回の例ではAzureAd配下にTenantId、ClientId、ClientCredentialsを置く形が示されています。構成変更だけでなく、CI/CDのシークレット注入、Key Vault参照、環境変数名の設計も合わせて見直してください。
Agent 365とagentic identityで確認すべきこと
今回の更新では、Agent 365とagentic identityが大きなテーマになっています。Microsoft Learnでは、Agent 365は組織内のエージェントを観察、保護、ガバナンスするための制御プレーンと説明されています。(Microsoft Learn)
告知記事では、Agent 365を使うことで、botがAI teammateとして動作し、Microsoft 365内で独自のメールボックス、Teamsプレゼンス、ディレクトリエントリ、マネージャー関係を持つIDとして扱われることが説明されています。また、従来のbotがアプリ権限でAPIを呼び出すのに対し、AI teammateは自身のIDに基づく権限でAPIを呼び出し、監査ログ上の帰属も変わるとされています。(GitHub)
これは便利な一方で、管理者にとっては確認項目が増える領域です。AIエージェントが「どの権限で」「どのデータにアクセスし」「どのログにどう残るか」を明確にしないまま展開すると、後から監査やデータ保護の説明が難しくなります。
管理者が確認すべきAgent 365関連ポイント
| 確認項目 | 見るべき内容 |
|---|---|
| エージェントのID | 対象エージェントが通常のアプリとして動くのか、AI teammateとして動くのか |
| 権限範囲 | Microsoft GraphやTeams関連APIに対する権限が過剰でないか |
| 監査ログ | 操作がアプリ、ユーザー、AI teammateのどれに帰属するか |
| データアクセス | メール、ファイル、チャット、会議情報へのアクセス範囲が業務上必要な範囲に限定されているか |
| 展開対象 | 全社展開ではなく、検証部門・限定ユーザーから開始できるか |
| セキュリティレビュー | Defender、Purview、Entra IDなど既存の統制と矛盾しないか |
Agent 365関連の機能はプレビュー扱いの情報も含まれます。Microsoft Learnでも、プレビュー機能は本番利用を目的としたものではなく、制限や変更の可能性があると明記されています。(Microsoft Learn)
Bot Framework v4からの移行で見るべきポイント
既存のBot Framework v4 botを持っているチームにとって、今回の更新で実務的に重要なのは、全面的な書き換えを前提にしていない点です。告知記事では、Microsoft.Teams.Apps.BotBuilderパッケージが互換レイヤーを提供し、既存のIBot実装を新しいSDKインフラ上で最小限の変更で動かせると説明されています。ConversationState、UserState、Dialogs、WaterfallDialogs、SSO、Middlewareなどのビジネスロジックはそのまま使えるとされています。(GitHub)
ただし、「移行が簡単」と「確認なしで置き換えてよい」は別です。特に、ホスティング、HTTPアダプター、構成ファイル、認証、ログ出力は動作に直結します。
Bot Framework v4移行時の実務チェック
| 項目 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| NuGetパッケージ | Microsoft.Bot.Builder.Integration.AspNet.Coreから互換パッケージへの置き換え | 古いパッケージが残り、依存関係が複雑になる |
| エンドポイント | 既存の/api/messagesを維持するか | Teams側のBot endpoint設定とアプリ側ルーティングがずれる |
| 認証設定 | 旧形式のMicrosoftAppIdなどをAzureAd形式へ移行 | 環境変数やKey Vault側の名前を変更し忘れる |
| 状態管理 | ConversationStateやUserStateが想定通り動くか | ストレージ接続先をステージングと本番で取り違える |
| ダイアログ | 既存のWaterfallDialogが同じ順序で動くか | Middlewareや例外処理の順序が変わる |
| SSO | サインイン完了、失敗、再認証の挙動 | OAuthイベントの扱いを新旧で混同する |
移行テストでは、単に「メッセージを返す」だけでは不十分です。実際のTeams環境で、インストール、メンション、1対1チャット、チャネル投稿、Adaptive Card、SSO、プロアクティブメッセージ、エラー時の再試行まで確認してください。
Teams SDK 2.0からの移行で注意すべき破壊的変更
今回追加された「Migration from Teams SDK 2.0」セクションでは、多くのAPIはそのまま使える一方で、移行が必要な変更点も明記されています。主な変更として、context.Refの削除、OAuthイベントのper-flowコールバック化、Activity型の名前空間変更、削除されたパッケージの置き換えが示されています。(GitHub)
特に注意すべき点は次のとおりです。
| 項目 | 旧 | 新・代替 | 実務上の注意 |
|---|---|---|---|
| 会話参照 | context.Ref.Conversation | context.Activity.Conversation | 参照箇所を検索し、テストで会話ID取得を確認する |
| OAuthイベント | teams.OnSignIn(...) | teams.GetOAuthFlow("graph").OnSignInComplete(...) | 複数OAuth接続がある場合はフロー単位で整理する |
| Activity名前空間 | Microsoft.Teams.Api.Activities | Microsoft.Teams.Apps.Schema | using変更だけで済む箇所と型差分がある箇所を分けて確認する |
| TeamsInfo | TeamsInfo | TeamsApiClient | チーム・メンバー情報取得の呼び出しを重点確認する |
| Graph拡張 | Microsoft.Teams.Extensions.Graph | Microsoft.Graph | Graph SDK側の認証・権限・API差分を確認する |
| AI関連 | Microsoft.Teams.AIなど | Microsoft.Extensions.AI | 既存のAI呼び出しコードを単純置換しない |
| Card関連 | Microsoft.Teams.Cards | TeamsActivityBuilderとAddAdaptiveCardAttachment() | Adaptive Card生成・送信のテストが必要 |
| Plugin | Microsoft.Teams.Plugins.* | ASP.NET Core middlewareとDI | プラグイン前提の初期化処理を設計し直す |
「多くのAPIが後方互換」と書かれていても、削除パッケージに依存している場合は作業量が増えます。まず.csprojとusingを検索し、削除対象パッケージに依存している箇所を一覧化してください。
管理者が確認すべき設定・権限・展開のポイント
Teamsアプリの管理者は、コード変更そのものよりも、展開時の統制に注意する必要があります。プレビューSDKやAgent 365連携を含むTeams botは、アプリ権限、ユーザー同意、管理者同意、監査ログ、データ保護と結びつきます。
展開前チェックリスト
| チェック項目 | 確認内容 |
|---|---|
| 対象アプリの棚卸し | Teams bot、メッセージ拡張、タスクモジュール、SSO利用アプリを一覧化する |
| テナント範囲 | 検証テナント、限定ユーザー、本番テナントの順に展開できるか |
| 管理者同意 | GraphやTeams関連APIの権限が最小限か |
| アプリ登録 | Client ID、Tenant ID、証明書・シークレット、マネージドID設定を確認する |
| Teams管理センター | カスタムアプリのアップロード、アプリ許可ポリシー、セットアップポリシーを確認する |
| 監査 | AI teammateまたはbotの操作がどこに記録されるか確認する |
| ロールバック | 旧バージョンのbot、旧パッケージ、旧構成に戻せる手順を残す |
| 利用者通知 | 検証ユーザーに、プレビュー機能であることと問い合わせ先を伝える |
プレビュー機能を扱うときは、「動いたか」だけでなく「誰が承認し、どの範囲で、いつ戻せるか」まで決めてから展開することが重要です。
開発者が最初にやるべき移行調査
開発者は、すぐにパッケージを更新するより前に、既存コードの依存状況を調べるべきです。特にTeams SDK 2.0やBot Framework v4からの移行では、移行難易度がコード量ではなく依存パッケージと認証方式で決まることがあります。
まず確認するファイル
| ファイル・場所 | 確認内容 |
|---|---|
.csproj | Microsoft.Teams.*、Microsoft.Bot.*、Graph、Cards、AI関連パッケージ |
Program.cs / Startup.cs | Botアダプター、DI登録、エンドポイント、Middleware |
appsettings.json | MicrosoftAppId形式か、AzureAd形式か |
| CI/CD定義 | シークレット名、環境変数、デプロイスロット |
| Teamsアプリマニフェスト | bot ID、スコープ、権限、メッセージ拡張 |
| Azure App Service / Functions | マネージドID、アプリ設定、Key Vault参照 |
| ログ基盤 | ILogger出力、相関ID、エラー通知 |
調査時は、次のような検索をかけると影響範囲を見つけやすくなります。
context.Ref
OnSignIn
Microsoft.Teams.Api.Activities
Microsoft.Teams.AI
Microsoft.Teams.Cards
Microsoft.Teams.Extensions.Graph
Microsoft.Teams.Plugins
MicrosoftAppId
MicrosoftAppPassword
TeamsInfo検索で見つかった箇所を「そのまま動く」「using変更で済む」「設計変更が必要」の3段階に分けると、移行計画を立てやすくなります。
本番適用前に避けたい失敗パターン
今回の更新はドキュメント更新ですが、内容をもとにSDKや構成を変更する場合、いくつかの典型的な失敗があります。
| 失敗パターン | 起きる問題 | 対策 |
|---|---|---|
| プレビュー版を本番botに直接導入する | 予期しない仕様変更や制限に巻き込まれる | ステージングで検証し、対象ユーザーを限定する |
| パッケージだけ更新する | 認証設定や名前空間変更でビルド・実行が失敗する | .csproj、設定、起動コードをセットで見直す |
| Agent 365の権限を広く取りすぎる | 監査やデータ保護上の説明が難しくなる | 最小権限、限定展開、監査ログ確認を徹底する |
| Bot Framework互換レイヤーを過信する | Middleware、SSO、状態管理の細部で差分が出る | 実際のTeamsシナリオで回帰テストする |
| 旧構成キーを残す | 環境によって別の資格情報を読んでしまう | 設定キーを整理し、不要なシークレットを削除する |
| 削除パッケージの代替を後回しにする | Cards、Graph、AI、Testing周りで移行が止まる | 依存パッケージごとに担当者と期限を決める |
特に注意したいのは、Agent 365やAI teammateの検証を「開発チームだけ」で進めないことです。ID、権限、監査、情報保護に関わるため、Microsoft 365管理者、Entra ID管理者、セキュリティ担当者を早い段階で巻き込むべきです。
今回の更新をどう受け止めるべきか
Microsoft Teams documentation update: Start blog post for 2.1 previewは、単なるブログ記事の整理に見えるかもしれません。しかし実務上は、Teams SDK for .NET 2.1 Previewを起点に、Teams bot開発をASP.NET Core標準へ寄せる流れ、Agent 365とAI teammateを前提にしたID管理、Bot Framework v4やTeams SDK 2.0からの移行方針をまとめて確認できる重要な更新です。
今すぐ行うべきことは、次の3つです。
- 自社のTeams botやTeamsアプリが、Teams SDK 2.0、Bot Framework v4、削除予定・置き換え対象のパッケージに依存していないか確認する
- Agent 365やagentic identityを検証する場合は、権限、監査、展開範囲、ロールバックを管理者と開発者で共有する
- プレビュー版の採用は検証環境から始め、パッケージ更新、認証設定、Teamsアプリ設定、実運用シナリオをセットでテストする
今回の更新は、すぐに全アプリを移行すべきという合図ではありません。むしろ、今の実装を棚卸しし、将来のTeams SDK 2.1系やAgent 365対応に備えるためのチェックポイントと捉えるのが適切です。
コメント