MENU

Windows 10／11の内部バージョン「10.0」の意味とは？メジャー・マイナー・ビルド番号を徹底解説

Windows

「Windows 10もWindows 11も、内部バージョンは10.0のまま」と聞くと、セマンティックバージョニングになじんだエンジニアほどモヤっとしがちです。本記事では、Windowsのメジャー／マイナー／ビルド番号の意味と歴史、そして開発・運用の現場でどう扱うのが正解かを、具体例と表を交えて整理します。

目次

Windowsの「内部バージョン番号」とは

まず押さえておきたいのは、Windowsには次のように複数の「バージョン表記」が存在することです。

  • マーケティング名：例）Windows 10、Windows 11
  • 機能アップデート名：例）22H2、23H2、24H2 など
  • 内部バージョン（NTバージョン）：例）10.0
  • OSビルド番号：例）19045、22000、22631、26100 など

「winver」や「設定 → システム → バージョン情報」で表示される

バージョン 23H2（OS ビルド 22631.6199）

のような表記は、内部的には次のような構造になっています。

項目例意味
メジャーバージョン10NTカーネルの「互換性ファミリー」を示す番号（現在、Windows 10／11ともに10）
マイナーバージョン0同じメジャー内のバリエーション。近年のクライアントWindowsでは0固定
ビルド番号22631世代・ブランチを示す実質的な「世代番号」。21H2は22000台、22H2は22621台など
リビジョン6199累積更新プログラムごとの増分。毎月の更新で増えていく

つまり、Windows 11 23H2は内部的には「10.0.22631.xxxx」という一連のバージョンで表されており、この「10.0」が本記事で取り上げる内部メジャー／マイナー番号です。

セマンティックバージョニングとWindowsの違い

多くのライブラリやWebアプリが採用しているセマンティックバージョニング（SemVer）では、一般に次のようなルールを取ります。

  • MAJOR：後方互換性を壊す変更が入ったときに+1
  • MINOR：後方互換性を保ったまま機能追加したときに+1
  • PATCH：バグ修正など、小さな変更のときに+1

一方、Windowsの内部バージョン番号は、現在はこのルールには従っていません。Microsoft自身も、Windowsのバージョン判定については「Version Helper APIを使ってください」「バージョン番号そのものに依存しないでください」と繰り返し強調しています。

項目セマンティックバージョニングWindows（現状）
メジャー破壊的変更の指標主に互換性ファミリーの識別子（NT 6系 / NT 10系 など）
マイナー後方互換な機能追加かつてはVista→7→8→8.1で利用されたが、現在は0固定
パッチ／ビルドバグ修正・小変更実質的な「新しさ」や世代差を表す主役（22000台、22621台、26100台…）

歴史的には「NTバージョン番号はOSコアの変更度合いも反映する」とされていましたが、Vista以降はアプリケーション互換性のためにメジャー番号を据え置くという割り切りがなされ、その流れの延長線上に「10.0のままのWindows 11」があります。

歴史で見るメジャー／マイナーの変遷

まずは、Windows NT系のクライアントOSで、マーケティング名称と内部バージョンの対応をざっと眺めてみましょう。

マーケティング名内部バージョン（NT）代表的なOSビルドメモ
Windows 20005.02195NT 5系の最初
Windows XP5.12600XPは「5.1」だがUI上は「5」はほぼ出てこない
Windows Vista6.06000NT 6系のスタート
Windows 76.17600／7601名前は「7」だが内部は「6.1」
Windows 86.29200モダンUI導入
Windows 8.16.39600「8の改良版」扱いでメジャーは据え置き
Windows 10（初期）10.0102406.xから一気に「10.0」へジャンプ
Windows 10 22H210.019045.xWindows 10の最終バージョン
Windows 11 21H210.022000.xWindows 11初期リリース
Windows 11 22H210.022621.xUI・機能を拡充した大規模アップデート
Windows 11 23H210.022631.x22H2に有効化パッケージで機能を足した版
Windows 11 24H210.026100.x新しいビルド系列（26100）で提供されるリリース

