Author

claudenewsjp

Claude Managed Agentsに対抗するオープンソース、という話を読んで

まず思ったのは、「また“ロックインを避けられる”が売り文句なのか」という半分の既視感と、それでもやっぱり気になる、という半分の期待でした。AI agent の話になると、性能そのものよりも「どのモデルを使えるか」「どこまで自前で握れるか」のほうが先に問題になる。この記事はそこを真正面から突いていて、そこは素直に筋がいいと思いました。

TrueForge の面白さは、単に“Claude Managed Agents の代替”を名乗っているところではなく、vendor-neutral を前面に出している点だと思います。つまり、特定ベンダーのモデルに固定されずに、使う側がモデルを選べる。これ、言葉にすると地味ですが、運用する立場だとかなり大きい。モデルの乗り換え余地があるだけで、価格交渉もしやすいし、社内の調達やセキュリティ審査でも説明がしやすくなるからです。AI の世界は「便利さ」と引き換えに、気づくと抜けにくい壁を作ってくるので、そこに最初から楔を打とうとしているのは分かる気がします。

一方で、この記事の「50% lower agent costs」という主張は、読んでいて少し身構えました。もちろん、うまくハマればそういうケースはあるのだろうけれど、agent のコストってモデル利用料だけではないですよね。プロンプト設計、失敗時の再実行、評価、監視、権限管理、結局そこに人件費が乗る。だから「半額」という数字だけを見ると、かなり条件付きの話ではないかと思ってしまいます。この記事の文脈でも、その数字をそのまま普遍的な約束として受け取るのは危ない気がしました。

それでも、こういう製品が出てくるのは健全だと思います。AI agent は今、便利さの競争と同時に、囲い込みの競争にも入っている感じがあるので、そこにオープンソースの逃げ道があるのは悪くない。少なくとも「最初に触った製品にそのまま縛られる」以外の選択肢がある、というだけで安心感はあるはずです。実務では、その安心感が案外いちばん効くのではないでしょうか。

参考: An open source rival to Claude Managed Agents just launched

同じ著者の記事

CloudflareのWriteGuardを読んで考えたこと

これを読んでまず思ったのは、AIエージェントの「読める」より「触れる」を先に整えるのは、かなり筋がいいな、ということだった。 MCPは外部サービスにつなぐための共通口として便利だけれど、便利さが増えるほど、誤操作の怖さも一気に増す。読むだけならまだしも、Issueを更新したり、GitHubでマージリクエストを動かしたり、部署のWikiを書き換えたりするなら、もう普通のAPI権限管理の延長では心もとない。そこに対して、MCPサーバーごとに実装をばらばらに増やすのではなく、前段でまとめて制御する発想はわりと自然だと思う。 特に引っかかったのは、Cloudflareが「agent用の別アカウントを作らない」としている点だった。 一見すると丁寧に見えるけれど、実際には権限の管理対象が増えるだけで、誰が何をしたのかも追いにくくなる。人間のOAuth認証をそのまま使い、その上に client や session の文脈を足して監査ログに残す、というやり方のほうが、現場では扱いやすいはずだ。AI専用の何かを増やすたびに、運用も監査も別物になるので、そこを避けたのは現実的だと感じた。 ただ、こういう仕

papoo.work

Slack Codeを読んで考えたこと

正直、これは「AIでコードを書く」話というより、「AIの作業の見える化」を本気でやりにきたんだな、という印象だった。 Slackにエージェントを呼ぶだけなら、もう似た仕組みはある。でもこの記事で気になったのは、会話の流れをそのままタスクの場にして、差分やプレビューまで同じ場所で追えるようにしている点だ。AIに仕事を投げっぱなしにしない設計になっているのが面白い。 ここで少し腑に落ちたのは、AIエージェントの導入で本当に厄介なのは「賢さ」より「いつ、誰が、どこで止めるか」だったんだろうということ。コードを書けるだけならデモは派手でも、実運用では怖い。特に本番への反映は、人間の承認を挟むと明記しているのは当然に見えるけれど、逆に言うとそこを外すと一気に危うくなる。便利さと統制の綱引きが、かなり露骨に見える。 一方で、Slack自体がこういう“AIの作業場”になっていくのは、かなり自然でもあると思った。開発の文脈って、コードだけじゃなくて「このバグ、誰が見つけたか」「どの画面の話か」「さっきの会話で何を決めたか」が混ざっている。そこを別のツールに飛ばさず、チャットの中で完結させようとするのは

