MCP（Model Context Protocol）概要と導入ガイド

用語定義

このセクションでは、本稿で使う主要用語を平易に定義します。用語を先に揃えることで、その後の設計指針や実装例の意味を一貫させます。読み手の前提知識に依らず参照できるようにまとめます。

コンテキスト

コンテキストはモデルに供給する外部情報の断片で、クエリへの根拠や参照材料として使います。

• 例：文書の抜粋、FAQの項目、コードスニペットなど。
• 主な属性：id、snippet（テキスト）、score（検索スコア）、metadata（doc_id, version, author, timestamp など）。

プロヴィナンス

プロヴィナンスは情報の出所と取得経路を示すメタデータで、説明性と監査性を確保します。

• 必須表現例：source（システム名）、url（参照先）、retrieved_at（取得時刻）、doc_id、chunk_id、offset。
• 利用目的：ユーザーに根拠を示す、アクセス制御・削除依頼に対応する、監査ログと突合する。

チャンク

チャンクは長文を扱いやすく分割した単位です。粒度はユースケースに依存します。

• よく使われる粒度：段落単位、セクション単位、固定トークン長。
• 留意点：チャンクサイズとトークン消費がプロンプト設計に直結するため、上限を設ける。

コネクタ / ソース

コネクタは外部データソース（SaaS、ファイルストア、DB 等）を取り込み用に変換するコンポーネントです。

• 機能：差分同期、アイデンティティ・アクセス管理、メタデータ抽出、チャンク化。
• 接続パターン：イベント駆動（Webhook/CDC）か定期バッチ（スケジューラ）を選択。

MCPとは：目的・背景・基本概念

Model Context Protocol（MCP）は、LLMやアプリに対して外部ナレッジを一貫した形式で供給するための設計思想とAPI集合です。横断検索や根拠提示付き応答などのユースケースで有効です。現状はコミュニティ提案と参照実装が中心で、国際的な標準（IETF/W3C 等）という形の公式仕様は存在しません（参考参照は文末にまとめます）。

主要APIの役割（getContext等の概念）

ここではMCPで典型的に使われるAPIの役割を整理します。API設計は組織のポリシーや性能要件に合わせて最小限化・拡張してください。

• getContext
• 概要：クエリまたは入力に関連するコンテキスト断片を返します。
• 要件例：Authorization ヘッダ（Bearer トークン）、query（必須）、max_items（任意）、filters（任意）、correlation_id（任意）。

• 利用例：LLM呼び出し前に関連断片を収集して、根拠付き応答を生成する。

• listSources / registerConnector

• 概要：利用可能なデータソースの列挙とコネクタ登録を行います。主に管理者向けの操作です。

• health / status

• 概要：コネクタ状態、インデックス鮮度、同期状況などを返します。運用監視に必須です。

getContext の安全な呼び出し例（認証を本文に含めない）

以下は認証情報を本文に含めない最小例です。資格情報は必ずシークレット管理から取得し、短寿命トークンを用いる運用を推奨します。

レスポンス（概念例）ではプロヴィナンスを含め、フィールド単位でのマスキングやアクセス制御を適用します。

最小APIスキーマと互換性レイヤー

ここでは運用で互換性を保つための最小必須スキーマ例と、既存レスポンスをMCPスキーマに変換する互換レイヤーの考え方を示します。実装は組織の要件に合わせて調整してください。

getContext の最小スキーマ（リクエスト・レスポンス）

この節は getContext の最小必須フィールドを示します。拡張は可能ですが、相互運用性を保つために必須項目は固定します。

• リクエスト（必須）
• query (string): 検索／関連付けのためのテキスト

• Authorization ヘッダ: Bearer トークン（必須）

• レスポンス（必須）

• contexts (array): 各要素は context object を持つ
• 各 context object の必須フィールド：id, source, snippet または summary, metadata.doc_id, provenance.url または provenance.id

最低限の context object スキーマ（例）

互換性レイヤー（変換マッピング）の実装例（Python）

既存の検索レスポンスをMCP準拠に変換する際は、変換マッピング層を設けます。以下は単純な変換例です（資格情報やネットワーク呼び出しは省略）。

