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

月曜日, 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も長期サポートとセキュリティ強化で並びつつあり、選択の基準は「年数」から「修正範囲、価格、規制対応、国内の支援体制」へ移ります。数字や日付は今後も動くので、契約や調達に使う際は、一次情報で確認してください。

参考にした主な一次情報

日曜日, 10月 18, 2026

Windows Serverの今後10年：OSは継続するが、運用・課金・延長保守の重心はAzure Arcへ移る

Windows Server は今後どうなるのか。クラウド移行が語られるたびに「そろそろ終わるのでは」という声が出ますが、現時点で公式に確認できるのは、現行の Windows Server 2025 が2034年11月まで延長サポート対象であること、そして次期 LTSC（長期サービスチャネル）の Insider プレビューが続いていることです。2036年に製品系列が残っている可能性は高いと考えますが、これは予測であり、次期版の名称・提供時期・サポート期間は未発表です。

変わりつつあるのは OS そのものより、運用・課金・延長保守の窓口です。Microsoft は、更新管理、従量課金、管理特典、ESU（拡張セキュリティ更新）、非 Azure 環境向けの Hotpatch といった「ハイブリッド環境の運用価値」を Azure Arc に寄せています。ただし Arc は Windows Server を別の OS に変えるものではなく、サーバーに Azure の管理面を追加する仕組みです。この記事では、この違いを意識しながら、現状と今後10年（2026〜2036年）の見通しを整理します。

本記事は2026年10月18日時点の公開情報に基づきます。根拠の強さを3段階で書き分けています。【Microsoft発表】公式文書で確認できる事実、【外部データ】第三者調査や報道に基づく推論、【筆者の仮定】筆者のシナリオ設定です。確率や時期の予想はすべて【筆者の仮定】であり、Microsoft の公式見解ではありません。

1. 現在地：サポート期限と Windows Server 2025

【Microsoft発表】Windows Server 2025 は2024年11月1日に一般提供が始まり、メインストリームサポートは2029年11月13日、延長サポートは2034年11月14日までです（リリース情報の表の日付）。Lifecycle ページは時刻付きで11月14日（メインストリーム）・11月15日（延長サポート）と表示されるため、資料に使う際は出典を併記してください。サードパーティのサイトには「2034年10月」「2035年」といった異なる記載もあるため、日付は Microsoft の公式ページで確認してください。

バージョン	メインストリーム終了	延長サポート終了	備考
2016	2022年1月11日	2027年1月12日	ESU は最長3年（2030年まで）。Arc 経由で2026年8月から Azure portal で設定でき、請求開始は2027年1月13日（Microsoft Learn）
2019	2024年1月9日	2029年1月9日	ESU は未発表
2022	2026年10月13日（終了済み）	2031年10月14日	メインストリーム終了後も、延長サポート期間中はセキュリティ更新が続く。「メインストリーム終了」と「サポート終了」は別物
2025	2029年11月13日	2034年11月14日	現行の LTSC。2024年11月1日に一般提供開始

出典：Microsoft Learn「Windows Server release information」、Microsoft Lifecycle ページ、Microsoft Learn「Arc 対応 ESU の準備」

【Microsoft発表】Windows Server 2025 の主な機能強化は次のとおりです。Hyper-V の Gen2 VM は最大メモリ240TB、仮想プロセッサ2,048に拡張されました（2,048 は PowerShell のみでの構成で、ゲスト OS 側の上限は別です）。ネイティブ NVMe スタックは2025年10月以降の累積更新でオプトイン機能として利用可能になりました。Microsoft の測定（Intel 2ソケット機、NVMe SSD、DiskSpd の 4K ランダムリード、NTFS）では、WS2022 比で IOPS が最大約80%向上し、I/O あたりの CPU サイクルが約45%減っています。結果は構成によって変わると注記されており、機能は既定で無効です。実ワークロードでの検証が前提になります。

2. Azure Arc は何で、何ではないか

Azure Arc は、オンプレミスや他社クラウド上のサーバーに、Azure の管理・ガバナンスの面を追加する管理プレーンです。Windows Server を別の OS に変換するものではありません。一方、Azure Local（旧 Azure Stack HCI）は仮想化・HCI を含む別のインフラ製品で、Arc とは位置づけが異なります。「Windows Server が Arc や Azure Local という OS になる」という読み方は技術的に不正確です。

