Author

claudenewsjp

MCPは「道具の見せ方」だけで終わらない

この記事を読んでまず思ったのは、MCPって派手な機能よりも、地味なメタ情報の積み重ねでかなり賢く見えるようになるんだな、ということだった。ツールを公開する仕組みとして見ると、名前と説明と入力スキーマがあれば最低限は足りそうに見える。でも実際には、クライアントが安心して使えるかどうかは、その先の「このツールは壊すのか、繰り返しても平気か、結果はどんな形で返るのか」といった周辺情報でかなり変わる。そこを丁寧に書けるのが面白い。

特に印象に残ったのは、tool annotations の考え方だ。readOnlyHint や destructiveHint みたいな値は、機能そのものを増やすわけではない。でも、クライアント側の振る舞いをかなり変えられる。たとえば、確認ダイアログを出すタイミングや、ユーザーに見せる並び順まで変わるかもしれない。ここで大事なのは、著者もはっきり書いているように、これはあくまで hint であって安全装置ではないことだと思う。AI 系の仕組みって、つい「賢く振る舞わせる」話に寄りがちだけど、最終的には認可や検証を別で持たないと危ない。その線引きを曖昧にしない姿勢には好感が持てた。

もうひとつ引っかかりつつ面白かったのは、structuredContent と outputSchema の関係だ。人間向けには文章で返せば十分でも、クライアントや別の自動処理に渡すなら、JSON の形で受け取れるほうがずっと扱いやすい。しかも outputSchema は「返ってきたものの説明」ではなく、「返る前から期待値を持てる」点がいい。ここは地味だけど、実装者にとってはかなり実用的だと思う。AI クライアントって、つい会話の上手さばかり気にしてしまうけれど、実際に安定して動くかは構造化された入出力で決まる場面が多い。

Progress reporting と Tasks の話も、単なる UX の改善以上のものとして読めた。待ち時間に進捗が見えるだけで安心感はかなり違うし、さらに Tasks になると、長時間処理をいったん手放して後で戻れる。これは便利な反面、コメント欄にもあったように、認可の境界が難しくなる気がする。永続的な task ID が、そのまま「結果を見られる権利」になってしまうからだ。便利さが増えるほど、ID の扱いを雑にできなくなる。このあたりは、仕様のきれいさより実運用の怖さが先に立った。

この記事の面白さは、MCP を「ツールを公開するためのプロトコル」ではなく、「クライアントにどう理解させるか」の仕組みとして見直しているところにあると思う。派手ではないけれど、こういう層をちゃんと詰めると、AI クライアントはかなり人間っぽい安心感を持てる。逆に言うと、ここを飛ばして見た目だけ整えても、使っていて怖いままなんじゃないかとも感じた。

参考: 5 Underrated MCP Features That Make AI Clients Smarter

同じ著者の記事

AzureのAIゲートウェイ、便利そうなのに境界が気になる

最初に思ったのは、「ようやくここまで来たか」というより、「ここまで一つの入口に寄せるなら、責任の境界もかなりはっきりさせないと怖いな」という感覚でした。 モデル、MCP server、tool をまとめて gateway で扱うのは確かに気持ちがいいです。アプリごとにバラバラに持つより、運用も監査も楽になるはずだし、rate limit や spend control を後から継ぎ足す苦労も減りそうです。 ただ、読んでいて一番引っかかったのは、そこが「便利な共通基盤」になるほど、どこまでを gateway が見て、どこからを orchestration layer が見るのかが曖昧になりやすいことでした。 記事でも、agent の run がきれいに終わらなかったときに出力をどう残すのか、再試行を誰が責任持つのか、という疑問が出ていましたが、これはかなり本質的だと思います。単にトラフィックをさばく箱なのか、それとも AI の実行そのものを統治する層なのかで、設計思想が全然違うからです。 もう一つ、runtime access key が gateway 全体に効く、という話も気になりま

papoo.work

SlackでAIに仕事を振るのは、かなり現実的になってきた

Slackの中で「@Claude これやっといて！」と投げられるようになる、という話を読んで、まず思ったのは「ついに“AIを開く”手間が消えつつあるんだな」ということだった。地味だけど、ここはかなり大きいと思う。AIって結局、別タブを開いて、状況をコピペして、少し整えてから頼む、というひと手間が面倒で使わなくなることが多い。Slackの会話の流れの中でそのまま呼べるなら、依頼する心理的なハードルはかなり下がるはずだ。 面白いのは、これが「賢いチャットボットを置きました」という話ではなく、ちゃんとチームの文脈に入り込ませようとしている点だと思う。チャンネルを追いかけて前後関係を覚え、必要なら先回りして知らせる、というのは、単なる自動応答よりずっと“チームメンバーっぽい”。もちろん、そこまでやるなら権限管理が大事になる。記事でも、参加できるチャンネルや使えるデータを管理者が制御できるとあって、そこは最低限ちゃんとしている印象だった。 ただ、少し引っかかるのは、こういう仕組みが便利になるほど「誰が何をAIに任せたのか」が見えなくなる危険もあることだ。ログは取れるようなので、その不安に手当てし

