#機密情報

読んでいてまず引っかかったのは、これは単なる「モデルの性能競争」の話ではなく、他社のAIをそのまま教材にしてしまう産業スパイ寄りの話になっていることだった。知識蒸留（distillation）自体は、上位モデルの出力を使って小さいモデルを育てる普通の手法だ。でもこの記事で描かれているのは、その境界をかなりあからさまに踏み越えたやり方で、Proxy や偽アカウント、盗んだ API key、さらにはユーザーとの会話ログまで使っている。ここまで来ると、技術の話というより、データの採集と回収の話に見える。 特に気持ち悪いのは、単に Claude の応答を真似しただけでなく、ユーザーとのやり取りの中にある機密っぽい情報まで混じっていた点だと思う。企業名や個人の会話が、意図しない形で学習用の材料にされる。モデル改善の名目でそんなことが起きていたなら、利用者の側はかなり不安になるはずだ。しかも、その会話がどこで保存され、誰に売られ、どのタイミングで再利用されたのか、外からは追いにくい。AI の性能向上とデータ収集の線引きが、かなり曖昧なまま回っている感じがある。 一方で、Anthro

この記事を読んでまず思ったのは、ようやく enterprise 向けの AI が「使うか使わないか」ではなく、「何を入れてよくて、何を入れてはいけないか」を本気で扱い始めた、ということです。ここがずっと曖昧だったので、むしろ今までよく事故が起きなかったな、という気持ちもあります。 Claude の前に DLP server（機密情報を検査する仕組み）を通すという発想は、地味だけれどかなり筋がいいと思いました。AI の安全性って、モデルの中身ばかり議論されがちですが、企業にとっては入力のほうがよほど現実的な問題です。社員がうっかり顧客情報や社内資料を貼り付ける。これをモデル側の善意に期待しても、そりゃ無理がある。送信前に止められるなら、そのほうがずっと管理しやすい。 一方で、少し引っかかるのは、これが「AI を安全にする」話というより、「企業の境界線を AI にも引き直す」話だという点です。つまり便利さの裏で、Claude はますます社内ネットワークの延長になる。たしかに安心ではあるけれど、同時に「AI は外部サービスだけど、実質は社内システム」という扱いが強くなる。そうなると、運用でき

GitHubのopenai/codexリポジトリに、ちょっと地味だけどかなり重要な要望が出ています。内容はシンプルで、AIエージェントに読ませたくないファイルを明示的に除外したい、というものです。 これ、派手さはないんですが実際にはかなり大事です。AIにコードを書かせる時代になっても、「これは見せていい」「これは絶対にダメ」の線引きは、人間がしっかり持っていないと危ない。そこをちゃんと仕組みにしよう、という提案です。 このIssueで求められているのは、エージェントが読み込んだり、モデルに送ったりしてはいけないファイルやパスを明示できる機能です。 しかも単なる一時的な指定ではなく、次の2段階を想定しています。 リポジトリごとの設定 ユーザー全体のグローバル設定 たとえば、プロジェクト内に `.codexignore` のようなファイルを置いて「このリポジトリではこのファイル群は触るな」と定義する。一方で、ユーザー側にも「どのプロジェクトでも `.env` や秘密鍵っぽいものは見せない」という共通ルールを持てるようにしたい、という考えです。 ここで面白いのは、**“プロジ