ラベル 情報セキュリティ の投稿を表示しています。 すべての投稿を表示
ラベル 情報セキュリティ の投稿を表示しています。 すべての投稿を表示

木曜日, 11月 05, 2026

YATA-Shieldは今どうなっているか:サイバー対処能力強化法の施行とGlasswingからCVPへ

前回の記事(2026年5月29日)は、Project YATA-Shieldが公表された直後の整理でした。それから約5か月がたち、政府の年次計画や予算方針、10月の法施行、Anthropic側のプログラム再編と、周辺が大きく動いています。今回は政府資料とAnthropicの公式発表に当たり直し、何が続き、何が変わり、前回記事のどこを直すべきかをまとめます。

結論から言うと、YATA-Shieldは単発の注意喚起では終わりませんでした。7月31日の「サイバーセキュリティ2026」で、2026年度の「特に強力に取り組むべき施策」に位置付けられています。一方、Glasswingは10月にCyber Verification Program(CVP)へ統合され、10月1日にはサイバー対処能力強化法の官民連携とアクセス・無害化措置が施行され、10月26日には相次ぐ情報漏えいを受けて首相が緊急対策パッケージの取りまとめを指示しました。

変わっていないのは、AIで脆弱性の発見が速くなっても、確認・開示・修正が追いつかないという構図です。Anthropicは5月の初期報告でこの点を述べ、10月の発表でも修正数の把握が追いついていないと書いています。

本記事は2026年11月5日時点の公開情報に基づきます。政府資料とAnthropicの公式発表を一次情報とし、報道のみで確認できる事項は「報道」と明記しています。見通しや評価に当たる部分は筆者の推定です。

1. YATA-Shieldとは何だったか(5月時点のおさらい)

2026年5月18日に公表された、AI性能の高度化を踏まえた政府全体のサイバーセキュリティ対策パッケージです。国家安全保障局、国家サイバー統括室(NCO)、内閣府、警察庁、金融庁、デジタル庁、総務省、外務省、文部科学省、厚生労働省、経済産業省、国土交通省、防衛省の14府省庁・機関(部局)が連名で出しました。製品ではなく政策パッケージで、「重要インフラ事業者等・政府機関等への対応」(4施策)と「脆弱性の発見・修正等への対応」(5施策)の2本柱です。

本文の末尾には、関係省庁・機関が施策の実施状況を機動的に確認し、追加の対応を不断に検証・実施すると書かれています。つまりローリング型の設計です。今回の問いは、そのローリングが実際に回ったのか、です。

2. 5月から11月までの動き

日付 動き 根拠の種類
5/18 YATA-Shieldを公表。14府省庁・機関が連名で、4施策+5施策を示した 政府資料
5/22 Anthropicが「Glasswing初期報告」を公表(前回記事は5/26と記載)。約50のパートナーが1か月で1万件超の高・致命的な脆弱性を見つけたと説明 Anthropic公式
6/2 Anthropicが、Glasswingを約150の追加組織へ広げると発表。各組織はアクセス前にセキュリティ要件を満たす必要がある Anthropic公式
6/3、8/27 日本政府と一部の金融機関がMythosのアクセス権を得たと、松本デジタル相(当時)が説明(6/3)。8/27には、メガバンク3行が使えるようになったと共同通信・日経が報じた 報道(契約内容などの詳細は公式には非開示)
6/12〜7/1 米商務省の輸出管理指令を受け、AnthropicがFable 5とMythos 5へのアクセスを停止。6/30に管理が解除され、7/1にアクセスを復旧 Anthropic公式声明
7/31 戦略本部が「サイバーセキュリティ2026」と令和9年度予算重点化方針を決定。YATA-Shieldを2026年度の「特に強力に取り組むべき施策」に位置付け 政府資料
9/17 内閣改造で、古川俊治氏がデジタル相兼サイバー安全保障担当相に就任(前任は松本尚氏) 就任発表・報道
10/1 サイバー対処能力強化法等の官民連携・アクセス無害化措置が施行。重要インフラ統一基準も施行(16分野) 政府資料・報道
10/6 AnthropicがCVPを3階層に拡張し、Glasswingを統合 Anthropic公式
10/26 第1回「サイバーセキュリティに関する関係閣僚会議」。首相が緊急対策パッケージを来週中を目途に取りまとめると表明 首相官邸・報道

3. 政府の位置付け:年次計画・予算方針・10月施行

3-1. 年次計画と令和9年度予算方針

7月31日に決定された「サイバーセキュリティ2026」は、日本成長戦略の分野横断的課題としてのサイバーセキュリティとあわせて、YATA-Shieldを2026年度の「特に強力に取り組むべき施策」に位置付けています。同日決定の令和9年度予算重点化方針も、YATA-Shieldに基づいてAIを活用した政府全体の重要システムの脆弱性点検などを速やかに実施すること、AISIの機能を抜本的に強化することを挙げています。

ただし、この方針は概算要求に向けた重点化の考え方で、予算の成立を意味しません。9月30日のNCO資料も、AIを活用したサイバー対処能力の強化等の事業を令和9年度予算で要求中と書くにとどまります。また、YATA-Shield本文には期限付きの数値目標が見当たりません。数値目標があるのは隣接する日本成長戦略の側で、必要な防護策を実施できている重要インフラ事業者等の割合を2031年度末までに100%にするというものです。

3-2. 10月1日に施行されたもの

  • サイバー対処能力強化法等:基幹インフラ事業者(経済安全保障推進法の特定社会基盤事業者。15分野・258事業者)に、資産の届出とインシデント報告の義務がかかり始めました。官民連携の協議会には約100組織が加わる予定で、アクセス・無害化措置も10月1日からです。導入済みの特定重要電子計算機の届出期限は来年3月までです。
  • 通信情報の利用:施行は来年秋です。年次計画は2027年11月までに施行されると記しています。
  • 重要インフラ統一基準:10月1日に施行され、行動計画も改定されました。INTERNET Watchによると、対象は情報通信、金融、航空、空港、鉄道、電力、ガス、行政サービス、医療、水道、物流、化学、クレジット、石油、港湾、郵便の16分野です。PwC Japanの解説は、この基準自体は事業者への直接の強制力を持たないものの、今後は所管省庁の安全基準などに反映されうると説明しています。

ここは混同しやすいので区別しておきます。法的な届出・報告義務がかかる「基幹インフラ」(15分野258事業者)と、行動計画・統一基準で防護する「重要インフラ」(16分野)は別の枠組みです。前回記事の「重要インフラ15分野」は、10月以降は郵便が加わって16分野になりました。

もう一点。NCOは、国が入手した未公表を含む脆弱性情報と、届出された資産を突き合わせ、該当する事業者に個別に注意喚起するとしています。AIで加速する脆弱性の悪用に対抗するという位置付けで、YATA-Shieldが求める「脆弱性がより高速かつ大量に見つかる前提での対策強化」を、国の側から支える仕組みと読めます(筆者の解釈)。

4. Anthropic側の変化:GlasswingからCVPへ

Glasswingは4月7日、ローンチパートナー12組織(Anthropic自身を含む)に、重要ソフトウェアを手がける40超の組織が加わる形で始まりました。5月22日の初期報告時点で約50パートナー、6月2日には約150の追加組織への拡大が発表されています。そして10月6日、Anthropicはこれを既存のCVPと一本化し、3階層のプログラムに再編しました。

  • Defense Access:SOC、インシデント対応、マルウェア解析、脆弱性の分析・検証といった防御業務向けです。規模を問わない重要インフラの運用者(地域の病院や自治体運営の公益事業者など)も対象例に挙がっています。回答は数日を目標とするとされています。
  • Red Team Access:承認された範囲での侵入テストやレッドチームが対象です。組織単位に限られ、審査は数週間です。ランサムウェアの展開や物理的損害につながる行為などは、リアルタイムでブロックされます。
  • Specialized Access:ブロックが最も少ない階層です。航空機の運航システム、電力網、通信網、銀行間送金基盤、政府の行政ネットワークなど、人命や市場に影響しうるシステムを試験できる、限定された組織向けです。米国政府と協力して組織ごとに詳細に審査され、既存のGlasswingメンバーは再承認なしでここへ移ります。

