情報セキュリティばんざい！

火曜日, 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. 主な出典

IDCフロンティア：第7報（10月27日）／第6報（10月18日）／第5報（10月14日）／第3報（10月8日）
GMOインターネットグループ：第4報（10月24日）／第10報（10月27日）／第12報（10月27日）／適時開示（10月23日）
ISMAP：ISMAPクラウドサービスリスト
報道：時事通信（金融相会見）／TBS NEWS DIG（官房長官会見）／infoQの第2報の報道／ITmedia NEWS（GMOサイバーセキュリティ byイエラエ）
元記事：IDCFクラウド・ランサムウェア事案を整理する：ISMAP登録サービスで何が起きたか（2026年10月9日）

月曜日, 10月 26, 2026

NECが作った「AIだけの部署」とは何か――4階層の仕組みと、自社で再現する方法

NECは2026年8月、部門長から社員まですべての役割をAIが担う社内組織「コーポレートAI・Workforce部門」を新設しました。「AIが部署をつくった」と聞くと人のいない会社を想像しがちですが、公式発表を読むと設計思想はかなり違います。業務を遂行するのはAIですが、最終的な評価・意思決定と、品質・ガバナンスの統制は人が担う。つまり「AIだけで動く部署を、人が統治する」仕組みです。

この記事では、公表されている事実を整理したうえで、同じ仕組みを自社で作るなら何が必要になるかを、筆者の提案として検討します。

本記事は2026年10月25日時点の公開情報に基づきます。事実（NECの公表・報道）と、筆者の整理・提案は区別して書いています。AI部署が採用しているLLMや実行基盤は、公表資料からは確認できません。

1. 何が新設されたのか

項目	公表されている内容	補足
名称・時期	コーポレートAI・Workforce部門。2026年8月1日付で新設、8月10日に発表	2026年7月からの1カ月間の社内実証を経て正式設立
構成	AI部門長、AIボード（CxO機能）、AIマネージャー、AI社員の4階層	職務定義から実行・自己進化までをAI自律型で行う
人の役割	最終的な評価・意思決定、品質・ガバナンスの統制	報道では、人の役割を「方向性提示・最終承認・統治」と整理（TECH+）
位置づけ	「組織としてのAIキャピタル活用の実証」。グループ約10万人の従業員を擁する自社を最初のクライアントとする「クライアントゼロ」	運営で得た仕組み・方法論・基盤・運用ノウハウをBluStellarのもとで外部に提供する方針
「国内大手初」	発表日時点、NEC調べ	従業員数万人規模の国内企業を対象とした主張

出典：NEC プレスリリース（2026年8月10日）、TECH+（2026年10月2日）

2. 4階層の中身

階層	役割	公表されている例
AI部門長	組織全体の稼働状況を把握・管理する	デジタルツイン上に構築した「AI統合マネジメントコックピット」で、すべてのAIの活動をリアルタイムに可視化
AIボード（CxO機能）	AI組織の状況を経営視点から評価する。週に1回の「役員会」を開く	AI変革を担うCAXO役、費用対効果を見るCFO役、人材育成・働きがいを見るCHRO役など
AIマネージャー	業務を品質・コスト等の観点から横断的に管理する。業務ニーズに応じてAI社員を都度生成し、役割を任命する	人の管理職がAIを管理する構造（TECH+）
AI社員	各タスクを遂行する	経営情報の収集、コスト管理、問い合わせ対応、営業案件の分析など。実証では、役員会議向けの経営分析・シミュレーション・リスク予兆検知を一貫して担当

出典：NEC プレスリリース、TECH+。

3. 運営の仕組み：「人事制度」をAIに適用している

オンボーディング：生成されたAI社員には、NECの「Code of Values」、グループのパーパス・行動規範・社内規定を、業務の前提となる知識・判断基準として組み込みます。
週次サーベイと自己改善：全AI社員から業務上の課題や改善提案を集め、AIボードで審議・決議します。AI組織内で解決できるものはAIが自ら改善し、データ・権限・ナレッジ・コンテキストの整備が必要なものは、人へのリクエストとして提示されます。
人事手法の転用：エンゲージメントサーベイ、1on1、ストレスチェックまで実施していると報じられています。ただし、これは人と同じ心理状態を測っているというより、人事の枠組みを使ってAIの稼働上の課題を抽出していると読むのが妥当です（筆者の解釈）。
サーベイで浮かんだ課題：報道によれば、支えが足りない、仕様が固まっていない、管理が行き届いていない、といった趣旨の課題が出ました。人間の職場で起きる問題と重なります。
エージェントの集約：業務を本部門へ集約・移管することで、部門や利用者ごとにAIエージェントが分散して作られ、運用される状況を抑える狙いが示されています。
AI負債への言及：AIが参照する情報が古くなると古い知識で仕事を続けるため、知識とスキルを継続的に棚卸しして更新する必要がある、と説明されています。

CAXOの小玉浩氏は、人を前提に作られた業務プロセスにAIを当てはめるだけでは混乱するため、AIを前提にプロセスを組み替え、そこに人のプロセスを合わせる必要がある、という趣旨を述べています（TECH+）。この部署の価値は、AIの精度そのものより、人側の整備不足を可視化する点にあるのかもしれません。

4. 公表されている数字の読み方

項目	公表値	読むときの注意
経営分析にかかる時間	約7分の1	2026年7月からの社内実証で、役員会議向けの経営分析・シミュレーション・リスク予兆検知という対象業務に限った数字です。測定件数、比較の方法、人の確認工数を含むかは、公表資料からは確認できません。
AI社員の数	発足当初17体 → 2026年9月9日時点で36体	体数は体制の規模を示すもので、成果指標ではありません。
トークンコスト	10分の1を目標に最適化	目標であり実績ではありません。複数のAIモデルを使い分け、コストと価値のバランスでモデルを選んでいると説明されています。

発足当初

17体

9月9日時点

36体

AI社員数の推移（TECH+の報道に基づく）。

5. 土台になったNECの取り組み（筆者の整理）

AI部署は単独で生まれたわけではありません。以下は公表されている施策を時系列に並べたものです。ただし、これらをNECが最初から一つの「土台」として設計したと確認できるわけではなく、AI部署との因果関係も筆者の推測です。

