【Anthropic Academy】MCP上級編 完全ガイド ― 本番運用のためのMCP実践テクニック

MCP: Advanced Topics ってどんなコース？

「MCP: Advanced Topics」は、Anthropic Academyの技術系コースの中でも最も高度な内容を扱う上級者向けコースです。MCPの入門コース「Introduction to MCP」を修了した開発者が次に進むべきコースとして位置づけられています。

入門コースでは「MCPとは何か」「ツール・リソース・プロンプトの3つのプリミティブ」「簡単なサーバーの作り方」を学びました。この上級コースでは、その知識を土台に本番環境で動くMCPサーバーを構築・運用するための実践的なテクニックを体系的に学びます。

認証とセキュリティ、Sampling（サーバーからAIに補完をリクエストする仕組み）、マルチサーバーオーケストレーション、パフォーマンス最適化、テスト手法、デプロイ戦略、MCPクライアントの自作まで。「MCPで何かを作ってみた」レベルから「MCPを本番で安全に運用できる」レベルへの飛躍に必要なすべてがここにあります。

MCPの基本概念を復習しよう

上級トピックに入る前に、入門コースで学んだMCPの基本概念を簡潔に振り返ります。ここが曖昧だと上級の内容が理解しにくくなるため、しっかり確認しておきましょう。

MCPとは何か

MCP（Model Context Protocol）は、AIモデル（Claude等）と外部のツールやデータソースを接続するためのオープンスタンダードなプロトコルです。「AIにとってのUSB-C」と例えられることが多く、1つの統一規格であらゆる外部システムと繋がれることを目指しています。

3つのプリミティブ

MCPは3つの基本的なプリミティブ（構成要素）を提供します。

• Tools（ツール） ― AIが呼び出せる「関数」。データベースのクエリ、APIの呼び出し、ファイル操作などのアクションを実行する
• Resources（リソース） ― AIが読み取れる「データソース」。ファイルの内容、データベースのスキーマ、設定情報などを提供する
• Prompts（プロンプト） ― 事前定義された「指示テンプレート」。特定のワークフロー向けの定型的な指示をサーバー側で用意しておける

クライアント-サーバーアーキテクチャ

MCPはクライアント-サーバーモデルで動作します。MCPクライアント（Claude Desktop, Claude Code等のホストアプリケーション）がMCPサーバーに接続し、サーバーが提供するツール・リソース・プロンプトを利用します。

┌──────────────────┐     ┌──────────────────┐     ┌──────────────────┐
│   AIモデル       │     │  MCPクライアント  │     │  MCPサーバー     │
│  (Claude等)      │ ←→ │  (ホストアプリ)   │ ←→ │  (ツール提供)    │
│                  │     │                  │     │                  │
│  推論・生成      │     │  接続管理        │     │  外部API接続     │
│  ツール呼び出し  │     │  権限制御        │     │  データ変換      │
│  判断            │     │  ユーザーUI      │     │  ビジネスロジック │
└──────────────────┘     └──────────────────┘     └──────────────────┘

コースで学ぶ上級トピック

ここからが本題です。MCP: Advanced Topics で学ぶ各トピックを、コード例を交えながら詳しく解説していきます。

認証とセキュリティ

本番環境でMCPサーバーを動かす場合、認証とセキュリティは最も重要な課題です。入門コースで作ったMCPサーバーはローカル環境で動かすだけだったので認証は不要でしたが、本番では「誰がこのサーバーにアクセスしているか」「このユーザーはこのツールを使う権限があるか」を厳密に管理する必要があります。

OAuth 2.0 による認証フロー

MCPサーバーの認証でよく使われるのがOAuth 2.0です。ユーザーが外部サービス（GitHub, Google, Slack等）にログインしている認証情報をMCPサーバーに委譲する仕組みです。

// MCPサーバーでのOAuth認証ミドルウェアの例
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";

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

// 認証ミドルウェアの設定
function authenticateRequest(req) {
  const token = req.headers?.authorization?.replace("Bearer ", "");
  if (!token) {
    throw new Error("認証トークンがありません");
  }

  // トークンの検証（JWT検証、データベース照合など）
  const user = verifyToken(token);
  if (!user) {
    throw new Error("無効なトークンです");
  }

  return user;
}

// ツールごとのアクセス制御
server.tool(
  "delete-record",
  "データベースからレコードを削除する",
  { recordId: { type: "string", description: "削除するレコードID" } },
  async (args, extra) => {
    const user = authenticateRequest(extra.request);

    // 管理者権限チェック
    if (!user.roles.includes("admin")) {
      return {
        content: [{ type: "text", text: "エラー: この操作には管理者権限が必要です" }],
        isError: true,
      };
    }

    // 実際の削除処理
    await database.delete(args.recordId);
    return {
      content: [{ type: "text", text: `レコード ${args.recordId} を削除しました` }],
    };
  }
);

