Microsoft Agent 365 SDK and CLIは、既存のAIエージェントを作り直すための新しいフレームワークではありません。既存のエージェントに、Microsoft EntraベースのID、監査可能なオブザーバビリティ、Microsoft 365データへの統制されたアクセス、管理センターでのライフサイクル管理を追加するための仕組みです。
2026年7月9日に更新されたMicrosoftの開発開始ガイドでは、既存エージェントへの段階的な機能追加、AIコーディングエージェントを使ったセットアップ、通常のエージェントと「AI teammate」の違いが整理されました。結論として、既存実装の多くはそのまま利用できますが、IDモデル、権限、テレメトリ、テスト方法については対応要否の確認が必要です。(Microsoft Learn)
公式ドキュメントには旧版との行単位の変更履歴が掲載されていないため、この記事では2026年7月9日時点の現行仕様を、従来のMicrosoft 365エージェント実装と比較して解説します。
Microsoft Agent 365 SDK and CLIで何が変わるのか
今回の情報で押さえるべきポイントは、エージェントの推論処理そのものではなく、企業内で安全に登録・監視・認可・廃止するための制御層が明確になったことです。
| 比較項目 | 従来の一般的な実装 | Microsoft Agent 365での考え方 | 実務への影響 |
|---|---|---|---|
| エージェント本体 | 利用するSDKや基盤ごとに構築 | 既存のSDKやフレームワークを継続利用 | 全面再構築は原則不要 |
| ID | Entraアプリ、サービスプリンシパル、ユーザー委任 | Agent Identity BlueprintとMicrosoft Entra Agent IDを推奨 | 権限設計と監査単位を見直す |
| 監視 | 独自ログ、Application Insights、個別のOpenTelemetry構成 | Agent 365向けの統一オブザーバビリティ | 推論、ツール実行、入出力を追跡可能 |
| Microsoft 365連携 | Microsoft Graphや独自コネクタを個別実装 | Work IQのMCPツールを管理者統制下で利用 | 同意、監査、取り消しを一元管理 |
| セットアップ | ポータル操作やスクリプトを個別に作成 | Agent 365 CLIとAI-guided setupで自動化 | 設定漏れを減らせるが変更レビューが必要 |
| 配置先 | Azure、AWS、GCP、オンプレミスなど | 既存の配置先を維持可能 | Agent 365導入のための移設は必須ではない |
| 公開・廃止 | チームごとの手順で管理 | CLIと管理センターでライフサイクルを管理 | 開発者と管理者の役割分離が必要 |
Agent 365はMicrosoft Agent Framework、Microsoft 365 Agents SDK、OpenAI Agents SDK、LangChain、Copilot Studio、Azure AI Foundryなどと併用できます。Azure以外で稼働するエージェントも対象にでき、Agent 365の採用は既存ランタイムの置き換えを意味しません。(Microsoft Learn)
Microsoft Agent 365 SDKと既存のAgents SDKは別物
名称が似ているため、最初に役割を切り分ける必要があります。
| 製品・要素 | 主な役割 |
|---|---|
| Microsoft Agent 365 SDK | ID、オブザーバビリティ、通知、Work IQツール、ガバナンスを追加する |
| Microsoft 365 Agents SDK | エージェントのホスティング、Activityプロトコル、メッセージ処理などを担う |
| Microsoft Agent Frameworkなど | モデル呼び出し、推論、ツール選択、ワークフローを実装する |
| Agent 365 CLI | Blueprint、権限、Azureリソース、公開、MCP設定などを操作する |
| Microsoft 365管理センター | エージェントやMCPサーバーを承認、監視、停止、廃止する |
Microsoftは、Agent 365 SDKがMicrosoft 365 Agents SDKを置き換えるものではなく、その上にガバナンスやコンプライアンスの機能を重ねるものだと説明しています。既存のAgents SDKプロジェクトでは、メッセージ処理や業務ロジックを維持しながら、必要なAgent 365パッケージだけを追加する構成が基本です。(Microsoft Learn)
導入は4段階に分けて判断する
Microsoft Agent 365は、すべての機能を一度に導入する必要はありません。公式ガイドでは、次の4段階に分けて機能を追加する考え方が示されています。
| 段階 | 追加されるもの | 適しているケース | 主な注意点 |
|---|---|---|---|
| Register | 管理センターへの登録と棚卸し | 既存エージェントをIT部門から見える状態にしたい | 既存のMicrosoft 365 custom engine agentは追加登録が不要な場合がある |
| Observability | OpenTelemetryベースの監視 | 推論、ツール呼び出し、例外を監査したい | 権限、ライセンス、Agent IDの設定が必要 |
| Work IQ | Mail、Calendar、SharePoint、Teamsなどのツール | Microsoft 365のデータや操作を利用したい | 管理者同意が必要。コードへの組み込みも必要 |
| AI teammate | 専用メールボックス、Teamsプレゼンス、ディレクトリ登録 | 人とは別の主体としてエージェントを運用したい | Frontierプレビュー対象。権限モデルが大きく変わる |
AI-guided setupはRegister、Observability、AI teammateの準備を支援します。一方、Work IQのツール呼び出しは、現時点ではAgent 365 SDKのTooling APIを利用して開発者が実装する必要があります。(Microsoft Learn)
既存エージェントはObservabilityから始めやすい
すでに業務で稼働しているエージェントに対し、いきなり専用IDやメールボックスを与えると、アクセス権の再設計が必要になります。
最初の導入候補としては、次の順序が現実的です。
- 管理センターへの登録と棚卸し
- オブザーバビリティの追加
- 必要なWork IQツールだけを許可
- 専用IDが本当に必要な場合だけAI teammate化
特に、既存エージェントの動作を変えずに監査性を高めたい場合は、Observabilityまでの導入を独立したパイロットとして進めると、影響範囲を限定できます。
Agent 365 CLIの仕様で注意すべき変更点
Agent 365 CLIは、a365コマンドで操作します。単なるデプロイツールではなく、Blueprint、権限、Agent Identity、MCP、公開、診断を扱う管理ツールです。
標準のsetupは通常のBlueprintエージェントを作成する
現在のa365 setup allは、標準ではAI teammateではなく、Blueprintベースの通常エージェントをセットアップします。AI teammateのフローを利用する場合は、明示的に--aiteammateを指定します。
# 通常のBlueprintエージェント
a365 setup all
# AI teammate
a365 setup all --aiteammate通常エージェントでは、OBO、S2S、または両方の認証方式を選択できます。AI teammateでは専用ユーザーIDを使ったOBO方式が前提となり、--authmodeは利用できません。(Microsoft Learn)
config-freeセットアップは完全なプロジェクト更新ではない
--agent-nameを使うと、a365.config.jsonを用意せずにセットアップできます。
a365 setup all --agent-name "ProcurementAgent" --dry-run
a365 setup all --agent-name "ProcurementAgent"ただし、この方法では外部ホスティングが前提となり、Azureインフラストラクチャの作成と、プロジェクト内の.envやappsettings.jsonへの設定同期がスキップされます。
「設定ファイルなしで簡単に導入できる」と考えるのではなく、Blueprintだけを準備するフローなのか、アプリケーション設定まで自動反映するフローなのかを先に決める必要があります。(Microsoft Learn)
MCPの承認はCLIから管理センターへ移った
develop-mcp approve、develop-mcp block、develop-mcp package-mcp-serverはAgent 365 CLIから削除されています。
MCPサーバーの承認やブロックは、テナント管理者がMicrosoftの管理センターで実施します。開発者がCLIだけで登録から承認まで完結させる運用はできません。(Microsoft Learn)
これは単なるコマンド変更ではなく、次のような責任分界の変更です。
- 開発者はMCPサーバーを開発・登録する
- 管理者は利用可否と権限を審査する
- セキュリティ担当者は利用状況やテレメトリを監視する
既存の自動化スクリプトで削除済みコマンドを使用している場合は、管理センターでの承認手順を含む運用へ変更が必要です。
既存実装との互換性
エージェント本体は原則として継続利用できる
Microsoft 365 Agents SDK、Microsoft Agent Framework、OpenAI Agents SDK、LangChainなどで構築したエージェントは、そのままAgent 365の対象にできます。すでにMicrosoft Entraアプリとして登録しているエージェントも引き続き利用できます。
ただし、Work IQやAI teammateなど、Blueprintを前提とする機能を利用する場合は、既存のアプリ登録とは別にAgent Identity Blueprintの作成が必要になる場合があります。(Microsoft Learn)
AWSやGCPで動くエージェントをAzureへ移す必要はない
Agent 365はエージェントの実行場所を限定していません。AWS、GCP、その他のエンドポイントで稼働するコードも、Microsoft 365側のID、管理、監視機能と連携できます。
Agent 365 CLIにはAzure App Serviceへのデプロイ機能がありますが、既存の外部ホスティングを継続する場合、Azureへのデプロイは省略できます。(Microsoft Learn)
JavaなどSDK未対応言語はObservabilityだけ直接連携できる
公式のSDKパッケージは、Python、JavaScript／Node.js、.NETを中心に提供されています。
Javaなど、Agent 365 SDKが直接対応していない言語でも、既存のOpenTelemetryパイプラインからOTLP over HTTPでテレメトリを送信できます。ただし、これは主にObservabilityの代替経路です。Work IQや通知など、SDK固有機能の利用可否は別途確認する必要があります。(Microsoft Learn)
既存のObservability SDKは直ちに動かなくなるわけではない
新規実装では、Agent 365、Microsoft Foundry、Azure Monitorなどで共通利用できるMicrosoft OpenTelemetry Distroが推奨されています。
既存のAgent 365 Observability SDK方式は、互換性を維持したまま継続利用できます。ただし、新規開発ではMicrosoft OpenTelemetry Distroを採用し、既存実装は言語別の移行ガイドを確認するのが安全です。(Microsoft Learn)
Observabilityパッケージ更新時には追加権限が必要
次のバージョン以降へ更新する既存エージェントでは、Agent365.Observability.OtelWrite権限の追加が必要です。
| プラットフォーム | 追加権限が必要となる最低バージョン |
|---|---|
| .NET | 0.3-beta |
| Node.js | 0.2.0-preview.1 |
| Python | 0.3.0 |
権限を追加せずに更新すると、テレメトリ送信がHTTP 403で失敗します。新規セットアップでは必要な権限が構成されますが、既存エージェントのアップグレードでは明示的な確認が必要です。(Microsoft Learn)
AI teammate化は単純な互換アップグレードではない
AI teammateは、呼び出したユーザーの権限で動くエージェントとは異なり、Microsoft 365内に専用のユーザーIDを持ちます。メールボックス、Teamsプレゼンス、ディレクトリエントリ、管理者によるライフサイクル管理などを利用できます。
この変更によって、エージェントがアクセスできる情報の基準も変わります。
| 認証モデル | アクセス範囲 |
|---|---|
| ユーザー委任・OBO | サインインしたユーザーがアクセスできる範囲 |
| アプリケーション権限・S2S | サービスプリンシパルに付与した範囲 |
| AI teammate | エージェント自身のユーザーIDに付与した範囲 |
AI teammateは、呼び出し元ユーザーのアクセス権を自動的に継承しません。既存実装がユーザー委任を前提としている場合は、SharePoint、Teams、メール、カレンダーなどへのアクセスをエージェント専用ID向けに再設計する必要があります。(Microsoft Learn)
また、AI teammateはFrontierプレビュー参加テナント向けです。プレビュー機能は提供内容が変わる可能性があり、Frontierには固有のサービスレベル契約がありません。本番の基幹業務へ採用する場合は、停止時の代替経路や機能変更への追従方針を用意しておくべきです。(Microsoft Learn)
導入に必要な環境と権限
開発環境の主な条件
| 項目 | 条件 |
|---|---|
| Agent 365 CLI | .NET 8.0以降 |
| 対応OS | Windows、Linux、macOS |
| Pythonサンプル・テスト | Python 3.11以降 |
| Node.jsサンプル・テスト | Node.js 18以降 |
| .NETサンプル・テスト | .NET 8.0 SDK |
| ローカルテスト | Agents Playground |
| Azure操作 | Azure CLIと対象サブスクリプション |
| LLM | OpenAIまたはAzure OpenAIなど、対象エージェントが利用するモデル環境 |
CLIは次のコマンドでインストールできます。
dotnet tool install --global Microsoft.Agents.A365.DevTools.Cli
a365 -h--globalという名称ですが、.NETグローバルツールはインストールしたユーザー単位で利用されます。共有端末やCIランナーでは、実行ユーザーごとにインストール状況とPATHを確認してください。(Microsoft Learn)
セットアップに必要なロール
Azureリソースを含むCLIセットアップでは、最低限としてAzure ContributorとAgent ID Developerが必要です。OAuth2権限への管理者同意まで一度に完了するにはGlobal Administratorが必要です。
Agent ID Developerで実行した場合、CLIは実行可能な処理を完了したうえで、Global Administratorが行うべき同意手順を出力します。開発者へGlobal Administratorを常時付与する必要はありません。(Microsoft Learn)
CLI用アプリ登録はDelegated権限を使用する
Agent 365 CLI用のカスタムクライアントアプリは、ユーザーが対話的にサインインし、そのユーザーとして操作する設計です。そのため、CLI用アプリ登録ではDelegated permissionsを使用します。
バックグラウンドで動作するエージェント本体のS2S認証と混同し、CLI用アプリへApplication permissionsだけを設定すると、認証エラーや権限不足が発生します。(Microsoft Learn)
Observabilityはライセンスの「割り当て」まで確認する
Agent 365のテレメトリ取り込みでは、対象テナント内の少なくとも1人へMicrosoft 365 E7またはMicrosoft Agent 365ライセンスが割り当てられている必要があります。
ライセンスSKUがテナントに存在するだけでは不十分です。ユーザーへ割り当てられていない場合、リクエストが成功したように見えてもテレメトリが記録されないケースがあります。(Microsoft Learn)
導入前に対応要否を判断する基準
| 現在の状況 | 推奨対応 |
|---|---|
| 既存エージェントを管理部門が把握できていない | RegisterとObservabilityを優先 |
| 監査ログが独自形式で追跡しにくい | Microsoft OpenTelemetry Distroを小規模導入 |
| Microsoft 365データを独自Graph処理で操作している | Work IQへの置き換え可否を評価 |
| エージェントに専用メールアドレスが必要 | AI teammateを別プロジェクトとして検証 |
| AWSやGCPで安定稼働している | ホスティングは維持し、管理機能だけ追加 |
| Javaなど未対応言語で実装している | Observabilityは直接OTLP連携を検討 |
| Observabilityパッケージを更新予定 | OtelWrite権限を先に確認 |
| CLIでMCP承認まで自動化している | 管理センター承認を含む運用へ変更 |
既存エージェントに対する緊急の全面移行は必要ありません。一方、Observabilityパッケージの更新や、削除されたCLIコマンドを使う自動化については、先に修正しないと運用障害につながる可能性があります。
安全に導入する手順
現行構成を棚卸しする
最初に、次の項目を一覧化します。
- エージェントのフレームワークとホスティング先
- Microsoft Entraのアプリ登録とサービスプリンシパル
- OBO、S2S、両方のどれを利用しているか
- Microsoft GraphとMCPの権限
- 現在のOpenTelemetry構成
- TeamsやCopilotへの公開状況
- 本番、検証、開発環境のテナントID
特に、Blueprint ID、Agent IdentityのクライアントID、既存アプリのクライアントIDを混在させないようにします。
導入する段階を決める
最初からAI teammateを選ぶのではなく、業務要件に必要な段階までに限定します。
監査が目的ならObservabilityまで、Microsoft 365操作が必要ならWork IQまで、専用メールボックスや組織図への登録が必要な場合のみAI teammateまで進めます。
CLIのバージョンと前提条件を確認する
dotnet --version
az --version
az account show
a365 --version
a365 setup requirementsa365 setup requirementsは前提条件を確認し、不足項目の修復方法を表示します。Global Administratorで実行し、CLI用アプリが存在しない場合は、アプリ作成と管理者同意を行うプロンプトが表示されることがあります。単なる読み取りチェックだと思わず、表示内容を確認してから承認してください。(Microsoft Learn)
dry-runで作成・変更対象を確認する
a365 setup all --agent-name "MyAgent" --dry-run確認する項目は、Blueprint名、Agent Identity名、テナントID、要求される権限、対象リソース、メッセージングエンドポイントです。
本番テナントへ直接適用せず、開発用テナントまたは検証用エージェントで差分を記録します。
自動生成されたコードをレビューする
AI-guided setupでは、AIコーディングエージェントがObservability関連のコードをプロジェクトへ直接書き込みます。Microsoftも、本番へ展開する前に変更内容をレビューするよう明記しています。(Microsoft Learn)
最低限、次の点を確認します。
- 既存のOpenTelemetry Providerが二重登録されていないか
- エクスポーターが複数回初期化されていないか
- 開発用トークンやシークレットがコードへ埋め込まれていないか
- 入出力やツール引数に機密情報が含まれる場合の収集方針
- 例外発生時に業務処理まで停止しないか
- パッケージのバージョンがロックされているか
ローカルとMicrosoft 365上の両方でテストする
Agents Playgroundで成功しても、Teams、Word、Outlookでの配信や権限まで保証されるわけではありません。
ローカルではメッセージ処理、MCPツール、通知、テレメトリを確認し、公開後はDeveloper Portal、管理センター、Teams上のエージェントインスタンスを含むエンドツーエンドテストを実施します。(Microsoft Learn)
テスト時に特に注意したいポイント
| 確認項目 | 注意点 | 対応 |
|---|---|---|
| Bearer token | ローカル開発専用。約1時間で期限切れになる | 本番ではAgentic認証またはOBOを使用 |
| MCP接続先 | MCP_PLATFORM_ENDPOINT未指定時は本番エンドポイントが使われる | 検証環境では明示的にtest／preprodを指定 |
| Blueprint IDとAgent ID | 間違ったIDでテレメトリを送ると403になる | エクスポートURLとトークンの主体を照合 |
| Observability権限 | パッケージ更新後にOtelWriteが不足すると403になる | BlueprintとManaged Identityの権限を確認 |
| Developer Portal | 未設定だとTeamsからメッセージが届かない | 公開後にBlueprintとの関連付けを確認 |
| AI生成コード | 構成の重複や誤った変数名が入り得る | コードレビューと差分テストを必須化 |
| .NETの再試行 | PythonとJavaScriptとは再試行動作が異なる | 429や5xxに対する再試行をアプリ側で設計 |
| config-free setup | プロジェクト設定が自動同期されない | 必要な値を.envやappsettings.jsonへ反映 |
Bearer tokenはローカル開発だけで使用し、本番環境のBEARER_TOKENやBEARER_TOKEN_<SERVER_NAME>には設定しないよう公式ガイドで明記されています。また、MCPエンドポイントを省略すると本番環境へ接続するため、テストデータであっても誤操作につながる可能性があります。(Microsoft Learn)
Observabilityでは、PythonとJavaScriptのSDKがHTTP 408、429、5xxに対して最大3回の自動再試行を行う一方、.NET SDKは自動再試行しません。負荷試験や一時障害試験では、言語ごとの挙動差を考慮してください。(Microsoft Learn)
よくある失敗と対処法
Agent 365 SDKへ移行すれば既存SDKを削除できると思う
Agent 365 SDKはエージェント本体のフレームワークではありません。既存のAgents SDKやAgent Frameworkを削除すると、メッセージ処理やモデル連携が動かなくなる可能性があります。
既存ランタイムは維持し、必要なAgent 365パッケージを追加してください。
CLI用アプリへApplication権限だけを追加する
Agent 365 CLIは対話的にサインインしたユーザーとして操作するため、Delegated permissionsが必要です。エージェント本体のS2S認証とは別に設計します。
AI teammate化してもユーザー委任と同じ範囲へアクセスできると思う
AI teammateはエージェント自身のIDで動作します。利用者が閲覧できるSharePointサイトであっても、エージェントIDに権限がなければアクセスできません。
移行前に、現在のユーザー委任権限と、AI teammateへ付与する権限を比較してください。
ローカルテスト用トークンを本番へ残す
Bearer tokenは短時間で失効し、本番向けの認証方式ではありません。さらに、.envやlaunchSettings.jsonを誤ってリポジトリへ登録すると、資格情報漏えいにつながります。
本番ではManaged Identity、Agentic認証、OBOなど、設計した認証方式へ切り替えます。
Observabilityが200応答なので記録できたと思う
ライセンス未割り当てなどの条件では、HTTP 200が返ってもデータが取り込まれない場合があります。
レスポンスコードだけで判断せず、Microsoft Defenderや管理センターで実際にトレースが確認できるところまでを受け入れ条件にします。
Agents Playgroundで動いたため公開テストを省略する
ローカルテストでは、Developer Portalの設定、管理センターでの公開、Teams上のインスタンス作成、メッセージングエンドポイントの到達性までは確認できません。
ローカルテストとMicrosoft 365上のテストを別工程として管理してください。
管理者が実施すべき管理策
開発者と管理者の権限を分ける
開発者はAgent ID Developerと必要なAzure権限を使い、管理者同意だけをGlobal Administratorへ引き渡す構成が適切です。
Global Administratorのアカウントで日常的な開発やCLI操作を行う運用は避けます。
Blueprintの権限を定期的に確認する
Blueprintは、将来作成されるエージェントインスタンスが継承する権限の基礎です。検証目的で広い権限を付けたまま本番へ移行すると、すべてのインスタンスへ過剰な権限が引き継がれる可能性があります。
query-entra系コマンドを使い、Blueprintとインスタンスのスコープ、同意状況、継承設定を確認できます。(Microsoft Learn)
MCPサーバーを許可リスト方式で管理する
開発者が登録したMCPサーバーを自動承認せず、次の項目を管理センターで審査します。
- 提供者と運用責任者
- 認証方式
- 利用するAPIと権限
- 外部送信されるデータ
- ツール入力の検証
- 監査ログ
- 障害時の停止手段
CLIとSDKのバージョンを固定する
開発端末ごとにCLIを自動更新すると、コマンドや生成設定の差によって再現性が失われます。
CI/CDではCLIとSDKのバージョンを記録し、更新時には次の項目を確認します。
- 削除または追加されたコマンド
- 必要なEntra権限
- 生成される設定ファイルの差分
- Observabilityの属性と送信先
- ロールバック方法
- 管理センター側の操作変更
まず実施すべき対応
Microsoft Agent 365 SDK and CLIへの対応では、既存エージェントを直ちに作り直す必要はありません。最初に現在の認証方式、Entraアプリ、テレメトリ、Microsoft 365へのアクセス方法を棚卸しし、必要な段階だけを選択します。
既存エージェントを安全に拡張する場合は、次の順序が現実的です。
- 開発用テナントで
a365 setup requirementsを実行する --dry-runで作成されるIDと権限を確認する- RegisterとObservabilityだけをパイロット導入する
- ローカルとTeamsの両方で動作を検証する
- Work IQは必要なツールだけを許可する
- AI teammateは別のID・権限設計として評価する
- MCP承認と管理者同意を運用手順へ組み込む
特に優先して確認すべきなのは、Observability更新時のAgent365.Observability.OtelWrite権限、削除されたMCP承認コマンド、Bearer tokenの本番混入、AI teammate化に伴うアクセス権の再設計です。この4点を先に確認すれば、既存環境への影響を抑えながらAgent 365の管理機能を導入できます。
コメント