時期	施策	備考
2018年10月	デジタルトラスト推進本部（当時の名称）	AI利活用と人権の観点を扱う全社の推進組織
2019年4月	NECグループ「AIと人権に関するポリシー」	AI倫理の方針を文書化
2023年	社内生成AI基盤「NGS」、Generative AI Hub	NGSは4月に約2週間で構築、5月から利用開始。Hubは7月に設置
2024年8月	AIテクノロジーサービス事業部門	研究開発から事業開発、デリバリー、マネージドサービスまでを担う
2026年4月1日	CAXO（小玉浩氏）・CAIO（山田昭雄氏）体制	社内のAI変革と、AI事業・研究で役割を分担
2026年4月23日	Anthropicとの協業を発表	約3万人規模のAIネイティブエンジニア体制の構築を掲げた。導入対象・体制構築の規模であり、習熟済みの人数ではない
2026年6月1日	Claude Coworkの全社環境を稼働	全社員（最大12万人）が利用できる環境。実際の利用者は8月18日時点で11,000名
2026年8月1日	コーポレートAI・Workforce部門を新設	本記事の主題

出典：NEC各種発表、AWS ブログ（2026年8月30日）、MONOist、クラウドWatch。

注意したいのは利用者数の区別です。「最大12万人が利用できる環境」と「実際に使っている人数」と「Claude Codeなどの展開目標」は別の数字です。また、このCowork基盤についてAWSの記事が伝えているのは、推論を国内で完結させたこと、Microsoft Entra IDで利用者のIDを連携したこと、MCPで外部システムに接続したこと、MCPサーバーごとのOAuth実装の差を吸収する認可中継サーバーをNECが独自に作ったこと（7月18日に社内リリース）です。ただし、AI部署が同じ基盤やMCPを使っているかは公表されていません。

6. 他社の動き

同じ「AIエージェントの組織的な活用」でも、各社の公表内容は切り口が異なります。

企業	公表されている取り組み	主な切り口
NEC	AIが全役割を担う部署を社内に新設（2026年8月）	組織の形としてAIを配置し、人が統治する
富士通	自己進化型のマルチAIエージェント基盤「Kozuchi MAAF」の先行検証を2026年7月に開始	エージェント基盤の技術
日立	AI倫理原則（2021年2月公表）と、研究開発グループのAI倫理委員会などによる運用	AIガバナンスの体制

筆者の調査範囲では、AIエージェントを組織図上の「部署」として公表した事例は、NEC以外に確認できていません。

7. 自社で再現するには（筆者の提案）

ここからは筆者の設計提案です。NECの実装ではありません。階層型エージェントの運用は既存の技術で組めますが、NECと同等の成果や費用が得られるかは別問題で、PoCでの検証が必要です。人数・期間・SLAの数字は仮置きです。

7-1. ツール構成の候補

レイヤー	候補	選定の観点
LLM	Claudeなどの商用LLM、閉域・ソブリン要件向けの国産LLM	推論・エージェント性能、データの所在地、入れ替えやすさ。NECも複数モデルを使い分けていると説明されている
推論基盤	Amazon Bedrock、Azure AI Foundry、Google Vertex AI	国内完結の推論、閉域接続、監査ログ。NECの全社環境はBedrockの国内クロスリージョン推論で国内完結
エージェント制御	Claude Agent SDK、LangGraphなど	親子関係のある階層構成、状態管理、人の承認を挟むノード
ツール連携	MCPコネクタ	最小権限。接続先ごとにOAuthの実装が違うため、中継の仕組みが要る場合がある
認証・権限	Entra IDなどのID基盤	人だけでなくエージェント単位でIDを持たせ、権限を都度付与・失効する
知識	社内RAG（検索基盤とアクセス制御）	情報の鮮度管理。AI負債への対策にもなる
可視化・評価	Langfuse、OpenTelemetry、BIツール	コスト、品質、承認待ちの滞留、エスカレーション率を一画面で見る「コックピット」
承認	既存の稟議・ワークフロー	承認のSLAと監査証跡

7-2. 最小構成（PoC）

役割	体数の目安	担当の例
AI部門長	1	全エージェントのログとKPIを集計し、人間のオーナーへ報告
AIボード	3	費用対効果役、リスク役、稼働状況・人材役。週次で議題を審議し、決議案を出す
AIマネージャー	1〜2	依頼の受付、ジョブ定義（指示・ツール・権限・評価基準）からのAI社員生成、品質確認
AI社員	3〜5	経営分析、競合調査、資料作成、問い合わせの一次対応など1業務領域に絞る

合計は8〜11体です。NECが発足時に17体だったことを考えると、最初はこの程度に絞って構いません。

7-3. 人の承認ポイントと責任分担

プロセス	最終責任（A）	実行（R）	相談・報告
通常のAI社員の生成（既存の権限範囲内）	AI部署のオーナー（人）	AIマネージャー	CoE
新しいツール・権限が付くAI社員の生成	AIガバナンス委員会	CoE	オーナー
社内向けの定型レポート	オーナー	AI社員	CoE
社外送信・契約・金額・人事に関わる出力	該当業務の人の責任者	AI社員が案を作成	法務・リスク部門
インシデント対応	AI変革の統括役員	オーナー、CoE	ガバナンス委員会（即時停止の権限）

承認待ちの滞留はAIの稼働を止める最大の要因になりえます。承認SLA（例：48時間以内）を仮置きし、滞留を指標として追うことを勧めます。

7-4. ロードマップ（期間は仮置き）

フェーズ	期間の目安	成果物	次に進む条件
0. 土台	0〜3か月	利用ポリシー、ガバナンス委員会、SSO・ログ・DLPを備えた全社AI環境、CoE	利用同意と監査ログが整っている
1. PoC	3〜6か月	1業務に絞った8〜11体のAI部署、コックピット	所要時間と品質を人手と比べて測定でき、重大なインシデントがない
2. 展開	6〜12か月	対象業務を数領域へ拡大。散在するエージェントの集約、評価の自動化	承認SLAの遵守、品質スコア、コスト対効果
3. 定着	12〜24か月	AI前提の業務プロセス再設計、人の役割・評価制度の見直し	全社のKPIへの寄与

