なぜあなたのCargoは「無実の罪」で全コンパイルを繰り返すのか？
Rust開発において、`build.rs`（ビルドスクリプト）は強力な武器ですが、同時に「大規模プロジェクトのビルドを破壊する爆弾」にもなり得ます。
多くのエンジニアが陥る罠は、`cargo:rerun-if-changed`の指定が広すぎることです。デフォルトの挙動や、不適切なパス指定により、「無関係なファイルの更新」をトリガーにして、巨大なクレートグラフ全体が再ビルドされる。この待ち時間は、開発者の集中力を削ぎ落とす最大の敵です。
本記事では、この「再コンパイルの連鎖」を断ち切り、ビルド時間を最小化するための高度な最適化戦略を伝授します。
—
1. 悲劇を招く「rerun-if-changed」の誤解
`build.rs`内で以下の記述を見たことはないでしょうか。
// 危険なアンチパターン
println!(“cargo:rerun-if-changed=.”);
これは「プロジェクト内の何かが変わったら再ビルドせよ」という命令です。`.git`ディレクトリ内のログ更新や、一時的な生成ファイル（`target`フォルダ内の一部など）まで監視対象となり、ビルドするたびにビルドがトリガーされるという地獄のようなループを生みます。
正しい戦略：ディレクトリではなく「意味のあるデータソース」を指定する
ディレクトリごと監視するのではなく、ビルドに必要な最小限のファイルのみを列挙してください。
fn main() {
// 依存関係を明示的に指定
println!(“cargo:rerun-if-changed=src/schema.sql”);
println!(“cargo:rerun-if-changed=proto/service.proto”);
println!(“cargo:rerun-if-changed=build.rs”); // スクリプト自体に変更があれば再実行
}
2. ビルドスクリプトの「静的解析」とキャッシュの分離
大規模プロジェクトでは、`build.rs`の中で重い処理（C++ライブラリのコンパイルや大規模なコード生成）を行うべきではありません。それを行うと、たとえRust側の変更がなくても、毎回その重い処理が走ります。
究極のテクニック：ビルド成果物のハッシュ化
`build.rs`の冒頭で入力ファイルのハッシュ値を計算し、前回のハッシュと比較して変更がある場合のみコンパイルを走らせるラッパー構造を構築します。
use std::fs;
use std::path::Path;
use sha2::{Sha256, Digest}; // 効率的なハッシュ計算のために導入
fn get_hash(path: &str) -> String {
let bytes = fs::read(path).unwrap();
format!(“{:x}”, Sha256::digest(&bytes))
}
fn main() {
let current_hash = get_hash(“data/config.json”);
let prev_hash_path = “target/build_hash.txt”;
if Path::new(prev_hash_path).exists() {
let prev_hash = fs::read_to_string(prev_hash_path).unwrap();
if current_hash == prev_hash {
// 変更なしなら再実行不要
return;
}
}
// ここで高コストな処理を実行
fs::write(prev_hash_path, current_hash).unwrap();
}
3. チーム開発を加速させる「神環境」の構築
個人の最適化だけでなく、チーム全員が同じ速度で開発できる環境を整えるのがテックリードの務めです。
`.cargo/config.toml` によるビルドの共有化
プロジェクトルートに以下の設定を配置し、コミットしてください。これにより、全員の環境で最適化オプションが強制されます。
.cargo/config.toml
[build]
リンカを高速化する設定（Moldを使用）
リンク時間が劇的に短縮されます。macOSならzld、Linuxならmoldを推奨
rustflags = [“-C”, “link-arg=-fuse-ld=mold”]
[profile.dev]
開発中のコンパイル時間を優先するための設定
incremental = true
opt-level = 0
debug = 1
推奨プラグイン：cargo-chef
Docker環境でのビルドを劇的に速くする[cargo-chef](https://github.com/LukeMathWalker/cargo-chef)は必須です。依存関係を別レイヤーとしてキャッシュすることで、コード変更時のDockerビルド時間が数分から数秒に短縮されます。
—
4. 現場のテックリードが教える「隠れたTips」
1. `cargo check` を `cargo build` の代わりに使う
- `cargo check`はコードの型チェックのみを行い、マシンコードを生成しません。IDE（rust-analyzer）の裏で走っているのもこれです。ビルドが通るか確認するだけなら、絶対に`build`を打ってはいけません。
2. `sccache` の導入
- CI/CD環境だけでなく、ローカルマシンでも`sccache`を動かしてください。以前ビルドしたオブジェクトファイルをクラウドストレージ（S3やGCS）経由で共有すれば、メンバーの一人がビルドした結果を別のメンバーが再利用できます。
3. キーボードショートカットの徹底
- VS Codeを使っているなら、`rust-analyzer.run`を `Ctrl + R` (または `Cmd + R`) にバインドし、「直近のテスト」を爆速で実行できるようにしてください。マウス操作はビルド時間のロスです。
最後に：アーキテクトからの提言
「ビルドが遅い」というのは、単なる技術的な課題ではなく、「開発者のフィードバックループが長すぎる」という経営リスクです。
`rerun-if-changed`を極めることは、単なる設定作業ではありません。あなたのチームが「コードを書いてから実行結果を見るまでの時間」を数秒単位で削り取り、思考の断絶を防ぐための投資です。
今日からあなたのプロジェクトの `build.rs` を見直し、不要な監視対象を削ぎ落としてください。その数秒の積み重ねが、半年後のプロダクトの品質と、エンジニアのモチベーションを決定的に変えるはずです。