> ## Documentation Index
> Fetch the complete documentation index at: https://lib.findy.co.jp/llms.txt
> Use this file to discover all available pages before exploring further.

# MCPとは — AIと外部ツールをつなぐ標準規格

> Model Context Protocolは、AIアプリケーションと外部のデータソース・ツール・ワークフローを接続するオープンな標準規格です。

## 概要

MCPはModel Context Protocolの略で、AIアプリケーションと外部システムを接続するためのオープンな標準規格です。MCPを通じて、AIエージェントは、ファイル・データベース・リポジトリなどのデータソース、検索エンジンやIssueトラッカーなどのツール、専用promptsのようなワークフローに接続し、実務に必要なコンテキストと操作を手に入れます。

MCPは、AIアプリケーションにとってのUSB-Cポートのようなものです。USB-Cが1つの標準化されたコネクタで多様な周辺機器をつなぐように、MCPは1つの標準化された方法でAIアプリケーションを多様な外部システムに接続します。組み合わせごとに独自の連携形式を作る必要はありません。

MCPの範囲は、エージェントと外部世界の境界です。ワークフロー設計の手法そのものでも、権限モデルそのものでも、明確な指示の代替でもありません。それらは引き続きエージェントの周辺で設計する必要があります。MCPは、その設計が立つための連携レイヤーです。

本ページでは、MCPがなぜ必要なのか、どのような要素で構成されるのか、状況に応じてどの導入方法を選ぶのか、そしてチームでMCPサーバーを運用するときに何を考えるべきかを解説します。

## なぜMCPか

AIエージェントは、実際の仕事が行われているシステムに触れられると有用になります。MCPで接続すると、たとえばエージェントは次のようなことができます。

* カレンダーやチームのドキュメントを読み、パーソナライズされたアシスタントとして働く
* デザインファイルから動くアプリケーションを生成する
* 組織内の複数のデータベースを横断分析して質問に答える

共通プロトコルがなければ、各AIアプリケーションは各ツールと直接連携しなければならず、新しいエージェントとツールの組み合わせごとに専用のアダプターが増えていきます。MCPはオープンな標準規格です。ツールやデータソースが1つのMCPサーバーを公開すれば、MCPに対応するどのクライアントからも接続できます。一度作れば、どこからでもつながります。

```mermaid theme={null}
flowchart LR
  A1[AIアプリケーション] --> C[MCPクライアント]
  C --> S1[MCPサーバー: リポジトリ]
  C --> S2[MCPサーバー: Issueトラッカー]
  C --> S3[MCPサーバー: データベース]
```

利点は、エコシステムのどこに立つかで異なります。

| 立場         | 利点                                                 |
| ---------- | -------------------------------------------------- |
| 開発者        | AIアプリケーションやエージェントを作る・連携するときの開発時間と複雑さを減らせます。        |
| AIアプリケーション | データソース・ツール・アプリのエコシステムに接続でき、エージェントにできることが広がります。     |
| エンドユーザー    | 自分のデータにアクセスし、必要なときに代わりに行動できる、より有能なAIアプリケーションを使えます。 |

その結果は「エージェントが何でもできる」ではありません。より狭く、実務的です。サーバーが公開し、サーバーとクライアントが制御する、特定の外部操作をエージェントが実行できるようになります。

## 基本要素

MCPは、サーバー/クライアントモデルとして捉えると理解しやすくなります。サーバーは3種類の機能を公開し、クライアントはElicitationのような逆方向の機能を提供します。

### サーバーとクライアント

MCPサーバーは、あるシステムの機能を公開します。ローカルコマンド、ファイルシステム、内部API、SaaS、データベース、ドキュメントインデックスなどを包むことがあります。サーバーは、MCPリクエストをそのシステム固有の操作へ変換する責務を持ちます。

MCPクライアントはAIアプリケーションの内側にあります。1つ以上のサーバーへ接続し、各サーバーが提供する機能を列挙し、アプリケーションのルールに従ってエージェントへ利用可能にします。

通常、エージェントは背後のサービスを直接呼び出しません。機能を使うようクライアントに依頼し、クライアントが構造化されたリクエストをサーバーへ送ります。

この分離により、連携を再利用しやすくなります。

| 部分        | 役割                                       |
| --------- | ---------------------------------------- |
| MCPサーバー   | システム固有の連携を担い、安定したMCPの表面を公開します。           |
| MCPクライアント | AIアプリケーションをサーバーへ接続し、エージェントが何を使えるかを仲介します。 |
| エージェント    | タスク解決の一部として機能を選び、利用します。                  |

