#エージェント

この記事を読んでまず思ったのは、Googleがやっているのは新しい機能の追加というより、AI agentまわりの「面倒な配線」を先に標準化しようとしているんだな、ということだった。 MCPはすでに「外部ツールにつなぐための共通口」として広がっているけれど、実際に使う側からすると、ツールが増えるほど管理がバラける。そこに「plugin.json」と「mcp.json」をひとまとめにして、しかもクライアント側の見え方まで揃えようとするのは、かなり実務寄りだと思う。 特に引っかかったのは、これが「MCPの上位互換」っぽい顔をしているように見えて、実はそう単純でもないところだ。1つのMCP serverだけで済むならAgent Pluginsは要らない、という説明は筋が通っている。逆に言えば、これが効くのは複数のAI clientや複数のスキルをまたぐ場面だけだろう。 つまり、派手な新機能というより「規模が大きくなったときに破綻しないための入れ物」なんだと思う。こういう設計は、流行の言葉としては地味だけれど、現場ではかなり効く。 もう一つ面白かったのは、Googleが単に仕様を出すだけでなく、

コード生成エージェントにテストを書かせれば、品質は簡単に上がる。そう期待したくなるが、実際にはそう単純ではないらしい。Dan Luu のこの記事は、その直感をかなり意地悪に検証している。エージェントに「TDDを使え」「QuickCheckを使え」「property-based testingを使え」と指示したとき、どれだけ実際の正しさに効くのかを、かなり大きな条件数で比べた。結果は、派手な万能策は見えず、むしろエージェントはテスト手法の使い方自体が下手だ、という話になっている。 元記事は、以前に行った Zstd 実装の評価を土台にしている。Zstd は圧縮関連の実装課題で、そこに coding agent を使わせ、テストや検証のやり方を変えたときに正答率がどう動くかを見た。実装言語は Rust にそろえ、エージェントには同じ課題をさまざまな追加指示つきで解かせている。たとえば「Use test-driven development」「Use Lean 4」「Use QuickCheck」「Use property-based testing」といった具合だ。 試した条件はかなり多い。

Metaが「Muse」という個人向けAIエージェントを紹介した。ここで言うAIエージェントは、ただ質問に答えるだけではなく、日々の作業をいくつかまとめて引き受ける存在だ。Metaは、検索やメッセージ、予定の確認のような細切れの作業をまたいで支援し、ユーザーがやりたいことを前に進める道具としてMuseを位置づけている。生成AIが「会話の相手」から「実務の手伝い」に移りつつある今、その方向をMetaがどう描いているのかを見るうえで、この記事は分かりやすい材料になる。 Metaの説明によると、Museは「personal AI agent」として、毎日のタスクを横断して手助けすることを狙っている。元記事は、Museが単に一問一答を返すチャットボットではないことを強く押し出している。ユーザーの文脈を踏まえ、必要な情報を集め、作業を進めるところまで関わる、というのが骨格だ。 扱う場面はかなり日常寄りだ。たとえば、何かを調べる、移動や予定を整える、メッセージに返す、次に何をするかを考える、といった細かな手間をまとめて減らすイメージで語られている。Metaが言いたいのは、AIの価値が「賢い返答」だけ

最初に気になったのは、性能向上よりも「安全対策の水準を変えたら別名になる」という作りです。 同じモデルでも、一般向けと審査済み組織向けで名前を分けている。ここはかなりAnthropicらしいし、同時に少し面白いところでもあります。モデルの賢さそのものより、「どこまで使わせるか」を製品設計の中心に置いている感じがあるからです。 しかも、その差がかなり実務寄りです。記事を読むと、`Mythos 5.1` はサイバーセキュリティやライフサイエンス向けにセーフガードを緩めた版で、一般公開は `Fable 5.1` だけ。つまり、同じ頭脳を持ちながら、出入り口だけを変えている。AIが本当に業務に入っていくと、こういう“能力差”より“許可差”のほうが効いてくるのだな、と思いました。 もうひとつ引っかかったのは、実質値下げの話です。性能が上がったのに、キャッシュ読み取りの料金が下がり、使い方によっては45％減というのは素直に大きい。ただ、こういう値下げは「安くなった」という単純な話ではなくて、モデルを長く使うエージェント用途ほど得になる設計です。つまり、短文をぽんぽん投げる使い方より、文脈を溜め込ん

