AIエージェント識別

API向けAIエージェント識別

あなたのAPIは、どのキーがリクエストを送ったかを既に把握しています。Proof of Actorは、その背後にどの種類のアクターがいたのか、その判断を支える証拠は何かを示し、次にどうするかはあなたのコードに決めさせます。

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

あなたのAPIはキーを知っています。アクターは知りません。

すべてのAPIリクエストには、それを支払っている主体を示す何らかの証跡が付いています。API key、OAuth token、sessionです。その証跡が答えるのは、1つの問いです。どのアカウントがその呼び出しの責任を負っているかを示します。しかし、今まさに実際に呼び出しているのが何かまでは示しません。

1つのAPI keyは、terminalでテストする開発者、定期実行されるbackend job、AI assistantを通じて作業する人、そしてキーを渡されてタスク完了を指示されたautonomous agentによって使われることがあります。これらはすべて異なるアクターです。リズムも、失敗の仕方も、リスクの形も違います。これらをすべて同じように扱うと、顧客が依存している正当な自動化を過度に制限するか、あるいは常時稼働していないagentに任せるべきでないAPIの部分を十分に保護できないかのどちらかになります。

API向けAIエージェント識別は、そのギャップを埋めます。キーからすべてを推測するのではなく、各リクエストの背後にいるアクターの分類と、それを支える証拠を得られます。これが Proof of Actor が提供するために作られたものであり、APIsのユースケースでは、APIチームがこれをルートごとにどう適用するかを示しています。

なぜ今、APIチームにアクターの文脈が必要なのか

APIへの自動トラフィックは新しいものではありません。script、integration、crawler は昔から存在していました。変わったのは自動化の種類です。AI agentは、documentationを読み、callを連鎖させ、創造的にretryし、すべての手順を見守っていない人に代わって行動できます。それらの多くは有用で歓迎すべきものです。中には作りが不十分なものもあります。少数は悪意があります。

アクターの文脈がなければ、APIチームはどうしても大雑把な手段に頼りがちです。

keyごとのrate limit は、良いagentも悪いagentも同じように遅くします。
user-agentルール は、クライアントがheaderを変えた瞬間に壊れます。
一律ブロック は、正当な自動化をWeb appのスクレイピングへ追いやります。

アクターの文脈があれば、より正確に応答できます。あなたが把握しているoperatorからの署名済みagentには、read routeで高めのlimitを与えられます。write routeを叩くUnknownの呼び出し元には、より強いcredentialを求められます。AI assistantを使う人には通常の体験を維持できます。重要なのはagentを止めることではありません。各種の呼び出し元に適切な経路を与えることです。署名付きリクエストで何が分かり、何が分からないかについては、署名付きAI agentリクエストが証明することをご覧ください。

Proof of ActorでAIエージェント識別がどう機能するか

Proof of Actorは、すべてのリクエストに対して同じ証拠先行の流れに従います。完全な流れは How It Works で確認できます。ここではAPIチーム向けに要点だけを示します。

1. 統合からのシグナル

統合は、その文脈で利用可能なシグナルをProof of Actorに渡します。APIでは通常、headerやprotocolの詳細などのリクエスト文脈、クライアントが提示する暗号学的なrequest signature、そしてクライアント自身が行う宣言が含まれます。各シグナルには、その出どころがラベル付けされます。

2. 根拠付きの分類

シグナルは検査され、4つの公開クラスのいずれかにまとめられます。

Human: 観測されたシグナルが、人による指示に基づくやり取りを示しています。
Human + AI: AIの支援が宣言されたか、あるいは観測可能な統合によって検出されました。
Agent: 自動化された、またはagent由来のトラフィックで、検証可能なIDか、慎重に条件付けられた推論によって裏付けられています。
Unknown: 証拠が信頼できる判断を支えません。

すべての結果には、その basis も付いています。verified、declared、inferred、unknown です。これがAPIチームにとって最も価値のある部分です。HTTP message signature が RFC 9421 で定義されているとおり公開鍵に対して検証される場合、そのリクエストはverifiedとして報告されます。クライアントが自らをagentだと名乗るだけならdeclaredとして報告されます。自動化されているように見えるパターンはinferredとして報告されます。結果が暗号学的根拠に基づくのか、ヒューリスティックに基づくのかを迷う必要はありません。 evidence basis は答えの一部です。

3. あなたのコードが扱える結果

結果は、class、basis、そして読みやすい証拠要約とともにアプリケーションへ返されます。何をするかはあなたのコードが決めます。観測モードでは、そのまま記録します。準備ができたら、それを使ってルーティングします。

チームが得られるもの: Detect, Understand, Route

Proof of Actorは、1つの製品に3つの機能を備えています。

Detect

APIから見えるアクターシグナルを集め、verifiedな断定とbehavioralな推論を切り分けます。署名付きagentリクエスト、宣言されたクライアント、自動化シグナル、Unknownの結果はすべて別々に保持されるため、何かが静かに1つのスコアへ混ざることはありません。

Understand

どのアクターがどのrouteを呼び、時間とともにそれがどう変わり、各分類の背後にどの証拠があるかを確認できます。Unknown rateは可視のまま維持されるため、どこまでをカバーできていて、どこでより強いシグナルが役立つのかが正確に分かります。

Route

routeごと、リスク層ごとにポリシーを書けます。allow、adapt、challenge、review、rate-limitです。read-only endpointでは、verifiedなagentに対して構造化された余裕のある経路を維持できます。影響の大きい操作には、より強いcredentialを求められます。Unknownとtimeoutに対して明示的なfallbackを定義し、何が起きてもAPIが予測可能に振る舞うようにします。どのポリシーをopenに失敗させ、closedに失敗させるかは、そのrouteでの誤りのコストに応じて決められます。

