Claude Fable 5.1 が [cyber] 判定で Opus 4.8 に落とされたとき、Opus 5 のまま続きを走らせる

Posted at 2026-09-06

コードの監査を回している最中に、画面のモデル表示が勝手に変わりました。自分で選んだのは Fable 5.1 なのに、Opus 4.8 になっています。

止めて選び直したら、そのまま最後まで走りました。かかったのは 19.2662 ドルでした。

先に結論だけ書きます

Fable 5.1 で作業していて Details: [cyber] と出て Opus 4.8 に切り替えられたとき、Opus 5 のまま続けたいなら、やることは 3 手です。

実行中の処理を Esc で中断する
/model を実行して Opus 5 (1M context) を選ぶ
「処理続けてください」と入力して再開させる

これだけで、少なくとも今回のセッションでは Opus 5 のまま完走しました。再度 Opus 4.8 に引き戻されることはありませんでした。

ただし注意点が 2 つあります。

これはセーフガードを回避する手ではありません。 Opus 側にも別のリアルタイム判定があります。今回はそこに触れなかっただけです
Opus 5 の 1M context で xhigh effort を最後まで回すと、普通にお金が飛びます。 今回は 19 ドルでした

以下、画面と数字を並べていきます。

画面に出たのはこれです

黄色い枠でこう出ました。

Fable 5.1's safeguards flagged this message. Our intentionally broad safeguards allow us to deliver more capabilities faster, but can sometimes flag legitimate coding, cybersecurity, and biology tasks. Switched to Opus 4.8. Send feedback with /feedback or learn more: https://support.claude.com/en/articles/15363606

Details: [cyber]

Tip: You can configure model switch behavior in /config

そのときの実行状態はこうでした。

Working… (9m 12s · ↓ 24.7k tokens · almost done thinking with xhigh effort)

9 分 12 秒。24.7k トークン。effort は xhigh。

つまりエラーで止まったわけではありません。処理は続いています。ただしモデルだけが入れ替わっています。9 分ぶんの thinking をどのモデルが引き継いだのか、画面からは分かりません。

最初に口から出たのは「なんじゃこれ」でした。

そもそも何をやらせていたのか

引っかかった作業の中身を先に書いておきます。ここが分からないと「何をしたら発火するのか」が伝わらないので。

やっていたのは、レガシーな CodeIgniter 3 のアプリに対するコード監査です。EOL のフレームワークで動いているものを、本番へ出す前に一度ちゃんと見ておきたい、という文脈でした。

監査プロンプトは自作のものを使っています。ざっくり言うと、こういう手順を踏ませる契約書です。

inventory: 構成・設定・CI/CD・DB の有無・使える手段（capability）を先に確定させる
exploration: 認証・認可・入出力・データ保護・設定・例外・資源・依存といった観点ごとに、疑わしい箇所（lead）を集める
adversarial verification: 集めた候補を自分で反証しに行き、確定 / 却下 / 判断待ちへ分類する
report: 事実と証拠だけを書いたレポートを作る
修正手順の起票: 確定した指摘を、実行可能なタスクへ展開する

ポイントは 3 の「反証しに行く」ところです。AI に「怪しいところを挙げて」と言うと、いくらでも挙がります。挙がったものをそのまま信じると、実在しない指摘まで台帳に載ります。なので、挙げたあとに自分で潰しに行かせます。

そして今回のスコープは「調査まで」でした。ソースコードは 1 行も変更していません。 ここを最初に縛るようになったのは、前に事故ったからです。

「監査して」と頼んだら、コードが書き換わっていた
https://note.com/ishizakahiroshi/n/n24245f2e9e31

この作業を回している間、画面には vulnerability や auth や bypass や exploit といった語が延々と流れます。しかも途中で GitHub の Advisory Database を読みに行きます。

そりゃ引っかかるよな、とは思いました。思いましたが、納得はしませんでした。

この切替は仕様でした。しかも落ちる先がカテゴリで違う

画面のリンク先を読みに行きました。

Anthropic のヘルプセンターに、この挙動の説明があります。
https://support.claude.com/en/articles/15363606

