# コアアーキテクチャ

MCPがクライアント、サーバー、およびLLMをどのように接続するかを理解する

Model Context Protocol (MCP)は、柔軟で拡張性のあるアーキテクチャに基づいており、LLMアプリケーションと統合の間でシームレスな通信を可能にします。このドキュメントは、コアアーキテクチャコンポーネントと概念をカバーしています。

## [概要](https://modelcontextprotocol.io/docs/concepts/architecture#overview)

MCPはクライアント・サーバーアーキテクチャを採用しています。以下がその構成です：

- **ホスト**は接続を開始するLLMアプリケーション（例えばClaude DesktopやIDE）
- **クライアント**はホストアプリケーション内のサーバーとの1:1接続を維持
- **サーバー**はクライアントにコンテキスト、ツール、プロンプトを提供


![image.png](https://api.apidog.com/api/v1/projects/837383/resources/351903/image-preview)

## [コアコンポーネント](https://modelcontextprotocol.io/docs/concepts/architecture#core-components)

### [プロトコル層](https://modelcontextprotocol.io/docs/concepts/architecture#protocol-layer)

プロトコル層はメッセージフレーミング、リクエスト/レスポンスのリンク、および高度な通信パターンを扱います。

- TypeScript
- Python

```typescript
class Protocol<Request, Notification, Result> {
    // 受信リクエストの処理
    setRequestHandler<T>(schema: T, handler: (request: T, extra: RequestHandlerExtra) => Promise<Result>): void

    // 受信通知の処理
    setNotificationHandler<T>(schema: T, handler: (notification: T) => Promise<void>): void

    // リクエストを送信し、レスポンスを待つ
    request<T>(request: Request, schema: T, options?: RequestOptions): Promise<T>

    // 一方向通知を送信
    notification(notification: Notification): Promise<void>
}
```

主要クラスには以下が含まれます：

- `Protocol`
- `Client`
- `Server`

### [トランスポート層](https://modelcontextprotocol.io/docs/concepts/architecture#transport-layer)

トランスポート層は、クライアントとサーバー間の実際の通信を処理します。MCPは複数のトランスポートメカニズムをサポートしています：

1. **Stdioトランスポート**
   - 通信に標準入力/出力を使用
   - ローカルプロセスに最適
2. **HTTPとSSEトランスポート**
   - サーバーからクライアントへのメッセージにServer-Sent Eventsを使用
   - クライアントからサーバーへのメッセージにHTTP POSTを使用

すべてのトランスポートはメッセージ交換に[JSON-RPC](https://www.jsonrpc.org/) 2.0を使用します。MCPメッセージフォーマットの詳細については[仕様](https://spec.modelcontextprotocol.io/)を参照してください。

### [メッセージタイプ](https://modelcontextprotocol.io/docs/concepts/architecture#message-types)

MCPには以下の主要なメッセージタイプがあります：

1. **リクエスト** は相手側からの応答を期待します：

   ```typescript
   interface Request {
     method: string;
     params?: { ... };
   }
   ```

2. **結果** はリクエストに対する成功した応答です：

   ```typescript
   interface Result {
     [key: string]: unknown;
   }
   ```

3. **エラー** はリクエストが失敗したことを示します：

   ```typescript
   interface Error {
     code: number;
     message: string;
     data?: unknown;
   }
   ```

4. **通知** は応答を期待しない一方向のメッセージです：

   ```typescript
   interface Notification {
     method: string;
     params?: { ... };
   }
   ```

![image.png](https://api.apidog.com/api/v1/projects/837383/resources/351904/image-preview)
## [接続ライフサイクル](https://modelcontextprotocol.io/docs/concepts/architecture#connection-lifecycle)

### [1. 初期化](https://modelcontextprotocol.io/docs/concepts/architecture#1-initialization)

サーバークライアントサーバークライアント接続使用の準備完了initializeリクエストinitializeレスポンスinitialized通知

1. クライアントはプロトコルバージョンと機能を伴う`initialize`リクエストを送信
2. サーバーはそのプロトコルバージョンと機能で応答
3. クライアントは確認として`initialized`通知を送信
4. 通常のメッセージ交換が開始

### [2. メッセージ交換](https://modelcontextprotocol.io/docs/concepts/architecture#2-message-exchange)

初期化後、以下のパターンがサポートされます：

- **リクエスト-レスポンス**: クライアントまたはサーバーがリクエストを送信し、相手が応答
- **通知**: いずれの側も一方向メッセージを送信

### [3. 終了](https://modelcontextprotocol.io/docs/concepts/architecture#3-termination)

いずれの側も接続を終了できます：

- `close()`によるクリーンな終了
- トランスポートの切断
- エラー条件

## [エラー処理](https://modelcontextprotocol.io/docs/concepts/architecture#error-handling)

MCPは以下の標準エラーコードを定義します：

```typescript
enum ErrorCode {
  // 標準JSON-RPCエラーコード
  ParseError = -32700,
  InvalidRequest = -32600,
  MethodNotFound = -32601,
  InvalidParams = -32602,
  InternalError = -32603
}
```

SDKとアプリケーションは-32000以上の独自のエラーコードを定義できます。

エラーは以下を通じて伝播されます：

- リクエストへのエラーレスポンス
- トランスポートのエラーイベント
- プロトコルレベルのエラーハンドラ

## [実装例](https://modelcontextprotocol.io/docs/concepts/architecture#implementation-example)

以下はMCPサーバーを実装する基本的な例です：

- TypeScript
- Python

```typescript
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

const server = new Server({
  name: "example-server",
  version: "1.0.0"
}, {
  capabilities: {
    resources: {}
  }
});

// リクエスト処理
server.setRequestHandler(ListResourcesRequestSchema, async () => {
  return {
    resources: [
      {
        uri: "example://resource",
        name: "Example Resource"
      }
    ]
  };
});

// トランスポート接続
const transport = new StdioServerTransport();
await server.connect(transport);
```

## [ベストプラクティス](https://modelcontextprotocol.io/docs/concepts/architecture#best-practices)

### [トランスポートの選択](https://modelcontextprotocol.io/docs/concepts/architecture#transport-selection)

1. **ローカル通信**
   - ローカルプロセスにはstdioトランスポートを使用
   - 同一マシンでの通信に最適
   - 単純なプロセス管理
2. **リモート通信**
   - HTTP互換が必要なシナリオにはSSEを使用
   - 認証と承認を含むセキュリティインプリケーションを考慮

### [メッセージ処理](https://modelcontextprotocol.io/docs/concepts/architecture#message-handling)

1. **リクエスト処理**
   - 入力を徹底的に検証
   - 型安全なスキーマを使用
   - エラーを優雅に処理
   - タイムアウトを実装
2. **進行状況の報告**
   - 長時間の操作には進行状況トークンを使用
   - 進行状況を逐次報告
   - 総進行状況がわかっている場合は含める
3. **エラー管理**
   - 適切なエラーコードを使用
   - 有用なエラーメッセージを含める
   - エラー時にリソースをクリーンアップ

## [セキュリティの考慮事項](https://modelcontextprotocol.io/docs/concepts/architecture#security-considerations)

1. **トランスポートのセキュリティ**
   - リモート接続にはTLSを使用
   - 接続元を検証
   - 必要な場合は認証を実装
2. **メッセージの検証**
   - すべての受信メッセージを検証
   - 入力をサニタイズ
   - メッセージサイズの制限を確認
   - JSON-RPC形式を確認
3. **リソース保護**
   - アクセス制御を実装
   - リソースパスを検証
   - リソース使用状況を監視
   - リクエストを制限
4. **エラー処理**
   - センシティブな情報を漏らさない
   - セキュリティ関連のエラーをログ
   - 適切なクリーンアップを実行
   - DoSシナリオに対応

## [デバッグとモニタリング](https://modelcontextprotocol.io/docs/concepts/architecture#debugging-and-monitoring)

1. **ロギング**
   - プロトコルイベントをログ
   - メッセージフローをトラッキング
   - パフォーマンスを監視
   - エラーを記録
2. **診断**
   - ヘルスチェックを実装
   - 接続状態を監視
   - リソース使用状況をトラック
   - パフォーマンスをプロファイル
3. **テスト**
   - さまざまなトランスポートをテスト
   - エラー処理を確認
   - エッジケースをチェック
   - サーバーを負荷テスト