C++でstd::numeric_limits::maxがWindows環境でエラーになる原因とNOMINMAXによる解決方法

Linux や macOS では普通に通っていた C++ のコードが、Windows の Visual Studio でだけ「syntax error: identifier ‘max’」と怒られる──その原因の多くは、C++ の文法ミスではなく <Windows.h> が定義するマクロとの衝突です。本記事では、std::numeric_limits<float>::max() で発生するエラーを題材に、根本原因と安全な回避策、既存プロジェクトでの実践的な対処方法まで、丁寧に解説します。

C++ の `std::numeric_limits` と `max()` を整理する

まずは問題の主役である std::numeric_limits と max() について、軽く整理しておきます。ここでいう max() は、std::max()（アルゴリズム関数）ではなく、numeric_limits の静的メンバ関数です。


#include &lt;limits&gt;

int main() {
    float fmax = std::numeric_limits&lt;float&gt;::max();   // float の最大値
    double dmax = std::numeric_limits&lt;double&gt;::max(); // double の最大値

    return 0;
}

std::numeric_limits<T> は型 T に関する情報（最大値、最小値、NaN を持つかなど）をコンパイル時に取得できるテンプレートクラスで、max() はその中の代表的な静的メンバ関数です。Linux / macOS / MinGW など多くの環境では、上記のコードは問題なくコンパイルできます。

ところが、MSVC（Visual Studio）の Windows 環境で、さらに Win32 API を使うために <Windows.h> をインクルードすると、突如としてコンパイルエラーが発生することがあります。

実際に出るエラーと最小再現コード

典型的な再現コードは次のようになります。


#include &lt;Windows.h&gt;
#include &lt;limits&gt;

int main() {
    float maxNum = std::numeric_limits&lt;float&gt;::max();
    return 0;
}

これを MSVC でビルドすると、次のようなエラーが出ることがあります。


error C2061: syntax error: identifier 'max'

日本語環境では「構文エラー: 識別子 ‘max’」のようなメッセージが表示される場合もあります。ぱっと見ると「max という識別子の書き方が間違っている？」ように見えますが、実際には C++ の文法の問題ではありません。

原因：`<Windows.h>` の `max`/`min` マクロと衝突

根本原因は、Windows SDK のヘッダーで定義されているマクロです。<Windows.h> では、昔からよくある C 風マクロとして max / min が定義されています。


// 実際の定義とは異なる場合がありますが、イメージとしてはこんな形
#define max(a, b) ((a) &gt; (b) ? (a) : (b))
#define min(a, b) ((a) &lt; (b) ? (a) : (b))

C/C++ コンパイラは、ソースコードを解釈する前に「プリプロセッサ」によるマクロ展開を行います。max( ... ) というトークン列は、コンパイラが C++ として読む前にプリプロセッサによって置き換えられてしまいます。

その結果、次のコード


float maxNum = std::numeric_limits&lt;float&gt;::max();

は、プリプロセッサの段階で max (...) にマッチする部分を誤って展開しようとしてしまい、不正なコードに変形されます。その「壊れた」コードに対して本体のコンパイラが構文解析を行うため、意味不明な場所で syntax error: identifier 'max' といったエラーが報告されるわけです。

段階	コードの見え方	何が起きているか
ソースコード記述時	`std::numeric_limits<float>::max()`	正しい C++ コードに見える
プリプロセッサ	`max` マクロに一致すると判断	`#define max(a,b)` に基づき置換しようとする
コンパイラ	めちゃくちゃになったコード	構文解析できず `syntax error: identifier 'max'`

このように、「C++ の識別子 max」と「C のマクロ max」が同名であることが、トラブルの直接の原因です。

最も手軽で安全な解決策：`#define NOMINMAX` を宣言する

Windows 環境でこの問題を根本から避ける一番シンプルな方法は、NOMINMAX マクロを定義してから <Windows.h> をインクルードすることです。


#define NOMINMAX        // &lt;-- これを必ず最初に定義
#include &lt;Windows.h&gt;
#include &lt;limits&gt;

int main() {
    float maxNum = std::numeric_limits&lt;float&gt;::max();
    float minNum = std::numeric_limits&lt;float&gt;::min();
    return 0;
}

NOMINMAX が定義されていると、<Windows.h> 内部では max / min マクロを定義しないように分岐されます。その結果、プリプロセッサによるマクロ展開が発生せず、std::numeric_limits<float>::max() は本来の C++ の意味のままコンパイルされます。

プロジェクト全体で確実に適用したい場合は、ソースファイルの先頭に毎回書くのではなく、ビルド設定に /D NOMINMAX を追加するのが現実的です。

