Copilot Studio で作成するAI エージェントのツールとしてMCP(モデル コンテキスト プロトコル)サーバーを追加できますが、現在、SharePoint に関するMCPサーバーも利用できるようになっています。SharePoint を利用するので、Microsoft 365 Copilot のライセンスは必要です。

利用できるのは次の2つです。なお、これらは現在 Frontier プログラムの一部となっています。

• Microsoft SharePoint Lists MCP

• Microsoft SharePoint and OneDrive MCP

この記事では SharePoint Lists MCP について説明します。

なお、今回の説明で使用しているモデルは GPT5-Auto (Preview) であり、プライマリ言語は日本語です。日本語でどこまで動作するのか試したくて。

Microsoft SharePoint Lists MCP とは?

このMCPをエージェント内でツールとして利用することでエージェントと自然な会話をしながら、SharePoint サイト内のリストを操作できます。

SharePoint Lists MCP サーバーに関する公式ドキュメントは次の通りです。

SharePoint Lists Tools MCP サーバー リファレンス | Microsoft Learn

ただし、Copilot Studioで利用する際にすべてこのドキュメントに書かれている通りに操作できるわけでもないようで、注意点などを含めてこの記事にまとめておきます。

※あくまでも 2025/12/28現在の情報であり今後いろいろとアップデートされていくことになると思います。

余談ですが上記ドキュメントに書かれている通り、この MCP ではすべての操作はMicrosoft Graph API v1.0 を使用しています。そのため、ある程度 Graph API v1.0 の知識があるとどうやってやり取りしたらいいかの勘所はつかみやすくなると思いますし制限もイメージしやすいと思います。

主な機能

このMCPサーバーで行える操作は次の通りです。

サイトの操作

• 名前または URL でサイトを検索する
• ホスト名とパスでサイトを解決する
• サブサイトの一覧
• サイト内のリスト一覧

リストの管理

• 新しい SharePoint リストを作成する
• 対応しているのはgenericList のみ
• ドキュメント ライブラリの作成はサポートされない (試すと404エラーとなる)

列の操作

• リスト内のすべての列を一覧表示する
• 列の削除

アイテムの操作

• アイテム取得（listListItems）
• アイテム作成（createListItem）
• アイテム更新（updateListItem、ifMatchで同時編集制御可）
• アイテムの削除

サポートされる列の種類

• 1行テキスト
• 複数(プレーンテキスト、リッチ テキスト)
• 数値 (小数点以下の桁数、最小値、最大値を含む)
• 選択肢 (単一選択および複数選択)
• はい/いいえ
• 日付と時刻 (日付のみ、または日時)
• ユーザーまたはグループの列 (単一選択および複数選択)
• 参照
• ハイパーリンク

サポートされていない機能

上記の機能以外は現時点ではサポートされていません。詳しくは先ほどの公式ドキュメントも確認してみてください。列の追加や編集ができたらいいなと思ったんですが、そこは難しそうですね。ちなみにドキュメント ライブラリを対象にファイル操作をしたい場合は、SharePoint and OneDrive MCPを使う必要があります。

MCPの追加

ツールタブから新しいツールとしてモデルコンテキスト プロトコルの一覧から Microsoft SharePoint Lists MCP を追加します。

追加すると、「ツール」に操作一覧が表示されます。必要な操作のみを許可することも可能ですが、ここでは一通りの処理を検証するため既定値のすべてオンのまま利用します。

このツールを追加してチャットで利用する場合は(テストチャットを含む)、接続の許可が必要です。

操作編

サイトの名前やURLを取得する

サイト名やURLの取得につかえるのは次の2つの操作です。リストを操作する際にまずは対象のリストが存在するサイトのURLが必要になるため、まずはサイトの情報の取得方法を覚えておきましょう。

英語名ですが名称からできることは推測できます。

• searchSitesByName
• getSiteByPath

searchSitesByName を利用できるということは、サイトの表示名や部分的なURLからサイトをできるようになっているということです。そのためサイト名が分かっていれば次のように目的のサイトの情報を取得できます。

例) 「Copilot Studio 入門」という名前のサイトの情報を取得して

getSiteByPath はURLが分かっている場合にサイトの情報を取得できるということです。

例) 「次のURLのサイトの情報を知りたい。
<サイトのURL>」

リストの取得

特定のサイトのリスト一覧を取得できる操作が利用できます。

• listLists

たとえば、次のように指示します。

例)「次のURLにあるリストの一覧を表にしてほしい。<サイトのURL>」

単にリストを一覧表示してほしいと依頼すると Hidden属性が True のものも表示されます。では次のように指示して、Hidden属性も表示させましょう。

例)「次のURLにあるリストの一覧を表にしてほしい。Hidden属性も表示すること。<サイトのURL>」

Hidden属性は隠しリストであるかどうかを示すもので、一般的にはシステムが使うリストは Hidden属性がTrueになっています。そのため、一般利用のリストの一覧を取得したい場合は、「次のURLにあるリストの一覧を表にしてほしい。Hidden属性がTrue のものは除外して表示して。」と依頼するといいでしょう。