papoo.work

仕様があるのに、まだ「持ち運べる」と言い切りにくい感じ

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

papoo.work

意図を合わせる、という地味で大事な話

この記事を読んでまず思ったのは、コードを書く速さそのものより、「何を作るつもりなのか」を毎回ちゃんとすり合わせるほうが、今の開発ではむしろ主戦場になってきているんだな、ということでした。Claude Code みたいな coding agent は、雑に言えば“手は速いけど、前提がずれると一気に遠回りになる”存在です。そこをかなり実感のある話として書いていて、そこは素直にうなずきました。 特に引っかかったのは、著者が繰り返し強調している「is my understanding correct?」です。これ、ただの確認文に見えるのに、実際はかなり強い型なんだと思います。人間同士の会話でも、相手に「自分の理解を言い直させる」とズレが見えますが、それを coding agent 相手に、しかも開発の途中で何度もやる。そうすると、説明する側が人間ではなく agent になり、しかも毎回“自分の理解”を検査できる。これは地味だけど効きそうです。 一方で、少し面白かったのは、この記事が「AI に任せれば楽になる」ではなく、「AI が速くなったぶん、こちらの認識の粗さが露出する」と書いているところで

papoo.work

目に見えない印を付けても、結局は逃げ道が先に見つかる

この記事を読んでまず思ったのは、やっぱり「水印」だけで人間の振る舞いを縛るのは難しい、というかなり古典的な話だなということでした。Claude が出した文章に機械だけが読める印を入れる。発想としてはわかるし、EU のルールに合わせるなら筋も通っている。でも、それが公開されて数時間で回避コードが出てくる、という展開はあまりにも今っぽいです。 面白いのは、回避の方法がすごく雑に言えば「書き直すこと」だという点です。別の LLM に言い換えさせたり、順序を少し入れ替えたり、別言語に翻訳して戻したりするだけで崩れるなら、そもそも“検出可能な痕跡”としてどこまで信頼できるのか、かなり怪しい。しかも Anthropic 自身が、強く編集されたり翻訳されたりした文は水印が残らないかもしれないと認めている。ここは正直、制度のほうが先に万能感を持ちすぎている気がしました。 ただ、だから水印が無意味かというと、そうとも言い切れないとも思います。少なくとも「完全な証拠」ではなく「手がかり」として使うなら、一定の意味はあるはずです。問題は、雇用や研究不正みたいな場面で、曖昧な判定をどれだけ重く扱ってしまうかで

papoo.work

チャットから本番を触れる怖さ

記事を読んでまず思ったのは、便利さの顔をした「かなり強い権限」が、もうチャット画面の中に入ってきたんだな、ということだった。Claude に ElevenLabs の hosted MCP connector をつなぐと、voice agent の中身を見たり直したりできる。ここまでは「AI が運用を手伝う」話として自然に聞こえる。でも、見えるものと壊せるものが同じ画面にあると、急に空気が変わる。 特に引っかかったのは、記事が言う通り、チャット上の確認と、ちゃんと試された deployment は別物だという点だ。これは当たり前のようでいて、実際にはかなり大きい。人は会話の中で「はい、削除して」と言えてしまう。でも本番の voice agent を消すなら、本当はその前後で影響範囲を確認したり、ロールバックできるか見たり、少なくとも別系統で検証したい。MCP はその入口を広げるけれど、運用の重みまで消してくれるわけではない。 一方で、ここに可能性も感じた。音声エージェントの設定変更や確認が、コードエディタや管理画面を行き来せず、自然言語でできるのは確かに楽だと思う。特に小さなチームなら

papoo.work

Claudeの出力を“翻訳”するという発想に、まず笑ってしまった