また、「価値がすべて Arc 前提になる」とも言えません。Arc が前提になるのは運用・商用面の機能で、OS 本体の機能は Arc なしでも使えます。

機能	Arc 接続	条件・補足
Hotpatch（オンプレ・他社クラウド）	必要	WS2025 Standard／Datacenter が対象で、VBS の有効化と Arc 接続が前提（その他の対応プラットフォーム要件は Microsoft の Hotpatch 文書で確認）。2026年5月19日以降は追加料金なし（それ以前は月額課金）。四半期のベースライン月は再起動が必要
Hotpatch（Datacenter: Azure Edition）	不要	Azure 上で既定で有効
Windows Server Management enabled by Azure Arc（Update Manager など）	必要	SA 付きライセンスまたはサブスクリプションの顧客は追加費用なし（ネットワーク・ストレージ・ログ取り込みは別途）。権利の申告が必要（Windows Server の従量課金に登録していれば自動で付与）。Hotpatch は別枠で、この権利の対象外
ESU（2016）	主要経路が Arc	Arc 以外の経路もあるため「Arc のみ」とは言えない。詳細は4章
Hyper-V、AD、AD CS、PQC の API、ネイティブ NVMe	不要	OS 本体の機能。NVMe は既定無効のオプトイン

出典：Microsoft Azure Arc ブログ、Azure Update Manager ドキュメント、Windows Server ブログ

3. リリースモデルと次期バージョン

3-1. LTSC は10年サポートを維持している

【Microsoft発表】Microsoft Learn は、LTSC の新しいメジャーバージョンを「通常2〜3年ごと」に出し、メインストリーム5年＋延長5年のサポートを提供すると説明しています。実績は2016、2019（2018年11月）、2022（2021年8月）、2025（2024年11月）で、およそ3年周期です。これは現行制度の説明であり、2036年まで制度が変わらない保証ではありません。

3-2. Annual Channel は縮小しているように見える

【Microsoft発表】Annual Channel（コンテナホスト向け）のリリースは2023年10月の23H2が最後で、後継は出ていません。Microsoft Learn は Annual Channel を通常12か月ごとにリリースすると説明していますが、23H2 の後継は確認できませんでした。AKS では Annual Channel のノードイメージはプレビュー扱いで、2026年5月15日に新規作成と更新が終了し、既存イメージは2027年5月15日に削除されます。ライフサイクルページ上は Annual Channel 自体がまだ「サポート中」と表示されており、Microsoft が全体の終了を宣言したわけではありません。【筆者の仮定】コンテナ用途は LTSC と Kubernetes 側に吸収され、Annual Channel は実質的に縮小すると見ています。「AKS 自体のサポート終了」ではない点にご注意ください。

3-3. 次期 LTSC：公式に言えること、言えないこと

【Microsoft発表】Windows Server Insider の告知では、次期版のプレビュー（Build 29641、2026年8月）の有効期限が2027年10月15日に延長されました。プレビュー中の機能としては、VM の Trusted Launch、Quick Machine Recovery、NVMe-oF イニシエーター、ReFS ブートなどが告知されています。製品名、一般提供日、サポート期間はいずれも未発表です。コードネームや「Windows Server 2028」といった名称を載せたファンサイトの情報は、Microsoft が確認していないため、ここでは採用しません。

【Microsoft発表】2026年9月21日公開の KB5129631 では、Windows Deployment Services（WDS）サーバーロールを「次の Windows Server リリースから非推奨にする計画」と案内しています。非推奨は削除とは別で、WDS は Windows Server 2025 以前の現行サポート版では引き続き使えます。Microsoft Configuration Manager の OS 展開は影響を受けないと説明されています。

4. ESU と課金モデル

