💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

はじめに — なぜいまエージェントウェブが話題なのか

2026年前半を通じて、Hacker NewsとGeekNewsの上位を交互に占めたテーマがあります。「AIエージェントが人間に代わってウェブサービスに登録し、ログインし、決済し、行動する世界を、私たちはどう設計すべきか」という問いです。

この2年、私たちはエージェントが「読む」段階を十分に経験してきました。検索し、文書を要約し、コードを書きました。ところが2026年に入って空気が変わりました。エージェントが「書く」段階、つまり外部サービスにアカウントを作り、フォームを埋め、サブスクを申し込み、APIキーを発行する作業を、ユーザーの代わりに行い始めたのです。

ここで根本的な摩擦が生じます。今日のウェブは徹底して「人間がブラウザでクリックする」という前提の上に建てられています。CAPTCHA、メール認証、規約同意のチェックボックス、携帯電話による本人確認。これらすべては反対側に人間がいることを前提とします。エージェントはこの前提を壊します。だから、ある者はエージェントを遮断しようとし、ある者はエージェントを正式な客として迎える標準を作ろうとします。

その標準論議の中心に登場したのが、auth.mdのような「ドメインルート規約」の提案です。WorkOSをはじめとする認証インフラ陣営から出てきたこのアイデアは、サイトが自らの認証ポリシーを機械が読める形でドメインルートに掲示しよう、というものです。ちょうどrobots.txtがクローラーに「ここは入っていいが、あそこは駄目だ」と知らせるように。

本稿では、エージェントウェブという潮流の正体を押さえ、auth.md提案をrobots.txtとsitemapの系譜の上で解釈します。次に、OAuthと委任トークンという既存の権限委任技術がこの絵にどう収まるのか、ボットの区別と悪用の懸念は何か、標準化の課題と設計時の考慮点は何かを順に整理します。

あらかじめ一つの視点を示すと、これらすべての論議の根底には単純な非対称性があります。エージェントは人間ではないのに、人間のために設計された関門を通過しなければならないという非対称性です。この非対称性を解消する方法は二つに一つです。エージェントをもっと人間らしくするか(偽装)、関門をエージェントも通過できるように設計し直すか(標準化)です。auth.mdは明らかに後者の道です。そして本稿の立場も、後者が長期的にはより健全だという側にあります。

エージェントウェブとは何か — 読むことから行動することへ

三段階のエージェント進化

エージェントがウェブと結ぶ関係は、おおよそ三段階に分けられます。

第1段階: 読む (Read)

- 検索、要約、情報抽出

- 副作用なし、冪等

- 例: 「このページを要約して」

第2段階: 相互作用 (Interact)

- フォーム入力、クリック、探索

- セッション内の一時的な状態変更

- 例: 「このフライトを検索して価格を比較して」

第3段階: 行動 (Act / Commit)

- 登録、決済、サブスク、投稿、削除

- 永続的で取り消しにくい変更

- 例: 「このサービスに登録して月額を申し込んで」

第1・第2段階はもう馴染みがあります。本当の問題は第3段階です。登録は一度起きればデータベースにユーザーレコードが生まれ、決済はお金が実際に出ていきます。この段階では「誰がこの行動を承認したのか」と「この行動の責任は誰にあるのか」が決定的に重要になります。

エージェント登録シナリオの現実

具体的なシナリオを思い描いてみましょう。ユーザーが自分の秘書エージェントにこう言います。「来月の出張で使うコラボツールを調べて、良ければ無料トライアルに登録して」。

エージェントは候補サービスを見つけ、登録ページに到達します。ところがそこで詰まります。

+------------------------------------------+

| 無料トライアルを開始 |

| |

| メール: [ ____________________ ] |

| パスワード: [ ____________________ ] |

| [ ] 14歳以上で規約に同意します |

| |

| [ 人間か確認: CAPTCHA ] |

| |

| [ 登録 ] |

+------------------------------------------+

ここでエージェントは四つの壁にぶつかります。

1. **メール認証**: 登録後に受信箱のリンクをクリックする必要があるなら、エージェントにその受信箱へのアクセス権はあるか。

2. **規約同意**: 規約に法的に同意する権限がエージェントにあるか。ユーザーが委任した権限の範囲はどこまでか。

3. **CAPTCHA**: 人間であることを証明せよという要求。エージェントは人間ではない。

4. **決済情報**: 有料転換時にカード情報を入力する権限があるか。

