【C++】#pragma onceとインクルードガードの違いと使い分け

2026年2月28日

C++の開発において、ヘッダーファイルの重複インクルードを防ぐことは極めて重要です。

定義が重複するとコンパイルエラーが発生するため、古くからインクルードガードと呼ばれるマクロを用いた手法が用いられてきました。

一方で、より簡潔な記述が可能な#pragma onceも広く普及しており、現代の主要なコンパイラでは標準的にサポートされています。

本記事では、これら2つの手法の仕組み、メリット・デメリット、そして現代のC++開発における使い分けについて詳しく解説します。

目次 [ close ]

二重インクルードとその問題点

C++では、クラスの定義や関数のプロトタイプ宣言をヘッダーファイルに記述します。

大規模なプロジェクトになると、あるヘッダーファイルが別のヘッダーファイルをインクルードし、それがさらに別のファイルに読み込まれるという複雑な依存関係が生じます。

もし、何の対策も講じずに同じヘッダーファイルを複数回インクルードしてしまうと、コンパイラは「同じクラスや構造体が二度定義された」と判断し、二重定義エラーを出力して停止してしまいます。

これを防ぐための仕組みが、今回紹介する2つの手法です。

インクルードガード（伝統的な手法）

インクルードガードは、プリプロセッサディレクティブである#ifndef、#define、#endifを組み合わせて実現する、最も伝統的で標準的な手法です。

インクルードガードの具体的な実装

以下に、インクルードガードを使用した標準的なヘッダーファイルの書き方を示します。

C++

#ifndef MY_HEADER_H
#define MY_HEADER_H

// クラスの定義などをここに記述
class MyClass {
public:
    void doSomething();
};

#endif // MY_HEADER_H

このコードでは、最初にMY_HEADER_Hというマクロが定義されているかを確認します。

未定義であれば定義を行い、ファイルの内容を読み込みます。

二回目以降のインクルードでは、既にマクロが定義されているため、#ifndefから#endifまでの内容がすべてプリプロセッサによって無視されます。

インクルードガードのメリット

1. 言語標準に準拠している

インクルードガードはC++（およびC言語）の標準的な仕様のみを使用しているため、どのような古いコンパイラや特殊な環境でも確実に動作します。

移植性を最優先するライブラリ開発などでは、現在でもこの手法が選ばれることが多いです。

2. 柔軟な制御が可能

マクロを使用しているため、特定の条件下でインクルードを制御するなど、高度なプリプロセッサ操作と組み合わせることが可能です。

インクルードガードのデメリット

1. マクロ名の衝突リスク

プロジェクト内でマクロ名が重複してしまうと、本来読み込まれるべきファイルがスキップされるという極めて見つけにくいバグを引き起こします。

そのため、一般的には「プロジェクト名_ディレクトリ名_ファイル名_H」のような、長く複雑な名前を付ける必要があります。

2. 記述の手間と保守性

ファイルの先頭と末尾の両方に記述が必要であり、ファイル名を変更した際にマクロ名も修正し忘れるといったヒューマンエラーが発生しやすくなります。

#pragma once（現代的な手法）

#pragma onceは、多くの現代的なコンパイラ（GCC, Clang, MSVCなど）でサポートされている非標準のプリプロセッサディレクティブです。

#pragma onceの具体的な実装

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

C++

#pragma once

// クラスの定義などをここに記述
class MyClass {
public:
    void doSomething();
};

この1行があるだけで、コンパイラはそのファイルを一度しか処理しないように自動的に管理してくれます。

#pragma onceのメリット

1. 簡潔でエラーが少ない

マクロ名を考える必要がなく、コードが非常にスッキリします。

マクロ名の衝突を心配する必要も、ファイル名変更に伴う修正漏れもありません。

2. コンパイル速度の向上

インクルードガードの場合、プリプロセッサは「ファイルを開き、中身を見て、マクロ判定を行う」という手順を踏みます。

