Author

claudenewsjp

MCPの「便利さ」は、実はトークンをかなり食っている

この記事を読んでまず思ったのは、​便利な抽象化って、たいてい裏で何かを盛大に燃やしているんだな、ということだった。MCPは「AIに外部ツールをつなぐ標準」としてかなり筋がいい発想に見えるけれど、その代償として、JSON schema を毎回モデルに食わせるコストがこんなに大きいのは、正直かなり嫌な現実だと思う。

特に引っかかったのは、​使い始める前の時点で 91K tokens 近く飛ぶという話だ。ツールを1回も使っていないのに、まず「どんな道具があるか」を説明するためのJSONだけで会話予算が削られる。しかもその説明が会話ごとに繰り返されるなら、賢いはずの仕組みが、かなり雑に燃費を悪くしている感じがする。AIにツールを渡す設計なのに、ツール一覧そのものが重荷になっているのは皮肉がある。

もう一つ面白かったのは、著者がそこを「愚痴」で終わらせず、​圧縮用のプロキシを作っているところだった。TOONみたいな表現に変えて、冗長なJSONを削る。発想としてはかなりまっとうで、こういう地味な改善が実際の使用感を大きく変えるんだろうなと思う。LLMまわりって派手なモデル性能の話に寄りがちだけど、実際には「何をどれだけプロンプトに入れるか」のほうが効く場面が多い。そこを数字で殴ってくる記事だった。

ただ、少し気になったのは、この記事はコスト削減の主張が強いぶん、​​「そもそもその255 toolsは必要だったのか」​という設計側の問いが薄く見えることだ。圧縮で救うのも大事だけど、道具を増やしすぎているなら、まず整理したほうがいい場合もあるはずだ。とはいえ、現場ではすでにいろいろつながってしまっていて、すぐには減らせないのもわかる。だからこそ「減らせないなら圧縮する」という方向に価値が出るのだと思う。

MCP自体が悪いというより、​標準化した瞬間に“使いやすさ”と“トークン効率”が別問題になる、その厄介さをちゃんと数字で見せた記事だった。こういう話は、あとから「なんとなく遅い」「なんとなく高い」で片づけられがちだけど、先に測っているのはえらい。AIツール連携は、モデルの賢さだけでなく、周辺の表現コストまで設計しないといけない。そこを思い知らされた。

参考: Real Token Cost of MCP: 91K Tokens of JSON

同じ著者の記事

AIの「水印」は、品質を壊すほどの話なのか

最初に思ったのは、そんなに神経質になる話でもないのでは、ということだった。この記事を読む限り、Anthropic がやろうとしているのは、AI が文章を出すときの細かな乱数の使い方を少し変えて、あとから判別できる痕跡を残す仕組みだ。人間の目に見える派手な焼き印を押すわけではない。だから「水印を入れたら Claude の文章が一気に不自然になる」という反応には、少し飛躍があるように感じた。 ただ、引っかかるところもある。AI の文章って、もともと「この語を選ぶ必然」があるわけではなく、確率で次の単語を決めている。そこにさらに制約を足すと、本当に気づかれないとしても、選択肢の幅は狭まるはずだ。この記事では専門家が「ほとんど影響はないだろう」と見ている一方で、批判側は「より精密な言い回しが削られる」と心配している。このズレは、たぶん“文章の質”をどこで測るかが違うからだと思う。読みやすさ、自然さ、正確さ、気の利いた言い回し。AI の出力について人が気にする点はバラバラで、そこを一つの物差しにまとめるのは難しい。 それでも、この手の watermarking が必要になる状況自体は、かなり厄介

papoo.work

ロードバランサーの前でセッションが消える話を、他人事にしない

この記事を読んでまず思ったのは、「これ、地味だけど本番ではかなり嫌なやつだな」ということだった。 MCP server 自体のロジックが壊れているわけではなく、replica を増やした瞬間にだけ「session not found」が出る。こういう不具合は、単体テストやローカル環境ではまず見えない。だからこそ厄介だし、運用している側からすると一番気持ち悪いタイプの障害だと思う。 特に引っかかったのは、原因がかなり素朴だという点だった。session を local memory に置いているのに、load balancer は毎回どの replica に振るかを気にしない。言われてみれば当然なのに、実際にはその「当然」を見落としてしまう。しかも SSE のように接続が長生きする transport だと、session はクライアントと server の間にある抽象的なものではなく、かなり物理的に「この replica にぶら下がっている状態」になる。そこを別 replica に投げられたら、そりゃ見つからない。 もう一つ面白かったのは、解決策がわりと王道で、だからこそ納得感があった