読んで一番驚いたのがここです。フォールバック先のモデルは、フラグのカテゴリによって違います。

When requests are blocked, they may fallback to a non-Mythos model, currently Opus 5 for biology, chemistry, and life sciences requests

Opus 4.8 for offensive cybersecurity technique requests

整理するとこうです。

biology / chemistry / life sciences で止まったとき → Opus 5
offensive cybersecurity で止まったとき → Opus 4.8

同じ「セーフガードに引っかかった」でも、生物系なら Opus 5 に、サイバー系なら Opus 4.8 に行きます。今回は [cyber] だったので、下の段に振り分けられたわけです。

このとき思ったのは、率直に言って「なんで 4.8 なんだ」でした。Opus 5 があるのに、と。

ただ、設計の意図はたぶん読めます。cyber 判定で止めた依頼を、より能力の高いモデルに渡したら、結局その能力が使えてしまう。だから最初から一段落としたモデルへ送る。そういうことだと思います。ここは公式に理由まで書かれてはいないので、あくまで推測です。

「切り替わった」のではなく「同じ会話で再実行された」

もうひとつ、読んで初めて分かったことがあります。切替の実体はこう書かれています。

Claude re-runs your blocked Claude Fable 5 or Fable 5.1 request on an Opus model in the same conversation. You'll see a notice explaining that the model switched, and the response will be labeled with the model that answered.

re-runs です。つまり、途中まで進んだ思考を Opus が引き継ぐのではなく、ブロックされた依頼を同じ会話の中で Opus に投げ直している。そして応答には、答えたモデルの名前がラベルとして付く、と書かれています。

これが分かると、画面の見え方が変わります。あのとき表示されていた Working… (9m 12s · ↓ 24.7k tokens) の 9 分は、Fable が使った時間なのか、投げ直された Opus 4.8 の時間なのか。少なくとも「Fable の 9 分を Opus が引き継いだ」ではないことは確かです。

そして、この仕様のおかげで自分の手が効いた、とも言えます。会話そのものは切れていないので、こちらも同じ会話に対して /model で別のモデルを指定して、続きを投げ直せる。やっていることの構造は、実は自動切替と同じでした。行き先を決めているのが機械か自分か、という違いしかありません。

判定対象は「入力した文章」だけではない

同じページで、もうひとつ効く記述がありました。

checks review everything the model reads, not just your latest message

including memory, content from connectors, web search results, and files, so a block can be triggered by content you didn't type

日本語にすると、判定はモデルが読むもの全部を見る、ということです。直前に入力したメッセージだけではありません。メモリ、コネクタから来た内容、Web 検索の結果、読み込んだファイル。全部が対象です。

これは監査タスクだと相当効きます。こちらが書いたのは「監査して」の一言でも、モデルが読みに行ったソースコードや Advisory ページの中に脆弱性まわりの記述が並んでいれば、そこで発火しうるということになります。

自分がその文章を書いていなくても止まる。 ここは覚えておいたほうがいいと思いました。

逆に言うと、「短い依頼文を工夫すれば止まらない」という話ではありません。読ませているものが理由なら、依頼文をどう書き換えても同じです。

誤検知であることは公式も認めている

同じページに、こういう記述もあります。

if your legitimate work in these areas keeps getting blocked, let us know. Use "Send feedback" to report it. Reports of incorrectly blocked requests help us narrow and improve these safeguards.

正当な作業が繰り返し止められるなら報告してくれ、と書いてあります。さらに、より精密にして誤検知を減らす作業を進めている、とも書かれています。

つまり「広めに取っているのは意図的で、誤検知は想定済み」という立て付けです。画面に出ていた can sometimes flag legitimate coding, cybersecurity, and biology tasks の一文がそのまま設計思想でした。

そこは分かりました。分かったうえで、行き先のほうが問題でした。

なぜ Opus 4.8 に落ちるのが嫌だったのか

ここは完全に個人的な経緯です。

Opus 4.8 では、作話（confabulation）で何度か痛い目にあっています。記事にもしてきました。

