0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

作業そのものは無害なのに、AIの安全装置が「振り返り」で誤発火した話

0
Posted at

AI コーディングエージェントで淡々と作業していたら、セッションの終わりに「今日の学びをまとめて」と頼んだ瞬間、モデルの安全装置が発火して別のモデルに切り替わりました。

やっていたのは、自分の検証環境に対する、ごく正当なテストです。何も危ないことはしていない。なのに、一番無害なはずの「振り返り」で引っかかった。この順序が面白かったので、なぜそうなったのかを考えた記録です。生成 AI の安全装置、デュアルユース検知、AI エージェントあたりの話をします。

先に断っておくと、これは特定のモデルを責める記事ではありません。むしろ「広めに網を張っている今の安全装置は、こういう誤検知の出方をするのか」という観察です。旬の Fable 5 で起きた実例ですが、仕組みとしてはどのモデルにも起こりうる話だと思っています。

記事の要約

起きたのは「振り返って」と打った瞬間だった

その日のセッションは長めでした。あるシステムの認証まわりの結合テストを、自分の検証環境に対して延々とやっていました。

作業自体は地味です。設定を読んで、テスト用のトークンを用意して、認証が要る画面を叩いて、DB を覗いて結果を確認する。エラーが出たら切り分けて、また叩く。半日くらい、その繰り返しでした。

区切りがついたので、セッションを振り返るスキルを起動しました。これは自作のツールで、やっていることはシンプルです。そのセッションのやり取りを最初から読み直して、「今回の成果」「学んだこと」「改善できたこと」「次にやること」の 4 項目に要約する。結果はチャットに出しつつ、後で見返せるように md ファイルにも書き出す。揮発するチャットを、再利用できる形に落とすための道具です。

肝は「セッション全体を読み直す」ところにあります。この性質が、あとで効いてきます。

スキルが読み込まれて、日付を取るコマンドが走って。その次の瞬間です。安全装置が発火して、上位モデルへ勝手にフォールバックしました。

安全装置の発火通知

上のキャプチャが実際に出た通知です。要約すると「このメッセージは安全装置に引っかかった。安全装置は今わざと広めにしてあり、安全で日常的なコーディング・セキュリティ・生物学の作業まで拾うことがある。上位の能力を早く届けるための措置で、改善中。別モデルに切り替えた」という内容でした。提供元がフォールスポジティブの可能性を自分から明記しているのが、むしろ誠実だなと思いました。

作業は止まらず続いたんですが、頭の中は「え、なんで今?」でいっぱいでした。

危ないことをした覚えは本当にないんです。しかも引っかかったのは、作業の本体ではなく、それを要約しようとした「振り返り」のターン。一番あたりさわりのない工程です。

個々の作業では、一度も引っかからなかった

ここが最初の違和感でした。

半日ぶんの作業では、一度も安全装置は反応していません。認証テストの一つひとつ、設定を読むのも、トークンを用意するのも、画面を叩くのも、全部すんなり通っていた。

なのに、それらを「まとめて」と頼んだ最後の 1 回だけが引っかかった。

普通に考えると逆な気がしませんか。危険な操作があるなら、その操作をした瞬間に止まるのが自然です。要約は、もう起きたことをただ言葉にするだけ。新しく何かを実行するわけでもない。

「振り返りスキルそのものが危険物と判定されたのか?」とも一瞬思いました。でもそれは違う。同じスキルを、当たり障りのないセッションで起動したことは何度もあって、そのときは何も起きていません。スキルは無実です。

じゃあ何が変わったのか。変わったのは、スキルではなく「スキルが読み込んだ中身」でした。

安全装置は、文脈の正しさより「信号のパターン」を見ている

ここからは仕組みの話です。少し噛み砕きます。

生成 AI の安全装置は、ざっくり言うと「この文脈、危ない方向の匂いがしないか」を見ています。大事なのは、それが「あなたの意図が正しいか」を理解して判断しているわけではない、という点です。見ているのは意図ではなく、パターンです。

