第2回から第5回まで、四つの段を登ってきた。見る、問い合わせる、操作する、取引する。段を登るたびに、エージェントへ渡す権限が一段ずつ大きくなった。
今回は、登らない。梯子から一歩引いて、すべての段を縦に貫いているものを見る。
各回の末尾に置いてきた「確かめること」を、四回ぶん並べ直してみると、気づくことがある。層ごとに言葉は違うのに、問いは二種類に畳める。
一つ ―― それは正しい根拠に基づいているか。記述された意味は実態と一致しているか（第2回）。答えは、指定した一次情報から引かれているか（第3回）。契約は挙動に忠実か（第4回）。取引は委任状に書いた条件の内側か（第5回）。
もう一つ ―― それは意図した権限の範囲か。答えるべきでないものに答えていないか（第3回）。露出は意図した操作集合と一致しているか（第4回）。委任は意図より広くないか（第5回）。
何を信じるか。どこまで許すか。柱は、この二本だ。層ごとの実装は毎年変わり、プロトコルの地図は5か月で描き換わる。だがこの二本の柱は、どの段でも同じ形で立っている。今回はこれを正面から扱い、あわせて第3回と第4回で残した宿題 ―― エージェントはそもそも、どうやってあなたのサイトの能力を見つけるのか ―― に、届いたばかりの答えの草案を当てる。
柱その一 何を信じるか ― 根拠の設計
答えがずれるのは、嘘をつくからではない
AIの間違いは「幻覚」という言葉で語られることが多い。何もないところから事実を作文する失敗だ。だが実務で出会う失敗の多くは、もっと地味な顔をしている。AIは、何かを根拠に答えている。その根拠が、こちらの意図とずれている ―― 古いコピー、第三者の不正確な記述、混ざり込んだ下書き。答えは流暢で、自信に満ちていて、そしてずれている。
RAG（Retrieval-Augmented Generation）は、この根拠を設計の対象にする仕組みだ。仕掛けは単純で、生成の前に検索を挟む。問いが来たら、まず指定した資料群から関連する箇所を引き、それを根拠として答えを組み立てさせる。モデルが世界一般について覚えていることではなく、こちらが指した資料で答えさせる ―― 根拠の所在を、モデルの内側という管理できない場所から、資料群という管理できる場所へ移す技術だと言っていい。
第3回で立てた窓口は、まさにこの構造をしていた。NLWebは、LLMの一般知識ではなく、あなたが索引化した内容から答えを引く。そして根拠の設計は、あの層だけの話ではない。第2回の構造化データは、根拠に使われる材料そのものだ。第4回では、エージェントがツールの説明文（description）を根拠に「いつ・どう使うか」を判断していた。第5回では、署名済みの委任状が取引の正当性の根拠だった。答えの根拠、行動の根拠、取引の根拠 ―― 貫いているのは、AIは渡されたものを信じて動くという一つの性質だ。
だから、渡すものがずれれば、すべてがずれる。そして根拠のずれは、エラーを出さない。索引に古い版が残っていても警告は鳴らず、第三者の誤情報を掴んでいても答えの口調は変わらない。第4回で「契約と挙動の乖離は静かに意図と違う結果を残す」と書いたのと同じ型の、静かな失敗がここにもある。
使う側の設計 ― 何を根拠にするかを決める
自社がAI・エージェントを使う側に立つとき、根拠の設計は三つの決めごとに絞られる。
一次情報の指定。 どれを参照させるかを、列挙で決める。製品仕様はこの文書群、価格はこのデータベース、社内規程はこの版 ―― 「そのへんにあるもの全部」は指定ではない。そして指定と同じ重さで、何を入れないかを決める。下書き、廃止した旧版、外に出せない情報。第3回で「何を入れないかが範囲設計の半分」と書いたのは窓口の話だったが、これはあらゆる根拠設計に共通する半分だ。
鮮度の管理。 第3回の参照実装が「データはコピーせず生きたデータベースに直結せよ」と釘を刺していた理由が、ここで一般化する。コピーされた根拠は、元が直っても古いまま答え続ける。直結できないなら、更新の仕組みと、鮮度に責任を持つ人を決める。指定は、決めた日ではなく、古びた日に壊れる。
参照範囲の線引き。 外部の情報をどこまで許すか。Web検索を許したエージェントは、指定の外 ―― 誰かの誤情報や、悪意ある記述 ―― を掴みうる。閉じれば安全だが答えは狭くなり、開けば広がるがずれの入口も開く。どちらが正しいという話ではなく、用途ごとに線を引き、引いた線を文書にしておく話だ。
引かれる側の設計 ― あなたのサイトは、一次情報として引かれているか
根拠には、もう一つの側がある。よそのAIが、あなたの会社について答えるとき ―― その根拠は誰が用意したものか。
以前、主要企業について生成AIが何を根拠に語るかを実測した。自社の一次情報が引かれる会社と、第三者のまとめ記事や古い記述で語られる会社に、はっきり分かれる。前者になるための整備が、実はこの連載の前半だった。第2回の構造化データとllms.txtは、自社の情報を「引ける形」にする作業であり、第3回の窓口は「引きに来られる場所」を立てる作業だった。梯子の下二段は、機能の話である以前に、自社について語られるときの根拠を、自社の一次情報にするための投資だ。
一次情報は、あるだけでは引かれない。引かれる資格を整えたサイトから、順に選ばれていく。何をどこまで開示するかという逆側の線引きは、情報開示戦略で扱った。
柱その二 どこまで許すか ― 権限の設計
合鍵ではなく、委任状を
第4回で、意図より広い露出はそのまま脆弱性になると書いた。第5回で、意図より広い委任はそのまま事故になると書いた。二つは同じ原則の、層ごとの現れだ。一般形はこうなる ―― 意図より広い権限は、そのまま損害の上限になる。広すぎる権限は、平時には何も起こさない。だから気づかれない。事故のときにだけ、被害の広さとして姿を現す。
以前「エージェントは道具ではなく準社員だ」と書いた。準社員に合鍵を渡す会社はない。渡すのは、範囲と条件と期限を書いた委任状だ。この対比が、権限設計の骨格をそのまま与えてくれる。
実務に落とすと、三点セットになる。最小権限 ―― その仕事に要る分だけを渡す。原則は単純だが、運用は言うほど易しくない。確認境界 ―― 不可逆・高額・初回といった線を先に引き、その内側では人間の承認を必須にする。線の引き方自体が設計判断だ。記録 ―― 行使を後から再構成できる形で残す。これは次の二つの節で、それぞれ理由が立つ。
プロンプトインジェクション ― 塞げない入口は、権限で受ける
第4回のCheck欄で「正面は横断の回で扱う」と書いた。ここがその正面だ。
まず、なぜこの問題が消えないのかを構造から押さえる。従来のプログラムでは、命令（コード）とデータ（入力）は走る場所が分かれていた。入力欄に何を書き込まれても、それが勝手にコードとして実行されることはない ―― その分離を破る攻撃には、SQLインジェクションという名前が付き、対策が確立した。LLMには、この分離が原理的にない。命令もデータも、同じ一本の文字列の川を流れる。だから、データのふりをした命令 ―― ページに白い文字で書かれた指示、ツールの返り値に混ぜられた一文、問い合わせ本文の「これまでの指示は無視して」 ―― が命令として効いてしまう余地が、モデルがどれだけ賢くなっても残り続ける。英国のNCSCも2025年12月、この問題をSQLインジェクションの類推で考えるなと警告している ―― SQLにはパラメータ化という根本対策があったが、命令とデータの区別をそもそも持たないLLMでは、同じ形の根本対策は望めない可能性がある、と。
そして入口は、特定の層にあるのではない。全層にある。第2回の構造化データは、悪意あるサイトが指示を仕込む器になりうる。第3回の窓口は言葉で問いを受ける ―― 入口が言葉である以上、悪意ある言葉も入る。第4回では仕様自身が三方向を整理していた ―― 説明文に仕込むツール汚染、返り値に仕込む出力注入、そしてツール自体が攻撃の的になる場合。第5回では、エージェント同士が交わすメッセージそのものが入口になる。層ごとに入口を一つずつ塞ぐ対症療法は、いたちごっこにしかならない。
だから、設計の順序が決まる。入力の無害化は破られる前提で置き、出ていく側 ―― 権限 ―― で受け止める。 注入がどこかで成功しても、そのエージェントに渡っている権限が最小で、不可逆な操作に確認が挟まり、走った操作が記録されていれば、被害は委任状の内側で止まる。permission-firstは行儀のよい作法の話ではない。塞ぎきれない入口に対する、構造的に唯一まともな答えだ。境界をどこに引くかの各論は境界設計の稿で掘った。自サイトが攻撃の踏み台側に回る筋はこちらで扱っている。
記録 ― 事故は正規の顔でやってくる
第5回で書いた一文を、ここで柱に昇格させる。事故は不正アクセスの顔をしてこない。正しい手続きの顔をしてやってくる。
上限を書き忘れた委任状の内側で走った想定外の購入は、ログの上では署名済みの正規取引だ。露出しすぎたツールへの呼び出しは、システムから見れば正常なAPI利用だ。意図とのズレは、不正検知のアラートでは捕まらない ―― 意図はシステムの外にあるからだ。システムが知っているのは「何が起きたか」までで、「それを意図していたか」は、記録と意図を人が突き合わせて初めて分かる。
だから記録の要件は決まる。どのエージェントが、誰の委任で、何を根拠に、何を呼び、何が変わったか ―― 後から再構成できる形で残すこと。記録は事故を防がない。だが記録がなければ、ズレに気づく手段そのものが存在しない。公開・委任・失効を含めた体制全体の考え方は、ガバナンスは設計判断であるという稿にまとめてある。
二本の柱が交わる場所 ― 発見の層、ARD
目録の宿題に、答えの草案が来た
第3回で、窓口の呼び方は標準化されたが「見つけ方が後を追っている」と書いた。第4回でも、ツールの発見は同じ宿題だと書いた。エージェントはそもそも、どうやって「このサイトに窓口がある」「このドメインにツールがある」と知るのか ―― 梯子のどの段にも共通する、入口の手前の問題だ。
その答えの草案が出た。2026年6月17日、Google、Microsoft、GitHub、Hugging Faceなど11社が、ARD（Agentic Resource Discovery）の仕様草案を公開した。サイトが自分のドメインの /.well-known/ai-catalog.json に能力の目録 ―― MCPサーバー、A2Aエージェント、API、スキル ―― を置き、レジストリと呼ばれる検索サービスがそれを収集・索引し、エージェントは「これができる相手はどこか」と自然言語で問い合わせる。仕様はApache 2.0でGitHubに公開され、Linux Foundation傘下のAI Catalog Working Groupが定めたデータモデルの上に組まれている。版はv0.9、状態はProposal ―― 草案自体の日付は5月28日で、6月の発表で公になった。
共著者の名前に目を留めてほしい。Junjie Bu（Google）、Shaun Smith（Hugging Face）、そしてR.V. Guha（Microsoft）。第3回に出てきた名前だ。RSSを作り、Schema.orgを作り、NLWebを構想した人物が、今度は発見の層を書いている。名札（Schema.org）、窓口（NLWeb）、目録（ARD） ―― 「機械に読ませる自己記述」という一本の設計思想が、同じ人物の手で、三十年かけて層を積んでいる。
流れは四段 ― 後半の二段が、この回の主役
ARDの動き方は四段で書ける。公開 → 発見 → 検証 → 接続だ。
公開。運営者が自ドメインのwell-knownパスに目録を置く。目録の骨格は、仕様の版（specVersion）、運営者の情報（host）、資源の一覧（entries）、部門別の子目録への連結（collections）。静的なJSONファイル一枚で、置くこと自体は軽い。
発見。レジストリが目録をクロールして索引し、エージェントからの自然言語の問い合わせに、候補を順位付きで返す。既知の取引先が相手なら、レジストリを介さず相手のドメインから目録を直接取ってもいい。どちらの道でも、エージェントは使うツールを事前に組み込んでおく必要がなくなり、発見が実行時に移る。
検証。レジストリの応答には、発行者を確かめるためのメタデータが付く。仕様は署名や発行者証明を段階的に組み込む信頼レイヤーを持ち、本番用途では暗号的に発行者を検証してから繋ぐ流れを想定している。
接続。ARDの仕事はここで終わる。見つけた資源へは、その資源本来のプロトコル ―― MCP、A2A、通常のAPI ―― で繋ぐ。ARDは呼び方を置き換えない。見つけ方だけを標準化して、あとは退く。
なぜ発見の話を、横断の回で扱うのか。四段の後半二つが、そのまま二本の柱だからだ。
検証は「何を信じるか」の問いだ。 検索が返してきた目録は、エージェントの次の行動の根拠になる。偽の目録を立てて誘い込む攻撃は、第5回で見た偽Agent Cardの問題と同型で、だからA2AがSigned Agent Cardsで答えたのと同じ場所に、ARDも信頼レイヤーを組もうとしている。検証を欠いた発見は、見知らぬ相手を信じる作業を自動化するだけだ ―― 便利になるのは、攻撃者も同じである。
接続は「どこまで許すか」の問いだ。 見つけたことは、渡してよい理由にならない。発見はあくまで候補を挙げるところまでで、接続した先に何の権限を渡すかは、発見とは別の判断として、委任状の書式で書く。発見が実行時に移るほど、この分離は重要になる ―― 事前に人間が選んで組み込んだツールと違い、実行時に見つけた相手には、人間の目が一度も通っていないからだ。
発見は便利さの入口であり、二本の柱が最初に試される関所でもある。
現在地 ― 書くのは安い、頼るのはまだ早い
冷静に現在地を置く。草案はv0.9で、参照実装はHugging FaceのDiscover Tool ―― Hub上のスキルやMCPサーバーをARDの枠組みで検索できる形で動いている。一方で採用はこれからだ。発表直後（2026年6月18日）の第三者調査は、仕様に名を連ねた11社を含む主要39サイトを巡回して、ai-catalog.jsonを配信している例を一つも見つけられなかったと報告している（調査は継続的に再実施・更新されている）。仕様を書いた側も、まだ自分のドメインには置いていない ―― それが2026年7月の実態だ。
だから扱いは、第5回のAgent Cardと同じ言い方になる。置くコストは低い。静的なJSONファイル一枚で、自社のエージェント窓口を機械可読にしておくのと同じ系譜の素振りだ。だが置けば客が来る段階ではない。引きに来るレジストリの生態系が、まだ育っていない。素振りとして書く価値はあり、集客経路として頼るのはまだ早い。レジストリが立つか、検証の作法が固まるか、主要なエージェントがARDクライアントになるか ―― 観察を続ける項目が、また一つ増えた。
Do ― いま、何をするか
横断の層のDoは、特定のファイルを置くことでも、特定のAPIを叩くことでもない。運用の形を決めることだ。四つに絞る。
- 参照させる一次情報を指定し、文書にする。 何を参照させるかを列挙で書き、何を入れないかも書く。鮮度に責任を持つ人を決める。この文書がないまま各層を積むと、層ごとにばらばらの根拠が育つ。
- 権限は委任状の形式で書く。 範囲・条件・確認・記録 ―― 第5回で決済向けに置いた4点は、決済に限らない。ツールの公開（第4回）、索引への投入（第3回）、外部エージェントとの接続、すべてに同じ書式が効く。書かない項目は無制限と同義になる、という原則ごと持ち回る。
- 非常停止を、平時に用意する。 ツールの撤収（第4回のAbortSignal）、委任の失効、索引からの除外 ―― 各層の「止め方」を、インシデントの渦中ではなく今、手順として書いておく。あわせて、何かを新しく「開く」ときのレビューの通り道と、いま何が開いているかの台帳を持つ。開いたものを列挙できない状態は、権限の最小性を確かめようがない状態と同じだ。
- ai-catalog.jsonは監視リストへ。 いま書くなら素振りとして。頼るのはレジストリと検証の生態系が立ってから。四半期に一度、現在地を見直す程度の距離感でいい。
Check ― 確かめること（観点）
例によって、観点までを示す。合否の閾値・判定手順はここには書かない。横断の層で確かめる観点は三つ ―― そして気づかれると思うが、これは第2回から第5回までの各Check欄を、柱の側から言い直したものになっている。
根拠の意図適合。 AI・エージェントの答えと行動は、指定した一次情報に基づいているか。古いコピー、範囲外のデータ、外部の誤情報が根拠に紛れ込んでいないか。なぜ要るか：根拠のずれはエラーを出さないからだ。答えは流暢なまま、静かに実態から離れていく。ずれは答えの表面からは見えず、根拠まで遡って初めて分かる。
権限の最小性。 いま渡っている権限の集合は、意図した委任の集合と一致しているか。使い終えたまま残っている権限、誰も覚えていない公開ツール、期限のない委任が紛れていないか。なぜ要るか：意図より広い権限は、平時には何も起こさないからだ。事故のときにだけ、被害の上限として姿を現す。平時に見えないものは、意図して探しに行かない限り見つからない。
監査可能性。 エージェント経由の参照・操作・取引を、後から再構成できるか。どの主体が、誰の委任で、何を根拠に、何を実行したか。なぜ要るか：事故は正規の手続きの顔でやってくるからだ。意図とのズレは、システムのアラートではなく、記録と意図の突き合わせでしか見つからない。記録がなければ、突き合わせる相手がいない。
形式面 ―― ログが出力されているか、目録がスキーマに適合するか、署名が検証を通るか ―― は機械が確かめる領域で、道具はプロトコル側から無料で降りてくる。人間に残るのは、その一段上だ。記録と一次情報と権限を、自社の事業の意図と突き合わせる仕事。四つの層で繰り返してきた線引きが、横断の柱でも同じ場所に引かれる。
まとめ ― 層は順に積める。柱は最初から立てる
横断の層を一枚にまとめる。柱は二本 ―― 何を信じるか（根拠）と、どこまで許すか（権限）。根拠のずれは静かな失敗を生み、権限のはみ出しは損害の上限を広げる。どちらもエラーを出さず、正規の顔でやってくる。だから、一次情報の指定と委任状の書式と記録を、層の実装より先に運用として決めておく。そして二本の柱が最初に試される関所として、発見の層 ―― ARD ―― が草案として立ち上がった。書くのは安く、頼るのはまだ早い。
梯子の四つの段は、下から順に積めばいい。だがこの二本の柱は、順番の外にある。どの段から始めるにしても、最初の一段を置く日に、柱も一緒に立てる ―― 根拠を決め、委任状の書式を決め、記録を残す。後から柱を差し込むのは、建った家に基礎を入れるのと同じ苦労になる。
これで地図の部品は揃った。四つの層と、二本の柱、そして発見の入口。最終回は、これを時間軸に展開する ―― 何を今すぐやり、何を2026年後半に、何を2027年に回すか。投資判断としての優先順位を、一枚のロードマップにする。
参考情報
ARD：Announcing the Agentic Resource Discovery specification（Google Developers Blog, 2026-06-17） / ARD 仕様サイト（ai-catalog仕様を含む） / ards-project/ard-spec（GitHub） / Agentic Resource Discovery: Let agents search（Hugging Face, 2026-06）
プロンプトインジェクションの整理：WebMCP 仕様のセキュリティ考察（W3C Web Machine Learning Community Group ドラフト） / Prompt injection is not SQL injection (it may be worse)（英NCSC, 2025-12）
採用状況の第三者調査：Agentic Resource Discovery (ARD) & ai-catalog.json: The Complete Guide（Synscribe, 2026-06）
この記事をシェアする
