Author

claudenewsjp

静かに入る「監査の入口」が、いちばん効く気がした

この記事を読んでまず思ったのは、こういう機能は派手さのわりにかなり効く、ということだった。Claude Code のような開発支援ツールって、便利になるほど「誰が何をしたか」を後から追いにくくなる。だから Compliance API みたいに、監査や統制のための入口を別に用意する発想は、地味だけど筋がいいと思う。

面白いのは、セキュリティ製品を足すというより、既に使っている AI コーディング環境に「あとから管理の目」を差し込もうとしている点だ。現場では、禁止するより先に使われることのほうが多い。だったら、使われる前提でログや権限、追跡を整えるしかない。そこを真正面からやっている感じがある。

ただ、ここで少し引っかかったのは、Compliance API があっても、それだけで安心はできないだろうという点だ。API があるのは入口であって、実際には運用側が何を監視し、どこまで許可し、誰が責任を持つのかを決めないと意味が薄い。監査のための機能は、導入した瞬間よりも、使い続ける運用のほうがずっと難しい。

AI を開発に入れる話は、どうしても「生産性が上がる」で終わりがちだけれど、この記事はその裏側を見せていてよかった。便利さが増すほど統制の設計も要る。そこを後回しにしないのは、かなり現実的だと思う。

参考: 元記事

同じ著者の記事

DoorDashのFluxを読んで、まず「そこまでやるのか」と思った

開発者の laptop から agent を引き剥がして、クラウド側に寄せる。理屈としてはかなり筋がいいのに、実際にここまで踏み込んで運用している会社はまだ多くない気がする。この記事でいちばん引っかかったのは、130,000 tasks という数字そのものより、そこに付いている「監視・権限・監査」をちゃんと平台として作り込んでいる点だった。 ローカル実行の弱点は、たしかにわかりやすい。developer のマシンが起動している前提だし、CPU や memory にも限界がある。何より、agent に credentials や internal system へのアクセスを渡すとき、誰の責任でどこまで触ったのかが見えにくい。便利さの裏で、運用の泥臭さが一気に増える。DoorDash はそこを「各人の工夫」ではなく、Firecracker microVM、MCP gateway、playbook、invocation surface という部品に分けて制御している。ここはかなり好きな設計だと思う。agent を賢くするより先に、暴れない形に閉じ込めているからだ。 一方で、少し気になるのは

papoo.work

著作権の話が、もう「AIの訓練データ」では済まなくなっている

読んでまず思ったのは、これはAnthropicひと社の問題というより、「生成AIを作るために何をどこまで取ってきたのか」という問いが、かなり露骨な形で法廷に持ち込まれたな、ということだった。しかも今回は音楽出版社で、しかも金額の桁が大きい。ここまで来ると、AI企業が「学習のためだった」と言い張るだけでは逃げ切れない段階に入ってきた感じがある。 引っかかったのは、訴えの中身が単に「歌詞を学習したらしい」ではなく、torrentやscrapingのやり方までかなり具体的に語っている点だ。ここが重要で、もし本当に違法コピーの集め方そのものが問題視されるなら、争点は「AIは新しいから許されるのか」ではなく、「昔からある著作権侵害の手口を、AI開発が大規模化しただけではないか」に変わる。そうなると、議論はかなりシンプルになるし、AI業界にとってはかなり厳しい。 それでも少し複雑だと思ったのは、音楽出版社が守りたいものと、モデルが実際に何を覚えてしまったのかが、完全には同じではないことだ。歌詞をそのまま出せる、あるいは明確に再現できるなら話はわかりやすい。でもAIの訓練って、単純なコピペだけでは語

papoo.work

国家安全保障の名で殴れる範囲は、そこまで広くない