APIキーの安全な管理

MCPサーバーは外部APIと連携することが多いため、APIキーの管理が重要です。コースではAPIキーをソースコードに直接書かない方法と、環境変数やシークレット管理サービスの使い方が解説されます。

// ❌ 絶対にやってはいけない
const API_KEY = "sk-abc123...";

// ✅ 環境変数から読み取る
const API_KEY = process.env.EXTERNAL_API_KEY;
if (!API_KEY) {
  throw new Error("EXTERNAL_API_KEY 環境変数が設定されていません");
}

// ✅ さらに安全: シークレット管理サービスを使う
import { SecretManagerServiceClient } from "@google-cloud/secret-manager";
const client = new SecretManagerServiceClient();

async function getApiKey() {
  const [version] = await client.accessSecretVersion({
    name: "projects/my-project/secrets/external-api-key/versions/latest",
  });
  return version.payload.data.toString();
}

入力バリデーションとサニタイズ

MCPサーバーが受け取るツール引数は、必ずバリデーション（検証）とサニタイズ（無害化）を行います。AIモデルからの入力であっても信頼せず、すべての入力を検証するのが鉄則です。

import { z } from "zod";

// Zodスキーマで入力を厳密に定義
const QuerySchema = z.object({
  tableName: z.string()
    .regex(/^[a-zA-Z_][a-zA-Z0-9_]*$/, "テーブル名に不正な文字が含まれています")
    .max(64, "テーブル名が長すぎます"),
  limit: z.number()
    .int()
    .min(1, "最小1件")
    .max(1000, "最大1000件")
    .default(100),
  where: z.string()
    .max(500, "WHERE句が長すぎます")
    .optional(),
});

server.tool(
  "query-database",
  "データベースにクエリを実行する",
  QuerySchema.shape,
  async (args) => {
    // Zodで自動バリデーション
    const validated = QuerySchema.parse(args);

    // SQLインジェクション対策: パラメータ化クエリを使用
    const result = await db.query(
      `SELECT * FROM ?? WHERE ? LIMIT ?`,
      [validated.tableName, validated.where, validated.limit]
    );
    return { content: [{ type: "text", text: JSON.stringify(result) }] };
  }
);

Sampling ― サーバーからAIに補完をリクエストする

MCPの上級トピックの中で最もユニークで強力な機能がSampling（サンプリング）です。通常のMCPの流れは「AIモデル → MCPサーバー」という一方通行ですが、SamplingではMCPサーバーからAIモデルに対して「補完（テキスト生成）をリクエストする」ことができます。

Samplingの仕組み

通常のMCPフロー（AIがサーバーのツールを呼ぶ）に加えて、Samplingでは逆方向のリクエストが発生します。

通常のフロー:
  AIモデル  →  MCPクライアント  →  MCPサーバー
  「このツールを呼んで」→「ツール実行結果を返す」

Samplingのフロー（逆方向が追加）:
  MCPサーバー  →  MCPクライアント  →  AIモデル
  「このテキストを生成して」→「生成結果を返す」

つまり、MCPサーバーのツール処理の途中で「この判断はAIにやってもらいたい」「この要約はAIに生成してもらいたい」というケースに対応できます。

Samplingの実装例

例えば、データベースから取得した大量のログを分析して、異常を検知するMCPサーバーを考えてみましょう。

server.tool(
  "analyze-logs",
  "直近のログを分析して異常を検知する",
  {
    timeRange: { type: "string", description: "分析期間（例: '1h', '24h'）" },
    severity: { type: "string", description: "最低重要度（info/warn/error）" },
  },
  async (args, extra) => {
    // 1. データベースからログを取得
    const logs = await fetchLogs(args.timeRange, args.severity);

    // 2. ログが大量にある場合、AIに要約・分析を依頼（Sampling）
    if (logs.length > 100) {
      const analysisRequest = {
        messages: [
          {
            role: "user",
            content: {
              type: "text",
              text: `以下の${logs.length}件のサーバーログを分析してください。
異常パターン、エラーの傾向、推奨アクションをまとめてください。

ログデータ:
${formatLogs(logs)}`,
            },
          },
        ],
        modelPreferences: {
          hints: [{ name: "claude-sonnet-4-20250514" }],
        },
        maxTokens: 2000,
      };

      // MCPクライアント経由でAIモデルに補完をリクエスト
      const analysis = await extra.sampling.createMessage(analysisRequest);

      return {
        content: [
          { type: "text", text: `## ログ分析結果（${logs.length}件を分析）\n\n` },
          { type: "text", text: analysis.content.text },
        ],
      };
    }

    // ログが少ない場合はそのまま返す
    return {
      content: [{ type: "text", text: formatLogs(logs) }],
    };
  }
);

