<style> .fz-hero{padding:clamp(24px,5vw,46px);border-radius:24px;background:linear-gradient(130deg,#111827,#1e3a8a 55%,#7c3aed);color:#fff}.fz-hero h2{color:#fff}.fz-grid{display:grid;grid-template-columns:repeat(3,minmax(0,1fr));gap:12px;margin:22px 0}.fz-card{padding:18px;border:1px solid #c7d2fe;border-radius:16px;background:#eef2ff}.fz-card strong{display:block;color:#4338ca;font-size:1.3rem}.fz-flow{display:grid;grid-template-columns:repeat(5,minmax(0,1fr));gap:9px;margin:22px 0}.fz-step{padding:14px;border:1px solid #c7d2fe;border-radius:14px;background:#f5f3ff}.fz-step b{display:block;color:#6d28d9}.fz-table{overflow-x:auto}.fz-table table{min-width:680px;width:100%;border-collapse:collapse}.fz-table th,.fz-table td{padding:11px;border:1px solid #cbd5e1;text-align:left;vertical-align:top}.fz-table th{background:#e0e7ff}.fz-note{padding:18px;border-left:5px solid #dc2626;border-radius:12px;background:#fef2f2;margin:20px 0}@media(max-width:720px){.fz-grid,.fz-flow{grid-template-columns:1fr}} </style>

AI AGENTS / 2026年9月24日公開

ファジングの「人手がかかる部分」をAIへ

GitHub Security Labは、C/C++プロジェクトを指定すると、テスト対象選びからクラッシュの一次解析まで進めるFuzzing Taskflowを公開しました。試す前に実行環境の隔離を確認する必要があります。

3行要約

• GitHub Security Labは2026年9月24日、LLMを使ってC/C++向けファジング工程を自動化するFuzzing Taskflowを公開しました。
• エージェントがハーネス（入力を対象関数へ渡す小さなテストプログラム）を作成し、AFL++で試験、カバレッジ確認、クラッシュの一次分類まで行います。
• GitHub自身が、AIの選んだビルドコマンドなどをコンテナなしでホスト上で実行すると警告しています。使い捨てのCodespaceやVM以外で安易に動かすべきではありません。

背景：ファジングは「回す前」と「回した後」が重い

ファジングは大量の変則的な入力を与え、プログラムの異常終了や想定外の動作を探す手法です。実行ツールを起動するだけでは十分ではなく、対象関数に入力を届けるハーネスを作り、どのコードまで届いたかを測り、見つかったクラッシュが本当の脆弱性かを調べる必要があります。GitHub Security Labの記事は、その反復的な工程をエージェントへ任せる試みを説明しています。

何が新しいのか

新しく公開されたFuzzing Taskflowは、既存のGitHub Security Lab Taskflow AgentというLLM駆動のセキュリティ自動化フレームワーク上に構築されています。従来フレームワークの新規発表ではなく、ファジング用の具体的なパイプラインが今回の題材です。

GitHubの説明によれば、リポジトリを指定すると必要なツールの準備、クローン、対象関数選定、ファズターゲット生成が進みます。クラッシュの報告は自動生成されますが、報告書が完成したことと、脆弱性が確認されたことは別です。

技術的なポイント：人間の判断をどこに残すか

カバレッジは「どのコードがテストで実行されたか」の指標です。高い数値だけで安全とは言えず、入力の質や未到達の重要経路も見ます。AI生成のハーネスが誤って対象関数をほとんど呼ばなければ、長時間実行しても有効な検査になりません。

開発者・企業向けの試し方

GitHubの公式記事は、対象リポジトリのCodespaceを開き、次の形で実行する例を示しています。OWNER/REPOには対象の公開リポジトリを指定します。

./scripts/fuzzing/run_fuzzing.sh OWNER/REPO

本番環境や機密ソースをいきなり指定せず、使い捨て環境・低権限のアカウント・必要最小限のネットワークで、小さな検証用C/C++リポジトリから試します。出力されたクラッシュは、手元で再現し、ハーネス起因の誤検知や既知の問題を除いてから担当者へ渡します。これらは公式の安全上の警告を踏まえた編集部の運用提案です。

リスクと限界

• 使い捨てのCodespaceまたはVMで、管理者権限を渡さず実行してください。
• 公式リポジトリによると、local_shellには対話的な確認プロンプトがなく、コマンドはログへ記録されます。ログは事後調査には役立ちますが、実行前の防御ではありません。
• オープンソースの試験的なツールであり、すべてのC/C++プロジェクトでビルドや有効な脆弱性発見が成功する保証はありません。

今後注目すべき点

実用性を測るには、対象選定にかかる時間、実際に到達したコード、再現可能な新規バグ、誤報率、実行コストを継続的に記録する必要があります。単に「自動で報告書が出た」だけで導入効果を判断しないことが重要です。

最終確認日：2026年9月26日

参照元（一次情報）

• GitHub Security Lab：AI-powered fuzzing with the Taskflow Agent（2026年9月24日）
• GitHubSecurityLab公式リポジトリ：seclab-taskflows-fuzzing
• GitHubSecurityLab公式README