はじめに：PHPのDI設定における「文字列地獄」からの脱却
SymfonyやLaravelといったモダンなPHPフレームワークにおいて、DI（依存性注入）コンテナはアプリケーションの骨格を成す。しかし、実務の現場でこんなストレスを感じたことはないだろうか。
- 「サービスクラスのリファクタリングに伴い、YAMLやXML、あるいはPHPの配列設定（`services.yaml`など）のクラス名やメソッド名を書き換える羽目になった」
- 「タイポや存在しないクラスの指定が、コンパイル時（ビルド時）ではなく、本番環境でのリクエスト到達時（実行時）の致命的な例外として発覚した」
動的言語であるPHPの限界に起因するこの「文字列による結びつき」は、大規模開発において常にTECHNICAL DEBT（技術的負債）の温床となる。
ここでHaxeの出番だ。Haxeの圧倒的な静的型付けシステムと、ビルド時にコードの抽象構文木（AST）を自在に操るマクロシステムを組み合わせれば、PHPのDI設定ファイルを「完全な型安全性」のもとで自動生成するパイプラインを構築できる。
今回は、Haxeのコードベースをソースオブトゥルース（真実の情報源）とし、コンパイル時にクラス構造をスキャンしてSymfony/Laravel互換のDI設定ファイルを自動生成する、プロダクション品質のアーキテクチャを伝授する。
—
全体アーキテクチャ：Haxeマクロによるコンパイル時コード解析
今回のパイプラインの設計思想は極めてシンプルだ。
1. Haxe側でコンポーネントを定義する：通常のHaxeクラスに特定のメタデータ（ `@:injectable` など）を付与する。
2. マクロでASTを走査する：Haxeのコンパイルプロセス（`macro`フェーズ）において、プロジェクト内の全型情報を走査し、依存関係（コンストラクタインジェクションの型）を解析する。
3. 設定ファイルを吐き出す：解析結果を元に、PHP側が読み込める設定ファイル（例: JSONやPHP配列ファイル）をビルド成果物として生成する。
これにより、Haxe側で型エラー（クラス名の変更や引数のミスマッチ）があれば、PHPへトランスパイルされる前のHaxeのコンパイル段階で必ず検知されるようになる。
—
実装コード：プロダクション・グレードのDIパイプライン
では、実際のコードを見ていこう。コピペでそのまま実務のビルドプロセスに組み込める設計としている。
1. 依存性注入をマークするメタデータとインターフェース
まずは、Haxe側でDI対象のクラスを識別するためのアノテーションを定義する。
package di;
/
- DIコンテナに登録すべきクラスであることを示すメタデータ
/
@:autoBuild(di.DiMacro.build())
interface Injectable {}
`@:autoBuild`を使うことで、このインターフェースを実装（あるいは継承）したすべてのクラスに対して、自動的にマクロがフックされる。
2. マクロビルダー：型情報の抽出とDI設定の自動生成
次に、コンパイル時にASTを解析し、依存関係ツリーを構築してPHP用の設定ファイルを書き出すマクロの実装だ。
package di;
if macro
import haxe.macro.Context;
import haxe.macro.Expr;
import haxe.macro.Type;
import sys.io.File;
import sys.FileSystem;
using haxe.StringTools;
endif
class DiMacro {
// 依存関係を蓄積する静的バッファ
private static var containerRegistry:Map
macro public static function build():Array
var cls = Context.getLocalClass().get();
var className = cls.pack.concat([cls.name]).join(“.”);
// 抽象クラスやインターフェース自体はスキップ
if (!cls.isInterface && !cls.isExtern) {
var dependencies:Array
// コンストラクタを走査して依存する型（引数）を特定する
if (cls.constructor != null) {
var ctor = cls.constructor.get();
switch (ctor.type) {
case TFun(args, _):
for (arg in args) {
switch (arg.t.follow()) {
case TInst(tRef, _):
var depClass = tRef.get().pack.concat([tRef.get().name]).join(“.”);
dependencies.push(depClass);
default:
// プリミティブ型や複雑な型はここでは一旦スキップ（必要に応じて拡張）
}
}
default:
}
}
containerRegistry.set(className, dependencies);
}
// 最終的な出力フェーズをフックする（全コンパイル完了時に一度だけ実行）
Context.onGenerate(function(types) {
generatePhpDiConfig();
});
return Context.getBuildFields();
}
private static function generatePhpDiConfig():Void {
var phpConfigCode = “ function(\$container) {\n’;
phpConfigCode += ‘ return new ${phpClassName}(\n’;
for (dep in deps) {
var phpDepName = “\\” + dep.split(“.”).join(“\\”);
phpConfigCode += ‘ \$container->get(${phpDepName}::class),\n’;
}
phpConfigCode += ” );\n”;
phpConfigCode += ” },\n”;
}
phpConfigCode += “];\n”;
// 出力先ディレクトリの確保と書き出し
var outputDir = “dist/config”;
if (!FileSystem.exists(outputDir)) {
FileSystem.createDirectory(outputDir);
}
File.saveContent(outputDir + “/di_container.php”, phpConfigCode);
// 開発者へのフィードバック
Sys.println(“[Haxe DI Macro] Successfully generated PHP DI container config.”);
}
}
3. アプリケーション層での利用例
ビジネスロジックを担うサービスクラス群をHaxeで記述する。
package services;
import di.Injectable;
class Logger implements Injectable {
public function new() {}
public function log(message:String):Void {
Sys.println(“[LOG] ” + message);
}
}
class UserService implements Injectable {
private var logger:Logger;
// コンストラクタインジェクション：依存関係がマクロによって完全に追跡される
public function new(logger:Logger) {
this.logger = logger;
}
public function registerUser(username:String):Void {
logger.log(‘User registered: $username’);
}
}
このコードをHaxeのPHPターゲットとしてコンパイルすると、`dist/config/di_container.php` に以下の様なPHPのネイティブなDI設定が自動生成される。
/
return [
\services\Logger::class => function($container) {
return new \services\Logger(
);
},
\services\UserService::class => function($container) {
return new \services\UserService(
$container->get(\services\Logger::class),
);
},
];
—
テクニカルリードからの実践的アドバイス：パフォーマンスと設計の罠
このアプローチを実務のプロダクション環境に導入する際、シニアエンジニアとして知っておくべき「落とし穴」と最適化の知見を共有する。
1. インクリメンタルビルド（キャッシュ）との闘い
Haxeは高速なコンパイルを誇るが、マクロ内でファイルシステムへ直接書き込み（`File.saveContent`）を行う場合、Haxeのコンパイラキャッシュ機能（`–times`やIDE連携時のバックグラウンドコンパイル）と競合し、ビルドキャッシュが無効化される原因になる。
- 対策: `Context.onGenerate` は最終成果物の生成時に1度だけ走るため適切だが、不要なファイルI/Oを防ぐために、生成される文字列のハッシュを比較し、変更がない場合はディスクへの書き込みをスキップするガード節を入れると、ビルドパイプラインの速度が劇的に向上する。
2. 循環参照（Circular Dependency）の検知
コンストラクタインジェクションにおいて、クラスAがクラスBを求め、クラスBがクラスAを求めるような循環参照が発生した場合、上記のシンプルなマクロでは無限ループにはならないものの、生成されたPHP側で実行時エラー（あるいはメモリ枯渇）を引き起こす。
- 対策: マクロのAST走査時に、有向グラフの閉路検出（Tarjanのアルゴリズムなど）を実装し、循環依存が見つかった時点で `Context.error(“Circular dependency detected”, pos)` を呼び出してコンパイルを意図的に失敗させるべきである。これこそが「実行時エラーをコンパイル時エラーに置き換える」Haxeの本領発揮である。
3. インターフェースと具象クラスのバインディング
実際のDIでは、「インターフェースを指定して、具体的な実装クラスを注入する（例: `IUserRepository` に対して `MySqlUserRepository` をバインディング）」という要件が多々発生する。
- 対策: Haxeのメタデータに引数を持たせ、`@:inject(services.MySqlUserRepository)` のように指定できるようにマクロを拡張せよ。メタデータパーサーの実装により、フレームワーク固有の複雑なバインディングルールもHaxeの型システムの範疇に完全に収めることが可能になる。
—
結びにかえて：HaxeでPHP開発を「モダン」に再定義する
PHPは柔軟で素晴らしい言語だが、大規模なエンタープライズ領域においては、その動的な性質ゆえの「変更に対する脆弱性」が常に付きまとう。
Haxeのマクロシステムを使いこなせば、PHPというランタイムの制約をエレガントにハックし、「Haxeで堅牢に書き、PHPとして高速に動かす」という最強のハイブリッド開発環境が手に入る。文字列のタイポにおびえる日々は、今日で終わりにしよう。あなたのコードベースに真の型安全をもたらすのは、他でもない、あなた自身のアーキテクチャ設計だ。