AIアプリケーションを外部の世界と連携させるには、何らかの方法でモデルをほかのアプリに接続する必要があります。MCP（Model Context Protocol）サーバーは、LLMと別のアプリをつなぐ小さなプログラムです。
この記事では、次の内容を解説します。
- AIにおけるMCPサーバーとは何か
- MCPサーバーの仕組み
- MCPサーバーが役立つ場面
- MCPサーバーの設定とテストの方法
MCPサーバーとは？
MCPサーバーは、AIアプリケーションがツール、データ、外部システムにアクセスするための標準化された方法を提供するプログラムです。たとえば、GitHub MCPサーバーを考えてみましょう。このサーバーは、次のようなツールを公開します。
search_repositoriesread_issuecreate_issueget_pull_request
AIアプリはGitHub MCPサーバーに接続し、公開されている機能を検出して、MCPプロトコルを通じてそれらの機能を呼び出せます。
たとえば、以下のスクリーンショットは、私たちが開発したローカルAIアプリAtomic Chatでのチャットです。ローカルで動作するAIモデルに、リポジトリ内のオープン状態のプルリクエストを取得するよう依頼しています。
こちらは別の例です。会話で決まった内容をまとめ、Notionの「Team Docs」の配下に保存するようAtomic Chatに依頼しています。
これを可能にしているのが、Notion MCPサーバーです。
MCPサーバーの仕組み
MCPサーバーはAIアプリケーションからツールのリクエストを受け取り、外部システムに対して実行し、結果を構造化された形式で返します。
| 段階 | 役割 |
|---|---|
| ユーザー | リクエストを送信するか、AIにタスクの実行を依頼します。 |
| AIアプリケーション | リクエストを解釈し、外部ツールやデータソースが必要かどうかを判断します。 |
| MCPクライアント | MCPサーバーに接続し、利用可能な機能を検出して、ツールやリソースに対する構造化されたリクエストを送信します。 |
| MCPサーバー | リクエストを受け取り、外部システムに対する操作に変換して、結果を返します。 |
| 外部サービス | GitHub、Slack、データベース、APIなど、実際にデータを保存したり、操作を実行したりする基盤となるシステムです。 |
MCPのツール、リソース、プロンプト
これを実現するために、MCPサーバーは通常、主に3種類の機能を公開します。
1. ツール
ツールは、AIが実行できる操作です。たとえば、次のようなものがあります。
search_issues create_issue send_message run_sql get_weather
ツールには通常、次の情報が含まれます。
- 名前
- 説明
- 必要な入力を定義するスキーマ
例：
{
"name": "get_weather",
"description": "Get the current weather for a city",
"inputSchema": {
"type": "object",
"properties": {
"city": {
"type": "string"
}
},
"required": ["city"]
}
}モデルは説明と入力スキーマを受け取るため、いつツールを使うべきか、どの引数を渡すべきかを判断できます。
2. リソース
リソースは、AIが取得できる情報です。具体的には、次のような情報を含む読み取り可能なデータを指します。
- ファイル
- データベースのレコード
- ドキュメント
- APIレスポンス
- アプリケーションのデータ
リソースは一般に、モデルが実行するものではなく、読み取るものです。
3. プロンプト
MCPサーバーは、よくあるタスク向けに事前定義された指示を提供する、再利用可能なプロンプトやワークフローを公開することもできます。たとえば、コードレビュー用のMCPサーバーは、プルリクエストをレビューするための再利用可能なプロンプトを公開できます。
MCPホスト、MCPクライアント、MCPサーバーの違いを理解する
MCPサーバーはAIモデルと混同されることがありますが、それ自体では推論を行いません。モデルがアクセスしたいアプリケーションやサービスとともに動作し、MCPインターフェースを通じてその機能を公開します。
MCPホストやMCPクライアントという用語を耳にすることもあるでしょう。アーキテクチャにおけるそれぞれの位置づけは次のとおりです。
- MCPホストは、ChatGPT、Claude Desktop、IDEなど、ユーザーが操作するアプリケーションです。
- MCPクライアントはホストの一部であり、MCPサーバーへの接続を確立し、サーバーが公開する機能を検出し、リクエストを送信して、結果をホストに返します。
1つのホストで複数のMCPクライアントを実行でき、通常はサーバー接続ごとに1つのクライアントを使用します。
ローカルMCPサーバーとリモートMCPサーバーの違い
MCPサーバーは、自分のコンピューター上でローカルに動作させることも、ネットワーク経由でリモートに動作させることもできます。
ローカルMCPサーバーは、自分のコンピューター上のプロセスとして動作します。通常は、そのコンピューターにしか存在しないものにアクセスする必要があるためです。代表的な例がFilesystem MCPサーバーで、選択したフォルダーやファイルをAIアプリに公開できます。ほかにも、開発者向けツール、ローカルデータベース、コマンドラインユーティリティをラップするローカルサーバーがあります。
リモートMCPサーバーは、接続先のサービスが運用するインフラ上で動作します。MCPクライアントはサーバーをローカルで起動する代わりに、HTTP経由で接続します。代表的な例がGitHub MCPとFigma MCPです。サーバーをGitHubやFigma自身のAPIに近い場所で動作させ、MCPを通じてそれらのサービスを公開できるため、連携用の仕組みを自分で稼働させる必要がありません。
この違いは、主にサーバーがどこで動作するかにあります。モデルから見ると、どちらも同じMCPインターフェースを通じてツールやリソースを公開します。
MCPサーバーはどのようなときに役立つ？
MCPサーバーは、AIアプリケーションが再利用可能な標準化された連携の仕組みを通じて、外部のデータやソフトウェアとやり取りする必要があるときに役立ちます。アプリケーションがモデルの外部にある情報や操作を一切必要としない場合、MCPはまったく必要ないかもしれません。
AIモデルを外部データに接続する方法は、MCPサーバーだけではありません。開発者は独自のコネクターを構築し、ツール呼び出しAPIを直接利用することもできます。MCPが登場する前は、個々のAIアプリとそれぞれの外部システムの間で、個別に連携機能を構築することがよくありました。モデル、アプリケーション、サービスの数が増えるにつれて、重複する連携開発の作業も増えていきました。
こうした背景から、Anthropicは2024年11月に、AIアプリケーションを外部システムに接続するためのオープン標準としてModel Context Protocolを発表しました。その狙いは、多数の個別の連携機能を共通のプロトコルで置き換えることでした。APIになじみがある方なら、MCPサーバーはAIアプリケーション向けに設計されたAPIアダプターに似たものと考えられます。
MCPサーバーの設定方法
私たちが開発したローカルAIアプリAtomic Chatを使って、設定手順を説明します。ほかのAIアプリでも、インターフェースは多少異なるものの、おおむね同じ手順で設定できます。
Atomic Chatで、Settings → MCP Servers → Add MCP Serverを開きます。
リモートMCPサーバーを設定するには
リモート接続のオプションを選択し、サーバーのメンテナーが提供するURLを入力します。
サーバーがOAuthを使用している場合、Atomic Chatがサインインを求めます。トークンやその他の認証情報を使用している場合は、サーバーのドキュメントに従って入力してください。
現在のホスト型MCPサーバーの多くはHTTPを使用しています。Atomic Chatは、従来のSSE構成が引き続き必要なサーバーにも対応しています。
ローカルMCPサーバーを設定するには
自分のコンピューター上で動作するサーバーの場合は、STDIOを選択します。
たとえば、参照実装のファイルシステムサーバーは、コンピューター上の特定のディレクトリへのアクセスをクライアントに提供するローカルMCPサーバーです。
Atomic Chatで、コマンドを次のように設定します。
npx
続いて、次の引数を順番に追加します。
-y @modelcontextprotocol/server-filesystem /Users/you/Projects
/Users/you/Projectsを、自分のコンピューター上のディレクトリに置き換えてください。
警告：サーバーにアクセスさせたいディレクトリだけを公開してください。
JSONでMCPサーバーを設定する方法
JSONは、同じ設定を指定するための別の方法です。ほとんどのMCPサーバーは設定手順をJSONスニペットとして公開しているため、フォームの各項目に置き換えて入力するよりも、Atomic ChatのJSONエディターに貼り付けるほうが速いことがよくあります。
たとえば、前のセクションで紹介したファイルシステムサーバーのJSON設定は、次のようになります。
{
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/Users/you/Projects"
],
"env": {}
}- command：サーバーを起動するプログラムです。ここでは、
npxがパッケージのダウンロードと実行を1つの手順で行います。 - args：パッケージ名と、サーバー自体のオプションです。ファイルシステムサーバーの場合、オプションはアクセスを許可するディレクトリの一覧です。
- env：環境変数で、通常はAPIキーやトークンを指定します。ファイルシステムサーバーでは必要ないため、このオブジェクトは空のままにします。
パッケージ名が変更されることもあるため、保存する前にサーバーの最新のドキュメントでパッケージ名を確認してください。
サーバーをテストする
サーバーに接続したら、そのツールを使って作業を進める前に、実際に動作することを確認してください。誤りがあっても何も変更されないよう、まずは小規模な読み取り専用のリクエストから始めます。ファイルシステムサーバーなら、次のように依頼できます。
- 私のProjectsフォルダーにはどのようなファイルがありますか？
- Projects内のREADMEを開いて要約してください。
モデルのツール呼び出しが表示され、実際のファイル名が返ってくれば、接続は機能しています。ツール呼び出しが表示されず、代わりにモデルが記憶している情報から回答する場合は、サーバーが接続されていないか、そのリクエストにサーバーが必要だとモデルが認識していない可能性があります。ツール名やサーバー名を明示してみてください。
ツール呼び出し自体が失敗する場合、よくある原因は、コマンドやパッケージ名の誤り、ディレクトリパスの入力ミス、または公開したディレクトリの外を指定するリクエストです。
MCPサーバーを安全に使う
MCPサーバーは非公開データを公開したり、サードパーティーのAPIにアクセスしたり、ユーザーに代わって操作を実行したりできるため、安全に利用するには正しく設定することが重要です。
2026-07-28版の時点で、公式のMCP仕様には、MCPサーバーを安全に使うための指針が非常に具体的に示されています。
推奨事項は数多くありますが、実務上もっとも重要なルールは、重大な影響を伴う操作について確認を有効にしておくことです。つまり、そのような操作を承認する前に、提案された操作、その対象、そしてどのような変更が加えられるかを確認します。
以下は、仕様全体から抜き出した、特に重要な指針です。
- 信頼できるMCPサーバーだけに接続してください。サーバーの運用者、公開されている場合はソースコード、デプロイ先のインフラ、公開されているツールを確認してください。サービス提供元のドキュメント、プロジェクトのソースリポジトリ、または公式MCP Registryの登録情報を優先し、その情報源でパッケージ名やエンドポイントを照合してください。非公式ディレクトリに見慣れた名前が載っているだけでは不十分です。特に、設定時にローカルでコードを実行するよう求められる場合は注意が必要です。悪意のあるMCPサーバーや侵害されたMCPサーバーは、プロンプトインジェクションやデータ流出のリスクをもたらす可能性があります。
- 強固な認証と最小権限を適用してください。固定の共有APIキーよりもOAuthを優先し、各ユーザーには必要なスコープだけを付与して、サーバー側でトークンを検証してください。データ側のアクセス範囲も絞りましょう。1つのプロジェクトにアクセスするだけでよいファイルシステムサーバーに、ホームフォルダー全体へのアクセスを与えるべきではありません。また、分析に使うデータベースには読み取り専用の認証情報を使うべきです。たとえば、GitHubの公式MCPサーバーは、ツールセットの選択、個別ツールの選択、読み取り専用モードに対応しているため、プルリクエストを一覧表示するためにリポジトリの編集権限は必要ありません。
- 破壊的な操作や外部から見える操作には、より厳格な認可とユーザーの確認を必須にしてください。Issueの一覧表示は何も変更しないため、容易に元に戻せます。一方、Notionページの作成、メッセージの送信、コードのデプロイ、ファイルの削除はそうではありません。サーバーがどこで何を行うのかを正確に理解できるまでは、外部システムを変更する操作について確認を有効にしておいてください。
- MCPが返すコンテンツは、信頼できないデータとして扱ってください。ドキュメント、ウェブサイト、GitHubのIssue、データベースのレコードには、モデルを操作することを意図した指示が含まれている可能性があります。アプリケーションは、取得したテキストを、権限を伴う別のツールを呼び出すための承認として決して扱うべきではありません。
- サーバー側で権限を適用してください。ユーザーが何にアクセスできるかの判断をモデルに委ねないでください。モデルはプロンプトインジェクション攻撃の影響を受けるため、MCPサーバーはデータを返したり操作を実行したりする前に、認証済みユーザーのID、テナント、リソースに対する権限、許可された操作を独立して確認するべきです。
- プロンプトやツールの結果にシークレットを含めないでください。認証情報はシークレット管理ツールや保護されたサーバー環境に保存してください。MCPレスポンスを通じて、アクセストークン、APIキー、データベースのパスワード、不要な機密情報フィールドを返すことは避けてください。
- データが通る経路全体を確認してください。ローカルMCPサーバーを使っても、会話全体がローカルで完結するとは限りません。モデルはクラウドで動作しているかもしれず、サーバーがGitHub、Notion、その他のホスト型APIを呼び出す可能性もあります。逆に、ローカルのファイルシステムサーバーは、ファイルへのアクセスを自分のコンピューター内で行いながら、選択したファイルの内容をクラウド上のモデルに返す場合があります。モデルの提供元、MCPサーバー、その先で接続するサービスをそれぞれ個別に確認してください。
- 危険なツールの機能範囲を絞ってください。
execute_arbitrary_sql(sql)やrun_shell(command)に相当するものよりも、update_ticket_status(ticket_id, status)を優先してください。機能範囲を絞ったインターフェースは、認可、監査、検証をはるかに容易にします。 - セキュリティに関わる操作をログに記録してください。認証された主体、呼び出されたMCPツール、影響を受けたリソース、結果、認可の判断を記録してください。シークレットや不必要に機密性の高いデータをログに記録することは避けてください。
重要なポイント
- MCPサーバーは、AIアプリケーションを外部のツールやデータに接続します。MCPはModel Context Protocolの略で、AIアプリケーションが共通のインターフェースを通じて、API、データベース、ファイル、開発者向けツール、業務用ソフトウェアとやり取りできるようにするオープン標準です。
- MCPサーバーを使うと、AIアプリケーションはモデル単体では持たない機能をモデルに与えられます。たとえば、最新データの読み取りや、ほかのアプリでの変更操作です。
- MCPサーバーは、ツール、リソース、プロンプトを公開できます。ツールはモデルによる操作の実行を可能にし、リソースは読み取る情報を提供し、プロンプトはよくあるタスク向けに再利用可能な指示やワークフローを提供します。
- MCPは標準化に役立ちます。独自のコネクターやツール呼び出しによる連携も引き続き利用できますが、MCPは共通のインターフェースを提供することで、重複する連携開発の作業を減らせます。
- MCPサーバーは、ローカルでもリモートでも動作させられます。ローカルサーバーは、連携に自分のコンピューター上のファイル、データベース、ツールへのアクセスが必要な場合に役立ちます。リモートサーバーはネットワーク上でホストされ、GitHub、Atlassian、Gmailなどのサービスへの管理されたアクセスを提供できます。