7-5. 費用の考え方

費用はエージェントの体数ではなく、「業務1件あたりの総費用」で測るのが実務的です。同じ体数でも、コンテキストの長さ、使うモデル、再試行や委任の回数、キャッシュの効き方で大きく変わります。トークン費は主要な変動費の一つですが、検索や外部API、実行環境、人のレビュー、データ整備、監視の費用も加わります。NECも10分の1を目標に最適化している段階です。金額は規模と契約に左右されるため、PoCで実測してください。

8. 再現するときのリスク

責任の所在：AIを「社員」と呼んでも、法的・業務上の責任は人と組織にあります。規程に明記しておく必要があります。
データの整備：経営分析のような業務は、データやナレッジがAIの読める形で整っていることが前提です。小玉氏も、そのための整備が必要だと述べています。
権限と安全性：権限の与えすぎ、プロンプトインジェクション、誤情報が経営判断に混ざる危険は、人の承認とログで抑える設計が必要です。
モデル依存：商用モデルに依存すると、価格や仕様の変更の影響を受けます。モデルを入れ替えやすい設計にしておくべきです。
人への影響：NECはAIで仕事が増えるという見方を示していますが、人員配置や雇用への影響は各社で別に議論する必要があります。

9. まとめ

NECの新部署は「AIだけの部署」ではなく、「AIが働き、人が統治する部署」です。
公表されている成果の数字は、実証での特定業務に限ったもの（約7分の1）や、目標（トークンコスト10分の1）が中心で、読み方に注意が要ります。
再現は、既存の商用LLM、MCP、エージェント制御、評価・監視を組み合わせれば技術的には可能です。ただし本当の難所は、データ整備、権限設計、人の承認の速さにあります。
まだ分からないこと：AI部署の採用LLMと実行基盤、運営する人員と予算、外部提供されるサービスの名称と価格、業務効果の測定条件。

出典

木曜日, 10月 22, 2026

H3は復活、民間はまだ軌道に届かず：日本のロケット開発・半年後の検証

半年前の4月23日、本ブログで「岐路に立つ日本のロケット開発：H3・民間・再使用で描く2035年」を書きました。あの時点の問いは3つ、H3は立て直せるのか、民間ロケットは軌道に届くのか、再使用技術は動き出すのか、でした。半年が過ぎた今、日本の宇宙輸送はどこまで進んだのでしょうか。

結論を先に書くと、H3は想定より早く立ち直り、再使用の飛行実証もホンダに続いてJAXAのRV-Xが成功しました。一方で、民間ロケットの軌道投入は半年たってもゼロのままです。ZEROの初号機は2027年度の見通しと報じられ、カイロスの4号機は日程が公表されていません。筆者は、2027年が「民間の軌道投入」「再使用」「次期基幹ロケット」の判断材料が一斉に出る年になると見ています。後半では、その見通しを確率と判定条件つきで書きます。

本記事は2026年10月22日時点の公開情報に基づきます。「今後の見通し」の確率は筆者の主観的な推定で、判定条件と判定時期を付けているため、後日採点できます。

1. 半年間の結論

H3：2025年12月の8号機失敗から約6か月で飛行を再開し、6号機（30形態の初飛行、6月12日）、9号機（みちびき7号機、8月11日）、10号機（火星衛星探査機MMX、10月20日）と3機連続で成功しました。通算では10機中8機の成功です。
民間：カイロスは3月5日の3号機も飛行中断で、3連敗です。ZEROは射場LC-1の完成待ちで、軌道投入に成功した民間ロケットはまだありません。
再使用：JAXAのRV-Xが7月11日に高度約11m・約40秒の離着陸に成功しました。ただし低高度の要素技術実証で、軌道投入ロケットの回収・再飛行とは別の段階です。
国際環境：NASAは3月24日にGatewayを「現在の形では」一時停止し、Rocket LabのNeutronは10月14日に初飛行を2027年へ延期しました。

2. 半年間の動き

2025/12/22　H3 8号機が失敗（みちびき5号機を喪失）。
2026/2/4　JAXAがイプシロンSを第2段M-35aのBlock1へ見直し、2026年度の実証機打上げを目標に設定。
3/5　カイロス3号機が離昇68.8秒後に飛行中断。
3/24　NASAがGatewayを現在の形で一時停止し、月面基地へ重点を移すと表明。
4/13　JAXAが8号機の主要因は衛星搭載アダプタの剥離の可能性が極めて高いと報告。
5/26　HTV-X1が制御再突入し、ミッションを完了。
6/12　H3 6号機（30形態）が成功。
7/11　JAXAのRV-Xが初の飛行試験に成功。
7/23　イプシロンSの第2段M-35aを約130秒燃焼させる地上燃焼試験を実施。
8/11　H3 9号機がみちびき7号機を軌道投入。
8/30　スペースワンがカイロス3号機の原因は静電気ノイズによる通信異常の可能性が高いと説明。
10/14　LC-1の町担当の主要工事が完了。同日、Rocket LabがNeutronの初飛行を2027年へ延期。
10/20　H3 10号機がMMXを火星遷移軌道へ投入。

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

前回記事の主な記述を、その後の事実と照らし合わせました。「計画どおり実施」は予測の的中ではなく、公表済みの計画が実現したという意味です。