【Microsoft発表】Microsoft は2026年2月25日に Windows Server 2016 の ESU を発表し、Azure Arc 経由で提供すると案内しました。Microsoft Learn によると、対象は Standard／Datacenter で、Arc 経由で購入するにはボリュームライセンス経由の Software Assurance（SA）が必要です。SPLA やサーバーサブスクリプションのライセンスなら SA は不要とされています。提供されるのはクリティカルと重要のセキュリティ更新で、最長3年（2030年まで）です。Azure portal では2026年8月から設定でき、請求は2027年1月13日に始まるとされています。VDI のマシンは Arc ではなく MAK で提供するなど、Arc だけが唯一の経路という整理にはなりません。Windows Server 2016 の ESU 価格は、今回確認した Microsoft の公開ページには掲載されていません。

価格の扱いには注意が必要です。Microsoft は2026年3月27日の Microsoft Licensing の告知で、2026年4月1日以降に提供する新規の ESU について、Azure・オンプレミス・他社クラウドのどこで買っても、また購入チャネルによらず同じ list price にする「標準化」を案内しています（Windows Server 2012 など既存の ESU には適用されません）。そのため、Windows Server 2012 のときのように「Azure に移せば ESU は無償」という前提は、2016 ではそのまま置けないと考えられます。一方で Microsoft Learn は、Azure VMware Solution と Azure Local 上の VM は無償の ESU の対象で、Arc では登録しないと説明しています。Azure 上の通常の VM の扱いは今回確認できておらず、適用条件は Windows Server 2016 向けの公式 FAQ と Product Terms で個別に確認してください。

【外部データ】CSP 経由の購入では、2026年10月1日から、年間契約を月払いにしているソフトウェアサブスクリプション（Windows Server、SQL Server、CAL、System Center など）に5%の上乗せが適用されると、Microsoft の2026年8月の Partner Center 告知を紹介する解説記事が伝えています（既存契約は2026年10月1日以降の更新時から。年払いと月単位の契約は対象外とされています）。Microsoft の価格設計は、Arc に接続して SA 特典や従量課金を使う方が有利に見えるよう組まれていますが、これは外部から見た傾向であり、Microsoft がそう明言しているわけではありません。

5. セキュリティ：NTLM 縮退と PQC

5-1. NTLM

【Microsoft発表】NTLMv1 は Windows Server 2025 で削除されました。Microsoft は2026年10月の更新で、Credential Guard が無効で BlockNtlmv1SSO が未設定のデバイスについて、NTLMv1 由来の SSO 資格情報の既定動作を Audit から Enforce に切り替える計画を示しています（日程は暫定で、変更の可能性があるとされています。実際の適用は KB で確認してください）。さらに Microsoft は段階計画として、次期メジャーリリースで NTLM を既定で無効にする方針を示しています。完全削除ではなく、ポリシーで再有効化できる前提で、変更の可能性があると断られています。古い複合機、NAS、業務パッケージなど NTLM に依存する資産の棚卸しは、次期 LTSC を待たずに始められる作業です。

5-2. PQC（耐量子暗号）：段階的に対応が進んでいる

【Microsoft発表】2025年11月の更新で、ML-KEM と ML-DSA が CNG の API として一般提供されました。2026年5月の更新（KB5087539）では、WS2025 の AD CS が ML-DSA 証明書の発行に対応しています。ただし既存の CA をその場で ML-DSA に移行することはできず、新規の ML-DSA CA を構築する必要があります。CA 階層、証明書テンプレート、クライアント互換性を含めた PKI の再設計が前提になります。

TLS のハイブリッド鍵交換については、Microsoft の Tech Community の FAQ が、Windows Server 2025 では2026年7月14日の更新（KB5099536）を使うよう案内しています。一方で Microsoft Learn の文書では、ML-KEM 系のグループは Schannel がサポートするものの既定では有効でない扱いとされています。有効化の状態は環境や構成に依存するため、導入時は FAQ と Learn の最新版で確認してください。

6. 主要機能の行方：Active Directory、WSUS、IIS、コンテナ

OS 全体の見通しに加えて、利用者の多い4つの機能が今後どうなるかを整理します。次期版の Insider ビルド 29641 の告知には、AD・IIS・コンテナ・WSUS に関する変更も、非推奨項目の記載も含まれていません（NTLM の既定無効化と WDS の非推奨は、別の告知によるものです）。そのため、次期 LTSC での扱いは現時点では読み取れず、以下は現行版までの公式情報と筆者の仮定を分けて書いています。

