【AI×セキュリティ】AIエージェントはサイトをどう探しに来るか｜「ai-catalog.json や llms.txt は置くべき？」を解く

【AI×セキュリティ】AIエージェントはサイトをどう探しに来るか｜「ai-catalog.json や llms.txt は置くべき？」を解く AIセキュリティ

アクセスログを眺めていたら、置いた覚えのない /.well-known/ai-catalog.json や /llms.txt へのアクセスが残っていた——最近、そんな経験をしたサイト運営者もいるのではないでしょうか。その同じログには、.env.openai のような、AI の API キーを狙ったとしか思えないアクセスも混ざっています。

AI 向けの「案内」を用意する仕様や慣習は、ここ 1〜2 年で一気に増えました。置けば AI に見つけてもらいやすくなる一方で、書き方を誤ると「攻撃者向けの地図」にもなります。

この記事では、このブログ（クエビコ）のログに実際に残った探索を手がかりに、AI 向けの案内ファイルとセキュリティの勘所を整理します！

このブログに実際に来た「探索」

このブログは、しばらく閲覧できる相手を限って運用していました。2026年10月6日の昼に誰でも閲覧できる状態にしたので、その前後のログを読みました（送信元のアドレスなど個人を特定できる値は載せません）。

来たもの様子結果
ページの品質を測る検査ツールPC 用とスマホ用がそれぞれ /llms.txt → /robots.txt → /.well-known/ai-catalog.json の順に 1 回ずつ（計約 6 秒）llms.txt と robots.txt は 200、ai-catalog.json は 404（置いていない）
OpenAI のクローラー（GPTBot・OAI-SearchBot）まず robots.txt やサイトマップを取得閲覧を限っていた時期なので 403
WordPress の古い機能を探すアクセスwlwmanifest.xml を、/blog/・/wp/・/shop/ など 17 通りの場所で総当たり。xmlrpc.php も計 126 件・5 つの送信元。https への転送で止まり、続きは来なかった
設定ファイル .env を探すアクセス.env に .local・.production・.bak などを付けた名前や、/api/.env のような場所を総当たり計 216 件・5 つの送信元。すべて 403（うち 208 件は閲覧を限っていた時期。公開後の 8 件は WAF が遮断）

1 行目の検査ツールは、名乗り（User-Agent）に「Chrome-Lighthouse」を含み、送信元は Google のホスト名でした。Google が開発する検査ツール Lighthouse は、2026年9月公開の 13.5 版で AI エージェント向けの検査に ai-catalog.json の確認を加え、既存の llms.txt の確認と並べました。robots.txt も読むのは、ai-catalog.json の置き場所の指定（後述の Agentmap 行）を探すためです（Lighthouse v13.5.0 リリースノート）。

OpenAI のクローラーは名前だけなら誰でも名乗れるので、OpenAI が公開する送信元アドレスの一覧と照らし合わせました。今回のアクセスはすべて一覧の範囲内でした。

目を引いたのは最後の行です。公開後に来たある送信元は、.git/HEAD を見たあと、約 2 秒のうちに AWS 用の .env.aws.local と並べて .env.anthropic・.env.openai・.env.openai.local・.env.gpt・.env.llm・.env.ai を要求しました。AI サービスの API キーを置いていそうな名前を並べた探索です。これらはサイトの前に置いている WAF（Web アプリケーションファイアウォール）が、公開してはいけない種類のファイルへのアクセスとして 403 で止めました。そもそも、このブログにそうしたファイルはありません。

同じ日のログに、「AI 向けの案内を読みに来る検査ツール」と「AI の鍵を探しに来る探索」が並んでいたわけです。

AI向けの「案内」は大きく3種類

サイトが AI に向けて出す案内は、目的で分けると次の 3 つです。

案内置き場所目的位置づけ（2026年10月時点）
llms.txt/llms.txtサイトの要点と読むべきページを、AI に読みやすい Markdown でまとめる個人の提案から広まった慣習
ARD のマニフェスト/.well-known/ard.json（旧名 ai-catalog.json）サイトが提供する MCP サーバ・A2A エージェント・API などの「道具」を一覧にする業界の有志による仕様の草案（v0.91）
A2A の Agent Card/.well-known/agent-card.json1 つの AI エージェントの能力と接続方法を自己紹介するA2A プロトコル仕様の一部

これとは別に、robots.txt が「どのボットに来てほしいか」を伝えます。順に見ていきます。

llms.txt：AI 向けのサイト案内

