だんご日報 開発者のための、AIと最新テックの串刺しニュース。
Rust 週刊 #1：1.99.0 安定版リリース、Tokio がフルスタック Web フレームワークを発表

Rust · Weekly #1

Rust 週刊 #1：1.99.0 安定版リリース、Tokio がフルスタック Web フレームワークを発表

rustRust言語週刊コンパイラフレームワーク

データソース：GitHub Releases + 官方博客 + HN

📦 バージョン動向

Rust 1.99.0 安定版リリース（リリース日：2026-10-01）

最新の安定版がついに 1.99 時代へと突入し、2.0 またはメジャーリファクタリングまであと一歩の節目を迎えました。今回のアップデートは低レイヤーの FFI 相互運用性と unsafe メモリ操作の充実に主眼が置かれています。当サイトの詳細な解説記事はこちら：/lang/2026-10-01-rust-1-99-release/

  1. extern "C" 可変長引数関数（Variadics）の安定化 これまで Rust からは FFI 経由で C の可変長引数関数（libc::printf など）を外部呼び出しすることしかできませんでしたが、今後は extern "C" または extern "C-unwind" ABI を使用し、低レベルで va_list 互換の VaList 型を通じて、Rust 内で直接可変長引数関数を定義・実装できるようになりました。これにより言語間の境界が取り払われ、既存のレガシー C ライブラリを Rust で書き直す際にグルーコードとしての C 言語層を挟む必要がなくなります。
  2. 非 Sized 型の生ポインタに対するメモリレイアウト問い合わせ 生ポインタを対象とした Layout::for_value_raw および mem::size_of_val_raw を含む 3 つの関数が安定化しました。これまでカスタムメモリアロケータなどにおいて、アライメント境界に従わないポインタや動的サイズ型（DST）のメタデータを取得するには参照型へのキャストが必要であり、未定義動作（UB）を誘発しやすい原因となっていました。新しい API により、生ポインタから直接かつ合法的にレイアウト情報を取得できるようになり、低レイヤーのメモリ操作における安全基準がさらに一段引き上げられました。

寸評：1.82 における生ポインタの参照外し安定化から、今回の 1.99 による生ポインタメモリレイアウト API の整備に至るまで、Rust 公式は「各個撃破」のアプローチを取り、2 年以上の歳月をかけて低レイヤーの unsafe 領域から参照への強制依存を段階的に取り除いてきました。これは本質的に、高パフォーマンスな並行データ構造を実装する際の認知的負荷を軽減するものです。

📝 深掘り記事

Tokio がフルスタック Web フレームワーク Topcoat を発表、Rails の開発体験再現を目指す

  • 何が起きたか：Tokio チームが Topcoat の最新進捗を公表しました。これは「batteries-included（オールインワン）」を掲げるフルスタックフレームワークで、Toasty ORM、ビュー、メール送信を統合し、バージョン 0.9 では Phoenix LiveView に類似したクライアント側リアクティブ機能も導入されています。
  • なぜ重要か：作者はかつて Ruby on Rails のコアコントリビューターであり、Rust 単一バイナリが誇る圧倒的なリソース効率（メモリ消費約 20MB）と、Rails の代名詞である「15分でアプリ構築」の体験を融合させることを目指しています。
  • 影響を受ける対象：Web フルスタック開発者。これまで Rust の Web エコシステムは Axum や Actix などのマイクロフレームワークが中心で、部品の組み合わせに依存していました。Topcoat は公式推奨のハイレベルな CRUD 業務開発パスを提供します。
  • 寸評：低レイヤーのネットワークライブラリが成熟・固定化する中、Tokio 公式がフルスタック分野へ進出するのは必然と言えます。Node.js や Go のエコシステムと比較して、Rust にはこれまで標準を牽引するオピニオンリーダー的なフレームワークが不在でした。Topcoat はマクロによる定型コード生成で明示的なライフタイム注釈を削減しており、計算資源（コンパイル時間）を投じて開発者の作業時間を節約する典型的な好例です。

コンパイラ性能の向上：9 月の平均所要時間が 4.5% 短縮

  • 何が起きたか：Nicholas Nethercote 氏による 9 月の性能レポートによると、629 件のベンチマークにおいて平均ウォールクロック時間が 4.57% 削減されました。特に Clippy への PGO（プロファイルに基づく最適化）導入で最大 18% の高速化が確認されたほか、LLVM 23 へのアップグレードにより全体でさらに 1.2% の向上がもたらされました。
  • なぜ重要か：単一の開発サイクルで 5% の高速化を果たすのは極めて困難です。今回のブレークスルーはアルゴリズムの再構築によるもので、例えば CFG（制御フローグラフ）走査の最適化により、apply_effects_in_block の呼び出し回数が 150 万回から 9 万回へと劇的に減少しました。さらに、精度の高い Polonius Alpha 借用チェッカーも Nightly で有効化されています。
  • 影響を受ける対象：すべての Rust 開発者。100 万行規模の大規模プロジェクトでは、4.5% の向上はローカルビルドで数分の短縮に相当し、CI/CD サーバーのインフラコスト削減にも直結します。
  • 寸評：C++ が Modules に頼ってビルドの遅さを解決しようとしているのに対し、Rust は依然としてフロントエンドの愚直なアルゴリズム改善と LLVM の恩恵から絞り出す方針をとっています。PGO 有効化で 18% の利得が得られたことは、Rust 自身の静的解析ツールがツールチェーン全体の最大のボトルネックの一つとなっていたことを物語っています。

