Anthropic の脆弱性発見ハーネスを運用者目線で読む — Claude に C/C++ のバグを探させる

結論: Anthropic が「Claude にバグを探させる」リファレンス実装を公開した

Anthropic が 2026 年、defending-code-reference-harness をオープンソースで公開しました。中身は 脅威モデリング / スキャン / トリアージ / パッチ用の 5 つの Claude Code Skillと、コードを実際にコンパイルして実行しながら攻める 7 段の自律スキャンハーネスの 2 階建てです。狙いは C/C++ のメモリ脆弱性（バッファオーバーフローのような、ポインタとメモリ確保まわりのバグ）を Claude に探させること。同時に発表された Claude Code Security の説明では、Claude Opus 4.6 が本番 OSS から 500 件超の脆弱性を見つけたとされています。運用者としてまず押さえるのは、これが「製品」ではなく 自分で組み替えるための参照実装だという一点です。

私は普段 Rails と Next.js を書く側で、C/C++ のメモリバグは正直ほぼ別世界の住人です。だからこそ「AI がメモリバグを自律で掘る」という話は、自分の足元に降りてくる前に構造だけ先に理解しておきたい。リポジトリの README と docs を読みながら、何が read/write だけ で安全に動き、何が コードを実行する ので危ないのかを、運用判断の軸で整理しました。

5 つの Skill と 7 段の自律ハーネス — 何が動くのか

要点から。このリポジトリは「人が対話しながら使う安全な Skill 群」と「無人で攻める自律パイプライン」がはっきり分かれていて、前者はファイルの読み書きしかしません。

Skill は Claude Code の .claude/skills/ に置かれた対話ツールで、/quickstart（30 秒の初回ガイド）、/threat-model（スキャン範囲を絞る脅威モデル作成）、/vuln-scan（範囲を絞った静的スキャン）、/triage（検出結果の検証・重複排除・ランク付け）、/patch（修正案の生成）、/customize（別言語・別検出器への移植）の 6 種です。これらは THREAT_MODEL.md や VULN-FINDINGS.json、TRIAGE.json といった成果物ファイルを書き出すだけなので、サンドボックス無しで回しても安全とされています。

一方、harness/ 配下の自律パイプラインは別物です。7 段で動きます。

1. Build — 対象を ASAN（AddressSanitizer、メモリエラー検出器）付きでコンパイル
2. Recon — エージェントがコードベースを注目領域に分割
3. Find — 複数エージェントが並列でクラッシュするまで不正な入力を作り続ける
4. Verify — 採点エージェントが新しいコンテナでクラッシュを再現
5. Dedupe — 判定エージェントが既知バグと重複排除
6. Report — レポートエージェントが悪用可能性を分析
7. Patch — パッチエージェントが修正を生成（別コマンド）

bin/vp-sandboxed run で起動し、--runs 3 --parallel --auto-focus のように並列度と試行回数を渡す設計です。fuzzing（ランダム入力でクラッシュを誘発する手法）の発想を、エージェントの推論で誘導している格好だと読みました。

「読み書きだけ」と「コードを実行する」の境界

結論。このツールで運用者が最初に引くべき線は、Skill の安全圏と、対象コードを実行する自律パイプラインの危険圏の間です。

自律ハーネスは攻撃対象のコードを 実際にビルドして実行するため、gVisor（Google 製のサンドボックス）での隔離が必須とされています。エージェントは隔離コンテナで動き、外部通信は Claude API への egress だけに制限される。エージェントを起動するサブコマンドは、サンドボックス外では明示的に上書きしない限り起動を拒否する作りになっています。ここは親切な設計で、docs/security.md と docs/agent-sandbox.md に詳細が置かれています。

つまり「試す」のハードルが工程ごとに違う。脅威モデルや静的スキャン、トリアージはファイルを読むだけなので手元で気軽に試せて、実際にクラッシュを誘発する段だけは Docker と gVisor のセットアップを要求される。この段差を理解せずに run を叩くと、自分の環境で信頼できないコードを実行することになります。

トリアージと偽陽性 — 500 件の「発見」をどう信じるか

