Cargoワークスペースの「依存地獄」を解体する：resolver = “2” と一元管理によるビルド・アーキテクチャの極致
Rustのプロジェクトが成長し、ワークスペース内のクレート数が数十〜数百に達したとき、多くのエンジニアが直面する壁がある。それは「依存関係の不整合」と「無駄なコンパイル時間」だ。
個別の`Cargo.toml`で依存を管理し、バージョンが微妙にズレた結果、同じライブラリが何度もコンパイルされ、リンク時に重複が発生する。これが現代のRust開発における最大のボトルネックの一つだ。本稿では、`resolver = “2”`と`[workspace.dependencies]`を駆使し、Cargoの内部挙動を制御下に置く「真のモジュールアーキテクチャ」について解説する。
—
1. resolver = “2” の深層：なぜ「依存グラフの衝突」が消えるのか
Cargoのデフォルト解決アルゴリズム（バージョン1）は、歴史的な経緯から、フィーチャーフラグが異なる場合に同一依存関係を別個のターゲットとしてビルドする傾向があった。これが「依存関係の爆発」を引き起こす。
`resolver = “2”`を指定すると、Cargoは以下の挙動をとる。
- 機能の合体: 異なるクレートが同一の依存関係に対して異なるフィーチャーを要求した場合、それらを自動的にユニオン（和集合）として統合する。
- 無駄な再コンパイルの排除: 依存グラフが最適化されるため、同一ライブラリが異なるビルド設定で何度もコンパイルされることがなくなる。
実装：ルートのCargo.tomlを制する
[workspace]
members = [“crates/”]
【重要】バージョン2の解像度アルゴリズムを採用し、依存グラフを極限までフラット化する
resolver = “2”
[workspace.dependencies]
ここで依存関係のバージョンを一元定義する。各サブクレートからはこのエイリアスを参照させる。
tokio = { version = “1.36”, features = [“full”] }
serde = { version = “1.0”, features = [“derive”] }
tracing = “0.1”
この設定により、サブクレート側では `tokio = { workspace = true }` と書くだけで済む。バージョン管理は一点に集約され、開発者が「どのバージョンを使っているか」を気にするコストがゼロになる。
—
2. CI/CDパイプラインへの最適化：DockerとCargoのレイヤーキャッシュ戦略
大規模プロジェクトにおいて、毎回のCIで依存関係を全て再ビルドするのは時間の浪費だ。`workspace`の構成を活かし、Dockerレイヤーキャッシュを最大化する戦略をとる。
ステージングされたDockerfileの構成術
1. 依存関係のインデックスだけをコピーし、空のダミービルドを行う
これにより、ソースコードを変更しても依存関係のキャッシュが壊れない
COPY Cargo.toml Cargo.lock ./
COPY crates/ ./crates/
ダミーのメインファイルを作成してビルドを通す
RUN mkdir -p src && echo ‘fn main() {}’ > src/main.rs && cargo build –release
2. 本番ソースをコピーしてビルド（依存関係はすでにキャッシュ済み）
COPY src/ ./src/
RUN cargo build –release
アーキテクトの知見:
単に`cargo build`を叩くのではなく、`cargo-chef`のようなツールを組み込み、依存関係のロックファイルから生成される`recipe.json`を利用するのがベストだ。これにより、プロジェクトの構造が変わらない限り、依存関係のコンパイル結果は永久に保存される。
—
3. 自動化スクリプト：依存関係の「ドリフト」を許さない
`workspace.dependencies`を使っていても、誰かが誤ってサブクレート側で`version = “x.y.z”`とハードコードしてしまうことはある。これをCIで検知し、強制的に修正させる自動化スクリプトを導入する。
!/bin/bash
【自動化】サブクレートのCargo.tomlを監視し、workspace=trueになっていない依存を検知する
jqを利用してCargo.tomlのJSONパースを行い、整合性をチェックする
for crate in crates/; do
if [ -f “$crate/Cargo.toml” ]; then
# 依存関係の中に version が直接記述されているものを抽出
bad_deps=$(cargo metadata –no-deps –format-version 1 | \
jq -r ‘.packages[] | select(.manifest_path | contains(“‘”$crate”‘”)) | .dependencies[] | select(.source == null and .req != null)’)
if [ ! -z “$bad_deps” ]; then
echo “警告: $crate に非推奨の依存記述があります。workspace.dependencies を使用してください。”
exit 1
fi
fi
done
—
4. パフォーマンスの深淵：メモリ消費とリンクタイムの最適化
Rustのビルド速度は「リンク」で決まることが多い。`resolver = “2”`でコンパイル単位が整理されると、最終的なリンク対象となるオブジェクトファイルの数も減る。
さらに、CIのメモリ消費を抑えるために以下の`config.toml`を適用せよ。
.cargo/config.toml
[build]
並列コンパイル数を制限し、CI環境のOOM（メモリ不足）を防ぐ
jobs = 4
[profile.dev]
開発中はデバッグ情報を減らして高速化
debug = 0
[profile.release]
リンクタイム最適化を有効化し、生成されるバイナリの実行速度を最大化する
lto = “fat”
codegen-units = 1
—
結論：アーキテクチャの「静かなる革命」
`workspace.dependencies`と`resolver = “2”`の導入は、単なる設定変更ではない。それは、「依存関係という複雑なグラフを、単一の決定論的な状態に固定する」という設計思想の転換である。
このアーキテクチャを採用したチームは、依存関係の不整合によるビルドエラーから解放され、CIの時間は劇的に短縮され、コードレビューでは「依存関係のバージョン」ではなく「ビジネスロジック」に集中できるようになる。
伝説的なエンジニアを目指す諸君、ツールに振り回されるな。ツールの内部挙動を掌握し、自分の開発フローを「設計」せよ。これこそが、最高峰のDevOpsの真髄である。