Microsoft 365 Copilotのエージェントの作り方と活用事例｜Copilot Studio・エージェントビルダー・Notebooksの使い分け（シリーズ完結）ARTICLE

※ Microsoft 365 Copilot は、2026年8月から「Microsoft Copilot」に名称が変わりました（Copilot Chat は「Microsoft Copilot Chat」）。移行期間中は旧名称も併用されているため、本記事では広く使われている「Microsoft 365 Copilot」の表記で統一しています（出典：Microsoft Learn「Microsoft Copilot のデータ、プライバシー、セキュリティ」）。

本シリーズではここまで、Microsoft 365 Copilot を導入し、社員が日常業務で「使う」ための準備と定着を扱ってきました。データの置き場所を整え、権限とルールを決め、研修とチャンピオン制度で使われる状態を作る——ここまで来た会社が次に向き合うのが、自社の業務に合わせたAIを「作る」段階です。

その中心にあるのがエージェントです。「社内規程の質問に答える」「見積もりの前に確認すべき点を洗い出す」といった特定の仕事に絞った Copilot を、IT部門ではなく現場の社員が作り、社内で共有できるようになっています。一方で、誰でも作れるからこそ、管理されないエージェントが増える問題も出てきます。

本記事は第1回：非IT企業のMicrosoft 365 Copilot導入ロードマップで示したフェーズ4の先、「その先のAI活用へ」を扱う第8回で、シリーズの完結編です。エージェントの作り方と使い分け、管理の考え方、料金の注意点を解説し、最後にシリーズ全体を振り返ります。

この記事の要点

• エージェントとは、指示・知識・操作を設定した業務専用の Copilot です。簡単なものはエージェントビルダー（ChatGPT の GPTs や Gemini の Gem の Microsoft 365 版）、決まった手順の自動化はPower Automate、外部連携まで要るものはCopilot Studio、案件ごとの資料の束はCopilot Notebooksで作ります
• エージェントとノートブックは、第2回前編で整理した「学習の3層」の③整理・蓄積を形にする道具です。暗黙知を書いて置く習慣があって初めて役に立ちます
• 作る人が増えるほど、所有者不在の野良エージェントが増えます。台帳・所有者2名・定期見直しのルールを、作り始める前に決めておきます
• 当社の支援では、SharePoint へのアップロード → Power Automate → Copilot → Excel の型で組むことが多く、精度とAIのクレジットの消費を見て、AIに任せる部分を読み取りなどに絞っています

Microsoft 365 Copilotのエージェントとは

Microsoft 365 Copilot のエージェントとは、特定の業務やテーマに合わせて、指示・知識・操作を設定した専用のAIアシスタントです。Microsoft は、エージェントを「特定の領域に合わせた特殊なAIアシスタントとして Copilot の機能を拡張するもの」と説明しており、情報の取得や要約に加えて、メールの送信や記録の更新といった操作を行うこともできます（出典：Microsoft Learn「Microsoft 365 Copilot のエージェント」）。

構成要素は、どんな役割でどう答えるかの指示、何を参照するかの知識（SharePoint の規程フォルダなど）、答える以外に何を実行するかの操作（申請の起票など）の3つです。

種類は、Copilot のAIモデルと処理の流れをそのまま使う宣言型エージェントと、独自のモデルや処理を組み込むカスタムエンジンエージェントの2つで、非IT企業が社内で作るのはほとんどが前者です。

「使う民主化」から「作る民主化」へ

生成AIの社内活用には、全社員がAIを使えるようにする段階と、現場の社員が自分の業務に合わせたAIを作れるようにする段階があります。

後者に踏み込んでいるのが、日用品メーカーのライオンです。同社は2025年6月、社内生成AIに共通業務のエージェントを実装するとともに、非エンジニアを含むビジネス部門から100名の「AIエージェント開発者」を育成し、2025年度内に各部門固有の30体以上のエージェントを本格運用することを目指すと発表しました。2026年度以降は、そこで得た開発ノウハウを各部門やグループ各社に共有していくとしています（出典：ライオン ニュースリリース（2025年6月24日））。同社はこれを「生成AIの民主化」と呼んでいます（参考：PIVOT「&Questions」）。