またリストにはドキュメント ライブラリも含まれます。ドキュメント ライブラリもリストの一種であるためです。もしリストのみにしたいのであれば、「ドキュメント ライブラリは除外して」「BaseType eq 0 のものだけにして」などと指定します。ちなみにライブラリのみにしたい場合は「ドキュメント ライブラリだけを対象にして」「BaseType eq 1 のものだけにして」などと指定します。

---

Tips

設定メニュー内の「生成AI」の項目から「コードインタープリター」を有効化していれば、Excel への出力もできます。

実際に Excel への出力を依頼するとすぐに作成してくれます。

---

特定のリストを取得する

サイトのURLとリスト名が分かっている場合は次のように指定することも可能です。

1. まず目的のサイトを取得する
2. リスト名を指定してリストを取得する

リストを新規に作成する

createList操作がサポートされており、リストの新規作成が可能です。ただし、現時点ではupdateList がサポートされていないためリスト名の変更などは対応していません。

例) 「このサイトに"図書の貸出台帳"という名前のリストを作成してください」

列の操作

列の操作としては listListColumn と deleteListColumn がサポートされています。つまり既存の列の一覧および削除ができます。createListColumn やgetListColumn やupdateListColumnがサポートされていないため、列の新規追加、特定の列情報の取得や更新はできません。

ちなみに、公式ドキュメントには createListItem は掲載されているのですが、実際に追加したツールの操作一覧には表示されておらず、列の新規作成を依頼しても、誤ってリストアイテムを作成しようとします。今後、サポートされるといいですね。

さて、リストの列の取得は可能です。一覧を取得してみましょう。

例) 「このリストの列を一覧にしてください」

---

Tips

決まったリストを操作するのに毎回サイトのURLやリスト名を指定するのは面倒です。このように特定のリストに対して繰り返し処理を行う場合は、指示に最初からサイトのURLとリスト名を指定しておくと便利です。

使用するURLはダブルクォーテーションで囲み、末尾には/を追加しないようにしましょう。末尾にスラッシュをうっかり追加してしまうだけで正しく回答してくれなくなります。

---

アイテムの新規追加、更新、削除

アイテムの新規追加、更新、削除がサポートされています。

• createListItem…新規追加
• updateListItem…更新
• deleteListItem…削除

例えば、次のような依頼をすることで新規にアイテムを追加できます。

例)「リストの列を確認したうえで、次のアイテムを追加してください。
タイトル: データ分析の基礎
貸出日: 2025-12-18
返却期限: 2026-01-08
状態: 貸出中
備考: 演習問題付き」

特定の列の値を変更したい場合は次のように指示できます。

例) 「次の書籍名の貸出者をそれぞれ更新してください。
-プロジェクト マネージメント入門: 佐藤 花子
-データ分析の基礎: 鈴木 太郎
- クラウドサービス 活用ガイド: 高橋 正樹」

ここまではシステム管理者っぽく操作をしてきましたが、エージェントがあれこれ推論してくれるため、もっとフランクにやり取りすることもできます。たとえば、次のようなやり取りです。

例) 「これから3日間借りられそうな本はありますか? 」

これに対して利用可能な書籍をリストアップして回答してくれます。

そのまま貸し出しを依頼することもできます。この場合、エージェントが先回りして特に指示しなくても、貸出日や返却期限、貸出者なども更新してくれます。
※返却日を空にするところまではしてくれませんでしたが。

リスト操作に不足する機能をどう補うか考える

ここまで見てきたように SharePoint Lists MCPではリストに対して、かなりのことが自然な会話のやり取りで操作できます。ただし、不足する機能があれば、適宜、リストの「ルール」を使うことも検討する必要があります。今回は貸し出し管理が題材でしたが、例えば、返却されたら貸出日と返却予定日を空にするようにルールを作成しておくと、対応がスムーズです。もちろん、これをAIエージェントの指示に書くことも可能ですが、ルールのほうがより確実です。

現時点ではまだサポートされる機能が十分でないところもあります。必要があれば、Power Automate などを使って機能を補うことも考慮する必要があります。

まとめ

ここまで、SharePoint Lists MCP の機能について詳しく説明してきました。これまで、リスト操作はフィルターや検索くらいしかできませんでした。それが、自然な会話形式であれこれやり取りできるのは画期的で、驚きました。

ただ、欲を言えばリストの更新、列の追加、列の変更がサポートされるようになるといいのになと思います。例えば、図書の貸し出し管理をしたいので、リストと列を提案してほしいという。この時に、日本人が引っ掛かりやすい表示名と内部名の問題も、Copilot に考案してもらい、それをそのままリスト化できるといいんですけどね。将来に期待しましょう。

ぜひ、ご自身でもいろいろと試してみてください! なかなか楽しいですよ。

今年、最後のご挨拶

さて、2025年も残すところあと3日です。本年のブログはこの記事をもって終わりとします。

