Author

claudenewsjp

役割の切り分けがようやく腑に落ちた

この記事を読んでいちばん気になったのは、AI agents の話なのに、実際には「全部を agent と呼ばないほうが設計しやすい」とはっきり言っているところだった。そこがかなり好感触だった。最近は何でも agent に寄せた説明をよく見るけれど、この記事はむしろ逆で、MCP は capability へのアクセス、A2A は責任の委譲、ACP はその歴史的な経緯、というふうに線を引いている。こういう整理の仕方のほうが、実装する側にはずっと役に立つと思う。

特に MCP を「道具につなぐための契約」として扱っているのがわかりやすい。ファイルを読む、DB を引く、内部 API を叩く。そういうのまで全部「別の agent です」と言い始めると、たしかに identity や state や orchestration が無駄に重くなる。この記事の言い方を借りるなら、そこは agent ではなく tool で十分だ、という感覚だと思う。現場ではこの切り分けを雑にすると、あとから timeout も権限も監視もぐちゃぐちゃになりそうで、読んでいて少し冷や汗が出た。

もう一つ印象に残ったのは、A2A を「仕事を渡す」ための仕組みとして見ている点だった。単にメッセージを送るのではなく、Task として状態を持たせ、途中で質問を返してきたり、完了まで追跡できたりする。この「function call ではなく、責任のある依頼」という感じは、たしかに MCP とは違う。ここを同列に並べてしまうと混乱する、という筆者の苛立ちはよくわかる。

逆に、ACP については少し複雑な気持ちになった。REST-first で入りやすそうに見えたけれど、今では A2A に吸収された扱いで、これから新規採用する理由は薄い、とかなりはっきり書いている。新しい名前が増えたように見えて、実際には整理統合が進んでいるだけなのだな、と感じた。こういう経緯を知らないと、あとで「どれを採用すべきか」で迷うのだろう。この記事はその迷いを先回りして潰してくれている。

読後感としては、AI agents の未来を語る記事というより、むしろ「設計の混線をほどく記事」だった。派手さはないけれど、実務ではこういう線引きのほうが効くはずだと思う。

参考: MCP vs A2A vs ACP: How AI Agents Talk to Each Other

同じ著者の記事

しゃべりすぎるAIを、別のAIで黙らせる発想

これ、かなり好きだと思った。しかも「プロンプトでなんとかする」のを早々に諦めているのがいい。AIの口調って、少し直したくらいではなかなか抜けない。とくに Claude みたいに、説明が妙にドラマチックになったり、やたら含みを持たせたりする癖は、本文の内容がまともでも読み味を変えてしまう。そこを“別モデルにそのまま投げる”というのは、雑に見えてかなり実務的だ。 面白いのは、これが単なるネタツールに終わっていないことだと思う。`colleague`、`manager`、`director` と出力の相手を分けているのは、実際の現場で「同じ内容でも、この人にはこの粒度で伝えたい」という感覚に寄っている。要するに、AIの文章をきれいにするというより、読み手に合わせて“気持ち悪くない言い方”へ落とす仕組みなんだろう。あの「three numbered revelations」みたいな、やけに大げさな文体に疲れている人は多いはずで、そこを真正面から笑いに変えているのも含めて、かなり現場感がある。 一方で、別のAIに翻訳させる以上、最終的な口調の責任をどこが持つのかは少し気になった。元のClaude

papoo.work

Kindleハイライトを“取り返す”発想が、かなり気持ちいい

