MCPサーバーを「道具箱」として分割する考え方
連載：AIに仕事を奪われる不安から始めるハーネス作成入門
全24回（週2回・12週間）｜第7回 / 24
この連載は、AIに仕事を奪われるかもしれないという不安を「ハーネス（AIエージェント制御の仕組み）」を自分で作る行動に変えるシリーズです。
はじめに：この記事で扱う不安
「MCPサーバーをどう分割すればよいかわからない」——これは、マイクロサービス設計でも長く議論されてきた問題です。
前回（第6回）でディレクトリ構成を作りましたが、その中の mcp_servers/ に何を置くかが次の課題です。SE経験者なら「モジュール分割」や「責務分離」の考え方に馴染みがあるはずです。その経験をMCPサーバーの分割に活かしましょう。
対象読者
- SE・プログラマ経験3年以上の方
- モジュール分割やマイクロサービスの経験がある（または興味がある）方
- MCPサーバーをどう分けるか迷っている方
- 前回までの連載を読んでいる方（未読でもOK）
結論
MCPサーバーの分割は、SEが日常的に行う**「責務分離」の考え方そのまま**です。「1つのMCPサーバーに1つの責務」を原則としつつ、プロジェクトの規模やフェーズに応じて柔軟に調整するのが現実的です。
なぜこのテーマが必要なのか
MCPサーバーの分割を間違えると、以下の問題が起きます。
- 巨大サーバー問題: 1つのMCPに全機能を詰め込むと、修正時の影響範囲が広がる
- 過度な分割問題: 細かく分割しすぎると、MCP間の連携コストが增大する
- 曖昧な境界問題: どの機能がどのMCPの責務か不明確だと、重複や欠落が生まれる
SEなら、これらの問題は「モノリス的なシステム vs マイクロサービス」の議論と同じだと気づくでしょう。
既存のSE / プログラマ経験をどう活かせるか
| SE経験 | MCP分割への活用 |
|---|---|
| クラスの責務分離（SRP） | 1 MCP = 1 責務の原則 |
| マイクロサービス分割の経験 | MCP間の通信・依存関係設計 |
| API設計の経験 | 各MCPのツールインターフェース設計 |
| DBテーブル設計 | MCPが管理するデータの境界設計 |
| テスト設計 | MCP単体テストと結合テストの分離 |
MCP分割の考え方：「道具箱」メタファー
MCPサーバーを「道具箱」と考えると、分割の判断がしやすくなります。
- ドライバーセット（ネジを回す道具）: データを操作するMCP
- ノコギリセット（木を切る道具）: コンテンツを生成するMCP
- 計測ツール（測る道具）: 品質を検証するMCP
- 収納箱（物を保管する道具）: 知識を記録・検索するMCP
実際のハーネスでの分割例を見てみましょう。
MCP責務表（今回の主要成果物）
以下は、この連載のハーネスで実際に使っているMCPサーバーの責務表です。
| MCPサーバー | 責務 | 主なツール（入力） | 主な出力 | 道具箱カテゴリ |
|---|---|---|---|---|
| article_mcp | 記事の作成・管理 | テーマ、ブリーフ、アウトライン | Markdown記事 | ノコギリセット |
| knowledge_mcp | 知識の記録・検索 | ドキュメント、クエリ | 関連知識、ベクトル検索結果 | 収納箱 |
| review_mcp | 記事の品質検証 | Markdown記事 | レビュー結果、指摘事項 | 計測ツール |
| publish_mcp | 記事の投稿・公開 | 記事、タグ、承認 | 投稿URL、ステータス | ドライバーセット |
MCP間のデータフロー
分割の判断基準
「これMCPを分けるべきか？」と迷ったときの判断基準を示します。
- 変更頻度が違う → 分けるべき（例：記事作成と投稿は組み合わせが変わりやすい）
- データの所有者が違う → 分けるべき（例：知識データと記事データは別管理）
- スケールが違う → 分けるべき（例：検索は重いが記事生成は軽い）
- 常に一緒に使う → まとめてもよい（例：レビューとMarkdown検証は同じMCPでも可）
- チームが違う → 分けるべき（例：フロントエンドとバックエンド）
実装・設計時の注意点
| 注意点 | 理由 | 対策 |
|---|---|---|
| 最初から細かく分けすぎない | 個人開発でMCPが10個もあると管理できない | 3〜5個程度から始める |
| MCP間の循環依存を避ける | A→B→Aの呼び出しはデバッグ困難 | オーケストレータ経由で制御する |
| 共通データの置き場を決める | 複数MCPが同じデータを扱うと整合性問題 | schemas/に共通スキーマを定義 |
| MCPの粒度はフェーズで変わる | プロジェクト初期と成熟期で最適解が異なる | 定期的に見直すタイミングを設ける |
今回の小さな成果物（チェックリスト）
- 自分のハーネスで必要なMCPサーバーを3〜5個書き出す
- 各MCPに「責務」「主なツール」「入出力」を定義する（MCP責務表）
- MCP間のデータフローを矢印で描いてみる
- 循環依存がないか確認する
- （発展）「道具箱カテゴリ」に分類してみる
まとめ
今回は、MCPサーバーの分割を「道具箱」メタファーで考える方法を示しました。
キーポイント
- MCP分割は、SEの「責務分離」の経験がそのまま使える
- 「1 MCP = 1 責務」を原則に、3〜5個から始める
- 「道具箱」の考え方で分類すると、役割が明確になる
- 分割の判断基準は「変更頻度」「データ所有者」「スケール」の違い
- 完璧な分割を最初から目指さず、定期的に見直す
次回予告
第8回「MCPサーバーの最小実装 — FastMCPで最初のツールを作る」 では、今回設計した責務表を「動くコード」に落とし込みます。
扱う内容
- FastMCPを使ったMCPサーバーの最小実装
- health_check + 業務ツール1つの実装例
- ツールのシグネチャ設計（型ヒント・docstring・デフォルト値）
得られる成果物
- 動作する最小MCPサーバー（health_check + create_article_project）
試しておくこと
- 今回のMCP責務表を手元に置いておく（次回、article_mcpの最初のツールを実装します）
- Pythonの仮想環境（venv）を準備しておく
-
pip install mcpでFastMCPをインストールしておく
連載目次
| 回 | タイトル | 状態 |
|---|---|---|
| 第1回 | 「AIに仕事を奪われる」不安の正体を分解する | ✅ |
| 第2回 | AI時代のSE生存戦略を俯瞰する | ✅ |
| 第3回 | ハーネスとは何か？— SE経験を活かした制御構造 | ✅ |
| 第4回 | task_request / task_result — AIとの契約を定義する | ✅ |
| 第5回 | SEの設計経験をAIエージェント制御に転用する | ✅ |
| 第6回 | ハーネス用のディレクトリ構成とREADMEを作る | ✅ |
| 第7回 | MCPサーバーを「道具箱」として分割する考え方 | 📖 |
| 第8回 | MCPサーバーの最小実装 — FastMCPで最初のツールを作る | 次回 |
| 第9回 | RAG / Knowledge MCPがSE経験者に向いている理由 | ─ |
| 第10回 | 設計メモをKnowledge MCPへ登録する前提のMarkdownテンプレート | ─ |
| 第11回 | プロンプト設計の基礎 — 指示と制約を分離する | ─ |
| 第12〜24回 | （以降の回） | ─ |
連載：AIに仕事を奪われる不安から始めるハーネス作成入門
著者: @and-and-and ｜ 週2回更新
次回は「MCPサーバーの最小実装 — FastMCPで最初のツールを作る」を予定しています。