APIキーの不正利用と無料枠のリスク
APIキーの不正利用対策は、無料リクエスト枠やトライアル用の認証情報を提供するAPIプラットフォーム、AIサービス、開発者向けツールにとって重要なポリシー設計です。EchoScanは、キーや追加の利用枠を付与する前に、デバイスの継続性とブラウザ、ネットワーク、自動化に関するリスク情報を提供します。Browser Verifierがブラウザでシグナルを収集して送信し、成功後にサーバー発行のImprintを受け取ります。導入先バックエンドは、そのImprintでLiteとPro共通の基本Reportを照会します。API提供者は、その結果をアカウント、利用条件、決済、本人確認、リクエスト頻度の情報と組み合わせて判断します。
メールアドレスを変えるだけでは不十分な理由
メールアドレスはアカウントを区別する手掛かりにはなりますが、利用しているデバイスやアクセス環境までは示しません。短時間に新しいアドレスを作成しても、同じブラウザやデバイス環境が使われ続ける場合があります。一方、共有端末、教室、家庭、開発チームでは、複数の正当なメールアドレスが1台のデバイスから利用されることもあります。
そのため、API提供者は複数の判断材料を組み合わせる必要があります。アカウントの作成日時、連絡先の確認状況、請求状態、招待関係、過去の利用枠、リクエスト頻度は、サービス上の利用履歴を示します。デバイスの継続性とアクセスリスクは、リクエスト時の環境を補足します。どちらか一方だけで、もう一方を置き換えることはできません。
キーを発行する前にデバイス情報を確認する
- 登録、開発者向けトライアル、キー作成、利用枠追加のページでBrowser Verifierを実行します。
{ imprint }を受け取り、保護対象のリクエストと一緒にAPI提供者のバックエンドへ送ります。- バックエンドからSecret API Keyを使ってReport API v1を照会します。
- LiteとPro共通の基本Reportで
risk.statusとデバイス継続性を確認し、任意フィールドは取得できたデータに応じて扱います。 - アカウント、利用枠、決済、本人確認、リクエスト頻度のルールと組み合わせます。
- API提供者が定めた許可、追加認証、制限、保留、確認、拒否の処理を行います。
公開可能なEnvironment IDはブラウザコードに設定し、Secret API Keyはサーバーだけに保存します。この境界により、訪問者が連携用の認証情報を使ってReportを読み取ることを防ぎます。
継続性とアクセスリスクから分かること
デバイス継続性は、その環境が以前に観測されたか、何回観測されたか、記録がある場合の初回・前回時刻を示します。両プランでブラウザと OS の整合性、ネットワーク情報、自動化の兆候、最近の活動を確認できます。History は独立した期間指定の照会です。
これらの情報は、初めて観測した環境か、アクセスの集中を詳しく確認すべきか、追加認証を求めるべきリスク状態か、といった個別の判断に役立ちます。無料プランの対象者かどうかをEchoScanが決めるわけではありません。利用条件はAPI提供者が定めます。
複数の情報を組み合わせた利用枠ポリシー
実際の運用では、次のような情報を組み合わせます。
- アカウント作成日時、メールや電話番号の確認状況、組織への所属
- 過去に取得した無料キー、クレジット、トライアル、利用枠
- 支払方法と有料プランへの移行履歴
- デバイスの継続性、ネットワーク情報、自動化リスク
- リクエスト頻度、同時実行数、Tokenや計算のリソースコスト、エンドポイントの重要度
- 完了した追加認証、手動確認、異議申し立ての履歴
API提供者は、最終判断を説明できるサービス上の記録を保持します。EchoScanが提供するのはアクセス時の情報であり、アカウントや契約に関する記録のすべてではありません。
中程度のリスクには段階的に対応する
SUSPICIOUSは追加情報を確認するきっかけであり、自動的な拒否を意味しません。メールや電話番号の確認、支払方法の登録、初期利用枠の縮小、高コスト機能の一時保留、同時実行数の制限、短い有効期限、手動確認などを選択できます。
アクセスリスクが、API提供者のアカウント情報や決済情報とも一致する場合は、より強い制限を検討できます。リソースコスト、取り消しやすさ、利用者の負担、正当な開発者を誤って止めた場合の影響に合わせて対応を調整します。
同じデバイスからの再訪だけでは不正の根拠にならない
同じデバイスは、正当な再訪、共有端末、サポートを受けながらの設定、学校のPC、企業ゲートウェイ、顧客が管理する自動テストでも使われます。seen_before: trueや高いaccess_countだけで、複数アカウントによる不正利用を証明することはできません。
再訪をきっかけに、時刻の分布、関連するアカウント、利用枠の履歴、本人確認、決済、ネットワークの変化、自動化リスク、保護対象の操作を確認します。すべての再訪デバイスを拒否すると誤検知が増え、デバイスを切り替える不正利用も見逃します。
LiteとProの選び方
Lite と Pro は同じ基本 Report 構造を使い、デバイス継続性、現在のアクセスリスクと理由、ブラウザ、OS、ネットワーク、最近の活動を提供します。任意フィールドは取得できたシグナルとデータに応じて返します。
Lite と Pro はどちらも History と任意の Account Map に対応し、新しい関連付けと既存スナップショットの読み取りを利用できます。Pro はリクエスト枠、レート上限、Browser Environment の容量を拡大します。History は指定期間を照会する操作です。基本 Report の継続性の概要と最近の活動は両プランで利用できます。
次のステップ
開発者向け導入フローを確認し、既存の利用枠ポリシーに結果を組み込んでください。ブラウザフィンガープリントAPIガイドでは、公開Environment IDとサーバー専用Secret API Keyの境界を説明しています。
API利用枠の判断に関するよくある質問
1台のデバイスを1つのAPIアカウントだけに制限するべきですか？
自動的に制限するべきではありません。共有端末、チーム、教室、サポート対応、正当な再訪でも、複数のアカウントが同じデバイスから利用されます。再訪は追加確認の材料であり、それだけで拒否する理由にはなりません。
EchoScanはAPI利用枠の不正利用を断定しますか？
断定しません。EchoScanが返すのはデバイスの継続性とアクセスリスクです。API提供者がアカウント、利用枠、決済、本人確認、リクエスト頻度の情報と組み合わせて最終判断します。
API利用枠の確認でProが役立つのはいつですか？
Lite と Pro は同じ基本 Report 構造を使い、デバイス継続性、現在のアクセスリスクと理由、ブラウザ、OS、ネットワーク、最近の活動を提供します。任意フィールドは取得できたシグナルとデータに応じて返します。Lite と Pro はどちらも History と任意の Account Map に対応し、新しい関連付けと既存スナップショットの読み取りを利用できます。Pro はリクエスト枠、レート上限、Browser Environment の容量を拡大します。History は指定期間を照会する操作です。基本 Report の継続性の概要と最近の活動は両プランで利用できます。
Imprint はブラウザが生成しますか？
ブラウザが生成するものではありません。Browser Verifier がシグナルを収集して送信し、成功後に EchoScan サーバー発行の Imprint を返します。導入先バックエンドは、その Imprint で Lite と Pro 共通の基本 Report を照会します。