対象モデルはClaude Opus 5.5、Sonnet 5.5、Mythos 5.1です。データ保持は、不正利用を監視するため原則として必須です。ただし例外があります。エンタープライズ向けの新しい仕組みEnterprise Frontier Safeguards(EFS)が提供されるまでの間、Fable 5.1またはMythos 5.1をゼロデータ保持で使える組織は、CVPもゼロデータ保持で使えます。調達や機密情報の扱いに直結するため、検討する場合はここを必ず確認してください。提供基盤はClaude Platform、Vertex AI、Microsoft Foundryで、Amazon BedrockはEFSの対象顧客に限られます。

日本の視点では、6月の出来事も見ておく必要があります。6月12日の米商務省の輸出管理指令でFable 5とMythos 5が止まり、6月30日に管理が解除され、7月1日にアクセスが復旧しました。国の防御手段になりうるツールの提供が、他国の政策判断で止まりうることを示した事例です。特定の1モデルに頼らず、複数の手段を持つ設計が望ましいというのが筆者の見方です。

5. 脆弱性件数の読み方

Glasswing関連の数字は、性格の違うものが並んでいます。混ぜて読むと実態を誤ります。まず5月22日時点のOSSスキャンで、外部評価が済んだ分の内訳です。

モデルが高・致命的と推定したOSSの脆弱性のうち、外部評価が済んだ分(2026年5月22日時点、Anthropic公表)

評価済み
1,752件
真陽性
1,587件(90.6%)
高・致命的と確認
1,094件(62.4%)
  • 1万件超(5/22):約50パートナーが1か月で見つけた「高・致命的な脆弱性」の合計です。公式の表現は脆弱性で、すべてをゼロデイと言っているわけではありません(4月7日の発表は、数千件のゼロデイ脆弱性を見つけたと表現しています)。
  • 23,019件と6,202件(5/22):1,000超のOSSプロジェクトをスキャンして、モデルが推定した全重大度の件数と、そのうち高・致命的と推定した件数です。人手で検証済みの数字ではありません。
  • 1,752件、1,587件、1,094件(5/22):6,202件のうち、6つの独立したセキュリティ研究会社(少数はAnthropic自身)が評価できた分です。真陽性のすべてが高・致命的だったわけではありません。
  • 12.9万件と5,500件、うち3.3万件超が高・致命的(10/6):パートナーが4〜7月に見つけた検証済み脆弱性が少なくとも12.9万件、Anthropic自身のOSSスキャン(4〜10月)が5,500件で、このうち3万3千件超が高・致命的と評価されています。ただし33件のパートナー報告とOSS連携に基づく部分データです。Anthropicは過小評価の可能性が高く、実際の影響は少なくとも5倍と見込んでいます(同社の見立て)。
  • 修正の進み具合:5/22時点で、開示済みの高・致命的530件のうち75件がパッチ済みでした。10/6の発表では、パッチ数を開示したパートナーが半数未満で、修正率は大きく過小に見えるとしています。「修正が少ない」と「残りは未修正」は別の話で、数字だけでは区別できません。なお「平均2週間」は、高・致命的バグ1件のパッチに要する平均期間の説明で、全候補が2週間で直るという意味ではありません。

6. 金融分野と「日本版グラスウィング」

金融庁は4月24日、日銀総裁、NCO、3メガバンクのトップ、日本取引所グループなどが出席する官民連携会議を開きました。席上、片山大臣が実務者レベルの作業部会の設置を提案し、出席者全員の賛同で設置されています。金融庁の広報誌は、大臣がこの作業部会を、いわば金融の「日本版プロジェクト・グラスウィング」と説明したと伝えています。作業部会は5月14日に開催されました。

参加組織は金融庁が一覧で公表しています(8月28日更新)。金融機関等6社、IT事業者等13社(AI開発事業者のAnthropic JapanとOpenAI Japanを含む)、業界団体、政府機関等(AISI、NCO、財務省、日本銀行、金融庁)という構成です。作業部会の議論の詳細は、サイバーセキュリティに関わるため非公表です。

呼称の補足です。「日本版Glasswing」はYATA-Shield全体の名称ではなく、政府文書上の正式名称でもありません。ただし、金融の作業部会について大臣自身がこの言い方を使っています。「公式名ではない」ことと「政府が使っていない」ことは別の話でした。

メガバンクのMythos利用は、6月3日に政府と一部の金融機関がアクセス権を得たと説明され、8月27日に3行が使えるようになったと共同通信・日経が報じました。いずれも各行やAnthropicの公式発表は確認できていません。報道の文面は「27日に分かった」というもので、実際の利用開始日までは読み取れない点にも注意が必要です。

7. 10月の漏えい連鎖と、10月26日の閣僚会議

10月に入って国内企業の情報漏えいが相次ぎ、政府は10月26日に第1回「サイバーセキュリティに関する関係閣僚会議」を開きました。首相官邸の発言要旨と報道によると、高市首相は、被害企業への支援強化、各省庁からNCOへの情報集約、AISIの知見も活用した高性能AIによる脆弱性チェックの前倒しなどを指示し、来週中を目途に政府として「緊急対策パッケージ」を取りまとめると表明しました。共同通信は、攻撃元サーバへの無害化措置を含む対処オプションを戦略的に実行する考えも示したと報じています。

11月5日時点で、緊急対策パッケージが正式に決定されたという発表は、筆者が確認できた範囲では見当たりません。YATA-Shieldを名指しで引き継ぐのかどうかも未確認です。また、個々の漏えい事案で攻撃にAIが使われたかどうかを示す公的資料は、今回確認した範囲にはありませんでした。YATA-Shieldの想定と今回の事案を安易に結びつけない方が安全だと考えます(筆者の見解)。

8. 前回記事の答え合わせ

前回記事の記述を、今回確認した一次資料と照らしました。○は一致、△は更新や補足が必要、×は訂正が必要、?は今回確認できなかったものです。

前回記事の記述 今回確認できたこと 判定
14府省庁・機関、2本柱・9施策、YATAの由来 政府資料と一致 ○
英国AISI評価、CyberGym 83.1%(Opus 4.6は66.6%)、OpenBSD 27年前・FFmpeg 16年前の事例 AnthropicのGlasswingページに直接掲載された数値・事例と一致。FreeBSDのCVE-2026-4747は今回確認できなかったため、本記事では扱わない ○(FreeBSDは?)
初月で1万件以上の高・致命的「ゼロデイ」 5/22の公式表現は「高・致命的な脆弱性」で、ゼロデイとは限定していない。ゼロデイという語は、4/7発表の「数千件」についての表現 △
5/26にAnthropicが初期報告を公表/CVDダッシュボードは5/22時点で281プロジェクト・1,596件 初期報告の公表日は5/22。ダッシュボードの数値は、過去時点の記録を確認できなかった 日付は×、数値は?
Glasswing参加機関は約50(Cloudflareなどを列挙) ローンチ12組織(Anthropic含む)に40超が加わり約50。Cloudflareはローンチ12組織ではないが、初期報告で成果が紹介された参加組織。その後6/2に約150が追加され、10/6にCVPへ統合された △
重要インフラ15分野 10/1から郵便が加わり16分野(報道)。法的義務がかかる基幹インフラ(15分野258事業者)は別の枠組み △
サイバー対処能力強化法は10/1に本格施行 10/1は官民連携・資産届出・インシデント報告・アクセス無害化措置。通信情報の利用は来年秋(2027年11月までに) △
YATA-Shieldは能動的サイバー防御の「実装プラットフォーム」 本文は、協議会の枠組みの下でIPA・AISIと連携し情報共有等を強化すると書くのみ。能動的サイバー防御の実装は強化法等の側にある △(言い過ぎ)
金融の作業部会は5/14、36組織。「日本版Glasswing」は公式名ではない 5/14開催は金融庁が公表。参加組織は一覧で公表されているが「36」は金融庁ページで確認できず。呼称は正式名称ではないが、片山大臣が4/24に作業部会について使用 △
中小企業・サプライチェーン下流は直接対象外 ベンダ向け注意喚起は、ソフトウェアを開発・提供・運用する主体を広く対象とし、クラウドサービスやシステムの構成要素も含む。企業規模による除外はない ×

出典:NCO、サイバーセキュリティ2026、金融庁、Anthropic公式ページ(2026年11月5日確認)

なお、前回記事の行動計画(協議会への参加など)は、10月1日に協議会が約100組織で始まったことで実際の段階に入っています。

9. 今後の見通しと実務への示唆

