ソフトウェアデバッグツール2026完全ガイド - gdb・lldb・rr・Pernosco・Replay.io・ASan・Valgrind・eBPF・perf・タイムトラベルデバッグ徹底解説

プロローグ — 2026年でもprintfは無敗、しかしオムニサイエントデバッガがすべてを変えた

2026年のデバッグについて最も正直な一文から始めよう。printfは今も無敗だ。 分散システムのどこかでNaNが現れたり、Kubernetesポッドが理由不明でOOMKillされたりすると、私たちはまずログ行を一本差し込む。コンパイラのベテランでもSREでも同じだ。

しかし同時に、2026年はオムニサイエント(omniscient)デバッグの時代でもある。Pernoscoは一度録画した実行を時間軸データベースとして再生し、任意の値をクエリできる。Replay.ioはブラウザセッションをクラウドに保存して、Reactコンポーネントのあらゆる状態を巻き戻す。rr 8.0はマルチスレッド録画を正式機能にし、Microsoft TTDはWindowsの本番ダンプを時間逆方向に歩く。「再現できない」という言い訳が、ますます受け入れられない文化が定着しつつある。

本稿は3つの軸を一度にたどる。

古典インタラクティブデバッガ — gdb、lldb、WinDbg、Delve、py-spy、Visual Studio
タイムトラベル・レコードリプレイデバッガ — rr、Pernosco、Replay.io、RevDeBug、TTD、IntelliTrace、Firefox WebReplay
動的解析・観測 — ASan、UBSan、TSan、Valgrind、Helgrind、Callgrind、Dr.Memory、perf、FlameGraph、eBPF、strace、JFR、async-profiler、OpenTelemetry

最後に、AIデバッグ(CursorのDebugモード、GitHub Copilot Debug、Devin)が実際にどこまで来ているか、日韓のデバッグ文化はどう違うかを整理する。

一行要約: 「再現できればほぼ終わり、再現できないなら録画せよ」。 この2文が2026年のデバッグツール選定の90%を決める。

1章・デバッグの3つの哲学 — printf、インタラクティブ、タイムトラベル

ツール名を覚える前に、3つの哲学を分離しよう。

哲学	中核行為	代表ツール	コスト	強み
Printfデバッグ	コードに出力を入れて再実行	`printf`、`console.log`、`tracing!`、`slog`	ほぼ0	どこでも動く、分散OK
インタラクティブ	稼働中プロセスに接続、ブレーク・ウォッチ	gdb、lldb、WinDbg、Delve、Chrome DevTools	中	深い状態検査、REPL
タイムトラベル	一度の実行を録画し時間軸で移動	rr、Pernosco、Replay.io、TTD、IntelliTrace	大	ハイゼンバグ、非決定性の制圧

3つは排他ではなく相補である。2026年のシニアエンジニアは3つすべてに通じている必要がある。ただしコストと効果の曲線が違う。

printfは情報がゼロのときに最強だ — どこで失敗しているかすら分からないとき。
インタラクティブは再現が容易なときに最強 — 一行で再現するNPE。
タイムトラベルは再現が困難なときに最強 — 1000回に1回起きるデータレース。

2章・gdb — GNUデバッガ、35年の標準

GDB(GNU Debugger)は1986年にRichard Stallmanが始めて以来、C/C++/Rust/Go/Adaの事実上の標準である。2026年時点でGDB 16.xが安定版であり、DWARF 5 デバッグ情報、Python 16スクリプティング、Ada/Rust/Fortranの式評価、マルチターゲットデバッグ、non-stopモード、逆実行まで備えている。

# 最も頻用のフロー
gcc -O0 -g3 -fno-omit-frame-pointer -o prog prog.c
gdb ./prog
(gdb) break main
(gdb) run arg1 arg2
(gdb) next               # 一行ステップオーバ
(gdb) step               # 関数内へ
(gdb) print *ptr         # 値の表示
(gdb) backtrace          # スタック表示
(gdb) watch counter      # counterが変わったら停止
(gdb) rwatch shared_x    # 読まれたら停止
(gdb) info threads
(gdb) thread 3
(gdb) continue

GDBのあまり知られていない武器が逆実行である。record fullまたはrecord btraceで命令トレースを録画してから、reverse-continue、reverse-next、reverse-finishで時間を逆に歩く。これがrrより前から存在する「元祖タイムトラベル」だ。代償はオーバーヘッドが大きいこと、x86_64に限定されること、マルチスレッドに弱いこと。

