フロンティアAIとは何か — 「最先端モデル」の定義と、社会はどう向き合おうとしているのか

1. 「フロンティアAI」とは何か — 定義の輪郭をつかむ

1-1. 厳密な単一定義は存在しない

「フロンティアAI（Frontier AI）」という言葉は、ここ数年のAI政策・研究コミュニティで急速に定着した用語である。ただし、法律や条約のように厳密に統一された単一の定義があるわけではない。おおむね「現時点で最も高性能で、既存のどのモデルよりも広範なタスクをこなせる、最先端の汎用AIモデル」を指す言葉として、政策文書・研究論文・各社の安全性方針のいずれでも共通して使われている。

GPT系列、Claude系列、Gemini系列といった、数千億〜数兆パラメータ級で訓練された大規模モデルがこれに該当するとされることが多い。ただし「何パラメータ以上ならフロンティアか」という明確な数値基準があるわけではなく、後述するように、各機関・各社が独自の閾値や判断基準を設けているのが実情である。

1-2. 「能力」と「規模」という2つの軸

フロンティアAIを語るとき、しばしば混同されがちなのが「モデルの規模（パラメータ数や訓練計算量）」と「モデルの能力（実際に何ができるか）」という2つの軸である。規模が大きいこと自体が問題なのではなく、規模の拡大に伴って**訓練時には想定していなかった能力が突然現れる（創発的能力・emergent capabilities）**ことがある、という点が政策上の焦点になっている。

高度な推論、複数ステップにわたる自律的な計画立案、ツールを使いこなすエージェント的な振る舞いなどは、モデルの規模がある水準を超えたあたりから急激に精度が向上する傾向が、複数の研究で報告されてきた。これが「フロンティア」という言葉に込められた、単なる「大きい」以上の含意である。

1-3. 具体的にどのモデルを指すのか

実務的には、フロンティアAIという呼称は、主要なAI開発企業が公開している最新・最上位クラスのモデル（いわゆるフラッグシップモデル）を指して使われることが多い。ただし、この呼称は開発企業自身による自己申告的な性格も強く、「自社の最新モデルはフロンティアレベルの安全対策の対象である」と表明することが、後述する自主的な安全性フレームワークの適用対象を宣言する意味合いを持つ場合もある。

1-4. 具体例で見る「未知のバグを見つける」という実力

抽象的な話が続いたので、具体例を挙げたい。近年、複数のAI開発企業が独立に、フロンティアAIが実世界のソフトウェアに潜む未知の脆弱性を発見した事例を報告している。特定の1社の実績ではなく、業界全体で同時多発的に起きている現象だという点が重要だ。

発見主体	使用モデル	発見された脆弱性	特徴
Google Project Zero / DeepMind（「Big Sleep」エージェント）	独自のLLMエージェント基盤	データベースエンジン「SQLite」のスタックバッファアンダーフロー脆弱性	2024年10月に発見・報告され、正式リリースに混入する前に同日中に修正された。広く使われる実運用ソフトウェアでAIエージェントが未知のメモリ安全性の欠陥を発見した、初の公開事例とされる
セキュリティ研究者Sean Heelan氏（独立系）	OpenAIの「o3」モデル	LinuxカーネルのSMB3実装（ksmbdモジュール）におけるuse-after-free脆弱性（CVE-2025-37899）	約1万2,000行に及ぶ並行処理を含む複雑なコードを解析させるベンチマークの一環として発見。2025年5月に公式へ確認された、世界中のサーバーで稼働するLinuxカーネルという大規模ソフトウェアでの発見事例

いずれの事例も、モデルに大量のコードを読み込ませ、人間の専門家が長年見落としてきたような、条件が重なったときにだけ顕在化する種類の欠陥を発見させている。共通しているのは、こうした発見が単発の実験結果ではなく、異なる企業・異なるモデルが独立に、同種の実世界の脆弱性発見という成果を出し始めているという点だ。

この事例が示すのは、フロンティアAIの能力が「ベンチマークの数字が良い」という抽象的な話にとどまらず、実際に専門家の目をすり抜けてきた現実のバグを発見できる水準に達しているという具体的な事実である。同時に、この能力が善用（脆弱性の早期発見によるセキュリティ向上）にも悪用（攻撃者による脆弱性の探索の自動化）にも使えることは、次章で述べる「二重利用性」の分かりやすい実例でもある。

1-5. 実際にはどうやっているのか — 手法と成功率

ここまでの話だけを聞くと、「対象のソースコードを渡して『脆弱性を探して』と一度聞けば見つかる」ものだと誤解されがちだが、実態はまったく異なる。Heelan氏が自身のブログで公開している手法の詳細を見ると、実際には周到な設計が必要であることが分かる。

