検索・ドキュメント・分析MCPの導入前レビュー: 情報源、鮮度、送信先

検索、ドキュメント取得、分析/BIに近いMCPは、コード実行やクラウド管理ほど強い権限に見えないことがある。それでも、AIエージェントの回答根拠、社内知識、分析結果に近い位置に入るため、導入前レビューでは「何を実行できるか」だけでなく「何を根拠として信じるか」も確認対象になる。

主要な観測

1. 20,629件のRegistryスナップショットのうち、検索・ドキュメント・分析MCPは計530件、全体の2.6%。
2. 内訳は検索/知識385件、ドキュメント84件、分析/BI61件。
3. リスクの中心は実行権限だけではなく、回答根拠、検索語、社内文脈、分析結果の流れ。
4. 導入前レビューの記録対象は、情報源の正本、更新日、引用/ログ、外部送信先、読み取り範囲。

データ

観測値	数値
記事日付	2026-06-30
Registryスナップショット	20,629件
Registry同期日	2026-06-06T01:17:38.963Z
集計確認日	2026-06-30
検索/知識カテゴリ	385件
ドキュメントカテゴリ	84件
分析/BIカテゴリ	61件
検索・ドキュメント・分析MCPの合計	530件、全体の2.6%

なぜ導入前レビューが必要か

検索/知識系MCPは、外部検索、社内ナレッジ、ベクトル検索、ドキュメント検索に接続する可能性がある。ドキュメント系MCPは、仕様、手順、APIリファレンス、運用手順をエージェントの文脈に入れる。分析/BI系MCPは、数値や集計結果を取得し、判断材料として使われる情報に近い。

問題は、読み取り中心なら低リスクとは限らない点にある。古い情報、不確かな引用、権限外の文書、外部検索サービスへ送られる検索語や文脈は、シェル実行とは別の形で導入リスクになる。

導入前レビュー項目

情報源の正本

公式ドキュメント、社内wiki、チケット、データウェアハウス、外部検索結果が混ざる場合、回答の根拠として使ってよい情報源と、補助情報に留める情報源を分ける。特に、外部検索結果や個人管理のドキュメントが正本のように扱われる設計は注意対象になる。

鮮度と古い情報の表示

検索対象やドキュメントの更新日、同期日、古いページの表示ルールが必要になる。MCPが古い仕様や古い分析結果を自然な文章に変換すると、情報の古さが画面上で見えにくい。

引用と監査ログ

回答の根拠をリンク、ドキュメントID、クエリ、ダッシュボード、ログで追える状態が望ましい。根拠を追えない検索・分析MCPでは、誤回答が起きた時の原因調査と訂正が難しくなる。

外部送信先

検索語、ユーザー文脈、取得した文書、分析クエリ、結果の要約がどこへ送られるかが導入判断に影響する。外部検索や外部分析サービスを使う場合、入力に機密情報が混ざらない境界設計が必要になる。

読み取り範囲

読み取り範囲は、全社、部門、プロジェクト、コードベース、データセット、ダッシュボード、ドキュメント集のどこまでか。読み取り専用でも、範囲が広すぎれば権限外の知識をAIエージェントへ渡す経路になる。

記録フォーマット

記録欄	記録する値
情報源の正本	公式ドキュメント、社内wiki、DWH、外部検索などの区分
更新日/同期日	最終更新日、最終同期日、古い情報の表示ルール
引用/ログ	リンク、文書ID、クエリ、ダッシュボード、監査ログ
外部送信先	検索語、文脈、取得データ、分析結果の送信先
読み取り範囲	組織、部門、プロジェクト、データセット、ドキュメント集単位の境界

この記録があると、MCPが何を実行できるかだけでなく、AIエージェントが何を根拠として信じるかをレビューしやすい。

限界

1. 530件はPublic Registryの集計カテゴリであり、すべてが危険という意味ではない。
2. カテゴリ名だけでは、個別MCPの権限、情報源、送信先、更新頻度は分からない。
3. 数値はスナップショットであり、Registry更新により変わる。
4. 根拠は公開可能な集計のみで、内部のスコアリングや検出ルールは含まない。

まとめ

検索・ドキュメント・分析MCPでは、実行権限よりも回答根拠やデータの流れが導入リスクになる場合がある。導入前レビューでは、情報源の正本、鮮度、引用/ログ、外部送信先、読み取り範囲を同じ記録に残すことが重要になる。