もう一つの武器がgdbserverとマルチターゲットである。組み込みボード上のgdbserverに接続して、ホスト側のGDBがARMバイナリをデバッグするワークフローが代表例だ。2026年にはRISC-Vボード、Zephyr RTOS、ESP32デバイスでも一般的である。

3章・lldb — LLVM陣営のモダンデバッガ

LLDBはLLVMプロジェクトのデバッガで、AppleがmacOS/iOSのXcodeに統合した結果、Appleプラットフォームの事実上の標準になった。2026年時点でLLDB 19.xが最新で、Swift/Rust/C++の式評価、JITベースの式実行、Python自動化、DAP(Debug Adapter Protocol)サーバモードが強みである。

clang -O0 -g -o prog prog.c
lldb ./prog
(lldb) breakpoint set --name main
(lldb) run
(lldb) frame variable
(lldb) thread backtrace
(lldb) expression -- some_func(42)
(lldb) memory read --size 4 --format x --count 16 $rsp
(lldb) breakpoint set --file foo.c --line 120 --condition 'i > 1000'

gdbとlldbの最大の違いはコマンド文法と拡張言語である。lldbのコマンドは動詞-目的語の形でやや長いが一貫しており、Pythonでの拡張が非常に深い。Apple Silicon ARM64デバッグ、iOSシミュレータデバッグ、Swiftの型システム評価は圧倒的にlldbである。

VS CodeもXcodeもlldbをDAPでラップしてGUIに露出する。ユーザはlldbのコマンドを直接知らずにブレークポイント、ウォッチ、ステップオーバを押す。しかし難しいバグが来たら結局デバッグコンソールでexpressionを直打ちすることになる。

4章・rr — Mozilla発の決定論的レコードリプレイ

rr(record and replay)はMozillaのRobert O'CallahanとKyle Hueyが2014年に公開したオープンソースツールである。中核アイデアは一行に収まる。

rr record ./prog
rr replay

rr recordはプロセスのシステムコール、シグナル、非決定性の源(rdtsc、スレッドスケジューリングなど)をすべてフックしディスクに書く。rr replayはその記録を使い同じ命令列を決定論的に再現する。その上にGDB互換インターフェースが乗る。

rr replay -- -ex 'break crash_function'
(rr) continue
(rr) reverse-continue
(rr) reverse-next
(rr) checkpoint
(rr) restart 1

rrの魔法はreverse-continueである。クラッシュ地点から逆に走らせれば、ある変数がいつ・どこで誤った値に変化したかを追跡できる。だから「use-after-free」「データレースのずっと後で起きるクラッシュ」「メモリ破壊の真の原因」といった問題に圧倒的に強い。

制約も明確である。x86_64 Linux限定、ハードウェアパフォーマンスカウンタ(PMU)が必要、AVX-512の一部命令は未対応、シングルコア直列化による約1.5〜3倍のオーバヘッド。2026年時点でrr 8.xはIntel CPUではほぼ完璧だが、AMD Zen5の一部SKUとApple Siliconでは動かない。

5章・Pernosco — オムニサイエントデバッグのクラウド実装

Pernoscoはrrの共同創設者たちが立ち上げた商用サービスである。中核アイデアは「rrの録画をクラウドにアップロードすれば、こちらが時間軸データベースとしてインデックス化して返す」というものだ。

伝統的デバッガは一時点で停止し、変数を見て、次の時点へ移動する。Pernoscoではすべての時点が同時に存在する。UIで変数をクリックすれば、その変数が生涯持ったすべての値と変更位置が即座に現れる。関数への全呼び出し、全引数、全戻り値を一度に見られる。これが「omniscient」の意味である。

項目	gdb + record	rr	Pernosco
録画	可、単一プロセス	強力、x86_64 Linux	強力
時間逆方向	可、遅い	可、速い	全変数で即時
マルチスレッド	弱い	良い	非常に良い
共有	トレースファイル	トレースファイル	1つのURLでチーム全体
価格	無料	無料	有料(エンタープライズ)

Pernoscoが解放した最大の課題はバグトリアージの非同期化である。エンジニアAがバグに遭遇したらrrで録画してPernoscoにアップロードする。エンジニアBは自分のノートPCでURLを開けば同じ実行を見られる。同じ場所・同じ時間にいる必要はない。

6章・Replay.io — ブラウザ時代のタイムトラベル

