SharePoint上のドキュメントを検索して取得する用のMCPサーバーを自作しました
SharePoint上のドキュメントを検索して取得する用のMCPサーバーを自作しました。公開しているので、使ってください。
この記事はわざわざ自作した経緯とどう作ったかについて説明します。
使い方は記事に書きませんのでReadMeを参照してください。
はじめに - なぜわざわざ自作したのか
SharePoint上のファイルを(Copilot以外の)生成AIから使用したいという話がありました。
そんなの既存のツールやMCPサーバーがあるだろうと思っていくつか試したのですが、いまいちやりたいことにマッチするものが見つからなかったので、探すのが面倒くさくなって自作しました。
やりたかったことは、次のようなものです。
- SharePoint上にアップロードしたファイルをナレッジとして使いたい
- SharePointに対する認証は、MCPサーバー内で完結させたい
認証に関して
まず、SharePointに接続するための認証方法を調べたのですが、想定よりも複雑でした。
「SharePointアプリ」か「EntraID」か
アプリ(MCPサーバーを含む)がSharePointに接続する為の認証手段は、大きく2つあります。
- SharePoint アプリ専用のアクセスを許可する方法
- EntraID (旧AzureAD) で認証する方法
ここで、1の方法は、2026年4月2日に廃止されるので、今から1を使う理由はないでしょう。
必然的に2のEntraIDで考えます。
「委任されたアクセス許可」か「アプリケーションの許可」か
EntraIDを使って認証するときの方式は、更に2つに分けられます。
a. エンドユーザーがログインして、その権限でSharePointにアクセスする(委任されたアクセス許可)
b. アプリケーション自体にSharePointのアクセス権限を付与する(アプリケーションの許可)
認可制御を考えるとaが望ましいのですが、aの方式はユーザーがMCPサーバーを使う前に毎回ログイン処理が必要となるます。その処理はMCPクライアント側でしないといけないので、MCPサーバーを使う側のハードルが上がってしまいます。
そのため、今回はMCPサーバー側で処理が完結するbの方式で対応します。
(どこかでaの方式にも対応できるようにしたいです。)
「シークレットアクセスキー」か「証明書」か
「アプリケーションの許可」で認証する場合、アプリケーションを認証する方法として、
ア. クライアントシークレット
イ. 証明書
の2つが上げられます。
正直なところ何も問題がなければ「とりあえずクライアントシークレットを使いました。」とするのですが、シークレットを使ってSharePointにアクセスしようとするとエラーになりました。
Unsupported app only token.
どうやら証明書でないとSharePointにアクセスできないようです。詳細は、こちらの記事が参考になりました。
ということで、証明書での認証を使ったMCPサーバーを作ることにしました。
採用した認証方式まとめ
認証方式の選択に関して、フローチャートにするとこんな感じです。(Claudeに整理してもらいました)
SharePointのAPIに関して
今回MCPサーバーを作るのにあたり、SharePointのREST APIを調べたのですが、正直ドキュメントを見ても全体像がよく分かりませんでした。
もうちょっと分かりやすいドキュメントを用意していただきたいです。
ただ、1つ言えることとして、たとえば「サイト上のすべてのリストを取得するlists
」などのAPIをそのままMCPサーバー化すると、生成AIが使い方に混乱してまともな精度が全くでませんでした。
今回欲しかった機能は「SharePoint上にアップロードしたファイルをナレッジとして使いたい」ですので、その目的外の機能は全て排除して、「アップロードしたファイルを検索する機能」と「検索したファイルをダウンロードする機能」に絞りました。
そのため、このMCPサーバーが持つツールは2つだけです。
- sharepoint_docs_search
- ドキュメントの検索 ( SharePointのAPI
/_api/search/query
を呼び出す )
- ドキュメントの検索 ( SharePointのAPI
- sharepoint_docs_download
- ファイルのダウンロード ( SharePointのAPI
/_api/web/getfilebyserverrelativeurl
を呼び出す )
- ファイルのダウンロード ( SharePointのAPI
なお、この戦略は、Anthropicの「Writing effective tools for agents — with agents」で推奨されている考え方を採用しているつもりです。
Too many tools or overlapping tools can also distract agents from pursuing efficient strategies. Careful, selective planning of the tools you build (or don’t build) can really pay off.
(訳) ツールが多すぎたり重複したりすると、エージェントが効率的な戦略を追求する妨げになることもあります。構築するツール(あるいは構築しないツール)を慎重に選択して計画することは、大きな成果をもたらす可能性があります。
また、ツールが増えると、エージェントが使うツールに迷って効率が下がる問題だけでなく、コンテキストが増えることでLLMのトークン数も増えて、すなわち課金額が増えます。
ですので、このMCPサーバーの持つツールは必要最低限に絞りました。
ただ、まぁ、流石に2つは少ない気もするので、今後必要に応じて追加機能は考えたいです。
先程のAnthropicの記事のも以下のように書いてありますし。
We recommend building a few thoughtful tools targeting specific high-impact workflows, which match your evaluation tasks and scaling up from there.
(訳) 特定のインパクトの大きいワークフローを対象とした、評価タスクに合致するいくつかの思慮深いツールを構築し、そこからスケールアップすることをお勧めします。
MCPサーバーをどう作ったか
MCPサーバーの作り方ですが、基本的には要件や使用技術を決めたら、Claude Codeにコードを書いてもらった感じです。
流れとしては、
- Geminiと会話しながら要件を決めて概要設計をする
- SharePointの認証方式の調査
- SharePointのAPIの調査
- MCPサーバーの大雑把な設計
- 開発環境の初期セットアップ(ほぼ手動)
-
uv
とかruff
とかty
とかの初期設定 - 既存プロジェクトからClaude.mdの使えそうな部分を流用
-
fastmcp
の導入
-
- 1で調べた内容や参考になりそうなレポジトリをClaude Codeに投げつけて、コードを書いてもらう
- 実際に動かして試す
と言った感じです。
1でGeminiを使っているのは、Deep Researchが優秀なのと、ここもClaudeでやると使えるトークンがすぐに枯渇するからです。
2に関しては、初期セットアップをAIに任せると急によく分からない技術を使いだしたりするので、最低限の土台は手動で作りました。
3は土台ができて参考文献が集まったら、あとは丸投げで作ってもらいました。
作っていてビックリしたこと
今回の開発でいくつか驚いたことがあります。
- GeminiにMicrosoft系のドキュメントを調べさせると、高確率でハルシネーションを起こす。
- SharePoint関連の調査は誤情報を連発して来て、正直かなり困りました。
- Claude CodeにMicrosoft公式SDKの使用するように指示したら、「使いにくいから」という理由で拒否された。
- そのため、このMCPサーバーではSharePointのRestAPIを直呼びしています。
もしかしたら、GeminiやClaudeはMicrosoftのことを好きではないのかもしれません。ライバルですものね。(オブラートに包もうとして包みきれなかった言い回し)
最後に
そんな感じで、SharePoint上のドキュメントを検索して取得する用のMCPサーバーを自作しました。もし同様の需要があれば使ってください。
この記事を書いていて思ったのですが、MCPというプロトコルは生成AIと外部システムを接続する汎用的な存在であるのに対して、MCPサーバーは特定のシステムや特定のユースケースに特化したツールとして作るべきものではないかと思いました。
初期に公開されたMCPサーバーの多くはAPIの延長線上で作られていて、1つのシステムに対して何でもできる汎用的なものが多いように思います。しかし、ユースケースを絞って必要な機能だけを持つMCPサーバーの方が、生成AIにとってより使いやすいツールになるのではないかと思います。

NCDC株式会社( ncdc.co.jp/ )のエンジニアチームです。 募集中のエンジニアのポジションや、採用している技術スタックの紹介などはこちら( github.com/ncdcdev/recruitment )をご覧ください! ※エンジニア以外も記事を投稿することがあります
Discussion