Declarative Agentsの重要なポイントは、AIエージェントの設定をコードに直接書き込むのではなく、YAMLやJSONなどの宣言的なファイルで管理できるようにすることです。開発者にとっては、エージェントの振る舞いをレビュー・共有・差し替えしやすくなる一方、管理者にとっては「誰が作ったエージェントが、どのデータやツールにアクセスするのか」を確認する重要性が高まります。
2026年5月23日時点のMicrosoft公式情報を踏まえると、Declarative Agentsは単なる新機能ではなく、Microsoft Agent FrameworkやMicrosoft 365 Copilot周辺で、AIエージェントを「作る」「管理する」「展開する」方法を整理し直す動きと見るべきです。特に確認すべきなのは、マニフェストやYAML/JSONの定義、利用するパッケージ、認証方式、ナレッジソース、管理センターでの公開範囲です。
Declarative Agentsとは何ができる仕組みなのか
Declarative Agentsは、エージェントの目的、指示、モデル設定、出力形式などを、プログラムコードではなく設定ファイルとして定義する考え方です。Microsoft Agent Frameworkの公式ドキュメントでは、YAMLまたはJSONファイルを使ってエージェント構成を定義でき、コードで直接実装するよりも定義・変更・チーム共有がしやすくなると説明されています。(Microsoft Learn)
たとえば、従来はC#やPythonのコード内に「どのモデルを使うか」「どのように答えるか」「出力形式をどうするか」といった情報が散らばりがちでした。Declarative Agentsでは、これらを設定ファイルに寄せられるため、開発者以外のレビュー担当者も差分を確認しやすくなります。
コード中心から設定中心に変わる
Declarative Agentsで変わるのは、AIエージェントの作り方そのものです。ロジックをすべてコードで抱え込むのではなく、以下のような要素を宣言的に分離できます。
| 項目 | 従来ありがちな状態 | Declarative Agentsでの考え方 |
|---|---|---|
| エージェントの目的 | コード内のプロンプトに埋め込む | YAML/JSONのinstructionsなどで管理 |
| モデル設定 | 実装ごとに個別指定 | 設定ファイルとしてレビュー可能にする |
| 出力形式 | コード側で都度整形 | outputSchemaなどで期待する形式を定義 |
| 変更管理 | コード変更として扱う | 設定ファイルの差分として確認しやすい |
| チーム共有 | 実装者に依存しやすい | エージェント定義を共有・再利用しやすい |
実務では、問い合わせ対応エージェント、社内ナレッジ検索エージェント、レビュー補助エージェントなど、目的ごとに設定を分けて管理する使い方が向いています。
Microsoft Agent FrameworkでのDeclarative Agentsの主な変更点
Microsoft Agent FrameworkのDeclarative Agentsでは、C#とPythonの両方で宣言的なエージェント定義を扱えるように整理されています。C#ではMicrosoft.Agents.AI.Declarative NuGetパッケージを追加し、利用するチャットクライアントのプロバイダー用パッケージもあわせて導入します。公式例ではAzure.AI.OpenAIやAzure.Identityが示されています。(Microsoft Learn)
C#で最初に確認するコマンドは次の通りです。
dotnet add package Microsoft.Agents.AI.Declarative --prerelease
dotnet add package Azure.AI.OpenAI
dotnet add package Azure.IdentityPythonでは、agent-framework-declarativeをプロバイダーパッケージと一緒に導入します。公式例では、Microsoft FoundryやAzure AI Foundry向けのパッケージと組み合わせる形が示されています。(Microsoft Learn)
pip install agent-framework-declarative agent-framework-foundry --preここで注意したいのは、公式例で--prereleaseや--preが使われている点です。本番利用を検討する場合は、パッケージのバージョン、サポート状況、既存アプリとの互換性を必ず検証環境で確認してください。
Microsoft 365 CopilotのDeclarative agentsとの違い
Declarative Agentsという言葉は、Microsoft Agent Frameworkだけでなく、Microsoft 365 Copilotの拡張でも使われます。混同しやすいですが、実務上は次のように分けて考えると整理しやすくなります。
| 観点 | Microsoft Agent Framework | Microsoft 365 CopilotのDeclarative agents |
|---|---|---|
| 主な対象 | .NETやPythonでAIエージェントアプリを開発する開発者 | Microsoft 365 Copilotを業務向けに拡張したい組織 |
| 定義方法 | YAML/JSONなどでエージェント構成を定義 | マニフェストで指示、ナレッジ、アクションを定義 |
| 実行場所 | 独自アプリ、バックエンド、ワークフローなど | Microsoft 365 CopilotやMicrosoft 365アプリ内 |
| 管理観点 | 認証、モデル、実行基盤、監視 | テナント内公開、権限、データアクセス、管理センター |
| 向いている用途 | 自社アプリへのAI組み込み、複雑なワークフロー | 社内ユーザー向けCopilot拡張、業務ナレッジ活用 |
Microsoft 365 CopilotのDeclarative agentsは、Microsoft 365 Copilotを業務シナリオに合わせてカスタマイズする仕組みで、指示、アクション、ナレッジを指定してCopilotの体験を調整します。Microsoft公式情報では、これらのエージェントはMicrosoft 365 Copilotと同じオーケストレーター、基盤モデル、信頼されたAIサービス上で動作すると説明されています。(Microsoft Learn)
そのため、社内向けに展開する場合は「開発できるか」だけでなく、「Microsoft 365管理センターで管理できる状態にするか」まで含めて設計する必要があります。
2026年5月時点で押さえたいMicrosoft 365 Copilot側の更新
Microsoft 365 Copilot向けのDeclarative agent manifestでは、バージョン1.7が公開されています。変更点として、事前定義したQ&Aを意味的に近い質問に使えるeditorial_answers、応答モードを制御するdefault_response_mode、会話スターターの依存機能を指定するdepends_onが追加されています。(Microsoft Learn)
editorial_answersはFAQ型エージェントに効く
editorial_answersは、あらかじめ定義した質問と回答のペアを使って、意味的に近いユーザー質問へ回答するためのオプションです。社内規程、手続き、製品サポートの定型FAQなど、回答を安定させたい領域で有効です。(Microsoft Learn)
ただし、使いどころを誤ると、更新されていない古い回答を返すリスクがあります。給与規程、契約条件、セキュリティポリシーなど変更頻度が高い情報では、回答の更新責任者とレビュー周期を決めてから使うべきです。
default_response_modeは速度と推論深度の設計ポイント
default_response_modeでは、エージェントの既定応答モードをAuto、Quick response、Think deeperから選べます。Quick responseは低遅延を重視する用途、Think deeperは複雑な問題解決や分析に向く一方で、応答までの時間が長くなる可能性があります。(Microsoft Learn)
実務では、次のように選ぶと失敗しにくくなります。
| 用途 | 推奨しやすいモード | 理由 |
|---|---|---|
| 社内FAQ、手順確認 | Quick responseまたはAuto | 回答の速さが重要で、深い推論が不要なケースが多い |
| 契約レビュー補助、障害原因分析 | Think deeperまたはAuto | 複数条件を踏まえた推論が必要になりやすい |
| 汎用アシスタント | Auto | ユーザー質問の幅が広く、固定しすぎると使いにくい |
なお、公式ドキュメントでは、メインのCopilot体験から@mentionで呼び出した場合に既定応答モードが適用されない既知の問題も示されています。展開前のテストでは、呼び出し方法ごとに動作を確認してください。(Microsoft Learn)
depends_onは表示してよい会話スターターを制御する
depends_onは、会話スターターを表示する条件として、必要な機能を指定するための項目です。たとえばWeb検索やメール参照が有効な場合だけ特定の会話スターターを表示する、といった制御に使えます。(Microsoft Learn)
これは地味ですが、利用者体験に大きく影響します。利用できない機能を前提にしたプロンプト例が表示されると、ユーザーは「使えないエージェント」と判断しがちです。会話スターターは単なる例文ではなく、利用可能な機能と連動させて管理する項目だと考えてください。
管理者が確認すべき影響範囲
Declarative Agentsの導入で、管理者が見るべき範囲は「アプリの公開可否」だけではありません。Microsoft 365管理センターでは、組織内で利用できるエージェントをAgent Registryで確認し、監視・管理・ガバナンスに使えると説明されています。(Microsoft Learn)
Agent Registryで棚卸しする
まず確認すべきなのは、テナント内にどのエージェントが存在するかです。Agent Registryでは、組織内で利用可能なエージェントを一覧化し、所有者がいないエージェントや管理されていないエージェントなどの情報を確認できます。(Microsoft Learn)
管理者は、少なくとも次の観点で棚卸しを行うべきです。
| 確認項目 | 見る理由 |
|---|---|
| 所有者 | 退職者や異動者が作成したエージェントが放置されるのを防ぐ |
| 公開範囲 | 全社公開すべきでないエージェントの拡散を防ぐ |
| データアクセス | SharePoint、OneDrive、メール、カレンダーなどへのアクセス範囲を把握する |
| 外部連携 | APIや外部サービスへのアクション実行リスクを確認する |
| 利用状況 | 使われていないエージェントを整理し、運用負荷を減らす |
Install、Block、Uninstall、Pinの使い分け
Microsoft 365管理センターのエージェント詳細では、エージェントに対してInstall、Uninstall、Block、Update in store、Pin for usersなどの操作が用意されています。Blockはユーザーがインストール・利用できないようにし、すでにインストール済みのユーザーからも削除される動作として説明されています。(Microsoft Learn)
実務では、次のように使い分けるとよいでしょう。
| 操作 | 使う場面 |
|---|---|
| Install | 特定ユーザーや部門に正式展開する |
| Block | セキュリティ・コンプライアンス上の懸念がある |
| Uninstall | 利用を停止し、組織内から外す |
| Update in store | 承認済みエージェントを新しいZIPパッケージで更新する |
| Pin for users | 重要なエージェントをユーザー画面で見つけやすくする |
管理者がピン留めできるエージェントは、全ユーザー、特定グループ、特定ユーザーを対象にできます。ただし、ピン留め後にエンドユーザーへ表示されるまで最大6時間かかる場合があるため、リリース当日の案内では反映遅延も考慮してください。(Microsoft Learn)
開発者が確認すべき設定と実装上の注意点
開発者が最初に見るべきなのは、Declarative Agentsを「設定ファイルにすれば終わり」と考えないことです。YAML/JSONに切り出した後も、モデル、認証、出力形式、ナレッジ、エラーハンドリング、監視の設計が必要です。
YAML/JSONはレビューしやすいが、壊れやすい
Microsoft 365 Copilotのマニフェスト仕様では、定義されていないプロパティや余計なプロパティがあると、文書全体が無効になるとされています。(Microsoft Learn)
これは移行時に特に重要です。既存の社内テンプレートや古いサンプルからコピーした項目が、現在のスキーマでは無効になっている可能性があります。CI/CDに組み込むなら、少なくとも次の検証を入れてください。
- YAML/JSONの構文チェック
- スキーマバージョンの確認
- 不明なプロパティの検出
- 必須項目の存在確認
- サンプルプロンプトによる応答テスト
- 期待する出力形式の検証
認証は開発環境と本番環境で分ける
Microsoft Agent Frameworkの公式サンプルではDefaultAzureCredentialが使われていますが、公式ドキュメントでは本番環境では慎重に検討し、ManagedIdentityCredentialなど特定の認証方式を検討するよう注意されています。(Microsoft Learn)
開発環境では便利でも、本番環境で意図しない認証情報を探索したり、余計な遅延が発生したりする可能性があります。運用設計では、次のように分けると安全です。
| 環境 | 認証設計の考え方 |
|---|---|
| ローカル開発 | 開発者の資格情報やCLI認証を利用して素早く検証 |
| 検証環境 | 本番に近いマネージドIDやサービスプリンシパルで確認 |
| 本番環境 | 最小権限、明示的な認証方式、監査可能な構成に固定 |
また、Microsoft Agent Frameworkは.envファイルを自動読み込みしないため、使う場合はアプリ側で読み込むか、シェルやIDEで環境変数を設定する必要があります。(Microsoft Learn)
ナレッジソースとライセンスの確認ポイント
Declarative agentsで社内データを使う場合、ナレッジソースの選び方が回答品質とセキュリティを大きく左右します。Microsoft 365 Copilot側では、SharePoint、OneDrive、Copilot connectors、Web検索、Dataverse、メール、Teamsメッセージなどの知識ソースや機能が整理されています。(Microsoft Learn)
SharePointとOneDriveはアクセス権とライセンスを確認する
SharePointやOneDriveをナレッジとして使う場合、Copilotはサインイン中のユーザーがアクセスできるファイル、フォルダー、サイトを検索して回答の根拠にします。公式ドキュメントでは、SharePointとOneDriveのナレッジソースにはアクティブなMicrosoft 365 Copilotライセンスが必要で、ライセンスがない場合は応答できない旨のエラーになると説明されています。(Microsoft Learn)
つまり、開発者の環境では動いたのに、一部ユーザーでは動かないという問題が起きやすい領域です。展開前に、対象ユーザーのライセンスとアクセス権を必ず確認してください。
Web検索は管理者ポリシーに左右される
Web検索を有効にすると、Bingの検索インデックスを使って回答できます。また、スコープ付きWeb検索では最大4つの公開Webサイトに対象を絞れます。(Microsoft Learn)
ただし、組織管理者がCopilotとエージェントのWeb検索を無効化している場合、エージェント側でWeb検索を有効にしていても、Web検索は回答に含まれません。公式ドキュメントでは、この場合でもエージェントがエラーを報告しないことがあると説明されています。(Microsoft Learn)
「Web検索を入れたのに情報が取れない」という問い合わせが出た場合は、まずテナント側のWeb検索ポリシーを確認しましょう。
埋め込みファイルは情報バリアに注意する
Agent Builderでファイルをアップロードしてナレッジ化する場合、埋め込みファイルの内容はSharePoint Embeddedに保存され、テナントのOneDriveとSharePoint容量を消費します。さらに、Microsoft Purview Information Barriersは埋め込みファイルではサポートされず、エージェントにアクセスできるユーザーは、そのファイルに基づく回答を見る可能性があります。(Microsoft Learn)
機密情報を含むファイルを安易に埋め込むのは避けるべきです。ファイルを使う場合は、感度ラベル、公開範囲、所有者、更新手順をセットで決めてください。
移行時に失敗しやすいポイント
Declarative Agentsへの移行でありがちな失敗は、既存のプロンプトや設定をそのままYAML/JSONに移すだけで終わらせることです。宣言化は整理の手段であり、品質保証の代わりではありません。
既存エージェントから移行する手順
移行は、次の順序で進めると安全です。
| 手順 | 作業内容 | 判断基準 |
|---|---|---|
| 現状把握 | 既存エージェントの目的、利用者、データソースを洗い出す | 使われていないものは移行対象から外す |
| 定義分離 | instructions、モデル設定、出力形式をYAML/JSONに切り出す | まずは挙動を変えずに移す |
| スキーマ確認 | 対応バージョンと必須項目を確認する | 不明なプロパティを残さない |
| テスト | 代表的な質問、失敗しやすい質問、権限差のあるユーザーで確認 | 開発者アカウントだけで判断しない |
| 管理者レビュー | データアクセス、外部連携、公開範囲を確認する | 全社公開前に限定グループで検証 |
| 段階展開 | 部門単位、役割単位でリリースする | 問い合わせ窓口とロールバック手順を用意する |
一つのエージェントに詰め込みすぎない
Microsoft 365 Copilotでは、宣言型エージェント同士を接続して、追加情報の取得やアクション実行を分担できます。公式ドキュメントでは、大量のドキュメントやツールを一つのエージェントに追加して品質が下がる場合、機能を別エージェントに分割して接続する考え方が示されています。(Microsoft Learn)
これは実務でも重要です。人事、経理、ITヘルプデスク、営業支援を一つの汎用エージェントにまとめると、指示が複雑になり、回答の一貫性が落ちやすくなります。まずは業務目的ごとに小さく作り、必要に応じて接続する方が運用しやすくなります。
展開前チェックリスト
Declarative Agentsを公開する前に、管理者と開発者で次の項目を確認してください。
| 確認項目 | 担当 | チェック内容 |
|---|---|---|
| 目的と対象ユーザー | 業務部門・開発者 | 誰のどの業務を助けるエージェントか明確か |
| instructions | 開発者・レビュー担当 | 禁止事項、回答範囲、トーンが具体的か |
| スキーマバージョン | 開発者 | 古いサンプルや無効なプロパティを使っていないか |
| 認証方式 | 開発者・管理者 | 本番でDefaultAzureCredentialに依存していないか |
| ナレッジソース | 管理者・情報管理部門 | SharePoint、OneDrive、Web、埋め込みファイルの範囲は妥当か |
| ライセンス | 管理者 | 対象ユーザーが必要なMicrosoft 365 Copilotライセンスを持つか |
| Web検索ポリシー | 管理者 | テナント設定とエージェント設定が矛盾していないか |
| 公開範囲 | 管理者 | 全社公開、特定グループ、テストユーザーの切り分けができているか |
| 監査・運用 | 管理者 | 所有者、更新手順、問い合わせ先、停止手順があるか |
| ユーザー案内 | 業務部門 | 何ができるか、何を入力してはいけないかを説明しているか |
Microsoft 365管理センターのエージェント詳細では、Data & toolsタブでエージェントがアクセスできるデータや外部ソース、実行できるアクションを確認できます。また、Permissionsタブでは付与された権限の詳細を確認できます。展開判断では、これらの情報を見てから承認・ブロック・削除を選ぶべきです。(Microsoft Learn)
どの方法で作るべきか
Microsoft 365 Copilot向けのDeclarative agentsは、Agent Builder、Microsoft 365 Agents Toolkit、Copilot Studio、SharePointなど複数の方法で作成できます。公式ドキュメントでも、これらのツールが選択肢として示されています。(Microsoft Learn)
選び方は、作る人と運用方法で判断すると分かりやすくなります。
| 作成方法 | 向いているケース | 注意点 |
|---|---|---|
| Agent Builder | 業務部門が素早く社内向けエージェントを作る | 公開範囲とナレッジソースの管理を後回しにしない |
| Microsoft 365 Agents Toolkit | 開発者がマニフェストやCI/CDを管理する | スキーマ検証とパッケージ更新の運用が必要 |
| Copilot Studio | 業務プロセスや外部連携を含むエージェントを作る | 権限、環境、コネクタ管理を整理する |
| SharePoint | 特定サイトのナレッジをもとにエージェント化する | サイト権限と情報整理の品質が回答に影響する |
| Microsoft Agent Framework | 独自アプリやバックエンドにAIエージェントを組み込む | 認証、監視、モデル選定、運用責任を自社で設計する |
小さく始めるならAgent BuilderやSharePoint、開発プロセスに組み込むならAgents ToolkitやAgent Framework、業務フロー全体を扱うならCopilot Studioが候補になります。
まず何から確認すべきか
Declarative Agentsの導入で最初にやるべきことは、新機能を試すことではなく、既存のAIエージェントやCopilot拡張を棚卸しすることです。誰が所有し、どのユーザーに公開され、どのデータにアクセスし、どのような業務判断に使われているかを整理してください。
次に、開発者はYAML/JSONやマニフェストのバージョン、認証方式、ナレッジソース、出力形式を確認します。管理者はMicrosoft 365管理センターでAgent Registry、Data & tools、Permissions、Security、公開範囲、共有ポリシーを確認します。
Declarative Agentsは、エージェント開発を簡単にするだけでなく、設定を見える化し、チームで管理しやすくするための仕組みです。まずは限定された業務シナリオで検証し、動作・権限・ライセンス・運用手順を確認してから、段階的に展開するのが安全です。
コメント