この記事について海外で公開された情報をもとにAIが要約・解説した記事です。原文の翻訳ではありません。正確な内容は記事末尾の出典元をご確認ください。
この記事の要点
  • GitHubリポジトリを指定するだけで、ハーネス作成からクラッシュのトリアージまで自動実行する
  • 判断はLLMエージェント、実行はMCPツールという役割分離を設計の柱に据える
  • カバレッジが伸びないギャップに対し、シード追加や辞書拡張を反復して試す

公開された仕組み

GitHub Security Labは、C/C++プロジェクト向けの自律型ファジングパイプライン「Fuzzing Taskflow」を公開した。ファジングとは、ランダムに近い入力を大量に与えてクラッシュを探すテスト手法を指す。利用者はGitHubのowner/repo形式のスラッグを渡すだけでよく、あとはエージェントがAFLのインストール、リポジトリのクローン、コード内の主要関数の特定、ファズターゲットの作成までを自ら進める。

実行はCodespace上で完結する。例えばxzを対象にするなら./scripts/fuzzing/run_fuzzing.sh tukaani-project/xzを実行するだけで、まずは小さなcJSONで試すこともできる。ソースコードはオープンソースとして公開されていると述べられている。

3層アーキテクチャ

構成は3層に分かれる。パイプラインの各段階をつなぐシェルドライバ(run_fuzzing.sh)、段階ごとのプロンプトを記述したタスクフローYAML、そして実際の処理を担うMCPツールである。エージェントはAFLやclangを直接呼び出さず、run_afl_forやcompile_harnessといったプリミティブを組み合わせてパイプラインを構成する。

状態はすべてSQLiteデータベース(fuzz_context.db)に保存され、各段階はメモリ上でデータを受け渡さない。また各ハーネスは2回ビルドされる。AFLのエッジ計装はファザーの誘導には向くが人間が読めるカバレッジレポートには向かないため、ファジング用の.aflバイナリと、カバレッジ計測用の.covバイナリを別々に作る。

デフォルトのモデルはClaude Sonnet 5で、内部テストを問題なく通過したことが選定理由として挙げられている。設定ファイルを編集すれば別のモデルも選べる。

カバレッジを伸ばす反復

パイプラインの中核はカバレッジフィードバックループである。各イテレーションでエージェントは一定時間AFLを走らせ、キューの入力を.covバイナリで再実行して実際のカバレッジを取得し、未到達の分岐を読み取る。その結果に応じて、未到達分岐に届くシードの追加、ハーネスソースの編集、AFL辞書へのマジック定数の追加、あるいは追わない判断、のいずれかを選ぶ。

時間予算は30秒から60秒、120秒、240秒、480秒、960秒(約32分)へと倍増していく。序盤は短いラウンドで安く広げ、後半は長いラウンドで突破しにくいガードに挑む設計である。停止条件はプラトー検出で、2回連続のイテレーションの伸びが既定の閾値(絶対行カバレッジ1%)を下回ると打ち切る。

テキストベースの構造化入力に対しては、4つの仕組みで対応する。認識済みフォーマット(JSON、XML、regex、PNG、長さ前置きのバイナリTLV)向けの辞書とカスタムミューテータ、対象の.c/.hから文字列リテラルと32ビット定数を抽出するソースレベル辞書、カバレッジ結果に応じてガード付近のトークンを追記する動的辞書、そしてコーパスの一部を入力に接ぎ合わせるスプライス演算子である。

トリアージと注意点

ファジング終了後は3段階が自動で走る。クラッシュをafl-tminで最小化し、ASanで再実行してスタックトレースを取得、スタックトップのハッシュで重複を排除する。既知のクラッシュは現在のバイナリで再実行し、修正済みかどうかを確認する。最後にエージェントがハーネスとクラッシュ関数を読み、公開APIから呼び出し連鎖をたどってクラッシュごとのmarkdownレポートを書く。

レポートは実際の脆弱性とハーネス自体のバグ(harness_bug)を区別し、file:line付きの根本原因分析、到達可能性の論証、悪用可能性の評価、unified diff形式の修正案、回帰テストの下書きを含む。ただし修正案には「review required」が付く。エージェントの分析はモデルの対象コード理解に依存するため誤ることもあり、人間の出発点として扱うべきだと筆者は明記している。

実行には注意点がある。このタスクフローはafl-fuzzやclang、LLMが選んだ任意のビルドコマンドをコンテナを挟まずホスト上で直接実行する。プロンプトインジェクションを受けたエージェントは原理上ユーザーと同じ権限で何でもできてしまうため、使い捨ての環境で昇格権限なしに実行するよう求めている。

