Anthropic RSP 3.3改定、AI安全審査の新基準

Anthropic は 2026年5月26日、Responsible Scaling Policy を RSP 3.3 に更新した。今回の更新は新モデル発表ではない。Anthropic の更新ページでは、主な変更として、化学・生物兵器に関する新規リスクの閾値を脅威モデルに合わせて見直したこと、個別モデルのリスクに関する off-cycle update の扱いを精緻化したこと、用語の小修正を挙げている。

日本企業にとって重要なのは、RSP 3.3 を「Anthropic が安全だと宣言した資料」として読むことではない。むしろ、Claude や frontier model を業務導入するときに、ベンダーへどの安全評価文書を求め、モデル更新時にどの変更を再審査するかを決めるための材料である。前回の RSP 3.2改定 は LTBT と Risk Report の監督に重心があった。今回の RSP 3.3 は、その統治文書の中で、特に高影響リスクの閾値とモデル別リスク更新の扱いを調整した更新として読むべきだ。

この流れは、Anthropic の他の安全・統制施策ともつながる。Claude containment はエージェントが触れる環境境界を扱い、Claude Compliance API統合 は監査ログを企業システムへ渡す話だった。RSP 3.3 は、そのさらに上位で、モデル能力と重大リスクをどう判断し、いつ安全文書を更新するかを示す政策レイヤーの資料である。

事実: RSP 3.3は3つの変更を明示した

Anthropic の Responsible Scaling Policy 更新ページは、RSP 3.3 の変更を 3 点に整理している。第一に、novel chemical/biological weapons production、つまり新規の化学・生物兵器生産に関する閾値を、懸念する脅威モデルにより合うよう改定した。第二に、個別モデルのリスクに関する off-cycle update の扱いを refined した。第三に、用語を軽微に直した。

ここでまず分けて考えるべきなのは、「新しい安全基準が一気に追加された」というより、RSP 3.0 以降の枠組みを運用しながら、閾値と更新手順を調整している点だ。Anthropic は 2026年2月の RSP 3.0 で、Frontier Safety Roadmaps と Risk Reports を中心に据えた構成へ大きく書き換えた。その後、4月の RSP 3.2 では外部監督のプロセスを増やし、5月の RSP 3.3 では高影響リスクとモデル別更新の扱いを詰めた。

つまり今回のニュースは、単体で派手な製品変更ではない。しかし、AI ベンダーの安全評価を追う側から見ると、RSP が一度作って終わりの文書ではなく、脅威モデル、モデル能力、評価実務に合わせて短い間隔で更新されていることを示している。

事実: バイオリスク閾値の変更は「能力」ではなく脅威モデルの話

Anthropic が明示した最初の変更は、化学・生物兵器に関する閾値の見直しである。ここで重要なのは、AI が生物学の質問に答えられるかどうかだけを見ているわけではない点だ。RSP の文脈では、問題は「モデルが、現実の攻撃者や組織にとって、危険な能力をどれほど実用的に引き上げるか」である。

たとえば、単に一般的な生物学知識を説明することと、危険物質の設計、取得、実験計画、失敗時の修正、運用上の隠蔽を連続して支援することは違う。RSP 3.3 の更新文が「懸念する脅威モデルによりよく追随する」と表現しているのは、こうした実用的な悪用シナリオに合わせて閾値を見直すという意味に近い。

日本企業の導入審査では、この点を誤読しないほうがよい。Claude を社内チャットや開発支援で使う企業が、いきなりバイオ兵器リスクを自社の主要リスクとして扱う必要はないかもしれない。しかし、ベンダーが重大リスクをどう定義し、能力評価をどの脅威モデルに接続しているかは、金融、製造、医療、公共、教育、研究機関の調達では説明材料になる。

特に研究開発部門や大学連携、製薬・化学・素材領域で生成AIを使う場合、単純な「危険質問を拒否するか」だけでは足りない。モデルが専門的な作業列をどこまでつなげるか、評価対象が公開モデルだけか内部モデルも含むか、閾値に近づいたときにどの safeguard が必要になるかを確認する必要がある。

事実: 個別モデルのリスク更新は、モデル横断の安全文書だけでは足りないという話

RSP 3.3 の二つ目の変更は、個別モデルのリスクに関する off-cycle update の扱いだ。これは企業導入にかなり実務的な意味を持つ。AI ベンダーの安全文書は、会社全体の方針、モデルファミリーの system card、個別モデルの risk report、リリースノート、インシデント報告に分かれる。モデルの能力が急に伸びたり、新しい評価結果が出たりしたとき、どの文書がいつ更新されるのかが分からないと、導入企業側の再審査も止まる。

Anthropic は RSP 更新ページで、2026年2月に Claude Opus 4.6 の sabotage risk report を公開したことにも触れている。その説明では、AI R&D-4 capability threshold を超えたとは判断していない一方で、その判断が主観的になりつつあるため、Opus 4.5 を明確に上回る将来の frontier model について sabotage risk report を書く方針を示していた。これは、能力評価が単なる発売時チェックではなく、モデル別・リスク別に文書化されていくことを示す例である。