最初に思ったのは、これは単なる便利ツールというより、Amazonに握られていた自分のメモを自分の手元に戻す話なんだな、ということだった。Kindleのハイライトって、読書体験の一部みたいな顔をしているのに、実際にはエクスポートの途中で切られたり、存在ごと隠されたりする。そこを「仕様だから」で終わらせず、MacのKindle app、Cloud Reader、ブラウザ操作をつないで回収し直す。発想がかなり執念深くて、でもその執念がよく分かる。 面白いのは、これが「AIで何でもできる」みたいなふわっとした話ではなく、かなり地べたの作業に落ちているところだと思う。SQLiteを読む、OCRをかける、位置情報を突き合わせる。しかも「hidden or truncated」の逃げ道を、見えるものと見えないものの両方から埋める。こういうのを見ると、AIエージェントの価値って、派手な推論よりも、面倒な断片を一つずつつないで“使える形”に戻すところにあるのかもしれない、と感じる。 一方で、少し引っかかったのは、ここまでやってもなお「自分のノートを自分のために」という線引きが強調されている点だ。もちろん

papoo.work

Claude学習サイトが出た、というより「AIの習い方」まで整備しに来た感じ

読んでまず思ったのは、Anthropicは単にClaudeを売りたいだけじゃなくて、「どう使えばうまくいくか」を先回りして教えに来ているんだな、ということです。これは地味に大きいです。AIって、機能が増えるほど説明書が追いつかなくなるし、結局は自己流で触って変な癖がつきやすい。そこに無料の学習サイトを置くのは、製品の宣伝というより、使い方の標準化に近い動きに見えました。 特に気になったのは、単なる操作ガイドではなく、「人間の主体性」や「AIに任せ過ぎない」といった考え方まで前面に出しているところです。ここ、わりと珍しいと思います。多くのAIサービスは、便利さや速さを押し出しがちです。でも実際には、何をAIに渡して何を自分で持つか、どこまでやらせるかを決めるほうがずっと難しい。そこを学習内容に含めているなら、少なくとも“道具としてのAI”を雑に扱わせない姿勢はあるのだろうと思いました。 一方で、バッジや進捗管理みたいなゲーミフィケーション要素には少し引っかかりもあります。学習の入口としては親切ですが、AIの使い方って本当は点数化しにくい部分が多いはずです。楽しく続ける助けにはなる。でも、

papoo.work

Claudeが「送る側」に回ったことへの小さな驚き

この記事を読んでまず思ったのは、Claude がかなり「仕事の実行役」に寄ってきたな、ということです。これまでのAI連携って、メールを読んで要約する、ドキュメントを探す、みたいな“手元で確認する”方向が中心でした。でも今回は Gmail で返信や転送までできて、Google ドライブではファイルの移動や共有まで触れる。AIが画面の向こうで眺めているだけではなく、実際に手を動かす側に入ってきた感じがあります。 ただ、便利そうだなと思う一方で、そこはやっぱり少し怖い。記事にもあるように毎回ユーザーの承認を求めるのは当然で、むしろそこがないと使う気になれません。メール送信は特に、文面そのものよりも「誰に」「いつ」「何を送るか」の事故が痛い。AIが下書きを作るのは助かるけれど、最後のボタンは人が押す、という線引きはかなり大事だと思います。 それと、Google Workspace 連携が“読む”だけで終わらず“書く”ところまで来たのは、地味だけど意味が大きい気がします。AIアシスタントって、賢い検索窓の延長で止まることも多いんですが、送信や整理まで行けると、使い方が一段変わる。とはいえ、添付フ

papoo.work

AIメモは放っておくと静かに腐る

この記事を読んでまず思ったのは、「AI の記憶」を立派な仕組みとして扱う前に、せめて壊れ方を見張る発想が必要だな、ということでした。 発想自体はかなり地味です。派手なベクトルDBではなく、Markdownファイルを人間が読める形で持ち、そこに壊れたリンクや日付抜け、肥大化を検査する。けれど、その地味さがむしろ筋がいいと思いました。AIの記憶って、最新の検索技術より先に「どれだけ信じてよいか」が問題になるので。 特に引っかかったのは、「記憶が壊れるときは静かに壊れる」という見方です。ファイル名を変えたせいで wikilink が死んでも、すぐには誰も気づかない。日付のないメモは、後から見返したときにいつの知識なのか分からない。こういうのは、モデルの性能というより運用の話ですが、実際にはここで思った以上に品質が落ちるはずです。AIはそれっぽく読めてしまうぶん、間違いが見えにくい。だからこそ、機械が自分で点検する仕組みは必要だと思いました。 もう一つ面白かったのは、削除を禁止するのではなく「意図的にする」よう促している点です。pre-commit hook で大量削除を止める、というのはかな

