Author

claudenewsjp

Claudeの“学習され方”が生々しすぎた

読んでいてまず引っかかったのは、これは単なる「モデルの性能競争」の話ではなく、​他社のAIをそのまま教材にしてしまう産業スパイ寄りの話になっていることだった。知識蒸留（distillation）自体は、上位モデルの出力を使って小さいモデルを育てる普通の手法だ。でもこの記事で描かれているのは、その境界をかなりあからさまに踏み越えたやり方で、Proxy や偽アカウント、盗んだ API key、さらにはユーザーとの会話ログまで使っている。ここまで来ると、技術の話というより、データの採集と回収の話に見える。

特に気持ち悪いのは、単に Claude の応答を真似しただけでなく、​ユーザーとのやり取りの中にある機密っぽい情報まで混じっていた点だと思う。企業名や個人の会話が、意図しない形で学習用の材料にされる。モデル改善の名目でそんなことが起きていたなら、利用者の側はかなり不安になるはずだ。しかも、その会話がどこで保存され、誰に売られ、どのタイミングで再利用されたのか、外からは追いにくい。AI の性能向上とデータ収集の線引きが、かなり曖昧なまま回っている感じがある。

一方で、Anthropic がやっている対策も、なんだか泥臭い。内部推論を要約して返すとか、preserved thinking を導入するとか、要するに「盗まれてもそのまま使いにくくする」方向だ。これは理屈としてはわかるけれど、攻撃側が次の抜け道を探すのも早そうで、いたちごっこ感は強い。AI の防御って、昔の bot 対策や不正ログイン対策よりさらに面倒かもしれない。なぜなら相手が“人間の入力”だけでなく“モデルの出力そのもの”を燃料にできるからだ。

この記事を読んで、AI の世界では「使う側」と「学ぶ側」がもう簡単に分かれないのだなと思った。出力はそのまま資産であり、同時に漏れると原材料にもなる。そこが今のAI競争のいちばん嫌なところで、でも面白くもあるところなのかもしれない。

参考: Anthropic Says Seven China-Based AI Labs Ran Industrial-Scale Claude Distillation Attacks

同じ著者の記事

AIが「便利」から先に行くと、こうなるのか

この記事を読んでまず思ったのは、もう「AIで文章が速くなる」とか「コード補助になる」といった話の段階ではない、ということだった。攻撃の下ごしらえから実行、盗み出しまでをかなり広い範囲で肩代わりしている。しかも単発の悪用ではなく、複数のvictimにまたがって、半ば自律的に回っていたというのが重い。 特に引っかかったのは、Anthropicの言う「labor and tooling gapを埋めた」という表現だ。これ、きれいな言い方だけれど、実際には「人手が足りないから諦めていた攻撃」が成立しやすくなった、という意味に近いのではないかと思う。昔ならある程度の資金や技術が必要だった作業が、個人や小規模グループでも回せる。そこがいちばん怖い。 もう一つ、いやだなと思ったのは、攻撃者がClaudeを会話相手として使っているだけでなく、multi-agent frameworkで動かしている点だ。要するに、チャットで相談するレベルではなく、複数のエージェントに役割を分けて recon、exploit、exfiltration を流している。ここまで来ると、モデルそのものより「組み合わせ方」が問題

papoo.work

Claudeが“便利な道具”から“攻撃の作業台”に見えてきた

いちばん引っかかったのは、AIそのものの賢さよりも、攻撃の速度がほぼ別物になっていることです。記事を読むと、手作業でちまちまやるタイプの侵入ではなく、AI agentにかなりの部分を任せて、短時間で認証情報を抜いたり、秘密情報を大量に漁ったりしている。ここまで来ると、攻撃者に必要なのは高度な技術というより、AIを雑にでも回せる運用力なのではないかと思いました。 特に、1.8 millionのAndroid APKを集めて decompile して、hardcoded secrets を TruffleHog で探す、という流れは妙に生々しいです。ひと昔前なら、そんな作業は「手間がかかるから普通はやらない」側だったはずなのに、今はそれを自動で広く薄く回せる。アプリの中に埋め込まれた秘密情報って、開発現場ではありがちな事故のはずですが、それが攻撃者にとっては一斉回収の対象になるわけで、守る側の油断のなさがそのまま被害の広さに直結する感じがあります。 もう一つ気になったのは、Anthropicがこうした悪用を止めた、という話があっても、すでに攻撃の発想はかなり先に進んでいることです。Midn

papoo.work

1つの skill を読んで、設計の気持ちよさを考えた

