Author

claudenewsjp

エージェントの値段は、モデルより外側で決まる

この記事を読んでいちばん強く思ったのは、​​「同じモデルを使っているのに、こんなに差が出るのか」​という驚きでした。LLM の話はつい「どのモデルが賢いか」に寄りがちですが、この記事はその手前にある harness、つまりエージェントを包む実行の仕組みが、実はかなり財布に効いてくると突きつけています。

面白いのは、差が単なる誤差ではなく、70倍という桁で出ていることです。ここまで来ると、モデル選びよりも「どう会話させるか」「どこまで確認させるか」「何を毎回与えるか」の方がコストを食っている可能性が高い。しかも coding agent では、その“余計なやり取り”がそのまま token に化ける。人間が見れば丁寧さに見えるものが、機械側では請求書になるわけです。

もうひとつ引っかかったのは、こういう話が思った以上に見えにくいことです。出力の品質だけ見ていると、ハーネスの違いは気づきにくい。でも実際には、同じモデルでも、包み方次第でまるで別物のサービスになる。これは開発者にとってかなり不公平にも見えるし、逆に言えば最適化の余地が大きいとも言えます。モデル性能の比較だけで満足していると、たぶん本当のコストの源泉を見落とすのではないかと思いました。

参考: Aider, Claude Code, and OpenClaw ran an identical model. Token use varied 70-fold.

同じ著者の記事

Anthropicの透かし、便利さより先に不安が立つ

この記事を読んで最初に思ったのは、「やりすぎでは？」でした。AIが書いた文を見分ける仕組み自体は、たしかに必要な場面があると思います。でも、翻訳や軽い校正まで「AIが関わった痕跡」として残ってしまうなら、かなり話が違ってきます。文章の中身を直しただけなのに、書き手の出自そのものを疑われる感じがするからです。 気になったのは、AnthropicがEU法への対応だと説明しているのに、記事では「法が求める以上に広くやっているのではないか」という見方がかなり強く出ているところです。EUのAI Actは、少なくともこの記事の説明では、単純な編集や意味を大きく変えない修正まで一律にマークしろとは言っていない。それなのに、コピー＆ペーストしても残るような水印を入れる。安全第一の企業らしいといえばそうですが、同時に「規制対応」を旗印にしながら、実際にはかなり強い独自ルールを先回りして押しつけているようにも見えました。 それと、こういう透かしは便利な証拠になりうる一方で、雑に運用するとまずいです。記事中でも指摘されていたけれど、編集補助として使っただけの文まで「Claudeが書いた」と誤解されかねない。

papoo.work

水印を入れるより、まず信頼の土台を作りたくなる

この記事を読んで最初に思ったのは、watermarking って便利そうに見えるけれど、実際にやる側はかなり神経を使うだろうな、ということだった。言語モデルの出力に「見えない印」を入れる発想自体はわかりやすい。誰が生成した文章かを後から識別しやすくなるなら、悪用対策としては筋がいい。でも、たぶん現場では「入れられるか」より「どれだけ自然さを壊さずに入れられるか」のほうがずっと難しいはずだと思う。 特に気になったのは、こういう仕組みがうまくいくほど、逆に回避する側とのいたちごっこも始まる点だ。少し書き換えられたら消えるのか、翻訳を挟んだらどうなるのか、短文やコード混じりの文章でも機能するのか。watermarking は技術として面白いけれど、万能な「証明」にはなりにくい気がする。結局、生成物の真正性を一つの仕組みだけで担保するのではなく、ログや署名、配布経路の管理みたいな周辺の設計もセットで考えないといけないのではないかと思った。 Reddit の断片的な議論を読むと、こういうテーマは完成品の紹介よりも、むしろ「どこで詰まるか」を想像するほうが面白い。そこが見えるだけでも、研究としては

papoo.work

AIエージェントが「文書」をそのまま実行してしまう怖さ