• 脆弱性のクラスを絞り込む: 「バグ全般を探して」という曖昧な指示ではなく、システムプロンプトの段階で「use-after-free（解放済みメモリの使用）」という特定の脆弱性クラスに狙いを絞って指示している
• コンテキストを事前に与える: 対象モジュール（Linuxカーネルのksmbd／SMB3実装）のアーキテクチャ概要や脅威モデルを、コード本体を読ませる前に説明している
• 誤検知の抑制を明示的に指示する: 確信が持てない指摘は報告しないよう、プロンプト内で強く釘を刺している
• 一度で終わらせず、大量に試行する: 既知の脆弱性を再発見できるかを試すベンチマークでは、同一プロンプトを100回試行している。対象コードが比較的狭い範囲（約3,300行）のときはo3が8%の確率、対象を広げた全ハンドラー（約1万2,000行）では1%の確率でしか、目当ての脆弱性を発見できなかったと報告されている
• 最終的には人間の選別が必須になる: 実際に新規発見となったCVE-2025-37899は、AIが「新種の脆弱性です」と単独で報告したものではない。100回分の出力を著者が見比べる中で、「これは既知のものと似ているが、実は別の新しいバグではないか」と気づいたことで発見に至っている

Googleの「Big Sleep」の場合も、チャット形式で一問一答するのではなく、コードブラウザ・デバッガ・実行サンドボックスを備えたエージェントとして、「仮説を立てる → 実際にコードを実行し、デバッガで検証する → 結果を見て次の仮説を立てる」というサイクルを何段階も繰り返し、ようやく1件のクラッシュ再現にたどり着いている。

つまり、フロンティアAIによる脆弱性発見は、①特定の脆弱性クラスに絞り込んだ専門的なプロンプト設計、②数十〜百回規模の試行を前提とした低い成功率、③ツールを使って実際にコードを実行・検証するエージェント的な繰り返し処理、④最終的な人間による選別、という複数の要素が揃って初めて成立している。「AIに聞けば見つかる」という単純な話ではなく、探索対象を絞り込み、大量に試行し、結果を人間が評価するという、地道なエンジニアリングプロセスの延長線上にある、という理解が実態に近い。

2. なぜ「フロンティア」という特別な区分が必要になったのか

2-1. 出現する能力という予測困難性

AI政策の議論では、すべてのAIモデルを同じ規制の枠組みで扱うことは非効率であり、時に的外れだという認識が広がっている。画像分類器のような特定タスク向けの小規模モデルと、あらゆる自然言語タスク・コード生成・エージェント的な自律行動までこなす最大級のモデルとでは、想定すべきリスクの種類も規模もまったく異なるからだ。

特に問題視されているのが、モデルの能力を事前に完全には予測できないという性質である。訓練が完了し、実際にベンチマークや評価を行って初めて、そのモデルがどの程度の能力を獲得したかが判明する。これは、リリース前に安全性を保証することの難しさに直結する。

2-2. 二重利用（デュアルユース）性

フロンティアAIの能力の多くは、良い用途にも悪い用途にも使える「二重利用（dual-use）」の性質を持つ。先述したBig SleepやCVE-2025-37899の事例が好例だ。同じ「未知のバグを見つけ出す能力」は、開発元に先んじて脆弱性を報告し修正を促す善意の研究にも使えれば、パッチが当たる前に攻撃者が悪用するゼロデイ攻撃の探索にも使える。実際、2025年11月にAnthropicが公表した事例では、攻撃者がAIエージェントを悪用し、偵察からエクスプロイト開発、侵入までの一連の攻撃工程の8〜9割を自律的に実行させていたことが報告されている（本誌「AIはどのようにサイバー攻撃を行うのか」を参照）。同じ技術的能力が、公表のわずか数か月の間に、防御にも攻撃にも実例を伴って現れたことになる。

2-3. 評価とレッドチーミングの難しさ

こうしたリスクに対応するため、主要な開発企業は、モデルを一般公開する前に、専門チームによる敵対的なテスト（レッドチーミング）や、外部の安全性評価機関との連携を行うようになっている。しかし、モデルが持ちうる危険な能力のすべてを事前に洗い出すことは原理的に難しく、評価手法そのものも発展途上の分野である。この「評価の不確実性」こそが、フロンティアAIをめぐる議論の根底に常にある課題だといえる。

3. 開発企業が自主的に設けている安全性フレームワーク

各社は法規制の整備を待つのではなく、自主的な安全性方針を公表し、モデルの危険な能力レベルに応じて訓練・公開の可否を判断する仕組みを整えつつある。

3-1. Anthropicの「責任あるスケーリングポリシー（RSP）」

Anthropicは、モデルの能力を「AIセーフティレベル（ASL）」としてASL-1からASL-4までの段階に分類し、各レベルに応じて求められる安全対策を定める「責任あるスケーリングポリシー（Responsible Scaling Policy、RSP）」を運用している。あるモデルが必要な安全対策の整備前に次のASLレベルの能力に到達したと判断された場合、開発または展開を一時停止するという枠組みになっている。このポリシーは固定されたものではなく、継続的に改訂されており、2026年7月時点でバージョン3.4まで更新されていると報告されている。