### Tools

`tools`は呼び出し可能なアクションです。MCPの中では関数呼び出しに近い部分です。サーバーはtool名、description、入力schema、結果の形を宣言し、エージェントは構造化された引数で実行を依頼できます。

典型的なtoolsには、次のようなものがあります。

* Issueやプルリクエストを検索する
* チケットを作成する
* 承認されたデータソースに対してqueryを実行する
* サービスと時間範囲を指定してログを取得する
* 狭い範囲の内部自動化を起動する

良いtoolsは、安全で有用になる程度に具体的です。`run_any_command`というtoolは、エージェントに広すぎる操作面を渡します。`search_recent_deploy_errors`というtoolであれば、意図、範囲、期待する入力が名前に含まれます。

実行時の流れは次のようになります。エージェントがリクエストからtoolを選び、構造化された引数で呼び出し、結果から回答します。

```text example theme={null}
> 昨日のapi-gatewayのデプロイでエラー出てた？

⏺ deploy-server - search_recent_deploy_errors (MCP)(service: "api-gateway", hours: 24)
  ⎿  ### Deploy errors: api-gateway (last 24h)
     total: 2
     - 14:03 Migration timeout on users table
     - 14:11 Rollback triggered by health check

⏺ 昨日のapi-gatewayのデプロイでは2件のエラーが発生しています。usersテーブルの
  migration timeoutと、それに続くhealth checkによるrollbackです。
```

### Resources

`resources`は、サーバーが公開する読み取り可能なコンテキストです。エージェントがデータを必要としているものの、すべての文書やオブジェクトについてアクション指向のtoolを呼ぶべきではない場合に有用です。

例としては、次のようなものがあります。

* ファイルやディレクトリツリー
* 設計ドキュメント
* runbook
* データベースschema
* プロジェクト状態の生成されたsummary

クライアントはサーバーのresource一覧を取得し、URIで読み取ります。ユーザーが会話に添付することも、タスクに必要になったときにエージェントが自ら取り込むこともできます。

```text example theme={null}
> rollbackの手順を教えて

⏺ deploy-server - resources/list (MCP)
  ⎿  file:///runbooks/deploy.md, file:///runbooks/oncall.md

⏺ deploy-server - resources/read (MCP)(uri: "file:///runbooks/deploy.md")
  ⎿  # Deploy runbook
     ## Rollback
     1. Freeze deploys
     2. Revert the release tag
     3. Re-run health checks

⏺ rollbackは3ステップです。デプロイを凍結し、リリースタグをrevertし、
  health checkを再実行してからパイプラインを再開します。
```

Resourcesは、クライアントが必要な部分だけを取得できる形にします。ドキュメントサイト全体をエージェントのコンテキストへ流し込むと、MCPを使う意味が薄れます。安定した識別子、意味のあるメタデータ、焦点の合ったresource本文を公開します。

### Prompts

`prompts`は、サーバーが提供する再利用可能なpromptテンプレートです。インシデントを調査する、プロジェクトを要約する、リリースノートを準備する、特定種別のalertをtriageするなど、そのサーバーのドメインに近い依頼の型をまとめます。

Promptが特に活きるのは、そのサーバー自身のtoolsを呼ぶ複数ステップの手順を定型化する場合です。

クライアントはサーバーのprompt一覧をユーザーに提示します。呼び出すとテンプレートがエージェントへの指示に展開され、エージェントがステップに従います。

```text example theme={null}
> /investigate_deploy_failure api-gateway

⏺ deploy-server - search_recent_deploy_errors (MCP)(service: "api-gateway", hours: 24)
  ⎿  ### Deploy errors: api-gateway (last 24h)
     total: 2 ...

⏺ deploy-server - get_deploy_status (MCP)(service: "api-gateway")
  ⎿  release v2.14.1 deployed 13:58 ...

⏺ エラーはv2.14.1から始まっており、原因はusersテーブルのmigrationである
  可能性が高いです。推奨: v2.14.0にロールバックし、migrationはオフピークに
  再実行してください。
```

### Elicitation

ここまでの3つの機能はサーバーからエージェントへ提供されるものですが、Elicitationは逆方向に働きます。サーバーが自力では得られない情報、たとえば不足しているパラメータ、認証情報、操作前の確認が必要になったとき、クライアントを通じてタスクの途中でユーザーに尋ねます。