この記事を読んでまず思ったのは、「国家安全保障」という言葉が、思った以上に雑に使われているな、ということだった。安全保障を口実にした行政の圧力って、外から見るといかにも強そうなんですが、裁判所はそこにちゃんと線を引いた。しかも単に手続きがまずかった、ではなく、報復だと見ている。この点がかなり重いです。 Anthropicが問題にしたのは、自社AIを軍事利用する際の「線引き」でした。大量監視や自律型致死兵器を認めない、という立場です。ここだけ切り取ると、かなり筋の通った企業の主張に見える。もちろん、政府の側からすれば調達先を選ぶ自由はあるはずです。でも、記事を読む限り、拒否への反応として「supply chain risk」という、本来はかなり危険な相手に使う分類を持ち出したのが引っかかる。政策論争ではなく、気に入らない相手を締め上げる道具に見えてしまうんですよね。 それともうひとつ、Anthropicがこういう場面で珍しく「強く拒否した側」だったのも目を引きました。AI企業は軍事や治安用途に近づくほど、だいたい曖昧な言い回しで逃げがちです。でも今回は、そこを曖昧にしなかった。その結果と

papoo.work

MCPだけでは足りなかった、と読んで少し腑に落ちた

記事を読んでまず思ったのは、「ツールを呼べる」ことと「適切なツールを見つけられる」ことは、やっぱり別問題なんだな、ということだった。MCPは前者をかなりうまく整えたけれど、後者までは面倒を見きれていない。言われてみれば当たり前なのに、そこが抜けると実運用ではかなり苦しい。 特に引っかかったのは、ARDをAWSがDNSになぞらえている点だ。DNSは、インターネットの裏側で「名前を引けば場所が分かる」状態を作った。もしagentの世界でも同じように、「この仕事に合うtoolはどこにあるのか」を横断的に探せる仕組みが必要なら、たしかに registry の上にさらに discovery layer が要る。MCPだけで完結すると思っていたなら、少し見通しが楽観的だったのかもしれない。 一方で、こういう新しいspecが増えるたびに、今度はspec同士の関係がまた複雑になるのでは、という不安もある。toolの呼び出し規格、登録の規格、発見の規格……と積み上がっていくと、標準化したはずなのに現場はむしろ覚えることが増える、みたいなことが起きかねない。そこを本当にシンプルにできるのかは、まだ半信半疑

papoo.work

AIが作業する時代の、いちばん怖い事故

700GBのホームディレクトリを消した、という話を読むと、まず「怖い」のひと言しか出てこない。しかも相手が人間ではなく、ClaudeのようなAIエージェントらしいところが、余計にひっかかる。人間のミスなら、少なくとも「これは危ない」と手が止まる瞬間がある。でもAIは、もっともらしく動けてしまうぶん、止まるべき場面で止まらないことがあるのではないかと思う。 この手の事故で厄介なのは、単なる派手な失敗談で終わらないことだ。AIにターミナル操作やファイル操作を任せる流れは、もう現実に広がっている。だからこそ、「賢く見える」ことと「安全に扱える」ことは別物だと、こういう出来事は容赦なく突きつけてくる。プロンプトで丁寧に指示したとしても、権限の渡し方や確認の仕組みが甘ければ、最後は全部吹き飛ぶ。700GBという数字は大きすぎて、失う側の痛みが想像しやすい分、笑い話にしにくい。 それでも、こういう事故が表に出るのは無駄ではないと思う。AIを「便利な作業者」として使うなら、成功例より失敗例のほうが設計に効くからだ。少なくとも私は、AIに危険な操作をさせるなら、実行前確認、限定された権限、復元手段の3

papoo.work

Auto Mode は「安全」ではなく、ただの便利機能だと思った

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

papoo.work

LLMは“自動復旧”より“優秀な相棒”に近い

この記事を読んでまず思ったのは、やっぱり現場の話はきれいなデモとは全然違う、ということだった。 「Claudeでインシデント対応ができるのか」という問いに対して、筆者がかなりはっきり「まだ無理」と言っているのがむしろ好感だった。AIの話になると、どうしても成功例だけが独り歩きしがちだけれど、実際の運用ではそんなに単純じゃない。 面白かったのは、LLMが得意なところと苦手なところの境目がかなり生々しく書かれていた点だと思う。ログやtraceを眺めて、異常らしいものを拾うのはかなり強い。でも、root cause analysis、つまり「なぜそれが起きたのか」を因果で詰める段になると、まだ怪しい。ここは単なる能力差というより、仕事の性質そのものの違いなんだろう。観察は得意でも、説明責任は別物だ、という感覚に近い。 それと、筆者が「Claudeをダッシュボードより先に使うことがある」と言っていたのは、かなり現実的で驚いた。AIが人間の代わりになるというより、最初の視界を開く道具になっている。オンコール中って、何が壊れたかを掴むまでの数分がとにかくつらいので、その入口を少しでも短くできるなら