ここから読み取れるポイントは次の通りです。

  • Vista〜8.1までは「6.x」ファミリーとして一括りにされている
  • マーケティング上は「7」「8」と名前を変えても、内部メジャーは6のままだった
  • Windows 10のタイミングで初めて「10.0」へメジャージャンプし、それ以降は10.0を維持したままビルド番号だけが進んでいる

つまり、現在のWindowsはざっくりと「NT 6系（Vista〜8.1）」と「NT 10系（Windows 10／11）」という2つの大きな互換性ファミリーに分かれていると見ると理解しやすくなります。

Windows 8から10への「飛び番号」はなぜ起きたのか

ブランドの統一と「Windows 10」という名前

Windows 8.1の次が「9」ではなく「10」になった理由は公式にはさまざま語られていますが、大きくは次のような事情がありました。

  • PC／タブレット／2-in-1／一部IoTなどを「One Windows」として束ねるブランド戦略
  • 「古い8の改良版」ではなく、新しい出発点としてのインパクト（Windows 7との違いを強調したい）

この「Windows 10」というブランド名に合わせる形で、「内部バージョンも10.0に揃えられた」と考えると筋が通ります。

プレビュー段階では「6.4」だったという事実

実は、Windows 10の初期プレビュービルドは内部バージョン「6.4」を名乗っていた時期があります。その後のビルドで「10.0」に変更されたことが複数の報道や開発者の証言から知られています。

なぜ途中で変えたのかというと、背景にはアプリケーションのバージョン判定ロジックとの相性問題がありました。

  • 実際のコードとしては、次のような判定が多く存在していたと考えられています。
    • if (major == 5 && minor == 1) {/* XP */}
    • else if (major == 6 && minor == 0) {/* Vista */}
    • else if (major == 6 && minor == 1) {/* 7 */}
    • …といった「既知のバージョンだけ許可」パターン
  • そこに突然「6.4」が登場すると、「知らないバージョンだから未対応」と判断され、インストーラやアプリが起動すらしないケースが増えかねない

Vistaのときにも「5.xから6.0になったことでアプリが動かなくなった」という互換性問題が多数報告されており、Microsoftとしては同じ失敗を繰り返したくなかった、という事情も想像できます。

結果として、

  • ブランド名：Windows 10
  • 内部バージョン：10.0

という形で揃えることで、「6.xファミリーから一段上の新しい互換性ファミリー」として整理し直した、と見るのが自然です。

「大刷新だから10.0」ではない

ここで重要なのは、10.0へのジャンプが「内部実装の劇的な大刷新」をそのまま意味しているわけではないという点です。

もちろんWindows 10でカーネルやドライバモデルに大きな変更は入っていますが、あくまでNT 6系からの継続的な進化であり、「完全に別物のOSになった」というよりは、互換性ファミリーのラインを整理し直した、という性格が強いと考えられます。

Windows 11なのに内部が10.0のままな理由

Windows 11の内部バージョンは「10.0 + 新しいビルド」

Windows 11の初期リリース（21H2）は、OSビルド番号22000番台からスタートしましたが、内部バージョンはやはり10.0です。

その後のリリースも含めて整理すると、以下のようになります。

Windowsマーケティングバージョン内部バージョン主なOSビルド
Windows 1022H210.019045.x
Windows 1121H210.022000.x
Windows 1122H210.022621.x
Windows 1123H210.022631.x
Windows 1124H210.026100.x

どの世代もメジャー／マイナーは10.0のままで、「世代差」はほぼビルド番号だけで表現されています。

理由1：アプリ・ドライバの「10.0以上ならOK」判定が大量に存在する

Windows 10リリース以降、多くのアプリケーションやドライバ、インストーラが「10.0」以降を前提に動くようになりました。

  • 「Windows 10以降のみサポート」という条件を、major == 10 && minor >= 0 や version >= 10.0 で判定しているコード
  • インストーラが「10.0未満ならインストール拒否」としているケース
  • ライセンスや機能制限をOSバージョンで分岐しているミドルウェア

