C++20 modulesの基本的な使い方とビルド設定：モジュール化による開発効率化の手順

2026年5月1日

基礎知識

C++は長年、ヘッダーファイルのインクルードという仕組みを通じてコードの再利用性を維持してきました。

しかし、プリプロセッサによるテキスト置換をベースとしたこの手法は、ビルド時間の増大やマクロの競合といった多くの課題を抱えていました。

C++20で導入された「モジュール（Modules）」は、これらの問題を根本から解決するために設計された待望の機能です。

本記事では、C++20モジュールの基本的な使い方から、開発効率を劇的に向上させるためのビルド設定まで、実務に即した内容を詳しく解説します。

目次 [ close ]

従来のヘッダーファイルが抱えていた課題

C++において、従来の#includeディレクティブは、指定されたファイルの内容をそのままソースコードに埋め込むという単純な動作に基づいています。

この仕組みには、現代の大規模なソフトウェア開発において無視できないいくつかの欠点が存在していました。

まず、コンパイル時間の増大です。

ヘッダーファイルが複数のソースファイルからインクルードされるたびに、コンパイラは同じ内容を何度も解析しなければなりません。

特に標準ライブラリや大規模なテンプレートライブラリを使用する場合、このオーバーヘッドは数分から数時間のビルド時間に直結します。

次に、マクロの汚染（Macro Leakage）です。

ヘッダーファイル内で定義されたマクロは、それをインクルードしたすべての場所に影響を及ぼします。

これにより、意図しない名前の衝突が発生し、デバッグが困難なバグを引き起こす原因となっていました。

また、インクルードの順序によってプログラムの挙動が変わるという不安定さも、開発者を悩ませる要因の一つでした。

C++20モジュールの基本概念

C++20で導入されたモジュールは、コードの論理的な境界を明確にし、効率的にコンパイルするための新しい単位です。

従来のヘッダーファイルとは異なり、一度コンパイルされたモジュールはバイナリ形式の中間表現として保存されるため、再利用時の解析コストが大幅に削減されます。

モジュールの主な特徴

モジュールには、これまでのC++開発にはなかったいくつかの重要な特徴があります。

カプセル化の強化：モジュール内でexportキーワードを付けた要素のみが外部から参照可能です。それ以外の内部関数や変数は完全に隠蔽されます。
インポートの高速化：import宣言は、プリプロセッサによるテキスト置換ではなく、セマンティック（意味論的）な情報の取り込みを行います。
マクロの分離：モジュールからマクロが漏れ出すことはなく、外部から持ち込まれたマクロによってモジュール内のコードが書き換えられることもありません。

モジュールの基本的な書き方

モジュールを作成するには、まず「モジュール・インターフェース・ユニット」を定義する必要があります。

これは、そのモジュールが外部に対して何を提供するのかを記述するファイルです。

モジュール・インターフェースの作成

以下に、基本的な数学関数を提供するモジュールの例を示します。

ファイルの拡張子は、環境によりますが一般的に.cppmや.ixxが使われます。

C++

// MathUtils.cppm (モジュール・インターフェース・ユニット)
export module MathUtils; // モジュール名の宣言

export namespace MathUtils {
    // 外部から利用可能な関数
    export int add(int a, int b) {
        return a + b;
    }

    // exportを付けていない関数は、モジュールの外からは見えません
    int internal_helper(int n) {
        return n * 2;
    }

    export int double_add(int a, int b) {
        return internal_helper(add(a, b));
    }
}

このコードでは、export module MathUtils;という宣言によって、このファイルがMathUtilsという名前のモジュールであることを示しています。

また、exportキーワードが付与された関数や名前空間のみが、このモジュールをインポートした側から利用可能になります。

モジュールの利用方法

作成したモジュールを利用するには、従来の#includeに代わり、importキーワードを使用します。

C++

// main.cpp
import MathUtils; // モジュールのインポート
#include <iostream>

int main() {
    int result = MathUtils::add(5, 3);
    std::cout << "Result: " << result << std::endl;

    // MathUtils::internal_helper(5); // コンパイルエラー：外部からはアクセス不可
    return 0;
}

実行結果

Result: 8

注意点として、モジュールをインポートする際はセミコロンが必要です。また、import文は通常、ファイルの先頭（グローバル・モジュール・フラグメントを除く）に記述する必要があります。

モジュールの構造化とパーティション

大規模なプロジェクトでは、一つのモジュールが巨大になりすぎないよう、複数のファイルに分割したい場合があります。

これを実現するのが「モジュール・パーティション」です。

インターフェース・パーティション

モジュールのインターフェースを機能単位で分割する場合、export module モジュール名:パーティション名;という構文を使用します。

C++

// Geometry-Circle.cppm
export module Geometry:Circle; // GeometryモジュールのCircleパーティション

export namespace Geometry {
    struct Circle {
        double radius;
    };
    
    double getArea(Circle c) {
        return 3.14159 * c.radius * c.radius;
    }
}

C++

// Geometry.cppm (プライマリ・モジュール・インターフェース)
export module Geometry;

export import :Circle; // パーティションを再エクスポート

プライマリ・モジュール・インターフェースでexport importを行うことにより、利用者はimport Geometry;とするだけで、分割されたすべての機能にアクセスできるようになります。

これにより、論理的なまとまりを維持しつつ、物理的なファイル分割が可能になります。

実装ユニットの分離

インターフェース（宣言）と実装（定義）を分離することも可能です。