llms.txt は、2024年9月に Jeremy Howard 氏が提案した、サイトのルートに置く Markdown のファイルです。サイトの概要と、詳しい情報へのリンクを、AI が短い文脈で読める形にまとめます。提案は v2 に改訂され、主要な AI 事業者も自社の開発者向けドキュメントに置いています（llms-txt「The /llms.txt file」）。

提案文書は、robots.txt とは目的が違うと書いています。robots.txt は「どんなアクセスを受け入れるか」を伝え、llms.txt は利用者を手伝う AI がその場で読む情報で、主に学習ではなく回答の生成に使われる想定です。

一方で Google は、検索の AI 機能（AI による概要など）に表示されるために、新たな機械可読ファイルや AI 用のテキストファイルを作る必要はないと明言しています（Google 検索セントラル「AI features and your website」）。llms.txt は、置けば必ず効くものではありません。

ai-catalog.json（ARD）：サイトの「道具」の目録

ARD（Agentic Resource Discovery）は、AI エージェントが使える道具（MCP サーバ、A2A エージェント、スキルなど）を、Web ページのように検索して見つけられるようにする仕様です。Microsoft・Google・GoDaddy・Hugging Face などの参加者が作る草案で、2026年6月に公開が告知されました（Hugging Face「Agentic Resource Discovery: Let agents search」）。

サイトは自分のドメインに道具の目録（マニフェスト）を置き、各項目に識別子・表示名・種類・接続先の URL などを書きます。検索サービス（レジストリ）がそれを集めて索引を作り、エージェントは「やりたいこと」で検索して道具を選びます。

ここで注意したいのが置き場所の名前です。2026年8月26日付の v0.91 で、目録の場所は /.well-known/ard.json に一本化され、従来の /.well-known/ai-catalog.json は「前の版の名前」になりました。読み手が旧名を見るかどうかは任意で、旧名にしか置いていない目録は見つけてもらえない可能性があります。目録の場所は、robots.txt の Agentmap: 行や HTML の link 要素でも示せます（ARD Specification v0.91）。2026年10月6日時点の Lighthouse のソースは旧名の ai-catalog.json を見に行くので、このブログのログにも旧名が残っていました。

Agent Card（A2A）：エージェントの自己紹介

A2A（Agent2Agent）は、AI エージェント同士が仕事を頼み合うためのプロトコルです。各エージェントは能力・接続先・認証方式を書いた Agent Card を /.well-known/agent-card.json に置いて見つけてもらいます（A2A Protocol Specification）。ARD の目録は、こうした Agent Card や MCP サーバの説明を「指し示す」側の仕組みです。

robots.txt：AIクローラーの書き分け

AI のクローラーは、学習用（OpenAI の GPTBot、Anthropic の ClaudeBot など）・AI 検索用（OAI-SearchBot・Claude-SearchBot など）と目的で名前が分かれ、Google の Google-Extended は Gemini の学習やグラウンディング（回答の根拠づけ）への利用を断るための robots.txt 上の名前です（OpenAI・Anthropic・Googleの公式ドキュメント）。書き分け方と守られる実態は、シリーズの AIクローラーとサイト運営 で詳しく扱っています。

📄 論文: エージェントの「目録」は、どんな方式が競っているのか

Evolution of AI Agent Registry Solutions: Centralized, Enterprise, and Distributed Approaches（Aditi Singh ほか、2025年8月、arXiv:2508.03095）は、査読前の論文（プレプリント）です。AI エージェントを見つけるための仕組みとして、MCP のレジストリ、A2A の Agent Card、分散型のディレクトリ、企業向けのディレクトリなど 5 つの方式を取り上げ、セキュリティ・認証・規模の拡大・保守のしやすさの 4 つの観点で比べました。

著者らは、中央集権的な管理・企業の統制・分散による耐障害性の間のトレードオフを示し、検証できる身元や共通の語彙が必要だと結論づけています。

運営者にとっての意味は、「見つけてもらう仕組み」も、載っている情報の身元を確かめる仕組みも、まだ発展途上だということです。

📄 論文: エージェントの道具は「読む」から「動かす」へ

How are AI agents used? Evidence from 177,000 MCP tools（Merlin Stein、2026年3月、arXiv:2603.23802）も査読前の論文です。2024年11月〜2026年2月に公開リポジトリで作られた MCP の道具 177,436 個を、データを読む道具・分析する道具・外部の環境を変える「行動」の道具に分類しました。

ツールの利用全体に占める「行動」の道具の割合は、16 か月で 27% から 65% に増えていました。金融取引のような影響の大きい道具もあります。

運営者にとっての意味は、目録に載せた道具が「何かを変更できる」なら、見つけた相手が実際に操作を試みうるということです。

セキュリティの視点：「案内」は攻撃者も読む