変換層はバージョニング可能にして、クライアントごとの互換性を維持します。

アーキテクチャと処理フロー

MCPサーバーは「取り込み（Ingest）」「インデックス/検索（Index / Retrieval）」「API/ポリシー層（Context API + Policy）」で構成されます。ここでは典型構成とクエリ時の処理フローを示します。

主要コンポーネント（Ingest / Index / API+Policy）

以下の各要素は独立してスケール可能とし、責務を分離します。認証・監査・シークレット管理などは補助サービスで担います。

• コネクタ／取り込み層（Ingest）

• 各ソースを正規化しチャンク化、差分同期を行う。イベント駆動（Webhook/CDC）を推奨。

• コンテキストストア／インデックス層（Index / Retrieval）

• ベクトルDBとメタデータDBの組合せで検索・スコアリングを実行。鮮度管理とバージョン管理を持つ。

• API層（Context API + ポリシー評価）

• getContext等を公開し、認可（AuthZ）・フィールド単位のマスキング・出力フィルタを適用する。全アクセスを監査ログに記録。

クエリ時の典型処理フロー

以下は典型的なリクエスト処理の流れです。各ステップで監査・メトリクスを取ります。

1. クライアントが短寿命トークンで getContext を要求する。
2. API 層で認証（AuthN）とポリシー評価（AuthZ）を行い、アクセス可能なソース一覧を決定する。
3. Retrieval Engine（ベクトル検索）で上位候補を取得し、必要に応じてフェーズ別フィルタを適用する。
4. スニペット抽出、スコア正規化、重複除去、プロヴィナンス付与を行う。
5. 結果を返却し、リクエストID・ユーザ情報・ポリシー判定結果を監査ログに記録する。

サンプル構成（概念）

API Gateway（WAF・Rate Limit）→ 認証基盤（OAuth2 / mTLS）→ MCP API Router（ポリシーエンジン連携）→ Retrieval Engine（ベクトルDB + メタDB）→ コネクタ群（SaaS・DB・ファイル）。コネクタはVPCピアリングやプライベートエンドポイントで安全に接続します。

移行・相互運用パターンと推奨OSS／ベクトルDB選定基準

段階的な移行と適切なOSS選定で導入コストを下げられます。ここでは具体的なパターンと実務で使える選定基準、コネクタ実装例を示します。

移行パターン

各パターンはリスクや改修コストに応じて選択します。

• ラッピング（Adapter）

• 既存APIのレスポンスをMCPスキーマに変換する翻訳層を作り、クライアント改修を小さくする。

• シャドウ／デュアルライト

• 新旧システムを並走させて差分を検証後に切替する。検証期間を定義すること。

• 互換性レイヤー（翻訳層）

• クライアントごとに適用できる変換設定を用意し、段階的に移行する。

ベクトルDB／OSS選定基準

選定はスケール、機能、運用性、コストのバランスで判断します。代表的な候補と評価軸を示します。

• 評価軸（例）

• スケール（データ量・QPS）、埋め込みのサポート、メタデータフィルタリング、レイテンシ、管理負荷、マルチテナンシー、レプリケーション／バックアップ、ホスティング（マネージド vs 自己運用）、コスト。

• 候補（参考）

• FAISS：ライブラリ。大規模自己運用向け。
• Qdrant：メタデータフィルタが使いやすく、OSS＋マネージド選択肢あり。
• Milvus：スケーラブルなOSS。分散環境向け。
• Weaviate：スキーマ中心、GraphQL等統合が得意。
• Pinecone：マネージドで運用負担が低いがコスト要検討。

コネクタ実装のコード例（Python・概念）

以下は安全な資格情報取得とチャンク化、埋め込み・アップサートの流れを示す概念例です。実際はライブラリ（LangChain / LlamaIndex / Haystack 等）を利用することで開発工数を削減できます。

並行してイベント駆動（Webhook / CDC）で差分同期を行い、フル再取得は例外的に行います。資格情報はSecrets ManagerやKey Vaultで厳格に管理してください。

セキュリティ・コンプライアンスと運用（具体的指示）

セキュリティ設計は認証・認可・暗号化・監査・データレジデンシーを明確に分離して行います。以下は実務で即使える具体手順や目安です。