Replay.ioは同じ哲学をJavaScript・ブラウザ・Reactに適用したツールである。Mozilla DevToolsの原作者たちが作り、2026年にはReact、Next.js、Cypress、Playwrightと深く統合されている。

動作はこうだ。開発者がReplayブラウザ(Firefox/Chromiumのフォーク)でサイトを開き録画ボタンを押すと、あらゆるDOMイベント・ネットワーク・コンソール・Reactコンポーネント状態がクラウドに書き込まれる。そのURLを同僚に送れば、同僚は自分のマシンで同じ実行を時間軸で再生できる。

printステートメントを後付け — console.logを入れ直して再実行ではなく、UIから「この時点のprint文」を追加するとクラウドが当該時点の値を計算して返す。
React DevToolsの全コンポーネント状態を任意時点で — N回目のレンダリングとN+1回目でpropsがどう変わったかを直接比較する。
CI統合 — Cypress/Playwrightテストが失敗したらReplay録画が自動添付される。

これが意味することは大きい。フロントエンドの「私のPCでは動くんですけど」を永遠に終わらせられる。

7章・WinDbg PreviewとTime-Travel Debugging (TTD) — Windowsの答え

Windows陣営の答えがWinDbg Preview(2017年初公開、2026年Microsoft Store正式版)とその上のTTD(Time Travel Debugging)である。TTDはtttracer.exeでプロセスを録画して.runファイルを生成する。WinDbg Previewがそのファイルを開いてg-(go backward)、t-(step backward)、p-(step over backward)で時間を逆に歩く。

0:000> g
Breakpoint 0 hit
0:000> p-      ; 1行戻る
0:000> g-      ; クラッシュ直前まで戻り続ける
0:000> dx -r1 @$curprocess.Threads

TTDの強みは本番フレンドリ性である。本番のWindowsサーバで1時間のトレースを録画してUSBで持ち出せる。弱点はWindows-x64限定であることと、トレースファイルのサイズが非常に大きいことである。

Visual Studio IntelliTrace(Enterprise SKU限定)は.NET側の同等機能である。.NET 9/10コードで関数呼び出し粒度の「履歴デバッグ」を行う。命令単位ではなくイベントベースだが、コールツリーを遡る用途には十分だ。

8章・RevDeBug・Firefox WebReplay — その他のタイムトラベル家族

RevDeBugは.NET、Java、JavaScriptにコードインストルメンテーションでタイムトラベルを提供する商用ツール。CIで失敗したテストの直近N分を自動録画してPRに添付する機能が強力だ。
Firefox WebReplayは2019年にMozillaが試みて中断され、後にReplay.ioチームが事実上その精神を継承した。本家Firefox WebReplayは断片的にしか残っていない。
Cisco Joulescopeは厳密にはデバッガではなくマイクロアンペア単位の電力測定器だが、IoT/ファームウェアデバッグで「この行以後に平均電流が5mA上がった」という種類のバグ追跡に決定的である。時系列データという意味でタイムトラベルの一変種と呼べる。

9章・AddressSanitizer・UBSan・ThreadSanitizer — コンパイラが助ける動的解析

AddressSanitizer (ASan) はGoogleが2012年に公開したコンパイラベースのメモリ誤り検出器である。LLVMとGCCの両方に含まれ、2026年にはMSVCも正式サポートしている。コンパイル時にフラグ一行を加えるとあらゆるメモリアクセスの周囲にシャドウメモリ検査が挿入される。

clang -O1 -g -fsanitize=address -fno-omit-frame-pointer -o prog prog.c
./prog
==12345==ERROR: AddressSanitizer: heap-use-after-free on address 0x602000000010
    READ of size 4 at 0x602000000010 thread T0
    #0 0x401234 in main /home/x/prog.c:42:5
freed by thread T0 here:
    #0 0x4af8f0 in free
    #1 0x401111 in main /home/x/prog.c:39:5

検出対象はheap buffer overflow、stack buffer overflow、global buffer overflow、use-after-free、use-after-return、use-after-scope、double-free、メモリリーク(LeakSanitizerと併用時)。オーバーヘッドはおよそメモリ2倍、CPU 1.5〜3倍で、単体テストやCIで常時有効にするのが標準である。

姉妹ツールも同じインフラを使う。