今日、多くのエージェントはこの壁を「人間のふりをして」越えようとします。ヘッドレスブラウザでピクセルをクリックし、CAPTCHA回避サービスを使い、ユーザーのメールパスワードを直接保管します。これこそが問題の核心です。明示的な標準がないからエージェントは人間を真似し、サイトはその真似を検知して遮断しようとし、双方とも軍拡競争に陥ります。

エージェントウェブ標準化論議の出発点は単純です。「エージェントが人間のふりをしなくてよい、正直な通路を作ろう」。

auth.md提案 — ドメインルート規約の発想

robots.txtとsitemapの系譜

auth.mdを理解するには、まずその祖先を見るべきです。ウェブには古くから「ドメインルートに約束されたファイルを置いて機械と対話する」というパターンがありました。

| ファイル | 登場時期 | 対象 | 役割 |

| --- | --- | --- | --- |

この系譜を見るとパターンは明白です。新しい機械的行為者が登場するたびに、ウェブはドメインルートにその行為者向けの案内文を追加してきました。クローラーにrobots.txt、検索エンジンにsitemap、研究者にsecurity.txtを与えたように、いまや認証エージェントにauth.mdを与えよう、というわけです。

auth.mdが盛り込めるもの

auth.mdの核心の発想は、「このサイトにエージェントがどう正当に認証し登録できるか」を機械が読める形で記述することです。まだ確定した標準ではないので、議論されている項目を概念的に整理すると、次のような形になり得ます。

https://example.com/auth.md (概念例 — 確定標準ではない)

Agent Sign-up Policy

Agents allowed: yes

Human-in-the-loop required: for-payment

Identity verification: oauth, did

Endpoints

Registration: https://example.com/.well-known/agent-register

Token endpoint: https://example.com/oauth/token

Scopes supported: read, create-account, subscribe

Terms

Terms URL: https://example.com/terms

Machine-readable terms: https://example.com/terms.json

Agent must present: delegation-token

Rate and Abuse

Max accounts per delegated principal: 1

Contact: agents@example.com

ここで核心は三つです。

1. **ポリシーの明示**: サイトがエージェント登録を許可するか、決済のような機微な行動に人間の関与を求めるかを、機械が読める形で宣言します。

2. **エンドポイントの案内**: エージェントが人間の真似ではなく呼び出すべき正式な登録エンドポイントとトークンエンドポイントを指し示します。

3. **規約の機械判読**: 規約を人間が読むHTMLだけでなく、機械がパースできる形でも提供し、エージェントが同意条件を理解し委任範囲を確認できるようにします。

なぜマークダウンなのか

名前がauth.mdである理由は、形式としてマークダウンを選んだからです。llms.txtがそうだったように、マークダウンは人間も読みやすく、LLMがパースしやすい。JSONやXMLより人間に優しく、エージェントのLLMコアが自然に解釈できるという折衷案です。ただし機械パースの厳密性のために、構造化ブロック(上記例のキー値)や別途のJSON補助ファイルを併用しようという意見もあります。

この形式論争自体が、エージェントウェブ標準化の特徴を示しています。一方の端には人間親和性(マークダウン、自然言語)があり、もう一方の端には機械の厳密性(JSONスキーマ、署名済みトークン)があります。エージェントはこの二つの間に存在するので、標準もその間のどこかに落ち着こうとします。

権限委任の技術 — OAuthと委任トークン

auth.mdが「ポリシー掲示板」なら、実際にエージェントへ権限を安全に渡す仕事はOAuth系の技術が担います。ここでの核心の問いはこれです。「ユーザーがエージェントに自分の代理権を与えつつ、その範囲をどう制限し追跡するか」。

OAuth委任モデルの再解釈

OAuth 2.0は元々「ユーザーが第三者アプリに自分のデータアクセスを委任する」ために作られました。エージェントウェブはこのモデルをもう一段押し進めます。委任を受ける主体が、人間がインストールしたアプリではなく、人間に代わって自律的に行動するエージェントである点が異なります。

伝統的OAuthとエージェント委任の違いを整理すると次のようになります。

| 側面 | 伝統的OAuthアプリ | 自律エージェント |

| --- | --- | --- |

| 委任主体 | ユーザーが明示的にインストール/承認したアプリ | ユーザーの自然言語指示で動的に生成 |

| 行動予測性 | アプリの機能範囲内で固定 | LLM推論により可変 |