3度目の作話で、Claude Opus 4.8 をやめた話
https://note.com/ishizakahiroshi/n/n020cff07baf0
続々々・Claude Opus 4.8 で /clear した直後にも踏んだ。同日 3 発目、context 空でも作話は消えなかった
https://note.com/ishizakahiroshi/n/n5015e3856e93

とくに 2 本目がきつくて、/clear の直後、つまり context が空の状態でも作話が出ました。正常なツール出力を「文字化けしている」と誤認したり、頼んでいない 38 ファイルを実際に移動したり、存在しないファイル名を生成して「実体が見つかった」と断言したりしています。長い文脈のせいにできない状況でこれが出たので、そこで使うのをやめました。

念のため書いておくと、Opus 5 なら作話がゼロというわけでもありません。こちらも 1 件観測して記事にしています。

続々々々・Opus 5 でも作話は出た。ただし今度は、正しい報告の中に 1 個だけ混ざっていた
https://note.com/ishizakahiroshi/n/n5d895cc87e68

なので「Opus 5 は完璧だから使う」ではありません。手元の観測では、頻度と副作用の大きさが違う、という程度の話です。

そのうえで今回いちばん引っかかったのは、性能差そのものではありませんでした。

自分が明示的に使わないと決めたモデルへ、処理の途中で自動的に移されること。 これです。

安全機構が動くこと自体には文句はありません。行き先を選べないことのほうが気になりました。しかも今回は 9 分ぶんの thinking を積んだあとです。

そして相手はコード監査です。指摘が 1 件混ざり込むだけで、実在しない脆弱性を追いかける時間が生まれます。作話で困った経験があるモデルに、よりによってこのタスクを渡されるのは、いちばん避けたい組み合わせでした。

なので、単純な方法を試すことにしました。自分で選び直せばいいんじゃないか、と。

やったことは 3 手です

画面上部には切替の通知が残ったままです。

Fable 5.1's safeguards flagged this message...
Switched to Opus 4.8.
Details: `[cyber]`
Interrupted · What should Claude do instead?

ここから、

/model

を実行します。表示はこうなりました。

Set model to Opus 5 (1M context) (default) and saved as your default for new sessions

そのまま、

処理続けてください

と入力しました。

画面下部のモデル表示も Opus 5 (1M context) に変わっています。コストはこの時点で $4.8375、コンテキストは 235.3k でした。

そして、黙りました。

Channeling… (3m 16s · almost done thinking with xhigh effort)

3 分 16 秒。これは正直、ちょっと長く感じました。xhigh effort なら異常ではないんですが、直前に一度セーフガードを踏んでいるので、待っている側の気分としては落ち着きません。

このとき考えていた分岐は 3 つです。

そのまま Opus 5 で続く
もう一度 [cyber] が出て Opus 4.8 に引き戻される
中断前の状態を引き継げなくて、最初からやり直しになる

2 だったら「モデル選択より上位でセーフガードが強制している」ということになります。3 だったら 9 分ぶんが無駄になります。

なので、触らずに見ていました。

中断しても、それまでの作業は消えませんでした

3 の心配は杞憂でした。Esc で止めたのは「今まさに生成している応答」だけで、それまでのやり取りは会話としてそのまま残ります。

なので「処理続けてください」の一言で、どこまで進んでいたかを自分で読み直して再開できます。監査で言うと、C1 から C3 の途中までは終わっていて、その続きから動き出しました。

ここは Claude Code の作りに助けられました。中断が「セッションの破棄」ではなく「今のターンの停止」である、という前提があるので、モデルを差し替えて続きを頼む、という荒業が成立します。

逆に言うと、まだファイルへ書き出していない中間成果は、頭の中にあるぶんだけ失われます。今回はレポートを md へ落とし始める前だったので、読み直しのコストはそのまま金額に乗りました。あとで効いてきます。

Opus 5 のまま動き出しました

しばらくして動き出しました。

CodeIgniter の 2 件は 3.1.10 で修正済みと確認できました（いずれも < 3.1.10 が対象）。
残る advisory の対象パッケージと版を確定させます。

