Microsoft 365 Agents SDK documentationの更新を見て、「既存のボットやAIエージェントをすぐ改修すべきか」「Microsoft 365 Copilotのライセンスが必要なのか」と迷う担当者も多いでしょう。
結論から言えば、2026年7月7日付の公式情報だけを理由に、既存のMicrosoft 365 Agents SDK実装を一律で変更する必要はありません。7月7日付で更新された公式ページは、名称がよく似た「Microsoft Agent 365 SDK」の説明であり、Microsoft 365 Agents SDKを置き換えるものではないためです。Microsoft Agent 365 SDKは、既存エージェントへID、監査、通知、ガバナンスなどを追加する補完レイヤーとして位置付けられています。(マイクロソフトラーニング)
ただし、Azure Bot Frameworkから移行する場合、Python SDKを更新する場合、Microsoft 365 CopilotでOAuthを利用する場合は、互換性の確認や再テストが必要です。本記事では、2つのSDKの違い、既存実装への影響、導入条件、テストで見落としやすいポイントを実務目線で整理します。
Microsoft 365 Agents SDK documentationで最初に確認すべき結論
対応が必要かどうかは、ドキュメントが更新された日付ではなく、現在の実装がどのSDK、パッケージ、認証方式、チャネルに依存しているかで判断します。
| 現在の状況 | 対応要否 | 最初に実施すること |
|---|---|---|
| Microsoft 365 Agents SDKを利用していない | 原則不要 | 新規エージェント開発で必要かを評価する |
| 安定版パッケージを固定し、既存テストも通っている | 緊急対応は不要 | リリースノートと依存関係を定期確認する |
| Azure Bot Frameworkから移行予定 | 対応が必要 | 非対応機能と代替手段を洗い出す |
| Adaptive DialogsやBot Framework Composerを利用中 | 設計変更が必要 | 単純移植ではなく会話設計を見直す |
| Pythonの旧インポート形式を利用中 | SDK更新時に修正が必要 | microsoft.agentsの利用箇所を検索する |
| Microsoft 365 Copilot WebでOAuthを利用 | 再テストを推奨 | 実チャネルでサインインとトークン交換を確認する |
| エージェントの監査や組織統制を強化したい | 別途評価が必要 | Microsoft Agent 365 SDKの追加を検討する |
Microsoft 365 Agents SDKはAzure Bot Framework SDKの発展形ですが、Adaptive Dialogs、Composerの成果物、旧Bot Framework CLI、従来のストリーミング接続などは、そのまま移行できません。また、Pythonではインポート構造の変更が明示されています。(マイクロソフトラーニング)
Microsoft 365 Agents SDK documentationとは
Microsoft 365 Agents SDK documentationは、C#、JavaScript、Pythonで会話型エージェントを構築するための公式ドキュメントです。クイックスタート、サンプル、ローカルテスト、Azureへの展開、各言語のリファレンスがまとめられています。(マイクロソフトラーニング)
Microsoft 365 Agents SDKの主な役割は、ユーザーとエージェント本体の間に入る「通信・状態管理の基盤」です。
Teams／Microsoft 365 Copilot／Web／Slack
↓
Activity
↓
Microsoft 365 Agents SDK
↓
業務ロジック／LLM／オーケストレーター
↓
応答を返す各チャネルから届くメッセージは、共通形式であるActivityに正規化されます。その後、メッセージ、ユーザー参加、イベントなどの種類に応じてハンドラーへ振り分けられ、応答が元のチャネルへ返されます。SDKは認証、メッセージ形式の変換、チャネル接続、会話状態の管理を担当します。(マイクロソフトラーニング)
一方、Microsoft 365 Agents SDK自体は次のものではありません。
- AIモデル
- プロンプトや推論を管理するオーケストレーター
- ノーコードでエージェントを作るサービス
- 回答内容を自動的に決める仕組み
Azure AI Foundry、Semantic Kernel、OpenAI Agents、LangChain、独自ロジックなどを組み合わせ、SDKの外側で回答生成やツール実行を実装します。AIサービスを固定しない設計である点が、Microsoft 365 Agents SDKの特徴です。(マイクロソフトラーニング)
2026年7月7日更新の正体はMicrosoft Agent 365 SDK
名称が似ているため、次の2つを混同しないことが重要です。
指定されたMicrosoft 365 Agents SDKの概要ページは2026年4月29日、Azureへの展開ページは2026年5月14日が更新日です。一方、2026年7月7日付で更新されているのは「Microsoft Agent 365 SDK and CLI」および「Microsoft Agent 365 SDK Overview」です。(マイクロソフトラーニング)
| 比較項目 | Microsoft 365 Agents SDK | Microsoft Agent 365 SDK |
|---|---|---|
| 主な目的 | 会話型エージェントの構築、ホスト、チャネル接続 | 既存エージェントへの企業向け機能の追加 |
| エージェントの作成・ホスト | 対応する | 作成・ホストは行わない |
| 主な機能 | Activity処理、状態管理、ストレージ、認証、チャネル抽象化 | Agent Identity、通知、監査、OpenTelemetry、管理されたMicrosoft 365データ利用 |
| 対応する基盤 | C#、JavaScript、PythonのAgents SDK実装 | 任意のSDK、プラットフォーム、クラウド |
| 既存実装との関係 | エージェント本体の実装基盤 | 既存エージェントに追加する補完レイヤー |
| 導入判断 | マルチチャネル対応やBot Framework移行時 | 組織統制、監査、ID管理を強化するとき |
Microsoft Agent 365 SDKは、Microsoft Entraに基づくエージェントID、OpenTelemetryによる可観測性、Microsoft 365アプリからの通知、管理されたMCPサーバーへのアクセス、管理者承認済みのブループリントなどを提供します。ただし、エージェント本体を作成したり、ホストしたりするSDKではありません。公式にも、Microsoft 365 Agents SDKを置き換えず、ガバナンスやライフサイクル管理を上乗せする関係であることが明記されています。(マイクロソフトラーニング)
したがって、2026年7月7日の情報は、Microsoft 365 Agents SDKに破壊的変更が一斉適用されたという意味ではありません。既存エージェントに企業向けの管理機能を追加するかどうかを、別レイヤーとして検討する更新です。
Azure Bot Frameworkからの仕様差分
Microsoft 365 Agents SDKはAzure Bot Frameworkの考え方を受け継いでいます。Activity、ハンドラー、会話状態、チャネルといった基本概念は似ていますが、ソースコードやパッケージを変更せずに置き換えられるわけではありません。
| 既存の機能・構成 | Microsoft 365 Agents SDKでの扱い | 実務上の対応 |
|---|---|---|
BotFrameworkAdapter | 削除済み | CloudAdapterを前提に認証と処理経路を見直す |
| Adaptive Dialogs | 非対応 | 会話フローをハンドラーやLLMオーケストレーションで再設計する |
| Bot Framework Composer成果物 | 直接移行できない | Composer依存部分を分解して再実装する |
| 旧Application Insights統合 | モダンな可観測性へ移行 | ログ、メトリクス、トレースの設計をやり直す |
| ASP.NET WebAPI | 旧方式は非対応 | 現行のASP.NET Core Web APIへ移行する |
| Bot Framework CLI、Yeoman生成 | 非推奨・非対応 | Microsoft 365 Agents Toolkitを利用する |
| LUIS、Orchestrator、QnA Maker | 旧AIツールとして非継承 | LLM、RAG、現行サービスへ置き換える |
| 従来のStreaming Connections | 互換性なし | ストリーミング処理を新SDK向けに再設計する |
特にAdaptive DialogsやComposerを大規模に利用しているボットは、パッケージ名を変更するだけでは移行できません。既存のダイアログを「入力判定」「状態管理」「外部処理」「応答生成」に分解し、どこを通常コード、どこをLLM、どこをワークフローとして実装するかを決める必要があります。(マイクロソフトラーニング)
JavaScriptでは、旧パッケージとの主な対応関係も示されています。
| 旧パッケージ | 新しいパッケージ |
|---|---|
botframework-schema | @microsoft/agents-activity |
botbuilder | @microsoft/agents-hosting |
botbuilder-dialogs | @microsoft/agents-hosting-dialogs |
botbuilder-azureのBlob関連 | @microsoft/agents-hosting-storage-blob |
botbuilder-azureのCosmos DB関連 | @microsoft/agents-hosting-storage-cosmos |
パッケージの役割は近くても、初期化方法、依存性注入、認証設定、ルーティングAPIが異なる可能性があります。置換表を機械的な検索・置換に使うのではなく、移行対象を洗い出すために使うのが適切です。(GitHub)
言語別の導入条件と互換性
Microsoft 365 Agents SDK documentationを利用する際は、単一ページの必要バージョンだけを見て環境を決めないことが重要です。2026年7月19日時点では、概要ページ、クイックスタート、言語別リポジトリでランタイム要件の記載に差があります。
| 言語 | 公式情報に記載された条件 | 新規構築時の実務的な基準 | 主な互換性確認 |
|---|---|---|---|
| C#／.NET | .NET 8.0以上 | .NET 8以上と安定版NuGetを使用 | DI登録、認証、CloudAdapter、状態管理 |
| JavaScript／TypeScript | 概要はNode.js 18以上、リポジトリは20以上、クイックスタートは22以上 | Node.js 22以上を基準にCIでも固定 | CommonJS／ESM、OAuth、パッケージのengines |
| Python | 概要は3.9～3.11、リポジトリは3.10～3.14で3.11以上を推奨 | Python 3.11以上を基準に仮想環境を固定 | インポート名、依存パッケージ、非同期処理 |
公式概要ではNode.js 18以上、Python 3.9～3.11とされています。一方、JavaScriptの公式リポジトリではNode.js 20以上、JavaScriptクイックスタートではNode.js 22以上です。Pythonの公式リポジトリでは3.10～3.14をサポートし、3.11以上が推奨されています。(マイクロソフトラーニング)
このような記載差がある場合は、次の優先順位で判断すると安全です。
- 実際に導入するパッケージの依存条件
- 対象バージョンのリリースノート
- 言語別の公式リポジトリ
- 対象言語の最新クイックスタート
- SDK全体の概要ページ
CI/CDではランタイムを固定し、ローカル環境だけ新しいバージョンへ更新しないようにします。JavaScriptならpackage-lock.json、Pythonならロックファイルやrequirementsファイル、.NETなら中央パッケージ管理などを利用し、開発・検証・本番で同じ依存関係を再現できる状態にします。
Pythonではインポート名の変更に注意
Python版では、インポート構造が次のように変更されています。
# 旧形式
from microsoft.agents import ...
# 新形式
from microsoft_agents.activity import Activity
from microsoft_agents.hosting.core import TurnContext公式リポジトリでは、この変更が破壊的変更として明示されています。SDK更新後に起動時のModuleNotFoundErrorが発生する場合は、パッケージのインストールだけでなく、ソースコード内のmicrosoft.agentsをリポジトリ全体で検索してください。(GitHub)
ベータ版やNightly版を本番へ直接入れない
.NETのNightlyパッケージはバージョン末尾が-betaとなり、最新コードを早く試せる一方、安定性は保証されていません。JavaScriptの@nextも開発中の機能を含む可能性があります。(GitHub)
本番環境では安定版を明示的に固定し、ベータ版は検証ブランチや専用環境でのみ試す運用が安全です。
Microsoft 365 Agents SDKの導入条件
ローカル開発だけならMicrosoft 365 Copilot契約は必須ではない
Microsoft 365 Copilotは対応チャネルの一つです。SDKの利用開始やWeb、ローカル環境での開発だけであれば、Microsoft 365 Copilotのサブスクリプションは必須ではありません。Microsoft 365 Copilotを実際の公開先やテスト先として使用する場合は、そのチャネルに必要な契約や環境が必要です。(GitHub)
ローカル開発では、一般に次の環境を用意します。
- C#、JavaScript、Pythonのいずれかの対応ランタイム
- Visual StudioまたはVisual Studio Code
- 使用言語に対応するAgents SDKパッケージ
/api/messagesを受け付けるローカルWebアプリ- Microsoft 365 Agents Playground
- 認証テストを行う場合はMicrosoft Entra IDのアプリ登録
Microsoft 365 Agents Toolkitを使うと、プロジェクト生成、ローカルテスト、デプロイ設定、認証設定の一部を自動化できます。Agents Playgroundによる匿名のローカルシミュレーションでは、Microsoft 365開発者テナント、トンネリングサービス、アプリ登録を用意せずに基本動作を確認できます。(マイクロソフトラーニング)
Agents Playgroundの基本的な使い方
現在の専用テストページでは、Windows版のスタンドアロンツールまたはnpmパッケージを利用します。
winget install agentsplaygroundまたは、npmを利用します。
npm install -g @microsoft/m365agentsplaygroundエージェントが既定の3978番ポートで動いている場合は、次のように接続します。
agentsplayground -e "http://localhost:3978/api/messages" -c "emulator"匿名モードでは追加の認証設定は不要です。認証を含めてテストする場合は、Agents Playground側とエージェント側の両方にMicrosoft Entra IDのアプリ登録が必要です。(マイクロソフトラーニング)
TeamsやMicrosoft 365 Copilotへ公開する条件
公式の手動展開手順では、Agents SDKアプリをWebアプリとしてAzureへ配置し、Azure Botリソースのメッセージングエンドポイントへ接続します。
https://{公開先ホスト名}/api/messagesTeamsまたはMicrosoft 365 Copilotへ公開する場合は、主に次の作業が必要です。
- エージェントをAzure App Serviceまたはコンテナーへ展開する
- Azure Botリソースを作成して認証を構成する
- メッセージングエンドポイントを設定する
- Azure BotリソースにMicrosoft Teamsチャネルを追加する
- Teamsアプリマニフェストを作成する
- Microsoft 365管理センターの「統合アプリ」からカスタムアプリをアップロードする
- 組織のアプリ利用ポリシーや承認手順を確認する
TeamsやMicrosoft 365 Copilotで利用するマニフェストは、すべての機能に共通する一つのテンプレートではありません。タブ、メッセージ拡張、SSOなど、使用する機能に応じて必要項目が変わります。マニフェストもソースコードと同様にバージョン管理し、変更時には権限と公開範囲を再確認してください。(マイクロソフトラーニング)
テスト時に見落としやすい注意点
匿名テストが成功しても認証成功とは限らない
Agents Playgroundの匿名モードは、メッセージの受信、ルーティング、応答生成を早く確認する用途に適しています。しかし、次の処理は匿名テストだけでは保証できません。
- Microsoft Entra IDによるサインイン
- SSO
- OAuthトークン交換
- ユーザーごとの権限判定
- Microsoft GraphやMicrosoft 365データへのアクセス
- 管理者同意が必要なアクセス許可
最低でも、匿名モードと認証モードを分けてテストしてください。
チャネルごとにActivityの内容が異なる
Agents Playgroundでは、emulator、webchat、msteamsなどのチャネルIDを指定できます。公式ドキュメントでも、チャネルによってユーザー体験とActivityのプロパティが異なると説明されています。(マイクロソフトラーニング)
次のようなコードは、ローカルエミュレーターでは動いても、実チャネルで想定外の結果になることがあります。
channelIdを完全一致で判定しているchannelDataの存在を前提にしている- Teams固有のユーザーIDを他チャネルでも使っている
- 添付ファイルのURL形式を固定している
- メンション情報が必ず存在すると仮定している
共通ロジックとチャネル固有ロジックを分離し、実際に公開するチャネルごとにテストケースを用意することが重要です。
Microsoft 365 Copilot WebのOAuthは実チャネルで確認する
JavaScript SDKでは、Microsoft 365 Copilot Webが複合形式のchannelIdを送信するため、OAuthトークン交換時に基底チャネルを使用する修正が行われています。これは、一般的なエミュレーターテストだけでは見つけにくい問題です。(GitHub)
Microsoft 365 Copilot Webで認証を利用する場合は、次の一連の動作を実環境で確認してください。
- サインインカードが表示される
- ユーザーが認証を完了できる
- トークン交換が成功する
- 必要なスコープだけが付与される
- トークン失効後に再認証できる
- サインインをキャンセルしても会話を継続できる
クイックスタートとテスト専用ページのコマンドを混在させない
一部のクイックスタートには、旧パッケージ名である@microsoft/teams-app-test-toolとteamsapptesterコマンドが残っています。一方、専用のローカルテストページでは@microsoft/m365agentsplaygroundとagentsplaygroundが案内されています。(マイクロソフトラーニング)
手順を実行する際は、一つのページからコマンドを断片的にコピーするのではなく、次の情報をセットで記録してください。
- 参照したページの更新日
- SDKパッケージのバージョン
- Playgroundのパッケージ名とバージョン
- Node.jsやPythonなどのランタイム
- 実行したコマンド
- 使用したサンプルのコミットまたはタグ
MemoryStorageの成功を本番運用の根拠にしない
クイックスタートでは、会話状態の保存にMemoryStorageが使われています。これは動作確認には便利ですが、本番の永続化設計を代替するものではありません。クイックスタートの成功後は、Blob Storage、Cosmos DBなど、要件に合った永続ストレージへ切り替えてください。(マイクロソフトラーニング)
特に次のテストが必要です。
- アプリ再起動後も会話状態を復元できるか
- 複数インスタンスで状態が競合しないか
- 同一会話へ同時にメッセージが届いた場合に破損しないか
- ストレージ障害時に再試行やエラー通知が機能するか
- スキーマ変更後も既存データを読み込めるか
.NET SDKでは、ストリーミング時のAgentStateのスレッド安全性や、配列を含む状態データのシリアライズに関する修正も行われています。状態管理を使うアプリでは、正常系だけでなく同時実行と再起動を含む負荷テストが重要です。(GitHub)
シークレットをコマンド履歴やリポジトリへ残さない
公式手順では--client-secretをコマンドライン引数として渡す例も示されていますが、共有PCやCI/CDで直接指定すると、シェル履歴や実行ログに残る可能性があります。
ローカルではユーザー単位のシークレット管理、CI/CDではシークレットストアやワークロードIDを利用し、次の情報をGitへ登録しないようにします。
- クライアントシークレット
- テナント固有の認証情報
- 接続文字列
- ストレージキー
- APIキー
- 開発用の一時トークン
実施すべき最小テストセット
Microsoft 365 Agents SDKを更新または移行する場合は、少なくとも次のテストを実施します。
| テスト | 確認内容 |
|---|---|
| 起動テスト | 依存関係、設定値、DI登録、エンドポイント |
| メッセージテスト | 通常メッセージ、空文字、長文、特殊文字 |
| Activityテスト | メッセージ、参加、退出、イベント、インストール更新 |
| 状態管理テスト | 複数ターン、再起動、同時実行、期限切れ |
| 認証テスト | ログイン、キャンセル、失効、再認証、権限不足 |
| チャネルテスト | emulator、Web Chat、Teams、Microsoft 365 Copilot |
| 添付ファイルテスト | ファイル、画像、サイズ超過、不正形式 |
| 障害テスト | LLM停止、外部API遅延、ストレージ停止、タイムアウト |
| デプロイテスト | Azure Bot接続、マニフェスト、管理者承認、公開範囲 |
| ロールバックテスト | 旧バージョンへ安全に戻せるか |
LLMの回答品質だけを確認してテスト完了としないことがポイントです。Agents SDKが担当するのは、通信、認証、Activity処理、状態管理、チャネル接続であるため、これらを独立したテスト項目として扱う必要があります。
安全に導入・更新するための管理策
パッケージとランタイムの組み合わせを台帳化する
プロジェクトごとに、最低限次の情報を記録します。
| 管理項目 | 記録例 |
|---|---|
| SDK言語 | C#、JavaScript、Python |
| SDKパッケージ | Microsoft.Agents.*など |
| 固定バージョン | 本番で使用している正確なバージョン |
| ランタイム | .NET、Node.js、Pythonのバージョン |
| 公開チャネル | Teams、Microsoft 365 Copilot、Web |
| 認証方式 | シークレット、証明書、マネージドID |
| 状態保存先 | Memory、Blob、Cosmos DBなど |
| AI基盤 | Azure AI Foundry、Semantic Kernel、外部LLMなど |
| 最終テスト日 | チャネル別の実施日 |
| ロールバック先 | 直前の安定版 |
「SDKは最新版」とだけ記録すると、障害時に環境を再現できません。正確なバージョンと組み合わせを残してください。
更新を自動適用しない
Dependabotなどで更新候補を検出することは有効ですが、Agents SDKを本番へ自動マージする運用は避けた方が安全です。
特に次の変更を含む場合は、人による確認と実チャネルテストを必須にします。
- 認証やOAuth関連
- Activityモデルやシリアライズ
- 会話状態やストレージ
- チャネル固有処理
- マニフェスト
- ストリーミング
- プロアクティブメッセージ
- パッケージ名や名前空間
マニフェストと権限をコードレビュー対象にする
TeamsやMicrosoft 365 Copilotのマニフェスト変更は、単なる表示設定ではありません。エージェントの機能、公開範囲、ドメイン、SSO、権限に影響します。
ソースコードと同様にプルリクエストで差分を確認し、開発担当者だけでなくMicrosoft 365管理者やセキュリティ担当者も確認できるフローを作ります。
組織統制が必要ならMicrosoft Agent 365 SDKを別途評価する
次の要件がある場合は、Microsoft 365 Agents SDKの置き換えではなく、Microsoft Agent 365 SDKの追加を検討します。
- エージェントごとに一意の企業IDを付与したい
- LLM呼び出しやツール利用を監査したい
- Teams、Outlook、Wordなどから通知を受けたい
- Microsoft 365データへのアクセスを管理者の統制下に置きたい
- エージェントの作成、配布、廃止をライフサイクル管理したい
- 未承認エージェントの利用を抑止したい
Microsoft Agent 365 SDKは、任意のエージェント基盤へ企業向け機能を追加できます。Microsoft 365 Agents SDKで構築したエージェントにも追加できますが、ID、アクセス許可、ログの保存先、管理者承認などを含む別の導入設計が必要です。(マイクロソフトラーニング)
対応要否を判断するチェックリスト
まず、対象リポジトリ全体から次の文字列を検索してください。
botbuilder
Microsoft.Bot.Builder
BotFrameworkAdapter
AdaptiveDialog
microsoft.agents
@microsoft/teams-app-test-tool
teamsapptester検索結果を基に、対応を次の3段階へ分類します。
緊急対応は不要
次の条件をすべて満たす場合は、直ちに本番コードを変更する必要はありません。
- Microsoft 365 Agents SDKの安定版を固定している
- Azure Bot Frameworkの非対応機能を使用していない
- 現在のランタイムがパッケージ要件を満たしている
- 認証と実チャネルのテストが成功している
- 2026年7月7日のAgent 365 SDK機能を直ちに必要としていない
この場合は、依存関係の台帳化と定期的なリリースノート確認を行います。
計画的な更新と再テストが必要
次のいずれかに該当する場合は、検証環境でSDK更新を試します。
- Node.js、Python、.NETのバージョンが古い
- Quickstartをコピーしたままパッケージを固定していない
- Pythonで旧インポート名を使っている
- OAuthやSSOを利用している
- TeamsとMicrosoft 365 Copilotの両方へ公開している
- MemoryStorageから永続ストレージへ移行していない
- ベータ版やNightly版を利用している
再設計を伴う移行が必要
次の機能に強く依存している場合は、単純なSDK更新ではなく移行プロジェクトとして扱います。
- Adaptive Dialogs
- Bot Framework Composer
BotFrameworkAdapter- LUIS、QnA Maker、Orchestrator
- 旧Bot Framework CLI
- 従来方式のStreaming Connections
- 旧ASP.NET WebAPI
- 独自改変したBot Frameworkミドルウェア
最初に行うべきことは、本番パッケージの即時更新ではありません。現在のSDK、ランタイム、旧Bot Framework依存、公開チャネル、認証方式を一覧化することです。そのうえで、匿名ローカル、認証付きローカル、Teams、Microsoft 365 Copilotの順にテスト範囲を広げます。
2026年7月7日付のMicrosoft Agent 365 SDK情報は、既存のMicrosoft 365 Agents SDKを廃止・置換する更新ではありません。エージェント本体の互換性確認と、企業向けガバナンス機能の追加判断を分けて進めることが、不要な改修とテスト漏れを防ぐ最も確実な対応です。
コメント