【C++】インクルードガードの書き方｜二重定義防止と#pragma once

2026年2月28日

C++の開発において、ヘッダーファイルの管理は非常に重要な要素です。

プロジェクトが大規模になるにつれて、一つのソースファイルから複数のヘッダーファイルを読み込む機会が増えますが、ここで問題となるのがヘッダーファイルの重複インクルードです。

同じ定義が二重に読み込まれると、コンパイラは「二重定義」としてエラーを出し、ビルドが停止してしまいます。

これを防ぐための仕組みがインクルードガードです。

本記事では、伝統的なマクロを用いた書き方から、現代的な#pragma onceの利用方法、そしてそれぞれのメリット・デメリットまで、2026年現在の標準的な知識を詳しく解説します。

目次 [ close ]

インクルードガードが必要な理由

C++のプリプロセッサは、#includeを見つけると、その内容をそのままソースコードに展開します。

もし、あるヘッダーファイルが複数の経路で読み込まれると、同じクラスや構造体の定義がソースコード内に複数出現することになります。

二重定義によるコンパイルエラー

C++では、クラスや構造体、インライン関数などを同じスコープ内で二回以上定義することは禁止されています。

これを「単一定義規則(ODR: One Definition Rule)」と呼びます。

例えば、以下のような構成を考えてみましょう。

Common.hで構造体Dataを定義する。
A.hがCommon.hをインクルードする。
B.hがCommon.hをインクルードする。
main.cppがA.hとB.hを両方インクルードする。

このとき、main.cppの中にはDataの定義が2つ存在することになり、コンパイラは「再定義されています」というエラーを出力します。

インクルードガードは、この重複展開を物理的に防ぐための防壁の役割を果たします。

マクロを使用した伝統的な書き方

古くから使われている最も一般的な手法は、プリプロセッサディレクティブである#ifndef、#define、#endifを組み合わせる方法です。

基本的な構文とサンプルコード

この方法では、一意なマクロ名を定義し、そのマクロが既に存在するかどうかをチェックします。

C++

// sample_header.h

#ifndef SAMPLE_HEADER_H // もし SAMPLE_HEADER_H が定義されていなければ
#define SAMPLE_HEADER_H // SAMPLE_HEADER_H を定義する

// ここにヘッダーの内容を記述します
struct UserData {
    int id;
    const char* name;
};

void printUserName(const UserData& user);

#endif // SAMPLE_HEADER_H の終了

このコードでは、最初に#ifndef(if not defined)が実行されます。

初回読み込み時はマクロが定義されていないため、中身が読み込まれ、同時に#defineによってマクロが登録されます。

二回目以降の読み込みでは、既にマクロが存在するため、#ifndefから#endifまでの間がすべてスキップされます。

マクロ名の命名規則

インクルードガードに使用するマクロ名は、他のファイルやライブラリと衝突しないように慎重に決める必要があります。

一般的によく使われるパターンは以下の通りです。

命名パターン	例	特徴
ファイル名大文字 + _H	`MY_HEADER_H`	シンプルで一般的
プロジェクト名 + ファイル名	`MYPROJ_UTILS_H`	衝突のリスクが低い
フォルダ構造 + ファイル名	`CORE_NETWORK_CLIENT_H`	階層が深い場合に有効

注意点として、アンダースコア2つで始まる名前(例: __MY_HEADER_H)や、アンダースコアに続く大文字の名前(例: _MY_HEADER_H)は、C++の実装(コンパイラや標準ライブラリ)が予約している領域であるため、使用を避けるべきです。

#pragma once を使用した現代的な書き方

近年、多くの開発現場で採用されているのが#pragma onceです。

これはコンパイラに対する指示(プラグマ)であり、「このファイルは一度しか読み込まない」ということを直接伝えます。

基本的な構文とサンプルコード

記述は非常にシンプルで、ファイルの先頭に一行追加するだけです。

C++

