Cargo（Rust）とは？インストールと使い方・主要コマンド一覧

Cargo（カーゴ）は、Rustの公式パッケージマネージャー兼ビルドツールです。プロジェクトの作成・ビルド・実行・テスト・依存ライブラリの管理までを1つのコマンド体系で扱えるため、Rustではビルドツールとパッケージ管理を別々に覚える必要がありません。この記事で扱うのは、rustup経由のインストール、cargo new／build／run／check／test／installの使い分け、Cargo.tomlとCargo.lockの扱い、npmやpipとの違い、つまずきやすいエラーの対処です。掲載したコマンド出力は、2026年8月20日リリースのCargo 1.98.0で確認した実際の表示をそのまま載せています。

※ 本記事で扱う「cargo」は、Rust言語のビルド／パッケージ管理ツールを指します。貨物・カーゴコンテナや、ポートフォリオ作成サービスの「cargo.site」のことではありません。

まとめ

CargoはRustの公式ツールで、プロジェクト作成・ビルド・実行・テスト・依存管理を1つで担います。まずは cargo new でプロジェクトを作り、cargo run で動かし、変更のたびに cargo check でエラーを確認、本番用には cargo build --release という流れを押さえれば、Rust開発の基本は十分にカバーできます。なお1.97.0からはCargoにbuild.warnings設定が加わり、ビルド警告をプロジェクト単位で制御できるようになりました。詳細はRust 1.97.0の変更点を参照してください。依存追加は cargo add、設定は Cargo.toml という対応関係を覚えておきましょう。

Cargoとは何か（30秒で分かる結論）

Cargoは、Rustツールチェーンに標準で含まれるコマンドラインツールです。役割を一言でいうと「Rustプロジェクトの管理人」で、次の作業をまとめて引き受けます。

• ビルド：ソースコードを実行ファイルへコンパイル（cargo build）
• 実行：ビルドと実行を1コマンドで（cargo run）
• 依存関係の管理：外部ライブラリ（クレート）を crates.io から自動取得し、Cargo.lock でバージョンを固定
• テスト：コード内のテストを一括実行（cargo test）
• ドキュメント生成・公開：APIドキュメント生成（cargo doc）やライブラリ公開（cargo publish）

npmやpipのようにパッケージ管理とビルドを別ツールで覚える言語が多いなか、RustではCargo1つで完結します（Goのようにビルドとテストが標準コマンドに統合されている言語もあります。詳細は後述の比較表を参照してください）。Cargoは2015年のRust 1.0リリース時点ですでに標準ツールとして同梱されており、Rustエコシステムの中核を担い続けています。

Cargoのインストール（rustup経由）

CargoはRust本体と一緒に配布されるため、単体でインストールする必要はありません。Windows・macOS・Linuxのいずれでも、公式の rustup でRustを導入すれば、コンパイラ（rustc）とCargoが同時に入ります。インストール後は次のコマンドでバージョンを確認できます。

$ cargo --version
cargo 1.98.0 (797e8a9bc 2026-08-05)

括弧内はビルド元のコミットハッシュとその日付なので、環境によって異なります。CargoのバージョンはRust本体と同じ番号で進み、安定版は6週間周期で更新されます。1.98.0のリリースは2026年8月20日なので、次の1.99.0は2026年10月上旬が目安です。

コマンドが見つからない場合は、~/.cargo/bin がPATHに含まれているかを確認してください。Cargo（およびRust本体）の更新は rustup update で行います。Rust言語そのものの環境構築や所有権・基本文法から押さえたい場合は、Rust入門｜環境構築から所有権・基本文法、受託開発での採用判断までを先に読むと迷いません。

なお cargo install は、Cargo自体を入れるコマンドではありません。crates.ioで公開されているCLIツール（ripgrepやcargo-editなど）のバイナリをビルドして ~/.cargo/bin へ配置するコマンドです。バージョンを固定したいときは cargo install --locked、削除は cargo uninstall を使います。

