RSL（Really Simple Licensing）のCAP（Crawler Authorization Protocol）は、「robots.txtのお願い」ではなく、HTTP認証の仕組みを使ってクローラーに「許諾トークン（License Token）」の提示を求める設計です。この記事では、CAPの前提、ライセンス発見からトークン取得（OLP /token）・提示（Authorization: License）・エラー処理（WWW-Authenticate）まで、実装の要点を最短距離で整理します。 CAPは、RSLでライセンス管理されるページにアクセスするクローラーに対し、HTTPの 押さえるべき結論 実装は「どのリソースがRSL対象か」を機械的に発見できないと始まりません。代表的には、RSLのCrawler Authorization Protocol(CAP)入門：許諾トークン実装
CAPの全体像
Authorizationヘッダーで「Licenseスキーム」を用いたトークン提示を求めるプロトコルです。RSLのガイドでは、Authorization: License <license_token>の形で提示し、成功時は200 OKでコンテンツを返す、とされています。
Authorization: License <token>でアクセスする401または402を返し、WWW-Authenticate: License ...で理由を返す/tokenで取得し、必要なら/introspectで検証する前提：RSLの発見
robots.txtにLicense:行でライセンスXMLのURLを載せ、クローラーがそこからRSL文書を取得します。RSLは、robots.txt・HTTPヘッダー・HTML linkなど既存の発見機構と統合する方針です。robots.txtの最小例
User-Agent: *
Allow: /
License: https://example.com/license.xmlなおAI利用条件の表明（例：train-aiの可否）だけならIETF AI Preferencesでも表現できますが、RSLは「許諾取得や補償ルール」まで機械可読にする点が役割です。
クローラー側実装
1) ライセンスURL取得
典型フローは以下です。
robots.txtを取得し、License:でRSLライセンスXMLのURLを見つける- RSLライセンスXMLを取得し、対象URL（またはURL範囲）と、必要なら
server（License Server）を特定する - 必要な利用目的（usage）や支払い条件に合わせて、OLPでトークンを取得する
2) OLPでトークン取得
RSLでは、ライセンスサーバーに対しOAuth 2.0のtokenエンドポイントを使ってライセンストークンを取得します（OLP）。仕様では、リクエストはapplication/x-www-form-urlencodedで行い、resourceに取得対象URL、licenseに要求する<license>要素（URLエンコード済み）を渡します。レスポンスのtoken_typeはlicenseになります。
注意
実装で混乱しやすいのは、CAP側のAuthorization: License ...（サイトへのアクセス）と、OLP側のクライアント認証（ライセンスサーバーへのアクセス）が別物な点です。OLPはOAuth 2.0のクライアント認証（client_id/client_secret等）を前提にします。
トークン取得の例
# 例: /token へライセンス取得（値は例示）
LICENSE_XML='<license xmlns="https://rslstandard.org/rsl"><permits type="usage">all</permits></license>'
ENC_LICENSE=$(python -c 'import urllib.parse,sys; print(urllib.parse.quote(sys.argv[1]))' "$LICENSE_XML")
curl -sS -X POST "https://api.example.com/token" \
-u "${CLIENT_ID}:${CLIENT_SECRET}" \
-H "Content-Type: application/x-www-form-urlencoded" \
--data "grant_type=client_credentials" \
--data "resource=https%3A%2F%2Fexample.com%2F" \
--data "license=${ENC_LICENSE}" | jq
3) CAPでトークン提示
取得したライセンストークンは、対象サイトへアクセスする際にAuthorizationヘッダーへ載せます。
GET /data HTTP/1.1
Host: example.com
User-Agent: YourCrawler/1.0
Authorization: License <license_token>成功時は200 OKに加えて、サーバーが「適用されるライセンス」へのLinkヘッダーを返すことが求められます。
4) 失敗時のリトライ
CAPでは、未提示や無効の場合に401 Unauthorizedまたは402 Payment Requiredが返り、WWW-Authenticate: License ...にエラー情報が入ります。クローラーはこれを見て、ライセンスURLへ遷移→トークン取得/更新→再試行、という実装にすると堅牢です。
サイト側実装
判定ポイント
サイト側（リソースサーバー）が行うべきことはシンプルです。
- 保護対象URLかどうかを判定（RSLで宣言した範囲か）
AuthorizationヘッダーがLicenseスキームかを判定- トークンが有効か、かつ当該
resourceへのアクセスが許可されているかを判定（必要に応じてOLPの/introspectで検証） - 結果に応じて
200/401/402/403を返し、CAPが求めるヘッダーを付与
ステータスの使い分け
| 状況 | 推奨ステータス | 必須/推奨ヘッダー |
|---|---|---|
| トークン未提示 | 401 | WWW-Authenticate: License + License参照（Linkまたは本文） |
| 支払いが必要 | 402 | WWW-Authenticate: License + License参照（Linkまたは本文） |
| トークンは有効だが範囲外 | 403 | WWW-Authenticate: License error=”insufficient_scope” + Link |
| 許可 | 200 | Link: <…license.xml>; rel=”license”; type=”application/rsl+xml” |
401/402のレスポンス例
HTTP/1.1 401 Unauthorized
WWW-Authenticate: License error="invalid_request", error_description="Access to this resource requires a license"
Link: <https://example.com/license.xml>; rel="license"; type="application/rsl+xml"
Content-Type: text/plain; charset=UTF-8HTTP認証フレームワーク（RFC 7235）では、401とWWW-Authenticateで「次に何の認証方式で再試行すべきか」を伝え、クライアントがAuthorizationで資格情報を送って再試行する流れが基本です。CAPはこれに沿って設計されています。
/introspectでの検証
サイト側での実装が最も現実的なのは、受け取ったライセンストークンをライセンスサーバーの/introspectへ投げて、active（トークン有効性）とpermitted（当該resourceが許可されるか）で判定する方法です。
curl -sS -X POST "https://api.example.com/introspect" \
-u "${CLIENT_ID}:${CLIENT_SECRET}" \
-H "Content-Type: application/x-www-form-urlencoded" \
--data "token=${LICENSE_TOKEN}" \
--data "resource=https%3A%2F%2Fexample.com%2Fdata" | jq
実装の落とし穴
キャッシュと更新
トークンにはexpires_inがあり、無期限の場合は0になり得ます。運用では「クローラー側で期限管理」＋「サイト側は失効/取り消しもあり得る前提で/ intorspectを適宜使う」が安全です。
ライセンス参照の返却
CAPでは、失敗時でも「適用されるライセンスの参照（Linkヘッダー等）」を返すことが求められています。クローラーが自動的に取得条件へ到達できるため、相互運用性に直結します。
403の意味を揃える
CAPでは「トークンは有効だが条件不足（insufficient_scope）」のときに403を返す設計です。実装では、単にブロックしたいからといって何でも403に寄せると、クローラーが更新フローへ進めず、結果として「意図した課金・許諾導線」が壊れます。
最小構成まとめ
最後に、CAPの「許諾トークン実装」を最小構成でまとめます。
- 公開側：robots.txtでライセンスURLを公開し、保護対象では
Authorization: Licenseを要求。未提示/無効なら401（必要なら402）＋WWW-Authenticate＋Link rel="license"を返す。 - クローラー側：robots.txt→license.xmlを辿り、必要ならOLP
/tokenでトークン取得。以後はリクエストにAuthorization: License <token>を付与し、401/402時はWWW-Authenticateを見て更新する。
実装の近道
まずは「サイト側で/ intorspectに丸投げして判定」→「クローラー側でtoken取得と再試行」を作ると、仕様への追従（ドラフト更新）にも耐えやすくなります。
クローラー運用を改善しませんか？
RSL/CAP対応を含むクローラー設計や運用ルールの整備を支援します。要件整理から実装・検証まで一気通貫でご相談ください。
まとめ
RSLのCAPは、HTTP認証（RFC 7235）の枠組みでクローラーに許諾トークン提示を求めることで、robots.txtより強い「契約の入口」を提供します。実装は、（1）ライセンス発見、（2）OLPでトークン取得、（3）Authorization: Licenseで提示、（4）WWW-Authenticateを使ったエラー処理、の4点を押さえると迷いません。
参考リンク