中小企業がこの規模をそのまま真似する必要はありません。ただし、業務を知っている人が作り、作ったものとノウハウを社内で共有するという方向性は、規模に関係なく参考になります。Microsoft 365 Copilot では、そのための道具がすでに用意されています。

作る道具は3つ ― エージェントビルダー・Copilot Studio・Copilot Notebooks

エージェントビルダー ― まずはここから

エージェントビルダーは、Microsoft 365 Copilot アプリや Teams から、会話形式で宣言型エージェントを作れる機能です。すでに ChatGPT の GPTs や Gemini の Gem を触ったことがあれば、その Microsoft 365 版と考えると分かりやすいです。役割や答え方の指示を書き、参照する知識を指定して、自分用のAIを作って共有する、という組み立ては同じです。違いは、知識として社内の SharePoint のファイルを指定でき、誰が何を見られるかは Microsoft 365 の権限がそのまま効くこと、管理者が組織として管理できることです。SharePoint 上のファイルなどを知識として指定し、テストしてから社内の他のユーザーと共有できます。Microsoft は、エージェントビルダーで作るエージェントは Microsoft 365 Copilot ライセンスに含まれるとし、外部サービスと連携する操作などの高度な機能が必要な場合は Copilot Studio を使うよう案内しています（出典：Microsoft Learn「Microsoft 365 Copilot のエージェント ビルダー」）。

注意点として、知識に指定した SharePoint のファイルやフォルダは、共有先の全員が閲覧できるように自動で設定されるとは限りません。エージェントを共有したのに「答えが返ってこない」場合は、参照先のファイルの権限を確認します。これはシリーズ第3回で扱う SharePoint の権限設計と同じ考え方で、エージェントも、使う人が見られる情報しか答えに使えないということです。

その前に ― Power Automate で足りることも多い

「業務の自動化まで踏み込みたい」と思ったとき、いきなり Copilot Studio に向かう必要はありません。決まった手順を決まった順番で流すだけなら、Power Automate のクラウドフローで足ります。

• SharePoint・Outlook・Teams・Excel などは、Power Automate の標準のコネクタでつながります（「ファイルが追加されたら」「メールが届いたら」を起点に、承認を回す、ファイルを移す、通知する）
• フローは自然言語で下書きできます。Microsoft は、Power Automate の Copilot について「自然言語で指定した手順を使用して、目標を達成するソリューションを提案します」と説明しています（出典：Microsoft Learn「Power Automate の Copilot」）
• 「本文を要約する」「問い合わせを分類する」のようにAIの判断を挟みたいところだけ、フローの途中にプロンプト（生成AIに処理させる部品）を差し込めます。プロンプトは Power Automate の画面から作成でき、フローの中から呼び出せます（出典：Microsoft Learn「プロンプトを作成する」）

使い分けの目安は次のとおりです。

当社の支援先でも、最初に挙がる「自動化したいこと」の多くは、会話するエージェントではなく決まった手順の自動化でした。Power Automate で形にし、判断が要る部分だけAIに任せる組み立てのほうが、作るのも直すのも簡単です。

K.S.Rogers の現場から

当社がよく使うのは、SharePoint のフォルダにファイルをアップロードすると Power Automate が動き、Copilot で処理して、結果を Excel に書き出す、という型です。支援先で個別の業務から入っても、型でくくると「帳票の読み取り・転記」「集計・報告書の作成」「紙の記録のデータ化と検索」「予定の共有」の4つ程度にまとまります。入口・処理・出口を同じ形にそろえておくと、1つの部署で作った仕組みを、別の業務や別の部署にも持ち込みやすくなります。