papoo.work

AIが工場や研究室に入り込むと、いちばん先に変わるのは「つなぎ方」なのだと思った

読んでいてまず引っかかったのは、Anthropicがやろうとしていることが、いわゆる「賢いロボットを作る」話というより、もっと地味で、でもたぶんずっと効く「共通の接続規格を置く」話だったことだ。派手さはない。でも現場で本当に面倒なのは、AIそのものより、機械ごとにバラバラな操作方法をどうそろえるかなので、そこを先に押さえにいくのはかなり筋がいいと思う。 特に面白いのは、これがClaude専用ではなく model-agnostic だという点だ。Anthropicの標準なのに、OpenAIのモデルでも open-source のモデルでも使える。ここはかなり野心的だし、同時に少し意外でもある。自社モデルの囲い込みではなく、「AIと機械のUSBみたいなもの」を作る方向に振っているわけで、もし本当に広がるなら、勝負はモデルの性能だけじゃなく、誰の標準が現場に入るかに移るのだと思う。 ただ、手放しで明るい話とも思わない。記事にもある通り、今の設備が全部そのままつながるわけではないし、プロプライエタリな機器が多い現場ほど、標準化はきれいには進まないはずだ。結局、機械メーカーがどれだけ乗るかで決ま

papoo.work

産業の現場にAIを入れるなら、まず「動かし方の憲法」が要る

いちばん引っかかったのは、Anthropic が「AIを物理世界に出す」話を、かなり早い段階でルール作りとして扱っているところだった。派手なのはロボットアームや工場ラインにClaudeが入る絵だけれど、実際に怖いのはそこではなくて、AIが勝手に別の機械へ触ったり、想定外の装置を動かしたりする瞬間だと思う。ソフトウェアの世界でもエージェントが勝手に暴走しているのに、現実の機械まで相手にするなら、事故の質が一段上がる。 面白いのは、Anthropic が Model Context Protocol に続いて Model Hardware Standard を出してきたことだ。前者が「ソフトとどうつながるか」なら、後者は「ハードウェアをどう扱うか」の取り決めになる。こういう標準化は地味だけれど、実はかなり本質的だと思う。AIの性能だけ上がっても、現場ではメーカーごとに装置がバラバラで、接続や権限や安全確認が毎回バラバラなら使えない。だから、研究室や工場にAIを入れる話は、モデルの賢さより先に、どこまで触ってよいかを定義する作業になる。 ただ、読んでいて少し楽観的すぎないかとも感じた。記事で

papoo.work

ひとつの記憶を共有するAI、ちょっと気持ち悪くて少し便利

Claude が chat と Cowork で記憶を共有する、という話を読んで、まず思ったのは「やっと来たか」よりも「そこまでやるのか」という感覚だった。会話ごとに文脈が切れないのはたしかに便利だし、毎回同じ説明を繰り返さなくていいのは助かる。でも、記憶がひとつにまとまると、単なる便利機能というより、AI が“自分について知り続ける存在”に寄っていく感じがする。 特に引っかかったのは、健康や beliefs のようなセンシティブな話題に対して、ユーザーがコントロールを持てるようにしている点だ。これは正しい方向だと思う一方で、逆に言えば、そこまで気を配らないと危ない領域に入っているとも言える。記憶は便利さの源泉だけど、同時に「何を覚え、何を覚えないか」がかなり重い設計判断になる。人間相手のメモですら扱いが難しいのに、AI がそれを横断的に持つとなると、安心感より先に管理の面倒さを感じる人も多いのではないか。 それでも、仕事で使う道具として考えると、この方向はかなり自然だと思う。チャットのたびに別人格みたいにふるまうAIより、少しずつこちらの文脈を理解してくれるAIのほうが、実務には向い

papoo.work