MCP文書管理システムとは？既存検索の活用とRAG構築、どちらを選ぶか

結論から先にまとめます。

MCP文書管理システムを作る前に、既存の「文書の所在」「検索の仕組み」「権限管理」の3つがどこまで揃っているかを確認します。この3つが揃っていない状態でMCPサーバーだけを開発しても、AIが参照できる文書の質は上がりません。
「MCP対応」という言葉は接続口（AIと外部データをつなぐ仕組み）を指すもので、検索エンジンや権限管理そのものではありません。既製の文書管理システムでもMCP対応をうたう製品が増えていますが、自社の権限設計まで自動で行うわけではない点に注意します。
開発の実装パターンは、既存の全文検索APIをMCP経由で公開する構成と、検索の仕組み自体をRAG等で新規に作る構成の2つに大きく分かれ、どちらを選ぶかで工数が大きく変わります。

ただし、この2つの実装パターンには見落としやすい注意点が1つあります。後半の「権限をどう引き継ぐか」の章で説明します。

MCPで文書管理を作るとは、具体的に何をすることか？

AIアプリが社内文書を検索・参照できるように、既存のデータと検索の仕組みをMCPサーバー経由で公開する実装のことです。

MCPの公式説明にあるとおり、MCP（Model Context Protocol）はAIアプリと外部の機能・データをつなぐための標準規格です。文書管理の文脈では、次の3つの要素を組み合わせて実装します。

要素	役割	自社にすでにあるか
データ層	文書の実体（ファイルサーバー、SaaS、DB）	既存の文書管理システムやストレージがあるか
検索層	質問に対して関連文書を探す仕組み	全文検索、メタデータ検索、意味検索（RAG）のいずれか
権限層	誰がどの文書を見られるかの制御	部署・案件・文書単位のアクセス権限表があるか

MCPサーバーはこの3層の「窓口」を作る役割であり、検索層・権限層そのものを作るわけではありません。既存の検索の仕組みが弱い状態でMCPサーバーだけを用意しても、AIは「探せるが精度が低い」状態になります。

検索の仕組みがすでにある場合、何を作ればよいか？

既存の全文検索APIやSaaSの検索機能があれば、その検索結果をMCP経由でAIに渡す接続部分だけを開発します。

社内のファイルサーバーやSaaS（Box、SharePoint、Google Workspace等）に、すでに検索機能が備わっている場合、ゼロから検索エンジンを作る必要はありません。この場合の実装は次のような構成になります。

既存の検索APIを呼び出すMCPツールを実装する
検索結果に、利用者の権限で見えない文書が含まれていないかをMCPサーバー側でも二重に確認する
検索結果から本文を取得する際、AIに渡すメタデータ（作成者、更新日、版番号）を整理する

この構成の利点は、検索精度を既存システムに委ねられるため、開発工数を接続部分に絞れることです。一方で、既存の検索が「ファイル名検索」程度しか対応していない場合、AIへの回答精度も検索精度に引きずられて低くなります。

検索の仕組み自体が弱い場合、何を検討すべきか？

全文検索やメタデータ検索では質問の意図に合う文書を探せない場合、RAG（検索拡張生成）などの意味検索の仕組みを別途構築する必要があります。

たとえば「A社との契約更新について、去年何か特殊な取り決めをしていなかったか」という曖昧な質問に、ファイル名やキーワードの完全一致検索では答えられません。文書の内容を意味的に検索する仕組み（ベクトル検索を使ったRAG等）が必要になります。

RAGを新規に構築する場合、次の工程が追加で発生します。

工程	内容	工数が変わる条件
文書の分割・埋め込み	文書を検索用の単位に分割し、ベクトル化する	文書量、フォーマットの種類（PDF・Word・スキャン画像等）
ベクトルDBの構築	埋め込みを保存・検索する基盤を用意する	更新頻度、検索速度の要件
権限を検索結果に反映	ベクトル検索の結果にも利用者の権限フィルタをかける	権限の粒度（部署単位か文書単位か）
回答生成の設計	検索結果を根拠にAIが回答を作る際の指示設計	誤情報を避けるための出典表示の要否

MCPサーバー単体の実装よりも、この検索基盤の構築のほうが工数の大部分を占めるケースが多く、「MCP対応」という言葉だけで見積もりを比較すると、検索基盤の有無で総額が大きく変わる点を見落としやすくなります。

権限をどう引き継ぐか？（冒頭の注意点の回収）

冒頭で触れた注意点はここです。検索の仕組みをどちらの構成で作るにせよ、既存の閲覧権限をAI経由の検索結果にも正しく引き継ぐ設計が最も見落とされやすい部分です。

架空の例で考えます。営業担当が「A社の契約更新条件」をAIに質問したとします。営業担当が閲覧権限を持つ契約書だけを検索対象にし、他部署が管理する契約書は検索結果にもタイトルにも出てこないようにする必要があります。ここで見落としやすい点が3つあります。

検索結果からの漏れ: 権限のない文書が検索結果の候補一覧にタイトルだけでも表示されると、文書の存在自体が伝わってしまいます。
キャッシュからの漏れ: 過去に生成した回答やキャッシュに、権限変更前の情報が残っていないか確認します。異動や退職で権限が変わった利用者が、古いキャッシュ経由で情報を見られる状態は避けます。
索引の反映漏れ: 文書を廃止・非公開にした際、検索用の索引（全文検索インデックスやベクトルDB）からも同じタイミングで削除されるか確認します。元の文書管理システムでは非公開でも、検索索引にだけ古い内容が残るケースがあります。