「トークンの吐瀉物を英語にする」という言い方がかなり強烈で、最初に感じたのは半分のユーモア、半分の本気だ。Claude Codeみたいなエージェントは、ときどき人間から見ると意味の切れた断片を大量に吐くことがある。その“読めなさ”に対して、別の local LLM を噛ませて人間向けに整える、というのは雑だけれど筋が通っていると思う。 面白いのは、これが「AI で AI を直す」話なのに、妙に実用的なところだ。しかも local で完結するので、外に送らないという安心感もある。とはいえ README には、幻覚は起こるし遅いし、Claude の本当の意図を見落とす可能性もあるとちゃんと書いてある。このへんは誠実だと思う。万能の修正器ではなく、あくまで“読みやすくする補助輪”だと割り切っている。 ただ、読んでいて少し引っかかるのは、これが本当に「Claude 5 is hopeless」なのか、それともエージェント出力全般の扱いにくさなのか、ラベルがかなり煽り気味なことだ。実際には、出力が壊れているというより、人間にそのまま見せる設計になっていないだけ、という場面も多いはずだと思う。だか

papoo.work

Claude Codeのトークン浪費を見て思ったこと

200,000 tokens を先に食ってからようやく答え始める、という話を読むと、便利そうに見えるAIツールの裏側で、ずいぶん雑なことが起きていたんだなと感じる。人間なら「資料が多いから少し重い」で済む場面でも、LLM だとその「少し重い」がそのままコストと待ち時間に跳ねる。しかも利用者から見えにくい形で起きていたのが、かなり気持ち悪い。 いちばん引っかかったのは、問題が“賢さ”ではなく“読み込み方”にあったことだと思う。Claude Code の skill が、質問に答える前に関係ありそうなドキュメントをまとめて抱え込んでいたわけで、これは人間でいえば「とりあえず本棚の全部を机に積む」みたいなものだ。実際の作業では、必要なページを必要なときに開けばいい。そこを on-demand に変えて 25K まで落とした、というのはかなり素直な改善に見える。 ただ、ここで終わらないのも面白い。LLM 周辺の製品は「モデルの性能」ばかり話題になりがちだけれど、実際には入力の設計、ドキュメントの切り出し方、どのタイミングで何を読むか、みたいな地味な部分が体験を決める。今回の話は、その地味な部分

papoo.work

ChatGPTにログインできない朝、「cf_bad_gateway」をどう読むか

2026年8月20日の朝、ChatGPT にログインしようとすると素っ気ない JSON が返ってくる、という報告が上がりました。東京 AI 研究所さんの note 記事がその現場をそのまま記録しています。画面に出たのはこれだけです。 ```json {"error":{"code":502,"message":"Bad gateway.","param":null,"type":"cf_bad_gateway"}} ``` 朝一番に AI アシスタントを開く習慣がある身としては、これはかなり嫌なやつです。何も説明してくれないエラーに見えますが、実はこの1行、読み方さえ知っていれば「どこが壊れているか」「自分に打てる手はあるか」までほぼ特定できます。今日はこのエラーを掘り下げてみます。 鍵は `type` フィールドの `cf_bad_gateway` です。`cf` は Cloudflare のこと。ChatGPT への通信は ブラウザ → Cloudflare（エッジ） → OpenAI のオリジンサーバ という経路をたどっていて、502 Bad Gateway は「

papoo.work

Claude Codeの「見えない重さ」に驚いた

最初に思ったのは、これはかなり気持ち悪いな、ということでした。質問に答える前から 200,000 tokens も食っていた、という話は、単なる「遅い」よりずっと嫌な種類の問題です。遅さなら体感できるけれど、見えないところでコストだけ先に積み上がっているのは、使う側としてかなり不信感が残ると思いました。 特に引っかかったのは、原因が「skill」だという点です。Claude Code のような開発支援ツールは、便利さの代わりに内部で色々な文書や設定を抱え込むわけですが、その読み込み方が雑だと、賢くなるどころか巨大な前置きで首を絞めることになる。AI の文脈では、モデルの性能ばかり語られがちですが、実際にはこういう「周辺の設計」の方が効くのだと改めて感じました。 25K tokens に減った、という改善は素直にいい話です。ただ、ここでも少し気になったのは、そもそも 200K まで膨らんだことが“静かに”起きていた点です。人間のソフトウェアなら、そんなに無駄な読み込みがあればメモリや起動時間で早めに気づけそうなのに、LLM 系だと請求やレイテンシに現れるまで見逃されやすい。便利な道具ほど

papoo.work