今年一年を簡単に振り返ってみると、初の試みとして SharePoint の勉強会コミュニティを立ち上げました。またメインの講師業としては、8月から Copilot Studio の入門者向け研修コースの開発をはじめ、11月に次の研修コースのリリースしました。

【オフィスアイ株式会社】Microsoft 365 Copilot ユーザーのためのCopilot Studioで始めるAIエージェント開発入門

新コースのリリース以降は、このブログでも生成AIおよび Copilot に関する情報を記事に書き始めましたが、来年も引き続きSharePoint が中心となりますが情報発信を続けていく所存でおりますので、皆様どうぞご期待ください。勉強会も不定期ですが来年もまた開催します。

そうそう、Microsoft 365 Copilot の中核を担っているのは SharePoint だといっても過言ではありませんし、今後ますます重要になりますから。

---

🗻🐍では、皆様、よい年をお迎えくださいませ🐎🎍

---

Microsoft の SharePoint ショーケースとして「メタデータとナレッジ エージェントとが Microsoft 365 Copilot の応答精度をいかに高めるか」に関する記事が公開されています。ここでは主要な点について考察を交えながら解説します。

SharePoint Showcase: How Metadata and the Knowledge Agent Elevate Microsoft 365 Copilot Responses | Microsoft Community Hub

メタデータの重要性

Microsoft は2025年11月から SharePoint ナレッジエージェントだけでなく Microsoft 365 Copilot にもメタデータを理解・活用できる機能を追加します。つまり、Microsoft 365 Copilot Chat などでファイルやフォルダー、ライブラリ参照時するときに、メタデータを含めた文脈でAIが推論できるようになるということです。

メタデータはファイル本文以外の次のような情報のこと言います。

• ファイル名
• ファイルの拡張子
• ファイルの作成者・更新者
• ファイルの作成微・更新日
• ドキュメント ライブラリ内の列の値

ここでの注目点はドキュメント ライブラリ内に追加する任意の列の値も生成AI(microsoft 365 Copilot や SharePoint ナレッジエージェント)が利用できるようなったということです。

SharePoint の場合は、ファイルの仕分け方はファイルの要件ごとにライブラリを複数に分け、ライブラリ内で共通する列を追加することです。そのうえで必要があればさらにフォルダーで物理的に仕分けていくという流れです。ここがファイルサーバー的な発想でのバイアスに縛られていると、ついライブラリ自体はフォルダーと表現されないのでルートフォルダー的なとらえ方をしてしまい、単一のライブラリ内に異なる種類・性質のファイルをフォルダーで仕訳けていくという使い方をしてしまいがちです。しかし、そもそも SharePoint での考え方はサイトやライブラリという粒度でまずは情報を仕分け、フォルダーにあまり依存せずにりようできるようになっています。

SharePoint エージェントによるメタデータ管理機能の強化

さて、現在、SharePoint ナレッジエージェント(プレビュー)ではライブラリ内のファイルをもとに列を提案し、Autofillまで設定できる仕組みとして「ライブラリの整理」という機能がありますが、従来からさらにメタデータ管理を強化していこうとしているわけです。

SharePoint が取り組んできたこれまでのメタデータ管理の経緯

SharePoint でメタデータ管理というと、最近急にそんなことを言い出したように感じる方もいらっしゃるようですが、メタデータは SharePoint Server 2007から利用できるものであり、この機能強化はその後も継続しています。急に出てきた機能ではありませんし、そもそも SharePoint の根幹機能の一つはドキュメント管理システムです。世の中のドキュメント管理システムは、メタデータを使ってナレッジ管理をしていく製品がほとんどであり、ずいぶん昔からメタデータ管理に取り組んでいるのです。決して付け焼刃的なものではなく、長年にわたり Microsoft も試行錯誤してきた経緯があります。メタデータ管理で最も厄介なのが、だれが妥当なタグ付けをしていくのかということです。ドキュメントアップロードと同時に関連付けたCSVファイルから属性情報を付加するような機能を持つ製品もあります。要は、人が手動で設定していくというのが基本です。ただ、昨今のように組織が抱えるコンテンツ量が膨大になると、もはや人海戦術的なアプローチだけでは不十分であり、そこにきて AIによってメタデータを付加していこうという流れが生まれるのは必然的なことです。ただ、Microsoft が開発してきたAI機能はたとえば、SharePoint Syntex などでのモデル生成機能などがありましたが、定型的な請求書フォームなどのデータはある程度は対応できたものの、非定型な(非構造化)契約書などのフォーマットの場合、モデル作成するためのメタデータ抽出の学習はなかなか骨の折れる作業であり、しかも英語のみが対応している状況が続き、日本語対応はできないままでした。ですが、ここに生成AIの登場です。生成AIの場合は、非定型的なデータ(非構造化データ)から文脈を読み取るのが得意であり、言語の壁も比較的簡単にクリアしてきています。SharePoint ナレッジエージェントが持つ「ドキュメントの整理」機能で列を自動生成し、かつ値もAIにより本文から抽出してくれますが、日本語でも動作します。つまり、自動的にメタデータを抽出して適切に設定することができるようになったわけです。

