Microsoft 365 CopilotのAgent Builderとは？特徴と実務での使いどころを整理

Posted at 2026-07-15

はじめに

Microsoft 365 Copilotには、特定の業務や目的に合わせたエージェントを作成できるAgent Builderがあります。

以前から存在していた機能ですが、最近あらためて確認してみると、自然言語による作成、テンプレート、ナレッジソースの指定、その場でのテストなどが整備され、以前よりもエージェントを試しやすくなっていました。

特に分かりやすく変わったのは、設定画面の項目を一つずつ埋めるだけではなく、

どのようなエージェントを作りたいかを文章で説明すると、Copilotが基本構成を作ってくれる

という作り方が前面に出てきたことです。

この記事では、2026年7月15日時点のMicrosoft公式情報をもとに、Microsoft 365 CopilotのAgent Builderについて、細かな上限値や料金体系ではなく、主な特徴と実務での使いどころを整理します。

ナレッジソースの上限、対応機能、ライセンス、料金などは変更される可能性があるため、実際に利用する際は最新のMicrosoft公式ドキュメントを確認してください。

まず結論

Microsoft 365 CopilotのAgent Builderは、次のような用途で使いやすい機能です。

特定の業務に合わせたCopilotを作る
毎回使っている長いプロンプトをエージェントとして保存する
SharePointなどの社内情報を参照させる
回答時の観点や出力形式を統一する
個人や小規模チームでエージェントを試作する
コードを書かずにエージェントを作る
作成画面で回答を確認しながら調整する

特に、

👉 同じ資料を参照し、毎回同じ観点と形式で情報を整理する

という作業と相性がよさそうです。

一方で、複雑な業務フロー、承認処理、外部システムへの登録・更新、全社規模での本格的な展開などが必要な場合は、Copilot Studioなどを検討する必要があります。

Agent Builderとは

Agent Builderは、Microsoft 365 Copilot内から、特定の目的に合わせた宣言型エージェントを作成するための機能です。

宣言型エージェントとは、独自のAIモデルを開発するのではなく、Microsoft 365 Copilotと共通のオーケストレーター、基盤モデル、AIサービスを利用しながら、次の要素を追加して特定用途向けに構成するエージェントです。

指示
ナレッジ
機能やアクション

Microsoftは、宣言型エージェントがMicrosoft 365 Copilotと同じ基盤上で動作し、指示、ナレッジ、アクションによって業務用途に合わせて調整される仕組みとして説明しています。

Agent Builderでは、主に次の項目を設定します。

エージェントの名前
エージェントの説明
実行する役割
回答時のルール
参照するナレッジ
会話を始めるためのプロンプト
必要に応じた追加機能

たとえば、次のようなエージェントを作成できます。

社内手順書について回答するエージェント
プロジェクト資料を要約するエージェント
過去の障害報告から類似事例を探すエージェント
会議資料から決定事項と宿題を抽出するエージェント
技術情報を社内共有用の文章へ変換するエージェント

自然言語でエージェントを作成できる

最近のAgent Builderで特に便利になったと感じるのが、自然言語によるエージェント作成です。

Microsoft 365 Copilotで新しいエージェントを作成する際は、主に次の方法を利用できます。

作りたいエージェントを自然言語で説明する
設定画面から手動で構成する
テンプレートから開始する

Microsoftの公式ドキュメントでも、Agent Builderは自然言語を使って宣言型エージェントを短時間で作成できるインターフェースとして説明されています。

たとえば、次のように入力します。

Salesforceのリリース情報を整理するエージェントを作成してください。
変更内容を次の分類で整理してください。
・新機能
・既存仕様への変更
・廃止予定
・管理者が確認すべき項目
・利用者への影響
結果は社内のSlackに投稿できる簡潔な日本語で出力してください。

この説明をもとに、Agent Builderが次のような基本構成を作成します。

エージェント名
説明
指示
回答ルール
会話の開始例

