Claude Media
Responsible Scaling Policy変遷 — v1.0からv3.4まで8回改定

Responsible Scaling Policy変遷 — v1.0からv3.4まで8回改定

AnthropicのResponsible Scaling Policyは2023年9月のv1.0から2026年7月のv3.4まで8回改定された。各版で何が変わったかを時系列で追う。

Responsible Scaling Policyとは

Responsible Scaling Policy(RSP)は、Anthropicが2023年9月に公表した自主的な枠組みで、モデルの能力が一定の危険水準を超えたときに安全対策を段階的に引き上げます。最新版はv3.4(2026年7月8日発効)。v1.0から数えて8回の改定を経ています。

骨格は一貫しています。モデルの危険な能力を「Capability Threshold(能力閾値)」として定義し、閾値を越えたらAI Safety Level(ASL)に応じた安全基準(Required Safeguards)を適用する。閾値を越えていないことの確認も、モデルを評価する仕組み(Capability Assessment)としてポリシーに組み込まれています。

8回のうち性格が大きく違うものが混ざっています。v2.0とv3.0は構造そのものを作り直した大改定、v2.1・v2.2・v3.1〜v3.4は既存の枠組みの中で文言や範囲を絞り込む小改定です。この二層構造を意識すると、変遷が読みやすくなります。

v1.0からv2.0へ — ASLの意味が「モデルの等級」から「対策のまとまり」に変わった

v1.0(2023年9月19日発効)は最初のRSPです。ASLという等級を定義し、ASL-2(当時の最新モデル)とASL-3(次の危険水準)だけを先に細かく決めました。ASL-4は「ASL-3に到達するまでに定義する」と約束する方式で、これを「iterative commitments(反復的な約束)」と呼んでいます。将来の水準まで今決めても時間に耐えないから、という理由です。

リスクの見方は2種類でした。ユーザーがAPIなどから使うことで生じる「デプロイメントのリスク」と、強力なモデルを持つだけで生じる「封じ込めのリスク」(盗まれた場合や内部で自律的に逃げ出す場合)です。ASLの要件を満たせないなら、スケーリングの停止か展開の延期を約束する。v1.0の核はこの「止まる約束」でした。

v2.0(2024年10月15日発効)は、運用1年の学びを反映して作り直した改定です。変更点を並べると、仕組みの考え方が変わったことが分かります。

くらべる

「ASL」の指すものがv1.0とv2.0で違う

2023年9月

v1.0

ASLはモデルの等級でもありました。モデルがASL-3相当と判定されれば、そのモデルに対策一式が紐づきます。評価は事前に決めた試験で行い、包括的な評価は3か月ごとでした。

2024年10月

v2.0

ASLは技術的・運用的な対策のまとまりを指す語になり、新しく「Capability Threshold」と「Required Safeguards」が置かれました。事前に決めた試験の代わりに、モデルが閾値から十分に遠いことを示す「affirmative case」を求め、評価の頻度は4倍の実効計算量か、6か月分の学習後強化のどちらか早いほうになりました。

評価間隔を3か月から6か月に延ばした理由は、変更履歴に書かれています。3か月ごとだと、各チームが包括的なテストや手法の改善よりも頻繁な評価の実施を優先してしまったためです。事前に決めた評価を取りやめたのも、精度の高い試験ほど頻繁に変わるため、取締役会による事前承認が現実的でなくなったからでした。

同じ改定で、自律的な複製と適応(ARA)の閾値は「チェックポイント」に格下げされました。到達しても自動的に高い基準は課さず、追加評価と対策の準備を促す位置づけです。AI R&Dの閾値も新設されています。

同日には、当時まだ実装段階だったASL-3の安全対策を、非拘束的な計画「Planned ASL-3 Safeguards」として先出しした文書も公開されました。デプロイメント安全対策は4層の防御(Access controls → Real-time classifiers → Asynchronous monitoring → Post-hoc jailbreak detection)として設計されています。セキュリティ対策としては、権限管理・ソフトウェアサプライチェーン監視・モデル重みへのアクセス制御・物理セキュリティなどが並びます。

v2.1・v2.2 — 能力閾値の細分化と適用範囲の絞り込み

v2.1(2025年3月31日発効)は、ASL-3を超える安全対策が必要になる能力閾値をより明確にする改定です。柱は3つありました。

