室谷代表取締役GitHubが、C/C++プロジェクト向けの自律型ファジングパイプライン「Fuzzing Taskflow」を発表したんですよね。GitHub Security Labが2026年9月24日に公開したブログで、仕組みから使い方までかなり具体的に書かれています。
テキトー教師DotAI 認定講師Fuzzing Taskflowは、GitHub Security Labが2026年9月24日に発表した、C/C++リポジトリ向けの自律型ファジングパイプラインです。GitHubリポジトリを指定するだけで、エントリポイントの特定、ビルド解析、ハーネス作成、AFL++の実行、カバレッジの読み取り、ハーネスの改善、クラッシュのトリアージ、脆弱性レポートの作成までを人手なしで行うとされています。
室谷代表取締役これはGitHub Security Labの「Taskflow Agent」というフレームワークの上に作られているんですよね。Taskflow Agent自体は2026年1月のブログでCodeQLアラートのトリアージに使われて、約30件の実脆弱性の発見が報告されている実績がある、と。
テキトー教師DotAI 認定講師そうなんですよ。単に新しいツールが出たという話じゃなくて、「LLMエージェントにセキュリティ作業のどこまでを任せられるか」という同Labの一連の実験の延長線上にある発表なんです。
GitHub Fuzzing Taskflowとは？何が発表されたのか
まとめ
GitHub Fuzzing Taskflowとは
- 「ファジングを便利にするツール」ではなく「ファジング運用に必要な人間の作業をどこまでエージェントに渡せるか」という問いから作られた
- 公式ブログは継続的ファジングを「魔法の解決策ではない」と明言。OSS-Fuzzに長年登録されたプロジェクトでも重大なバグが残り、理由はほぼ常に同じ
- 理由は「人間が足りない」こと。カバレッジ監視、未到達コードへの新ハーネス作成、クラッシュの仕分けというループに人が必要だった
- ファジングにはhuman in the loop(人間の介在)が不可欠で、その人間の作業をLLMエージェントに引き渡す試みとして位置づけられる
- 発表元はGitHub Security Lab。基盤はTaskflow Agentで、パイプラインは一連のタスクフローとして表現されエージェントが端から端まで実行
- 単体の新製品ではなく、Taskflow Agentという既存フレームワーク上に組まれた「ファジング用のタスクフロー群」。YAMLとMCPツールという設計が効いてくる
室谷代表取締役まず押さえておきたいのが、これは「ファジングを便利にするツール」というより、「ファジング運用に必要な人間の作業をどこまでエージェントに渡せるか」という問いから作られたものだという点なんですよね。
テキトー教師DotAI 認定講師そのとおりです。公式ブログでも、継続的ファジングは「魔法の解決策ではない」と明言されています。
OSS-Fuzzに長年登録されているプロジェクトでも重大なバグが残ることがあり、その理由はほぼ常に同じだと。
OSS-Fuzzに長年登録されているプロジェクトでも重大なバグが残ることがあり、その理由はほぼ常に同じだと。
室谷代表取締役理由が「人間が足りない」という話なのがつらいところで。カバレッジを監視して、誰も到達していないコードに新しいハーネスを書いて、出てきたクラッシュを仕分けする。
このループに人が必要だった、と。
このループに人が必要だった、と。
テキトー教師DotAI 認定講師つまりファジングには「human in the loop（人間の介在）」が不可欠だったわけです。Fuzzing Taskflowは、その人間の作業をLLMエージェントに引き渡す試みとして位置づけられています。
室谷代表取締役発表元はGitHub Security Labで、基盤はTaskflow Agent。パイプラインは一連のタスクフローとして表現され、エージェントが端から端まで実行する形になっているんですよね。
テキトー教師DotAI 認定講師はい。ここで大事なのは、Fuzzing Taskflowが単体の新製品というより、Taskflow Agentという既存フレームワーク上に組まれた「ファジング用のタスクフロー群」だという構造です。
だからこそ、後で説明するYAMLとMCPツールという設計が効いてきます。
だからこそ、後で説明するYAMLとMCPツールという設計が効いてきます。
Fuzzing Taskflowでできること——ハーネス作成から脆弱性レポートまで
Fuzzing Taskflowでできること（ハーネス作成から脆弱性レポートまで）
- 01エントリポイントの特定GitHubリポジトリを指定すると適切なエントリポイントを特定
- 02ビルドシステムの解析
- 03ハーネスの作成
- 04AFL++の実行
- 05カバレッジレポートの読み取り従来は人間が担当。未到達のブランチを探す作業
- 06ハーネスの改善従来は人間が担当。新しいハーネスや新しい入力を書いてカバレッジを改善
- 07クラッシュのトリアージ
- 08ユニークなバグごとの脆弱性レポート作成パイプラインの終端。人間が読める形にまとめるところまで一気通貫
室谷代表取締役できることの範囲がかなり広いんですよね。GitHubリポジトリを指定すると、まず適切なエントリポイントを特定して、ビルドシステムを解析して、ハーネスを書いて、AFL++を回して、カバレッジレポートを読んで、ハーネスを改善して、クラッシュをトリアージして、ユニークなバグごとに脆弱性レポートを書く、と。
テキトー教師DotAI 認定講師整理するとこうです。
- エントリポイントの特定
- ビルドシステムの解析
- ハーネスの作成
- AFL++の実行
- カバレッジレポートの読み取り
- ハーネスの改善
- クラッシュのトリアージ
- ユニークなバグごとの脆弱性レポート作成
室谷代表取締役このうち従来「人間がやっていた」と公式ブログが明言しているのが、カバレッジを見て未到達のブランチを探す作業と、新しいハーネスや新しい入力を書いてカバレッジを改善する作業なんですよね。
テキトー教師DotAI 認定講師そこをエージェントに渡すのが今回の核心です。しかもレポート作成まで含まれているのが大きい。
トリアージした結果を人間が読める形にまとめるところまで一気通貫でやる、という設計になっています。
トリアージした結果を人間が読める形にまとめるところまで一気通貫でやる、という設計になっています。
室谷代表取締役ただ、ここで注意したいのは、これは「脆弱性を自動で修正する」ものではないということですよね。あくまで発見とレポートまで。
修正やパッチの話は今回のソースには出てきません。
修正やパッチの話は今回のソースには出てきません。
テキトー教師DotAI 認定講師そうですね。公式ブログの説明でも、パイプラインの終端は「ユニークなバグごとの脆弱性レポート」です。
そこから先は人間が確認する前提だと読めます。
そこから先は人間が確認する前提だと読めます。
なぜ今、ファジングの自動化なのか——従来の「人間の介在」という課題
まとめ
ファジング自動化の背景と課題
- ファジングは新しい技術ではなく、ランダム/変則的な入力を大量に与えてクラッシュを検出する手法
- C/C++のようなメモリを直接扱う言語でバッファオーバーフローなど重大な脆弱性の発見に有効
- 中核はAFL++のようなファザーで、カバレッジを手がかりにコードを深く探索する
- 人間依存だった3つの工程: カバレッジ監視、未到達コードへの新ハーネス作成、クラッシュの仕分け
- 継続的に回すほど新コード・新未到達領域が出るため、継続的に人間が張り付く必要があった
- OSS-Fuzzに長年登録されているプロジェクトでも重大なバグが残る=人が足りていない領域がある証拠
- LLMがコードの意味や論理を扱えるようになり、人間なら分かる判断をエージェントに寄せられるようになった
- 前身の取り組みではツールは基本的なファイル取得と検索のみ(静的/動的解析はCodeQLのアラート生成以外未使用)でも約30件の実脆弱性を発見
- 「ツールは最小限、判断はLLM」という思想がFuzzing Taskflowにも流れ込んでいる
室谷代表取締役ファジングそのものは新しい技術ではないんですよね。ランダムあるいは変則的な入力を大量に与えてクラッシュを検出する手法で、C/C++のようにメモリを直接扱う言語ではバッファオーバーフローなど重大な脆弱性の発見に有効とされています。
テキトー教師DotAI 認定講師中核になるのがAFL++のようなファザーで、対象コードのどこを実行したかを示す「カバレッジ」を手がかりに、より深くコードを探索します。ここまでは従来どおりです。
室谷代表取締役問題はその先で。カバレッジを監視して、誰も到達していないコードに新しいハーネスを書いて、出てきたクラッシュを仕分けする。
この3つが人間依存だったわけです。
この3つが人間依存だったわけです。
テキトー教師DotAI 認定講師しかもこれは「一度やれば終わり」ではないんですよ。ファジングを継続的に回すほど、新しいコードが入ってきて、新しい未到達領域が出てくる。
だからこそ「継続的ファジング」と言いながら、継続的に人間が張り付く必要があった。
だからこそ「継続的ファジング」と言いながら、継続的に人間が張り付く必要があった。
室谷代表取締役OSS-Fuzzに長年登録されているプロジェクトでも重大なバグが残る、というのがその証拠なんですよね。登録しているのに、人が足りていない領域がある、と。
テキトー教師DotAI 認定講師ここが「なぜ今か」の答えです。LLMがコードの意味や論理をある程度扱えるようになったことで、従来は正規表現やパターンマッチでは捉えきれなかった「人間なら分かる」判断をエージェントに寄せられるようになった。
ファジングのボトルネックだった人間の介在を、そこに置き換えにいく流れなんです。
ファジングのボトルネックだった人間の介在を、そこに置き換えにいく流れなんです。
室谷代表取締役実際、Taskflow Agentの前身の取り組みでは、LLMに与えたツールは基本的なファイル取得と検索だけで、静的な解析ツールや動的な解析ツールはCodeQLのアラート生成以外に使っていない、と書かれています。それでも約30件の実脆弱性が見つかった、と。
テキトー教師DotAI 認定講師この「ツールは最小限、判断はLLM」という思想が、Fuzzing Taskflowにもそのまま流れ込んでいます。
Fuzzing Taskflowの仕組み——LLMが判断し、MCPツールが実行する
室谷代表取締役ここが一番おもしろいところなんですけど、アーキテクチャが3層に分かれているんですよね。
テキトー教師DotAI 認定講師整理するとこうです。
- シェルドライバ（run_fuzzing.sh）がパイプラインの各段階をつなぐ
- 段階ごとのタスクフローYAML（実質はプロンプト）が、各ステップでLLMエージェントに何をすべきかを伝える
- MCPツール群が実際の作業を行う（AFLの実行、ハーネスのコンパイル、クラッシュの保存、カバレッジレポートの読み取りなど）
室谷代表取締役設計原則がはっきりしていて、「LLMエージェントが判断を所有し、MCPツールが実行を所有する」という分離なんですよ。エージェントは何をファズするか、どんなハーネスを書くか、次にどのカバレッジギャップを追うかを決める。
ツールはrun_afl_forやcompile_harnessといったプリミティブを提供するだけ。
ツールはrun_afl_forやcompile_harnessといったプリミティブを提供するだけ。
テキトー教師DotAI 認定講師エージェントはAFLやclangを直接呼ばない、というのがポイントです。ビルディングブロックを組み合わせてパイプラインを構成する。
この分担が、判断の再現性と実行の安全性を分けて考えられるようにしています。
この分担が、判断の再現性と実行の安全性を分けて考えられるようにしています。
室谷代表取締役状態は全部SQLiteデータベース（fuzz_context.db）に置かれるので、各段階がメモリ上でデータを渡し合うことはなく、データベース経由だけで受け渡す、と。
テキトー教師DotAI 認定講師もう一つ細かいけど重要なのが、各ハーネスが2回ビルドされる点です。AFLのエッジ計装はファザーを導くのには優れているけれど、人間が読めるカバレッジレポートには向かない。
だからすべてのハーネスが.aflバイナリ（afl-clang-lto -fsanitize=address,undefinedでビルド）と.covバイナリ（clang -fprofile-instr-generate -fcoverage-mappingでビルド）の両方になる。
だからすべてのハーネスが.aflバイナリ（afl-clang-lto -fsanitize=address,undefinedでビルド）と.covバイナリ（clang -fprofile-instr-generate -fcoverage-mappingでビルド）の両方になる。
室谷代表取締役.aflバイナリがファジングを担当して、.covバイナリが後からAFLのキューを再生して、実際のソース行とブランチのカバレッジを出す、という役割分担なんですよね。
テキトー教師DotAI 認定講師この二重ビルドがあるからこそ、「カバレッジを読む」という人間の作業をエージェントが代替できるわけです。
室谷代表取締役あと、カバレッジフィードバックループの時間予算がおもしろくて。30秒 → 60秒 → 120秒 → 240秒 → 480秒 → 960秒（約32分/ターゲット）と、毎回倍々に増えていくんですよ。
テキトー教師DotAI 認定講師狙いは明確で、序盤は取れるカバレッジが多いので安く短いラウンドを回し、終盤は難しいガードを突破するのに時間がかかるので長いラウンドにする。人間が手でやるときの感覚をそのままルール化したような設計です。
室谷代表取締役そして停止条件がプラトー検出で、2回連続のイテレーションでカバレッジの伸びが一定以下になったら止める、と。
テキトー教師DotAI 認定講師未到達ブランチを見つけたときのエージェントの選択肢も整理されていて、未到達ブランチに届くための新しいシードを追加する、ハーネスのソースを編集して追加のAPIを呼ぶ、ガードが比較しているマジック定数をAFL辞書に自動で足す、コールドなエラーパスやベンダーコードなら追わずにスキップする、という数個のアクションから選ぶ形になっています。
室谷代表取締役ここ、地味にすごいんですよね。「追わない」という判断も選択肢に入っているのが、実運用を分かっている感じがして。
テキトー教師DotAI 認定講師ええ。全部のギャップを追うのではなく、費用対効果で捨てる判断まで含めてエージェントに渡している。
これは手動ワークフローをそのまま写しているからこそ出てくる設計です。
これは手動ワークフローをそのまま写しているからこそ出てくる設計です。
Fuzzing Taskflowの使い方・始め方——対象リポジトリと実行環境
室谷代表取締役使い方はかなりシンプルにまとまっていて、GitHubSecurityLab/seclab-taskflows-fuzzing に行ってCodespaceを立ち上げて、スクリプトを実行するだけなんですよね。
テキトー教師DotAI 認定講師コマンドはこうです。
code
./scripts/fuzzing/run_fuzzing.sh PROJECT例えばxzならこうですね。
code
./scripts/fuzzing/run_fuzzing.sh tukaani-project/xz引数はGitHubのowner/repoスラッグだけ。あとはエージェントが前処理を自分でやります。
AFLなどのソフトウェアのインストール、リポジトリのクローン、コード内で最も関連性の高い関数の特定、それらの関数のファズターゲットの作成まで。
AFLなどのソフトウェアのインストール、リポジトリのクローン、コード内で最も関連性の高い関数の特定、それらの関数のファズターゲットの作成まで。
室谷代表取締役長いキャンペーンに入る前に軽くスモークテストしたいなら、小さめの対象を指定するといいと。公式ブログではcJSONが例に挙げられています。
code
./scripts/fuzzing/run_fuzzing.sh DaveGamble/cJSONここで必ず伝えておきたい警告があります。このタスクフローは、afl-fuzz、clang、そしてLLMが選んだ任意のビルドコマンドを、コンテナを挟まずにホスト上で直接実行します。
室谷代表取締役つまりプロンプトインジェクションを受けたエージェントは、原理的にはユーザーができることは何でもできてしまう、と。だから使い捨ての環境（Codespaceや捨てる前提のVM）で、昇格した権限なしで実行してください、という注意が明記されているんですよね。
テキトー教師DotAI 認定講師これはセキュリティツールを扱う上で非常に重要な注意点です。便利さと引き換えに、実行環境の隔離を自分で担保する必要がある。
講座でも、こういう「エージェントに実行権限を渡す系」のツールは必ず隔離環境で、と伝えています。
講座でも、こういう「エージェントに実行権限を渡す系」のツールは必ず隔離環境で、と伝えています。
室谷代表取締役モデル選択についても書かれていて、既定はClaude Sonnet 5。これは内部テストを問題なく通過したからだそうで、変更したい場合はsrc/seclab_taskflows_fuzzing/configs/model_config.yamlを編集する、と。
テキトー教師DotAI 認定講師フロンティアモデルの中には出力にセキュリティガードレールを課すものがある、という文脈で既定モデルが選ばれている、という説明になっています。
室谷代表取締役あと、これはオープンソースとして公開されている点も見逃せないですよね。seclab-taskflow-agentとseclab-taskflowsの両リポジトリがオープンソースで、誰でも同様のタスクを実行するLLMタスクフローを開発できる、と。
テキトー教師DotAI 認定講師ライセンスの詳細については、今回のソースでは明らかにされていません。リポジトリを確認する必要があります。
従来のファジングと何が変わる？自動化される範囲と限界
室谷代表取締役ここまで読むと「全部自動化されるのか」と思われがちなんですけど、公式ブログはかなり慎重に書いていて。継続的ファジングは魔法の解決策ではない、という前提から始まっているんですよね。
テキトー教師DotAI 認定講師自動化される範囲を整理するとこうです。
- 自動化される: エントリポイント特定、ビルド解析、ハーネス作成、AFL++実行、カバレッジ読取、ハーネス改善、クラッシュのトリアージ、脆弱性レポート作成
- 人間が担う前提として残る: 実行環境の隔離、レポートの最終確認、修正の判断
室谷代表取締役特に実行環境の隔離は、公式が明示的に「使い捨て環境で」と書いている以上、人間側の責任として残っている部分です。
テキトー教師DotAI 認定講師それと、Taskflow Agentの前身の取り組みでは、LLMにエクスプロイトを作らせて結果を検証させる指示はしておらず、実行環境も与えていなかった、と書かれています。それでも結果はかなり正確だった、という報告です。
室谷代表取締役つまり「自動検証まではしていない」というのが現時点の正直な姿なんですよね。レポートは出るけれど、それが本当に悪用可能かどうかの最終判断は人間がやる、と。
テキトー教師DotAI 認定講師あと、前身の取り組みでは、レポートのフォーマットと情報の一貫性をチェックして、情報が欠けていたり矛盾していたりする場合はハルシネーションなどの可能性が高いとしてレポートを却下する、という検証ステップも入っていました。
室谷代表取締役そういう「出力をそのまま信じない」設計が組み込まれているのは、実運用に乗せる上でかなり現実的ですよね。
テキトー教師DotAI 認定講師さらに、GitHub Issueを作って人間がレビューできるチェックポイントにする、という設計も引き継がれています。レビューで見つかった誤検知の理由を記録しておくと、次回以降エージェントがそれを踏まえて判断できるようになる、という学習の仕組みです。
室谷代表取締役ここは「エージェントが勝手に学習する」というより、人間のレビュー結果をリポジトリ固有の知識としてプロンプトに足していく運用なんですよね。
テキトー教師DotAI 認定講師そのとおりです。だからこそ、いきなり全自動で任せるというより、まず小さめのリポジトリでスモークテストして、レポートの質を見ながら運用に組み込んでいく、という始め方が現実的だと思います。
室谷代表取締役MYUUUでも、エージェントに実行系の権限を渡すときは、まず隔離環境で小さく試すところから始めています。いきなり本番リポジトリに向けるのは危険すぎますからね。
テキトー教師DotAI 認定講師講座でも受講生さんによく言うんですが、こういうツールは「何を自動化して、何を人間に残すか」を先に決めてから触るのが大事です。今回のFuzzing Taskflowは、その線引きが公式ドキュメントにかなり明示されている珍しい例だと思います。
よくある質問
室谷代表取締役ここからは、検索で気になりそうな点を整理していきますね。
テキトー教師DotAI 認定講師まず、Fuzzing Taskflowは誰が提供しているのか。これはGitHub Security Labが発表・提供しているもので、GitHub Security Lab Taskflow Agentというフレームワークの上に構築されています。
室谷代表取締役対応している言語はC/C++です。公式ブログでもC/C++プロジェクト向けの自律型ファジングパイプラインと明記されています。
テキトー教師DotAI 認定講師使うのに料金はかかるのか、という点については、今回のソースでは明らかにされていません。リポジトリがオープンソースとして公開されていること、Codespaceから始められることは書かれています。
室谷代表取締役日本で使えるかという点も、今回のソースでは明らかにされていません。ただしGitHubリポジトリを指定してCodespaceで実行する形なので、リポジトリにアクセスできる環境であれば同じ手順になる、というのが読み取れる範囲です。
テキトー教師DotAI 認定講師既定モデルはClaude Sonnet 5で、変更したい場合はmodel_config.yamlを編集する、というのが公式の説明です。
室谷代表取締役どんなリポジトリに向くのかというと、公式ブログではまず小さめの対象でスモークテストするのが推奨されていて、例としてcJSONが挙げられています。xzのような実プロジェクトの例も示されています。
テキトー教師DotAI 認定講師実行時の注意点は、コンテナを挟まずホスト上でafl-fuzzやclang、LLMが選んだビルドコマンドを直接実行するため、使い捨て環境で昇格権限なしに実行すること。ここは必ず守りたいところです。
室谷代表取締役カバレッジギャップの追跡方法については、各イテレーションでAFLを時間予算分回して、キューを.covバイナリに対して再生して実際のカバレッジレポートを取得し、未到達ブランチのリストを読んで、シード追加・ハーネス編集・辞書拡充・スキップのいずれかを選ぶ、という流れになっています。
テキトー教師DotAI 認定講師停止条件はプラトー検出で、2回連続のイテレーションでカバレッジの伸びが一定以下になったら止まる、という設計です。
室谷代表取締役ライセンスや依存関係の詳細については、今回のソースでは明らかにされていません。seclab-taskflow-agentとseclab-taskflowsのリポジトリを直接確認するのが確実です。
テキトー教師DotAI 認定講師最後に、これは「脆弱性を自動修正する」ものではないという点も改めて。パイプラインの終端はユニークなバグごとの脆弱性レポートの作成で、そこから先の判断は人間に残されています。
室谷代表取締役セキュリティの自動化は「どこまで任せるか」の設計がすべてですからね。Fuzzing Taskflowは、その線引きをかなり丁寧にドキュメント化してくれている事例として、読む価値があると思います。