認証と短寿命トークン（実装方針）

認証は短寿命トークン（OAuth2 Client Credentials 等）や mTLS を標準とします。トークンを取得する基本フロー例（概念）：

トークンは短寿命（例：5～60 分）とし、Refreshを認可サーバー側で管理します。クライアントはトークンを平文でログに残してはいけません。

KMS の実装例と鍵ローテーション手順

KMS（CMEK）を用いた実装は以下手順を推奨します。ここでは概念的なステップを示します。

• 設計
• データ鍵（DEK）と鍵管理鍵（CMK）でエンベロープ暗号化を採用する。DBやオブジェクトストレージには暗号化済データと暗号化されたDEKを保存する。

• キーポリシーでキー管理者と利用者ロールを分離する。

• 鍵ローテーション手順（例）

• 新しい CMK を作成し、必要なキーポリシーを設定する。
• 新しい CMK を alias（例：alias/mcp-data-key）に結びつける。
• ストレージ上の既存データについて、再暗号化（Re-encrypt）ジョブを実行するか、読み取り時に再ラップして段階的に切替える。

• 切替が完了したら旧 CMK を削除または無効化し、関連するロギングを保管する。

• 例（AWS 想定）

• GenerateDataKey + KMS を用いてサーバー側で DEK を生成し、その DEK で実データを暗号化。DEK の ciphertext を保存。再暗号化は AWS KMS の ReEncrypt API やカスタムバッチで実行。

• ローテーション頻度（目安）

• アクセストークン/アプリシークレット: 30～90 日でローテーション検討。
• DEK/CMK: 年次または規制要件に基づく。業務要件により短縮。

データレジデンシーとネットワーク設計

データの保存場所と転送先を明確化し、法規制（地域法）に従います。実装上のポイント：

• リージョン固定：個人データや機密データは指定リージョン内に保管。クロスリージョンレプリケーションは可否を規定する。
• ネットワーク：VPC ピアリング、Private Endpoint、プライベートリンクを活用し、パブリックインターネット経由を最小化する。
• ロギング：監査ログも保存リージョンを限定し、暗号化とアクセス制御を適用する。

監査ログの設計と保持期間（具体例）

監査ログは改ざん防止と検索性を担保して保存します。推奨事項の例：

• 含める項目：timestamp, request_id, user_id, client_id, action (getContext/listSources/etc)、対象 context_id、policy_decision、client_ip、response_status、latency_ms、correlation_id。
• 保持期間（目安）：運用目的は最低 1 年、法務／会計／規制要件に応じて 3〜7 年。要件があれば WORM（S3 Object Lock 等）で保管する。
• 保全：ログは署名やハッシュチェーンで整合性検証できるようにする。SIEM 連携で検出ルールを構築する。

シークレット管理と資格情報の運用例

シークレットはシークレットマネージャ（AWS Secrets Manager / GCP Secret Manager / Azure Key Vault）で中央管理し、アクセスは最小権限で付与します。運用例：

• 資格情報は環境変数に直書きせず、実行時に取得する。
• ローテーション：DB パスワード等は自動ローテーションを設定（例：30 日）。サービスアカウントキーは短寿命トークンに置換。
• 監査：シークレットへのアクセスを監査し、アクセス頻度の異常値はアラート化する。

インシデント対応（Runbook の要点）

• 漏洩検知：大量の getContext リクエストや異常なアクセス元を検知したら即時遮断。
• 資格情報漏洩時：該当秘密をローテーションし、関係するコネクタを即時再認証、影響範囲を監査する。
• インデックス破損：スナップショットからの復旧手順を整備し、復旧後の整合性検証を自動化する。

プロヴィナンスと説明可能性（集約）

プロヴィナンスの要件を一箇所にまとめます。プロヴィナンスは重複記述を避け、一貫した最小スキーマを定義することが重要です。

プロヴィナンス最小スキーマ

ここではトレーサビリティを担保するための最小フィールドを示します。これらはプロンプト内のトークン予算を圧迫しないように要件に合わせて調整します。