```mermaid theme={null}
sequenceDiagram
  participant U as ユーザー
  participant C as MCPクライアント
  participant S as MCPサーバー
  C->>S: tools/call
  S->>C: elicitation/create
  C->>U: ダイアログを表示
  U->>C: 入力して承認
  C->>S: 回答を返す
  S->>C: toolの実行結果
```

クライアントはリクエストをユーザーに表示し、回答をサーバーへ返します。尋ね方は2つの形があります。サーバーが定義したフィールドを持つフォームと、認証や承認のためにブラウザで開くURLです。フォーム形式のリクエストの流れは次のようになります。

```text example theme={null}
> deploy-serverでstagingをロールバックして

⏺ deploy-server - rollback_release (MCP)(environment: "staging")

  deploy-server → elicitation/create
    message: "Roll back staging to v2.14.0?"
    fields:  reason (string)

  user → accept { reason: "migration timeout" }

  ⎿  Rolled back staging to v2.14.0 (reason: migration timeout)

⏺ stagingをv2.14.0にロールバックしました。理由として「migration timeout」を
  記録しています。
```

Elicitationは、確認をtoolの設計ではなくプロトコルの側に持たせます。不足した入力を推測したり、破壊的な操作を黙って実行したりする代わりに、サーバーは立ち止まってユーザーに尋ねられます。

## 導入方法

MCPの導入は、クライアントが何に接続するかで整理できます。形は3つあります。ローカルで起動して使う既存MCP、URLで接続するリモートMCP、そして自分で作る自作MCPです。

| 選択肢     | 向いている状況                                 |
| ------- | --------------------------------------- |
| 既存MCP   | 使いたいツールが、コマンド1つでローカル起動できるサーバーを提供している場合。 |
| リモートMCP | サーバーがベンダーまたは自組織によってホストされており、URLで接続する場合。 |
| 自作MCP   | 有用な機能が内部システムの背後にあり、サーバーを自分で作る必要がある場合。   |

### 既存MCP

チームがすでに使っているツールがMCPサーバーを提供している場合は、それを接続します。実装が不要で設定だけで済む、最も低コストな選択肢です。多くのMCPクライアントは同様の形式の設定を読みます。認証が必要なサーバーを登録する例です。

```json client configuration theme={null}
{
  "mcpServers": {
    "example-server": {
      "command": "npx",
      "args": ["-y", "@example/mcp-server"],
      "env": {
        "EXAMPLE_API_TOKEN": "${EXAMPLE_API_TOKEN}"
      }
    }
  }
}
```

認証が必要なサーバーには、`env`キーで環境変数として認証情報を渡します。tokenのような秘匿値の実値を設定ファイルに書かないようにします。

既存サーバーを評価するときは、次を確認します。

* エージェントが実際に必要とする機能を公開しているか
* tool descriptionとschemaが、信頼して使える程度に具体的か
* 認証を実ユーザー、チーム、環境にscopeできるか
* サーバーの戻り値が簡潔か、それともコンテキストを過剰に埋めるか
* メンテナンス方針が自組織に合うか

既存サーバーが最も少ない運用リスクで価値を出すのは、読み取り中心の作業です。検索、lookup、要約、コンテキスト取得が該当します。

### リモートMCP

サーバーが別の場所でホストされている場合は、リモートMCPに接続します。SaaSベンダーが運営する公式サーバーの場合もあれば、自組織がチーム向けに運用するサーバーの場合もあります。ローカルでは何も動かさず、クライアントはURLで接続して認証します。認証は一般にOAuthまたはAPIキーです。

```json client configuration theme={null}
{
  "mcpServers": {
    "deploy-server": {
      "type": "http",
      "url": "https://mcp.example.com/mcp",
      "headers": {
        "Authorization": "Bearer ${DEPLOY_MCP_TOKEN}",
        "X-Organization": "${DEPLOY_MCP_ORG}"
      }
    }
  }
}
```

既存MCPと同様、秘匿値は環境変数参照で渡します。多くのクライアントが設定内での環境変数の展開をサポートしています。

リモートサーバーを自組織でホストする場合は、次のものを1箇所で管理できます。

* 認証と認可。誰がどのtoolsを使えるかをサーバー側で制御でき、マシンごとに認証情報を配る必要がありません
* サーバーの更新。全員が同じデプロイに接続するため、サーバーを更新すれば全員に行き渡り、toolの一覧や挙動もチームで揃います
* Audit logと監視。すべてのリクエストが1箇所を通るため、ログと可観測性を集中できます

