モダンC++ 2026 — C++ 23 / 26 / Modules / Reflection / Senders / std::print / CMake 3.30 / Conan 2 / vcpkg 徹底ガイド

プロローグ — 「C++ は死んだ」は毎年新たに死ぬ

2010年代を通じて、C++ の死亡記事は毎年新しく書かれてきた。Go が出たとき、Rust が出たとき、Swift が出たとき、そしてZig が出たとき、毎回「次のシステムプログラミングはX が獲る」と言われ続けた。2026年5月時点で、その予測はまた外れた。C++ 23 は2024年10月にISO/IEC 14882:2024 として公式に出版され、C++ 26 は2026年のratification に向けて最後のマイルストーンを進めている。Reflection (P2996) という巨大な機能が入り、Senders/Receivers (P2300) が標準のasync モデルとして定着し、Linear Algebra (P1673) がstd に入りつつある。

同時に現場はかつてないほど忙しい。ゲームエンジン — Unreal 5.5、Unity のネイティブコア、CryEngine、内製エンジン — はいまだにC++ だ。HFT (High-Frequency Trading) のマイクロ秒単位の取引システムもC++ だ。Chromium・Firefox・WebKit などのブラウザエンジン、LLVM・GCC・Clang などのコンパイラ、MySQL・PostgreSQL・ClickHouse などのデータベース、CUDA・ROCm・oneAPI などのGPU ランタイム、すべてC++ である。サムスン・LG・ソニー・カプコン・NCsoft が作るほとんどすべてのデバイスとゲームがその上で動く。

本稿では2026年のC++ を一枚の地図として描く。標準 (C++ 23 / 26)、ビルドツール (CMake 3.30・Meson・xmake・build2・Bazel)、パッケージ (Conan 2・vcpkg)、コンパイラ (Clang 19・GCC 14・MSVC)、標準ライブラリ (libc++ vs libstdc++)、Sanitizers、そして後継言語候補 (Carbon・Hylo・Cppfront)。最後に韓国と日本の現場での使われ方で締めくくる。

1章 · 2026年のC++ — C++ 23 出版とC++ 26 仕上げ

まず全体像。

C++ 23 — 2024年10月公式出版

C++ 23 は2024年10月にISO/IEC 14882:2024 として正式に出版された。2020年のC++ 20 から3年ぶりだ。主要機能は次の通り。

std::expected<T, E> — Rust の Result に近いモナディックなエラー処理。例外を使わないコードベースの新しいベースライン。
std::print / std::println — printf とiostream の30年間の地位を獲りに行く。{fmt} ライブラリを標準化した結果。
std::generator — コルーチンベースのlazy range。Python の yield パターンが標準入り。
std::flat_map / std::flat_set — ソート済み vector の上に乗せたcache-friendly な連想コンテナ。
std::mdspan — non-owning な多次元view。BLAS・科学計算用。
[[assume(expr)]] — 最適化ヒント。
if consteval — コンパイル時分岐。
static operator() — ラムダの this キャプチャオーバーヘッドを消す。
Deducing this — メンバ関数のexplicit object parameter。

C++ 26 — 2026年ratification、主役はReflection

C++ 26 は2026年にratification が終わり、ISO/IEC 14882:2026 として出版予定だ (2025年6月のSofia 会議でfeature complete が宣言された)。主要機能は以下。

Reflection (P2996) — コンパイル時reflection とsplicing。C++ のmetaprogramming を一から書き換える。
Senders/Receivers (P2300) — std::execution として入るasync モデル。std::future の後継。
Linear Algebra (P1673) — BLAS 形のインターフェースを標準化。
Hazard pointers / RCU — lock-free データ構造用のメモリ回収。
Contracts (P2900) — 関数の事前・事後条件。C++ 20 で外され、ようやく戻ってきた。
Pattern matching (P2688) — inspect キーワードベース。
std::simd — データ並列型。

「なぜC++ は死なないか」 — 市場の現実

2026年時点のTIOBE やIEEE Spectrum のランキングでC++ は1~5位の間を維持し、GitHub のPR 統計でも同様だ。理由は単純である。

レガシーが巨大すぎる。 Chromium・LLVM・Linux の一部・MySQL・Unreal といった巨大プロジェクトがC++ で書かれており、移行は事実上不可能だ。
完全に代替できる言語がない。 Rust は素晴らしいが、すべてのC++ 領域をカバーできない (特にゲーム・科学計算・Windows GUI)。Carbon はまだalpha。Hylo は研究段階。
依然として速い。 GCC 14・Clang 19 が生成するコードは世界最高峰のまま。LTO・PGO・BOLT まで合わせれば、他のコンパイル言語と同等かそれ以上。
標準が生きている。 C++ 23・26 は単なる整理ではなく、本当に新機能 が入り続けている。

2章 · C++ 23 (2024年10月出版) — std::expected / std::print / std::generator

C++ 23 で最も使われている新機能を3つ取り上げる。

std::expected — モナディックなエラー処理

Rust の Result<T, E> がC++ に来た。std::expected<T, E> は成功値T かエラー値E のどちらかを保持する。例外を使わないコードベース (ゲーム・組み込み・HFT) が長年自前で書いていたパターンが標準化された形だ。