ファイルの数が少なければ、フォルダーの階層構造で仕訳けていくのが比較的容易ですが、コンテンツ量が膨大になっていくと階層は複雑化し、かつ分類も複数のフォルダー分類にまたがる可能性があるものもでてくる。そうなると、どの階層をたどればよいかが判別しにくい。しかも、ファイルを探すのに、手がかりはフォルダー構造とファイル名頼みで、人は「暗記」に頼るしかなくなる。それでも覚えきれず、フォルダーなどのショートカットを作成して、決まった場所を使い続けていくことになります。ユーザーがアクセスする範囲は局所的になってしまう。ファイルサーバーだと検索なども十分にできませんし、しかもバージョン管理機能がないので似たファイル名でバックアップを山ほど作成して、どれが正規版かわからない。適切に削除もされないので、古い情報もたまっていくばかり。日の目を見ないコンテンツもあるでしょうし、似たようなファイルが複数作成されているかもしれない。組織のナレッジがうまく蓄積・整理・共有できないという状況になってしまいます。

組織に蓄積されているコンテンツは本来は、各従業員が蓄積してきたノウハウや知恵・知識の宝の山です。これを生かしてよりよい仕事の仕方ができるよう工夫する糧になるはずで、ひいては人材を大切に育成することにもつながっていくはず。

こうした情報を埋もれさせず、捨てるべきは捨て、秘匿するものは秘匿するという仕組みを作ってくために必要な情報の一つがメタデータです。ようはファイルにタグ付けを必要な数だけ行えばファイルの格納場所に依存せずに、いろいろな切り口で情報を見つけることができるようになる。このようにまずは組織が抱えるコンテンツを把握できるような見通し確保できないと、組織の宝となるナレッジを十分に利用できません。ちなみに、SharePointは最初のバージョンから検索エンジンを持っており、蓄積+検索を視野に入れています。ファイルサーバーに不足している「大量コンテンツをいかに再利用しやすくするのか」という点にフォーカスを当てて、製品が進化してきています。

検索がうまくいかないという声をX.comでも時々目にしますが、まったくヒットしないということはないはずで、たぶん、検索範囲というものがあることを知らないだけではないかと思います。その点は以前の記事で取り上げているのでよかったらどうぞ。

SharePoint Technical Notes : SharePointの検索は検索を開始する場所によって検索範囲が異なる

メタデータによりMicrosoft 365 Copilot による組織内のデータを高精度で取得できる

さて、冒頭でも述べましたが2025年9月には SharePoint ナレッジエージェントはライブラリの列をメタデータとして利用できる機能がロールアウトされました。2025年11月には、さらに Microsoft 365 Copilot にも拡大されるということです。

メタデータのある SharePoint コンテンツをグラウンディングするエージェントは、メタデータがあることで、本文だけでなく、タグや分類、業務的背景も含めて、推論できるようになるのでより精度の高い回答が導けます。これはMicrosoft エコシステム内で構築されたAIだからこそ実現できる独自の強みと言えます。

LLMs は確率論的である。これをメタデータを組み合わせて決定論的なものに変容させる

そもそも、LLMというものは性質上、確率論的です。LLMsが生成するものは、データのパターンに基づくものにすぎません。

しかし、法務や財務、エンジニアリングやヘルスケアなどの特定の産業では決定論的な回答が求められます。つまり、生成AIから得られる回答は常に一定である必要があるわけです。常に同じ条件なら同じ答えが返ってくる。さらに言えば事実に基づいて再現性があり、曖昧さや揺らぎがないことを求められるわけです。

しかし、AIを完全に決定論的に追及していくことは、LLMの持ち味である創造性や微妙なニュアンスが犠牲になることにつながりる。となれば、解決策の一つは、AIが安全に動作できるような決定論的な環境を整えることです。

SharePoint のコンテンツに対してメタデータによって情報を付け加えることでAIの創造性をしっかりと維持したまま情報の境界線を明確にできる。メタデータは “アンカー(錨)” のような役割を果たし、Copilot やエージェントが創造性を保ちつつ、信頼性の高いビジネス向けの回答を提供する一助となります。

LLMs は本質は常に確率論的ですが、構造化されメタデータが豊富な環境では、ビジネス上のニーズに応じて、AIはよりはるかに高い精度での応答が可能になるのです。

実際に原文の記事では、メタデータとして列を追加している場合と追加していない場合とでCopilotの解答の精度の違いを実験しています。メタデータの有無によりかなり結果が変わってきます。

フォルダー構造と「複数のライブラリ+メタデータ」

従来通りファイルサーバーと同様にフォルダー構造を使うほうが良いのか、メタデータを使うほうが良いのかという議論は、よく話題に上がります。私としては、これまでもこのブログ、拙筆の書籍、弊社の研修、コミュニティ勉強会などでも一貫してメタデータを組み合わせることの重要性は説明してきています。

