GitHubのAIファジング一行実行、回す前に決める隔離環境とLLM課金の上限

誰におすすめ

C/C++のネイティブ拡張・コーデック・パーサ・組み込みファームを自分で保守している、あるいは依存として同梱して出荷している個人開発者・少人数チームのテックリード向け。従量課金のGitHub Copilotプランを持ち、Codespacesの月間無料コア時間に上限がある状態で、次のリリース前にファジングを自分のプロジェクトへ回そうとしている人が対象になる。

何をすべきか

2026-09-24にgithub.blogが公開した記事は、GitHub Security Lab内製だったFuzzing Taskflow(GitHubSecurityLab/seclab-taskflows-fuzzing、MITライセンス、取得時点(2026-09-27)で12スター・2フォーク)を、./scripts/fuzzing/run_fuzzing.sh <owner>/<repo> という一行の実行インターフェースとして公開した。既定のLLMはClaude Sonnet 5で、README自身は前提としてPython 3.11+・Linux環境(またはCodespace)・GitHub CLI(gh)を挙げ、必要な変数としてCOPILOT_TOKENを含む「標準的なエージェント変数」を列挙する一方、ANTHROPICやAPI_KEYに類する変数名は一度も登場しない。GitHubが自ら公開しているCopilotの課金ドキュメントでは、Claude Sonnet 5の従量単価(入力$2/百万トークン・出力$10/百万トークン、Anthropicが直接公開している単価と同額)はAI Credits(1クレジット=$0.01)に換算されると説明されている。二つを重ねると、このtaskflowのLLM呼び出しはGitHub CopilotのAI Credits残量に対して計上されると推測できるが、これはあくまで変数名からの推論であり、ベンダーがこのtaskflow自体について明示した言明ではない。

README自身の警告はもう一つある。「afl-fuzz・clang・llvm-cov、およびLLMが選んだ任意のビルドコマンドを、コンテナなしでホスト上で直接実行する」——だからこそREADMEは使い捨てのCodespaceや使い捨てVMなどの隔離環境の中でのみ実行するよう指示している。README自身のベンチマーク(5つのOSS C/C++プロジェクト、Codespaceの開発イメージ上で1対象あたり約32分)では、xz・cJSON・libexpatの3プロジェクトはクラッシュ0件だった一方、jansson で10件、oniguruma で13件のクラッシュが見つかり、うち2件はREADME自身が「実在するOOB(範囲外)読み取り」と分類している。ここでいう「対象」はtaskflowが1つのリポジトリの中に自動生成する個々のfuzzingハーネスを指し、件数(このベンチマークでは3〜10件)は読者が選ぶのではなくtaskflow自身が決める。ただしこれはメンテナー自身の参照プロジェクトの結果であり、読者自身のプロジェクトでの実績を保証するものではない。

そして、ブログ記事・README・ベンチマーク結果のいずれにも、1回のランのトークン数・AI Credits消費量・ドル建てコストを記載した一次資料は存在しない。README自身の32分/対象という実測値からCodespacesのコンピュート代だけは計算できるが、それは無料枠に収まる規模の金額にとどまる一方、LLM(Claude Sonnet 5)側の消費はGitHub CopilotのAI Credits月間枠に計上されると推定される——これは変数名からの推論であり、金額そのものは公表資料だけでは確定できない。

注意点

• LLM側の課金がGitHub CopilotのAI Creditsに着地するという読みは推論であり、ベンダーの明示的な言明ではない。
• ベンチマークのクラッシュ件数はメンテナー自身の参照プロジェクトの結果であり、読者自身のプロジェクトで同じ結果が出ることを約束しない。
• スター・フォーク数(12・2)は取得時点のGitHub UI上の値であり変動する。