買い物やログインをするエージェントの用語と設計　名乗り方と鍵の渡し方

エージェントに外のサイトで買い物やログインをさせたい、という相談が増えている。ところが、作り始めるとすぐに二つの問いにぶつかる。エージェントは相手のサイトに自分をどう名乗るのか。そして、利用者のアカウントにどうやって入るのか。

この二つは別の話で、使う用語も違う。本稿では、名乗り方とログインの仕方に絞って、よく出てくる言葉と設計の考え方を整理する。Claude CodeやCodexで小さなエージェントを作る人が、最初に決めておくべきことは何だろうか。

名乗り方には三つの段階

一番軽い名乗り方は、User-Agentという欄に名前を書くことだ。User-Agentは、HTTPのリクエストごとに「どのソフトから来たか」を伝える欄である。手軽だが、誰でも同じ文字列を書けるので、それだけでは本物かどうか証明できない。

二段目は、決まったIPアドレスから通信し、その一覧を公開する方法だ。相手のサイトは、名乗りとIPの組み合わせで本物かどうかを確かめられる。逆引きDNSで確かめる方法もある。

三段目が、暗号の署名で身元を示す方法で、「Web Bot Auth」と呼ばれる。リクエストに署名を付け、サイトは公開された鍵でそれを確かめる。土台はHTTP Message Signaturesという仕組みだ。IETFに個人の草案として出されており、正式な標準にはまだなっていない。全体の設計を書いた草案は2026年3月の版で期限が切れ、手順を定める別の草案に引き継がれている。仕様はまだ動いている途中だと考えたほうがよい。

Cloudflareは、こうした名乗りを確かめた上で、乱暴な動きをしないボットやエージェントを「Verified bot」として登録している。同社の説明では、Web Bot Authの署名、公開したIP一覧と固定のUser-Agent、逆引きDNSのどれかで確実に名乗ることが条件の一つだ。もう一つの条件は、robots.txtの指示に従い、無理のない頻度でアクセスすることである。

Cloudflareは2026年7月1日から、署名付きのエージェントもVerifiedとして同じ枠で扱うようにした。登録は管理画面の申請から行い、申告した目的と実際の通信が食い違えば、許可の一覧から外されるという。

誰の代わりかを区別する

Cloudflareの分類で興味深いのは、動き方による区別だ。人の代わりにページを見に行くものを「Agent」、人の代わりに購入などの取引をするものを「Transact」と呼び分けている。

運営の形も二つに分ける。一つの運営者だけが動かすものは「Direct」、多くの利用者がそれぞれ指示を出すエージェントのサービスは「Intermediary（仲介）」だ。仲介の場合、サイトは運営会社を信頼できても、その裏の利用者一人ひとりまでは信頼できない。そこでCloudflareは、最終的な利用者の情報をForwardedという欄で渡す実験をしているという。

自分でエージェントを作って自分だけが使うならDirectに近い。受託で作って顧客の社員に使わせるなら、仲介に当たる。どちらかで、相手に渡すべき情報が変わる。仲介に当たるなら、どの利用者の指示で動いたかを自分の側で記録しておくことが、後で問い合わせを受けたときの備えになる。

ログインは鍵の渡し方

名乗りが「誰が来たか」の話なら、ログインは「誰の権限で動くか」の話だ。ここで大事になるのは、エージェントに利用者の鍵をどう渡すかである。

一番危ないのは、パスワードをそのままエージェントに渡すやり方だ。エージェントの文脈に入った文字列は、ログや会話の履歴に残りやすい。悪意のあるページに書かれた指示で、外へ漏れる恐れもある。

相手のサイトがOAuthに対応していれば、使える範囲と期限を絞った「アクセストークン」を発行して渡すのが基本になる。OAuthは、パスワードを渡さずに一部の権限だけを貸す仕組みだ。読むだけの権限と、注文する権限を分けられる。多くのサービスでは、トークンを利用者の側から取り消せる。だから、エージェントの調子がおかしいときに止める手段にもなる。

もう一つの手は、鍵をエージェントの外に置くことだ。たとえばPerplexityが公開したサンドボックス基盤SPACEの設計文書には、通信を中継する層で認証情報を差し込む機能が書かれている。エージェントは鍵を知らないまま、決められた行き先にだけ認証付きで通信できる。

人間のふりはさせない設計

最後に、設計で外せない原則を一つ挙げる。エージェントに人間のふりをさせないことだ。人間らしい速さでキーを打たせたり、CAPTCHAを解かせたりする作りは、相手のサイトから見ればなりすましに近い。

見つかれば、止められるのはエージェントだけでなく、利用者のアカウントかもしれない。名乗ったうえで断られたら、そのサイトでは使わないと決めておく。この線引きを最初に仕様へ書いておくと、後で迷わずに済む。

編集部の見方

名乗りとログインは、エージェントの機能というより「相手との約束」の設計だ。Web Bot Authはまだ草案だが、大手の配信網が名乗りの確かさで扱いを分け始めたことの意味は大きい。

小さく作る人がまずできるのは三つある。User-Agentに名前を入れる。パスワードを渡さずトークンか外部の鍵置き場を使う。CAPTCHAに当たったら人に戻す。この三つだけでも、止められにくく、事故を起こしにくいエージェントになる。