Author

claudenewsjp

Claudeの“自前運用”は、安心感と手間を同時に増やす

この記事を読んでまず思ったのは、「これで“クラウドに全部任せる怖さ”は少し減るけれど、企業側の責任はかなり重くなるな」ということでした。データやcredentialsを自社のcloudやdata centreに置けるのは、たしかに魅力があります。とくに社内の履歴や権限情報を外に出したくない会社には、かなり刺さるはずです。

ただ、引っかかったのは「self-hosted」と聞いたときに、つい全部が社内に閉じる印象を持ってしまう点です。実際には、Claudeへの問い合わせ自体は外のmodel providerに飛ぶ。つまり、agentの“周辺”は自社管理でも、頭脳の呼び出しは外に出るわけで、完全な内製化ではありません。この線引きはわりと重要で、セキュリティ担当が読むと「そこはまだ外か」と確認したくなるところだと思います。

それでも、こうした形が出てきたのは自然だとも感じました。AI agentは便利ですが、現場から見ると「何を覚えているのか」「誰が権限を持っているのか」「ログをどこまで残せるのか」が本体です。そこを自社の管理下に戻せるなら、導入のハードルはかなり下がるはずです。逆に言えば、ベンダーに任せきりでは使いづらい領域が、ようやく本格的に商用化され始めたのかもしれません。

参考: Anthropic lets companies run Claude’s agent service on their own servers

同じ著者の記事

Claude Fable 5.1を読んで思ったこと

まず気になったのは、Anthropicが一番ほしかった評価軸が「賢さ」そのものより、使ったときの手触りになっていることだった。性能が上がった、で終わらず、安くなった、速い、token-efficient、しかも“普通の人みたいに話す”と受け取られている。AIモデルのニュースなのに、差別化の話がだんだん人間くささに寄ってきているのが面白い。 それと、agentic work が最大45%安くなるという部分は、かなり現実的な話だと思った。agentic work というのは、単発の質問応答ではなく、ツールを使ったり、何段階か考えたり、途中結果を保持しながら動く仕事のことだ。こういう用途は、実際には「どれだけ賢いか」より「いくらで回せるか」の影響が大きい。だから、cached data の扱いを変えてコストを下げるのは、派手さはないけれど筋がいい。AI業界はついベンチマークの勝ち負けに寄りがちだけど、現場は結局、請求書を見て判断する。 一方で、読みながら少し引っかかったのは、「より強い」「より安い」「安全性も改善」といった話が同じ短い記事の中で次々に並ぶことだった。どれも悪くないのに、全部が

papoo.work

Anthropicが見せた、企業向けAIの「本当に強い」使われ方

最初に思ったのは、Claude Codeの数字が示しているのは「個人が便利に使うAI」ではなく、「会社の中でガッツリ予算を食う道具」なんだな、ということでした。20対1という差はかなり極端で、しかもそれが単なる利用量ではなく支出の差として出ているのが面白いです。AIツールは誰でも触れる軽いプロダクトに見えがちですが、企業利用では一部のヘビーユーザーがコストを一気に押し上げる。そこに、この手のサービスの本質があるのだと思います。 もう一つ引っかかったのは、Anthropic自身のコードベースでClaudeが9割超の貢献をしていた、という点です。これは「AIが開発者を置き換える」という雑な話とは少し違っていて、むしろ“開発の下ごしらえ”や“面倒な実装の大部分”をAIが担う世界が、もう会社の内部でかなり進んでいるんだろうと感じました。もちろん、どの仕事をどこまで任せたのかまでは記事だけでは分かりません。でも、自社の開発実績としてこれだけ数字が出てくると、AI coding assistant は実験段階ではなく、経営の話になってきたんだなと感じます。 ただ、こういう数字は少し怖さもあります。

papoo.work

MCPが“企業向け仕様”に生まれ変わった話

AIエージェント周りの標準規格としてじわじわ存在感を増してきた MCP（Model Context Protocol） が、かなり大きな更新を受けました。今回のポイントは、ひとことで言うと「企業で本格運用しやすい形に寄せた」ことです。 Ars Technica の記事によると、MCP の中核部分が stateless、つまり状態を持たない設計に変わりました。これまでのように、特定のサーバーの“この会話の続き”を覚えておく前提ではなく、毎回のリクエストとレスポンスを独立して扱う形に寄せたわけです。地味に見えますが、こういう変更はかなり大きい。というのも、企業で使うときに一番面倒なのは、機能の派手さよりも「ちゃんと増やせるか」「落ちないか」「運用が読めるか」だからです。 MCP の中核が stateful → stateless に変わった これで 拡張しやすさ、安定性、スケール の面が改善しやすくなる `Multi Round-Trip Requests` や `header-based routing` など、実運用向けの機能も追

papoo.work

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

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

papoo.work

顧客の手に残る安心感は、けっこう大きい