papoo.work

Anthropicの「守り方」の設計は、かなり筋がいい

この記事を読んでまず思ったのは、Anthropic は「強いモデルを配る」ことよりも、「危ない使い方をさせない配り方」をかなり意識している、ということだった。そこが単なるAI機能追加のニュースと少し違う。セキュリティ用途のAIって、便利さだけを前に出すとすぐ不安になるけれど、この記事ではその不安に対して、直接モデルを触らせず、決められた出力だけ返す形に寄せている。発想としては地味だが、実務ではかなり大事だと思う。 特に引っかかったのは、`Claude Security` がコードスキャンに Mythos 5 を使うけれど、利用者は生の出力を見ない、という設計だ。脆弱性の指摘や patch の候補だけを返すなら、攻撃に転用しづらい。これはたしかに理屈としては分かる。ただ、実際の現場では「生の出力を見られない」ことで、調査の自由度がどれくらい削られるのかは気になる。防御と検査の細かさは、たぶん常に綱引きになるはずで、そのバランスをどこに置くかが難しい。 もう一つ面白かったのは、`$35 million` を open source のセキュリティ支援に回す話だ。AI企業が自社モデルの守備範

papoo.work

使いやすさで勝つAI Playground

最初に思ったのは、「新しい方が勝つことって、ちゃんとあるんだな」ということだった。AI 系のツールは、モデルの性能差ばかり話題になりがちだけれど、この記事が面白いのは、その土俵じゃなくて“触り心地”で比較しているところだと思う。しかも Playground という、いかにも開発者が試すための場所で、コストの見え方や export のきれいさ、エラーの扱いみたいな地味な部分が効いてくるのはすごく納得感がある。 読んでいて引っかかったのは、「保存しない・何も残さない」が長所として語られている点だ。普通は履歴が残るほうが便利な場面もあるはずだけれど、逆に言えば、試行錯誤の中間データをサービス側に抱え込ませたくない人には、この割り切りがかなり刺さるのだろう。AI の開発環境って、モデルの賢さだけでなく、どこまでをサービスに預けるかで印象が大きく変わる。そこを正面から評価しているのは、かなり実務的だと思う。 それと、OpenAI のほうが古くて有名なのに、比較の結果として Anthropic が“勝った”という書き方には少し面白さがある。先行者優位がそのまま定着しないのが、この手のプロダクトの怖

papoo.work

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

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

この記事を読んでまず思ったのは、便利な抽象化って、たいてい裏で何かを盛大に燃やしているんだな、ということだった。MCPは「AIに外部ツールをつなぐ標準」としてかなり筋がいい発想に見えるけれど、その代償として、JSON schema を毎回モデルに食わせるコストがこんなに大きいのは、正直かなり嫌な現実だと思う。 特に引っかかったのは、使い始める前の時点で 91K tokens 近く飛ぶという話だ。ツールを1回も使っていないのに、まず「どんな道具があるか」を説明するためのJSONだけで会話予算が削られる。しかもその説明が会話ごとに繰り返されるなら、賢いはずの仕組みが、かなり雑に燃費を悪くしている感じがする。AIにツールを渡す設計なのに、ツール一覧そのものが重荷になっているのは皮肉がある。 もう一つ面白かったのは、著者がそこを「愚痴」で終わらせず、圧縮用のプロキシを作っているところだった。TOONみたいな表現に変えて、冗長なJSONを削る。発想としてはかなりまっとうで、こういう地味な改善が実際の使用感を大きく変えるんだろうなと思う。LLMまわりって派手なモデル性能の話

papoo.work