このフレームワークが実際に発動した最初の例が、2025年5月に公開された「Claude Opus 4」だ。Anthropicは同モデルについて、化学・生物・放射性物質・核（CBRN）兵器の開発転用リスクを明確に排除できないと判断し、モデルの重みを盗み出されにくくする強化されたセキュリティ対策と、関連する用途を限定的に制限する配備対策からなる「ASL-3」の保護措置を、予防的な措置として初めて適用したと公表している。これは、フレームワーク上の抽象的な段階分けが、実際のモデル公開判断に反映された具体的な事例である。

3-2. OpenAIの「Preparedness Framework」とGoogle DeepMindの「Frontier Safety Framework」

OpenAIも同様に、サイバーセキュリティ、生物・化学兵器転用リスク、自律性など、複数のリスク領域ごとにモデルの能力レベルを評価し、一定の閾値を超えた場合に追加の安全対策を要求する「Preparedness Framework」を公表している。Google DeepMindも「Frontier Safety Framework」という名称で同種の枠組みを整備しており、2026年4月にはバージョン3.1への更新が報告されている。

3-3. 自主的フレームワークの共通点と限界

これらのフレームワークに共通するのは、「能力の閾値」と「その閾値を超えた際に求められる安全対策」をあらかじめ定義しておく、という設計思想である。一方で、これらはあくまで各社の自主的な取り組みであり、外部から強制力を持って遵守を確認する仕組みは限定的だという指摘も根強い。閾値の設定方法や運用の透明性についても、企業ごとにばらつきがあるのが実情である。

4. 各国・国際社会の規制・ガバナンスの動き

自主的なフレームワークだけでなく、法規制によってフロンティアAIを対象化する動きも各国で進んでいる。

4-1. EUのAI法と汎用AI向け実践規範

EUでは、AI法（AI Act）を補完する形で「汎用AIのための実践規範（Code of Practice for General-Purpose AI）」が整備されており、OpenAI・Anthropic・Google・xAIなど主要なフロンティアAI開発企業を対象に、モデル評価、安全・セキュリティ上の緩和策、社内ガバナンス、インシデント追跡といった要件が課される。この規範に基づく本格的な運用は、2026年8月から始まるとされている。

4-2. アメリカ：連邦レベルの動きと州法の先行

アメリカでは連邦レベルでの包括的なAI規制の整備が流動的な状況にある一方、州レベルでの立法が先行している。カリフォルニア州の「Transparency in Frontier Artificial Intelligence Act（TFAIA）」、ニューヨーク州の「Responsible AI Safety and Education（RAISE）Act」、イリノイ州の「Frontier AI Safety Act」などが、大規模な計算資源を用いてフロンティアAIを開発する企業に対し、破局的リスクを管理するための枠組みの整備を義務づける内容になっている。

4-3. 国際的なAIサミットの系譜

フロンティアAIの安全性をめぐる国際的な議論は、2023年の英国ブレッチリー・パークでの「AI Safety Summit」を起点に、2024年の韓国・ソウルサミット、2025年のフランス・パリでの「AI Action Summit」、そして2026年2月にインド・ニューデリーで開催された「India AI Impact Summit」へと続いている。各国の首脳、主要AI企業、研究者、市民社会の代表が一堂に会し、評価枠組みや安全性に関するコミットメントについて議論する場として定着しつつある。

4-4. 国際科学者による独立評価「International AI Safety Report」

こうした政府間協議とは別に、Yoshua Bengio氏を中心に30か国以上・100名を超える専門家が参加してまとめられた「International AI Safety Report 2026」が、フロンティアAIの能力とリスクに関する独立した科学的評価として公表されている。同報告書は、悪用リスク、自律的なAIの誤作動、社会システムへの波及的影響といった論点を、特定の企業や政府の立場から独立した視点で整理している点に特徴がある。

5. フロンティアAIとどう向き合うべきか — 実務者への示唆

5-1. 「自社が扱うモデルはフロンティアか」を問う意味

エンジニアやアーキテクトの立場からは、自社が採用しているモデルがフロンティアAIの区分に該当するかどうかにかかわらず、この区分をめぐる議論の背後にある問題意識——「能力の向上が予測困難な形で進むこと」「二重利用性への配慮が必要なこと」「評価とガバナンスの仕組みが能力に追いついていないこと」——は、規模の大小を問わず参考になる視点である。

5-2. ガバナンスの仕組みを性能に見合った形で設計する

フロンティアAIをめぐる規制・自主フレームワークの多くが採用しているのは、「能力の水準に応じて、求められる安全対策のレベルを引き上げる」という段階的な設計思想である。これは、本誌が繰り返し取り上げているAIQDD（AI Quality-Driven Development）の考え方——仕様・実装・検証・監査ログを一体的に設計し、AIの自律性の水準に見合ったガバナンスを組み込む——とも多くを共有している。

5-3. まとめ

フロンティアAIという区分は、単なる性能競争の指標ではなく、「性能が一定の閾値を超えたときに、開発・運用のプロセスがどう変わるべきか」という設計思想の問題である。各社の自主的フレームワークと各国の法規制は、アプローチこそ異なるものの、いずれも「能力の拡大に、監督の仕組みを追いつかせる」という共通の目標に向かって、2026年時点でも急速に整備が進んでいる領域だといえる。