正しく理解するためには
はい。これ以降の記事は86％（当社計算）が概念で構成された読み物（ポエム）です。
ちゃんと理解したい人は上の情報を読んでね。〜終〜
生成AI界隈が早すぎてついていけない
はい。私もついていけません。
が、この業界、この職種で飯を食うつもりな限りわからんから知らんとは言えないので、超理解していきましょう。
その前にAIエージェントを超理解する
はい。生成AIの少し前？の流行技術です。
そもそも生成AI（以下では狭義に文章生成AIを指すこととする）はある命令（プロンプトと言いますね）に対してその特徴量を持った、命令（＝入力）とは異なる新たな出力を生み出すものです。ただし、この出力は何も制約を加えないと使い物にならないので、チャットボット利用の場合は命令に対して、「命令の回答」となるように仕向けますし、必要に応じてこの界隈の情報のみに情報源絞ったり（RAGと言ったりしますね）、命令や回答を他のソフトウェアの入出力と繋いでみたり、さらに次の生成AIに繋いでみたりと調整しています。雑に言ってしまえば、コアレベルの生成AI（ChatGPTとか）を使って組み込み的に作る生成AIはこうして出来ていますね。弊社もここ頑張ってます。はい。前段終わったのでそろそろ起きてください。
ただ、この生成AIというのもある程度作っていくと、プロンプトの「幅」への対応が難しくなってきます。うまくRAGチューニングすればするほど使い勝手は良くなるはずなんですが、一方で、「え！？こんなプロンプト想定してないんですけど！」というケースに対して弱くなります。言ってしまえば、専門性を高めていくほど、汎用性が失われてしまうわけですね。まあそりゃそうだ。
そこで出てきたのがAIエージェントという概念です。まず、少しメタレベルをあげた、取りまとめ指示役の生成AI、つまりエージェントを立てます。エージェントは人から命令を受ける役です。エージェントは命令に応えるため、何をしなきゃいけないかを考え、タスクに落とし込みます。このタスクを実行するのが今まで育ててきた「組み込み」生成AIです。つまり、エージェントはタスクを複数の生成AIに投げて集約し、回答するという振る舞いをします。これにより、タスクを受ける生成AIが特化していても問題ない、いや、多方向に特化した生成AIがあればあるほど効果的な生成AIが作れるのではないか、というものです。
具体的な（夢の？）例を挙げると、例えば、「旅行がしたい」という人間の命令があったとしましょう。エージェントは旅行するために何が必要かを考えます。その人の趣味嗜好にあう旅行先を調べるかもしれません。あと、スケジュールの空きを調べるでしょう。空きが見つかったら、旅行先の移動手段を調べたり、その価格を確認したりするでしょう。そして究極のエージェントになれば、ここが良いので旅券とホテル、予約入れておきましたよ、と回答してくれるかもしれません。
脱線：じゃあなんでAIエージェントって流行らないの？
いいえ。きっかけ待ちです。MCPは良い契機かもしれません。
何故、の超概念的回答としては、組み込み型の生成AIが目指すのが特化型だから、です。大手のChatGPT等があるのに対して、わざわざ自社で作る意味としては、99%が特化事例（特定業務特化、特定知識特化、社内情報特化、等）に対応するためです。そして、特化型を正しく作れば作るほど、プロンプトはプロダクトの特化の利用形態（≒業務内容、業務フロー）に従って制限されます。つまり、その目的上プロンプトが限られてしまうため、エージェントが必要となる複雑なタスク、特に、このケースではこのタスクがいる/いらない、タスクの実行順番が変わる、などの条件分岐が必要なものは生まれにくく、エージェント概念を持ち出すまでもないんですよね。
さて、休話閑題。
そんな夢みたいなプロダクト、作れませんかね？
いいえ。それはそれは結構な夢物語でした。何しろこんな生成AI、いや、生成AIだけじゃなくて周辺機能開発とか考えたら出来る訳がねぇ！そう、今までは。
何故そんな開発が難しいかというと、とにかく生成AI含めた作り込み量に他なりません。前述のシステム、作ろうとしたら一体どれ程のシステムつなぎこみが発生するのでしょうか？
それに対し、一つのプロダクト開発（≒作り込み）に依らない方法で機能を繋ぐ方法をMCPは提案しています。つまり、生成AIを繋ぐための取り決め＝プロトコルです。このままAIエージェントの究極を目指していくと、そのプロダクトに無限の開発が付き纏いますが、その特化した生成AIを繋ぐ取り決めを標準化しておけば同機能は再開発することなく組み合わせて作れちゃいますよ、という提案です。
Why MCP?
はい。それは実装の軽量性に尽きます。
これも事例で考えましょう。例えば天気を知るというタスクを担う（エージェントのタスクをこなす）生成AIを使いたいとします。仮に前情報が何もなければ、天気を知る方法を探すところからスタートです。そして運よく叩くと天気をとれるAPIが見つかったとしても、次にすることとしてそのAPI仕様を調べる必要に追われるでしょう。そして、都合の良い結果をとれるものが見つかったら、実装です。そして最後に待っているのが、エージェントがその実装したコードを実行できるようにすることです。API側は厳密な制約の元、こういう入力をしてね、と決められているので、生成AIが適切な出力をするよう調整を行う必要があります。ここまで書いた内容を「あーそういうことね」と実装しきれる人はそんなにいないでしょう。
それが、MCPだとどうなるか。例えば天気を知るというタスクをこなせる生成AIがありました（これをMCPサーバという）。見つかればあとは簡単です。エージェントにそのMCPサーバを知らせれば（登録すれば）良いだけです（これがMCPクライアントになります）。もう少し詳しく説明すると、MCPクライアントはMCPサーバから俺がこなせるタスク/使い方集のお品書き、例えば地域入れたら天気返すぜ、的なリスト（Tool）をいただきます。それをエージェントに読ませて、必要なタスクが出たらそのtoolから適切なやつ選んで叩いていいよ、という情報を登録します。
そして実際どう動くか。人間からプロンプトを受け取ったエージェントは、必要なタスク分解を行います。その中に天気タスクが発生したら、Toolの記載に従ってお天気MCPサーバにプロンプトを渡します。すると、生成AIの機能としてお天気の出力を返してくるでしょう。そういうプロトコルだからこそ、こんなんでできてしまう。うーん強い。
つまり？
はい。もしや今まで寝てましたね？長文で失礼しました。
つまり、AIエージェントのような他の生成AIとのやり取りを行うケースを促進するために作られたのがMCPです。これを使うと、多少の登録作業を行なってしまえばあとは生成AI同士がよしなにやり取りしてくれるので、開発がほぼいらなくなってしまいます。
その結果、組み込み的に作る生成AIの可能性が大きく広がりました。今までのありきたりな生成AIから、みたことのないプロダクトが作れることになるでしょう。また、一部の開発力のある、もしくは、自社に強いプロダクトのある会社だけが生成AIプロダクトを作れて儲けられる時代から大きくシフトチェンジするきっかけになり得ます。特に生成AIで何か新しいプロダクトを産み出そうとしている方々は今すぐMCPの理解を深めるべきでしょう。
ただし、それは開発者（≒MCPクライアント開発者）の立場での話でしかありません。一方で提供者（＝MCPサーバ開発者）からみたときのメリット・デメリットを考えてみるとどうでしょうか。例えば某○FFICEプロダクトとともにC○pilotのような生成AIプロダクトも提供する企業からすると、将来の競合生成AIプロダクトが生まれる可能性を残すようなことはしないでしょう。
それでも現在、MCP提供する企業は増えています。その狙いは何か。それはある意味オープンな外部への生成AI化開発の発注とでも言えるのではないかなと。良い生成AIが出来れば、そのプロダクトの価値向上になり得ますし、必要があればその開発をさらに取り込んで自社機能にできるかもしれません。
この辺りは企業側の戦略になりますのでよく見定める必要があります。公開しているから使っちゃお、で良いかどうか、メリットがなければ引っこめて使えなくなってしまう可能性もありますからね。
また、あなた自身がMCPサーバを開発しても良いかもしれません。これは別に世の中に公開しなくてはいけない、という話ではなく、コードの再利用を高めるためのテクニックです。特に生成AI周りを色々いじっていると、前に使ったあの仕組みまた使いたいな、であったり、前のあのPJみたいなことこっちでもやって欲しいんだけど、であったりと、同じ仕組みを何回も利活用するケースが多いことに気づきます。そこで毎回クラウドサーバ立てて開発環境を構築してもいいんですが、MCPサーバを一つ作ってしまっていれば、作るのはMCPクライアントで済むという圧倒的ショートカットが可能となります。夢が広がりますね。
ところで超理解って何？
はい。技術を技術で理解するのではなく、コンセプトで掴むこと（造語）です。目指すのは「あー完全に理解したわー（わかってない）」の境地。皆様も始めましょう、超理解。