Miri のキャッシュ機構に起因する GitHub Actions 認証情報漏洩リスク

  • 何が起きたか：Rust セキュリティレスポンスチームがセキュリティアドバイザリを公開しました。cargo miri の実行時にビルド関連の環境変数が target/ ディレクトリ内に保存される問題が判明しました。プロジェクトが GitHub Actions で target/ をグローバルキャッシュし、PR からの読み取りを許可している場合、悪意ある攻撃者が PR を提出することで、メインブランチのキャッシュに含まれる高権限シークレットを抽出・漏洩させることが可能になります。
  • なぜ重要か：本脆弱性は Miri 本体のコードバグではなく、ツールの仕様と CI サービスのキャッシュ戦略が組み合わさったことで生じた二次的脆弱性です。
  • 影響を受ける対象：CI で Miri を有効化し、かつグローバルキャッシュを設定しているオープンソースメンテナー。特にメモリ安全性の自動検証に依存する低レイヤーライブラリが影響を受けます。
  • 寸評：過去の CVE を振り返ると、このような「キャッシュ権限昇格」攻撃は NPM エコシステムなどでも度々発生しています。Rust コミュニティでは CI 高速化のために target/ ディレクトリを丸ごとキャッシュする習慣がありますが、今回のインシデントはビルドディレクトリ内のテスト生成物と環境情報が分離されていないという構造的課題を浮き彫りにしました。

32 ビット Windows ホストツールチェーンの段階的廃止

  • 何が起きたか：公式発表によると、Rust 1.100.0 より i686-pc-windows-msvc および gnu ターゲットが、ホストツール（rustc など）を提供する Tier 1 から std-only へと格下げされます。これにより、開発者は 64 ビット環境から 32 ビットバイナリをクロスコンパイルする運用に限定されます。
  • なぜ重要か：32 ビット Windows は 2025 年 10 月にサポートを終了しています。加えて、i686 環境での巨大なツールチェーンのビルドは頻繁にクラッシュを引き起こしており（LLVM コンパイル時の GNU C++ の OOM など）、同環境の CI を維持するコストがメリットを上回っていました。
  • 影響を受ける対象：産業制御システムやレガシーエンタープライズソフトウェアの開発者。今後も 32 ビット向けバイナリのコンパイル自体は可能ですが、32 ビット OS 上に Rust コンパイラを直接インストールして開発することはできなくなります。
  • 寸評：クロスコンパイルへの強制移行は、LLVM 23 など最新コンパイラインフラの要求リソースが 32 ビットアドレス空間（4GB メモリ）の限界を超えたことを示しており、ハードウェアの世代交代に伴うツールチェーンの必然的な淘汰と言えます。

🔥 コミュニティの話題

  • Topcoat フレームワーク：Rust に本当に Rails は必要なのか？

    • 反響：113 points / 100 コメント (Hacker News)
    • 主な論点：一部のエンタープライズ開発者は、フレームワーク初期段階の作者自身がブログで「将来の方向性は未知数」と認めている点を不安視し、本番採用のリスクが高いと慎重な姿勢を示しています。一方で、Elixir の Phoenix LiveView に匹敵するものとして歓迎する層も多く、小規模チームにとっては自前でマイクロサービス的な依存関係（Axum + SQLx + Tera）を組み上げるよりも、標準化された ORM とリアクティブビューを備えた単一のフレームワークのほうが圧倒的に開発効率が高いと主張しています。

  • なぜ Rust のコンパイラはいつも遅いのか？

    • 反響：262 points / 153 コメント (Hacker News)
    • 主な論点：4.5% の性能向上を歓迎する一方で、コンパイルの遅さという根本課題に関する議論が再燃しました。一方は、ゼロコスト抽象化（ジェネリクスの単相化、マクロ展開）や借用チェックがアルゴリズムの計算量において本質的に C 言語より重いと指摘。もう一方は、具体的なコミットの分析を通じて、真のボトルネックはレガシーコードにおける非効率なグラフ走査（CFG）にあり、Polonius のオンデマンド解析機構が導入されれば、こうした冗長な計算は根本から解消されると反論しています。

来週の注目トピック

  • Polonius Beta の進展：Nightly において Polonius Alpha 借用チェッカーがデフォルトで有効化されたことを受け、来週には複雑に交錯するライフタイムに関するコミュニティからの初期フィードバックが集まる見込みです。これまで借用エラーと誤判定されていた複雑なグラフデータ構造の実装コードが、unsafe を使わずに書けるようになる道筋が期待されます。
References（8）

関連記事