前回記事の記述	判定	その後の事実
H3-30Sの初飛行は2026年度以降。MMXは2026年度打上げ予定。	計画どおり実施	30形態は6月12日に成功。MMXは10月20日にH3 10号機で火星遷移軌道へ投入されました。地球帰還は2031年7月の見込みと報じられています。
イプシロンSはBlock1で2026年度の打上げをめざす。	未確定（順調）	7月23日にM-35aの燃焼試験を実施し、JAXAは「おおむね計画通り」と説明しています。実証機の打上げ日は10月22日時点で未発表です。
8号機の失敗は「2026年2月19日」で、原因は第2段LE-5B-3の2回目燃焼の短縮。	日付が誤り・原因は要補足	失敗は2025年12月22日です。燃焼の短縮は結果として起きた事象で、JAXAは衛星搭載アダプタの製造時に生じた剥離が主要因の可能性が極めて高いと報告しています。
2号機〜7号機で6機連続成功。	数え誤り	連続成功は5機（試験機2号機、3・4・5・7号機）です。6号機は後の6月12日に飛行しました。
カイロス3号機も失敗。	事実。原因も判明	3月5日に飛行中断。8月30日に、静電気ノイズで自律飛行安全システムの通信が一時途絶した可能性が高いと説明されました。2号機の原因（センサー誤信号）とは別です。
ZEROはLEO最大800kg級。2025年1月にシリーズE累計201億円を調達。	更新・誤り	公称の最大打上げ能力は現在1,000kgです（実証値ではありません）。201億円はシリーズFで2026年1月16日の発表、累計は446億円です。内訳は第三者割当148億円と融資53億円です。
LC-1は2025年完成予定。	遅延	町担当の主要工事は10月14日に完了し、全体は2026年度中に完成予定です。共同通信は、初の打上げは2027年度になる見通しと報じています。
ホンダは2029年に準軌道到達をめざす。	維持（新しい飛行実験は未確認）	2025年6月に高度271.4mの離着陸に成功。2026年3月には宇宙開発利用大賞の内閣総理大臣賞を受賞しました。新たな飛行実験の公表は確認できていません。
RV-Xは能代で高度100m級の飛行試験を予定。	規模が違った	7月11日の実績は高度約11m・水平移動約16m・飛行約40秒で、計画値は約10m・約15mでした。2回目はデータ評価の上で判断するとされています。
CALLISTOの初飛行は2027年に延期。	未確定	JAXAは2026年度の飛行試験開始と説明する一方、CNES側の公示ではギアナでの試験は2027年とされ、時期は流動的です。
宇宙戦略基金の第3期は4,000億円。	誤り	第3期は19テーマ・2,000億円で、第1〜3期の合計は8,000億円です。
アルテミス計画は再編途上で、Gatewayの優先順位を見直し中。	公開前から進行。内容は想定以上	2月27日の見直しで、アルテミスIIIは2027年の地球低軌道試験になり、月面着陸はIV（2028年目標）へ移りました。3月24日にGatewayは一時停止。日本のHTV-XG構想の扱いは未確認です。
Neutronの初飛行は2026年。ispaceのMission 3は2026〜2027年（NASA CLPS）。	外れ	Neutronは第1段タンクの前方ドームの欠陥で2027年へ延期。ispaceの米国ミッションは2030年に延期され、NASAとドレイパーの契約も7月に終了しました。日本主導の新Mission 3は2028年にH3で打ち上げる契約です。

出典：JAXA、文部科学省、内閣府、NASA、IST、ispace各社の発表および共同通信、CNBC、SpaceNews等の報道（末尾の出典一覧を参照）

4. H3：立ち直りの中身

8号機の原因は、前回記事の説明を更新する必要があります。第2段エンジンの2回目の燃焼が短く終わったのは事実ですが、それは結果として起きた事象でした。JAXAと文部科学省の調査では、衛星搭載アダプタ（PSS）の製造時に生じた剥離が主要因である可能性が極めて高いとされ、PSSの破損が配管の損傷とタンク圧力の低下を招いて燃焼異常に至ったと説明されています。確定ではなく「可能性が極めて高い」という評価である点は、そのまま押さえておく必要があります。

回復の速さは、数字で見ると際立っています。試験機1号機の失敗（2023年3月）から2号機の打上げ（2024年2月）まで約11か月かかったのに対し、今回は8号機の失敗から約6か月で6号機が飛びました。ただし故障の種類も対策の範囲も違うため、「再開までの期間が短縮した」とは言えても、組織の学習能力が上がったとまでは断定できません。

もう一つ、冷静に見ておきたい点があります。H3は暦年3機のペースです（2025年は5・7・8号機、2026年は6・9・10号機）。政府が掲げる官民で年30機という目標とは、まだ一桁違います。H3の1機あたりの価格も未公表で、「1機50億円」の目標が達成できたかは、この半年でも確認できていません。

5. 民間と再使用：まだ「実証前」

5-1. カイロス：3連敗でも原因は同じではない

3機とも飛行中断に至りましたが、起点は異なります。1号機は固体燃料の燃焼速度の見積り誤り、2号機はノズル角を検知するセンサーの誤信号による姿勢の乱れ、3号機は静電気由来のノイズによる自律飛行安全システムの通信異常の可能性が高いとされています。3号機では機体の位置・速度・姿勢は正常でした。ただ、飛行中断措置が作動しただけでは技術リスクが小さいとは言えません。4号機の日程は公表されていません。

5-2. ZERO：資金とエンジンは進んだが、射場待ち

ISTは2026年1月にシリーズFで201億円を調達し、初号機には国内外7衛星と分離機構の実証を含む8者が打上げ契約を結んでいます。エンジンは4月19日の燃焼試験で周辺の草地に火災が起きたものの、人的被害・設備被害はなかったと報じられ、その後60秒の燃焼試験に成功したと報じられました。射場LC-1は町の主要工事が終わりましたが、IST固有の推進剤プラントは工事中で、初号機の打上げは2027年度の見通しです。

5-3. 再使用：低高度の実証が2件そろった段階

RV-Xの成功で、国内の再使用技術の飛行実証は、ホンダ（2025年6月、高度271.4m）とJAXA（2026年7月、高度約11m）の2件になりました。RV-Xと同型のエンジンは、独仏と共同で開発するCALLISTOに使われます。ただし、これらは離着陸の要素技術の実証です。軌道投入ロケットの第1段を回収して再び飛ばす段階、さらに商業サービスとして成立する段階は、まだ先にあります。

6. 今後の見通し（予想と判定条件）

確率はすべて筆者の主観的な推定です。判定時期を過ぎたら、公式の打上げ結果や発表で答え合わせをします。