確定している予定と、見込みの段階のものを分けます。

  • 11月上旬(見込み):緊急対策パッケージ。決定は未確認です。
  • 2027年3月:基幹インフラ事業者が、導入済みの特定重要電子計算機を届け出る期限です。
  • 令和9年度予算:AISIの機能強化とAI活用のサイバー対処能力の事業が要求段階です。
  • 2027年秋:通信情報の利用規定が施行されます(2027年11月までに)。
  • 今秋以降:AnthropicがEFSを提供する予定としています。

実務への示唆は、筆者の見解として次の4点です。

  • ソフトウェアを開発・提供・運用する側は、SaaSや受託開発を含め、規模にかかわらず注意喚起の対象です。リリース前後の脆弱性確認にAIを使うことと、パッチ提供の迅速化が求められています。
  • Mythosを使えるかどうかを出発点にしないことです。政府文書が求めているのは、基本的な対策の確実な実施と、脆弱性がより高速かつ大量に見つかる前提での対策強化です。
  • CVPなどのAIツールを使う場合は、階層とデータ保持の要件を先に確認します。
  • 発見数が増えても、修正が追いつかなければリスクは下がりません。自社の脆弱性対応で、検知から適用までの時間を計測し、短縮の目標を置くのが現実的です。

10. まとめ

YATA-Shieldは、年次計画と予算方針に組み込まれ、10月の法施行と統一基準で受け皿が整い、ローリング型として動き続けています。一方で、Anthropic側の枠組みはGlasswingからCVPへ広がり、米国の輸出管理で供給が止まった事例も生まれました。発見が速くなるほど、修正と運用の速度が問われます。11月上旬に見込まれる緊急対策パッケージが、その運用面にどこまで踏み込むのかが、次の注目点です。

参考資料

火曜日, 10月 27, 2026

IDCFクラウドとGMOデスクトップクラウド:2つの事案を公表情報で整理する(10月27日夜時点)

先日公開した記事「IDCFクラウド・ランサムウェア事案を整理する:ISMAP登録サービスで何が起きたか」は、10月9日夜時点の情報に基づくものでした。その後、10月27日にIDCフロンティアが第7報で一連の調査の完了を公表し、侵入経路が公式に説明されました。同じ時期には、GMOインターネットグループの「お名前.com デスクトップクラウド」への不正アクセスと恐喝が進んでいます。

本記事は、公表された情報をもとに、元記事からの変化とGMO事案を整理した続報です。結論を先に書きます。

  • IDCF:侵入経路の概要が公表されました。第7報によれば、IDCFクラウドポータルの認証システムで使っていたOSSの脆弱性を突かれて侵入され、管理コンソール経由で仮想化基盤の管理者権限を取得されました。OSSの名称や脆弱性識別子は公表されていません。
  • IDCF:データの流出は確認されていません。仮想サーバー内のデータの外部流出は確認されていません。一方、ポータルの登録情報は最大71社分に不正な照会があり、ログインパスワードが最大4件、不正に変更されていました。バックアップデータを取り出せる顧客は、495のうち206です。
  • ISMAP:「未決定」のままです。10月27日夜時点で、IDCFの登録一時停止や再監査の公表は、筆者が確認できた範囲ではありません。
  • GMO:進行中の事案です。影響の可能性があるサーバーは26,739件(確認された被害件数ではなく、上限の数字です)。10月27日には攻撃者とみられる者による情報公開が確認され、同日夜の第12報で、特別見舞金と総額100万米ドルの懸賞金が公表されました。
  • 両事案の関連を示す公開根拠は、確認できません。
本記事は2026年10月27日夜時点(GMOの第12報は19時10分時点)の公開情報に基づきます。GMO事案は進行中で、内容が短時間で変わる可能性があります。公式発表を一次情報とし、報道に基づく部分はその旨を書いています。評価や見通しは筆者の見解です。

1. IDCF第7報で分かったこと

IDCFは10月27日、第7報で一連の調査の完了を公表しました。元記事の公開時点(10月9日夜)と比べると、次の点が変わっています。

論点 10月9日夜時点(元記事) 第7報(10月27日) 補足
侵入経路 未公表 IDCFクラウドポータルの認証システムで使っていたOSSの脆弱性を悪用して侵入された。 OSS名、脆弱性識別子、初期侵入の詳しい手順は公表されていない。
攻撃の流れ ランサムウェア攻撃(詳細は調査中) 認証システムへの侵入後、管理コンソール経由で仮想化基盤の管理者権限を不正に取得。顧客の仮想サーバーを停止し、仮想サーバー自体を暗号化した。 影響範囲は東日本リージョン1の4ゾーン(tesla/henry/pascal/joule)。495の企業・自治体。
仮想サーバー内データの流出 未公表 外部への流出はなかったと判断。持ち出しを示す痕跡や裏付ける事実は確認されていない。影響のなかったゾーンや他リージョンでも同様。 10月14日の第5報で示された判断。本件に起因する不正利用などの二次被害も、現時点では確認されていない。
ポータルの登録情報 未公表 最大71社の登録情報に不正な照会。個人名または個人名を含む可能性があるメールアドレス等が最大31社(31件)。ログインパスワードが最大4件、不正に変更されていた。 第5報時点は48社。外部への持ち出しの痕跡は確認されていない。該当パスワードはリセット済みで、対象顧客には個別に連絡。
バックアップデータの取り出し 「取り出し・復元が困難な見通し」 206の顧客で取り出し可能(10月20日に判明)。 第5報時点は194顧客。残る289顧客について、同じ方法で取り出せるとの公表はない。
攻撃者との接触 記載なし 攻撃者と接触しておらず、身代金の支払いや交渉は一切行っていない。

出典:IDCフロンティア 第7報(2026年10月27日)、第5報(10月14日)、第3報(10月8日)

1-1. 攻撃の経路をどう読むか

公式の説明では、攻撃は「ポータルの認証システム → 管理コンソール → 仮想化基盤の管理者権限」という経路で進みました。顧客の仮想サーバーの中から侵入されたという説明ではありません。仮想サーバー内のデータの流出が確認されていない一方で、サーバーが止まり暗号化されたのは、管理側の権限が奪われたためと読めます。

なお、これは公式説明の範囲での整理です。OSSの名称、脆弱性の識別子、攻撃者の初期侵入からの詳しい手順は、第7報でも明らかにされていません。

1-2. 復旧の現状とポータル再開の見通し

  • 東日本リージョン1の一部以外の仮想サーバーは稼働中です。ただし、脆弱性のあった「IDCFクラウドポータル」は外部から遮断され、利用停止が続いています。
  • ポータルの再開は3段階の予定です。第1段階(現在実施中)はIDCFが主要な操作(仮想サーバーの起動・停止、各種設定変更など)を代行します。第2段階で全機能の操作を代行し、第3段階で全機能を顧客自身が操作できる状態に戻します。再開の時期は示されていません。
  • 再開に向けて、ポータルの新環境での再構築、全サーバーの認証情報の変更、認証システムの外部IdP(Identity Provider)事業者のシステムへの刷新、接続元のIPアドレス制限、多要素認証の必須化を進めるとしています。
  • 再発防止策として、セキュリティ専任の独立組織の設置(対応済み)、脆弱性診断・攻撃診断の対象範囲のOSSへの拡大、ソフトウェア構成情報の全社一元管理(SBOM化)と脆弱性情報との突合の自動化を挙げています。

「IDCFクラウド バックアップ」は、10月18日の第6報で提供が再開されています。

2. 元記事の記述はどうなったか(答え合わせ)

元記事で「未公表」「見通し」と書いた点と、筆者の推定について、現時点の状況を並べます。

