#プロトコル

AIエージェントやチャットアプリが、外部のデータベースや社内ツール、ファイル操作、検索機能とつながる場面が増えている。その接続を共通化しようとしているのが Model Context Protocol、略して MCP だ。元記事は、そのMCPが実際にどんな順番でメッセージをやり取りしているのかを、プロトコルの中身に踏み込んで説明している。表面的な「MCP対応」ではなく、どこでアプリが動き、どこでモデルが判断し、どこでサーバーが応答するのかを追えるのが面白い。 元記事はまず、MCPを「AIアプリを、そのアプリが使う tools や data とつなぐための open standard」と定義している。重要なのは、モデルがサーバーと直接しゃべるわけではない、という点だ。Claude、Cursor、ChatGPT、あるいは agent のようなホスト側のAIアプリが前面に立ち、サーバーは「自分に何ができるか」をアプリに提示する。アプリはその内容をモデルに見せる。モデルは、その中から使いたいものを選ぶ。実際にサーバーへ問い合わせて結果を受け取るのはアプリで、モデル自身がネットワーク先へ直結する

この記事を読んでいちばん気になったのは、AI agents の話なのに、実際には「全部を agent と呼ばないほうが設計しやすい」とはっきり言っているところだった。そこがかなり好感触だった。最近は何でも agent に寄せた説明をよく見るけれど、この記事はむしろ逆で、MCP は capability へのアクセス、A2A は責任の委譲、ACP はその歴史的な経緯、というふうに線を引いている。こういう整理の仕方のほうが、実装する側にはずっと役に立つと思う。 特に MCP を「道具につなぐための契約」として扱っているのがわかりやすい。ファイルを読む、DB を引く、内部 API を叩く。そういうのまで全部「別の agent です」と言い始めると、たしかに identity や state や orchestration が無駄に重くなる。この記事の言い方を借りるなら、そこは agent ではなく tool で十分だ、という感覚だと思う。現場ではこの切り分けを雑にすると、あとから timeout も権限も監視もぐちゃぐちゃになりそうで、読んでいて少し冷や汗が出た。 もう一つ印象に残ったのは、

この記事を読んでまず思ったのは、MCPって派手な機能よりも、地味なメタ情報の積み重ねでかなり賢く見えるようになるんだな、ということだった。ツールを公開する仕組みとして見ると、名前と説明と入力スキーマがあれば最低限は足りそうに見える。でも実際には、クライアントが安心して使えるかどうかは、その先の「このツールは壊すのか、繰り返しても平気か、結果はどんな形で返るのか」といった周辺情報でかなり変わる。そこを丁寧に書けるのが面白い。 特に印象に残ったのは、tool annotations の考え方だ。`readOnlyHint` や `destructiveHint` みたいな値は、機能そのものを増やすわけではない。でも、クライアント側の振る舞いをかなり変えられる。たとえば、確認ダイアログを出すタイミングや、ユーザーに見せる並び順まで変わるかもしれない。ここで大事なのは、著者もはっきり書いているように、これはあくまで hint であって安全装置ではないことだと思う。AI 系の仕組みって、つい「賢く振る舞わせる」話に寄りがちだけど、最終的には認可や検証を別で持たないと危ない。その線引きを曖昧にしな

MCP（Model Context Protocol）は、AIエージェントが外部のツールやファイル、サービスにアクセスするための共通ルールだ。ざっくり言うと、「AIに何をどう頼むか」を標準化するための通信規格である。 今回の元記事が面白いのは、単なる機能追加の話ではなく、MCPの骨格そのものが変わったと指摘しているところだ。いちばん大きいのは、これまで前提だった「セッションを持ち続ける」方式をやめたこと。これでMCPは、かなりHTTPらしい、軽くて扱いやすい形に寄ってきた。 2026-07-28仕様で、MCPはセッション前提の stateful な設計をやめた これにより、sticky session や共有Redisのような面倒な運用が減る OAuth / OIDC の安全性が強化された tool list や prompt list などにキャッシュ期限を持たせられるようになった Tasks は正式な extension として整理され、長い処理を扱いやすくなった 主要SDKはすでに対応しており、MCPはかなり大規模に使われている 元記事の中心はここ