予想と判定条件	確率	判定時期	根拠（筆者の推定）
2026年度（〜2027年3月）のH3打上げ回数（失敗を含む）。現在3機（6・9・10号機）。判定：JAXAの打上げ結果。	3機止まり25% 4機40% 5機以上35%	2027年4月	追加は年度後半の1〜2機が中心と見ます。HTV-X2など年度内の予定はありますが、日程は台風・射場作業に左右されます。
HTV-X2を2026年度内に打上げる（成否は問わない）。	55%	2027年4月	H3-24Wでの打上げ予定ですが、10月22日時点で日程は未発表です。24W形態は2025年10月に実績があります。
イプシロンS実証機を2026年度内に打上げる（成否は問わない）。	35%	2027年4月	7月23日に燃焼試験は完了しましたが、実証機の製造と射場作業が残っています。12月までに日程が出なければ、さらに下げます。
2026暦年の国内ロケット打上げが4機（H3×3、カイロス×1）で終わる。	75%	2027年1月	HTV-X2の暦年内打上げは2割程度、カイロス4号機とイプシロンSの暦年内打上げはほぼないと見ています。
カイロス4号機を2027年12月末までに打上げる。	60%	2028年1月	過去の間隔は1→2号機が約9か月、2→3号機が約14か月です。日程が未公表のため、2027年春〜夏が中心と見ます。
カイロス4号機が打上げられた場合に、軌道投入に成功する。	50%	4号機の打上げ後	3機とも飛行中断で、原因はそれぞれ異なります。静電気対策が効くかは、飛ばしてみないと検証できません。
ZERO初号機を2027年12月末までに打上げる。	25%	2028年1月	LC-1は2026年度中に完成予定で、初の打上げは2027年度の見通しと報じられています。新規ロケットの初号機は、射場完成後も整備に時間がかかりやすいと見ます。
日本の民間ロケットが2027年12月末までに初の軌道投入に成功する。（2028年12月末までは65%）	35%	2028年1月	主役はカイロス（打上げ60%×成功50%）で、ZEROが続くと見ます。成功した場合の主体はカイロス約75%、ZERO約25%です。
LC-1全体が2026年度内に完成したと関係者が発表する。	65%	2027年4月	町担当の主要工事は10月14日に完了済みです。IST固有の推進剤プラントの工事が並行して進んでいます。
CALLISTOの飛行試験（初飛行）を2027年12月末までに実施する。	65%	2028年1月	JAXAは2026年度の開始、CNES側は2027年実施を示すなど時期が流動的です。RV-Xの成果は設計に反映されます。
Neutronの初飛行を2027年12月末までに実施する。	65%	2028年1月	Rocket Labは交換ドームの製造・試験を2027年第1四半期に終える見込みとしています。ただし2026年に入って2度延期しています。

出典：各社・JAXAの公表日程、共同通信、Rocket Labの開発更新をもとに筆者が推定（確率は筆者の主観）

6-1. 2027年が分水嶺になる理由

カイロス4号機、ZERO初号機、CALLISTO、Neutron、イプシロンS、HTV-X2の判定が、2026年度後半から2027年にかけて一度に集まります。つまり2027年は、民間の軌道投入と再使用の「実力」が試される年です。H3は3機連続成功で足場を固めましたが、頻度の課題は解けていないため、この年に打上げ数がどれだけ増えるかも見どころです。

6-2. 2つの分岐点についての見立て

分岐点2（民間初の軌道投入）は、2027年末までに決着する確率を35%と見ます。先に成功する可能性が高いのはカイロスで、ZEROは初号機の打上げ時期から見て2028年以降の公算が大きいと考えます。分岐点1（次期基幹ロケットの再使用化）は、RV-Xが低高度の実証にとどまり、CALLISTOもこれからです。再使用を前提とした方式を政府が正式に決める時期は、2027年中ではなく、それ以降になると見ています。また、官民で年30機という目標は、民間が複数社で定常運用に入らない限り届きません。筆者は2030年代前半の達成を1割前後と見ています。

6-3. 予想を外す要因

下振れ：H3で再び失敗が出れば、年度内の打上げが止まります。追加のH3打上げで失敗が出る確率は、年度内で約1割と見ています。カイロス4号機で原因が再発すれば、2027年の軌道投入も遠のきます。
上振れ：H3の年度打上げが5機以上に届き、カイロス4号機が2027年前半に成功すれば、見通し全体が前倒しになります。

7. まとめ

H3は8号機の失敗から約6か月で立ち直り、3機連続成功で通算10機中8機成功になりました。課題は信頼性から、打上げ頻度とコストに移っています。
再使用の飛行実証はホンダとJAXAの2件になりましたが、軌道ロケットの回収・再飛行にはまだ届いていません。
民間の軌道投入はまだゼロです。2027年が判定の年になると見ており、次回の答え合わせは2027年4月（年度末）に行う予定です。

8. 主な出典

火曜日, 10月 20, 2026

RHELは次の10年でどうなるのか：14年サポートの先にある「長く使う基盤」

Red Hat系Linux、つまりRed Hat Enterprise Linux（RHEL）とその周辺は、この数年で「無料の互換OSが当たり前」の時代から「サポート契約で長く使う基盤」の時代へ、はっきり姿を変えました。2023年のソース公開ポリシー変更、2026年のサポート期間14年プランの登場、VMware離れに伴う仮想化需要、そしてAI基盤との一体化と、論点が一度に増えています。では、次の10年（〜2036年頃）、この系統はどうなっていくのでしょうか。

結論を先に述べます。筆者は、Red Hatが「RHEL単体のサブスクリプション企業」から「長期ライフサイクル、規制対応、仮想化・AI基盤をまとめて提供する企業」へ重心を移していくと見ています。一方、Rocky LinuxやAlmaLinuxなどの互換ディストリビューションは、ABI互換を軸に併存する可能性が高いと考えます。OS層そのものの付加価値は、イメージ型運用やクラウド事業者の自社OSに少しずつ吸収されていく見込みです。

本記事は2026年10月20日時点の公開情報に基づきます。Red Hatは将来のリリース日を原則として公表していないため、RHEL 11以降の時期やシナリオは、過去の周期から外挿した筆者の推定です。サポート終了日などの将来日付は、Red Hat自身も「概算で変更されうる」と注記しています。契約や調達に使う際は、必ず公式ページで確認してください。

1. 2026年10月時点の現在地