これは従来の.hと.cppの関係に似ていますが、モジュールではより厳密に管理されます。

C++

// Database.cppm (インターフェース)
export module Database;

export class Connection {
public:
    void connect();
};

C++

// Database.cpp (実装)
module Database; // exportは付けない

void Connection::connect() {
    // 複雑な接続処理
}

実装ユニットではexportキーワードを記述しません。

コンパイラは、同じモジュール名を持つインターフェース・ユニットと実装ユニットを適切に関連付けます。

Header Unitsによる既存資産の活用

プロジェクト全体を一度にモジュール化するのは困難です。

C++20には、既存のヘッダーファイルをモジュールのように扱うための「Header Units」という仕組みが用意されています。

import <iostream>; や import "my_header.h"; のように記述することで、従来のヘッダーをモジュールとしてインポートできます。

これにより、マクロの衝突を抑制しつつ、ビルド時間の短縮という恩恵を部分的に受けることができます。

機能	#include (ヘッダー)	import (モジュール)
処理方式	テキスト置換	バイナリ解析
マクロの透過性	どこまでも伝播する	外部へは漏れない
ビルド時間	重複解析により遅い	キャッシュにより速い
ODR違反のリスク	高い	低い

ビルドシステムの設定：CMake 3.28以降の対応

2026年現在、主要なビルドシステムであるCMakeはC++20モジュールを完全にサポートしています。

以前は複雑な設定が必要でしたが、CMake 3.28以降、標準的な記述方法でモジュールを扱えるようになりました。

CMakeLists.txt の記述例

モジュールをコンパイルするには、target_sourcesでFILE_SET TYPE CXX_MODULESを指定するのが最新のベストプラクティスです。

CMake

cmake_minimum_required(VERSION 3.28)
project(ModuleExample LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

add_executable(MyApp main.cpp)

# モジュールファイルの登録
target_sources(MyApp
    PUBLIC
        FILE_SET CXX_MODULES FILES
            MathUtils.cppm
            Geometry.cppm
)

この設定により、CMakeはモジュール間の依存関係を自動的に解析し、正しい順序でコンパイルを実行します。

以前のように「どのモジュールを先にビルドするか」を開発者が手動で管理する必要はありません。

主要コンパイラのサポート状況

MSVC (Visual Studio): 最も早くから実用的なサポートを提供しており、.ixx拡張子を標準として推奨しています。
Clang: バージョン16以降で標準的なモジュール対応が進み、CMakeとの連携も安定しています。
GCC: バージョン11から段階的にサポートされ、現在は大規模なプロジェクトでも利用可能なレベルに達しています。

開発効率化のためのベストプラクティス

モジュールを導入して開発効率を最大化するためには、単に構文を覚えるだけでなく、いくつかの設計指針を意識することが重要です。

1. 粒度の適切な設計

モジュールを細かく分けすぎると、依存関係の解析オーバーヘッドが増大する可能性があります。

一方で、巨大すぎるモジュールは再ビルド時のコストを下げられません。

論理的な機能単位（コンポーネント単位）でモジュールを構成するのが理想的です。

2. 内部実装の隠蔽

モジュール内部でのみ使用する関数やクラスには絶対にexportを付けないでください。

これにより、内部実装の変更が外部に影響を与えないことが保証され、不必要な再コンパイルを連鎖的に発生させるリスクを軽減できます。

3. グローバル・モジュール・フラグメントの活用

既存のライブラリがモジュールに対応していない場合、module;で始まる「グローバル・モジュール・フラグメント」セクションに#includeを記述します。

これにより、モジュールの所有権を持たないコードとの共存が可能になります。

C++

module;
#include <sqlite3.h> // モジュール化されていない外部ライブラリ

export module DatabaseWrapper;
// ... 以下にモジュールの定義

モジュール導入時の注意点とトラブルシューティング

移行期において、いくつかの典型的な問題に遭遇することがあります。

循環参照の禁止

モジュール A がモジュール B をインポートし、かつモジュール B がモジュール A をインポートすることはできません。

これはヘッダーファイルでも避けるべきことでしたが、モジュールではコンパイル時に厳密にチェックされ、エラーとなります。

設計段階で単方向の依存関係を意識してください。

ツールチェインの不整合

IDEのインテリセンス（コード補完）がモジュールを正しく認識しない場合があります。

この場合、ビルドディレクトリをクリーンにして再生成するか、最新のIDEアップデートを適用することを確認してください。

2026年現在のVisual StudioやCLion、VS CodeのC++拡張機能は高い精度でモジュールを認識しますが、ビルドシステムの出力する依存関係グラフと同期している必要があります。

まとめ

C++20モジュールは、30年以上にわたるC++のコンパイルの仕組みを根本から変える革新的な機能です。

ヘッダーファイルによる物理的なテキストコピーから、セマンティックなモジュールインポートへと移行することで、「ビルド時間の短縮」「堅牢なカプセル化」「名前衝突の解消」という大きな恩恵を享受できます。

最初は CMake の設定や新しい拡張子に戸惑うかもしれませんが、一度環境を整えてしまえば、その開発効率の高さは手放せなくなるはずです。

まずは小さなユーティリティ関数からモジュール化を始め、徐々にプロジェクト全体へと適用範囲を広げていくことをお勧めします。

C++のモダンな開発手法を取り入れ、よりクリーンでスケーラブルなコードベースを構築していきましょう。