公開した目録は、攻撃面の一覧になる

ai-catalog.json（ard.json）や Agent Card は、誰でも読める場所に置くファイルです。社内向けの MCP サーバや管理用の API を載せれば、攻撃者には「どこに何があるか」の一覧になります。

A2A の仕様は、認証した相手にだけ詳しい内容を見せる「拡張 Agent Card」の取得に認証を必須とし、その拡張カードにさえ、漏れたら悪用されうる情報（内部サービスの URL や資格情報など）は載せるべきでないとしています（A2A Protocol Specification）。公開のカードに載せないのは言うまでもありません。

ARD の仕様は、認証を道具ごとのプロトコルに任せ、目録の仕組みとしては定めていません。仕様の例でも、社内のエージェントは社内の検索サービスから返す形です。社内の道具は公開の目録ではなく、社内の仕組みで案内するのが筋です。また ARD は、識別子に含まれるドメインと発行元の証明が一致するかを検索サービス側で確かめる仕組みを用意しています。なりすましの目録が出回りうる前提の設計です。

llms.txt と robots.txt は「お願い」であって強制ではない

robots.txt はアクセス認可の仕組みではないと、標準（RFC 9309）自身が明記しています（RFC 9309）。llms.txt も、AI に「ここを読んでほしい」と伝えるだけで、読まれたくないページを守る力はありません。見せたくないものは、認証の内側に置くのが原則です。

AI の API キーを狙う探索への備え

.env は、設定やパスワード、API キーを書いておく定番のファイル名です。公開ディレクトリに置いたままだと、URL を当てるだけで中身を読まれます。探索側は AI サービス向けの名前まで用意しています。

📄 論文: Web に置き忘れられた API キーは珍しくない

Keys on Doormats: Exposed API Credentials on the Web（Nurullah Demir ほか、2026年3月、arXiv:2603.12498）は arXiv 版で、ACM CCS 2026 に採録されています。1,000 万の Web サイトを実際に表示して調べ、14 の事業者向けの資格情報 1,748 件が、実際に使える状態で露出していることを確かめました。表 2 によると、そのうち OpenAI の鍵は 181 件でした。

露出の多くは公開用にまとめた JavaScript の中や外部から読み込む部品で起きていて、ソースコードを静的に調べるだけでは見逃されがちでした。露出は数か月から数年残ることが多かったといいます。

運営者にとっての意味は、.env を置かないだけでなく、公開するファイルに鍵が混ざっていないかを確かめ、漏れたら無効にするところまでが対策だということです。

このブログの結論

ai-catalog.json（ard.json）は置きません。 このブログは記事を読んでもらうサイトで、AI エージェントに提供する道具（MCP サーバや API）がありません。載せるものが無い目録を置く理由はなく、検査ツールで「見つからない」と出ても、それで正しい状態です。

llms.txt は、置いたままにして期待はしない、という扱いにします。 実はこのブログの llms.txt は、使っている SEO プラグインが自動で作っていました。中身は公開済みの記事の題名・要約・URL とサイトマップへのリンクで、すでに誰でも見られる情報です。AI の助けになるなら良いものの、検索の AI 機能に出る条件ではありません。下書きや非公開の情報が混ざっていないかだけ、ときどき確かめます。

robots.txt は、今は AI 向けの書き分けをしていません。

AIエージェント時代のサイト運営の鍵は次の3点です

  1. 案内ファイルは「誰が読んでも困らない」ものだけにする
    ai-catalog.json（ard.json）や Agent Card は攻撃者も読みます。社内の道具や内部の URL は載せず、詳しい情報は認証の内側に置きましょう。
  2. llms.txt と robots.txt は「お願い」と心得る
    どちらもアクセスを止める力はありません。守りたいものは認証やサーバ側の制御で守ります。
  3. AI の鍵は置かない・埋め込まない・漏れたら無効にする
    AI の API キーを狙う探索はすでに来ています。設定ファイルを公開ディレクトリに置かず、WAF などで探索そのものも止めておきましょう。

まとめ：AIへの案内は「出してよいもの」だけ、鍵はしまっておく！

AI 向けには、llms.txt、ai-catalog.json（新しい名前は ard.json）、agent-card.json といった新しい入口が用意されつつあります。このブログのログでも、検査ツールが llms.txt と ai-catalog.json を確かめに来る一方で、別の送信元は AI の API キーを探して .env.openai を要求していました。案内は提供する機能があるときに、外に出してよいものだけを載せる。鍵は公開の場所に置かない。この 2 つを押さえて、AI エージェント時代の入口に備えましょう！

参考文献

タイトルとURLをコピーしました