マルチサーバーオーケストレーション

実際の業務環境では、1つのMCPサーバーですべてを賄うことは稀です。GitHub用、データベース用、Slack用、監視用など、複数のMCPサーバーを連携させるのが一般的な構成です。

この「複数のMCPサーバーをどう構成し、どう連携させるか」がマルチサーバーオーケストレーションのテーマです。

マルチサーバー構成の設定例

Claude Desktopでの複数MCPサーバー設定例を見てみましょう。

// claude_desktop_config.json
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "ghp_xxxxxxxxxxxx"
      }
    },
    "database": {
      "command": "node",
      "args": ["./mcp-servers/database-server.js"],
      "env": {
        "DB_HOST": "localhost",
        "DB_NAME": "production"
      }
    },
    "slack": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-slack"],
      "env": {
        "SLACK_BOT_TOKEN": "xoxb-xxxxxxxxxxxx"
      }
    },
    "monitoring": {
      "command": "node",
      "args": ["./mcp-servers/monitoring-server.js"],
      "env": {
        "SENTRY_DSN": "https://xxxx@sentry.io/yyyy",
        "DATADOG_API_KEY": "ddxxxxxxxxxxxx"
      }
    }
  }
}

サーバー間の依存関係と起動順序

マルチサーバー構成では、サーバー間の依存関係を意識する必要があります。例えば、監視サーバーがデータベースサーバーの正常稼働を前提としている場合、起動順序を制御しなければなりません。

// サーバー起動マネージャーの例
class McpServerManager {
  constructor() {
    this.servers = new Map();
    this.dependencies = new Map();
  }

  // 依存関係を定義
  addServer(name, config, dependsOn = []) {
    this.servers.set(name, config);
    this.dependencies.set(name, dependsOn);
  }

  // 依存関係の順序で起動
  async startAll() {
    const started = new Set();
    const startOrder = this.topologicalSort();

    for (const serverName of startOrder) {
      // 依存サーバーがすべて起動済みか確認
      const deps = this.dependencies.get(serverName) || [];
      for (const dep of deps) {
        if (!started.has(dep)) {
          throw new Error(
            `${serverName} の依存先 ${dep} が起動していません`
          );
        }
      }

      console.log(`[起動] ${serverName}...`);
      await this.startServer(serverName);
      started.add(serverName);
      console.log(`[完了] ${serverName} が起動しました`);
    }
  }

  // トポロジカルソートで起動順序を決定
  topologicalSort() {
    // ...（依存関係のグラフをソート）
  }
}

// 使用例
const manager = new McpServerManager();
manager.addServer("database", dbConfig);
manager.addServer("github", ghConfig);
manager.addServer("monitoring", monitorConfig, ["database"]);
manager.addServer("notification", notifyConfig, ["monitoring", "github"]);

await manager.startAll();
// 起動順序: database → github → monitoring → notification

名前空間の衝突を避ける

複数のMCPサーバーが同じ名前のツールを提供していると衝突が起きます。コースではサーバーごとにプレフィックス（名前空間）を付与する設計パターンが紹介されます。

// ❌ 衝突する命名
// GitHub サーバー: "search" ツール
// データベースサーバー: "search" ツール
// → AIモデルがどちらの "search" を呼ぶべきか混乱する

// ✅ 名前空間で衝突を回避
// GitHub サーバー: "github_search" ツール
// データベースサーバー: "db_search" ツール
// → 明確に区別できる

パフォーマンス最適化

MCPサーバーが本番環境で多くのリクエストを処理する場合、パフォーマンスの最適化が不可欠です。レスポンスが遅いとAIモデルの応答全体が遅くなり、ユーザー体験に直結します。

キャッシュ戦略

頻繁にアクセスされるが更新頻度の低いデータはキャッシュすることで、外部APIへのリクエスト数を大幅に削減できます。

// TTL（有効期限）付きキャッシュの実装例
class McpCache {
  constructor() {
    this.cache = new Map();
  }

  get(key) {
    const entry = this.cache.get(key);
    if (!entry) return null;

    // 有効期限チェック
    if (Date.now() > entry.expiresAt) {
      this.cache.delete(key);
      return null;
    }
    return entry.value;
  }

  set(key, value, ttlMs) {
    this.cache.set(key, {
      value,
      expiresAt: Date.now() + ttlMs,
    });
  }
}

const cache = new McpCache();