たとえば「秘密の鍵を使って認証トークンを作る」「認証情報が入ったファイルを読む」「"認証を回避する" という言葉」。これらは、正規のテストでも、悪意ある攻撃でも、まったく同じ文字列として現れます。文脈を人間のように理解しない限り、この 2 つは見分けがつきません。

だから安全装置は、こういう「どっちにも使える(デュアルユースな)」信号が一定量集まると、中身の正当性に関わらず反応します。今の設定は、取りこぼすより拾いすぎる方に倒してあるようです。実際、提供元の注意書きにも「今の安全装置は意図的に広めで、安全で日常的なコーディングやセキュリティ、生物学の作業まで拾うことがある」と明記されていました。上位の能力を早く出すために、広めの網を一時的にかけている、という説明です。

つまり、これは仕様の範囲内の誤検知(フォールスポジティブ)だったわけです。

なぜ「振り返り」だけが引っかかったのか

ここまで来ると、最初の違和感が解けます。

半日の作業では、デュアルユースな信号は会話のあちこちに散らばっていました。トークンの話はここ、設定ファイルの話はあそこ、認証回避という語はそっち。一つひとつのターンでは、危険信号の密度が薄い。網に引っかかるほど固まっていなかった。

ところが「振り返り」スキルは、仕様として「セッション全体を読み直して要約する」ものです。つまり、それまで散らばっていた信号を、一つのターンに全部呼び戻してくる。

上の図がその構図です。左のように時系列でバラけていた危険信号が、要約という工程を通ることで、右のように一箇所へ濃縮される。しかも、要約として書き出そうとしている文章自体にも「トークンに署名」「認証」「回避」といった語が凝縮される。薄かった濃度が、その瞬間だけ跳ね上がる。

要約スキルは、内容を圧縮する道具です。情報を圧縮するということは、信号も圧縮するということでした。無害な便利ツールが、たまたま「危険信号の濃縮装置」として働いてしまった。皮肉な話です。

正直、この見立てが 100% 正しいとは言い切れません。安全装置の内部がどう判定したかを、こちらから直接覗くことはできないからです。ただ「振り返りスキルが単体で危険」と考えるより、「散らばった信号が要約で一点に集まった」と考える方が、起きた順序をきれいに説明できます。

もう一つの容疑者。「要約」そのものが監視対象だった

記事を書きながら公式ドキュメントを読み直していて、もう一つ心当たりが出てきました。

公式が挙げている監視対象は 4 領域あります。攻撃的なサイバーセキュリティ、生物・化学、フロンティアな LLM 開発、そして「蒸留(distillation)攻撃、すなわちモデルの要約された思考を引き出す試み」です。

4 つ目に「要約」という語が入っているのが引っかかりました。私が起動したのは、まさに「セッションを要約するスキル」です。もちろん、蒸留攻撃が指すのは「モデルの内部思考を抜き出す」行為であって、私がやったのは「自分の作業ログを要約する」ことです。指しているものは違います。

でも安全装置は意図ではなく信号を見る、というさっきの話に戻ると、「要約・抽出しようとしている」という表層のふるまい自体が、監視対象の 4 つ目とうっすら重なる可能性はあります。つまり今回の発火は、①セキュリティ的な信号の濃縮、②「要約・抽出」という動作が蒸留カテゴリと表層一致、この二つが同じターンで重なった合わせ技だったのかもしれません。

これも推測です。ただ「なぜ要約のターンで」という問いに対して、濃縮と蒸留カテゴリの二つが揃うのが要約ターンだった、と考えると腑に落ちます。

調べたら、あちこちで同じことが起きていた

自分だけの珍事かと思って検索したら、まったくそんなことはありませんでした。むしろ定番の詰まりどころでした。