型の中でAIに任せる範囲は、実際に動かして精度を見てから決めます。

K.S.Rogers の現場から

ある支援先では、Copilot に処理を任せたところ、精度が足りませんでした。そこで、手順として決められる部分は Excel の Office Scripts（Excel の操作をスクリプトで自動実行する仕組み）で組み、AIには読み取りだけを任せる形に切り替えました。AIに任せる範囲を絞ると結果がぶれにくくなり、誤りが出たときもどこを直せばよいか分かります。「AIで全部やる」より「手順で組めるところは手順で組む」ほうが、現場で安心して使える仕組みになります。

Copilot Studio ― 操作と連携が必要になったら

Copilot Studio は、外部サービスとの連携や条件に応じた自動実行を組み込める開発ツールです。ノーコード・ローコードで作れますが、「どのデータに、誰の権限でアクセスし、何を実行するか」の設計と保守が必要です。非IT企業では、最初からCopilot Studioで作り込まず、エージェントビルダーや Power Automate で試して「会話の中でこの操作まで自動にしたい」という具体的な要望が出てから移るほうが、使われないエージェントを避けられます。

Copilot Notebooks ― 案件ごとの判断材料を束ねる

Copilot Notebooks（Copilot ノートブック）は、ファイル、会議のメモ、メール、Copilot とのチャットなどを1か所に集め、その内容に基づいて質問に答えさせたり、新しい下書きを作らせたりできる作業場所です。ノートブックはチームと共有でき、Microsoft 365 Copilot のライセンスがなくても Copilot Chat のユーザーであれば利用できます（作成には SharePoint または OneDrive のライセンスが必要です）（出典：Microsoft サポート「Copilot ノートブックの使用を開始する」、Microsoft サポート「Microsoft 365 Copilot ノートブックについてよく寄せられる質問」）。

なお、2026年9月時点では、ノートブックに招待したユーザーは全員が編集できる権限を持ち、読み取り専用のメンバーは設定できないとされています。共有する相手は、編集されてもよい関係者に絞ります。

「学習の3層」の③整理・蓄積を形にする

第2回前編では、「AIに学習させる」という言葉を3つの層に分けました。①モデルの学習（Copilot では行われない）、②参照（質問のたびに社内データを検索して答える、Copilot の本体）、③整理・蓄積（特定のテーマの資料ややりとりを束ね、繰り返し判断材料を引き出せる形にする）です。前編では「③の使い方は第8回で本格的に扱う」と予告しました。

③を形にする道具が、ノートブックとエージェントです。使い分けは次のとおりです。

• ノートブック：案件やプロジェクトのように、期間が決まっていて、関係者が限られる判断材料の束
• エージェント：社内規程や製品知識のように、期間を問わず、多くの人から繰り返し聞かれる問いへの窓口

案件別の意思決定ノートを作る

経営者の「過去の判断の経緯を、後から引き出せるようにしたい」という要望に応えるのが、案件ごとの意思決定ノートです。進め方は次のとおりです。

1. 案件ごとに SharePoint のフォルダ（または Teams のチャネル）を用意する
2. 会議のたびに「決定事項・決めた理由・却下した案・未決事項」を短く書いて置く（Teams 会議の要約を下書きに使ってよい）
3. 案件のノートブックを作り、見積書、議事録、顧客とのメール、決定メモを参照として追加する
4. 案件の途中や終了後に「この仕様に決めた理由は何だったか」「同じ顧客から過去に出た変更要望は何か」とノートブックに聞く

ここで大切なのは、AIに材料を渡す前に、判断の理由を書いて置く習慣を作ることです。第2回前編で述べたとおり、暗黙知は書かれて Microsoft 365 の中に置かれて初めてAIの材料になります。ノートブックもエージェントも、書かれていない判断理由を補ってはくれません。

非IT企業でのエージェント活用例 ― 最初に作るなら