UndefinedBehaviorSanitizer (UBSan) — -fsanitize=undefined。整数オーバーフロー、アラインメント違反、nullポインタ参照、シフトオーバーフローなどUBを捕える。
ThreadSanitizer (TSan) — -fsanitize=thread。happens-beforeアルゴリズムでデータレースを検出。
MemorySanitizer (MSan) — 未初期化メモリ使用を検出。ライブラリ全体をMSanビルドする必要があり、適用コストが大きい。
HWASan — ARM64のハードウェアメモリタグを使ってASanのオーバーヘッドを1.2倍程度まで下げる。

10章・Valgrind家族 — 仮想マシンの上ですべてを観る

Valgrindは1999年にJulian Sewardが始めたツールで、ユーザプロセスを仮想マシン上で実行しすべてのメモリアクセスをフックする。同じフレームワーク内に複数のツールを持つ。

ツール	機能
Memcheck	メモリエラー、リーク
Helgrind	POSIXスレッドのデータレース
DRD	別のデータレース検出器
Callgrind	コールグラフ + 命令数
Cachegrind	キャッシュシミュレーション
Massif	ヒーププロファイル

valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all ./prog
==12345== HEAP SUMMARY:
==12345==     in use at exit: 24 bytes in 1 blocks
==12345==   total heap usage: 3 allocs, 2 frees, 96 bytes allocated
==12345==
==12345== 24 bytes in 1 blocks are definitely lost in loss record 1 of 1
==12345==    at 0x4C2BBAF: malloc
==12345==    by 0x4006A8: leak_func (leak.c:7)

Valgrind対ASanのトレードオフは2026年でも興味深い。

項目	Valgrind/Memcheck	AddressSanitizer
再コンパイル必要	不要(任意のバイナリ)	必要
オーバーヘッド	約20〜50倍	約2〜3倍
検出範囲	非常に広い(uninit、細かいリーク)	非常に深いがスタック/ヒープ中心
マルチスレッド	弱い(Helgrindは別)	良い
外部ライブラリ	そのまま検査可	ASanビルド推奨
プラットフォーム	主にLinux	Linux/Mac/Windows

原則は単純だ。ソースとCIがあるならASan、他人のバイナリしかないならValgrind。

Dr.MemoryはValgrindの精神をWindowsとLinuxに同等に持ち込んだツールで、MSVCビルドのバイナリに強い。AppVerifierはWindows標準の類似ツールである。

11章・perfとFlameGraph — Linux性能デバッグの黄金コンボ

性能問題はデバッグの異端児だ。「クラッシュはしないが遅い」が最も捕まえにくいバグである。Linuxではperf(linux-tools)とBrendan GreggのFlameGraphが事実上の標準である。

# 99HzのCPUプロファイルを60秒採取
perf record -F 99 -g -p <PID> -- sleep 60
perf report --stdio | head -50
perf script | flamegraph.pl > flame.svg

perf script | flamegraph.plが生成するSVGは一言で「どこでCPU時間を使っているか一目」だ。シニアエンジニアが30秒でホットスポットを見つけるツールとしてよく使われる。

perfの拡張も併せて知っておきたい。

perf stat — 一度実行のPMUイベント要約(IPC、cache miss、branch miss)。
perf c2c — cache-to-cacheのfalse sharing検出。
perf lock — ロックコンテンション。
perf mem — メモリアクセスのサンプリング。

2026年にはperfが後述のeBPFツールに一部の地位を譲ったが、依然「最初に通る扉」である。

12章・eBPF・bpftrace・BCC・Tetragon — カーネルがデバッガを抱える

eBPF(extended Berkeley Packet Filter)は2026年で最も革新的なデバッグ・観測インフラだ。ユーザが書いた小さなプログラムがカーネル内の安全なVMで実行され、任意の関数の入出をフックしてデータをユーザ空間に送る。

# どのプロセスがどのファイルを開くか30秒間観察
sudo bpftrace -e '
  tracepoint:syscalls:sys_enter_openat {
    printf("%s %s\n", comm, str(args->filename));
  }'

# システム全体のread()レイテンシ分布
sudo bpftrace -e '
  tracepoint:syscalls:sys_enter_read { @start[tid] = nsecs; }
  tracepoint:syscalls:sys_exit_read /@start[tid]/ {
    @ns = hist(nsecs - @start[tid]);
    delete(@start[tid]);
  }'

ツール家族を整理するとこうだ。

bpftrace — DTrace風ワンライナー。一行で答えを得るのが最速。
BCC(BPF Compiler Collection) — Python/Cベースのより大きなツール群。tcpconnect、execsnoop、opensnoopなど100以上の即戦力ツールが入る。
Tetragon — Isovalentのセキュリティ・観測ツール。コンテナ内のシステムコール、ファイルアクセス、ネットワーク呼び出しをポリシーベースで捕える。
Pixie(New Relicが買収) — KubernetesクラスタをeBPFで自動観測。

