従来型APIがAIシステムで機能しない理由とMCPサーバーによる解決アプローチ

最近、AIエージェントの話、よく聞くけど。

自律的に動くAI。あれ、どうやって作られてるんだろうって考えてた。

で、気づいたのが... 今までのAPI、もう限界なんじゃないかってこと。ソフトウェアの作り方が、根本から変わる時期なのかも。

TL;DR

先に結論だけメモ。

従来のAPIは、決まった仕事をこなす「トランザクション」向け。でも、AIエージェントは文脈を読んで「対話」したり「思考」したりする。目的が違う。

だから、AIエージェントのために設計された新しい通信ルール、それが「Model Context Protocol (MCP)」ってことらしい。

APIベースだと、すぐ破綻する理由

API自体は、すごく優秀。それは間違いない。

CRUD操作とか、マイクロサービス間の連携とか。入力と出力がはっきり決まってる仕事なら、今でも最適解だと思う。

でも、LLMが入ってくると話が変わる。何が問題かというと...

• ステートレスすぎる: APIって基本、一回ごとのやり取りで完結する。前の会話を覚えてない。でもAIエージェントは「さっきの話の続きなんだけど…」みたいな記憶力が必要。
• 振る舞いが読めない: LLMは確率で動くから、同じ指示でも毎回同じ結果になるとは限らない。コンテキストで振る舞いが「創発」する。固定的なAPIだと、この揺らぎに対応できない。
• 連携が地獄: 複数のLLMを連携させようとすると、Pythonスクリプトとかで無理やり繋ぐことになる。LangChainとか使っても、すぐ複雑になって、デバッグも大変。スパゲッティコードの完成。
• 意図が伝わらない: こっちは「パリ行きの飛行機を予約して」って自然言語で言いたいのに、APIは`{ "destination": "CDG", "date": "2024-12-10" }`みたいな厳格な形式を求めてくる。この翻訳作業が、実はすごく難しい。

結果、メンテ不能で、脆くて、スケールしないシステムが出来上がる。心当たりある人もいるかも。

そこで出てくるのがMCP（Model Context Protocol）

なんか新しいのが出てきたな、と。

Model Context Protocol...略してMCP。これはClaudeを作ったAnthropicが提唱してる考え方らしい。さすが、LLMを深く知ってる会社は違う。

これはAPIの置き換えっていうより、もっと上位の概念。AIコンポーネント同士がどうやって「協調」するか、そのためのプロトコル。

APIが「電話」だとしたら、MCPは「共有のホワイトボードがある会議室」みたいな感じ。単に用件を伝えるんじゃなくて、同じ場所で、同じ情報を見ながら、一緒に仕事を進めるイメージ。

MCPのアーキテクチャは、ホスト、クライアント、サーバーで構成されてる。サーバーがファイルとかDBみたいなローカルデータに安全にアクセスして、それをAI（ホスト）に提供する。なかなか考えられてる。

RESTとかgRPCと、何が違うの？

じゃあ、よく使われるRESTやgRPCと比べて、MCPはどう違うのか。ちょっと整理してみる。

...こう見ると、全然違うな。MCPは「APIの新しいバージョン」じゃなくて、「AIのための、全く別のコミュニケーション方法」って考えるのが正しそう。

これ、日本だと特に大規模なシステムでマイクロサービスを細かく分けすぎて、結局サービス間の通信オーケストレーションがボトルネックになる、みたいな話はよく聞くけど...それのAI版が今まさに起ころうとしてるって感じかな。

設計思想が、そもそも違う

MCPを導入するってことは、ただ技術を変えるだけじゃない。開発者の頭の切り替えが必要になる。

• エンドポイント → エージェントの役割: `/get_user`みたいなAPIエンドポイントを設計するんじゃなくて、「リサーチ担当エージェント」「要約担当エージェント」みたいに、AIの役割とゴールを定義するようになる。
• ペイロード → 意図: `{ "user_id": 123 }`みたいな厳密なデータ構造じゃなくて、「来月のパリ出張の準備を手伝って」みたいな、もっと曖昧な「意図」を渡す。詳細はAIが対話しながら詰めていく。
• DB/セッション → メモリ: 状態を維持するためにDBを使うんじゃなくて、会話の文脈（短期記憶）や、ベクトルDB（長期記憶）みたいな「メモリ」をエージェントが直接利用する。
• シーケンス → 交渉: A→B→Cっていう一直線の処理じゃなくて、エージェント同士が「このプランはどう？」「いや、こっちの方が効率的だ」みたいに「交渉」したり、試行錯誤したりする。

もう、プログラミングっていうより、チームマネジメントに近いのかもしれない。

でも、万能じゃないよね？ [反例與誤解釐清]

ここまで聞くとMCPが最強に見えるけど、もちろんそんなことはない。

大事なのは、これが「APIの置き換え（Replacement）」ではなくて、「APIの上に立つ、より高いレベルの抽象化（Abstraction）」だということ。これは`modelcontextprotocol.io`のサイトでも言及されてる。

例えば、単純にユーザー情報をDBから取ってきて表示するだけ、みたいなタスクにMCPを使うのは、大砲でアリを撃つようなもの。過剰すぎる。そういうのは今まで通りREST APIで十分。

あと、学習コストも間違いなく高い。これは新しいパラダイムだから、チーム全体で考え方をアップデートする必要がある。テストやデバッグの方法も、今までとは全く違うアプローチが求められるはず。

だから、「なんでもかんでもMCP」じゃなくて、システムの中に自律的な「エージェント」が必要になったときに、初めて選択肢として考えるべきものなんだと思う。

まとめ：AIのための新しい土台

ソフトウェアが、単に指示を待つだけの「反応的な」ものから、自ら考えて動く「知的な」ものに変わろうとしてる。

LLMやAIエージェントが、システムの一等市民になる時代。

それなのに、古いアーキテクチャに押し込めようとしたら、そりゃ無理が出る。APIはリクエストとレスポンスの世界のために作られた。MCPは、思考と関係性の世界のために作られようとしている。

もし、次世代のAIネイティブなシステムを考えるなら...MCPサーバーは、ただの新しい選択肢じゃなくて、新しい「土台」になるのかもしれない。