ここで内部バージョンを11.0や10.1に変えてしまうと、次のような問題が起きかねません。

  • 「未対応の新OS」と誤判定され、インストールできない・起動できない
  • 「Windows 10専用機能」と誤判定され、思わぬ制限がかかる

Microsoft自身も、Windows 8.1以降では「アプリが新しいOSに対応していない場合は、意図的に古いバージョン番号（6.2＝Windows 8）を返す」など、互換性のためにバージョン偽装を行っていることを公式に説明しています。

こうした事情から、内部メジャー番号は10.0のまま維持し、世代差はビルド番号や機能検出で表現する、という方針が取られていると考えられます。

理由2：Windows 10と11は「同じNT 10ファミリー」として設計されている

Windows 11はUIやハードウェア要件（TPMやCPU世代など）が大きく変わりましたが、コア部分はWindows 10からの継続的な進化です。ドライバモデルやカーネルの大枠は共通で、Windows 10用ドライバがそのままWindows 11でも動くケースが多いのは、このためです。

その意味で、MicrosoftはWindows 10と11を「同じNT 10ファミリーの別ビルド」として扱っている、とも言えます。

理由3：ユーザー向けには「21H2／22H2／23H2」のほうが重要になった

Microsoftの公式ドキュメントやサポート情報でも、最近は「バージョン 23H2（OS ビルド 22631）」のような表記を使うことが増えています。開発者・管理者にとって重要なのは、「現在のOSがどの機能アップデート系列に属しているか」であり、「メジャー／マイナー（10.0かどうか）」ではなくなっているのです。

メジャー／マイナー番号は今や「互換性フラグ」

以上を踏まえると、現在のWindowsにおけるメジャー／マイナー番号は、もはや「変更規模」ではなく「互換性ファミリー」を示すフラグとして扱われていると理解できます。

  • 5.x：Windows 2000／XP 世代
  • 6.x：Vista／7／8／8.1 世代（NT 6ファミリー）
  • 10.0：Windows 10／11 世代（NT 10ファミリー）

一方で、「どこまで新しい機能が入っているか」「どのリリース世代か」はビルド番号とH2表記（21H2/22H2/23H2…）が担っています。

開発者視点では、

  • major/minorは「大きな家族名」
  • buildは「家族の中での何番目の子か」

くらいの感覚で扱うのが実務的です。

開発者向け：正しいバージョン判定のベストプラクティス

ここからは実務寄りの話です。Windows向けアプリやツールを作る開発者にとって、バージョン判定は避けて通れませんが、やり方を間違えると将来のWindowsで動かなくなる危険があります。

Version Helper関数を使う（Win32／C++）

Microsoftは、OSバージョンの判定にはVersion Helper APIを使うことを推奨しています。Win32アプリケーションの場合、VersionHelpers.h に定義されているインライン関数を使うと、読みやすいコードになります。


#include <windows.h>
#include <VersionHelpers.h>

bool IsSupportedWindows()
{
    // Windows 10 以降（= 内部 10.0 以上）が必須
    if (!IsWindows10OrGreater()) {
        MessageBoxW(nullptr,
                    L"このアプリは Windows 10 以降でのみ動作します。",
                    L"サポート対象外のOS",
                    MB_OK | MB_ICONERROR);
        return false;
    }
    return true;
}

このように「～以上かどうか」を判定するのが基本パターンです。Windows 11だからといって「11.0」を見るのではなく、「Windows 10以降であればOK」といった考え方で設計すると、メジャー番号が仮に変わっても破綻しにくくなります。

アプリ マニフェストでサポートOSを宣言する

Windows 8.1以降、GetVersion や Version Helper API はアプリケーションのマニフェストを見て、あえて古いバージョンを返すことがあります。

そのため、正しくバージョン判定を行うには、アプリケーションのマニフェストに「このアプリはWindows 10／11を正式にサポートしている」という情報を埋め込んでおく必要があります。