元記事の記述(10月9日夜) 現時点の状況 10月27日夜時点で言えること
4ゾーンのデータは「取り出しや復元が困難な見通し」。復元は顧客自身のバックアップからのみ(IDCFの現時点の見解) 一部更新 元記事も「見解は変わる可能性がある」と書いていました。第5報はスナップショット機能を使っていた顧客について、IDCF側のバックアップデータを取り出せると説明し、対象は206顧客に増えました。取り出せることと、システムとして復元できることは別で、代替環境への移行や取り出しの手順は、ソフトバンクと連携して個別に提案されています。
侵入経路は未公表 更新 ポータル認証システムのOSSの脆弱性が悪用されたと公表されました。OSS名と識別子は未公表です。
情報漏えいの有無は未公表 更新 仮想サーバー内データの外部流出は確認されていません。ポータルの登録情報は、最大71社に不正な照会があり、最大4件でパスワードが不正に変更されました。「漏えいなし」と一括りにせず、データの層を分けて読む必要があります。
SNSで出回った暗号化の主張画像は、攻撃者側の主張とされ真偽未確認 未確定 第7報は、ランサムウェアにより仮想サーバー自体が暗号化されたと説明しています。画像の真偽には触れていません。
事業者側のバックアップの構成は未公表 一部判明 事業者側の保存データから取り出せる顧客が206いたことは分かりました。構成の詳細は公表されていません。
全リージョンの管理コンソールを停止中 更新 全リージョンのポータルは外部から遮断され、利用停止が続いています。他リージョンの仮想サーバーは稼働中で、主要な操作はIDCFが代行しています。
ISMAPの一時停止・再監査は公表なし。再監査の可能性は「十分にある」が、未決定(筆者の推定) 未確定 10月27日夜時点でも、筆者が確認できた範囲では公表がありません。第7報にISMAPへの言及もありません。推定の当否は、まだ判定できません。
管理系の分離やバックアップを含む復旧性に関する統制の実効性が論点になり得る(筆者の推定) 手がかりが出た 攻撃が管理系の経路で進んだことが公式に示されました。ただし、ISMAPの統制に不備があったかどうかの評価は公表されていません。
infoQ「最大約95万件」 更新 10月14日の第2報で、89万4,082件の外部持ち出しを確認したと報じられています。これは情報の記録件数で、同数の人数とは限りません(4-5参照)。
可用性とサプライチェーンへの波及で最も重大な事案の一つ 維持 第7報で、IDCFの社長も顧客のさらに先の事業活動にまで影響が及んだ重大な事態と述べています。

出典:IDCフロンティア 第7報、第5報。infoQは報道による

3. ISMAPの現状

  • 10月27日夜時点で、ISMAPクラウドサービスリストにはIDCFクラウド(登録番号C23-0070-2)が掲載されています。備考欄には、2026年2月27日に登録の有効期限や監査対象期間などを変更したこと、9月30日に更新申請が行われているため有効期限以降も登録は有効であることが記されています。
  • 今回の事案を理由とする登録の一時停止や再監査の開始は、筆者が確認できた範囲では公表されていません。ただし、「公表を確認できない」ことは「ない」ことの証明ではありません。
  • 登録規則上、一時停止や再監査は「できる」規定であり、インシデントが起きたことで自動的に発動するものではありません。この点は元記事から変わっていません。

筆者の見解:第7報が示した攻撃経路と、IDCFが再発防止策で挙げた項目は、重なっています。OSSを含む脆弱性管理、管理系の権限の持たせ方、ポータルへの接続の認証強化(接続元IPの制限と多要素認証)です。ISMAP側が何を論点にするかは未公表ですが、運営委員会が判断する場合は、これらが統制の実効性を確認する材料になると考えます。ただし、統制の不備を指摘できる根拠は、公開情報にはありません。

4. GMO:お名前.com デスクトップクラウドへの攻撃

10月のGMOグループでは、性質の異なる2件の侵害が公表されています。規模、影響、恐喝を伴う点で、「お名前.com デスクトップクラウド」への不正アクセスが中心の事案です。infoQの件は4-5で簡単に触れます。

4-1. 時系列

日時(2026年) 出来事 出典
10月19日 顧客からの問い合わせを受け、調査を開始。 第4報の経緯
10月20日 不正なプログラムの設置を確認。新規申込とコントロールパネルを停止。 第4報の経緯
10月21日 4:00 被害拡大防止のため全プランのサーバーを順次停止し、第1報を掲載。同日、脅迫メールを受信(約80億円の要求)。 第4報、第12報の経緯
10月22日 警察に相談(13:00)。第2報を掲載(16:59)。 第12報の経緯
10月23日 16:10 第3報。影響の可能性があるサーバーは26,739件。 GMOインターネットグループの適時開示
10月24日 11:50 第4報。不正なアクセスと、顧客情報の外部持ち出しを確認したと説明。一律5,000円の見舞金、不正取引の損失補償、代替サービスの6か月無償提供を表明。能動的サイバー防御の適用を政府関係機関に要請。 第4報
10月25〜26日 顧客に端末調査への協力を依頼(25日)。預かった端末の解析を開始(26日21:00)。 第10報の経緯
10月27日 9:58/11:59 第8報・第9報。端末解析の途中経過を報告し、PCのバックアップ取得、ネットワーク切断、電源断を依頼。 第10報の経緯
10月27日 12:30 攻撃者とみられる者による、GMOと顧客に関する情報と称するものの公開を確認。公開内容は確認中で、事実と異なる内容を含むおそれがあるとしている。 第10報
10月27日 13:55 第10報。ランサムウェア攻撃は、同時点で確認されていない。 第10報
10月27日 19:10時点 第12報。情報が公開された顧客への特別見舞金と、懸賞金制度を公表。 第12報

4-2. 被害の範囲をどう読むか

  • 26,739件は上限です。適時開示は、これを「影響の可能性があるサーバー数」とし、不正アクセスや情報取得が確認された件数ではないとしています。人数や漏えい件数として読むことはできません。
  • 影響の可能性がある情報は、サーバー内に保存されていた情報です。取引ツールに保存された取引口座のログイン情報などが含まれます。クレジットカード情報を含む決済情報は、このサーバー上には保持していないとされています。
  • 第4報は、サービスの環境への不正なアクセスと、顧客の情報が外部に持ち出された事実を確認したと説明しています。持ち出された情報の種類と件数は示されていません。
  • 一部の顧客から、取引口座での身に覚えのない取引の報告を受けています。件数と被害総額は公表されていません。片山金融相は10月27日の閣議後会見で、FX業者5社から、GMO関連と考えられる顧客被害の報告を受けたと述べました(時事通信)。
  • 攻撃者とみられる者から、金銭の要求と、応じない場合の行為の予告を受けたとして、GMOは3点を挙げています。(1) 国内外の70を超える証券会社・FX会社等にある顧客口座への不正操作の継続、(2) サービスと接続した顧客PCに関する情報の公開とランサムウェア攻撃、(3) GMOのシステムや運用体制の情報の公開です。なお「70超」は脅迫が対象として言及した数で、70社が社名付きで名指しされたとまでは書かれていません。

情報の公開について:10月27日12時30分に公開が確認されましたが、その内容は確認中で、事実と異なる内容を含む可能性があるとされています。したがって、現時点で「顧客情報の真正なデータが公開された」とは断定できません。GMOは、当該サイトにアクセスした人の情報は攻撃者に取得されていると警告し、アクセスや拡散をしないよう求めています。本記事も、攻撃者のサイトや公開物へのリンクは掲載しません。

4-3. GMOの補償と対応

項目 内容 補足
一律の見舞金 現在サービスを利用しているすべての顧客に、被害の有無にかかわらず5,000円。 連絡方法・受け取り手続・支払時期は、10月30日23:59までに登録メールで案内される(この日は申請期限ではない)。
不正取引の損失補償 本件に起因すると認定した不正取引の実現損失(差損と手数料等)が対象。市場変動による損失や、得られたはずの利益は対象外。 取引所等から返金があれば、差し引いた残額を支払う。申請方法等は11月6日までに案内される。
代替サービス 独立したクラウド基盤上の代替サービスへの乗り換えを案内。移行後6か月は無償。 現行の基盤は再開しない。顧客の同意なく移行は行わない。
特別見舞金(第12報) 公開が確認された情報の区分ごとに支払う。基本的な情報(氏名・連絡先など)1万円、金融・認証に関する情報1万5,000円、機微・要配慮情報2万5,000円。複数区分は合算し、1公開につき上限300万円。 一律5,000円や損失補償とは別枠。公開の状況が変われば内容を見直すことがある。
懸賞金(第12報) 「GMOサイバー犯罪撲滅・懸賞金」。犯人の特定・検挙や事件の解明に貢献する情報が対象で、総額の上限は100万米ドル(参考換算で約1.5億円)。10月28日12:00に受付を開始。 犯人への身代金や、盗まれた情報の買い取りではないと説明。独自の侵入調査や犯人との接触は行わないよう求めている。
要求への対応 犯人の要求には応じない(第12報は「永久に」と表明)。通信記録などの証拠を警察に提出し、捜査を要請している。 主要な取引所・証券会社には、サービス経由のアクセス遮断、セッションの強制切断、不正取引の監視を要請。
政府への要請 能動的サイバー防御の適用を、政府関係機関に要請した(第4報)。 官房長官は個別事案へのコメントを控え、無害化措置は要請の有無にかかわらず法定要件に照らして判断すると説明した(TBS NEWS DIG)。