#include <expected>
#include <string>
#include <print>

enum class ParseError { InvalidFormat, Overflow };

std::expected<int, ParseError> parse_int(std::string_view s) {
    if (s.empty()) return std::unexpected(ParseError::InvalidFormat);
    int v = 0;
    for (char c : s) {
        if (c < '0' || c > '9') return std::unexpected(ParseError::InvalidFormat);
        if (v > (INT_MAX - (c - '0')) / 10) return std::unexpected(ParseError::Overflow);
        v = v * 10 + (c - '0');
    }
    return v;
}

int main() {
    auto r = parse_int("42")
        .and_then([](int v) -> std::expected<int, ParseError> { return v * 2; })
        .transform([](int v) { return v + 1; });

    if (r) std::println("ok: {}", *r);
    else std::println("err");
}

and_then・transform・or_else といったモナディック演算子が用意され、チェーンが自然に書ける。ゲームエンジンのasset ローダ、HFT の注文パーサ、組み込みの設定パーサが続々と移行した。

std::print / std::println — printf の後継

{fmt} ライブラリ (Victor Zverovich) がC++ 20 で <format> として入り、C++ 23 でついに出力関数 std::print / std::println まで揃った。printf のフォーマット文字列安全性とiostream のtype safety を合わせた結果だ。

#include <print>
#include <vector>

int main() {
    std::println("hello {}, you are {} years old", "yj", 33);

    std::vector<int> v{1, 2, 3, 4, 5};
    std::println("vec = {}", v); // [1, 2, 3, 4, 5]

    // 韓国語・日本語もUTF-8 でそのまま
    std::println("ko: {}, ja: {}", "annyeong", "konnichiwa");
}

ベンチマーク上 std::print は printf より速く、std::cout << ... よりはるかに速い (locale・sync オーバーヘッドがないため)。2026年時点ではiostream は事実上deprecated 扱いの空気だ。

std::generator — コルーチンベースのlazy range

C++ 20 でコルーチンキーワード (co_await・co_yield・co_return) は入ったが、標準ライブラリ側のgenerator がなく、ほぼ使えなかった。C++ 23 で std::generator<T> が追加され、Python の yield パターンがC++ でも自然に書けるようになった。

#include <generator>
#include <print>
#include <ranges>

std::generator<int> fib() {
    int a = 0, b = 1;
    while (true) {
        co_yield a;
        auto t = a + b;
        a = b;
        b = t;
    }
}

int main() {
    for (int v : fib() | std::views::take(10)) {
        std::println("{}", v);
    }
}

Ranges と組み合わせると非常に強力だ (次章)。

3章 · C++ 26 — Reflection の時代

C++ 26 最大の事件は Reflection (P2996) だ。Daveed Vandevoorde・Wyatt Childers・Andrew Sutton・Faisal Vali が数年かけて磨き上げてきた静的reflection 提案がついに標準入りする。

従来のSFINAE・<type_traits>・マクロベースmetaprogramming を一気に置き換える可能性を持つ。中心となるのは新しい2つの演算子 ^^ と [: ... :]。

^^X — X のreflection 値を得る (型は std::meta::info)。
[: r :] — reflection 値r をsplice して元のentity に戻す。

#include <meta>
#include <print>

struct Person {
    std::string name;
    int age;
    std::string email;
};

template<typename T>
void print_struct(const T& t) {
    constexpr auto members = std::meta::nonstatic_data_members_of(^^T);
    template for (constexpr auto m : members) {
        std::println("{} = {}",
            std::meta::identifier_of(m),
            t.[:m:]);
    }
}

int main() {
    Person p{"yj", 33, "yj@example.com"};
    print_struct(p);
    // name = yj
    // age = 33
    // email = yj@example.com
}

この機能ひとつでJSON serializer、ORM、RPC stub、GUI binding、設定ローダといったライブラリが マクロなし・boost.pfr なし・cereal なし で短く安全に書き直される。2026年後半時点でClang trunk とEDG (Intel) が部分的に実装中。

その他のC++ 26 の大物機能。

std::simd — SIMD が標準の型として入る。intrinsics の代わりにportable なデータ並列コード。
Contracts (P2900) — pre(expr)・post(expr) で関数の事前・事後条件を表現。C++ 20 で外され、ようやく復帰。
Pattern matching (P2688) — inspect (x) { ... } でRust の match に近い形。
Hazard pointers / RCU — lock-free データ構造のメモリ回収技法。

4章 · Modules — ようやく実用段階か

Modules はC++ 20 で入ったが、2020~2023年はほぼ使えなかった。コンパイラ (Clang・MSVC・GCC) の実装が不完全で、ビルドツール (CMake・Bazel) との統合もひどかった。2024年から状況が急速に変わり、2026年現在は ようやくproduction で実用に耐える。

Modules の基本