概念的には、次のようなイメージです（実際のGUIDなどは公式ドキュメントを参照してください）。


<assembly ...>
  ...
  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
    <application>
      <supportedOS Id="{GUID: Windows 10}" />
      <supportedOS Id="{GUID: Windows 11}" />
    </application>
  </compatibility>
</assembly>

これを正しく設定しておくと、Version Helper関数が実際のOSバージョンに基づいた値を返してくれるようになります。

機能検出（feature detection）を優先する

とはいえ、OSバージョンだけを見ても、「その機能が本当に使えるか」までは分かりません。特定のAPIや挙動は、同じ22H2でもビルドによって有無が異なることもあります。

そのため、可能な限り次のような方針が推奨されます。

  • OSバージョンではなく、利用したいAPIや機能そのものが存在するかをチェックする
  • Win32なら GetProcAddress や LoadLibrary で関数の存在を確認してから使う
  • .NETなら OperatingSystem.IsWindowsVersionAtLeast と個別APIの存在チェックを組み合わせる

擬似コードで書くと、次のようなイメージです。


if (IsWindows10OrGreater() && HasRequiredApi()) {
    EnableNewFeature();
} else {
    FallbackImplementation();
}

このように「バージョン」と「機能検出」の両輪で判定することで、将来ビルドやメジャー番号が変わっても致命的な問題を起こしにくくなります。

ビルド番号の使い方：どうしても必要なときだけ

Windows 10／11では、同じH2バージョン内でも、ビルド番号によって細かい挙動が変わることがあります。そのため、どうしても必要な場合に限り、ビルド番号に閾値を設けて判定することもあります。

OS目安となるビルドコメント
Windows 10 22H219045.xWindows 10最終世代。ESUで延命されるビルド群
Windows 11 21H222000.x初代Windows 11。教育／企業向けのみ一部サポート継続
Windows 11 22H222621.x22H2の基盤ビルド
Windows 11 23H222631.x22H2に有効化パッケージで機能追加されたビルド群
Windows 11 24H226100.x新ビルド系列（26100）。25H2もこの系統を引き継ぐ構成

.NETの場合は、Environment.OSVersion.Version から Build を参照するのが手軽です。ただし、将来の変更に備えて「下限だけ見る」（例：build >= 22000 なら11世代とみなす）といった使い方に留めるのが無難です。

やってはいけないバージョン判定アンチパターン

逆に、避けるべきパターンをいくつか挙げておきます。

  • GetVersionEx に依存する
    • 公式に非推奨（deprecated）扱いであり、マニフェスト設定次第で実際のOSより低いバージョンを返すことがあります。
  • OS名の文字列をパースする
    • 「Windows 11」といった文字列に頼ると、地域言語や将来の名称変更に弱くなります。
  • 特定バージョンの等号比較に頼る
    • if (major == 10 && minor == 0 && build == 22000) のようにぴったり一致を前提にした判定は、少しでもアップデートされると破綻します。
  • 「11.0が来たらこう動く」と決め打ちする
    • 現状メジャー番号は10.0のままですが、将来のメジャーアップ時には互換性レイヤーでバージョン偽装を行う可能性もあり、「11.0」という数字に意味を持たせ過ぎると危険です。

管理者・一般ユーザー向け：自分のWindowsの「世代」を見分ける

開発者でなくても、「このPCはWindows 10の最終版なのか？」「Windows 11 23H2のサポートはいつまで？」といった情報は気になるところです。

バージョン確認の実用的な方法

最も手軽な確認方法は次の2つです。

  1. 「winver」を実行する
    • Win + R → winver と入力 → Enter
    • 「バージョン 23H2（OS ビルド 22631.6199）」のようなダイアログが表示されます。
  2. 「設定 → システム → バージョン情報」を開く
    • Windows 10／11ともに、ここで「エディション」「バージョン（22H2など）」「OS ビルド」が確認できます。

実務的には、「バージョン（21H2/22H2/23H2/24H2）」と「OSビルドの前半（19045 / 22000 / 22621 / 22631 / 26100）」を覚えておくと、サポート情報やトラブルシュート記事と突き合わせやすくなります。