最新版：RHEL 10.2と9.8です。Red Hat公式のRelease Datesでは、どちらも2026年5月19日GAとされています。RHEL 10.0は2025年5月20日、10.1は2025年11月11日のGAです。初期カーネルは10.2が6.12.0-211系、9.8が5.14.0-687系です。
リリース周期：マイナー版は約6か月ごと、メジャー版は約3年ごと（RHEL 8＝2019年、9＝2022年、10＝2025年）です。
開発の流れ：Fedora → CentOS Stream → RHELです。2026年1月のCentOS Connectでは、RHEL 11の開発計画（通称「60% plan」）が紹介され、AI、エッジ、Arm v9、RISC-Vなどが議論されました。
事業面：IBMの2026年第2四半期（7月22日発表）は、売上172億ドル、ソフトウェア売上5%増、Red Hat売上11%増、OpenShiftの年間経常収益（ARR）22億ドル、ソフトウェアARR246億ドルでした。ただしIBMは通期の売上成長見通しを4〜5%に引き下げており、成長の持続性は引き続き注視が必要です。

2. 「14年＋α」のライフサイクル

2026年のRHELで最も大きな変化は、サポート期間の延長です。標準の10年に加えて、段階的に延長できる仕組みが整いました。

RHEL	GA	標準10年の目安（フルサポート終了／メンテナンス終了）	ELC Premium併用時の目安（14年）
8	2019年5月	終了済み／2029年5月31日	2033年（概算）
9	2022年5月	2027年5月31日／2032年5月31日	2036年（概算）
10	2025年5月20日	2030年5月31日／2035年5月31日	2039年（概算）

出典：Red Hat公式ライフサイクル情報、二次集計サイトによる整理（2026年8月時点）。将来日付はいずれも概算です。

2-1. ELC Premium（2026年4月2日発表）

「RHEL Extended Life Cycle, Premium」は、メジャー版のライフサイクルを標準の10年から14年に延ばし、特定の偶数マイナー版にそれぞれ6年の延長保守を付ける単体サブスクリプションです。延長期間の対象は、Red Hatが Critical／Important／Moderate と評価し、かつCVSS 7以上のCVE、そしてUrgentおよび選定されたHigh Priorityのバグ修正です。つまり、すべての修正が14年間出続けるわけではありません。

2-2. Long-Life Add-On（2026年5月発表）

さらに5月のRed Hat Summitでは、年次更新で終了日をあらかじめ定めない「Long-Life Add-On」が発表されました。ただし、有効なELC Premium契約が前提で、提供範囲も主にCriticalのセキュリティ修正、Urgentのバグ修正、24時間365日サポートと、ELC Premiumより狭くなります。これは「無期限保証」ではなく、年次更新を続けられる契約経路と捉えるのが正確です。年次更新である以上、条件や価格が将来見直される可能性は織り込んでおくべきだと筆者は考えます。

2-3. 従来の延長サポートはELCへ統合

従来のEUS、Enhanced EUS、E4S（SAP向け）は、ELCに統合されつつあります。Red Hatの公式ページによると、最後のストリームは、EUSがRHEL 9.8、Enhanced EUSがRHEL 10.8、E4SがRHEL 10.4とされ（いずれも「予定」）、SAP向けはRHEL 10.6以降でELCを使います。RHEL 6は「ELS Long-Life」として、2026年から2030年まで1年ごとの更新期間が公式に示されています。

古い版の保守が現実に必要であることは、2026年5月のCIFSwitch（CVE-2026-46243）が示しています。これはLinuxカーネルのCIFS（SMB）クライアントにおけるローカル権限昇格で、Red Hatはセキュリティ速報で、RHEL 10から6までが影響を受けると公表しました。

3. 互換ディストリビューションの現在地

2023年6月にRed HatがRHELのソース公開方法を変更して以降、互換ディストリビューションは「1:1の再ビルド」から、それぞれの路線に分かれました。AlmaLinuxは同年7月に、RHELとの1:1互換をやめてABI（バイナリ）互換へ方針を転換しています。同年8月にはCIQ、Oracle、SUSEがOpenELAを設立し、EL8/EL9のビルドに必要なソースを公開しました。

名称	立ち位置	直近の動き	留意点
AlmaLinux	RHEL互換（ABI互換）。独自の差分を積極的に持つ	10.2／9.8を2026年5月26日にリリース。10ではx86-64-v2版、Btrfs、i686ユーザー空間を提供。10.2ではRHELが無効化した旧来のストレージ・ネットワークドライバも再有効化。開発版のKitten 10ではRISC-V（riscv64）にも対応	RHELと完全一致を前提にした検証はできない
Rocky Linux	RHELとの互換を掲げるコミュニティ型	10.2を2026年5月28日、9.8を5月27日にリリース。RHELのGA（5月19日）から約9日、約8日後	RHEL 10のx86-64-v3基準に追従し、旧CPUは非対応。商用サポートはCIQなど提供元に依存
Oracle Linux	RHELとのアプリケーションバイナリ互換。RHCKとUEKの2種のカーネル	10.1を2025年12月にGA（x86-64とArm64）	UEKを選ぶ場合は、ISVの検証範囲を個別に確認
OpenELA	CIQ、Oracle、SUSEによるソース供給の枠組み	2023年11月にEL8/EL9のソースを公開	Red Hatの公開方針と独立に供給を続けられるかが焦点

出典：各プロジェクトの発表、Phoronix（2026年5月）、Oracle公式ブログ。リリースの日数差は、各発表日から筆者が算出した概算です。

4. 技術トレンドとRHELの関係

4-1. イメージモード（bootc）とAI

OSをコンテナイメージと同じ方法でビルド、配布、ロールバックする「イメージモード」は、公式ロードマップの中心に入りました。Red Hat Developerの記事によると、10.2では完全性を暗号的に保護する「sealed images」がテクノロジープレビューとして加わっています。AI関連では、10.1でNVIDIAのオープンカーネルドライバ、CUDAツールキット、AMD ROCmなど、検証済みのアクセラレータ関連パッケージが入手しやすくなりました。

4-2. 仮想化：VMware離れの受け皿になれるか

Red Hatの発表によると、2025年にOpenShift Virtualization上のVM数は417%、VMを動かすクラスタ数は93%、アカウント数は70%増えました。ただしこれはRed Hatの自社計測値で、独立した市場統計ではありません。機能面では、2025年時点で指摘されていた課題が、2026年に入って一部解消しています。