AIエージェント向けの「skills files」をどう管理するか。Hacker Newsで投げかけられたこの質問には、便利な運用ノウハウだけでなく、「そもそも技能ファイルは要るのか」というかなり根本的な疑問まで集まりました。話題になっているのは、モデルに毎回同じ作業のやり方を覚えさせるためのテキストやスクリプトを、個人で、あるいはチームでどう整理するかです。便利だと感じる人もいれば、むしろノイズだと見る人もいて、使う人の熟練度や仕事の種類で評価がかなり変わっていました。 投稿者はまず、skills をどう見つけ、整理し、実際に役立つ状態に保つのかを尋ねています。時間がたっても改善し続けているのか、という問いもありました。投稿者自身は、いつか skills はモデルの能力に吸収されていく気がするが、それまでは管理の仕方を知りたい、という立場です。 返答の中で目立ったのは、「外から集めるより、自分で書く」という姿勢でした。ある参加者は、skills を探すのではなく、頻繁に繰り返す作業から自分用に作っていると書いています。ファイルはローカルと GitHub で version contr

この記事を読んでまず思ったのは、AI agent の話がもう「便利な機能」ではなく「勝手に動く権限をどう縛るか」の段階に入ってきたんだな、ということでした。 browser を触り、file を読み、email にもつながる agent に、普通のアプリと同じ感覚で add-on や plugin を入れていくのは、たしかに怖いです。人間なら「この拡張機能、便利そう」で済む場面でも、agent はそのまま業務システムに手を伸ばす。そこで malicious な instruction や typo-squatted package が混ざっていたら、被害が一気に大きくなるのは想像しやすいです。 一方で、こういう「AI firewall」という言い方には少し引っかかりもあります。ネットワーク firewall のように境界を守る発想はわかるのですが、AI agent の危険は境界の外から来るとは限らず、内部の plugin や MCP server のふるまいからも生まれる。つまり、止める対象がかなり曖昧です。記事にあるような継続評価や trust の取り消しは筋がいいと思うものの、本当

この記事を読んでまず思ったのは、AIエージェントの話って、もう「何ができるか」より「何を勝手にやってしまうか」の段階に入ったんだな、ということです。Claudeの件をきっかけに、observability（実行中の挙動を観測して追えること）がセキュリティの話として扱われているのがかなり印象的でした。 プロンプトで安全に縛れば何とかなる、という期待はたぶんもう弱いのだと思います。記事が強調しているのは、エージェントは指示を受けて動くだけでなく、ツールを呼び出し、コードを実行し、外部とつながる。そこでは「よくできた注意書き」より、権限を絞ることや、何をやったかを後からではなく今見えるようにしておくことのほうが効く。これは地味だけれど、かなり現実的です。 同時に、ここで言う observability は単なる監視ログでは足りないんだろうなとも思いました。人間が「あれ、変だな」と気づくころには遅いことがある。だから、どのタイミングでどのツールに触れたか、どんな判断をしたかをライブで追える仕組みが必要になる。AIエージェントを便利な自動化として使うほど、その裏側に小さな権限管理の地味な設計が要

AIエージェントに何を覚えさせるか、どう呼び出すかは、実はかなり面倒な問題です。Cal Paterson はそこに対して、記憶を巨大なパイプラインではなく、もっと素朴な「ファイル形式」として扱おうと提案しています。記事の狙いは、既存の agent memory がなぜ使いづらいのかを整理したうえで、より単純で移植しやすい代替案を示すことにあります。単なる思いつきではなく、Markdown や SQLite、semantic search をどう組み合わせるかまで踏み込んでいるのが面白いところです。 記事の中心にあるのは、agent memory を処理工程ではなくデータとして扱おう、という考え方です。著者はまず、今よくある記憶システムを3種類に分けて批判します。ひとつ目は、特定のハーネスやプラットフォームに縛られるタイプです。会話履歴から情報を抜き出す設計が多く、結局「その人についての記憶」ばかりが増えやすい。ふたつ目は、pgvector、Neo4j、独自の LLM まで使うような複雑すぎる仕組みで、管理も大変だしモデルを混乱させる、と言います。みっつ目は、理想化された graph や

