C++という言語は、非常に強力な静的型付けシステムを持っていますが、その一方で利便性のために「暗黙の型変換」という仕組みを備えています。
この仕組みは、プログラマーが意図しない場面で勝手に型を変換してしまうことがあり、時に深刻なバグの原因となります。
こうした意図しない挙動を制御し、コードの安全性を高めるために導入されたのがexplicit指定子です。
本記事では、explicit指定子の基礎から、C++20で導入された最新の機能までを詳しく解説します。
コンストラクタにおける暗黙の型変換とは
C++では、1つの引数で呼び出し可能なコンストラクタを持つクラスがある場合、その引数の型からクラスの型へと自動的に変換が行われることがあります。
これを「暗黙の変換」と呼びます。
まずは、この挙動がどのようなものかを確認しましょう。

暗黙の変換が発生する仕組み
C++のコンパイラは、関数の引数や代入式の左右で型が一致しない場合、ユーザー定義変換を利用して型を合わせようと試みます。
引数が1つのコンストラクタ(または2番目以降の引数にデフォルト値があるコンストラクタ)は、その変換ルールとして利用されます。
以下のサンプルコードを見てください。
#include <iostream>
class MySize {
public:
// 引数1つのコンストラクタ
MySize(int size) : width(size) {
std::cout << "MySize(int) が呼び出されました。値: " << width << std::endl;
}
int getWidth() const { return width; }
private:
int width;
};
void printSize(const MySize& s) {
std::cout << "幅は " << s.getWidth() << " です。" << std::endl;
}
int main() {
// 1. 本来の呼び出し方
MySize s1(10);
printSize(s1);
// 2. 暗黙の型変換による呼び出し
// int型の 100 が MySize型に自動で変換される
printSize(100);
return 0;
}
MySize(int) が呼び出されました。値: 10
幅は 10 です。
MySize(int) が呼び出されました。値: 100
幅は 100 です。
このコードでは、printSize関数はMySizeオブジェクトを期待していますが、printSize(100)のように整数を渡してもコンパイルエラーになりません。
コンパイラが「整数を受け取ってMySizeを作るコンストラクタがあるから、それを使って一時オブジェクトを作ればいいんだな」と親切心で判断してしまうためです。
explicit指定子の基本と役割
前述した暗黙の変換は、便利な反面、コードの可読性を下げ、予期せぬ動作を引き起こします。
そこで、コンストラクタの前にexplicitキーワードを付与することで、この暗黙の変換を禁止することができます。

explicitの記述方法
使い方は非常にシンプルで、コンストラクタの宣言の先頭にexplicitと記述するだけです。
#include <iostream>
class MySize {
public:
// explicit を指定して暗黙の変換を禁止する
explicit MySize(int size) : width(size) {}
int getWidth() const { return width; }
private:
int width;
};
void printSize(const MySize& s) {
std::cout << "幅は " << s.getWidth() << " です。" << std::endl;
}
int main() {
// コンパイルエラー:intからMySizeへの暗黙の変換はできない
// printSize(100);
// OK: 明示的な作成
MySize s1(10);
printSize(s1);
// OK: キャストによる明示的な変換
printSize(MySize(200));
printSize(static_cast<MySize>(300));
return 0;
}
explicitを指定したコンストラクタは、直接初期化(MySize s(10);)や明示的なキャストには反応しますが、引数の渡し間違いなどによる暗黙の生成をブロックします。
これにより、「なぜこの数値が渡せているのか?」という混乱を未然に防ぐことができます。
なぜ暗黙の型変換が問題になるのか
「勝手に変換してくれるなら便利ではないか」と思うかもしれません。
しかし、大規模なプロジェクトや複雑なロジックにおいて、暗黙の変換は牙を剥きます。
意図しない関数のオーバーロード解決
例えば、整数を受け取る関数と、あるクラスオブジェクトを受け取る関数の両方が定義されている場合、型変換のルールが複雑に絡み合い、プログラマーが想定していない方の関数が呼ばれてしまうリスクがあります。
リソース管理クラスでの危険性
メモリバッファを管理するクラスを考えてみましょう。
class Buffer {
public:
// 指定したサイズのメモリを確保するコンストラクタ
explicit Buffer(int size);
};
もしこれがexplicitでない場合、Buffer b = 10;というコードが通ってしまいます。
一見すると「10という値を保持するバッファ」を作っているように見えますが、実際には「10バイトの空のバッファ」が作成されることになります。
このような意味の取り違えは、デバッグが非常に困難な論理バグを生みます。
C++20以降のexplicit(bool)による条件付き指定
モダンなC++開発において、テンプレートを駆使したプログラミングでは「ある条件のときだけexplicitにしたい」という要求が生まれます。
これに応えるのが、C++20で導入されたexplicit(bool)です。