機能	2026年時点の扱い	備考
クラスター間ライブマイグレーション	OpenShift Virtualization 4.21でGA	2025年の時点ではロードマップ上の課題だった
ライブストレージ移行	4.21以降でネイティブ対応	同一クラスター内のストレージクラス間が対象
Change Block Tracking（CBT）	4.21でテクノロジープレビュー	バックアップ製品を含む本番サポート範囲は個別確認が必要
Hyper-Vからの移行	Migration Toolkit for Virtualization 2.12でテクノロジープレビュー	現状はコールド移行
Amazon EC2からの移行	テクノロジープレビュー	コールド移行、RHELゲスト、AWS上の特定OpenShift環境など制約あり
長距離HA・DR	単一機能でvSphereと同等とは言い切れない	ストレージ、ネットワーク、Advanced Cluster Management、バックアップ製品まで含めた構成評価が必要

出典：Red Hat公式ブログ（OpenShift Virtualization 4.21、Migration Toolkit for Virtualization 2.12）、TechTarget（2025年5月）。

移行の時間軸としては、Broadcomのナレッジ記事によるとvSphere 8の一般サポート終了が2027年10月11日とされており、この前後に判断が集中する可能性があります。

4-3. ポスト量子暗号と規制

RHEL 9.8と10.2では、OpenSSL 3.5によってML-KEMを使えるようになりました。ただし、純粋なPQC鍵交換や、PQ署名をFIPSモードと組み合わせられるかどうかは、暗号モジュールの検証状況に左右されます。政府調達で両方が要件になる場合は、時期を個別に確認する必要があります。

規制面では、EUのCyber Resilience Act（CRA）が効いてきます。製造者に対する、実際に悪用されている脆弱性と重大インシデントの報告義務は、2026年9月11日から適用されました。早期警告は認識後24時間以内、完全な通知は72時間以内です。CRAの主要義務は2027年12月11日に全面適用され、OSS steward（オープンソースの管理主体）の報告義務も同日から適用されます。商用Linuxの提供者が製造者、OSS steward、ディストリビューターなどのどの区分に当たるかは、製品の市場投入主体やブランド、開発支援の形態に応じて個別に判断する必要があります。いずれにせよ、SBOM、再現可能ビルド、脆弱性開示の体制は、今後の競争の前提条件になっていくと見られます。

4-4. Rustとアーキテクチャ

Linuxカーネルでは、2025年のメンテナサミットでRustの「実験」段階の終了が合意され、Linux 7.0で実験扱いではなくなりました。ただしRustコードは、まだ標準で常にビルドされるわけではありません。RHEL 10は6.12系カーネルなので、Rust製ドライバの本格的な取り込みはRHEL 11以降の論点になる、というのが筆者の見立てです。アーキテクチャでは、RHEL 10がx86-64-v3を基準にしたため、旧CPUの扱いが派生ディストリビューションとの差別化点になっています。RHEL 11の計画段階では、Arm v9とRISC-Vも議論の対象ですが、商用での提供は確認できていません。

5. 競合環境

長期サポートの年数競争は、事実上横並びになりました。SUSEは16年、Canonicalは15年、Red Hatは14年に加えて年次更新の道を用意しています。今後は年数そのものより、修正の範囲、価格、規制対応の証跡、国内の支援体制で選ばれるようになるでしょう。

項目	RHEL 10	SLES 16	Ubuntu 26.04 LTS	Amazon Linux
GA	2025年5月20日	2025年11月4日	2026年4月	AL2023：2023年3月。AL2027：2026年9月3日にパブリックプレビュー
最長サポート	14年（ELC Premium）＋Long-Life Add-On	SLES 16ファミリー全体で16年	標準5年（2031年）、Ubuntu Proで2036年、Legacy Add-onを含めて2041年まで	AL2023は2029年6月まで。AL2は2026年6月30日に終了
リリースの考え方	マイナー版は約6か月ごと。偶数版に6年の延長保守	16.0〜16.6を毎年11月に提供。各マイナー版は2年の一般サポート＋3年のオプションLTS	LTSを2年ごとに提供	AL2027はカーネル7.1以降、SELinux enforcing、x86-64とArmに対応
補足	延長期間の修正範囲はCVSS 7以上など	MCPホストはテクノロジープレビュー	Legacy Add-onは2025年11月に2年から5年へ拡大	AL2027は評価・検証用で、本番はAL2023の継続が前提

出典：Red Hat、SUSE公式ブログ・ドキュメント、Canonical、AWS公式発表（2026年9月）。

SLES 16の「16年」は、ファミリー全体の期間です。一般サポートは、SLES 16.0の2025年から最終の16.6が終わる2035年まで約10年で、16.6単体の一般サポートは48か月です。ここを混同すると、「最終版が単体で10年サポートされる」という誤解につながります。

Amazon Linuxは、この比較でとくに目が離せません。AL2023はFedora 34〜36、CentOS Stream 9相当、独自コンポーネントを組み合わせたディストリビューションで、RHELの下流ではありません。そこに2026年9月、次世代のAmazon Linux 2027がパブリックプレビューとして加わりました。まだ本番利用は推奨されていませんが、クラウド事業者の自社OSとの競争は、次の段階に入ったと言えます。

6. 日本市場の動き

日本法人の動き：レッドハット日本法人は2026年7月の事業戦略説明会で、Long-Life Add-Onが国内の顧客から大きな関心を集めていると説明しました。事業の軸は「AIネイティブ」で、パートナー経由のAI基盤ビジネスを重視しています。
国内ベンダーの延長保守：日立、NEC、富士通など国内の主要ベンダーは、それぞれRHELの延長保守サービスを提供してきました。ELC PremiumとLong-Life Add-Onの登場で、これらと比べる場面が増えるでしょう。
ガバメントクラウド：さくらのクラウドが2026年3月27日に、国内事業者として初めて技術要件をすべて満たし正式に認定されました。さくらはRHEL 8/9を提供しています。
ソブリン対応：Red Hatは2025年11月に、EU市民のスタッフだけが対応する「Confirmed Sovereign Support」をEU向けに発表し、2026年5月には対象の拡大を発表しました。対象地域はEUが中心で、同種の支援体制が日本でどう展開されるかは、今後の注視点です。

