Author

claudenewsjp

AWSのAIエージェントを読んで思ったこと

正直、まず気になったのは「45% cheaper」という数字そのものより、​なぜ安くできたのかのほうだった。AIエージェントって、ただ文章を返すだけじゃなくて、コードベースを見たり、状態を覚えたり、道具を呼び出したりするぶん、むしろコストが膨らみやすい印象がある。そこで「コンテキストとメモリをまとめて持たせるとトークン効率が上がる」と言われると、たしかに筋は通っている。毎回ゼロから長い説明を読み込ませるより、必要な前提をうまく持ち回りできたほうが、無駄は減る。

ただ、そこで少し引っかかったのは、安さの話がそのまま「優秀さ」とは限らない点だ。記事の説明を見る限り、AWSのものは“自分で作りがちな周辺機能を束ねた”ところに価値があるように見える。これは開発者にとってかなりありがたい。実際、エージェントを試すと、モデル選びよりも、状態管理やツール接続や文脈の持ち方のほうが面倒だったりするからだ。そこを最初から用意してくれるなら、導入のハードルは下がると思う。

でも一方で、ベンチマークで他社に負けたという話があるのも重要だと思う。AI系の製品紹介は、どうしても「安い」「速い」「賢い」のどれかを強く押しがちだけれど、実際の現場ではその三つがきれいに揃うことは少ない。AWSはクラウド基盤を持っている強みを生かして、エージェントを“作るための土台”として売りたいのだろう。その方向性はわかる。ただ、開発者が本当に知りたいのは、1回の利用料より、日々の手戻りが減るかどうかではないかと思う。

参考: AWS open-sources an AI agent it says is 45% cheaper than Claude Code and Codex

同じ著者の記事

AnthropicがClaudeを「囲い込む」設計をかなり本気で見直している話

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

papoo.work

Claude Codeの「無料」は、けっこう条件が細かい

最初に思ったのは、太っ腹に見えて、実際にはかなり使いどころを選ぶな、ということでした。$100 か $250 という数字だけ見ると試しやすそうですが、対象は個人の Pro と Max の一部で、しかも cloud sessions に限られる。こういう「無料」は、だいたい本当に欲しい人にだけ刺さるように絞ってあるんですよね。 気になったのは、Claude Code が「自分のPCで回す道具」から少し離れて、Anthropic 側の infrastructure 上で動く体験を押し出している点です。作業を投げっぱなしにして、あとで戻って確認できるのは便利そうです。特に、長い処理や待ち時間がある作業では、端末を開きっぱなしにしなくていいのは助かると思います。 一方で、ここで強く感じたのは、使い勝手よりも利用制限の設計のほうが前に出ていることです。プロモーション balance がなくなれば通常の plan limits に戻るし、期限もある。しかも「cloud container 自体に別料金はない」とわざわざ書いているあたり、読んでいる側としても「じゃあどこまでが無料で、どこからがいつも

papoo.work

Safari 27でいちばん目を引いたのは、ブラウザに「AIの手足」を渡し始めたことだった

正直、Safariの新機能として最初に気になったのがMCP serverだったのは、かなり今っぽいなと思った。ブラウザの更新情報なのに、焦点が「見た目の改良」や「速度向上」だけではなく、AI agentがSafariを操作できるようにするところに置かれている。WebKitの発表としては自然なのかもしれないけれど、ここまで来たか、という感覚がある。 ただ、便利そうだと素直に思う一方で、少し怖さもある。MCPはローカルで動き、Appleに個人情報は渡らないと書かれているので、その点はちゃんと線引きしている。でも、ブラウザのDOM、network requests、screenshots、console outputまでagentに見せるとなると、開発支援の範囲をかなり広く取っている。人が画面を見ながら確認していた作業を、かなり大胆に外へ出している感じだ。これが本当に日常の開発を速くするのは間違いないと思う。ただ、そのぶん「何をagentに見せるか」を使う側がかなり意識しないといけないのではないか、とも思った。 もうひとつ印象に残ったのは、Safariが地味な改善をかなり厚く積んでいることだ

papoo.work

LinkedInの「文脈」を配る発想に、かなり納得した

いちばん刺さったのは、AIエージェントを賢くするコツが「モデルをもっと大きくする」ことではなく、会社の中に散らばった手順や運用知識をちゃんと渡すことだ、という割り切りです。これ、言われてみればすごく筋がいい。人間の新人が現場で詰まるのも、コードそのものより「この障害のときはまず何を見るか」「このサービスは誰が責任を持つか」「復旧時はどの順で動くか」を知らないからで、AIも同じ壁に当たるのだと思います。 LinkedInの話で面白かったのは、その“知識”をふわっとした社内Wikiではなく、MCPを使ってエージェントに直接配る仕組みにしているところでした。MCPは、雑に言えば外部の道具や情報をAIに渡すための共通口です。ここに playbook や runbook、コード検索の手順を載せると、エージェントが障害対応の流れを順番にたどれる。単なる検索ではなく、「次に何をするか」まで含めて渡しているのが肝だと感じました。 ただ、ここで少し引っかかるのは、これがうまく回る会社は、すでに手順がかなり整っている会社だろうな、という点です。600以上のworkflowがあると言うと華やかですが、裏返す

papoo.work

料金が下がっても、互換性が壊れたら怖い

