AIエージェントに自社の社内ドキュメントやデータベースを参照させたいと考えたとき、どのようなアプローチを取るべきでしょうか。
これまでは、AIモデルごとに専用のAPI連携を独自に開発し、データソースとの橋渡しを行うのが一般的でした。しかし、この手法は開発コストがかさむだけでなく、AIモデルの仕様変更のたびに改修を迫られる「技術的負債」を生み出しやすいという課題が指摘されています。
このような背景から注目を集めているのが、Anthropic社がオープンソースとして提唱した標準規格「MCP(Model Context Protocol)」です。本記事では、MCPの理論的な優位性を解説するとともに、実際にMCPサーバーを構築し、Claude Desktopと連携させるまでの手順をステップ・バイ・ステップで解説します。専門家の視点から、単なる「動くコード」ではなく、セキュリティと保守性を担保したセキュアな実装手法をお伝えします。
なぜ今「MCP(Model Context Protocol)」が必要なのか:AI連携の標準化がもたらす安心感
AIエージェントの開発において、外部データ連携は避けて通れない重要なテーマです。しかし、既存の連携手法には構造的な限界が存在します。まずは、なぜMCPという新しいプロトコルが必要とされているのか、その理論的な背景から紐解いていきましょう。
独自実装の限界とセキュリティリスク
従来のAI連携は、各ツールやデータソースに対して個別のAPIクライアントを実装する「密結合」なアーキテクチャが主流でした。例えば、社内のファイルサーバー、タスク管理ツール、顧客データベースなど、それぞれ異なる認証方式やエンドポイントを持つシステムに対して、AIがアクセスするための専用の仲介プログラム(ミドルウェア)を開発する必要がありました。
このアプローチには、以下のような重大な課題が伴います。
- 保守性の低下(技術的負債の蓄積)
データソース側のAPI仕様が変更されたり、AIモデル側の関数呼び出し(Function Calling)のフォーマットが変わったりするたびに、仲介プログラムの改修が必要になります。 - セキュリティ上の脆弱性
独自実装のAPI連携では、アクセス制御やエラーハンドリングが開発者のスキルに依存しがちです。特に、AIが生成したパラメータをそのまま内部システムに渡してしまうと、意図しないデータ漏洩や破壊的な操作(インジェクション攻撃など)を引き起こすリスクが高まります。 - スケーラビリティの欠如
新しいAIモデルが登場するたびに、既存の連携システムを新しいモデルの仕様に合わせて作り直す必要があり、エコシステム全体の拡張が困難になります。
これらの課題は、システムが複雑になるほど深刻化し、エンタープライズ環境でのAI導入を阻む大きな要因となっています。
Anthropicが提唱するオープン規格のメリット
こうした独自実装の限界を打破するために登場したのが、MCP(Model Context Protocol)です。MCPは、AIモデル(クライアント)とデータソース(サーバー)の間の通信を標準化するオープン規格であり、両者を「疎結合」に保つことを目的としています。
MCPを採用することで得られる最大のメリットは以下の通りです。
- 一度の構築で複数のAIクライアントに対応できる汎用性
MCPに準拠したサーバーを一度構築すれば、Claude Desktopをはじめ、将来的にMCPをサポートするあらゆるAIエージェントや開発環境(IDEなど)から、同じデータソースにアクセスできるようになります。これにより、「N対N」の複雑な連携が「1対1」のシンプルな構造に整理されます。 - 関心事の分離による堅牢なセキュリティ
AIモデルは「何をしたいか」という意図の解釈に専念し、データへの実際のアクセスや権限管理はMCPサーバー側で厳格に制御します。これにより、AIの予測不可能な振る舞いから社内システムを保護する境界線(バウンダリ)を明確に設定できます。
標準規格に則って基盤を構築することは、将来の技術的変化に対する強力な保険となります。
チュートリアルのゴールと前提環境の確認
理論的背景を理解したところで、ここからは実践的なハンズオンに入ります。本記事では、読者が自身の環境で実際に手を動かしながらMCPの仕組みを体感できるよう、具体的な開発手順を解説します。
本記事で構築する「ローカルファイル参照サーバー」の概要
今回構築するのは、特定のローカルディレクトリ内にあるファイルを検索し、その内容を読み取る機能を持つMCPサーバーです。
完成すると、Claude Desktopのチャット画面から「プロジェクトフォルダの中にある設計書の内容を要約して」と指示するだけで、Claudeが自律的にMCPサーバーを呼び出し、指定されたファイルを読み取って回答を生成できるようになります。
このチュートリアルを通じて、以下の技術要素を習得することを目指します。
- MCP SDKを用いたサーバーの初期化と構成
- AIモデルに機能を提供する「Tool」の定義方法
- パストラバーサル攻撃を防ぐセキュアなファイルアクセス処理
- Claude DesktopへのMCPサーバーの統合
必要なツール(Node.js, Claude Desktop, MCP Inspector)
ハンズオンを進めるにあたり、以下の環境がローカルマシンに準備されていることを確認してください。
- Node.js
MCPサーバーの実装にはTypeScript/Node.jsを使用します。最新のLTS(Long Term Support)バージョンのインストールを推奨します。 - Claude Desktop
Anthropicが提供するデスクトップアプリケーションです。設定ファイルを編集することで、ローカルのMCPサーバーと連携させることができます。公式サイトから最新版をダウンロードしてインストールしてください。 - MCP Inspector
開発中のMCPサーバーをテスト・デバッグするための公式ツールです。AIクライアントを通さずに、サーバーの挙動を直接確認する際に使用します。
エディタはVisual Studio Codeなどの使い慣れたものをご用意ください。
Step 1:MCPサーバーのスケルトン作成とプロトコルの理解
それでは、実際にコードを書き始めましょう。まずはプロジェクトの土台となるスケルトン(雛形)を作成し、MCPの通信プロトコルの基本構造を理解します。
@modelcontextprotocol/sdk の導入
任意の作業ディレクトリを作成し、Node.jsプロジェクトを初期化します。
mkdir mcp-local-file-server
cd mcp-local-file-server
npm init -y
次に、MCPサーバーの構築に必要な公式SDKと、TypeScript環境のパッケージをインストールします。
# MCP公式SDKのインストール
npm install @modelcontextprotocol/sdk
# 開発用パッケージのインストール
npm install -D typescript @types/node tsx
# TypeScriptの設定ファイル生成
npx tsc --init
tsconfig.jsonが生成されたら、プロジェクトの準備は完了です。続いて、エントリーポイントとなる index.ts を作成します。
サーバーの基本構造(Resource, Tool, Promptの定義)
MCPでは、サーバーがクライアントに提供できる機能として主に「Resource」「Tool」「Prompt」の3つの概念が定義されています。
- Resource: データベースのスキーマやログファイルなど、AIに読み取らせたい静的なデータ。
- Tool: ファイルの書き込みやAPIの実行など、AIに実行させたい動的なアクション(副作用を伴う操作も含む)。
- Prompt: 再利用可能なプロンプトのテンプレート。
今回は「指定したパスのファイル内容を読み取る」という動的な操作を実装するため、Toolとして定義します。
以下は、MCPサーバーを立ち上げるための最も基本的なスケルトンコードです。
// index.ts
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import {
CallToolRequestSchema,
ListToolsRequestSchema
} from "@modelcontextprotocol/sdk/types.js";
// サーバーインスタンスの作成
const server = new Server(
{
name: "local-file-server",
version: "1.0.0",
},
{
capabilities: {
tools: {}, // Tool機能を有することを宣言
},
}
);
// サーバーの起動処理
async function main() {
// 標準入出力(stdio)を用いた通信トランスポートの設定
const transport = new StdioServerTransport();
// サーバーをトランスポートに接続
await server.connect(transport);
console.error("MCP Local File Server is running...");
}
main().catch((error) => {
console.error("Server error:", error);
process.exit(1);
});
MCPはJSON-RPCというプロトコルをベースにしており、標準入出力(stdio)またはHTTP(SSE)を介して通信を行います。ローカル環境でClaude Desktopと連携する場合は、上記のようにStdioServerTransportを使用するのが一般的です。
Step 2:実用的な「ファイル検索・読み取りツール」の実装
スケルトンが完成したら、AIが実際にファイルを読み取るための具体的なロジックを実装していきます。ここで最も重要なのは「セキュリティ」です。
ローカルディレクトリへのアクセス制限の実装
AIエージェントにローカルファイルへのアクセス権を与える場合、システム全体を自由に探索されてしまうリスク(パストラバーサル攻撃など)を考慮しなければなりません。そのため、アクセス可能なディレクトリ(ベースディレクトリ)を厳格に制限する仕組みが必須です。
以下に、安全なパス解決を行うためのヘルパー関数を実装します。
import path from "path";
import fs from "fs/promises";
// 許可されたベースディレクトリ(例としてプロジェクト内の 'allowed_docs' フォルダ)
const BASE_DIR = path.resolve(process.cwd(), "allowed_docs");
/**
* リクエストされたパスがベースディレクトリ内にあるか検証する関数
* 【セキュリティ上の重要ポイント】
* AIが "../../../etc/passwd" のような悪意あるパスを指定した場合でも、
* ベースディレクトリ外へのアクセスを遮断します。
*/
function getSafePath(requestedPath: string): string {
// パスを絶対パスに解決し、正規化する
const resolvedPath = path.resolve(BASE_DIR, requestedPath);
// 解決されたパスがベースディレクトリから始まっているか確認
if (!resolvedPath.startsWith(BASE_DIR)) {
throw new Error(`Access denied: Path is outside of allowed directory.`);
}
return resolvedPath;
}
このように、外部からの入力をそのままファイルシステムに渡すのではなく、必ずサーバー側でサニタイズ(無害化)と検証を行う設計が、エンタープライズ水準のシステムでは求められます。
Claudeからの呼び出しに応答するハンドラ記述
次に、AIモデルに対して「どのようなToolが利用可能か」を提示し、実際にToolが呼び出された際の処理を記述します。
// ToolのリストをAIモデルに提示するハンドラ
server.setRequestHandler(ListToolsRequestSchema, async () => {
return {
tools: [
{
name: "read_file",
description: "指定されたファイルのテキスト内容を読み取ります。パスはベースディレクトリからの相対パスで指定してください。",
inputSchema: {
type: "object",
properties: {
filePath: {
type: "string",
description: "読み取るファイルの相対パス(例: 'document.txt')",
},
},
required: ["filePath"],
},
},
],
};
});
// Toolが呼び出された際の実行ハンドラ
server.setRequestHandler(CallToolRequestSchema, async (request) => {
if (request.params.name === "read_file") {
const { filePath } = request.params.arguments as { filePath: string };
try {
// 安全なパスを取得(セキュリティチェック)
const safePath = getSafePath(filePath);
// ファイルの読み込み
const content = await fs.readFile(safePath, "utf-8");
// 成功時:ファイル内容をAIに返す
return {
content: [
{
type: "text",
text: content,
},
],
};
} catch (error: any) {
// エラー時:AIが理解しやすい形でエラーメッセージを返す
return {
content: [
{
type: "text",
text: `Error reading file: ${error.message}`,
},
],
isError: true, // MCPプロトコルにおけるエラーフラグ
};
}
}
throw new Error(`Unknown tool: ${request.params.name}`);
});
ここで注目すべきは、エラー発生時のハンドリングです。例外をそのままスローしてサーバーをクラッシュさせるのではなく、isError: true を付与したテキストメッセージとしてAIに返却しています。これにより、AIは「ファイルが存在しなかった」という事実を認識し、「別のパスを試しますか?」といった次のアクションを自律的に判断できるようになります。
Step 3:Claude Desktopへの組み込みと動作検証
サーバーの実装が完了したら、いよいよClaude Desktopと連携させます。
config.jsonへのサーバー登録
Claude Desktopに自作のMCPサーバーを認識させるには、専用の設定ファイル(claude_desktop_config.json)を編集します。
設定ファイルの保存場所はOSによって異なります。
- Windows:
%APPDATA%\Claude\claude_desktop_config.json - macOS:
~/Library/Application Support/Claude/claude_desktop_config.json
ファイルを開き(存在しない場合は作成し)、以下のように記述します。
{
"mcpServers": {
"local-file-server": {
"command": "npx",
"args": [
"tsx",
"/絶対パス/mcp-local-file-server/index.ts"
]
}
}
}
commandとargsには、MCPサーバーを起動するためのコマンドを指定します。今回は開発環境であるため npx tsx を使用していますが、本番運用ではトランスパイル済みのJavaScriptファイルを node コマンドで実行するよう設定するのが一般的です。
設定を保存した後、Claude Desktopを完全に再起動してください。右側のパネルにプラグのアイコン(MCP連携アイコン)が表示されれば、接続は成功です。
MCP Inspectorを用いたデバッグ手法
もしClaude Desktop上でうまく動作しない場合、問題が「MCPサーバーの実装」にあるのか、「Claude Desktopの設定」にあるのかを切り分ける必要があります。
このような時に役立つのが、公式が提供する「MCP Inspector」です。以下のコマンドを実行することで、ブラウザ上でMCPサーバーの動作テストを行うことができます。
npx @modelcontextprotocol/inspector npx tsx index.ts
ブラウザが立ち上がり、定義したTool(read_file)の一覧表示や、任意の引数を渡しての実行テストがGUI上で行えます。ここで正常にファイル内容が取得できれば、サーバー側の実装には問題がなく、Claude Desktop側の設定やパス指定に原因があることが特定できます。
エンタープライズ導入に向けたリスク管理とQ&A
チュートリアルを通じて基礎的な実装方法は理解できたかと思います。しかし、これを実際の業務環境に導入する際には、技術選定や社内稟議において様々な懸念事項が浮上します。ここでは、組織導入に向けたリスク管理のベストプラクティスを解説します。
データ漏洩を防ぐためのサンドボックス化
Q: MCPサーバー経由で社内の機密データが外部のLLMプロバイダーに学習されてしまうリスクはないのか?
多くの企業が抱えるこの懸念に対する答えは、システムのアーキテクチャ設計にあります。MCP自体は単なる通信プロトコルであり、データの学習ポリシーは利用するAIクライアント(API)の仕様に依存します。
対策として、エンタープライズ向けに提供されているデータ学習オプトアウト(学習に利用しない)が保証されたAPIエンドポイントを使用することが大前提です。
さらに、MCPサーバー側での対策として「データのサンドボックス化」が有効です。AIに直接データベースのSQL実行権限を与えるのではなく、「事前に集計・匿名化されたデータのみが配置される専用の参照用データベース」を構築し、MCPサーバーはそのサンドボックスのみを参照するよう設計します。これにより、万が一AIが予期せぬクエリを生成しても、本番データへの影響を物理的に遮断できます。
社内プロキシ環境下での注意点
Q: 社内ネットワークの厳しいプロキシ制限下でもMCPサーバーは構築可能か?
可能です。本チュートリアルで紹介した StdioServerTransport は標準入出力を使用するため、ローカルマシン内で完結する通信においてはネットワークプロキシの影響を受けません。
ただし、MCPサーバー自体が外部のSaaS API(SalesforceやJiraなど)からデータを取得してくるような構成にする場合、MCPサーバーを実行するプロセスに対して適切なプロキシ設定(環境変数 HTTP_PROXY や HTTPS_PROXY など)を渡す必要があります。
また、社内ネットワークから外部のAIモデルAPIへアクセスするための通信経路が確保されていることも確認が必要です。
次のステップ:自社固有のデータベースやAPIとの接続へ
本記事では、MCPの概念理解からローカルファイル参照サーバーの構築までを解説しました。MCPがもたらす「AIとデータソースの分離」というアーキテクチャは、システムに高い保守性とセキュリティをもたらします。
ここから先のステップとして、自社のビジネス要件に合わせた拡張を検討してみてください。
GitHub上の既存MCPサーバー群の活用
すべてをゼロから独自実装する必要はありません。Anthropicをはじめとするオープンソースコミュニティでは、すでに多くの実用的なMCPサーバーが公開されています。
例えば、GitHub連携、Google Drive連携、Slack連携、PostgreSQL接続用のMCPサーバーなどが提供されています。これらを自社の要件に合わせてフォークし、カスタマイズすることで、開発工数を大幅に削減できます。コミュニティの動向を定期的にチェックし、エコシステムの恩恵を最大限に活用することをおすすめします。
自社専用MCPエコシステムの構築計画
最終的な目標は、社内に点在する様々なナレッジやシステムを、MCPという共通言語を通じてAIとシームレスに連携させる「自社専用のAIエコシステム」の構築です。
まずは、リスクの低い社内FAQの検索や、公開されているAPIのデータ参照など、小さなユースケースからMCPの導入を始めてみてください。標準規格に基づいた設計を行うことで、将来的に新しいAIモデルが登場した際にも、既存のデータ連携資産をそのまま活用できる強固な基盤となるはずです。
自社への適用を検討する際は、アーキテクチャの全体設計について専門家への相談で導入リスクを軽減することも有効な手段です。セキュアで持続可能なAIエージェント開発に向けて、本記事の知見が第一歩となれば幸いです。
コメント