server.tool(
  "get-user-profile",
  "ユーザープロフィールを取得する",
  { userId: { type: "string" } },
  async (args) => {
    const cacheKey = `user:${args.userId}`;

    // キャッシュから取得を試みる
    const cached = cache.get(cacheKey);
    if (cached) {
      return {
        content: [{
          type: "text",
          text: `[キャッシュ] ${JSON.stringify(cached)}`,
        }],
      };
    }

    // キャッシュにない場合はAPIから取得
    const profile = await externalApi.getUser(args.userId);

    // 5分間キャッシュ
    cache.set(cacheKey, profile, 5 * 60 * 1000);

    return {
      content: [{ type: "text", text: JSON.stringify(profile) }],
    };
  }
);

バッチ処理

複数のリクエストをまとめて処理することで、外部APIへの呼び出し回数を削減します。

// バッチ処理の例: 複数ユーザーの情報を一括取得
server.tool(
  "get-team-members",
  "チームメンバーの情報を一括取得する",
  {
    userIds: {
      type: "array",
      items: { type: "string" },
      description: "ユーザーIDの配列",
    },
  },
  async (args) => {
    // ❌ 1件ずつリクエスト（N+1問題）
    // for (const id of args.userIds) {
    //   const user = await api.getUser(id);  // N回のAPIコール
    // }

    // ✅ バッチAPIで一括取得（1回のAPIコール）
    const users = await api.getUsersBatch(args.userIds);

    return {
      content: [{
        type: "text",
        text: JSON.stringify(users, null, 2),
      }],
    };
  }
);

接続プーリング

データベースや外部APIへの接続を使い回す（プーリング）ことで、接続の確立と切断にかかるオーバーヘッドを削減します。

import { Pool } from "pg";

// 接続プールの設定
const pool = new Pool({
  host: process.env.DB_HOST,
  database: process.env.DB_NAME,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD,
  max: 20,            // 最大接続数
  idleTimeoutMillis: 30000,  // アイドル接続のタイムアウト
  connectionTimeoutMillis: 5000, // 接続タイムアウト
});

server.tool(
  "query",
  "SQLクエリを実行する",
  { sql: { type: "string" }, params: { type: "array" } },
  async (args) => {
    // プールから接続を取得（使い終わったら自動で返却）
    const result = await pool.query(args.sql, args.params);
    return {
      content: [{
        type: "text",
        text: JSON.stringify(result.rows, null, 2),
      }],
    };
  }
);

// サーバー終了時にプールをクリーンアップ
process.on("SIGTERM", async () => {
  await pool.end();
  process.exit(0);
});

エラーハンドリングパターン

本番環境では「正常に動くこと」だけでなく「異常時にどう振る舞うか」が極めて重要です。MCPサーバーのエラーハンドリングには、通常のサーバーアプリケーションとは異なる特有の考慮点があります。

構造化されたエラーレスポンス

MCPサーバーでエラーが発生した場合、AIモデルが理解できる形でエラー情報を返す必要があります。

// 構造化エラーハンドリングの例
class McpToolError extends Error {
  constructor(code, message, details = {}) {
    super(message);
    this.code = code;
    this.details = details;
  }
}

// エラーの種類を定義
const ErrorCodes = {
  VALIDATION_ERROR: "VALIDATION_ERROR",
  AUTH_ERROR: "AUTH_ERROR",
  RATE_LIMIT: "RATE_LIMIT",
  EXTERNAL_API_ERROR: "EXTERNAL_API_ERROR",
  TIMEOUT: "TIMEOUT",
  NOT_FOUND: "NOT_FOUND",
};

server.tool(
  "fetch-data",
  "外部APIからデータを取得する",
  { endpoint: { type: "string" } },
  async (args) => {
    try {
      const data = await callExternalApi(args.endpoint);
      return {
        content: [{ type: "text", text: JSON.stringify(data) }],
      };
    } catch (error) {
      // エラーの種類に応じた構造化レスポンス
      if (error.status === 429) {
        return {
          content: [{
            type: "text",
            text: `[エラー: レート制限] APIのリクエスト制限に到達しました。
${error.retryAfter}秒後に再試行してください。
対処法: 時間をおいてから再度このツールを呼び出してください。`,
          }],
          isError: true,
        };
      }

      if (error.status === 404) {
        return {
          content: [{
            type: "text",
            text: `[エラー: 未検出] エンドポイント "${args.endpoint}" が見つかりません。
利用可能なエンドポイント: /users, /repos, /issues`,
          }],
          isError: true,
        };
      }

      // 予期しないエラー（内部詳細は漏洩させない）
      console.error("予期しないエラー:", error);
      return {
        content: [{
          type: "text",
          text: `[エラー: 内部エラー] 予期しない問題が発生しました。
管理者に連絡してください。エラーID: ${generateErrorId()}`,
        }],
        isError: true,
      };
    }
  }
);

