メインコンテンツにスキップ
検証済みの自動化

検証済みの自動リクエストを識別する

自動クライアントがリクエストに署名している場合、アプリケーションはその署名を確認し、呼び出し元を適切に扱えます。Proof of Actor は、その確認を明確で振り分け可能な結果に変えます。

早期アクセスを取得仕組みを探る
Toshendra Sharma

著 Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

すべての自動トラフィックが同じではない

自動クライアントは毎分のようにアプリケーションへ到達します。検索クローラー、監視ツール、ユーザーのためにページを取得するパートナー連携、AI アシスタント、そしてタスクを実行する自律エージェントです。長い間、多くのアプリケーションがそれらを見分ける唯一の手段は user-agent ヘッダーであり、どのクライアントでも好きな値を設定できました。

そのため、アプリケーションチームは難しい立場に置かれます。すべての自動化を疑えば、お客様が依存している正当なエージェントの体験を損ねます。ヘッダーを信用すれば、誰でも有名クローラーを名乗れてしまいます。

検証済みの自動リクエストは、この前提を変えます。自動クライアントが公開済みのキーでリクエストに署名している場合、アプリケーションはその署名を確認し、どのクライアントが署名したのかを暗号学的に把握できます。Proof of Actor はその確認を、コードで振り分け可能な一貫した actor の結果の一部にします。その確認で何が分かり、何が分からないのかを詳しく知るには、署名された AI エージェントのリクエストが何を証明するか をお読みください。

リクエスト署名の仕組み

自動トラフィックに対する新しいアプローチは、HTTP message signatures を使います。これは RFC 9421 で標準化されており、HTTP メッセージの構成要素に対する署名の作成、エンコード、検証方法を定義しています。クライアントは各リクエストの選択された部分に秘密鍵で署名し、署名とそのパラメータをヘッダーに含めます。対応する公開鍵は、クライアントが管理する識別子、通常はそのドメインに結び付いた場所に公開されます。

リクエストが届くと、受信側は公開鍵を取得または参照し、署名された内容を再構成して、署名を検証します。検証に成功すれば、そのリクエストはそのキーの保持者によって署名されたことになります。自動トラフィックの署名に関する作業は IETF の Web Bot Auth working group で継続しており、その charter では、クローラーやエンドユーザーの代わりに動く AI エージェントなどの自動クライアントを暗号学的に認証することを対象にしています。これについては Web Bot Auth の用語集エントリでも要約されています。署名された AI エージェントのリクエストが何を証明するか のブログ記事では、検証済みのリクエストを最初から最後まで追っています。また、APIs のユースケース では、検証が最初にどこで効くのかを示しています。

署名されたエージェントリクエストの検証 のガイドでは、タイムスタンプ、リプレイウィンドウ、キーキャッシュを含め、仕組みを詳しく説明しています。

検証済みの署名が証明するものと、証明しないもの

この区別は、検証済みの自動リクエストを適切に扱ううえで最も重要です。

有効な署名は、リクエストが公開された識別子に関連付けられたキーで署名されたことを証明します。キーが運用者のドメインに属している場合、そのリクエストはその運用者のキーを保持するクライアントから送られたことになります。

有効な署名が証明しないもの:

  • そのエージェントに誰が指示したのか、あるいは誰かがこのアクションを依頼したのか
  • その人がエージェントに権限を委任したこと
  • 運用者の背後にある現実世界の法的な身元
  • 要求されたアクションが安全であること、またはアプリケーション内で許可されていること

これらは別の問いです。アプリケーションは、自身の認証情報、認可モデル、ポリシーでそれらに答えます。Proof of Actor はそれらを意図的に分けて扱います。Detection & Limitations のページには、各種の証拠が何を示せるのかが正確に記されています。

Proof of Actor が検証済みの自動リクエストをどう扱うか

Detect

統合は、署名ヘッダーを含むリクエストコンテキストを Proof of Actor に渡します。署名は公開されたキーと照合されます。検証できたリクエストは verified の基盤で記録されます。自分自身の名前しか示さないクライアントは declared として記録されます。行動パターンは inferred として記録されます。十分な材料がない場合、結果は Unknown です。暗号学的検証に成功しない限り、何も verified には昇格しません。

Understand

どの verified な運用者がアプリケーションを呼び出しているのか、どの route を使っているのか、頻度はどれくらいか、そして declared や Unknown の自動化とどう比較されるのかを確認できます。各結果の証拠サマリーには、関与したキーと識別子が示されるため、チームはどのリクエストでもすばやく調査できます。

Route

ポリシーには基盤を使います。よくあるパターンは次のとおりです。

  • 読み取り専用 route では、verified な agent に構造化された応答を返す。たとえば API やページの Markdown 版です。
  • verified な運用者が識別できる場合は rate-limit を引き上げ、declared クライアントには標準の制限を維持する。
  • 署名内容にかかわらず、すべての書き込み route で既存の認可を維持する。
  • 各 route ごとに、署名なしおよび Unknown の呼び出し元に対する明示的な fallback を定義する。

ポリシーを決めるのはお客様です。Proof of Actor は証拠を提供します。

user-agent ヘッダーだけでは不十分な理由

user-agent 文字列は宣言です。どのクライアントでも任意の値を送信でき、user-agent spoofing は技術を要しません。そのため、クローラーの運用者は独自の確認方法を公開しています。Google は Googlebot の検証 のために逆引きと正引きの DNS 参照および公開 IP 範囲を案内し、Bing は Bingbot の検証 のための DNS チェックを公開し、OpenAI は自社の crawlers and user agents ごとに IP 範囲ファイルを公開しています。Proof of Actor は user-agent の主張を declared の証拠として扱い、検証とは見なしません。つまり、よく知られたクローラーを名乗っていても有効な署名がなければ、そのクライアントは declared または inferred の基盤で報告され、ポリシーは本当に身元を証明したクライアントとは別に扱えます。

