コンテンツにスキップ
LinkedInX

AIエージェントとMCP

約10分

対象読者: AIエージェントの基本を理解しており、ツール連携の仕組みとセキュリティを学びたい方

MCP(Model Context Protocol)とは、AIアプリケーションが外部システムへ接続するためのオープン標準です。[1] エージェントがさまざまなツールを共通のプロトコルで扱えるようにすることで、ツール統合の複雑さを減らします。

AIエージェントとツール連携の課題

Section titled “AIエージェントとツール連携の課題”

AIエージェントが「行動する」ためにはツールが不可欠です。しかし従来のツール連携には以下の課題がありました。

課題内容
API仕様のばらつきツールごとに異なるリクエスト形式・認証方式・レスポンス構造
統合コストの増大新しいツールを追加するたびにカスタム実装が必要(M×N問題)
エラーハンドリングの複雑化ツールごとに異なるエラーコード・例外処理が必要
セキュリティ管理の分散各ツールの認証情報・権限管理が別々

具体的には、エージェントがWeb検索・GitHub操作・データベース照会・ファイル操作を組み合わせる場合、それぞれ異なるSDKをインポートし、異なる形式で呼び出す必要がありました。

MCPは、エージェントとツールの間に共通のプロトコル層を設けることで、上記の課題を解決します。

エージェントはMCPという「共通言語」でツールを呼び出すだけでよく、各ツールの実装の詳細はMCPサーバーが隠蔽します。

USB-Cのアナロジーが分かりやすいです。MCP公式ドキュメントも、MCPを「AIアプリケーション向けのUSB-C」のような標準接続として説明しています。[1]

エージェントがMCPを使ってツールを呼び出す全体像は以下の通りです。

graph LR
    subgraph AgentSystem["エージェントシステム"]
        Agent["エージェント\n(LLMコア)"]
        MCPClient["MCPクライアント\n(プロトコル変換)"]
        Agent <-->|"ツール呼び出し要求\n・実行結果"| MCPClient
    end

    subgraph MCPServers["MCPサーバー群"]
        FS["File System MCP\nファイル読み書き"]
        GitHub["GitHub MCP\nリポジトリ操作"]
        Browser["Puppeteer MCP\nブラウザ自動化"]
        DB["Database MCP\nDB照会・更新"]
        Search["Search MCP\nWeb検索"]
    end

    MCPClient <-->|"標準化されたMCPプロトコル"| FS
    MCPClient <-->|"標準化されたMCPプロトコル"| GitHub
    MCPClient <-->|"標準化されたMCPプロトコル"| Browser
    MCPClient <-->|"標準化されたMCPプロトコル"| DB
    MCPClient <-->|"標準化されたMCPプロトコル"| Search

MCPクライアントは、Host内でMCPサーバーとの接続を維持し、Hostが使うコンテキストを取得するコンポーネントです。[2] エージェントは統一されたプロトコルでツールを利用できます。

Claude Code は MCP をサポートしており、公式ドキュメントでは claude mcp add コマンドと、スコープに応じた設定先が説明されています。プロジェクト共有の設定はルートの .mcp.json、ユーザー別・ローカル設定は ~/.claude.json に保存されます。[3]

File System MCP(ファイルシステム操作)

Section titled “File System MCP(ファイルシステム操作)”
// .mcp.json の概念例(実際のコマンド・引数は利用するサーバーの公式手順を確認)
{
  "mcpServers": {
    "filesystem": {
      "command": "filesystem-mcp-server",
      "args": [
        "/Users/yourname/projects"
      ]
    }
  }
}