リトライとサーキットブレーカー

外部APIが一時的に不安定な場合に自動リトライを行い、長時間の障害時にはサーキットブレーカーで過剰なリトライを防ぐパターンです。

// サーキットブレーカーの実装例
class CircuitBreaker {
  constructor(options = {}) {
    this.failureThreshold = options.failureThreshold || 5;
    this.resetTimeout = options.resetTimeout || 60000; // 1分
    this.failureCount = 0;
    this.state = "CLOSED";       // CLOSED = 通常, OPEN = 遮断, HALF_OPEN = 試行
    this.lastFailureTime = null;
  }

  async execute(fn) {
    // OPEN状態: リクエストを即座に拒否
    if (this.state === "OPEN") {
      if (Date.now() - this.lastFailureTime > this.resetTimeout) {
        this.state = "HALF_OPEN"; // タイムアウト後に試行状態へ
      } else {
        throw new Error(
          "サーキットブレーカー OPEN: 外部サービスが利用不可です。" +
          `${Math.ceil((this.resetTimeout - (Date.now() - this.lastFailureTime)) / 1000)}秒後に再試行します`
        );
      }
    }

    try {
      const result = await fn();
      // 成功したらカウンターをリセット
      this.failureCount = 0;
      this.state = "CLOSED";
      return result;
    } catch (error) {
      this.failureCount++;
      this.lastFailureTime = Date.now();

      if (this.failureCount >= this.failureThreshold) {
        this.state = "OPEN";
        console.warn(
          `サーキットブレーカー OPEN: ${this.failureCount}回連続失敗`
        );
      }
      throw error;
    }
  }
}

// 使用例
const apiBreaker = new CircuitBreaker({
  failureThreshold: 3,
  resetTimeout: 30000,
});

server.tool("get-status", "外部サービスの状態を取得", {}, async () => {
  const result = await apiBreaker.execute(() => externalApi.getStatus());
  return { content: [{ type: "text", text: JSON.stringify(result) }] };
});

MCPサーバーのテスト手法

MCPサーバーは外部システムとAIモデルの間に位置するため、テストの設計に工夫が必要です。コースではユニットテスト、統合テスト、E2Eテストの3段階でのテスト戦略が解説されます。

ユニットテスト ― ツールのロジックを単体テスト

// ツールのビジネスロジックを分離してテスト
// src/tools/user-tools.js
export function formatUserProfile(rawData) {
  return {
    name: rawData.full_name || "不明",
    email: rawData.email_address,
    role: rawData.is_admin ? "管理者" : "一般ユーザー",
    lastLogin: new Date(rawData.last_login_at).toLocaleDateString("ja-JP"),
  };
}

// tests/user-tools.test.js
import { describe, it, expect } from "vitest";
import { formatUserProfile } from "../src/tools/user-tools.js";

describe("formatUserProfile", () => {
  it("正常なデータを正しくフォーマットする", () => {
    const result = formatUserProfile({
      full_name: "田中太郎",
      email_address: "tanaka@example.com",
      is_admin: true,
      last_login_at: "2026-04-07T10:00:00Z",
    });
    expect(result.name).toBe("田中太郎");
    expect(result.role).toBe("管理者");
  });

  it("名前がnullの場合は「不明」を返す", () => {
    const result = formatUserProfile({
      full_name: null,
      email_address: "test@example.com",
      is_admin: false,
      last_login_at: "2026-04-07T10:00:00Z",
    });
    expect(result.name).toBe("不明");
  });
});

統合テスト ― MCPプロトコルレベルでのテスト

// MCP SDKのテストユーティリティを使用
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { InMemoryTransport } from "@modelcontextprotocol/sdk/inMemory.js";
import { Client } from "@modelcontextprotocol/sdk/client/index.js";

describe("MCPサーバー統合テスト", () => {
  let server;
  let client;

  beforeEach(async () => {
    server = createMyMcpServer(); // テスト対象のサーバー

    // インメモリトランスポートで接続（ネットワーク不要）
    const [clientTransport, serverTransport] = InMemoryTransport.createLinkedPair();

    await server.connect(serverTransport);
    client = new Client({ name: "test-client", version: "1.0.0" });
    await client.connect(clientTransport);
  });

  it("ツール一覧を正しく返す", async () => {
    const tools = await client.listTools();
    expect(tools.tools).toContainEqual(
      expect.objectContaining({ name: "get-user-profile" })
    );
  });

  it("ツールを正しく実行する", async () => {
    const result = await client.callTool({
      name: "get-user-profile",
      arguments: { userId: "test-user-1" },
    });
    expect(result.isError).toBeFalsy();
    expect(result.content[0].text).toContain("test-user-1");
  });

  it("無効な引数でエラーを返す", async () => {
    const result = await client.callTool({
      name: "get-user-profile",
      arguments: { userId: "" }, // 空文字列
    });
    expect(result.isError).toBe(true);
  });
});

