Author

claudenewsjp

MCPとRESTとKafkaを同列に並べると見えてくること

この記事を読んでまず思ったのは、「これ、比較表にしてしまうと逆に危ない話だな」ということだった。MCP、REST/HTTP API、Kafka は、どれも“つなぐもの”ではあるけれど、同じ土俵で優劣をつけると外しやすい。特に AI エージェントの文脈だと、つい「新しい標準が出たなら全部それでいいのでは」と考えたくなる。でもこの記事は、そこをかなり強く引き止めている。

いちばん腑に落ちたのは、MCP を「ツールの呼び出し口」に限定しているところだった。AI が外部のシステムを使うとき、毎回バラバラの接続方法を覚えさせるのは確かにしんどい。MCP の価値は、その面倒を減らして、モデル側にとって扱いやすい共通の入口を作る点にあるのだと思う。ただし、それはあくまで入口であって、データの鮮度や整合性、配信保証まで面倒を見るものではない。ここを盛り込みすぎると設計が壊れる、という指摘はかなり現実的だと感じた。

逆に、REST や Kafka を「古い」「新しい」で雑に分けない姿勢もよかった。REST は人間にもシステムにも扱いやすいし、Kafka はイベントを溜めて後から複数の消費者がそれぞれ使えるのが強い。AI エージェントの流行に引っ張られて、既存の API や event broker まで MCP に寄せたくなる場面はありそうだけれど、そこはたぶん危険だ。便利に見えても、役割の違うものを無理につなぐと、最後に困るのは運用する側だから。

この記事で少し引っかかったのは、MCP の成熟をかなり前向きに描きつつ、セキュリティの話はまだ道半ばだと書いている点だった。標準として広がるスピードに比べて、権限管理や監査の整備は追いついていない。これは新しいプロトコルではよくあることだけれど、AI エージェントは自動で動くぶん、普通の API よりも事故の広がり方が怖い。便利さに目が行きがちだけれど、実運用では「何をつながせるか」より「何をつながせないか」の設計のほうが先に来るのではないかと思う。

参考: MCP vs REST/HTTP API vs Kafka: The Architect's Guide to Agentic AI Integration

同じ著者の記事

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

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

papoo.work

API設計でいちばん怖いのは「人間には通るけど、AIには通らない」ことだった

この元記事は、APIドキュメントの書き方ひとつで、AI agent が普通に失敗する話を扱っている 問題は「出力は number、入力は string」という型のズレ。人間は気づいて回避しても、agent はそのままつなぐので落ちる テストも人間向けの書き方になっていて、`String()` で勝手に直していたからバグを見逃していた 直し方としては、出力側を変えるのではなく、入力側を広げるのが安全だった ただし `z.union()` や `z.coerce.string()` には別の危険があるので、筆者は `preprocess` で限定的に吸収する方法を選んでいる いまのAIは「空気を読む」のではなく、文字どおりに実行する。だからAPI docs も、テストも、そこに合わせて鍛え直す必要がある この記事で扱っているのは、かなり地味だけれど、実はものすごく厄介なバグです。 著者たちは helpdesk の仕組みを MCP 経由で AI agent に触らせていて、agent はチケット一覧を取り、スレッドを読み、下書きを作る、といった操作ができるようになっていました。 で、ある日、

papoo.work

曖昧な差し戻しに備える、という現実的すぎる話

読んでまず思ったのは、「ああ、これはかなり地味だけど本当に効くやつだな」ということだった。MCP server の話ではあるけれど、実際にはどんな申請制の審査にもそのまま刺さる感覚がある。動くかどうかより、「審査する側に何が見える状態で出すか」のほうがずっと厄介なんだよな、と改めて思った。 特に引っかかったのは、ローカルでは普通に動くのに、store review に出した途端に止まる、しかもフィードバックが薄すぎて直せない、という前提の置き方だ。これ、開発者からするとかなり消耗する。バグがあるならまだしも、「何を直せばいいのか分からない」というのは、技術というより運用の問題に見える。記事がそこを真正面から扱っていて、しかも精神論ではなく、submit 前に frozen な commit を作って schema や tool list、auth scope、例の transcript を固定しておけと言っているのが良い。 僕はこの手の話で、CI を通したら安心してしまう瞬間がある。でもこの記事の感覚だと、CI は合格証ではなく、せいぜい「自分たちの手元では壊れていません」の証明にすぎ

papoo.work

Production MCPを読んで考えたこと

いちばん引っかかったのは、MCPそのものより「ちゃんと運用すると、急に話が現実になる」という空気でした。プロトコルのきれいさを褒める記事かと思いきや、実際には「3日で壊れた」「2AMにSlackで知った」みたいな、かなり泥臭い失敗談から入ってくる。そこがよかったです。AIまわりの話って、デモの気持ちよさに寄りがちですが、この記事は最初から“壊れる前提”で読ませにきている。 特に腑に落ちたのは、MCPをUSB-Cにたとえる話が、単なる比喩ではなく「N×Mの組み合わせ地獄を減らす」という運用上の痛みと直結している点です。LLMとツールの接続が増えるほど、個別実装の継ぎはぎは本当にきつくなる。ここでJSON-RPCという共通の会話形式に寄せるのは、地味だけどかなり強い発想だと思います。派手な機能より、まず“壊れにくい共通語”を作る。AI時代のインフラっぽさがある。 一方で、読んでいて少し身構えたのは、この記事が「MCPはこう作ればいい」と言うだけでなく、「でもここを雑にすると普通に事故る」と何度も釘を刺してくるところです。特にOAuth 2.1やstateless scalingの話は、きれ

papoo.work

MCPの話を読んで、いちばん引っかかったところ

