GitHub Security Lab の Taskflow Agent が面白い
LLM × セキュリティの「手順書」という発想

公開日：2026.02.09　更新日：2026.02.09

「AI でセキュリティを強化する」と聞くと、多くの人はコードレビューの自動化や脆弱性スキャンの高速化を思い浮かべるかもしれません。
しかし GitHub Security Lab が作ったオープンソースツール Taskflow Agent は、もう少し違う角度からこの問題に切り込んでいます。

この記事では、Taskflow Agent の背景にある課題意識と設計思想を紹介します。
次回の後編では、実際にセットアップして動かすところまでを扱う予定です。

1. なぜ GitHub Security Lab はこれを作ったのか

セキュリティの実務には、LLM に「一発のプロンプト」で解かせるのが難しい種類の仕事があります。

たとえば CodeQL がコードスキャンで出したアラートのトリアージ。GitHub Security Lab は定期的にオープンソースプロジェクトに対して CodeQL クエリを実行し、大量のアラートを生成しています。
これを人間がひとつずつ見ていくわけですが、作業の大半は反復的で、しかも判断基準が曖昧です。
「このアラートは偽陽性か、本物の脆弱性か？」を判定するには、コードの文脈を追い、ロジックの意味を理解し、過去の似たパターンと照らし合わせる必要があります。

熟練のセキュリティ研究者であれば、偽陽性のパターンを「見ればわかる」ものです。
たとえば GitHub Actions のワークフローに対するアラートでは、リポジトリのメンテナだけがトリガーできるチェックが入っていれば安全だと判断できます。
こうした判断は人間には自然ですが、従来の静的解析ツールでフォーマルに表現するのは難しいんですよね。

ここに LLM の出番があります。LLM は、従来のツールが苦手とする「あいまいなパターンマッチング」が得意です。
コードの意味的な文脈を読み取り、人間の判断に近い形でアラートをフィルタリングできる可能性があります。

ただし、問題もあります。セキュリティのトリアージは単発の質問ではなく、複数のステップからなるワークフローだということです。
アラートを取得し、関連するコードを読み、判定基準に照らし合わせ、結果を記録し、次のアラートに移る。
この一連の流れを、ひとつの巨大なプロンプトに押し込めるのは現実的ではありません。

これは、セキュリティに限らず多くの業務に当てはまる構造です。
「やることは明確だが、ステップが多く、各ステップに文脈依存の判断が含まれる」──そういう仕事を LLM で回すには、プロンプトの工夫ではなく、仕事の流れそのものを構造化する仕組みが必要です。

Taskflow Agent は、まさにその仕組みとして生まれました。

2. Taskflow Agent とは何か

Taskflow Agent は、GitHub Security Lab がメンテナンスしている実験的なエージェントフレームワークです。
MIT ライセンスのオープンソースとして公開されています。

ひとことで言えば、YAML で定義した「手順書（taskflow）」に従って、複数のエージェントが順番にタスクをこなす CLI ツールです。

技術的には OpenAI Agents SDK の上に構築されており、バックエンドには GitHub Copilot API を使用します（スタンドアロンのCLIとして動く際は、OpenAI APIキーやAzure OpenAIを利用することも可能です）。
MCP（Model Context Protocol）に対応しており、外部ツールとの連携が可能です。
GitHub Actions のワークフロー YAML に似た文法で手順を記述し、コードを一行も書かずにエージェントのワークフローを定義・実行できるのが特徴になっています。

面白いのは、これが「もっとも洗練されたツール」を目指していない点です。
GitHub Security Lab 自身がブログで明言しているように、目標は「自分たちが使いたいツールを作る」ことと、「コミュニティが手順を共有できるようにする」ことの二つ。
研究チームとして素早く実験できることが優先されていて、効率よりも変更しやすさを重視しています。

Docker イメージでのデプロイにも対応しており、Codespace から数ステップで試すこともできます。

3. 中核となる 3 つの概念：taskflow・personality・toolbox

Taskflow Agent を理解するには、3 つの概念を押さえれば大丈夫です。

taskflow（手順書）

taskflow は YAML で書かれたタスクのリストです。
各タスクは、最低限「使うエージェント（personality）」と「ユーザープロンプト」を定義します。

タスクは順番に実行されます。
ここで重要なのは、各タスクは新しいコンテキストで始まるという点です。
前のタスクの結果を次に渡すには、toolbox を介して明示的にデータを受け渡す必要があります。
これにより、コンテキストウィンドウの肥大化を防ぎつつ、タスク間の依存関係を制御できるようになっています。

タスクにはモデルの指定（gpt-4o、gpt-5 など）、完了必須かどうかのフラグ、最大ステップ数などのパラメータも設定できます。
また、テンプレート変数を使って同じ手順を異なるデータに対してバッチ実行する機能もあります。

personality（人格・役割）

personality は、エージェントのシステムプロンプトに相当するものです。
YAML ファイルで定義します。

