1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【MCPって工数削減にあんまならなくね?と捨て始めている皆様へ。】MCPロードマップとGoogleの動きから見る未来図

Posted at

はじめに

最近話題のMCP(Model Context Protocol)について、LLM界隈では日夜トピックが流れてきます。

一方で「工数削減っていっても、MCPでAPIラッピングするからトントン以下じゃない?」という声も聞こえてきて、幻滅期に入っている方も多いの方と思います。標準プロトコル対応で、取り込める機能が増えるのは嬉しいものの、LLM玄人の方ほどMCPである必要があるのか?というような疑問も持っていると思います。

本記事では、「MCPブームの背景」、「幻滅期の原因」、そしてロードマップと最近のエージェント動向から見えてきた「MCPに取り組まなけらばならない将来」についてまとめます。

最終結論ネタバレすると、「toCサービスの競争原理になる」、「AIO対策用に取り組む必要がある」ということをMCPのロードマップと最近のClaudeとGeminiの動きから考察しています

MCPとは?

MCP(Model Context Protocol)は、LLMがさまざまなツールやサービスとやり取りするための標準プロトコルです。従来のFunction Callingの仕組みを統一的な形で扱えるように設計されています。(typeCのようなものであるという写真よりしっくりきそうなのを載せておきます。)
image.png
https://blog.cloudnative.co.jp/27994/

MCPがなぜこんなにブームになったか

MCPが注目を集めた背景には、以下のような流れがあったと考えています。

1. エンジニアの開発体験の向上

開発する上で、自分で一から開発するほどでもないけど確実に欲しい機能がどんどん出てきて、それらを簡単に機能拡張できるようになりました。この手軽さと可能性の広がりに、多くのエンジニアがわくわく感を感じたのかなと思います。(最初のMCPの構想的にもここがメインのターゲット層だったというのをどこかで見ました。)

2. エンジニアの熱がXで次第に非エンジニア・企業に伝播

エンジニアたちの熱量がXを通じて広がり、企業公式のMCPが続々と登場しました。これにより、非エンジニアの方々にもMCPの良さが広がってきました。Githubなどから始まり、Figma×Cursorでどんどん加速をしていったように思います。

3. ChatGPT、Windowsの相乗り発表

リモートMCPの対応などを打ち出した3/29のプロトコルアップデート後、ChatGPTやWindowsが続々と相乗りする声明を出し、デファクトスタンダードになりそうという予測から、なったなという確信に変わったところだと思います。

しかし、LLM玄人からの冷静な視点

私自身はMCPブームに踊らされていたのですが、LLM玄人の方から、
「いろいろなLLMアプリに組み込めるけど、APIをMCPラッピングする工数の元とれる?」、
「Function Callingの時の衝撃はない」という感想を受けて、一気に幻滅期に入ってしまいました、、、

確かに、Mastra MCPサーバーやCDK MCPなど、そのまま流用できるMCPサーバーは有用で、再利用しやすいというのはとてつもない効用があります。ただ、自分たちのサービスで工数の元が取れるかというと、疑問になってくるところです。

工数削減という一本槍ではMCPの幻滅期からは抜けれそうになかったので、たくさんリサーチした結果をまとめていきます。

現時点での結論

結論として、自社に閉じたサービスであればMCPである必要はないと思います。事前定義されたツールを呼び出すだけであれば、ツールリストにAPIを呼び出す関数をセットしておくほうが都合がいいからです。

ただ、ツールリスト外から動的にツールを拾ってこれるとなるとどうでしょうか?私は、工数削減でやるやらないの話ではなくなってくると思います。

ツールリスト外からの動的なツール取得とは

まず、ツールリスト外から動的にツールを拾ってこれるとは何なのかというと、事前定義されたツールで対応しきれない場合に、MCPレジストリを見て適切なツールを拾ってくるようになるということです。
この裏付けとしては、Anthropicが公式のMCPレジストリを出そうとしており、さらにdiscovery(自動検知)にも力を入れて取り組んでいることが挙げられます。さらに、A2A(googleが4月に出したエージェント間の通信プロトコル)においても同じようなロードマップが敷かれており、相互作用で自動検知の流れが広がっていくとみています。

動的ツール取得が変える未来

以下の2つのステップで、工数でやるやらないの判断が変わっていくと思います。

①toCサービスの競争原理としてのMCP

toCサービサーも自社のサービスをレジストリに入れて、色々なエージェントから呼び出してほしいというように競争が始まり、工数を削減できるからではなく、売り上げを上げる一手段としてのMCP活動が始まるのではないでしょうか。
SaaS企業の提供形態が、AIエージェントに向けたMCPツールとしての提供になるような動きも最近のX投稿で少しずつ見かけつつあります。また、Paypal,Squareなどの企業がリモートMCPサーバーを続々と出しており、この流れが日本に来るのも遠くないのでは?と思っています。

②AIエージェントが操作する画面の中で、決済を完了させるための必須ツール

現状、Anthropicのcomputer useにおいて、MCPの補完としてブラウザ操作が存在するというような示唆が出されていたり、googleのproject marinerというブラウザ操作ツールにおいてもMCPで注文を行うような説明がありました。MCPに対応できないサイトはユーザーの要望する処理をAI経由で遂行できず、AIOで淘汰されていくようなホラーストーリーもあるのではいないでしょうか。

現在単純なSEOからAIOに切り替わりつつある中で、QAのロジックを含んでユーザーの回答に答えられるものが優先表示されるなどのロジックも少しずつ分かっていると思いますが、リサーチにおいて共通にユーザーに信頼性のある情報を提供するものが表示されています。これは、タスクを遂行するようになるAIエージェントブラウザにおける信頼性にはタスクの遂行率はかなり重要な要素になるのではないでしょうか?

Project MarinerでのGeminiによる自動購入の様子
image.png
https://deepmind.google/models/project-mariner/

まとめ

工数削減という軸においては、確かに幻滅期になってしまいます。レジストリにMCPを放り込んでおけば、AIが自動で選別してくれるくらいの性能になれば、かなり楽にはなるかもしれないが、やはりAPIをMCPラッピングする工数を上回る価値はあまり感じないかもしれません。

ただ、ChatGPT, Gemini, Claudeから変わるユーザーの消費行動の変化というところに視点を移すと、MCPは触らなければならないものに見えてくると思っております。

まだまだMCP,AIエージェントについて追い切れていないところがあると思いますので、反論あればぜひぜひお申し付けください!

1
1
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?