Fetch(https://github.com/advisories/GHSA-jwqp-wh5g-4gmm)
  Received 175.1KB (200 OK)
  Allowed by auto mode classifier

Fetch(https://github.com/advisories/GHSA-j9f9-8j39-4g97)
  Received 174.4KB (200 OK)
  Allowed by auto mode classifier

Running 1 shell command…

GitHub Advisory Database を読みに行って、200 OK が返っています。その下では shell command も走っていて、git の差分を確認しています。

（スクリーンショット中の黒い帯は、監査対象リポジトリの絶対パスを塗りつぶしたものです）

画面下部は $9.3436 Opus 5 (1M context) ↑262.3k。モデル表示は変わっていません。

ここで「動いてるな。Opus 4.8 は流石にきついからこのまま様子見る」と判断して、放置しました。

つまり、今回のセッションで確認できたのはここです。

Fable 5.1 で [cyber] 判定を踏んで Opus 4.8 へ自動切替されたセッションでも、中断して /model で Opus 5 を選び直し、続きを指示すれば、Opus 5 のまま処理を再開できました。再度 Opus 4.8 へ引き戻されることはありませんでした。

念のため強調しておくと、これは 1 回の観測です。毎回こうなるという保証はどこにもありません。

`Allowed by auto mode classifier` という行

上のログに 2 回出ている行です。これはセーフガードの話ではなく、Claude Code 側の auto mode の判定です。

auto mode を有効にしていると、ツール実行の許可を毎回人間に聞かずに、判定器が「これは通してよい」と判断したものを自動で通します。今回で言うと、GitHub の Advisory ページを取りに行く Fetch がそれに当たりました。

紛らわしいのは、画面に「classifier」という語が 2 種類出ることです。

[cyber] のほう: モデル側のセーフガード。引っかかるとモデルが差し替わる
Allowed by auto mode classifier のほう: CLI 側の実行許可。引っかかると承認待ちで止まる

止まり方が違うので、そこで見分けられます。承認ダイアログが出ているなら後者、モデル表示が変わっているなら前者です。

context が倍になったら、金額も倍になりました

スクリーンショットが撮れたタイミングの数字を並べます。左下のコスト表示と、その右にあるコンテキストの使用量です。

出典はこの記事に貼った画面そのもので、請求明細ではありません。Claude Code がセッション内で出している概算値なので、そのつもりで読んでください。

タイミング	コスト	コンテキスト
Opus 5 へ切替した直後	`$4.8375`	`235.3k`
Advisory を読んでいる途中	`$9.3436`	`262.3k`
完了時	`$19.2662`	`490.4k`

最後の画面はこれだけです。

$19.2662  Opus 5 (1M context)  ↑490.4k  ↓1.8k

並べてみて、はっきり出たなと思ったのがここです。

235.3k → 262.3k のあいだ（+27k）でコストは 4.8 → 9.3 ドル
262.3k → 490.4k のあいだ（+228k）でコストは 9.3 → 19.2 ドル

コンテキストが倍になったところで、累計コストもだいたい倍になっています。

当たり前といえば当たり前で、ターンを重ねるたびに、それまでの会話を全部読み直させているからです。読ませているものが増えれば 1 ターンの単価が上がります。effort が xhigh なら、そのうえで thinking も長くなります。

ここから引ける実務的な結論は、たぶんこうです。

長時間タスクでは「あと何回ターンを回すか」より「今 context に何が載っているか」を見たほうがいい
中間成果を早めにファイルへ落として、要らなくなった探索ログを context から降ろせる設計にしておくと効く
逆に、1M context に甘えて全部載せたまま最後まで走ると、後半のターンが一番高くつく

正直に言うと、途中経過を眺めている間は「まあ 10 ドルくらいかな」と思っていました。倍になりました。9.3 ドルの地点で残り作業が半分以上あることに気づいていれば、そこで effort を落とす判断もできたはずです。できませんでした。

長時間タスクを回すときは、コスト表示をたまに見たほうがいいです。見たところで途中でやめる決断ができるかというと、それはそれで別の話なんですが。

19 ドルで何が残ったか

これで何も残らなかったら、ただの授業料です。何が出たかを書いておきます。

出たのは 3 本の md でした。

監査レポート（事実と証拠の正本）
監査 plan（作業記録と残件）
修正手順の md（実行の正本）

数字で言うと、確定した指摘が 29 件。内訳は critical 3 / high 9 / medium 14 / low 3 です。候補として挙がったのは 41 件で、そのうち 35 件を検証して、29 件を確定、6 件を却下、残り 6 件は稼働環境を見ないと判断できないので保留、という整理になっていました。

この「41 件のうち 6 件を自分で却下した」という部分が、個人的にはいちばん価値がありました。挙げっぱなしなら 41 件のレポートになります。そこから自分で 6 件落として、根拠を書いて、判断待ちを判断待ちとして残す。ここまでやって、はじめて人間が読む価値のある台帳になります。

そして、その 29 件を 30 タスクに展開した修正手順まで書かれていました。

29 件なのにタスクが 30 個ある理由も書いてありました。1 つの指摘を「まず権限を閉じる対処」と「出力側の恒久対策」の 2 本に割っているからです。これは指示していません。勝手にそう分けていました。ここは素直に良いと思いました。

さらに、30 タスクは「本番切替前に必須」「本番切替前に推奨」「切替後で可」「所有者の判断待ち」の 4 つのバッチに並べてありました。判断待ちの 2 件については「所有者の決定が出るまで着手しない」と明記されています。監査は指示ではない、という線引きが残っているのは助かります。

このとき使っていた監査プロンプトは自作で、公開しています。

何ができるかの紹介ページ: https://ishizakahiroshi.com/work.html?id=ai-audit-prompts
リポジトリ（Star をいただけると励みになります）: https://github.com/ishizakahiroshi/ai-audit-prompts

AI に書かせたコードや作業を、安全に業務へ取り込むためのレビュー・監査用プロンプト集です。今回使ったのはそのうちのアプリ監査用の 1 本で、特定の AI ツールに依存しない書き方にしてあります。

このプロンプト集自体の話は別に書いています。

9日前の「最新」が、もう古かった。自作の監査プロンプト集を、AIの群れに直させた話
https://qiita.com/ishizakahiroshi/items/288dbf9aa52b8d9bafbe

監査結果は「指示」ではないので、そう書かせておく

19 ドルぶんの成果物で、金額以上に効いたのが実はここでした。

AI に監査させると、出てくるのは「直すべきものの一覧」に見えます。見えますが、実際には「直すかどうかを人が決めるための材料」です。この 2 つを混ぜると、AI が挙げた 29 件をそのまま全部やる、という話になります。それは違います。

なので、監査プロンプト側で最初から線を引いてあります。出力にこう書かせています。

監査は指示ではない。採否・担当・実施時期は所有者が決める
判断待ちのものは、判断待ちのまま残す（無理に確定させない）
所有者の判断が要るタスクには、判断が出るまで着手しないと明記する

今回だと、稼働中のサーバーを読み取りで観測しないと確定できないものが 6 件、方式そのものを決めないと手が付けられないものが 2 件、そのまま残りました。残せたのが良かったと思っています。AI に「全部きれいに片付けて」と言うと、分からないものを分かったことにして埋めてきます。そこを埋めさせない書き方をしておくと、あとから読んで信用できる台帳になります。

同じ理屈で、レポートに載っている点数（総合スコアのようなもの）についても、算定式を先に書かせたうえで「これは heuristic であり暫定値で、未調査ぶんを減点していないので上限値である」と本文に明記させています。

数字は一人歩きします。とくに「セキュリティスコア〇〇点」みたいな形をしていると、前提を読まずに数字だけ抜かれます。なので、数字を出させるなら、その数字が何を測っていないかを同じ場所に書かせる。ここは AI に限らず、人が書くレポートでも同じだと思っています。

途中でモデルが変わると、成果物の記録はどうなるか

ここは今回いちばん書きたかったところです。

作業 md の frontmatter に、どの AI がその文書を作ったかを記録する仕組みを入れています。こういう形です。

ai_provenance_version: 1
ai_author_agent: claude
ai_author_runtime: many-ai-cli
ai_author_provider: anthropic
ai_author_model_id: claude-fable-5-1
ai_author_model_display: Claude Fable 5.1
ai_author_reasoning: xhigh
ai_author_model_source: runtime
ai_execution_refs: [AIX-...]

複数の AI CLI を使い分けていると、あとから「これ、どの AI に書かせたやつだっけ」が分からなくなります。plan は A に書かせて、実装は B にやらせて、レビューは C、みたいなことをやるので。それで、文書側に記録を持たせています。

今回、この設計が想定していなかったことが起きました。文書を作り始めたモデルと、作業を終えたモデルが違う、というケースです。しかも自分の意思ではなく、セーフガードによって差し替えられています。

結果としてどうなったかというと、こうなりました。

監査 plan のほう。frontmatter は作成時点の claude-fable-5-1 のままです。そして本文にこう追記されていました。

セッション途中でユーザーが実行モデルを Opus 5 (1M context) へ切り替えたため、C3 後半以降の実行 model は claude-opus-5[1m] である。frontmatter は作成時の値を保持し、上書きしない。

一方、切替のあとに新規で起票された修正手順の md は、最初から claude-opus-5 / Claude Opus 5 (1M context) / xhigh で記録されていました。

つまり、

文書を作成した AI（ai_author_*）は作成時点の値で固定する
各工程を実行した AI（ai_execution_refs）は工程ごとに別で記録する

という分け方が、たまたま今回の状況でちゃんと機能しました。

もし frontmatter を「最後に触ったモデル」で上書きする作りにしていたら、「この監査 plan は Opus 5 が作った」という嘘の記録が残っていたはずです。実際には前半を Fable 5.1 が、後半を Opus 5 が書いています。どちらか一方の名前だけを残すと、後から作話の傾向を追いかけるときに使えない台帳になります。

ついでに気づいた、モデル名の表記ゆれ

記録を見比べていて気になったのが、同じモデルを指す文字列が場所によって違うことです。

画面下部の表示: Opus 5 (1M context)
plan 本文に書かれた実行 model: claude-opus-5[1m]
修正手順の frontmatter: claude-opus-5

[1m] が付くかどうかが揃っていません。1M context かどうかは、同じモデルの別バリアントの扱いです。同じモデルとして数えるか、別物として数えるか。

台帳としては、あとから「1M context のときだけ精度が落ちた」みたいな比較をしたくなる可能性があるので、変種まで残るほうが望ましいはずです。ここは自分の仕組みの直しどころとして持ち帰りました。細かい話ですが、こういうところが揃っていないと、数か月後に集計しようとしたときに手作業が発生します。

ここは正直、そこまで考えて分けていたわけではありません。「作成した AI と実行した AI は違う軸だろう」という程度の理由でした。

セーフガードが勝手にモデルを差し替えてくる世界では、この 2 つを分けておく実利があるんだな、というのは今回はじめて分かりました。自分でモデルを選んでいるつもりでも、記録上は選べていないことがある。 それが観測できただけで、19 ドルのうち何割かは元が取れた気がしています。

自動切替を切るという選択肢はあるか

あります。ただ、切ったら幸せになるかというと、そうでもなさそうです。

公式の説明はこうです。

With automatic switching disabled, a blocked request pauses the conversation instead of switching models

自動切替を切ると、モデルを差し替える代わりに会話が一時停止します。そのうえで、メッセージを編集して Fable 5 / 5.1 で再試行するか、自分で能力の低いモデルへ手動で送る、という流れになります。
https://support.claude.com/en/articles/15363606

設定場所は、Web の設定だと Settings > Capabilities の Switch models when a message is blocked。Claude Code では /config の MODEL & OUTPUT の下にあります。画面のヒントにも You can configure model switch behavior in /config と出ていました。

自分は ON のままにしています。理由は単純で、9 分ぶんの thinking を積んだところで完全停止されるより、いったんどこかで走り続けてくれたほうが、あとから選び直せるからです。今回まさにそれをやりました。

止まってくれたほうが良い場面もあると思います。「知らない間に別のモデルが答えを書いていた」のが困るケースです。とくに、成果物にモデル名を記録している人や、モデルごとの精度を比べている最中の人は、黙って差し替わるほうが困ります。

そこは何を作っているかで判断が変わるはずなので、断定はしません。ON にするなら「差し替わったことに気づける仕組み」を自分側に持っておくのが現実的だと思います。今回で言えば、成果物の provenance がそれでした。

正攻法は Cyber Verification Program のほうです

ここまでは「引っかかったあとにどうするか」の話でした。そもそも引っかかりにくくする道も用意されています。

Cyber Verification Program（CVP）というものがあります。防御目的のセキュリティ業務をやっている場合に申請すると、Opus / Sonnet 系でのセーフガードが緩和される、という枠組みです。無料で、身元確認があり、審査結果はおおむね 2 営業日でメール通知、と説明されています。

Real-time cyber safeguards on Claude Opus and Sonnet
https://support.claude.com/en/articles/14604842-real-time-cyber-safeguards-on-claude-opus-and-sonnet
Making frontier cybersecurity capabilities available to defenders
https://www.anthropic.com/news/claude-code-security

こちらのページには、判定が 2 つのカテゴリに分かれていることも書かれています。

禁止用途: 大量のデータ持ち出しやランサムウェア開発など。「ほぼ常に悪意をもって使われ、正当な防御用途がほとんどない」もの。これは緩和されません
高リスクの両用（dual use）: 脆弱性の悪用や、セキュリティツールの開発など。正当な防御業務としてありうるもの。こちらが CVP の対象です

なお、利用しているプラットフォームによって使えるかどうかが違う、という注意もありました。ファーストパーティのサービス、Microsoft Foundry、AWS 上の Claude Platform では使えて、Bedrock と Vertex AI では使えない、と書かれています。

自分はまだ申請していません。今回のような自分のリポジトリの読み取り監査でどこまで対象になるのかを、まだ読み切れていないからです。ここは確認できていないので、そのまま書いておきます。

同じことが起きたときの手順

ここまでの内容を、次に自分が踏んだときのためにまとめておきます。

1. 画面の Details を見る
   [cyber]      → フォールバック先は Opus 4.8
   biology 系   → フォールバック先は Opus 5

2. そのモデルで続けてよいか決める
   よい   → そのまま放置して完走させる
   いやだ → 3 へ

3. Esc で中断する（会話は消えない）

4. /model で使いたいモデルを選ぶ
   Opus 5 (1M context) など

5. 「処理続けてください」で再開
   → 中断地点から読み直して続く

6. 完走したら、成果物側にどのモデルで走ったかが
   残っているかを確認する
   （frontmatter を上書きする作りだと嘘の記録になる）

7. コスト表示とコンテキスト使用量を時々見る
   context が倍になると累計コストも倍になる

3 と 5 のあいだで /config を触りたくなりますが、今回はそこはいじっていません。切替の設定を変えたのではなく、切替の結果を上書きしただけです。

なお、画面の Send feedback with /feedback は、誤検知だと思ったときの報告口です。公式ページ側も「正当な作業が繰り返し止められるなら報告してほしい」と書いているので、同じパターンで何度も踏むようなら、そこから 1 本入れておくと後々のためになるはずです。

次に同じ監査をやるなら、こうします

反省というほどではないんですが、同じことをもう一度やるなら変えるところがいくつかあります。

effort を最初から xhigh にする必要はなかった

今回は最初から xhigh でした。9 分 12 秒の thinking も、3 分 16 秒の thinking も、その設定の結果です。

ただ、監査の工程を思い出すと、xhigh が本当に効くのは 3 の adversarial verification だけです。「候補を挙げる」「ファイルを読む」「構成を数える」あたりは、深く考えるより広く読むほうが大事な工程で、そこに最大の effort を張る理由は薄い。

なので次は、探索まではふつうの effort で回して、検証と最終レポートの段だけ上げる、という分け方を試すつもりです。工程ごとに effort を切り替えられるなら、そのほうが素直です。

1M context を選ぶかどうかも別の判断

Opus 5 (1M context) を選んだのは、単に既定にしていたからです。監査対象が大きいので、context が広いほうが安心ではありました。

ただ、さっきのコスト推移を見ると、広い context は「入れられる」だけで「入れるべき」ではないという当たり前のことが数字で出ています。490.4k まで積んだ状態のターンは、235.3k の頃のターンより単純に高い。

対策は context を広げないことではなくて、中間成果を早めにファイルへ落とすことだと思っています。読んだ結果をレポートの下書きへ吐き出しておけば、探索ログそのものは持ち歩かなくて済みます。今回は後半でレポートを書き始めたので、そこまでの探索が全部乗ったまま最後まで走りました。

監査の工程を、セッションごとに切る

もうひとつは、そもそもセーフガードに触れる工程を分けるという手です。

今回いちばん怪しかったのは、GitHub Advisory を読みに行った工程です。判定がモデルの読むもの全部を見るなら、advisory の本文を読み込んだ時点で発火する可能性は当然あります。

なら、依存パッケージと版のリストを作るところまでを 1 セッションでやって、advisory の突き合わせは別セッションに切る、という分け方ができます。1 本の長い会話に全部積むより、context も軽くなるので一石二鳥です。

これは未検証です。分けたら発火しなくなる、とまでは言えません。ただ、発火したときに巻き添えになる範囲は確実に小さくなります。

Fable 5.1 に戻して再試行する手もある

公式ページには、Opus へ落ちたあとに「メッセージを編集して Fable 5 / 5.1 で再試行する」という選択肢も書かれています。
https://support.claude.com/en/articles/15363606

今回はそちらを試していません。中断した時点で、モデルを選び直すほうが早いと判断したからです。

ただ、Fable のほうが速い作業をやっている最中に踏んだなら、依頼文を書き直して Fable で再試行するほうが理にかなっています。どちらが良いかは、その時に走らせているタスクの性質で変わります。

今回わかったこと

観測できた事実だけを並べます。

Fable 5.1 で監査作業中に [cyber] でフラグされた
処理は止まらず、モデルだけ Opus 4.8 に切り替わった
中断して /model から Opus 5 (1M context) を選び直せた
「処理続けてください」で、途中状態を捨てずに再開できた
再開後、最後まで Opus 4.8 に引き戻されなかった
コストは $4.8375 → $9.3436 → $19.2662、コンテキストは 235.3k → 262.3k → 490.4k と伸びた

公式ドキュメントで裏が取れたのは以下です。

フォールバック先はカテゴリで違う（biology 系は Opus 5、offensive cyber 系は Opus 4.8）
判定はモデルが読むもの全部を見る（自分が入力していない内容でも発火しうる）
誤検知は想定済みで、フィードバックを求めている
自動切替を切ると、モデルを替える代わりに会話が一時停止する
防御目的の業務向けに Cyber Verification Program がある

わかっていないこと

正直に書きます。

なぜ引き戻されなかったのかは分かりません。 手動で選んだモデルが優先されるのか、再開時の入力が短かったから判定に触れなかっただけなのか、切り分けていません
Opus 5 自体のセーフガードに触れたらどうなるのかも確認していません。 Opus 側にもリアルタイム判定はありますが、そこでさらに別モデルへ落とすという記述は見つけられませんでした（「ブロックされる」とだけ書かれています）
1 回の観測です。 別の日、別のタスク、別の文脈で同じになるかは分かりません

なので、この記事は「こうすれば必ず続けられます」ではなく、「こういう手があって、今回は効きました」くらいの温度で読んでもらえるとありがたいです。

おわりに

19 ドルは高いです。普通に高い。

ただ、レガシーなアプリを丸ごと読ませて、公開されている脆弱性情報まで突き合わせて、候補 41 件から 29 件へ絞って、修正タスクを 30 個に割って、実行順まで並べた台帳が残りました。これを人力でやったら、丸 1 日では終わりません。そう考えると、まあ、という気持ちになります。

もっとも、毎回これをやったら月末に泣きます。effort と context を毎回最大にする理由はないので、そこは使い分けだと思っています。

今回いちばん残ったのは、金額でも監査結果でもなくて、自分が使うモデルを自分で選び直せたという感触のほうでした。安全機構が動くのは構いません。動いたあとで、行き先を自分で決められるかどうか。そこだけは手放したくないと思いました。

とりあえず次は、この 30 タスクを順番に潰すところからです。今度は effort を落として。