Claude Codeにllms.txtの技術ドキュメントを取り込んで学ばせる手順
ライブラリのllms.txtと.mdページをcurlでdocs/vendor/に保存し、CLAUDE.mdから案内する手順です。@で常時読み込む範囲とWebFetch許可との使い分けも比べます。
新しいライブラリのドキュメントをClaude Codeに読ませるなら、HTMLを丸ごと取るより、サイトが用意したllms.txtとMarkdownページを必要な分だけ手元に保存する方法が扱いやすくなります。保存先を docs/vendor/ に決め、CLAUDE.mdから場所を案内すれば、「このバージョンのドキュメントだけを根拠に答える」運用を作れます。
ただし、保存したファイルを @ でCLAUDE.mdに取り込むと、毎セッション全文が文脈に載ります。ここが最初の分かれ道です。この記事では、llms.txtの仕組み、取り込み方の選び方、実際に動かしたスクリプト、WebFetchの許可ドメインで済ませる方法との違いを順に扱います。
llms.txtとは何か — Claude Codeに渡せる形
llms.txtは、サイトがLLM向けに置くMarkdownの目次ファイルです。提唱文書によると、サイトのルートか任意のパス(/docs/llms.txt など)に置き、そのパス配下を担当します。複数あるときは、より具体的なパスのものを使う想定です。
必須なのは先頭のH1(プロジェクト名)だけです。続けて引用ブロックの要約、H2ごとのリンク一覧を置きます。各リンクは [名前](URL) に、任意で : 補足 を付けます。
もう一つの提案が、各ページのMarkdown版です。元のURLに .md を足す(page.html.md)か、拡張子を .md に置き換えたURLで、HTMLのナビゲーションやJavaScriptを含まない本文を返します。目次のllms.txtが小さく、詳細はリンク先にあるので、エージェントは目次から必要なページだけ取りに行けます。
Claude Code自身のドキュメントもこの形です。code.claude.com/docs/llms.txt は約64KBの目次で、各ページの .md へのリンクと一行説明が並びます。各ページの冒頭にも「全ページの一覧はこのllms.txtにある」という案内が付いています。
取り込み方を決める — @参照は全文が毎回載る
Claude CodeがCLAUDE.mdから別ファイルを読む方法は @path/to/import です。インポートされたファイルは展開され、参照元のCLAUDE.mdと一緒に文脈へ載ります。最大4段まで再帰します。
ここで効いてくるのが、メモリ機能の説明にある次の点です。インポートはCLAUDE.mdの整理には役立ちますが、文脈の消費は減りません。さらに、1つの指示ファイルは200行以内が目安で、長いと遵守率が下がるとされています。@ で読んだファイルも1ファイルとして数えられます。
つまり、数百行のドキュメントを @ で常時読み込むのは、ドキュメントを毎回すべて貼り付けるのと同じです。取り込み方は3通りに分けて考えると決めやすくなります。
| 方法 | 文脈に載るタイミング | 向く対象 |
|---|---|---|
@docs/vendor/uv/llms.txt と書く | 文脈に載るタイミング毎セッション、全文 | 向く対象数十行〜百行程度の目次だけ |
`docs/vendor/uv/guides_projects.md` とバッククォートで書く | 文脈に載るタイミングClaudeが必要と判断してReadしたとき | 向く対象ページ本体 |
.claude/rules/ に paths を付ける | 文脈に載るタイミング一致するファイルをRead・編集したとき | 向く対象特定の設定ファイルと結び付く資料 |
バッククォートで囲むと、パスはインポートとして扱われず文字のまま残ります。公式の説明では、コードスパンとフェンス付きコードブロックの中はインポートの解析対象外です。これを使えば、ファイルの場所を知らせつつ文脈は消費しません。
手順 — 目次とページをdocs/vendor/に保存する
実例として、Pythonのパッケージ管理ツールuvのドキュメントを使います。uvは docs.astral.sh/uv/llms.txt を公開していて、冒頭に「ディレクトリには明示的に index.md を付けて取得すると、HTMLではなくきれいなMarkdownが返る」と書いてあります。リンクもすべて index.md 形式です。
保存用のスクリプトは次のとおりです。目次と指定したページを取得し、取得日とURLを SOURCES.txt に残します。
#!/usr/bin/env bash
# ./vendor-docs.sh uv https://docs.astral.sh/uv guides/projects
set -euo pipefail
name=$1; base=$2; shift 2
dir=docs/vendor/$name
mkdir -p "$dir"
curl -fsSL "$base/llms.txt" -o "$dir/llms.txt"
for page in "$@"; do
out="$dir/$(echo "$page" | tr / _).md"
curl -fsSL "$base/$page/index.md" -o "$out"
echo "$(date +%F) $base/$page/index.md" >> "$dir/SOURCES.txt"
done
wc -l -c "$dir"/*2ページを指定して実行すると、次の結果でした。
./vendor-docs.sh uv https://docs.astral.sh/uv \
guides/projects concepts/projects/dependencies 2 139 docs/vendor/uv/SOURCES.txt
932 28867 docs/vendor/uv/concepts_projects_dependencies.md
262 7891 docs/vendor/uv/guides_projects.md
93 5145 docs/vendor/uv/llms.txt
1289 42042 total目次のllms.txtは93行・約5KBで、@ で読ませても重くなりません。一方、依存関係の概念ページは932行あり、@ で取り込めば単体で200行の目安を大きく超えます。
同じ「プロジェクトの使い方」ページで比べると、HTMLは89,444バイト、Markdown版は7,891バイトでした。ナビゲーションやスクリプトを除くだけで、1桁近く小さくなります。
CLAUDE.mdに書く断片
保存したら、CLAUDE.mdには場所と守るルールだけを書きます。目次だけを @ で読み、ページ本体はバッククォートで案内します。
## 参照ドキュメント(docs/vendor/)
- uv の挙動は、保存済みの `docs/vendor/uv/` のページだけを根拠に答える
- 目次: @docs/vendor/uv/llms.txt
- ページ本体は必要になったときに Read する(取得日は `docs/vendor/uv/SOURCES.txt`)
- 目次にあっても未保存のページは推測で補わず、保存すべきページ名を答える「未保存のページは推測で補わず」の一文が、運用の要です。これがないと、保存していない範囲を学習済みの記憶で埋めてしまい、「このバージョンの記述だけ」という前提が崩れます。
設定ファイルと結び付けて読ませる
依存関係の質問は pyproject.toml を開いたときに出やすいので、パス指定のルールにすると、該当ファイルを触るときだけ案内が載ります。.claude/rules/uv.md の例です。
---
paths:
- "pyproject.toml"
- "uv.lock"
---
# uv の依存関係
- 依存の追加・更新は `docs/vendor/uv/concepts_projects_dependencies.md` を先に読む
- そのページに無い操作は提案せず、不足を報告するパス指定のルールは、Claudeが一致するファイルをRead・Write・Editしたときに読み込まれます。一致するファイルに対して cat や head で中身を見たときも対象です。
動作を確かめる
保存と案内を入れたら、保存範囲の内外を一問ずつ尋ねて挙動を見ます。
uv で開発用の依存グループを追加する方法を、保存済みドキュメントだけを根拠に説明して。
どのファイルのどの節を読んだかも挙げて。回答に保存ファイル名と節が挙がれば、案内は効いています。保存していない話題(例えば uv の別ページ)を尋ねて、推測で答えずに「未保存」と返すかも、あわせて試すとよいでしょう。ルールが守られていないときは、CLAUDE.mdの文言を具体的にします。
WebFetchの許可ドメインで済ませる方法との違い
保存せず、都度WebFetchで取りに行く方法もあります。許可ルールは WebFetch(domain:docs.astral.sh) の形で、ホスト名に対して照合されます。サブドメインも含めるには WebFetch(domain:*.example.com) を別に書きます。
どちらが良いかは、ドキュメントの更新頻度と再現性のどちらを重く見るかで分かれます。
| 観点 | docs/vendor/ に保存 | WebFetchで都度取得 |
|---|---|---|
| 参照するバージョン | docs/vendor/ に保存保存した時点に固定。取得日を記録できる | WebFetchで都度取得取得時点の最新 |
| 更新の手間 | docs/vendor/ に保存スクリプトを再実行し、差分をコミットで確認 | WebFetchで都度取得不要 |
| チームでの再現性 | docs/vendor/ に保存リポジトリに入るので全員が同じ内容 | WebFetchで都度取得取得のたびに内容が変わりうる |
| ネットワークと許可 | docs/vendor/ に保存保存時だけ。セッション中は不要 | WebFetchで都度取得毎回ドメインの許可が必要 |
| 文脈への影響 | docs/vendor/ に保存目次だけ常時、本体は必要時 | WebFetchで都度取得取得したページ全文が載る |
注意点が1つあります。許可ドメインを絞っても、Bashが許可されていれば curl で任意のURLに届きます。URLを制限するBashルール(Bash(curl http://github.com/ *) など)は、オプションの位置やプロトコルが違うだけで外れるため、壊れやすいと説明されています。確実に制限したいときは、サンドボックスのネットワーク許可リストと組み合わせます。
保存方式でも、取得は curl を使う作業です。保存用のスクリプトを人が実行し、Claudeには保存済みファイルだけを読ませる形にすれば、ドメインの許可を広げずに済みます。
保存方式がつまずく4つの場面
目次の置き場所と形式がサイトごとに違う。Svelteの svelte.dev/llms.txt は、ページ一覧ではなく、llms-medium.txt(抜粋版)や llms-small.txt(圧縮版)、llms-full.txt といったドキュメントセットを案内する構成でした。パッケージごとの個別llms.txtもあります。uvのように1ページずつ index.md を取る前提のサイトとは、取り方が変わります。
古くなる。保存した時点のドキュメントなので、ライブラリを更新すると食い違います。SOURCES.txt に取得日を残し、依存のバージョンを上げるPRで再取得するようにすると、ずれに気付けます。uvのllms.txtと保存した2ページには、版番号の記載がありません。版の記録は自分で SOURCES.txt に足します。
ページを選び過ぎて、必要な節が抜ける。目次の一行説明だけで保存対象を決めると、関連ページを取り逃がします。回答が「未保存」で止まったページを追加で保存する運用にして、少しずつ広げるのが現実的です。
言語版がある。Claude Codeのドキュメントのllms.txtは、末尾に各言語版の目次(日本語版を含む)へのリンクを持ちます。英語版と日本語版では記述の更新時期が違うことがあるため、どの言語を根拠にするかをCLAUDE.mdに書いておくと、答えがぶれにくくなります。
保存方式とMCPのどちらを選ぶか
ライブラリのドキュメントを渡す方法には、MCPサーバーもあります。Context7のMCPをClaude Codeに設定する手順では、最新ドキュメントをバージョン指定つきで注入する方法を扱っています。公開リポジトリの文書を検索する方法はDeepWiki MCPをClaude Codeで使う手順にあります。
保存方式が向くのは、次のような場面です。
- 対象の数が少なく、使うページが決まっている
- 社内のレビューで「どの版の記述を根拠にしたか」を示したい
- ネットワークを閉じた環境で作業する
数が多く、毎回違うライブラリを引く場合はMCPの方が手数は少なくなります。両者は排他ではなく、よく使うライブラリだけ保存し、残りはMCPに任せる分担もできます。ドキュメント検索を会話で回す別の構成はClaudeとPromptlessをMCPでつなぐ記事が参考になります。
まとめ
保存して案内する方式の要点は、目次だけを @ で常時読ませ、ページ本体は場所の案内にとどめることです。取得日を残し、未保存の範囲は推測させない一文をCLAUDE.mdに入れておけば、保存した版の記述だけを根拠にする運用になります。最初は目次と2〜3ページから始めて、回答が「未保存」で止まった分だけ足していく進め方が続けやすいでしょう。
参照した一次ソース
この記事の記述は、次の一次ソースと照合しています。更新時に参照先が変わった場合は一覧も更新します。