機能	公式に確認できる現状	特に注意する点	筆者の見立て（仮定）
Active Directory	WS2025 で機能レベル10、32k ページ（任意）、LDAP の署名・暗号化の既定必須化（新規展開）、dMSA を追加。廃止の発表は確認できず	NTLM は次期メジャーで既定無効の方針。Kerberos の RC4 縮退は進行中（外部解説）。機能レベル10は WS2019／2022 に後付けされない	2036年も多くの組織で残る可能性が高い。変わるのは「古い互換性」の切り落とし
WSUS	2024年9月に非推奨化を発表。新機能の開発は止まるが、現行機能と更新の配信は継続。WS2025 にも含まれる	削除日は未公表。代替は Intune、Azure Update Manager、Windows Autopatch。Configuration Manager には影響しない	次期 LTSC にも残るが、機能は凍結される可能性（確度は低め）
IIS	IIS 自体の廃止の発表は確認できず。WS2025 で IIS 6 管理コンソールと SMTP サーバーを削除。TLS 1.0／1.1 は既定無効	VBScript は将来オンデマンド機能になった後に削除予定。クラシック ASP への影響は公式回答なし	ロールとして継続しつつ、レガシー部分が切り落とされる。新規の Web は IIS 以外へ
コンテナ	AKS の Windows ノードは LTSC の WS2025／2022 のみ（プロセス分離）。Annual Channel の AKS サポートは2026年5月に終了	AKS 上の WS2022 は2028年6月30日で終了。OS の延長サポート（2031年10月）より先に期限が来る	既存の .NET Framework 系アプリの延命用途が中心。新規は Linux コンテナが主流

出典：Microsoft Learn（Windows Server 2025 の新機能、削除・開発終了の機能、AKS の Windows ベストプラクティス）、Windows IT Pro Blog（WSUS 非推奨）、Insider ビルド 29641 の告知。見立ての列は筆者の仮定

6-1. Active Directory：残るが、古い互換性は切り落とされる

【Microsoft発表】Windows Server 2025 の AD DS には、新しい機能レベル（DomainLevel／ForestLevel 10）と、任意機能の 32k データベースページサイズが入りました。32k ページは Windows 2000 以来の 8k に代わるもので、複数値属性が持てる値の数が約1,200から約3,200に増えます。新規に構築する DC は 32k ページで導入できますが、アップグレードした DC は従来の形式（8k）のままです。32k への移行はフォレスト全体で行う必要があり、すべての DC が対応していなければなりません。Microsoft は、この機能レベルを Windows Server 2019／2022 に後付けする予定はないと明記しています。AD の新機能の一部は、WS2025 以降の DC を揃えないと使えないということです。AD DS は64を超えるコアにもスケールできるようになりました（NUMA 対応）。

【Microsoft発表】セキュリティ面では、新規 AD 展開で LDAP の署名と暗号化（sealing）が SASL bind 後に既定で必須になり、機密属性の操作は暗号化された接続でのみ許可されます。LDAP over TLS 1.3 にも対応しました。コンピューターアカウントの既定パスワードの設定は DC が拒否し、旧来の SAM RPC パスワード変更メソッドはリモートから既定でブロックされます。Kerberos では KDC が RC4 の TGT を発行しなくなり、PKINIT は暗号アルゴリズムを固定しない構成になりました。サービスアカウントについては、既存アカウントから移行しやすい委任管理サービスアカウント（dMSA）が追加されています。

【外部データ】Kerberos の RC4 は、CVE-2026-20833 に関連して段階的に縮退していると解説されています。専門ベンダーの解説では、2026年1月13日の更新で監査（KDCSVC イベント 201〜209）を始め、4月に既定を AES のみ（DefaultDomainSupportedEncTypes が 0x18 相当）に切り替え、7月に監査モードを廃止して強制する、という3段階です。この解説は影響を受ける Windows Server のバージョンを示していないため、対象と日程は Microsoft の KB と CVE の公式情報で確認してください。解説どおりなら7月の強制段階はすでに過ぎており、RC4 に依存したサービスアカウントや古い機器は、障害の形で表面化しうる時期に入っています。