Fuzzing Taskflowが生成する2種類のハーネスバイナリの違い
バイナリビルドフラグ主な用途
.aflバイナリafl-clang-lto -fsanitize=address,undefinedファジングの実行
.covバイナリclang -fprofile-instr-generate -fcoverage-mappingキューの再実行によるカバレッジ計測
原文からの引用
The design rule I cared about most is a clean separation of responsibility: the LLM agent owns the decisions, and the MCP tools own the execution.

私が最も重視した設計原則は、責務の明確な分離である。判断はLLMエージェントが担い、実行はMCPツールが担う。

今後の見通し

Fuzzing Taskflowは、人手がボトルネックになりがちなファジングの反復作業をエージェントに委ねる試みである。今後は、どの程度の規模のプロジェクトまで実用的に回るのか、またエージェントが書いたハーネスや修正案の精度がどこまで実運用に耐えるのかが焦点になるとみられる。原文では、未到達分岐を追わない判断などエージェントの裁量に委ねられる部分が多く、その妥当性を測る指標は示されていない。実際の脆弱性発見件数や誤検知率といった実績データが公開されれば、導入判断がしやすくなる。エージェントがハーネス自体のバグをどの程度の頻度で出すのかも、評価の分かれ目になりそうだ。

日本の開発者・IT企業にとっての意味

日本のIT企業や開発者にとって、この発表はファジングの運用コストをどう下げるかという論点に直結する。C/C++で書かれた自社製品やOSSの依存ライブラリは、継続的なファジングが有効だと分かっていても、ハーネス作成やカバレッジ確認、クラッシュのトリアージを担う人手を確保しにくい。リポジトリのスラッグを渡すだけでこれらを試せるなら、これまでファジングに手を出せなかったチームが最初の一歩を踏み出しやすくなる。一方で、ホスト上で任意のビルドコマンドを実行する設計は、CIや開発端末にそのまま載せることをためらわせる。使い捨てのクラウド環境で動かし、得られたレポートを人間がレビューする工程を組み込む形が現実的だろう。既存のCIパイプラインへの組み込み方は、今後の検証が待たれる。

気になる点

実行環境は何が必要ですか。手元のPCでも動かせますか。
原文ではCodespaceまたは使い捨てVMでの実行を推奨している。afl-fuzzやclang、LLMが選んだビルドコマンドをコンテナを挟まずホスト上で直接実行するため、プロンプトインジェクションの影響を受け得るからだ。昇格権限を与えず、破棄できる環境で動かすのが前提となる。
使用するモデルは変更できますか。
変更できる。既定はClaude Sonnet 5で、内部テストを問題なく通過したことが理由として挙げられている。src/seclab_taskflows_fuzzing/configs/model_config.yamlを編集することで別のモデルを選択できる。モデルごとの利用コストについては原文に記載がない。
出力される脆弱性レポートはそのまま使えますか。
そのまま使うことは想定されていない。修正案には「review required」が付き、エージェントの分析はモデルの対象コード理解に依存して誤ることもあると筆者が明記している。file:line付きの根本原因分析や到達可能性の論証を含む、人間が確認するための出発点として位置づけられている。

用語解説

ファジング
ランダムに近い入力や変異させた入力をプログラムに与え、クラッシュや不具合を自動で探すテスト手法。
ハーネス
ファジングの対象となる関数を呼び出し、入力を渡して実行するための小さなプログラムやラッパーコード。
AFL++
カバレッジ情報を手がかりに入力を進化させる代表的なファザー。ファジングエンジンとして広く使われる。
MCP
Model Context Protocol。LLMエージェントが外部ツールを呼び出すためのプロトコル。
プロンプトインジェクション
入力やデータに紛れ込ませた指示によって、LLMエージェントを意図しない動作に誘導する攻撃。
ASan
AddressSanitizer。メモリ破壊などの不具合を実行時に検出するサニタイザー。

出典

AI-powered fuzzing with the GitHub Security Lab Taskflow Agent

GitHub / Antonio Morales / 2026年9月25日

https://github.blog/security/application-security/ai-powered-fuzzing-with-the-github-security-lab-taskflow-agent

AI導入も顧問も、お任せください

何から手をつけるか、どこまでAIに任せるか。自社の業務に合わせて整理し、導入から運用まで伴走します。相談だけでも構いません。

AI導入について相談する