最初から設定項目を一つずつ考える必要がないため、エージェントの作成経験が少ない場合でも、まず形にしやすくなっています。

作成された内容が意図と違う場合は、会話形式で修正できます。

回答をもう少し短くしてください。

廃止予定の機能には、影響を受ける利用者も記載してください。

技術者向けと管理者向けの確認事項を分けてください。

👉 普段Copilotへ依頼する感覚に近い方法でエージェントを組み立てられる点が、Agent Builderの分かりやすい特徴です。

テンプレートから開始できる

作成したいエージェントの構成が思い浮かばない場合は、用意されたテンプレートから開始することもできます。

テンプレートには、用途に応じて次のような項目があらかじめ設定されています。

エージェントの目的
基本的な指示
回答時のルール
会話の開始例

テンプレートをそのまま使うというよりも、自分の目的に近いものを選び、業務に合わせて修正する使い方が向いています。

最近のMicrosoft 365 Copilotの更新でも、一般的な業務シナリオ向けのエージェントテンプレートが追加されています。

エージェントの指示をゼロから設計する必要がないため、試作を始める際のハードルを下げてくれます。

社内情報をナレッジとして指定できる

Agent Builderでは、エージェントが回答するときに参照するナレッジソースを指定できます。

代表的なものとして、次のような情報源があります。

SharePointのファイル、フォルダー、サイト
OneDrive上のファイル
Teamsのチャット
Outlookのメール
組織内の人物情報
公開Webサイト
端末からアップロードしたファイル
Microsoft 365 Copilotコネクタ経由の情報

利用できる情報源は、ライセンス、管理者設定、組織の環境などによって異なります。Microsoftの公式ドキュメントでも、SharePoint、Teams、公開Webサイト、アップロードファイル、Copilotコネクタなどを、Agent Builderのナレッジとして利用できることが案内されています。

たとえば、次のような構成が考えられます。

利用者
 ↓ 質問
Agent Builderで作成したエージェント
 ↓ 参照
SharePoint上の手順書・設計書・FAQ
 ↓
回答と参照情報を返す

特定の資料をナレッジとして指定しておけば、利用者がファイルの保存場所を把握していなくても、自然言語で質問できます。

SharePoint、OneDrive、Teams、OutlookなどのMicrosoft 365上の情報は、原則として利用者自身のアクセス権限に従って参照されます。

一方、端末から直接アップロードしたファイルはエージェントに埋め込まれます。エージェントを共有すると、共有先の利用者がそのファイルの内容に基づく回答へアクセスできるため、ファイルの機密性、秘密度ラベル、エージェントの共有範囲を事前に確認してください。

実際に利用する際は、次の点を確認する必要があります。

対象資料のアクセス権限
エージェントの共有範囲
古い資料と新しい資料の混在
機密情報や個人情報の有無
回答根拠として適切な資料か
利用するナレッジソースの最新仕様

細かな件数上限やライセンス条件は変更される可能性があるため、本記事では扱いません。利用時点の公式ドキュメントを確認してください。

指示とナレッジを分けて考えられる

Agent Builderを理解するうえでは、指示とナレッジを分けて考えると分かりやすくなります。

指示

エージェントに、どのように振る舞ってほしいかを設定します。

最初に結論を示してください。
回答は500文字以内にしてください。
管理者向けと利用者向けの対応を分けてください。
資料に書かれていない内容は推測しないでください。

ナレッジ

エージェントが回答を作る際に参照する情報を設定します。

手順書
仕様書
FAQ
議事録
障害報告
社内規定
Webサイト

たとえば、同じSharePoint上の手順書を参照させる場合でも、指示を変えることで異なる用途のエージェントを作れます。

手順書
 ├─ 利用者向けFAQを作るエージェント
 ├─ 管理者向けの確認項目を抽出するエージェント
 └─ 新旧手順の違いを整理するエージェント