この文脈で RSP 3.3 の off-cycle update は重要だ。企業が Claude を導入するとき、最初の審査で system card と RSP を読んで終わりにはできない。モデルが更新された、risk report が追加された、評価基準が変わった、あるいはベンダーが特定リスクの見立てを更新した場合に、自社側の利用範囲や承認条件を見直す必要がある。

分析: 日本企業はRSPを保証書ではなく質問票として使う

ここからは分析だ。

RSP 3.3 は、Anthropic が安全であることを第三者が保証する文書ではない。自主的なリスクガバナンス文書であり、法令、監査報告書、SOC 2、ISO 認証、個別契約の代わりにはならない。それでも実務価値があるのは、AI ベンダーに確認すべき質問を具体化してくれるからである。

日本企業が Claude や他の frontier model を調達するとき、少なくとも次の問いを持つべきだ。重大リスクの capability threshold は何か。閾値に近づいたとき、どの safeguard が必要になるのか。Risk Report はどの頻度で出るのか。個別モデルの評価結果が変わったとき、off-cycle update はどの文書で通知されるのか。外部レビューや独立した監督主体はどこまで関与するのか。

これは、RSP v3.1の文言修正 から続く読み方でもある。RSP の小さな改定は、単なる法務文書の言い換えではなく、Anthropic がどのリスクをどの粒度で説明しようとしているかを示す。日本企業の調達・法務・セキュリティチームは、ベンダー比較表に「RSP の有無」だけを書くのではなく、改定履歴と実際の risk report の粒度まで見るべきだ。

分析: バイオリスクは特定業界だけの話ではない

RSP 3.3 の中心に化学・生物兵器リスクがあるため、一般企業には遠い話に見えるかもしれない。しかし、実務上の読みどころはもう少し広い。AI ベンダーが重大リスクを定義するとき、単に禁止カテゴリを列挙するのではなく、脅威モデル、能力評価、しきい値、必要な safeguard、個別モデル更新をどう結びつけるかが問われている。

これはサイバーセキュリティ、金融犯罪、詐欺、個人情報、重要インフラ、研究開発にも応用できる考え方だ。たとえば、AI エージェントが脆弱性修正を支援するなら、その能力は防御にも悪用にも使える。Claude containment の議論で見たように、便利さが増すほど実行境界と監査が必要になる。RSP 3.3 のような上位ポリシーは、こうした個別製品の安全設計を評価する土台になる。

日本企業では、AI ガバナンスがしばしば「利用規程」や「禁止事項一覧」に寄りがちだ。しかし frontier model の導入では、禁止リストだけでは追いつかない。モデル能力が更新され、評価手法が変わり、ベンダー文書も改定される。そのため、自社側にも「モデル更新時に何を再確認するか」という運用が必要になる。

まず導入審査で見るべきこと

第一に、RSP 3.3 の本文と redline を、前回の RSP 3.2 と比較して読む。特に、化学・生物兵器リスクの閾値がどう変わったか、個別モデルのリスク更新がどの条件で行われるかを見る。日本企業の調達担当は、ベンダーに最新版だけを送ってもらうのではなく、改定差分を説明できるかを確認したほうがよい。

第二に、自社の利用範囲を risk report の粒度と対応させる。Claude を文章作成だけに使うのか、開発、セキュリティ、研究、データ分析、社内エージェントに使うのかで、見るべき risk report は変わる。特に agentic use case では、モデルの misalignment や sabotage risk、実行環境の containment、監査ログを別々に読まず、同じ運用設計に載せる必要がある。

第三に、off-cycle update の受け取り方を決める。モデルが自動で切り替わる SaaS では、利用者が気づかないうちに能力や安全評価が変わることがある。契約、管理者設定、監査ログ、ベンダー通知、社内 change management をつなぎ、重要モデルの risk update が出たときに誰が判断するかを決めておきたい。

第四に、RSP を社内説明用に過剰に使わない。RSP があるから安全、という説明は危ない。正しい使い方は、RSP を根拠に「このベンダーは重大リスクをこう定義しており、当社はこの利用範囲ではこの文書とこの統制を確認する」と説明することだ。

まとめ

Anthropic の RSP 3.3 改定は、モデル性能や料金のニュースではない。化学・生物兵器リスクの閾値と、個別モデルのリスク更新手順を見直した、AI 安全ガバナンスの運用面の更新である。

日本企業にとっての価値は、Claude 導入時の安全審査を具体化できる点にある。RSP 3.3 を保証書として扱うのではなく、ベンダーに投げる質問票、社内再審査のトリガー、モデル更新時の確認項目として使う。そうすれば、AI ベンダー評価は「モデルが賢いか」だけでなく、「重大リスクをどう定義し、いつ文書を更新し、誰が見直すか」まで含む実務判断に近づく。

出典

• Responsible Scaling Policy Updates - Anthropic, 2026-05-26
• Anthropic’s Responsible Scaling Policy Version 3.3 - Anthropic, 2026-05-26
• Anthropic’s Responsible Scaling Policy Version 3.3 redline - Anthropic, 2026-05-26
• Risk Report: Claude Opus 4.6 Sabotage - Anthropic, 2026-02-10