Hirosato Gamo | AI Cloud Solution Architect

MCPはLLMがツールアクセスする際の手続き(LLMがツール選択・パラメータ抽出し、そのパラメータを使ってプログラムが自分で処理したりAPIとかへリクエストを送ったりして、場合によっては結果をLLMへ返す)を標準化しどんなベンダのLLMも共通して使えるようにルール提案したもの。 MCPサーバはその手続きに準拠して作られた実際の処理をやってくれるサーバ(実態としてはその処理コード)。MCPの手続きに則ったツールアクセス方式にしてるサービスなら、このMCPサーバを介したツールアクセスが可能。CursorやらClaude DesktopはそのMCPの手続きでプロンプトもコードも書いていて、更にMCPサーバを持って来てGUIサービス上で組み込めるようにした。 こうなると、自作でMCPサーバさえ作れば色んなサービスから使えるわけで、このMCPサーバがフリーに配布されれば自分で作り込まなくても使える。 他人と自分のMCPサーバを集めて連携させれば、自分だけの最強のツールたちを持ったLLMがGUI上で使えるのですめでたしめでたし。だから今こぞって色んなMCPサーバを作って共有して盛り上がってます！…が現状。

で、このMCPサーバで書かれる「ツール利用処理」は何でも良いので、単なる足し算処理かも知れないし、検索リクエスト投げる処理かも知れないし、DBアクセス処理かもしれないし、スケジューラへの予定登録APIへのリクエスト処理かも知れない。 良く勘違いされるがRAGは「外部情報取ってきてコンテキストに付与してLLMに答えさせること」なので、RAGを実現する手続きとして、個別で作り込むかMCPに準拠した手続きがあるってだけ。なので競合するものではない。

更に重要な点は、MCPサーバがフリー化しGUIサービス上で組み込み可能になったため、見かけ上色んなツールが使えるようになったが、ツールを持たせる行為は全て今までも個別に開発することは可能だったということ。 なのでよく「MCPを使えば〇〇が可能になる」「MCPを使うと精度が上がる」という発言を見るが、これはGUIの各種サービスを使っているユーザに限った話であり、元々APIを介してLLMアプリ開発をする人間にとってはこれは誤り。MCPを使わずとも作り込みは可能だったし、何ならサービスに個別最適してない手段なので、開発効率は上がるかもしれないが何なら精度自体は落ちる。 なのでLLMエンジニアサイドはなぜここまで盛り上がってるか理解が追いつかず、この辺りの熱量格差が若干の混乱を生んでいる気がする。

結果として ◆LLMサービス利用ユーザは、MCPで色んなツールが使えるようになって盛り上がっていて、 ◆LLMエンジニアは「MCP導入で開発効率は上がるけど、ツール利用は前からできてね…？」とちょっと困惑している。 みたいな状況が発生中なのかなと…