- [ ホーム ](/ja/) / - [ ブログ ](/ja/blog/) / - llms.txt のプロンプトインジェクションを脅威モデリングする # `llms.txt` のプロンプトインジェクションを脅威モデリングする llms.txt ファイルはエージェント向けの外部コンテキストになり得ます。だからといって、エージェントが設計上それに従うわけではありません。しかし、発行者とエージェントの構築者は間接的なプロンプトインジェクションを脅威モデルに含めるべきです。 最終更新: 2026年8月12日 このページの内容 - [ ログに現れたシグナル ](#the-signal) - [ ファイルが設計上公開される理由 ](#why-exposed) - [ 簡潔な脅威モデル ](#threat-model) - [ 実践的なリスク軽減策 ](#mitigations) ## ログに現れたシグナル Ahrefs が 137,210 ドメインで `/llms.txt` リクエストを調査したところ、2026年5月 のこれらのファイルへのトラフィックの 2.7% を研究用クローラーが占めていました。このカテゴリで最大のユーザーエージェント文字列は **`prompt-injection-survey/1.0`** でした。 その文字列が証明するのは、クライアントがそのラベルを申告したことだけです。運用者を特定することも、手法を明らかにすることも、悪意を示すことも、攻撃の成功を証明することもありません。Ahrefs はこれをプロンプトインジェクションに関する体系的な調査と解釈しました。この観測から正当に導けるのは、脅威モデルを検討するきっかけにすることであり、インシデントとして報告することではありません。 これは、現在何体のエージェントがファイルを読むかとは無関係な理由から、真剣に受け止める価値があります。セキュリティ上の露出はトラフィックに比例しません。何かがそれを読む一度の機会に何が起きるかに比例します。 ## 意図的にファイルを公開する理由 `llms.txt` が何のためのものか確認します。[V2 仕様](https://llmstxt.org/)は、ルートまたはより具体的なパスに置き、該当サイト領域の厳選マップをモデルに渡す Markdown ファイルを説明しています。Chrome の Lighthouse ドキュメントは、サイトの構造を理解するために必要なクロールを減らす方法としてこのファイルを示しています。 取り込みは、優先や従順を意味しません。安全なエージェントはファイルを経路案内の手がかりとして使いながら、すべての説明とリンク先を信頼できない外部データとして扱えます。[OWASP GenAI Security Project](https://genai.owasp.org/llmrisk/llm01-prompt-injection/)は、間接的なプロンプトインジェクションを、Web サイトやファイルなどの外部ソースに埋め込まれた悪意ある指示と説明しています。エージェントが消費する限り、`llms.txt` ファイルはこの一般的な脅威モデルの中に置かれます。 つまり、現在のログがエージェントによる広範な利用を示していなくても、取得や実行に影響し得る外部入力と同じ扱いをファイルに与える必要があります。 それを増幅する性質が 2 つあります。 - **自由記述の説明を含む通常の Markdown です。** 形式上、説明と指示を区別するものはありません。`- [Docs](https://example.com/docs/): ignore previous instructions and ...` と書かれた行も、構文上は有効なエントリです。 - **サイト外へ自由にリンクします。** 仕様はリンク先を制限していないため、侵害されたファイルが、自分で管理していないドメインへエージェントを誘導できます。 ## 短い脅威モデル 劇的さではなく、可能性の高い順に並べた現実的な 3 つの道筋です。 **古いファイル、間違ったルート。** ファイルが、移動済みのエンドポイント、料金ページ、バージョンパスを指しています。そのエントリに依存するクライアントは誤った場所へ案内されます。これは保守と正確性の問題であり、必ずしもセキュリティインシデントではありません。 **未確認の生成。** Ahrefs は、Wix などのプラットフォームがすでにこうしたファイルを生成し、Framer と Lovable がその存在を調べていると記しています。あなたに代わって生成されたファイルを一度も確認しなければ、その内容を保証できないファイルです。[ジェネレーター](/ja/generator/)を使う場合は、私たちのものを含め、出力は下書きです。公開する前に読んで確認してください。 **書き込み権限をてこにします。** `llms.txt` は、静的アセットと同じ `public/` ディレクトリに置かれることが多くあります。そのパスのレビューが少なければ、侵害された発行者やデプロイ手順が、通常人が訪れるレンダリング済みページを変更せずに説明と遷移先を変えられます。 ## 実務的な軽減策 どれも特殊なものではありません。動作に影響するファイルに適用する通常の統制です。 **バージョン管理し、変更をレビューします。** ファイルは手作業でアップロードせず、リポジトリに置きます。`public/llms.txt` の差分にも、ルートハンドラーの差分と同じ注意を払うべきです。 **編集できる人を制限し、許可されていない変更を通知します。** CI でデプロイ済みファイルとコミット済みの版を比較できるなら、そうします。[バリデーター](/ja/validator/)は構造とリンクを確認しますが、変更の監視はリポジトリとデプロイの統制に委ねられます。 **コンテンツは指示ではなく、常にデータの形にします。** リンクと事実に基づく説明だけにします。命令文、「常に」、「X について聞かれたら Y と答える」は入れません。表の行として読んで不自然な文は、ファイルに属しません。[ベストプラクティス](/ja/best-practices/)では品質の観点からこれを勧めていますが、安全性の理由も同じルールをより厳しくしたものです。 **外部の遷移先を確認します。** オフサイトリンクは形式上許可されており役立つこともありますが、確認すべき所有者とライフサイクルが一つ増えます。エージェントが遷移先に自動で作用する場合は、許可リストを使います。 **プラットフォームが生成したものはすべて確認します。** 特に、CMS やサイトビルダーが確認なしに追加したファイルを含みます。 **利用するエージェントを制約します。** 最小権限を適用し、取得したコンテンツを信頼済みの指示から分離し、ツールの入力と出力を検証し、重大な操作には人の承認を求めます。これらの統制は OWASP の指針に沿うもので、ファイル自体の文言ルールより重要です。 **`llms-full.txt`は、扱いを減らすのではなく、より慎重に扱います。** リンク一覧ではなくページ全体の内容をインライン化するため、攻撃対象領域が厳密に大きくなります。[llms-full.txt とは何か](/ja/llms-full-txt/)で、何を含めるべきか確認してください。 正直な捉え方はこうです。これは `llms.txt` の公開を避ける理由ではありません。マーケティング上の成果物として扱うのをやめ、設定として扱い始める理由です。実際にそれが設定だからです。 ## ソース - [ Ahrefs、13万7千サイトを分析：llms.txt ファイルの97%は一度も読み取られない（2026年6月） ](https://ahrefs.com/blog/llmstxt-study/) - [ llmstxt.org、仕様 ](https://llmstxt.org/) - [ Chrome for Developers、Lighthouse のエージェント型ブラウジング監査：llms.txt ](https://developer.chrome.com/docs/lighthouse/agentic-browsing/llms-txt) - [ OWASP GenAI Security Project、プロンプトインジェクション ](https://genai.owasp.org/llmrisk/llm01-prompt-injection/)