Rustのライフタイム超入門！基本からエラー解決まで徹底解説

Rustを学んでいると、まるでラスボスのように立ちはだかるライフタイム。アポストロフィが付いた謎の記号 `'a` や、コンパイラからの厳しいメッセージに、心が折れそうになる瞬間、ありますよね？

この記事では、Rustのライフタイムが「なぜ存在するのか」という根本的な理由から、具体的な書き方、関数や構造体での使い方、そして誰もが一度は遭遇するであろう「あのエラー」の解決策まで、順を追って解説していきます。

この記事で学べること

• ライフタイムの基本的な考え方と、その必要性
• ライフタイムアノテーション（`'a`みたいなの）の書き方
• 関数や構造体でライフタイムを指定する方法
• よくあるライフタイムエラーの原因と解決のヒント
• ライフタイム指定を省略できる便利なルール

読み終わる頃には、「なるほど、ライフタイムってそういうことか！」と、コンパイラさんと少し仲良くなれているはず。

Rustのライフタイムとは？なぜ必要なの？

まず、ライフタイムって一体何者なんでしょう？

簡単に言うと、ライフタイムは「参照（データを直接持っているのではなく、場所だけを指し示しているもの）が、どれくらいの期間有効なのか」をコンパイラに教えるための目印のようなものです。

「なんでそんな目印が必要なの？」と思いますよね。

それは、Rustがメモリ安全をすごく気にしている言語だからです。他の言語だと、うっかり存在しないデータや、すでに片付けられてしまったデータの場所を指し示してしまう参照（これをダングリングポインタと言います）を作ってしまうことがあります。これは、予期せぬクラッシュやバグの大きな原因になります。

Rustでは、コンパイラがこのライフタイムの情報を元に、「この参照は、参照先のデータが存在している間だけ使われているかな？」を厳しくチェックしてくれます。

まるで、図書館で本を借りるときに「この本は貸出期間中ですよ」と教えてくれるシステムみたいですね。このチェックのおかげで、私たちは意図せず危険な参照を使ってしまうことから守られているのです。

Rustくん、ありがとう！

ライフタイムを理解する - 所有権と参照（Borrowing）

ライフタイムの話をする前に、Rustの基本的なルールである「所有権」と「参照（借用）」について、軽くおさらいしておきましょう。

忘れてしまった方も、初めての方も、ここを押さえておくとライフタイムの理解がぐっと楽になりますよ。

• 所有権
  Rustでは、全ての値に「所有者」と呼ばれる変数が存在します。原則として、所有者は1つだけで、所有者がスコープ（有効範囲）から外れると、値は自動的にメモリから片付けられます。
• 参照（借用）
  値の所有権を移動させずに、その値を使いたい場合に「参照」を使います。これは、データを「借りてくる」イメージです。参照には、変更可能な参照（`&mut`）と、変更不可能な参照（`&`）があります。

ライフタイムは、この「借りてきた」参照が、元のデータ（所有者が持っているデータ）が存在している期間内で、ちゃんと使われているかを保証するための仕組み、というわけです。

借りた本は、図書館が開いているうちに返さないといけませんよね？それと同じ感覚です。

Rustのライフタイムの基本的な書き方 - ライフタイムアノテーション

では、実際にライフタイムをどうやってコードに書くのか見ていきましょう。

ライフタイムを指定するには、ライフタイムアノテーションという特別な記法を使います。

見た目はこんな感じです。

'a

'b

'document

アポストロフィ（`'`）に続けて、小文字の名前（慣習的に`a`や`b`が使われることが多いですが、意味のある名前も付けられます）を書きます。

「ジェネリクスの型パラメータ（``みたいなの）に似てる？」と思った方、鋭い！

見た目は似ていますが、ライフタイムアノテーションは型ではなく、参照が有効な「期間（スコープ）」を表すためのもの、という点が異なります。

最初は「なんだこれ？」と思うかもしれませんが、まずは「ふーん、こういう書き方をするんだな」と、形だけ覚えておけばOKです。実際にどう使うかは、これから見ていきましょう。

Rustのライフタイムの使い方① 関数におけるライフタイム