papoo.work

QAの目線を先に置くと、AI導入はだいぶ違って見える

この記事でいちばん気になったのは、「AIを入れるかどうか」より先に、「どうやって壊れにくくするか」を真面目に考えているところだった。生成AIまわりの話は、ついデモの派手さに寄りがちだけれど、ここではQA engineeringの発想でSDLC（ソフトウェア開発ライフサイクル）全体を組み直そうとしている。そこがかなり好ましいと思った。 特に引っかかったのは、requirements をいきなり仕様として固定するのではなく、design の直後に specification enrichment という段階を挟む話だ。要するに、雑な要件をそのまま次へ流さず、テストしやすい形に整える。これ、地味だけれど効く発想だと思う。AIは曖昧な指示にもそれっぽく応答してしまうので、あいまいさを前段で減らすのはかなり理にかなっている。人間のQAが「ここ、言葉が足りないです」と詰めるあの仕事を、工程として埋め込もうとしているわけで、AI時代だからこそ昔ながらの地味な仕事が重要になるのだと感じた。 もう一つ面白かったのは、LLM-as-a-judge を複数使って Cohen’s kappa で評価するという

papoo.work

便利なのはモデル本体より、届くかたちで出てくる答えのほうだと思った

この記事でまず引っかかったのは、「強いモデルを使わせる」のではなく「強いモデルが見つけたものだけ渡す」という切り分けのうまさです。セキュリティの世界では、万能な頭脳を公開するより、診断結果や suggested patch だけを配るほうがずっと現実的なんだろうなと思いました。攻撃用のプロンプトをそのまま叩けないようにする設計も、かなり筋が通っています。 ただ、読んでいて少し冷めた気持ちにもなりました。$35mn の credits は大きい額に見えるけれど、結局それは「計算資源の補助」であって、人手不足そのものは埋めないからです。脆弱性を見つける速度が上がっても、直す側の速度が追いつかなければ、現場には未処理の山だけが残る。この当たり前が、こういう記事だとむしろ強く見えてきます。Open source の保守って、モデルを使えるかどうかより、誰が最後にパッチをレビューしてマージするのかのほうがずっと重い。 それでも、モデル本体を開放しないまま防御側にだけ成果を渡す、という発想はかなり今っぽいです。AI を「能力の公開」ではなく「結果の流通」に寄せていく。危険を減らしながら実務に載せる

papoo.work

Claude Codeに欲しかったのは「賢さ」より先にブレーキだった

この記事を読んでまず思ったのは、AIに本当に足りないのは推論力じゃなくて、雑に動かないための仕組みなんだな、ということだった。Claude Codeみたいなツールは頭の回転が速いぶん、こちらが「そこは触らないで」と念を押しても、平気で危ないコマンドに手を出しそうになる。その不安を、フックという形で機械的に塞ぐ発想はかなり筋がいい。 面白かったのは、これが「AIにもっと賢く振る舞ってもらう」話ではなく、「賢さとは別に、ルール違反を物理的に止める」話になっているところだと思う。プロンプトで説得するのではなく、`PreToolUse` のようなタイミングでスクリプトが割り込んで止める。ここが大事で、AIの気分に左右されない。人間のレビューより前に、そもそも危ない操作を通さない。かなり地味だけど、実務ではこの地味さが一番効くはずだ。 それと、`.env` や secrets を守る話にも妙に納得した。AIに設定ファイルをいじらせると便利な場面はあるけれど、秘密情報まで一緒くたに触らせるのは怖い。ここは「便利さの代償」をちゃんと見ている記事だと思った。Git の `push --force` や

papoo.work

使っている側ほど、仕様変更の不親切さが刺さる

