正常に見えるAPIリクエストも、ボット攻撃になり得る？ AIエージェント時代のビジネスロジック悪用
サマリー
API攻撃の変容： API攻撃は、必ずしも異常なアクセスや不正なリクエストとして現れるとは限りません。正規機能を自動化し、在庫を買い占めたり予約枠を独占したりする行為も、サービスに被害をもたらす可能性があります。
AIエージェント時代の難しさ： AIエージェントがユーザーに代わってAPIを呼び出すようになったことで、自動化されたリクエストという理由だけでトラフィックを遮断することが難しくなっています。
多層的な防御の必要性： IP、User-Agent、リクエスト回数といった従来の指標だけでなく、アカウント、セッション、呼び出し順序、アクセス時間、最終的な結果まであわせて分析する必要があります。
データ品質の重要性： AIを活用した検知においても、モデルそのもの以上に、正常なユーザー、正規のAIエージェント、悪意ある自動化を正確に区別するためのデータ選別とラベリングが重要です。
多層構造での対策： ビジネスロジックの悪用は、WAF、Rate Limit、Bot Managementのいずれか一つだけで解決するのではなく、複数のセキュリティレイヤーを組み合わせて対策する必要があります。
2026年9月、OpenAIに関連するAIエージェントが十数件の外部Webサイトを利用し、許可されていない方法で情報をやり取りしていたという調査結果が報告されました。研究では、この行動はハッキングというよりもスパムに近いものだと説明されています。しかし、AIエージェントが既存の環境を自ら迂回し、本来とは異なる目的で活動したという点は注目に値します。
この出来事自体を、直ちに「AIエージェントによるAPIビジネスロジック攻撃」と断定することはできません。しかし、システムによって許可された機能だけを使用していたとしても、その機能が想定外の順序や目的で繰り返し利用されれば、運営者が意図していない結果が生じる可能性があるという点では、共通する部分があります。
この出来事自体を、直ちに「AIエージェントによるAPIビジネスロジック攻撃」と断定することはできません。しかし、システムによって許可された機能だけを使用していたとしても、その機能が想定外の順序や目的で繰り返し利用されれば、運営者が意図していない結果が生じる可能性があるという点では、共通する部分があります。
APIセキュリティにおいても、同様の問題が発生します。リクエスト形式が一般ユーザーのものと似ており、個々の呼び出し回数が制限を超えていなかったとしても、行動全体を見ると攻撃に該当する場合があります。
では、正常なAPI利用とビジネスロジックの悪用は、どのように区別すればよいのでしょうか。
APIビジネスロジックの悪用とは？
APIビジネスロジックの悪用とは、サービスが提供する正規機能を自動化したり、想定されていない方法で組み合わせたりすることで、ビジネス上の被害を発生させる行為です。
Webアプリケーションの脆弱性やセキュリティについて研究・啓発を行う国際的な非営利セキュリティコミュニティであるOWASPは、この問題を「機密性の高いビジネスフローへの無制限アクセス（Unrestricted Access to Sensitive Business Flows）」に分類しています。注文、会員登録、予約といったアプリケーションの正規機能を、自動化されたボットやスクリプトで大量に呼び出し、ビジネスに被害を与える行為を指します。
攻撃者は、APIが支える業務プロセスを把握し、関連するエンドポイントを特定して自動化することで、在庫の買い占め、予約枠の独占、スパムの大量生成、リワードの不正獲得といった被害を発生させる可能性があります。
一般的な脆弱性攻撃と比較すると、その違いはより明確になります。
区分 | 一般的な脆弱性攻撃 | ビジネスロジックの悪用 |
|---|---|---|
リクエスト形式 | 不正なコードや悪意ある入力値が含まれる | 正常なリクエスト形式を使用 |
認証状態 | 認証の回避やクレデンシャルスタッフィングが行われる | 正規のアカウントやセッションも利用可能 |
個別のAPI呼び出し | 単一のリクエストから攻撃の特徴が確認できる | 個々のリクエストだけを見ると正常に見える |
主な判断基準 | 既知の攻撃パターン、脆弱性、入力値 | 呼び出し順序、反復性、ユーザー間の関係、最終結果 |
主な被害例 | システムへの侵入、データ流出 | 在庫の先取り、予約枠の独占、価格・プロモーションの悪用 |
重要なのは、リクエストの形式ではなく、そのリクエストが生み出す結果です。
正常なAPI呼び出しが「攻撃」に変わる仕組み
1. EC：商品購入機能を利用した在庫の買い占め
攻撃者は、商品照会、カートへの追加、注文作成APIを正常な順序で呼び出すことができます。それぞれのリクエストには正しいパラメータが含まれ、決済まで正常に進む場合もあります。
しかし、複数のアカウントとIPを利用し、限定商品の大半を短時間で購入している場合、通常の消費行動ではなく、転売を目的としたスキャルピング（買い占め）である可能性が高くなります。OWASPも、複数のIPや位置情報を利用して限定商品を自動購入する行為を、APIビジネスロジック悪用の代表事例として挙げています。
2. 旅行・予約：予約とキャンセルを繰り返して選択肢を制限
航空券、宿泊施設、公演、医療機関などの予約システムにおいて、予約の作成自体は正常な機能です。しかし、自動化されたリクエストによって座席や時間枠を大量に確保し、予約とキャンセルを繰り返すと、ほかのユーザーが予約できる機会が減少します。これは、実際の顧客から利用機会を奪い、企業の売上低下につながる可能性があります。
個々のリクエストだけを見れば、正常な予約またはキャンセルに見えます。その行動が攻撃に該当するかを判断するには、同一のアカウント、セッション、デバイスが、どの程度の時間間隔で予約とキャンセルを繰り返しているかまで関連付けて確認する必要があります。
3. プロモーション：クーポンやリワード制度の反復的な悪用
新規会員登録クーポンや紹介リワードも、正常なサービス機能です。しかし、多数のアカウントを自動作成し、特定のアカウントに特典を集中させれば、実際の顧客が特典を受け取れなくなり、サービス側が意図していない結果が発生します。
この場合も、会員登録API、紹介コードの入力、クーポン発行APIはすべて正常に動作しています。異常性は個別の呼び出しではなく、複数のアカウントと、一つのデバイス、セッション、決済手段との関係に現れます。
4. データ収集：許可された照会APIを利用した大量スクレイピング
価格、在庫、商品情報など、ユーザーに公開されているデータであっても、大量かつ反復的に収集されれば、競合情報の取得や無断でのデータ利用につながる可能性があります。
特に、リクエスト速度を落とし、複数のIPやセッションに分散させた場合、単純なリクエスト回数を基準とした検知では正常なユーザーに見える可能性があります。そのため、照会回数だけでなく、URLの遷移順序、滞在時間、照会範囲、反復周期などもあわせて確認する必要があります。
AIエージェントの普及によって何が難しくなるのか？
従来のボット対策では、「人間か、自動化されたプログラムか」を区別することが重要な判断基準でした。しかし、AIエージェントは実際のユーザーから依頼を受け、商品の検索や価格比較を行い、予約や購入に関する意思決定を支援する正規の自動化システムです。
つまり、AIエージェントが普及する今後の環境では、「自動化されたリクエストである」という理由だけで、すべてを悪性トラフィックに分類することは困難になります。
これからのトラフィックは、少なくとも次の3種類に区別して管理する必要があります。
サービスを直接利用する人間のユーザー
ユーザーに代わって正規の業務を実行する「AIエージェント」
悪意ある目的で機能を自動化する「攻撃者（悪性ボット）」
これからのサービス運営者は、「自動化されたアクセスか」という問いから、さらに一歩踏み込む必要があります。
誰に代わってリクエストしているのか
どのような権限と目的でアクセスしているのか
許可された範囲内で行動しているのか
呼び出しの結果がサービスやほかのユーザーにどのような影響を与えるのか
IPとUser-AgentだけでAIエージェントを区別できるのか？
IPとUser-Agentは、ボット攻撃を検知するうえで現在も必要な分類情報です。しかし、それだけを信頼して判断することには限界があります。
近年では、IPアドレスやUser-Agentを容易に偽装できることや、VPN、プライバシープロキシ、共有クラウドインフラでは、複数のユーザーやサービスが同じ接続環境を利用する可能性があることなどが課題として挙げられています。そのため、リクエストを送信したエージェントの身元を確認するための仕組み（署名認証など）も提案されています。
ただし、リクエストを送信したAIエージェントの身元を確認できたとしても、すべてのリクエストが安全であるとは限りません。
リクエスト署名は、「どこから送信されたリクエストなのか」を確認するためのシグナルにはなりますが、そのエージェントが「許可された範囲内で正しく行動していること」まで自動的に保証するものではありません。そのため、エージェントの身元確認と実際の行動分析をあわせて適用する必要があります。
WAFとRate Limitだけでは十分ではない理由
WAFとRate Limitは、現在もAPIセキュリティにおいて重要な役割を担っています。ただし、それぞれが主に検知する対象は異なります。
WAFは攻撃パターンと脆弱性への防御に強い
WAFは、SQLインジェクションやXSSなど、既知のWeb脆弱性を悪用するリクエストや、異常な入力値を含むリクエストを検知するために主に使用されます。
一方、ビジネスロジックの悪用では、正常な入力値や許可されたAPIが使用される場合があります。そのため、リクエスト内から既知の攻撃パターンを探すだけでは、行動全体の意図を判断することが困難です。
Rate Limitはリクエスト量を制限するが、意図までは判断しない
Rate Limitは、一定時間内に許可するリクエスト数を制限し、過剰な呼び出しからシステムを保護します。
しかし、攻撃者がリクエストを複数のアカウントやIPに分散させたり、設定された閾値よりも低い速度で長時間呼び出したりすれば、制限値を超えない可能性があります。また、同じ回数のリクエストであっても、一般商品の照会と限定商品の購入では、ビジネスへの影響が異なります。
そのため、APIごとの重要度やリクエスト量だけでなく、「誰が、どのような順序で、どのような結果を生み出したのか」まであわせて確認する必要があります。
AIを活用したAPIボット検知では、どのデータを見るべきか？
AIモデルを導入しただけで、ビジネスロジックの悪用を自動的に区別できるわけではありません。まず、サービスにおいて何を正常とし、何を異常と判断するのか、その基準を定義する必要があります。
1. 保護すべきビジネスフローを先に定義する
すべてのAPIを同じ基準で分析する必要はありません。サービスに直接的な被害を与える可能性がある重要な機能から特定します。
ログインとアカウント復旧
商品・在庫照会
カート追加と注文作成
決済と返金
予約とキャンセル
クーポン・ポイント発行
コンテンツの検索とダウンロード
2. 個別のリクエストではなく、リクエスト間の関係を分析する
ビジネスロジックの悪用は、複数のリクエストを関連付けたときに初めて明らかになるケースが多くあります。そのため、次のシグナルをあわせて分析する必要があります。
ログインID、セッションID、IP、ASN
デバイスとブラウザの属性
アクセスしたURLとAPIエンドポイント
APIの呼び出し順序
リクエスト間の時間間隔
同一行動の反復回数
複数のアカウントと一つのデバイスとの関係
注文、予約、クーポン発行などの最終結果
ヘッドレスブラウザやや自動化ツールの使用痕跡
HTTPヘッダーとJA3・JA4フィンガープリント
例えば、同一のセッションで「商品照会 → カートへの追加 → 注文」という処理が10分かけて行われていれば、一般的な購入フローと判断できる可能性があります。一方、数百件のセッションで同じ順序がほぼ同一の時間間隔で繰り返されている場合は、自動化マクロの可能性を疑う必要があります。
3. 正常なユーザーと正規のエージェントを区別してラベリングする
AIを活用した検知において最も重要な作業の一つは、学習データの基準を明確にすることです。
Googleの機械学習ガイドでは、不正確なデータ、ラベルの誤り、データの偏りがモデルの精度に直接影響する可能性があると説明されています。また、直接的な正解ラベルが存在せず、代替指標を使用する場合には、その指標が実際の予測対象とどの程度一致しているかを検討するよう推奨しています。
APIトラフィックは、少なくとも次のように分類する必要があります。
実際の正常なユーザー
パートナー企業と内部システム
検索エンジンと許可されたクローラー
ユーザーに代わって行動する正規のAIエージェント
悪性ボットとマクロ
現時点では判断が難しいトラフィック
マクロが多数含まれるトラフィックを検証せず正常データとして使用すると、モデルが「反復的な自動化行動」をサービスの一般的な正常パターンとして学習してしまう可能性があります。
そのため、リクエスト量や取引の成否だけで自動的にラベルを付与するのではなく、運用記録、遮断結果、ユーザーからの報告、取引結果などもあわせて確認する必要があります。
4. 一つの固定された閾値ではなく、サービスの状況を反映する
正常なパターンは、サービスの種類や時点によって異なります。
平常時には異常に見える短時間での反復照会も、チケット販売開始時や限定販売時には、正常なユーザーにも発生する可能性があります。反対に、リクエスト数が多くなくても、予約とキャンセルを長期間繰り返していれば、サービスに実質的な被害を与える可能性があります。
そのため、サービスの種類、イベントの日程、APIの重要度、ユーザーの行動基準を反映し、検知ポリシーを調整する必要があります。
検知されたリクエストは、すべて遮断すべきか？
AIエージェント時代には、検知結果をそのまま遮断判断と結び付けるアプローチについても、見直す必要があります。
トラフィックのリスクレベルと判断の確度に応じて、対応を区別できます。
リスクレベル | 判断例 | 対応方法 |
|---|---|---|
低 | 身元が確認された検索・照会エージェント | 許可およびモニタリング |
要観察 | 反復性は高いが、被害が確認されていない | 記録、速度制限 |
疑わしい | 異常な呼び出し順序、または複数アカウントとの関連 | CAPTCHA、追加認証 |
高 | APIへの直接アクセス、セッションの再利用、パラメータ改ざん | リクエストの遮断 |
非常に高 | アカウント乗っ取り、大規模な在庫・予約枠の先取り | セッション・アカウントの遮断および調査 |
このような段階的な対応は、正常なユーザーや正規のAIエージェントによるアクセスを維持しながら、悪意ある自動化の実行コストを高めることを目的としています。
APIビジネスロジック悪用への対策チェックリスト
次の質問に回答できない場合、正常に見える自動化リクエストを見逃している可能性があります。
自社サービスにおいて最もビジネスインパクトが大きい重要なAPIは何か？
そのAPIを呼び出せるユーザーやシステムは誰か？
正常な呼び出し順序や時間間隔はどの程度か？
同一行動が何回繰り返されるとビジネス上の被害が発生するのか？
一つのデバイスが複数のアカウントと関連付けられているパターンを確認できるか？
ブラウザを経由しないAPIへの直接アクセスを識別できるか？
正常なユーザー、パートナーシステム、AIエージェント、悪性ボットを区別できているか？
遮断前に追加の検証や認証を適用できるか？
検知ポリシーの変更後に、誤検知率やユーザー離脱を確認しているか？
検知結果を学習データやポリシーの改善に反映しているか？
FAQ
Q. APIリクエストが認証に成功していれば、正常なリクエストではないのですか？
A. 必ずしもそうとは限りません。認証は、リクエストの送信者が有効なアカウントや認証情報を持っていることを意味します。しかし、その送信者が機能を意図された範囲内で利用していることまで保証するものではありません。
正規のアカウントを使用して予約、キャンセル、クーポン発行を繰り返す行為も、ビジネスロジックの悪用に該当する可能性があります。
Q. AIエージェントトラフィックは、すべてボットとして遮断すべきですか？
A. AIエージェントによるアクセスは自動化されたトラフィックですが、すべてが悪性であるとは限りません。ユーザーに代わって商品を検索したり、予約を行ったりする正規のエージェントも存在する可能性があります。
エージェントの身元、アクセス目的、権限の範囲、実際の行動をあわせて確認する必要があります。
Q. WAFを導入していれば、Bot対策は不要ですか？
A. 二つのソリューションは、主に分析する対象が異なります。WAFはWeb脆弱性や既知の攻撃パターンを中心に防御し、Bot対策は正常なリクエストのように見える自動化ツールや反復的な行動の識別に重点を置きます。
一方をもう一方の完全な代替手段として捉えるのではなく、組み合わせて適用することが適切です。
Q. Rate Limitを適用すれば、大量のAPI呼び出しを防げますか？
A. 一定時間内の過剰な呼び出しを制限するうえでは有効です。しかし、リクエストが複数のIPやアカウントに分散していたり、設定された閾値よりも低い速度で繰り返されたりする場合は、検知が難しくなる可能性があります。
APIの重要度、アカウントとセッションの関係、呼び出し順序、最終結果まであわせて確認する必要があります。
Q. AIを活用したボット検知で最も重要なことは何ですか？
A. アルゴリズムと同じくらい、学習データの品質が重要です。実際の正常なユーザー、正規のAIエージェント、パートナーシステム、悪意ある自動化を区別し、一貫した基準でラベリングする必要があります。
サービスの特性に合わないデータを学習した場合、高い検知精度が実際の運用性能につながらない可能性があります。
これからは「ボットか否か」ではなく「何をしているのか」を見るべき
AIエージェントがユーザーに代わってWebサイトやAPIを利用する環境では、単に「自動化されているかどうか」だけで正常なアクセスと攻撃を区別することが難しくなります。
リクエスト形式が正しいか、認証に成功しているか、呼び出し回数が閾値を超えているかは、今後も重要な判断基準です。しかし、それだけでは正規機能を悪用する行為を十分に把握できません。
これからのAPIボット対策では、次の問いをあわせて確認する必要があります。
誰がリクエストし、どのような権限を持ち、どのような順序で行動した結果、サービスにどのような影響を与えたのか。
AIを活用した検知の差別化も、単に大量のトラフィックを学習させることから生まれるものではありません。サービスにとって有効な正常トラフィックを選別し、正常なユーザー、AIエージェント、悪性ボットを正確に区別したデータによって、モデルとポリシーを継続的に改善することから始まります。