File System MCP を設定すると、エージェントは以下の操作を自律的に実行できます。

  • プロジェクトのファイル一覧を取得する
  • ファイルの内容を読み取って分析する
  • コードの修正結果をファイルに書き込む
  • ディレクトリ構造を把握して設計判断に活用する
{
  "mcpServers": {
    "github": {
      "command": "github-mcp-server",
      "args": [],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

GitHub MCP を使うと、エージェントは以下の操作を実行できます。

  • Issue の内容を参照してコードを修正する
  • Pull Requestを作成・更新する
  • リポジトリのコードを検索・分析する
  • コミット履歴を参照してバグの原因を調査する

Puppeteer/Playwright MCP(ブラウザ自動化)

Section titled “Puppeteer/Playwright MCP(ブラウザ自動化)”

Web UIのテスト・スクレイピング・動的コンテンツの取得を自動化します。

{
  "mcpServers": {
    "puppeteer": {
      "command": "browser-mcp-server",
      "args": []
    }
  }
}

PostgreSQL・SQLiteなどのデータベースへの照会・更新を標準化されたインターフェースで実行できます。

{
  "mcpServers": {
    "postgres": {
      "command": "postgres-mcp-server",
      "args": [
        "postgresql://localhost/mydb"
      ]
    }
  }
}

エージェントがMCPツールを呼び出す際の詳細なフローは以下の通りです。

sequenceDiagram
    participant U as ユーザー
    participant A as エージェント(LLM)
    participant MC as MCPクライアント
    participant MS as MCPサーバー
    participant T as 外部ツール/API

    U->>A: タスク依頼「issueを見てコードを修正して」

    A->>MC: 利用可能なツール一覧を要求
    MC->>MS: tools/list
    MS->>MC: ツール一覧(read_file, write_file, list_issues など)
    MC->>A: ツール一覧を返す

    A->>A: Reason: GitHub MCP で issue を読む

    A->>MC: tools/call: list_issues(repo="myrepo")
    MC->>MS: tools/call リクエスト
    MS->>T: GitHub API 呼び出し
    T->>MS: issue データ
    MS->>MC: ツール実行結果
    MC->>A: issue 内容を返す

    A->>A: Reason: 修正が必要なファイルを特定

    A->>MC: tools/call: read_file(path="src/auth.ts")
    MC->>MS: tools/call リクエスト
    MS->>T: ファイルシステム読み取り
    T->>MS: ファイル内容
    MS->>MC: ファイル内容
    MC->>A: ファイル内容を返す

    A->>A: Reason: 修正内容を生成

    Note over A,U: 不可逆な操作(ファイル書き込み)のため確認
    A->>U: 「以下の変更を適用しますか?」(承認リクエスト)
    U->>A: 承認

    A->>MC: tools/call: write_file(path="src/auth.ts", content="...")
    MC->>MS: tools/call リクエスト
    MS->>T: ファイル書き込み
    T->>MS: 成功
    MS->>MC: 完了
    MC->>A: 書き込み成功

    A->>U: 修正完了を報告

MCPを通じたエージェントのツール利用には、適切なセキュリティ設計が不可欠です。

エージェントが使用できるツール・操作を明示的に制限します。

// セキュリティ設定例(概念的)
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/yourname/projects/safe-dir"  // アクセス許可ディレクトリを限定
      ]
    }
  },
  "permissions": {
    "allow": [
      "filesystem/read_file",
      "filesystem/list_directory",
      "github/list_issues",
      "github/read_pull_request"
    ],
    "deny": [
      "filesystem/delete_file",    // ファイル削除は禁止
      "github/delete_repository"   // リポジトリ削除は禁止
    ]
  }
}

不可逆な操作への確認(Human-in-the-loop)

Section titled “不可逆な操作への確認(Human-in-the-loop)”

一度実行すると取り消せない操作の前には、必ず人間の確認を求める設計にします。

操作カテゴリ推奨対応
高リスク(必ず確認)ファイル削除、データベース削除、メール送信、支払い変更内容を表示して明示的な承認を要求
中リスク(確認推奨)ファイル上書き、外部APIへのPOST、設定変更変更内容のプレビューを表示
低リスク(自動実行可)ファイル読み取り、Web検索、リスト取得確認なしで実行