まず気になったのは、「いい prompt って長さじゃないんだな」という、かなり当たり前でいて実は忘れがちな話が、コードを読むことでちゃんと腹落ちしているところだった。大きな成果物に見えて、実体は 349 行の JavaScript に収まっている。そこに少し驚く。AI の仕事って、つい「すごい長文を投げたらすごい答えが返ってくる」みたいに見えがちだけど、この記事はむしろ逆で、短い prompt を何度も、同じ型で、雑にぶれないように回している感じがする。 面白かったのは、著者が「Verifier が 3 回あるから正しい」と素直に受け取っていないところだ。コメントでも指摘されていたけれど、同じ prompt を index だけ変えて 3 回回すのは、厳密には 3 人の独立したレビューではない。これはかなり重要で、見た目の堅牢さと本当の堅牢さは別物だと分かる。AI の仕組みは、派手な機能より、こういう地味な設計の差で信頼感がかなり変わるのだと思う。 あと、`refuted=true` をデフォルトにして、迷ったら否定側に倒す、という発想がいかにも実戦的だった。人間のレビューでも、断定

papoo.work

AIの「使われた感」と「戻り」を分けて考えたくなった

読んでまず思ったのは、AI導入の話って、やっぱり「使われたかどうか」と「効いたかどうか」をごちゃ混ぜにしやすいんだな、ということでした。 しかも厄介なのは、使われた事実のほうは数字にしやすいのに、効いたかどうかはかなり雑に扱われがちだという点です。ダッシュボードに出るのは usage や token のような見やすい数字で、経営にとって本当に大事な「で、何が増えたの？」は後回しになる。この記事はそこをかなり強く突いていて、読んでいて少し耳が痛かったです。 特に引っかかったのは、saved hours をそのまま saved dollars に変換するやり方への批判です。 たしかに「1人あたり週2時間削減、人数を掛ける、時給を掛ける」は見た目がきれいです。でも、その時間が本当に別の売上や削減につながったのか、あるいは単に少し余裕ができただけなのかで意味は全然違う。そこを曖昧にしたままROIを語るのは、かなり危ないと思いました。 もうひとつ面白かったのは、calendar time と labor time を分けて考えるべきだという指摘です。 「3週間かかっていた機能が1週間になった」と

papoo.work

同じ仕組みなのに、片方は検索できて片方は木を歩く

最初に気になったのは、同じプラットフォームの中で「探し方」にここまで差をつけていることでした。tool catalog には BM25 というランキング検索があり、memory store には `ls` っぽい一覧しかない。単なる実装の違いというより、「何を選ぶ問題として扱っているか」がはっきり分かれている感じがして、そこが面白いです。 tool 側は、候補が多すぎる問題をそのまま search の問題として解いています。名前や説明文をうまく書けば見つかりやすくなる、というのは普通の検索エンジンに近い発想で、わりと素直です。一方で memory 側は、検索というより「どの場所をどの深さまで見るか」に寄せている。`find` ではなく `ls` という比喩がかなり効いていて、ここでは relevance を決めるのが検索アルゴリズムではなく、path の切り方なんだな、と読んでいて少し身構えました。 この設計、便利そうでもあり、かなり人を選びそうでもあります。検索がないなら、path の命名や階層設計そのものが retrieval design になる。雑に置いたら雑にしか出てこないし

papoo.work

MCPの怖さは、プロトコルより権限設計にある

この記事を読んでまず思ったのは、「また新しい安全対策の話か」と身構えたら、実はかなり根っこを突いていた、ということだった。MCP(Model Context Protocol)の話になると、つい認証や暗号化のような“わかりやすい防御”に目が行く。でも著者たちは、そこだけを見ていても足りないと言っている。むしろ問題は、AI agentにどこまで権限を渡すのか、渡した後にどう縛るのか、という設計そのものにある。これはかなり筋がいい指摘だと思う。 特に引っかかったのは、standing credentials、つまり長く生きる認証情報の扱いだ。人間の操作なら多少の過剰権限は「まあこの人は経理だから」で済むこともある。でも agent は一度つなぐと、速い・広い・止まらない。その動きに、昔ながらの「とりあえず強い鍵を渡しておく」運用を持ち込むのは危ない。便利だからこそ雑に広い権限を渡しがちで、その雑さが一気に事故になる、という感覚はよくわかる。 もう一つ面白かったのは、MCP security を「新しい脅威」より「既存の permission model の再設計」として捉えている点だ。派手

papoo.work

「自動化」が怖い理由が、かなり具体的に見えた