一方、#pragma onceはコンパイラがファイルパスを直接管理しているため、二回目以降はファイルを開くこと自体を省略できる場合があり、大規模プロジェクトではコンパイル時間の短縮が期待できます。

#pragma onceのデメリット

1. 非標準である

ISO C++標準規格には含まれていません。

しかし、2026年現在の主要なコンパイラ（GCC 3.4以降、Clang全バージョン、Visual C++ 2005以降など）では完全にサポートされているため、実用上の問題になることは稀です。

2. ファイルの同一性判定の問題

コンパイラが「ファイルパス」で同一性を判断するため、シンボリックリンクやハードリンクを多用する複雑なファイルシステム構成において、同じファイルが別ファイルと誤認されて二重に読み込まれる可能性がゼロではありません。

両者の徹底比較

それぞれの特徴を以下の表にまとめました。

特徴	インクルードガード	#pragma once
標準化	ISO標準（C/C++共通）	非標準（実質的なデファクト標準）
記述量	3行以上必要	1行のみ
名前衝突	発生する可能性がある	発生しない
保守性	マクロ名の管理が必要	非常に高い
コンパイル速度	わずかに遅い傾向	わずかに速い傾向
移植性	完璧	ほぼ全ての主要環境で動作

どちらを使うべきか？現代の推奨事項

結論から述べると、現代の一般的な開発環境においては#pragma onceの使用を第一選択とすることをおすすめします。

#pragma onceを推奨する理由

多くの開発現場で#pragma onceが好まれる理由は、その圧倒的な保守性の高さにあります。

マクロ名の重複によるバグは、一度発生すると原因の特定に時間がかかることが多く、そのリスクを未然に防げるメリットは非常に大きいです。

インクルードガードを使用すべきケース

一方で、以下のような特定の状況下では、依然としてインクルードガードが選ばれます。

極めて古いコンパイラを使用しなければならないレガシーシステムの保守
組み込み向けなどの特殊なツールチェーンを使用する環境
あらゆる環境でコンパイル可能であることを保証したいオープンソースライブラリの公開

両方の併用（ハイブリッド方式）

一部のライブラリでは、安全策として両方を記述するケースも見られます。

C++

#pragma once
#ifndef MY_HEADER_H
#define MY_HEADER_H

// 内容

#endif

しかし、現代のコンパイラ性能を考えると、これらを併用するメリットは薄く、コードが冗長になるデメリットの方が目立ちます。

プロジェクト内でどちらかに統一するのが最善の策と言えるでしょう。

C++20以降の展望：Modules

2026年の開発環境において無視できないのが、C++20で導入されたModules（モジュール）です。

import構文を使用するモジュールでは、そもそも二重インクルードという概念自体が存在しません。

C++

// 現代的なモジュールの例
export module MyModule;

export class MyClass {
public:
    void doSomething();
};

今後、既存のヘッダーファイルからモジュールへの移行が進むにつれ、インクルードガードや#pragma onceの議論自体が過去のものになっていく可能性があります。

ただし、膨大な既存資産がある以上、ヘッダーファイルの管理技術は依然として必須のスキルです。

まとめ

インクルードガードと#pragma onceは、どちらもヘッダーファイルの二重定義を防ぐという目的は同じですが、そのアプローチが異なります。

インクルードガードは、高い移植性と標準準拠を誇る伝統的な手法であり、環境を選ばず確実に動作します。

一方で、#pragma onceは、記述の簡潔さと保守性の高さ、そしてコンパイル速度の面で優れており、現代の主要な開発環境では事実上の標準として広く採用されています。

新規のプロジェクトであれば、特別な制約がない限り#pragma onceを使用し、コードの可読性とメンテナンス性を向上させるのがベストプラクティスです。

また、将来的にはC++モジュールへの移行も視野に入れつつ、適切なヘッダー管理を行っていきましょう。