本番環境へのデプロイ戦略

MCPサーバーのデプロイ方法は、トランスポートの種類によって大きく異なります。コースではstdioベースのローカルデプロイから、HTTP/SSEベースのリモートデプロイまで、段階的にカバーされます。

ローカルデプロイ（stdio）

最もシンプルなデプロイ方法です。MCPサーバーをローカルのプロセスとして起動し、標準入出力（stdio）でクライアントと通信します。

# npm パッケージとして配布するパターン
npm publish @your-org/mcp-server-custom

# ユーザーはclaude_desktop_config.jsonで以下のように設定
{
  "mcpServers": {
    "custom": {
      "command": "npx",
      "args": ["-y", "@your-org/mcp-server-custom"],
      "env": {
        "API_KEY": "your-api-key"
      }
    }
  }
}

リモートデプロイ（HTTP + SSE）

チーム全体で共有するMCPサーバーや、クラウドサービスと連携するサーバーは、HTTPサーバーとしてデプロイします。Server-Sent Events（SSE）を使ったストリーミング通信が標準的です。

// HTTP + SSEでのMCPサーバーデプロイ例
import express from "express";
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { SSEServerTransport } from "@modelcontextprotocol/sdk/server/sse.js";

const app = express();
const server = new McpServer({
  name: "remote-mcp-server",
  version: "1.0.0",
});

// ツールの定義
server.tool("ping", "サーバーの生存確認", {}, async () => ({
  content: [{ type: "text", text: "pong" }],
}));

// SSEエンドポイント
app.get("/sse", async (req, res) => {
  const transport = new SSEServerTransport("/messages", res);
  await server.connect(transport);
});

// メッセージ受信エンドポイント
app.post("/messages", async (req, res) => {
  // SSEトランスポートがメッセージを処理
});

const PORT = process.env.PORT || 3000;
app.listen(PORT, () => {
  console.log(`MCPサーバーがポート ${PORT} で起動しました`);
});

Dockerコンテナでのデプロイ

# Dockerfile
FROM node:20-slim

WORKDIR /app

# 依存関係のインストール
COPY package*.json ./
RUN npm ci --production

# アプリケーションコードのコピー
COPY src/ ./src/

# ヘルスチェック
HEALTHCHECK --interval=30s --timeout=5s --retries=3 \
  CMD curl -f http://localhost:3000/health || exit 1

# 非rootユーザーで実行
USER node

EXPOSE 3000

CMD ["node", "src/index.js"]

# docker-compose.yml（複数MCPサーバーの構成例）
version: "3.8"

services:
  mcp-github:
    build: ./mcp-servers/github
    environment:
      - GITHUB_TOKEN=${GITHUB_TOKEN}
    ports:
      - "3001:3000"
    restart: unless-stopped

  mcp-database:
    build: ./mcp-servers/database
    environment:
      - DB_HOST=postgres
      - DB_NAME=production
    depends_on:
      - postgres
    ports:
      - "3002:3000"
    restart: unless-stopped

  mcp-monitoring:
    build: ./mcp-servers/monitoring
    environment:
      - SENTRY_DSN=${SENTRY_DSN}
    depends_on:
      - mcp-database
    ports:
      - "3003:3000"
    restart: unless-stopped

  postgres:
    image: postgres:16
    environment:
      - POSTGRES_DB=production
      - POSTGRES_PASSWORD=${DB_PASSWORD}
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

MCPクライアントの実装

MCPの上級トピックとして、サーバーだけでなくクライアント側の実装も学びます。Claude DesktopやClaude Codeは既製のMCPクライアントですが、独自のアプリケーションにMCPクライアント機能を組み込むことで、自分だけのAIツール統合環境を構築できます。

// カスタムMCPクライアントの実装例
import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StdioClientTransport } from "@modelcontextprotocol/sdk/client/stdio.js";

async function createMcpClient(serverCommand, serverArgs) {
  const transport = new StdioClientTransport({
    command: serverCommand,
    args: serverArgs,
  });

  const client = new Client({
    name: "my-custom-client",
    version: "1.0.0",
  });

  await client.connect(transport);
  return client;
}