👉 単に資料を登録するだけでなく、どの観点で読み、どの形式で返すかを指示することが重要です。

作成画面でそのままテストできる

Agent Builderでは、作成中のエージェントをその場でテストできます。

たとえば、ナレッジを追加した後に次のような質問を行います。

この手順書で、管理者が事前に準備する項目を整理してください。

結果が期待と違う場合は、エージェントの指示を修正します。

回答には、参照した資料名を含めてください。
資料に記載されていない内容は推測しないでください。
確認できない場合は「資料からは確認できません」と回答してください。

Microsoftの公式ドキュメントでも、Agent Builderでエージェントを作成し、その場でテストした後、Microsoft 365 Copilotで利用したり、組織内のユーザーと共有したりできると説明されています。

設定とテストを繰り返しながら回答を調整できるため、完成したプロンプトを一度で作ろうとする必要はありません。

回答方法もある程度調整できる

Agent Builderでは、エージェントの指示だけでなく、用途に応じた応答方法も設定できます。

たとえば、次のように用途によって求められる回答は異なります。

短時間で要点だけ知りたい
通常の深さで回答してほしい
時間をかけて詳しく分析してほしい

現在のAgent Builderでは、回答速度と分析の深さに関する応答モードも用意されています。

応答モードの名称、動作、適用条件などは今後変わる可能性があります。具体的な設定内容については、利用時点の公式ドキュメントや実際の設定画面を確認してください。

記事として重要なのは、Agent Builderが単に資料を検索するだけでなく、目的に応じて回答方法も事前に調整できるようになっている点です。

毎回同じプロンプトを書かなくてよくなる

通常のCopilotでも、長いプロンプトを書けば、特定の形式で回答させることはできます。

Agent Builderとの大きな違いは、繰り返し利用する役割やルールをエージェントとして保存できる点です。

項目	通常のCopilot	Agent Builder
主な用途	一時的な幅広い作業	特定業務の繰り返し
指示	会話ごとに入力	エージェントに保存
参照情報	都度指定することが多い	ナレッジとして設定
回答形式	必要に応じて毎回指定	あらかじめ設定可能
共有	プロンプトなどを共有	エージェントとして共有
調整	会話の中で行う	設定とテストを繰り返す

一度だけ行う作業であれば、通常のCopilotで十分です。

一方、次のような場合はAgent Builderが向いています。

同じ作業を何度も行う
同じ長いプロンプトを繰り返し使っている
複数人で同じ回答ルールを使いたい
参照する資料をある程度固定したい
出力形式を統一したい
エージェントとして名前を付けて使い分けたい

👉 Agent Builderは、Copilotへ毎回入力していたプロンプトを、再利用可能な業務ツールへ変える機能と考えると分かりやすいです。

Copilot Studioとの違い

Microsoft 365 CopilotのAgent BuilderとCopilot Studioは、どちらもエージェントを作成する機能ですが、想定されている用途が異なります。

Microsoftは、Agent Builderを個人や小規模チーム向けにエージェントを素早く作る場合に適した選択肢として案内しています。

一方、Copilot Studioは、より高度な設定、外部連携、業務フロー、管理、組織規模での展開などを行うためのローコード開発環境として位置付けられています。

ざっくり整理すると、次のようになります。

項目	Agent Builder	Copilot Studio
主な対象	個人・小規模チーム	部門・組織
作り方	自然言語・簡易設定	ローコード・詳細設定
始めやすさ	比較的始めやすい	設計項目が多い
ナレッジの参照	対応	対応
複雑な条件分岐	基本的に非対応	対応
複数ステップの処理	基本的に非対応	対応
承認や業務フロー	基本的に非対応	対応
外部システム連携	Agent Builder単体では限定的	コネクタなどで拡張
管理・分析	比較的簡易	より詳細
向いている用途	試作・検索・要約・定型回答	業務自動化・本番展開