| 権限範囲 | インストール時点でスコープ確定 | 作業ごとに必要なスコープが変わる |

| 責任追跡 | アプリ単位 | エージェント-作業-委任者のチェーン単位 |

この違いのため、エージェント委任ではスコープをより細かく刻み、トークンの寿命を短くし、委任チェーンを明確に記録することがより重要になります。

委任トークンの構造

エージェントがサイトに「私はこのユーザーの委任を受けて登録しようとしている」と証明するには、委任の事実を含むトークンが必要です。概念的に委任トークンは次のような主張を含みます。

{

"iss": "https://agent-platform.example",

"sub": "agent-instance-7f3a",

"act": {

"sub": "user:alice@personal.example",

"delegation_id": "del-2026-06-25-abc"

"aud": "https://example.com",

"scope": "create-account subscribe:trial",

"constraints": {

"max_monthly_spend": "0",

"human_approval_for": ["payment", "data-deletion"]

"exp": 1782000000,

"iat": 1781996400

}

ここでactクレームが核心です。これはOAuthトークン交換標準(RFC 8693)に定義された「actor」概念で、「このトークンを持って行動する主体(エージェント)が、実際には別の主体(ユーザー)を代理している」という委任関係を表現します。つまり「エージェント7f3aがユーザーaliceに代わって行動中」という事実がトークン自体に刻まれています。

constraintsブロックは委任の限界を釘付けにします。月の支出上限を0に置き、決済やデータ削除のような危険な行動には人間の承認を求めます。サイトはこのトークンを検証することで、人間の真似を検知する軍拡競争ではなく「正直に宣言された委任」を受け入れられます。

トークン交換と委任チェーン

実際の流れでは、トークンが複数段階で交換されます。ユーザーがエージェントプラットフォームにログインし、プラットフォームが特定作業のための狭い委任トークンを発行し、エージェントが対象サイトのトークンエンドポイントでそれを交換する、という具合です。

ユーザー(Alice)

| 1. 自然言語指示 + 本人認証

エージェントプラットフォーム

| 2. 作業別委任トークン発行 (狭いスコープ、短い寿命)

エージェントインスタンス

| 3. 対象サイトのトークンエンドポイントで交換 (RFC 8693)

対象サイト(example.com)

| 4. 委任トークン検証 -> 登録を許可または拒否

ユーザーレコード生成 (委任者=Alice、行為者=エージェント)

このチェーンが明確なら、後で「誰がこのアカウントを作ったのか」を追跡できます。アカウントレコードに「委任者はAlice、実際の登録を行った行為者はエージェントインスタンス7f3a、委任IDはdel-2026-06-25-abc」が残るからです。これが責任追跡の土台になります。

ボットの区別と悪用の懸念 — 正直なエージェントと悪性ボット

良いボットと悪いボットをどう分けるか

エージェントウェブの最大の難題は、「正直に宣言したエージェント」と「人間のふりをする悪性ボット」を区別することです。auth.mdと委任トークンは正直なエージェントに正門を開きますが、悪性ボットは依然として裏口から入ろうとします。

+---------------------------+

| エージェントの4象限 |

+-------------+-------------+

| 正直 + 宣言 | 正直だが |

| (auth.md | 未宣言 |

| 遵守) | (ただのボット) |

+-------------+-------------+

| 悪意 + 偽装 | 悪意 + 宣言 |

| (スパム/詐欺,| 違反 |

| CAPTCHA | (宣言後 |

| 回避) | 規約違反) |

+-------------+-------------+

理想の世界では、すべてのエージェントが左上、つまり正直に宣言して正門から入ります。しかし現実には四象限が全部存在します。標準の目標は、正直なエージェントの正門通過をあまりにも簡単で魅力的にして、偽装の誘因を減らすことです。正門が裏口より楽なら、わざわざ偽装する理由がなくなります。

検証可能なエージェント身元

正直な宣言だけでは不十分です。「私は正直なエージェントです」とは誰でも言えるからです。だから検証可能な身元が必要です。これにはいくつかのアプローチがあります。

1. **プラットフォーム証明(attestation)**: 信頼されるエージェントプラットフォームが自分のエージェントに署名します。サイトはそのプラットフォームの公開鍵で署名を検証します。

2. **分散身元(DID)**: エージェントが分散識別子と検証可能な資格情報を提示します。特定プラットフォームに依存しない方式です。

3. **mTLSとクライアント証明書**: エージェントが相互TLSで自分を認証します。企業間通信で馴染みのある方式です。

核心は「エージェントが誰の委任を受け、どのプラットフォームがそのエージェントを保証するか」を暗号学的に検証できなければならない点です。検証可能な身元があってこそ、サイトは悪用時に責任を追跡し信頼を撤回できます。

悪用シナリオと防御

エージェントウェブが開きうる悪用シナリオを率直に押さえてみましょう。

| 悪用 | メカニズム | 防御 |

| --- | --- | --- |

| 大量アカウント作成 | ボットが一人の委任で数千アカウント作成 | 委任者あたりアカウント上限(auth.md明示)、委任ID追跡 |

| 無料トライアル乱用 | エージェントがトライアルだけ繰り返し登録 | 委任者単位の重複検知、決済の人間承認強制 |

| 規約の迂回同意 | エージェントが読まずに無条件同意 | 機械判読規約 + 委任範囲明示、同意責任を委任者に帰属 |

| 自動スパム/投稿 | エージェントがコンテンツ大量生成 | 投稿スコープ分離、レートリミット、行為者追跡 |

| ソーシャルエンジニアリング | エージェントが他ユーザーになりすまし | 検証可能身元の強制、なりすまし不可 |

防御の共通原理は「匿名の人間の真似」を「追跡可能な宣言された委任」に変えることです。匿名ボットは遮断しにくいですが、委任IDと検証可能な身元がついたエージェントは、悪用時にその委任者とプラットフォームまで遡れます。

同意と責任 — エージェントは規約に同意できるか

委任の法的な重さ

技術問題を超えて、エージェントウェブには厄介な同意問題があります。エージェントがユーザーに代わって規約の「同意」ボタンを押すとき、その同意は法的に有効か。ユーザーが「適当に登録して」と一言言っただけなのに、それが50ページの規約への有効な同意になるのか。

この問題は委任の範囲と明確さにかかっています。委任トークンのscopeとconstraintsが「このエージェントは無料トライアル登録のみ、決済は人間承認」のように明確であるほど、その範囲内の行動への同意は委任者に帰属すると見やすくなります。逆に範囲が曖昧な「全権委任」は紛争の種になります。

人間の関与が必要な地点

そこで多くの設計が「人間の関与(human-in-the-loop)」を特定の行動に強制します。上のトークン例のhuman_approval_forフィールドがそれです。一般に次の行動は人間の明示的確認を求めるのが安全です。

自動委任OK 人間確認が必要

--------------- ---------------

- 情報照会 - 決済/サブスク確定

- 無料登録 - 個人情報の第三者提供同意

- フォーム一時保存 - データの永久削除

- 比較/推薦 - 法的拘束力ある契約締結

- 読み取り専用API - 評判に影響する公開投稿

この境界線は固定ではなく、委任者の信頼レベルと行動の取り消し不能性に応じて調整されます。核心原則は「取り消しにくく影響が大きい行動ほど、人間の指が実際にボタンを押すべき」というものです。

実務適用 — サイトとエージェント双方の設計

サイト運営者のためのチェックリスト

あなたがサービスを運営するなら、エージェントウェブに備えて次を点検できます。

[ ポリシー掲示 ]

[ ] エージェント登録を許可/条件付き許可/禁止のどれにするか決めたか?

[ ] auth.mdのような機械判読ポリシーを掲示する計画があるか?

[ ] 規約を機械判読形式でも提供できるか?

[ 正門を作る ]

[ ] 人間の真似ではなく呼び出す正式な登録/トークンエンドポイントがあるか?

[ ] 委任トークン(RFC 8693 actorクレーム)を検証できるか?

[ ] 委任者あたりアカウント上限、レートリミットを定義したか?

[ 追跡と責任 ]

[ ] アカウントレコードに委任者と行為者を分離記録するか?

[ ] 悪用時に委任IDで追跡し信頼を撤回できるか?

[ ] 機微な行動に人間承認を強制するゲートがあるか?

興味深いのは、エージェントを歓迎するにせよ遮断するにせよ、auth.mdのようなポリシー明示は双方に有用だという点です。遮断したいサイトは「エージェント登録禁止」を明示でき、歓迎したいサイトは正門を案内できます。robots.txtがクロールを許可するサイトと禁止するサイトの双方に役立ったのと同じ理屈です。

エージェント開発者のための原則

逆にエージェントを作るなら、次の原則を勧めます。

1. **正直に宣言せよ**: User-Agentと委任トークンで「私はエージェントであり、誰の委任を受けた」を明示せよ。人間の真似は短期の利益、長期の負債だ。

2. **auth.mdをまず読め**: robots.txtを尊重するように、サイトの認証ポリシーをまず確認し正門から入れ。

3. **スコープを最小化せよ**: 作業に必要な最小権限のみ要求せよ。全権委任は危険で拒否されやすい。

4. **人間を適切に呼べ**: 決済のような危険な地点では委任範囲を超えず、ユーザーに確認を求めよ。

段階的な採用経路

これらすべてが一度に標準化されるわけではありません。現実的な採用経路は段階的です。

いま (2026):

- 一部サイトがllms.txt/実験的auth.mdを掲示

- 主要エージェントプラットフォームが委任トークンを試験導入

- RFC 8693トークン交換はすでに成熟

次の段階:

- well-knownパス標準化の試み (IETF/W3C論議)

- 機械判読規約フォーマットの合意

- 検証可能なエージェント身元エコシステムの形成

成熟期:

- 正門通過が裏口より簡単になる

- 人間の真似による軍拡競争の誘因が減少

いまの段階で個人開発者にできる最も実用的なことは、すでに成熟したOAuthトークン交換とスコープ設計をきちんと身につけておくことです。auth.mdがどんな形で標準化されようと、その下で権限を安全に委任する仕事は結局OAuth系の技術が担うからです。

よくある質問

**Q1. auth.mdはrobots.txtのように強制力がありますか?**

ありません。robots.txtと同様、auth.mdも自律的な規約です。強制力は標準そのものではなく、検証可能な身元とトークン検証から生まれます。サイトが委任トークンを実際に検証し、正門の通過を正直なエージェントだけに許可するなら、それが事実上の強制力になります。auth.mdは「ここから入りなさい」という案内文であり、強制はその正門で起こります。

**Q2. CAPTCHAはもうなくなりますか?**

当面はなくなりません。auth.mdと委任トークンは正直なエージェントのための正門であって、悪性ボットを防ぐ道具を代替するものではありません。むしろ正門ができれば、CAPTCHAは「宣言していないトラフィック」だけに集中できるようになります。正直なエージェントはトークンで通過し、正体不明のトラフィックだけがCAPTCHAに出会う、という具合に役割が分担されます。

**Q3. 小さなサイトもこれを実装すべきですか?**

すぐにはその必要はありません。ほとんどの小さなサイトは標準が成熟するまで待ってかまいません。ただし、エージェント登録を明示的に禁止したいなら、その意思を表示する手段が生まれるという点は知っておく価値があります。歓迎であれ拒否であれ、明示的な宣言は双方にとって有益です。

**Q4. 委任トークンと一般的なOAuthアクセストークンの違いは?**

核心的な違いはact(actor)クレームです。一般的なアクセストークンは「このトークンの主体が行動する」としか言いませんが、委任トークンは「主体(エージェント)が別の主体(ユーザー)に代わって行動する」という委任関係を明示します。これによって責任追跡が可能になります。

**Q5. エージェントが人間より信頼される逆説はあり得ますか?**

興味深いことに、あり得ます。検証可能な身元と明示的な委任範囲を持つエージェントは、匿名で登録する人間よりもむしろ追跡可能で責任が明確になり得ます。正直に宣言されたエージェントが、匿名の人間よりも「一級市民」に近づく未来も想像できます。

落とし穴と批判的視点

バランスのために、エージェントウェブとauth.md提案への懐疑論も整理します。

1. **「また標準が一つ増えるだけ」批判**: ドメインルートにファイルをまた追加することが本当に問題を解くのか。robots.txtは強制力がなく悪性クローラーは無視する。auth.mdも正直なエージェントだけが従い、悪性ボットは依然として人間の真似をする。つまり標準は正直な側のコストだけ増やし、悪性側は止められないかもしれない。

2. **検証インフラの不在**: 委任トークンと検証可能身元が機能するには、誰が信頼される発行者かについての合意とインフラが必要だ。この信頼アンカー問題はまだ解けていない。少数のビッグテックプラットフォームだけが信頼されれば中央集権の懸念が生じる。

3. **同意の形骸化**: エージェントが規約に自動同意する慣行が固まれば、ただでさえ誰も読まない規約がさらに形式化する。機械判読規約がむしろ「エージェントが勝手に同意したからよし」という言い逃れの手段になる危険がある。

4. **中央集権とゲートキーピング**: サイトが「検証されたプラットフォームのエージェントのみ許可」し始めると、少数の巨大エージェントプラットフォームがウェブの新たな関門になる。これはオープンウェブの精神と衝突しうる。

5. **時期尚早論**: まだエージェントが人間に代わって登録することが普遍的でもないのに標準から作るのは過剰反応だという見方。逆に、robots.txtがそうだったように、事実上の慣行が定着する前に標準を論じてこそ断片化を防げるという反論もある。

6. **フォーマット乱立の危険**: すでにllms.txt、security.txt、ads.txtなど、ドメインルートのファイルが増え続けている。auth.mdがまた一つ加われば、サイト運営者は管理するファイルが増え、一貫性を保ちにくくなる。一つの統合されたwell-knownメタデータに収束すべきだという意見と、用途別に分離する方がよいという意見に分かれる。

これらの批判は大半が妥当です。とくに1番、「標準は正直な側だけが従う」という指摘は、robots.txtの歴史が証明した弱点です。ただし反論もあります。auth.mdの本当の価値は悪性ボットを止めることではなく、正直なエージェントの正門をあまりにも便利にして多数を正門に誘導することにあるというものです。軍拡競争を終わらせはしなくても、正直な行動のコストを下げてエコシステムの重心を移すことはできる、という論理です。

おわりに — 人間の真似を終わらせる標準へ

エージェントウェブの核心の問題は技術ではなく、正直さのインセンティブです。今日エージェントが人間の真似をする理由は、正直に「私はエージェントです」と言える正門がないからです。auth.mdと委任トークンの本当の目標は、その正門を作ることです。

ウェブの歴史は、新しい行為者が登場するたびにその者のための正直な通路を作ってきた歴史でもあります。クローラーにrobots.txtを、検索エンジンにsitemapを与えたように、いまやエージェントに正門を与える番です。その正門がrobots.txtのように不完全であっても、通路を作ろうとする試みそのものが、偽装と検知の悪循環から抜け出す第一歩です。

整理すると次のようになります。

1. ウェブは人間がクリックするという前提の上に建てられましたが、エージェントが「行動」段階に入ることでその前提が崩れています。

2. auth.mdはrobots.txtとsitemapの系譜を継ぐドメインルート規約で、サイトがエージェントに認証ポリシーを機械判読形式で知らせようという提案です。

3. 実際の権限委任はOAuthトークン交換(RFC 8693)のactorクレームと、狭いスコープ・短い寿命の委任トークンで実装できます。

4. 核心は「匿名の人間の真似」を「追跡可能な宣言された委任」に変え、悪用時に委任者とプラットフォームまで責任を遡れるようにすることです。

5. 批判も妥当です。標準は正直な側だけが従い、信頼アンカーは未解決で、中央集権の懸念があります。それでも正直な行動のコストを下げることには価値があります。

エージェントが人間に代わって行動する世界はすでに始まりました。問いは、その世界を真似と検知の軍拡競争で満たすのか、それとも正直な委任と追跡可能な責任の構造で満たすのか、です。auth.mdはその後者へ向かう小さな一歩です。そして、その一歩の方向を定めるのは標準文書ではなく、いまエージェントとサービスを作る私たちの設計判断です。

次にエージェントやサービスを設計するとき、一つだけ自問してみてください。「このシステムは、エージェントが正直に自らを明かすよう促すのか、それとも隠れることを強いるのか」。この小さな問いが集まって、エージェントウェブの性格を決めます。

参考資料

- [WorkOS Blog — The Agentic Web and authentication standards](https://workos.com/blog)

- [GeekNews — auth.mdとエージェントウェブ認証の議論](https://news.hada.io/)

- [Hacker News](https://news.ycombinator.com/)

- [RFC 8693 — OAuth 2.0 Token Exchange](https://datatracker.ietf.org/doc/html/rfc8693)

- [RFC 6749 — The OAuth 2.0 Authorization Framework](https://datatracker.ietf.org/doc/html/rfc6749)

- [robots.txt標準 (RFC 9309 — Robots Exclusion Protocol)](https://datatracker.ietf.org/doc/html/rfc9309)

- [security.txt (RFC 9116)](https://datatracker.ietf.org/doc/html/rfc9116)

- [llms.txt proposal](https://llmstxt.org/)

- [W3C Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/)

- [W3C Verifiable Credentials Data Model](https://www.w3.org/TR/vc-data-model/)