ヘッダベース (#include) の問題はテキスト前処理である点だ。同じヘッダが.cpp ごとに再解析され、マクロが漏れ、ODR 違反が起き、ビルドが遅い。Modules はコンパイル済みインターフェースを一度だけ作り、各所からimport する。

// math.cppm (module interface)
export module math;

export int add(int a, int b) {
    return a + b;
}

export int sub(int a, int b) {
    return a - b;
}

// main.cpp
import math;
import std; // C++ 23 から標準ライブラリもmodule としてimport できる

int main() {
    std::println("{}", add(1, 2));
}

ビルドツール側

CMake 3.30 (2024年) — C++ 20 modules のfirst-class サポート。Ninja 1.11+ が必要。
MSVC (Visual Studio 17.10+) — modules が最も安定。
Clang 17~19 — modules ほぼ完成。-fmodules-ts ではなく標準の -std=c++20 + -fmodules。
GCC 14~15 — modules 部分サポート、header units はまだ弱い。
Bazel — cc_module rule が2025年から正式化。

効果

ビルド時間 — Chromium の部分的なmodules 移行で、incremental ビルドが30~50% 短縮。
ODR — module 内のマクロは外に漏れない。
IDE — IntelliSense・clangd がmodule を理解すればnavigation が速くなる。

落とし穴

標準ライブラリの import std はコンパイラ・STL の組み合わせ次第でサポートがまだら。2026年時点でlibc++ + Clang 18+ はOK、libstdc++ + GCC 14 は部分的、MSVC STL はOK。
ビルドシステムがmodule の依存関係を正確に計算する必要がある。cmake --build はmodule graph をscan してからコンパイルするので、first build はかえって遅くなることもある。

5章 · Ranges (C++ 20) — ようやく成熟

Ranges はC++ 20 で入ったが、当初はほぼ使われなかった。コンパイルエラーが恐ろしく (数十行のtemplate instantiation)、debugger 上の型が醜く、標準ライブラリ側のalgorithm が出揃っていなかったからだ。C++ 23 で欠落分が埋まり、2026年時点では日常コードの相当部分がRanges で書かれている。

#include <ranges>
#include <vector>
#include <print>

int main() {
    std::vector<int> v{1, 2, 3, 4, 5, 6, 7, 8, 9, 10};

    auto result = v
        | std::views::filter([](int x) { return x % 2 == 0; })
        | std::views::transform([](int x) { return x * x; })
        | std::views::take(3);

    for (int x : result) std::println("{}", x);
    // 4
    // 16
    // 36
}

C++ 23 で追加されたもの

std::views::enumerate — Python の enumerate 相当。
std::views::zip / zip_transform。
std::views::join_with — 文字列のjoin のように。
std::views::chunk / chunk_by / slide — windowing。
std::views::stride — n ステップずつ。
std::views::cartesian_product — 全組み合わせ。
std::ranges::to<vector> — view をcontainer にmaterialize。

auto names = std::vector<std::string>{"alice", "bob", "charlie"};
auto ages = std::vector<int>{30, 25, 40};

for (auto [name, age] : std::views::zip(names, ages)) {
    std::println("{}: {}", name, age);
}

性能

Ranges はlazy なので、中間ベクタは作られない。コンパイラがinline をきちんとすれば、生成コードは手書きのfor-loop と同等になる (godbolt で確認)。ただしSTL view にはreference invalidation などの落とし穴があり、std::ranges::to で早めにmaterialize するのが安全なことが多い。

6章 · Senders/Receivers (P2300) — async モデル

std::future はC++ 11 で入ったが、ほぼ使われなかった。promise/future のコストが大きく、composition がなく、cancellation も欠け、allocator がhardcoded だったからだ。C++ 26 の Senders/Receivers (P2300) はこれを全部再設計する。

Eric Niebler・Lewis Baker・Kirk Shoop・Lee Howes がNVIDIA・Meta・Microsoft の実production コード (stdexec、libunifex) で磨いてきたモデルだ。

コアコンセプト

Sender — 「値を非同期に生み出す」というlazy な記述。
Receiver — sender の結果を受け取るsink。
Scheduler — sender がどこで実行されるかを決める (thread pool、GPU stream など)。

#include <execution>
#include <print>

namespace ex = std::execution;

int main() {
    auto pool = ex::static_thread_pool(4);
    auto sched = pool.get_scheduler();

    auto work = ex::schedule(sched)
        | ex::then([] { return 42; })
        | ex::then([](int x) { return x * 2; });

    auto [result] = std::this_thread::sync_wait(work).value();
    std::println("result = {}", result); // 84
}

なぜ重要か

従来の std::async はthread を直接作るか、launcher が勝手に決めるかのどちらかで、どこで実行されるかが分からない。Senders は scheduler が明示的 なので、同じコードをthread pool・fiber・GPU stream・Linux io_uring・Windows IOCP・Android JNI thread といった様々なcontext に乗せられる。

composition も自然だ。then・when_all・let_value・upon_error・stopped_as_optional といったalgorithm で非同期グラフを組む。cancellation は stop_token で伝播する。

NVIDIA のCUDA 12・13 の一部async API はすでにsender インターフェースを露出しており、2026年後半に標準実装が登場すると見られる。

7章 · 線形代数BLAS std (C++ 26)

C++ 26 のもう一つの大物機能が std::linalg (P1673) — Bradley A. Lucier・Mark Hoemmen・Christian Trott・Daisy Hollman が主導したBLAS 形インターフェースの標準化だ。

数十年間、C++ の線形代数はEigen・Blaze・Armadillo・xtensor といった外部ライブラリに依存してきた。同じBLAS 呼び出しを毎回違うラッピングで包んだ結果、コードの可搬性が悪く、ML/AI の隆盛で標準化の遅れへの批判が高まっていた。

<linalg> は std::mdspan (C++ 23) の上にBLAS Level 1・2・3 の標準インターフェースを乗せる。

#include <linalg>
#include <mdspan>
#include <vector>

int main() {
    std::vector<double> data(16);
    auto A = std::mdspan(data.data(), 4, 4);

    std::vector<double> x(4, 1.0);
    std::vector<double> y(4, 0.0);

    // y = alpha * A * x + beta * y
    std::linalg::matrix_vector_product(
        A, x, y);
}

裏の実装はvendor (Intel MKL、OpenBLAS、NVIDIA cuBLAS、AMD rocBLAS) が自由。標準のインターフェースだけが揃う。

ML 推論、シミュレーション、コンピュータビジョン、信号処理の分野で大きな変化を呼ぶと見られる。

8章 · CMake 3.30 / Meson / xmake / build2 / Bazel C++ — ビルドツール

C++ の永遠の悩み。2026年のビルドツール地図は次の通り。

CMake — 事実上の標準

好き嫌いに関わらずCMake は事実上の標準だ。ほぼすべてのライブラリが find_package または FetchContent で統合され、IDE (CLion・Visual Studio・Qt Creator・VS Code) もすべて対応している。

CMake 3.30 (2024年) — C++ 20 modules のfirst-class サポート、presets v8、新しい cmake -E subcommand。
CMake 3.31 / 3.32 — modules サポート改善、package manifest (vcpkg / Conan 統合) 強化。

基本パターン。

cmake_minimum_required(VERSION 3.30)
project(myapp CXX)

set(CMAKE_CXX_STANDARD 23)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)

