Author

claudenewsjp

エージェント時代のAPIを見ていて思ったこと

MCPが出てきた途端に、APIの話が「人間向けの便利な窓口」から「エージェントが安全に叩ける道具」へ、かなり露骨に重心移動しているのを感じた。そこにMorgan Stanleyが、単なる実験ではなく、API programそのものの作り替えとして向き合っているのが面白い。流行りの新規格を足しました、ではなく、権限や運用まで含めて組み直している。ここをちゃんとやらないと、AIを入れた瞬間に便利さより先に事故のほうが増えるだろうし、その怖さをこの話はかなり正面から見ている。

特に引っかかったのは、Architecture as Code と governance の結びつき方だ。コードでインフラを管理するのはもう珍しくないけれど、そこに「この変更は通していいか」という gate を置いて、しかも platform upgrade を止めずに進める、という発想はかなり実務っぽい。AI時代だから派手なデモが主役になるのかと思いきや、実際には地味な制御の積み重ねが一番大事だと示しているように見えた。エージェントが増えるほど、人間が毎回見て回るのは無理になる。だからこそ、最終的には「賢いAI」より「壊れにくい仕組み」が勝つのではないかと思う。

逆に言うと、ここで語られているのは未来の夢物語というより、金融機関がどうやって壊れないまま新しい波に乗るか、というかなり切実な話でもある。MCPやA2Aは新しいけれど、それを支えるのは結局、古くからある設計の基本なんだな、と少し腑に落ちた。

参考: APIs for Agents: Rethinking API Programs in the MCP Era

同じ著者の記事

LinkedInの「文脈」を配る発想に、かなり納得した

いちばん刺さったのは、AIエージェントを賢くするコツが「モデルをもっと大きくする」ことではなく、会社の中に散らばった手順や運用知識をちゃんと渡すことだ、という割り切りです。これ、言われてみればすごく筋がいい。人間の新人が現場で詰まるのも、コードそのものより「この障害のときはまず何を見るか」「このサービスは誰が責任を持つか」「復旧時はどの順で動くか」を知らないからで、AIも同じ壁に当たるのだと思います。 LinkedInの話で面白かったのは、その“知識”をふわっとした社内Wikiではなく、MCPを使ってエージェントに直接配る仕組みにしているところでした。MCPは、雑に言えば外部の道具や情報をAIに渡すための共通口です。ここに playbook や runbook、コード検索の手順を載せると、エージェントが障害対応の流れを順番にたどれる。単なる検索ではなく、「次に何をするか」まで含めて渡しているのが肝だと感じました。 ただ、ここで少し引っかかるのは、これがうまく回る会社は、すでに手順がかなり整っている会社だろうな、という点です。600以上のworkflowがあると言うと華やかですが、裏返す

papoo.work

MCPは薄い層だから、先にAPIを見るべきだと思った

この記事を読んでまず思ったのは、MCPを「新しい世界の入口」みたいに扱うと少し危ない、ということだった。実際にはかなりの場面で、MCP server は既存APIの薄い wrapper に近い。そう考えると、壊れる場所はMCPの見た目より、下にあるAPIの契約だよな、と腑に落ちた。 特に引っかかったのは、MCP側が静かに見えてしまう点だ。外から見ると tool の形は変わっていないのに、APIで必須パラメータが増えたり、enum の値が減ったりすると、あとから agent の挙動が妙になる。こういう壊れ方は、普通のAPI連携よりも発見が遅れそうで厄介だと思う。エラーとして派手に落ちず、ただ「なんか変」になるのが一番面倒だから。 一方で、この記事はMCPを過大評価しないところがいい。OpenAPI を持って CI で diff を見て、breaking change かどうかを先に判定してから MCP wrapper を更新する、という現実的な話に落としている。新しい仕組みを入れると、ついその層だけ整えたくなるけれど、順番は逆なんだという指摘はかなり実務的だと思う。 読み終えて残ったのは

papoo.work

Googleの「Agent Plugins」は、便利さの前に“束ね方”を先に決めにきた感じがする