「AIエージェントで業務効率化」と聞くと大がかりに感じますが、最初に作るべきなのは、質問の範囲がはっきりしていて、答えの根拠となる資料がすでにあるエージェントです。

ライオンの育成プログラムでも、成果物の例として「アンケートの自由回答の解析」「申請書類の事前添削」といった、部門や個人の業務に特化したエージェントが挙げられています（出典：ライオン ニュースリリース）。いずれも、対象の業務が具体的で、効果を測りやすいものです。

一方、請求書の読み取りと基幹システムへの転記、複数のシステムをまたぐ照合のように、判断よりも決まった処理を大量に回す業務は、Copilot のエージェントより、業務システムと直接つないだ自動化のほうが向いています。K.S.Rogers の支援でも、請求書の仕分けと転記の自動化で月次経理作業の負担を65%削減し、決算業務を2営業日前倒しした事例があります（OpeZeroの導入事例）。

誰がどこまで作るか ― 段階別の目安

「全社員がエージェントを作れるようになるべきか」と聞かれることがありますが、その必要はありません。第7回（後編）：社内研修の進め方で示した入門・初級・中級・上級の段階に沿って、どこまでできれば十分かを整理すると、次のようになります。

入門・初級の人は「使う」だけで十分です。第7回（後編）で書いたとおり、全員が上級を目指す必要はありません。作る人は各部署に1〜2名いれば回り始めます。中級の人がノートブックを作り始めたら、上級への入り口に立っています。

エージェントの作り方 ― 5つのステップ

エージェントビルダーで最初のエージェントを作るときは、次の順番で進めます。

1. 業務と問いを決める ―― 「誰が、どんな質問をするための窓口か」を1文で書く。範囲を広げすぎない
2. 知識を選び、権限を確認する ―― 参照させる資料を最新版に絞り、使う人全員がその資料を閲覧できるか確認する。古い版や下書きは混ぜない
3. 指示を書く ―― 役割、答え方、分からないときの対応（「規程にないことは推測せず、担当部署を案内する」など）を書く
4. 意地悪な質問でテストする ―― 範囲外の質問、あいまいな質問、資料にない質問をして、推測で答えないかを確認する
5. 所有者と共有範囲を決めて公開する ―― 所有者を2名決め、共有する部署を決めてから公開する。社内台帳に登録する

特に4つ目が重要です。エージェントは資料にないことでもそれらしく答えようとするため、「分からないときの振る舞い」を指示に書き、確かめてから共有します。

野良エージェント化に注意 ― 作る前に決める管理のルール

作る人が増えると、必ず起きるのが野良エージェントの問題です。野良エージェントとは、作成者の異動・退職や目的の消滅によって、誰も管理していないまま社内に残るエージェントのことです。放置すると、次のような問題が起きます。

• 参照先の資料が古いまま更新されず、誤った回答を返し続ける
• 同じ目的のエージェントが部署ごとに乱立し、どれを使えばいいか分からなくなる
• 共有範囲や参照先の権限が、作成者の意図と違うまま広がる

Microsoft 365 管理センターには、エージェントを管理する機能がそろってきています。組織内で共有されたエージェントの一覧（エージェント レジストリ）で作成者や状態を確認し、安全でない・規則に合わないと判断したエージェントをブロックできます。組織全体に公開するエージェントは、管理者の承認を経てエージェントストアに掲載する流れになっており、所有者のいないエージェントに所有者を割り当てる操作も用意されています。利用できる機能は契約中のライセンスによって異なります（出典：Microsoft Learn「Microsoft 365 管理センターでエージェントを管理する」、Microsoft Learn「Microsoft 365 管理センターでのエージェントの概要」）。

ただし、管理機能があっても、判断の基準は社内で決める必要があります。作り始める前に、次のルールを決めておきます。