【Microsoft発表】次期版の Insider ビルド 29641 の告知は、既知の問題として、TLS のハイブリッド鍵交換の競合状態により LSASS がクラッシュしうること、回避策としてハイブリッドグループを無効にする方法を挙げています。プレビュー版の話ですが、DC を含む認証基盤で PQC 関連の機能を有効にする際は、段階的な検証が必要という示唆になります。

【筆者の仮定】Microsoft が AD DS の廃止を発表したことは、今回の調査では確認できていません。AD DS は WS2025 の延長サポート（2034年11月）までロールとして提供され、DC の世代交代は WS2019（2029年1月）、WS2022（2031年10月）の終了日に沿って進むと考えます。Entra ID と組み合わせたハイブリッド ID が標準になる一方、Kerberos、GPO、LDAP に依存する業務アプリ、ファイルサーバー、機器が残る限り、オンプレの AD は2036年にも多くの組織で残る可能性が高いと見ています。変わるのは AD の存在そのものではなく、NTLM、RC4、弱い LDAP 設定といった古い互換性が、NTLM の既定無効化（5章）のような形で順に切り落とされていく点です。

6-2. WSUS：非推奨だが、すぐには消えない

【Microsoft発表】Microsoft は2024年9月に WSUS の非推奨化を発表しました。新機能への投資と新規の機能要望の受付は止めるが、現行機能は維持し、WSUS チャネル経由の更新の公開と、すでにそのチャネルで公開されたコンテンツのサポートは続ける、という内容です。WSUS ロールは Windows Server 2025 にも含まれ、Microsoft Configuration Manager のサポートには影響しないと説明されています。代替として、Intune、サーバー向けの Azure Update Manager、クライアント向けの Windows Autopatch が案内されています。

非推奨は削除ではありません。削除日は公表されておらず、Microsoft Learn の Q&A では回答者（MVP）が、WS2025 のライフサイクルから少なくとも2034年までは使えるはずだと推論していますが、これは Microsoft の約束ではなく【外部データ】の推論です。同じ構図は、2026年9月に告知された WDS の非推奨（3章）とも共通します。

【筆者の仮定】次期 LTSC にも WSUS ロールは残る可能性が高い一方、機能追加は期待できず、削除は次の次以降の LTSC で告知される可能性があります（確度は低めです）。実務では、オンプレの更新配布は、Azure Update Manager（非 Azure のサーバーでは Arc 接続が前提）への移行、Configuration Manager の継続、WSUS の現状維持のいずれかになります。閉域環境やソブリン要件の強い環境で Azure Update Manager が使えるかは、構成ごとに公式文書で確認が必要です。

6-3. IIS：ロールは続くが、周辺のレガシーが整理される

【Microsoft発表】IIS 自体の廃止や非推奨を示す公式発表は、今回の調査では確認できませんでした。一方、Windows Server 2025 向けの「削除・開発終了の機能」の一覧（プレビュー期の版）には、IIS 周辺の整理が並んでいます。IIS 6 管理コンソールは削除され、SMTP サーバーも削除されて OS 内に代替はありません。TLS 1.0／1.1 は既定で無効、WMIC は新規インストールで既定無効、VBScript は将来のリリースでオンデマンド機能（FOD）になった後に OS から削除される予定とされています。

クラシック ASP には注意が必要です。VBScript の削除計画が IIS の ASP に及ぶかどうかは、Microsoft Learn の Q&A スレッドで回答者の見解が割れており、Microsoft からの公式な回答は出ていません。WS2025 のプレビューで ASP が動作したという報告と、VBScript の FOD を無効にした環境で動作しなかったという報告が併存しています。【外部データ】これはコミュニティの情報で、Microsoft の公式見解ではありません。クラシック ASP を使う資産では、VBScript の FOD の有無をテスト項目に入れ、移行計画を持っておく方が安全です。SMTP サーバー機能に依存するアプリも、WS2025 では代替の確保が必要です。

【筆者の仮定】IIS は OS のロールとして各バージョンのサポート期間に沿って提供され続け、.NET Framework 系の既存アプリのホストとして残ると考えます。新規の Web アプリは ASP.NET Core や Linux コンテナに流れていくでしょう。IIS 周りで確実に進むのは、プロトコルと暗号の既定値の厳格化と、古い互換コンポーネントの切り落としです。

6-4. コンテナ：LTSC に一本化され、AKS の期限が先に来る

