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):
- Why Claude switched models in your conversation with Fable 5(公式ヘルプ・キャプチャのリンク先)
- Issue #74783: 図の変更の要約 + git 操作で誤発火(私の事例に最も近い)
- Issue #67246: 無害な内容で発火し /model でも上書きできない
- Issue #73784: 正当な不正対策(T&S)セッションで繰り返し発火
- Issue #74734: 通常のデプロイ作業で繰り返し Opus 4.8 に降格
日本語の解説・事例(note / Qiita / Zenn / 検証記事):
- Zenn: Claude Fable 5 を解説。性能・料金・セーフガードの仕組みまとめ
- Qiita: Claude Fable 5とは。会話中にモデルが切り替わる新しい安全設計
- note: Claude Fable 5からOpus 4.8に自動で切り替わった事例集
- DevelopersIO: Fable 5 が会話の途中で Opus 4.8 へ切り替わる挙動を再現してみる
※ ヘッダー画像とインフォグラフィックは AI(画像生成)で作成しています。
書いた人: ishizakahiroshi
群馬の北部で、保護猫2匹と暮らす、在宅エンジニア(何でも屋)
https://ishizakahiroshi.github.io/
https://github.com/ishizakahiroshi
X(業務委託・各種相談はこちら):
https://x.com/ishizakahiroshi
バックエンド・インフラ・AI連携まわりで、業務委託のご相談を受け付けています。フルリモートです。スポットや週2〜3時間からでも歓迎で、いろんな案件に携われたらうれしいです。こんな相談、歓迎です。