// クライアントを使ってMCPサーバーの機能を利用
async function main() {
  const client = await createMcpClient("node", ["./my-mcp-server.js"]);

  // 利用可能なツール一覧を取得
  const { tools } = await client.listTools();
  console.log("利用可能なツール:");
  tools.forEach((tool) => {
    console.log(`  - ${tool.name}: ${tool.description}`);
  });

  // ツールを実行
  const result = await client.callTool({
    name: "get-user-profile",
    arguments: { userId: "user-123" },
  });
  console.log("結果:", result.content[0].text);

  // リソースを取得
  const { resources } = await client.listResources();
  for (const resource of resources) {
    const data = await client.readResource({ uri: resource.uri });
    console.log(`リソース ${resource.name}:`, data.contents[0].text);
  }

  // 接続を終了
  await client.close();
}

main().catch(console.error);

高度なトランスポート設定

MCPのトランスポート（クライアントとサーバーの通信方式）には、stdioとHTTP/SSEの2つがあります。上級コースではそれぞれの特性を理解し、ユースケースに応じて選択・設定する方法を学びます。

HTTPトランスポートの認証付き設定

// 認証付きHTTPトランスポートの設定例
import { SSEServerTransport } from "@modelcontextprotocol/sdk/server/sse.js";
import express from "express";
import cors from "cors";
import helmet from "helmet";

const app = express();

// セキュリティヘッダーの設定
app.use(helmet());

// CORSの設定（必要なオリジンのみ許可）
app.use(cors({
  origin: ["https://your-app.example.com"],
  methods: ["GET", "POST"],
}));

// Bearer認証ミドルウェア
function authMiddleware(req, res, next) {
  const token = req.headers.authorization?.split(" ")[1];
  if (!token || !isValidToken(token)) {
    return res.status(401).json({ error: "認証が必要です" });
  }
  req.user = decodeToken(token);
  next();
}

// ヘルスチェック（認証不要）
app.get("/health", (req, res) => {
  res.json({ status: "ok", uptime: process.uptime() });
});

// MCP接続（認証必要）
app.get("/sse", authMiddleware, async (req, res) => {
  console.log(`[接続] ユーザー: ${req.user.name}`);
  const transport = new SSEServerTransport("/messages", res);
  await server.connect(transport);
});

app.post("/messages", authMiddleware, express.json(), async (req, res) => {
  // メッセージ処理
});

実践アーキテクチャ例 ― 企業内での複数MCPサーバー構成

ここまでの個別トピックを統合して、実際の企業環境でのMCPアーキテクチャの全体像を見てみましょう。

┌─────────────────────────────────────────────────────────────┐
│                     開発者のワークステーション                │
│                                                             │
│  ┌─────────────┐                                           │
│  │ Claude Code  │ ← MCPクライアント（ホストアプリ）         │
│  │             │                                           │
│  │ ┌─────────┐ │     stdio       ┌────────────────────┐   │
│  │ │MCP Client├─┼────────────────→│ ローカルMCPサーバー │   │
│  │ └────┬────┘ │                  │ (ファイル操作等)    │   │
│  │      │      │                  └────────────────────┘   │
│  └──────┼──────┘                                           │
│         │ HTTP/SSE                                          │
└─────────┼───────────────────────────────────────────────────┘
          │
          ▼ (社内ネットワーク)
┌─────────────────────────────────────────────────────────────┐
│                     社内MCPサーバー群                         │
│                                                             │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐     │
│  │ GitHub MCP   │  │ Jira MCP     │  │ Confluence   │     │
│  │ サーバー     │  │ サーバー     │  │ MCPサーバー  │     │
│  │              │  │              │  │              │     │
│  │ ・PR管理     │  │ ・チケット   │  │ ・ドキュメント│     │
│  │ ・コードレビュー│ │ ・スプリント │  │ ・ナレッジ   │     │
│  │ ・Issue管理  │  │ ・バックログ │  │ ・検索       │     │
│  └──────┬───────┘  └──────┬───────┘  └──────┬───────┘     │
│         │                 │                 │               │
│         ▼                 ▼                 ▼               │
│  ┌──────────────────────────────────────────────────┐      │
│  │              認証・認可ゲートウェイ               │      │
│  │         (OAuth 2.0 + RBAC + 監査ログ)           │      │
│  └──────────────────────────────────────────────────┘      │
│                                                             │
│  ┌──────────────┐  ┌──────────────┐                        │
│  │ データベース  │  │ 監視・通知    │                        │
│  │ MCPサーバー  │  │ MCPサーバー  │                        │
│  │              │  │              │                        │
│  │ ・クエリ実行 │  │ ・Sentry連携 │                        │
│  │ ・スキーマ   │  │ ・Slack通知  │                        │
│  │ ・マイグレーション│ │ ・メトリクス│                        │
│  └──────────────┘  └──────────────┘                        │
│                                                             │
└─────────────────────────────────────────────────────────────┘