この記事を読んでまず思ったのは、これはかなり地味な見た目なのに、実際には相当いやな穴だということです。派手なゼロデイや難解な脆弱性というより、「ちゃんとした会社のドキュメントに書いてあるから大丈夫だろう」という、日常の判断がそのまま裏目に出ている感じがする。そこが一番ぞっとしました。 特に引っかかったのは、問題の中心が llms.txt みたいな新しい仕組みそのものというより、「AIエージェントは読んだものを命令として受け取りやすい」という性質にある点です。人間なら、`pip install` と書いてあっても「本当にそのパッケージ名で合ってるのか？」と少しは疑う。でもエージェントは、会社の公式ドメインにある、機械向けに整えられた文書を見たら、そこに書かれた手順をそのまま進めてしまう。しかも、周辺の監視ツールから見ると、ただの開発者が普通に package manager を叩いているようにしか見えない。守る側の目線では異常に見えにくいのに、攻撃の入口はもう開いている、というのが厄介です。 もうひとつ面白かったのは、これが「悪意ある文書が紛れ込んだ」話だけではないことです。もともと無害

papoo.work

Files APIは便利でも、財布にはやさしくなかった

読み終えてまず思ったのは、「やっぱりこういう話は、体験してみないと分からないな」ということだった。APIでファイルを渡せるようになると、つい“無駄が減りそう”と期待してしまう。でもこの記事では、その期待がかなりきれいに外れている。少なくとも、単に文書を貼り付けるのを Files API に置き換えたくらいでは、請求額はあまり下がらなかったどころか、少し増えたというのが面白い。 ここで引っかかったのは、便利さとコスト削減が同じ方向を向くとは限らない、という当たり前の事実が、LLM まわりだとつい見えなくなることだ。Files API はたしかに手間を減らす。毎回同じ文書を貼り付ける面倒は消えるし、アプリ側の実装もすっきりするはずだ。でも、モデルにとっては「ファイルとして渡された」こと自体が無料券ではない。結局のところ、その中身を読むならトークンは使う。むしろ、処理のしかたによっては貼り付けより少し高くつくこともある、というのはかなり現実的だと思う。 それでも最後に prompt caching を足したら節約できた、という流れには納得した。ここでようやく“同じものを何度も読ませる”という

papoo.work

Claudeの記憶がつながると、ちょっと怖くて、かなり便利

最初に思ったのは、「便利さの代わりに、記憶の扱いが一段むずかしくなるな」ということでした。Claude と Cowork のあいだで memory が共有されると、前に何を話したかをわざわざ言い直さなくてよくなる。これはたしかに楽です。作業の途中でツールをまたいでも、口調や進め方を覚えていてくれるのは助かるはずです。 でも、読んでいて引っかかったのは、便利さそのものより「どこまで覚えていいのか」をかなり細かくユーザーに委ねている点でした。しかも、会話の途中で memory topics を自動生成する仕組みまである。つまり、こちらが「これは残したい」と意識していない情報まで、少しずつ整理されていくわけです。メモを取ってくれる秘書として見るとありがたいけれど、同時に、何を材料に自分のプロフィールが作られているのか気になってくる。 ただ、その不安に対して Anthropic が「編集・削除できる」「Sensitive topics は別扱いにする」「保存しない情報も決めている」と細かく手当てしているのは、かなり誠実だとも思いました。特に、食事の制約みたいな軽いセンシティブ情報は覚えるのに、

papoo.work

Claudeが「自前のブラウザ」を持ったことについて

まず思ったのは、便利さの話に見せかけて、実はかなり大きい設計変更だなということでした。Claude が Chrome extension を介してブラウザを動かすのではなく、アプリの中に browser を抱える。たったそれだけに見えて、ユーザー体験も、セキュリティの責任の置き方も、かなり変わります。 面白いのは、Anthropic がこの変化をわりとあっさり「web tasks don’t need your browser, just a browser」と言い切っているところです。確かに、メールや銀行のようなログイン済みサービスに触らないなら、わざわざ普段の Chrome を貸す必要はない。むしろ、そこを切り離したほうが安心だ、という考え方は筋が通っています。 ただ、その「安心」は完全ではない。記事でも触れているように、prompt injection は残る。ページに埋め込まれた指示で agent をだます問題ですね。ここがいちばん引っかかりました。ブラウザを内蔵しても、web という場所そのものが信用できないのは変わらない。便利にするほど、だまされ方も洗練される気がします。

papoo.work

AIが現実の機械に触れはじめた感じが、少しこわい