出典:GMOインターネットグループ 第4報(10月24日)、第12報(10月27日)、TBS NEWS DIG

4-4. 公式に示されていない点

  • 侵入経路と原因:第4報は「システムにセキュリティ上の問題が存在していた」と述べていますが、具体は筆者が確認できた範囲の公式発表に示されていません。
  • 攻撃の開始時期、持ち出された情報の種類と件数、不正取引の件数と総額。
  • 攻撃者の特定:GMO、警察、政府のいずれも、攻撃者を特定・公表していません。攻撃者側のサイトの主張や名乗りは検証されておらず、本記事では扱いません。

4-5. 別の事案:infoQ(GMOリサーチ&AI)

アンケートサイト「infoQ」は、10月2日以降にソフトウェアの脆弱性を悪用されたと報じられています。10月5日の公表時点では最大94万8,498件でしたが、10月14日の第2報で、89万4,082件の外部持ち出しを確認し、ポイントの不正交換が611件(286万9,500円相当)あったとされています(報道による二次情報)。元記事の「最大約95万件」は、初報の最大値を丸めたものでした。件数は情報の記録件数で、同数の人数とは限りません。

5. 2つの事案に関連はあるか

観点 IDCFクラウド お名前.com デスクトップクラウド
公式が説明する侵入の起点 ポータル認証システムのOSSの脆弱性 一部顧客のサーバー環境への不正プログラムの設置。侵入経路の具体は未公表
被害の中心 顧客の仮想サーバーの停止と暗号化(可用性)。仮想サーバー内データの流出は確認されず 顧客情報の外部持ち出し、取引口座への不正操作、情報公開の予告と恐喝
攻撃者の行動(公式の説明) 事業者は攻撃者と接触せず、身代金の支払い・交渉もしていない 金銭要求と情報公開の予告を受け、10月27日に情報の公開を確認
波及の形 利用企業・自治体と、その先の顧客・住民へ 利用者の金融口座・端末と、取引事業者へ

出典:IDCF 第7報、GMOインターネットグループ 第4報・第10報

2026年10月27日夜までの公開情報では、IDCFとGMOの事案の攻撃者や手口に共通性を示す根拠は確認できません。これは「関連がない」と断定するものではなく、関連を示す根拠が公開されていないという意味です。

10月19日には、GMOサイバーセキュリティ byイエラエが、日本企業を狙う不正アクセスの攻撃元で、AIを使った自律型の侵入テストツール「ARTEX」の利用を確認したと発表しています(ITmedia NEWS)。ただし、同社は個別の企業名や漏えいとの関係を明らかにしておらず、IDCF、infoQ、デスクトップクラウドのいずれかに結び付ける根拠にはなりません。

筆者の整理:元記事ではサプライチェーンへの波及という観点でIDCF事案を整理しました。GMO事案も、事業者の侵害が利用者の資産や取引事業者に連鎖した点では共通しますが、波及先が金融口座と利用者の端末である点が異なります。2つをまとめて「サプライチェーン型」と呼ぶより、外部サービスへの依存を通じた連鎖被害として見るほうが、実態に近いと考えます。

6. 利用側への示唆(筆者の見解)

以下は事実ではなく、筆者の見解です。

  • 事業者の管理系は、顧客側の設定では守れません。管理ポータルや管理コンソールへの認証経路が破られると、顧客側が堅牢に構成していても影響を受け得ます。調達や契約の段階で、管理系の分離、接続元の制限と多要素認証、OSSを含む脆弱性管理の方針を、事業者に説明してもらうことを勧めます。IDCFがポータル再開の条件に、IP制限と多要素認証の必須化を入れたことは、参考になります。
  • バックアップは事業者の外にも持つ、という元記事の方針は変わりません。206顧客がIDCF側から取り出せたことは救いですが、残る289顧客に同じ確認は公表されておらず、事業者側のスナップショットを当てにする設計は危ういままです。
  • 事業者側のサーバーに置いた認証情報は、事業者の侵害で漏れ得ると考えておく必要があります。GMO事案では、サーバー内に保存された取引口座のログイン情報などが、影響の可能性がある情報に含まれています。取引口座側で権限を必要最小限にする、パスワードを使い回さない、といった見直しは、事案の帰結を待たずに行えます。
  • 公開されたとされる情報には、アクセスしない・拡散しないでください。GMOは、当該サイトにアクセスした人の情報が攻撃者に取得されていると警告しています。

7. まとめと今後の注目点

IDCF事案は、第7報で侵入経路の概要と影響の全体像が公式に示され、調査としては一区切りがつきました。一方、OSSの名称と脆弱性の識別子、ポータルの再開時期、ISMAPの手続きは、まだ見えていません。GMO事案は、情報の公開と恐喝が続く進行中の事案で、確定した事実は限られます。

  • IDCF:ポータルの再開時期(3段階の進み方)、OSSの名称や脆弱性識別子の公表の有無、残る顧客の復旧状況。
  • ISMAP:運営委員会による再監査や登録の扱いの公表の有無。
  • GMO:公開された情報の真偽と範囲、不正取引の件数と総額、侵入経路の公式説明、代替サービスの提供開始時期。10月28日12時の懸賞金の窓口開設、10月30日と11月6日の顧客への案内も控えています。
  • 政府:能動的サイバー防御に関する措置の判断と、サイバー攻撃への緊急対策の中身。

続報で内容が変わった場合は、あらためて整理します。

8. 主な出典

金曜日, 10月 09, 2026

IDCFクラウド・ランサムウェア事案を整理する:ISMAP登録サービスで何が起きたか

2026年10月7日、IDCフロンティアが提供する「IDCFクラウド」の東日本リージョン1の一部がランサムウェア攻撃を受け、仮想サーバーが停止して再起動できない状態になりました。影響を受けたのは495の企業・自治体です。同社は、teslaなど4ゾーンに保管された顧客データを「取り出しや復元が困難な見通し」とし、現時点の見解として、復元は顧客自身が持つバックアップからのみ可能だと説明しています。

IDCFクラウドのコンピュートなどは、政府情報システムのためのセキュリティ評価制度「ISMAP」の登録対象です。では、登録されていれば安心なのか。運営側はこの事案をどう扱うのか。利用する側は何をすべきか。公表されている情報から整理しました。

結論を先に書きます。

  • 事実として確認できるのは、ランサムウェア攻撃、4ゾーンのデータ復元困難、495の企業・自治体への影響までです。侵入経路と情報漏えいの有無は、10月9日夜の時点で公表されていません。
  • ISMAPについて、運営委員会などがIDCFを名指しした措置(登録の一時停止や再監査の開始)を公表した形跡は、筆者の確認した範囲ではありません。再監査に進む可能性は十分にありますが、現時点では未決定です(筆者の推定)。
  • ISMAP登録は統制の評価であり、サービスが止まらないこと、データが失われないことの保証ではありません。バックアップを事業者の外に持つこと、委託先・再委託先の利用クラウドを把握することが、利用側の現実的な備えになります。
本記事は2026年10月9日夜時点の公開情報に基づきます。IDCFの公式発表を一次情報とし、報道に基づく部分はその旨を書いています。見通しや評価は筆者の推定・見解です。続報が出た場合は内容が変わる可能性があります。

1. IDCFクラウド事案:公式発表で確認できること

公表 日付 主な内容
第1報 10月7日 第三者からの不正アクセスにより、東日本リージョン1で障害が発生。対象の顧客には個別に連絡。
第2報 10月7日 原因を「第三者からの不正アクセス(ランサムウェア攻撃)」と特定。影響は495の企業・自治体。東日本リージョン1をネットワークから遮断し、システムを停止。
第3報 10月8日 対象を4ゾーン(tesla/henry/pascal/joule)に特定。データは取り出し・復元が困難な見通しで、復元は顧客自身のバックアップからのみ、と案内。他のゾーン・リージョンは不正アクセス未確認だが、自前のバックアップ取得を案内。全リージョンの管理コンソールを停止中。
第4報 10月9日 10月7日午前9時に緊急対策本部を設置し、親会社のソフトバンクと連携して対応。顧客窓口はソフトバンクの法人部門で、バックアップ手順の案内、移行環境の提案、仮想サーバーの起動・停止の代行を実施。外部の専門企業と詳細調査を進め、監督省庁や警察などへ報告・相談している。