ライフタイムアノテーションが活躍する場面の一つが、関数です。特に関数が参照を引数に取ったり、参照を返り値として返したりする場合に登場します。

なぜ関数でライフタイム指定が必要になることがあるのでしょうか？

それは、関数に渡される参照や、関数から返される参照が、どれくらいの期間有効なのか、コンパイラだけでは判断できない場合があるからです。

例えば、2つの参照を受け取って、そのうちの1つを返すような関数を考えてみてください。コンパイラは、返される参照が、入力された2つの参照のうち、どちらのライフタイム（有効期間）と同じ長さを持つべきなのかを知る必要があります。

そういう時に、私たちがライフタイムアノテーションを使って「この返り値のライフタイムは、この引数のライフタイムと同じだよ！」と教えてあげるのです。

【サンプルコード】参照を返す関数のライフタイム指定

百聞は一見にしかず！具体的なコードで見てみましょう。

ここでは、2つの文字列スライス（`&str`）を受け取り、文字数が長い方のスライスを返す関数`longest`を作ってみます。

まず、ライフタイムを指定しないとどうなるか…

// これはコンパイルエラーになります！
fn longest(x: &str, y: &str) -> &str {
    if x.len() > y.len() {
        x
    } else {
        y
    }
}

fn main() {
    let string1 = String::from("long string is long");
    let result;
    {
        let string2 = String::from("xyz");
        result = longest(string1.as_str(), string2.as_str());
    } // string2 はここでスコープを抜けて無効になる
    // println!("The longest string is {}", result); // ここで result を使おうとすると問題が…
}

このコードをコンパイルしようとすると、Rustコンパイラは「返り値の参照（`&str`）が、引数`x`と`y`のどちらのライフタイムに関連付いているのか分からないよ！」とエラーを出します。（`missing lifetime specifier` のようなエラーです）

そこで、ライフタイムアノテーションの出番です！

// ライフタイム 'a を指定してコンパイルを通す
fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() {
        x
    } else {
        y
    }
}

fn main() {
    let string1 = String::from("long string is long");
    let result;
    {
        let string2 = String::from("xyz");
        // longest 関数に渡される参照 x と y は、'a という共通のライフタイムを持つ必要がある。
        // この場合、'a は string1 と string2 の両方が有効な期間、
        // つまり内側のスコープ {} の期間となる。
        result = longest(string1.as_str(), string2.as_str());
        println!("Inside inner scope, longest is: {}", result); // これはOK
    } // string2 はここでスコープを抜ける

    // ↓ この行をコメントアウト解除するとコンパイルエラーになる！
    // println!("The longest string is {}", result);
    // なぜなら、result が参照しているかもしれない string2 はもう存在しないから。
    // longest 関数のライフタイム指定により、result のライフタイム 'a は
    // string2 が有効な期間（内側のスコープ）に制限されるため。

    // string1 のライフタイムは main 関数の終わりまで続く
    let string3 = String::from("another long one");
    let result2 = longest(string1.as_str(), string3.as_str());
    println!("Using only longer-lived references: {}", result2); // これはOK
}

【解説】

• fn longest<'a>(...): 関数名`longest`の後に`<'a>`を付けて、ライフタイムパラメータ`'a`を宣言します。
• x: &'a str, y: &'a str: 引数`x`と`y`の参照が、どちらもライフタイム`'a`を持つことを示します。
• -> &'a str: 返り値の参照も、同じライフタイム`'a`を持つことを示します。

重要なのは、この `'a` が「入力された参照のうち、短い方のライフタイムと同じ期間だけ、返り値の参照も有効だよ」とコンパイラに伝えていることです。

関数から返された参照が、うっかり無効なデータを指してしまう事故を防いでくれます。

Rustのライフタイムの使い方② 構造体におけるライフタイム

関数だけでなく、構造体（struct）の定義でもライフタイムアノテーションが必要になることがあります。

それは、構造体のフィールド（メンバ変数）が参照を持つ場合です。

なぜ構造体にもライフタイムが必要なのでしょう？

考えてみれば自然なことで、構造体のインスタンス（実体）が存在している間は、そのフィールドが指し示しているデータもちゃんと存在していてほしいですよね。

