はじめに
以前以下の記事を書いたのですが、その際、個人的には「もうちょっとかな?」という感じでした。
最近改めて触ってみて、以前よりいい感じに動きましたので、改めて記事を書きます。
以前作ったエージェントの検証
以下のようなリストを基にエージェントを作成しています。
指示文は以下のような感じです。せっかくなので、モデルは GPT-5.2 Chat にしています。
ツールでは以下だけをオンにしています。
以前した質問をしてみます。
普通にいい感じに回答されています。
多少文言を変えても回答返ってきます。
時々うまくいかないこともありますが、概ねいい感じです。
再作成してみる
以前に作成したもののため、再度別のリストを作成して動作確認してみます。
Question 列にインデックスを作成しています。
こちらもいい感じです。そのため、SharePoint リストをナレッジにするなど、リストと連携をする場合は、こちらを試してみるのがよいと思います。
どんな仕組み?
なぜ以前よりいい感じに動作するようになったかは分かりませんが (以前触った際はリリースされたばかりだったので不安定だったのかも?)、こうなってくると、仕組が気になりますよね。いい感じに回答が来ているようだったので少し喜んでいましたが、調べてみた結果、個人的にはあまり万歳で喜べるような動作ではなかったです。
まず、気になったのは以下の箇所です。どうやら、filter をして情報を取得しているようです。ただ、「セキュリティカードをなくした」という入力をしていますが、「社員証」でフィルターしていますね。こちらは、エージェント (LLM) が 検索に効きやすい代表語として「社員証」を選んで contains に入れたと考えられます。理論上は、そのため、多少文言が違っても情報が返ってくることが予想されます。
なお、試してみた感じ、必ずしも filter されるわけではなく (後述の通り、filter 失敗している)、以下のようにかなり大量のデータを取得した上で最終的に回答しているケースもありました。試した限りでは、100 件 (データ行の件数) 全部取得して、そちらをベースに回答しているようです。
リクエスト内容は以下の形式でした。
https://graph.microsoft.com/v1.0/.../lists(...)/items(fields())
利用している API はこちらですかね。
つまり、Microsoft SharePoint Lists MCP では、セマンティックインデックスを基にナレッジを検索しているわけではなく、あくまで、上記 API を自然言語から呼べるようにしており、また、フィルターする際のキーワードは必要に応じて、エージェント (LLM) が 検索結果としてヒットしやすい代表語に置きかえていると考えられます。ただし、上記 API の問題なのか、SharePoint Lists MCP の問題なのかは分かりませんが (恐らく前者)、filter では上手く情報が見つからず、「Item not found」となってしまう。
※自動で生成される以下の構文が上手く動作しないようです。リストの列は、fields 配下にあるため、正しい構文には見えますが、expand と合わせるとうまく動作しないのでしょうか。。もしかしたら上手く動作するケースもあるかもしれませんが、少し安定感にかける印象です
/items?$expand=fields
&$filter=contains(fields/Question,'勤怠')
その後、filter なしで大量に取得した情報を基に強引に回答している感じで、仕組的にはあまり効率は良くないと思います。
以前試した際、以下のような結果が返ってきたのもそのためと考えられます。
そのため、ある程度シンプルな FAQ かつ数百件以内くらいであれば概ね動作すると考えますが、複雑かつ数千、数万以上の大量のナレッジの場合は、処理効率が非常に悪く、個人的にはあまり推奨できないかもしれません。やはり、インデックス自体が進化して、必要な情報だけが検索結果としてヒットして返されるようになった方が理想的と思います。
※仮に filter が機能しても、あくまでキーワードでフィルターしているだけのため、大量のナレッジ検索にあまり向いていないと考えます
以下、リファレンスです。フィルターされない場合、データ量が増え応答に時間を要す可能性があるため、filter や select (取得対象列の絞り込み) も自分で指定できるようですが、
以下は、select で列を指定した場合の指示文の例です。
ユーザーの質問に対して「Microsoft SharePoint Lists MCP」だけを使い、次のサイトID・リストIDのリストから回答してください。他の情報源は使わないでください。
- SiteID: *****
- ListID: *****
必須(Selectの指定):
- listListItems 実行時は、取得列を Question と Answer のみに限定するため、Select を必ず次の値にする:
fields/Question,fields/Answer
やること:
1) リストの「Question」列を検索し、質問内容に近い行を見つける(必要なら短いキーワードで検索してよい)。
2) 見つかったら、その行の「Answer」列の内容だけを回答する。
3) 見つからない場合は「情報がありませんでした」と回答する。
一応、select を入れると別のエラーになりました。。
一旦、元に戻して、最後に、まとめてテストしてみました。
大体回答が来ています。処理効率は良くないと思いますが、100 件くらいのシンプルなリストであれば、ある程度は動作しそうです。
まとめ
今回は、Microsoft SharePoint Lists MCP が進化しているように見えたため、再度検証、深堀りしてみました。依然として、市民開発をしている組織からすると、SharePoint リストにナレッジが溜まっておりそちらを活用したいというニーズが強いため、引き続きウォッチしていこうと思います。
