出典:IDCフロンティア公表(第1報/第2報/第3報/第4報)

1-1. 確認できている事実

  • 発生は2026年10月7日午前3時40分ごろで、第3報の時点では継続中とされています。
  • 対象は東日本リージョン1の一部(tesla/henry/pascal/jouleの4ゾーン)です。仮想サーバーの停止と再起動不可が起きています。
  • 4ゾーンの顧客データは「取り出しや復元が困難な見通し」で、同社は「現時点での当社の見解」として、復元は顧客自身のバックアップからのみ可能としています。今後の調査で見解が変わる可能性はあります。
  • IDCFクラウド TypeS(旧ホワイトクラウド ASPIRE)とIDCFプライベートクラウドは、本事象の対象外です。

1-2. 未公表・未確認の事項

  • 侵入経路と、攻撃の詳しい影響範囲(調査中とされています)。
  • 顧客データが外部に持ち出されたか(情報漏えいの有無)。公式発表では確認も否定もされていません。
  • どのストレージやバックアップが暗号化・破壊されたのか。事業者側のバックアップの構成も公表されていません。したがって、本件から事業者の設計上の不備を断定することはできません。
  • 495の企業・自治体の内訳(ゾーン別の数、国の機関が含まれるか)。
  • SNSでは、暗号化やスナップショット破壊を主張する画像が出回っています。攻撃者側の主張とされるもので、公式発表には含まれません。真偽は未確認です。

1-3. 影響を受けた利用者の例

  • シックス・アパート:Movable Typeクラウド版のサーバー31台がIDCFクラウド上では復旧できない見込みとなりました。Google Cloudに保管していたバックアップ(7世代)を使い、さくらのクラウドへ移行する方針と報じられています(ITmedia NEWS)。
  • 小平市:市のホームページが停止し、委託先のクラウド基盤がランサムウェア攻撃を受けたと公表しました。問い合わせフォームなどに入力された住民情報が漏えいした「おそれ」があるとしています(セキュリティ対策Lab)。自治体が直接契約していない委託先のクラウドが影響した例です。
  • 茨城県:県庁と県警のホームページが閲覧できなくなったと報じられています(時事通信)。
  • ニッスイ(日水物流):物流拠点の入出荷に影響が出たと公表しましたが、事業者名は明記していません。IDCFクラウドの影響と報じられている段階です(報道)。

2. ISMAP登録サービスとしての位置づけ

2-1. 登録範囲

IDCFが2024年1月10日に公表したリリースによると、ISMAPクラウドサービスリストへの登録範囲は次のとおりです(IDCF)。

  • IDCFクラウド:コンピュート、インフィニットLB、RDB、DNS、GSLB、コンテナ
  • IDCFプライベートクラウド(TypeV 2020など)と、IDCFクラウド ベアメタルサーバー(クラウドタイプ)

今回停止したのは仮想サーバー、つまりコンピュートで、登録範囲に含まれます。なお、プライベートクラウドも登録対象ですが、IDCFは今回の事象の対象外としています。また、登録は「サービス単位の統制の評価」であり、特定のリージョンやゾーンの安全性を個別に認定したものではありません。

2-2. 規程上の枠組み

ISMAP基本規程(英語参考訳。原文は日本語)には、関係する規定が次のように書かれています(ISMAP)。

  • 報告(3.7):登録事業者は、利用者に重大な影響を及ぼし得る情報セキュリティインシデントが起きた場合、ISMAP運営委員会または運用支援機関に直ちに報告する責任を負います。確認を求められたときは速やかに対応する必要があります。
  • 再監査(5.2):モニタリングの結果などを踏まえ、運営委員会は事業者に再監査を求めることができます。
  • 一時停止・取消し(5.4):モニタリングや再監査の結果、またはインシデントが起きた場合に、運営委員会は登録を一時停止または取り消すことができます。

ここで重要なのは、いずれも「できる」規定であることです。インシデントが起きただけで、登録が自動的に停止されるわけではありません。個別の運用を定めた登録規則では、第9章(インシデント報告)、第11章(モニタリング)、第12章(再監査)が再監査の手続きの根拠として引かれています(過去の事案についてのITmedia NEWS)。具体の判断は、現行規則と事実関係に基づき運営委員会が行います。

2-3. 現状(10月9日夜時点)

  • ISMAP運営委員会、国家サイバー統括室、デジタル庁のいずれも、IDCFを名指しした登録の一時停止や再監査の開始を公表した形跡は、筆者が確認できた範囲ではありません。
  • IDCFは「監督省庁」などへの報告・相談を進めていると述べています。ただし、その中にISMAPへの報告が含まれるかは、公開情報からは分かりません。
  • 筆者の推定では、コンピュートが登録対象で、停止とデータ復元困難という影響の重さから、IDCFが報告対象に当たるインシデントと判断する可能性は高いと考えます。

2-4. 過去の再監査と今後の見通し

公開情報で確認できる、インシデント後の再監査の前例は次の2件です。

時期 対象サービス きっかけ 経過
2022年9月〜2023年3月 ニフクラ、FJcloud-V 2022年5月、ロードバランサーの脆弱性を悪用した不正アクセスで、情報が盗まれた可能性が公表された。 約6か月の再監査の結果、運営委員会は「要求事項が適切に実施されていることが確認できた」としてリストに残留。
2023年9月28日〜 FJcloud 採用するネットワーク接続サービスのトラブル(2023年2月に、ネットワーク機器に不正なプログラムが仕込まれていたと公表)。事業者は当時、FJcloudへの影響はないと説明していた。 登録規則の第9・11・12章に基づき再監査を開始。再監査中も登録リストには掲載。終了時期は発表時点で未定。

出典:ITmedia NEWS「富士通の“政府認定クラウド”が再監査に」(2023年9月29日)

この2件は、事案の性質も被害の規模もIDCF事案とは違います。それでも、重大インシデントの後にISMAP運営委員会が再監査を行った実績があること、再監査は数か月単位で進み、その間も登録がリストに残ったことは、見通しを考える材料になります。再監査は登録の取消しとは別物です。

筆者の推定:IDCF事案が再監査に進む可能性は十分にあります。ただし、前例は2件しかなく、「可能性が高い」と確率を付けられる根拠はありません。現時点では未決定と見るのが妥当です。結論は、IDCFの報告内容、調査で分かる侵入経路、復旧と再発防止の実施状況、統制が実際に機能していたかの確認に左右されるでしょう。論点になり得るのは、管理系の分離や、バックアップを含む復旧性に関する統制の実効性です。ただし、事業者のバックアップ構成が未公表の現段階で、監査の不備を指摘できる根拠はありません。

3. 利用側(府省庁・自治体・委託先)に求められる対応

  • 影響の棚卸し:自組織だけでなく、委託先や再委託先(保守業者、SaaS事業者など)がIDCFクラウドを使っていないか確認します。小平市の例のように、直接契約していない委託先経由で影響が及ぶことがあります。
  • 4ゾーンの利用者:IDCFは別環境を用意しての再構築を案内しており、データは自前のバックアップから復元する前提です。
  • それ以外のゾーン・リージョンの利用者:不正アクセスは確認されていませんが、管理コンソールは停止中です。IDCFが順次案内するバックアップ手順に従い、自前のバックアップを取得しておきます。
  • 個人情報が保存されていた場合:個人情報保護法上の報告・本人通知の要否を検討します。小平市は「おそれ」の段階で公表しました。
  • 被害情報の共有:国家サイバー統括室は10月9日、事業者向けの文書で、被害に遭った組織が攻撃に関する技術的な情報を同室や所管省庁に速やかに共有するよう呼びかけています。

同じ文書は、対策のポイントを3分野で示しています(ITmedia NEWS、原文)。

  • ウェブシステム等の適切な管理:OSやCMSへのパッチの速やかな適用、サポート終了製品の利用停止、多要素認証の導入
  • サプライチェーンを通じた侵害への対策:委託先の対策状況を契約時だけでなく継続的に確認、漏えい時の報告義務を契約に盛り込む、業務終了後にデータを確実に削除させる
  • データの適切な管理:情報資産の棚卸し、不要な情報の削除、保存データと通信経路の暗号化、クラウド利用時の公開設定とアクセス権限の確認、アクセスログの点検・分析

4. 調達・設計への示唆(筆者の見解)