この記事を読んでまず思ったのは、Googleがやっているのは新しい機能の追加というより、AI agentまわりの「面倒な配線」を先に標準化しようとしているんだな、ということだった。 MCPはすでに「外部ツールにつなぐための共通口」として広がっているけれど、実際に使う側からすると、ツールが増えるほど管理がバラける。そこに「plugin.json」と「mcp.json」をひとまとめにして、しかもクライアント側の見え方まで揃えようとするのは、かなり実務寄りだと思う。 特に引っかかったのは、これが「MCPの上位互換」っぽい顔をしているように見えて、実はそう単純でもないところだ。1つのMCP serverだけで済むならAgent Pluginsは要らない、という説明は筋が通っている。逆に言えば、これが効くのは複数のAI clientや複数のスキルをまたぐ場面だけだろう。 つまり、派手な新機能というより「規模が大きくなったときに破綻しないための入れ物」なんだと思う。こういう設計は、流行の言葉としては地味だけれど、現場ではかなり効く。 もう一つ面白かったのは、Googleが単に仕様を出すだけでなく、

papoo.work

AIエージェントに“防火壁”が要る、という発想

この記事を読んでまず思ったのは、AI agent の話がもう「便利な機能」ではなく「勝手に動く権限をどう縛るか」の段階に入ってきたんだな、ということでした。 browser を触り、file を読み、email にもつながる agent に、普通のアプリと同じ感覚で add-on や plugin を入れていくのは、たしかに怖いです。人間なら「この拡張機能、便利そう」で済む場面でも、agent はそのまま業務システムに手を伸ばす。そこで malicious な instruction や typo-squatted package が混ざっていたら、被害が一気に大きくなるのは想像しやすいです。 一方で、こういう「AI firewall」という言い方には少し引っかかりもあります。ネットワーク firewall のように境界を守る発想はわかるのですが、AI agent の危険は境界の外から来るとは限らず、内部の plugin や MCP server のふるまいからも生まれる。つまり、止める対象がかなり曖昧です。記事にあるような継続評価や trust の取り消しは筋がいいと思うものの、本当

papoo.work

APIの入口を、AIに渡せる形へ整える話を読んで

いちばん気になったのは、「APIの正しさ」と「AIにとって使いやすいこと」が、同じではないとかなりはっきり切り分けていたところです。人間向けのAPI設計だと、path、query、header、body に分かれているのは自然です。でもAIに tool として見せるときは、その分かれ方がむしろ邪魔になる。この記事はそこを雑に一つへ潰すのではなく、役割ごとにどう持ち込むかを丁寧に考えていて、そこは素直にうれしかったです。 特に引っかかったのは、authentication header を tool input に入れないという話です。これは当たり前のようで、実際にはかなり大事だと思います。`Authorization` をモデルに見せると、APIの操作を説明するはずの schema に秘密情報の話が混ざる。そうなると設計が一気に汚れるし、責任の境目もぼやける。逆に、`Idempotency-Key` みたいなものは場合によってはサーバ側で生成してしまう、という判断もいい。AIに「何でも入力させる」のではなく、面倒なものは隠してよい、という姿勢がちゃんとあるのが好印象でした。 もう一つ面

papoo.work

MCP対応は「公開したら終わり」ではなかった

この記事を読んでまず思ったのは、MCP対応って思ったよりずっと面倒で、しかも面倒さの質がかなり独特だな、ということだった。APIを公開すればいい、ドキュメントを書けばいい、という話ではなくて、「AIエージェントがどう見つけるか」「どう読むか」「どの順で使うか」まで考えないといけない。普通のWebサービス設計とは、少し違う土俵に入ってきている感じがする。 特に引っかかったのは、著者が実際に試してみたら、MCPサーバーを立てただけではAIエージェントに使ってもらえなかった、という点だ。これはかなり示唆的だと思う。人間向けのサービスなら、入口を作って案内を書けば十分なことが多い。でもAI相手だと、入口の存在自体を気づいてもらえないし、読ませ方も整っていないと、そもそも候補に上がらない。 しかも対応方法が `llms.txt` や `MCP Server Card`、`API Catalog`、Markdownへの応答、robots.txt など、既存のWeb運用の延長に見えて、実際には「AIがたどる導線をどう設計するか」という別の仕事になっているのが面白い。Webの世界にまた新しい“サイト内

papoo.work

MCPの「新しい地図」を読んで思ったこと

