Zig言語、パッケージ管理をコンパイラから独立—ビルドシステムへ移行

コンパイラとビルドシステムの役割を明確に分離

Zig言語の作者Andrew Kelley氏は、2026年6月30日にこの大きなアーキテクチャ変更を発表しました。（出典）

従来、Zig言語のコンパイラは zig build、zig fetch、zig init、zig libc といったパッケージ管理関連のサブコマンドを担当していました。今回の変更により、これらの機能が 「maker」と呼ばれるビルドシステムプロセスに移行 されました。

パッケージ管理機能を独立させることで、その機能を再コンパイルなしでパッチ適用できるようになります。

これに伴い、以下のコンポーネントがコンパイラからビルドシステムに移行しました：

• パッケージ取得ロジック
• HTTPクライアント・ネットワーク機能
• TLS（トランスポートレイヤーセキュリティ）と関連する暗号化処理
• Gitプロトコル対応
• 複数の圧縮フォーマット対応（xz、gzip、zstd、flate、zip）
• build.zig.zonファイルのパース・検証

プロセス階層構造の最適化がもたらす利点

この変更の背景には、プロセス構造の最適化があります。従来は以下のような階層でした：

zig build（コンパイラ＋パッケージマネージャー）
└─ builder（ユーザーのbuild.zig ロジック＋ビルドシステム）

それが、2024年のプロセス分離により以下のように変わり：

zig build（コンパイラ＋パッケージマネージャー）
├─ configurer（ユーザーのbuild.zig ロジック）
└─ maker（ビルドシステム）

そして今回、さらに最適化されました：

zig build（コンパイラ）
└─ maker（ビルドシステム＋パッケージマネージャー）
   └─ configurer（ユーザーのbuild.zig ロジック）

makerがparentプロセスになることで、設定の変更時にサーバプロセスが終了・再接続する必要がなくなります。

この構造の利点は、zig build --watch など長時間実行されるプロセスで顕著です。build.zig が変更された場合、configurer プロセスだけを再実行し、maker は生存したままいられるため、より効率的に再構築できるようになります。

個人的には、このようなプロセス設計の最適化は、大規模なビルドシステムの動きを観察していく上で非常に興味深いですね。ZLS（Zigのランゲージサーバー）のようなツールの利便性向上にも直結する改善です。

セキュリティと性能向上の副作用

この変更には想定外のメリットも生まれました。

maker 実行ファイルは ReleaseSafe モード でコンパイルされるため、ネットワーク処理時にセキュリティチェックが有効になります。さらに、ネットワークやファイルハッシュに使用される暗号化処理が、ホスト特有の特殊 CPU 命令を活用できるようになりました。

Kelley氏は「AOT（事前コンパイル）とJIT（実行時コンパイル）の両方を手に入れられた」と表現していますが、これは CPU 拡張命令（例：AES-NI など）の恩恵を受けながら、同時に配布環境との互換性を保てるという意味です。

こうした最適化は、とくにローカルLLMやStable Diffusionを動かすときのビルド時間短縮など、開発環境における体感速度に影響してきます。

後方互換性と今後のロードマップ

この変更は ほぼ破壊的変更ではない とされていますが、いくつかの観測可能な差分があります：

• --maker-optflag フラグが ZIG_DEBUG_MAKER 環境変数に置き換わり
• --zig-lib-dir フラグが ZIG_LIB_DIR 環境変数に置き換わり

Zig 0.17.0 のリリースに向け、以下の項目がブロッカーとなっています：

• ビルドサーバープロトコル MVP（ZLS のブロック解除に必要）
• ビルドスクリプト自体のパス依存関係の導入
• zig build --watch で build.zig の変更を検出し自動実行
• カレントディレクトリの違いによるビルドスクリプトキャッシュミスの解決

Kelley氏は 7 月に学会発表を控えているため、これらの実装は 8 月初頭までずれ込む見通しを示しています。

読者へのメッセージ

Zig を愛用している開発者の方であれば、このプロセス構造の改善によって、ビルド時間の短縮やパッケージ管理の柔軟性向上の恩恵を受けることになります。環境変数の仕様変更には注意が必要ですが、スクリプトの更新は簡単なはずです。