Agent Builderは「Copilot Studioの簡易版」というよりも、Microsoft 365 Copilotを自分たちの業務向けに調整するための入口と考えるとよさそうです。

Agent Builderから始めて発展させることもできる

最初からCopilot Studioで大きなエージェントを作るのではなく、Agent Builderで小さく試す方法もあります。

通常のCopilot
 ↓ プロンプトを試す
Agent Builder
 ↓ 指示の保存・ナレッジ追加・共有
Copilot Studio
 ↓ 外部連携・業務フロー・本格展開

Agent Builderで作成したエージェントを、後からCopilot Studioへコピーして拡張する方法も用意されています。

すべての設定やナレッジがそのまま移行できるとは限りません。

そのため、

まず通常のCopilotでプロンプトを試す
繰り返し使えそうならAgent Builderへ移す
業務フローや外部連携が必要になったらCopilot Studioを検討する

という段階的な進め方が現実的です。

Agent Builderが向いているケース

参照する資料が決まっている

たとえば、次のような資料です。

社内規定
操作手順書
製品仕様書
プロジェクト資料
FAQ
過去の議事録
障害報告書

「まずこの資料を確認して回答してほしい」という用途で使いやすくなります。

回答時の観点が決まっている

次のように、毎回確認する項目が決まっている作業です。

・概要
・影響範囲
・対象となる利用者
・管理者の確認事項
・対応期限

こうした観点をエージェントの指示として保存しておけば、毎回プロンプトを書く必要がありません。

同じ形式に変換する

たとえば、次のような変換です。

技術資料からSlack共有文を作る
会議資料からアジェンダを作る
議事録から決定事項を抽出する
長い文書から管理者向けの要点を作る
社内資料からFAQを作る
説明資料から利用者向けの案内文を作る

繰り返し行う定型的な情報整理は、Agent Builderと相性がよさそうです。

Agent Builderだけでは不足するケース

Agent Builderは手軽ですが、すべての業務を実現できるわけではありません。

次のような要件がある場合は、Copilot StudioやPower Automateなども含めて検討する必要があります。

外部システムへデータを登録・更新する
条件によって処理を細かく分岐する
複数の処理を決められた順番で実行する
上司や担当者による承認を行う
定期的に自動実行する
エラー時に通知や再実行を行う
複数のシステムを連携させる
利用状況を詳細に分析する
開発・検証・本番環境を分けて管理する
全社向けに厳密なガバナンスを適用する

Microsoft 365全体の情報を使って質問へ回答するところまではAgent Builderで試しやすくなっています。

一方、回答だけでなく実際の業務処理まで実行させたい場合は、別の仕組みが必要になります。

業務で考えられる活用例

Salesforceの変更情報を整理する

Salesforce関連の資料や社内の確認事項を参照し、次の形式で整理するエージェントです。

・新機能
・既存機能への変更
・廃止予定
・管理者の確認事項
・利用者への影響

最新情報を定期的に取得する仕組みは別途必要ですが、取得済みの情報を社内向けに整理する用途には使えそうです。

社内手順書について回答する

SharePoint上の操作手順書を参照し、利用者の質問に回答します。

OAuth認証へ切り替える場合、
利用者が最初に行う操作を説明してください。

回答時に資料名や根拠を示すよう設定しておくと、利用者が元資料を確認しやすくなります。

障害事例を探す

過去の障害報告書や対応履歴をナレッジとして指定し、現在の事象に似た事例を探します。

現在のエラーと類似する過去事例を抽出し、
原因、対処方法、確認項目を整理してください。

最終判断をエージェントへ任せるのではなく、調査の入口として利用する形が現実的です。

会議資料から共有文を作る

会議資料や議事録をもとに、次の形式で共有文を作成します。

・決定事項
・継続検討
・担当者
・期限
・次回までの宿題

TeamsやSlackへ投稿する形式をあらかじめ指示しておけば、毎回同じ構成で出力できます。

