Web Bot Auth用Ed25519鍵生成ツールとHTTP署名スターターキット

従来のクローラーやAIエージェントは、User-Agent文字列やIPアドレスのホワイトリストによって識別されてきました。しかし、これらの情報は容易に偽装可能であり、悪意のあるボットが正当なボットを装う問題が後を絶ちません。Web Bot Authは、HTTP Message Signatures（RFC 9421）のドラフトに基づき、ボットが各リクエストに対して暗号学的な署名を行うことで、この問題を解決します。

ボットはEd25519などのアルゴリズムを用いてリクエストに署名し、ホスト側はボットが公開している公開鍵ディレクトリに対して検証を行います。これにより、User-Agentの偽装やIPアドレスの動的な変更に関わらず、ボットの正当性を数学的に証明できます。Web Bot Auth鍵生成ツールを用いれば、ブラウザ上で安全に鍵ペアを生成し、必要な設定ファイルを即座に取得できます。

注意点として、Web Bot AuthおよびHTTP Message Signaturesは、現在もIETFのInternet-Drafts段階にあります。本番環境への導入にあたっては、最新の仕様変更を追跡する必要があります。暗号学的な証明は、従来のシグナルに比べて圧倒的に堅牢であり、AIエージェントの運営者にとって必須の技術となりつつあります。

Web Bot Auth鍵生成ツールは、単なる鍵生成にとどまらず、導入に必要なすべての要素をワンクリックで提供するスターターキットです。ツールに入力したオリジンとターゲットホストに基づき、以下の出力カードが生成されます。

• 鍵ID: RFC 8037およびRFC 7638に基づくJWKサムプリントです。SHA-256ハッシュをbase64urlエンコードしたもので、すべての署名でkeyidとして使用されます。
• 鍵ディレクトリJSON: 公開鍵のみを含むJSON形式のデータです。オプションでnbf（有効開始日時）やexp（有効期限）を含めることができます。
• ディレクトリレスポンスヘッダー: 24 時間の有効期限を持つサンプル署名を含むHTTPヘッダーです。
• 秘密鍵と公開鍵: 秘密鍵はJWKおよびPKCS#8 PEM形式、公開鍵はSPKI PEM形式で出力されます。
• 署名付きリクエスト例: @authorityとsignature-agentを対象とし、web-bot-authタグを持つcurlコマンドとヘッダーの例です。署名は5 分で有効期限が切れます。

これらの出力は、カスタム署名機能の実装時におけるデバッグ用リファレンスとしても機能します。

生成された公開鍵は、特定のWell-knownパスに配置してホスト側が取得できるようにする必要があります。ディレクトリは/.well-known/http-message-signatures-directoryに配置し、適切なメディアタイプで配信します。

重要なのは、ディレクトリレスポンス自体もHTTP Message Signaturesによって署名されなければならないという点です。本番環境では、このレスポンスを毎回動的に生成し、新鮮な署名を付与する必要があります。静的なファイルとして配置し、署名が期限切れにならないよう注意してください。

鍵の有効期間（nbfやexp）を設定する場合、鍵のローテーション戦略が不可欠です。有効期限を短く設定すればセキュリティは向上しますが、運用の負荷が増加します。有効期限を設定しない場合、鍵の漏洩リスクが長期間にわたって持続します。組織のセキュリティポリシーと運用リソースのバランスを取り、適切なローテーションサイクルを設計してください。

HTTP Message Signatures（RFC 9421）では、リクエストの特定のコンポーネントを対象として署名を計算します。Web Bot Authでは、主に@authority（ホスト名とポート）やsignature-agentなどのヘッダーがカバーされます。

署名プロセスは、署名ベース（Signature Base）と呼ばれる文字列を構築することから始まります。署名ベースは、対象コンポーネントの値と、Signature-Inputヘッダーのパラメータを組み合わせて行ごとに構築されます。Signature-Inputには、created（作成日時）、expires（有効期限）、keyid（鍵ID）、alg（アルゴリズム）、nonce（ナンス）、tag（タグ）などのパラメータが含まれます。

署名が拒否される最も一般的な原因は、署名ベースの不一致です。改行コードやスペース、ヘッダーの順序がバイト単位で一致していないと、検証に失敗します。Web Bot Auth鍵生成ツールが出力する署名ベースの例を参照し、自身の署名実装が正確な文字列を生成しているかを確認してください。

Web Bot Auth鍵生成ツールの最も重要な特徴は、プライバシーとセキュリティの設計にあります。鍵ペアはブラウザのWeb Crypto APIを用いてユーザーのデバイス上で生成され、秘密鍵が外部サーバーに送信されることは決してありません。

ページをリロードすると、生成された鍵はメモリから完全に消失します。これは、秘密鍵が意図せずログやネットワーク上に漏洩するリスクを排除するための設計です。生成直後にJWKまたはPEM形式で秘密鍵をダウンロードし、シークレットマネージャーに安全に保存してください。

JWK形式の秘密鍵には、秘密の値を表すdパラメータが含まれています。このパラメータを誤って公開鍵ディレクトリやログに出力しないよう細心の注意を払う必要があります。公開鍵ディレクトリには、公開パラメータのみを含むJSONを配置してください。サーバーサイドのジェネレーターにシークレットを貼り付けるような運用は避け、常にローカルで鍵を管理する習慣を徹底してください。

Web Bot Authによる署名は、ボットの身元を暗号学的に証明するものであり、そのボットがどのリソースにアクセスできるかを制御するものではありません。アクセス許可の制御は、従来のボット制御メカニズムと組み合わせて行う必要があります。

ボットがクロールしてよいパスや除外すべきパスは、robots.txtによって定義します。robots.txtの生成や、既存のルールの検証にはrobots.txtテスターを活用し、意図しないアクセスを防いでください。

また、AIエージェントに対して特定のコンテンツやメタデータを提供したい場合は、llms.txtの活用が有効です。身元証明（Web Bot Auth）、アクセス制御（robots.txt）、コンテンツ提供（llms.txt）の3つを適切に組み合わせることで、ホスト側とボット側の双方にとって安全で効率的な通信環境を構築できます。JWTなどのトークンベースの認証と混同しないよう、HTTPレベルの署名とリソースレベルの制御の役割を明確に区別してください。