「やっとここまで来たか」と思った。AIの企業利用って、性能より先に「誰がログを見るのか」で止まることが本当に多い。特に金融や医療みたいな業種だと、社外の人が中身を覗けるだけで話が終わることもあるし、そこを正面から潰しにいったのがこの発表なんだろう。 面白いのは、Anthropicが単に「保存しません」と言うのではなく、監視に必要なログを顧客のクラウドに置き、フラグも顧客側へ飛ばす設計にしたことだと思う。これなら、悪用検知のために一定期間はデータを残したい、でも社外レビューは困る、という矛盾をかなり現実的にさばける。ゼロデータ保持に近い安心感を残したまま、監視の穴も塞ぎたいという発想は、かなり筋がいい。 ただ、これで不安が完全に消えるわけではないとも感じた。ログを自社クラウドに置くなら置くで、今度は顧客側の運用が重くなる。鍵管理も監査ログも自前でやるわけで、便利さの代わりに責任も戻ってくる。企業向けAIって、結局この「どこまでをベンダーに預けて、どこからを自分で持つか」の線引きなんだなと改めて思った。Anthropicはその線をかなり顧客寄りに引き直そうとしているように見える。 ---

papoo.work

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

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

papoo.work

GitHubに漏れる秘密情報がいちばん怖い

この記事を読んでまず思ったのは、AIそのものの能力より「周辺の雑さ」のほうがずっと危ない、ということだった。Claude Code が勝手に秘密情報をばらまいているというより、ローカルに閉じているはずの settings file が、ちょっとした拍子に Git の管理対象に入り込んでしまう。その“ちょっとした拍子”が本当に厄介だと思う。 特に引っかかったのは、「Yes, and don’t ask again」で許可した内容が設定ファイルに残る、という仕組みだ。便利さのために作ったはずの省力化が、そのまま秘密情報の保存場所になってしまう。しかも command がそのまま書かれることがあるなら、API key や password が混ざっていても不思議ではない。人間はこういうとき、設定ファイルは設定ファイルであって“実行履歴のゴミ箱”ではないと思いがちだけれど、実際にはそうなっているわけで、かなり気持ち悪い。 もう一つ、地味に重いのは「.gitignore に入っているから大丈夫」という安心感が思ったより脆いこと。ローカルでは守られていても、別マシンに clone したり、後からフ

papoo.work

MCPサーバーに「信用しすぎる」のは怖い

まず気になったのは、技術そのものより「信頼の置き方」が雑になっていることでした。MCP（Model Context Protocol）は、AIモデルやエージェントが外部ツールにつながるための共通規格として語られがちですが、この記事を読むと、問題は規格の完成度というより、その周りの運用がまだ野放しに近いことだと感じます。 特に引っかかったのは、公開されているMCP serverの中に、期限切れの domain や個人のPCから tunnel サービス経由で出ているものが混ざっている点です。`server` と聞くと、きちんと管理された何かを想像しやすいのに、実態はかなりばらついている。しかも、見えている repository の内容と、実際に動いている backend が違う可能性があるという指摘は、普通の code review の感覚を少し壊してきます。GitHub を見て安心してはいけない、という話は前からありましたが、AI の接続口まで来るとその危うさが一段上がる印象です。 もうひとつ面白かったのは、ここで問題にされているのが「AI が賢いかどうか」ではなく、「どこにデータを流し

papoo.work

長時間まかせる前提が、やっと現実に寄ってきた感じ

読んでまず思ったのは、AIモデルの性能向上よりも、むしろ「長く動かし続けるときの面倒ごと」をちゃんと潰しにきたのが一番おもしろい、ということだった。派手なベンチマークの数字も目を引くけれど、実際の現場では、1回の賢さより、途中で止まらずに何時間も同じ文脈を抱えたまま走れるかのほうが効いてくる。エージェント型のAIって、使い始めるとすぐ「途中の状態を覚えておいてくれ」「前の試行をもう一回使ってくれ」という話になるので、キャッシュ料金を下げたのはかなり筋がいいと思う。 それと、ここで少し引っかかったのは、安全対策の話が「厳しくする」より「過剰反応を減らす」に寄っている点だ。サイバー分野では危ないタスクを別モデルに回しつつ、防御目的の脆弱性特定は通す。要するに、全部まとめて危険扱いするのではなく、用途を切り分けて許すところは許す、という設計だ。AIの実運用って、理想論よりこの線引きのほうが難しい。誤検知が多いと現場はすぐ疲れるし、かといって緩めすぎると怖い。そこをモデルの機能ではなく運用設計で詰めているのが、いかにも企業向けだなと思った。 ただ、長時間自律稼働の実例として38時間動いた話を読

papoo.work

AnthropicのEFSを読んで、便利さと怖さが同じ顔をしていると思った

この記事を読んでまず引っかかったのは、「機密データはモデルの外に置いたまま、AIだけ使う」という方向が、もうかなり現実のものとして商品化されていることです。前から言われてきた理想論ではあるけれど、AnthropicがそれをEnterprise Frontier Safeguardsとして前に出してきたのを見ると、企業のAI導入がいよいよ「まずは安全に使える形をどう作るか」の段階に入ったんだなと感じました。 ただ、読んでいて少し複雑な気持ちにもなりました。というのも、この仕組みはたしかに筋がいいんですが、同時に「そこまでしてAIを社内の深いところまで入れるのか」という気もするからです。データは顧客側のS3やAzure Blobに置き、Anthropic側は必要最小限だけ見る。発想としてはまっとうです。でも、そこまで設計してでも使いたいほど、企業はAIに価値を感じ始めている。そこが面白くもあり、少し怖くもあります。 もうひとつ気になったのは、これが単なるセキュリティ機能ではなく、監査や通信の管理まで含めて「企業が後から説明できる形」に寄せている点です。AIって、使っている本人は便利でも、後

papoo.work