Cargoの基本ワークフローと主要コマンド

Rust開発の基本的な流れは「cargo new で作成 → コードを書く → cargo run で実行 → cargo test で検証 → cargo build --release で本番用ビルド」です。まず cargo new で新規プロジェクトを作ります。

$ cargo new hello_cargo
    Creating binary (application) `hello_cargo` package
note: see more `Cargo.toml` keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

生成されるディレクトリ構成は次の通りです。Git管理下でないディレクトリで実行した場合は、Gitリポジトリの初期化と .gitignore の作成も同時に行われます。すでにGit管理下のディレクトリで cargo new を実行したときは .git と .gitignore が作られず、Cargo.toml と src だけが生成されます。モノレポで「ファイルが足りない」と感じたらこれが理由です。

hello_cargo/
├── .git/
├── .gitignore
├── Cargo.toml      … プロジェクト設定・依存関係のマニフェスト
└── src/
    └── main.rs     … エントリポイント（雛形のHello World）

src/main.rs には、以下の雛形コードが自動生成されます。

fn main() {
    println!("Hello, world!");
}

cargo new と cargo init の違い

cargo new は新しいディレクトリを作ってプロジェクト化しますが、既存のディレクトリをプロジェクト化したい場合は cargo init を使います。生成されるファイルは同じで、新規ディレクトリを作るかどうかだけが異なります。ライブラリを作りたい場合は cargo new --lib を指定すると、main.rs の代わりに src/lib.rs が作られます。

cargo check：コンパイルが通るかだけを高速確認

cargo check は実行ファイルを生成せず、型や構文のエラーチェックだけを行います。ビルドより高速なので、コーディング中の素早いエラー確認に向いています。以下の出力例では、プロジェクトの絶対パスを /path/to/hello_cargo に置き換えています。末尾の秒数もマシンによって変わります。

$ cargo check
    Checking hello_cargo v0.1.0 (/path/to/hello_cargo)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.66s

cargo build：ビルド（コンパイル）

cargo build はソースコードをコンパイルし、実行ファイルを target/debug/ に生成します。初回ビルド時には、依存関係の正確なバージョンを記録した Cargo.lock が作られます。

$ cargo build
   Compiling hello_cargo v0.1.0 (/path/to/hello_cargo)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 1.22s

cargo run：ビルドと実行を同時に

開発中にいちばん使うのが cargo run です。必要に応じてビルドしてから、そのまま実行まで行います。プログラムへ引数を渡すときは cargo run -- 引数 のように -- で区切ります。

$ cargo run
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.01s
     Running `target/debug/hello_cargo`
Hello, world!

cargo test：テストの実行

#[test] 属性を付けた関数が、cargo test でまとめて実行されます。例えば次のようなコードを書いて実行すると、テスト結果が一覧表示されます。

fn add(a: i32, b: i32) -> i32 {
    a + b
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_add() {
        assert_eq!(add(2, 3), 5);
    }
}

$ cargo test
   Compiling hello_cargo v0.1.0 (/path/to/hello_cargo)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.94s
     Running unittests src/main.rs (target/debug/deps/hello_cargo-5801f41a01395b24)

running 1 test
test tests::test_add ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

このほか、ビルド成果物を削除する cargo clean、APIドキュメントを生成する cargo doc（--open でブラウザ表示）もよく使います。主要コマンドを早見表にまとめると次の通りです。

プロジェクト構成とCargo.toml／Cargo.lock

Cargoプロジェクトの設定は Cargo.toml に集約されます。最低限、パッケージ情報を書く [package] と、依存ライブラリを書く [dependencies] の2つのセクションを覚えておけば十分です。

[package]
name = "hello_cargo"
version = "0.1.0"
edition = "2024"

[dependencies]
serde = "1.0"

edition はRustの言語エディションで、2015 / 2018 / 2021 / 2024 の4つがあります。エディション2024はRust 1.85.0で安定化され、現在の cargo new は --edition を指定しなければ2024を使います。[dependencies] に書いたクレートは、ビルド時にcrates.ioから自動取得されます。