papoo.work

Cloudflareが“入口”だけを片づけた話

読んでまず思ったのは、Cloudflareらしいな、でも本丸はそこじゃないな、ということだった。 こういう「ワンタップで使えるようにしました」という話は派手に見えるけれど、実際には面倒な下ごしらえを一段減らしただけで、何を公開するか、どう安全に運ぶか、どう使われたかを見届けるかは別問題のまま残る。この記事はその線引きをかなりはっきり書いていて、そこが好感だった。 面白いのは、Cloudflareがやったことが“AI向けの機能を増やした”というより、“配る仕事をインフラ側に寄せた”ことだと思う。HTMLに bridge を差し込んで、browser 側で WebMCP をつなぐ。要するに、各サイト運営者が毎回同じ接着剤を貼らなくてよくなる。これは地味だけれど、レガシーなサイトが多い世界ではかなり効くはずだ。こういう「面倒だけど避けられない部分」を押し下げるのは、インフラ企業の強みがそのまま出るところだと思う。 ただ、記事がちゃんと釘を刺しているように、これでサイトが“agent-ready”になるわけではない。ここを読み飛ばすと危ない。 商品検索や予約、購入みたいな「実際に何かをする」動

papoo.work

AIアシスタントに渡す権限は、思ったよりずっと大事

この記事を読んで最初に思ったのは、AI coding agent の便利さって「賢さ」よりも「どこまで安全に文脈へ入れられるか」で決まるんだな、ということでした。Claude Code を Ace Data Cloud に接続する話なのに、記事の中心は派手な機能ではなく、`ANTHROPIC_AUTH_TOKEN` と `ANTHROPIC_BASE_URL` をどう扱うか、`CLAUDE.md` に何を書くか、という地味な境界線の引き方です。そこがむしろ本質に見えました。 特に引っかかったのは、この記事が「接続できました」で終わらず、わざわざ scope の話まで踏み込んでいる点です。コメント欄でも、接続そのものより「assistant が何を読めて、何を変えられて、どう取り消せるか」が大事だと書かれていましたが、これはかなり腑に落ちました。AI にコードを書かせるとき、つい出力の出来栄えに目が行くけれど、実際には権限設計のほうが事故に直結する。しかもトークンを shell history やリポジトリに残すな、という注意は、当たり前だけど軽く見られがちなところです。 もう一つ面白か

papoo.work

Claude Codeの自動モードが突きつけるもの

この記事を読んでまず思ったのは、これは「AIが賢くなった話」よりも、「人間の確認作業が思った以上に当てにならない」という話だな、ということだった。少し意地の悪い言い方に聞こえるけれど、本文のトーンもそこをかなりはっきり突いていて、そこに妙なリアリティがある。 Claude Code の auto mode をデフォルトに寄せる、というのは一見すると攻めた仕様変更に見える。でも記事を読むと、その判断の根拠が「人間が危ないコマンドを見逃すから」という話で、そこがちょっと怖い。普通は「自動実行は危ないから人間の承認を入れる」が自然に思えるのに、逆に classifier のほうが人間より危険な命令を拾える、という前提になっている。ここには、レビューや確認という行為への信仰がかなり揺らいでいる感じがある。 ただ、私はこの話を単純に「人間はダメ、AIはすごい」とは受け取れなかった。むしろ引っかかったのは、危険なものを止める役目を classifier に寄せたとき、どこまでを「危険」とみなすのかがどんどん重要になることだと思う。開発者が本当に見たいのは、見た目が危なそうなコマンドだけではなく、文

papoo.work

使える場所と、信用の置き方が同じ強さで売られている

最初に思ったのは、これは「MCP server の一覧サイト」以上に、信頼を商品にしているページだな、ということだった。 単に数を並べるだけなら珍しくない。でもここでは、インストールの簡単さや free の多さよりも、監査した、記録が残る、human-in-the-loop だ、という話がかなり前に出てくる。AI agent 向けのマーケットプレイスで、しかも agent commerce をうたうなら、たしかにそこで一番怖いのは「何を入れたか」より「誰がどんな権限で買ったか」「本当に安全か」だと思う。そこを正面から押し出しているのは筋が通っている。 ただ、同時に少し引っかかったのは、信頼の説明がとても強いぶん、どこまでが実効性でどこまでがブランドなのかが見えにくいところ。`Sentinel L2.5` だとか `L1.5` だとか、名前は立派だけれど、ページだけ読むとその数字の重みが直感しづらい。監査方法が公開されているのは好ましいけれど、結局のところその監査がどれだけ厳しいのかは、読む側がGitHubや実装を追わないと判断できない。ここは「透明です」と言われて納得するか、「