Visual Studio での設定例

プロジェクトのプロパティを開く
C/C++ → プリプロセッサ → プリプロセッサ定義 を開く
既存の定義（WIN32 や _DEBUG など）の末尾に NOMINMAX を追加

CMake を使っている場合は、例えば次のように CMakeLists.txt に記述します。


add_compile_definitions(NOMINMAX)

項目	内容
メリット	`max/min` マクロを根本から消せる。C++ 標準ライブラリの利用と衝突しない。
デメリット	古いコードで Windows の `max/min` マクロに依存している場合、そちらがコンパイルエラーになる可能性。
推奨度	新規開発・モダン C++ コードでは最優先で採用すべき。

その他の回避パターンと注意点

何らかの事情（既存コードとの互換性など）で NOMINMAX をすぐに導入できない場合、別の回避策を取ることもできます。ただし、それぞれ一長一短があるため、特徴を理解して使い分けることが大切です。

`#undef max` / `#undef min` でマクロを無効化する

もっともシンプルな回避策は、<Windows.h> をインクルードした後で #undef する方法です。


#include &lt;Windows.h&gt;
#undef max
#undef min
#include &lt;limits&gt;

int main() {
    float maxNum = std::numeric_limits&lt;float&gt;::max();
    return 0;
}

この方法は「この翻訳単位内では Windows の max/min マクロを使わない」と決めてしまえる点では分かりやすいですが、実務ではいくつかの落とし穴があります。

ヘッダーファイルの奥深くで再度 <Windows.h> がインクルードされると、マクロが復活することがある
#undef を書き忘れた翻訳単位だけ問題が再発し、バグが再燃する
チーム開発では「どこで #undef してよいか」のルールを決める必要がある

小さな検証コードや一時的な回避には便利ですが、中〜大規模のプロジェクトでは管理コストが高くなりがちです。

`<Windows.h>` を最後にインクルードする

別のアイデアとして、標準ライブラリや自作ヘッダーをすべてインクルードした「最後」に <Windows.h> を読み込む、というパターンがあります。


#include &lt;limits&gt;
#include &lt;vector&gt;
// ... 他のヘッダー

#include &lt;Windows.h&gt; // 最後に読む

こうすることで、「C++ 標準ライブラリ側のヘッダーが Windows の max/min マクロを見てしまう」ことをある程度避けられます。しかし次のような問題は完全には防げません。

自作ヘッダー内のコードでも std::numeric_limits<T>::max() を使う場合、そこから見える位置に <Windows.h> があると衝突する
どのヘッダーが <Windows.h> をインクルードしているかを把握し続けるのは難しい
プリコンパイル済みヘッダー（pch.h）を使う場合、この順序が崩れやすい

「とりあえずマシになる」程度の回避策であり、根本治療ではありません。

苦肉の策：`(std::numeric_limits<float>::max)()` と書く

最もローレベルな対処として、呼び出したい識別子を括弧で囲むというテクニックがあります。


float maxNum = (std::numeric_limits&lt;float&gt;::max)();

