Cargo Resolver “2” の深淵：依存関係の「フィーチャー汚染」を根絶し、ビルドグラフを支配する
RustのビルドシステムであるCargoは、単なるパッケージマネージャではない。それは、依存関係という名の「静的リンクの迷宮」を解くための制約充足ソルバーである。
かつて、多くのシニアエンジニアを悩ませてきた「フィーチャーの統合問題（Feature Unification）」は、ある種の不可避なコストと見なされてきた。しかし、`resolver = “2”` の登場により、そのパラダイムは崩壊した。本稿では、このリゾルバーが何を変え、我々がどのようにしてCI/CDパイプラインからビルドの決定論的制御を奪還するかを説く。
—
1. なぜ「Resolver 2」は革命的なのか
従来の「Resolver 1」は、依存グラフ全体で特定のクレートが持つフィーチャーフラグを「単一のグローバルセット」に統合しようとした。これが何を引き起こすか？ 依存先Aが `log` クレートの `std` を要求し、依存先Bが同じ `log` クレートを `no_std` で要求した場合、Cargoはこれらを強制的に結合し、どちらかに合わせる必要があった。結果として、意図しないコンパイルエラーや、不要なコードの肥大化を招いていた。
`resolver = “2”` は、この制約を「ターゲット依存（target-dependency）」と「開発依存（dev-dependency）」、そして「通常依存」という文脈で分離する。これにより、テスト実行時のみ必要なフィーチャーや、特定のプラットフォームでのみ必要な機能を、依存グラフ内でクリーンに隔離できるようになった。
—
2. 現場で直面する「フィーチャー干渉」の外科的処置
実務で最も厄介なのは、推移的依存（transitive dependencies）による「意図しない機能の有効化」だ。これに対し、`resolver = “2”` と `[target.’cfg(…)’.dependencies]` を組み合わせることで、ビルドの純度を保てる。
実践：フィーチャーの隔離戦略
以下の設定は、特定の環境下でのみコンパイルされるクレートに、限定的なフィーチャーを適用する例である。
[package]
name = “enterprise-core”
version = “0.1.0”
edition = “2021”
ここでリゾルバーのバージョンを指定することで、
依存グラフの構築ロジックを最新の最適化済みアルゴリズムへ切り替える
resolver = “2”
[dependencies]
共通依存。resolver 2ではフィーチャーの統合がより賢く行われる
serde = { version = “1.0”, features = [“derive”] }
特定のターゲット環境でのみ追加フィーチャーを有効化し、
メインのグラフへの「フィーチャー汚染」を完全に防ぐ
[target.’cfg(target_os = “linux”)’.dependencies]
tokio = { version = “1.0”, features = [“rt-multi-thread”] }
[target.’cfg(target_os = “windows”)’.dependencies]
tokio = { version = “1.0”, features = [“rt”] }
この設定により、`cargo build –target x86_64-unknown-linux-gnu` を実行した際、CargoはWindows用のフィーチャーセットをグラフ構築の計算から完全に除外する。メモリ消費量の削減だけでなく、コンパイルキャッシュの効率も飛躍的に向上する。
—
3. CI/CDパイプラインへの統合：決定論的ビルドの強制
CI/CDにおいて「環境によってビルド結果が微妙に異なる」という事態は、DevOpsの敗北を意味する。`resolver = “2”` を活用し、ビルドの再現性を担保する最強の運用フローを提示する。
Dockerマルチステージビルドでの最適化
Docker内でビルドを行う際、`Cargo.lock` と `resolver = “2”` の組み合わせは、コンパイル時間の短縮に直結する。
ビルドキャッシュを最大限に活用するためのレイヤー設計
FROM rust:1.75-slim AS builder
WORKDIR /app
依存関係のみを先にビルドし、キャッシュを有効化
COPY Cargo.toml Cargo.lock ./
ダミーのmain.rsを作成して依存関係だけをコンパイル
RUN mkdir src && echo ‘fn main() {}’ > src/main.rs && cargo build –release
ソースコードをコピーして本番ビルド
COPY . .
RUN touch src/main.rs && cargo build –release
ここで重要なのは、`resolver = “2”` があれば、依存グラフが最小化されるため、`cargo build` の各ステップで無駄なクレートの再コンパイルが発生しにくい点だ。
—
4. エキスパート向けハック：ビルドグラフの可視化と解析
内部で何が起きているかを知ることは、アーキテクトの矜持である。依存関係が複雑すぎて「なぜそのフィーチャーが有効になっているのか」不明な場合、以下のコマンドでグラフをダンプせよ。
依存グラフをDOT形式で出力し、Graphvizで解析する
cargo tree –format “{p} {f}” –target x86_64-unknown-linux-gnu > graph.dot
特定のフィーチャーがどこから注入されているか追跡する
cargo tree -e features -i
このコマンドをCIパイプラインのポストプロセスに組み込み、「意図しないフィーチャーが有効化された場合にビルドを異常終了させる」スクリプトを書くのが、プロの防御策だ。
自動検証スクリプトの例（CI用）
import subprocess
def verify_no_unwanted_features():
# 特定のクレートで禁止したフィーチャーが有効になっていないかチェック
cmd = [“cargo”, “tree”, “–target”, “x86_64-unknown-linux-gnu”, “-i”, “tokio”]
result = subprocess.run(cmd, capture_output=True, text=True)
if “unwanted-feature” in result.stdout:
print(“!! 依存関係の汚染を検知しました !!”)
exit(1)
verify_no_unwanted_features()
—
結びに：ビルドという名の「計算コスト」を支配せよ
Cargoの `resolver = “2”` を採用することは、単なる設定変更ではない。それは、複雑な依存関係というカオスを、コンパイラの最適化ロジックの中に正しくマッピングするための知的規律である。
依存関係の競合に頭を抱える時間は、エンジニアにとって最も非生産的な時間だ。リゾルバーを掌握し、ビルドグラフを構造化し、CIパイプラインを「再現可能な真理」へと昇華させろ。それこそが、このツールを骨の髄まで使い倒すということに他ならない。
さあ、今すぐ `Cargo.toml` を開き、リゾルバーを「2」に書き換えることから始めよう。その先に、かつてないほどクリーンで高速なビルドの世界が待っている。