Skip to Content
Docs06. セキュリティフロンティアセーフティの概観

この記事の音声は準備中です。

音声の一覧・再生リストへ

フロンティアセーフティの概観

この記事の目的

最前線モデルの安全枠組み(危険能力評価・責任あるスケーリング)を読み解き、モデル選定・調達時に「提供者の安全体制」を評価軸にできるようになります。通常のアプリ安全との違い・各社フレームワークの共通構造・第三者機関(各国 AISI 系)・実務者への含意を理解し、システムカードや安全方針の何を見るかを判断できる状態を目指します。個別のフレームワーク名・版は変化が速いため、本記事は共通構造と読み方を軸に、確認日付きの具体例を示します。

対象読者

  • モデル選定・調達で、提供者の安全体制を評価軸に加えたいテックリード・アーキテクト
  • 「責任あるスケーリング」「危険能力評価」などの語を目にするが、実務で何を見ればよいか掴みたい人

前提知識

本文

概要: 「アプリの安全」ではなく「能力の安全」

通常のセキュリティは、動いているアプリ・Agent への攻撃を守ります(Agent の脅威モデル概観)。**フロンティアセーフティ(frontier safety)**はそれとは層が違い、最前線モデルの能力そのものが重大被害(サイバー・生物化学・AI の自己改善など)に使われうるリスクを、モデル提供者が管理する枠組みです。

  • 違いは「何を評価するか」: アプリ安全は「このシステムは攻撃に耐えるか」を、フロンティアセーフティは「このモデルの能力は危険な水準に達したか」を評価します
  • 実務者の関わり方: ほとんどの実務者はフレームワークを作る側ではありません。しかしモデルを選ぶ・調達する側として、「提供者がどんな安全体制を持ち、何を公表しているか」を評価軸にできます。本記事はその読み方を扱います

最終確認日: 2026-09-10。 本記事で触れる各社フレームワーク名・版・各国機関の名称は改版・改称のペースが速いです(版番号は数か月単位で動き、機関名も改称された例があります)。以下の更新例は「2026-09-10 時点」のスナップショットとして読み、採用時は各社・各機関の公式ページで必ず再確認してください(後述の「変わりやすい項目」)。

各社フレームワークの共通構造

主要な提供者は、それぞれフロンティア安全のフレームワークを公表しています(2026-07 時点の代表例として、責任あるスケーリング方針・準備フレームワーク・フロンティア安全枠組みなど、呼称は各社で異なります)。名称・粒度は違っても、共通の 4 段構造を持ちます。この構造こそが、実務者が押さえるべき骨格です。

段階内容
①能力閾値の設定重大被害につながりうる能力領域ごとに、危険とみなす「能力水準」を事前定義する
②評価開発・展開の過程で危険能力評価を行い、閾値に達したかを判定する(早期警告を含む)
③対応措置閾値に達したら、能力に応じたセキュリティ強化・展開制限・公開前審査を課す
④公表フレームワークの版管理・モデルごとのカード・リスク報告で説明責任を果たす
  • これは提供者の「自己統治」: この 4 段は、多くが**提供者自身が定め・運用する自己統治(self-governance)**です。外部の強制力は、各国機関の評価連携や規制(コンプライアンスとガバナンス)で補完されます
  • 「安全だ」は自己申告: フレームワークの存在・版・内容は公表された事実ですが、そこに書かれた「安全性の達成度」は**提供者の自己評価(自己申告)**です。鵜呑みにせず、評価軸として使います(後述)

公表文書の版と対象日を分けて読む

方針本文・個別モデルのカード・複数モデルを横断するリスク報告は、それぞれ役割と更新時期が異なります。調達記録では「文書の版・発効日・公表日・評価対象日」を別欄にします。

文書2026-09-10 時点の確認読む際の判断
Anthropic Responsible Scaling Policy(RSP)v3.4、2026-07-08 発効。公式ページ更新日は 8/14自動化 R&D の閾値に加え、リスク報告の共有・墨消し表示・外部レビューの変更を確認
Anthropic August 2026 Risk Report2026-08-14 公表、評価対象日(coverage date)は 7/15公表日までの全モデル・全変更が評価済みと推測しない。自社が採用するモデルと対象範囲を照合
OpenAI Preparedness Framework2025-04-15 更新の枠組み危険能力の閾値と開発・配備時の緩和策を読む基礎
OpenAI Frontier Governance Framework2026-05-28 公表Preparedness の関連部分を California TFAIA や EU の GPAI 実務規範などの制度へ接続する文書。別の役割として確認
OpenAI のサイバー能力に関する方針記事2026-08-18 公表訓練・研究・配備の隔離、監視、アラインメントなどの強化と今後の Preparedness 改定方針。新しい Preparedness 版の発行そのものとは区別