eBPFの真の利点は本番安全性である。カーネルモジュールのようにpanicを起こさない。verifierが無限ループや不正メモリアクセスをコンパイル段階で遮断する。だから「本番でデバッグコードをオンにできる事実上唯一の方法」と評価される。

13章・strace・ltrace・dtrace — システムコール層のデバッグ

eBPFがあらゆる場所に行き渡る前、そして行き渡った後でも、straceは一級市民である。「プロセスが何をしているか1分で知りたい」とき最速のツールだ。

# すべてのシステムコールを追跡
strace -f -o trace.log ./prog

# 特定の呼び出しだけ・時間計測・引数デコード
strace -e openat,read,write -T -tt ./prog

# 起動中のPIDに接続
sudo strace -p 12345 -e network

ltraceは同じことを**ライブラリ呼び出し(libc、libsslなど)**のレベルで行う。dtraceはSolaris出身でmacOSに残っており、LinuxではeBPF、SystemTap、LTTngが同じ領域をより強力に占めている。

しばしば忘れられる小技。strace -cは「どのシステムコールに最も時間を費やしたか」を要約する。CPUプロファイルより速くI/Oバウンドかどうかを判別する手段だ。

14章・JFR・async-profiler・py-spy・Delve — 言語別デバッガ

言語ランタイムごとに専門化されたデバッグツールがある。

JFR(Java Flight Recorder) — JDK内蔵で常時オンにできるプロファイラ。オーバーヘッドおよそ1%。jcmd <pid> JFR.startの一行で始まる。
async-profiler — JFRの限界を補うオープンソース。ネイティブスタックも捕える。Linuxのperf_eventsと組み合わせる。
py-spy — CPythonプロセスにptraceまたはprocess_vm_readvで接続しGILを止めずにスタックをサンプリング。本番で安全である点が強力。
py-buggy — IPythonの上にインタラクティブデバッグモードを載せたモダンPDB代替。breakpoint()をより豊かに。
rust-gdb / rust-lldb / lldb-rust — Rust標準配布に同梱されるラッパ。Vec<T>、Box<T>、Resultを人間が読める形式で出力する。
Delve (dlv) — Goの事実上の標準デバッガ。dlv debug、dlv attach <pid>、dlv test。goroutine単位のデバッグが強み。
Bytecode Alliance debugging tools — WebAssemblyデバッグインフラ。wasm-debug、wasmtimeの-Dgdb-server、Component Modelのtraceツールが徐々に標準化されつつある。

# Goデバッグのフロー
dlv debug ./main.go
(dlv) break main.handleRequest
(dlv) continue
(dlv) goroutines
(dlv) goroutine 17
(dlv) stack
(dlv) locals
(dlv) print req.Body

15章・Chrome DevToolsとReact DevTools — フロントエンドデバッグの標準

ブラウザデバッグは独立した宇宙だ。Chrome DevToolsは2026年でも事実上の標準で、Firefox DevTools、Safari Web Inspectorが続く。

中核パネルを整理するとこうだ。

Sources — ブレークポイント、条件付きブレークポイント、ログポイント(console.logなしの一時ログ)、Workspace同期でディスクへ直接保存。
Performance — performance.markとperformance.measureによるユーザー定義タイムライン。
Memory — ヒープスナップショット、比較、リテイナツリー。リーク追跡の標準。
Network — HARエクスポート、スロットリング、オーバーライド(レスポンスを任意の偽データに置換)。
Application — IndexedDB、Service Worker、Storage検査。
Recorder — ユーザ操作を録画しPlaywright/Cypressスクリプトとして書き出す。

React DevToolsはこの上にコンポーネントツリー、props/state、Profilerを重ねる。2026年にはReact Compilerが自動でメモ化するので「なぜ再レンダリングしたか」の分析がより重要になり、React DevTools Profilerの「Why did this render?」パネルが標準解である。

ブラウザデバッグの最大の変化は、6章で見たReplay.ioの時間軸統合である。

16章・カーネルデバッグ — kgdb・crash・KASAN・KCSAN

カーネルは特殊だ。一般デバッガをそのまま使えない。2026年のLinuxカーネルデバッグツールは以下のように分化している。