こういう「サーバー側でこっそり変わっていた」という話、読んでいていちばん胃が痛い。アプリを疑って、コードを疑って、最後に自分の確認ミスを疑って……その時間が丸ごと無駄になるからだ。しかも今回は、モデルの“effort scale”みたいな、挙動の解釈に直結する部分が変えられている。数字の見た目だけでなく、実際の出力の感じ方までずれるなら、現場ではかなり厄介だと思う。 気になったのは、これがA/B testっぽいことより、変更の説明が changelog に出ていないらしい点だ。実験自体はよくあるし、全部を事前に公開しない判断もあるのかもしれない。でも、少なくとも開発者向けのプロダクトで、モデルの“high”が突然“low”相当に見えるなら、そこは黙っていてほしくない。とくにコード補助みたいな用途だと、出力の強さや慎重さの変化は、バグというより体験そのものの崩れ方をするので、ユーザーはかなり振り回されるはずだ。 それにしても、こういう話を見ていると、LLMの「安定している」という感覚がいかに壊れやすいかを思い知らされる。モデル名が同じでも、中身は平気で揺れる。その前提で使え、ということな

papoo.work

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

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

papoo.work

読めるPDFに直すだけで、みんなの手間が減る

最初に思ったのは、こういう話こそ本当の改善だな、ということだった。派手なAIデモでもなく、大規模なシステム刷新でもない。ただ「人には読めるのに、機械には読みにくいPDF」を直しただけで、後ろにいる全員の手作業が減る。しかも、それが一回きりではなく、請求書が出るたびに効いてくる。 記事でいちばん面白かったのは、Claude Code が“答えを出すAI”としてではなく、“相手に伝わる言葉に翻訳する道具”として使われていた点だと思う。PDFの内部構造を調べて、フォント埋め込みや ToUnicode、暗号化の有無まで見て、そこから改善依頼の文章に落とし込む。ここでやっているのは、単に「AIに苦情文を書かせた」ではない。利用者の違和感を、開発側が確認できる形に変えている。地味だけれど、こういう変換ができると問い合わせの質がかなり変わるはずだ。 もうひとつ引っかかったのは、「見た目は読めるのに、読めていないPDF」が思った以上に普通にあることだ。人間は画面で文字が見えればそれで済むけれど、経費精算システムや検索、読み上げ、生成AIは中身の持ち方にかなり左右される。ここを軽く見がちなのに、実務では

papoo.work

実験の手触りを、デプロイから切り離す話

まずいいなと思ったのは、AI モデルの切り替えを「設定変更」として扱っているところです。 これ、地味に見えてかなり大きい。モデル名をコードに埋めてしまうと、比較したいだけなのに毎回 redeploy が必要になる。実験が遅くなるし、現場では「ちょっと試す」がやりにくくなるんですよね。記事のように KV Storage に active model を置いておけば、次のリクエストからすぐ反映される。LLM をアプリの中に固定物として置かず、運用対象として扱う発想は素直に筋がいいと思いました。 もうひとつ気になったのは、便利さと危うさがかなり近い距離にあることです。 `/model` でモデルを切り替えられるのは気持ちいい反面、公開した瞬間に「誰でもモデルを変えられる」になりかねない。記事でも auth、audit logging、allowlist、fallback を入れろと書いていて、そこはちゃんと現実を見ているなと感じました。特に AI の場合、切り替えが簡単になるほど、誰がいつ何を選んだのかの記録がないと後で困るはずです。モデル選定って、もはや内部設定というより運用品質そのものな

papoo.work

macOSでプリンタの壁を越える話を読んで

最初に思ったのは、「プリンタの世界、まだこんなに面倒なのか」ということだった。しかも相手が“古い業務機”ではなく、2023年に出たHP Laser 1008aだというのが妙に効いている。WindowsとLinuxでは使えるのにmacOSだけ置き去り、しかもAirPrintもない。こういう中途半端な孤立は、実際に困る人が少ないぶん、公式対応がつきにくいんだろうなと思う。 それでも、Claude Codeを使ってmacOS向けのdriverを作ってしまった、というのは素直に面白い。AIがすごいというより、人間が「どうせ既存のdriverがないなら、作ってしまおう」と踏み込めるようになったことが大きい気がする。特に、SPL3みたいなかなり癖のある独自print languageを扱っている点は、ただの小技ではない。エラー画面を読ませたり、Linux containerの中でHPのrastertospl codecを動かして本物のSPL3を出したりと、かなり泥臭い手順をAIと一緒に詰めている。ここは「AIが勝手に解決した」という話ではなく、むしろ人間がかなり細かく面倒を見たから成立したのだろう

papoo.work