表示されているエラー
use文またはextern crate行を追加してcargo buildを実行すると、次のようなエラーが表示されます：
error[E0463]: can't find crate for `serde`
--> src/main.rs:1:5
|
1 | use serde::Deserialize;
| ^^^^^ can't find crate
または、組み込みやno_stdコードを書いている場合：
error[E0463]: can't find crate for `std`
原因は主に3つあります。クレートがCargo.tomlに記載されていない。名前のスペルが間違っている。またはビルド環境が壊れているかターゲットが不足している。以下の手順を順番に試してください — ほとんどの場合はステップ1または2で解決します。
ステップ1 — まずCargo.tomlを確認する
Cargo.tomlを開き、[dependencies]セクションを確認してください。クレートが記載されていない場合、Cargoはダウンロードもリンクもできません。それだけのことです。
[dependencies]
# クレートはここに記載されていますか？
serde = "1"
記載がない場合は、1つのコマンドで追加できます（Cargo 1.62以降が必要）：
cargo add serde
serde、tokio、axumなどの人気クレートの多くは、実際に使用する機能を有効にするためにフィーチャーフラグが必要です：
cargo add serde --features derive
cargo add tokio --features full
追加後、Cargo.tomlにエントリが追加されたことを確認し、再ビルドします：
cargo build
ステップ2 — クレート名が正確かどうか確認する
クレート名はcrates.ioではハイフン（-）を使いますが、Rustソースコード内ではアンダースコア（_）を使います。この見落としがちな違いが頻繁に問題を引き起こします。
Cargo.toml内：my-crate = "0.1"- Rustソース内：
use my_crate::SomeStruct;
# Cargo.toml
[dependencies]
my-crate = "0.1"
// src/main.rs
use my_crate::SomeStruct; // underscore, not hyphen
Cargo.tomlのタイポ — 1文字でも間違えると — Cargoは何もダウンロードせず、コンパイラがエラーを出します。次のステップに進む前に、crates.ioで正確なスペルを確認してください。
ステップ3 — クレートインデックスとロックファイルを更新する
Cargo.lockは、特にCargo.tomlを手動編集した後に同期がずれることがあります。強制的に更新します：
cargo fetch
cargo build
まだ解決しない場合は、問題のあるクレートだけを更新します：
cargo update -p serde
またはすべてのロックを削除してCargoに新しく解決させます：
cargo update
ステップ4 — 正しいワークスペースメンバーにいることを確認する
ワークスペースにはルートのCargo.tomlと個別のメンバークレートがあります。各メンバーは独自の依存関係を管理します — ルートは自動的に共有しません。
# workspace root Cargo.toml
[workspace]
members = ["app", "lib"]
エラーがapp/src/main.rsから発生している場合は、ルートではなくapp/Cargo.tomlを確認してください。そして、そのパッケージを明示的にターゲットにします：
cargo build -p app
ステップ5 — Rustエディションとextern crateの使用を確認する
Rust 2015ではすべての場所で明示的なextern crate宣言が必要でした。Rust 2018以降はその要件がなくなり、useを直接書くだけでよくなりました。2021プロジェクトに残っている2015スタイルの宣言が混乱を引き起こします。
Cargo.tomlにedition = "2021"と記載されている場合は、次のような行を削除してください：
extern crate serde; // remove this
代わりにこのように書きます：
use serde::Deserialize;
現在もextern crateが必要なケースは、proc-macroクレートとextern crate alloc;のような特殊なno_stdの使用に限られます。
ステップ6 — no_stdの場合：can't find crate for std
ファームウェアやWebAssemblyを書いていてcan't find crate for 'std'が表示される場合、コンパイルターゲットに標準ライブラリがありません。クレートルートの先頭に#![no_std]を追加し、stdの代わりにcoreを使用します：
#![no_std]
use core::fmt;
use core::mem;
またはstdが必要な場合は、正しいターゲットがインストールされているか確認します：
# List installed targets
rustup target list --installed
# Add a target that includes std
rustup target add x86_64-unknown-linux-gnu
ステップ7 — 他の方法で解決しない場合はRustツールチェーンを再インストールする
破損したツールチェーン — 多くの場合rustup updateの途中中断が原因 — により、コンパイラがstd、core、allocを完全に見失うことがあります。まれですが発生します。アンインストールしてクリーンに再インストールします：
rustup toolchain uninstall stable
rustup toolchain install stable
rustup component add rustfmt clippy
次に、ビルドキャッシュを削除して最初からやり直します：
cargo clean
cargo build
検証 — 修正が正常に機能したか確認する
クリーンビルドを実行し、重要な出力だけをフィルタリングします：
cargo build 2>&1 | grep -E "error|warning|Compiling"
正常なビルドは次のようになります：
Compiling serde v1.0.210
Compiling my-project v0.1.0
Finished dev [unoptimized + debuginfo] target(s) in 3.42s
error[E0463]の行がなければ、クレートが見つかってリンクされています。
クイックリファレンス — よくある原因と対処法
- Cargo.tomlにクレートがない →
cargo add <crate-name>を実行する - クレート名のタイポ → crates.ioで確認してスペルを修正する
- フィーチャーフラグが不足している →
cargo add tokio --features full - ロックファイルが古い →
cargo fetchまたはcargo updateを実行する - ワークスペースメンバーが違う → 各メンバー自身の
Cargo.tomlを確認する - エディションの不一致 → 2018以降のエディションでは古い
extern crate行を削除する - no_stdターゲット →
#![no_std]を追加するかrustupで正しいターゲットをインストールする - ツールチェーンが破損している →
rustup toolchain uninstall stable && rustup toolchain install stable