本記事にはAmazonアソシエイトリンクが含まれています。リンク経由で購入された場合、当サイトに紹介料が支払われることがあります。詳しくはプライバシーポリシーをご覧ください。
担任手帳のRustコードを開いた瞬間、目の前が真っ白になった。1行も読めない。
つい先日、バイブコーディングで5つのアプリを作った話を意気揚々と書いたばかりだった。「困りごとを言語化すれば、プロダクトになる時代」なんて締めくくった。それは本当だと今でも思う。でも、その記事を書き終えた後に僕が直面したのは、もっと根本的な問題だった。
自分のアプリのコードが、まるで読めない。
Rustのコードが、1行も読めなかった
担任手帳は、僕が作った中で最も本格的なアプリだ。Tauri 2.0というフレームワークを使っていて、画面はReactで、裏側のロジックはRustという言語で書かれている。
ある日、ふと気になって src-tauri/src/ ディレクトリを開いてみた。
pub fn encrypt_data(data: &[u8], password: &str) -> Result<Vec<u8>> {&[u8] って何だ。Result<Vec<u8>> って何だ。関数の1行目すら意味がわからない。
スクロールすると 'a とか &mut とか Option<T> とか、見たことのない記号が延々と続く。14個のTauriコマンド、暗号化処理、データベース操作——全部、AIが書いてくれたコードだ。全部、「僕のアプリ」のコードだ。でも、1行たりとも自力で説明できない。
それは、奇妙な感覚だった。自分の家なのに、間取り図が読めない。自分の車なのに、ボンネットの中が理解できない。
セキュリティ監査で見えた「自分の限界」
本当に怖くなったのは、セキュリティ監査の時だった。
担任手帳は教員向けの生徒管理アプリだ。名前、出欠、成績メモ——扱うのは個人情報ばかり。だから公開前にセキュリティチェックをかけた。結果、いくつかの問題が指摘された。
- CSP（Content Security Policy）の設定不備
- データベースのトランザクション処理の不足
- ファイルパスの検証が不十分（パストラバーサルのリスク）
- パスワード要件の強化が必要
指摘そのものはAIに「直して」と言えば修正してくれる。実際に全部修正できた。でも、僕は一つも理解できていなかった。
「CSPって何？」「パストラバーサルってどういう攻撃？」「トランザクションがないと何が起きるの？」
修正前と修正後のコードを見比べても、何が変わったのかわからない。「直ったよ」とAIに言われて「ありがとう」と答える。それしかできなかった。
生徒の個人情報を扱うアプリで、セキュリティの「良し悪し」を自分で判断できない。これは、教員として無責任ではないか——そう思った瞬間、背筋が冷たくなった。
「作ってから学ぶ」という逆転
でも、この経験は同時に、僕にとって大きな転機でもあった。
従来の順序：学ぶ → 作る
プログラミングの学び方といえば、普通はこうだ。
- 教科書を買う
- 基礎文法を学ぶ
- 練習問題を解く
- 小さなプロジェクトを作る
- 徐々に大きなものへ
正攻法。王道。だけど、僕はこのルートで何度も挫折してきた。大学でC言語を触った時も、途中で「これが何の役に立つのか」がわからなくなって投げ出した。基礎の段階で目的を見失うのだ。
僕の順序：作る → 困る → 学ぶ
僕がたどったのは、完全に逆の順序だった。
- バイブコーディングでアプリを作る
- 動くものが手元にある
- でもコードが読めない、セキュリティが判断できない
- 「だから学ばなきゃ」という具体的な動機が生まれる
- 何を学ぶべきかが明確にわかる
教員として10年以上の経験がある僕は、この「逆転」に既視感があった。授業でもそうなのだ。理論を先に教えてから実験させるよりも、先に実験させてから「なぜそうなったか」を考えさせた方が、生徒の目の色が変わる。体験が先にあると、理論が「答え合わせ」になる。腹落ちの深さが全然違う。
僕自身が今、その状態にいる。「自分のアプリのRustコードが読めない」という体験が、「Rustを学びたい」という最強の動機になっている。
3冊の本を買った
そして僕は、本屋で3冊の本を買った。
リーダブルコード — 読めるコードとは何か
1冊目は定番のリーダブルコード。もっと良いコードを書くためのシンプルで実践的なテクニックが詰まった本だ。
「でもお前、コード書いてないじゃん」と思うかもしれない。その通り。僕はコードを書いていない。でも、AIが生成するコードの「良し悪し」を判断する力は必要だ。
変数名が適切かどうか。関数が長すぎないか。コメントが的確か。AIに「もっと読みやすくして」と指示するにしても、「読みやすいとは何か」の基準がないと、その指示すら出せない。
コンピュータシステムの理論と実装 — 魔法の中身を知る
2冊目は通称Nand2Tetris。NANDゲートという最小の論理回路から出発して、最終的にテトリスが動くコンピュータを作り上げるという本だ。
なぜこの本を選んだかというと、僕にとってコンピュータがまだ「魔法の箱」だからだ。コードを書いて（正確にはAIに書いてもらって）、ボタンを押したら動く。でも、なぜ動くのかがわからない。
セキュリティの監査結果を理解できなかったのも、根本的にはここに原因がある。メモリとは何か、プロセスとは何か、データはどう保存されるのか——そういう基礎がないと、「なぜこの書き方が危険なのか」を本質的に理解できない。
プログラミングRust 第2版 — 自分のアプリの言語を理解する
3冊目はRustの入門書。これは最も直接的な動機がある。担任手帳のバックエンドがRustで書かれているから。
Rustの特徴は「所有権」という概念だ。データの所有者を明確にすることで、メモリ安全性を言語レベルで保証する。これは実は、セキュリティ監査で指摘された問題と深く関係している。
なぜRustが安全とされるのか。なぜ & や &mut が必要なのか。なぜコンパイラがあんなに厳しいのか。自分のアプリのコードを「読める」ようになるために、この本は避けて通れなかった。
読み始めて変わったこと
正直に言うと、まだ3冊とも読み始めたばかりだ。「マスターした」なんてとても言えない。でも、すでに感じている変化がある。
「なるほど」の解像度が全然違う
リーダブルコードを読んでいて、「変数名は略さず、意味がわかる名前をつける」という章があった。普通の初学者なら「ふーん、そうなんだ」で終わるかもしれない。
でも僕は、自分のアプリのコードで enc_data とか tmp_val とかいう変数名をたくさん見てきた。AIが生成したコードの中に、実際にそういう名前がある。だから「これのことか！」と腹落ちする。教科書の例題じゃなくて、自分のアプリで実感できる。
Rustの所有権の章を読んだ時も同じだった。「ある値の所有者は常に一つ」と書いてある。抽象的な概念だけど、担任手帳で生徒データを暗号化して保存する処理を見ると、「ああ、だからこう書かれているのか」と合点がいく。
体験が先にあるから、理論が血の通った知識になる。
バイブコーディングを否定しているわけじゃない
ここまで読んで、「結局バイブコーディングじゃダメなんじゃん」と思った人がいるかもしれない。違う。僕は前回の記事を撤回するつもりは一切ない。
バイブコーディングがなければ、僕は5つのアプリを作れなかった。教室の席替えを手作業でやり続けていたし、出張の旅費計算で消耗していたし、生徒のデータ管理に不安を抱えたままだった。バイブコーディングは、僕の仕事を確実に変えた。
ただ、バイブコーディングには次のステージがある。
最初のステージは「言葉にする力」。困りごとを言語化して、AIに伝える力。これだけで、動くアプリが作れる。
次のステージは「理解する力」。AIが書いたコードを読み、品質を判断し、セキュリティを評価する力。これがあると、作ったアプリに責任を持てるようになる。
僕は今、1から2へ移行しようとしている最中だ。前回の記事は「ステージ1の到達報告」で、この記事は「ステージ2への出発報告」。否定ではなく、進化だと思っている。
まとめ：動機があるから、学べる
3冊の本を買った理由を一言で言えば、「自分のアプリがあるから」 だ。
プログラミングを学ぶ最大の壁は「何のために学ぶのか」が見えないことだと、僕は思う。基礎文法を覚えても、それが何に繋がるのかわからなければ、続かない。大学でC言語を挫折した時がまさにそうだった。
でも今の僕には、学ぶ理由がある。
- 担任手帳のRustコードを読めるようになりたい
- セキュリティの「良し悪し」を自分で判断したい
- AIが生成するコードの品質を見極めたい
全部、自分がアプリを作ったから生まれた動機だ。教科書を読んで「いつか使うかも」と思いながら学ぶのと、「今まさにこれが必要だ」と思いながら学ぶのでは、吸収力がまるで違う。
作ることは、種を蒔くことだ。学ぶことは、水をやることだ。種がなければ水をやる対象がない。でも、水をやらなければ種は芽を出さない。
僕はバイブコーディングで種を蒔いた。そして今、水をやり始めた。
どこまで育つかはわからない。でも少なくとも、「何を育てたいのか」は明確にわかっている。それだけで、学ぶことが楽しい。
See ya!