プリプロセッサは、max( ... ) という形にマッチする場合にマクロ展開を行います。ここで (std::numeric_limits<float>::max) と括弧で囲むことで、「max というトークンの直後に ( が来る」形を避け、マクロ展開の対象から外すことができます。

この書き方は、Windows の max マクロと std::max（アルゴリズム関数）を共存させる場面でよく使われるテクニックでもあります。


#include &lt;algorithm&gt;

int a = 1;
int b = 2;

// Windows マクロの max を避けつつ std::max を呼びたい
int c = (std::max)(a, b);

しかし、可読性が低く、毎回書くのも手間なので、恒久的な解決策としてはおすすめしません。「外部ライブラリなどの事情でどうしても今すぐ NOMINMAX を導入できない一時しのぎ」として捉えるのが良いでしょう。

回避方法	メリット	デメリット	想定シーン
`NOMINMAX` を定義	根本原因を解消。C++ 標準ライブラリと衝突しない。	古いコードで Windows の `max/min` マクロに依存している部分の修正が必要な場合あり。	新規開発、既存コードのモダナイズ時の基本方針。
`#undef max`, `#undef min`	影響範囲を翻訳単位単位で制御できる。	書き忘れ・再インクルードなどで再発しやすい。管理が面倒。	小さなツールや、一部の cpp ファイルだけで問題を抑えたい場合。
`<Windows.h>` を最後にインクルード	標準ライブラリ側への影響を若干減らせる。	自作ヘッダーとの関係や PCH によって簡単に崩れる。	とりあえず「マシ」にしたい暫定対応。
`(...)()` の括弧テクニック	局所的にコンパイルエラーを回避できる。	読みづらく、忘れやすく、量が多いとつらい。	一時しのぎ、サンプルコード、外部制約がある箇所だけ。

実務的なベストプラクティス

現代的な C++ プロジェクト（特にクロスプラットフォームを意識したコード）では、次のような方針を取るのが現実的です。

`Windows.h` 包装ヘッダーを用意する

プロジェクトのどこからでも直接 <Windows.h> をインクルードするのではなく、専用のラッパーヘッダーを 1 つ用意し、そこに Windows 固有の設定を集約する方法が有効です。


// windows_wrapper.h
#pragma once

#define WIN32_LEAN_AND_MEAN  // 余計なヘッダーの読み込みを抑制（任意）
#define NOMINMAX             // max/min マクロを無効化

#include &lt;Windows.h&gt;

そして、プロジェクト内では <Windows.h> を直接ではなく、このラッパーを通じて利用します。


#include "windows_wrapper.h"
#include &lt;limits&gt;

int main() {
    float maxNum = std::numeric_limits&lt;float&gt;::max();
    return 0;
}

こうしておくと、

NOMINMAX を定義し忘れる心配がなくなる
将来 Windows 固有の設定（UNICODE など）を追加したくなったときに、1 箇所を修正すればよい
<Windows.h> をヘッダー側で安易にインクルードしない、というコーディング規約を徹底しやすい

といったメリットが得られます。

`<Windows.h>` は可能な限りヘッダーから締め出す

もうひとつ重要なのは、「<Windows.h> をヘッダーファイルに書かない」ことです。ヘッダーファイルに Windows 固有のヘッダーを含めてしまうと、そこをインクルードするあらゆる翻訳単位にマクロがばらまかれてしまいます。

ヘッダー側では Win32 API のハンドル・構造体を前方宣言や void* で隠蔽する
実際に API を呼び出すのは .cpp に閉じ込める

といった工夫により、「マクロの汚染範囲」を最小限にすることができます。

なぜ Linux では問題が起きないのか

同じコードが Linux や macOS（GCC / Clang）では問題なくコンパイルできるのは、システムヘッダーに max/min マクロが定義されていないからです。

プラットフォーム	システムヘッダーの `max/min` マクロ	本記事の問題の発生有無
Windows + MSVC	`<Windows.h>` で定義される（`NOMINMAX` なしの場合）	発生する
Windows + MSVC + `NOMINMAX`	定義されない	基本的に発生しない
Linux + GCC / Clang	通常定義されない	基本的に発生しない
macOS + Clang	通常定義されない	基本的に発生しない

クロスプラットフォーム開発では、「Windows だけでコンパイルが通らない」コードは、たいていこのような「システムヘッダー由来のマクロ」や「コンパイラ依存の拡張」が絡んでいます。今回の max/min はその典型例です。

`std::numeric_limits` と `std::max/std::min` の違い

似た名前のせいで、std::numeric_limits<T>::max() と std::max() / std::min() を混同しがちなので、ここで一度整理しておきます。

std::numeric_limits<T>::max()
型 T に対する「表現可能な最大値」を返す静的メンバ関数。テンプレートクラスの一部。
std::max(a, b), std::min(a, b)
2 つの値のうち大きい方 / 小さい方を返す関数テンプレート。<algorithm> で定義される。

Windows の #define max(a,b) は本来 std::max(a, b) と用途が近いのですが、名前空間も型安全性もなく、C 由来の素朴なマクロです。このマクロは std::max() とも衝突しますが、std::numeric_limits<T>::max() のような「識別子としての max」にも悪影響を及ぼします。

モダン C++ では、基本的にマクロ版の max/min は使わず、C++ 標準ライブラリの std::max/std::min と std::numeric_limits を使うという方針に統一するのが安全です。そのためにも、早い段階で NOMINMAX を導入しておく価値があります。

既存コードベースで `NOMINMAX` を導入する際のポイント

長年運用されている Windows 向け C++ プロジェクトでは、すでに max/min マクロをあちこちで使っていることがあります。そうしたコードベースに NOMINMAX を導入すると、次のようなコンパイルエラーが出るかもしれません。


int a = 1, b = 2;
int c = max(a, b); // &lt;-- ここがエラーに

この場合は、次のような手順で段階的に移行していくと比較的安全です。

コード全体を検索して max( / min( の利用箇所を洗い出す
Windows マクロ由来なのか、独自関数なのかを確認します。
明らかに「2 つの値の大小比較」だけの用途のものから std::max/std::min に置き換える
<algorithm> をインクルードして、std::max(a, b) / std::min(a, b) に書き換えます。
テンプレートや異なる型の比較など、挙動がシビアな箇所はテストを用意してから変更する
ひと通り置き換え終えたら、ビルド設定に NOMINMAX を追加する

段階的に置き換えていけば、「ある日突然大量のコンパイルエラーが出て仕事にならない」という状況を避けやすくなります。テストが整っているプロジェクトであれば、NOMINMAX を導入 → 失敗した箇所だけ修正、というアプローチも取りやすいでしょう。

まとめ：`NOMINMAX` を徹底して「マクロ汚染」から解放されよう

本記事では、MSVC + <Windows.h> 環境で std::numeric_limits<float>::max() が「syntax error: identifier ‘max’」になる問題について、原因と回避策を詳しく見てきました。

原因は <Windows.h> が定義する #define max(a,b) / #define min(a,b) マクロとの衝突
プリプロセッサが max(...) というトークン列を強制的に置き換えてしまうため、C++ の正しいコードが壊される
最もシンプルで推奨される解決策は、NOMINMAX を定義してから <Windows.h> をインクルードすること
#undef max / #undef min、インクルード順の調整、括弧テクニックなどの回避方法もあるが、いずれも暫定的な対処にとどまる
Windows 専用のラッパーヘッダーを用意し、<Windows.h> はそこからだけインクルードする運用が実務的に扱いやすい
既存コードで Windows の max/min マクロを使っている場合は、段階的に std::max/std::min への置き換えを進める

「Windows の max/min マクロにこれ以上悩まされたくない」のであれば、プロジェクトに NOMINMAX を導入し、<Windows.h> の取り扱いを整理することが最も効果的です。これにより、Linux / macOS との挙動差も減り、クロスプラットフォームな C++ コードを書きやすくなります。今回の std::numeric_limits<float>::max() の問題も、その流れの中で自然に解消されていくでしょう。

この記事を書いた人

佐藤健司

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

C++でstd::numeric_limits::maxがWindows環境でエラーになる原因とNOMINMAXによる解決方法

C++ の `std::numeric_limits` と `max()` を整理する

実際に出るエラーと最小再現コード

原因：`<Windows.h>` の `max`/`min` マクロと衝突

最も手軽で安全な解決策：`#define NOMINMAX` を宣言する

Visual Studio での設定例

その他の回避パターンと注意点

`#undef max` / `#undef min` でマクロを無効化する

`<Windows.h>` を最後にインクルードする

苦肉の策：`(std::numeric_limits<float>::max)()` と書く

実務的なベストプラクティス

`Windows.h` 包装ヘッダーを用意する

`<Windows.h>` は可能な限りヘッダーから締め出す

なぜ Linux では問題が起きないのか

`std::numeric_limits` と `std::max/std::min` の違い

既存コードベースで `NOMINMAX` を導入する際のポイント

まとめ：`NOMINMAX` を徹底して「マクロ汚染」から解放されよう

この記事を書いた人

コメント

コメントするコメントをキャンセル

C++でstd::numeric_limits::maxがWindows環境でエラーになる原因とNOMINMAXによる解決方法

C++ の std::numeric_limits と max() を整理する

実際に出るエラーと最小再現コード

原因：<Windows.h> の max/min マクロと衝突

最も手軽で安全な解決策：#define NOMINMAX を宣言する

Visual Studio での設定例

その他の回避パターンと注意点

#undef max / #undef min でマクロを無効化する

<Windows.h> を最後にインクルードする

苦肉の策：(std::numeric_limits<float>::max)() と書く

実務的なベストプラクティス

Windows.h 包装ヘッダーを用意する

<Windows.h> は可能な限りヘッダーから締め出す

なぜ Linux では問題が起きないのか

std::numeric_limits と std::max/std::min の違い

既存コードベースで NOMINMAX を導入する際のポイント

まとめ：NOMINMAX を徹底して「マクロ汚染」から解放されよう

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

C++ の `std::numeric_limits` と `max()` を整理する

原因：`<Windows.h>` の `max`/`min` マクロと衝突

最も手軽で安全な解決策：`#define NOMINMAX` を宣言する

`#undef max` / `#undef min` でマクロを無効化する

`<Windows.h>` を最後にインクルードする

苦肉の策：`(std::numeric_limits<float>::max)()` と書く

`Windows.h` 包装ヘッダーを用意する

`<Windows.h>` は可能な限りヘッダーから締め出す

`std::numeric_limits` と `std::max/std::min` の違い

既存コードベースで `NOMINMAX` を導入する際のポイント

まとめ：`NOMINMAX` を徹底して「マクロ汚染」から解放されよう

コメントするコメントをキャンセル