add_executable(myapp src/main.cpp)

find_package(fmt CONFIG REQUIRED)
target_link_libraries(myapp PRIVATE fmt::fmt)

CMake の欠点はよく知られている — DSL が不格好で、エラーメッセージが醜く、大規模プロジェクトではgenerator expression が複雑になる。それでも みんなが知っている ことが最大の強みだ。

Meson — Pythonic な代替

Meson はPython で書かれたビルドシステム。syntax が綺麗で速い。GNOME・systemd・QEMU・GStreamer が使う。CMake より速く (Ninja バックエンド標準)、subproject 管理が良い。

project('myapp', 'cpp',
  default_options : ['cpp_std=c++23'])

fmt_dep = dependency('fmt')
executable('myapp', 'src/main.cpp', dependencies : fmt_dep)

欠点はCMake ほどライブラリサポートが広くないこと。ただしGNOME 圏では事実上の標準。

xmake — Lua ベースの新興

xmake は中国発のLua ベースビルドシステムで、非常に速くモダン (xmake init → xmake build → xmake install)。パッケージマネージャ (xrepo) も内蔵。ゲーム・組み込みで急速に増えている。

add_rules("mode.debug", "mode.release")
set_languages("c++23")

target("myapp")
    set_kind("binary")
    add_files("src/*.cpp")
    add_packages("fmt")

build2 — 学術的・厳密な代替

build2 は非常に厳密で一貫したビルドシステム + パッケージマネージャ。C++ Modules サポートが最も早く正確。ユーザーは少ないが熱狂的なファンがいる。

Bazel — Google 流monorepo

Bazel はGoogle の社内ビルドシステムBlaze をオープンソース化したもの。巨大monorepo (TensorFlow、gRPC、Envoy) で輝く。hermetic build、remote cache、distributed execution が強み。欠点は学習曲線と、小規模プロジェクトには過剰なセットアップ。

# BUILD.bazel
cc_binary(
    name = "myapp",
    srcs = ["src/main.cpp"],
    copts = ["-std=c++23"],
    deps = ["@fmt//:fmt"],
)

2026年時点でgoogle/bazel-cpp のmodules サポートが入った。

選定ガイド (大まかに)

一般オープンソース・ライブラリ → CMake
GNOME / systemd 圏・ビルド速度重視 → Meson
ゲーム・組み込み・中国圏・Lua フレンドリー → xmake
Modules 完全サポート必須 → build2
Monorepo・数万target・remote cache → Bazel

9章 · Conan 2 / vcpkg — パッケージマネージャ

数十年間、C++ の最大の弱点はパッケージマネージャの不在だった。各自がソースから直接ビルドするか、Linux distro のパッケージに依存するか、git submodule で引っ張るかだった。2020年代に2つの大選手が定着した — Conan と vcpkg。

Conan 2 (2023年メジャーリリース)

Conan はPython で書かれた分散型パッケージマネージャ。JFrog がbacking。Conan 2 は1.x から綺麗に書き直され、2026年時点では非常に安定。

# conanfile.py
from conan import ConanFile
from conan.tools.cmake import CMake, cmake_layout

class MyAppRecipe(ConanFile):
    settings = "os", "compiler", "build_type", "arch"
    generators = "CMakeDeps", "CMakeToolchain"

    def requirements(self):
        self.requires("fmt/10.2.1")
        self.requires("spdlog/1.13.0")
        self.requires("nlohmann_json/3.11.3")

    def layout(self):
        cmake_layout(self)

conan install . --build=missing
cmake --preset conan-default
cmake --build --preset conan-release