一方の Cargo.lock は、実際に解決された依存バージョンを固定するファイルです。これをチームで共有すれば「自分の環境では動くのに、他の人の環境では動かない」というバージョン差異を防げます。cargo new は既定でこのファイルをバージョン管理の対象にします。

「ライブラリならコミットしない」という区分けが長く語られてきましたが、現在のCargo公式FAQはこの線引きを示していません。示されているのは「コミットするかどうかはパッケージの必要に応じて決まる」という基準のほうです。判断材料ははっきりしていて、git bisectでの原因追跡・CIの再現性・MSRV（最低サポートRustバージョン）の検証を重く見るならコミットします。依存の最新版で常に検証したいなら、コミットしたうえでCI側に cargo update を組み込みます。ひとつ押さえておきたいのは、Cargo.lock が自分のクレートの利用側のビルドには効かない点です。利用側に影響するのは Cargo.toml だけで、cargo install は --locked を付けない限り最新の依存を選びます。

なお Cargo.toml には、上記2つ以外にもよく使うセクションがあります。テスト時だけ必要な依存を書く [dev-dependencies]、ビルドスクリプト用の [build-dependencies]、リリースビルドの最適化を細かく調整する [profile.release]（前述の opt-level や lto など）、クレートの任意機能を定義する [features] といったものです。最初は [package] と [dependencies] だけ押さえ、必要になった段階で順に覚えれば十分です。

依存ライブラリの追加とバージョン指定

依存クレートの追加は、cargo add コマンドが手軽です。かつては外部ツール（cargo-edit）が必要でしたが、Rust 1.62以降はCargo標準のコマンドとして使えます。

$ cargo add serde
    Updating crates.io index
      Adding serde v1.0.229 to dependencies
             Features:
             + std
             - alloc
             - derive
             - rc
             - serde_derive
             - unstable
    Updating crates.io index
     Locking 7 packages to latest Rust 1.98.0 compatible versions
      Adding proc-macro2 v1.0.107
      Adding quote v1.0.47
      Adding serde v1.0.229
      Adding serde_core v1.0.229
      Adding serde_derive v1.0.229
      Adding syn v3.0.4
      Adding unicode-ident v1.0.24

実行すると Cargo.toml の [dependencies] に serde = "1.0.229" が追記されます。手書きで serde = "1.0" と書く場合と違い、cargo add はその時点の最新パッチ版まで含めた番号を書き込みます。有効・無効になっているフィーチャーも一覧表示されるため、derive のような任意機能を付け忘れていないかをその場で確認できます。

バージョンはセマンティックバージョニング（SemVer）に従って指定します。代表的な記法は次の2つです。

• キャレット ^（既定）：互換性を保つ範囲で更新を許可。serde = "1.0" は ^1.0 と同義で、1.x系の最新を許容
• チルダ ~：より狭い範囲のみ許可。~1.0.0 は 1.0.x のみ

依存を最新化したいときは cargo update を実行すると、Cargo.tomlで許容された範囲内でCargo.lockを更新します。

デバッグビルドとリリースビルド（–release）

Cargoのビルドには2つのモードがあります。既定のデバッグビルドは最適化を抑えてコンパイルが速く、開発向きです。--release を付けたリリースビルドは最適化を行い実行速度が大きく向上する代わりに、コンパイル時間が長くなります。

$ cargo build --release
   Compiling hello_cargo v0.1.0 (/path/to/hello_cargo)
    Finished `release` profile [optimized] target(s) in 0.76s

成果物の出力先も分かれており、デバッグは target/debug/、リリースは target/release/ に生成されます。本番配布やベンチマークでは必ず --release を使いましょう。Cargo.tomlの [profile.release] で opt-level や lto（リンク時最適化）を調整することもできます。

複数クレートをまとめる「ワークスペース」