たとえば「Actions のセキュリティ専門家」「C 言語の監査人」「汎用アシスタント」など、タスクの性質に応じて異なる personality を割り当てることで、エージェントの思考の軸を切り替えられます。

toolbox（ツール箱）

toolbox は、エージェントが使える外部ツールの定義です。
MCP サーバーとして実装されており、ファイルの取得、GitHub API の操作、CodeQL データベースへの問い合わせなどが含まれます。

Taskflow Agent には CodeQL MCP サーバーが同梱されています。
これは CodeQL クエリ自体を LLM に生成させるのではなく、あらかじめテンプレート化された CodeQL クエリを MCP ツールとして提供するアプローチです。
エージェントはこのツールを使ってコードをナビゲートし、探索します。
LLM の得意な「意味の理解」と、CodeQL の得意な「構造的なコード分析」を組み合わせる設計になっているわけですね。

この 3 つの概念──手順（taskflow）、役割（personality）、道具（toolbox）──の組み合わせが、Taskflow Agent の骨格です。

4. 実際にどう使われているか

GitHub Security Lab は、このフレームワークを実際のセキュリティ業務に適用しています。
ブログ記事によれば、2024年8月以降、トリアージ用の taskflow を使ってコードスキャンアラートを処理し、約30件の実際の脆弱性を発見したとのことです。
その多くはすでに修正・公開済みだそうです。

具体的には、GitHub Actions の脆弱性トリアージと、JavaScript/TypeScript の XSS（クロスサイトスクリプティング）アラートのトリアージに適用されています。

Actions アラートのトリアージ

GitHub Actions のアラートでは、偽陽性の原因がある程度パターン化されています。
たとえば「pull_request_target を使っているがメンテナしかトリガーできないチェックがある」ケースは安全であることが多いです。
こうした判定基準をプロンプトに明確に記述し、タスクごとに具体的な回答を求めることで、LLM のハルシネーションを最小限に抑えています。

なぜ巨大プロンプトではなく taskflow なのか

ポイントは、トリアージの全工程をひとつのプロンプトに詰め込むのではなく、個々のタスクに分解していることです。
アラートの取得、コードの参照、判定基準との照合、結果の記録──それぞれが独立したタスクとして定義されています。

この分解によって得られるメリットは大きいです。
各タスクのプロンプトを精密に書ける。個別にデバッグ・改善できる。
同じタスクを異なるアラートに対してバッチで回せる。
そして何より、この手順書そのものを他の人と共有できます。

GitHub Security Lab のチームは、トリアージで LLM に与えたツールはファイル取得と検索だけで、CodeQL 以外の静的解析・動的解析ツールは使っていないと述べています。
つまり、LLM の「コードを読んで意味を判断する」能力と、手順の精密な分解を組み合わせることで、シンプルなツール構成でも実用的な成果を出せることを示しているんですね。

CVE-2023-2283 のデモ

Taskflow Agent のリポジトリには、CVE-2023-2283（libssh の認証バイパス脆弱性）を題材にしたデモ taskflow も含まれています。
C コードの CodeQL データベースを使い、エージェントがコードを探索しながらレビューする様子が公開されています。
これは「LLM にコードを丸投げする」のではなく、「CodeQL のツールでコードを辿りながら、LLM が判断を下す」という協調的なアプローチの実例です。

5. Taskflow Agent が示す設計思想

Taskflow Agent の面白さは、ツールとしての機能よりも、その背後にある考え方にあると思います。

プロンプトエンジニアリングではなく「手順の資産化」

多くの LLM 活用の試みが「いかに良いプロンプトを書くか」に集中する中、Taskflow Agent は「いかに仕事の流れを切り出すか」にフォーカスしています。

YAML で記述された taskflow は、特定のモデルに依存しません。
gpt-4o で動かしていた手順を gpt-5 に切り替えるのは、YAML のモデル指定を一行変えるだけです。
モデルが進化しても手順書は残る。
これは、セキュリティ知識をプロンプトという揮発的な形ではなく、再利用可能な資産として蓄積する試みだと言えます。

「エージェントを作る」より「仕事の流れを切り出す」

Taskflow Agent の設計思想は、GitHub Security Lab のブログにある一文に凝縮されています。
LLM を使った自動化の良い候補となる仕事の条件として、彼らはこう述べています──
「多くの反復的なステップがあり、各ステップに明確で具体的なゴールがある。
そのステップの一部に、従来のプログラミングでは捉えにくいが人間の監査人にとっては比較的簡単なロジックや意味の判断が含まれている」。

これはセキュリティに限った話ではありません。
製造業の工程管理、業務システムのデータ検証、ドキュメントのレビュー──
「反復・曖昧・文脈依存」な仕事は、どの業界にもあります。

コミュニティで手順を共有する

GitHub Security Lab の最終的なビジョンは、taskflow をコミュニティで共有することです。
セキュリティの知識を自然言語で記述し、YAML の手順書として配布できれば、脆弱性の発見をスケールさせることができます。
実際に、GitHub Secure Open Source Fund の参加者にもこのフレームワークが共有されています。