Conan の強みは profile システム。同じパッケージを様々な設定 (debug/release、GCC/Clang、x86/arm、libc++/libstdc++) でビルドしてcache する。社内のArtifactory と連携してpatched ビルドを共有する。

vcpkg (Microsoft、2017~)

vcpkg はMicrosoft 製のマネージャ。最初はWindows 中心だったが、今ではLinux・macOS もしっかり動く。カタログが非常に大きく (3000+ ライブラリ)、CMake との統合が自然。

// vcpkg.json
{
  "name": "myapp",
  "version": "0.1.0",
  "dependencies": [
    "fmt",
    "spdlog",
    "nlohmann-json"
  ]
}

vcpkg install
cmake -B build -S . \
  -DCMAKE_TOOLCHAIN_FILE=$VCPKG_ROOT/scripts/buildsystems/vcpkg.cmake
cmake --build build

vcpkg の強みはmanifest mode + binary cache。同じ依存関係を毎回再ビルドせずcache から取ってくる。Azure DevOps / GitHub Actions との統合がしっかりしている。

Conan vs vcpkg — どう選ぶか

基準	Conan 2	vcpkg
出自	JFrog (スペイン)	Microsoft
言語	Python recipe	CMake 風portfile
Profile	非常に強力	弱い (triplet ベース)
カタログ	1500+	3000+
社内cache	Artifactory フレンドリー	Azure Artifacts
学習曲線	急	緩やか
Windows	OK	最高

大まかに: 社内の多様なビルドマトリクスが必要 → Conan、素早く始めたい / Windows メイン → vcpkg。

10章 · Clang 19 / GCC 14 / MSVC — コンパイラ

2026年5月時点の主要コンパイラの状態。

Clang 19~20 (LLVM)

C++ 23 ほぼ完全、C++ 26 は半分程度 (modules・reflection trunk)。
最速のコンパイル速度と最良の診断メッセージ。
libc++ と最も相性が良い。
macOS・iOS・Android (NDK) の事実上の標準。
Apple Clang はLLVM trunk より1~2バージョン遅れる。

GCC 14~15

C++ 23 ほぼ完全、C++ 26 も急速に追従。
Linux サーバ・組み込みの事実上の標準。
libstdc++ と一緒に。標準ライブラリ品質で最も信頼される。
-O3 のコード品質はClang よりわずかに上のことが多い (ベンチマーク次第)。

MSVC (Visual Studio 17.10+)

Windows デスクトップ・コンソール (Xbox)・ゲーム (Unreal) の事実上の標準。
2010年代までC++ 標準への追従は遅かったが、今は速い。
Modules・coroutine などで最初に実装することも多い。
C++ 標準ライブラリ (MSVC STL) はGitHub でオープンソース (microsoft/STL)。

選定ガイド

環境	第一選択
Linux サーバ	GCC 14
macOS / iOS	Apple Clang (またはHomebrew LLVM)
Windows デスクトップ / ゲーム	MSVC
Android NDK	Clang
組み込みARM	GCC arm-none-eabi またはClang
HFT / 最新標準採用	Clang trunk

11章 · libc++ vs libstdc++ — 標準ライブラリ

C++ 標準ライブラリは事実上 標準は一つ、実装は別 だ。2026年時点の主要実装。

libstdc++ — GCC 陣営。最も保守的だが完成度が高い。Linux の事実上の標準。
libc++ — LLVM 陣営。macOS・iOS の標準。Linux でも増加中。
MSVC STL — Microsoft の標準ライブラリ。Windows の標準。GitHub でオープンソース。

違い

ABI — libstdc++ とlibc++ は ABI 互換ではない。同じオブジェクトファイルを混ぜると壊れる (特に std::string・std::list)。
性能 — 一部アルゴリズム (例えば std::sort・std::regex) の性能が異なる。libc++ の std::regex の方が速いというベンチが多く、libstdc++ の <algorithm> の方が最適化されていることが多い。
標準追従 — libc++ の方が新機能の実装が一般的に速い。
Modules — 2026年時点でlibc++ + Clang 18+ の import std が最も安定。libstdc++ + GCC 14 は部分的、MSVC STL はOK。

選び方

Linux でどちらを使うかはdistro と既定コンパイラに従う場合がほとんど。macOS は事実上libc++ 強制。意図的に選びたい場合はClang + -stdlib=libc++ で。

12章 · Sanitizers — ASan / UBSan / TSan / MSan

Sanitizer はLLVM が始め、GCC が追従した、ランタイムのメモリ・同期バグ検出ツール。C++ コードの品質を一段引き上げた。

AddressSanitizer (ASan)

内容 — heap-buffer-overflow、use-after-free、use-after-return、double-free、leak。
オーバーヘッド — CPU 2~~3倍、メモリ 1.5~~3倍。
使い方 — -fsanitize=address -fno-omit-frame-pointer。

clang++ -std=c++23 -O1 -g -fsanitize=address -fno-omit-frame-pointer main.cpp
ASAN_OPTIONS=detect_leaks=1 ./a.out

CI ですべてのテストをASan で回すのが2026年のbaseline。

UndefinedBehaviorSanitizer (UBSan)

