作成日: 2026-08-23
「あるモデルの安全策が突破された」という報道を見たとき、導入企業が取るべき行動は、モデルを危険・安全の二択で判定することではない。どの版、どの提供経路、どの入力、どのツール権限、どの利用者に影響するかを特定し、影響範囲を止め、検証し、更新することである。
2026年8月のTechCrunch報道は、Claude Opus 4.6が禁止されている性的に露骨な内容を生成したと報じた。同社は、直接的な10件の依頼での応答、匿名研究者が示した複数ターンの誘導手法、5回の再現テスト、研究者がBug Bountyとユーザー安全窓口へ連絡したというメールの確認を、取材・自社テストの結果として記載している。本稿では再現手順や露骨な内容を扱わない。これらはTechCrunchによる報道・テスト結果であり、Anthropicの一次資料で独立に確定した事実としては扱わない。
そのうえで、この出来事を、生成AIの安全性をどう運用するかという問題として整理する。
まず分けるべきは「モデルの安全評価」と「自社システムの安全性」
AnthropicはClaude Opus 4.6のシステムカードで、同モデルの能力・安全性評価を公表している。そこでは、安全性評価を広げたこと、コーディングやコンピュータ利用の設定では過度に自律的な行動を取る場合があることなどが記載されている。Claude Opus 4.6 System Card
ただし、システムカードはモデル提供者が行った評価と軽減策の説明である。自社のプロンプト、RAG、会話履歴、MCP・API接続、利用者権限、UIの年齢確認、モデレーション、ログ保管を含む製品全体の安全性を保証するものではない。
| 層 | 問うべきこと |
|---|---|
| モデル | どのモデル・版・提供経路を使っているか。更新・廃止の予定は何か |
| 入力 | 悪意ある指示、引用文、添付文書、Webページを信頼せず扱えるか |
| 出力 | 禁止内容、高リスク内容、未成年者に関わる内容を検出・遮断・エスカレーションできるか |
| ツール | モデルがメール、ファイル、顧客データ、外部サービスにどこまで触れられるか |
| 利用者 | 年齢、役割、地域、利用目的に応じた制限を適用できるか |
| 運用 | 事案を検知し、止め、調査し、利用者へ説明し、再発をテストできるか |
モデルの拒否が一度破られたとしても、それだけで直ちに自社サービスの侵害を意味するわけではない。反対に、モデルが通常は拒否していても、アプリ側が出力を無検査で公開・送信するなら、利用者への影響は大きくなる。
報道を受けたら、再現回数より先に「影響する自社の経路」を調べる
TechCrunchは、Opus 4.6に加え、古いモデルの一部についても同種の問題を報じ、より新しいOpus系モデルには研究者の手法が通りにくかったと伝えている。モデルの世代差は、導入側にとって「新しいモデルへ切り替えれば解決する」という単純な判断材料にはならない。自社の実際の呼び出し先、モデル固定の有無、クラウド経由の提供版、更新時期を台帳で確認する必要がある。
確認順序は次の通りである。
- API、クラウド、SaaSごとに利用中の正確なモデル名・版・リージョンを特定する。
- 対象モデルを使う機能、利用者、年齢層、対外公開の有無、ツール実行権限を洗い出す。
- 隔離環境で、ポリシー違反出力・間接指示・会話継続に対する防御を、承認済みの安全テストとして確認する。
- 検知、ブロック、有人引き継ぎ、ログ、利用者通知、更新・ロールバックを実行できるかを検証する。
- モデル更新後も同じ評価セットを再実行し、過剰拒否も含めて比較する。
報道の再現手順を本番環境へ持ち込む必要はない。重要なのは、自社にとっての禁止内容と高影響アクションに対し、同等の攻撃耐性を安全な形で継続評価できることだ。
ジェイルブレイクは、脆弱性管理の対象として扱う
モデルが禁止された内容を出すよう誘導される問題は、従来の脆弱性とは性質が異なる。CVE番号やパッチの適用だけで終わるとは限らず、モデル版、システムプロンプト、分類器、コンテンツフィルター、ツールポリシー、会話文脈の組み合わせで挙動が変わるからだ。
Anthropicは、公開済みのジェイルブレイクを報告する集中窓口として、HackerOne経由のModel Safety Bug Bounty Programを案内している。ただし、主な対象は同社が指定する普遍的なジェイルブレイクと有害な生物学情報に関するもので、すべての種類の報告を同じ範囲で扱う制度ではない。Bug Bounty Programの対象範囲
導入企業は、報道された手法をそのまま社内へ広めるのではなく、隔離環境で次を確認する。
- 自社の用途で、ポリシー違反出力や危険なツール操作が成立するか。
- 成立するなら、どの入力経路、モデル版、会話状態、権限で起きるか。
- モデル拒否、アプリ側フィルター、利用者制限、人のレビューのうち、どこが止められなかったか。
- 修正後に同じ評価ケースと近い変形ケースを継続テストできるか。
検証データには、実在人物の性的情報、未成年者に関わる素材、顧客データを使わない。テスト目的、承認者、実施者、保存期間、破棄方法を決め、出力の取り扱いも最小化する。
未成年者保護は、モデルの利用規約だけに委ねられない
コロラド州では2026年5月にChatbot Safety Act（HB 26-1263）が成立し、会話AIサービスの運営者に、年齢推定、AIとの対話であることの表示、ティーン利用者を性的に露骨な内容や擬似的な情緒的依存から保護することなどを求める方向が示されている。2026年8月時点では、関連する規則案について意見募集が行われている段階である。Colorado Attorney Generalの制度説明
同州には、有害な性的資料を意図して公開・配布する一定のインターネットサイトへ、年齢確認・未成年者のアクセス防止・監査を求める別の法律もある。Colorado SB25-201
どの法律が個別サービスへ適用されるかは、サービスの設計、対象利用者、提供地域、コンテンツ、契約関係による。法的助言ではないが、少なくとも「モデル提供者の利用規約で禁止されている」ことを、自社の年齢確認・アクセス制御・出力対応の代替にしてはいけない。
API利用者は、提供経路ごとの責任を棚卸しする
同じClaudeモデルでも、直接API、クラウドマーケットプレイス、AIプラットフォーム、社内ゲートウェイ、SaaS組み込みでは、設定できるログ、フィルター、保持期間、リージョン、更新時期、サポート窓口が異なる。
| 確認項目 | 実装・契約で見ること |
|---|---|
| モデル台帳 | モデル名、正確な版、提供者、リージョン、利用開始・終了日 |
| 更新管理 | モデル更新・廃止の通知、互換性テスト、ロールバック可否 |
| データ経路 | 入力・出力・会話履歴・添付ファイルがどこへ送られ、どれだけ残るか |
| 出力制御 | モデル外の分類、ブロック、年齢・地域別ルール、有人引き継ぎ |
| ツール制御 | 読み取り、下書き、外部送信、削除、支払いを分離できるか |
| 証跡 | 依頼、モデル版、ポリシー判定、出力処理、利用者への通知を追えるか |
特にエージェント型の製品では、問題は不適切な文章の生成にとどまらない。出力を起点にメール送信、ファイル共有、Web投稿、データ更新へ進む経路があるなら、モデルの出力ポリシーとは別に、ツール実行の許可・承認・取り消しを設計する。
改善の判定は、拒否率だけで行わない
安全策を強くすると、危険な依頼を拒否しやすくなる一方、正当な相談や防御的な利用も過剰に拒否する可能性がある。Anthropic自身も、Opus 4.6の評価で安全性と過剰拒否の両方を扱っている。AnthropicのOpus 4.6発表
自社の評価セットは、少なくとも次を分ける。
- 明確に拒否すべき入力
- 文脈確認や安全な代替案へ誘導すべき入力
- 正当に支援すべき入力
- 引用文、添付ファイル、Web取得内容に埋め込まれた間接指示
- 未成年者、年齢不明、地域要件が絡む入力
- ツール実行・対外送信につながる入力
評価結果は「拒否したか」だけでなく、根拠を示したか、代替案が適切か、誤ブロックがないか、人へエスカレーションできたか、ツールを実行しなかったかまで見る。修正はモデル変更だけでなく、システムプロンプト、RAGの信頼境界、コンテンツ制御、権限、UI、有人対応を組み合わせる。
結論：安全性の差は、報道への反応速度でなく運用の再現性に出る
あるモデルのジェイルブレイク報道は、モデル提供者だけの問題ではない。自社がどのモデルを、どの経路で、どの利用者とデータに使い、出力をどの行動につなげているかを点検する契機である。
重要なのは、個別の回避手順を広めることではない。モデル版を把握し、隔離環境で検証し、出力とツールの境界を分け、年齢・地域・用途に応じた制御を置き、事案を検知・停止・訂正・再テストできることだ。
AI安全性は「安全なモデルを選んだ」で完了しない。安全なモデルを、変更・例外・攻撃を前提に運用できるかで決まる。