【C++】unique_ptrを引数として渡す方法とベストプラクティス

2026年3月1日

C++においてメモリ管理の安全性と効率性を両立させるために欠かせないのが、スマートポインタの一つであるstd::unique_ptrです。

しかし、このポインタは「コピーができない」という特性を持つため、関数へ引数として渡す際に戸惑う開発者が少なくありません。

本記事では、std::unique_ptrを引数として渡すためのさまざまな手法を網羅し、どのようなシーンでどの方法を選択すべきかというベストプラクティスを詳しく解説します。

所有権の移動、借用、そしてパフォーマンスの観点から、モダンC++におけるリソース管理の真髄を紐解いていきましょう。

目次 [ close ]

unique_ptrの基本概念と所有権のルール

std::unique_ptrを正しく扱うためには、まずその根本的な性質である「排他的な所有権(Exclusive Ownership)」を理解する必要があります。

所有権の移動(std::move)

std::unique_ptrは、コピーコンストラクタとコピー代入演算子が削除(delete)されています。

これにより、あるリソースに対して複数のunique_ptrが同時に責任を持つという状況をコンパイルレベルで防いでいます。

リソースを別の場所に渡したい場合は、std::moveを使用して所有権を移動(ムーブ)させる必要があります。

ムーブが行われると、元のポインタは空(nullptr)になり、移動先のポインタがそのリソースを管理する唯一の存在となります。

なぜ「渡し方」が重要なのか

関数にunique_ptrを渡す際、単に「ポインタを渡す」といっても、その目的は多岐にわたります。

関数にリソースの管理責任を完全に引き継がせたい(譲渡)
関数内で一時的にリソースを使いたいだけ(借用)
リソースの中身を書き換えたい、あるいは読み取りたいだけ

これらの目的に応じて適切な渡し方を選択しないと、不要なムーブが発生したり、コードの可読性が低下したりする原因になります。

unique_ptrを引数として渡す4つの主要パターン

C++において、スマートポインタを関数に渡す方法は主に4つのパターンに分類されます。

それぞれの書き方と挙動を詳しく見ていきましょう。

1. 値渡しによる所有権の譲渡(Sinks)

関数が引数としてstd::unique_ptr<T>を値で受け取る場合、それは「所有権の譲渡(消費)」を意味します。

これを一般に「シンク(Sink)関数」と呼びます。

サンプルコード：値渡し

C++

#include <iostream>
#include <memory>
#include <utility>

class Resource {
public:
    Resource() { std::cout << "リソースを確保しました\n"; }
    ~Resource() { std::cout << "リソースを解放しました\n"; }
    void do_something() { std::cout << "リソースを使用中...\n"; }
};

// 所有権を受け取る関数 (Sink)
void consume_resource(std::unique_ptr<Resource> res) {
    std::cout << "--- 関数内に入りました ---\n";
    res->do_something();
    std::cout << "--- 関数を終了します ---\n";
    // ここで res がスコープを抜け、リソースが解放される
}

int main() {
    auto my_res = std::make_unique<Resource>();

    std::cout << "関数を呼び出します\n";
    // std::move が必須。コピーはできない。
    consume_resource(std::move(my_res));

    if (!my_res) {
        std::cout << "呼び出し元の my_res は空になりました\n";
    }

    return 0;
}

実行結果

リソースを確保しました
関数を呼び出します
--- 関数内に入りました ---
リソースを使用中...
--- 関数を終了します ---
リソースを解放しました
呼び出し元の my_res は空になりました

このパターンは、その関数がリソースを「最後まで責任を持って処理する」場合に使用します。

呼び出し側は、関数に渡した後はそのオブジェクトを二度と使用しないことが保証されます。

2. 生ポインタ(T*)による参照(借用)

実は、モダンC++において最も推奨される「単に中身を使いたいだけ」の場合の渡し方は、unique_ptrそのものを渡すのではなく、生ポインタ(Raw Pointer)を渡す方法です。

サンプルコード：生ポインタ渡し

C++

#include <iostream>
#include <memory>

class Gadget {
public:
    void perform() { std::cout << "ガジェットが動作しています\n"; }
};

// unique_ptr ではなく、生ポインタで受け取る
void observe_gadget(Gadget* g) {
    if (g) {
        g->perform();
    }
}

int main() {
    auto my_gadget = std::make_unique<Gadget>();

    // get() メソッドを使用して生ポインタを渡す
    // 所有権は移動しない
    observe_gadget(my_gadget.get());

    if (my_gadget) {
        std::cout << "呼び出し元の my_gadget は依然として有効です\n";
    }

    return 0;
}

実行結果

ガジェットが動作しています
呼び出し元の my_gadget は依然として有効です

この方法は、unique_ptrだけでなくshared_ptrやスタック上のオブジェクトに対しても共通のインターフェースを提供できるため、関数の汎用性が極めて高くなります。

また、スマートポインタのオーバーヘッドを完全に回避できます。

3. 参照(T&)によるアクセス

もし対象のリソースが「必ず存在すること(nullptrではないこと)」が保証されているのであれば、生ポインタよりも参照(T&)で渡すのがベストです。

サンプルコード：参照渡し

C++

#include <iostream>
#include <memory>

void use_strictly(int& value) {
    value += 10;
}