ただ、このようにメタデータの重要性を説明すると「愛さんは、フォルダーは嫌いなんでしょう?」と声をかけられることがあります。これは単に個人的な好みで好きとか嫌いという話ではなく、いかに業務を合理化するかという話にすぎません。どうしても新しい概念が登場すると大抵の人は「とっつきにくさ」があるため、あまり考えずに今まで慣れている「フォルダー」作成をしがちなです。そのためフォルダーを作らなくても済むように一度よく考えてみて欲しい、という啓蒙的な観点でフォルダーはなるべく持たせないようにしましょうと言っているだけなのです。

いくつか現場を拝見する際に、業務の内容によっては従来通りフォルダー構造にして "場所" で格納場所を覚えてそこから必要な情報を掘り起こしていく方が向いているケースももちろんあります。こうしたケースでは、コンテンツを格納するスピード感が優先され、整理整頓する時間が十分に取れないことがよくあります。それでも、精度が多少低くともある程度は生成AIが情報を検索してくれるでしょうから、人の手で探すよりは Microsoft 365 Copilot の有償版をうまく活用するのが吉と出ると思います。

ただ、多くの人が「探す」ことに時間を費やすことが多い、手順書や手続き、仕様書、社内規程、法定保存文書(契約書、見積書、請求書など)、教材などは、探す時間を短縮しかつより正確な情報を取得できるようメタデータを活用できるのが望ましいと思っています。

適材適所でうまく使い分け、業務によっては従来通りのフォルダー構造が良ければそれを使えばいいし、それでも「探す時間」がかかることが業務効率の低下につながっているようなケースではサイトやライブラリの分け方を再考して、メタデータを活用する方向で舵を切りたいところです。

機密情報保護とコンテンツのライフサイクル

最後に付け加えておくのが、機密情報保護とコンテンツのライフサイクル管理です。

Copilot が組織の重要情報をもとに不用意に回答を作成しないようにMicrosoft 365 ではファイル単位で「秘密度ラベル」というのもを付加できます。この秘密度ラベルもファイルに対するメタデータの一種です。ラベルの設定によってはファイルを暗号化でき、社外にデータが持ち出されても正規のユーザーでないとファイルを開けないようにできます。また、機密情報が含まれているメールを外部に共有できないようにするといったことも可能です。

ライブラリ単位で既定の秘密度ラベルを設定しておくことも可能で、新規に格納したファイルは既定で常にライブラリに指定した秘密度ラベルが自動適用される。そのため、このライブラリは機密情報を格納する場所にしよう! というように決めておけます。フォルダーではなくライブラリ単位であることに注意してください。

またこの秘密度ラベルは SharePointサイトに適用することも可能です。ラベルによっては共有リンクのオプションを自動的に変更したり、コンテンツのダウンロードを禁止するような設定が可能です。

また、コンテンツのライフサイクル管理は重要です。ようは、寿命を決めてしかるべきタイミングできちんとコンテンツを削除するという話です。ファイルサーバーだけでは、これが適切にはできなかったのですが、SharePointではこうしたライフサイクル管理が可能です。一定期間は削除できないとか、期限が来たら削除できるようになる、もしくは自動的に削除する、Power Automate のフローで削除の判断をするなどできます。

こうした機密情報保護やコンテンツのライフサイクル管理は SharePoint 単独ではなく Microsoft 365 に含まれる Microsoft Purview と共に管理していくことになります。こうした管理を組み合わせれば、SharePoint + Purview で電子帳簿保存法にもしっかりと対応できます。

さらに、Microsoft 365 Copilot 有償ライセンスを持つ組織であれば、SharePoint サイトのガバナンス管理機能が強化されます。サイトのライフサイクル管理も可能で、使わなくなったサイトは一定期間サイト管理者から応答がなければ、読み取り専用に変えるとか、アーカイブしてストレージコストを抑えるといったことも可能です。

こうした一連の管理タスクなども踏まえて Microsoft 365 Copilto を利活用を推進できるのが望ましいといえます。

弊社で用意しているオリジナル研修

弊社では、こうしたMicrosoft 365 および Microsoft 365 Copilot の利活用から運用管理を考えた研修コンテンツのラインナップを取り揃えています。

• Microsoft 365 - SharePoint サイト管理基礎
• Microsoft 365 のドキュメント管理と検索
• Microsoft 365 Copilot ユーザーのためのCopilot Studioで始めるAIエージェント開発入門
• Microsoft Purview コンプライアンス入門～Microsoft 365 ファイルおよびメールに対する機密情報保護と情報ガバナンス～
• Microsoft 365 SharePoint の構成と管理 ～Microsoft 365 Copilot 対応～

お問い合わせや研修のお申込みは次のリンク先からお願いいたします。

• オフィスアイ株式会社-問い合わせフォーム

Copilot Studio にはエージェント フローという機能が用意されています。ベースは Power Automate で作成されているので基本的には Power Automate と似ているのですが、高度な承認フローが使えるなど機能面でも異なる点がいろいろとあります。

