C言語のヘッダ二重インクルード防止術(インクルードガード)

2025年10月18日2025年10月29日

C言語

C言語では、複数のソースファイルから同じヘッダを読み込むのが普通です。

しかし、同じヘッダが1つの翻訳単位に2回以上取り込まれると、定義の重複によりコンパイルエラーになります。

その典型的な対策が「インクルードガード」です。

本記事では、仕組みから実践コード、よくあるミスの直し方まで丁寧に解説します。

目次 [ close ]

ヘッダの二重インクルードとは

Cの#includeは、指定したファイルの中身をその場にテキスト展開します。

同じ定義(構造体定義や変数定義など)が2回以上現れると再定義エラーになり、ビルドが止まります。

何が起きるか

ヘッダに構造体の「定義」を書き、そのヘッダを同じソースで2回#includeすると再定義になります。

プロトタイプ宣言の重複は許されますが、型や構造体の本体定義、グローバル変数の定義の重複はNGです。

以下は、あえてインクルードガードを付けない悪い例です。

C言語

// bad.h (インクルードガードなしの例: わざと悪いコード)
typedef struct Example {
    int value;
} Example; // 構造体の"定義"がここにある

C言語

// dupe.c
#include "bad.h"
#include "bad.h" // 同じヘッダを2回インクルード(意図的)

int main(void) {
    Example e = {0};
    return 0;
}

この状態でコンパイルすると、典型的には以下のようなエラーになります。

実行結果

dupe.c:2:10: error: redefinition of ‘struct Example’
    2 | #include "bad.h"
      |          ^~~~~~~