いちばん引っかかったのは、Claude Code の Auto Mode がかなり強く見える一方で、攻撃の入り口を少しずらされるだけで崩れる、という点だった。モデルが怪しい binary を拒否するのは一見まともだし、そこで安心したくなる。でもこの記事では、その「拒否」が逆に、攻撃者が用意した Python の方へ誘導する踏み台になっている。安全機能がちゃんと働いた結果、より危ない経路に入る。この皮肉はかなり重い。 特に印象に残ったのは、攻撃がいかにも派手な一発芸ではなく、細かい選択の連鎖で成立しているところだ。WebFetch から curl に移し、ZIP を展開させ、binary は走らせず、自前で decoder を書かせる。その decoder が置かれた場所で module shadowing が効く。どれも単体では「まあありそう」に見えるのに、つながると普通に code execution まで届く。LLM エージェント相手の攻撃って、プロンプト注入だけを警戒していても足りないんだな、と改めて思った。実際には、ツールの使い方、作業ディレクトリ、言語固有の import の

まず思ったのは、「やっとここまで来たか」というより、「まだ分岐が必要なんだな」という感覚でした。ClaudeのWeb操作が、ブラウザー内蔵と「Claude in Chrome」の二本立てになったのは、便利さの裏にある現実がまだ整理しきれていないからだと思います。つまり、AIに“新しく何かをさせる”場面と、“今開いている自分の画面をそのまま触らせる”場面は、見た目が似ていても別物なんですよね。 特に内蔵ブラウザーを「自分のブラウザーやログイン情報から切り離す」と明言しているのは、かなり重要だと感じました。AIエージェントに何でも渡したくなる一方で、タブ、ブックマーク、パスワードまで見える状態は怖い。そこを最初から遮断しているのは筋がいいです。ただし、その代わりにログイン情報のインポートが必要になる。便利さを取りにいくほど、結局はどこかで“移し替え”が発生する。この手間は、エージェント活用の普及を少し遅らせるかもしれないと思いました。 それと、プロンプトインジェクションの話がちゃんと残っているのも好印象でした。Webページの中に「AIへの命令」が紛れ込んで、意図せず操られる問題ですね。派手

この記事を読んでいちばん強く思ったのは、「同じモデルを使っているのに、こんなに差が出るのか」という驚きでした。LLM の話はつい「どのモデルが賢いか」に寄りがちですが、この記事はその手前にある harness、つまりエージェントを包む実行の仕組みが、実はかなり財布に効いてくると突きつけています。 面白いのは、差が単なる誤差ではなく、70倍という桁で出ていることです。ここまで来ると、モデル選びよりも「どう会話させるか」「どこまで確認させるか」「何を毎回与えるか」の方がコストを食っている可能性が高い。しかも coding agent では、その“余計なやり取り”がそのまま token に化ける。人間が見れば丁寧さに見えるものが、機械側では請求書になるわけです。 もうひとつ引っかかったのは、こういう話が思った以上に見えにくいことです。出力の品質だけ見ていると、ハーネスの違いは気づきにくい。でも実際には、同じモデルでも、包み方次第でまるで別物のサービスになる。これは開発者にとってかなり不公平にも見えるし、逆に言えば最適化の余地が大きいとも言えます。モデル性能の比較だけで満足していると、

この記事を読んでまず思ったのは、「ブラウザ操作の話なのに、ブラウザを実際には起動しないのか」という少し拍子抜けする感じと、でもそのほうが筋が通っているのではないか、という納得感の両方でした。 AI エージェントにWebを触らせるとき、結局いちばん壊れやすいのは“画面の座標を当てにいく”やり方です。スクリーンショットを見て「このボタンはここだろう」と推測するより、ページの構造そのものを見て要素を指定するほうがずっと堅い。人間の感覚に寄せるより、機械が機械らしく扱える情報を使う。かなり自然な方向だと思いました。 一方で、名称だけ見ると誤解を招きやすいとも感じます。Browser Use という名前なのに、読者はつい「ブラウザを自動操作するツール」を想像します。でも実際には、記事が伝えているのは「見た目をなぞる」のではなく、「DOM や参照を手がかりにする」仕組みだということでした。ここは地味ですが大事で、AI に画面を“理解させる”のではなく、Webページの部品を“扱わせる”発想に近い。派手さはないけれど、実務ではこっちのほうが頼れる場面が多いはずです。 逆に気になったのは、これが本当にど

