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時間からでも歓迎で、いろんな案件に携われたらうれしいです。こんな相談、歓迎です。