序文：デバッグは「追跡」から「対話」の時代へ
エンジニアが最も時間を溶かす作業、それは「デバッグ」だ。変数の値を追い、コールスタックを遡り、ドキュメントとコードを往復する。Python標準の`pdb`やその強化版である`ipdb`は、長らく我々の「メス」として機能してきた。しかし、現代の複雑怪奇なマイクロサービスや非同期処理、巨大なライブラリ群を相手にするには、メスだけでは足りない。
真のアーキテクトは、ツールをただ使うのではない。ツールを「拡張」し、自身の脳の外部ストレージとして再定義する。
今回は、Pythonデバッガの真髄である`pdb`を、ローカルLLM（AIエージェント）と直結させ、「なぜエラーが起きたのかをAIが解説し、その場で修正パッチを提案する」という、デバッグ体験を劇的に変貌させる究極のハックを伝授する。
—
1. 概念設計：なぜ pdb を AI に接続するのか
一般的なAI補完（GitHub Copilot等）は「コードを書く時」には強力だが、ランタイムの「動的な状態」を完全には把握していない。一方で、`pdb`は実行時のローカル変数、スタック、オブジェクトの状態をすべて握っている。
この「静的なコード解析」と「動的な実行状態」のミッシングリンクを埋めるのが、今回のAIエージェント接続だ。
技術的要諦：pdbのフック機能
`pdb`の実体は`pdb.Pdb`クラスである。このクラスのメソッドをオーバーライドすることで、プロンプトが表示される直前のコンテキスト（現在の行、周辺コード、スタックトレース、変数の値）をすべて横取りし、AIへのプロンプトとして成形できる。
—
2. 実装：AIデバッグ・エージェント「AIPdb」の構築
以下に、ローカルLLM（Ollama等）のAPIを叩き、デバッグ中のコンテキストから修正案を導き出すカスタムデバッガのプロトタイプを示す。
import pdb
import sys
import requests
import json
import inspect
class AIPdb(pdb.Pdb):
“””
pdb.Pdbを継承し、AI解析コマンドを追加した拡張デバッガ
“””
def __init__(self, args, kwargs):
super().__init__(args, kwargs)
self.prompt = “(AIPdb) ”
def do_ai(self, arg):
“””
‘ai’ コマンド: 現在のコンテキストをLLMに送信し、原因分析と修正案を取得する
“””
# 1. 現在のスタックフレーム情報を取得
frame = self.curframe
code_context = self._get_source_context(frame)
error_msg = str(sys.exc_info()[1]) if sys.exc_info()[1] else “Manual Breakpoint”
# 2. ローカル変数のサマリを作成（巨大なオブジェクトは間引く知性が必要）
local_vars = {k: str(v)[:100] for k, v in frame.f_locals.items() if not k.startswith(‘__’)}
prompt = f”””
あなたはシニアPythonエンジニアです。以下のデバッグ情報を分析してください。
【エラー内容】: {error_msg}
【現在の変数状態】: {local_vars}
【ソースコード周辺】:
{code_context}
原因を特定し、修正のための具体的なパッチコードを提示してください。
“””
print(“\n[AI Agent] 解析中…”)
try:
# ローカルLLM (Ollama) へのリクエスト例
response = requests.post(‘http://localhost:11434/api/generate’,
json={
“model”: “codellama”, # または llama3, mistral 等
“prompt”: prompt,
“stream”: False
}, timeout=30)
result = response.json().get(‘response’, ‘解析失敗’)
print(f”\n— AI 診断結果 —\n{result}\n”)
except Exception as e:
print(f”AI接続エラー: {e}”)
def _get_source_context(self, frame):
“””現在の行の前後5行を取得するヘルパー”””
try:
lines, start_line = inspect.getsourcelines(frame.f_code)
return “”.join(lines)
except:
return “ソースコードを取得できませんでした。”
ユーティリティ関数：これをコードに埋め込む
def set_trace():
AIPdb().set_trace(sys._getframe().f_back)
この実装の「震える」ポイント
- `do_ai`メソッドの追加: `pdb`は`do_xxx`というメソッドを定義するだけで、プロンプト上で`xxx`というコマンドを自作できる。
- 実行時コンテキストの注入: `inspect`モジュールと`frame.f_locals`を組み合わせることで、AIに対して「今、目の前で起きている真実」を伝えることができる。
—
3. 実務で差がつく pdb キーボードショートカット & コマンド
AIを使うまでもなく、`pdb`を使いこなせていないエンジニアは多い。生産性を極限まで高めるための「指に覚えさせるべき」操作を整理する。
| コマンド | 役割 | 現場での活用術 |
| :— | :— | :— |
| `l .` | 現在行の表示 | 迷子になったらまずこれ。周辺コードを再確認する。 |
| `longlist` (ll) | 関数全体の表示 | `l`よりも俯瞰的に、現在の関数全体のロジックを確認できる。 |
| `sticky` | 画面追従モード | `ipdb`で有効。スクロールせずに常に最新の実行行を画面上部に固定する。 |
| `j
| `interact` | 任意コード実行 | 現在のスコープで自由なPythonシェルを起動する。複雑なデータ加工を試すのに最適。 |
—
4. 神プラグインと設定ファイル（.pdbrc）のベストプラクティス
`pdb`を素のまま使うのは、IDEをプラグインなしで使うようなものだ。
推奨プラグイン: `ipdb` と `pdbpp`
- `ipdb`: IPythonの強力な補完機能、シンタックスハイライトをデバッガに持ち込む。
- `pdbpp`: `pdb`の完全互換でありながら、`sticky`モードや、より美しいスタックトレース表示を可能にする。
秘伝の `.pdbrc` 設定
ホームディレクトリに置く `.pdbrc` は、チーム全体で共有すべき知財である。
~/.pdbrc
補完機能を有効化
alias h help
頻繁に使うコマンドのエイリアス
alias ll longlist
alias nn next
alias cc continue
AIデバッガを自動ロードする設定（前述のAIPdbをモジュール化している場合）
import sys; from my_utils.debug import AIPdb;
—
5. チーム開発におけるデバッグ戦略の共有化
アーキテクトとして、個人のハックをチームの規約に落とし込む。
1. `breakpoint()` の活用: Python 3.7以降、`import pdb; pdb.set_trace()` と書くのは古い。`breakpoint()` を使い、環境変数 `PYTHONBREAKPOINT` で使用するデバッガ（`ipdb.set_trace`等）を切り替える運用を徹底せよ。
2. Docker環境でのデバッグ:
`docker-compose` でデバッグする場合、`stdin_open: true` と `tty: true` を設定しなければ `pdb` は動作しない。これをプロジェクトの `docker-compose.override.yml` に記述し、チームに共有する。
3. CIでのデバッグコード混入防止:
`pre-commit` フックに `debug-statements` を追加し、`breakpoint()` や `print()` がコミットされない仕組みを構築せよ。
—
結論：ツールを「育てる」者が勝つ
デバッグとは、孤独な作業ではない。今回紹介したようにLLMをデバッガの一部として組み込むことで、あなたは「世界最高の知能を持つペアプログラマー」をデバッグプロンプトの中に飼うことになる。
`pdb`のプロンプトで `ai` と打ち込んだ瞬間、スタックトレースの迷宮から解き放たれ、修正パッチが手元に届く。この未来は、すでにあなたの手の中にある。あとはこのコードを自分の環境に組み込み、メスを「知性を持ったレーザー」へと進化させるだけだ。