最新AI論文を現場実装へ---LLM活用によるWeb自動脆弱性診断クローラーの探索力強化アプローチ
最新AI論文を現場実装へ
こんにちは、GMOサイバーセキュリティ byイエラエ株式会社で「ネットde診断 for Webアプリ」の開発に携わっている中野です。
「ネットde診断 for Web」は、Webアプリケーションの脆弱性診断を誰でも手軽に、かつ高精度で実施できるWebサービスです。セキュリティエンジニアの知見を活かした診断エンジンを開発することで様々な脆弱性に対応しています。
このサービスの診断プロセスは大きく2つのステップで構成されています。
まず、診断対象サイトの構造を把握するため、Webクローラーがサイト内を自動で巡回し、診断対象となるページや機能を洗い出します。次に、抽出された各ページに対して、SQLインジェクションやXSS（クロスサイトスクリプティング）などの脆弱性診断を実行します。つまり、クローリングによる正常系抽出→診断実行という流れで、脆弱性診断を実現しているのです。
本記事では、このクローラーの診断カバレッジを向上させるために、LLMを活用したAIエージェントを自作した道のりと、その試行錯誤から得られた知見を共有します。
Webクローリングと「フォーム」という名の壁
このサービスの中核を担うのが「Webサイトクローラー」です。
前述した診断プロセスの第1ステップとして、Webサイトを巡回し、診断対象となるページや機能を自動で洗い出すのがその役割となります。
しかし、Webクローリングには長年にわたり”越えられない壁”が存在していました。それが「フォーム」です。
ログイン、会員登録、検索、問い合わせ…。こうしたフォームの”向こう側”には、アプリケーションの重要な機能や脆弱性リスクが潜んでいます。
特に、これらのフォーム送信後にはデータベースへのアクセスやメール送信など、さまざまな副作用を伴う処理が実行されることが多く、その裏側に脆弱性が潜んでいるケースも少なくありません。
従来のクローラーは、aタグなどのリンクを辿ることは得意でも、フォームの意味を理解し、適切に入力・送信することができませんでした。この「フォームの壁」をどう乗り越えるかは、クローラーのカバレッジを大きく左右しますし、長年手付かずだった領域への挑戦となったわけです。
話題のAIエージェントとその実力
現在脚光を浴びているLLMを活用したAIエージェント技術は、人間のようにブラウザ画面を”見て”、意味を”理解”し、操作できるという点で大きな期待を集めています。とりわけ、汎用ブラウザ操作エージェント（以下、某エージェントA・Bとして引用）は、多様なWeb操作に柔軟に対応できる点で非常に優れています。しかし、フォーム入力のような特定のユースケースだけに絞った場合、より高精度かつ効率的なアプローチが可能ではないかと感じさせる点もありました。
実際にこれらのエージェントを試してみると、単純なフォームでの動作には一定の安定性が見られた一方、複雑なDOM構造や複数の同種要素が存在するケースでは、精度にばらつきが見られました。例えば、画面中央のメインコンテンツではなくヘッダーの検索フォームを操作し始めたり、「必須」と書かれている項目を空のまま送信しようとして別ページに飛んでしまったりと、意図しない挙動が散見されました。
また、コスト面においても最適化の余地を感じる場面がありました。私たちが検証した汎用エージェントでは、1画面の操作あたりAPI（呼び出し/コール）回数が5〜6回、多い場合には10回以上に及び、トークン消費量も1画面あたり2万を超えるケースがありました。実行時間も長く、1画面に約30秒以上かかることもありました。これが複数画面、複数サイトにまたがると、我々の要件に合致させるには追加の最適化が必要だと判断しました。
「このAPI（呼び出し/コール）回数とトークン消費量では、ユーザーに十分な価値を提供し続けるのは難しいのではないか……」という懸念の中で、私たちは”汎用性のもつ難しさ”と、”ユースケース特化による可能性”の両方を実感することになりました。
なぜ我々の要件に適合しなかったのか？
高機能な汎用エージェントが、なぜ私たちの要件にあまり適合しなかったのか。私たちはその理由を以下の3点に整理しました。
1. 汎用プロンプト
あらゆるWebサイトに対応するために設計された汎用的なAIエージェントは、広範な応用性を持つ一方で、特定のタスク（今回のケースではフォーム入力）における精度や安定性においては、曖昧さが残ることがあります。
これは機械学習の分野でよく知られる No Free Lunch定理（すべての問題に対して常に最適なアルゴリズムは存在しない）にも通じます。つまり、すべてのケースに対応しようとすればするほど、個々のタスクに最適化された挙動が犠牲になりがちなのです。
2. コンテキスト過多によるノイズ
ページ全体の情報をそのままLLMに渡すアプローチは、特にフォーム入力のようなタスクにおいては、かえってノイズの混入につながることがあります。大量の無関係な要素に重要な情報が埋もれてしまい、意図しない操作を引き起こす原因となります。
汎用エージェントではあらゆる操作に対応する必要があるため、ページ全体を取り込む設計が前提となりますが、フォーム入力のような目的が明確なユースケースでは、必要な要素だけを抽出して入力する方が、判断ミスや処理コストの削減においても合理的です。
3. コストの最適化
汎用エージェントはその高い柔軟性ゆえに、API（呼び出し/コール）回数やトークン消費量、実行時間といった処理コストが増大しやすいという特性があります。 このような特性は、幅広いタスクに対応する設計としては理にかなっていますが、実サービスへの組み込みや大規模展開を視野に入れると、運用面での最適化余地があるとも感じました。
これらの観点から、私たちは「汎用性に依存するアプローチ」ではなく、「フォーム入力というユースケースに特化したアーキテクチャやプロンプト設計」が重要であるという結論に至りました。
“無いなら作れ” – フォーム入力特化型AIエージェントという選択
こうした課題を抱える中、私たちは「Webクローラーのカバレッジ向上」という本来の目的に立ち返り、その最大のボトルネックである「フォーム入力」という一点だけに機能を絞った、特化型のエージェントを自作することにしたのです。
コンセプトは「万能なスイスアーミーナイフではなく、切れ味鋭い一本のナイフを作る」。
ブラウザ操作AIエージェントの研究から読み解く
そこでまず色々な論文を参考にしました。その中でAIエージェント関連論文で議論されている方法として 「HTML全体をLLMに渡すアプローチ」 と 「必要な要素だけを抽出して渡すアプローチ」 の2つがあることを発見し、これを対比しました。
HTML全体を与えるアプローチ
まず、関連研究として AutoScraper（Huang et al.,）[^1] をご紹介します。この論文では、HTML全体をLLMに入力として与え、そこから段階的にXPathや抽出ロジックを生成する手法が提案されています。構成としては、Progressive GenerationとSynthesisという2段階の流れを通じて、汎用性の高いスクレイパーの構築を目指しています。
AutoScraperのプロンプト設計戦略
AutoScraperでは、前述した二段階のフェーズを経てスクレイパーを生成するプロセスが採用されており、複雑なHTML構造を段階的にかつ汎用的に理解させるための、非常に洗練されたプロンプト戦略が用意されています。これらの詳細は割愛しますが、ここではその一部として「Top-down」と呼ばれるPromptをご紹介します。
Top-downプロンプト
Top-down方式では、DOMツリーのルートからスタートし、目的の情報が含まれるノードに向けて段階的に絞り込みを行っていきます。各ステップでは、LLMが該当ノードへのXPathを出力し、それが期待される値と一致するかどうかを履歴ベースで検証するように設計されています。
Here’s the HTML extraction task:
Task description: Please read the following HTML code, and then return an Xpath
that can recognize the element in the HTML matching the instruction below.
Instruction: {0}
We will offer some history about the thought and the extraction result. Please
reflect on the history trajectory and adjust the xpath rule for better and
more exact extraction. Here are some hints:
1. Judge whether the results in the history are consistent with the expected
...
Please output in the following JSON format:
{
"thought": "", # thought of why the xpaths in history do not work and how toadjust the xpath
"consistent": "", # whether the extracted result is consistent with theexpected value, return yes/no directly
"value": "", # the value extracted from the HTML that matches the taskdescription
"xpath": "", # a new XPath that is different from the XPath in the followinghistory if not consistent
}
And here’s the history of the thought, xpath and result extracted by scraper.
{1}
Here’s the HTML code:
‘‘‘
{2}
‘‘‘[論文内より抜粋]
このプロンプトは、過去の出力結果を参照しながらエラーの原因を分析し、改善に活かす「反省的なアプローチ」を採用しており、制約条件も含め、非常に緻密に設計されています。
プロンプトエンジニアリングでも解決できない根本的課題
このようにAutoScraperは、プロンプト設計・全体プロセスの両面で優れた提案を行っています。一方でフォーム入力に特化するという点において、現実のWebサイト環境においては、HTML全体をそのままLLMに渡すアプローチには一定の課題も存在すると私たちは考えました。
たとえば、実際のWebページでは以下のように構造が複雑で、ナビゲーションや広告、非表示のDOM、動的要素など、目的に直接関係しないノイズが含まれているケースが少なくありません。
<html>
<head>...</head>
<body>
<nav>...</nav> <!-- ナビゲーション（ノイズ） -->
<aside>...</aside> <!-- 広告（ノイズ） -->
<main>
<div class="content"> <!-- 実際に必要な部分 -->
<span>目的のデータ</span>
</div>
</main>
<footer>...</footer> <!-- フッター（ノイズ） -->
</body>
</html>特にフォーム入力のような明確な目的を持つタスクでは、”content”以下の特定領域が中心となる一方で、ナビゲーション広告などの周辺要素にLLMが意図せず注意を払ってしまい、似て非なる要素に誤ってXPathを割り当ててしまう可能性もあります。また、ページ全体をそのままプロンプトに含めると、トークン数が数万単位に及び、推論コストや応答時間の増加も無視できない要素となります。
このような背景から、私たちは今回のタスクにおいては「HTML全体をそのまま与える」という方針ではなく、目的に応じて必要な構造を前処理・抽出したうえでのプロンプト設計を行うことが有効ではないかと考えました。
要素を画像や構造化して渡すアプローチ
次にご紹介するのは、GPT-4V is a Generalist Web Agent, if Grounded（Zheng et al.）[^2] です。この論文では、従来の「HTML全体をそのまま渡す」という方式とは異なり、ページの画像（スクリーンショット）や構造化された要素情報をLLMに入力として与えるという新しいアプローチが提案されています。
アプローチとプロンプト設計
本論文で特徴的なのは、二段階構成のプロンプト設計です。
まずAction Generationのフェーズでは、人間のウェブ操作を模倣するようなタスク指示が与えられ、スクリーンショットや過去の操作履歴をもとに「次にどのようなアクションを取るべきか」を自然言語で推論させるよう設計されています。
その一部抜粋をご紹介します：
Imagine that you are imitating humans doing web navigation for a task step by
step. At each stage, you can see the webpage like humans by a screenshot and
know the previous actions before the current step decided by yourself through
recorded history. You need to decide on the first following action to take. You
can click an element with the mouse, select an option, or type text with the
keyboard. (For your understanding, they are like the click(), select_option() and
type() functions in playwright respectively) One next step means one operation
within the three.
You are asked to complete the following task: {TASK}
Previous Actions:
{PREVIOUS ACTIONS}
...
(Current Webpage Identification)
Firstly, think about what the current webpage is.
(Previous Action Analysis)
Secondly, combined with the screenshot, analyze each step of the previous action
history and their intention one by one. Particularly, pay more attention to the last
step, which may be more related to what you should do now as the next step.
...[論文内: Table6より抜粋]
その上で視覚情報と履歴などを元に次の適切な操作を導き出す構造が取られています。論文内では、以下の3つの手法が検証されています。
1. Grounding via Element Attributes
この方式では、要素の属性（タイプやテキストなど）をもとに、どの要素を操作すべきかをGPT-4Vが推論します。以下のような出力形式が想定されています：
GPT-4V:
ELEMENT: The "Search" button located to the right of the zip code field at the top of the Thumbtack homepage.
ELEMENT TYPE: BUTTON
ELEMENT TEXT: Search
ACTION: CLICK
VALUE: None[論文内: Figure5より抜粋]
2. Grounding via Textual Choices
あらかじめ定義された選択肢の中から、最も適切な要素を選ぶ方式です。マルチチョイス形式で選択を行う構造になっています。
GPT-4V: (Reiteration)
The next target element is the "Search" button located to the right of the zip code field.
(Multichoice Question)
H. <button id=7 submit search> Search </button>
(Final Answer)
ELEMENT: H
ACTION: CLICK
VALUE: None[論文内: Figure7より抜粋]
3. Grounding via Image Annotation
最後に、スクリーンショット上の要素にラベルを付け、そのラベルを参照してアクションを決定する手法です。画面上での相対的な位置や視覚的な特徴を活用する形となります。
GPT-4V: ELEMENT: 4
ACTION: CLICK
VALUE: None[論文内: Figure9より抜粋]
これらの手法はいずれも、画像ベースの認識能力と構造的理解を組み合わせ、より人間に近い判断を可能にする工夫が凝らされています。
各手法の性能や精度については、ぜひ原論文をご参照ください。
また、HTML全体をLLMに直接渡す方式と比較した際、以下のような利点が見えてきます：
- ノイズが大幅に軽減され、LLMが本質的な判断に集中しやすい
- トークン数の削減によるコスト・応答時間の最適化
このような視点から、私たちも「フォーム入力」という明確なユースケースにおいて、画像や構造情報を用いたプロンプト設計が有効かどうかを検討することにしました。
私たちの実装における適用
ここまで紹介してきた研究成果をふまえ、私たちが開発したフォーム入力に特化したAIエージェントでも、、要素などの情報を抽出・加工してプロンプトに加えるアプローチを採用しました。
この設計により、精度を維持しながらもトークン消費量を大幅に抑えることができ、精度とコストの両立という、実運用上重要な要件を満たすことができました。
このことは、フォーム入力のような明確な目的があるタスクにおいては、「HTML全体を渡す」よりも、「前処理を通じて必要な情報を絞り込み、構造的に提示する」ことが、より現実的な選択肢になりうるという示唆を与えてくれました。
なお、具体的なコードやプロンプトの詳細は公開できませんが、設計思想のコアには以下のような考え方がありました。
特化型エージェント設計の「3つの勘所」
- 役割の明確な限定
エージェントの責務を「HTMLを受け取り、フォーム入力に必要な情報を抽出する」ことに限定。
タスクの範囲を狭めることで、精度や一貫性を高める工夫を行いました。 - 情報の枝刈り（Pruning）
ページ全体のHTMLをそのまま渡すのではなく、必要な領域だけを抽出・整形してLLMに渡すことで、
ノイズとトークン数の双方を削減し、判断の集中度を高めました。 - 明確な行動制約（Constraints）
「ヘッダー・フッターのフォームは除外する」「個人情報は事前に定義したリストから選択する」など、
具体的な制約条件を明示し、意図しない挙動を防ぐ設計としました。
特化型エージェントの成果
このアプローチによって構築したエージェントは、私たちの期待を上回る成果を上げることができました。
| モデル | API（呼び出し/コール）回数 | Token数 | 時間 |
|---|---|---|---|
| 独自実装 | 1-2回 | ~8,000 | ~10秒 |
| 某エージェントA | ~10回 | ~26,000 | ~40秒 |
| 某エージェントB | ~25回 | ~37,000 | ~60秒 |
※特定のフォームにおける検証結果（参考値）
コスト（API（呼び出し/コール）回数・トークン数・時間）の面でも、フォーム入力タスクにおける特化型アプローチの有効性が示された結果となりました。
また、フォーム画面の突破についても、他のエージェントと同等以上の精度を維持できており、コスト削減だけでなく実用上のパフォーマンスも十分に確保できていることが確認できました。
ただし、エージェント各種には汎用性や他タスク対応などの強みがあり、本比較はあくまで「フォーム入力に限定した条件下」での一例である点をご理解いただければと思います。
おわりに
今回の開発と検証を通じて、私たちは以下のような学びを得ました。
- 特定の目的に対しては、焦点を絞ったアーキテクチャ設計がきわめて効果的である
- 「No Free Lunch定理（No Free Lunch Theorem）」のとおり、あらゆるケースに万能な手法は存在せず、未だに課題に応じた最適化が有効なケースも多い
AIエージェントによる自動化技術は、今まさに発展途上にあります。汎用エージェントには大きな可能性がありますが、業務やサービスといった制約のある現場では、今回のようにタスク特化型のアプローチがより有効な場面も少なくないと考えます。
また本記事でご紹介したフォーム入力特化型AIエージェントの技術は、「ネットde診断 for Webアプリ」に組み込まれ、今後さらに診断カバレッジや精度の向上に大きく貢献することが期待されています。従来のクローラーでは到達が難しかったフォーム画面の奥深くまで自動で到達できるようになったことで、より幅広い脆弱性診断の実現に向けてサービス自体も進化を続けています。
「ネットde診断 for Webアプリ」は、こうした最先端のAI技術を積極的に取り入れることで、これまで以上に多くのWebアプリケーションの安全性を守るお手伝いができると考えています。
今後もユーザーの皆様に、より高精度かつ効率的な診断サービスをお届けできるよう、技術開発・サービス改善に取り組んでまいります。
最後に本記事が、同様の課題に取り組むエンジニアや研究者の皆様の一助となれば幸いです。
[^1]: Huang et al., “AutoScraper: A Progressive Understanding Web Agent for Web Scraper Generation”, https://aclanthology.org/2024.emnlp-main.141/
[^2]: Zheng et al., “GPT-4V is a Generalist Web Agent, if Grounded”, https://dl.acm.org/doi/10.5555/3692070.3694608
