C++でマルチスレッドプログラミングや非同期処理を記述する際、オブジェクトが自分自身の共有ポインタ(shared_ptr)を安全に配布したい場面が多々あります。
しかし、安易にthisポインタからshared_ptrを生成してしまうと、二重解放によるクラッシュを招く危険性があります。
これを安全に解決する仕組みがstd::enable_shared_from_thisです。
本記事では、このクラスが必要な理由から、内部構造、具体的な実装パターン、そして開発者が陥りやすい注意点までを、現在のモダンなC++の視点で徹底的に解説します。
なぜenable_shared_from_thisが必要なのか
C++のメモリ管理において、std::shared_ptrは非常に強力なツールです。
しかし、クラスのメンバ関数内で「自分自身を指すshared_ptr」を他の関数やコールバックに渡したい場合、単純な実装では深刻なバグを引き起こします。
まずは、この仕組みが必要とされる背景を理解しましょう。

二重解放の恐怖
通常、std::shared_ptrは「コントロールブロック」と呼ばれる管理領域を共有することで、一つのオブジェクトの寿命を管理します。
しかし、メンバ関数内でstd::shared_ptr<T>(this)のように記述してしまうと、既存の管理領域を無視して新しいコントロールブロックを作成してしまいます。
この結果、同じオブジェクトに対して複数の独立した管理者が存在することになり、一方の参照カウントがゼロになった時点でオブジェクトが破棄されます。
もう一方の管理者は、すでに破壊されたメモリ領域を管理し続けることになり、最終的に二重解放(Double Free)が発生してプログラムは異常終了します。
安全に自身のポインタを配布する
std::enable_shared_from_thisを継承すると、オブジェクトは内部的に「自分がどのように管理されているか」という情報を保持できるようになります。
これにより、メンバ関数内でshared_from_this()を呼び出すことで、既存のコントロールブロックを共有する正しいshared_ptrを取得することが可能になります。
基本的な使い方と実装例
使い方は非常にシンプルです。
自身のクラスを定義する際、std::enable_shared_from_thisを基底クラスとして継承します。
このとき、CRTP(Curiously Recurring Template Pattern)と呼ばれる手法を用い、テンプレート引数に自分自身のクラス名を指定するのがポイントです。

実装のコードサンプル
以下のコードは、メンバ関数内で自分自身のshared_ptrを取得し、外部のレジストリに登録する例です。
#include <iostream>
#include <memory>
#include <vector>
// 1. enable_shared_from_thisを継承する。テンプレート引数に自クラスを指定。
class MyComponent : public std::enable_shared_from_this<MyComponent> {
public:
MyComponent(int id) : id_(id) {
std::cout << "Component " << id_ << " created." << std::endl;
}
~MyComponent() {
std::cout << "Component " << id_ << " destroyed." << std::endl;
}
void registerTo(std::vector<std::shared_ptr<MyComponent>>& registry) {
// 2. shared_from_this() を使用して安全に自身のshared_ptrを取得する
// 決して shared_ptr<MyComponent>(this) と書いてはいけない
registry.push_back(shared_from_this());
}
void printInfo() const {
std::cout << "I am component " << id_ << std::endl;
}
private:
int id_;
};
int main() {
std::vector<std::shared_ptr<MyComponent>> globalRegistry;
{
// 3. 必ずshared_ptrとしてインスタンス化する必要がある
auto comp = std::make_shared<MyComponent>(1);
// メンバ関数を通じて自身を登録
comp->registerTo(globalRegistry);
std::cout << "Object count: " << comp.use_count() << std::endl;
} // ここで comp はスコープを抜けるが、globalRegistryが参照を保持しているため生存
std::cout << "After scope end..." << std::endl;
for (const auto& item : globalRegistry) {
item->printInfo();
}
return 0;
}
Component 1 created.
Object count: 2
After scope end...
I am component 1
Component 1 destroyed.
このプログラムでは、スコープ内で生成されたcompが、メンバ関数registerToを経由して自分自身をglobalRegistryに渡しています。
shared_from_this()を使用しているため、参照カウントが正しくインクリメントされ、スコープを抜けた後もオブジェクトが生存し続けていることが確認できます。
内部メカニズム:どのように実現しているのか
なぜ継承するだけでこのような魔法が使えるのでしょうか。
その秘密は、std::enable_shared_from_thisが内部に隠し持っているstd::weak_ptrにあります。
コントロールブロックとの連携