構造体インスタンスより先に、参照先のデータが消えてしまったら、そのフィールドは宙ぶらりんの危険な参照になってしまいます。

そのため、構造体定義にライフタイムアノテーションを付けて、「この構造体のインスタンスは、フィールドが参照しているデータが有効な期間（ライフタイム）と同じか、それより短い期間だけ存在できるよ」とコンパイラに教える必要があります。

【サンプルコード】参照を持つ構造体のライフタイム指定

では、文字列スライスへの参照をフィールドに持つ構造体`ImportantExcerpt`を例に見てみましょう。

ライフタイム指定がないと… やっぱりエラー！

// これはコンパイルエラー！
// struct ImportantExcerpt {
//     part: &str, // 参照フィールドにはライフタイム指定が必要
// }

// fn main() {
//     let novel = String::from("Call me Ishmael. Some years ago...");
//     let first_sentence = novel.split('.').next().expect("Could not find a '.'");
//     let i = ImportantExcerpt {
//         part: first_sentence,
//     };
// }

ライフタイムを指定して修正！

// 構造体定義とフィールドにライフタイム 'a を指定
struct ImportantExcerpt<'a> {
    part: &'a str,
}

fn main() {
    let novel = String::from("Call me Ishmael. Some years ago...");
    let first_sentence = novel.split('.') // novel を '.' で分割
                          .next()      // 最初の部分を取得 (Option<&str>)
                          .expect("Could not find a '.'"); // Optionから値を取り出す

    // 構造体のインスタンスを作成
    let i = ImportantExcerpt {
        part: first_sentence, // first_sentence は novel の一部への参照
    };

    // i (構造体インスタンス) が有効な間は、
    // i.part (参照フィールド) が指すデータ (novelの一部) も有効でなければならない。
    // ライフタイム指定 'a により、この関係が保証される。
    println!("Excerpt part: {}", i.part);

    // もし novel より先に i がスコープを抜けるなら問題ない。
    // しかし、novel が先にスコープを抜けてしまうと、i.part が無効な参照を指す可能性があり、
    // コンパイラがエラーを出す（ライフタイムのチェックのおかげ！）。
}

【解説】

• struct ImportantExcerpt<'a> { ... }: 構造体名の後に`<'a>`を付けて、ライフタイムパラメータを宣言します。
• part: &'a str,: 参照を持つフィールド`part`の型にも、同じライフタイム`'a`を指定します。

これで、「`ImportantExcerpt`インスタンスの有効期間（ライフタイム）は、フィールド`part`が参照している文字列スライス（`&str`）の有効期間（ライフタイム`'a`）を超えることはないよ」とコンパイラに伝えることができます。

Rustのライフタイム - 省略できるケース（ライフタイム省略規則）

ここまで見てきて、「毎回こんなアポストロフィを書かないといけないの？面倒…」と思った方もいるかもしれません。ご安心ください！

Rustのコンパイラはとても賢くて、よくあるパターンについては、私たちが明示的にライフタイムを書かなくても、文脈から自動的にライフタイムを推論してくれる機能があります。これをライフタイム省略規則（Lifetime Elision Rules）と呼びます。

いくつかの省略規則がありますが、特に重要なのは関数に関する以下の3つのルールです。

1. 入力ライフタイムルール
   参照である各引数には、それぞれ異なるライフタイムパラメータが割り当てられます。
   例： `fn func(x: &i32, y: &str)` は `fn func<'a, 'b>(x: &'a i32, y: &'b str)` のように解釈されます。
2. 第1ルール（入力が1つの場合）
   入力ライフタイムが1つだけの場合、そのライフタイムが出力ライフタイム（返り値の参照のライフタイム）にも割り当てられます。
   例： `fn func(x: &i32) -> &i32` は `fn func<'a>(x: &'a i32) -> &'a i32` のように解釈されます。
3. 第2ルール（入力に `&self` や `&mut self` がある場合）
   複数の入力ライフタイムがあっても、その中に`&self`または`&mut self`（メソッドの第一引数）が含まれていれば、`self`のライフタイムが出力ライフタイムに割り当てられます。
   例： `fn method(&self, y: &str) -> &str` は `fn method<'a, 'b>(&'a self, y: &'b str) -> &'a str` のように解釈されます。