このアーキテクチャの利点は、各MCPサーバーが単一責任を持つことです。GitHubサーバーはGitHub操作のみに専念し、データベースサーバーはデータベース操作のみに専念する。サーバーの追加・削除・更新が他のサーバーに影響しないため、マイクロサービスアーキテクチャの考え方がそのまま適用できます。

受講のコツ ― 実際にMCPサーバーを本番デプロイしてみる

このコースを最大限に活かすためのコツを紹介します。上級コースだからこそ、「聞いて終わり」ではなく「手を動かして実感する」ことが不可欠です。

コツ1: 入門で作ったサーバーを「本番レベル」に改修する

Introduction to MCPで作った簡単なサーバーがあるはずです。そのサーバーに、このコースで学ぶ認証、バリデーション、エラーハンドリング、テストを追加してみましょう。ゼロから作るより、既存のサーバーを改修するほうが「何が足りなかったか」を実感できます。

コツ2: 実際のAPIに接続するサーバーを作る

ダミーデータではなく、実際の外部API（GitHub API, Notion API, OpenWeather API等）に接続するMCPサーバーを作ってみてください。実際のAPIに接続すると、レート制限、認証、エラーハンドリングの必要性を身をもって体験できます。

コツ3: テストを先に書く（TDD）

コースで学ぶテスト手法を使って、新しいツールを追加する前にテストを先に書いてみましょう。テストファーストで開発すると、ツールの仕様（入力は何か、出力は何か、エラー時はどうなるか）を事前に明確化でき、設計品質が上がります。

コツ4: docker-compose で複数サーバー構成を試す

マルチサーバー構成は、手元のdocker-composeで実際に動かすのが最も理解が深まります。GitHub + データベース + 通知の3サーバー構成を作り、AIモデルから横断的なタスクを実行してみてください。「こういう連携ができるのか！」という発見があるはずです。

学習パス全体のまとめ ― 技術系コースの集大成として

MCP: Advanced Topicsは、Anthropic Academyの技術系コースの集大成に位置します。ここに到達するまでの学習パスを振り返り、このコースの位置づけを確認しましょう。

このコースを修了すると、以下のスキルが身に付きます。

• セキュアなMCPサーバーの設計 ― OAuth認証、RBAC、入力バリデーション、シークレット管理を含む本番品質のサーバーを設計・実装できる
• Samplingの活用 ― サーバー処理の途中でAIモデルに補完をリクエストする高度なパターンを実装できる
• マルチサーバー構成の設計 ― 複数のMCPサーバーを連携させ、企業規模のアーキテクチャを設計できる
• パフォーマンスの最適化 ― キャッシュ、バッチ処理、接続プーリングを適切に使い分けられる
• 堅牢なエラーハンドリング ― 構造化エラー、リトライ、サーキットブレーカーを実装できる
• テストの設計と実装 ― ユニットテスト、統合テスト、E2Eテストの3段階でMCPサーバーをテストできる
• 本番デプロイ ― Dockerコンテナ化、HTTP/SSEトランスポート、ヘルスチェックを含むデプロイを実施できる
• MCPクライアントの実装 ― 独自のアプリケーションにMCPクライアント機能を組み込める

まとめ ― MCPを「知っている」から「使いこなす」へ

MCP: Advanced Topicsは、MCPの入門知識を持つ開発者が本番環境で通用するMCPサーバーを構築・運用する力を身につけるためのコースです。

• 対象: Introduction to MCPを修了した開発者。実際にMCPサーバーを構築した経験があるとさらに良い
• 所要時間: 約2〜3時間。修了証あり
• 核心トピック:
  • 認証・セキュリティ（OAuth, RBAC, 入力バリデーション, シークレット管理）
  • Sampling（サーバーからAIに補完をリクエスト）
  • マルチサーバーオーケストレーション（複数サーバーの連携・依存管理）
  • パフォーマンス最適化（キャッシュ, バッチ処理, 接続プーリング）
  • エラーハンドリング（構造化エラー, リトライ, サーキットブレーカー）
  • テスト手法（ユニット, 統合, E2E）
  • デプロイ戦略（stdio, HTTP/SSE, Docker）
  • MCPクライアントの自作
  • 高度なトランスポート設定
• 最大の収穫: 「動くサーバー」と「本番で安全に動くサーバー」の差を理解し、その差を埋めるための具体的な手法を習得できる
• 受講のコツ: 入門で作ったサーバーを本番品質に改修する。実際のAPIに接続する。docker-composeでマルチサーバー構成を試す

MCPはまだ新しいプロトコルですが、AIとツールの連携は今後ますます重要になります。このコースで学ぶ設計パターンやセキュリティの考え方は、MCPに限らずあらゆるAIツール統合の基盤になるでしょう。