APIは以前、単純なトラフィックモデルで動いていました。開発者が登録し、keyを受け取り、統合を実装し、その統合がスケジュールに従って、またはユーザーが何かをクリックしたときにエンドポイントを呼び出す。API向けのボット管理は、そのモデルを前提に発達しました。keyを認証し、量を抑え、明らかに悪質なトラフィックをふるい落とし、残りのサービスを全員に提供し続ける、という考え方です。
そのモデルは今も有効で、そこで使うツールも今なお重要です。変わったのは、呼び出しの背後にいる主体です。同じAPI keyが、顧客のアプリを使う人間、人間に代わって作業を依頼されたAI assistantを使う人間、そして複数ステップの作業を夜通し実行する自律的なagentからのリクエストを運ぶようになりました。既存の制御は1つのkeyと1つのリクエスト率しか見ませんが、製品、サポート、ポリシーの判断には、それ以上の情報が必要なことが多いのです。
Proof of Actor はそのギャップを埋めます。各リクエストで誰または何が動作しているかをAPIに伝え、その証拠を示し、最終判断はコードに委ねます。このページでは、APIボット対策の主要な層と比較し、それぞれの役割を確認します。
簡潔な要約
| APIボット対策 | Proof of Actor | |
|---|---|---|
| 主な問い | このリクエストは許可され、認証され、制限内に収まっているか? | 誰または何が動いていて、その根拠は何か? |
| 典型的な層 | API gateway、WAFのボットルール、API keys、rate limits | APIまたはMCP server内のactor classification |
| 識別するもの | keyを所有するアカウントまたは統合 | 各リクエストの背後にいるactor: Human, Human + AI, Agent, Unknown |
| 出力 | Allow、Reject、Throttle。場合によってはbot score | classとbasis: verified、declared、inferred、unknown |
| 不明確なトラフィック | keyが有効なら通常は許可、またはルールで拒否 | Unknown。routeごとにフォールバックを選べる |
| 応答を決める人 | gatewayとWAFの設定 | あなたのアプリケーションコード |
| インストール直後の既定 | enforcement | observation。policyを追加するまで何も変わらない |
| 最も得意なこと | 可用性、悪用のふるい落とし、クォータ、責任の所在 | 各actorに適切に応答し、API利用を理解すること |
以下の各節で、それぞれを説明します。
APIボット対策が得意なこと
Proof of Actorは、これらすべての層と並んで置くために設計されており、置き換えるためではありません。だからこそ、それぞれの役割を明確にしておく価値があります。
API gateways
gatewayはAPIの正面玄関です。接続を終端し、API keyやtokenを認証し、リクエストを適切なサービスへ振り分け、クォータを強制し、請求や分析のために利用状況を記録することがよくあります。これは、「この呼び出し元は入ってよいか、どの入口から入るか?」という問いに、すべてのendpointで素早く一貫して答えます。
WAF bot rules
botルールを持つweb application firewallは、既知の攻撃パターンや悪用目的の自動化をトラフィックから検査します。インジェクションの試行をふるい落とし、悪用履歴のある送信元からのトラフィックを遮断し、スクレイピングやcredential攻撃のように見えるリクエストにchallengeをかけたり破棄したりできます。これは、本来コードに届いてはならないトラフィックに対する最善の防御です。
API keys and tokens
keyとtokenは責任の所在を明確にします。すべてのリクエストがアカウントに結び付くので、どの統合が呼び出したかが分かり、アクセスを取り消せて、利用状況を帰属させられます。スコープ付きtokenはさらに踏み込み、呼び出し元ができることを制限します。
Rate limits
rate limitsは可用性を守ります。1つの統合が全体の容量を使い切るのを防ぎ、ブルートフォースや列挙の試行を遅らせます。key単位、route単位の制限は、標準的で効果的な制御です。
これらの層を合わせれば、保護と責任の所在に関する問いには十分に答えられます。これは維持してください。
彼らが答えるためには作られていなかった問い
これらの層はどれも、認証済みリクエストの背後にいる actorの種類 を教えるために設計されていません。有効なkeyは、どのアカウントがその統合を所有しているかを示しますが、次のことまでは示しません。
- この特定の呼び出しが、顧客のアプリでボタンを押した人間から来たのか
- 人間がAI assistantにその操作を依頼したのか
- 自律的なagentが長いタスクの1ステップとして呼び出したのか
- あるいは、誰にも分からないのか
この区別は月ごとに重要性を増しています。CRM統合、スケジューリングツール、開発者向けプラットフォームを提供するAPIは、今では人間主導のアプリと同じkeyでagent trafficを受けることが増えています。agentに構造化された応答を返したい、高影響の書き込みではagent主導の操作に確認を求めたい、AI支援の送信を明示したい、あるいは単にAPI利用のどの程度がagent主導なのかを測りたいなら、actor contextが必要です。
Proof of ActorがAPIに加えるもの
Proof of Actorは、各interactionに対して4つのclassのいずれかを返します。
- Human: 観測された信号が、人間主導のinteractionを示します。
- Human + AI: 人間がAIの支援を受けてinteractionを指示し、それが宣言されたか、対応する統合を通じて観測されています。
- Agent: 自動化された、またはagent由来のinteractionです。
- Unknown: 根拠が信頼できる判定を支えません。
各結果には、その evidence basis も示されます。
- Verified: たとえば、公開鍵に対して確認された HTTP Message Signature (RFC 9421)。
- Declared: クライアント、またはあなた自身のアプリケーションがそう述べたもの。
- Inferred: 振る舞いまたは文脈の信号で、推論であることが明確に示されたもの。
- Unknown: 信頼できる根拠がない。
APIでは、verified basis が特に有用です。リクエストに署名するagentは、公開されたkeyと照合できます。これは、IETFの Web Bot Auth の取り組みの基礎となっている方法です。背景は Web Bot Auth for product teams を、実装面は verifying signed agent requests を参照してください。
ここで1つ重要な制約があります。有効な署名は、どのkeyがそのリクエストに署名したかを証明します。ただし、そのagentがその操作を実行する権限を持つことまでは証明しません。authorizationは、あなたのAPIのアクセス制御に残ります。agent authorization の項目がその違いを説明しています。
スコアとkeyとactor evidenceの違い
一部のボット対策製品は、各リクエストにスコアを付けます。スコアは、ブロック判断には効率的です。しかし、正当なリクエストが人間主導なのかagent主導なのかを示さず、事実と推論を分けないため、API製品の判断にはあまり向きません。
API keyは逆の制約を持ちます。所有者については正確ですが、actorについては何も語りません。1人の顧客のkeyが、1時間の間に4つすべてのclassを運ぶこともあります。
Proof of Actorは、その両方の区別を見えるままに保ちます。APIはkeyからアカウントを、Proof of Actorからactor classを、そしてそれを支えるbasisを見ます。それぞれの層が、得意な問いに答えます。
どこで動くか
gatewayとWAFは、ネットワークのエッジ、またはサービスの前面で動きます。その位置は、保護とクォータに適しています。
Proof of Actorは、APIロジックがある場所で動きます。Founding teamは、Node.js middleware、Next.js、制御下にあるedge layer、汎用HTTP API、またはMCP serverの統合を通じて接続できます。全一覧は integrations を参照してください。アプリケーション内で動作するため、APIが知っている情報、つまりroute、workflow、クライアントが自分を宣言したかどうか、署名が検証されたかどうかを使えます。
ルーティング判断はコードの中に残る
Proof of Actorは、既定では何もブロックしません。最初は observation mode で始まるため、導入してもAPIの応答方法は変わりません。endpointごとのactor構成を確認し、個々の結果の証拠を見て、Unknownの比率を追えます。
準備ができたら、route、actor class、basisごとにアプリケーション定義のpolicyを記述します。典型的な結果は次のとおりです。
- Allow: 通常どおりリクエストを処理する。
- Adapt: verified agentに対して、構造化された応答、または簡略化された応答を返す。
- Challenge: 追加の確認手順を求める。たとえば、高影響の書き込みに対する人間の承認。
- Review: 人が確認するためにアクションをキューに入れる。
- Rate-limit: 特定のroute上の特定のclassとbasisに、より厳しい制限を適用する。
policyを実運用トラフィックでpreviewしてからenforceでき、routeごとに段階的に適用できます。手順は rolling out actor-aware policies safely にまとめてあり、protecting sensitive actions without blocking agents ではよくあるパターンを紹介しています。
UnknownのAPI呼び出し元を扱う
どのAPIにも、高い確度では分類できないトラフィックがあります。従来の制御では、有効なkeyなら通常は通過し、無効なら通過しません。その間はありません。
Proof of Actorは、明示的な Unknown の結果を返し、routeごとにフォールバックを選べます。読み取り専用のカタログendpointは開いたままにできます。アカウント変更は、既存のより厳しい確認を維持できます。大量エクスポートはreviewに回せます。詳細は handling Unknown traffic と unknown automated traffic を参照してください。
どう組み合わせるか
最も強いAPI構成は、それぞれの層をそれぞれの役割に使います。
- エッジでは、WAFが不正で不完全なトラフィックをふるい落とします。
- gatewayでは、keyを認証し、クォータを強制し、利用状況を記録します。
- APIの内部では、Proof of Actorが通過した各リクエストを分類し、そのbasisを示します。
- ハンドラでは、classとbasisを使って応答を選びます。人間主導の呼び出しには通常処理、verified agentには構造化応答、agent主導の高影響書き込みには確認手順、Unknownにはフォールバック。
- 分析では、gatewayからのアカウントデータと並べて、各actor classがどのendpointやworkflowを使っているかをチームが確認できます。
このスタックには、重複しているものはありません。gatewayはアカウントを知り、WAFは脅威パターンを知り、Proof of Actorはactorを知ります。
何に重点を置くべきか
主な問題が悪用、可用性、または無制限の利用であるなら、まず APIボット対策 に重点を置いてください。たとえば、認証endpointへのcredential攻撃、過度なスクレイピング、1つの統合が他を圧迫する問題です。
主な問いが呼び出し元に関するものなら、Proof of Actor に重点を置いてください。たとえば、APIトラフィックのどの程度がagent主導か、どのagentがどのendpointを呼ぶか、人間主導とagent主導の利用がどこで違うか、どのrouteにactor-aware policyが必要か、といった点です。APIs use case と AI agent identification for APIs では、さらに詳しく説明しています。
本番APIを運用する多くのチームは、両方に答える必要があります。
始める
Proof of Actorはprivate betaです。選定されたfounding developer teamは、合意した利用上限の範囲で、最大12か月の無料アクセスを受けられ、自動請求はありません。早期アクセスに申し込む から、理解したいAPIと呼び出し元についてお知らせください。