具体的には、オブジェクトが最初にstd::shared_ptrによって管理される際、そのshared_ptrのコンストラクタ(あるいはstd::make_shared内部)が、対象オブジェクトがenable_shared_from_thisを継承しているかをチェックします。
もし継承していれば、内部のweak_ptrに自分を管理しているコントロールブロックの情報をセットします。
以降、shared_from_this()が呼ばれるたびに、このweak_ptrからshared_ptrを生成して返すことで、既存の管理情報を引き継いだポインタを提供できるのです。
避けては通れない致命的な注意点
enable_shared_from_thisは便利ですが、誤った使い方をすると実行時に例外(std::bad_weak_ptr)が発生し、プログラムが停止します。
特に初心者が陥りやすいポイントが2つあります。
1. shared_ptrで管理されていないオブジェクトでの呼び出し
shared_from_this()が成功するためには、そのオブジェクト自体が既にshared_ptrによって所有されている必要があります。
| インスタンス化の方法 | shared_from_this() の成否 | 理由 |
|---|---|---|
std::make_shared<T>() | 成功 | コントロールブロックが作成されるため |
std::shared_ptr<T>(new T()) | 成功 | コントロールブロックが作成されるため |
T obj; (スタック) | 失敗 | 管理するshared_ptrが存在しないため |
T* ptr = new T(); | 失敗 | 生ポインタのみでは管理されないため |
スタック上に確保されたオブジェクトや、newしただけの生ポインタに対してshared_from_this()を呼び出すと、内部のweak_ptrが未初期化状態であるため、例外がスローされます。
2. コンストラクタ内での使用禁止
これは非常に多いミスです。
コンストラクタの中でshared_from_this()を呼び出すことはできません。
なぜなら、コンストラクタが実行されている最中は、まだそのオブジェクトを管理するshared_ptrの生成が完了していないからです。
オブジェクトの生成が完了し、そのアドレスがshared_ptrに渡された後に初めて内部のweak_ptrが有効になります。
コンストラクタ内での初期化処理で自身を登録したい場合は、後述するファクトリメソッドパターンを利用する必要があります。
ベストプラクティス:ファクトリメソッドの導入
前述のミスを防ぐ最も確実な方法は、コンストラクタをprivateにし、専用の生成関数(ファクトリメソッド)を用意することです。
これにより、利用者が誤ってスタック上にオブジェクトを作ったり、生ポインタで管理したりすることをコンパイルレベルで禁止できます。

堅牢なクラス設計の例
#include <iostream>
#include <memory>
class SafeComponent : public std::enable_shared_from_this<SafeComponent> {
private:
// コンストラクタをprivateにすることで、
// 直接的なインスタンス化を禁止する
SafeComponent(int value) : value_(value) {}
public:
// 静的な生成用メソッド
static std::shared_ptr<SafeComponent> create(int value) {
// std::make_sharedはprivateコンストラクタにアクセスできない場合があるため、
// 構造によっては new を使った shared_ptr 生成が必要になることもある
// ここでは、単純なフレンド指定や構造上の工夫で対応する
return std::shared_ptr<SafeComponent>(new SafeComponent(value));
}
void doSomething() {
auto self = shared_from_this();
std::cout << "Safe processing: " << self->value_ << std::endl;
}
private:
int value_;
};
int main() {
// auto comp = SafeComponent(10); // コンパイルエラー!
// 常にshared_ptrとして生成されることが保証される
auto comp = SafeComponent::create(10);
comp->doSomething();
return 0;
}
C++17以降の新機能:weak_from_this()
モダンなC++(C++17以降)では、shared_from_this()に加えてweak_from_this()というメンバ関数が追加されました。
従来、weak_ptrが必要な場合でも一度shared_from_this()でshared_ptrを作り、それをweak_ptrに変換するという無駄なステップ(参照カウントの一時的な加算)が必要でした。
weak_from_this()を使えば、参照カウントを操作せずに直接weak_ptrを取得できます。
循環参照を防止する非同期処理
非同期タスクに自分自身をキャプチャさせる場合、shared_ptrで渡してしまうと、タスクが完了するまでオブジェクトが絶対に解放されません。
オブジェクトの生存期間をタスクに強制したくない(オブジェクトが死んでいたらタスクを中止したい)場合は、weak_ptrを渡すのが定石です。
void SafeComponent::startAsyncTask() {
// C++17以降なら weak_from_this() が使える
std::weak_ptr<SafeComponent> weakSelf = weak_from_this();
// 疑似的な非同期コールバックの登録
auto callback = [weakSelf]() {
// オブジェクトがまだ生きているか確認
if (auto self = weakSelf.lock()) {
std::cout << "Async task: Object is still alive. Value = " << self->value_ << std::endl;
} else {
std::cout << "Async task: Object was already destroyed." << std::endl;
}
};
// 本来はここでスレッドやタイマーにcallbackを渡す
callback();
}
まとめ
std::enable_shared_from_thisは、C++におけるオブジェクトの自己所有管理を安全に行うための必須コンポーネントです。
特に非同期処理やイベント駆動型の設計においては、オブジェクトの寿命とポインタの整合性を保つために極めて重要な役割を果たします。
今回の重要ポイントを振り返りましょう。
- 二重解放を防ぐ
thisから直接shared_ptrを作らず、共通のコントロールブロックを利用する。- 継承とCRTP
public std::enable_shared_from_this<T>として継承する。- 利用条件に注意
必ず
shared_ptrで管理された状態で呼び出す。コンストラクタ内は厳禁。
- ファクトリメソッド
安全性を高めるため、生成専用の
static関数を用意する。- weak_from_this
循環参照を防ぎたい非同期処理では、C++17以降のこの機能が有効。
これらの原則を守ることで、メモリリークや不正アクセスといった低レイヤのバグに悩まされることなく、堅牢なC++アプリケーションを構築することができます。
モダンな設計パターンの一部として、ぜひマスターしておきましょう。