1つ目は、CBRN(化学・生物・放射性物質・核)開発に関する新しい能力閾値の追加です。中程度のリソースを持つ国家プログラムの開発能力を大幅に押し上げうる水準を対象にしています。2つ目は、AI R&Dの能力閾値を2段階に分割したことです。「エントリーレベルのAI研究業務を完全自動化できる」水準と「有効スケーリングの速度を劇的に加速できる」水準を別々に定義し、それぞれの安全対策の詳細を加えました。

3つ目は、新しいRequired Safeguardsに上げるたびに能力閾値の一覧を見直すという、一般的な約束です。v1.0にあった「ASL-N+1の評価をASL-Nのモデルを作る時点までに定義する」約束は外されました。能力閾値はきれいな段階にまとまって現れるわけではなく、その約束は不要な複雑さを増やすという判断です。

v2.2(2025年5月14日発効)は文言レベルの小改定です。ASL-3セキュリティ基準の対象範囲を定めた脚注で、それまで「高度に洗練された国家関与のインサイダー」だけを除外対象としていたところを、「洗練されたインサイダー」と「国家関与のインサイダー」の両方を除外する形に改めました。

v3.0の全面書き換え — 集団行動の問題を前提に作り直した

v3.0(2026年2月24日発効)はRSPの包括的な書き直しです。発効時の説明では、v1.0以来の「if-thenの約束」が、2年半でうまくいった部分とそうでない部分に分かれたことが語られています。ASL-3のデプロイメント基準を満たすために入出力の分類器が磨かれたのは成功例でした。一方、高いASLで想定した対策は、1社だけでは達成が難しいこともはっきりしました。

そこでv3.0は、前提を変えました。旧RSPは、他社がどう動くかと無関係に、自社モデルのリスクを許容水準まで下げる緩和策を約束していました。しかし社会にとって重要なのは業界全体のリスクです。1社が安全対策のために開発を止めても、他社が強い緩和策なしに進めば、保護の弱い開発者が速度を決める世界になり、責任ある開発者は安全研究の機会を失います。この問題はまだ起きていないものの、備えるに足る可能性だとされています。

新しいRSPは、この前提に立って緩和策を2つに分けました。他社の動きにかかわらず自社が進めるものと、業界全体で実施すれば先端AIのリスクを適切に管理できるはずの、野心的な能力と緩和策の対応表です。あわせて2つの公開文書の仕組みを導入しました。

Frontier Safety Roadmapは、セキュリティ・アラインメント・セーフガード・政策の各分野で緩和策の具体的な計画を示す文書です。拘束的な約束ではなく、進捗を公開で採点する目標という位置づけです。例として、情報セキュリティの「ムーンショットR&D」の立ち上げ、数百人の参加者を持つバグバウンティを上回る自動化レッドチーム手法の開発、規制の「はしご」に当たる政策提案の公開が挙がっています。

Risk Reportは、デプロイ済みの全モデルにわたるリスクを、能力・脅威モデル・緩和策をつなげて評価する文書です。一部を伏せたうえでオンライン公開され、3〜6か月ごとの更新が予定されています。2026年2月のRisk Reportはv3の下で公表された最初のものです。続く2026年8月のRisk Report(8月14日公開)は、前回から報告の対象日である7月15日までのモデルと活動を扱っています。

2026年2月10日には、RSPの別の運用例も公開されました。RSPは「AI R&D-4」能力閾値を越えたモデルについて、ミスアライメントリスクを特定し緩和策を説明する「affirmative case」の作成を義務付けています。Claude Opus 4.6はこの閾値を越えていないと判定された一方、「確信を持って除外することが次第に難しくなっている」とされました。そこでOpus 4.5の能力を明確に上回る今後のフロンティアモデルについて、外部向けの「Sabotage Risk Report」を作る方針が示され、Opus 4.6版が同日公開されています。これはv3.0の発効前、当時のRSPの下での運用です。

v3.1〜v3.4 — 運用しながらの継続的な微調整

v3.0公開後の改定は中身が分かれます。v3.1は文言の明確化、v3.2はLTBTへの権限の追加、v3.3は化学・生物兵器の閾値の改定、v3.4は閾値の改定と社内共有範囲の見直しです。

あゆみ