kgdb — カーネル自体にGDB stub。シリアル/ネットワークで別マシンのGDBと接続。
kdb — カーネルコンソール上の基本デバッガ。シリアルケーブルと併用。
crash(Red Hat製) — vmcoreダンプ解析。パニック後の事後解析。
drgn — Meta製のPythonベースカーネル・コアダンプ解析器。カーネルのデータ構造をPythonオブジェクトとして公開。
KASAN(Kernel AddressSanitizer) — ASanをカーネルに適用。ビルドオプションでカーネルuse-after-freeやout-of-boundsを捕える。
KCSAN(Kernel Concurrency Sanitizer) — カーネルのデータレース検出。
KFENCE(Kernel Electric-Fence) — サンプリングベースのメモリ安全検査。本番で有効にできるほど軽量。
ftrace — カーネル関数トレーサ。perfと併用が最も多い。

eBPFがカーネルデバッグの多くを侵食したが、カーネル自体が死んだときにはcrash + drgn + vmcoreの組み合わせが正解だ。

17章・ハイゼンバグと再現性 — デバッグの真の敵

ハイゼンバグは「観測すると消えるバグ」というジョークだ。デバッガを当てると出ない、printfを入れると出ない、ASanを有効にすると出ない。こうしたバグが本当に難しいのは非決定性のせいである。

非決定性の源を分類するとこうなる。

源	例	対策ツール
スレッドスケジュール	データレース	TSan、Helgrind、rr
メモリ確保位置	UAFで新オブジェクトが同じアドレスに	ASan、hardened allocator
外部時刻/乱数	`time()`、`rand()`、`rdtsc`	rr(すべて録画)
ネットワーク遅延	RPCタイミング	Replay.io、OpenTelemetry
ハードウェア非決定性	rdtsc、cache miss	rr(rdtscフック)

これらすべての源を録画後再生で決定論的にする、というのがrr・Pernosco・TTD・Replay.io共通の価値提案である。

もう一つの解決策がproperty-based testingとfuzzingだ。AFL++、libFuzzer、Honggfuzz、Atheris(Python)が自動で入力を変異させクラッシュを誘発する。クラッシュが出たらそのコーパスから再現可能な単体テストを作る。

18章・本番でデバッグする — 観測可能性との境界

「ノートPCでは出ないが本番でだけ出るバグ」にはどう対処するか。2026年の答えは2つに分かれる。

観測可能性で十分な手がかりを集める — OpenTelemetry trace、構造化ログ、REDメトリクス、分散コンテキスト伝播。Datadog、Honeycomb、Grafana Tempo、Jaeger。
本番で安全なデバッグチャネルを置く — eBPF/bpftraceでライブ追跡、async-profilerで1%オーバーヘッドのプロファイル、JFRを24/7オン、py-spyでGILを止めずスタックサンプリング。

OpenTelemetryとデバッガの関係は直交(orthogonal)だ。OpenTelemetryは「どこで遅いか、どこでエラーか」を教える。その先がデバッガの領域である。良いシステムはこの2つを滑らかに接続する。たとえばOpenTelemetryのtrace IDをコアダンプファイル名に埋めておけば、興味あるtraceに対応するインスタンスのダンプを正確に拾える。

最強パターンはPernosco式の本番録画と非同期解析だ。一部の企業はrr録画をカナリホストで常時オンにし、クラッシュ時に自動でPernoscoへアップロードしている。

19章・ツール比較表 — 一望する2026デバッガ地形

+----------------+-----------+-----------+-----------+------------+-----------+
| ツール          | プラットフォーム | 録画      | 逆方向    | マルチスレッド | 価格      |
+----------------+-----------+-----------+-----------+------------+-----------+
| gdb            | Linux/Mac | record    | yes(遅い) | 弱い        | free      |
| lldb           | All       | -         | -         | 普通        | free      |
| WinDbg+TTD     | Windows   | tttracer  | yes       | 良い        | free      |
| rr             | Linux x64 | 強力      | yes       | 良い        | free      |
| Pernosco       | Cloud     | rrベース  | 即時      | 非常に良い   | 有料      |
| Replay.io      | Browser   | 強力      | yes       | n/a(JS)    | 有料      |
| IntelliTrace   | Windows   | yes       | yes(イベント)| 普通      | VS Ent.   |
| RevDeBug       | .NET/JVM  | yes       | yes       | 良い        | 有料      |
| Delve          | Linux/Mac | -         | -         | 良い        | free      |
| py-spy         | All       | sampling  | -         | 良い        | free      |
| Chrome DevTools| Browser   | -         | -         | n/a        | free      |
+----------------+-----------+-----------+-----------+------------+-----------+

