近年、ChatGPTやClaudeなどの生成AI（人工知能）を自社の業務システムや外部データベースと連携させ、高度なタスクを自動化する動きが急速に進んでいます。AIに社内データを検索させたり、外部のAPI（システム同士を連携させる窓口）を呼び出して操作させたりする「ツール連携」は、AI活用を次のステージに進めるためのキーテクノロジーです。
そうした中、Anthropic社が発表した「MCP（Model Context Protocol：モデル・コンテキスト・プロトコル）」というオープン標準規格が大きな注目を集めました。これは「あらゆるAIと外部ツールを共通の手順で簡単につなぐための万能な規格」として期待され、多くのエンジニアや企業が導入を検討し始めています。
しかし、海外の技術コミュニティでは「MCPは最初から筋が悪いアイデアだったのではないか（Why MCP was always a bad idea）」という強い疑問を投げかける議論が沸き起こり、大きな話題を呼びました。
「とりあえず標準規格だから導入しよう」と飛びつくと、かえってシステムの構造が複雑になり、セキュリティや応答速度の問題に頭を抱えることになるかもしれません。
この記事では、MCPに関する議論の背景をひも解きながら、AIと外部ツールを連携させる際の課題、そして実務で失敗しないための「導入・設計・運用ガイド」を分かりやすく解説します。専門用語も丁寧に噛み砕いて説明しますので、現場のエンジニアだけでなく、AIシステムの導入を検討しているプロダクトマネージャーや技術責任者の方も、ぜひ「自分ごと」として参考にしてください。
MCP（Model Context Protocol）とは何か？従来のツール連携との違い
まず背景として、MCPとは何なのか、そしてこれまで行われていたツール連携と何が違うのかを整理しておきましょう。
従来のツール連携：「関数呼び出し（Function Calling）」
これまでのAIアプリ開発において、AIに外部ツールを使わせる代表的な手法は「関数呼び出し（Function Calling）」でした。
これは、開発者がAIに対して「以下のような機能（関数）が利用可能です」とあらかじめプログラムの仕様書（ルール）を文章（プロンプト）で教えておき、AIが「今はこの機能を使ってほしい」と判断したら、指定された形式のデータ（JSON形式など）を返してくれる仕組みです。アプリ側はその指示を受け取り、実際のデータベース検索やWebリクエストを実行して結果をAIに送り返します。
この方式はシンプルで直感的ですが、「AIごとに書き方や接続コードを毎回作る必要がある」という手間がありました。
MCP：共通のプラグでつなぐ標準規格
そこで登場したのが「MCP（Model Context Protocol）」です。
MCPは、AI本体（クライアント）と、外部のデータ源やツール（サーバー）との間の「通信ルール」を共通化しようという試みです。家電製品で例えるなら、メーカーごとにバラバラだったコンセントの形状を全世界で統一し、どのAIであっても、MCPに対応したツール（MCPサーバー）であれば「差し込むだけで即使える」ようにしようという発想です。
一見すると、非常に便利で理想的な仕組みに見えます。では、なぜこの仕組みに対して「筋が悪い」という批判の声が上がっているのでしょうか。
なぜ「MCPは筋が悪いアイデア」と言われるのか？実務での課題と懸念
エンジニアのMaharshi Patel氏によるブログ記事「Why MCP was always a bad idea」や、技術掲示板Hacker Newsでの議論では、MCPの設計思想や実務での適用において、いくつかの本質的な問題点が指摘されています。主な懸念点を平易に解説します。
1. 構造の複雑化（オーバーエンジニアリング）
従来の「関数呼び出し」であれば、自社のアプリケーションコードの中に数行の処理を書くだけで完了していたような単純なAPI連携であっても、MCPを採用する場合は「独立したMCPサーバー」を立ち上げて管理しなければなりません。
通信の手順やプロトコルを共通化するために層（レイヤー）を増やした結果、システムの構造が無駄に複雑になり、開発・運用のコストが跳ね上がってしまうという問題があります。「壁に1つの小さな穴を開ければ済む話なのに、わざわざ巨大なトンネルと管理事務所を作っているようなものだ」という批判です。
2. セキュリティ境界の曖昧化とリスク
AIにツール権限を与える際、最も恐ろしいのが「プロンプトインジェクション」と呼ばれる攻撃です。これは、第三者が悪意ある命令を文章の中に紛れ込ませ、AIを騙して意図しない操作を実行させる攻撃手法です。
MCPのように、AIが外部のMCPサーバーと動的に通信して権限やツールを自動的に取得する仕組みでは、「どこまでが安全で、どこからが危険なのか」というセキュリティの境界線があいまいになりがちです。もしメール送信ツールやデータベース削除ツールがMCP経由で繋がっていた場合、悪意ある指示によって不必要なデータの流出や非破壊的操作が行われてしまう危険性が高まります。
3. コンテキスト（背景情報）の過剰な肥大化とコスト増
AIが正しくツールを選ぶためには、各ツールの詳しい説明文や使用ルールをAIの記憶領域（コンテキストウィンドウ）に読み込ませる必要があります。
MCPサーバーが多くのツールやコンテキストを提供するようになると、AIに送る指示文（プロンプト）が非常に長くなります。AIの利用料金は処理した文字数（トークン数）に応じて課金されるため、使わないツールの説明まで毎回送信することで「利用料金が高騰する」「AIのレスポンスが遅くなる」という問題が発生します。
4. WEBの基本原則（ステートレス）との相性の悪さ
現代のWebシステム（REST APIなど）の多くは、通信ごとに完結する「ステートレス（状態を持たない）」な設計で作られており、これがシステムの高い拡張性や信頼性を支えています。
しかし、MCPの初期仕様や実装では、接続を維持し続ける「ステートフル（状態を保持する）」な通信を前提としている場合があり、クラウド環境（サーバーレス環境など）でのスケールアウト（負荷分散）が難しくなるという課題も指摘されています。
実務で失敗しない「MCP・ツール連携」の導入・設計・運用ガイド
これらの批判は「MCPという概念すべてが不要だ」という意味ではありません。重要なのは、「何でもかんでもMCPにすれば良いわけではない」という事実を理解し、用途に合わせて適切な設計を選ぶことです。
実務でAIと外部ツールの連携を構築する際、どのように設計・運用すべきか、具体的なガイドラインをまとめました。
ガイド1：ユースケースに応じて「直接連携」と「MCP」を使い分ける
ツール連携を行う際は、まず「本当にMCPが必要か？」を吟味しましょう。
-
従来の「関数呼び出し＋直接API連携」を選ぶべきケース：
- 作成するAIアプリが1つ（または少数）で、連携したいツールやAPIが明確に決まっている場合。
- 応答速度（レイテンシ）を最優先したい場合。
- システム構成をシンプルに保ち、保守コストを下げたい場合。
- 結論： ほとんどの自社専用AIアプリ開発では、従来の方式の方がシンプルで安全です。
-
「MCP」の導入を検討してもよいケース：
- 社内に数百種類のツールがあり、様々な異なるAIクライアント（Claude Desktop、自社内製チャットボット、CursorなどのAIエディタ）から共通のツール群を動的に呼び出したい場合。
- プラットフォームとして「サードパーティ（他社）にツール開発を開放したい」場合。
- 結論： 開発基盤やエコシステム全体を標準化したいフェーズに適しています。
ガイド2：セキュリティ設計の徹底（最小権限と人間の確認）
AIにツールを連携させる際は、AIを「100%信用できるオペレーター」として扱ってはいけません。以下のセキュリティ対策を必ず組み込みましょう。
- 最小権限の原則： AIに与えるAPIキーやアクセス権限は必要最小限にします。「データの参照（READ）」のみを許可し、「更新・削除（WRITE/DELETE）」の権限は原則として与えない、または別の安全なプロセスに分離します。
- Human-in-the-Loop（人間の介在）： メールの送信、資金移動、データの削除など、取り返しのつかない操作をAIが要求した場合は、必ず人間の画面に確認ポップアップを出し、人間がボタンを押さないと実行されない仕組み（承認フロー）を挟みます。
- 入力のサニタイズ（害の除去）： 外部から取得したテキストデータに悪意ある命令（プロンプトインジェクション）が含まれている可能性を常にと考慮し、AIに渡す前に危険な文字列をフィルタリングします。
ガイド3：コンテキスト最適化による高速化とコスト削減
AIのプロンプトを無駄に太らせないための設計工夫も欠かせません。
- 動的なツール読み込み： 用意されているすべてのツールの定義を最初からAIに渡すのし、ユーザーの入力内容に応じて「関連しそうなツールのみ」を検索・選択してプロンプトに注入する仕組み（メタツールやRAGの技術を活用）を構築します。
- レスポンスの要約と絞り込み： ツールが返した検索結果（JSONデータなど）をそのまま巨大な生のデータのままAIに投げ返すのではなく、必要な項目だけに絞り込んだり、要約したりしてからAIに渡すことで、トークン数の消費を劇的に抑えることができます。
ガイド4：堅牢なモニタリングとエラーハンドリング
AIは時として、ツールの仕様を無視したデータ形式を出力したり、存在しないツールを呼び出そうとしたり（ハルシネーション：幻覚）します。
- 厳密なスキーマチェック： AIが出力したツールの呼び出し命令が、あらかじめ定義したデータ形式（型や必須項目）に合致しているかをプログラミング言語側で厳密にチェック（バリデーション）します。形式が崩れている場合は、エラーメッセージとともにAIに自動で再試行（リトライ）させます。
- 実行ログの全件保存： 「いつ、どのユーザーの操作によって、AIがどのツールをどのような引数で呼び出したか」をすべてログとして記録し、後から追跡できるようにしておきます。
注意点と未確認事項
この記事で紹介した議論や設計ガイドを実務に適用するにあたり、以下の点に注意してください。
- 仕様の急速な進化： MCP（Model Context Protocol）は現在進行形で開発・議論が進められている比較的新しい規格です。初期に指摘されていたパフォーマンスやセキュリティ上の課題、通信プロトコルの仕様（HTTP/SSE対応など）は、今後のアップデートによって急速に改善される可能性があります。
- 未確認事項について： 元記事（Maharshi Patel氏のブログ）およびHacker Newsの議論では、MCPの概念的・建築学的な課題が主に論じられています。特定のMCPサーバー実装における定量的（数値的）なベンチマークテスト結果（「レスポンスが〇〇ミリ秒遅くなる」「トークン数が〇〇%増える」などの具体的数値データ）については、元記事内には詳細な記載がないため未確認となります。導入時は自社の環境で実際の性能測定（ベンチマーク）を行うことを強く推奨します。
まとめ：流行に流されず、最適なアーキテクチャを選ぼう
新しい技術や標準規格が登場すると、私たちはついつい「これがこれからのデファクトスタンダード（標準）だ」と考えて、すべてのシステムに適用したくなってしまいます。
しかし、今回取り上げたMCPを巡る議論が教えてくれるのは、**「優れた抽象化や標準規格が、必ずしもすべての開発現場にとっての最適解とは限らない」**というソフトウェア開発の原点です。
- 単体のAIアプリや、用途が明確な社内ツール： シンプルで扱いやすい「関数呼び出し（Function Calling）」と直接的なAPI連携を選ぶ。
- 複数のAIと多数のツールが入り乱れる大型プラットフォーム： 課題を理解した上で、標準化の恩恵を受けるために「MCP」の採用を検討する。
大切なのは、話題の技術の表面的な便利さだけに目を奪われず、セキュリティ、コスト、運用保守のしやすさといった「実務でのリアルな課題」を見極めることです。自社のシステムの規模と目的に合わせた最適なツール連携アーキテクチャを選択し、安全で快適なAI活用を進めていきましょう。