【Microsoft発表】AKS は Windows ノードのホスト OS として、LTSC の Windows Server 2025 と 2022 をサポートし、分離はプロセス分離のみです。Windows Server 2025 が既定になるのは Kubernetes 1.36 以降で、それ以前は 2022 が既定です。Windows ノードプールには制約もあり、最初のシステムノードプールは Linux である必要があること、特権コンテナーは使えず HostProcess コンテナーで代替すること、Windows の自動更新はなくノードイメージのアップグレードで対応することなどが挙げられています。

AKS の Windows ノード	期限・状況	備考
Windows Server 2025（LTSC）	サポート中。Kubernetes 1.36 以降で既定	Microsoft は Windows ノードプールに WS2025 を推奨
Windows Server 2022（LTSC）	2028年6月30日にノードプールのサポート終了（Kubernetes 1.37 以降は非対応）。ノードイメージは2029年6月30日に削除	OS の延長サポートは2031年10月14日まで。AKS 上の期限の方が先に来る
Windows Server 2019	Kubernetes 1.33 以降ではノードプールを作れない。ノードイメージは2027年4月1日に削除	削除後はスケール操作が失敗する
Annual Channel（プレビュー）	2026年5月15日に新規ノードプールと更新を終了。イメージは2027年5月15日に削除	LTSC への移行を推奨。HostProcess などの特権系コンテナーは追加テストが必要

出典：Microsoft Learn「Windows containers on AKS のベストプラクティス」「Windows と Linux のコンテナー」。AKS 以外（Azure Local など）の期限は別途確認が必要

【Microsoft発表】Windows Server 2025 の機能としては、コンテナーイメージとそのデータを、変更なしでホスト間や環境間で移せる「コンテナーのポータビリティ」が挙げられています。表のとおり、AKS は LTSC に一本化し、古いバージョンと Annual Channel を整理する方向です。AKS 上の期限が OS の延長サポートより早い点は、Windows コンテナーの更新計画で見落としやすいところです。

【筆者の仮定】Windows コンテナーは、.NET Framework 系の既存アプリを OS から切り離して延命する用途が中心になり、新規開発の主流は Linux コンテナーだと考えます。AKS で Windows Server 2025 が既定になる時期が Kubernetes のバージョンに連動していることから、次期 LTSC が出た後も、AKS で段階的に新しい LTSC が既定になるパターンが続くと見ています（時期は未定です）。

7. 市場環境：Microsoft の収益構造と VMware 移行

【Microsoft発表】FY26 の決算説明で、Satya Nadella CEO は Azure の年間売上が1,000億ドルを超え、前年比41%増だと述べました（41%が報告ベースか為替一定ベースかは、確認した範囲では明示されていません）。Q4 単独では、Azure and other cloud services の売上が43%増でした。一方、オンプレミスのサーバー事業について Amy Hood CFO は、Q4 の売上は前年並みで、為替一定ベースでは1%減と説明しています。通期のオンプレ向け数値は今回確認できていないため記載しません。なお財務諸表上は、Azure 単独の売上明細ではなく「Server products and cloud services」などの区分で開示されます。経営陣が補足する Azure の売上・成長率と、報告セグメントの数字は基準が違うため、混ぜて読まないでください。【筆者の仮定】このため、Microsoft はオンプレ OS の売上そのものより、Arc や Azure の利用につながる機能と価格の設計を優先しやすいと考えます。

【外部データ】VMware（Broadcom 買収後）からの移行は、Windows Server にとって追い風になりうる材料です。Nutanix の CEO は2026年8月の FY26 決算説明の質疑で、顧客数を約3万1,000〜3万2,000社と述べ、FY26 の新規顧客は約3,000社（3年連続の水準）と報じられています。VMware からの移行は今後5年も続くとの見方も示されました（SDxCentral）。ただし調査の読み方には注意が必要です。CloudBolt の調査（2026年1月実施、北米の従業員1,000人以上の企業で VMware 関連の意思決定権を持つ幹部302人）では、86%が VMware の利用を積極的に縮小中で、54%は VMware を維持しつつ依存を減らす段階的な移行でした。移行先の上位は、パブリッククラウド IaaS（72%）、Hyper-V／Azure Stack（38%）、SaaS（34%）と紹介されています（分母の定義は原典で確認が必要です）。いずれもベンダー実施の調査や報道で、母数も限られます。全面移行より部分移行が主流という見方が妥当で、Windows 中心の環境では Datacenter エディションの仮想化権利を使った Hyper-V が受け皿になりやすい、というのが筆者の推論です。