内容 — signed integer overflow、null deref、divide by zero、misaligned access など。
オーバーヘッド — ほぼなし。
使い方 — -fsanitize=undefined。

ASan と同時に使える。

ThreadSanitizer (TSan)

内容 — data race、一部deadlock、mutex の誤用。
オーバーヘッド — CPU 5~~15倍、メモリ 5~~10倍。
使い方 — -fsanitize=thread。

マルチスレッドコードのrace 検出はほぼTSan が唯一の自動ツール。

MemorySanitizer (MSan)

内容 — 未初期化メモリの読み出し。
オーバーヘッド — CPU 3倍程度。
注意 — 標準ライブラリまでMSan でビルドしないとfalse positive が出る (libc++ のMSan ビルドを使う)。

推奨セットアップ

CI にASan + UBSan マトリクスを追加。
マルチスレッドコードは別ジョブでTSan。
nightly でfuzzer (libFuzzer + ASan) を回す。

13章 · 後継言語 — Carbon (Google) / Hylo / Cppfront (Herb Sutter)

C++ の「ABI 負担 / 安全でない既定値 / 巨大な標準」をどう解くかへの答えとして3つの大きな試みがある。

Carbon (Google、2022~)

Chandler Carruth が主導するGoogle のC++ 後継言語。核心アイデアは 双方向のinterop — 同じコードベース内でC++ とCarbon を混ぜて使えるようにする。Swift がObjective-C の後継だったように。

package Sample api;

fn Fib(n: i32) -> i32 {
  if (n < 2) { return n; }
  return Fib(n - 1) + Fib(n - 2);
}

fn Main() -> i32 {
  Print("fib(10) = {0}", Fib(10));
  return 0;
}

2026年5月時点でCarbon はまだ0.x experimental。self-hosting もできておらず、標準ライブラリもほぼ存在せず、一般使用は推奨されない。2030年以前にproduction で使えないというのが公式スタンス。

Hylo (旧Val、2020~)

Dimitri Racordon・Dave Abrahams が作る研究言語。C++ の後継というより mutable value semantics を真剣に追求する言語。変数は既定でunique で、mutation が明示的なので、race やaliasing の問題が消える。

Swift のアイデアの一部をさらに推し進めた形。研究段階だが学界と産業界の関心を集めている。

Cppfront / cpp2 (Herb Sutter、2022~)

C++ 標準委員会のchair だったHerb Sutter が作る 「C++ の代替シンタックス」。別言語ではなく、cppfront がcpp2 コードを受け取ってC++ にtranspile する。

// hello.cpp2
main: () = {
    print("hello, world!");
}

square: (x: int) -> int = x * x;

既存のC++ と自由に混ぜて使え、安全な既定値 (default const、bounds check) を持ち込むのが核心。Carbon よりずっと軽量なアプローチ。

まとめ

2026年時点でC++ 後継言語はすべて prototype / experimental。今後5~10年で1, 2 個が定着する可能性はあるが、その間にC++ 自体も進化する。Reflection・Senders・Modules が入れば「C++ を離れる理由」は減る。

代替として Rust もますます使われている。システム・組み込み・OS 領域ではRust がC++ と直接競合する (Linux kernel のRust モジュール、Windows kernel の一部、Android の一部)。しかしゲーム・科学計算・Windows GUI・既存巨大コードベース領域では依然としてC++ が圧倒的。

14章 · 韓国 — サムスン、LG、NCsoft、Toss インフラ

韓国でのC++ 採用先を概観する。

サムスン電子

System LSI / Foundry — チップ設計ツール (EDA) の一部がC++。
モバイル事業部 — Android のネイティブ層、カメラISP のfirmware、モデムのfirmware。
CE (家電) — TV のTizen OS、冷蔵庫・洗濯機の組み込みコントローラ。
半導体 — メモリコントローラのverification (SystemVerilog + C++)、DRAM/NAND のfirmware。
Samsung Research — AI/ML の一部、デバイス上LLM 推論エンジン。

LG 電子

HE (TV) — webOS のネイティブコンポーネント、画質エンジン。
VS (車載) — 車載インフォテインメント、自動運転SoC のfirmware。
H&A (家電) — 洗濯機・エアコン・ロボット掃除機のコントローラ。

NCsoft

リネージュ・ブレイド&ソウル — 内製エンジン (独自C++)。
TL (Throne and Liberty) — Unreal Engine 5 + 独自C++。
AI Center — Vapor (内製ゲームAI)、音声合成エンジン。

Toss — インフラ / トレーディング領域

Toss 証券 — マッチングエンジン — 一部のlatency critical 領域でC++ を使用 (Java/Kotlin がメインだが、コアmatching の一部)。
インフラ — 一部ミドルウェア。

(注: Toss のコアサービスはKotlin でC++ の比率は低いが、latency-critical 領域で使用事例がある。)

その他の韓国企業

カカオエンターテインメント — ゲームサーバの一部、マルチメディア処理。
Krafton — PUBG のclient (Unreal Engine 4 + 独自)、サーバサイドbattle simulator。
Pearl Abyss — 黒い砂漠の自社エンジンBlackSpace (C++)。
Smilegate — ロストアーク client (Unreal)、自社server engine。
現代自動車 / Mobis — 車両ECU firmware、ADAS。
Hanwha Systems / LIG Nex1 — 防衛embedded。