• 台帳に登録する ―― 名前、目的、所有者、参照先の資料、共有範囲、最終見直し日を一覧にする
• 所有者は2名にする ―― 異動・退職で所有者不在にならないようにする
• 半年に1回見直す ―― 使われていない、資料が古いエージェントは更新するか削除する
• 全社公開は申請制にする ―― 部署内での共有は自由に、全社に公開するものは推進責任者が確認する

エージェントを社内で共有する「ハブ」の考え方

作ったエージェントを部署に閉じず、社内で見つけて使えるようにする場所を、ここではエージェントハブと呼びます。Microsoft 365 Copilot では、管理者が承認したエージェントをエージェントストアで公開できるので、ストアを社内のハブとして運用するのが基本です。

ハブを機能させるコツは、エージェントそのものに加えて、作り方のノウハウも共有することです。どんな指示を書いたらうまくいったか、どんな質問でテストしたか——ライオンが開発ノウハウの社内共有を次の段階に掲げているように、作り方が共有されると、2体目以降のエージェントは格段に作りやすくなります。第7回で扱った社内コミュニティを、作る人の情報交換の場としても使います。

エージェントの料金とライセンス（2026年9月時点）

エージェントの料金は、エージェントを使う人のライセンスと、エージェントが何を参照・実行するかで変わります。2026年9月時点の Microsoft の説明を整理すると、次のとおりです。

（出典：Microsoft Learn「Copilot 拡張オプションのライセンスとコストに関する考慮事項」、Microsoft Learn「Copilot Studio のライセンス」）

Copilot クレジットは、エージェントの応答や操作の量を測る単位で、1回の応答で消費される量はタスクの複雑さによって変わります。支払い方法には、月ごとの容量を前払いで購入する方法と、Azure のサブスクリプションを通じて実際に使った分だけ支払う従量課金があります。Microsoft の日本向け価格ページでは、前払いのパックが月額29,985円で25,000クレジットと表示されています（出典：Microsoft「Copilot Studio の価格」、2026年9月時点）。

ライセンスを持たない社員にも社内データを使うエージェントを配る場合、従量課金は既定で無効になっており、管理者が請求の設定をして初めて有効になります。予算の上限と通知も設定できます（出典：Microsoft Learn「Microsoft Copilot Pay-as-You-Go Service Overview」）。「ライセンスのない人にも配ったら、想定外の請求が来た」を防ぐため、予算上限を必ず設定します。

エージェントに限らず、フローの中でAIに処理させる場合も、使った量に応じた費用を見込んでおく必要があります。

K.S.Rogers の現場から

Power Automate のフローの中で Copilot の処理を回したところ、AIのクレジットを大量に消費したことがありました。1件ずつは小さくても、毎日・毎件の処理にAIを挟むと積み上がります。根本的な回避策はまだ検討しているところですが、量の多い処理では、件数とクレジットの消費量から費用を先に見積もり、AIに任せる範囲を決めるようにしています。前述のとおり、手順で組める部分はAIを使わずに組めるので、量を見て使い分けます。

料金体系・製品名・機能は変わりやすい領域です。導入や予算の判断の前には、最新の公式情報を確認してください。

シリーズ全体の振り返り

最後に、全8回と特別編・番外編で扱ってきた内容を、第1回で示したロードマップのフェーズに沿って振り返ります。

全体像

• 第1回：非IT企業のMicrosoft 365 Copilot導入ロードマップ｜ライセンスを配る前に決めるべきこと ―― 失敗パターン、Copilot の種類、二層構成、5フェーズのロードマップ

フェーズ0：現状把握

• 第2回前編：Microsoft 365 Copilotは社内のメールやチャットを「学習」するのか ―― 学習の3層、データの置き場所、Box・SharePoint・OneDrive の判断
• 第2回後編：Exchange Online移行の注意点とLINE WORKSからの移行 ―― メールとチャットの移行、導入前チェックリスト
• 番外編：Microsoft 365 Copilotはいらない？ ―― 「Googleより高い」への答え方と判断基準

フェーズ1：データガバナンス整備