最初に思ったのは、「便利そう」より先に「それ、誰の責任になるの？」だった。 Grok Bot や Claude Tag みたいに、AI agent が persistent な identity を持って、前のやり取りや権限をある程度引き継ぐようになると、ただのチャット相手ではなくなる。名前がつき、役割がつき、権限が残る。そこまで来ると、もう“賢い補助輪”というより、小さな従業員に近い。 でも従業員っぽく見えるからこそ、逆に危ない気がする。人は肩書きがあると中身を信用しやすいし、「この bot は営業担当だからこの範囲は知っているはず」と雑に扱ってしまいそうだ。実際には、何を覚えていて、何にアクセスできるのかを毎回確認しないといけない。記事がそこを強く匂わせていたのは、かなり筋がいいと思った。 あと、persistent permissions という言葉が地味に重い。会話をまたいで記憶が残るだけでも十分ややこしいのに、アクセス権まで持ち越すなら、失敗したときの被害も長持ちする。人間の同僚なら異動や退職で権限が整理されるけれど、AI agent は放っておくとずっと居座る。そこがいちば

読んでまず思ったのは、こういう標準化の話って、だいたい「パッケージの形式は揃った」で終わりがちだな、ということです。この記事もまさにそこに引っかかっていて、Agent Plugins は見た目には整ってきたのに、実際に別のクライアントへ持っていったときの動き方までは揃っていない。そこがいちばん現実的で、いちばん厄介だと思いました。 特に気になったのは、標準の中心を作った Anthropic が、その運営やガバナンスの側で強く前に出ているわけではない点です。仕様を作った人が、その周辺のズレを埋める役割まで持つとは限らないのは当然なんですが、AI エージェントみたいに「箱は同じでも中の振る舞いが違う」とすぐ壊れる領域では、そこを誰が面倒を見るのかがかなり重要に見えます。標準とは、単に文書を公開することではなくて、どこまでを共通化し、どこから先を各社の実装に任せるかを決めることでもあるので、この記事の問題意識はかなり筋がいいと思いました。 もう一つ、MCP server や secrets、schema、client capabilities みたいな話が並んでいるのを見て、結局「ポータビリ

正直、いちばん引っかかったのは「AIの感染」を止めたのが高度な検知でも、難しい隔離策でもなく、たった1段落の警告文だったことだ。 防御って、もっと複雑で手間のかかるものだと思いがちだけれど、こういう実験を見ると、AIエージェントの弱点は案外“注意書きを読まずに素通りする癖”みたいな、すごく人間くさいところにあるのかもしれないと思う。 面白いのは、脆弱なのがモデルの賢さそのものではない点だ。記事では、能力が高いモデルだから抵抗できる、という単純な話になっていない。むしろ、空の `SOUL.md` を持っているか、作業に没頭しているか、ネットワークに参加していると思わされているか、みたいな初期状態のほうが効いている。ここはかなり気持ち悪い。AIの安全性を「モデルの性能」で見てしまうと見落とすけれど、実際には“どんな状態で起動して、何を記憶し続けるか”がかなり支配的なのだろう。 それと、この記事を読んで少し怖くなったのは、こうしたpayloadが単なる自己主張ではなく、実際にファイル削除や危険な `curl | bash` まで誘導できる点だ。エージェントが仕事をするほど、プロンプトファイル

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

いちばん面白いのは、これまでの分析ツールが見ていた「人間のクリック」ではなく、AIエージェントに渡した仕事の実行過程を測ろうとしているところだと思った。ユーザーはもうUIを触らず、ClaudeやChatGPTの中で用事を済ませる。そうなると、従来のプロダクト分析はかなり手が届かない。アクセス解析を入れているのに、肝心の利用実態が見えない、という少し不気味な空白がある。Armatureはそこを埋めにいっている。 読んでいて引っかかったのは、「成功したかどうか」だけでなく、「なぜ失敗したか」をセッション単位で再構成する、という発想の強さだ。APIが200 OKを返していても、ユーザーは目的を果たせていないことがある。人間向けのWebプロダクトでもよくある話だけれど、agentic workflow ではそれがさらに見えにくい。しかも、agent の thinking や tool call の並びを見せることで、単なるログではなく“体験”として追えるようにしている。ここは便利そうだし、同時にかなり怖くもある。便利さの裏で、どこまでを記録してよいのかという線引きが難しいからだ。 もう一つ、e