RSP v3.4 は、非墨消し版の社内共有先を少なくとも 200 人とし、公開版には墨消し箇所の表示を求めます。外部レビューは部分ごとに異なるレビュー担当者でもよい一方、非墨消し版の全部分が少なくとも 1 人の外部レビューを受ける扱いです。実務では「外部レビューあり」の一言で済ませず、どの版・対象期間・範囲が誰に評価されたかを確認します。本記事では 186 ページの August Risk Report の全リスク評価結果を精査していません。

危険能力評価の領域(概観)

フレームワークが評価対象とする「危険能力」の領域は、各社でおおむね共通します。本記事は領域の概観に留め、具体的な危険能力の手法(攻撃方法)は一切扱いません。

  • 代表的な領域: サイバーセキュリティ、生物・化学(CBRN)、AI の自己改善 / ML R&D の加速、自律性・操作(ミスアラインメント)など
  • 評価は「これらの能力が、緩和策なしに重大被害を生みうる水準に達したか」を測るもので、能力の閾値判定の手段として位置づけられます
  • 実務者が見るのは「どの領域を・どの段階で評価しているか」という枠組みであって、危険能力そのものではありません

第三者機関と評価エコシステム

提供者の自己統治を補完するのが、**各国の AI 安全機関(AISI 系)**と評価エコシステムです。

日本 AISI は 2026-07-07 公表の評価観点ガイド第 1.20 版で Agent の「観測と制御」、自律的な挙動、外部環境との相互作用を追加しました。7/23 公表の AI ロボティクスの評価観点ガイドも、物理環境へ作用するシステムの参照先です。提供者の能力評価を読むだけでなく、自社 Agent を観測・制御できるかの評価計画へつなげます。これらは認証規格ではありません(AI 規格・認証の実務)。

実務者への含意: 何を評価軸にするか

フロンティアセーフティを、モデル選定・調達の評価軸に落とし込みます。共通構造を、そのままチェック項目に変換できます。

  1. 提供者のフレームワーク現行版: 提供者がフロンティア安全のフレームワークを公表しているか、その現行版は何か
  2. モデルのカードとリスク報告: 当該モデルのシステムカード/モデルカードに加え、Risk Report に危険能力評価・閾値判定・緩和策が記載されているか。公表日と評価対象日を分け、採用モデルが対象に含まれるか
  3. 公表の更新履歴: 透明性・安全のページが更新され続けているか(一度きりでないか)
  4. 第三者評価との連携: 各国 AI 安全機関との評価連携があるか(補助的なシグナル)
  • 複数を突き合わせる: いずれも提供者の自己申告が中心です。1 つの主張を信じるのでなく、フレームワーク・カード・更新履歴・第三者連携を突き合わせて評価軸にします
  • 選定の一要素: フロンティアセーフティは、モデル選定ガイドの判断軸(品質・コスト・レイテンシ等)に加えるもう 1 つの軸です。とくに機微な用途・規制産業では、提供者の安全体制の重みが増します

変わりやすい項目(定点観測)

本記事のうち、次は変化が非常に速く、四半期ごと(および改訂時)の再確認が必要です。

  • 各社フロンティア安全フレームワークの版番号(数か月単位で改訂される)
  • 各国 AI 安全機関の名称・所在・役割(改称・改組がある)
  • 対象とする提供者の顔ぶれ(新たに公表する提供者の追加)
  • 規制側の枠組み(汎用 AI モデルへの義務など)との接続

調査メモ research/trust/frontier-safety.md(2026-09-10 更新)に、この定点観測の詳細と出典を記録しています。

実務での注意点

アンチパターン

  • 提供者の「安全」宣言を鵜呑みにする → 自己申告を検証なしに信頼する → フレームワーク・カード・更新履歴・第三者連携を突き合わせて評価軸にする
  • フレームワークの版番号を固定情報として扱う → 数か月で改訂され陳腐化する → 「最新版を各社公式で確認」を前提に、版は都度確認する
  • AI 安全機関の評価を「認証」と誤解する → 網羅的なお墨付きと誤認する → 機関ごとの焦点を理解し、網羅的認証ではないと踏まえる
  • フロンティアセーフティを選定軸に入れない → 機微用途で提供者の安全体制を見落とす → 品質・コスト等に加え、安全体制を選定軸にする
  • 危険能力の具体を追う → 本来見るべき「枠組み・公表・評価連携」から逸れる → 領域の概観と公表の有無を見る

チェックリスト

  • フロンティアセーフティ(能力の安全)と、自社システムのアプリ安全を区別している
  • 提供者がフロンティア安全のフレームワークを公表し、その現行版を確認した
  • 当該モデルのシステムカード/モデルカードで、危険能力評価・緩和策を確認した
  • 透明性・安全ページの更新が継続しているかを見た
  • 各国 AI 安全機関との評価連携を補助シグナルとして確認した
  • これらを「自己申告」と理解し、複数を突き合わせて評価軸にした
  • 版番号・機関名は変わる前提で、都度公式を確認している

関連トピック

参考資料

TODO・未確認事項