自作 MCP サーバーを外注する前に決める要件書テンプレ｜スコープ・エラー処理・ログ・SLA（自動化・開発会社向け）
目次 クリックで開く
Anthropic社が公開したMCP（Model Context Protocol）は、ClaudeなどのLLM（大規模言語モデル）と社内の独自データ、あるいはSaaSを安全かつ効率的に接続するためのオープン標準として、急速に普及しています。しかし、従来のWeb API開発やスクレイピングツールの外注と同じ感覚で発注すると、「LLMがツールを正しく認識しない」「予期せぬエラーでコストが跳ね上がる」といったトラブルに直面します。
本記事では、IT実務担当者が自作MCPサーバーを開発会社や外部パートナーへ外注する際に、最低限詰めなくてはならない要件定義のテンプレートを解説します。スコープ定義からエラー処理、SLA（サービスレベル合意）まで、実務でそのまま使える構成を網羅しました。
1. MCPサーバー外注化の罠を回避する要件定義の全体像
MCPサーバーの構築を外注する際、最も重要なのは「LLMが理解しやすい形でデータと機能を公開する」という視点です。従来のシステム連携とは設計思想が根本から異なります。
1.1 MCPサーバー構築が従来のAPI開発と異なる点
従来のAPI開発では、クライアント（人間や特定のプログラム）が固定の引数を投げ、期待通りのレスポンスを返すことがゴールでした。しかし、MCPはLLMがクライアントになります。LLMは自然言語で指示を解釈し、必要だと判断した「ツール」を自律的に呼び出します。そのため、要件定義には以下の要素が含まれる必要があります。
- ツールの説明文（Description）の最適化：LLMが「いつ、なぜこのツールを使うべきか」を理解するための言語定義。
- 柔軟なスキーマ設計：LLMが生成する揺らぎのある入力に対して、どこまでサーバー側で吸収するか。
1.2 外注時に「丸投げ」が通用しない3つの理由
以下の3点を曖昧にしたまま外注すると、納品後のメンテナンスコストが肥大化します。
- データガバナンス：どのデータをLLMのプロンプト（コンテキスト）として渡し、どのデータはサーバー内で秘匿するかの判断は自社で行う必要があります。
- ビジネスロジックの所在：計算処理をLLMに任せるのか、MCPサーバー側のプログラムで実行するのかの切り分け。
- テストの定義：LLMの出力は確率的であるため、100%同じ結果が返るとは限りません。テスト合格の基準を明確にする必要があります。
2. 【要件定義テンプレ】MCPサーバー構築の必須項目一覧
外注先へのRFP（提案依頼書）や要件定義書に盛り込むべき具体的な項目を整理しました。
2.1 スコープ定義：リソース、プロンプト、ツールの役割分担
MCPには主に3つの機能セットがあります。どこまでを開発範囲に含めるかを明記します。
- Resources（リソース）：LLMが読み取り専用で参照できるデータ。DBのレコードやドキュメント。
- Tools（ツール）：LLMが実行できるアクション。データの書き込み、外部APIの実行、計算など。
- Prompts（プロンプト）：特定のタスクを実行するためのテンプレート。
例えば、社内の請求データを扱う場合、freee会計導入マニュアルにあるような会計ソフトのAPIと連携し、請求一覧を取得する「Resource」と、未入金通知を送る「Tool」をセットで構築する、といった具体的なスコープが必要です。
2.2 セキュリティ・認証要件：機密情報の保護とAPIキー管理
LLMに機密情報を渡す際のガードレール設計は、発注側が主導すべき最重要事項です。
- 認証方式：OAuth2.0、API Key、またはローカル環境でのSTDIO通信。
- データマスキング：個人情報やクレジットカード番号などをLLMに渡す前にサーバー側で置換・削除する処理。
- 環境変数の管理：AWS Secrets ManagerやGoogle Secret Manager等の利用指定。
2.3 エラー処理・リトライ戦略：LLM特有の「失敗」への対処
LLMが誤った引数をツールに渡した場合の処理を定義します。単に400エラーを返すだけでは、LLMはパニックを起こすか、無限に誤った再試行を繰り返します。
- フィードバックループ：エラーメッセージを「人間向け」ではなく「LLMが修正案を考えられる形式」で返す。
- リトライ制限：1つのタスク内でMCPサーバーを呼び出せる回数の上限設定。
2.4 ログ・モニタリング：呼び出し履歴とデバッグの設計
「なぜLLMがこのツールを呼び出したのか」を後から検証できるよう、以下のログ要件を含めます。
- 実行コンテキストの保存：呼び出し時のユーザープロンプトと、サーバーが返した生データの保存。
- パフォーマンス監視：MCPサーバーのレスポンス遅延がLLMの体験を損なわないかの監視。
3. 開発手法とインフラ選定の比較
MCPサーバーをどの技術スタックで構築するかは、保守性に直結します。現在主流の2つのアプローチと、デプロイ先の比較をまとめました。
3.1 TypeScript (Node.js) vs Python
公式のSDKが最も充実しているのはTypeScript（Node.js）です。フロントエンドとの親和性も高く、Claude Desktopでのデバッグも容易です。一方、データ解析やAIモデルとの深い連携が必要な場合はPythonが選ばれます。
3.2 インフラ構成比較表
外注先に提案を求める際の比較基準として活用してください。
| 選定軸 | Cloudflare Workers | Vercel / Next.js | AWS Lambda / App Runner | オンプレミス / 自社サーバー |
|---|---|---|---|---|
| メリット | 超低遅延、安価。MCP-SDKの公式対応が早い。 | フロントエンドと一括管理が可能。 | 既存の社内VPC資産と連携しやすい。 | セキュリティポリシーが厳しい企業に最適。 |
| コスト感 | 極めて低い（無料枠大） | 中程度（商用利用は要Proプラン） | 従量課金（リクエスト数依存） | 固定費（サーバー維持費） |
| 主な用途 | SaaS連携などの軽量なMCPサーバー | 社内ポータル一体型AIツール | 基幹システム・DB直結型 | 極秘データのバッチ処理 |
特に、モダンデータスタックとしてBigQuery等を利用している場合は、GCP環境（Cloud Runなど）にMCPサーバーを配置するのが、ネットワーク遅延とセキュリティの観点から合理的です。
4. SLAと保守運用の設計指針
MCPサーバーは構築して終わりではありません。LLM側のアップデートや、連携先SaaSの仕様変更に耐えうる運用体制を外注要件に含めるべきです。
4.1 稼働率とレスポンスタイムの目標設定
LLM（Claude等）のタイムアウト制限を考慮する必要があります。通常、MCPサーバーは10秒以内、理想的には2秒以内のレスポンスが求められます。これを大幅に超えるバッチ処理などは、非同期実行のステータス確認ツールとして設計を分けるべきです。
4.2 プロンプト変更に伴うツール定義のメンテナンス
LLM側のプロンプトが変わると、今まで正しく呼ばれていたツールが呼ばれなくなることがあります（プロンプト・ドリフト）。
外注契約には、以下の項目を含めることを推奨します。
- 定期的な精度チェック：特定の入力に対して正しいツールが選択されるかの回帰テスト。
- スキーマアップデート：連携SaaSのAPIバージョンアップに伴うメンテナンス責任。
5. 実務に導入するステップとよくあるエラー対応
実際に外注先とプロジェクトを進める際の手順と、現場で必ず遭遇するトラブルへの対処法です。
5.1 ステップバイステップの導入フロー
- PoC（概念実証）：
まずはローカル環境（Claude Desktop）で動作する最小限のMCPサーバーを構築し、業務適合性を確認する。 - プロトコル選定：
通信プロトコルとして、標準の「JSON-RPC over STDIO」か、Web経由の「SSE（Server-Sent Events）」かを選択する。 - 本番デプロイと認可設定：
サーバーをホスティングし、特定のIPアドレスやユーザーのみがアクセスできるよう認証・認可を実装する。 - 自動テストの組み込み：
MCPサーバー単体テストに加え、LLMを介したエンドツーエンド（E2E）テストの自動化。
例えば、AppSheetを活用した業務システムとMCPを連携させる場合、AppSheetのAPIを通じてデータを操作するツールをMCP側に定義することで、チャットインターフェースからのデータ更新が可能になります。
5.2 よくあるエラーとリカバリ策
- Connection Refused (STDIO)：
原因：MCPサーバーのパスが間違っている、または依存ライブラリの不足。
対処：mcp-inspectorを活用して、サーバー単体での正常起動を確認する。 - Invalid Tool Arguments：
原因：LLMが必要な引数を生成し損ねている。
対処：ツールのinputSchema(JSON Schema) のrequired項目を見直し、説明文（description）に具体例（e.g. YYYY-MM-DD形式）を追記する。 - Context Window Exceeded：
原因：MCPサーバーが返すリソースのデータ量が多すぎる。
対処：サーバー側でページネーション（分割取得）を実装し、LLMに「続きを取得しますか？」と判断させる。
6. まとめ：自社に最適なMCP環境を構築するために
MCPサーバーの外注は、単なるプログラミングの依頼ではなく、「AIが自社の手足として動くためのインターフェース」を定義する重要なプロジェクトです。本記事で紹介した要件定義テンプレを活用し、特にエラー処理とログ設計を疎かにしないことで、導入後の運用コストを劇的に下げることが可能です。
まずは社内のどの業務（経理、顧客対応、インフラ監視など）をLLMに接続すべきか、優先順位を明確にすることから始めてください。適切な要件定義こそが、AIによる業務自動化を成功させる唯一の近道です。
7. 発注前に確認すべき「MCP実装チェックリスト」と公式リソース
要件定義書を完成させる前に、開発会社との認識齟齬を防ぐための最終確認事項を整理しました。特に、開発環境（Claude Desktop）では動くものが、サーバーにデプロイした途端に動かなくなる事象は頻発します。
7.1 実装フェーズの最終チェックリスト
- 実行環境の分離：開発時の「stdio（標準入出力）」接続から、本番の「SSE（Server-Sent Events）」への切り替えコストを見込んでいるか。
- タイムアウト設計：外部APIのレスポンスが遅延した場合、LLM側がタイムアウトする前に中間レスポンスを返せる設計になっているか。
- 依存ライブラリのライセンス：MCP SDK（MIT License）以外の、ラッパーライブラリやスクレイピングツールの商用利用に問題はないか。
- サンドボックス環境の有無：書き込み系「Tool」をテストするための、本番データに影響を与えない非破壊環境が提供されているか。
7.2 技術選定の参考となる公式ドキュメント
外注先のエンジニアと技術スタックを協議する際は、以下の公式リソースをベースに会話することをお勧めします。独自実装を増やすよりも、標準SDKに準拠することが保守性を高める近道です。
8. MCPサーバーと既存の自動化ツールの役割分担
「すべての連携をMCPで行うべきか」は慎重に判断する必要があります。既存のiPaaS（MakeやZapier）や、すでに構築済みのデータ基盤がある場合、MCPサーバーは「LLMとの接点」に特化させるのが理想的です。
| 機能・役割 | MCPサーバー | iPaaS / 既存自動化ツール |
|---|---|---|
| 主な制御主体 | LLM（自律的な判断） | 定義済みのワークフロー（定型処理） |
| 得意なタスク | 非定型なデータ抽出、文脈に応じたツール実行 | 大量データの定期バッチ、確実なトリガー実行 |
| セキュリティ | プロンプトインジェクション対策が必要 | 静的なAPIキー/トークン管理 |
| 推奨される用途 | AIチャットからの「動的」な操作 | システム間の「静的」なデータ同期 |
例えば、BigQueryやdbtを用いたモダンデータスタックを導入済みの場合、MCPサーバーはBigQueryに対して自然言語でクエリを投げるインターフェースとして機能させることで、高額なCDPを導入せずとも高度なデータ活用が可能になります。
また、広告運用などの複雑な最適化が必要な領域では、CAPIとBigQueryを組み合わせたアーキテクチャをMCP経由で操作できるように設計することで、マーケターがチャット上から直接、高度な分析と施策実行を行えるようになります。
ご相談・お問い合わせ
本記事の内容を自社の状況に当てはめたい場合や、導入・運用の設計を一緒に整理したい場合は、当社までお気軽にご相談ください。担当より折り返しご連絡いたします。