メタプログラミングとマクロ（コンパイル時計算）

コードがコードを書くとは何か

メタプログラミングとは、プログラムを「データ」として扱い、別のプログラムから生成・解析・変換することを指します。ここでの主役はマクロで、その本質は「コードを入力に取り、コードを出力する関数」です。普通の関数が値から値を計算するのに対し、マクロはプログラム片からプログラム片を計算します。しかもその計算が走るのは実行時ではなく、コンパイル時（あるいは展開時）です。

なぜこれが価値を持つのか。同じ構造のコードを何度も書く場面で、テンプレートを一度書けば残りを機械生成できるからです。重要なのは、生成がコンパイル時に完結する点です。生成されたコードはそのまま通常のコンパイル経路に乗るため、実行時の追加コストはゼロに近づきます。リフレクションで実行時に動的生成する方式と比べ、速度と静的検査の両面で有利になります。本稿では、この「コードを操作する」仕組みを、何を入力に取るかという観点から段階的に見ていきます。

テキスト置換マクロ：構文を知らない危うさ

最も素朴なのが、C言語の #define に代表されるテキスト置換型です。プリプロセッサがソースを字句（トークン）列として走査し、マクロ名を本体へ機械的に差し替えます。構文木を作る前、つまり言語の文法を理解する前の段階で動くため、置換は純粋に字面の操作になります。

この「構文を知らない」性質が、有名な落とし穴を生みます。

#define SQUARE(x) x * x

int r = SQUARE(1 + 2);   // 展開後: 1 + 2 * 1 + 2  →  5（期待は9）

SQUARE(1 + 2) は 1 + 2 * 1 + 2 へ素直に展開され、演算子の優先順位により 5 になります。プリプロセッサは x が式であることを知らず、優先順位の概念も持たないため、こうなります。本体を括弧で囲めば緩和できますが、引数の二重評価（SQUARE(i++) が i を2回進める）などの問題は括弧では消えません。根本原因は、テキスト置換が字句解析の手前で動き、構造を一切扱えないことにあります。

構文マクロ：ASTを入出力する

これを解決するのが構文マクロ（syntactic macro）です。テキストではなく、すでに構文解析を経た**抽象構文木（AST）**を入力に取り、変換後のASTを返します。Lispの defmacro、Rustの macro_rules! や手続きマクロがこの系統です。木を扱うので優先順位は構造として確定済みであり、SQUARE 問題のような優先順位崩れは原理的に起きません。

Lispが構文マクロの理想形に近いのは、コードとデータが同じ表現を共有する（homoiconicity, 同図像性）からです。Lispのソースは入れ子リストそのものであり、マクロは「リストを受け取りリストを返す関数」として、通常のリスト操作で書けます。