韓国C++ コミュニティ

Modern C++ Korea — Facebook グループ + meetup。標準委員会の韓国NB (National Body) 活動。
NDC (NEXON Developers Conference) — ゲーム開発者カンファレンス。C++ track 多数。
書籍・翻訳書 — Chanho Ok・Sangsoo Park などのモダンC++ 書籍がよく読まれる。

15章 · 日本 — Sony PlayStation、Square Enix、Capcom、Bandai Namco

日本はゲーム・家電・自動車の本場で、ほぼすべてC++ の上で動く。

Sony Interactive Entertainment

PlayStation 5 / Pro / 6 — OS、SDK、devkit のほぼすべてがC++。firmware はC + C++。
PSN backend — 一部C++、一部Java/Kotlin/Rust。
first-party スタジオ — Naughty Dog、Insomniac、Santa Monica、Polyphony、Guerrilla — すべて自社engine またはUnreal + C++。

Square Enix

Crystal Tools / Luminous Engine — FF シリーズの自社エンジン群。すべてC++。
ドラゴンクエスト — Unreal Engine または自社engine。
外部ライセンス — Unreal Engine 5 多数。

Capcom

RE Engine — Resident Evil 7 から開始。Devil May Cry 5、Monster Hunter Rise / Wilds、Street Fighter 6 がすべてRE Engine。独自C++。
MT Framework (旧) — 一部レガシー。

Bandai Namco

Tekken 8 — Unreal Engine 5。
Elden Ring — FromSoftware — 自社engine (Souls engine)。C++。
ガンダムシリーズ — Unreal または自社。

Konami

eFootball / ウイニングイレブン — Unreal Engine。
桃太郎電鉄 — 自社。

SEGA

Phantasy Star Online — 自社。
龍が如く / Like a Dragon — Dragon Engine (自社C++)。

日本の自動車 (Toyota、Honda、Nissan)

車両ECU / Autosar — ほぼすべてC++ またはC。Autosar Adaptive はC++ ベース。
ADAS / 自動運転 — C++ メイン。ROS の一部 (ROS 2 はC++)。

日本の家電 (Sony、Panasonic、Sharp)

TV / カメラ / オーディオ — 組み込みLinux + C++ またはRTOS + C++。

日本のC++ コミュニティ

CppCon Japan / C++ MIX — 東京・大阪のmeetup。
C++ 日本NB — 標準委員会の日本representative が活発。
Cybozu / DeNA / GREE — 一部backend でC++ を使用。

16章 · 誰がC++ を選ぶべきか — ゲーム / 組み込み / HFT / システム

最後に2026年の 新規プロジェクトの言語選定 でC++ を選ぶべきケースとそうでないケースをまとめる。

C++ が正解のケース

ゲーム — Unreal Engine / 自社engine — 他に選択肢がほぼない。Unreal のgameplay code もC++ (またはBlueprint)。
HFT (High-Frequency Trading) — マイクロ秒単位のlatency。JVM のGC が許されない領域。
OS / システムプログラミング (一部) — Linux kernel はC メイン + Rust 一部だが、Windows kernel の一部、Apple Darwin の一部、組み込みRTOS はC++ も多い。
組み込み / firmware — ARM Cortex-M、RISC-V、自動車ECU、家電 — C++ またはC。
CAD / シミュレーション / EDA — AutoCAD、SolidWorks、ANSYS、Synopsys、Cadence のほぼ全部。
データベースエンジン — MySQL、PostgreSQL、ClickHouse、MongoDB、RocksDB。
コンパイラ / ランタイム — LLVM、GCC、V8、JVM HotSpot 自体。
グラフィックス / GPU ランタイム — CUDA、ROCm、oneAPI、Vulkan 実装。
AI 推論エンジン — llama.cpp、PyTorch C++ runtime、TensorFlow Lite、ONNX Runtime。

Rust の方が良い可能性が高いケース

新規システムプログラミング (特にメモリ安全性が重要なもの) — Rust。
WebAssembly ターゲット — Rust の方がはるかに自然。
インターネットインフラ (Cloudflare、Discord など) — Rust が事実上の標準に。
CLI ツール — Go またはRust。

Go / Java / TypeScript が正解のケース

バックエンドAPI サーバ — Go / TypeScript / Java / Kotlin。
データパイプライン — Python / Scala / Java。
GUI デスクトップアプリ — Electron / TypeScript / C# (WPF) — ただしゲームはC++。

落とし穴

「安全性」が絶対要件でなければ、モダンC++ (C++ 20・23・26) の生産性も悪くない。std::expected・std::print・Ranges・Modules が日常を変える。
既存C++ コードベースに新機能を追加 → ほぼ常にC++ で続けるのが正解。Rust interop は可能だがABI・ビルドシステム・CI が複雑になる。
学習曲線 — モダンC++ は依然として急。Rust が難しいと言われるが、C++ のUB とtemplate metaprogramming ほど難しいものはない。

17章 · 結び — モダンC++ は依然として生きている

2026年のC++ は1998年のC++ でもなく、2011年のC++ でもない。C++ 23 の std::expected・std::print・std::generator が日常を変え、C++ 26 のReflection・Senders・Linear Algebra がライブラリ生態系を再構築する。Modules がついにビルドを軽くし、Ranges がコードを読みやすくする。

