Extend Microsoft 365 Copilotは、Microsoft 365 Copilotを「社内データに答えるAI」「業務システムを操作するAI」「独自アプリに組み込めるAI」へ広げるための拡張機能群です。2026年5月16日に更新された公式情報では、Agent BuilderのOneDrive知識ソース、宣言型エージェントのmanifest 1.7、エージェント評価、Package Management APIなど、管理・開発の実務に直結する変更が整理されています。結論として、利用者はより業務文脈に合ったCopilotを使いやすくなりますが、管理者と開発者は、エージェントの公開範囲、データ権限、ライセンス、評価、棚卸しを先に設計しておく必要があります。(Microsoft Learn)
Extend Microsoft 365 Copilotで何が変わるのか
Extend Microsoft 365 Copilotの中心は、Copilotをそのまま使うのではなく、エージェント、Copilot connectors、Work IQ API、Microsoft 365 Copilot APIsを使って、自社の業務データや業務フローに合わせて拡張することです。Microsoftの概要では、エージェントによる業務ワークフローの自動化、Copilot connectorsによる外部業務データの取り込み、Work IQ APIによるMicrosoft 365の仕事文脈の利用、Copilot APIsによる独自アプリへのCopilot機能統合が整理されています。(Microsoft Learn)
| 拡張領域 | できること | 実務上の意味 |
|---|---|---|
| エージェント | 特定業務向けのAIアシスタントを作る | 社内規定確認、ITヘルプデスク、営業支援、オンボーディングなどをCopilot上で実行しやすくなる |
| Copilot connectors | ERP、CRM、ナレッジベース、チケット管理など外部データをCopilotに接続する | SharePoint以外の業務データも検索・要約・推論対象にできる |
| Work IQ API | Microsoft 365上のメール、会議、ドキュメント、Teams、人物情報などを文脈として扱う | 独自エージェントやアプリが、ユーザーの仕事文脈を踏まえて応答できる |
| Microsoft 365 Copilot APIs | Retrieval API、Search API、Chat API、Meeting Insights APIなどを利用する | 自社アプリにCopilot由来の検索、会話、監査、会議インサイトを組み込める |
重要なのは、これは「Copilotの画面が少し変わる」程度の更新ではないという点です。社内で作られたエージェント、外部SaaSとつながるコネクタ、独自アプリから使うAPIが増えるほど、Copilotは業務基盤に近づきます。その分、IT管理者による制御と、開発者による品質管理が欠かせません。
2026年5月16日更新で押さえるべき変更点
2026年5月16日更新の「What’s new in Microsoft 365 Copilot extensibility」では、2026年5月分の更新として、Agent Builder、宣言型エージェント、評価、管理APIに関する内容が追加されています。特に影響が大きいのは、OneDriveファイルを知識ソースにしやすくなった点、manifest 1.7で応答制御が拡張された点、エージェント評価の仕組みが整備された点です。(Microsoft Learn)
| 変更点 | 何ができるようになるか | 最初に確認すべきこと |
|---|---|---|
| Agent BuilderのOneDrive knowledge | Agent Builderでフォルダーや最大50個のOneDriveファイルを知識として追加できる | 機密ファイルを安易に共有対象エージェントへ入れていないか |
| Declarative agent manifest 1.7 | editorial_answers、default_response_mode、depends_onを利用できる | 既存manifestを更新する必要があるか、互換性テストを行うか |
| 新しいAgent Builderテンプレート | Executive Briefing、My Company Policy、SME Finderなどのテンプレートを利用できる | テンプレートをそのまま使わず、自社データ・権限・利用部門に合わせて調整する |
| エージェント評価 | 評価フレームワークやAgent Evaluations CLIで品質を測定しやすくなる | 本番展開前にテストケースと合格基準を作る |
| Package Management API更新 | 管理者がパッケージのブロック、ブロック解除、メタデータ更新、所有者再割り当てを扱える | 退職者が所有するエージェントや未承認エージェントの棚卸しを行う |
宣言型エージェントmanifest 1.7では、意味的に近い質問を定義済みQ&Aへ対応させるeditorial_answers、応答モードを制御するdefault_response_mode、会話スターターの依存関係を指定するdepends_onが追加されています。開発者は「manifestを新しくする」だけでなく、想定質問、応答速度、推論品質、会話導線のテストをセットで行うべきです。(Microsoft Learn)
Package Management APIはプレビューとして、組織内のアプリやエージェントの一覧取得、詳細取得、ブロック、ブロック解除、所有者再割り当てなどに対応します。ただし、利用にはMicrosoft Agent 365ライセンスが必要とされています。運用上は、退職者が作成したエージェント、部門で放置されたエージェント、利用停止すべきエージェントの棚卸しに役立つ領域です。(Microsoft Learn)
利用者への影響：社内文脈に合ったCopilotを使いやすくなる
利用者側の一番大きな変化は、Copilotがより「自社の業務に近い回答」を返しやすくなることです。たとえば、経費精算ルール、製品仕様、障害対応手順、顧客対応履歴、プロジェクトの進捗などを、エージェントやCopilot connectorsを通じて扱えるようになります。
具体的には、次のような使い方が想定されます。
- 新入社員が「在宅勤務の申請ルールを教えて」と聞くと、社内規定をもとに回答する
- 営業担当が「この顧客の最近の問い合わせ傾向をまとめて」と聞くと、CRMやチケット情報をもとに要約する
- プロジェクトメンバーが「今週のリスクを整理して」と聞くと、Teams会話、会議、ドキュメントを踏まえて整理する
- 管理部門が「この規定の最新版はどれか」と聞くと、SharePointやOneDriveの指定ファイルを根拠に回答する
ただし、利用者が自由にすべての情報へアクセスできるわけではありません。Work IQ APIの公式説明では、要求はサインイン中のユーザーのコンテキストで実行され、Microsoft 365の権限や秘密度ラベルを尊重し、Microsoft 365の信頼境界内にとどまると説明されています。(Microsoft Learn)
一方で、Agent Builderにアップロードした埋め込みファイルには注意が必要です。公式ドキュメントでは、エージェントにアクセスできるユーザーは、埋め込みファイルの内容に基づく応答を受け取れると説明されています。また、埋め込みファイルではMicrosoft Purview Information Barriersがサポートされない旨も示されています。機密ファイルを「便利だから」という理由だけでエージェントに直接アップロードするのは避けるべきです。(Microsoft Learn)
管理者が確認すべき設定と運用ポイント
Extend Microsoft 365 Copilotの導入で、管理者が最初に確認すべきなのは「誰が作れるか」「誰が使えるか」「どのデータに接続できるか」「どう止めるか」です。Microsoft 365 admin centerでは、エージェントの有効化、無効化、割り当て、ブロック、削除などを管理でき、Microsoft 365 Copilotライセンス済みテナントではこの機能が既定で有効とされています。(Microsoft Learn)
| 確認項目 | 確認する場所・観点 | 失敗しやすいポイント |
|---|---|---|
| エージェントの利用可否 | Microsoft 365 admin centerのAgents関連設定 | 既定で使える状態のまま、部門ごとのルールを決めずに展開する |
| 組織カタログへの公開 | エージェントの申請・承認・公開フロー | 作成者の判断だけで全社利用に近い状態になる |
| 共有エージェントの管理 | 作成者が共有したエージェントの一覧、作成者、状態 | 部門内で作ったエージェントが放置される |
| カスタムアプリのサイドロード | Teams admin centerのUpload custom apps設定 | 開発検証のために全社へ広く許可してしまう |
| Copilot connectors | Entra IDアプリ登録、Graph権限、コネクタの有効化 | 外部データの権限設計が不十分なまま接続する |
| ライセンス・課金 | Microsoft 365 Copilotライセンス、Copilot Studio従量課金、Copilot Credits | 組織データを使うエージェントで必要なライセンスや課金を見落とす |
| 棚卸し・停止 | Package Management API、管理センター | 退職者所有のエージェントや古いエージェントが残る |
Agents Toolkitで作成したエージェントをテナントへサイドロードするには、Teams admin centerでカスタムアプリのアップロードを有効にする必要があります。検証目的で有効にする場合でも、対象ユーザーや期間を限定し、検証後に設定を見直す運用が安全です。(Microsoft Learn)
Copilot Studioを利用する場合は、Power Platform管理者またはDynamics 365管理者による生成AI機能の有効化、Microsoft 365テナント管理者によるCopilot Studioアプリの展開などが必要です。開発部門だけで進めると、公開直前に管理者設定で止まることがあるため、PoCの初期段階から管理者を巻き込むべきです。(Microsoft Learn)
Copilot connectorsは「同期型」と「フェデレーション型」を使い分ける
Copilot connectorsは、外部の業務データをMicrosoft 365 Copilotで扱うための重要な拡張です。公式情報では、外部コンテンツをMicrosoft Graphへ取り込みインデックス化するSynced connectorsと、Model Context Protocol（MCP）を使ってリアルタイムに取得し、Microsoft Graphへ保存しないFederated connectorsの2モデルが示されています。(Microsoft Learn)
| 種類 | 特徴 | 向いているデータ | 注意点 |
|---|---|---|---|
| Synced connector | 外部コンテンツをMicrosoft Graphへ取り込み、インデックス化する | ナレッジベース、文書リポジトリ、FAQ、社内規定、LOBシステムの参照データ | 取り込み対象、更新頻度、外部アイテムの権限を設計する |
| Federated connector | MCPを使ってクエリ時にリアルタイム取得し、Microsoft Graphへ保存しない | 常に最新性が必要なデータ、規制上ソースに残したいデータ、動的な業務データ | API応答速度、認証方式、可用性、MCPサーバー運用を考慮する |
判断基準はシンプルです。検索性や再利用性を重視し、Microsoft 365側で意味検索しやすくしたいデータは同期型が向いています。一方、在庫数、インシデント状態、承認ステータスのようにリアルタイム性が重要なデータや、データをGraphへ取り込みたくない業務ではフェデレーション型を検討します。
カスタムコネクタでは、タイトルや本文に十分な情報を入れる、semantic labelsを適切に付ける、URL解決やユーザーアクティビティを設計するなど、検索品質に直結する設定があります。管理者は、Copilot connectorsをMicrosoft SearchやMicrosoft 365 Copilotで使う場合、inline resultsの有効化も確認する必要があります。(Microsoft Learn)
Agent Builderで知識ソースを追加するときの注意点
Agent Builderでは、公開Webサイト、SharePoint、OneDrive、Teamsチャット、アップロードファイル、Copilot connectorsなどを知識ソースとして追加できます。2026年5月16日更新の公式ドキュメントでは、最大4つの公開WebサイトURL、SharePointファイル・フォルダー・サイト、最大50個のOneDriveファイル、最大5つのTeamsチャットURL、端末からアップロードした埋め込みファイル、管理者が有効化したCopilot connectorsを追加できると説明されています。(Microsoft Learn)
特に注意したいのは、知識ソースの範囲を広げすぎないことです。たとえば「人事問い合わせエージェント」に全社ポータル全体を参照させるよりも、就業規則、休暇規定、福利厚生FAQなどに絞ったほうが、回答の根拠が安定しやすくなります。
設定時の実務ポイントは次の通りです。
| 項目 | 実務での判断基準 |
|---|---|
| SharePoint・OneDrive | 部門単位ではなく、用途単位でファイルやフォルダーを選ぶ |
| Teamsチャット | 何でも参照させず、プロジェクトや会議体ごとに絞る |
| Outlookメール | スコープ制御が難しいため、業務上の必要性を慎重に判断する |
| 埋め込みファイル | 機密度が低く、エージェント利用者全員に共有してよい情報に限定する |
| Copilot connectors | コネクタ側の権限、対象データ、スコープ属性を確認する |
Agent Builderには「Only use specified sources」に相当する指定ソース優先の設定がありますが、公式ドキュメントでは、Agent Builderは一般AI知識を完全にブロックする機能をサポートしていないと説明されています。厳密に参照元を制御したい場合は、Copilot Studioの利用を検討する必要があります。(Microsoft Learn)
また、Restricted SharePoint Searchが有効な場合、SharePointを知識ソースとして使えないとされています。SharePointをナレッジ基盤として使う予定がある組織は、検索制限の設定とエージェントの知識ソース設計を合わせて確認してください。(Microsoft Learn)
開発者が確認すべき実装・移行ポイント
開発者は、最初に「エージェントを作るのか」「コネクタでデータを接続するのか」「APIで独自アプリへ組み込むのか」を切り分ける必要があります。目的が違うと、選ぶべき技術も管理すべきリスクも変わります。
| 目的 | 選択肢 | 向いているケース |
|---|---|---|
| 社内向けに簡単な業務エージェントを作る | Agent Builder | 部門FAQ、社内規定、プロジェクト支援など |
| より高度な制御や業務アクションを作る | Copilot Studio | 承認、問い合わせ分類、外部API連携、厳密な会話設計 |
| プロコードでエージェントやアクションを作る | Microsoft 365 Agents Toolkit | manifest管理、APIプラグイン、組織カタログ展開 |
| 外部業務データをCopilotで扱う | Copilot connectors | CRM、ERP、チケット管理、ナレッジベース |
| Microsoft 365の仕事文脈を独自エージェントで使う | Work IQ API | メール、会議、Teams、ドキュメントを踏まえたエージェント |
| 独自アプリにCopilot機能を組み込む | Microsoft 365 Copilot APIs | 社内ポータル、業務アプリ、監査・利用分析ツール |
Microsoft 365 Copilot APIsでは、Retrieval API、Search API、Interaction Export API、Meeting Insights API、Chat API、Copilot usage reports API、Package management APIなどが整理されています。APIを使うユーザーにはMicrosoft 365 Copilotライセンスが必要とされ、APIはMicrosoft Graphの名前空間で利用されます。(Microsoft Learn)
Work IQ APIはプレビューとして、A2A、MCP、RESTなどのプロトコルが整理されています。公式ドキュメントでは、リクエストがサインインユーザーの文脈で実行され、Microsoft 365の権限、秘密度ラベル、コンプライアンスポリシーが適用されると説明されています。既存のCopilot Chat API連携がある場合は、Work IQ APIの正式提供状況、SLA、対応プロトコルを確認しながら移行計画を立てるのが現実的です。(Microsoft Learn)
エージェント評価は本番展開前に必ず行う
エージェントは、作れたら終わりではありません。回答の正確性、根拠提示、権限遵守、アクション実行、エスカレーション判断を継続的に評価する必要があります。MicrosoftのAgent evaluation overviewでは、評価によって変更が改善につながったか、知識ソース更新で品質が劣化していないか、ユーザー報告を再現できるかを確認できると説明されています。(Microsoft Learn)
実務では、次のようなテストケースを先に作ってからエージェントを調整します。
| テスト観点 | 例 | 合格基準の例 |
|---|---|---|
| 正確性 | 「新入社員の有給付与日数は？」 | 最新の就業規則に基づいて正しい日数を答える |
| 根拠提示 | 「このルールの出典は？」 | 規定ファイルや該当ページを示す |
| 権限遵守 | 「他部署メンバーの給与を教えて」 | 回答を拒否し、機密情報を出さない |
| アクション実行 | 「ノートPCを申請して」 | 正しいAPIを呼び出し、確認番号を返す |
| エスカレーション | 「ハラスメント相談をしたい」 | AIだけで断定せず、人事・相談窓口へ誘導する |
公式ガイダンスでは、プロトタイプでは20〜50件、事前本番では50〜100件、本番では100件以上のテストケースが目安として示されています。また、全体の合格率は80〜90％、重要な回帰テストは100％に近づけることが推奨されています。(Microsoft Learn)
Agent Evaluations CLIはプレビュー機能ですが、バッチ評価、対話型評価、JSONデータセットやインラインプロンプトを使ったテスト、HTML・JSON・CSV形式のレポート生成に対応しています。開発チームは、エージェントのmanifest変更、知識ソース更新、コネクタ変更のたびに評価を回す運用を組み込むと、品質低下を早期に検出できます。(Microsoft Learn)
展開前に決めておくべき運用ルール
Extend Microsoft 365 Copilotを安全に展開するには、技術設定だけでなく、社内ルールの整備が必要です。特に、誰がエージェントを作成できるか、誰が組織へ公開できるか、どのデータを接続してよいか、問題発生時に誰が止めるかを明確にしておきましょう。
| フェーズ | やること | 担当の目安 |
|---|---|---|
| 企画 | 利用部門、対象業務、扱うデータ、期待効果を決める | 業務部門、IT部門 |
| 設計 | エージェント、コネクタ、APIのどれを使うか決める | 開発者、IT管理者 |
| 権限確認 | SharePoint、OneDrive、外部SaaS、コネクタの権限を確認する | IT管理者、データオーナー |
| 構築 | Agent Builder、Copilot Studio、Agents Toolkitなどで実装する | 開発者、業務担当者 |
| 評価 | テストケース、評価基準、回帰テストを作る | 開発者、QA、業務部門 |
| 承認 | 組織カタログ、共有範囲、利用対象者を決める | IT管理者、セキュリティ担当 |
| 展開 | まずは部門・グループ単位で段階展開する | IT管理者 |
| 運用 | 利用状況、失敗ログ、古いエージェント、所有者を定期確認する | IT管理者、運用担当 |
公開方法にも違いがあります。Agents Toolkitで作った宣言型エージェントは組織カタログやMicrosoft Commercial Marketplaceへの提出に対応しますが、Agent Builderで作った宣言型エージェントは組織内共有や組織カタログへの提出に対応し、Commercial Marketplaceへの提出は対象外です。Copilot StudioやSharePointエージェントも公開・共有方法が異なるため、作成ツールを選ぶ段階で展開方法まで確認しておくべきです。(Microsoft Learn)
よくある失敗と回避策
Extend Microsoft 365 Copilotの導入で失敗しやすいのは、技術的なエラーよりも「便利だから広くつなぐ」「試験的に作ったものがそのまま残る」「権限の意味を誤解する」といった運用面です。
| 失敗例 | 原因 | 回避策 |
|---|---|---|
| 機密ファイルをエージェントに直接アップロードしてしまう | 埋め込みファイルの共有影響を理解していない | 機密データはSharePoint権限や秘密度ラベルを確認し、必要最小限の知識ソースにする |
| エージェントが関係ない情報を回答する | 知識ソースが広すぎる、指示が曖昧 | 用途別にソースを絞り、評価テストで根拠を確認する |
| コネクタを作ったのにCopilotで期待通り出ない | semantic labels、本文情報、inline resultsなどの設定不足 | 接続後に検索・要約・引用の観点で検証する |
| 開発環境では動いたが本番で使えない | サイドロード、ライセンス、管理者承認が未確認 | PoC開始時点で管理者設定と公開フローを確認する |
| 退職者が所有するエージェントが残る | 棚卸しと所有者管理がない | Package Management APIや管理センターで定期レビューする |
| プレビューAPIを本番前提で使う | 仕様変更リスクを見落とす | プレビュー機能は変更前提で扱い、代替策と移行計画を用意する |
Copilot policy settings APIもプレビューであり、/beta配下のAPIは変更される可能性があり、本番アプリでの使用はサポートされないと明記されています。管理自動化に使う場合は、対象設定、テナントレベルのみ対応する点、プレビュー仕様の変更リスクを踏まえて設計しましょう。(Microsoft Learn)
まず何から始めるべきか
Extend Microsoft 365 Copilotを導入するなら、最初に作るべきものは大規模なエージェントではありません。まずは、影響範囲が明確で、データ権限を確認しやすく、効果を測定しやすい小さな業務から始めるのが安全です。
おすすめは、次の順番です。
- 対象業務を1つ選ぶ
例：社内規定FAQ、IT問い合わせ、営業資料検索、プロジェクト状況確認 - 使うデータを限定する
例：特定のSharePointフォルダー、OneDriveの検証用ファイル、限定されたコネクタデータ - 管理者設定を確認する
エージェントの利用可否、共有範囲、サイドロード、Copilot Studio、コネクタ権限を確認します。 - 最小構成でエージェントを作る
まずはAgent BuilderやCopilot Studioで、業務担当者が評価できる形にします。 - テストケースを作って評価する
正しい回答、根拠提示、拒否すべき質問、誤回答時の挙動を確認します。 - 小さく展開して改善する
最初は特定部門や特定グループに限定し、利用ログ、問い合わせ、失敗例をもとに改善します。
Extend Microsoft 365 Copilotの価値は、Copilotを「何でも聞けるAI」にすることではなく、業務に必要なデータと操作を、権限と品質を保ったままCopilotから扱えるようにすることです。管理者はガバナンスを先に決め、開発者は評価と移行計画を組み込み、利用部門は具体的な業務シナリオから小さく始める。この順番で進めると、便利さと安全性の両方を確保しやすくなります。
コメント