社内文書を用途別に変換する

一つの技術資料から、目的の異なる文章を作成します。

技術資料
 ├─ 管理者向けの説明
 ├─ 利用者向けの案内
 ├─ 会議用のアジェンダ
 └─ Slack投稿用の要約

同じナレッジを使い、指示だけを変えた複数のエージェントを作る方法も考えられます。

作成時に意識したいこと

最初から大きなエージェントを作らない

最初から多くの資料と複雑な指示を入れると、回答が期待どおりにならなかったときに原因を特定しにくくなります。

まずは次のような小さな構成から始める方がよさそうです。

対象業務を一つに限定する
ナレッジを少数の資料に限定する
出力形式を一つにする
テスト質問を用意する
結果を確認してから資料を追加する

指示を具体的にする

「分かりやすく回答してください」だけでは、回答結果を評価しにくくなります。

次のように具体化します。

回答は500文字以内にしてください。
最初に結論を示してください。
資料に記載がない内容は推測しないでください。
回答の最後に参照した資料名を記載してください。
管理者が行う作業と、利用者が行う作業を分けてください。

Microsoftの公式ドキュメントでも、宣言型エージェントの指示には、目的、一般的なガイドライン、スキル、ステップ、エラー処理などを具体的に記載することが案内されています。

テスト質問を先に用意する

エージェントを作成してから思いつきで質問するのではなく、事前に期待する質問と回答を用意しておくと評価しやすくなります。

たとえば、次の観点で確認します。

正しい資料を参照しているか
古い情報を優先していないか
資料にない内容を推測していないか
指定した形式で回答しているか
質問の言い換えにも対応できるか
分からない場合に適切に回答できるか
実際の利用者にも分かる回答になっているか

注意点

Agent Builderが便利になったとしても、エージェントの回答が常に正しいとは限りません。

特に、次の点には注意が必要です。

重要な判断は元資料でも確認する
古い資料をナレッジに含めない
正式文書と参考資料を区別する
回答根拠を表示するよう指示する
機密情報を含む資料の共有範囲を確認する
作成者だけでなく実際の利用者でもテストする
Microsoft 365の管理者設定を確認する
利用する機能のライセンス条件を確認する

また、Agent Builderは比較的変更の多い機能です。

次のような細かな仕様は、記事に固定値として書くよりも、実際に利用する直前に公式情報を確認した方が安全です。

ナレッジソースごとの上限
利用できるファイル形式
対応する情報源
応答モードの種類
ライセンス条件
従量課金の有無
Copilot Studioへ移行できる設定
既知の問題
管理者が制御できる項目

本記事はAgent Builderの特徴と使いどころを把握するための概要として利用し、導入時の詳細な仕様は最新の公式ドキュメントで確認してください。

まとめ

Microsoft 365 CopilotのAgent Builderは、自然言語で作りたいエージェントを説明し、Copilotに基本構成を作ってもらえることで、以前よりかなり試しやすくなっています。

特に便利になったと感じるポイントは、次のとおりです。

自然言語でエージェントを作成できる
テンプレートから開始できる
Microsoft 365内の情報をナレッジとして指定できる
回答時の役割やルールを保存できる
作成画面でそのままテストできる
エージェントとして他の利用者と共有できる
必要に応じてCopilot Studioへ発展させられる

毎回同じ長いプロンプトを入力している業務や、特定の資料を参照して同じ観点で情報を整理している業務があれば、Agent Builderを試す価値があります。

一方で、複雑な条件分岐、承認、外部システムとの連携、定期実行などが必要な場合は、Agent Builderだけで完結させようとせず、Copilot StudioやPower Automateも含めて検討する必要があります。

まずは個人用の小さなエージェントを作り、実際の質問で回答を確認しながら、チーム共有や業務への展開を判断するのが現実的だと思います。

※本記事は個人の整理メモです。

参考（公式情報）

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up