ID evidence、credentials、authorizationは3つの別々のものです

agentを意識したAPI設計で最もよくある誤りは、3つの別々の問いを1つにまとめてしまうことです。Proof of Actorはそれらを分けて扱い、あなたの設計もそうあるべきです。

ID evidence: どの種類のアクターが呼び出しているのか、そしてそれを何が証明するのか。これがAIエージェント識別の役割です。verified signatureは、リクエストをキーと、その公開されたoperator identifierに関連付けます。IETFの Web Bot Auth working group は、この種の自動クライアント向け暗号学的認証を標準化することを目的としており、その範囲はエンドユーザーではなくagentの認証を対象としています。
credentials: この呼び出しの責任を負うのはどのアカウントか。これはあなたが発行し管理するAPI key、token、sessionです。
authorization: この呼び出し元は、特定のことをしてよいのか。これはあなたのpermission modelです。

verifiedなagentが自動的にauthorizedなagentになるわけではありません。有効なsignatureは、人がagentに権限を委任したことも、その要求された操作が安全であることも証明しません。Proof of Actorは、最初の問いに対して信頼できる文脈を与え、2つ目と3つ目は本来あるべき場所、つまりあなたのアプリケーションに残します。詳細は agent authorization と、証拠が何を確立できて何をできないかについての Detection & Limitations をご覧ください。

Unknownは失敗ではなく、機能です

request signingは任意であり、署名のないクライアントは自分のことを好きなように名乗れます。すべてのリクエストをHumanかAgentのどちらかに強制するsystemは、ときどき自信満々に間違い、その瞬間にそれが分かりません。

Proof of Actorは、証拠が判断を支えないときにUnknownを返します。UnknownがHumanに変換されることはなく、デフォルトで悪意があるとみなされることもありません。ポリシーが、routeごとにUnknownの意味を定義します。public readでは許可し、account変更では既存のcheckを維持し、重要度が高い場所ではreviewに回します。Unknownを見えるままにしておくことが、他の分類を信頼できるものにします。 handling unknown traffic のガイドでは、その設計方法を示しています。

AIエージェント識別がスタックのどこに入るか

Proof of Actorは、既存のgateway、authentication、rate limitingと並んで配置されます。どれかを置き換えるものではありません。一般的な配置は次のとおりです。

server-side middleware をroute handlerの前に置き、business logicが動く前にすべてのリクエストを評価する。
edge に置き、originに届く前にシグナルを評価する。
汎用HTTP integration として使い、どのstackでもrequest contextを送信し、basis付きの結果を受け取れるようにする。

integrationは、onboardingの間に各founding teamへ実地で提供されます。そのため、pathがあなたのarchitectureに合うようになっており、逆ではありません。developer hub では、現在利用できるintegration pathを確認できます。agent向けのtoolを運用している場合は、MCP Serversのユースケースに、tool callの具体的なパターンがまとめられています。

観測モードから始める

Proof of Actorを導入しても、APIの応答方法は変わりません。結果は記録されるだけなので、チームは既知の結果と照らし合わせ、agentが実際にどこへ向かっているのかを確認し、各routeのUnknown rateを測定し、誤っているように見える分類を見直せます。そのうえで初めて、証拠が支える範囲に限って、routeごとにポリシーを有効化します。

これが、顧客を驚かせたり、依存しているintegrationを壊したりせずに、AIエージェント識別を展開する方法です。アクターを意識したポリシーを安全に展開するガイドでは、その手順を1つずつ説明しています。

founding developer programに参加する

Proof of Actorは、少人数のfounding development teamとのprivate betaです。選定されたチームは、onboarding時に合意した利用上限の範囲で、最長12か月の無料利用に加え、当社エンジニアによる直接のintegration supportと、次に何を作るかへの実質的な影響力を得られます。

APIを運用していて、実際に誰が呼び出しているのかを知りたいなら、早期アクセスに申し込んでください。あなたのAPI、最も重要なroute、そしてアクターの文脈があれば変えたい判断について教えてください。Proof of Actorがどう適合するかをお伝えします。

Sources

RFC 9421: HTTP Message Signatures, IETF, February 2024.
Web Bot Auth (webbotauth) working group charter, IETF.

開発者向け

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を読む

よくある質問

AIエージェント識別は、APIキー認証とどう違いますか?

APIキーは、どのアカウントがリクエストを送ったかを示します。AIエージェント識別は、そのリクエストの背後にどの種類のアクターがいたのか、そしてその結論を支える証拠は何かを示します。どちらも必要で、答える問いは異なります。

Proof of Actorは、APIを呼び出すすべてのAIエージェントを識別できますか?

Proof of Actorは、見えているすべてのリクエストをHuman、Human + AI、Agent、Unknownのいずれかに分類し、その結果の根拠を示します。証拠が十分でない場合、推測はせず、結果はUnknownになります。

アクターを識別したら、そのアクターは行動を許可されたことになりますか?

いいえ。識別と認可は別です。Proof of Actorは呼び出し元に関する文脈をアプリケーションに渡し、何を許可するかはあなたの認可ルールが決めます。

Proof of Actorは、APIへのリクエストをブロックしますか?

あなたがそうする必要があると決めない限り、ブロックしません。すべての統合は観測モードから始まり、実際の enforcement はチームが記述して有効化したポリシーを通じてのみ行われます。

どうすれば利用できますか?

Proof of Actorはprivate betaです。早期アクセスに申し込み、選定された創業開発チームは、合意した利用上限の範囲で最長12か月無料で利用できます。

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

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

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

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