この表の最大のメッセージは**「一つで全部はできない」**だ。C++サーバはrr+ASan、.NETデスクトップはWinDbg+TTD、フロントはReplay.io、GoマイクロサービスはDelve+Datadog、PythonデータパイプラインはPy-spy+JFR相当。

20章・AIデバッグ — Cursor、Copilot Debug、Devinが変えたもの

2026年で最も急速に変わる領域がAIデバッグである。

Cursor AI Debug — エディタ内でデバッガを自動制御する。「このテストはなぜ失敗するか?」と尋ねると自動でbreakpointを置き、実行し、変数を見て、仮説を立てて答える。
GitHub Copilot Debug — Copilotがデバッガの最初の指になった。クラッシュスタックを貼ると考えられる原因3つと次の手を提示する。
Devin / Replit Agent — 自律コーディングエージェントが「バグ→仮説→修正→テスト→PR」全体を試みる。小さなバグでは時々成功する。
Pernosco Copilot — Pernoscoが自社LLMを結合し「この変数が0になった理由」を時間軸で自動的に遡って自然言語で説明する。

AIデバッグが得意な領域と苦手な領域は明確に分かれる。

得意	苦手
スタックトレースの解釈	深いドメイン知識が必要なビジネスロジック
一般的なNullPointer系	並行性の微妙なデータレース
コードスタイルや小さなタイポ	外部システムとの相互作用
単一関数内のアルゴリズムバグ	マイクロサービス間の分散トランザクション

2026年の現実的な結論は**「AIはデバッガの最速の指であって、デバッガ自体ではない」**である。

21章・韓国エンジニアコミュニティのデバッグ文化

ネイバー・カカオ・LINE・クーパン・配民(いわゆるネカラクバ)、そしてToss・Daangn・Samsung・LGのデバッグ文化にはいくつか共通点がある。

社内APMと社内デバッガ — Pinpoint(ネイバー)、Scouter、Naver FE-newsでよく言及される社内RUM、カカオの分散トレーシング、LINEのPromgenといったツールがOpenTelemetry以前から進化してきた。
社内ビルドのASan/UBSan CIパイプライン — C++比重の大きいゲーム企業(Nexon・NC Soft・Smilegate)では、ビルドbotにASan/TSanが常時オンになっている。
障害ふりかえりとポストモーテム文化 — Toss、Woowa Brothers、カカオの公開ポストモーテム記事は韓国エンジニアリングブログの名物だ。「再現可能な単体テストで締める」が標準パターンである。
Kubernetes主体の運用とeBPF採用 — クーパンのCilium導入、カカオのeBPFセキュリティ事例が2024〜2026年に公開された。
社内LLMデバッグアシスタント — ネイバーのHyperCLOVA X、カカオのKoGPT派生の社内コードヘルパがデバッグペアの役を担う。

韓国コミュニティの強みはポストモーテムの公開性と具体性だ。「なぜこの変数がnullだったか」を社のブログで公開する文化が比較的強い。

22章・日本エンジニアコミュニティのデバッグ文化

日本は別の質感を持つ。

ライブデバッグ登壇文化 — Builderscon、JAWS、Rust.Tokyo、RubyKaigi、JJUG CCC、PyCon JPで「実際にステージ上でデバッグするセッション」が頻繁にある。RubyKaigiでは毎年ruby/debugメンテナがライブデモを行う。
ruby/debug、rdbg、debug.gem — Ruby 3.x標準デバッガを作った笹田耕一(SmartHR、元クックパッド)のシリーズが日本Ruby生態系のデバッグを支えている。
JVM主軸の大企業 — 楽天、LINEヤフー、SBI、メルカリでJFR + async-profilerの活用が深い。メルカリのSREブログはperf/FlameGraph事例を継続的に公開する。
ローカルC++組み込みデバッグの深さ — ソニー、キヤノン、キーエンス、パナソニックの組み込みチームがgdb + JTAG + Lauterbach TRACE32の組み合わせで深いデバッグを行う。
PFNと Preferred Networks — Python・CUDA・機械学習デバッグでNVIDIA Nsight、py-spy、torch.profilerを深く活用する事例が豊富。

文化的に日本は「再現可能な小さな例(MCVE)とクリーンなパッチ」を非常に重視する。オープンソースに報告されるバグレポートの平均品質が高いことで知られる。