以下は事実ではなく、筆者の見解です。

  • ISMAP登録の位置づけ:登録は、政府調達に必要な統制を事業者が整備・運用していることの評価です。侵害されないこと、止まらないことの保証ではありません。2026年9月にはデジタル庁のGSSも、既知のVPN脆弱性から侵入されたと公表されています。
  • バックアップの置き場所:重要システムでは、本番と異なる障害・認証・管理ドメインにバックアップを持ちます。別アカウント、別リージョン、別媒体、別クラウドのどれにするかは、RTO/RPO、情報区分、データ所在の要件で決めます。すべてのシステムに別事業者への保管を一律に課すのは、現実的ではありません。
  • バックアップの堅牢性:イミュータブル(変更・削除できない)な構成にし、本番の管理者資格情報だけでは消せないようにします。
  • 復元の実証:バックアップがあるだけでは足りません。定期的なリストア試験を、契約やSLA、運用報告に含めます。
  • 契約条件:重大インシデント発生時の顧客通知期限、証拠保全、出口戦略、データの持ち出し手段、ISMAPへの報告の有無の共有を、契約で定めます。
  • 新規採用の判断:IDCFの新規採用は、侵入経路と再発防止策が公表され、ISMAP側の手続きの方向が見えるまで保留するのが、重要な本番システムでは合理的な選択です。検証環境や代替しやすいシステムまで一律に止めるかは、バックアップ設計や契約上の補償措置を含めて個別に判断すべきです。

5. 政府・当局の動き

  • 10月8日 JPCERT/CC:国内で相次ぐ不正アクセスについて注意喚起(JPCERT-AT-2026-0030)を公表しました。確認された手口として、既知の脆弱性や管理不備を突く攻撃、スマホアプリの解析による内部APIの不正操作、BIツールMetabaseのSQLインジェクション脆弱性(CVE-2026-72898)の悪用が挙げられています(マイナビニュース)。
  • 10月8日 関係省庁会議:サイバー攻撃の多発を受けて緊急に開かれ、被害情報は国家サイバー統括室に集約する方針が示されました。古川大臣は、危急の状況だとして政府一丸での対策を訴えています(Impress Watch)。
  • 10月8日報道 個人情報保護委員会:強い多要素認証やEDRの導入、不要な個人データの消去などを、緊急に例示したと報じられました(ITmedia NEWS)。
  • 10月9日 国家サイバー統括室:大量の個人情報を扱う事業者向けに、対策の徹底を求める文書を公開しました(第3節の3分野)。

6. 同時期の主要な情報漏えい・不正アクセス

IDCF事案と並行して、国内では大規模な漏えいの公表が続いています。件数は各社が公表した最大値や「可能性」を含みます。「漏えいを確認」と「漏えいの可能性」は区別してください。

6-1. 9月

公表日 組織・サービス 規模 概要・状態
9月11日 デジタル庁 ガバメントソリューションサービス(GSS) 約24.6万件 VPN機器の既知の脆弱性を悪用した侵入。漏えいの可能性。マイナンバーや口座情報は含まないと公表。
9月15日 ムラウチドットコム 771万6,811件 Webシステムの脆弱性を悪用された。持ち出しを確認。
9月16日 Gyazo(Helpfeel) ユーザー関連データ約2,362万件、画像メタデータ約4.9億件 不正アクセスによる流出。9月25日の続報で、削除済み画像のメタデータ約1.74億件の流出も判明。
9月25〜29日 タイムズカー(タイムズモビリティ) 約660万アカウント(うち本人確認書類を含むのは約160万件) 9月25日に検知。第三者による取得を確認。クレジットカード情報は含まない。
9月27日 OZmall(スターツ出版) 最大44万2,779名 海外からの大量の不正アクセス。メールアドレスなどが閲覧された可能性。件数は10月1日の第2報で精査された値。
9月29日 セイコーマートアプリ 約57万アカウント 第三者に閲覧された可能性。
9月30日 VOISING 約17万件 BIツールの既知の脆弱性を悪用された。

出典:@IT(GSS)、ムラウチ、Helpfeel、Impress Watch(タイムズカー)、OZmall、セイコーマート、VOISING

6-2. 10月

公表日 組織・サービス 規模 概要・状態
10月5日 焼肉きんぐ公式アプリ(物語コーポレーション) 1,078万8,963件 会員管理システムへの不正アクセス。氏名、メールアドレス、電話番号など。パスワード・決済情報は含まない。登録者のほぼ全員が対象。
10月6日 ミスターマックス(アプリ・オンラインストア) 最大173万5,154人 ソフトウェアの機能を不正利用したサーバー侵入。住所・カード情報などは対象外。
10月6日 スカラコミュニケーションズ FAQシステム「i-ask」(委託先) 最大5社・延べ最大71万3,126件 管理サイトへの不正ログインと不正プログラムの設置。件数は問い合わせ単位の延べ件数で、重複を含む。利用企業の公表は、大和証券(10月5日、約11万人)、シチズン時計(10月6日、約10万人)、損保ジャパン(10月7日、延べ約6万件)。
10月7日 HIS(タイ現地法人) 最大627名 パスポート情報とアレルギー情報の流出の可能性。2025年12月11日に検知し、2026年10月7日に公表。
10月7日 IDCフロンティア「IDCFクラウド」 495の企業・自治体 ランサムウェア攻撃による障害(第1節)。情報漏えいの有無は未公表。
10月9日 ブックオフグループホールディングス(子会社の会員管理システム) 最大約643万件 不正アクセスによる会員情報の流出(報道ベース)。

出典:焼肉きんぐ、ミスターマックス、Internet Watch(i-ask)、ITmedia NEWS(損保ジャパン)、トラベルWatch(HIS)、ITmedia NEWS(ブックオフ)

このほか、10月6日前後には、GMOリサーチ&AIのアンケートサービス「infoQ」(最大約95万件)や「楽天ドライブ」(約1.5万アカウント)の不正アクセスも報じられています。

7. まとめと今後の注目点

今期の情報漏えいの多くは、個人情報の窃取です。一方、IDCFクラウド事案は、クラウド基盤そのものが止まり、その上で動く自治体サイトや企業のサービスが同時に影響を受けました。漏えいの件数では他の事案が大きくても、可用性とサプライチェーンへの波及という点では、最も重大な事案の一つだと言えます。

今後、次の点に注目しています。

  • IDCFの続報:侵入経路、情報漏えいの有無、復旧計画、再発防止策
  • ISMAP運営委員会の対応:再監査や登録の扱いに関する公表の有無
  • 国家サイバー統括室や個人情報保護委員会による、クラウド利用時の追加の指針

利用する側としては、ISMAPのリストに載っているかどうかに加えて、事業者が止まったときに自分のデータをどこから復元できるかまで、調達や設計の段階で確認しておくことが重要です。

水曜日, 9月 30, 2026

タイムズカー約660万件個人情報漏洩の教訓: なぜ退会者の免許証画像まで流出したのか

記事の要点(TL;DR)

  • 最大約660万件のアカウント情報流出: パーク24グループの「タイムズカー」Webシステムが外部からの不正アクセスを受け、現会員のみならず退会者や申込未完了者の情報まで流出したことが確認されました。
  • 約160万件の本人確認書類画像が流出: 運転免許証や現住所確認書類等の画像データが含まれており、パスワードと異なり変更・失効が実質不可能な個人識別資産が侵害されました。
  • 検知から通信遮断まで約22時間: 2026年9月25日09:07の検知から遮断完了まで約22時間を要しました。モビリティ基幹サービスの継続と緊急遮断のトレードオフが浮き彫りとなりました。
  • データリテンション(保持期限ポリシー)の欠如: 取引記録保管を根拠に退会後約7年間保持する運用が採られていましたが、法令上の記録義務を超えて原本画像を残置していたガバナンスの破綻が被害を拡大させました。
  • Web層と機微データストレージの分離不全: 公開Webシステムから本人確認書類の蓄積領域まで侵入を許したアーキテクチャ上の脆弱性が根本的な要因として指摘されています。

1. インシデントの概要と被害の全容

2026年9月、時間貸駐車場およびモビリティサービス国内最大手のパーク24株式会社および連結子会社のタイムズモビリティ株式会社は、カーシェアリングサービス「タイムズカー」等のWebシステムに対する不正アクセスにより、大規模な個人情報流出が発生したことを発表しました(パーク24公式リリース(第2報))。