サーバー OS 全体の市場シェアについては、IDC や Gartner の最新の一次データを今回確認できていないため、数値は掲載しません。

8. 日本市場とソブリン要件

【外部データ】MM総研は2025年10〜12月に、国内企業の情報システム部門の担当者を対象に Web アンケートを実施しています（スクリーニング調査の有効回答は45,172件、本調査は Windows Server 2016 や仮想化環境の利用者を対象とした967件）。協賛記事の見出しではこの調査を引用して「約25万台が稼働」と紹介されていますが、台数の推計方法は原典で確認できていません。移行に動けない理由の最多は「社内の人材不足」（約45%）、次いで「予算の確保、経営層への上申理由、理解」（32.2%）と紹介されています。また、クラウドへの移行を選ぶ回答は約5%で、Windows Server 2012 の調査時より低いとされています（分母の定義は原典で確認が必要です）。これらはいずれもベンダー協賛の解説記事経由の数字です。解説では、既存のオンプレミス環境を前提に、OS と仮想化基盤の見直しを優先する企業が多いという分析も紹介されています（ベンダー側の解釈です）。

【Microsoft発表】ソブリン要件への対応では、Azure Local の存在感が増しています。2026年2月には切断運用（disconnected operations）を一般提供し、2026年4月27日には、Azure Local が単一のソブリン環境で「数百から数千台」のサーバー規模まで拡張できると発表しました。DCD の報道では、2025年11月の拡張以前は最大16台とされていたとのことで、規模は大きく変わっています。ただし数千台という上限の具体的な構成は公式ブログからは読み取れず、実際の設計では構成上限や検証済み構成の公式文書で確認が必要です。Microsoft は検証済みのパートナーとして、DataON、Dell Technologies、Everpure、Hitachi Vantara、HPE、Lenovo、NetApp などを挙げていると報じられています。【筆者の仮定】ライセンスの再販や OS の導入作業より、運用設計や移行支援に SIer の付加価値が移っていくと考えます。

9. 今後10年（2026〜2036年）の見通し

ここからは、公式発表と筆者の仮定を分けて整理します。出発点になる事実は3つです。Windows Server 2025 は2034年11月までサポートされること、次期 LTSC のプレビューが続いていること、そして運用・課金の窓口が Arc に寄っていることです。

時期	予想される出来事	根拠の強さ
〜2028年	2016 の延長サポート終了（2027年1月）と ESU。次期 LTSC の一般提供（2027年後半〜2028年前半が有力）。NTLM が次期版で既定無効に	2016 の日程と NTLM 方針は【Microsoft発表】。次期版の時期はプレビュー期限と3年周期からの推論【筆者の仮定】
〜2031年	2019（2029年1月）・2022（2031年10月）の延長サポート終了。両者に ESU が提供される可能性。次の LTSC（2030年前後）。新規基盤では Arc 接続が標準的な選択肢に	終了日は【Microsoft発表】。ESU の提供、LTSC の時期、Arc の普及度は【筆者の仮定】
〜2036年	WS2025 の延長サポート終了（2034年11月）。LTSC はさらに1世代（2033年前後）。Windows Server は主に既存資産（AD、ファイル、VDI、.NET Framework 系業務アプリ）の基盤として残る。運用の自動化が進む	2034年11月は【Microsoft発表】。それ以外は【筆者の仮定】で確度は低め

以下は【筆者の仮定】によるシナリオと確率です。独立した根拠のある数字ではなく、現時点の判断を可視化するためのものとして読んでください。

