2026 年 9 月 24 日の公式ブログで、GitHub Security Lab は LLM 駆動のファジングパイプライン Fuzzing Taskflow をオープンソース化した。GitHub のリポジトリアドレスを指定するだけで、エントリーポイントの自動特定、テストハーネスの作成、AFL++ の実行、カバレッジレポートの読み取り、テストケースの改善を行い、最後に各クラッシュを脆弱性レポートにトリアージする——人の監視は一切不要だ。
1 つのコマンドでパイプラインが自走する
セキュリティツールとは思えないほど使い方が簡単だ。コードは GitHub 上で公開されている（組織名 GitHubSecurityLab、プロジェクト名 seclab-taskflows-fuzzing）。Codespace を開いて ./scripts/fuzzing/run_fuzzing.sh tukaani-project/xz を実行すれば、残りはエージェントが引き受ける：AFL の依存関係のインストール、リポジトリのクローン、コード内のテストすべき関数の特定、その関数向けファズターゲットの生成だ。
作者の Antonio Morales はブログで明確な警告を添えている：このパイプラインは afl-fuzz、clang、LLM 自身が決めた任意のビルドコマンドをホストマシン上で直接実行し、間にコンテナ隔離はない。プロンプトインジェクションされたエージェントは理論上、ユーザアカウントができることは何でもできるため、使い捨ての環境（Codespace や使い捨て VM）でのみ実行し、昇格権限は決して与えてはならない。
エージェントは判断、ツールは実行
Fuzzing Taskflow は GitHub Security Lab の Taskflow Agent フレームワーク上に構築され、パイプライン全体が一連の taskflow として表現され、エージェントがエンドツーエンドで実行する。アーキテクチャは 3 層：各フェーズをつなぐシェルスクリプト、各フェーズのプロンプトを記述する YAML taskflow 群、そして AFL の実行・ハーネスのコンパイル・クラッシュの保存・カバレッジレポートの読み取りなど実際に働く MCP ツール群だ。
設計上の分業は明確だ：LLM エージェントが判断権を持ち、何をテストするか、どんなハーネスを書くか、次にどのカバレッジの穴を追うかを決める。MCP ツールは実行プリミティブのみを公開する。エージェントは AFL や clang を直接呼ばず、これらの積み木でパイプラインを組み立てる。すべてのフェーズの状態は SQLite データベースに保存され、フェーズ間でメモリデータを直接渡すことはない。
デフォルトのモデルは Claude Sonnet 5 で、全社内テストを通過し安全ガードレールを発動させなかったことが選定理由だ。モデルを変えたい場合は src/seclab_taskflows_fuzzing/configs/model_config.yaml を編集すればよい。
核心はカバレッジフィードバックループ
手動ファジングで最も骨が折れる 2 つの作業は、カバレッジレポートを読んで未カバー分岐を探すことと、その分岐向けに新しいハーネスを書くことだ。Fuzzing Taskflow はこの 2 つをエージェントに任せる：各ラウンドで各ハーネスに AFL 実行の時間予算を与え、実行後にキューをリプレイして真の行カバレッジと分岐カバレッジを生成し、未カバー分岐を読み取って、次のいずれかのアクションを選ぶ——その分岐を直撃する新シードの追加、ハーネスを改変して別の API を呼ぶ、条件を守るガードのマジックナンバーを AFL 辞書に自動補充する、あるいは冷門なエラーパスと判断してスキップだ。
時間予算はラウンドごとに倍増する：30 秒、60 秒、120 秒、最大で約 32 分。いつ止めるかは「停滞検出」：連続 2 ラウンドで絶対行カバレッジの増加が 1% 未満なら収穫逓減と判断し、次のターゲットに移る。最後の数分の 1 パーセントを搾り出すために計算資源を燃やさない。
JSON、XML、正規表現、PNG などの構造化入力向けには 4 つの補完メカニズムも備える：プリセットの形式辞書とカスタムミューテータ、ターゲットのソースコードから文字列定数をスキャンして自動生成するソースレベル辞書、カバレッジに応じて動的に成長する辞書、そしてコーパススプライシング演算子だ。
最も面倒なクラッシュトリアージも自動化
クラッシュを見つけるのは仕事の半分で、トリアージの方が時間を食うことが多い。ファジング後、パイプラインは自動で 3 段階を踏む：各クラッシュを afl-tmin で最小化し、ASan 下でリプレイしてスタックを取得し、「スタックトップハッシュ」で重複排除する。次に、過去の既知クラッシュをすべて新バイナリ上でリプレイし、上流の修正で解決済みかを確認する。最後にエージェントがハーネスのソースとクラッシュ関数を読み、コールチェーンを遡って、各クラッシュごとに Markdown レポートを書く。
各レポートには verdict が付く：真の vulnerability、library_hardening、ハーネス自体のバグ、OOM、タイムアウト、アサーション失敗、重複のいずれか。「本物のバグ」と「ハーネスの書き間違い」の区別こそ、かつては人が座ってコードを 1 行ずつ追うしかなかった判断だ。各レポートには、根本原因分析（ファイル・行番号付き）、到達可能性の論証、悪用可能性の評価、「要人手レビュー」と明記された unified diff 形式の修正案、回帰テストの草案も含まれる。
起動後はポート 8765 でリアルタイムダッシュボードが開き、各ハーネスのハートビート、カバレッジ推移、クラッシュヒートマップ、イテレーションのタイムラインを確認できる。
OSS メンテナがまず試せる
最も直接的な受益者は、「ファズすべきと分かっているが人手がない」C/C++ OSS プロジェクトのメンテナだ。OSS-Fuzz 導入後も、ハーネス作成、カバレッジ監視、クラッシュトリアージは人手が残っていた——その部分をエージェントが引き受ける。もちろん Morales 自身も認める通り、エージェントの verdict はあくまで「よく準備された出発点」であり最終結論ではない。レポートの修正案に「要レビュー」と明記されているのには理由がある。
興味深いのは、コードセキュリティに AI を持ち込むのは GitHub だけではないことだ。当サイトでは以前 Cursor の Security Reviewer を報じたが、あちらは「PR ごとにスキャン」の流儀、GitHub のこれは「深掘りファズ」の流儀だ。増分コードを守るものと、既存コードを守るものが、ちょうど互いに補完し合う。