ベンダーがホストするサーバーなら、自分たちの運用コストはかかりません。自組織でホストする場合は、認証、versioning、監視を維持する共有インフラになります。チーム全体での共有がそのコストに見合うときに、セルフホストを選びます。

### 自作MCP

既存の連携が自分たちのワークフローに合わない場合や、有用な機能が内部システムの背後にある場合は、自作のMCPサーバーを作ります。公式のTypeScript SDKでは、1つのtoolと1つのpromptを公開する小さなサーバーは次のように書けます。サーバーはクライアントの子プロセスとして起動し、標準入出力で通信します。これがstdio transportです。

```ts deploy-server theme={null}
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
import { z } from 'zod';

const server = new McpServer({ name: 'deploy-server', version: '1.0.0' });

server.registerTool(
  'search_recent_deploy_errors',
  {
    title: 'Search recent deploy errors',
    description:
      'Searches deploy logs for errors in the given service and time range. ' +
      'Use when investigating a failed or unstable deployment.',
    inputSchema: {
      service: z.string().describe('Service name (e.g. "api-gateway")'),
      hours: z.number().max(72).default(24).describe('Hours to look back'),
    },
  },
  async ({ service, hours }) => {
    const errors = await fetchDeployErrors(service, hours);
    const lines = [
      `### Deploy errors: ${service} (last ${hours}h)`,
      `total: ${errors.length}`,
      ...errors.map((e) => `- ${e.occurredAt} ${e.summary}`),
    ];
    return { content: [{ type: 'text', text: lines.join('\n') }] };
  }
);

server.registerPrompt(
  'investigate_deploy_failure',
  {
    description: 'Investigate a failed deployment step by step',
    argsSchema: {
      service: z.string().describe('Service name to investigate'),
    },
  },
  async ({ service }) => ({
    messages: [
      {
        role: 'user',
        content: {
          type: 'text',
          text: [
            'Investigate the failed deployment in the following order.',
            `1. Call \`search_recent_deploy_errors\` with service "${service}".`,
            '2. Call `get_deploy_status` and find the release that introduced the errors.',
            '3. Summarize the likely causes and propose a rollback decision.',
          ].join('\n'),
        },
      },
    ],
  })
);