これらのルールのおかげで、多くのシンプルなケースでは、私たちはライフタイムを意識せずにコードを書くことができます。

例えば、引数を1つ取ってその参照をそのまま返すような関数では、ライフタイム指定は不要です。

// ライフタイム省略規則のおかげで、'a を書かなくてもOK！
fn first_word(s: &str) -> &str {
    let bytes = s.as_bytes();

    for (i, &item) in bytes.iter().enumerate() {
        if item == b' ' {
            return &s[0..i];
        }
    }

    &s[..]
}

fn main() {
    let my_string = String::from("hello world");
    let word = first_word(&my_string); // my_stringへの参照を渡す
    println!("the first word is: {}", word);
}

コンパイラが推論できない、もっと複雑な場合（先ほどの`longest`関数の例など）にのみ、私たちが明示的にライフタイムを書いてあげる必要がある、というわけですね。賢い！

Rustのライフタイムでよくあるエラーと解決策

さて、ライフタイムを学んでいると、どうしても避けて通れないのがコンパイルエラーです。特に、あの有名なエラーメッセージ…！

`borrowed value does not live long enough` （借りてきた値が十分に長く生存しません）

このエラーが出ると、「うわ、またか…」と頭を抱えたくなりますよね。

でも、このエラーはライフタイムの仕組みがちゃんと働いている証拠でもあります。危険な参照を作り出す前に、コンパイラが未然に防いでくれているのです。

このエラーが出る主な原因は、参照（借りているもの）が、参照先のデータ（貸主）よりも長く生き残ろうとしているケースです。

例えば、

• 関数の中で作られた一時的な値への参照を、関数の外に返そうとした。
• あるスコープで作られたデータへの参照を、そのスコープの外で使おうとした。

といった状況で発生します。

解決策は状況によりますが、考えられるアプローチはいくつかあります。

• 参照ではなく、データの所有権を移動させる（値を直接返す）。
• 参照ではなく、データをコピー（`.clone()`など）して、独立した値を作る。
• 参照を使っているコードのスコープを、参照先のデータが有効なスコープの内側に収める。
• ライフタイムアノテーションを使って、参照間の生存期間の関係をコンパイラに正しく教える。

エラー例：「borrowed value does not live long enough」

具体的なコードで、このエラーが発生する典型的なパターンと、その考え方を見てみましょう。

ダメな例：関数からローカル変数の参照を返す

// これはコンパイルエラー！ "borrowed value does not live long enough"
// fn dangle() -> &String { // 返り値は String への参照
//     let s = String::from("hello"); // s は dangle 関数の中だけで有効
//     &s // s への参照を返そうとしている
// } // ここで s はスコープを抜けて破棄される！

fn main() {
    // let reference_to_nothing = dangle();
}

【なぜダメなのか？】
関数`dangle`の中で作られた`String`型の変数`s`は、関数`dangle`が終わると同時にメモリから片付けられてしまいます。それなのに、関数はその`s`への参照（場所情報）を返そうとしています。関数が終わった後、返された参照が指し示す先には、もう何もない（かもしれない）危険な状態！Rustコンパイラはこれを見逃しません。

【どうすればいい？】
この場合、参照を返すのをやめて、データの所有権そのものを返すのが正解です。

// 解決策：参照ではなく、String そのものを返す
fn no_dangle() -> String { // 返り値の型を &String から String に変更
    let s = String::from("hello");
    s // s の所有権を関数の呼び出し元に移動させる
}

fn main() {
    let s_owner = no_dangle(); // s_owner が String の所有者になる
    println!("{}", s_owner);
}

エラーが出たときは、参照（`&`）と、その参照が指している先のデータの実体が、それぞれ「いつまで存在するのか（スコープ）」を意識するのが解決の糸口になります。[ここにスコープを図示したイメージを入れると分かりやすいです]

Rustのライフタイムに関する注意点

ライフタイムについて、もう少し知っておくと良い点をいくつか補足します。

`'static` ライフタイム

`'static` という特別なライフタイムがあります。これは、プログラムの実行期間全体を通して有効な参照を示すときに使われます。