最初に思ったのは、「これは便利そう」というより「便利さの置き方がかなり正しいな」という感覚だった。MCP のような仕組みは、AI アシスタントに社内の Git や文書、DB をつなげるときにすごく魅力的だけれど、現場ではたいてい“とりあえず動く”形で始まってしまう。そこに個人の PAT をローカル設定へ入れてしまう、という話はかなり現実的で、読んでいて少しぞっとした。便利さの代わりに、秘密情報が端末に散らばる。しかも本人が気づかないまま増える。そこを真正面から問題として扱っているのが、この文章のいちばん誠実なところだと思う。 特に腑に落ちたのは、「信頼境界を laptop ではなく gateway に置く」という考え方だった。開発者の PC は、どうしても守り切れない。だから、端末がやられても漏れるのは session までで、credential そのものは奪えない形にする。セキュリティの話ではよく聞く発想だけれど、MCP みたいに“AI が人間の代わりにツールを呼ぶ”世界だと、これはかなり重い意味を持つと思う。人間の手元に鍵を置かない、というより、AI に鍵を見せない設計に寄せてい

papoo.work

Google HomeがAIの手足になる感じが、もうかなり現実的になってきた

この記事を読んでまず思ったのは、「スマートホームの面倒なところを、ついにAIに丸投げできる段階まで来たのか」という驚きでした。音声アシスタントに「電気を消して」と頼むのとは少し違って、Home MCPは機器の状態や履歴まで見にいける。つまり、ただ命令を受けるだけじゃなく、状況を読んで動けるわけです。ここが地味に大きいと思いました。 ただ、便利そうだな、で終わらないのも正直なところです。家の中の情報をAIエージェントに渡す、というのはやっぱり強い権限です。カメラ映像の要約や、外出中の出来事の分析までできるなら、かなり生活に食い込む。しかも記事を見る限り、解錠みたいな機微な操作は止めているし、アクセス権も取り消せるようにしてある。そこは当然の防波堤ですが、逆に言うと、そこまでやらないと成立しない領域に入っているとも読めます。 個人的には、MCPという仕組みの広がり方も面白いです。AIが「賢い会話相手」から、「外部サービスを操作する実行役」へ寄っていく流れがはっきり見える。スマートホームはその中でも相性がいい題材で、成功すればかなりわかりやすい実例になります。家の中の操作は、抽象的な文章生成

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 HomeにAIエージェントをつなぐという話を読んで

まず思ったのは、便利そうというより先に「家の中の権限をどこまでAIに渡すんだろう」という不安のほうだった。スマートホームはもともと、照明やカメラや空調を一か所で扱えるのが魅力だけれど、そこにMCPみたいな外部接続の標準が入ると、できることが増えるぶんだけ、事故ったときの面積も一気に広がる。 記事でいちばん引っかかったのは、使い道そのものより「securely work with all of the devices and event history」という部分だった。ここはかなり強い言い方に見えるけれど、同時に「本当に全部を安全に扱えるのか？」とも思う。家のカメラ映像や履歴は、単なるデータではなく生活そのものなので、自然言語で便利に操作できることより、誰がどこまで見られるのかの線引きのほうがずっと大事だと思う。 MCP自体は、いろいろなAI agentをつなぐための共通口として面白い発想だし、Google Homeみたいな実用寄りの製品に入ると一気に現実味が出る。けれど、記事が最後に触れている security flaws の話は軽く流せない。標準が広まるほど、弱点も広く共有される。

papoo.work

信頼は「通していいか」より「どこまで許すか」

この記事を読んでまず思ったのは、AIエージェント周りで本当に怖いのは、モデルが変な答えを返すことより、その後ろで動くコードが何をしてしまうかなんだな、ということだった。プロンプト注入の話はよく聞くけれど、実際には「ツール呼び出しの先で、どのファイルに触れられるのか」「ネットワークに出られるのか」「fork できるのか」みたいな話のほうが、ずっと現実的な事故につながりそうだと思う。 Ephemora Cell の発想で面白いのは、許可・不許可を雑に決めるのではなく、capability という形で「この guest にはこれだけ渡す」と線を引いているところだ。WASM/WASI の sandbox は前からあるけれど、記事を読むと、これは単なる流行りの安全装置というより、AI がコードを書く前提に合わせた実行の切り方に見える。特に、MCP tool も「JSON schema だけじゃなくて実コードだ」という指摘にはうなずいた。見た目は API っぽくても、裏では普通に危ない処理が走る。そこを同じ箱に閉じ込めるのは筋がいい。 一方で、記事がかなり丁寧に「これは万能ではない」と釘を刺してい

papoo.work

安全なMCPサーバーを見て思ったこと

この記事を読んでまず思ったのは、MCPの怖さは「AIに何をさせるか」より、「AIに何を見せるか」にある、という当たり前だけど見落としやすい話を、かなり真面目に突き詰めているな、ということでした。MCPというと、つい便利なツール連携の話に寄りがちです。でもこの記事は、むしろそこで気を抜くと普通のAPI設計より危ない、という感覚を前に出しています。 特に印象に残ったのは、最初から read-only の tool だけに絞っている点です。AIに検索させたり要約させたりするだけでも、見せていい範囲を間違えれば十分に事故になる。だから「まず読めるだけ」にするのは、地味ですがかなり筋がいいと思いました。書いてある内容も、単に権限を絞りましたという話ではなく、検索条件や結果件数を縛って、自由入力の抜け道を減らしている。ここはちゃんと“機能”と“権限”を分けて考えていて、好感が持てました。 もう一つ引っかかったのは、監査ログの扱いです。普通なら「全部残しておけば安心」と考えたくなるのに、この記事では逆に、チケット本文や引数を丸ごとログに残すのは危ないと切っています。監査が便利になるほど、そこが第二の

papoo.work