• provenance.id（任意）
• provenance.source（必須）: ソース名（confluence, notion 等）
• provenance.doc_id（必須）: ソース内の識別子
• provenance.url（可能な場合）: 直接参照可能な URL
• provenance.retrieved_at（必須）: ISO8601 タイムスタンプ
• provenance.chunk_id / offsets（開始・終了オフセット）
• provenance.confidence（任意）: スニペットと検索スコアの関係を示す数値

プロヴィナンス付与のタイミングとポリシー

プロヴィナンスは取り込み時に初期付与し、検索時に最終的確認・追加情報（取得時刻、キャッシュ状況等）を付与します。ポリシー例：

• 取り込み時：元ドキュメントのID・バージョン・取得時刻を必須で保存。
• 検索時：取得タイムスタンプを更新し、キャッシュ経由か否かを記録。
• 開示制御：ユーザー権限により URL や author をマスキング可能にする。

プロンプト向けの軽量プロヴィナンス設計

LLM へ渡す際はプロヴィナンスは最小化し、詳細はユーザーが必要とする場合に参照できる形（リンクや参照ID）にします。

評価指標（KPI）・SLO と測定方法

KPI・SLO は業務要件に依存するため目安を示します。測定方法とサンプリング補足を明記し、運用での解釈基準を提供します。

KPI候補（目安）

• 精度系：precision@1、precision@k、citation accuracy（出典一致率）
• 品質系：hallucination rate（誤情報率）、ユーザー満足度（CSAT）
• 性能系：p50/p95/p99 レイテンシ（getContext／E2E）、可用性（稼働率）
• 運用系：インデックス鮮度（最終更新からの経過時間）、エラー率、コスト／クエリ

SLO設計と測定方法（具体的目安）

SLO は組織の用途に応じて設定します。以下は測定方法と目安です。

• 測定箇所：エンドツーエンド（クライアント→API→Retrieval→応答）と内部（Retrieval単体）を分けて計測する。
• サンプリング：本番は 1% 〜 5% をトレース、エラー時は 100% キャプチャ。合成プローブは 1 分間隔で代表クエリを投げる。
• 統計窓と有意性：p95 は少なくとも 5 分間のウィンドウかつ 50 件以上のサンプルで算出する。サンプル数が少ない場合は補助指標に注目する。
• 目安（参考）
• getContext（retrieval のみ、インタラクティブ用途）：p95 ≦ 250 ms（目安）
• getContext（E2E、LLM 呼び出し含む）：p95 ≦ 1500 ms（目安）
• 可用性：99.9%（業務クリティカル度により 99.95% 以上を検討）

これらはあくまで目安です。例えばコールドスタートや大規模検索、法務分野の精度重視ケースではレイテンシより正確性を優先してください。閾値設定の根拠はユーザー期待値（UX）とシステム的な許容遅延を合わせて決定します。

コスト見積もりアプローチ（概念式）

コスト想定は実データで校正が必要です。概算の算出式を示します。

1. データ準備：#ドキュメント × 平均チャンク数 × 準備工数（人時） × 単価
2. 埋め込みコスト： (総トークン数 / 1000) × 埋め込み単価
3. ストレージ／インデックスコスト：インデックスサイズ（GB） × 単価
4. ランタイムコスト：1 クエリ当たりの埋め込み/検索/LLMコスト × QPS × 稼働時間
5. 運用工数：SRE/エンジニアの月次工数 × 単価

概算例は本文中の式を用いて現実データで校正してください。

ベストプラクティス・アンチパターン・チェックリスト

成功例とよくある失敗を押さえて、パイロットから本番移行までの主要チェック項目を示します。

ベストプラクティス

• 限定スコープのパイロット（1〜2 ソース、限定ユーザー）で早期検証する。
• スキーマファーストでメタデータとプロヴィナンスを定義する（互換性レイヤーを用意）。
• 最小権限の接続を徹底し、資格情報はシークレットマネージャに保管する。
• ゴールドセットで定期評価し、ログ・トレース・SLO を早期に導入する。

よくあるアンチパターンと対策

