プロローグ — 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つに分かれる。

1. **観測可能性で十分な手がかりを集める** — OpenTelemetry trace、構造化ログ、REDメトリクス、分散コンテキスト伝播。Datadog、Honeycomb、Grafana Tempo、Jaeger。

2. **本番で安全なデバッグチャネルを置く** — 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章の本稿が結局やったのはツールのリストアップである。しかしデバッグの本質はツールではない。

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

1. **「私が間違っているはず」**を初期仮説に置く。コンパイラより自分のコードを疑え。

2. **再現可能な最小例**を作る。再現した瞬間に半分は終わる。

3. **理論を立てて、それを殺そうとする**。確証バイアスを避ける唯一の方法だ。

4. **ログをよく残すことは未来の自分への手紙だ**。構造化ログ・トレース・メトリクスが6ヶ月後の自分を救う。

5. **録画せよ**。コストは下がった。言い訳はもうない。

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

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