一次ソースは公式のヘルプ記事で、キャプチャのリンク先そのものです。「安全装置は今わざと広めで、正当なコーディング・セキュリティ・生物学の作業まで誤って拾いうる」と提供元自身が明記しています。切替を止めたい場合の設定場所(Settings > Capabilities、Claude Code なら Config > MODEL & OUTPUT の「Switch models when a message is flagged」)も、ここに書いてありました。

開発リポジトリの Issue には、私とほぼ同じ「無害な作業での誤発火」が並んでいます。特に近かったのが、図(アーキテクチャ図)の変更を要約して git のコミット手順を出しただけで発火した、という報告でした。ここでも「要約 + 積み上がった専門語彙」が引き金になっていて、濃縮仮説の裏づけになっています。ほかにも「正当な不正対策(T&S)セッションで繰り返し止まる」「通常のデプロイ作業で勝手に降格する」といった Issue が立っていました。

日本語圏でも note・Qiita・Zenn に解説や事例が出ています。仕組みのまとめ、会話中に切り替わる設計の解説、実際に切り替わった事例集など、切り口はさまざまですが、観測している現象は同じでした。

参考にした主なリンクは記事末尾にまとめて置いておきます。同じところで詰まった人の地図になれば。

学んだこと

同じことをまた踏むかもしれないので、一般化して残しておきます。

  • 安全装置は「意図」ではなく「信号のパターン」を見る。正当な作業でも、危険操作と同じ語彙・同じ形を使えば同じように反応しうる
  • 危険信号には「密度」がある。散らばっていれば通るのに、要約・集約の工程で一点に集めると閾値を超えることがある
  • だから引っかかるのは、危険な操作の瞬間とは限らない。それを「まとめる」無害な工程の方が危ないことすらある
  • 今の広めの網では、これは誤検知として起こりうる前提の挙動。切り替わっても作業は止まらないので、慌てて回避策に走る前に、まず何が濃縮されたのかを見る方がいい

上の図は、実務でできる小さな対処です。認証情報を読む作業や鍵を扱う作業を、延々と同じセッションに溜め込まないで、区切りのいいところでセッションを切る。そうすると信号が一箇所に濃縮されにくくなります。対症療法ではありますが、誤検知の頻度は下げられそうです。根本的には、安全装置側のチューニングが進むのを待つ話です。

誤検知そのものを、責める気にはならなかった

一つだけ、書いておきたいことがあります。

拾いすぎる網は、鬱陶しいです。正当な作業が止まると、単純にイラッとする。でも「取りこぼす」より「拾いすぎる」に倒してある、という方針自体は、たぶん今の段階では正しいんだろうと思っています。

新しくて強い能力を早めに世に出すなら、そのぶん安全側のマージンを厚く取る。厚すぎて誤検知が出るなら、使う側がフィードバックを返して、少しずつ削ってもらう。今回みたいな「正当な自環境テストが引っかかった」実例は、まさにその調整に使ってほしい種類の事例なので、フィードバックは送っておきました。

旬の新しいモデルを触るということは、こういうまだ荒い部分に付き合うということでもあります。それはそれで、面白い。荒さも含めて今しか見られない挙動だと思うと、誤発火の 1 回も記録する価値がありました。

次にまた引っかかったら、慌てずに「何が濃縮されたんだろう」と数えてみます。たぶんそれが、一番てっとり早い原因の見つけ方なので。

参考にしたリンク

一次ソース(公式・開発リポジトリの Issue):

日本語の解説・事例(note / Qiita / Zenn / 検証記事):


※ ヘッダー画像とインフォグラフィックは AI(画像生成)で作成しています。

書いた人: ishizakahiroshi
群馬の北部で、保護猫2匹と暮らす、在宅エンジニア(何でも屋)
https://ishizakahiroshi.github.io/
https://github.com/ishizakahiroshi
X(業務委託・各種相談はこちら):
https://x.com/ishizakahiroshi

バックエンド・インフラ・AI連携まわりで、業務委託のご相談を受け付けています。フルリモートです。スポットや週2〜3時間からでも歓迎で、いろんな案件に携われたらうれしいです。こんな相談、歓迎です。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?