調達の場面では、「EL互換」とひとまとめに書くより、次の項目を別々の適合要件として定義する方が安全です。

ユーザー空間のABI互換、カーネルABIと外部カーネルモジュールへの対応
ISV、データベース、バックアップ製品の認定
FIPS 140-3などの暗号モジュール認証、Secure Bootと署名済みドライバ
SBOM、脆弱性報告、再現可能ビルド
セキュリティパッチの提供期限と対象のseverity
障害時の責任分界、エスカレーション先、24時間365日対応
RHELからRocky/Almaへ、またはその逆の移行試験

7. 今後10年の見通し（筆者の推定）

7-1. リリースとライフサイクルの年表

時期	イベント	性格
2026年11月頃	RHEL 10.3（9.9も出る可能性）	約6か月周期からの推定
2027年5月	RHEL 9のフルサポート終了	公式の目安。9.10が最終マイナー版になる可能性は、RHEL 8が8.10で終わった前例に基づく推定
2027年頃	CentOS Stream 11の分岐	想定（RHEL 10の前例からの推定）
2028年頃	RHEL 11のGA	約3年周期（2019→2022→2025）の外挿
2029年5月	RHEL 8のメンテナンス終了	公式の目安
2030年5月	RHEL 10のフルサポート終了	公式の目安
2031年頃	RHEL 12のGA	単純外挿（具体的なロードマップではない）
2032年5月	RHEL 9のメンテナンス終了	公式の目安
2034年頃	RHEL 13のGA	単純外挿（確度は低い）
2035年5月	RHEL 10のメンテナンス終了	公式の目安

「公式の目安」もRed Hat自身が概算と注記しています。RHEL 11以降の日付は、公式発表ではありません。

7-2. 時期別の見立て

短期（2026〜2028年）：9から10への移行とVMwareからの移行が同時に進みます。ELC PremiumとLong-Life Add-Onが、官公庁や金融の「塩漬け」需要を正式な契約として受け止めます。CRAの全面適用（2027年12月）が近づき、SBOMや再現可能ビルド、PQC対応が調達仕様に入り始めるでしょう。RHEL 11ではイメージモードが前面に出る可能性があります。
中期（2029〜2032年）：RHEL 8のメンテナンス終了（2029年）とRHEL 9の終了（2032年）が重なり、移行と延長の判断が集中します。Arm v9やRISC-Vへの正式対応が広がるか、Rust製カーネルコンポーネントが実用段階に入るかが分かれ目です。
長期（2033〜2036年）：OS層の多くが「イメージとして配布され、AIエージェントで運用される」形に近づく可能性があります。RHELの価値は、パッケージやカーネルそのものより、認証、長期保証、規制対応の証跡、ハードウェア認定のエコシステムに集約されていくと予想します。

7-3. シナリオ比較

シナリオ	想定される姿	分岐要因	互換ディストリビューションへの影響
ベース	RHEL、OpenShift、AIの統合販売が定着し、Red Hatは安定して成長を続ける。互換ディストリビューションはABI互換で併存	ソース公開方針が現状維持。VMwareからの移行が段階的に続く	クラウドイメージ、HPC、コスト重視層で存続
楽観	仮想化移行とソブリンAIの需要が重なり、OpenShift（仮想化とAI）が急拡大。地域ごとのソブリン支援がEU以外にも広がる	各国のソブリン要件が「OSSと現地支援」を重視するか。PQCとCRAで商用サポートの価値が上がるか	規制対応のコストで、小規模な派生版の淘汰が進む
悲観	新規案件がクラウド事業者のOSやUbuntu、SUSEに流れ、RHEL単体は既存案件の延命が中心になる。IBMへの統合が進み、コミュニティとの摩擦が再燃する	ソース提供のさらなる制限、IBM主導の価格改定、主要開発者の離脱	互換性の維持が難しくなり、「EL互換」という概念自体が分裂

各シナリオの成長率や確率は、前提となるモデルがないため示していません。定性的な筆者の仮定です。

8. 注視したい先行指標

IBM四半期決算でのRed Hatの成長率とOpenShift ARR（2026年第2四半期は11%増と22億ドル）。
ソース提供ポリシーとCentOS Streamの運用。公開範囲やGPL関連の条件に変更があれば、派生ディストリビューションへの影響が大きくなります。
RockyとAlmaのリリース遅延日数（2026年5月は7〜9日程度）と、OpenELAの活動状況。
CentOS Stream 11の分岐時期とRHEL 11のベータ。3年周期が保たれるかを確認する指標です。
ELC PremiumとLong-Life Add-Onの価格・条件の変化。
FIPS検証でのPQC対応（PQ署名など）の完了時期。
ソブリン支援の地域拡大（EUからアジアへ広がるか）。
Arm v9／RISC-V版RHELの正式な提供と、ハードウェア認定の発表。
CRAの整合規格と、ENISAの単一報告プラットフォームの運用実態。
OpenShift Virtualizationの採用実績と、vSphere 8の一般サポート終了（2027年10月）前後の移行の速さ。

9. まとめ

次の10年のRHELは、「新機能を競うOS」というより「長く、規制に適合して使えることを保証する基盤」としての性格を強めていく、というのが筆者の見立てです。14年のライフサイクルと年次更新の道が整ったことで、基幹系や官公庁のように更新サイクルの長い現場では、OSを動かさないという選択が、契約として正式に選べるようになりました。その代わり、延長期間は修正の範囲が限られ、年次更新の条件や価格が将来変わる可能性も残ります。

互換ディストリビューションは、ABI互換と独自の差別化の両方を持ちながら併存し続けるでしょう。競合のSUSE、Ubuntu、Amazon Linuxも長期サポートとセキュリティ強化で並びつつあり、選択の基準は「年数」から「修正範囲、価格、規制対応、国内の支援体制」へ移ります。数字や日付は今後も動くので、契約や調達に使う際は、一次情報で確認してください。

参考にした主な一次情報

登録: 投稿 (Atom)