土曜日, 9月 19, 2026

「193.6倍高速」をどう読むか ― TypeSafe Jevの公称値と実像

テキストを一切生成しないAIモデル、と言われたら何を思い浮かべるでしょうか。2026年9月15日、サンフランシスコのスタートアップ TypeSafe AI がステルスを脱して公開した「Jev(ジェヴ)」は、まさにそういうモデルです。自由文も、コードも、思考過程の説明も返しません。返すのは「この問い合わせは二重請求カテゴリである確率0.94」といった、型の付いた判断と確率だけです。

公開直後から日本の技術コミュニティでも一気に話題になりました。「既存のLLMがCPUなら、JevはそのGPU版」という評価がある一方で、「それ、既存LLMのlogitを読めば同じことができませんか?」という冷静な検証も同時に出てきています。TypeSafe自身は「最大193.6倍高速・444.6倍安価」と謳っていますが、この数字がどこまで一般化できるのかは、発表資料を読むだけでは判断できません。

先に結論を書きます。Jevは「回答候補が事前に定義できる判断」を高速・低コストで大量に回す用途には十分な実用性があります。ただし公称性能値はベンダー自己評価であり、参照値すら客観的な正解ラベルではありません。基幹の不可逆な意思決定をJev単独に委ねるのは時期尚早で、誤りを検出・救済できる判断層から、自前の評価データを用意して始めるのが妥当です。以下、その根拠を順に見ていきます。

本記事は2026年9月19日時点の公開情報にもとづきます。Jevは早期アクセス段階にあり、仕様・料金・レート上限・モデルバージョンはいずれも流動的です。また、性能に関する数値の多くはTypeSafe自身の評価であり、独立した再現検証は現時点で限定的です。本文中、事実として確認できた事項と、筆者の評価・推奨は区別して記述しています。

1. Jevとは何か

Jevは TypeSafe AI の旗艦モデルであり、同社が「System One Model」と呼ぶ新カテゴリの最初の公開モデルです。公式サイトは Jev の役割を unstructured state in, typed probabilistic decisions out(非構造の状態を入力し、型付きの確率的判断を出力する)と表現しています。入力として状況説明(state)と型付きの質問を受け取り、質問のスキーマが定める範囲の値と確率を返す。それだけです。

名称の由来は公式FAQとプレスリリースで説明されています。System One はダニエル・カーネマンが広めた「速い直感的思考(システム1)」に、Jev は「効率の改善がかえって総需要を増やす」というジェヴォンズのパラドックスで知られる経済学者 William Stanley Jevons に由来します。知能が安くなれば、これまで使う気にならなかった場所にまで知能が入り込む、という含意でしょう。

開発元の TypeSafe AI は2024年創業、サンフランシスコ本拠のAIラボです。2026年9月15日に DCVC 主導で約4,000万ドルのシード調達を公表しました。共同創業者は Diogo Almeida(CEO)、Erik Gafni(CTO)、Sasha Sheng(COO)で、Almeida は元OpenAIの研究者であり InstructGPT 論文やRLHF系の研究に貢献した人物です。プレスリリースでは「ChatGPTの共同発明者」と紹介されていますが、これは企業広報の表現であり、実態としては上記の理解が中立でしょう。

設計思想として TypeSafe が掲げるのは、「LLMは人間が読むテキストを生成するよう最適化されており、コードが判断を消費する用途にはミスマッチがある」という問題意識です。従来はLLMに構造化出力を無理やり吐かせ、パースし、検証し、それでも型エラーやリクエスト間のブレのリスクが残りました。Jevはその判断部分だけを切り出し、出力空間をスキーマで閉じてしまおうという発想です。公式ドキュメントは、大規模な自動化では機械対機械のやり取りが大半を占め、人間との対話はその一部にすぎない、という想定を置いています。

2. 3つのプリミティブと並列評価

Jevが答えられる質問は3種類だけです。この割り切りが設計の核心にあたります。

プリミティブ 返すもの confidence 主な用途
Choice 定義済み選択肢から選ばれた1つと、全選択肢にわたる確率分布 あり 問い合わせ分類、ルーティング、カテゴリ判定。選択肢は最大255
Score 順序付きルーブリック上の確率加重位置と、レベル別の分布 あり 品質採点、優先度付け、リランキング
Noul yes/no命題が真である確率(0〜1)のみ なし(確率そのものが答えのため) 条件判定、ガードレール、フラグ立て

実際のリクエストは、1つの state に対して複数の質問をまとめて投げる形になります。

{
  "model": "jev-latest",
  "state": "先ほどの注文が二重に請求されています。返金してください。先週も問い合わせましたが返事がありません。",
  "questions": {
    "category": { "type": "choice", "options": ["二重請求", "配送", "その他"] },
    "refund_requested": { "type": "noul", "statement": "顧客は返金を要求している" },
    "is_followup": { "type": "noul", "statement": "これは再問い合わせである" }
  }
}

この3つの質問は、1回のAPI呼び出しの中で並列かつ互いに独立に評価されます。質問を増やしてもレイテンシの増加は小さく、追加されるのは安価な入力トークン分だけです。質問同士が文脈を汚し合わないので、「カテゴリ判定の結果に引きずられて返金要求の判定が歪む」といった現象は起きません。

ただし、ここは誤解しやすいところです。質問の追加による文脈汚染(context rot)が起きないことと、state そのものが長くなっても劣化しないことは別の話です。公式のモデル特性文書(jaggedness)は、無関係な情報を多く含む大きな state は精度を落とすと明記しています。state は絞り込む必要があります。

推奨される使い方は、大きな問いを原子的な質問に分解し、合成はコード側で行う、というものです。「このスタートアップのピッチを評価して」と丸投げするのではなく、市場規模・技術的実現性・差別化をそれぞれ独立した質問にし、重み付けはプログラムで明示的に書く。判断ロジックがブラックボックスの中ではなくコードの中にあるので、レビューもテストも効きます。

3. 価格・制限・提供チャネル

公式の料金は入力10億トークンあたり42ドル、すなわち100万トークンあたり0.042ドルで、出力は無料です。出力が型に閉じているので課金対象にする意味がない、という設計です。逆に言えば、課金は完全に入力トークン依存であり、「1判断いくら」という固定単価は存在しません。1判断あたりのコストを見積もるなら、自分の state の長さで計算する必要があります。

現行モデルは jev-1.13.0 で、jev-latestjev-preview は現在ともにこれを指します。エイリアスは更新時に挙動が変わり得るため、confidence の閾値をチューニングした本番システムではバージョンを固定し、レスポンスの model フィールドを記録しておくことが公式にも推奨されています。

項目 内容
入力形式 テキストのみ(文字列 / JSONオブジェクト / テキスト配列)。画像・音声・動画は非対応
コンテキスト長 リクエスト全体で64kトークン、state+最長の質問の組み合わせで32kトークン
レート上限 250,000 tokens/秒、1,200 requests/分(早期アクセス段階のため変動しうる)
Choiceの選択肢上限 255。超える場合はScoreで絞ってからChoiceで確定する二段構成を利用者側で組む
言語 英語が主要訓練言語で最も精度が高い。日本語を含むCJKは処理可能だが同等ではなく、自前評価が必要と公式が明記
提供形態 ホスト型APIのみ(重み非公開)。早期アクセスのwaitlist制