await server.connect(new StdioServerTransport());
```

実際の利用時に、ユーザーがtool名を口にすることはありません。「昨日のapi-gatewayのデプロイでエラーは出ていた？」と尋ねると、エージェントはリクエストをtoolのdescriptionと照合してこのtoolを選び、`{ service: "api-gateway", hours: 24 }`で呼び出し、返ってきた要約から回答します。一方、promptは明示的に呼び出します。ユーザーがクライアントのprompt一覧から`investigate_deploy_failure`を選ぶと、展開されたテキストがエージェントへの指示になり、エージェントはサーバーのtoolsを順に呼ぶステップを毎回同じ流れで実行します。

クライアントはコマンド指定でサーバーを起動します。

```json client configuration theme={null}
{
  "mcpServers": {
    "deploy-server": {
      "command": "node",
      "args": ["./dist/deploy-server.js"]
    }
  }
}
```

最初は狭く始めます。API全体を包む広いwrapperより、1つか2つの明確なtoolsのほうが有用です。サーバーの表面はエージェントの視点から設計し、許可されたタスクに必要な入力だけを公開します。状態を変更するtoolでは、操作内容を名前と結果で明示します。

中でもdescriptionは、MCPサーバー設計の要です。エージェントは自然言語のリクエストをdescriptionと照合してtoolを選ぶため、descriptionの書き方がtoolが使われるかどうかを決めます。試しに作るときには軽視されがちな部分ですが、真っ先に丁寧に書く価値があります。

自作サーバーを後からチームで共有したくなったら、transportをstdioからStreamable HTTPに切り替えるだけで、同じコードのままリモートで提供できます。

## 運用上の考慮点

MCPはエージェントにデータアクセスとコード実行の経路を渡すため、適切な運用の中心は信頼とscopeの管理です。どのサーバーを接続するのか、誰が何を使えるのか、どれだけのコンテキストが返るのか、同時にいくつの選択肢をエージェントに渡すのかを管理します。

### サーバーの信頼性

MCPサーバーを接続することは、エージェントのコンテキストと操作への経路をそのサーバーに渡すことです。そのため、運用上の最初の判断は「どのサーバーを信頼するか」になります。MCPの仕様は、信頼できるサーバー由来でない限り、toolのdescriptionをuntrustedとして扱うことを求めています。descriptionは指示を運びうるものであり、エージェントは何を呼ぶかの判断の一部としてそれを読んでしまうためです。これは一般的な問題の一例であり、リスクの捉え方とその防御は[セキュリティ](/ja/ai/security)で解説しています。

* すでに信頼している提供元のサーバーを接続し、公式のものを優先します
* チームに展開する前に、サーバーが公開するもの（toolsとそのdescription）を確認します
* 更新後は再評価します。サーバーのtool一覧は時間とともに変わり得ます

### 認証と権限設計

MCPサーバーは抜け道ではなく、アプリケーション連携として扱います。認証では、ポリシーと監査に十分な粒度で、ユーザー、workspace、service account、環境を識別できるようにします。MCPの仕様はユーザーの同意を中心に置いています。ホストはtool実行前に明示的な承認を得て、どのデータを共有するかの制御をユーザーが保持します。

最小権限を基本にします。

* デフォルトは読み取り専用にする
* 読み取りtoolsと書き込みtoolsを分ける
* Tokenは有用な最小範囲のシステムと操作にscopeする
* 破壊的、高コスト、外部に見える操作には確認を求める
* Debugと監査に必要なrequest metadataを記録する

認可は両側に置きます。サーバーは背後のシステムが許すことを強制し、クライアントは、そのsessionでエージェントが公開済み機能のどれを使えるかを決めます。クライアント側をどう設計するか、つまり許可リスト・読み取り専用の役割・人間の承認を挟む操作の選び方は[セキュリティ](/ja/ai/security)で解説しています。

### コンテキスト効率

MCP連携は、コンテキストを良くも悪くもします。サーバーがタスクに必要なデータを正確に返すと助けになります。呼び出しのたびに大きなraw objectを返し、エージェントがそれを抱え続ける場合は悪化します。

小さく、判断に使える応答を設計します。

* Full bodyの前にsummaryを返す
* Pagination、filter、安定した識別子を提供する
* エージェントが候補を選んだあとにdetailを取得できるようにする
* タスクに役立たないフィールドを省く
* 次のステップが機械的な場合は、proseよりstructured dataを優先する

これはAgentic Workflowで使うコンテキスト管理と同じ規律です。大きなraw dataはmain contextの外に置き、判断に必要なものだけを移動します。

### ツール数の管理

Toolsが多いほどエージェントが有能になるわけではありません。tool定義はそれ自体がエージェントのコンテキストを消費します。さらに重複するtoolsが多すぎると、選択ミスが増え、エージェントの動きが遅くなり、権限レビューも難しくなります。

Tool setは小さく、読みやすく保ちます。

* 常に一緒に使うtoolsは統合する
* Risk levelが異なるtoolsは分ける
* Actionとscopeが分かる名前を付ける
* Experimentalなtoolsはdefault sessionから隠す
* 使われなくなったtoolsは削除する

Tool descriptionは重要です。エージェントはそれを読んで何を呼ぶかを決めます。Toolの目的、必要な入力、重要な制限を書きます。2つのtoolsのdescriptionが同じ用途に見えると、エージェントはどちらを呼ぶべきか区別できず、どちらかを恣意的に選びます。

<Note>
  MCPは連携レイヤーです。その周辺には、明確なタスク境界、リポジトリ規約、人間による検証が必要です。委任設計は[Agentic Workflow](/ja/ai/agentic-workflow)を、協働型のcoding practiceは[Vibe Coding](/ja/ai/vibe-coding)を参照してください。
</Note>

## 関連ページ

<CardGroup cols={3}>
  <Card title="Agentic Workflow" icon="diagram-project" href="/ja/ai/agentic-workflow">
    エージェントが計画、実装、検証を担う委任モデルを、人間の責任範囲と合わせて設計します。
  </Card>

  <Card title="Skill" icon="puzzle-piece" href="/ja/ai/skill">
    エージェントが必要になったときだけ読み込む、再現可能な手順と補助ファイルをまとめます。
  </Card>

  <Card title="Security" icon="shield-halved" href="/ja/ai/security">
    信頼できないツール応答がなぜ危険なのかと、読んだ内容に対してエージェントに何を許すかの設計を扱います。
  </Card>

  <Card title="Plugin" icon="box-open" href="/ja/ai/plugin">
    コマンド・エージェント・Skill・フック・MCP設定を1つの単位に束ね、チームで導入・更新できるようにします。
  </Card>
</CardGroup>