int main() {
    auto num = std::make_unique<int>(5);

    // デリファレンスして参照として渡す
    use_strictly(*num);

    std::cout << "更新後の値: " << *num << "\n"; // 15
    return 0;
}

実行結果

更新後の値: 15

この記法は、呼び出し側でnullptrチェックを済ませていることを暗黙的に示します。

関数内部でif (ptr != nullptr)のようなチェックを記述する必要がなくなり、コードがスッキリします。

4. unique_ptrの参照渡し(非推奨なケースと例外)

初心者の方がよくやってしまうのが、void func(std::unique_ptr<T>& res)のように、スマートポインタそのものを参照渡しすることです。

これは特定の状況を除いてアンチパターンとされています。

渡し方	意味・用途	評価
`const std::unique_ptr<T>&`	読み取り専用で借用する	非推奨。生ポインタ(`T*`)の方が汎用的です。
`std::unique_ptr<T>&`	関数内で中身を「入れ替える」可能性がある場合	限定的に許可。リセットや再代入が必要な場合のみ。

なぜ const std::unique_ptr<T>& は避けるべきか

この形式で引数を受け取ると、その関数は「std::unique_ptrで管理されているオブジェクト」しか受け取れなくなります。

もしスタック上の変数や、別の管理方式のオブジェクトを渡したくなった場合、関数を書き直さなければなりません。

unique_ptrの参照渡しが適切なケース

一方で、以下のように「ポインタが指す先を書き換える(リセットする)」ことが目的の場合は、参照渡しが適切です。

C++

void reset_resource(std::unique_ptr<Resource>& res) {
    // 既存のリソースを捨てて新しいものに入れ替える
    res = std::make_unique<Resource>();
}

デザインパターン別の使い分けガイド

開発シーンに合わせてどの方法を選ぶべきか、以下のフローを参考にしてください。

シンク(Sink)パターン

関数内でそのオブジェクトの寿命が尽きる、あるいはクラスのメンバ変数として所有権を完全に保管する場合に使用します。

推奨： std::unique_ptr<T> の値渡し

オブザーバー(Observer)パターン

関数内でオブジェクトを一時的に利用するだけで、所有権には関与しない場合に使用します。

推奨： T* または T&

ファクトリ(Factory)パターン

リソースを生成して呼び出し元に返す場合、戻り値としてunique_ptrを使用します。

C++

std::unique_ptr<Resource> create_resource() {
    auto res = std::make_unique<Resource>();
    // ... 初期化処理 ...
    return res; // C++11以降、戻り値でのmoveは自動的に最適化される(NRVO)
}

よくある間違いとトラブルシューティング

moveし忘れによるコンパイルエラー

最も頻発するのが、std::moveを忘れて直接unique_ptrを渡そうとすることです。

C++

auto ptr = std::make_unique<int>(10);
process(ptr); // エラー！コピー不可
process(std::move(ptr)); // OK

コンパイルエラーメッセージに「deleted function」や「copy constructor」といった単語が含まれていたら、このミスを疑いましょう。

関数呼び出し後の「ダングリングポインタ」

生ポインタを渡す場合、そのポインタが指しているオブジェクトの寿命を呼び出し側が保証しなければなりません。

C++

void async_process(Resource* res) {
    // 非同期で res を使うと、呼び出し元が先に破棄される可能性がある
}

このような非同期処理が絡む場合は、unique_ptrではなく、所有権を共有できるstd::shared_ptrの検討が必要になります。

const の付け方に注意

リソースの中身を変更させたくない場合は、ポインタではなく指す先の型にconstを付けます。

void func(const Resource* res) : 中身を書き換えられない
void func(Resource* const res) : ポインタのアドレスを書き換えられない(あまり意味がない)

モダンC++における視点

現在のC++開発においては、「所有権のセマンティクス(意図)」をコードで表現することが重視されています。

インターフェースの純粋性: 関数が必要としているのは「データ」なのか「データの管理権」なのかを明確に分けます。
パフォーマンス: スマートポインタのコピー(shared_ptrの場合)やムーブは、生ポインタの受け渡しに比べれば僅かながらコストがかかります。

極限のパフォーマンスを求める領域では、関数の引数は極力生ポインタや参照に倒すのが定石です。
静的解析の活用: 最近のコンパイラや静的解析ツール(Clang-Tidyなど)は、const std::unique_ptr<T>&のような非効率な記述を自動で検知し、改善を促してくれます。

まとめ

std::unique_ptrを引数として渡す際のルールは、シンプルに整理すると「所有権を移すなら値渡し、使いたいだけなら生ポインタ/参照」に集約されます。

値渡し: 所有権の譲渡。呼び出し元は空になる。
**生ポインタ(T*):** 借用。nullptrの可能性がある場合に最適。
**参照(T&):** 借用。nullptrでないことが確実な場合に最適。
**unique_ptrの参照渡し:** 特殊なケース(ポインタ自体の差し替え)のみ。

これらの原則を守ることで、メモリリークや二重解放といったバグを未然に防ぐだけでなく、他の開発者にとっても「この関数がリソースをどう扱うのか」が一目でわかる、美しく堅牢なC++コードを書くことができるようになります。

適切な渡し方をマスターし、スマートポインタを最大限に活用していきましょう。