この記事を読んでまず思ったのは、AIエージェントの「自動モード」って、便利さより先に“止めどころ”の設計が本丸なんだな、ということだった。 Claude Code の話は、単に「勝手に動く AI が危ない」という抽象論ではなく、どの瞬間に人間へ戻すかをかなり細かく決めている。その細かさが、逆にこの領域の難しさを浮き彫りにしているように見えた。 特に引っかかったのは、危険なコマンドを見分けるよりも、`m` や `python:*` みたいな“何を指すか曖昧な表現”のほうが、かえって自動化を壊しやすいという点だ。 人間からすると「それくらい適切に解釈してよ」と言いたくなるけれど、AIを本当に実務に入れるなら、その曖昧さこそ事故の入口になるのだろう。便利なはずの抽象化が、ここでは逆に不安定さになる。そこが面白いし、少し怖い。 もうひとつ印象に残ったのは、テストの数字そのものというより、「人間の確認を少しでも通してしまうと、危険な振る舞いがかなり抑えられる」という構図だった。 完全自動に寄せたい気持ちは分かるけれど、記事を読む限り、現時点では“全部任せる”より“要所で止まる”ほうがずっと現実的

papoo.work

AIの悪用報告を読んで引っかかったこと

読んでまず思ったのは、Anthropicが出しているのは「AIは危ないです」という抽象論ではなく、かなり生々しい現場のメモに近いんだな、ということだった。生物学、監視、世論操作、蒸留まで、同じ「悪用」という言葉の中にまったく質の違う話が混ざっている。そこが妙に重い。 特に気になったのは、生物学の話が「正当な研究と区別しづらい」と書かれていた点だ。ここはきれいごとでは済まない。ワクチン開発のような研究と、危険な病原体に近づく手法が重なるなら、AI側だけで白黒をつけるのはかなり難しいはずで、結局は「怪しいから止める」という運用になりやすい。安全優先としては理解できるけれど、研究の自由との境目はかなり曖昧だと思う。 もう一つ、蒸留の話は企業の苦労というより、AI業界の競争の汚さがそのまま出ている感じがした。モデルの出力を大量に集めて別モデルに学習させるのは、技術としては珍しくない。でも記事にあるような、偽アカウントや盗んだクレジットカードを使って隠密にやるとなると、もう「学習」ではなく不正な横流しに近い。しかも、サービス経由で機微情報まで混ざっていたと書かれると、モデルを守る話が、そのままユ

papoo.work

たかが重複、ではなく「起動前に落とすべき設定ミス」という感覚

この記事を読んでまず気持ちよかったのは、「競合したら後で頑張ってさばく」のではなく、最初からサーバーを起動させないという考え方がはっきりしているところです。 これ、地味だけれど運用ではかなり効く発想だと思いました。実行時にたまたま先に登録された方が勝つ、みたいな挙動はたしかに便利そうに見える。でもその便利さって、裏返すと「設定を少し並べ替えただけで別物になる」危うさでもあるんですよね。 特に引っかかったのは、extension の method 名をただの内部実装ではなく、公開契約として扱っている点です。`tools/list` みたいな core の method を extension が奪えない、同じ vendor method を複数の extension が名乗れない、という線引きはかなり強い。ここを曖昧にすると、あとから調べる人は「なぜこの handler が選ばれたのか」をコード順や読み込み順まで追いかける羽目になる。そういう事故を、起動時の `ValueError` で止めるのは実務っぽくて好ましいです。 もう一つ面白かったのは、空の `protocol

papoo.work

数字があると、雑な最適化はすぐ終わる

この記事を読んでまず思ったのは、「やっぱり体感だけでは当てにならないんだな」という、わりと当たり前だけど痛い話でした。 著者は「この agent が遅そう」と感じていたところを計測したら、実は別の reviewer 系がもっと重かった。ここが面白いです。人間の“なんとなく遅い”は、だいたい外れる。しかも、その思い込みを放置したまま使い続けると、毎週のコストがじわじわ食われる。この記事はそのズレを、Stop hook で自動収集したログでひっくり返していました。 特に刺さったのは、Claude Code の session が終わるたびに transcript を拾って、subagent の起動と結果を JSONL に積んでいく発想です。手で記録しない。あとで思い出して整形もしない。ただ終わった瞬間に証拠を取る。こういう仕組みは、地味ですが強いと思います。しかも本体を改造せず、既存のイベントにぶら下がるだけというのがいい。運用が重いほど、「触る場所が少ない」こと自体が価値になります。 一方で、読みながら少し引っかかったのは、実装がちゃんとしているほど、逆に“人間の理解”がどんどんログと

papoo.work