SharePoint/OneDrive のドキュメントを RAG ではなく MCP で触る case|メタデータ更新の監査
目次 クリックで開く
Microsoft 365(SharePoint / OneDrive)に蓄積された膨大なドキュメントをAIに活用させる際、これまでは「RAG(検索拡張生成)」による情報の抽出・回答が主流でした。しかし、実務においては「情報の読み取り」だけでは不十分なケースが多々あります。例えば、数千件の契約書ファイルに対して「契約終了日」をメタデータとして自動付与したり、請求書のステータスをAIが判断して更新したりといった、「書き込み・操作」を伴うアクションが求められています。
こうしたニーズに応える最新のプロトコルが、Anthropicによって提唱されたMCP(Model Context Protocol)です。本記事では、RAGではなくMCPを用いてSharePoint/OneDriveのドキュメントを直接操作し、メタデータの自動更新とその監査(オーディット)を安全に行うための実務的なアーキテクチャを詳説します。
RAGとMCPの比較:ドキュメント操作における決定的な違い


📥 関連ガイドをダウンロード
まず、従来型のRAGと、新たな潮流であるMCPの違いを明確にしておきましょう。多くの企業が直面している「AIがファイルを編集できない」という壁を突破する鍵がここにあります。
| 比較項目 | RAG (Retrieval-Augmented Generation) | MCP (Model Context Protocol) |
|---|---|---|
| 主な目的 | 外部知識を参照した精度の高い回答生成 | 外部システム(SaaS/DB/ファイル)の操作・連携 |
| 操作権限 | 原則として「読み取り」のみ | 「読み取り」+「書き込み・削除・移動」等 |
| データの鮮度 | ベクトルDBへのインデックス同期に依存(遅延あり) | API経由でリアルタイムなデータ取得・操作 |
| 主な用途 | 社内規定の検索、Q&A対応、要約 | メタデータ付与、ファイル整理、ワークフロー実行 |
| SharePoint連携 | Microsoft 365 Copilot / Azure AI Search連携 | MCP Server経由でのMicrosoft Graph API操作 |
RAGは「知る」ためのツールですが、MCPは「行う」ためのツールです。特にSharePointのリスト列やドキュメントライブラリのカスタムプロパティを更新する場合、RAGの仕組みだけでは実現できず、Microsoft Graph APIを叩くための「Tool」としての実装が必要になります。これを標準化されたプロトコルで提供するのがMCPの役割です。
このようなデータ操作の自動化は、バックオフィス業務のDXにおいて極めて重要です。例えば、経理部門での請求書処理の自動化については、楽楽精算×freee会計の自動化事例に見られるような、ツール間のデータ連携思想と共通する部分が多くあります。
MCPによるSharePoint連携のアーキテクチャ
MCPを利用してSharePointやOneDriveを操作する際、システム構成は「MCP Client」「MCP Server」「Microsoft Graph API」の3つのレイヤーで構成されます。
1. MCP Client(ホスト)
AIモデル(Claude 3.5 Sonnet等)を搭載したインターフェースです。Claude DesktopやCursor、あるいは自作のAIエージェントアプリがこれに該当します。ユーザーの指示(例:「このフォルダ内の全てのPDFから日付を抽出して、SharePointのメタデータに書き込んで」)を解釈し、適切なMCP Serverの「Tool」を呼び出します。
2. MCP Server
Microsoft Graph APIとの仲介役となるプログラムです。ローカル環境またはサーバー上で動作し、MCP Clientからの要求を受けて、実際にSharePointへの読み書きを実行します。このサーバー内で、Entra ID(旧Azure AD)の認証情報を保持し、安全にAPIリクエストを投げます。
3. Microsoft Graph API
Microsoft 365のリソースにアクセスするための標準ゲートウェイです。MCP Serverは、このAPIの /sites や /drives エンドポイントを叩くことで、ドキュメントの操作を実現します。
実践:SharePoint/OneDrive用MCP Serverの構築手順
実際にMCPを用いてドキュメント操作を行うための、環境構築ステップを解説します。
STEP 1:Microsoft Entra IDでのアプリ登録
まず、Microsoft Graph APIにアクセスするための資格情報を取得します。Microsoft Entra 管理センター(https://entra.microsoft.com/)にアクセスし、以下の設定を行います。
- アプリの登録: 新規登録を行い、「アプリケーション ID(クライアント ID)」と「ディレクトリ ID(テナント ID)」を控えます。
- 証明書とシークレット: 新しいクライアント シークレットを発行します。
- API のアクセス許可: 以下の権限(委任されたアクセス許可またはアプリケーションの許可)を追加し、管理者の同意を与えます。
Files.ReadWrite.All(全てのドライブの読み書き)Sites.ReadWrite.All(全てのサイトのメタデータ編集に必要)User.Read(サインインユーザーの識別)
STEP 2:MCP Serverの実装(サンプルロジック)
MCP ServerはNode.jsやPythonで記述できます。例えば、SharePointのドキュメントにカスタムメタデータを付与するツールを定義する場合、以下のようなエンドポイントを実装します。
// メタデータ更新ツールの定義イメージ
const updateFileMetadata = async (siteId, itemId, metadata) => {
const url = https://graph.microsoft.com/v1.0/sites/${siteId}/drive/items/${itemId}/listitem/fields;
const response = await fetch(url, {
method: 'PATCH',
headers: {
'Authorization': Bearer ${accessToken},
'Content-Type': 'application/json'
},
body: JSON.stringify(metadata)
});
return response.json();
};
このように、MCP Server側に「ファイルの中身を読み取る機能」と「メタデータを書き換える機能」をToolとして登録しておくことで、AIが自律的にこれらを組み合わせて実行できるようになります。
社内のインフラ環境によっては、こうしたSaaS間の連携を整理し、コストを最適化することも重要です。詳細はSaaSコストとオンプレ負債を断つアーキテクチャを参考にしてください。
メタデータ更新の監査(オーディット)とセキュリティ
AIによる自動更新を導入する際、コンプライアンス上最も重要になるのが「誰が、いつ、何を書き換えたか」の追跡性です。
Microsoft Purview 監査ログの活用
SharePoint/OneDrive上での全ての操作は、既定でMicrosoft 365の監査ログに記録されます。MCP Server経由で操作が行われた場合、ログには以下の情報が残ります。
- 操作されたアイテム: ファイル名、パス
- 操作の種類:
FileModified(ファイル更新)やListItemUpdated(リスト項目の更新) - ユーザーID:
- 委任されたアクセス権を使用している場合:操作を実行した「人間」のアカウント。
- アプリケーションの許可(Daemon)を使用している場合:登録した「アプリ名」。
重要:実務上の注意点
内部統制上は「誰の指示でAIが動いたか」を明確にするため、可能な限り委任されたアクセス許可(Delegated Permissions)を利用することを推奨します。これにより、監査ログ上で「AIアプリを介したユーザーAによる操作」として記録され、責任の所在が明確になります。
更新の妥当性チェック
AIによるメタデータの誤入力を防ぐため、MCP Server側にバリデーションロジックを組み込むことも有効です。例えば、「日付型の列にはYYYY/MM/DD形式以外を受け付けない」といった制限をAPIリクエスト前に設けることで、データの不整合を未然に防げます。
実装時によくあるエラーと対処法
実務でMCP Serverを運用する際に遭遇しやすいトラブルとその解決策をまとめました。
- 403 Forbidden (Access Denied):
- 原因:Entra IDのアプリ登録で、SharePointの特定のサイトコレクションに対するアクセス権限が与えられていない。
- 対処:Graph APIの
Sites.Selected権限を使い、特定のサイトに対してのみPermissionsエンドポイントで権限を付与する「最小権限の原則」を適用してください。
- Invalid Metadata Field:
- 原因:SharePointの内部名(Internal Name)と表示名(Display Name)の混同。
- 対処:APIでメタデータを更新する際は、必ず「内部名」を指定する必要があります。ブラウザで列設定のURLを確認し、
Field=以降に表示される文字列を確認してください。
- Throttling (429 Too Many Requests):
- 原因:大量のファイルに対して一括でMCPを介した更新指示を出した。
- 対処:MCP Server側にリトライ処理(指数バックオフ)を実装するか、バッチ処理(JSON Batching)を利用してリクエスト回数を削減してください。
こうしたID管理やアクセス権の制御は、退職者のアカウント削除漏れを防ぐためのID統制とも深く関連します。Entra ID・Oktaを活用した自動化アーキテクチャの記事も併せて参照し、セキュアな基盤を構築してください。
まとめ:セキュアなAI自動化基盤の構築に向けて
MCPを活用することで、SharePointやOneDriveは単なるドキュメントの「置き場所」から、AIが自律的に整理・加工を行う「アクティブなデータ基盤」へと進化します。RAGで情報を引き出すだけでなく、MCPでメタデータを適切に管理することで、将来的な検索精度向上やワークフローの自動化がより強固なものになります。
導入にあたっては、まず小規模なドキュメントライブラリでMCP Serverの挙動と監査ログの出力を確認し、徐々に適用範囲を広げていくアプローチが現実的です。Microsoft Graph APIの強力な操作権限をAIに委ねるからこそ、厳格な認証認可とログ監視を設計の軸に据えてください。
最新の技術仕様やAPIの制限値については、常にMicrosoft Graph 公式ドキュメントおよびMCP公式ドキュメントを参照し、最適な実装を選択しましょう。
ご相談・お問い合わせ
本記事の内容を自社の状況に当てはめたい場合や、導入・運用の設計を一緒に整理したい場合は、当社までお気軽にご相談ください。担当より折り返しご連絡いたします。
3. **追記するHTMLだけ**(通常は `
4. 次の1行を**そのまま**出力:
AI×データ統合 無料相談
AI・データ統合・システムの最適な組み合わせを、企業ごとに設計・構築します。「何から始めるべきか分からない」という段階からでも、まずはお気軽にご相談ください。