関連する複数のクレート（パッケージ）を1つのプロジェクトとしてまとめて管理したいときは、Cargoのワークスペース機能を使います。ルートに置いた Cargo.toml に [workspace] を定義してメンバーを列挙すると、それらが Cargo.lock とビルド先 target/ を共有し、依存解決とビルドをまとめて行えます。アプリ本体と共通ライブラリを分割したり、複数のバイナリを1つのリポジトリで扱うモノレポ構成に向いています。

[workspace]
members = ["app", "core", "utils"]
resolver = "3"

ルートで cargo build や cargo test を実行すると、全メンバーがまとめてビルド・テストされます。特定のメンバーだけを対象にしたいときは cargo build -p app のように -p（package）でパッケージ名を指定します。resolver はフィーチャー解決の方式で、エディション2024の既定は "3"（Rust 1.84以降）です。ルートに [package] を持たない仮想ワークスペースはエディションから既定を引き継げないため、ここで明示します。

導入の目安は割り切って構いません。バイナリと共有ライブラリにクレートが割れた時点で入れてください。単一クレートで足りているうちは、Cargo.lock と target/ を共有する利点が出ないので不要です。

Cargoと他言語のパッケージ管理ツールの違い（npm・pip・Go Modules比較）

「cargoはnpmやpipと何が違うのか」という疑問は多いところです。最大の違いは、Cargoがビルド・テストまで統合している点です。npmやpipは依存管理が主目的で、ビルドやテストは別ツールに委ねます。主要言語のツールを比較すると次の通りです。

このように、Cargoは「依存管理＋ビルド＋テスト」をひとつのツールに統合しているのが強みです。なお、近年はPythonでもこの統合志向のツールが登場しています。Cargoやnpmに似た操作性を持つ次世代ツールについては、Pixiとは？Python/Conda対応の高速パッケージ管理ツールもあわせて参考になります。

よくあるエラーと対処法

• command not found: cargo：PATHが通っていません。再ログインするか ~/.cargo/bin をPATHに追加します。
• linker `link.exe` not found（Windows）：Visual C++ Build Toolsが未導入です。インストールで解決します。Linuxで cc/gcc が無い場合も同様にビルドツールを導入します。
• 依存解決の失敗（version solving failed）：クレート間でバージョンが競合しています。Cargo.tomlで許容範囲を調整するか、cargo update で再解決します。
• パニックの原因を追いたい：環境変数 RUST_BACKTRACE=1 を付けて実行すると、関数呼び出しの履歴（バックトレース）が表示されます。

よくある質問（FAQ）

Q. cargoの読み方は？

A. 「カーゴ」と読みます。英語で「貨物」を意味する cargo が由来です。

Q. CargoとRust（言語）の違いは？

A. Rustはプログラミング言語そのもの、Cargoはその開発を支える公式ツールです。Rustをインストールすると標準でCargoも入るため、通常は一緒に使います。

Q. cargo build と cargo run の違いは？

A. cargo build はコンパイルのみ、cargo run はコンパイル＋実行までを行います。動作を確認したいときは cargo run が便利です。

Q. cargo check は何のためにある？

A. 実行ファイルを作らずに型・構文エラーだけを高速にチェックするコマンドです。コーディング中のこまめなエラー確認に使い、エラーが無くなってから build/run します。

Q. Cargoだけを単体でインストールできる？

A. 通常はrustup経由でRustと一緒に導入します。Cargoだけを別個に入れる運用は基本的に不要です。

関連記事

• Pixiとは？Python/Conda対応の高速パッケージ管理ツール｜インストールと使い方
• Leptosとは？Rust製フルスタックWebフレームワークの特徴・使い方・Yew/Dioxusとの違い
• Rustにおけるasync/await構文の基本とその使い方: 初心者のための非同期処理完全入門ガイド
• Rust入門｜環境構築から所有権・基本文法、受託開発での採用判断まで
• Actix-webとは？Rust製の高速Webフレームワークの特徴・使い方をわかりやすく解説