Claude Code には権限確認を省略する --dangerously-skip-permissions のような危険なモードがあります。通常運用では、重要な操作の確認を省略しない設計にしてください。[4]

エージェントがコードを実行する場合、本番環境に直接影響しないようサンドボックス(隔離された実行環境)内で実行します。

graph LR
    Agent["エージェント"] --> Sandbox["サンドボックス環境\n(Docker コンテナなど)"]
    Sandbox --> |"限定的なアクセスのみ"| Prod["本番環境\n(保護)"]
    Sandbox --> LocalFS["ローカルファイルシステム\n(作業用)"]
    Sandbox --> Internet["インターネット\n(必要に応じて)"]

サンドボックスでの実行例

  • コード実行はDockerコンテナ内に限定する
  • 本番データベースへの書き込みは禁止し、テスト用DBのみ使用する
  • ネットワークアクセスを必要なエンドポイントのみに制限する

MCPはオープン規格であり、コミュニティが多数のMCPサーバーを公開しています。

MCPサーバーの概念例

| カテゴリ | 提供機能の例 | |---------|------------|---------| | ファイルシステム | ファイル読み書き・ディレクトリ操作 | | バージョン管理 | Issue・PR・リポジトリ操作 | | ブラウザ | ブラウザ自動化・スクレイピング | | データベース | SQLデータベースの照会・更新 | | 検索 | 検索APIの呼び出し | | 通知 | メッセージ送信 |

MCP公式サイトにはRegistryやSDKへの導線があり、既存サーバーを探したり、独自サーバーを実装したりできます。[1]

  • MCPはAIエージェントとツール間の通信を標準化するオープン規格
  • エージェントはMCPクライアント経由で複数のMCPサーバーに接続し、ツールを統一されたインターフェースで呼び出す
  • Claude Code では公式手順に従ってMCPサーバーを追加し、プロジェクト共有なら .mcp.json、個人設定なら ~/.claude.json で管理する[3]
  • セキュリティ設計の核心は「allow/deny list」「不可逆操作への確認」「サンドボックス化」の3点
  • MCPエコシステムには多数の公式・コミュニティ製サーバーが存在し、カスタムサーバーの実装も可能

Q: MCPを使わないエージェントも作れますか?

A: はい、可能です。LLMのFunction Calling(OpenAI)やTool Use(Anthropic)機能を直接使って、MCPなしでツールを呼び出せます。MCPはツール統合を標準化するための規格であり、必須ではありません。ただし、複数ツールを使う場合はMCPを採用する方が長期的なメンテナンスが容易になります。

Q: MCPサーバーはどこで動きますか?ローカルですか?

A: ローカルサーバー(stdioトランスポート)とリモートサーバー(Streamable HTTPトランスポート)の両方があります。[2] 詳細はローカルMCPとリモートMCPの違いを参照してください。

Q: MCPサーバーへの認証情報(APIキーなど)はどう管理しますか?

A: 環境変数として注入する方法が一般的です("env": {"API_KEY": "${MY_API_KEY}"} のような形式)。APIキーをMCP設定ファイルにハードコードせず、個人用設定やローカル設定に閉じる設計にしてください。[3]

Q: 自分でMCPサーバーを作ることはできますか?

A: はい。MCP公式ドキュメントは、複数言語のSDKをMCPプロジェクトの一部として案内しています。[2] 社内の独自APIや独自データソースをエージェントから使えるようにしたい場合に有効です。

Q: MCPとAPIの違いは何ですか?

A: APIは特定のサービスへの接続インターフェースです。MCPはエージェントとツール間の通信を標準化するメタプロトコルです。MCPサーバーは内部でAPIを呼び出すことが多くあります。MCPはAPIを置き換えるものではなく、エージェントがAPIをより簡単に利用できるようにする仕組みです。

  1. Model Context Protocol, What is the Model Context Protocol?
  2. Model Context Protocol, Architecture overview
  3. Anthropic, Connect Claude Code to tools via MCP
  4. Anthropic, Claude Code security
クイズ