ですが、そもそも Power Automateがすでにあるのに類似するフロー作成ツールとしてエージェント フローが登場することになったのか? という疑問がわきます。これには経緯があります。

これまで Power Automate の Premium コネクターを使う場合は基本的にはそのフローを使うユーザーごとに Premium ライセンスが必要でした。が、Copilot Studio のエージェントには Premium コネクターの利用権が含まれているため、追加で Pwoer Automate Premium のライセンスを必ずしも購入する必要はないわけです。

特に Microsoft 365 Copilot 有償版ライセンスを持つユーザーは一般的な業務利用の場合はフェアユース規制が設けられており、基本的には追加料金なくこうしたコネクターも使えます。ただエージェント フローの中でも一部の機能はフェアユースにはなっておらず、Copilot クレジットや AI Builder のを消費するものもあり、ライセンス体系は少々複雑です。

詳しくは Microsoftの資料で確認してください。

Copilot クレジット制ライセンス | Microsoft Learn

Human in the Loop: Multistage approval (多段階承認)

さてこのエージェントフロー内で注目したいのが、「Human in the loop」というコネクターです。

現在、Power Automate にある承認機能は、従来は「承認」コネクターと呼ばれていたのが、今年に入ってから急に「Standard Approval」コネクターという名称に変わりました。つまり、Power Automate で提供される承認機能は標準的なものであり、より高度な承認機能はエージェント フローの Human in the loop というコネクターが持つよ、ということです。

Human in the loop とは、生成AIで用いられる概念であり、「完全な自動化ではなく人間の判断や介入を意図的に組み込む設計思想のこと」を指します。つまり、今回の話では承認にAIによるものと人によるものがくわわるというニュアンスですね。

このコネクター自体まだプレビューですが、ここに含まれるアクションの一つが「Run a multistage approval(preview)」です。要は多段階承認の仕組みですね。

このアクションでは次の3つの要素を利用できます。

• 手動での承認ステージ
• AI承認ステージ
• 条件または条件による承認

AI ステージは興味深く、人が判断するだけでなく、AIによる自動承認が可能になるというこのが画期的なところです。ちなみに、AI承認ステージはプロンプトを使って承認を判定するのですが、Copilot クレジットを必ず消費するので注意してください。

さて、このAI承認ステージなどの仕組みですが、まだプレビューというともあり、使い方についてあまり詳しい情報がありません。

基本的には次の公式情報を手掛かりに探ることになります。

• エージェント フローでのマルチステージおよび AI 承認 - Microsoft Copilot Studio | Microsoft Learn
• Multistage and AI approvals in agent flows - Microsoft Copilot Studio | Microsoft Learn (英語版)

ということで、いろいろと承認を試したのですが、今のところいろいろと"クセ" があるようなので、試行錯誤したところを箇条書きでまとめておきますね。

自分も試してみようとする方の参考になれば。ただし、あくまでも 2025年10月26日ごろに試した話でプレビューですし状況は変わるでしょうから、あくまで備忘録です。

1. 条件ステージの分岐先が未設定で Bad Gateway エラー

条件ステージで True または False の分岐先ステージが設定されていない場合、フローが停止し Bad Gateway エラーになります。UI上で「承認で終了」などが選択できるように見えても、実際には AI ステージまたは手動ステージを明示的に接続する必要があります。ただ、Microsoft Learn を読むと分岐でも承認判断ができるはずなので、現時点の不具合なのかもしれません。

2. 条件ステージは最初に配置できない

Copilot Studioでは、条件ステージをフローの最初に配置することはできません。金額によって AI か手動かを分岐したい場合は、AI ステージで判定を行う設計にする必要があります。

3. AI ステージの 'Rejected' 出力がフロー結果に確定される

先にAI ステージで 'Rejected' と出力すると、後続に手動ステージがあって、そこで "Approved" にしても最終結果が 'Rejected' になるようです。これは仕様に近いのですが、実質的にはバグ的にも思います。最終的に人が判断した内容で上書きしたいですからね。

今のところ、仕方がないので、AIステージでは判断できないため、最終的な人の判断を優先するようにしたければ、あえで AI ステージでエラーを出すようにしてエラー時の進み先のステージを手動承認ステージにしておくと、承認ステータスが決まらずに進められるため最終的な人の判断が優先されます。

4. 手動ステージで承認・却下ボタンが押せない

AI ステージで次ステージを明示すると、手動ステージが表示されても操作できないことがあります。「続行」設定にすることで、手動ステージが有効になります。

5. AI ステージの変数は必ずテキスト型で渡す

AI ステージに数値型や Boolean 型の変数を渡すと、暗黙的な型変換は行われず Bad Gateway エラーになります。必ず string() などで明示的にテキスト型に変換して渡す必要があります。

6. 手動ステージの後の分岐は明示できない

手動ステージでは承認・却下後の分岐先を明示的に指定することはできません。次のステージが存在すれば、自動的に続行されると考える必要があります。