• 第3回：Microsoft 365 Copilotの情報漏洩対策 ―― SharePoint・OneDrive・Teams の権限の棚卸しと是正
• 第4回前編：Microsoft 365 Copilotのセキュリティ設定 ―― 中小企業に秘密度ラベルとDLPは必要かの判定
• 第4回後編：秘密度ラベルとDLP ―― 「警告」から始める段階設計とライセンス

フェーズ2：ルール整備

• 第5回前編：生成AIの社内ルールの作り方（サンプル条文付き） ―― 利用ガイドラインの作り方
• 第5回後編：システム開発を外注するときのAI利用ルール ―― 開発会社に求める5つの約束
• 特別編：その社内規則、Microsoft 365 Copilotを禁止していますか？ ―― 規程の禁止文言と EDP の読み合わせ

フェーズ3：パイロット

• 第6回：Microsoft 365 Copilotのパイロット導入と効果測定 ―― 指標と Go/No-Go 判断
• 番外編：Microsoft 365 Copilotが使えない・期待した回答を返さない原因と対処 ―― 切り分けフローチャート

フェーズ4：全社展開と定着化、その先へ

• 第7回前編：Microsoft 365 Copilotの定着化 ―― チャンピオン制度と「使われない」を防ぐ仕組み
• 第7回後編：Microsoft 365 Copilotの社内研修の進め方 ―― 段階別研修と復習の仕組み
• 番外編：情シスがいない会社のMicrosoft 365 Copilot導入 ―― 一人情シス・兼務でも回る体制
• 第8回：本記事（エージェントの作り方と活用）

このほか、シリーズと並行して、AI利用のルールづくりの実務としてClaude Codeの秘密情報対策とhooksの設定例も公開しています（開発に生成AIを使う場合の話です）。

シリーズを通して伝えてきたことは、1つに集約できます。Copilot 導入の成否は、AIの性能ではなく、社内の情報の扱い方を整えられるかで決まるということです。データを置く場所、見せてよい範囲、使ってよいルール、使う人を支える仕組み——これらはエージェントを作る段階でも、そのまま土台になります。

K.S.Rogers の支援

K.S.Rogers では、Microsoft 365 Copilot の導入ロードマップの策定から、データの置き場所と権限の整備、ガイドライン策定、定着化、そしてエージェントづくりまでを一貫して伴走しています。エージェントについては、最初の1体を現場の方と一緒に作り、台帳と見直しのルールまで含めて社内に残る形で支援します。

Copilot のエージェントの範囲を超えて、基幹システムとつないだ定型業務の自動化が必要な場合は、OpeZeroでシステム環境調査（20万円〜）から構築・運用まで対応します。また、「どの業務をAIに任せるか」から整理したい場合は、要件定義支援の相談・壁打ち（月10万円・税別）から始めることもできます。

M365 の導入・ファイル移行から Power Platform・Copilot の活用までの支援の範囲と進め方は、Microsoft 365 導入・活用支援のページにまとめています。

シリーズのどの段階からでも、お問い合わせよりお気軽にご相談ください。

まとめ

• エージェントは、指示・知識・操作を設定した業務専用の Copilot です。エージェントビルダーで小さく始め、外部連携が必要になったら Copilot Studio、案件ごとの資料の束は Copilot Notebooks を使います
• 決まった手順を自動で流すだけなら、Copilot Studio の前に Power Automateで足ります。判断が要るところだけ、フローの中でAIに任せます
• ノートブックとエージェントは「学習の3層」の③整理・蓄積を形にする道具です。判断の理由を書いて置く習慣が前提になります
• 野良エージェントを防ぐため、台帳・所有者2名・半年ごとの見直し・全社公開の申請制を、作り始める前に決めます
• 料金は使う人のライセンスと参照するデータで変わります。従量課金を使う場合は予算上限を設定し、最新の公式情報を確認します

本シリーズは今回で完結です。最後までお読みいただき、ありがとうございました。