explicit(bool) の具体例
例えば、標準ライブラリのstd::pairやstd::optionalのようなラッパークラスを実装する場合、ラップする対象の型がexplicitなコンストラクタを持っているかどうかに応じて、自身の挙動も変える必要があります。
#include <iostream>
#include <type_traits>
template <typename T>
struct Wrapper {
// Tが暗黙的に変換可能でない場合のみ、自身もexplicitになる
template <typename U>
explicit(!std::is_convertible_v<U, T>)
Wrapper(U&& val) : data(std::forward<U>(val)) {}
T data;
};
struct StrictType {
explicit StrictType(int) {} // explicitなコンストラクタ
};
struct LooseType {
LooseType(int) {} // 暗黙の変換を許可
};
int main() {
// LooseTypeは暗黙変換可能なので、Wrapperも暗黙変換を許可する
Wrapper<LooseType> w1 = 10;
// StrictTypeはexplicitなので、Wrapperもexplicitになる
// 下記はコンパイルエラーになる
// Wrapper<StrictType> w2 = 20;
// 直接初期化ならOK
Wrapper<StrictType> w3(30);
return 0;
}
この機能により、ジェネリックなコードの柔軟性と安全性を両立させることが可能になりました。
ライブラリ開発者にとっては、ユーザーに提供するクラスの挙動をより精密に制御するための必須の道具となっています。
変換演算子におけるexplicitの活用
explicitは、コンストラクタだけでなく、ユーザー定義の変換演算子にも適用できます。
変換演算子とは、自作クラスをbool型やint型などの他の型に変換するための特別な関数です。
変換演算子の罠
特にbool型への変換演算子は便利ですが、explicitを付けないと、予期せぬ算術演算にオブジェクトが参加してしまうことがあります。

#include <iostream>
class SmartPointerLike {
public:
SmartPointerLike(int* p) : ptr(p) {}
// explicitを付けたbool変換演算子
explicit operator bool() const {
return ptr != nullptr;
}
private:
int* ptr;
};
int main() {
int val = 10;
SmartPointerLike p(&val);
// OK: if文の条件式などの「文脈上のbool変換」には利用できる
if (p) {
std::cout << "ポインタは有効です。" << std::endl;
}
// NG: explicitがないと、下記の計算が通ってしまうリスクがある
// int x = p + 10; // コンパイルエラー:explicitのおかげで安全
// explicitがあっても、明示的にキャストすれば計算可能
int y = static_cast<bool>(p) + 10;
std::cout << "計算結果: " << y << std::endl;
return 0;
}
ポインタは有効です。
計算結果: 11
explicit operator bool()は、「if文やwhile文の条件式」としては機能しますが、数値としての足し算などには自動で変換されないという絶妙な挙動を示します。
これはモダンC++において、オブジェクトの真偽判定を安全に実装するためのベストプラクティスです。
explicitを使用すべきか判断する指針
いつexplicitを使うべきか、その基準を整理しましょう。
| コンストラクタの引数 | 推奨される対応 | 理由 |
|---|---|---|
| 引数が1つ | 原則として付与 | 予期せぬ暗黙の変換を避けるため。 |
| 引数が複数 | 原則不要(C++11以降は検討) | 波括弧初期化 {} による暗黙の変換を防ぎたい場合に付与。 |
| コピー/ムーブコンストラクタ | 不要 | 型そのもののコピーであり、変換ではないため。 |
| 変換演算子 | 原則として付与 | 勝手に他の型(特に数値型)として扱われないようにするため。 |
なぜ「引数1つ」はほぼ必須なのか
Google C++ Style Guideなどの主要なコーディング規約では、「1つの引数で呼び出せるすべてのコンストラクタにexplicitを付けること」を強く推奨しています。
これは、プログラムの「読みやすさ」を「書きやすさ」よりも優先するためです。
コードを読んでいる人が、foo(10)という記述を見たときに、それが関数のオーバーロードなのか、それとも暗黙の型変換なのかをいちいちクラス定義に戻って確認しなければならない状況は、保守性を著しく低下させます。
複数引数の場合(C++11以降)
C++11で導入されたリスト初期化(波括弧初期化)により、複数の引数を持つコンストラクタでも暗黙の変換が起こりうるようになりました。
struct Point {
explicit Point(int x, int y) {}
};
void draw(Point p);
// explicitがない場合、下記が通ってしまう
// draw({10, 20});
draw({10, 20})という記述が直感的で便利だと感じるならexplicitは不要ですが、「常に型名を明示させたい」という厳格な設計を目指すなら、複数引数であってもexplicitを付ける価値があります。
まとめ
C++のexplicit指定子は、コンパイラの「お節介」による暗黙の型変換を制御するための重要なツールです。
1つ引数のコンストラクタにこれを付与することは、現代のC++開発において最低限守るべきマナーに近いものとなっています。
暗黙の変換はコードを短く書けるようにしてくれますが、その代償として「意図しない動作」という爆弾をコード内に埋め込むことにもなりかねません。
特にC++20のexplicit(bool)などの登場により、安全性と汎用性の両立はさらに容易になりました。
「迷ったら付ける」というスタンスで開発に臨むことが、バグの少ない、そしてチームメンバーにとっても理解しやすい堅牢なプログラムを作成するための第一歩となります。
ぜひ今日から、自作クラスのコンストラクタを見直し、適切なexplicitの運用を始めてみてください。