// modern_header.h
#pragma once // このファイルを一度だけインクルードするように指示

// ここにヘッダーの内容を記述します
class Calculator {
public:
    int add(int a, int b) { return a + b; }
};

この一行だけで、マクロによる管理と同じ(あるいはそれ以上の)効果が得られます。

#ifndefのように、#endifを書き忘れたり、マクロ名が他のファイルと被ったりする心配がありません。

#pragma once のメリットとデメリット

現在、主要なコンパイラ(GCC, Clang, MSVCなど)はすべて#pragma onceをサポートしています。

メリット

記述が簡潔で読みやすい。
マクロ名の衝突を気にする必要がない。
ファイル名が変わってもコードを修正しなくて良い。
コンパイラがファイルパスを直接管理するため、一部の環境ではビルド速度が向上する可能性がある。

デメリット

標準規格(ISO C++)で定義されている機能ではなく、あくまで「多くのコンパイラがサポートしている拡張機能」である。
非常に特殊な環境や非常に古いコンパイラでは動作しない可能性がある。
シンボリックリンクなどが複雑に絡むファイルシステムにおいて、稀に同一ファイルの判定に失敗することがある。

どちらを使うべきか？(2026年時点の推奨)

現代のC++開発においては、基本的には #pragma once の使用を推奨します。

選択の基準

プロジェクトの性質に合わせて選択するのがベストです。

以下の基準を参考にしてください。

一般的なアプリケーション開発: 迷わず#pragma onceを使用しましょう。

コードの保守性が高まり、記述ミスによるバグを未然に防ぐことができます。
広範囲に配布するオープンソースライブラリ: あらゆる環境（マイコン向けの古いコンパイラなど）での動作を保証する必要がある場合は、伝統的な#ifndef方式を採用するか、両方を併用することがあります。
特定のスタイルガイド（例: Google）に従う場合: 企業やプロジェクトによっては、コーディング規約で「マクロ方式を使用すること」と定められている場合があります。

その場合は規約に従います。

両方を併用する書き方

非常に堅実な設計を好むプロジェクトでは、以下のように両方を記述することもあります。

C++

#pragma once
#ifndef MY_PROJECT_HEADER_H
#define MY_PROJECT_HEADER_H

// コンテンツ

#endif // MY_PROJECT_HEADER_H

これにより、#pragma onceをサポートするコンパイラでは高速な処理を期待でき、サポートしていないコンパイラでもマクロによる保護が機能します。

ただし、コードが冗長になるため、現代ではどちらか一方に絞るのが一般的です。

インクルードガードの動作確認

実際に二重インクルードが発生した際、ガードがどのように機能するかをコードで確認してみましょう。

C++

// guard.h
#pragma once
#include <iostream>

inline void hello() {
    std::cout << "Hello from Header!" << std::endl;
}

C++

// main.cpp
#include "guard.h"
#include "guard.h" // 意図的に2回インクルード

int main() {
    hello();
    return 0;
}

実行結果

Hello from Header!

このプログラムは問題なくコンパイル・実行されます。

もしguard.hにインクルードガードがなかった場合、hello()関数の定義が2つ存在することになり、「error: redefinition of ‘hello’」というエラーが発生します。

まとめ

インクルードガードは、C++プログラミングにおける初歩的かつ必須のテクニックです。

ヘッダーファイルの二重定義を防ぐことで、複雑な依存関係を持つプロジェクトでも安定してビルドを行うことが可能になります。

伝統的な#ifndefマクロは高い移植性を持ちますが、マクロ名の管理が必要です。

一方で現代的な#pragma onceは、簡潔でミスが少なく、現在の主要な開発環境のほぼすべてで動作します。

特別な理由がない限りは#pragma onceを選択し、シンプルでメンテナンス性の高いコードを目指しましょう。

どちらの手法を使うにせよ、すべてのヘッダーファイルに必ずインクルードガードを施す習慣をつけることが、C++エンジニアとしての第一歩です。