本インシデントの特徴は、単なるアクティブ会員の流出にとどまらず、過去に解約した元会員や入会手続き途中で離脱した登録未完了者、さらには法人向け「タイムズビジネスサービス」の会員・退会者にまで影響が及んでいる点です。さらにその後の調査により、運転免許証などの本人確認書類画像が流出した対象が約160万件に達することが判明しました(パーク24公式リリース(第3報))。

漏洩データの内訳と保管状態

情報分類 漏洩が確認された主なデータ項目 影響規模 / 保管状態
基本属性情報 氏名、住所、生年月日、電話番号、メールアドレス 最大約660万件(対象者ごとに差異あり)
法人所属情報 法人会員における所属部署名 タイムズビジネスサービス会員および退会者
本人確認書類情報 運転免許情報、運転免許証画像、現住所確認書類画像(公共料金領収書等)、学生証画像、家族確認書類画像 画像データ流出は約160万件
認証・連携情報 ログインパスワード、外部連携サービスID(計9件、JR西日本「WESTER ID」等) パスワードは不可逆形式(ハッシュ等)で保管
決済情報 クレジットカード番号、有効期限、セキュリティコード 当該システム内未保持のため「漏洩なし」を確認

幸いにもクレジットカード情報については当該システム内で保持されておらず、侵害対象から除外されています(読売新聞オンライン 報道)。

2. インシデントのタイムラインと初動対応

不正アクセスの検知から封じ込め、公式公表に至る一連のタイムラインは以下の通りです(piyolog(piyokango氏の解説))。

日時 フェーズ 事象および実施対応
2026年9月25日 09:07 検知・調査着手 タイムズカーWebシステムに対する外部からの異常アクセスを検知し、直ちに社内調査を開始。
2026年9月25日中 初期開示(第1報) 外部からの不正アクセス形跡と情報漏洩の可能性を公表。個人情報保護委員会へ速報を提出(パーク24公式リリース(第1報))。
2026年9月26日 07:25 遮断・封じ込め完了 侵入経路の遮断、攻撃元IPとの通信遮断、アクセス不能確認を完了(検知から約22時間後)。
2026年9月28日 被害確定公表(第2報) 外部専門機関の調査に基づき約660万件の個人情報取得を確定発表。警察への届出、WESTER ID等の流出を公表。
2026年9月29日 詳細公表・個別通知(第3報) 本人確認書類画像の流出が約160万件であることを特定。該当会員への個別メール通知を開始(タイムズカー公式お知らせ(第3報))。

初動対応の評価と課題

検知当日に個人情報保護委員会へ一報を入れ、外部への注意喚起(第1報)を迅速に公表した初動は、個人情報保護法が求める報告要件(概ね3から5日以内の速報要件)に照らして適切な対応でした。

一方で、検知から通信遮断完了までに約22時間を要している点は技術的な分析対象となります。全国数万台規模で稼働するカーシェア車両の予約・解錠・返却といった物理インフラを即時停止させずに原因特定を進めるという、事業継続性(BCP)を重視した判断が背景にあったと推察されます。しかし結果として、この遮断までの時間的猶予の間にデータ窃取が進行・完遂された可能性は否定できません。

3. なぜ運転免許証画像の流出が致命的なのか

本インシデントにおいて最も深刻な脅威は、約160万件に及ぶ「運転免許証などの本人確認書類画像」の流出です(ITmedia Mobile 報道)。

パスワードと身分証明書の決定的な違い

  • パスワードやクレジットカード: 侵害が発覚した時点で失効処理や再発行を行うことで、無効化することが可能。
  • 運転免許証の券面画像: 氏名、住所、生年月日に加え、鮮明な顔写真、公安委員会番号、交付日、有効期限などが一体化しており、取り消しや失効ができません。

日本の運転免許証番号(12桁)は、公安委員会コード(2桁)+取得年(2桁)+固有番号(6桁)+チェックデジット(1桁)+再交付回数(1桁)で構成されています。再交付を行っても変動するのは末尾1桁のみであり、上11桁は生涯変更されません。したがって、一度外部に漏洩した免許証画像は、実質的に「生涯変更できない個人認証キー」が流出したことを意味します。

想定される二次被害シナリオ

  1. オンライン本人確認(eKYC)の突破による不正契約
    金融機関の口座開設、クレジットカード発行、消費者金融の融資、格安SIMの契約などに悪用されるリスクがあります。近年のeKYCは動作検知を導入していますが、生成AIを用いたディープフェイク技術により、鮮明な顔写真から動画を生成して審査をすり抜ける手口が急速に進化しています。
  2. 標的型スピアフィッシングへの悪用
    漏洩データには「法人会員における所属部署名」が含まれています。攻撃者は部署名や実名を組み合わせ、「タイムズカー利用規約改定に伴う再認証」や「社用車経費精算システムの不備」といった極めて精巧な偽装メールを企業の社用アドレス宛に送付し、企業イントラネットへの足がかりを狙うソーシャルエンジニアリングが可能です。
  3. 自衛手段の限定性
    信用情報機関(JICC、CIC、全国銀行個人信用情報センター)に対する本人申告制度は存在しますが、登録には手間と費用がかかる上、加盟事業者が照会時に参考情報として扱うにとどまり、強制的な契約拒否を行うものではありません。また、普通預金口座の開設などは照会対象外であるため、根本的な防御策にはなり得ないのが現状です。

4. 技術的要因とデータガバナンスの構造的欠陥

本インシデントから得られる技術的教訓は、主に2つの構造的欠陥に集約されます。

① Webシステムと機微データストレージの分離不全

攻撃者は公開Webシステムを足がかりに侵入し、会員データベースのみならず、アップロードされた本人確認書類画像が蓄積されたストレージ領域にまで到達しています。

これは、Webフロントエンド層と機微データ蓄積層との間におけるネットワークセグメンテーションの不備、あるいはWebアプリケーションに過剰なストレージアクセス権限が付与されていた可能性を強く示唆しています。本人確認完了後の画像ファイルは、Web層から完全に隔離されたアーカイブストレージに移行し、厳格な最小権限ポリシーと暗号化キーの分離を施すべきでした。

② データリテンション(保持期限ポリシー)の欠如

より本質的な問題は、「不要な機微データをオンライン環境に長期間滞留させていた」というライフサイクル管理の欠如です。

タイムズカー側は取引記録の保管義務を根拠に「退会後約7年間保管する」方針を掲げていました(タイムズカー FAQ)。しかし、レンタカー・カーシェア関連法令が義務付けているのは貸渡簿における「免許証番号等のテキスト記録」の保存であり、高解像度の「券面画像原本」を数年間にわたりオンライン上に保持し続ける法的義務はありません。

ましてや、入会審査に落ちたユーザーや申込途中で離脱した登録未完了者の画像データまで保持し続けていた点は、個人情報保護法が求める「利用目的達成後の遅滞ない消去」の原則に照らして重大なガバナンス上の瑕疵といえます。

5. 今後に向けた技術的提言と利用者の防護策

サービス事業者が直ちに実装すべきアーキテクチャ

  • データ最小化(Data Minimization)の実装: eKYCや入会審査が完了した時点で、身分証明書の画像データ原本は即座に削除するか、オフライン環境へコールドパージする設計を標準化する。
  • データライフサイクルの自動強制: 退会者や審査未完了者の機微データは、一定の保持期間(例: 30日)経過後に自動完全消去(パージ)されるライフサイクルルールをシステム的に強制する。
  • ゼロトラストに基づくストレージアクセス制御: Webサーバーが直接機微ストレージを読み取れないよう、署名付きURLの短時間発行や中継マイクロサービスの権限分離を徹底する。

ユーザー側で求められる自衛アクション

  • 公式窓口以外の連絡をすべて警戒: パーク24やタイムズを騙り、パスワード、クレジットカード情報、認証コードの入力を求める連絡はすべて詐欺とみなしてください(公式でもメール等でこれらの情報を聞くことはないと明言しています)。
  • パスワードの使い回し停止: タイムズカーで使用していたパスワードを他サービスでも利用している場合は、直ちに別々の強固なパスワードに変更してください。
  • 不審な契約通知の監視: 信用情報機関への本人申告を検討するとともに、身に覚えのないクレジットカード発行やSIM契約の通知が届いた場合は、即座に事業者および警察(専用相談電話 #9110)へ通報してください。

火曜日, 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移行の本質は、特定のアルゴリズムへの乗り換えではなく、アルゴリズムを乗り換えられる組織になることなのだと思います。