Rustでの開発において、パッケージマネージャーであるCargoは欠かせない存在です。
プロジェクトを作成すると、必ずと言っていいほどCargo.tomlとCargo.lockという2つのファイルを目にすることになります。
初心者の方にとって、これら2つのファイルがどのように使い分けられ、どのような役割を担っているのかを正確に把握することは非常に重要です。
特にチーム開発やCI/CD環境において、ビルドの再現性を担保する鍵となるのがCargo.lockです。
本記事では、2026年現在のRust開発におけるCargo.lockの役割から、Git管理の最新ベストプラクティスまでを詳しく解説します。
Cargo.lockの基本的な役割と仕組み
Cargo.lockの最も重要な役割は、プロジェクトが依存するすべてのクレートの「正確なバージョン」を固定することにあります。
Rustのプロジェクトでは、直接的な依存関係だけでなく、それらが依存している間接的なライブラリ (依存の依存) が膨大になることが珍しくありません。
もし、開発者の環境によってこれらのバージョンが異なってしまうと、「自分の環境では動くが、他の人の環境ではコンパイルエラーになる」といった問題が発生します。
Cargo.lockは、初めてビルドした際や依存関係を更新した際の正確なスナップショットを保存します。
これにより、誰がいつどこでビルドしても、全く同じソースコードの組み合わせでバイナリを生成することが可能になります。
セマンティックバージョニングと再現性
Rustのクレートは通常、セマンティックバージョニング (SemVer) に基づいて管理されています。
しかし、SemVerに従っていても、マイナーアップデートやパッチアップデートによって挙動が微妙に変化する可能性はゼロではありません。
Cargo.lockが存在することで、意図しないアップデートが勝手に適用されるのを防ぐことができます。
Cargo.lockが生成されるタイミング
Cargo.lockは、開発者が手動で作成するファイルではありません。
cargo build や cargo run、あるいは cargo check を実行した際に、Cargoが自動的に生成または更新を行います。
Cargoは Cargo.toml の定義を読み取り、依存関係グラフを解決した結果を Cargo.lock に書き出します。
Cargo.tomlとCargo.lockの決定的な違い
これら2つのファイルはどちらも依存関係を管理するものですが、その性質は対照的です。
一言で言えば、Cargo.tomlは「開発者の意図」を記述する場所であり、Cargo.lockは「計算された結果」を記録する場所です。
Cargo.toml：開発者が管理する設定ファイル
Cargo.tomlには、プロジェクトの名前、ライセンス、そして「どのライブラリのどのバージョン範囲を使いたいか」を記述します。
例えば、serde = "1.0" と記述した場合、それは「1.0.0以上、2.0.0未満の最新版を使ってほしい」という指示になります。
Cargo.lock：Cargoが管理するロックファイル
一方でCargo.lockには、実際に解決された serde = "1.0.210" といった具体的なバージョン番号と、そのソースのハッシュ値が記録されます。
以下に、両者の違いを表形式でまとめました。
| 項目 | Cargo.toml | Cargo.lock |
|---|---|---|
| 役割 | 依存関係の定義・プロジェクト設定 | 解決された依存関係の固定 (ロック) |
| 編集者 | 主に開発者が手動で編集する | Cargoが自動で生成・編集する |
| バージョンの指定 | 範囲指定 (例: “1.0”) が一般的 | 厳密な固定値 (例: “1.0.210”) |
| 依存の深さ | 直接の依存関係のみを記述 | 間接的な依存関係もすべて網羅 |
コード例で見る依存関係の記述
まずは、開発者が編集する Cargo.toml の例を見てみましょう。
# Cargo.toml の例
[package]
name = "my_rust_project"
version = "0.1.0"
edition = "2021"
[dependencies]
# バージョン1.0系であれば許容するという指定
serde = "1.0"次に、Cargoが自動生成する Cargo.lock の内容の一部を見てみます。
# Cargo.lock の例 (一部抜粋)
[[package]]
name = "serde"
version = "1.0.210"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "c8e3592472072e6e2415a14d750459581575b9d27a12650058b547f899df9ad6"このように、Cargo.lockには checksum が含まれており、サプライチェーン攻撃のリスクを軽減する役割も果たしています。
Git管理のベストプラクティス
「Cargo.lockをGitのリポジトリに含めるべきかどうか」という問いは、Rustコミュニティで長年議論されてきました。
2026年現在、一般的な推奨事項はプロジェクトの種類によって明確に分かれています。
バイナリ・アプリケーションプロジェクトの場合
CLIツール、Webサーバー、GUIアプリなどの実行可能なバイナリプロジェクトでは、必ずCargo.lockをGitにコミットしてください。
これには明確な理由があります。
開発チーム全員が同じバージョンのライブラリを使って開発を行うためです。
また、CI/CDパイプラインにおいて、テストが行われた環境と本番環境にデプロイされるバイナリが同一であることを保証するためでもあります。
ライブラリプロジェクトの場合
一方で、他のプロジェクトから利用されるライブラリ (クレート) の開発では、歴史的にCargo.lockを無視 (gitignore) するのが一般的でした。
ライブラリの利用者がどのバージョンの依存関係を使うかは、最終的なアプリケーション側の Cargo.lock で決定されるからです。
しかし、最近のベストプラクティスでは、ライブラリであっても Cargo.lock をコミットすることが推奨されるケースが増えています。
その理由は、ライブラリのCI環境において「依存関係の最新版でビルドが壊れていないか」を確認しつつ、一方で「開発者が意図した最小構成で動作するか」を確認する再現性が必要だからです。
Rust公式のドキュメントでも、現在は「すべてのプロジェクトで Cargo.lock をコミットしても良い」というスタンスに傾いています。
CI/CDでの活用
CI環境では、cargo build --locked というフラグを使用するのが一般的です。
このフラグを付けると、Cargo.lock の更新が必要な場合にビルドをエラーにしてくれます。
これにより、「ローカルで Cargo.toml を書き換えたのに Cargo.lock を更新し忘れた」というミスを検知できます。
Cargo.lockを操作するためのコマンド
通常、Cargo.lockを直接テキストエディタで編集することはありません。
依存関係を更新したい場合は、Cargoが提供するコマンドを利用します。
cargo update：最新版への更新
cargo update コマンドを実行すると、Cargo.toml で許可されている範囲内で、すべての依存パッケージを最新バージョンに更新し、Cargo.lock を書き換えます。
// 特定のパッケージだけを更新する場合
cargo update -p serdeこのコマンドを実行した後は、必ずテストを行い、新しいバージョンで不具合が発生していないかを確認する必要があります。
cargo generate-lockfile：ビルドせずにロックファイルを作成
ビルドを行わずに Cargo.lock だけを最新の状態に更新、あるいは生成したい場合に利用します。
競合 (Merge Conflict) の解決法
チーム開発で複数のメンバーが依存関係を追加すると、Cargo.lock でコンフリクトが発生することがあります。
Cargo.lock は機械的なファイルであるため、手動でマージするのは非常に困難です。
このような場合は、一旦 Cargo.lock の競合を無視して、再度 cargo fetch や cargo build を実行することで、Cargoが自動的に正しい整合性を保った状態に再生成してくれます。
セキュリティと整合性の維持
Rustの強力なエコシステムを支えているのが、Cargo.lock による整合性チェックです。
各パッケージにはハッシュ値 (checksum) が付与されており、ダウンロードされたファイルが改ざんされていないかチェックされます。
サプライチェーン攻撃への対策
近年、オープンソースライブラリに悪意のあるコードを混入させるサプライチェーン攻撃が増加しています。
Cargo.lock がリポジトリに含まれていれば、ある日突然、依存先のライブラリが攻撃者の用意した不正なコードに差し替わったとしても、ハッシュ値の不一致によりビルドが失敗します。
このように、Cargo.lock はプロジェクトの安全性を守る防壁としての役割も担っているのです。
cargo-deny 等のツールとの連携
高度なプロジェクトでは、cargo-deny などのツールを使用して Cargo.lock をスキャンします。
これにより、ライセンス違反のあるライブラリや、脆弱性が報告されている古いバージョンのライブラリが混入するのを未然に防ぐことができます。
まとめ
Rustにおける Cargo.lock は、単なる自動生成ファイルではなく、開発の信頼性を支える重要な基盤です。
Cargo.toml が「何をしたいか」という仕様書であるのに対し、Cargo.lock は「何を使ってビルドしたか」という厳密な記録です。
アプリケーション開発においては、迷わず Git 管理に含めるようにしましょう。
また、ライブラリ開発においても、ビルドの再現性を高めるためにコミットすることを検討してください。
cargo update や --locked フラグを適切に使い分けることで、依存関係の管理に伴うトラブルを最小限に抑えることができます。
この記事を通じて、Cargo.lock の役割と重要性についての理解が深まれば幸いです。
最新のツールやコマンドを駆使して、安全で堅牢な Rust プロジェクトを構築していきましょう。