23章・デバッグワークフロー・レシピ — 状況別ツールマッチング

最後に実戦マッチング表。

症状	一次ツール	二次ツール	三次ツール
C++サーバが時々SEGV	`gdb`コアファイル解析	ASan + 再実行	rr録画
Linux機が時々ハング	`dmesg`、`journalctl`	bpftraceシステムコール分布	crash + drgn
Nodeサーバがメモリリーク	Chrome DevToolsヒープスナップショット	clinic.js heap	jemalloc heap profile
React UIが時々誤描画	React DevTools Profiler	Replay.io録画	console.log時系列比較
Pythonジョブが遅くなる	`py-spy top --pid`	cProfile + snakeviz	scalene
Goサーバのgoroutineリーク	pprof goroutine	`dlv trace`	OpenTelemetry trace
JVMがGCで停止	1時間JFR録画	async-profiler alloc	GC log + GCViewer
Windows .NETクラッシュ	WinDbg + TTD	IntelliTrace	dotnet-dump
Linuxカーネルパニック	crash + vmcore	drgn	KASANビルドで再現
WebAssemblyの無限ループ	wasmtime --dbg	wasm-debug	rr(ホスト側)

表を暗記する必要はない。ただ**「症状に対する正しいツールを自分が知らないと自覚せよ」**がシニアとジュニアを分ける最大の差である。

24章・2030年のデバッグ — どこへ向かうか

最終章は短い予測だ。

レコードリプレイがIDE標準になる。VS Codeの「Record this run」ボタンが標準化される可能性が高い。
AIが仮説を立て、デバッガが実行する。CursorやDevinが先行展示したパターンがIDE標準機能に入る。
eBPFがOS抽象を作り直す。すべての観測・デバッグがカーネルレベルで統合され、コンテナ内でも安全にホストを観る。
ハードウェアデバッグチャネルが復権する。Intel Processor Trace、ARM CoreSight ETMがPMUベースのrr/Pernoscoの中核インフラとなり、RISC-Vは最初から標準仕様に取り込んでいる。
WebAssemblyデバッグが一級市民になる。Component Modelのtrace標準が決まれば、wasmモジュールも時間軸で観られる。
**「録画なしのデバッグは古い話」**という冗談が真剣な言葉になる。

最大の変化は文化だろう。2026年には「再現できず」がしばしば受け入れられる。2030年にはその言葉が「録画しなかった」の同義語になる。

25章・終わりに — ツールではなくマインドセット

この25章の本稿が結局やったのはツールのリストアップである。しかしデバッグの本質はツールではない。

良きデバッガのマインドセット。

**「私が間違っているはず」**を初期仮説に置く。コンパイラより自分のコードを疑え。
再現可能な最小例を作る。再現した瞬間に半分は終わる。
理論を立てて、それを殺そうとする。確証バイアスを避ける唯一の方法だ。
ログをよく残すことは未来の自分への手紙だ。構造化ログ・トレース・メトリクスが6ヶ月後の自分を救う。
録画せよ。コストは下がった。言い訳はもうない。

ツールは仮説を検証する指で、マインドセットは仮説を立てる頭だ。両方そろってはじめてバグの前で震えなくなる。

References

GNU GDB Documentation — https://sourceware.org/gdb/current/onlinedocs/gdb/
LLDB Project — https://lldb.llvm.org/
rr Project — https://rr-project.org/
Pernosco — https://pernos.co/
Replay.io Docs — https://docs.replay.io/
Google Sanitizers — https://github.com/google/sanitizers
Valgrind Project — https://valgrind.org/
Dr.Memory — https://drmemory.org/
Brendan Gregg — Linux Performance — https://www.brendangregg.com/linuxperf.html
bpftrace — https://bpftrace.org/
BCC — https://github.com/iovisor/bcc
Tetragon — https://github.com/cilium/tetragon
OpenTelemetry — https://opentelemetry.io/
Microsoft WinDbg + TTD Docs — https://learn.microsoft.com/windows-hardware/drivers/debugger/time-travel-debugging-overview
Java Flight Recorder Docs — https://docs.oracle.com/javacomponents/jmc.htm
async-profiler — https://github.com/async-profiler/async-profiler
py-spy — https://github.com/benfred/py-spy
Delve — https://github.com/go-delve/delve
drgn — https://github.com/osandov/drgn
Linux Kernel Sanitizers — https://docs.kernel.org/dev-tools/kasan.html