7. 英語表記の重要性

Teams の承認アプリでは、日本語の文字列が文字化けすることがあるため、承認タスクのタイトルや説明文、AI ステージの出力は英語で記述するのが安全です。そもそもプレビューですし、英語前提でょうから変数名なども英語の方が無難なようです。

日本語で変数名を指定すると、一度作成した変数名が消えてくれなくて、どんどん増えていったりして、仕方がないのでいったん Multistage approval のアクションを削除して作り直したりしました。

と、とりあえず、覚えている範囲でのメモを共有しておきます。これを読んだだけだとわからないと思いますが、実際に構成してみるといくつかは参考になるのでは? 

最後にコース宣伝!

2025年11月より Copilot Studio の入門コースを弊社で開催を始めます。生成AIの基本から、応用利用まで深く学べる2日になっているので、よかったらご参加ください。

そもそもこのコース用のデモを作っていてハマっていたんですよ。。。

【オフィスアイ株式会社】Microsoft 365 Copilot ユーザーのためのCopilot Studioで始めるAIエージェント開発入門

先日の Microsoft Build 2024 で SharePoint サイト内の複数のファイルなどからカスタム Copilot を素早く作成できるようになることが発表されました。

これから紹介する機能が一通り利用できるようになるのは 2024年の夏ごろになるということで、現在、プライベートプレビューです。

📌プライベート プレビューのエントリー
⇒ https://aka.ms/TryCopilotsSharePoint

SharePoint をベースとした Copilot 登場の背景

SharePoint は多くのコンテンツが蓄積され続けています。コンテンツのリポジトリが増え続ける中、より正確な情報に基づいて回答を得たいと思ったときにどうすればよいのか。また知識をほかの人と共有するにはどうしたらよいか悩むところです。

これまでは何か仕事を行うために必要な情報を自らかき集めてくる必要がありました。ですが、AI の力を借りて素早く必要な情報を集め、私たちは自分の行うべき仕事に専念できるようになる。そんな未来を描きつつ、新たに登場するのが数クリックで「 SharePoint からのカスタム Copilot の作成」できる機能です。作成した Copilot は、Teams チャットやメールなどで他のユーザーと共有できます。

この記事について

Microsoft Build 2024のオープニング Keynote で Jeff Taper 氏がこのことについて話しています(1:07頃から)。

この記事では、Keynote と TechCommunityで発表された内容および Microsoft Build 2024 BKR144 の内容を日本語でまとめていきます。

各SharePointサイト (OneDrive含む) で利用できるビルトインの Copilot

SharePoint のサイト所有者はそのサイトのコンテンツを範囲とするビルトインの Copilotを有効化できるようになります。

このビルトインの Copilot はサイト内の情報をもとに回答を生成してくれます。たとえば、マーケティングチームが新しい製品のラウンチに向けて資料などをSharePoint サイトに格納しているとします。そこには、デモビデオ、スペックシート、プレゼンテーション資料、プレスリリースなどが含まれています。このサイトの Copilot は「この製品のラウンチ日は最終決定したの?」などと尋ねるとこうしたサイト内の情報をもとに信頼性の高い回答を返してくれるのです。

ちなみに、Copilot は回答する際にそのサイトのコンテンツ内から情報を得ますが、ユーザーのアクセス権限に基づいて取得するため、ユーザーにとってはその人が閲覧可能な情報から回答が生成されるということです。

Copilot の既定のスコープはそのサイトです。ですが、この範囲を広げたいということもあるでしょう。サイトの所有者として Copilot をカスタマイズできます。 Microsoft Copilot Studio または Visual Studio で作成した Copilot をサイトの既定の Copilot として指定することもできます。

つまり、ビルトインの Copilot と独自にカスタマイズする Copilot の2つがある。この2つの違いについては Build の BRK144セッションの資料がわかりやすくまとまっています。

Integrating your bots and Copilot experiences natively into SharePoint and Viva | BRK144

日本語にして少し加筆すると次のようになるでしょう。

harePoint サイトごとのCopilot	自分で選択したコンテンツから作成した カスタム Copilot
サイト用のビルトイン Copilot	サイト用にカスタム Copilot を作成したもの
サイトのコンテンツが基盤で、すぐに利用を開始できる	自分で選択したコンテンツが基盤
カスタマイズ可能	左と同じ
Teams やメールなどを経由して Copilot を他のメンバーと共有できる。そのため同僚は同じナレッジベースを使って仕事ができ、リアルタイムにコラボレーションできる	左と同じ
自分のコンテンツのアクセス許可レベルはそのままで応答できる (各ユーザーにとって閲覧権限がなければ、その情報は使われない)	左と同じ
サイトの所有者は自サイトのCopilotを制御できる。	-

誰でも数クリックで SharePoint から Copilot (拡張) を作成できる

サイトの所有者やサイトの管理者だけでなく、サイトの編集権限を持つ人（サイトメンバーなど）であれば、数クリックでサイトの Copilot を作成できます。SharePoint からカスタムのCopilot を作成できるので、特定のプロジェクトなどの特定の目的の専用 Copilotを手軽に用意できます。