シナリオ	確率（仮定）	概要	見分ける兆候
基本：ハイブリッド管理への漸進的な移行	60%	LTSC は続き、運用価値の重心が Arc 側へ。新規ワークロードは Linux や PaaS が中心になり、Windows Server は既存資産の更新需要で安定	次期 LTSC が予定どおり出る。ESU の購入経路が Arc 中心に収れんする
楽観：再評価	20%	VMware からの移行、ソブリン需要、Hotpatch の無償化で、Hyper-V／Azure Local と Datacenter の需要が伸びる	Azure Local の国内事例の増加。VMware 乗り換えの事例で Hyper-V が目立つ
悲観：縮退とロックインの強化	20%	SA 必須化や値上げ、主要機能の Arc／Azure 限定化が進み、顧客が Linux や他の基盤、SaaS へ流れる。または規制によりクラウド接続前提の機能が使えない	Arc 未接続ではセキュリティ機能が使えなくなる。LTSC の周期が延びる。日欧でクラウド依存への規制が強まる

今後の追跡に向く指標は、次期 LTSC の公式発表（Ignite などの場）、Insider プレビュー期限の更新、2019／2022 の ESU の発表時期と提供経路、NTLM 既定無効化のスケジュール、Azure Local の構成上限の更新、Microsoft の四半期決算でのコメントです。機能面では、WSUS・WDS といった非推奨ロールの削除告知、AD の機能レベルや認証まわりの既定値の変更、AKS の Windows ノードの期限更新も、見通しを修正する材料になります。

10. 実務への示唆

2016 の扱いを早めに決める。ESU で時間を稼ぐか、WS2025 などへ移すか。ESU は価格が未公表で、適用条件も経路ごとに異なるため、見積もりの前提を公式 FAQ で固めてください。
Arc 接続の方針を先に決める。Hotpatch、管理特典、ESU の窓口が Arc に寄っているため、ネットワーク要件とソブリン要件の折り合いをアーキテクチャ段階で整理します。
新規構築は、原則 WS2025 を第一候補にする。ただし ISV の認証、ハードウェア互換性、バックアップ・監視製品、アプリのサポート条件によっては、延長サポート期間中の WS2022 も選択肢になります。
NTLM 依存の棚卸しを始める。監査機能で利用状況を把握し、Kerberos への移行を計画します。
PKI は新規設計として扱う。ML-DSA CA は既存 CA からのインプレース移行ができないため、アルゴリズム移行、CA 階層、テンプレート、クライアント互換性を含めて設計します。
AD は DC の世代と古い互換性を洗い出す。機能レベル10や 32k ページを使うかを判断し、LDAP の署名設定、RC4 に依存するサービスアカウント、NTLM 依存の機器を棚卸しします。
更新配布の将来像を決める。WSUS を現状維持するか、Configuration Manager を使い続けるか、Azure Update Manager（Arc 接続）へ移すか。閉域環境での可否は公式文書で確認します。
IIS 上の資産は、ASP・VBScript・SMTP への依存を確認する。クラシック ASP は VBScript の FOD を無効にした状態でのテストを計画に入れます。
Windows コンテナーは、AKS の期限から逆算する。WS2022 ノードは2028年6月30日で終了するため、OS の延長サポートではなく AKS 側の期限を基準に更新計画を立てます。

11. まとめ

Windows Server は少なくとも2034年11月までは現行製品としてサポートされ、次期 LTSC の開発も続いています。2036年にも製品系列が残る可能性は高いと見ていますが、将来版の名称、提供時期、ライフサイクルは未発表です。Microsoft が Windows Server そのものを Azure Arc に置き換えるのではなく、非 Azure 環境向けの Hotpatch、更新管理、従量課金、管理特典、ESU といった運用・商用面の価値を Arc 中心に移している、というのが現時点の実像です。

主要機能については、AD は NTLM や RC4 といった古い互換性を切り落としながら残り、WSUS は非推奨でも当面は動き続け、IIS はロールとして続きつつ周辺のレガシーが整理され、Windows コンテナーは LTSC に一本化されて AKS の期限が OS より先に来る、というのが現時点で確認できる姿です。次期版でのこれらの扱いは未発表です。

導入や更改に関わる立場では、OS の更新という単位ではなく、Arc の接続方針、Hyper-V／Azure Local の選択、VMware からの移行、NTLM 依存の解消、PKI と PQC、ソブリン要件までを含めた基盤の再設計として検討する方が、10年のスパンでは筋が通ります。

主な参考資料

登録: 投稿 (Atom)