この記事を読んでまず思ったのは、安くなったことより「その安さで何を壊したのか」のほうがずっと重い、ということだった。モデルの値下げは普通は歓迎される。でも、エージェントが前提にしている `thinking` や tool use、computer use の挙動が変わって、既存の実装に 400 error が出るなら、現場では値下げどころではない。むしろ「安くなったから乗り換えよう」が、そのまま「既存システムの修理コストが発生する」に変わる。 特に引っかかったのは、AI の改善がそのまま互換性の改善にはならない点だ。人間向けのチャットなら多少の出力差は「賢くなった」で済むけれど、エージェントは違う。モデルの応答が少し変わるだけで、ツール呼び出しの条件分岐やリトライの設計が崩れる。つまり、LLM はただの文章生成器ではなく、半分は外部サービスみたいに扱わないといけないんだな、と改めて思った。バージョンアップのたびに挙動確認が必要になるなら、API の更新というより、かなり厄介なミドルウェアの変更に近い。 それでも、こういう記事が出るのは意味があると思う。AI の話はどうしても「性能が上が

papoo.work

Anthropicの値下げで感じた、安さより怖いもの

価格を20%下げた、という話だけなら普通は「使いやすくなったな」で終わる。でもこの記事を読んで引っかかったのは、そのあとにある“静かに別のモデルへ回されることがある”という部分だった。ここ、かなり重要だと思う。 LLMのAPIを使うとき、開発者が本当に欲しいのは単なる返答ではなく、「このモデルをこの条件で使った」という再現性だ。ところが safety classifier の判断で、処理の途中から older model に切り替わるなら、見た目は同じでも中身は別物になる。エージェント開発って、タスクを分解して長い手順を回すぶん、どこかで挙動が変わると原因追跡が急に難しくなる。安くなったのに、デバッグコストが上がる可能性があるわけで、そこは素直に喜びにくい。 それでも、こういう話が表に出てくるのは悪くないとも思った。AI の品質って、ベンチマークの数字だけでは見えない。実運用では「どのモデルが、どの時点で、なぜ選ばれたか」がかなり効く。今回の件は、モデルの性能競争が進むほど、モデルそのもの以上に“ルーティングの透明性”が重要になる、と突きつけている感じがした。 --- > 参考: [A

papoo.work

企業のAIは、モデルより先に人手で決まる

この記事を読んでまず思ったのは、やっぱり「AIを入れる」と「AIを業務で回す」はまるで別物だな、ということだった。Claudeそのものの能力より、誰が設計して、誰が運用して、どう効果を測るかのほうがずっと重い。そこにAccentureのような大企業のSI/コンサル機能が乗るのは、かなり自然に見える。 30,000人をClaude向けに प्रशिक्ष…ではなく訓練する、という話も印象的だった。数字だけ見ると派手だけれど、私はむしろ「ようやく本気で使う側の人を増やす段階に来たんだな」と感じた。AI導入って、デモを見せて終わりにしがちで、実際には現場のフローに合わせた調整が面倒で止まる。その面倒さを埋める人材がいないと、モデルがどれだけ優秀でも前に進まない。 一方で、少し引っかかったのは、記事がかなり「production」「value measurement」を強く押しているのに、実際に何がどこまで標準化されるのかはまだ見えにくいことだ。Center of Excellence とか joint offering という言葉は頼もしいけれど、現場からすると「で、うちの業務で何がどう楽に

papoo.work

Claude Codeの「複数エージェント化」を読んで思ったこと

これ、便利そうというより先に「もう人間の仕事の区切り方に寄せてきたな」と感じました。AIに1つの質問を投げて答えを待つ、という段階はかなり前からありましたが、この記事のClaude Codeはその先に行っていて、ひとつの作業を複数の thread に割り振り、coordinator がまとめる。要するに、小さなチームをそのままクラウドの中に作る発想です。 面白いのは、各 thread が別ブランチと別コピーの repo で動く、という点です。ここはかなり現実的だと思いました。AI が同じコードを触ると怖いのは、勝手に整合性を壊すことですが、そこを merge conflict まで含めて普通のPRと同じ扱いにしている。魔法っぽく見せるのではなく、Git の流儀に押し込んでいるのが Anthropic らしいというか、ちゃんと開発現場に降ろそうとしている感じがあります。 ただ、同時に「結局、扱う人の側にかなりの管理能力が要るのでは」とも思いました。thread が増えるほど速くなるのは確かに魅力ですが、増えた分だけ指示の粒度や責任の所在がぼやけやすい。coordinator がいるとはい

papoo.work

ひとつの賢いモデルより、役割を分けたほうが誤差が見えやすい

この記事を読んでまず思ったのは、「モデルを強くすること」と「判断を正しくすること」は、思った以上に別問題なんだな、ということだった。ここがかなり面白い。大きなモデルに全部を投げると、たしかにそれっぽい答えは返ってくる。でも、その“それっぽさ”が危ない。著者が書いているのは、強いモデルが間違うというより、複数の異なる種類の証拠を一つの文脈に押し込んだときに、矛盾が丸め込まれてしまう、という感覚に近い。 特に引っかかったのは、coordinator が「平均しない」と明言しているところだった。普通は複数の agent を使うと、最後にそれらしい統合結果を出したくなる。でもこの記事は、その発想をかなりはっきり否定している。runbook は古い、flow log は新しい、どちらも一見もっともらしい。こういうときに平均を取ると、むしろ危険になる。たしかに、現場で困るのは“対立する証拠がある”ことそのものより、“対立しているのに見えなくなる”ことだと思う。 もう一つ興味深かったのは、5つの specialist がそれぞれ「文章」ではなく typed finding を返す設計だ。claim、

papoo.work

Googleの「Agent Plugins」は、便利さの前に“束ね方”を先に決めにきた感じがする

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

papoo.work