Rust 1.100.0は、Rustのリリースチームが2026年11月12日に公開した安定版です。約10年越しで!（never型）が安定化し、カスタムアロケータを渡すためのAllocatorトレイトや、スコープを抜けるときに必ず後始末を走らせるDropGuardも標準で使えるようになりました。Cargo側では未使用依存の警告と、公開直後の版を依存解決で選ばせない「依存クールダウン」が入っています。この記事では、1.100.0の変更点を設定例とコード付きで整理し、既存プロジェクトを上げる前にどこを確かめるべきかまで解説します。
まとめ：Rust 1.100.0で押さえる変更点とアップグレード前の確認事項
実務への影響が大きいのは2点です。1つ目は、never型のフォールバック先が全エディションで()から!に変わったことです。2021以前のエディションのコードで、戻り値の型が推論任せになっている箇所がコンパイルエラーになる場合があり、型注釈を足して直します。2つ目はCargoのcargo::unused_dependenciesが既定で警告を出すようになったことで、CIで警告をエラー扱いにしている案件はビルドが止まる可能性があります。
新機能として取り入れる価値が高いのはglobal-min-publish-ageです。公開から一定期間たっていない版を依存解決で選ばない設定で、乗っ取られたクレートの新版を即座に取り込む事故を減らせます。DropGuardとAllocatorは、ロールバック処理やメモリ管理を自前で書いていたコードを整理したいときに検討すれば足ります。
Rust 1.100.0の全体像と一次情報：リリース日と更新コマンドの確認
まずは版の位置付けと、更新に使うコマンドを確認します。Rustは6週間ごとに安定版を出しており、1.100.0もこの定期リリースの1つです。3桁目に入ったことに特別な意味はなく、互換性の方針も従来と同じです。
2026年11月12日公開の1.100.0をrustupで更新して版を固定する手順
手元とCIのツールチェーンはrustupで上げます。案件ごとに版を固定する場合は、プロジェクト直下にrust-toolchain.tomlを置き、チャンネルに版番号を書きます。
# 安定版を最新（2026年11月時点で1.100.0）へ更新
rustup update stable
rustc --version
# rust-toolchain.toml（プロジェクト直下に置くと、この版が使われる）
[toolchain]
channel = "1.100.0"
components = ["clippy", "rustfmt"]固定版を書き換える前に、別ブランチでchannelだけを上げたCIジョブを流し、既存ジョブとの差分を見るのが安全な順序です。前回の定期リリースで入ったシンボルマングリングやCargo警告制御の変更は、Rust 1.97.0の変更点の解説で扱っています。数版をまとめて飛ばす案件では、あわせて確認してください。
公式ブログとリリースノートで変更点と互換性注意を読み分ける順序
変更の背景とコード例は公式ブログの「Announcing Rust 1.100.0」に、項目の完全な一覧はRustのリリースノートの1.100.0節にまとまっています。移行前に必ず読むべきなのはリリースノート末尾の「Compatibility Notes」です。1.100.0では20項目を超える互換性の注意が並んでおり、ブログ本文には出てこない変更も含まれます。
たとえば、if letで使う変数をクロージャがより厳密にキャプチャするようになった点、boxパターンが構文として受け付けられなくなった点、標準ライブラリのUnicodeが18.0.0に上がった点は、リリースノートでしか確認できません。プルリクエスト単位の追跡にはGitHubのリリースタグが使えます。
never型の安定化：Result型での書き方とフォールバック変更への対処
1.100.0の目玉はnever型です。書けることが増えた面と、既存コードの推論結果が変わる面の両方があるため、分けて確認します。
never型を型名として書けるようになった点とInfallibleとの関係
never型（!）は「値が決して作られない型」を表します。これまでは関数の戻り値位置でしか書けませんでしたが、1.100.0からはResult<T, !>のように任意の型の位置で使えます。あわせてstd::convert::Infallibleは!の型エイリアスになりました。
// エラーが起こり得ないResultから、unwrapせずに値を取り出す
fn infallible_unwrap<T>(res: Result<T, !>) -> T {
match res {
Ok(v) => v, // Err(!)は存在し得ないため、この1腕で網羅になる
}
}
fn main() {
let r: Result<u32, !> = Ok(7);
println!("{}", infallible_unwrap(r));
}失敗しない変換やパーサを、unwrap()でパニックの可能性を残さずに書けるのが実務上の利点です。Infallibleを返していた既存のトレイト実装はそのまま動きます。
全エディションでフォールバックが!に変わる影響と型注釈での直し方
推論で型が決まらない式の型（フォールバック先）は、これまで2021以前のエディションでは()でした。1.100.0では全エディションで!に統一され、Edition Guideの該当章によると、移行を支援していたdependency_on_unit_never_type_fallbackリントも削除されています。自動修正は用意されていません。
壊れやすいのは、戻り値がジェネリックな関数の結果を捨てている箇所です。修正は、型を明示してフォールバックに頼らない形にするだけです。
fn f<T: Default>() -> Result<T, ()> {
Ok(T::default())
}
fn outer<T>(x: T) -> Result<T, ()> {
// f()?; // 1.100.0ではTが!に推論されエラーになり得る
f::<()>()?; // 型引数を明示する
// () = f()?; // こちらの書き方でもよい
Ok(x)
}クロージャの中でpanic!()だけを返している箇所も同じ型の問題を起こすため、|| -> () { panic!() }のように戻り値型を書きます。依存クレート側で失敗する場合は、公式ブログによると影響を受けた公開クレートには修正版が出ているため、まずクレートの更新を試してください。
AllocatorとDropGuard：標準ライブラリで新たに使えるAPIの実装例
標準ライブラリでは、メモリ確保と後始末に関わる2つのAPIが安定化しました。いずれも既存コードの書き換えは必須ではなく、該当する処理を持つプロジェクトが選んで取り入れる種類の変更です。
Allocatorトレイト安定化でVecやBoxにアロケータを渡す書き方
Allocatorトレイトと、それを受け取るVec::new_in・Vec::with_capacity_in・Box::new_inなどが安定化しました。これまでは#[global_allocator]でプログラム全体のアロケータを1つ差し替える方法しかなく、コレクション単位で確保先を変えるにはナイトリー版が必要でした。
use std::alloc::System;
fn main() {
// このVecとBoxだけ、OSのアロケータ（System）から確保する
let mut buf: Vec<u8, System> = Vec::with_capacity_in(1024, System);
buf.extend_from_slice(b"hello");
let boxed = Box::new_in(42u64, System);
println!("len={} value={}", buf.len(), boxed);
}独自アロケータを実装する場合はunsafe impl Allocatorを書くことになり、確保・解放の契約を守る責任は実装側に残ります。リクエスト単位のアリーナ確保など、効果を計測で示せる箇所に絞って使うのが妥当です。値がスタックとヒープのどちらに置かれるかの基礎は、Rustのスタックとヒープの解説を参照してください。また、Boxの一部の実装が任意のアロケータ向けに一般化されたため、型推論が新たに失敗する場合があるとリリースノートの互換性注意に書かれています。
DropGuardで失敗時のロールバックを全経路で確実に走らせる実装
DropGuardは、値とクロージャを受け取り、ガードが破棄されるときにクロージャを実行する型です。return・?・パニックのどの経路で抜けても後始末が走り、成功時だけDropGuard::dismissで解除できます。dismissはメソッドではなく関連関数なので、guard.dismiss()とは書けない点に注意してください。
use std::mem::DropGuard;
use std::num::ParseIntError;
// 途中で1件でも失敗したら、numsを呼び出し前の長さに戻す
fn parse_all(nums: &mut Vec<u32>, inputs: &[&str]) -> Result<(), ParseIntError> {
let original_len = nums.len();
let mut nums = DropGuard::new(nums, move |nums| nums.truncate(original_len));
for s in inputs {
nums.push(s.parse()?); // ここでErrになるとガードが巻き戻す
}
DropGuard::dismiss(nums); // 全件成功したので巻き戻しを解除
Ok(())
}これまで同じことをするには、専用の構造体にDropを実装するか、scopeguardのような外部クレートに頼る必要がありました。依存を1つ減らせる場面では置き換えを検討してよいでしょう。ただし、クロージャ内でさらにパニックを起こすとプロセスが中断されるため、後始末の処理は失敗しない操作に限ります。
文字列の前後削除やスマートポインタ変換など小さな安定化APIの要点
日常のコードで効くのは、str::trim_prefix・trim_suffix（スライスとPathにも同名あり）、真偽値を反転するbool::toggle、中身を変換するBox::map・Rc::map・Arc::map、要素を関数で生成するVec::from_fnです。trim_prefixは接頭辞が無ければ元の文字列をそのまま返すため、strip_prefixのようにOptionを外す処理が要りません。
サイズ0の型を安全に作るためのstd::mem::conjure_zstも追加されました。transmute(())などで代用していたunsafeコードを置き換える用途で、通常のアプリケーションでは使う場面はほとんどありません。
Cargoの変更：未使用依存の警告とmin-publish-ageによる依存クールダウン
Cargoの変更はCIと依存管理に直接効きます。特に未使用依存の警告は、何も設定しなくても1.100.0に上げた時点で出始めます。
cargo::unused_dependenciesの既定warnと警告レベルの制御
1.100.0でCargo独自のリント機構が入り、Cargo.tomlの[lints.cargo]テーブルで警告レベルを制御できるようになりました。最初の主要なリントが、どのビルドターゲットからも使われていない依存を検出するcargo::unused_dependenciesで、既定はwarnです（Cargo Bookのリント一覧）。
# Cargo.toml（単体パッケージで未使用依存をエラーにする）
[lints.cargo]
unused_dependencies = "deny"
# ワークスペースで共通化する場合：ルートのCargo.toml
[workspace.lints.cargo]
unused_dependencies = "deny"
# 各メンバーのCargo.toml
[lints]
workspace = true判定には癖があります。cargo check --bin fooのように一部のターゲットだけをビルドしたときは警告が出ず、[dev-dependencies]は対象外です。推移的な依存の版を固定するためだけに書いている依存は誤検知されるため、ドキュメントではtarget."cfg(false)".dependenciesへ移す方法が示されています。いきなりdenyにせず、まずwarnのまま一覧を出して誤検知を仕分けるのが現実的な順序です。Cargoの基本操作はCargoのインストールと主要コマンドの解説にまとめています。
global-min-publish-ageで公開直後の版を選ばせない設定と例外の扱い
依存クールダウンは、crates.ioに公開されてから指定期間がたっていない版を、依存解決の候補から外す機能です。乗っ取られたクレートに悪意ある新版が出た場合に、発覚して取り下げられるまでの猶予を取ってから取り込むという考え方です。設定は.cargo/config.tomlに書きます（Cargoの設定リファレンス）。
# .cargo/config.toml
[registry]
global-min-publish-age = "3 days" # 既定は"0"（制限なし）
[resolver]
incompatible-publish-age = "deny" # 既定値。Cargo.lockにある版は維持される
# 緊急の脆弱性修正版だけ、一時的に制限を外して取り込む
CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allow cargo update clap --precise 4.6.9期間には「3 days」「2 weeks」のように整数と単位を書きます。レジストリ単位で期間を変えたい場合の設定項目はregistries.<name>.min-publish-ageです。例外が3つあります。インデックスに公開日時（pubtime）の無い版は保留されないこと、cargo installはこの設定を無視すること、そしてクールダウンだけでサプライチェーン攻撃を防ぎ切れるわけではないことです。cargo installで入れるツールはcargo install foo --version 1.2.3のように版を固定してください。
build-dirレイアウト変更とcargo installのロックファイル既定化の影響
中間生成物を置くビルドディレクトリの構成が変わり、ビルド設定のハッシュがすべての成果物に一貫して付くようになりました。不要な再ビルドや、git worktree間でキャッシュを共有したときの取り違えが減る変更です。一方で、target配下のパスを直接たどって成果物を拾っているスクリプトは壊れる可能性があります。リリースノートは、ディレクトリ構成は安定したインターフェースではないとし、CargoのJSONメッセージで成果物の場所を取得するよう案内しています。
またcargo installは、配布物（.crate）に同梱されたロックファイルを既定で使うようになり、--lockedは指定しても何も変わらないオプションになりました。CIでツールを入れる手順に--lockedが残っていても害はありません。
Rust 1.100.0へのアップグレード判断：先に検証すべき構成と見送り条件
結論から書くと、2024エディションで書かれた通常のWebアプリケーションやCLIは、依存の更新と警告の確認だけで上げてよい版です。逆に、次に挙げる条件に当てはまる案件は、CIで一度通してから本番の固定版を更新してください。
すぐ上げてよい案件と、CIで先行検証してから上げるべき4つの条件
先行検証が要るのは、影響の大きい順に次の4つです。
- 2021以前のエディションのクレートを含み、ジェネリックな戻り値を捨てるコードやマクロ生成コードが多い（never型フォールバックの変更）
- CIで警告をエラー扱いにしている（
unused_dependenciesの新しい警告でビルドが止まる） - ビルドディレクトリのパスを直接参照するデプロイスクリプトやキャッシュ設定がある（build-dirレイアウト変更）
- ARMv7のハードフロート向けや32bit x86向けなど、組み込み・特殊ターゲットへビルドしている（ABI関連の互換性注意が複数ある）
1と2に当てはまるだけなら、修正は型注釈の追加と依存の整理で済み、コードの設計を変える必要はありません。4に当てはまる場合は、リリースノートの該当項目を1つずつ照合するまで上げないでください。ARMv7では1.94〜1.100の間に必要だったFPU前提が修正されたため、-Ctarget-feature=+d32の指定が要る構成があります。
受託開発でRustの版更新を定期保守運用に組み込むときのルール設計
受託で運用しているRust製システムでは、版の更新を「新機能のため」ではなく、セキュリティ修正を受け取り続けるための定期保守として扱うのが実務的です。今回のglobal-min-publish-ageは、その定期保守で依存の更新を安全側に倒すための仕組みです。たとえば「ツールチェーンは安定版の公開から2週間後に追随する」「依存は公開から3日たった版だけを入れる」と運用ルールに書いておけば、更新のたびに判断し直す手間が減ります。性能要件のあるAPIサーバーやシステム連携をRustで組み、こうした更新運用まで含めて任せたい場合は、当社のAPI開発・システム連携の受託開発で相談を受けています。言語選定やバージョン固定の基礎から確認したい場合は、Rust入門（環境構築から受託開発での採用判断まで）に全体像をまとめました。
よくある質問
Rust 1.100.0について調べるときに出てきやすい疑問へ、2026年11月時点の公式情報をもとに回答します。
Rust 1.100.0はいつ公開されましたか？
2026年11月12日に安定版として公開されました。Rustは6週間ごとに安定版を出しており、1.100.0もその定期リリースの1つです。手元の環境はrustup update stableで更新できます。版番号が3桁になったことに特別な意味はなく、互換性の方針も従来と変わりません。変更点の一次情報は公式ブログとリリースノートの2つが基準になります。
never型の安定化で既存コードは壊れますか？
多くのコードはそのまま動きます。影響が出やすいのは、2021以前のエディションで、戻り値がジェネリックな関数の結果を捨てている箇所や、クロージャがpanic!()だけを返す箇所です。フォールバック先が()から!に変わったことで型が決まらずエラーになる場合があり、f::<()>()のように型を明示すれば直ります。自動修正は提供されていません。
InfallibleとneverのRust上の違いは何ですか？
1.100.0からは同じ型です。std::convert::Infallibleは!の型エイリアスに変更されたため、Result<T, Infallible>とResult<T, !>は区別されません。既存のInfallibleを使ったコードは書き換えなくても動きます。新しく書くコードでは、意図が短く伝わる!を使っても差し支えありません。
min-publish-ageを設定すると脆弱性の修正版も遅れて入りますか？
遅れます。修正版も公開直後は候補から外れるため、急ぐ場合はCARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allowを付けて対象のクレートだけをcargo update --preciseで上げます。Cargo.lockに記録済みの版は維持されるので、設定しただけで既存の依存が古い版へ戻ることはありません。期間は3日〜1週間程度から始め、運用に合わせて調整してください。
unused_dependenciesの警告が誤検知の場合はどうすればよいですか？
まず、全ターゲットをビルドしたうえで警告が出ているかを確認します。一部のバイナリだけをビルドしたときは判定されません。推移的な依存の版固定だけを目的に書いている依存なら、Cargo Bookの案内どおりtarget."cfg(false)".dependenciesへ移します。どうしても抑えたい場合は、[lints.cargo]でunused_dependencies = "allow"に下げられます。
関連記事
- Rust入門｜環境構築から所有権・基本文法、受託開発での採用判断まで：Rust自体をこれから学ぶ方向けに、環境構築から文法、実務採用の判断軸までをまとめた入門記事です。
- Rust 1.97.0とは｜v0シンボルマングリング既定化とCargo警告制御の変更点【2026年7月】：前回取り上げた版の変更点です。複数の版をまとめて上げるときにあわせて確認できます。
- Cargo（Rust）とは？インストールとcargo installの使い方・主要コマンド一覧：本記事で触れたCargoの設定やcargo installの基本操作を掘り下げています。
- Rustのスタックとヒープ｜値がヒープへ脱出する条件とスタックオーバーフローの防ぎ方：Allocatorを検討する前提となる、メモリ配置の基礎を解説しています。