代表的な例で感覚をつかむ

winverの例意味
バージョン 22H2（OS ビルド 19045.6466）Windows 10 22H2。Windows 10最終世代で、ESUによる延長サポート対象ビルド。
バージョン 23H2（OS ビルド 22631.6199）Windows 11 23H2。Home/Proは2025年11月前後でサポート終了、24H2/25H2へのアップグレードが推奨されています。
バージョン 24H2（OS ビルド 26100.4652）Windows 11 24H2。26100系ビルドで提供される最新版のひとつ。

このように、「バージョン」と「OSビルド」が分かれば、自分のPCがどの世代に属していて、サポート期間がどの程度残っているかを把握しやすくなります。

今後「10.1」や「11.0」になる可能性は？

では、将来Windows 11やその後継が「10.1」や「11.0」「12.0」といった内部バージョンになることはあるのでしょうか。

これについてMicrosoftが明確なロードマップを公開しているわけではありませんが、少なくとも近い将来は10.0ファミリーを維持するほうが無難と考えられます。

  • 10.0に依存したアプリ・ドライバが膨大に存在する
  • すでにVersion Helperやマニフェストによる互換性レイヤーが整備されており、「10.0内でビルドを進める」設計に慣れている
  • H2形式の機能アップデート（22H2/23H2/24H2…）＋ビルド番号で十分に世代差を表現できている

仮に将来「11.0」や「12.0」に上げる場合でも、

  • 古いアプリからは従来通り「10.0」と見えるようにバージョン偽装する
  • マニフェストや新しいAPIを使ったアプリだけが「11.0」を認識できる

といった互換レイヤー（shim）をかませる可能性が高いでしょう。そうでなければ、Windows 10登場時以上の互換性問題が発生してしまうからです。

したがって、開発者としては「いつかメジャー番号が変わるかどうか」を気にするのではなく、

  • OS名やメジャー／マイナー番号ではなく、機能検出とビルド番号でロジックを書く
  • Version Helperやマニフェストといった公式の仕組みを利用する
  • 「10.0がずっと続く前提」でなく、「メジャー番号が変わっても壊れない設計」を心がける

というスタンスを取るのが、もっとも安全で現実的です。

まとめ：Windowsのバージョン番号をどう理解し、どう付き合うか

最後に、本記事のポイントを整理します。

  • 現在のWindowsでは、メジャー／マイナー番号は変更規模の指標ではなく「互換性ファミリーの識別子」として扱われている
  • Vista〜8.1までが「NT 6系」、Windows 10／11が「NT 10系」で、Windows 11も内部バージョンは10.0のまま
  • Windows 10で6.xから10.0にジャンプしたのは、大幅刷新というよりブランド統一＋互換性整理の色合いが強い
  • Windows 11への移行でもメジャーを変えなかったのは、「10.0以上ならOK」という前提のアプリ／ドライバが大量に存在するため
  • 実務では、ビルド番号（19045 / 22000 / 22621 / 22631 / 26100…）とH2表記（22H2/23H2/24H2…）が「世代」の指標になる
  • 開発者は：
    • Version Helper関数＋マニフェストでOSバージョンを扱う
    • 可能な限り機能検出で分岐する
    • GetVersionEx 依存やOS名文字列パースといったアンチパターンを避ける
  • 一般ユーザー・管理者は、「winverでバージョンとOSビルドを確認する」習慣をつけると、サポート情報を追いやすくなる

Windowsのバージョン番号は、一見すると「分かりにくい飛び番号」や「11なのに10.0」といった謎に見えますが、互換性とブランド戦略を優先した結果と理解すると全体像が見えてきます。メジャー／マイナーを「互換性フラグ」、ビルド番号を「実際の世代」と捉え直すことで、開発・運用どちらの現場でも、より安全で将来に強い設計・運用がしやすくなるはずです。

Windows
Windows 11 開発者向け 互換性 Windows 10 バージョン番号

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次