利用チャネルは公式HTTP API(POST https://api.typesafe.ai/v1/systemone)に加え、Python / JavaScript の公式SDK、Vercel AI Gateway、Cloudflare Workers AI、OpenRouter などのゲートウェイ経由があります。ただし各ゲートウェイで課金体系や表示される機能名に差があるため、TypeSafe直販APIの価格・上限をそのまま適用できると考えない方が安全です。

なお、GitHubの typesafe-ai/system-one-adapter-python を「Jevの公式SDK」と紹介している記事が散見されますが、これは誤りです。Adapterは OpenAI や Anthropic のLLMを TypeSafe 互換インターフェースに載せて比較するためのOSSであり、Jevを呼ぶためのものでも、Jevをローカルで動かすためのものでもありません。Jevの重みや学習実装は含まれていません。

4. 公称値をどう読むか

ここが本記事でもっとも注意して書きたい部分です。

TypeSafe は自社の workflow evals において「最大193.6倍高速、444.6倍安価」と報告しています。ただし同社自身が、これは現実世界で得られるゲインの上限側の結果だと公式ブログで注記しています。さらに重要なのは、この評価の作り方です。ワークフローは同社の model capabilities team が作成したもので、正解ラベルは用意されていません。参照値として使われているのは GPT-6 Astra と Claude Fable 5.1 の予測の平均です。

つまり、このベンチマークが測っているのは客観的な正解率ではなく、「特定の計算グラフの上で、2つのフロンティアモデルの平均とどれだけ近い答えを出すか」という一致度です。TypeSafe 自身もブログで、この参照解答の取り方が OpenAI・Anthropic のモデルに有利なバイアスをかけると認めています。

したがって、この eval で報告されている集約値(Jev 約67.8%、最良の比較対象 約74.1%)を「精度」と呼ぶのは不正確です。参照モデル平均との一致度として読むべきものであり、一般的な分類精度や、まして一般知能の指標として外挿することはできません。請求書処理のワークフローでは差が大きく開いており、タスク依存性もはっきりしています。

公称された主張 正確な読み方
最大193.6倍高速・444.6倍安価 TypeSafe自社evalにおける最大値。同社自身が現実的ゲインの上限側と注記している
集約スコア67.8% 正解率ではなく、GPT-6 AstraとFable 5.1の予測平均を参照値とした一致度
ハルシネーションが起きない スキーマ適合性の保証に限定される。出力空間外の生成や型違反は設計上防げるが、候補内での意味的な誤判定は防げない
較正された確率を返す 較正は予測群についての統計的性質であり、個々の回答の正しさを保証しない、と公式も明記
LLMではない 外部インターフェースと推論目的が生成LLMと異なる、という製品分類。内部アーキテクチャは非公開のため、言語モデル的な要素を一切使わないとまでは確認できない

訓練手法として TypeSafe が名前を出しているのは RLCD(Reinforcement Learning for Calibrated Decisions)で、RLHF(人間の好み)やRLVR(検証可能報酬)に対して「較正された判断」を最適化目標に置く、と説明されています。ただし報酬関数の設計、較正手法の詳細、較正曲線はいずれも非公開です。アーキテクチャについても「新規アーキテクチャ」「parallel sampler」「全確率を並列に出力」までは公開されていますが、内部の層反復や sampling 回数は開示されていません。したがって「1回のforward passで完結する」という説明は踏み込みすぎで、「自己回帰的にトークン列を生成せず、単一リクエストで複数の型付き判断を並列に返す」と書くのが正確です。

訓練データについては、TechCrunch が Almeida の説明として合成データのみを用いたと報じています。公式サイトやドキュメントの範囲では、査読論文・技術論文は確認できませんでした。

5. 第三者検証で見えたこと

公開から日が浅いため、独立した検証はいずれも小規模です。それでも、速度とコストの優位については複数の独立した観測が一致しています。

検証 規模 主な結果 留意点
Every(米メディア) 37文書 × 21問=777判定 0.7秒未満、約0.0025ドルで完了。別途12文書の欠陥検出比較では、Jevが6/7検出に対しFable 5.1が7/7、速度は約25倍と報告 公式ベンチの再現試験ではなく、別用途のハンズオン。タスク条件とコスト算定を公開本文から完全には再構成できない
lindfors.no(ノルウェー語) 24文書 × 各11問 中央値0.32秒、1,000文書換算0.22ドル。Choiceのトップ確率0.9以上では stance 14/15、respondent 20/20 が参照ラベルと一致 著者自身が「benchmarkではなくfirst look」と明記。基準ラベルはFable 5.1生成のため、正解率ではなくモデル間一致
Near Here(英国) 実出品50件のモデレーション判定 Jev 96%に対しMistral Small 4が84%、Gemini 3.5 Flash-Liteが86%。平均0.59秒/判定、1,000件あたり0.043ドル サンプル数50件と小さく、単一サービスのドメイン特化タスク

これらを「公式の193.6倍/444.6倍を独立に追認した」と表現するのは不適切です。いずれも別のタスクで、別の条件下で、低レイテンシと低コストを観測した、というのが正しい整理です。一方で、精度については「フロンティアモデルにやや劣るが実用範囲」という傾向が共通して見えており、これはTypeSafe自身のeval結果とも矛盾しません。

lindfors.no の検証で興味深いのは、質問文の書き方で較正が悪化したという報告です。同じタスクで、短いdraft wordingを長いcareful wordingに変更したところ、ECE(期待較正誤差)が0.040から0.116に悪化しました。これは「質問文一般に敏感」という広い証明ではなく一例ですが、プロンプトエンジニアリング的な感度がJevにも存在することは示しています。

6. 較正はどこで崩れるか

Jevの売りは「較正された確率」です。85%と言ったら実際に85%正しい、という性質が成立していれば、confidence を閾値にした自動化・エスカレーション設計が可能になります。では、その較正はどこまで信頼できるのか。

公開されている反例として、サイコロの実験があります。隠されたサイコロの出目をChoiceで400回尋ねたところ、Jevは400件すべてで「1」を選び、平均約83%の確信度を付けました。真の確率は1/6です。同じ問いをNoulで尋ねると約19%となり、1/6(約16.7%)にかなり近い値が返りました。実験者本人がコードとデータを公開したうえで報告しています。

ただしこれは、「観測情報がまったくない対称な問題について、事前確率を答えられるか」という分布外・認識的不確実性の試験です。業務文書の分類における較正が一般に失敗することを直接証明するものではありません。適切な理解は、RLCDによる較正は万能ではなく、プリミティブの選び方や情報の欠如した対称問題では大きく崩れる反例が存在する、というものでしょう。

実務への含意は明確です。Choiceのトップ確率をそのまま「正しさの確率」として読んではいけません。自分の用途のデータで reliability diagram、ECE、Brier score、coverage-risk 曲線を測り、そのうえで閾値を決める。accuracy だけを見て calibration を見ないと、confidence ゲーティングの設計自体が砂上の楼閣になります。

7. 「それ、既存LLMでできませんか?」

日本の技術コミュニティで最も鋭かった反応がこれです。回答候補をそれぞれ単一のトークンIDに割り当て、最初のトークンのlogitsを読み出す。あとはバッチ推論とKVキャッシュの再利用を組み合わせれば、既存のLLMでもJevに近い高速な限定選択が実装できるのではないか、という指摘です。

この批判は技術的に妥当です。Zennでは Gemma 3 270M を用いた自作実装でJSON生成比77倍の高速化が報告され、海外でも Sean Goedecke が、1トークン制約とバッチングによって速度・一貫性・並列性の多くは再現できると論じています。実際、オープンモデルのlogitを直接読む模倣実装が公開数日でGitHubトレンド入りしました。

ただし、これがJevの性能全体を再現した証拠ではない点も押さえておく必要があります。TypeSafe の差別化仮説は、専用訓練、確率較正、APIとしての一貫した型、並列推論基盤、そして低価格での運用を一体化した点にあります。個々の要素は模倣可能でも、束ねて安定運用するのは別の話です。とはいえ、公開情報だけでは技術的moatの強弱を確定できないのも事実で、大手が同等機能を提供してきた場合にどうなるかは未知数です。

現時点で言えるのは、「Jevでしかできないこと」があるというより、「Jevだと考えなくていいことが増える」という性質の優位だろう、ということです。既存LLMがCPUでJevがGPUだという比喩は、この感覚をよく捉えています。汎用性を捨てて特定の形の計算に特化し、その代わり桁で速い。

8. 導入をどう判断するか

ここからは筆者の評価です。事実認定ではなくリスク判断として読んでください。

早期アクセス段階であること、レート上限が動的であること、モデルが更新されうること、非英語での性能差があること、公開されている技術情報が少ないこと。これらを踏まえると、基幹的で高リスクで不可逆な判断をJev単独に委ねるのは時期尚早です。一方で、「Jevは本番投入すべきでない」という一般命題は強すぎます。

誤りを検出・救済できる判断層であれば、shadow mode や限定トラフィックでの本番導入は合理的です。具体的には以下のような領域が該当します。

  • 問い合わせの分類とルーティング(誤分類は後段で人が拾える)
  • LLM出力の検証・スコアリング(判定そのものが補助信号)
  • ガードレールの一次フィルタ(危険コマンド、不適切コンテンツの検出)
  • RAGのリランキングや候補絞り込み(最終判断は別途)
  • 既存LLM呼び出しのうち、実質的に分類しかしていない箇所の置き換え

導入時の設計原則としては、confidence を行動可否の第二軸に置くこと。公式も confidence-gated routing のパターンを示しています。ただし「0.9以上なら自動、0.4未満ならフォールバック」といった閾値は普遍的な値ではありません。誤判定のコスト行列、偽陽性と偽陰性の非対称性、クラス別の較正、カバレッジ目標から決めるべきもので、記事や文書に出てくる数値はあくまで例示です。

日本語環境で使うなら、自前のベンチマークは必須です。英語前提で訓練されたモデルである以上、日本語での confidence 分布やECEが英語と同じである保証はありません。LLMに英訳させてから渡すという回避策もありますが、それでは速度とコストの優位が消えてしまうので、まず日本語のまま評価するのが筋でしょう。なお、サービスが米国西海岸で提供されている点は公式ブログから読み取れますが、リージョン一覧や日本からの具体的な追加レイテンシについて公式の保証は確認できていません。国内から使う際のネットワーク遅延は、自分の環境で実測してください。

判断を切り替えるべきタイミングとしては、次のあたりが目安になります。第三者の中立なハーネスで精度パリティが再現されること。較正が難易度や敵対的入力に対しても崩れないことが示されること。日本語で confidence 0.9以上の正答率が自社の運用要件を満たすこと。そして料金体系が維持されること。現状の価格が補助金的なものである可能性は、TypeSafe自身も否定していません。

まとめ

Jevは、AIに「考えさせる」のではなく「判定させる」ためのモデルです。出力空間をスキーマで閉じ、確率を較正し、並列に返す。この割り切りによって、これまでコストとレイテンシの制約でAIを入れられなかった場所に判断を差し込めるようになりました。LayerXが社内勉強会で得た気づきとして「既存のLLM呼び出しを置き換えるだけでなく、これまでAIを使うと考えなかった場所に差し込む」発想の転換を挙げているのは、この性質を的確に言い当てています。

一方で、公開されている性能値の多くはベンダー自己評価であり、参照値すら客観的な正解ラベルではありません。「ハルシネーションゼロ」はスキーマ適合性の話であって意味的な正しさの話ではなく、「較正されている」は予測群の統計的性質であって個々の回答の保証ではない。この区別を曖昧にしたまま設計すると、静かに間違い続けるシステムができあがります。

技術としては面白く、実用的価値もある。ただし、ベンダーの宣伝値と、第三者の小規模試用と、客観的に検証された事実は、それぞれ別のものとして扱う必要があります。低リスクな判断層から、自前の評価データで calibration まで測りながら始める。当面はそれが現実的な向き合い方だと考えます。

参考資料

木曜日, 9月 17, 2026

AIはミレニアム懸賞問題を解いたのか ― ナビエ–ストークス「解決」発表の実像

数学には「解けたら100万ドル」という問題が7つあります。クレイ数学研究所(CMI)が2000年に掲げた「ミレニアム懸賞問題」です。四半世紀のあいだに正式に解決されたのはポアンカレ予想ただ1つで、残る6問は数学の最難関として手つかずに近い状態が続いてきました。

ところが2026年9月、OpenAIが「AIがナビエ–ストークス方程式の問題を解いた」と発表し、同じ朝にNYUの数学者とAnthropicの研究者が近い結果を公表したことで、帰属をめぐる論争まで起きました。AIが数学オリンピックで金メダル相当に届いたのが2025年夏ですから、わずか1年余りで「懸賞問題」の土俵に上がってきたことになります。これは本当に「AIが数学の最難関を解いた」瞬間なのでしょうか。

先に結論を書くと、AIが数学研究の現場を大きく変えつつあるのは確かですが、「ミレニアム問題が解かれた」と言い切れる段階ではありません。OpenAIの主張は4つある選択肢のうち「外力あり」の2つに関するもので、CMIは状態を「active」に変更したものの、賞の授与も独立検証もまだです。本記事では、ミレニアム問題の基本から、AIと数学の最新動向、そして「解決」ニュースの読み方までを整理します。

本記事は2026年9月17日時点の情報に基づきます。ナビエ–ストークス問題の検証は進行中であり、今後のCMIの判断や査読の結果によって評価が変わる可能性があります。また、後半の見通しに関する記述は筆者の見解であり、精密な予測ではありません。

1. ミレニアム懸賞問題とは

CMIは2000年5月24日、パリのコレージュ・ド・フランスで開いた会合で7つの問題を発表しました。基金は総額700万ドル、1問あたりの賞金は100万ドルです。1900年にダフィット・ヒルベルトが同じパリの国際数学者会議で提示した「23の問題」を意識した企画で、リーマン予想は両方のリストに入っています。

受賞の手続きは意図的に慎重に作られています。解答をCMIに直接送ることはできず、まず評価の確立した査読付き数学誌に掲載され、さらに掲載後2年間を経て数学界で一般に受け入れられる必要があります。その後にCMIの科学諮問委員会が検討に入ります。反例による否定的解決の場合も同様の待機期間が設けられています。「証明が出た」ことと「賞が授与される」ことの間には、少なくとも数年の距離があるわけです。

2. 7つの問題の中身

7問は分野もばらばらです。専門的な定式化は省き、何を問うているのかを一言でまとめると次のようになります。

問題 分野 何を問うているか 2026年9月時点の状況
P対NP問題 計算機科学 答えを速く「検証」できる問題は、速く「解く」こともできるのか 未解決。P≠NPと考える研究者が多数派
ホッジ予想 代数幾何 複雑な図形の位相的な特徴の一部が、代数的な部分(代数的サイクル)の組み合わせで表せるか 未解決
ポアンカレ予想 トポロジー 「穴のない」閉じた3次元空間は、本質的に3次元球面と同じか 解決済み(ペレルマン、2002〜2003年)
リーマン予想 数論 ゼータ関数の非自明な零点は、すべて実部1/2の直線上にあるか。素数の分布と直結する 未解決。数値的には膨大な範囲で成立を確認済み
ヤン–ミルズ方程式と質量ギャップ 数理物理 素粒子の標準模型の土台となる量子場の理論を数学的に厳密に構成し、正の「質量ギャップ」を示せるか 未解決
ナビエ–ストークス方程式 偏微分方程式 滑らかな流れは永遠に滑らかなままか、それとも有限時間で速度が発散する「特異点(爆発)」が生じうるか CMIが状態を「active」に変更。賞は未授与(第5〜6章)
バーチ・スウィンナートン=ダイアー(BSD)予想 数論 楕円曲線上の有理点の「多さ」(ランク)が、対応するL関数の振る舞いで決まるか 未解決

IT技術者にとって最も身近なのはP対NP問題でしょう。公開鍵暗号の安全性は「ある種の計算は現実的な時間では解けない」という前提に立っており、P=NPが示されればその前提が根本から揺らぎます。CMIに掲載されたスティーヴン・クックの公式問題文は、P=NPが成り立つなら、妥当な長さの証明をもつ定理の形式的証明をコンピュータが見つけられるようになり、その例にはCMIの懸賞問題すべてが含まれうる、とまで書いています。AIと数学の関係を考えるうえで、示唆的な一文です。

3. 唯一の解決例:ポアンカレ予想

ロシアの数学者グリゴリー・ペレルマンは、2002年から2003年にかけて3本の論文をプレプリントサーバのarXivに投稿し、リチャード・ハミルトンが始めた「リッチ・フロー」の理論を発展させてポアンカレ予想を証明しました。注目すべきは、彼が論文を査読誌に投稿しなかったことです。複数の専門家チームが数年かけて内容を検証し、その結果として証明が受け入れられました。

ペレルマンは2006年のフィールズ賞を辞退し、2010年にCMIが授与基準を満たしたと発表したミレニアム賞も辞退しました。ミレニアム賞の辞退理由として、ハミルトンの貢献が自分に劣らないことを挙げたと伝えられています。この一件は、ミレニアム問題の「解決」が、論文の公開ではなく数学界による長期の検証によって確定するものだということをよく示しています。

4. AIは数学をどこまで変えたか

2026年9月の出来事を理解するには、ここ数年の「AI×数学」の流れを押さえておく必要があります。大きく分けると、競技数学での到達、未知の構造やアルゴリズムの発見、そして定理証明支援系(Lean)による形式化の3本柱です。

時期 主体 成果 読むときの注意
2022年 He、Lee、Oliver、Pozdnyakov 楕円曲線のデータに機械学習を適用する過程で、振動パターン「murmurations」を発見(arXiv:2204.10140) BSD予想の解決ではなく、関連する新現象の発見
2024年7月 Google DeepMind 国際数学オリンピック(IMO)で、AlphaProofが非幾何の3問、AlphaGeometry 2が幾何の1問を解き、合計28/42点(銀メダル相当)。論文は2025年11月にNature掲載 4問はAlphaProof単独の成果ではない。金メダル境界まで1点
2025年 Google DeepMind AlphaEvolveが4×4の複素数行列の積を48回のスカラー乗算で計算する手法を発見(1969年のシュトラッセン法の49回を56年ぶりに更新)。11次元の接吻数の下界を592から593へ 「50超の問題の約75%で既知最良と一致、約20%で改善」はDeepMind自身の評価
2025年7月 OpenAI、Google DeepMind 汎用の推論モデルがIMO 2025で6問中5問を解き、35/42点(金メダル相当) 競技数学は答えが既知で、研究数学とは性質が異なる
2026年9月4日 Anthropic Claudeがフェルマーの最終定理の証明を11日間ほぼ自律的にLeanで形式化。約1,300万行、30,300個の定理を証明し、うち29,500個を最終証明で使用 既に人間が証明した定理の形式化であり、新定理の発見ではない
2026年9月8日 OpenAI ナビエ–ストークス方程式の有限時間爆発について、解析的証明とLean形式化を発表 「外力あり」版。帰属論争あり、CMIの検証は未了(次章)

なかでも見逃せないのが形式化の進展です。Leanのような定理証明支援系で書かれた証明は、機械的にチェックできます。人間が数百ページの論文を何年もかけて読み解く必要があった従来に比べ、「証明が正しいか」の確認コストを大きく下げられる可能性があります。フェルマーの最終定理の形式化は、Leanの数学ライブラリMathlibの約5倍という規模で、インペリアル・カレッジ・ロンドンのケヴィン・バザード氏も自動形式化の成果として高く評価しました。AIが大量の証明を生み出す時代に、その正しさを誰がどう保証するのかという問題への一つの答えがここにあります。

5. 2026年9月、ナビエ–ストークス問題に何が起きたか

「爆発」を探す長い助走

ナビエ–ストークス方程式は、粘性のある流体の運動を記述する方程式で、気象予測から航空機設計まであらゆる工学の土台になっています。問題の核心は、滑らかな初期状態から出発した流れが、有限の時間で速度が無限大に発散する「爆発」を起こしうるかどうかです。

数学者たちは、本命に挑む前段階として、粘性のないオイラー方程式など、より扱いやすい方程式で爆発を探してきました。LuoとHouが数値計算で有力な爆発候補を示し、2022年にはChenとHouがコンピュータ支援証明によってその爆発を厳密に裏付ける成果を出しています。ただ、こうした「安定な」爆発に対し、ナビエ–ストークスで起こりうる爆発は、ごく微妙な条件下でしか現れない「不安定な」ものだと考えられてきました。

ここでAIが登場します。NYUのトリスタン・バックマスター氏らは、物理法則を組み込んだニューラルネットワーク(PINN)で自己相似解を直接探す手法を開発しました。2025年9月にはGoogle DeepMindやスタンフォード大学などとの共同研究として、複数の流体方程式で不安定な特異点の新しい族を系統的に見つけたとするプレプリントを公開しています。

OpenAIの発表

2026年9月8日(発表資料の日付は9月7日)、OpenAIは非公開の内部モデルを使い、約1万のAIエージェントが88時間稼働して、ナビエ–ストークス方程式が有限時間で特異点を生じうることの解析的証明と、そのLeanによる形式化を生成したと発表しました。この内部モデルは、公開中の最新モデルGPT-6 Astraよりも高性能だとされています。エージェント数や稼働時間はOpenAI自身の公表値であり、計算の過程を第三者が検証したものではありません。

BBCはこれを、ミレニアム賞が求める4つの記述のうち2つを解決したものと報じています。この「4つのうち2つ」という点が、次章で説明するように非常に重要です。

同じ朝に出た、もう一つの証明

OpenAIの発表の直前、バックマスター氏とAnthropicの研究者レヴェント・アルペゲ氏が、約1年取り組んできた成果として、外力のあるオイラー方程式の爆発を含む3つの証明を公表しました。こちらもLeanで形式化されており、両陣営の証明が同じ朝に出そろう形になりました。

バックマスター氏は、OpenAIが自分たちの進展を知ったうえで同じ道筋を追ったと主張しました。論点の一つは、同氏がOpenAIのコーディングツールCodexを研究に使っていたことで、そのやり取りがOpenAI側の研究に影響したのではないかというデータの扱いをめぐる疑問です。OpenAIはこの主張を「断じて虚偽」だと否定し、手法も異なると反論しています。双方の主張は食い違っており、2026年9月17日時点で決着はついていません。

テレンス・タオ氏はこの件について、バックマスター氏らの成果を高く評価する一方で、噂だけでAI企業が巨大な計算資源を投入し、人間の研究者がアイデアを育てきる前に問題が「刈り取られて」しまう危うさや、AI企業が数学の成果を論文や講演ではなくプレスリリースで伝える姿勢への懸念を示しています。良質な未解決問題は有限の資源であり、それがAIによって急速に消費されていくことへの問題提起でもあります。

6. 「解決」と言えるのか:4つの選択肢とCMIの判断

CMIのナビエ–ストークス問題は、チャールズ・フェファーマンが書いた公式問題文で、次の4つのいずれかを証明すれば解決とみなすと定めています。「滑らかさが保たれる」を示す肯定的な2つと、「破綻する」を示す否定的な2つです。

選択肢 内容 外力 2026年9月時点
A 3次元全空間で、滑らかな解が永遠に存在し滑らかさを保つ なし 未解決
B 周期境界条件の空間で、同じく滑らかさを保つ なし 未解決
C 3次元全空間で、滑らかな初期値と外力から出発しても滑らかな解が続かない例がある あり OpenAIが証明を主張
D 周期境界条件の空間で、同様の破綻例がある あり OpenAIが証明を主張

規定上はどれか1つを示せば解決です。ただし、流体に外から力を加え続けることを許すC・Dと、外力なしで流体そのものの性質を問うA・Bとでは、数学的な意味合いが異なります。多くの数学者が「本丸」と見てきたのは外力なしの問題であり、こちらは依然として手つかずです。「ナビエ–ストークス問題が解けた」という見出しだけを見ると、この区別が抜け落ちてしまいます。

CMIは2026年9月10日付の声明で、ナビエ–ストークス問題は「解決されたようだ(apparently been settled)」と述べました。翌11日には、検証と帰属を判断するプロセスは意図的に急がないものだと改めて強調し、公式サイト上の状態を「unsolved」でも「solved」でもない「active」に変更しています。賞は授与されておらず、第1章で説明した査読付き掲載と2年間の待機期間という手続きもこれからです。

7. 残る5問とAIの距離

ナビエ–ストークス以外の未解決5問について、AIとの関わりは問題ごとにかなり違います。

リーマン予想は、計算機との付き合いが最も長い問題です。アラン・チューリングも初期のコンピュータで零点の検証を行いました。現在の到達点の一つであるPlattとTrudgianの研究(arXiv:2004.09765)は、区間演算を用いて厳密に、高さ3×1012までのすべての非自明零点が実部1/2の直線上にあることを確認しており、その数は12兆3,631億個を超えます。とはいえ、零点は無限にあるため、どれだけ数値検証を積み重ねても証明にはなりません。

BSD予想では、前述のmurmurationsがAIによる発見の好例です。その後、ニーナ・ズブリリナ氏がこの現象に初めて厳密な理論的説明を与え、論文は2025年にInventiones Mathematicaeに掲載されました。機械学習がパターンを見つけ、人間の数学者が理論を与えるという分業は、AI支援数学の一つの型になりつつあります。ただし、これはBSD予想そのものの解決に直結する成果ではありません。

P対NP問題は、AIにとって最も遠い問題かもしれません。計算量の下界を示す深い分離定理は、既知の証明手法そのものに障壁があることが知られており、探索や形式化の力だけで突破できる見通しは現時点で立っていません。一方で、AIの側から見るとこの問題は他人事ではありません。学習の計算量的な困難さや暗号の安全性は、P≠NPかそれに類する仮定の上に立っているからです。

ホッジ予想とヤン–ミルズ問題は、そもそも問題を正しく定式化して形式化するところから難しく、現時点でAIによる目立った進展は報告されていません。ヤン–ミルズ問題は量子場の理論の厳密な構成を要求しており、数学的な土台づくりそのものが課題です。

ナビエ–ストークスが最初の舞台になったのは、偶然ではないと筆者は考えています。「爆発する解を見つける」という問題は、候補を数値的に探索し、見つかった候補を厳密に証明するという、AIと計算機が得意とする手順に分解しやすい構造を持っていました。すべてのミレニアム問題がこの形に落とし込めるわけではありません。

8. 競技数学と研究数学のギャップ

AIの数学能力を測るベンチマークの推移も、状況を読むうえで参考になります。Epoch AIのFrontierMathは、2024年11月の公開時点では、当時の最先端モデルでも正答率2%未満という難問集でした。

その後、2026年6月12日に改訂版(v2)が公開されました。元の問題の約42%に誤りが見つかって修正され、全338問(Tier 1〜3が295問、研究レベルのTier 4が43問)の構成になっています。旧版とはスコアの互換性がない点に注意が必要です。報道やリーダーボード集計によれば、GPT-6 AstraはTier 4(v2)で97.6%に達し、このベンチマークはほぼ飽和したとされます。

対照的なのが、Epoch AIが本当に未解決のエルデシュ問題68問をLeanで形式化した「FrontierMath Erdős」です。報道によれば、GPT-6 Astraが解けたのは68問中2問(約3%)で、他のモデルは0問でした。答えの決まった難問ではほぼ満点を取れても、誰も答えを知らない問題になると急に正答率が落ちる。この落差こそが、現在のAIの数学能力の実像です。

その意味で、2026年9月のナビエ–ストークスの件は、この落差を越えた可能性のある最初の大きな事例として注目されています。一方で、1万のエージェントを88時間動かすという計算規模や、先行する人間の研究との関係を考えると、「AIが単独で成し遂げた」と単純に言える話でもありません。

9. 「AIが解いた」ニュースの読み方

今後も「AIが難問を解いた」という見出しは増えるはずです。ミレニアム問題に関するニュースを読むときは、少なくとも次の点を確認すると、見出しと実態のずれを見抜きやすくなります。

  • 査読を経ているか。企業の発表やarXivのプレプリントは査読前です。CMIの賞は査読付き掲載と2年間の待機を前提としています。
  • 公式問題文のどの記述を満たすのか。ナビエ–ストークスであれば、外力ありのC・Dか、外力なしのA・Bかで意味が大きく変わります。
  • CMI自身がどう表現しているか。2026年9月時点の公式の状態は「active」であり、「solved」ではありません。
  • 数値は誰の申告か。エージェント数、稼働時間、ベンチマークスコアの多くは開発元の自己申告か第三者の集計で、独立検証されていないことがあります。
  • 「発見」「形式化」「解決」を区別しているか。既知の証明の形式化や、関連する新現象の発見は重要な成果ですが、懸賞問題の解決とは別物です。

また、今回の帰属論争は、未公表の研究をAIツールに入力する研究者にとって現実的なリスクを示しました。業務でAIツールに機密情報を扱わせる企業にとっても、データの扱いに関する規約と実際の運用を確認しておく必要性を示す事例と言えます。

まとめ

ミレニアム懸賞問題は、2000年にCMIが掲げた7つの難問で、2026年9月時点で正式に解決されたのはポアンカレ予想だけです。ナビエ–ストークス問題については、OpenAIとバックマスター氏・アルペゲ氏の双方からLeanで形式化された成果が同時期に出され、CMIも状態を「active」に変えましたが、それは外力ありの選択肢に関するもので、賞の授与も独立検証もまだ先です。

AIと数学の関係は、この数年で「難問集で点数を取る」段階から、「未知の構造を見つける」「証明を形式化して検証する」「研究者と一緒に未解決問題に挑む」段階へと移ってきました。競技数学やベンチマークでは人間のトップに並んだ一方、本当に答えの分からない問題ではまだ正答率が大きく落ちます。

筆者の見立てでは、当面の焦点は二つです。一つは、ナビエ–ストークスの主張が査読とCMIの手続きを通過するかどうか。もう一つは、本丸である外力なしの問題や、性質の異なる他のミレニアム問題に、同じ手法がどこまで通用するかです。いずれにしても、「AIが解いた」という見出しより、誰が何をどの手続きで確かめたのかに目を向けることが、これからますます重要になるでしょう。

水曜日, 9月 16, 2026

3機が2機に――グローバルホーク墜落で見えた日本の無人ISRの弱点

2026年9月15日、航空自衛隊三沢基地所属の無人偵察機RQ-4Bグローバルホーク1機が、鳥取県沖の公海上で地上との通信が途絶えた直後にレーダーから消えました。付近の海上で機体の一部とみられる浮遊物が見つかり、空自は「墜落したものと推定」と発表しています。空自がグローバルホークを失うのは、2022年の配備以来初めてです。

この事故は、1機約170億円の機体を失ったというだけの話ではありません。空自の保有機は3機しかなく、日本の広域常時監視は少数の高価な輸入機に大きく依存しています。一方で、グローバルホークは本家の米空軍では退役に向かっている機体でもあります。今回の事故は、日本の無人偵察(ISR)体制をどう組み立てるかという問いを改めて突きつけています。

結論を先に書きます。事故原因は調査中で、現時点では通信障害・機体故障・外部要因のいずれとも断定できません。日本の無人ISRは、空自のRQ-4Bと海自・海保のMQ-9Bという輸入機を軸にしています。そのうえで国産側では、次期戦闘機と連携する無人機の研究開発と、三菱重工・フジ・インバックによる小型長時間滞空機という、性格の異なる2つの動きが進んでいます。本記事では、事故の経過、機体の位置づけ、同種機との比較、自衛隊・海保の配備状況、国産機の現在地を順に整理します。

本記事は2026年9月16日時点の公開情報に基づいています。事故原因は調査中であり、今後の発表で内容が変わる可能性があります。記事後半の役割分担や今後の見通しは筆者の分析であり、確定した政策や予測ではありません。

1. 何が起きたのか

空自の発表と主要報道をもとに、事故当日の経過を整理します。

時刻(9月15日) 出来事 情報の性格
午前10時20分ごろ 三沢基地(青森県)を離陸 空自発表
午後0時55分以降 三沢の地上操縦装置との通信が途絶(通信装置との接続不良) 空自発表
午後0時58分ごろ 鳥取県沖の北約50kmの公海上でレーダーから航跡が消失 空自発表。詳細な地点は機密保持のため非公表
午後2時19分ごろ以降 海上保安庁の巡視船や空自の戦闘機が浮遊物を相次いで発見。撮影写真から機体の一部と推定され、空自は「墜落したものと推定」と発表 空自発表・主要報道。「墜落」は現時点で推定
午後5時時点 人的被害を含む外部被害の情報なし 空自発表(毎日新聞)

空自は「訓練中ではなく任務飛行だった」と説明していますが、具体的な任務内容は「運用の細部に関わる」として明らかにしていません。墜落機の機体番号を23-6003とする情報もありますが、これは海外の専門メディアによる識別で、空自が公式に確認したものではありません。

原因究明の焦点は、通信不良の発生から航跡消失までの約3分間です。米空軍の資料によれば、グローバルホークには通信途絶時に設定経路で基地へ戻るRTB(Return-To-Base)機能が備わっています。ただし、今回RTBが作動したかどうかは分かっていません。注意したいのは、通信の途絶が墜落の「原因」だとは限らない点です。通信喪失が時間的に先に起きただけで、電源・飛行制御・推進系などの異常が通信喪失と墜落の両方を引き起こした可能性もあります。撃墜や電波妨害を示す情報も、現時点では公表されていません。

3機のうち1機を失った影響について、防衛省の報道官は「任務遂行の支障が生じないよう、運用上の必要な態勢を確保している」と述べています。残る2機の飛行停止や一斉点検については、本稿執筆時点で公式な発表は確認できていません。

2. グローバルホークとはどんな機体か

RQ-4グローバルホークは、米ノースロップ・グラマン製の高高度長時間滞空型(HALE)無人偵察機です。1998年に初飛行し、米空軍では衛星や有人偵察機を補完する戦略級のISRアセットとして使われてきました。系列には、画像情報型のBlock 20、画像・レーダー・信号情報をまとめて扱うBlock 30、地上移動目標を追うAESAレーダーを積んだBlock 40があります。派生型には米海軍のMQ-4Cトライトン、NATOのRQ-4Dなどがあります。

空自機は全長約15m、翼幅約40mです。時速約570kmで巡航し、約36時間の連続飛行ができるとされています。運用高度は約60,000ftで、民間旅客機の巡航高度を大きく上回ります。空自は2015年度から取得を始め、2022年に三沢基地へ配備して無人機専門の「偵察航空隊」を発足させました。3機体制が整ったのは2023年6月です。空自機は、米空軍のBlock 30をベースにした仕様です。

価格は報道によって「1機約170億円」(2019年時点)、防衛省の説明として「1機あたり約173億円」とされています。ただし、FMS(対外有償軍事援助)による調達では、機体本体、センサー、地上操縦装置、教育訓練、技術支援、予備品のどこまでを含むかで金額が大きく変わります。この数字は機体あたりの取得額であり、地上設備や維持費を含むプログラム全体の総額とは区別して読む必要があります。

3. 「3機から2機」が意味すること

今回の喪失で、空自の保有機数は3機から2機へ、機数ベースで約33%減りました。ただし、これで監視能力がそのまま3分の1失われたとは言えません。実際の任務能力は、整備中の機数、地上操縦装置の数、操縦員・解析要員の態勢、同時に飛ばせる機数、予備機の設定などで決まるからです。

それでも影響が小さいとは言えません。大型機は定期整備で長期間飛べない期間が生じるため、2機では「1機が整備中なら残りは1機」という状況が起きやすくなります。長時間任務を途切れなく続ける余裕や、予備機を確保する余地は明らかに狭まりました。

もう一つの論点が、米国側の支援基盤です。米空軍は2022年にBlock 30をISR任務から退役させ、残った機体の一部は極超音速兵器の試験支援などに転用されました。現在の米空軍のRQ-4はBlock 40が中心で、空軍自身は宇宙配備型のISRなどへ役割を移す方針を示してきました。これに対して米議会は、合衆国法典第10編第9062条(m)でRQ-4の退役を制限しています。2026会計年度国防授権法による改正で期限は2030年9月30日まで延長され、この期間はRQ-4の総在庫を原則として10機未満に減らすことができません。ただし、事故などで修理が経済的でない個体は例外です。

空自機と同系統のBlock 30が米空軍の現役から外れていることは、部品の入手や技術支援の面で空自機の長期維持に影響する可能性があります。ただし、メーカーによる支援、同系統機を運用する韓国の存在、試験用途に転用された米軍機などもあるため、直ちに部品供給が止まるといった状況にあるわけではありません。

4. 同種機との比較

長時間の情報収集を目的とする主な機体を並べました。数値は公称値または代表的な値で、搭載物や任務条件をそろえた比較ではありません。特に滞空時間は、ペイロード、高度、気象、燃料の余裕によって大きく変わります。

機種 分類・規模 運用高度 滞空時間(公称) 日本との関係
RQ-4B グローバルホーク 大型HALE無人機。EO/IR、SAR、信号情報などを搭載(Block 30系) 約60,000ft 30時間超(空自機は約36時間と公表) 空自が運用(3機→2機)
MQ-4C トライトン RQ-4派生の洋上監視型。海上捜索レーダーなどを搭載 50,000ft超 24時間超 米海軍が運用。日本は導入していない
MQ-9B シーガーディアン 中高度長時間滞空型(MALE)。対水上レーダー、EO/IRなど 40,000ft級 30時間超(構成により異なる) 海保が運用中。海自が取得を進めている
U-2S 有人の高高度偵察機 70,000ft超 有人のため数時間〜半日程度 米空軍が運用
WZ-7 翔龍 中国の連結翼型高高度無人機。センサー構成の公開情報は限定的 高高度(資料により差) 資料により差 日本周辺での飛行が確認されている
E-5LK(国産) 小型長距離機。最大離陸重量150kg未満(メーカー公表) 非公表 40時間・4,000km(メーカー公表) 三菱重工とフジ・インバックが開発・製造。陸自が同系統とみられるE-5L型を検証

表のE-5LKは約14トン級のRQ-4Bとは機体の規模がまったく違うため、同列の性能比較ではなく「長時間の情報収集」という目的で並べた参考です。公称の滞空時間だけを見るとRQ-4Bより長いものの、搭載できるセンサーの規模や飛行高度が異なるため、グローバルホークの代わりにはなりません。

グローバルホーク系列の喪失は今回が初めてではありません。2019年6月には、米海軍の広域洋上監視実証機(RQ-4A派生のBAMS-D)がホルムズ海峡付近でイラン革命防衛隊の地対空ミサイルに撃墜されています。2026年4月9日には米海軍のMQ-4Cが墜落し、米海軍安全司令部がクラスAの航空事故として記録しました。ただし、公式資料で確認できるのは日付・機種・人的被害なしといった範囲で、発生場所や原因は明らかにされていません。この件は、撃墜のような敵対行為による喪失とは確認されていない点に注意が必要です。

無人機以外の選択肢として参考になるのがドイツです。ドイツはRQ-4派生のユーロホークを欧州空域での耐空証明問題などで2013年に断念し、その後、ビジネスジェットをベースにした有人の信号情報収集機PEGASUSへ切り替えました。混雑した空域で大型無人機を運用する難しさを示す例です。

5. 自衛隊・海保の無人ISR体制

海上自衛隊(MQ-9B):海自は2023年から試験運用を行ったうえで、洋上監視用の滞空型無人機としてMQ-9Bシーガーディアンを選定しました。令和8年度(2026年度)予算にはMQ-9Bの取得等として765億円が計上されています。2026年8月末に公表された令和9年度概算要求では17機分の取得が盛り込まれ、計23機を2027年度から配備し始める計画と報じられています。防衛省は、これらを武装せず情報収集・警戒監視・偵察の用途に限るとしています。なお、選定時に報じられた「1機平均約120億円」は、地上管制システムや付属品を含む金額で、飛行機体だけの単価ではありません。

海上保安庁(MQ-9B):海保は2022年からMQ-9Bを運用しており、現在は北九州空港を拠点に日本周辺海域の警戒監視にあたっています。2025年11月には、北九州空港への着陸時に垂直尾翼とプロペラの先端が滑走路に接触して損傷し、他の機体も安全確認のため運用を停止しました。国は当初この件を「重大インシデント」としていましたが、損傷が大修理を要する程度と判明したため、2026年5月に「航空事故」へ認定を変更しました。損傷は胴体の隔壁などにも及び、運輸安全委員会が調査を続けています。

陸上自衛隊:陸自は輸入機のスキャンイーグル2を「UAV(中域用)」として2019年から本格的に導入し、師団・旅団の情報隊へ配備してきました。令和8年度予算には、水上艦艇などを遠距離から早期に探知するための「UAV(広域用)」の取得費111億円(5式と報じられている)も計上されています。ただし、どの機種を取得するかは公表資料では特定されていません。

在日米軍:米空軍のRQ-4は、これまで三沢基地や横田基地に展開して日本周辺で活動してきました。日米の無人ISRは、運用面でも互いを補い合う関係にあります。

6. 国産機の現在地

グローバルホーク級の国産高高度無人偵察機は、現時点で存在しません。過去には防衛省の研究として無人機研究システムなどが試作されましたが、実用配備には至っていません。今の国産の動きは、「小型長時間滞空機」と「次期戦闘機と連携する無人機」という性格の異なる2つの流れに分けて見ると分かりやすくなります。

6-1. 三菱重工・フジ・インバックの情報収集用無人機

三菱重工は、情報収集用の無人航空機としてフジ・インバックと協力し、E-5LKとE-7K2の2機種を開発・製造しています。同社は、四方を海に囲まれた日本に必要な長い航続時間・距離を実現した機体だと説明しています。メーカーが公表している主要諸元は次のとおりです。

項目 E-5LK E-7K2
最大航続距離 4,000km 2,000km
飛行時間 40時間 20時間
ペイロード 10kg 15kg
最大離陸重量 150kg未満 メーカーの諸元表では記載なし
通信・航法 直接通信、衛星通信。GNS/INSあり(メーカー表記のまま) 諸元表では機種別の記載なし
適用センサ EO/IR、ESM、SAR 諸元表では機種別の記載なし
その他機能 短距離離着陸、目標検知・自動追尾 諸元表では機種別の記載なし

いずれもメーカーの公表値で、第三者による検証結果は公開されていません。運用高度と価格も非公表です。製品ページの諸元表では、重量・通信・センサーなどの行はE-5LKの列にだけ値が書かれており、これらがE-7K2にも共通する仕様かどうかは表からは確認できません。

製品ページでは、機能面の特徴として次の点も挙げられています。

  • 高精細EO/IRカメラ、SARセンサ、ESMセンサ、衛星通信、AIコンピュータなどを搭載できる
  • 短いサイクルでソフトウェア更新や新規センサーの搭載を行う
  • 同社の無人機統合管制システム「CoasTitan」により、少人数で複数機を同時に運用できる

自衛隊での検証も進んでいます。陸上自衛隊は2024年3月、三菱重工と共にフジ・インバック製の「E-5L型UAV」を検証中であると公表しました。偵察や輸送などで長期間連続して運用できるUAVを使って実証を行い、本格導入に向けた検討を加速するとしています。同年7月には静岡県の富士川滑空場で、夜間を含む飛行や画像情報の中継など、基本性能と運用要領の検証を実施しています。陸自が検証した「E-5L型」と製品名の「E-5LK」の関係(改良型かどうか)は、メーカーから明示されていません。

また、陸自中央会計隊の契約情報によると、2026年1月21日に「無人機統合管制システムの連接検証役務」を三菱重工業と約4,950万円で契約しています。ただし、公開された契約件名からは、対象がCoasTitanそのものか、E-5L系の機体との連接かまでは読み取れません。E-5LK/E-7K2を正式な装備品として取得する計画(機数・予算)も、公開情報では確認できていません。

開発パートナーのフジ・インバックは、横浜市に拠点を置く小型固定翼UAVのメーカーです。2008年に長距離無人機、2009年に高高度用無人機の開発を達成したと公表しており、有人機の接近を検知して自動回避するシステムや、緊急時にパラシュートで機体を安全地帯へ降ろす回収システムも手がけています。日刊工業新聞によれば、同社は2021年時点で3,000kmを30時間で飛ぶ機体の開発を掲げ、価格は海外製より安い1億5,000万円程度を想定していました。同社の無人機は防衛省への納入実績もあると報じられています。

6-2. 次期戦闘機と連携する無人機

もう一つの流れが、日英伊で共同開発する次期戦闘機と連携する無人機です。防衛省の政策評価書は、令和8年度から令和10年度にかけて構想設計を行い、次期戦闘機の量産初号機の配備に合わせて令和17年(2035年)の装備化を目指すとしています。技術リスクとコストを下げるため、海外との共同研究・開発の可能性も探るとしています。予算は、令和8年度概算要求の約49億円に対し、成立した予算では48億円が計上されました。

技術面では、防衛装備庁が遠隔操作型支援機に関する研究を進めており、SUBARUが開発した無人実験機を使った飛行試験が行われています。三菱重工も、2024年の国際航空宇宙展でAIを搭載する戦闘支援無人機の模型を初公開しました。これらは戦闘機に随伴する機体であり、グローバルホークのような広域監視機とは目的が異なります。

6-3. 成層圏プラットフォームと国産化の課題

民間との共用(デュアルユース)技術としては、NEDOの経済安全保障重要技術育成プログラムで、成層圏を長期間飛行する無人機による海洋状況把握技術の開発・実証が2024年に始まっています。大型UAVでなければ積めなかった光学・赤外線センサーやSARの軽量化・省電力化が目標の一つです。

高高度級の国産化に向けた課題は、薄い大気中でも効率を保つ推進系、センサーの小型軽量化、少数調達によるコスト高、運用実績の不足です。防衛省の政策評価書も、既存の国産無人装備では次期戦闘機との連携に必要な要件を満たす見通しが立たないとして、新たな研究開発が必要だとしています。

7. 役割分担で考える

今回の事故で見えたのは、少数の高価な機体に監視を頼る構成の弱さです。とはいえ、小型機を増やせば解決するという単純な話でもありません。機体ごとに得意分野が異なるため、階層に分けて組み合わせる考え方が現実的だと筆者は考えます。以下は筆者の整理です。

階層 主な役割 日本での代表例
高高度大型無人機 高高度からの広域・戦略レベルの複合的な情報収集 空自RQ-4B
中高度長時間無人機 海洋監視、柔軟なセンサー運用 海自・海保MQ-9B
小型長時間無人機 沿岸・島しょ部の局地的な持続監視、分散配置、複数機運用 E-5L系(陸自が検証)、スキャンイーグル2
成層圏・衛星 超長時間の通信中継、広域監視の補完 NEDOの研究開発、防衛衛星
戦闘機連携無人機 有人機と組んだ任務の拡張 次期戦闘機と連携する無人機(研究開発中)

損耗を許容できる安価な機体を多数組み合わせれば、1機を失ったときの影響は小さくなります。ただし、小型機のセンサー性能、悪天候への強さ、電波妨害への耐性、有人機と同じ空域で安全に飛べるかといった点は、公開情報からは評価できません。高価な大型機を置き換えるのではなく、層を重ねて冗長性を持たせる方向が現実的だと筆者は見ています。

8. 今後の注目点

  • 空自RQ-4B墜落の事故調査結果。特に、通信途絶と墜落の因果関係、RTB機能が作動したかどうか
  • 残る2機の運用状況と、欠けた1機を補充するのか、他の手段で補うのかという判断
  • 年末に予定される安全保障関連3文書の改定で、無人ISRがどう位置づけられるか
  • 海自MQ-9Bの配備開始(2027年度から)と、海保の北九州での事故調査結果
  • 陸自によるE-5L型の検証結果と、E-5LK/E-7K2の正式採用の有無。UAV(広域用)の機種がどれになるか
  • 次期戦闘機と連携する無人機の構想設計の進み具合
  • 米空軍のRQ-4退役制限が2030年以降どう扱われるか

まとめ

空自のグローバルホーク墜落は、原因がまだ分かっていない段階ですが、日本の無人ISRが少数の高価な輸入機に依存していることをはっきり示しました。保有機は3機から2機に減り、整備と任務の両立はより難しくなります。米国では同系統機が退役へ向かっており、長期的な維持の見通しも楽観できません。

一方で、海自のMQ-9B導入、陸自の広域用UAV、三菱重工とフジ・インバックの小型長時間機、次期戦闘機と連携する無人機など、選択肢は着実に増えています。これらはグローバルホークの単純な代わりではなく、それぞれ別の層を担う機体です。今回の事故をきっかけに、どの層を何機でどう組み合わせるかという全体設計の議論が深まることを期待します。

「ソブリンAIサーバ」とは何か:国産の“中身”を層で読み解く

「ソブリンクラウド」に続いて、「ソブリンAIサーバ」「国産AIサーバ」という言葉を見かける機会が増えました。2026年に入ってから、国内工場でのAIサーバ製造、国内設計CPUを搭載したサーバの販売発表、通信事業者による国産サーバ構想の報道などが相次いでいます。

ただ、「ソブリン」が何を守る言葉なのかは、使う人によってかなり違います。データの保管場所なのか、適用される法律なのか、運用する人なのか、それとも半導体やファームウェアの出どころなのか。サーバという物理的な箱が話題になったことで、この曖昧さが調達の現場で問題になり始めています。

先に結論を書くと、「ソブリンAIサーバ」に統一された業界標準の定義は見当たりません。国内での組立や部品のトレーサビリティは供給網や改ざんのリスクを下げますが、それだけで主権が完結するわけではなく、半導体の前工程、BMCやファームウェア、暗号鍵、保守経路、ソフトウェアまで層ごとに見る必要があります。本記事では、概念の整理、国内外の動き、制度、そして選定時の確認項目の順に整理します。

本記事は2026年9月15日時点の公開情報に基づきます。製品の出荷時期や半導体の量産時期など、今後の予定・計画を含みます。また、性能値の多くはベンダー自身の公表値であり、独立した第三者検証を経たものではありません。

1. 「ソブリンAIサーバ」とは何か

富士通は2026年2月の発表で、ソブリンAIサーバを「データ流出リスクの最小化や国内法への準拠など、ITインフラのソブリン性を重視した用途に対応するサーバ」と説明しています。ただしこれは一社の用法で、業界で合意された規格や認証があるわけではありません。米シンクタンクのCNASも、ソブリンAIには合意された定義がないとして独自の定義を置いて分析しています。

ソブリンAIをどう分解するかにも統一見解はありません。Singh と Sengupta の論文(arXiv:2511.15734)は、Data、Compute Infrastructure、Model Autonomy、Normative Alignment の4本柱を提示しています。一方でベンダー各社は「データ・インフラ・モデル・運用」といった別の切り口を使っており、言葉は似ていても中身は揃っていません。本記事では便宜上、データ・モデル・インフラ・運用の4領域で考え、サーバはこのうち「インフラ」の中核要素として扱います。

周辺用語との関係は次のように整理できます。

用語 主に問うこと 注意点
データレジデンシー データが物理的にどこに保管されているか 国内保管でも、外国法の適用や外部からのアクセスを排除できるとは限らない
データ主権 どの法域の法がデータを支配し、誰がアクセスを決められるか 保管場所より、事業者の管轄と暗号鍵の支配が効いてくる
ソブリンクラウド データ主権や運用主権を満たすように設計されたクラウド 「国内事業者運営」「海外クラウドの国内運用」など実装が多様
ソブリンAI AIの計算資源・モデル・データ・運用を自国(自組織)の統制下に置くこと 分解の仕方は論文・ベンダーごとに異なる
ソブリンAIサーバ ハードウェアの設計・製造・供給網・ファームウェアまで説明可能か ベンダー・市場用語であり、どの工程まで国内かは製品ごとに確認が必要

2. なぜ今、サーバまで問われるのか

背景のひとつは、外国法によるデータアクセスへの懸念です。よく引き合いに出される米国のCLOUD Actは、データの保存場所ではなく、米国の管轄下にある事業者がそのデータを「占有・保管・管理(possession, custody, or control)」しているかどうかを軸に、海外に保存されたデータにも開示命令が及び得る仕組みです。したがって「国内リージョンだから安全」とも「米国法人だから自動的に適用される」とも単純には言えません。

同じ理屈で、国産サーバをオンプレミスに置けばリスクが消えるわけでもありません。米国系SaaSとの連携、遠隔保守、テレメトリ送信、鍵管理、バックアップ先などの運用設計次第で、外部の管轄に触れる経路は残ります。サーバの国産化は、この問題の一部を担うにすぎません。

もうひとつの背景は供給網リスクです。地政学的な緊張が続くなかで、部品の出どころや製造工程での改ざん、ファームウェアへの不正コード混入といった懸念が、重要インフラや防衛分野の調達で重視されるようになりました。日本では経済安全保障推進法により、2022年12月にクラウドプログラムを含む11物資が「特定重要物資」に指定され(その後の政令改正で対象は追加されています)、国内の計算資源整備が政策的に後押しされています。

3. サーバの「主権」を層に分解する

「国産サーバ」と言っても、どの層が国内にあるかは製品によって大きく異なります。国内の基板実装・装置組立とトレーサビリティは、供給網の透明性や真正性の面で意味のある前進です。ただし、CPUやGPUの前工程、NIC、SSD、BMC、UEFI、ファームウェア更新の配信経路、暗号鍵、保守経路のどこかに外国依存があれば、インフラ主権は部分的にしか成立しません。「国内製造だからバックドアが存在しない」という保証にもなりません。評価の軸は、たとえば次のように分けられます。

評価軸 確認項目 国内組立だけで改善するか
設計主権 CPU・基板・BMC・BIOS/UEFI・ファームウェアの設計主体 改善しない。設計元を個別に確認する必要がある
製造主権 半導体前工程、先端パッケージ、基板実装、装置組立、鍵注入、試験の所在 後工程の一部は改善。半導体前工程は海外ファウンドリ依存が一般的
供給網透明性 HBOM、原産国、部品ロット、ファウンドリ、EMS、二次調達先、変更通知 ロット追跡や製造履歴の記録は改善しやすい
運用主権 国内要員、特権アクセス、遠隔保守、テレメトリ、更新の承認、緊急時の自律運用 改善しない。保守契約と運用設計で決まる
データ・法的主権 データ所在地、暗号鍵の支配、外国政府アクセス、契約上の管轄、退出可能性 オンプレミス配置で一部は改善するが、連携先サービス次第
ソフトウェア主権 OS、ハイパーバイザ、コンテナ、AIランタイム、モデル、MLOpsの可搬性 改善しない。GPU向けソフトウェアスタックへの依存も残る
性能・TCO 実ワークロードでの性能、精度、レイテンシ、電力、冷却、保守費、移行費 主権とは別軸。トレードオフとして評価する

この表から分かるように、「どこまで国産ならソブリンと言えるか」は要件次第です。国内での基板実装で足りる調達もあれば、BMCやファームウェアのソース監査、非米国製のCPU/GPU、国内ファウンドリまで求める調達もあり得ます。後者を満たす量産製品は、現時点では国内外ともにほぼ存在しません。

4. 国内の動き

国内では、ハードウェアの国内製造に踏み込む動きと、クラウドや運用の側で主権を確保する動きが並行しています。

事業者 アプローチ 主な取り組み(2026年9月時点)
富士通 国内製造 2026年2月、石川県の笠島工場で装置組立(3月〜)と基板組立(6月〜)を行い主要部品のトレーサビリティを確保すると発表。Supermicroと協業。9月には国内設計CPU「FUJITSU-MONAKA」と搭載サーバの販売を発表
ソフトバンク 国内製造(構想) 2026年5月の日経報道によれば、NVIDIA・Foxconnと国産AIサーバについて協議。外部調達部品の国内組立から始め、将来は全工程を担う構想。別途、GB200 NVL72搭載の計算基盤(Blackwell GPU 1,224基、将来4,000基超)を2025年12月22日に稼働
さくらインターネット 国内クラウド 2026年3月27日、「さくらのクラウド」がガバメントクラウドの技術要件305項目を満たし正式採択。AWS、Azure、OCI、Google Cloudと並ぶ5サービス目で、国内サービスでは唯一
NEC クラウド・運用 求める主権の度合いに応じたソブリンクラウドのメニューを提供。自社LLM「cotomi v3」はガバメントAI「源内」の試用モデルに選定
日立製作所 クラウド・運用 自社管理の国内データセンターで運用し、他国の法令の影響を排除することを掲げたクラウドを提供。Google Cloudとの提携はフィジカルAIや生成AIの実装が中心
KDDI 海外技術の国内運用 大阪堺データセンターで「Gemini on Google Distributed Cloud」をソブリン用途向けにトライアル提供

ハードウェア面で具体的な製品が出ている例として、FUJITSU-MONAKAの中身を少し見ておきます。演算コアに2nm、キャッシュとI/Oに5nmのプロセスを使い分けた3D積層構造で、1チップ144コアのArmv9-A CPUです。販売開始は2026年11月ですが、CPUの提供は2026年度第4四半期(2027年1〜3月)、搭載サーバは2026年度下期から金融・通信・製造の一部顧客に先行提供し、日本・欧州向けの出荷は2027年4月以降の予定です。「販売開始」と「出荷」の時期がずれている点には注意が必要です。

富士通は「AI推論で他社CPU比2倍のスループット、同等処理に必要なサーバ台数と消費電力を半減」としていますが、これは自社公表値で、比較対象や測定条件は公開文面では十分に明らかではありません。また、CPUは国内で設計・開発され、サーバは国内工場で製造されるものの、先端ダイの製造は報道によればTSMCで行われます。第3節の表でいえば、設計主権と製造(後工程)主権を強化した製品であり、前工程まで国内で完結しているわけではありません。

5. 海外の動き

NVIDIAは「ソブリンAI」を事業戦略の柱に据えており、2025年のGTC Parisでは欧州に20カ所超のAIファクトリーを構築し、うち5カ所をギガファクトリー規模とする計画が報じられました。日本でも理化学研究所が、2,000基を超えるBlackwell GPUを搭載したシステムの導入を進めています。ソブリンAIの計算資源の多くがNVIDIA製GPUで構成されているという点は、各国に共通する構図です。

サーバベンダーでは、HPEがNVIDIAと共同で「HPE AI Factory sovereign」を展開し、エアギャップでの管理や国ごとの規制対応を想定した構成を打ち出しています。ただし、米国企業が提供する「ソブリン」製品は、データや運用を顧客側に閉じても、ベンダー自体は米国の管轄下にあるという点を切り分けて評価する必要があります。

欧州では、仏Eviden(Atosグループ)が域内の主権を前面に出しています。2025年11月に発表されたフランス初のエクサスケール機「Alice Recoque」は、AMDのEPYC「Venice」とInstinct MI430Xに加え、欧州製CPUであるSiPearlの「Rhea2」を採用する構成です。ここでも、欧州製CPUの採用と米国製アクセラレータの併用という「部分的な主権」の組み合わせになっている点は、日本の状況と重なります。

6. 日本の制度面

経済安全保障推進法に基づくクラウドプログラムの供給確保計画では、さくらインターネットが2024年2月に基盤的なクラウド技術の開発計画(最大助成額約6億円)で、同年4月には生成AI向け計算資源の整備計画(最大助成額約501億円)で認定を受けるなど、複数の事業者が支援対象になっています。両者は別の計画なので、金額を混同しないよう注意が必要です。

行政側の需要としては、デジタル庁のガバメントAI「源内」があります。国産LLMの公募には15件の応募があり、7件が試用モデルとして選定されました。全府省庁の職員約18万人を対象とした利用環境で評価が進められており、2027年度以降の有償調達は、改めて実施する評価の結果などを踏まえて判断される見込みです。国産モデルの試用は国産クラウド上で行われていますが、これは源内全体の実行基盤がすべて国産という意味ではありません。

半導体の前工程については、Rapidusが北海道千歳市で2nmロジック半導体の量産を2027年度に開始する計画を掲げています。国内で先端ロジックを製造できるようになれば、第3節の「製造主権」の穴を埋める選択肢になり得ますが、現時点では計画段階であり、量産の達成や顧客の獲得は確定していません。

7. 課題と市場の見方

最大の課題は、AI計算の中心であるGPUの海外依存です。国内で組み立てたサーバでも、搭載するアクセラレータとそのソフトウェアスタックは米国製が主流で、輸出規制の変更や供給制約の影響を直接受けます。加えて、国内製造やトレーサビリティの確保はコストに跳ね返るため、グローバル大手の量産規模と価格面でどう折り合うかも問われます。

市場規模の推計は、調査会社によって対象範囲が大きく異なります。MarketsandMarketsはソブリンAI市場を2025年の400億ドルから2032年に1,480億ドル(年平均成長率20.6%)と見積もり、market.usは2025年の411億ドルから2035年に2,587億ドルと予測しています。いずれもハードウェア、クラウド、モデル、サービスのどこまでを含むかで数字が変わるため、「ソブリンサーバ市場」の規模として読み替えることはできません。

8. 選定時に確認したいこと

「ソブリン」「国産」というラベルだけで判断せず、要件を具体的な確認項目に落とし込むことが重要です。ハードウェアの真正性については、たとえば次のような項目を個別に求める方が実効性があります。

  • SBOM/HBOM(ソフトウェア・ハードウェアの部品表)と部品ロットの追跡
  • セキュアブート、署名付きファームウェア、製造時の鍵注入の手順と所在
  • BMCのソースコードの扱いと脆弱性管理の体制
  • 改ざん検知の仕組み、サプライヤ監査の範囲
  • 故障交換(RMA)時のデータ消去とその証跡

運用面では、遠隔保守の有無と経路、テレメトリの送信先、ファームウェア更新の承認フロー、ネットワーク断時に自律運用できるかを確認します。性能面では、ベンダー公表値をそのまま比較に使わず、比較対象、モデル、精度、バッチサイズ、ソフトウェア条件を含むベンチマーク条件の提示を求めるのが無難です。

9. まとめ

「ソブリンAIサーバ」は、データ・法域・運用・供給網に対する自律性と説明可能性を高めることを狙ったAIサーバを指す市場用語であり、統一された標準定義はまだありません。国内での組立とトレーサビリティは主権を構成する重要な要素ですが、半導体の前工程、ファームウェア、暗号鍵、保守経路、ソフトウェアまで含めて初めて全体像が見えます。

国内ではハードウェアの国内製造に踏み込む事業者と、クラウドや運用で主権を確保する事業者がそれぞれの道を進んでおり、海外でも欧州製CPUと米国製GPUの組み合わせのような「部分的な主権」が現実解になっています。利用者側に求められるのは、自組織にとってどの層の主権が必要かを定義し、ラベルではなく確認項目で製品を比べることです。

火曜日, 9月 15, 2026

耐量子暗号2026 ― 鍵交換は勝負あり、署名はこれから

「量子コンピュータが実用化されたら、今の暗号は全部破られる」——この言い方は、半分正しくて半分間違っています。正しいのは、RSAや楕円曲線暗号といった公開鍵暗号が原理的に危険にさらされるという点。間違っているのは「全部」という部分です。そして、この区別を曖昧にしたまま移行計画を立てると、優先順位を完全に取り違えます。

2024年8月にNISTが最初の3つの耐量子計算機暗号(PQC)標準を確定してから2年が経ちました。この2年で状況は大きく動いています。米国は2026年6月の大統領令で連邦システムの移行期限を2030年/2031年へ前倒しし、日本政府も2025年11月に「原則2035年まで」という方針を打ち出しました。CRYPTRECは2026年3月、電子政府推奨暗号リストに初めてPQCの表を新設しています。もはや「様子見」のフェーズではありません。

結論を先に書きます。いま着手すべきは、暗号インベントリの作成と、TLSの鍵交換のハイブリッド化です。署名と公開PKIは技術的にも制度的にもまだ動いている最中で、こちらを先に急ぐと手戻りします。以下、なぜそうなるのかを標準の現在地から順に見ていきます。

本記事の記述は2026年9月14日時点で確認できた内容です。PQCは標準化と制度整備が同時進行している分野で、特にFIPS 206(FN-DSA)の公開時期、HQCのドラフト、CA/Browser ForumのML-DSA許可、日本政府の工程表は今後数か月で動く可能性があります。時期に関する見通しには筆者や業界の推定が含まれ、確定した予定ではありません。

1. 量子コンピュータは何を壊し、何を壊さないのか

最初に誤解を潰しておきます。量子アルゴリズムが暗号に与える影響は、対象によって質が全く違います。

Shorのアルゴリズムは、素因数分解と離散対数を多項式時間で解きます。これはRSA、楕円曲線暗号、Diffie-Hellmanという、現在の公開鍵暗号のほぼ全てを直撃します。鍵長を伸ばして逃げることができない種類の破壊です。

一方Groverのアルゴリズムは、総当たり探索を平方根分だけ高速化するにとどまります。AESやハッシュ関数に対しては「鍵長や出力長を十分に取れば当面問題ない」という結論になります。CRYPTRECが2026年3月に新設したPQCリストにAES-192/256とSHA-384/512、SHA3-384/512が載っているのは、まさにこの理屈です。既存の共通鍵暗号・ハッシュ関数がそのままPQCリストに入っている。つまり「全部作り直し」ではありません。

もう一つ整理しておきたいのがPQCと量子暗号(QKD)の違いです。この二つは頻繁に混同されますが、別物です。

  • PQC(耐量子計算機暗号):計算量的安全性に基づく。古典コンピュータ上で動く普通のアルゴリズムで、既存のTLSやPKIにソフトウェア更新で組み込める。NISTが標準化しているのはこちら。
  • QKD(量子鍵配送):情報理論的安全性に基づく。専用の光ファイバや装置が必要で、距離と鍵生成レートに制約がある。汎用インターネットの代替にはならない。

日本政府の中間とりまとめも、PQCへの完全移行ではなく既存暗号との併用やQKDの導入を「視野に入れることも考えられる」という書き方をしており、両者は補完関係として扱われています。

では、量子コンピュータの実現時期はどうか。ここは正直に書きます。予測できません。内閣官房の中間とりまとめも「量子計算機により公開鍵暗号の安全性が低下・危殆化する時期を現時点で予測することは困難である」と明記しています。それでも移行を急ぐ理由がHNDL(Harvest Now, Decrypt Later)です。今の通信を記録して保管しておき、将来の量子コンピュータで復号する。保護期間が10年を超えるデータは、量子コンピュータが登場する前から既にリスクにさらされている、という理屈です。実現時期の不確実性は、移行を遅らせる理由にはなりません。

2. NIST標準の現在地——「出揃った」のは第1陣だけ

「NISTのPQC標準はもう確定した」という言い方をよく見ますが、正確には確定したのは3本で、残り2本はまだ途中です。ここを混同すると、まだ最終仕様が固まっていないアルゴリズムを本番実装してしまう事故につながります。

標準 名称(旧名) 用途 数学的基盤 2026年9月時点の状況
FIPS 203 ML-KEM(CRYSTALS-Kyber) 鍵カプセル化 格子(Module-LWE) 2024年8月13日確定。実装・展開が最も進んでいる
FIPS 204 ML-DSA(CRYSTALS-Dilithium) デジタル署名 格子(Module-LWE/SIS) 2024年8月13日確定。汎用署名の第一候補
FIPS 205 SLH-DSA(SPHINCS+) デジタル署名 ハッシュ関数のみ 2024年8月13日確定。格子が破られた場合の保険
FIPS 206 FN-DSA(FALCON) デジタル署名 NTRU格子 2025年8月28日にNISTがドラフト標準を承認手続きに提出。最終版は未公開。業界の見通しは2026年末〜2027年初だが、NISTの手続き次第
(未採番) HQC 鍵カプセル化 符号ベース 2025年3月11日に第2のKEMとして選定。ドラフトは2026年頃、最終化は2027年頃の予定

FN-DSAがなぜ遅れているのかには技術的な理由があります。FALCONの署名生成は浮動小数点演算を使ったガウスサンプリングに依存しており、これを定数時間で安全に実装するのが難しい。サイドチャネル攻撃の温床になりかねないため、NISTは慎重に仕様を詰めています。NISTのpqc-forumでは、ドラフトがNISTと商務省の承認プロセスに入ったまま公開日が読めない状態が続いていると説明されていました。DigiCertのように「ML-DSA/SLH-DSAのドラフト版と最終版で名称やOIDの混乱が起きた経験から、FN-DSAは最終化まで本番環境に実装しない」と公言しているベンダーもあります。妥当な判断だと思います。

HQCの位置づけも誤解されがちです。これはML-KEMの置き換えではなく、数学的基盤の分散が目的です。ML-KEM・ML-DSA・FN-DSAはいずれも格子ベースで、格子問題に大きな突破口が見つかると同時に危うくなる。そこで全く異なる符号ベースの方式をバックアップとして用意しておく、という設計思想です。

この「基盤を分散させる」発想が単なる杞憂でないことは、2022年のSIKE崩壊が示しています。NISTの第4ラウンド候補だった同種写像ベースのSIKEは、古典コンピュータで多項式時間に解かれました。新しい数学的仮定への信頼は、ある日突然崩れることがある。だからこそ、特定アルゴリズムを固定実装せず差し替え可能にしておく「クリプト・アジリティ」が本質的に重要なのです。

3. サイズという現実的な制約

PQC移行で実装者が最初にぶつかるのはサイズです。以下は各方式の生のバイト数(raw値)で、X.509のDER符号化や証明書に格納した場合の実サイズとは異なる点に注意してください。

方式 公開鍵 暗号文/署名 備考
X25519 32 B 32 B 比較の基準となる従来方式
ECDSA P-256 65 B(非圧縮)/33 B(圧縮) 署名 約64〜72 B 署名長はDER符号化で変動。Ed25519の公開鍵は32 B
RSA-3072 法 n が384 B 署名 384 B SubjectPublicKeyInfo全体はこれより大きい
ML-KEM-768 1,184 B 暗号文 1,088 B 実運用の事実上の標準パラメータ
ML-KEM-1024 1,568 B 暗号文 1,568 B NSA CNSA 2.0が指定するパラメータ
ML-DSA-44 1,312 B 署名 2,420 B ECDSA署名の約35倍。証明書チェーンへの影響が大きい
ML-DSA-87 2,592 B 署名 4,627 B CNSA 2.0指定
FN-DSA(Falcon-512) 897 B 署名 約0.7 KB(可変長) PQC署名で最小級。圧縮署名は可変長で、正確な最大長はFIPS 206最終仕様による
SLH-DSA 32〜64 B 署名 約7.9 KB〜約49 KB パラメータにより幅が大きい。公開鍵は極小だが署名が巨大
「Category 3=192ビット安全」ではありません。NISTのセキュリティカテゴリは、攻撃に必要な計算資源を既知の対称暗号と比較するための区分です。CRYPTRECの定義でも、Category 3は「192ビット鍵を持つブロック暗号に対する鍵探索と同程度以上の計算資源が攻撃に必要」という意味であり、あらゆる攻撃モデルで厳密に192ビットの安全性を持つという意味ではありません。

なお、ML-KEMは「重いから遅い」わけではありません。鍵生成・カプセル化・復号はいずれもマイクロ秒級で、演算そのものはむしろ高速です。問題になるのは計算量ではなくネットワークに乗るバイト数です。TLSのClientHelloが1パケットに収まらなくなる、ロードバランサやWAFが大きなハンドシェイクを想定していない、といったところで詰まります。

4. 主戦場はTLSの鍵交換——ここは既に勝負がついている

PQC移行の中で、鍵交換だけは別格に進んでいます。理由は単純で、HNDL対策として最も効果が高く、しかも証明書やPKIといった制度的な手続きを経由せずにクライアントとサーバの実装更新だけで完結するからです。

事実上の標準になったのがX25519MLKEM768です。従来のX25519とML-KEM-768を連結したハイブリッド方式で、両方の共有秘密をKDFに通して鍵を導出します。2026年8月にRFC 10024(Proposed Standard、全9ページ)として標準化されました。同RFCはX25519MLKEM768のほか、SecP256r1MLKEM768とSecP384r1MLKEM1024を定義しています。後者2つはNIST曲線を要求するコンプライアンス環境向けで、IETFとしての推奨(Recommended Y)が付いているのはX25519MLKEM768のみです。

RFC番号を混同しやすいので整理しておきます。RFC 9794はPQ/Tハイブリッドの用語を定義したInformational RFC、RFC 9954はTLSにおけるハイブリッド鍵交換の一般的な構成を定義した文書、RFC 10024がX25519MLKEM768などの具体的な方式を定義したものです。実装で参照すべきはRFC 10024です。

ハイブリッドの安全性については、雑に「両方破らないと解読できない」と書かれることが多いのですが、もう少し正確には「適切なcombinerとダウングレード防止機構を備えた設計であれば、構成方式の少なくとも一方が安全である限り機密性が保たれることを目指す」というものです。設計次第では成り立たないので、自前で組み合わせを作るのは避けるべきです。

RFC 10024のClientHello側の鍵共有サイズはX25519MLKEM768で1,216バイト(ML-KEM部1,184+X25519部32)、サーバ側が1,120バイトです。X25519単体の32バイトと比べれば劇的に大きいものの、実運用に耐える範囲に収まっています。

普及の速度は、正直なところ予想を超えています。Cloudflareの公開データによると、同社を経由する人間由来のHTTPSトラフィックのうちPQC鍵交換で保護された割合は、2025年初頭の29%から2025年12月初頭に52%へ倍増し、2026年4月時点で約67%に達しています。Chrome 131とFirefox 132が既定でX25519MLKEM768を提示するようになったことが効いています。

ただし、これは「クライアントからCDNまで」の話です。CloudflareがスキャンしたオリジンサーバのPQC対応率は約9〜10%にとどまります(2025年初頭は1%未満だったので10倍以上の伸びではあります)。エッジまではPQCで守られていても、そこから先の自社サーバまでの区間は従来暗号のまま、という構図が当たり前に存在している。自社のサーバ側TLS設定を確認するのが、実は一番手近な宿題です。

5. 署名と公開PKIが本当の難所

鍵交換が順調な一方、署名側は明確に遅れています。2026年9月時点で、ブラウザの信頼ストアに入った公開PKIのML-DSA証明書はまだ存在しません。

CA/Browser ForumのServer Certificate Working Groupでは、公開信頼TLSサーバ証明書でML-DSAを許可するballotが2026年5月時点でまだ議論中でした。証明書透明性(CT)ログへの影響や、そもそも従来型X.509証明書をPQC移行の器とすべきかという根本論点で意見が割れています。Microsoftは自社のML-DSA X.509証明書パイロットを進める意向を示しつつ、こうした証明書をCTログから除外することを提案していました。

一方で、動いている領域もあります。S/MIMEについては、Ballot SMC013により2025年8月22日にS/MIME Baseline Requirements v1.0.11が採択され、ML-DSAとML-KEMを使うPQC証明書が既に許容されています(ハイブリッドではない単一鍵方式)。また、プライベートPKI向けのML-DSAトラストアンカー対応はChrome 150で提供される予定とされています。

この状況から導かれる実務的な結論ははっきりしています。

  • 内部PKI・社内mTLSは今すぐML-DSAを試せる。ブラウザの信頼ストアに依存しないため、制度待ちにならない。
  • コード署名・ファームウェア署名は優先度が高い。2026年に署名したバイナリが10年以上動き続ける世界では、検証側の入れ替えに時間がかかることを見越して早く着手する必要がある。
  • 公開WebのTLSリーフ証明書は、CA/Browser Forumのベースライン改定とブラウザのルートプログラム対応を待つしかない。ここを前倒ししようとしても空回りする。

なお署名PQCの実装例としては、Cloudflareが1.1.1.1のDNSSEC検証にML-DSA-44を導入しています。2,420バイトの署名をDNSでどう扱うかという、まさにサイズ問題と正面から向き合った事例です。

6. 各国ロードマップ——「2035年」は同じ言葉で中身が違う

主要国の期限は「2030年代前半に高優先度システム、2035年前後に全体移行」という点で似た形をしていますが、対象範囲も拘束力も、そもそも「非推奨」と「禁止」の定義も国ごとに違います。横並びの表で見ると同じに見えてしまうので、性格の違いを併記します。

主体 文書 主なマイルストーン 性格
NIST(米) IR 8547(2024年11月、初期公開ドラフト) 112ビット安全性(RSA-2048、P-256など)は2030年以降「非推奨」、2035年以降「使用不可」。128ビット以上も2035年以降は使用不可 ドラフト。それ自体に法的拘束力はないが、後続の大統領令・OMB通達が参照
米大統領令 EO 14412(2026年6月22日署名) HVA(高価値資産)・高影響システムについて、鍵確立を2030年12月31日、署名を2031年12月31日までにPQC化。連邦調達業者も2030年末までにPQC FIPS準拠。NISTは自組織のパイロットを2027年12月31日までに完了 連邦民生機関への指令。国家安全保障システム(NSS)は対象外
米OMB M-26-15(2026年6月24日) 各機関はPQC移行責任者を2026年7月下旬までに指名し、移行計画を2026年10月22日までに提出。以降、棚卸し・計画(〜2027年)、試行(〜2028年)、鍵確立(〜2030年)、署名(2031年)、残存システム(〜2035年)の段階。TLS 1.3以降の対応を2030年1月2日までに要求 EO 14412の実装通達。M-23-02を実質的に置き換え
NSA(米) CNSA 2.0 ML-KEM-1024/ML-DSA-87/AES-256/SHA-384・512を指定。ソフトウェア署名やネットワーク機器から段階的に排他利用へ移し、2035年にNSS全体の移行完了 NSSを対象とするNSAの指針。カテゴリ別に期限が異なる
EU 協調ロードマップ(2025年6月、NIS協力グループ) 2026年に準備開始、2030年に高リスク用途、2035年に可能な限り全体移行 リスクベースの勧告。加盟国ごとに実装が分かれる
英NCSC PQC移行タイムライン(2025年3月) 2028年までに棚卸しと計画、2031年までに高優先度システム、2035年までに全体移行 ガイダンス。ML-KEM-768、ML-DSA-65を基本線とする
日本 中間とりまとめ(2025年11月20日、内閣官房国家サイバー統括室) 政府機関等について原則2035年までの移行を目指す。2026年度に工程表を策定 方針表明。現時点で禁止規定や中間期限の設定はない

この表で注目すべきは、米国だけが明確に前倒ししている点です。EO 14412以前の米国の姿勢は「2035年までにできる限り量子リスクを緩和する」という目標ベースでしたが、2026年6月の一連の文書で高価値資産については2030年/2031年という期限に置き換わりました。連邦調達業者にも2030年末の要件がかかるため、米国政府に納入するサプライチェーンには実質的な強制力が及びます。

また、EO 14412はNIST・CISAに対し、2027年3月までに連邦CBOM(Cryptography Bill of Materials、暗号部品表)の最小要素を定めるよう指示しています。SBOMの暗号版です。今後、政府向けベンダーには「自社製品がどの暗号アルゴリズムをどこで使っているか」を標準形式で提出することが求められるようになる可能性が高い。日本企業にとっても他人事ではありません。

7. 日本の現在地——リストは動いた、期限はこれから

日本の動きで最も実務に効くのは、2026年3月30日のCRYPTREC暗号リスト改定です。「電子政府における調達のために参照すべき暗号のリスト」(CRYPTREC LS-0001-2022R2)の電子政府推奨暗号リストに「表2 耐量子計算機暗号(PQC)リスト」が新設されました。内容は以下の通りです。

技術分類 名称 パラメータセット
公開鍵暗号 - 署名 該当なし
公開鍵暗号 - 鍵共有 ML-KEM ML-KEM-768(Category 3)、ML-KEM-1024(Category 5)
共通鍵暗号 AES AES-192(Category 3)、AES-256(Category 5)
ハッシュ関数 SHA2 / SHA3 SHA-384(Category 4)、SHA-512、SHA3-384(Category 4)、SHA3-512

読み取るべきポイントが3つあります。

第一に、掲載されたのはML-KEM-768と1024だけで、ML-KEM-512は入っていません。「新規案件ではML-KEMを既定に」と言うときは、日本政府向けならパラメータを768以上にする必要があります。

第二に、署名は「該当なし」です。ML-DSAもSLH-DSAも、NISTでは2024年に確定済みですが、CRYPTRECの推奨リストにはまだ載っていません。表の枠だけ用意して空欄にしてある、という状態です。CRYPTRECは2025年度報告書で、PQCリストへの追加を引き続き検討中としており、PQCに関するワーキンググループでガイドラインと研究動向調査報告書の2026年度版を作成する方針を示しています。

第三に、暗号強度要件の設定基準は当面この表2の公開鍵暗号には適用されません。従来の鍵長ベースの基準がPQCには噛み合わないためで、2026年度に設定基準そのものの改定を進めるとされています。

政府方針としては、内閣官房国家サイバー統括室(NCO)が2025年11月20日に「政府機関等における耐量子計算機暗号(PQC)への移行について(中間とりまとめ)」を公表しました。原則2035年までの移行を目指し、2026年度に工程表を策定するという内容です。同文書は移行の準備・開発コストと所要期間が膨大になりうることに触れ、クリプト・インベントリの構築(移行対象の詳細な把握)を検討の前提に置いています。加えて、PQC実装時のセキュリティ対策が現状では不十分であることを理由に、クリプト・アジリティの確保や既存暗号との併用、QKDの導入も選択肢として挙げています。

金融分野は比較的先行しています。金融庁は2024年7〜10月に「預金取扱金融機関の耐量子計算機暗号への対応に関する検討会」を開催し、2024年11月26日に報告書を公表しました。3メガバンク、全銀協、地銀協、日銀金融研究所などが参加し、優先度の高いシステムを2030年代半ばまでにPQC利用可能な状態にすること、暗号利用箇所の棚卸しに早期着手することなどを求めています。

総じて日本の立ち位置を評価するなら、「方針とリストの整備は着実、期限の具体性と強制力は米国に比べて弱い」というところでしょう。中間とりまとめ自身が、諸外国に比べて移行が遅れれば安全保障上の支障が懸念されるという認識を示しています。2026年度の工程表がどこまで踏み込むかが次の焦点です。

8. ベンダー・製品の対応状況

製品・サービス 鍵交換 署名・証明書 備考
OpenSSL 3.5(2025年4月、LTS) ML-KEMをネイティブ実装。既定でX25519MLKEM768を優先提示 ML-DSA、SLH-DSAをネイティブ実装 最も影響範囲が広い。ただし本体での利用可能性とFIPS ProviderのCMVP検証状況は別問題
Chrome / Firefox Chrome 131(2024年11月)、Firefox 132(2024年10月)で既定化 プライベートPKI向けML-DSAトラストアンカー対応がChrome 150で提供予定 クライアント側の既定化が普及率を押し上げた主因
AWS KMS等へのハイブリッドPQ TLS対応 AWS Private CAがML-DSA証明書に対応(2025年11月) サービス側の対応と、利用者の通信が実際にPQC化されているかは別。SDK側で明示的に有効化が必要な構成がある
Microsoft SymCryptにML-KEM。Windows/Linuxへ展開 CNG/ADCSでML-DSA。ML-DSA X.509のパイロットを推進 CA/Browser ForumのML-DSA ballotを支持する立場
Cloudflare エッジ・オリジン間でX25519MLKEM768を展開 1.1.1.1のDNSSEC検証にML-DSA-44を導入 Radarで採用率を公開。オリジン対応率の可視化も提供
Signal PQXDH(2023年)に加え、SPQRを組み込んだTriple Ratchet(2025年10月2日) ML-KEMを採用。初期鍵確立だけでなく会話中のラチェットまでPQC化した点が新しい
Apple iMessage PQ3(2024年)。iOS 26/macOS TahoeでX25519MLKEM768に対応 PQ3の「レベル3」はApple独自の分類であり、NISTやIETFの共通評価基準ではない

この表を見て「主要ベンダーは対応済み」と結論づけるのは早すぎます。対応範囲、既定で有効かオプトインか、FIPS検証の有無、署名・証明書まで含むかは製品ごとにバラバラです。「PQC対応」という一言が何を指しているのかは、製品ドキュメントで個別に確認する必要があります。特にHSM、PKI製品、組込み機器は、ソフトウェアライブラリより一段遅れると考えておくのが安全です。

9. 何から手をつけるか

実務の順序としては、以下が妥当だと考えます。

  • 暗号インベントリ/CBOMの整備。RSA・ECC・DHをどこで使っているかの棚卸し。TLS、VPN、コード署名、内部認証、証明書、HSM、アプリケーションコード。これがないと移行計画は立てられません。米国のCBOM標準化(2027年3月まで)も見据えて、機械可読な形式を意識しておくと後で効きます。
  • 長期機密データの特定とHNDLリスク評価。保護期間が長いデータほど優先度が上がります。10年後に漏れても困らないデータと、30年後でも困るデータを分ける作業です。
  • TLS・VPN等の鍵確立をハイブリッド化。標準・製品・認証要件が整っている環境では、X25519MLKEM768を優先候補に。日本政府向け調達を意識するならML-KEM-768以上。
  • 経路上の機器の検証。MTU、ClientHelloのフラグメント、ロードバランサ、WAF、プロキシ、HSM。ここで詰まるケースが実際に報告されています。
  • 内部PKI・コード署名でML-DSAを評価。公開Web PKIを待たずに始められる領域です。
  • 公開Web PKIは制度の動きを待つ。CA/Browser Forumだけでなく、ブラウザのルートプログラム、TLS実装、証明書サイズ、失効基盤まで揃って初めて実用になります。
  • クリプト・アジリティの確保。ML-KEMやML-DSAを固定実装せず、将来HQCやFN-DSAへ差し替えられる設計にしておく。OpenSSLのEVPのような抽象化層を経由させ、アルゴリズム選択を設定で変えられるようにするのが基本です。

判断を切り替える目安として、以下のイベントをウォッチしておくとよいと思います。

  • CA/Browser ForumがTLSサーバ証明書でML-DSAを許可 → 公開証明書の移行計画を起動
  • FIPS 206(FN-DSA)の最終化 → 帯域制約のある用途で署名方式を再評価
  • CRYPTRECが署名アルゴリズムをPQCリストに追加 → 日本政府向け調達要件の更新
  • 2026年度の政府工程表の公表 → 自組織の期限設定の根拠として参照

まとめ

耐量子暗号の移行は、「量子コンピュータが完成してから対応する」という選択肢が構造的に存在しない、珍しい種類の課題です。HNDLがある以上、脅威の実現時期を待つことは、その分だけ既に失われたデータを増やすことを意味します。

その上で、現実的な優先順位ははっきりしています。鍵交換は既に実用段階に入っており、標準(RFC 10024)も実装(OpenSSL 3.5、主要ブラウザ)も揃っています。Cloudflareの計測で人間由来トラフィックの3分の2がPQCで保護されている一方、オリジンサーバ側の対応が1割程度にとどまっているという非対称は、そのまま「自社サーバの設定を見直せ」というメッセージとして読めます。

対照的に、署名と公開PKIはまだ制度が動いている最中です。FIPS 206は未確定、CRYPTRECの署名欄は空欄、公開信頼のML-DSA証明書はゼロ。ここを焦っても手戻りするだけで、いま投資すべきは個別アルゴリズムの実装ではなく、何が使われているかを把握する仕組みと、後から差し替えられる設計です。

SIKEが2022年に崩壊したことを思い出せば、今日「安全」とされているアルゴリズムが10年後も安全である保証はどこにもありません。PQC移行の本質は、特定のアルゴリズムへの乗り換えではなく、アルゴリズムを乗り換えられる組織になることなのだと思います。