v3.1からv3.4までの変更

  1. 2026年4月2日v3.1: AI R&D閾値の読み違いを正す

    「2018年から2024年のAI進歩2年分を1年に圧縮する」という表現が、「AI能力全体の進歩速度が2倍」とも「研究者個人の生産性が2倍」とも読めることに、公開後の指摘で気づきました。前者の意味であると明記し直しています。あわせて、RSPが要求していなくてもいつでも開発を一時停止できる自由を持つことを明記し、Risk Reportへの社内フィードバックの扱いも直しました。

  2. 2026年4月29日v3.2: LTBTに外部レビューの権限

    LTBT(Long-Term Benefit Trust)に、Risk Reportの外部レビューを要求する権限と、外部レビュアーの選定を承認する権限が与えられました。LTBTへの定期報告も義務になっています。

  3. 2026年5月26日v3.3: 化学・生物兵器の閾値を改定

    新規の化学・生物兵器製造に関する能力閾値を、脅威モデルに即した形に改めました。個別モデルのリスクに関するオフサイクル更新の扱いも見直されています。

  4. 2026年7月8日v3.4: 自動化R&D閾値とRisk Reportの運用

    自動化R&Dの閾値を改定し、未編集版Risk Reportの社内共有先を「全通常クリアランス社員」から「少なくとも200人の社員」に変えました。Risk Reportの対象は公表日の30日前までの任意の日を基準にでき、公開版には編集箇所の明示が義務になりました。外部レビューは、複数のレビュアーが異なる未編集部分を分担してもよいとされています。

v3.4の自動化R&D閾値の改定には、具体的な論点があります。AI全体の進歩速度が一定か鈍化していて、AI以前の想定より劇的に速い、という場合に閾値を越えたと見なすかどうかです。見なさない、というのが答えでした。AI要因の加速と非AI要因の減速が相殺し続けるなら、加速より「傾向の継続」を想定する強い論拠がありうるためです。この閾値が捉えたいのは、劇的な再帰的自己改善の始まりであり、運用に落とし込むのは難しかったと書かれています。

社内共有の範囲を狭めた理由も書かれています。リスク評価に重要で、かつ非常に機微な情報には、より強い社内の区画化が必要になりうるからです。会社の成長を踏まえた判断とされ、最小限の編集版は従来どおり全通常クリアランス社員に共有されます。対象日の導入は、直近の変化を急いで分析する必要をなくす狙いです。厳格化と柔軟化が同じバージョンに同居しているのがv3.4の特徴です。

なぜ8回も改定が必要だったのか

RSPは「一度作って終わり」の文書ではなく、運用しながら直し続ける文書になっています。v3.1の発表でも、今後の変更はこのページとポリシー文書内の変更履歴の両方に記録すると述べられています。実際、RSPの公式ページと各PDFの末尾の履歴で、どの版で何が変わったかを遡れます。

改定の間隔は次のように縮まっています。v1.0からv2.0までは約1年1か月、v2.0からv3.0までは1年4か月かかりました。v3.0以降はv3.1(4月2日)・v3.2(4月29日)・v3.3(5月26日)・v3.4(7月8日)と、約1〜2か月おきの改定が続いています。v3.1のように、運用で見つかった文言の曖昧さを直す改定も含まれています。

実務上のポイントは2つです。第一に、Claude Opus 4.6のように「AI R&D-4閾値を越えたか」という判定結果は、Opus 4.5・4.6ではシステムカードに記載されており、モデル選定時の安全性根拠として参照できます(廃止されるモデルの重み保存や退任面談といった別の約束はClaudeモデル廃止でAnthropicが約束する重み保存と退任面談にまとめています)。第二に、Risk Reportは公開文書なので、Anthropicの安全対策の実装状況を継続的に追える一次情報源として使えます。

Anthropicの安全性研究がどう製品に反映されているかは、Anthropicの安全性研究はClaude製品のどこに入っているかで経路別に整理しています。個々のモデルの安全性評価の読み方はClaudeシステムカードの読み方を参照してください。Anthropicという企業自体の概要はAnthropicとはにまとめています。

まとめ

RSPの改定は、v2.0とv3.0で考え方そのものが変わり、その間の版は閾値と範囲の微調整、という二層で読めます。個別の改定を追うときは、変更履歴の文言と、v3以降なら最新のRisk Reportを合わせて見ると、各版が何を直したのかを判断しやすくなります。版間の差分(redline)はAnthropic公式のRSPページでv2.2とv3.1以降について公開されています。

この記事を共有:XはてブLinkedIn