ビルドツールはCMake 3.30・Meson・xmake・build2・Bazel の中から選べ、パッケージはConan 2 とvcpkg のどちらもproduction-ready。コンパイラはClang 19・GCC 14・MSVC のすべてがC++ 23 ほぼ完成。Sanitizers が品質のbaseline になった。

後継言語 — Carbon・Hylo・Cppfront — はどれも興味深いがまだprototype。Rust は一部領域を獲ったが全部は獲れていない。ゲーム・組み込み・HFT・システム領域でC++ は依然として圧倒的で、韓国・日本の巨大企業がその上で次の製品を作っている。

「C++ は死んだ」はまた外れた。そしてその予測は今後も毎年外れ続けるだろう。その間、C++ 自体はさらに良くなっていく。

参考 / References

ビルドツール

パッケージマネージャ

Conan — https://conan.io/
vcpkg — https://vcpkg.io/

Sanitizers

AddressSanitizer — https://clang.llvm.org/docs/AddressSanitizer.html
UndefinedBehaviorSanitizer — https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
ThreadSanitizer — https://clang.llvm.org/docs/ThreadSanitizer.html
MemorySanitizer — https://clang.llvm.org/docs/MemorySanitizer.html

後継・実験言語

Carbon — https://github.com/carbon-language/carbon-lang
Hylo — https://www.hylo-lang.org/
Cppfront — https://github.com/hsutter/cppfront

ライブラリ / プロジェクト

fmt (std::format / std::print の原型) — https://github.com/fmtlib/fmt
stdexec (NVIDIA / Senders のreference 実装) — https://github.com/NVIDIA/stdexec
mdspan (reference 実装) — https://github.com/kokkos/mdspan

韓国・日本のゲーム / エンジン

Unreal Engine — https://www.unrealengine.com/
Capcom RE Engine — https://www.capcom-games.com/re-engine/
NCSoft — https://kr.ncsoft.com/

プロローグ — 「C++ は死んだ」は毎年新たに死ぬ

1章 · 2026年のC++ — C++ 23 出版とC++ 26 仕上げ

C++ 23 — 2024年10月公式出版

C++ 26 — 2026年ratification、主役はReflection

「なぜC++ は死なないか」 — 市場の現実

2章 · C++ 23 (2024年10月出版) — std::expected / std::print / std::generator

std::expected — モナディックなエラー処理

std::print / std::println — printf の後継

std::generator — コルーチンベースのlazy range

3章 · C++ 26 — Reflection の時代

4章 · Modules — ようやく実用段階か

Modules の基本

ビルドツール側

効果

落とし穴

5章 · Ranges (C++ 20) — ようやく成熟

C++ 23 で追加されたもの

性能

6章 · Senders/Receivers (P2300) — async モデル

コアコンセプト

なぜ重要か

7章 · 線形代数BLAS std (C++ 26)

8章 · CMake 3.30 / Meson / xmake / build2 / Bazel C++ — ビルドツール

CMake — 事実上の標準

Meson — Pythonic な代替

xmake — Lua ベースの新興

build2 — 学術的・厳密な代替

Bazel — Google 流monorepo

選定ガイド (大まかに)

9章 · Conan 2 / vcpkg — パッケージマネージャ

Conan 2 (2023年メジャーリリース)

vcpkg (Microsoft、2017~)

Conan vs vcpkg — どう選ぶか

10章 · Clang 19 / GCC 14 / MSVC — コンパイラ

Clang 19~20 (LLVM)

GCC 14~15

MSVC (Visual Studio 17.10+)

選定ガイド

11章 · libc++ vs libstdc++ — 標準ライブラリ

違い

選び方

12章 · Sanitizers — ASan / UBSan / TSan / MSan

AddressSanitizer (ASan)

UndefinedBehaviorSanitizer (UBSan)

ThreadSanitizer (TSan)

MemorySanitizer (MSan)

推奨セットアップ

13章 · 後継言語 — Carbon (Google) / Hylo / Cppfront (Herb Sutter)

Carbon (Google、2022~)

Hylo (旧Val、2020~)

Cppfront / cpp2 (Herb Sutter、2022~)

まとめ

14章 · 韓国 — サムスン、LG、NCsoft、Toss インフラ

サムスン電子

LG 電子

NCsoft

Toss — インフラ / トレーディング領域

その他の韓国企業

韓国C++ コミュニティ

15章 · 日本 — Sony PlayStation、Square Enix、Capcom、Bandai Namco

Sony Interactive Entertainment

Square Enix

Capcom

Bandai Namco

Konami

SEGA

日本の自動車 (Toyota、Honda、Nissan)

日本の家電 (Sony、Panasonic、Sharp)

日本のC++ コミュニティ

16章 · 誰がC++ を選ぶべきか — ゲーム / 組み込み / HFT / システム

C++ が正解のケース

Rust の方が良い可能性が高いケース

Go / Java / TypeScript が正解のケース

落とし穴

17章 · 結び — モダンC++ は依然として生きている

参考 / References

ISO 標準 / 委員会文書

リファレンス / 学習

コンパイラ / 標準ライブラリ

ビルドツール