AIにRustを書かせると、想像以上にそれっぽいコードが返ってきます。
CLIツール、簡単なWeb API、ファイル処理、非同期処理のひな形まで、かなりの速度で出力してくれます。
しかしRustに関しては特に、そこで油断しないほうがいいと強く感じます。
なぜならRustは、コンパイルが通ること自体に大きな意味がある言語だからです。
GoやPythonだと、ある程度動いたからヨシとして進めてしまえる場面があります。
しかしRustは、所有権・借用・ライフタイム・スレッド安全性など、コードの意味を理解していないと、そもそも前に進めないことが多いです。
逆に言うと、AIがそれっぽく書いたコードでも、自分が概念を理解していないと、修正やレビュー、再利用も難しくなります。
この記事では、AI時代にRustを書くなら、すべてを暗記しなくてもいいけれど、これだけは理解しておいたほうがいい概念を実務目線でまとめます。
この記事で言いたいこと
Rustで本当に理解しておくべきなのは、細かい文法よりも次のような概念です。
- 所有権はRust特有の面倒なルールではなく、メモリ管理の前提
- 借用は参照ではあるけれど、何でも自由に共有できるわけではない
- ライフタイムは長生きさせる記法ではなく、参照関係の整合性を示すもの
- Result と Option は例外の代替ではなく、失敗や不在を型で表す設計
- trait はOOPのinterfaceに似て見えて、設計の切り方がかなり違う
- async や並行処理は、書けることより Send / Sync を含めて理解しているかが大事
Rustは、表面的なコードを読むだけでは分かった気になりやすい言語です。
しかし本質はかなり型と制約に寄っています。
だからこそAI時代でも、概念を知っているかどうかがそのままコード品質に直結します。
1. 所有権はRustのクセではなく、この言語の中心
Rustを触り始めると、最初にぶつかるのが所有権です。
正直、最初はかなり面倒に見えます。
変数を代入しただけなのに元が使えないのか、なぜ clone が必要なのか、参照を渡しているだけなのにコンパイルエラーになるのか、と思いがちです。
しかしRust公式Bookでも、所有権はRustがメモリ管理を行うためのルールの集合として説明されています。つまり、あとから足された作法ではなく、Rustそのものの中心です。
fn main() {
let s1 = String::from("hello");
let s2 = s1;
// println!("{}", s1); // ここは使えない
println!("{}", s2);
}
この例で大事なのは、s1 が s2 にコピーされたのではなく、所有権がムーブしたということです。
なぜこれを理解すべきか
AIはRustコードをかなりそれっぽく書けます。
しかし、所有権を理解していない人がそのコードを触ると、次の瞬間に詰みます。
- なぜここで move されたのか分からない
- どこで clone すべきか判断できない
- 修正したら borrow checker に怒られる
- 一応直したけど無駄なコピーだらけになる
Rustではこの値を誰が持っているかを読む力が、そのまま保守力になります。
AI時代でもRustが難しい理由はここで、出力されたコードを読むために所有権の理解が不可欠なのです。
2. 借用は便利。でも好き放題の参照ではない
所有権だけだと不便なので、Rustには借用があります。
借用は、値の所有権を渡さずに参照だけ使う仕組みです。公式Bookでも、参照を作ることを borrowing と説明しています。
fn len(s: &String) -> usize {
s.len()
}
fn main() {
let s = String::from("hello");
let n = len(&s);
println!("{}", n);
println!("{}", s); // 所有権は移っていないので使える
}
ここまでは分かりやすいです。
しかしRustの本質はその先で、借用には同時利用のルールが存在します。
たとえば、ある時点において以下の制約があります。
- 不変参照は複数持てる
- しかし、可変参照は同時に1つだけ
- さらに、不変参照と可変参照は同時に共存できない
fn main() {
let mut s = String::from("hello");
let r1 = &s;
let r2 = &s;
// let r3 = &mut s; // ここはNG
println!("{}, {}", r1, r2);
}
なぜこれを理解すべきか
AIが出力するRustコードは、ちょっとした修正で急にコンパイル不能になることがあります。
その原因の大半は、文法ではなく借用関係の崩れです。
つまりRustでは、コードレビューのときにこの関数は何を所有して、何を借りて、どこで変更しているかを追えないと厳しいです。
逆にここが見えてくると、borrow checker に怒られたときも、Rustが意地悪をしているのではなく、可変性と共有を同時に許さない設計になっていると理解できるようになります。
3. ライフタイムは寿命を延ばす魔法ではない
Rust学習でよく誤解されるのがライフタイムです。
'a のような記法が出てくると、急に難しく見えます。
しかしライフタイムは、メモリを長生きさせるための記号ではありません。
Rust公式Bookでは、ライフタイムの主目的はダングリング参照を防ぐことだと説明されています。
つまりライフタイムは、この参照は参照先が有効な間しか生きられないという関係を型システムの中で表すためのものです。
fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
if x.len() > y.len() { x } else { y }
}
このコードで <'a> がやっているのは、文字列を延命することではありません。
返り値の参照が、引数たちとどういう関係にあるかを示しているだけです。
なぜこれを理解すべきか
AIにRustを書かせると、ライフタイムはかなり雑に扱われがちです。
- なくてもいいのに複雑なライフタイムを書く
- 必要な箇所で構造を整理せず、記法で押し切ろうとする
-
Stringを返すべきところで無理に&strを返そうとする
Rustで大事なのは、ライフタイム構文を増やすことではなく、参照で返すべきか、所有権を返すべきかを考えることです。
ライフタイムが難しく見えたら、まず記法ではなく設計を疑う。これはRustを書く上でかなり大事な感覚です。
4. Result と Option は面倒な包み紙ではない
Rustでは、失敗や値の不在が型に出てきます。
- 失敗しうる処理は
Result<T, E> - 値がないかもしれない処理は
Option<T>
これはかなり重要です。
Rust公式Bookでも、Result は成功 (Ok) か失敗 (Err) を表す列挙型として説明されています。
use std::fs::File;
fn main() -> Result<(), std::io::Error> {
let _file = File::open("hello.txt")?;
Ok(())
}
この ? は便利ですが、ただの省略記法ではありません。
エラーを呼び出し側へ伝播する設計を簡潔に書いているだけです。
なぜこれを理解すべきか
AIは unwrap() をかなり気軽に使います。
デモコードならまだしも、実務コードで雑に unwrap() が増えると危険です。
Rustに慣れている人は、Result を見たときに単に失敗する可能性があると認識するだけでなく、さらに一歩踏み込んで考えます。
- ここは呼び出し元に返すべきか
- ここで回復すべきか
-
panic!にしてよい場面か - エラー型をどう揃えるか
Option も同じです。値がないかもしれない状態を null ではなく型で表すので、雑に流せません。
AI時代にRustで大事なのは、他言語の例外処理の感覚を持ち込まないことです。
Rustは失敗や不在を、最初から型に出して設計する言語です。
5. trait はinterfaceに似ている。でも同じつもりで使わないほうがいい
Rustの trait は、最初は他言語のinterfaceに見えます。
trait Speak {
fn speak(&self) -> String;
}
struct Dog;
impl Speak for Dog {
fn speak(&self) -> String {
"wan".to_string()
}
}
確かにある振る舞いを型に要求するという意味では似ています。
しかしRustでは、trait は単なる抽象化だけでなく、ジェネリクス・静的ディスパッチ・制約表現と強く結びついています。公式Bookでも、ジェネリクスやtraitはコードの重複を減らしつつ抽象化する主要な仕組みとして説明されています。
なぜこれを理解すべきか
AIが生成するRustでは、traitの使い方が極端にOOP寄りになることがあります。
- 何でもtrait化する
- 動的ディスパッチ前提で設計する
- ジェネリクスで十分なところを
Box<dyn Trait>にする - 逆に柔軟性が必要なのに全部具体型で固定する
このあたりは、Rustらしさがかなり出るところです。
Rustでtraitを使うときは、抽象化したいのか、コンパイル時に最適化される形で制約をかけたいのか、実行時に差し替えたいのかを区別して考えたほうがいいです。
ここが曖昧だと、AIが書いたコードは見た目だけRustで、中身は他言語の発想の移植になりがちです。
6. Rc / Arc / RefCell / Mutex は、分かった気になった瞬間が危ない
Rustを書いていると、所有権だけでは表現しにくい場面が出てきます。
そこで出てくるのが Rc<T>、Arc<T>、RefCell<T>、Mutex<T> です。
これらを単なる便利なラッパーとして覚えると危険です。
たとえば公式Bookでは、RefCell<T> は interior mutability（内部可変性）のための仕組みとして説明されています。つまり、通常の借用ルールではなく、実行時に借用規則をチェックする形へ切り替える道具です。
また Rc<T> は単一スレッドでの共有所有、Arc<T> は複数スレッド向けの共有所有です。共有状態の並行処理では Arc<T> と Mutex<T> の組み合わせが典型になります。
なぜこれを理解すべきか
AIはこのあたりをコンパイルを通すための部品として使いがちです。
- とりあえず
Rc<RefCell<T>>にする - マルチスレッドだから何となく
Arc<Mutex<T>>で包む - 本来のデータ所有設計を見直さずラッパーで押し切る
これはRustでかなりありがちなアンチパターンです。
大事なのは、これらを呪文として覚えることではなく、なぜ普通の借用では表現できないのかを考えることです。
設計を見直すべきなのか、本当に共有所有が必要なのか、可変性をどこに置くべきなのか。
ここを考えずにラッパーを増やすと、Rustを書いているのにRustの恩恵を減らしてしまいます。
7. async と並行処理は、書けたことより安全に運べるかが大事
Rustで async / await を書けるようになると、一気にモダンなコードを書いている感覚になります。
公式Bookでも、async は Future を返し、.await で完了を待つ仕組みとして説明されています。
しかし、Rustの非同期や並行処理で本当に重要なのは、構文そのものよりもその値がスレッド間で送れるか、共有できるかです。
Rustonomicon では、Send は別スレッドへ安全に送れる型、Sync は複数スレッドから参照して安全な型と説明されています。
なぜこれを理解すべきか
AIは async fn を書くのは得意です。
しかし、得意なのは書き始めるところまでで、その先の深い部分になると一気に怪しくなります。
- なぜこのFutureは Send でないのか
- なぜ
tokio::spawnに乗らないのか - なぜ Rc が使えず Arc が必要なのか
- なぜロックをまたいで await するのが危ないのか
Rustの非同期は、見た目以上に所有権・借用・スレッド安全性の延長線上にあります。
そのため、asyncを別トピックとして切り離さず、Rustの基本概念の続きとして理解したほうが強いです。
8. AI時代にRustで本当に強い人は、全部書ける人より制約を読める人
ここまで読むと、Rustは人間がすべてを理解しないと無理なのかと思うかもしれません。
しかし実際はそうではありません。
AI時代にRustで強いのは、すべてをゼロから手で書ける人より、AIが出したコードの制約を読める人です。
つまり、以下のポイントを見抜けることが重要になります。
- どこで所有権が移るか
- どこで借用が衝突するか
- どこでライフタイムが絡むか
- どこで Result を返すべきか
- どこで共有所有やスレッド安全性が問題になるか
Rustは、なんとなく修正してなんとなく動かすより、型エラーやborrow checkerのメッセージを読んで設計を整えるほうが圧倒的に強いです。
まとめ
AIのおかげで、Rustコードのたたき台はかなり速く作れるようになりました。
しかしRustは、書けることよりもなぜその形でしか書けないのかを理解していることの価値がとても高い言語です。
だからこそ、AI時代にRustで理解しておくべきなのは、細かい構文暗記よりも次の土台です。
- 所有権はRustの中心
- 借用は自由な参照ではない
- ライフタイムは参照関係の整合性
- Result / Option は型で失敗や不在を表す設計
- trait は単なるinterface置き換えではない
- Rc / Arc / RefCell / Mutex は設計の逃げ道ではなく意味を持つ
- async や並行処理は Send / Sync を含めて読む必要がある
Rustは、表面的なコードだけ見ると難しそうに見えます。
しかし実際には、ルールが厳しいぶん、設計の意図がコードに出やすい言語でもあります。
AIにコードを書かせる時代だからこそ、Rustのコードを全部手で書けること以上に、この制約は何を守っているのかを読めることの価値が高いと感じています。
おまけ: Rustを学ぶときのおすすめ順
Rustを学ぶときは、文法を順番に追うより、次の順で理解するとかなり楽になります。
- 所有権
- 借用と可変参照
-
String/&strの違い -
Option/Result - trait とジェネリクス
-
Rc/Arc/RefCell/Mutex -
async/await -
Send/Sync
この順で見ていくと、AIが出力したRustコードを見たときに、どこが本質で、どこが単なる記法かがかなり分かるようになります。
最後に
もしRustを手を動かしながら体系的に学びたい方がいれば、以下の講座一覧も参考にしてみてください。
すべて演習型で、実際に書きながら進められる構成になっています。（割引価格で受講できるリンクです）
Udemy講座一覧