• 何でも無差別にインデックス化して PII が混入 → 取り込みルールと PII 検出を導入する。
• プロヴィナンスを保存しない → 出典付与を必須にし、アクセス制御で表示制限する。
• 埋め込みモデルやインデックスを検証なく頻繁に変更 → バージョン管理と AB テストを行う。
• 大規模一括導入で障害切り分け不能 → 段階的ローンチとシャドウ運用を行う。

パイロット用チェックリスト（抜粋）

• スコープと成功基準（KPI と閾値）を文書化したか
• データマッピングとメタデータ整備が完了しているか
• コネクタの差分同期と再同期テストを実施したか
• PII 検出／マスキングルールを検証したか
• getContext の p95 レイテンシ計測と負荷試験を行ったか
• ゴールドセットで精度評価を行ったか

ブランド適合性と外部公開ポリシー

外部向けに公開するドキュメントと内部資料は記載内容を区別してください。外部公開時に含めて良い内容と内部限定にすべき情報の例を示します。

• 外部公開に適した内容：アーキテクチャの高レベル図、API の利用例（認証を含めない）、セキュリティ方針の概略、利用例・導入メリット。
• 内部限定とすべき内容：具体的な資格情報保管場所、内部エンドポイント、Runbook の手順、鍵ローテーションの実行履歴。
• 公開前チェック：内部でのセキュリティレビューと法務レビューを必須化すること。

参考（一次情報・関連リンク）

以下は本文で参照したり、導入時に参照すべき一次情報や代表的なOSSのリンク集です。主要な一次情報（公式ドキュメント／GitHub）を優先しています。リンク切れチェック日: 2026-05-10。

• GitHub 検索（Model Context Protocol 等の参照実装を探す際の入口）

• https://github.com/search?q=Model+Context+Protocol

• OSS／ツール（代表例）

• LangChain（ドキュメント／リポジトリ）: https://github.com/langchain-ai/langchain
• LlamaIndex（GPT Index）: https://github.com/jerryjliu/llama_index
• Deepset Haystack: https://github.com/deepset-ai/haystack
• Qdrant: https://github.com/qdrant/qdrant
• Milvus: https://github.com/milvus-io/milvus
• Weaviate: https://github.com/semi-technologies/weaviate
• Pinecone: https://www.pinecone.io/
• Airbyte（コネクタ基盤）: https://github.com/airbytehq/airbyte

• Open Policy Agent (OPA): https://github.com/open-policy-agent/opa

• KMS / クラウドドキュメント（実装参照）

• AWS KMS（概説と API）: https://docs.aws.amazon.com/kms/latest/developerguide/
• GCP KMS: https://cloud.google.com/kms

• Azure Key Vault: https://learn.microsoft.com/azure/key-vault

• 技術解説・事例（コミュニティ記事／ブログ）

• Qiita 解説（参考）: https://qiita.com/realbios/items/fea46ed799c1a7e0ffe1
• JAPAN AI による解説（参考）: https://japan-ai.geniee.co.jp/media/basic/6154/
• MCP ユースケース集（コミュニティまとめ、参考）: https://mome-n.com/posts/mcp-usecases-software-development/

参考リンクは随時更新されます。導入・検討時は各プロジェクトの公式ドキュメントとライセンスを必ず確認してください。

まとめ

要点を整理します。導入時は限定スコープでの検証と、運用上の具体対応（認可・KMS・監査ログ）を早期に整備することが成功の鍵です。

• MCP はモデルに一貫したコンテキストとプロヴィナンスを提供する考え方で、現状はコミュニティ提案・参照実装が中心です。
• アーキテクチャは取り込み／インデックス／API+ポリシーの三層を基本とし、認証・監査・シークレット管理を初期から設計してください。
• セキュリティではデータレジデンシー、KMS によるエンベロープ暗号化と鍵ローテーション、監査ログの保持方針を具体的に決めて運用します。
• KPI・SLO は業務要件依存のため目安を用い、計測方法（サンプリング・合成プローブ・トレース）と閾値設定の根拠を文書化してください。
• プロヴィナンス関連の表現と保存は一箇所に集約し、出典の提示とアクセス制御を運用で担保してください。
• 移行はラッピング／シャドウ／互換性レイヤー等を使って段階的に行い、LangChain 等のOSSや Qdrant/Milvus 等のベクトルDB を導入候補として評価してください。