これが、検証済みの自動リクエストが価値を持つ理由です。ヘッダーをコピーしただけの相手にまで信頼を広げることなく、信頼に値するクライアントへだけ信頼を拡張する、信頼できる方法を提供します。

身元の証拠、認証情報、認可

自動クライアントを扱うあらゆるアプリケーションでは、3 つの層が連携します。

  1. 身元の証拠: どのクライアントがこのリクエストに署名したのか。これは検証済みの署名が答えます。
  2. 認証情報: どのアカウントが責任を持つのか。これは API key、token、session が答えます。
  3. 認可: この呼び出し元はこれを実行できるのか。これは権限モデルが答えます。

Proof of Actor は最初の層を強化し、それを可視化します。身元や委任の認証情報を発行することはなく、認可を置き換えることもありません。層を分けておくことで、低リスクな route では verified な agent を寛容に扱い、高い影響を持つ route では慎重に扱えます。

どこに組み込むか

Proof of Actor は、gateway、認証、rate limiting と並んで機能します。統合はサーバーサイドの middleware として、edge で、MCP server 内で、または汎用 HTTP integration として動作し、各 founding team に対して実装支援付きで提供されます。トラフィックの大半が APIs と tools である場合は、APIs と MCP Servers のユースケースが、最も重要なパターンを示しています。

観測モードから始める

すべての統合は観測モードから始まります。結果は、アプリケーションの応答方法を変えずに記録されるため、自動トラフィックのどれだけが verified なのか、どの運用者が署名しているのか、Unknown の割合がどこで最も高いのかを確認できます。ポリシーは、その証拠が支えられるようになってから、route ごとに後で適用します。How It Works で全体の流れを説明しています。

検証を信頼できるものにする実務上のポイント

署名検証の信頼性は、その周辺の実装次第です。いくつかの実践で、検証済みの自動リクエストを本番で安定して扱えます。

新しさを確認する

RFC 9421 は created と expires の署名パラメータを定義しており、署名付きリクエストには通常それらが含まれます。短い時間窓の外にある署名は拒否してください。そうすれば、取得されたリクエストが後で再生されることを防げます。

キーを適切にキャッシュする

運用者の公開キーを毎回取得すると、遅延が増えます。適切な期間キャッシュし、未知の key identifier によって署名検証が失敗したときは更新してください。そうすれば、キーのローテーションが誤った失敗を引き起こしません。

リクエストの適切な部分に署名する

タイムスタンプだけを含む署名は、ほとんど証明しません。署名対象の要素に method、path、host が含まれていることを確認し、署名がアプリケーションが実際に受け取ったリクエストに結び付くようにしてください。

証拠を記録する

各検証済みリクエストについて、key identifier、公開された識別子、結果を保持してください。何か異常が起きたとき、チームはどのクライアントが何をいつ署名したのかを正確に確認できます。

Proof of Actor はこれらの確認を Detect ステップの一部として処理し、ポリシーが読み取れる基盤として結果を報告するため、アプリケーションコードはシンプルなままです。

Founding developer program に参加する

Proof of Actor は private beta です。選定された founding development teams は、合意済みの利用上限の範囲で、エンジニアによる直接の統合サポート付きの無料アクセスを最大 12 months free で受けられます。

自動クライアントがアプリケーションに到達し、検証済みのものを別扱いにしたい場合は、早期アクセスに申し込んでください。アプリケーションと見えている自動呼び出し元について教えていただければ、Proof of Actor がどう当てはまるかをご案内します。

出典

開発者向け

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record
{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}
class
Human, Human + AI, Agent, Unknown。
basis
証拠の強さです: Verified, Declared, Inferred, Unknown。
evidence
結果の背後にあるsignalsです。理由をチームが確認できます。

observation modeから始めます。結果をlogの横に記録し、policyを選ぶまで何も変更しません。 Node.js integration guideを読む

よくある質問

検証済みの自動リクエストとは何ですか?

既知の識別子のために公開されたキーで暗号学的署名が検証できる、自動クライアントからのリクエストです。たとえば運用者のドメインです。どのクライアントがリクエストに署名したのかが分かります。

検証済みの署名があれば、そのエージェントは認可済みという意味ですか?

いいえ。署名は、リクエストをキーとその公開された識別子に関連付けるだけです。そのクライアントがアクションを実行できるかどうかは、アプリケーションが行う別の認可判断です。

リクエストに署名しない自動クライアントはどうなりますか?

Proof of Actor は、利用可能な場合は declared と inferred の証拠を使ってそれらを分類し、証拠が十分でないときは Unknown と報告します。すべての結果に基盤が示されます。

user-agent 文字列でクライアントを検証できますか?

いいえ。user-agent 文字列は簡単に偽装できるため、検証ではなく宣言として扱われます。リクエストを検証可能にするのは暗号学的署名です。

どうやって始めればよいですか?

早期アクセスに申し込んでください。Founding チームは観測モードから開始し、選定されたチームは合意済みの利用上限の範囲で最大 12 months free を受けられます。

誰があなたの app を使っているかを把握します。

少数のfounding developer向けのprivate betaです。

早期アクセスを取得価格を見る

先に話しますか? 創業者に相談する