Rustバイナリの「極限ダイエット」：バイナリサイズを極小化し、実行速度を落とさない究極のビルド戦略
Rustのバイナリが肥大化するのは、言語のせいではない。コンパイラの親切心、そして我々エンジニアの「怠慢」が原因だ。
プロダクション環境において、数メガバイトの差は単なるディスク容量の問題ではない。コンテナのPull速度、コールドスタートの遅延、そしてキャッシュ効率（L1/L2/L3）に直結する。本稿では、Rustツールチェーンを極限まで使い倒し、バイナリサイズを削ぎ落とすための「アーキテクトの深淵」を共有する。
—
1. `opt-level = “z”` の真実と罠
多くのエンジニアが `opt-level = 3` を選択するが、サイズ制限が最優先の環境（Lambda, Edge Compute等）では `opt-level = “z”` が解となる。
なぜ “z” なのか？
`”s”` は「速度を維持しつつサイズを減らす」が、`”z”` は「速度へのペナルティを許容してでもサイズを最小化する」という強い意思表示だ。LLVMの最適化パスにおいて、インライン展開を極限まで抑制し、コードの重複を排除する。
`Cargo.toml` の最適解:
[profile.release]
サイズ削減の要：速度よりもサイズを優先する
opt-level = “z”
リンク時の最適化を有効化：バイナリ全体を解析し不要なコードを削除
lto = true
コード生成の並列化を1に固定：最適化の網を全体に広げる
codegen-units = 1
パニック時の挙動を軽量化：スタックトレースを捨て、abortする
panic = “abort”
不要なシンボルをリンク時に除外
strip = “symbols”
—
2. 隠されたコスト：シンボルとデバッグ情報
Rustのデフォルト設定では、バイナリにデバッグ情報（DWARF）が含まれる。これは素晴らしい機能だが、配布物には不要だ。`strip` 設定は、ビルド後に外部ツールを叩く手間を省く「最後の砦」である。
なぜ `strip = “symbols”` なのか？
バイナリからシンボルテーブルを削除しても、`.debug_info` セクションが残る場合がある。`cargo` の `strip` オプションは、プラットフォーム固有のストリップツール（`strip`や`dsymutil`）を自動的に呼び出す。
もし、さらに過激にやるなら、CI/CD上で以下の処理をパイプラインに組み込むべきだ。
バイナリのセクションをさらに削ぎ落とす（GNU strip使用時）
–strip-all: シンボルと再配置情報をすべて削除
–remove-section=.comment: コンパイラのバージョン情報など不要なメタデータを削除
strip –strip-all –remove-section=.comment –remove-section=.note ./target/release/my-app
—
3. 開発スピードを劇的に加速させる「神プラグイン」と設定
毎日 `cargo build` を繰り返すのは非効率だ。以下の環境設定で、脳の負荷を下げろ。
神プラグイン: `cargo-chef`
CI/CDにおけるビルド時間の9割は「依存関係のコンパイル」だ。`cargo-chef` は、ソースコードと依存関係の依存グラフを計算し、Dockerのレイヤーキャッシュを極限まで活かす。
依存関係のみをビルドするレイヤーを分離
RUN cargo chef cook –release –recipe-path recipe.json
チーム開発の共有化ルール: `.cargo/config.toml`
個人の好みを排除せよ。プロジェクトルートの `.cargo/config.toml` に以下の設定を入れ、全メンバーのビルド環境を統一する。
[build]
全員が同じ最適化設定を強制される
rustflags = [“-C”, “target-cpu=native”]
[target.x86_64-unknown-linux-musl]
静的リンクを強制し、ポータビリティを担保
rustflags = [“-C”, “link-arg=-s”]
—
4. アーキテクトの視点：バイナリを削るプロの思考回路
バイナリサイズを本気で削るなら、ツールチェーンの外側に目を向ける必要がある。
1. `wasm-opt` の活用: もしWebAssemblyをターゲットにしているなら、`wasm-opt -O4` を通さずにリリースしてはならない。これは単なる最適化ではなく、Wasmのバイナリ形式に対する「再圧縮」だ。
2. `bloat` で可視化せよ: 勘で最適化するな。`cargo-bloat` を使い、どのクレートが肥大化の原因か特定せよ。
# どの関数がサイズを食っているかランキング形式で表示
cargo bloat –release –crates
3. パニックの制御: `panic = “abort”` を使用する場合、`std` のパニックハンドリングコードがバイナリからごっそり消える。ただし、エラーハンドリングは `Result` で厳密に行う必要がある。これはRustの設計思想に合致する「安全で軽量な開発」の極みだ。
結論：サイズは「品質」である
バイナリが小さいことは、実行時のメモリ占有率が低いことと同義だ。そして、メモリ効率の良さは、キャッシュミスを減らし、結果として実行速度の向上をもたらす。
「最適化レベル `z`」と「徹底的なシンボル削除」は、単なる容量削減のテクニックではない。あなたのプロダクトが、クラウド上の限られたリソースでいかに「高潔に」振る舞うかを示す、エンジニアとしての矜持である。
今すぐ `Cargo.toml` を開き、不要な肥満を取り除く設定を書き込め。その数バイトの削減が、数ヶ月後のシステム負荷を劇的に下げているはずだ。