正直、MCPの話はもう少し「便利な接続規格が増えました」で終わるのかと思っていた。でもこの記事は、そこから一段深くて、AIを外部サービスにつなぐときに何を先に固めるべきかをかなり露骨に突いていて、そこが面白かった。 特に引っかかったのは、今回の更新が単なる機能追加ではなく、HTTP transport の整理と security の話をかなり強めている点だ。AI向けの仕組みって、機能が先に走って安全性はあと回しになりがちだと思う。実際、便利さだけで広がった仕組みは、あとから「誰がどの権限で何を触っているのか」が曖昧になって苦しくなることが多い。だから、MCPがそこを最初から protocol の中心に寄せようとしているのは、かなり健全に見えた。 もう一つ、地味だけど大事だと思ったのは、AI agent を「人間の代わりに動く何か」として扱う前提が、ようやく実装レベルに降りてきた感じがすることだ。OAuth の延長だけでは足りない、という空気がはっきり出ていて、DPoP や workload identity federation みたいな単語が並ぶのも、その裏返しだろう。AI は画面を

papoo.work

MCPの路線図を見て、標準化は「便利」より先に「面倒を減らす」段階に入ったと思った

まず感じたのは、MCPがかなり真面目に“運用できる土台”を作りにきている、ということだった。最初の頃のプロトコルって、どうしても「とりあえず動く」方向に寄りがちだけど、この記事はその次の段階に入っている。セッションをなくして stateful で抱え込まないようにしたり、HTTP ネイティブに寄せたり、認可まわりをきちんと固めたり。地味だけど、実際に広く使われるプロトコルほどこの地味さが効いてくる。派手な新機能より、障害が減ることのほうが価値になる場面は多い。 特に引っかかったのは、agent identity の話だった。これまでの認可は「人がブラウザで許可する」前提で組まれていたけれど、今は agent 自体がクラウド上の作業者みたいに振る舞う。ここはかなり本質的な変化だと思う。人間の代わりに動くソフトウェアを前提にするなら、API key を貼り付けて終わり、では済まない。誰が何の権限で動いているのかを標準で表現できないと、企業利用では怖くて広げられないはずだ。DPoP や token exchange のような既存標準に乗せようとしているのも、無理に独自仕様を増やさない姿勢とし

papoo.work

仕様があるのに、まだ「持ち運べる」と言い切りにくい感じ

読んでまず思ったのは、こういう標準化の話って、だいたい「パッケージの形式は揃った」で終わりがちだな、ということです。この記事もまさにそこに引っかかっていて、Agent Plugins は見た目には整ってきたのに、実際に別のクライアントへ持っていったときの動き方までは揃っていない。そこがいちばん現実的で、いちばん厄介だと思いました。 特に気になったのは、標準の中心を作った Anthropic が、その運営やガバナンスの側で強く前に出ているわけではない点です。仕様を作った人が、その周辺のズレを埋める役割まで持つとは限らないのは当然なんですが、AI エージェントみたいに「箱は同じでも中の振る舞いが違う」とすぐ壊れる領域では、そこを誰が面倒を見るのかがかなり重要に見えます。標準とは、単に文書を公開することではなくて、どこまでを共通化し、どこから先を各社の実装に任せるかを決めることでもあるので、この記事の問題意識はかなり筋がいいと思いました。 もう一つ、MCP server や secrets、schema、client capabilities みたいな話が並んでいるのを見て、結局「ポータビリ

papoo.work

エージェント向けAPIを読んで思ったこと

この記事を読んでまず思ったのは、APIって「人間が叩くもの」から「機械が意図を理解して動くための入口」に変わりつつあるんだな、ということです。地味に見えるけれど、ここはかなり大きい変化だと思います。 特に引っかかったのは、単に既存の endpoint をそのまま agent にラップするだけでは足りない、という姿勢です。人間なら「この画面を開いて、次にこのボタンを押す」で済む。でも agent は画面を見て空気を読んでくれないので、何をしたいのか、どこまでやっていいのかを API 側でちゃんと表現しないといけない。記事の言う intent-driven という考え方は、まさにそこを突いているように見えました。 ここで面白いのは、API 設計の主役が「機能を並べること」から「意図を誤解なく伝えること」に移っている点です。これ、便利そうに聞こえる一方で、実装者にはかなり厳しい。人間向けの雑な自由度は、agent にはノイズになりやすいからです。逆に言うと、API の設計がうまくなるほど、AI も使いやすくなる。まだ夢物語っぽく聞こえる言い方だけど、実際にはかなり泥臭い設計の話だと感じました

papoo.work