結論から言うと、Microsoft 365 Copilot拡張の開発環境は「何のデータに接続するエージェントを作るか」で選びます。指示やWeb検索を使う軽いエージェントならCopilotライセンスなしでも検証できますが、SharePoint、Copilot connectors、Microsoft Graph、メール、Teamsメッセージなどの組織データを使う場合は、従量課金、Copilot Credits、Microsoft 365 Copilotライセンス、管理センター側の設定確認が必要です。
2026年5月15日前後に更新されたMicrosoft Learnの「Set up your development environment for Microsoft 365 Copilot」では、Microsoft 365 Copilotを拡張するための開発環境、Copilot Studio、Microsoft 365 Agents Toolkit、開発者モード、ライセンス別の機能差が整理されています。英語版ページ上の最終更新日は2026年5月14日と表示されているため、本記事ではその公式情報をもとに、日本企業の管理者・開発者が確認すべき実務ポイントに絞って解説します。(Microsoft Learn)
Microsoft 365 Copilot拡張で押さえるべき変更点
今回の要点は、Microsoft 365 Copilotの拡張開発が「Copilotライセンスを持つ一部ユーザーだけの開発」ではなく、Microsoft 365 Copilot Chat、Copilot Studio、従量課金、Copilot Creditsを組み合わせて段階的に進める形へ整理されている点です。
Microsoft 365 Copilot Chatは、Microsoft 365ユーザーが利用できる広いAIチャット入口として位置づけられています。一方で、SharePointデータやMicrosoft 365 Copilot connectorsを使った高度なエージェント機能は、Copilot Studioの従量課金が有効なテナント、またはMicrosoft 365 Copilotライセンスを持つユーザーで利用できると説明されています。(Microsoft Learn)
つまり、管理者や開発者が最初に判断すべきことは「Copilotを使えるか」ではなく、次の3点です。
- エージェントがWebや指示だけで動くのか
- SharePoint、Dataverse、Copilot connectorsなどの組織データを使うのか
- メール、ユーザー情報、Teamsメッセージ、Teams会議など、より深いMicrosoft 365データまで扱うのか
この判断を誤ると、開発環境では動いたのに本番でデータに接続できない、管理者にサイドロードを止められて検証できない、Copilot Creditsの消費が想定より大きい、といった問題が起きやすくなります。
開発環境は4パターンから選ぶ
Microsoft 365 Copilot拡張の開発環境は、大きく分けると次の4パターンです。開発者の都合だけで選ぶのではなく、接続するデータ、検証したい機能、管理権限、コスト管理のしやすさで選びます。
| 開発環境 | 向いている用途 | 注意点 |
|---|---|---|
| Microsoft 365 Developer Programのサンドボックス | 基本的なエージェント開発、Web検索や指示ベースの検証 | 対象者が限定される。サブスクリプションがコマースをサポートしないため、組織データによるグラウンディングや一部機能は利用できない |
| Microsoft 365 Copilotライセンス付きの本番環境 | 実データを使ったパイロット、社内展開前の現実的な検証 | 管理者がカスタムアプリのサイドロードやコネクタ権限を制限している場合がある |
| CopilotライセンスなしのMicrosoft 365サブスクリプション | Microsoft 365 Copilot Chat向けの軽量なエージェント検証 | 利用できる機能は限定的。組織データを使う場合は従量課金またはライセンスが必要 |
| 本番とは別の開発用テナントにCopilotライセンスを用意 | 管理者権限を持って安全に検証したい場合 | ライセンス費用、課金設定、データ移行・同期範囲の設計が必要 |
Microsoft 365 Developer Programのサンドボックスは便利ですが、公式情報では対象者がVisual Studio Professional/Enterpriseサブスクライバー、ISV Success Programメンバー、対象のMicrosoft AI Cloud Partner Programパートナー、Premier/Unified Support顧客などに限定されるとされています。また、現時点ではコマースをサポートしないため、組織データに基づくエージェントの構築には向きません。(Microsoft Learn)
本番環境で開発する場合は、実際のユーザー権限やSharePoint、Teams、Graphデータに近い条件で検証できるのが利点です。ただし、管理者のポリシーによってカスタムアプリのサイドロードがブロックされていたり、Copilot connectorsに必要な権限が付与されていなかったりすることがあります。(Microsoft Learn)
ライセンス別に使える機能の違い
Microsoft 365 Copilot拡張では、ライセンスや従量課金の状態によって、使えるデータソースとエージェント機能が変わります。特に重要なのは、Copilot Chatだけで使える範囲と、Copilot CreditsまたはMicrosoft 365 Copilotライセンスが必要になる範囲を分けて考えることです。
| やりたいこと | Copilot Chatのみ | Copilot Chat＋従量課金 | Microsoft 365 Copilotライセンス |
|---|---|---|---|
| 指示ベースの宣言型エージェント | 利用可能 | 利用可能 | 利用可能 |
| Web検索を使ったナレッジ | 利用可能 | 利用可能 | 利用可能 |
| Copilot connectorsを使ったナレッジ | 利用不可 | 利用可能 | 利用可能 |
| SharePointデータの利用 | 利用不可 | 利用可能 | 利用可能 |
| Dataverseの利用 | 利用不可 | 利用可能 | 利用可能 |
| メール、人物情報、Teamsメッセージ、Teams会議の利用 | 利用不可 | 利用不可 | 利用可能 |
| 開発者モードでの検証 | 利用不可 | 利用不可 | 利用可能 |
公式ドキュメントの機能表では、Copilot Chatのみでもカスタム指示、Web検索、スコープ付きWeb検索、Code interpreter、Image generator、MCP Appsなどの機能は利用可能とされています。一方、Copilot connectors、SharePointデータ、埋め込みファイル、Dataverseは従量課金またはMicrosoft 365 Copilotライセンスが必要です。メール、人物情報、Teamsメッセージ、Teams会議を使うナレッジはMicrosoft 365 Copilotライセンス側の機能として整理されています。(Microsoft Learn)
実務では、最初から全社データを接続するよりも、まずは指示ベースまたはWeb検索ベースのエージェントで利用シーンを検証し、必要性が明確になってからSharePointやCopilot connectorsに進む方が安全です。特に社内FAQ、営業支援、申請状況確認、ナレッジ検索のような用途では、どのデータを使うかによって必要なライセンスと管理設定が変わります。
Copilot Studioで確認すべき前提条件
Copilot StudioはMicrosoft 365ユーザーがエージェントやアクションを作成するために利用できます。ただし、SharePointやCopilot connectorsを使って組織データに基づくエージェントを作る場合は、テナントで従量課金を設定するか、必要なCopilot Studioライセンスを用意する必要があります。(Microsoft Learn)
Copilot Studioを使う前に、管理者は次の設定を確認してください。
| 確認項目 | 管理者 | 確認ポイント |
|---|---|---|
| 生成AI機能の有効化 | Power Platform管理者またはDynamics 365管理者 | Power Platform管理センターでGenerative AI featuresを有効にする |
| Copilot Studioアプリの展開 | Microsoft 365テナント管理者 | Microsoft 365管理センター側で組織内利用に必要なアプリ展開を行う |
| 従量課金またはCopilot Credits | 課金管理者、Power Platform管理者 | SharePoint、Copilot connectors、Dataverseなどを使う場合に必要 |
| データ移動の同意 | Power Platform管理者またはDynamics 365管理者 | 環境やリージョンによっては、生成AI機能のためにリージョンをまたぐデータ処理への同意が必要 |
| エージェント公開・配布 | Microsoft 365管理者、AI管理者 | Copilot Control Systemで承認、割り当て、ブロック、削除を管理 |
Power Platformの生成AI機能では、環境がホストされている地域や利用機能によって、リージョンをまたぐデータ処理の同意が必要になる場合があります。設定画面では、Move data across regions、Bing search、Microsoft 365 servicesなどの項目を確認します。データ移動を許可しない場合でもすべてのCopilot機能が無効になるわけではありませんが、一部の生成AI機能が利用できない可能性があります。(Microsoft Learn)
日本企業では、ここを法務・セキュリティ部門に説明せずに進めると、PoCの後半で承認が止まりやすくなります。開発開始前に、対象環境、利用するデータ、処理リージョン、利用規約への同意者を一覧化しておくと、展開時の手戻りを減らせます。
Microsoft 365 Agents Toolkitを使う場合の注意点
Microsoft 365 Agents Toolkitを使うと、Microsoft 365 Copilotライセンスがなくてもエージェント開発を始められます。ただし、組織データに基づくエージェントを作るには、テナントで従量課金を設定するか、Microsoft 365 Copilotライセンスを用意する必要があります。(Microsoft Learn)
もう一つ重要なのが、Teams側のカスタムアプリのサイドロード設定です。Agents ToolkitやIDEからエージェントをテストするには、管理者がTeams管理センターでカスタムアプリのアップロードを許可している必要があります。公式手順では、Teams admin centerの「Teams apps」から「Setup policies」を開き、「Global (Org-wide default)」の「Upload custom apps」をオンにすると説明されています。(Microsoft Learn)
開発者が「コードは正しいのにテストできない」と感じる場合、原因は実装ではなく管理ポリシーであることが少なくありません。特に大企業では、Teamsアプリのアップロード、外部コネクタ、カスタムアプリ配布が既定で制限されていることがあります。開発環境を作る段階で、Teams管理者にサイドロード可否を確認しておきましょう。
開発者モードは何に使うべきか
Copilot Chatには、開発者モードを使って、ユーザーのプロンプトに対してオーケストレーターがプラグインやエージェントをどのように選択するかを検証する機能があります。有効化はCopilot Chatで-developer on、無効化は-developer offを入力します。ただし、開発者モードはライセンス付きのMicrosoft 365 Copilotエクスペリエンス内でのみ利用できます。(Microsoft Learn)
開発者モードは、単に「動くか」を見るためのものではありません。次のような検証に使うと効果的です。
- 期待したエージェントが呼び出されているか
- 類似した複数エージェントのうち、どちらが選択されるか
- ユーザーの自然な質問文でアクションが発火するか
- 不要な場面でエージェントが呼び出されていないか
- 社内用語、略語、部署名を含む質問でも意図を判定できるか
たとえば「来月の営業会議の資料をまとめて」と入力したときに、営業ナレッジ検索エージェントが呼ばれるのか、会議情報を扱う機能が呼ばれるのか、あるいは通常のCopilot応答で終わるのかを確認できます。展開前にこの挙動を見ておかないと、ユーザーが実際に使い始めた後で「呼ばれないエージェント」や「呼ばれすぎるエージェント」が発生します。
Copilot Creditsと課金管理の見落としに注意
Copilot Studioの従量課金では、エージェントの利用がCopilot Creditsで測定されます。消費量は、エージェントの設計、利用頻度、使う機能によって変わります。公式ドキュメントでは、生成回答、エージェントアクション、Tenant Graph grounding、AIツールなどが異なるレートで課金されることが説明されています。(Microsoft Learn)
管理者が注意すべき点は、1回の会話が1種類の消費だけで終わるとは限らないことです。たとえば、社内データに基づく生成回答では、生成回答とTenant Graph groundingの両方が消費対象になる場合があります。エージェントがアクションやフローを呼び出す場合は、さらに消費が増える可能性があります。(Microsoft Learn)
本番展開前には、次の3つを必ず決めてください。
| 決めること | 理由 |
|---|---|
| 誰が利用できるか | 対象ユーザーを広げすぎると、検証段階で想定以上にCopilot Creditsを消費する |
| どのデータを使うか | SharePoint、Copilot connectors、Tenant Graph groundingはコストと権限設計に影響する |
| 月次の上限をどう管理するか | Power Platform管理センターで個別エージェントの月次消費上限を設定できる |
Copilot Studioの容量管理では、消費超過時にエージェントやフロー実行へ影響が出る場合があります。Power Platform管理センターで消費状況を確認し、必要に応じて容量の再割り当て、追加購入、従量課金の設定を検討します。(Microsoft Learn)
セキュリティと権限設計で見るべきポイント
Microsoft 365 Copilot拡張で最も重要なのは、AIそのものよりも「どのデータを、誰の権限で、どの経路から使うか」です。Microsoft 365 Copilotは、既存の権限とポリシーを使って情報を提示する考え方を採っています。Copilot connectorsで取り込まれた外部データも、Microsoft Graph内でユーザーのアクセス境界に従って扱われます。(Microsoft Learn)
Copilot connectorsを使って外部データをMicrosoft 365 Copilotに接続する場合、外部データはMicrosoft Graphに取り込まれます。外部アイテムへのアクセス権は、Microsoft Entraユーザー、グループID、外部グループなどに関連付けたACLで管理できます。(Microsoft Learn)
一方、エージェントやアクションとして外部サービスと連携する場合、外部データはアプリ側にとどまり、Microsoft Graphに流れ込まないケースがあります。ただし、Copilotはユーザーのプロンプトや会話履歴、ユーザーがアクセスできるMicrosoft 365データをもとに、エージェントへ検索クエリを送ることがあります。(Microsoft Learn)
ここで失敗しやすいのが、既存のSharePointや社内システムの権限が緩いままCopilotに接続してしまうことです。Copilotが「本来見えてはいけない情報」を新たに作り出すわけではありませんが、ユーザーがアクセス権を持っている情報を見つけやすくするため、過剰共有されたファイルや古いACLが表面化しやすくなります。
本番前には、少なくとも次の確認が必要です。
| 確認項目 | 実務上の見方 |
|---|---|
| SharePointの共有範囲 | 「全社共有」「リンクを知っている全員」などが残っていないか |
| Copilot connectorsのACL | 外部データの権限がMicrosoft Entraのユーザー・グループと正しく対応しているか |
| アクションの権限 | 申請、承認、削除、送信などの操作に人間の確認ステップを入れるべきか |
| プライバシーポリシーと利用規約 | エージェント利用前に管理者・ユーザーが確認できる状態か |
| 監査ログとDLP | Copilot Studio、Power Platform、Microsoft Purviewの管理範囲を整理しているか |
特に、未検証の外部データやユーザー入力を扱うアクションに、承認、送信、削除、更新のような操作を直接実行させるのは避けるべきです。公式情報でも、信頼できないデータソースを使う場合は侵害を想定した設計を行い、慎重な人間の介入なしに機微な操作を実行させないことが推奨されています。(Microsoft Learn)
エージェントの展開はCopilot Control Systemで管理する
エージェントを作った後は、公開、割り当て、展開、ブロック、削除までを管理する必要があります。Microsoft 365管理センターでは、組織内のCopilotエージェントを有効化、無効化、割り当て、ブロック、削除できると説明されています。(Microsoft Learn)
管理者は、Microsoft 365 admin center内のCopilot Control Systemを使い、Agentsページで利用可能なエージェント、展開済みエージェント、ブロック済みエージェントを確認できます。エージェントごとに、利用可能性、アクセス、公開、展開、ブロック、削除といった操作を管理できます。(Microsoft Learn)
Copilot Studioで作成されたエージェントを組織に公開すると、Microsoft 365管理センターのCopilot Control System上で要求済みエージェントとして扱われます。その後、管理者が確認・承認することで、ユーザーやグループに利用可能にできます。(Microsoft Learn)
展開時は、いきなり全社公開するのではなく、次の順序で進めるのが現実的です。
| フェーズ | 対象 | 確認すること |
|---|---|---|
| 開発者検証 | 開発者、管理者 | エージェントが意図したデータとアクションだけを使うか |
| 限定PoC | 業務部門の数名から十数名 | 業務用語、質問パターン、回答精度、誤動作を確認 |
| 部門展開 | 対象部門 | Copilot Credits、問い合わせ量、権限問題を確認 |
| 全社展開 | 対象ユーザー全体 | 利用ポリシー、監査、サポート体制、改善サイクルを運用 |
エージェントの展開では、AI管理者やMicrosoft 365管理者だけでなく、Power Platform管理者、Search管理者、Azure管理者、セキュリティ管理者が関わる場面があります。Microsoft 365 agents deployment checklistでも、Microsoft 365 admin、Power Platform admin、Microsoft 365 Search admin、Azure adminの関与が整理されています。(Microsoft Learn)
既存ボットやプラグインから移行する場合の判断基準
既存のTeamsボット、社内FAQボット、業務アプリ連携、メッセージ拡張をMicrosoft 365 Copilot向けに拡張・移行する場合は、単にインターフェースを変えるだけでは不十分です。重要なのは、Copilotの中で使わせる価値があるか、ユーザー権限に沿って安全にデータを返せるか、コストを制御できるかです。
移行判断では、次の基準を使うと整理しやすくなります。
| 既存機能 | 移行・拡張の方向性 | 注意点 |
|---|---|---|
| 固定FAQボット | 指示ベースまたはWeb検索ベースのエージェントから開始 | 回答の根拠、古いFAQ、重複コンテンツを整理する |
| SharePoint上の社内ナレッジ検索 | SharePointデータを使うエージェントとして検討 | 権限の過剰共有とCopilot Credits消費を事前確認する |
| CRMや基幹システム検索 | Copilot connectorsまたはPower Platform connectorsを検討 | ACL、API権限、応答速度、外部システムの負荷を見る |
| 申請・承認・更新処理 | アクション付きエージェントとして段階的に展開 | 重要操作は人間の確認を入れる。最初は参照系から始める |
| Teamsメッセージや会議情報の活用 | Microsoft 365 Copilotライセンス前提で検討 | ライセンス対象、利用範囲、監査要件を明確にする |
移行で失敗しやすいのは、既存ボットの機能をそのままCopilotに載せ替えることです。Copilotでは、ユーザーが自然文で質問し、複数のエージェントやデータソースの中から必要なものが選ばれます。そのため、エージェント名、説明、指示、使うナレッジ、アクションの粒度を見直す必要があります。
たとえば「経費精算エージェント」を作る場合、最初から申請登録まで自動化するより、まずは「規程の検索」「必要書類の案内」「差し戻し理由の説明」までに限定した方が安全です。利用が安定した後で、申請システムとの連携や承認ワークフローに広げると、管理者の承認も得やすくなります。
管理者と開発者が最初にやるべきチェックリスト
Microsoft 365 Copilot拡張を始める前に、次のチェックリストを使って開発環境を確認してください。
| チェック項目 | 確認内容 |
|---|---|
| 開発環境 | Developer Programサンドボックス、本番環境、別テナントのどれで検証するか |
| ライセンス | Microsoft 365 Copilot、Copilot Studio、Microsoft 365 Copilot Developer licenseの要否 |
| 課金 | Copilot Credits、従量課金、月次上限、消費レポートの確認方法 |
| データソース | Web、SharePoint、Dataverse、Copilot connectors、メール、Teamsのどれを使うか |
| 管理設定 | Teamsサイドロード、Copilot Studioアプリ展開、Power Platform生成AI機能 |
| セキュリティ | SharePoint共有範囲、コネクタACL、DLP、監査ログ、Purview対応 |
| 展開方法 | Copilot Control Systemでの承認、割り当て、ブロック、削除手順 |
| テスト | 開発者モード、ユーザー権限別テスト、部門別PoC、ロールバック方法 |
開発者は「エージェントを作れるか」だけでなく、管理者が本番展開できる状態かを早い段階で確認する必要があります。管理者は「便利そうだから許可する」のではなく、データ範囲、権限、コスト、監査、サポート体制をセットで判断することが重要です。
まとめ：まずはデータ範囲を決めてから開発環境を作る
Microsoft 365 Copilot拡張の開発環境設定では、最初にツールを選ぶのではなく、エージェントが扱うデータ範囲を決めることが出発点です。Webや指示ベースなら軽量に始められますが、SharePoint、Copilot connectors、Dataverse、メール、Teamsデータを使う場合は、ライセンス、従量課金、管理センター設定、セキュリティ設計が不可欠です。
次に取るべき行動は、対象エージェントを1つ選び、次の順で整理することです。
| 手順 | やること |
|---|---|
| 1 | エージェントの目的を1文で定義する |
| 2 | 使うデータソースをWeb、SharePoint、外部システム、Microsoft 365データに分類する |
| 3 | 必要なライセンスとCopilot Creditsの有無を確認する |
| 4 | Teams、Power Platform、Microsoft 365管理センターの設定を確認する |
| 5 | 小さなPoCで回答精度、権限、課金、展開手順を検証する |
Microsoft 365 Copilotの拡張は、作って終わりではありません。エージェントの公開、利用状況の確認、権限の見直し、Copilot Creditsの管理、ユーザーフィードバックを継続的に回すことで、初めて業務に定着します。まずは、全社展開を急がず、管理しやすい小さな業務シナリオから始めるのが最も安全で効果的です。
コメント