資源リーク検出

概要

資源の解放漏れは、つくった直後は動いてしまい、ハッピーパスのテストもすり抜けます。本番で実行を重ねるうちにハンドルや接続が積み上がり、ある時だけ開けない・つながらないという再現困難な障害になります。実装の瞬間に「閉じていない資源」を機械的に拾い、枯渇が起きる前につぶすためのツールです。

効果

• 本番で徐々に進行し再現が難しい資源枯渇障害を、実装時に先回りで防ぐ。
• ファイル・接続・ロック・サブプロセスごとに位置・深刻度・直し方が出るため、その場で直せる。
• 決定的なので同じ入力には必ず同じ結果＝CIで件数・重大度をしきい値にしてゲート化できる。
• 誤検出を避ける保守的判定（with や対応する後始末があれば陰性）でノイズが少ない。
• それでも残る誤検出は report_outcome で報告すればallowlistに載り、以後は自動で抑制される（サーバは何も保存しないステートレス設計）。

インプット

• 実装コード

汎用LLMとの違い

どの呼び出しを資源確保とみなし、どの後始末を解放とみなすか（資源カタログ・確保と解放の対応規則）が bubo 独自の中核です。汎用LLMに「資源リークしてない？」と聞くより、構文木の規則照合で漏れなく・再現性高く拾い、with や対応する後始末を確認できる箇所は陰性にしてノイズを抑えます。

実際の入力と、返ってきた出力

同じコードと問いかけを、汎用AIと resource-leak-lint にそのまま渡した実際のやりとりです（要約ではありません）。

def persist_state(state: str, db_path: str = _DEFAULT_DB_PATH) -> None:
    conn = sqlite3.connect(db_path)
    cur = conn.cursor()
    cur.execute("CREATE TABLE IF NOT EXISTS device_state (id INTEGER PRIMARY KEY, value TEXT)")
    cur.execute("DELETE FROM device_state")
    cur.execute("INSERT INTO device_state (id, value) VALUES (1, ?)", (state,))
    conn.commit()


def load_state(db_path: str = _DEFAULT_DB_PATH) -> str:
    with sqlite3.connect(db_path) as conn:
        conn.execute("CREATE TABLE IF NOT EXISTS device_state (id INTEGER PRIMARY KEY, value TEXT)")
        row = conn.execute("SELECT value FROM device_state WHERE id = 1").fetchone()
...

SQLite接続のリークは的中させましたが、それとは別に「自己診断（run_selftest）がALARM復元後のブザーを無条件でOFFにする」というラベル外の指摘を最重要点として提示しました。これは実在しうる懸念ですが、リソースリーク観点の質問に対する回答としては論点がずれています。

verdict = block。3件検出（すべて unclosed_connection／high）
- persist_state (line 31) — 接続が確実に解放されていない
- persist_state (line 32) — 同上（カーソル）
- load_state() — 「with sqlite3.connect(...) はコミット/ロールバックのみで接続自体はcloseしない」という、見落としやすい仕様を明示して指摘

recall = 1.0（既知欠陥を的中）。

汎用LLMは「なんか問題ある？」という開かれた質問に対して指摘の幅を広げがちで、本来の観点（リソースリーク）以外の指摘に紙面を割いてしまうことがあります。resource-leak-lintは観点を固定した決定的解析のため、with文があっても接続がcloseされない見落としがちな仕様も一貫して拾います。

社外秘のコードを、どう守るか

ワンタイムコードは単回使用・有効期限7日・サーバーに平文保存はしません。発行したトークンは設定ファイルに直書きせず環境変数で参照します。既存のMCP設定がある場合も、壊さず冪等にマージします。

どう申し込み、どうつなぐのか

← QA向けMCPツール一覧へ戻る