これらは「検索できるかどうか」のテストだけでは見つかりません。権限を変更した直後に、変更前の状態で検索・キャッシュ・索引のいずれかに古い情報が残っていないかを個別に確認するテスト項目として設計時点で組み込む必要があります。

書き込み操作は、検索とは別の判断が必要

参照（検索）の次の段階として、契約更新日や担当者情報をAI経由で更新したいという要望が出てくることがあります。ここは検索の可否とは切り離して判断してください。

誰の承認を経て更新を確定するか
更新前後の内容を誰が確認できるか（操作履歴）
誤った更新をした場合に、どう元に戻すか

「検索して内容を把握できたのだから、更新も自動化してよい」という判断は範囲の拡大であり、業務上の責任者との合意なしに進めるべきではありません。

MCP文書管理の実装を、既存検索APIの活用とRAG新規構築の2パターンに分岐させ、権限層の引き継ぎ確認を共通の必須工程として位置づけた判断フロー図

継続運用で決めておくこと

稼働後は、次を誰が担当するかを事前に決めておくと運用が止まりにくくなります。

文書の追加・削除に合わせた検索索引の更新
利用者の異動・退職に合わせた権限の見直し
接続先API・検索エンジンの仕様変更への追従
認証情報（APIキー等）の更新と管理

MCPサーバーが一時的に停止した場合にも、元の文書管理システムへ直接アクセスできる導線を残しておくと、問い合わせ窓口を「AI経由の不具合」と「元システムの不具合」で切り分けやすくなります。

工数と費用を見積もる

工数は、既存検索APIを使う構成か、RAGを新規構築する構成かで大きく変わります。以下は見積もりの際に確認する項目です。

確認項目	既存検索API活用の場合	RAG新規構築の場合
検索基盤の開発	不要（接続のみ）	埋め込み・ベクトルDB構築が必要
権限設計	既存の権限をMCP層でも確認	ベクトル検索結果にも権限フィルタを設計
データ量の影響	検索速度は既存システム依存	文書量に応じて埋め込み・インデックス工数が増加
保守	既存システムの仕様変更に追従	ベクトルDB・埋め込みモデルの保守が追加

当社の作業単価は 1時間11,000円（税込） です。要件定義・契約後のすり合わせ・開発・テスト・バッファの時間を積み上げて見積もります。バッファは未確定事項ごとに理由を示し、クラウド・API等の実費と保守契約は別に確認します。初回相談・認識合わせの無料モック・お見積もりは無料です。見積もりの進め方と相談シートで整理できます。

固定の総額相場をここで示すことはしません。検索基盤の有無と文書量によって工数が変わるため、御社の状況を伺ったうえで積み上げます。

この記事で持ち帰れることは次の3点です。

MCPは接続口であり、検索の精度・権限管理そのものは別途確認・設計が必要なこと
既存の検索APIを使う構成とRAGを新規構築する構成で、工数の掛かり方が大きく異なること
権限の引き継ぎは「検索結果」「キャッシュ」「索引」の3箇所で個別に確認が必要なこと

まずは、自社の文書検索で「ファイル名検索で足りているか」「内容を意味的に探したい質問が多いか」を書き出してみてください。それだけで、既存検索API活用かRAG新規構築か、どちらの構成に近いかの見当がつきます。

よくある質問

Q. MCPを使えばRAGは不要になりますか？

役割が異なります。MCPは接続の仕組み、RAGは検索の仕組みです。検索精度を上げたい場合はRAG等の検索設計が必要で、MCPはその検索結果をAIに渡す窓口として組み合わせて使います。

Q. 文書を外部のAIサービスに送らずに使う構成は可能ですか？

構成によります。保存先、検索処理、回答生成をどこで行うか、社内で完結させるか外部APIを使うかで送信範囲が変わります。自社ホスト型のモデルを使う場合も、ログの保存先は別途確認してください。

Q. 権限管理が複雑な場合、開発期間はどのくらい変わりますか？

部署単位の権限より、文書単位・案件単位で細かく権限を分けている場合の方が、権限フィルタの設計・テスト工数が増えます。既存の権限表がどこまで整理されているかによっても変わるため、要件定義の段階で確認します。

Q. 楽々Document Plusのような既製のMCP対応文書管理システムと、個別開発はどう使い分けますか？

既製のMCP対応文書管理システムに乗り換えられる場合は、まずその選択肢を検討するのが現実的です。既存の基幹システムや独自の権限体系と密接に連携している、既製システムに移行できない事情がある場合に、個別開発を検討する段階に入ります。

自社の状況を整理して相談する

まず、文書の正本、既存の検索の仕組み（全文検索か意味検索が必要か）、部署・案件別の閲覧範囲を書き出してください。この記事に合う検討シートとAI相談用プロンプトで、未確認の項目を残したまま整理できます。シートを完成させる前でも、お気軽にご相談いただけます。

AI駆動開発全体の費用の考え方はAI駆動開発とは？英語での呼び方・費用・納期を発注者向けに解説、委託先のセキュリティ確認はAI駆動開発を外注する前に確認すべきセキュリティ・権限管理チェックリスト、社内でAIエージェントを運用する際の権限設計はAIエージェントのセキュリティ設計もあわせてご確認ください。