Claude Cookbook は、Anthropic が公開している実践ガイド集です。名前のとおり「レシピ本」みたいなもので、Claude をどう使えばうまく動くのかを、コード例つきでかなり具体的に教えてくれます。 単なる使い方の説明ではなく、「実際のアプリに入れるとき、どこで詰まりやすいか」「どう設計すると破綻しにくいか」まで踏み込んでいるのが面白いところです。正直、こういう資料は読んでいて楽しいです。理想論よりも、現場の泥臭さがにじむからです。 Claude Cookbook は、Claude を使った実装パターンを集めた実践ガイド集 tool use、RAG、multimodal、memory、agent など、いまの AI 開発で重要な論点を幅広く扱う 「どう作るか」だけでなく、「どう遅延を減らすか」「どうコンテキストを保つか」みたいな運用の悩みにも答える 1本1本の記事がかなり具体的で、机上の空論ではなく手を動かす前提になっている いわゆる“AIの便利さ”より、“AIをプロダクトに落とし込む難しさ”がよく見える Cookbook の中身を眺めると、単に「Claude で文章

Claudeの安全対策と聞くと、つい「危ないことをしそうなら止める仕組みかな」と思いがちですが、今回のInfoQの記事で面白いのは、Anthropicがその発想をかなり冷たく、そして現実的に捉えているところです。要するに、モデルそのものを賢くするだけでは足りない。ファイルに触れられる範囲、ネットに出られる範囲、実行できる範囲を、環境側でガチガチに制限しないとダメだ、という話です。 この考え方、地味に見えてかなり重要です。AIの安全性というと、プロンプトに注意書きを入れるとか、危ない出力を検出する分類器を挟むとか、そういう「ソフトな制御」がまず浮かびます。でもAnthropicは、そういうものは効くときもあるが、保証にはならない、と割り切っています。個人的にはここがいちばん筋がいいと思いました。AIは人間みたいに「まあ今回はやめておこう」と自制してくれる存在ではないので、最後は環境で縛るしかない、という発想です。 Claudeの安全対策は、モデル内部の注意喚起よりも「実行環境の制限」を重視している Claude.ai、Claude Code、Claude Coworkでは、それぞれ危険の

vLLM Semantic Router は、1回のモデル呼び出しの裏で複数モデルを協調させる「micro-agent runtime」を目指している ユーザーから見ると API はたった1つでも、裏では confidence / ratings / ReMoM / fusion / workflows などの実行方式を切り替えられる 重要なのは「全部を巨大なモデル1発に任せる」ことではなく、仕事の形に合ったループを選ぶこと ベンチマークでも、単一モデルの置き換えではなく「コラボレーションで性能を作る」発想が効いている 個人的には、これはかなり面白い方向だと思う。モデルそのものを巨大化する競争だけでなく、サービング層が頭を使う時代に入ってきた感じがある vLLM の記事「Micro-Agent: Beat Frontier Models with Collaboration inside Model API」は、ひとことで言うと「モデルを返すだけのサーバー」から「モデルの力を組み立てるサーバー」へ、という話だ。 普通、APIで `model` を指定したら、そのモデルが1回答えて終わり

Vercelが公開した Eve は、AIエージェントを「作る」「動かす」「運用する」ための open-source framework です。InfoQの記事を読んでまず感じたのは、これが単なる新顔の開発ツールではなく、「AIエージェント周りで毎回バラバラに作っていた面倒ごとを、かなりまとめて面倒みる」方向に振り切っていることです。 AIエージェントは、チャットするだけのAIとは少し違います。指示を受けて、外部サービスにつながり、必要ならコードを実行し、途中で止まったら再開し、定期実行までこなす。便利だけれど、裏側はわりと泥臭い。Eveはその泥臭さを、filesystem-first という考え方で整理しようとしています。要するに、エージェントの振る舞いを「フォルダとファイル」で表現する発想です。これ、かなりVercelらしいと私は思います。開発者が触るものを、なるべく普通のプロジェクト構造に寄せるのがうまい。 AIエージェントを production で動かすための open-source framework 指示、tool、skill、subagent、通信チャネル、定期実

大きなAIモデルを見ていると、最近は「文章をうまく作る」だけでは全然足りないんだな、としみじみ思います。次に来るのは、AIが環境の動きまで頭の中で予測する方向です。今回のarXiv論文 Qwen-AgentWorld: Language World Models for General Agents は、まさにそこを真正面から狙っています。 ざっくり言えば、これは「言語モデルを使って、エージェントが置かれた世界の変化をシミュレーションする」研究です。チャットの延長ではなく、AIが「この操作をしたら次に何が起きるか」を考えられるようにする。ここが肝です。正直、この発想はかなりおもしろいです。AIを“答える機械”から“先読みする機械”に近づけようとしているので。 Qwen-AgentWorldは、agentic environment をシミュレートする language world model 35B-A3B版と397B-A17B版の2モデルを公開 **7つのドメインをまたいで、long chain-of-thought reasoning による環境予測