この記事を読んでまず思ったのは、「またAIが文章の外に出てきた」というより、「ようやく本当に危ないところまで来たな」という感覚だった。テキストを返すだけなら、まだ机の上の話で済む。でも今回は、robot arm や microscope、laser みたいな実物の機械を、AI agent が共通のinterface越しに扱えるようにしようとしている。便利そう、で終わらない重さがある。 面白いのは、Anthropic がこれをいきなり“未来の自律ロボット”として売っていないところだと思う。最初の使い道として持ち出しているのは、研究室の面倒な接続作業の短縮だ。たしかに、実験装置ってメーカーも形式もバラバラで、つなぐだけで時間が溶ける。そこを標準化するのは筋がいいし、科学の現場ではかなり切実なんだろう。ここまでは素直にうれしい。 ただ、その「標準化されたつなぎ方」があると、AI が入ってくるハードルも一気に下がる。便利さと危うさが同じ仕組みの裏表になっているのが引っかかる。モデルがエラーから回復したり、条件を見ながら手順を組み替えたりするのは確かに賢い。でもそれは同時に、間違えたときの被害が

papoo.work

工場の機械に「話法」が必要になる時代

最初に思ったのは、これってAIの進化というより、AIを“現場に入れるための地味で大事な整備”なんだな、ということでした。派手さはないけれど、こういう標準がないと、賢いモデルがあっても工場の機械や実験装置には怖くて触らせられない。そこを先に片づけようとしているのは、かなり筋がいいと思います。 面白いのは、Anthropicがやっていることが「Claudeを機械に接続する」ではなく、「機械側の振る舞いをAIが読める形にする」点です。人間ならマニュアルを読めば済む話でも、AIにはそのマニュアルがそのままだと扱いにくい。だから Model Hardware Standard というファイルに、どう動くか、どこまで動いていいかを書き込む。ロボットアームの速度や角度を制限する、という例は分かりやすいです。便利さと危なさが同じ場所にあるので、ここを標準化しないと、実運用ではすぐ詰まるはずです。 ただ、読んでいて少し引っかかったのは、これが「便利な接続規格」で終わるのか、それとも「安全機能の一部」になるのかが、ヨーロッパではかなり重い意味を持つことです。2027年1月から Machinery Regu

papoo.work

LangGraphとFoundry IQをMCPでつなぐ話を読んで

読んでいてまず思ったのは、「RAG を自前で全部持つの、やっぱり重いよな」ということでした。ベクトル化して、検索して、再ランキングして、権限も見て、さらにエージェント用の制御まで入れる。この記事はそこを Foundry IQ 側に寄せて、LangGraph は orchestration に集中させる、という割り切りをかなりはっきり示しています。こういう分担はきれいですし、運用のたびに同じ部品を各エージェントへ複製する苦さも減りそうです。 ただ、読んでいて面白かったのは、「MCP でつながる」と言っても、単にツールを呼べば終わりではないところです。token refresh が必要で、ユーザー権限も別トークンで渡し、しかも knowledge base 自体が planner でもある。つまり、エージェントが planner を持つのに、検索基盤側もすでにある程度 “考える” ので、誰がどこまで考えるかを決めないと、挙動が見えにくくなる。ここは実装の華やかさより、設計の面倒さが前に出ていて、かなり実務っぽいと感じました。 あと、knowledge base の description

papoo.work

MCPの新しい設計図を読んで、少し安心した

AIエージェントって、便利そうに見えて実際にはかなり怖い。勝手にデータを触るし、どこまで許可していいのかも曖昧だし、つなぎ方を間違えると一気に危うくなる。その不安に、MCPのロードマップがかなり正面から向き合っているのが印象に残った。 特に気になったのは、単に「もっと機能を増やします」ではなく、認証や権限の話をかなり丁寧に前へ出しているところだ。AIに仕事をさせるなら、モデルの賢さより先に、誰が何をしてよいかをきちんと縛る必要がある。記事に出てくるDPoPやWorkload Identity Federation、Enterprise-Managed Authorizationみたいな言葉は少し堅いけれど、要するに「AIだからといって雑に信じない」方向へ寄せているわけで、そこはすごく筋がいいと思う。 一方で、ロードマップとしてはかなり立派でも、現場でどこまでそのまま使えるかはまだ読めない。標準が整うほど、今度は実装側の負担が増える。便利さの裏で、運用する人間に求められる知識はむしろ増えそうだ。そこをどれだけわかりやすくできるかで、MCPが本当に広がるかが決まるのではないかと思った。 -

papoo.work