プロダクトを作って、中級から上級へ

基礎01〜10の後に、Trailという1つの作業ログプロダクトを育てる。コードを使って困りごとを見つけ、必要になったRustの知識を学び、変更の効果を確かめる。

到達目標は「機能を書ける」から「失敗・負荷・変更に対して設計を説明できる」へ進むこと。上級の目印は、unsafeの量やフレームワークの数ではない。

現在の出発点

Trail v0 は実装・実行できる。作業名と分数の記録、再起動後の一覧、合計がある。

11〜30の機能はこれから本人が実装する。 以下の時間は計画上の目安で、能力の認定や納期ではない。1段階を60〜90分の作業に分け、利用して気づいたことを次の改善にする。

5つのプロダクト段階

段階	作るもの	Rustで扱うこと	目安	区切りの成果
11〜14: 使えるCLI	型、日付、タグ、集計、引数	不変条件、所有権、エラー、module	8〜12時間	自分で1週間使い、改善を1件反映
15〜18: 保存とデータ	JSON、SQLite、更新、インポート	Serde、trait、境界、transaction、性質テスト	12〜18時間	壊れた入力でも既存データを失わない
19〜22: ローカルWeb	API、入力フォーム、集計画面	async、Tokio、Axum、共有状態、観測	16〜24時間	ブラウザから保存し、再起動後も見られる
23〜26: 長い処理と復旧	ジョブ、進捗、再試行、再起動	channel、Send/Sync、状態機械、取消、冪等性	20〜30時間	中断・重複要求・過負荷を再現して復旧
27〜30: 保守と配布	安定したライブラリ、測定、配布	lifetime、Cow、trait設計、プロファイル、互換性	20〜30時間	別環境で再現できる配布物と運用手順

計76〜114時間程度を見込むが、理解と実際の利用を優先する。すでにできる段階は、到達条件を実演して短縮してよい。

1段階の実務手順

1. 使う: 今ある機能を触り、利用者の困りごとを1文で書く。
2. 契約を決める: 入力、出力、失敗、保存されるものを具体例3つで決める。
3. 最小の縦の経路を通す: 入力から保存・結果表示まで、機能を1つ通す。層だけ先に大量に作らない。
4. 検証する: 成功例、境界、障害を試す。テストを追加する場合、フィルタが0件で成功していないか確認する。
5. 観察する: 実データに近い小さいfixtureで、ログ・変数・時間・データの残り方を見る。
6. 設計を言葉にする: 選んだ方法、代案、捨てた保証、測定結果を4〜6行で残す。
7. 見直す: 使い方と記録を更新し、変更を1まとまりのコミットにする。

例えば「CSVを大量に入れる」は大きい。まず「3行のCSVを検査して、全て正しい時だけ保存する」までを1回で実装する。

演習と理解の接続

演習	段階	何を練習するか
ex07	13	決定的な順序の集計、借りた入力から所有する結果へ
ex08	23	許されるジョブ状態の遷移を表す
ex09	24	上限付きbackoff、整数の境界
ex10	18・24	順序を保つ重複除去と借用の寿命

cargo test -p exercises ex07 -- --ignored
cargo run -p trail --example bounded_queue

演習は学習用の小さな関数。通過後、プロダクトで同じ考え方を使う。ただし、メモリ上の重複除去だけでは再起動を越える冪等性は保証できない。

考え方と図解

メンタルモデル集は、用語の辞書ではなく判断するための問いをまとめている。各課題から必要なモデルへリンクする。

• 値の所有者: 「誰が、いつまで、この値を持つか」
• 境界と不変条件: 「外から来た値を、どの時点で信じられるか」
• asyncと待ち行列: 「何を待っているか。増えた仕事をどこまで受けるか」
• 保存と応答: 「何が確定したか。利用者が何を観測したか」
• 性能: 「どの量を、どの条件で、小さくしたいか」

プロダクト図解 の受付・処理・待ち行列と、応答を失った再試行を操作し、同じ状態を実装のテストで再現する。

学習支援の頼み方

「第16段階。保存は動いたが更新途中の失敗が不安。まず考え方を図で説明して、次に自分でテストを書きたい」のように、段階・観察・疑問を伝える。

支援は 最小例 → 自分の実装 → 実行 → 反証 → 説明 の順。解答の丸写しで完了にしない。本人が作った変更、観測した証拠、まだ保証していないことを 学習記録に残す。

上級への確認

最終段階で、第三者が次を確認できる状態を目指す。

• 正常な利用をデモでき、失敗する入力でも状態が説明できる。
• API・DB・ワーカーの間で、誰が値を所有し、どこで処理が確定するか描ける。
• 性質・並行実行・中断・再試行のテストがあり、その限界も説明できる。
• 遅い箇所を測り、最適化前後を同じ条件で比較できる。
• 変更を小さく保ち、移行・復旧・配布の手順を別環境で再現できる。

最後は異なる小さなプロダクトで設計を再現する。別のデータ・負荷条件でも判断できることが、教材を完了したこと以上の証拠になる。

AI 移行の話を scope 約束でなく review protocol にする

Trail v0 のリンクは実装済みの出発点を示し、stage 11〜30 は学習者がこれから実装する計画である。この区別を issue、commit、demo ごとに保つ。2024 goals と2025年の Rust 2024 release は言語の進化経路を示すが、製品 architecture を認定しない。製品 stage にはそれぞれ input contract、durable state の規則、recovery の証拠が必要である。

現在の AI 事例は有用な規律を与える。Google の2026-10-01 Argon 発表は、C/C++ 移行で profile-guided experiment、compiler output の調査、audit、emulation test、review を使うと記す。これは Google 自身の作業に関する主張であり、Trail の benchmark ではない。この順番を stage 18 または24へ翻訳する。まず invariant と失敗 fixture を保存し、一つの小変更を行い、focused persistence/recovery test を実行し、diff を検査してから、関係する全 suite を実行する。性能変更候補は baseline、fixture size、hardware/toolchain、反復回数、出力同一性確認、rollback plan を残す。

AI 支援の feature 一つを厳格な review envelope で作る。model に test case を三つ出させても、説明できる一つだけを選び、最小 vertical path を実装し、明示的な rejection test を加える。その後 save または queue transition の途中で process を殺し、restart 後の state を記録する。AI 生成 Rust の保守性や低 effort 投稿に関する community thread は体験報告であり、AI code が常に unsafe だという証拠ではない。適切な結論は、全変更の追跡可能な ownership である。