Repeater Strike：反復しがちな手動テストを“増幅”するという提案

本記事は、PortSwigger Research による公開記事「Repeater Strike: manual testing, amplified」を元ソースとして、その内容と周辺の公式情報（portswigger.net 上の関連ページ）だけに基づき整理したものです。

概要

手動テストは、対象の挙動を観察しながら仮説を立て、リクエストを少しずつ変えて検証していく点に強みがあります。一方で、同じ種類の確認を延々と繰り返す局面が多く、集中力を消耗しやすいのも事実です。PortSwigger はこの課題意識を出発点に、「手動テストは繰り返し作業である必要はない」と述べつつ、Burp Suite の拡張として Repeater Strike を紹介しています。これは AI を活用し、Repeater（手動でリクエストを投げて検証する機能）で行う作業を支援しながら、IDOR（Insecure Direct Object Reference）やそれに類する脆弱性の“発見の自動化”を狙うものだと位置づけられています。

また、BApp Store の説明でも Repeater Strike は「AI-powered tool」であり、Repeater のリクエストを分析して IDOR などの脆弱性を見つける助けになる、とされています。つまり、既存の手動ワークフローを置き換えるというより、手動の強み（観察・仮説・検証）を保ったまま、反復になりがちな探索部分を増幅する、という発想が中心にあります。

詳細

PortSwigger Research の記事タイトルが示す通り、Repeater Strike は「manual testing, amplified（手動テストの増幅）」を掲げています。ここで重要なのは、手動テストそのものを否定して“すべてを自動スキャンに任せる”という話ではなく、Repeater を使った日々の検証が単調な繰り返しになりがちな点に着目し、AI によって探索の負荷を下げる、という方向性です。特に IDOR のように、オブジェクト参照（ID など）を変えたときのアクセス制御の差異を追うタイプの問題は、仮説検証の筋道は手動で立てつつも、試行のパターン自体は増えやすく、そこで反復作業が膨らみます。Repeater Strike はまさにこの“反復”を対象に据え、Repeater のリクエストを材料に脆弱性探索を支援する、と説明されています。

さらに portsWigger.net 上には、同じく「AI-enhanced manual testing（AI による手動テストの強化）」をうたう Shadow Repeater の紹介もあります。名称は異なりますが、いずれも「手動テストを中心に据えながら AI で補助する」という大枠の思想が読み取れます。こうした流れの中で見ると、Repeater Strike は“Repeater で行う検証”を起点に、IDOR など特定のクラスの不備に焦点を当てて支援を行う拡張として理解しやすいでしょう。

また、PortSwigger は「Document My Pentest: you hack, the AI writes it up!」という別記事で、Repeater を通常どおり使って検証し、ドキュメント化の段階で履歴を掘り返す手間を減らす、という文脈にも触れています。ここでも Repeater が“作業の中心”として扱われており、AI はその周辺（整理・記述・支援）を担うという構図が示唆されます。Repeater Strike をこの文脈に置くと、同じ Repeater という現場の接点を保ったまま、発見（探索）側を支援するアプローチとして対比できます。

総じて、Repeater Strike は「手で確かめる」価値を残しつつ、繰り返しに押しつぶされがちな時間を圧縮し、テスターが本来注力すべき判断や検証設計に戻るための道具、という整理ができます。導入や位置づけの判断にあたっては、研究記事での問題提起（繰り返しの負担）と、BApp Store での端的な説明（Repeater リクエスト分析による IDOR 等の探索支援）を出発点に、まずは既存の手動ワークフローを崩さずに試す、という使い方が想像しやすいはずです。