In file included from dupe.c:1:
bad.h:1:16: note: originally defined here
    1 | typedef struct Example {
      |                ^~~~~~~

原因は単純で、テキストとして同じ定義が2回挿入されるからです。

原因

プリプロセッサは#includeを見つけると、そのファイルの内容を丸ごと貼り付けます。

これにより、1回目のインクルードで定義された構造体やグローバル変数が、2回目で再び定義されてしまうのです。

宣言だけ(関数プロトタイプなど)は複数回あっても問題ありませんが、定義の重複はエラーになります。

「宣言は何度でもよいが、定義は1度だけ」という基本ルールを覚えておくと理解しやすいです。

インクルードガードの基本

インクルードガードは、「このヘッダをこの翻訳単位ではまだ読み込んでいない」場合だけ中身を有効にする仕組みです。

プリプロセッサの条件付きコンパイルを使います。

基本構文

もっとも一般的なパターンは#ifndef・#define・#endifの組み合わせです。

C言語

// example.h (雛形)
#ifndef EXAMPLE_H_INCLUDED   // まだ定義されていなければ…
#define EXAMPLE_H_INCLUDED   // ここでマクロを定義して、以降の重複を防ぐ

// ヘッダの中身(型定義、関数プロトタイプ、定数マクロなど)を書く

#endif // EXAMPLE_H_INCLUDED

1回目のインクルードではEXAMPLE_H_INCLUDEDが未定義なので中身が有効になります。
2回目以降はEXAMPLE_H_INCLUDEDが既に定義済みなので、#endifまでスキップされます。

この「条件付きで1回だけ有効にする」動作がインクルードガードの本質です。

マクロ名の付け方

マクロ名は衝突を避けられるよう、プロジェクト名やパスを含めた大文字スネークケースにするのが通例です。

例: PROJECT_MODULE_EXAMPLE_H、EXAMPLE_H_INCLUDED、MYLIB_UTIL_STRING_H_
先頭にアンダースコア、あるいはダブルアンダースコアは予約識別子に該当し得るため避けます(例: _EXAMPLE_H、__EXAMPLE_HはNG)。
なるべくファイルパスの情報を反映させると、異なるディレクトリの同名ヘッダでも衝突しにくいです。

書く位置

ヘッダのいちばん先頭に書いて、ヘッダ全体を#endifで閉じるのが鉄則です。

ヘッダ内の全ての定義をガードで包めば、途中で漏れなく適用できます。

先頭にコメントを置くのはOKですが、プリプロセッサディレクティブや宣言をガードより前に置かないようにします。

実践例で理解する

ここからは、実際にヘッダにインクルードガードを付け、同じヘッダを複数回インクルードしてもビルドが通ることを確認します。

C言語初心者の方でも追えるように、短い例で説明します。

example.hにインクルードガードを付ける

C言語

// example.h
#ifndef EXAMPLE_H_INCLUDED
#define EXAMPLE_H_INCLUDED

// 定数マクロ(ヘッダ利用側でも使いたい値)
#define EXAMPLE_VERSION 100

// 構造体の"定義"をヘッダに置く(ガードがないと再定義になりやすい)
typedef struct Example {
    int value;
} Example;

// 関数プロトタイプ宣言(重複してもOKだが、ヘッダにまとめるのが慣例)
void util_print(const char* label);
int add(int a, int b);

#endif // EXAMPLE_H_INCLUDED

構造体の定義を含むヘッダは、ガードがないと特に危険です。

今回のように必ずインクルードガードで包みます。

main.cとutil.cで同じヘッダを#include

C言語

// util.c
#include <stdio.h>
#include "example.h" // 同じヘッダをソース間で共有

// ラベルとバージョンを表示する関数の定義
void util_print(const char* label) {
    // ヘッダの定数マクロ(EXAMPLE_VERSION)を利用
    printf("util_print: label=%s, version=%d\n", label, EXAMPLE_VERSION);
}

// 加算のサンプル(本題とは無関係だが出力用に用意)
int add(int a, int b) {
    return a + b;
}

C言語

// main.c
#include "example.h"
#include "example.h" // わざと二重インクルード(インクルードガードがあればOK)

int main(void) {
    Example ex = { .value = 42 }; // ヘッダで定義した構造体を使う

    util_print("Hello, Example!");
    int result = add(3, 4);

    // 実行出力を見やすくするための改行
    // (printfはutil_print内だけで使う設計にしています)
    // 実際の現場ではログ出力や整形はユーティリティ側に寄せるのが一般的です
    // 今回は説明簡略化のためにputsを使います
    // putsは自動で末尾に改行を付けます
    puts("main: util_print called above");
    puts("main: result=7 and Example.value=42");

    // 使った値が本当に計算されていることの念押し
    (void)result;
    (void)ex;

    return 0;
}

ビルドと実行の例を示します。

Shell

# GCCの例
gcc -Wall -Wextra -std=c17 main.c util.c -o app
./app

実行結果

util_print: label=Hello, Example!, version=100
main: util_print called above
main: result=7 and Example.value=42

このように、main.cで同じヘッダを2回インクルードしても、インクルードガードによって1回分しか有効化されないため、再定義エラーになりません。

二重インクルードでもビルド成功

ポイントは以下です。

説明のため文章で整理します。

main.cは#include "example.h"を2回書いていますが、2回目は#ifndefの条件でスキップされるため安全です。
util.cでも同じヘッダを読みますが、翻訳単位はファイルごとに独立なので、各翻訳単位内で1回だけ有効になれば問題ありません。
実行結果が期待通りなら、インクルードガードが効いて再定義が起きていないことの確認になります。

よくあるミスと対策

インクルードガードは構文がシンプルなぶん、タイポや書き忘れの影響が直接エラーになります。

代表的な落とし穴と対策をまとめます。

マクロ名の衝突やタイプミス

マクロ名を打ち間違えると、ガードが効かずに二重インクルードになります。

C言語

// bad_guard.h (わざとのタイプミス例)
#ifndef EXAMLE_H_INCLUDED   // "EXAMPLE"のPが抜けている(ミス)
#define EXAMPLE_H_INCLUDED  // こちらは正しい
typedef struct Foo { int x; } Foo;
#endif

このヘッダを2回インクルードすると、1回目はEXAMLE_H_INCLUDEDが未定義なので中身が有効になりますが、2回目もEXAMLE_H_INCLUDEDが未定義のままなので再び有効となり、再定義エラーが出ます。

対策はシンプルで、同じマクロ名を#ifndefと#defineで正確に揃えることです。

エディタのスニペットやテンプレートを活用するとミスが減ります。

#endifの入れ忘れ

#endifを閉じ忘れると、コンパイラは「未終了の条件付きコンパイル」としてエラーを出します。

C言語

// missing_endif.h (わざと閉じ忘れ)
#ifndef MISSING_ENDIF_H
#define MISSING_ENDIF_H
typedef struct Bar { int y; } Bar;
// #endif を書き忘れ！

エラー例:

text

missing_endif.h:5:1: error: unterminated #ifndef

開いたら閉じる、ガードで包んだらヘッダ全体を閉じるというリズムを身につけましょう。

行末コメントで対になるマクロ名を残す(例: #endif // MISSING_ENDIF_H)のも効果的です。

#pragma onceとの違い

#pragma onceは「このヘッダは1度だけ」の意図を簡潔に示す非標準拡張です。

多くの処理系で使えますが、標準Cの仕様ではありません。

違いを要点で比較します。

項目	インクルードガード	#pragma once
標準準拠	C標準で利用可能	非標準(多くの処理系で事実上サポート)
可搬性	とても高い	高いが処理系依存の余地あり
記述の明確さ	少し長いが明示的	短く読みやすい
パス/リンクの罠	影響なし	シンボリックリンクや重複パスでまれに効かない報告
ビルド速度	近年は差が小さい	実装により高速化の最適化あり