次のスクリーンショットは Microsoft Build 2024のオープニング Keynote 内でのデモ画面です。配達ドローンのラウンチを行うサイトで、ライブラリ内の複数のファイルを選択してコマンドバーから「Create a copilot」をクリックしています。

次の画面ではこれらのファイルが含まれているフォルダー名と同じ Final Maetrials Copilot という名前で Copilotが生成されるのがわかります。

ということで、本当に数クリックで Copilot ができてしまいます。この画面からすぐに使う場合は「Try it」、編集する場合は「Edit」をクリックします。

このように作成することで SharePoint サイトの右側でカスタム Copilot がすぐに利用できます。

ちなみに、この Copilot のソースファイルも画面上のドキュメント ライブラリに作成されていることがわかります(ReleCloud_Delivery_Doron.copilot)。

なお、 Copilot の右上の … をクリックすることで既存の Copilot の共有、編集が行えるだけでなく、新しいチャットを開始したり、チャット履歴を確認することもできます。

Copilot の設定

SharePoint に Copilot が展開されると、サイトの設定メニューに「Site Copilot Settings (サイトのコパイロットの設定)」が新たに追加されます。

この設定からこのサイト上でユーザーが利用できる Copilot を選択できます。既定の Copilot を指定するのではなく、複数利用可能な Copilot がある場合に、そのうちのどれをユーザーが利用できるかを決めるということです。

実際には次の図のように Copilot の切り替えができるようになるようです。

Copilot の共有

作成した Copilot は共有できるのですが、結局のところCopilot の共有とは、ライブラリ内に作成された*.copilot であり、このファイルの共有リンクを作成することですね。SharePoint ではおなじみの共有方法です。

たとえば、この共有リンクは Microsoft Teams のチャットに貼り付けられます。追加するとメンバーもこの Copilot と対話できるようになります。

アクセス権はどうなる?

ビルトインの Copilot と同様に、カスタム Copilot は既存の SharePoint のアクセス許可レベルに従います。カスタム Copilot のファイル自体の共有は共有リンクで行いますが、コンテンツに関してはすでにアクセス権限を持っている必要があり過剰共有の問題はおきません。

Microsoft Copilot Studio との統合

Copilot for Microsoft 365 ユーザーは Copilot Studio の使用権を持っています。ですから、組織内での利用に関しては追加料金がかかることなく利用できます。

次の画面はMicrosoftが発行しているライセンスガイドの一部です(2024年4月のP19)。単体の Microsoft Copilot Studio のサブスクリプションと比較すると機能は限定的ですが社内利用に関してはほとんどの機能が利用できることがわかります。

基盤としてSharePoint 以外に拡張する必要がある場合は、 Copilot Studio からデータソースを追加できます (※現在、1,000種類以上のデータコネクターがある)。Copilot for Microsoft 365 であれば、Copilot Stduio 内でプレミアムコネクターやカスタムコネクターも利用できます。

既存の Copilot を Copilot Studio で編集するには Copilot の編集画面でSource タブまたは Behavior タブをクリックすると下部に表示される「Add advanced customiztion in Copilot Studio」をクリックします。

画面上部に次のようなメッセージが表示されます。

Your SharePoint copilot extension is ready for editing. Once you choose Create, any additional edits to this copilot can only be made in Copilot Studio.

つまり、SharePoint copilot 拡張を編集する準備ができたので右上の「Create」ボタンが押せます。ただし、一度この Create ボタンを押せば、今後は Copilot Studio 内からしか編集できないようになるということです。

Copilot Studio では編集にフル機能を使えます。

たとえば、ナレッジベースを追加する場合はDataverse データベースやパブリック Web サイトなども追加できます。これらは Copliot 用のコネクターを通じて行えます。

※ Copilot コネクターのプレビューへのアクセスは2024年6月より開始されます。

またアクションも追加できるようになっており、特定のコネクターのアクションの追加や新規フローの作成などもできるようになっています。一通りの設定が終わったあとは[Publish]ボタンから発行するだけです。

Microsoft 365 Copilot アプリでの利用

Microsoft 365 の Copilot アプリでもカスタム Copilot として利用できます。この場合は、自分で作ったカスタム Copilot や自分に共有されている Copilot は、自分が最近使った Copilot 拡張の一つとして表示されます。

最後に

ここまで、これから利用できるようになる SharePoint のサイトをベースにした Copilot やカスタム Copilot 作成について説明してきました。

SharePoint サイト内に共有されている情報を生成AIを使って有効に利活用できるようになります。従来のファイルサーバーでは格納される情報が増大するほど埋もれがちでしたが、Copilot と SharePoint の組み合わせで、SharePoint 内でユーザーが作成した様々なデータだけでなく外部のデータも組み合わせて有効活用できるというのは画期的だと思います。

いよいよ、新しいナレッジマネージメントの姿へと進んでいくという側面としてもとらえられそうです。