;; unless を if へ展開するマクロ
(defmacro unless (cond &rest body)
  `(if (not ,cond)
       (progn ,@body)))

(unless done (print "still working"))
;; 展開後: (if (not done) (progn (print "still working")))

バッククォート ` は「この木をそのまま雛形として作れ」、, は「ここだけ評価して値（部分木）を差し込め」を意味します。マクロの返り値は文字列ではなく木構造なので、後続のコンパイラはそれを通常のコードと区別なく扱えます。ASTを直接生成・変換する考え方はASTと中間表現の設計と地続きで、マクロは要するに「コンパイル経路の途中にユーザーが差し込む木変換パス」だと言えます。

衛生性（hygiene）：変数捕獲という落とし穴

構文マクロでも、なお厄介な問題が残ります。変数捕獲（variable capture）です。マクロが内部で一時変数を導入すると、それが呼び出し側の同名変数と偶然衝突し、意図しない束縛が起きることがあります。

;; swap を素朴に書くと…（非衛生的な擬似コード）
swap(a, b)  を  { tmp = a; a = b; b = tmp; }  へ展開するマクロ

呼び出し側:  tmp = 100;  swap(tmp, y);
展開後:      { tmp = tmp; tmp = y; y = tmp; }   ← 呼び出し側の tmp と衝突して破綻

マクロが導入した tmp と、呼び出し側の tmp が混ざってしまいました。これを自動で防ぐのが衛生的マクロ（hygienic macro）です。中核となる規則は2つです。第一に、マクロ展開で導入された識別子は、呼び出し側の識別子と決して衝突しない。第二に、マクロ本体が参照する自由変数は、定義時のスコープで解決される（呼び出し側のスコープに乗っ取られない）。

実現の鍵は、識別子に「どの展開で生まれたか」という**構文コンテキスト（色）**を付けて区別することです。同じ綴り tmp でも、マクロが生成したものと呼び出し側が書いたものは別の色を持ち、名前解決では別物として扱われます。これはラムダ計算におけるα変換（束縛変数の付け替えによる捕獲回避）を、構文変換の層へ持ち込んだものと理解できます。捕獲を避けるために束縛変数を一意な名前へ付け替える、という発想が共通しています。

テンプレートメタプログラミング：型を計算するコンパイル時計算

C++のテンプレートは、出自は異なるものの、結果的に強力なコンパイル時計算機構になりました。テンプレートはコンパイラが型や定数を引数に取って具体的なコードを実体化（instantiation）する仕組みで、その実体化規則の組み合わせがチューリング完全であることが知られています。つまり原理的には、コンパイル時に任意の計算を回せます。

// コンパイル時に階乗を計算する古典的テンプレート
template <int N>
struct Factorial { static constexpr int value = N * Factorial<N - 1>::value; };

template <>
struct Factorial<0> { static constexpr int value = 1; };

// Factorial<5>::value はコンパイル時に 120 へ確定する

ここで再帰の停止は、Factorial<0> の**特殊化（specialization）**が担います。実行時の if ではなく、テンプレートのパターンマッチで基底ケースを選ぶ点が特徴です。ただしこの手法は記述が冗長で、エラーメッセージも難解になりがちでした。そこで近代のC++は constexpr／consteval 関数を導入し、通常の関数構文のままコンパイル時評価を書けるようにしています。

マクロとリフレクションの違い

「コードを操作する」点で混同されがちですが、マクロとリフレクションは作用する時刻と対象が異なります。マクロは主にコンパイル時にコード（構文）を生成・変換します。リフレクションは多くの場合、すでにコンパイル済みのプログラムが実行時に自分自身の構造（型・メソッド・フィールド）を走査・操作する仕組みです。

両者はトレードオフの関係にあります。マクロは生成物が通常コードと同じく静的検査を通るため安全で高速ですが、書ける内容はコンパイル時に確定する範囲に限られます。リフレクションは実行時の動的な情報（外部から渡されたクラス名など）に基づける柔軟性がある反面、走査と動的ディスパッチのコストを払い、誤りが実行時まで露見しません。近年は両者の中間として、コンパイル時に型情報を走査するコンパイル時リフレクション（C++26で標準化が進む ^^ 演算子など）も登場し、リフレクションの柔軟さと静的検査・ゼロコストの両立が図られています。

まとめ

メタプログラミングの核は「コードを入力に取りコードを出力する」変換であり、その安全性は何を入力に取るかで決まります。テキスト置換は字句の手前で動くため優先順位崩れや二重評価を防げず、構文マクロはASTを直接扱うことでこれらを原理的に回避します。さらに衛生的マクロは、識別子に構文コンテキスト（色）を付けて変数捕獲を自動で防ぎ、ラムダ計算のα変換と同じ発想で健全性を保証します。C++テンプレートや constexpr／consteval はコンパイル時にチューリング完全な計算を実行し、生成コードを実行時ゼロコストに保ちます。一方リフレクションは実行時に型情報を走査する別系統の手法で、柔軟さと引き換えにコストと静的検査の弱さを抱えます。どの手法も「実行時コストを払わず抽象化する」ための道具ですが、デバッグ容易性とビルド時間という代償を理解したうえで選ぶことが、メタプログラミングを使いこなす鍵になります。