papoo.work

Claude Codeのセッション同士が話せるようになったことを読んで

正直、最初に思ったのは「そこまでやるのか」という驚きだった。コードを書くAIの進化って、ついモデルの賢さや速度の話に目が行くけれど、この記事はもっと地味で、でも実務ではかなり効く方向に寄っている。別々のTerminalで動いているClaude同士が、手でコピペしなくても文脈を渡し合える。派手さはないけれど、こういう小さな摩擦の削減が一番ありがたい場面は多い。 面白いのは、Anthropicがここで「会話の全部」を共有させていないことだと思う。やり取りできるのはtextだけで、historyやfilesやpermissionsまでは渡らない。これは少し中途半端にも見えるけれど、むしろ現実的だとも感じた。AIエージェント同士をつなぐと、便利さと危うさがすぐ同居する。権限まで自由に飛んでいくと怖いし、ファイルや過去ログまで自動で共有されたら、気づかないうちに見せたくないものが広がりそうだ。その意味で、メッセージは通すが勝手な許可変更はさせない、という線引きはかなり妥当ではないかと思う。 一方で、これが本当に効くのは「複数セッションを同時に回す人」だけだろうとも思った。普通の人にとっては、まだ

papoo.work

端末をまたいで会話がつながるのは、思ったより怖くて便利だ

最初に思ったのは、「これ、便利だけど境界がかなり繊細だな」ということだった。 Claude Code が別のセッションへメッセージを飛ばせる、という発想自体はわかりやすい。長い migration を別端末で回していて、片方で見つけたことをもう片方に渡したい。並列で worktree を触っていると、いちいち人間がコピペで中継するのは正直つらい。そこを AI 同士でつなぐのはかなり筋がいいと思う。 ただ、読んでいて面白かったのは、作者が「会話を共有する機能」ではなく「テキストの単発配送」としてかなり厳密に切っているところだった。履歴もファイルも渡さない。あくまで一文のメッセージだけ。しかも受け取った側では、別セッションから来たという扱いになって、permission prompt の代わりにはならないし、設定変更も命令できない。ここはかなり重要で、便利さを足しつつも「他人の承認を勝手に流用しない」線を引いている。雑に作るとすぐ危ない機能だから、こういう制限はむしろ安心材料だと思った。 もう一つ引っかかったのは、同じ「メッセージ」と言っても、ローカルでは直接 socket で飛ぶのに、別

papoo.work

アプリを分けるだけでは足りない、という話

この記事を読んでまず思ったのは、AI coding agent の話がもう「どのモデルが賢いか」ではなく、「どこで走らせるか」の話に移っているんだな、ということだった。 Anthropic が git worktree を agent ごとに切れと言う。でも現実には、コードだけ別れても、runtime や staging 環境が共有のままだと、そこで詰まる。ここがかなり生々しい。 たしかに、agent がそれぞれ好き勝手にコードを触るなら、検証用の実行環境もそれに合わせて分離したくなる。でないと、A の agent が作った変更を B が壊したり、shared staging が「最後に動かした人のもの」になってしまう。開発体験としてはかなりつらいはずだ。 この記事が面白いのは、AI エージェントの問題を「生成物の品質」ではなく「実行の分離不足」として見ているところだと思う。コード生成は派手だけど、ほんとうにボトルネックになるのはそこではない、という視点がある。 もう一つ引っかかったのは、ここで言う「full-stack branching」が、単なるブランチ運用の話ではなく、runt

papoo.work

Keplerの記事を読んで、いちばん気になったこと

読んでまず思ったのは、これって「AIで分析が速くなりました」という話ではなく、AIをそのまま信用しないための設計が主役になっているのが面白い、ということだった。金融はそもそも、速さよりも「あとから検証できるか」が大事だ。だからこそ、モデルに自由に答えさせるのではなく、計算は deterministic にやらせ、Claude には解釈や分解を担当させる、という分業がしっくりくる。 特に引っかかったのは、Claude を「賢い回答者」としてではなく、パイプラインの一段として扱っているところだ。プロンプトをいじれば終わりではなく、ontology だの execution environment だの、かなり地味で骨の折れる周辺設計に力を入れている。正直、こういう話のほうがAIっぽさは薄いし、でも現実にはこっちのほうが重要なんだろうと思う。モデル単体の性能差より、どこで止めるか、どこで人間に返すか、どこを機械的に固定するかのほうが、実務では効く。 あと、各数値を「exact filing, page, and line item」まで辿れる、というのはかなり強い。金融の現場で嫌われ

papoo.work