先に要点。「500 件超を発見」という数字は魅力的ですが、運用上の本当のコストは検出ではなく 検証と偽陽性のふるい分けに出ます。

ハーネスが Verify / Dedupe / Report の 3 段を別エージェントとして持っているのは、まさにここが本丸だからだと読みました。クラッシュを再現できなければ報告しない、既知バグと重複していれば落とす、悪用可能性を分析してからレポートする。AI に「探させる」のは比較的やさしく、「その指摘が本物か」を人間が一件ずつ潰すのが現場では一番重い。私は以前、フロンティア LLM 同士が事実判定で割れる話を5 つの LLM が事実判定の 67% で割れるという記事で書きましたが、脆弱性のトリアージも構図は同じです。出力を鵜呑みにせず、再現条件まで確かめて初めて信用できる。

攻撃者は AI を使って、これまでより速く悪用可能な弱点を見つける。だが素早く動く防御側は、同じ弱点を先に見つけ、塞ぎ、攻撃のリスクを減らせる。

この「攻撃側も防御側も同じ AI を持つ」という前提が、ツールを公開する側の言い分です。だからこそ運用者は、検出数の派手さより、自分のコードベースで偽陽性をどれだけ削れるかという地味な指標で採否を測るべきだと思います。Claude Opus は推論の強さで知られていますが（Opus 4.8 を初日に触った記事でも effort control を試しました）、強いモデルでも「指摘の正しさ」は人間の検証とセットで初めて価値になります。

運用者として、これをどう迎えるか

結論。今すぐ本番に差し込む話ではなく、「AI に脆弱性を探させる仕組みの設計図」を、自分のスタックに引き寄せて読む段階です。判断材料を 3 つに絞ります。

まず、これは保守されない参照実装で、README にも「メンテナンスしない・コントリビュートも受け付けない」と明記されています。マネージドで使いたいなら Anthropic の Claude Security が別にある。つまり本リポジトリは「production にそのまま載せる SaaS」ではなく、「自分の言語・自分の脆弱性クラスに /customize で移植する土台」として読むのが筋です。次に、コストの見積もり。Find 段で複数エージェントを並列に走らせ、入力を作り続ける構造は、API トークンを素直に食います。エージェントを束で動かすときのトークン消費は、私がコンテキストエンジニアリングでトークンを半減させた記事で痛感した通り、設計次第で何倍にも振れる。最後に、期待値の置き方。「500 件発見」も「自律で攻める」も前提付きの主張なので、自分の対象・自分の言語で小さく回し、偽陽性率と再現性を実測してから採否を決めるのが、運用者として一番ズレない受け止め方です。

ちなみに本ブログは、AI が下書きを書き、私が公開前に確認・編集して投稿する形で運用しています。この記事も同じで、脆弱性ハーネスの /patch が「修正案を出すが、最終承認は人間」という設計になっているのを読みながら、起稿は AI・採否は人間という自分のワークフローと重なって、少し笑ってしまいました。AI は速い。速いものほど、人間のレビュー工程を省く理由にはならない。

まとめ: 探させるのは易しく、信じるのは難しい

defending-code-reference-harness は、Claude に C/C++ のメモリ脆弱性を探させるための、Skill とサンドボックス付き自律パイプラインの設計図です。持ち帰る点を並べます。

• 構成は 5 つの対話 Skill（threat-model / vuln-scan / triage / patch / customize ほか）+ 7 段の自律ハーネス（Build→Recon→Find→Verify→Dedupe→Report→Patch）
• 安全圏（ファイル読み書きだけの Skill）と危険圏（対象コードを実行する自律パイプライン、gVisor 必須）が明確に分かれている
• Claude Opus 4.6 が本番 OSS から 500 件超を発見したと主張。ただし価値は検出数より偽陽性のふるい分けに出る
• 保守されない参照実装。マネージドが欲しければ Claude Security が別にある

私はまず /quickstart と /triage という読み書きだけの入り口から触って、自律パイプラインは隔離環境を整えてから回します。検出数ではなく、偽陽性をどれだけ削れるかで採否を決めます。