TL;DR
- LLMフレンドリーなドキュメント提供方法としては、ローカルにダウンロードさせるのが現時点では最も効率が良い
- library提供者は、ドキュメントを
npm等のpackageとしてpublishすることを検討するべき（例:@foo/docs） - Vibe Codingが盛んな今日において、libraryやframeworkがLLMフレンドリーであることはとても重要
Note: このブログでは主にJavaScriptエコシステムに絞って話をするので、
npmregistryにpublishする話を書いています。他のエコシステムについては他のエコシステムなりのpackage配布手段があるので、そこに置き換えて考えてみてください
2025年の漢字は「Coding Agent」と「MCP」
2025年はCoding Agentの年でした。3月にClaude Codeが発表され、5月にGAになってからはその勢いはとどまることなく、その後CodexやOpenCodeなどのAgent人気にも火がつきました。 世の中を見渡すと、日頃どのようなモデルがCodingに良いか、どのエージェントがうまく出力を出すか、どのようなツールがコード生成をサポートするかといった話題で持ちきりです。 これに加えて、MCPの普及もありました。特にCoding Agentを助けるものとしては効果的であるとされ、毎日のように新しいMCP Serverが公開され、人々はそれについて話しています。
LLMから望む出力を得るには
ところで世の中にはいろいろな開発ツールやlibraryがあります。LLMは主に有名なものを学習対象にしており、かつknowledge cutoff後の知識については当然知り得ないため、当然、何もしないままポン出しでは望む出力が得られません。 有名な話ではSvelte4と5の違い、React Router V6とV7の違いなど、breaking changesが行われたWeb Frontend Frameworkなどでは顕著に表れていました。さらにCLIツールを作るためのlibraryなどは得てしてマイナーなもの、学習対象が少ないものが多くなりがちで、出力結果が望ましいものでない場合が多いです。 これらの問題を解決するためには、いかにしてLLMにできる限りの情報を与えられるかという環境整備の話が大事になってきます。つまり、LLMの知識にないものをできるだけ用意してアクセスできる状態にすることで望み通りの情報を得られるようにLLMを導く、ということです。 この約1年を通して様々な場所で色々な議論が行われてきました。それぞれの良いこと、悪いこと、その時に良いとされてきたもの、振り返ってみると微妙だったよねとなっているもの、様々あります。
けつろんぱ
Vibe Codingが盛んな今日において、libraryやframeworkをLLMフレンドリーにすることはますます重要になっています。LLMと相性が悪いlibraryは、それだけで選択肢から外される可能性があります。では、library提供者はどのようにしてLLMフレンドリーな環境を実現できるでしょうか？
結論から言うと、LLMフレンドリーなドキュメント提供方法としては、ローカルにあるだけのものをダウンロードしそれをCoding Agentが自由に読める状態にすることが現時点では最も効率が良いです。
libraryの提供者は、ドキュメントをバージョン管理可能な状態でnpm等のregistryに上げるのが現時点では最も効果的なのではないかと筆者は考えています。
ブログではドキュメントを与える方法がどのように変わっていったか、そしてなぜその方法が一番良いと筆者が結論づけているのかについて論じていきます。
ドキュメント提供方法の変遷
RAG
RAG (Retrieval-Augmented Generation)は、LLMに外部知識を与えるための方法として広く知られています。 2022年11月にChatGPTが公開された後、人々の間で、「関連情報とプロンプトを一緒に渡せば知識に基づいた望ましい出力が得られる」という認識が広まりました。 これに伴ってプロンプトからいかに関連した情報を取り出して渡すかという議論が盛んになりました。 ここではRAGの具体的な手法には触れませんが、ドキュメントを渡してone-shotで回答を得るということの大切さの議論は、ここから盛んになったものと考えられます。
Web Search
2023年、ChatGPTにWeb検索機能が追加されました。これにより、LLMはインターネット上の最新情報にアクセスできるようになりました。 ChatGPTが能動的に情報をネットから探して、それについて回答を生成することが可能になりました。 ただし、HTMLという構造はLLMフレンドリーではなく、また毎回検索をするのはコストが高いため、決して効率のいい方法とは言えません。 現代のCoding Agentはウェブ検索機能を搭載するのが当たり前になっている一方、この問題は今後もついて回ることになるでしょう。 こと現在のContext Engineeringの常識を鑑みるにWeb Searchに頼るのは最終手段にすべきでしょう。
llms.txt
llms.txtは、2024年9月に提案された、比較的新しいウェブ標準"案"です。 llms.txtを用いることで、WebサイトはHTMLのような人間にとっての構造を廃し、LLMにとって必要最低限の情報をマークダウンで記述することで、トークン量を減らしつつ正確な情報を提供することができます。
Mintlifyなど、Coding Agentからアクセスすると、HTMLではなく自動的にllms.txtを返してくれるようなドキュメントサービスも増えています。
MCP Server
2024年後半から2025年にかけて、MCP (Model Context Protocol)が普及しました。
MCPは2023年6月にOpenAIから発表された function calling ( tool calling )の概念を標準化する形で提案されたプロトコルです。
2025年になって、Coding Agentに情報を与える手段として、Anthropic社から大々的に宣伝されたこともあり、ものすごい勢いでMCP Serverが増えていきました。
MCP Serverの素晴らしいところは、ひとたびMCPに沿った形でツールを定義すると、それがClaude CodeでもCodexでもOpenCodeでもamp codeでも好きなCoding Agentでそれが使えるということです。
これまでにいろいろなタイプのMCP Serverが作られてきました。筆者もsitemcpというMCP Serverを作成し、ドキュメントをMCP Server経由で提供する方法を提案しました。
libraryやframeworkの提供者がそれを使うための MCP Serverを個別に提供し始めています。
また独自の手法を用いてGitHubやlibraryの情報をいい感じに要約して返してくれるMCP Serverもあります。 Deepwiki MCP、Context 7、grep mcpなどはその最たる例です。
既存の方法の問題点
しかし、MCP Serverには大きな問題点がありました。
- Coding Agentに登録できるMCP Serverの数には上限があります。そのため、いろいろな情報を駆使してコーディングをさせたいときには、この上限が大きなネックになります。
- 多くのMCP Serverを登録すると、その定義だけでcontext windowを大きく圧迫することになります。1セッションあたりにこなせるタスク量が減ってしまいます。 このブログの趣旨とは違いますが、例えば
PlaywrightMCPをClaude Codeに接続しただけでほとんどのcontext windowを使い果たしてしまい、肝心の作業がほとんどできないといったことも起こっています。 - MCP Serverが一度に返せる情報量には限りがあり、多くの情報を返そうと思うと、何度かやり取りをしなければならず、N+1問題が容易に発生します。
sitemcpでもこの問題に対処するためにPaginationを導入しましたが、文字通りこれはN+1問題を引き起こしている例と言えるでしょう。
また、llms.txtにも共通する問題点として
- 毎回リモートにあるドキュメントを参照するのに時間もコストもかかる
- ドキュメントがバージョンごとに存在しているのは稀で、バージョンが古いlibraryを使っているときに情報のミスマッチが起きる
- 実際にCoding Agentが使うのは得られた情報の一部でしかないのにもかかわらず、取得したすべての情報をcontext windowに保持することになり、非常に効率が悪い
最後の問題に関しては、Claude Code は Subagents という仕組みを導入することで、部分的に解決しています。 しかし他の問題は残ります。
原点回帰: ローカルドキュメント
MCPが普及し始めた2025年4月ごろから、MCPとCLIはどっちがいいんだという議論が度々話題になっていました。Coding Agentもこの半年でいくつか世代を経るごとに、CLIツールの呼び出し方については、めきめきと精度が上がっていきました(これと比較して、MCPなどのツール呼び出しの精度は実はあんまり上がってないんですよね…)。
これを踏まえると、できる限りドキュメントやlibraryのソースコードを手元に置いておくのがいいのではないかなというアイデアを筆者の周りではより頻繁に聞くようになりました。
例えば友人である NATSUKIUM は ghqを使って使用しているlibraryをローカルにクローンして参照するようにCLAUDE.mdに指示を書いています。また、btcaというCLIツールでは、指定したlibraryを実際にGitHubからクローンしてきて、その情報を与えるための仕組みを整備していたりします。
一度手元にドキュメントをおいて仕舞えば、あとはCoding Agentがfd, rgなどを使って必要な情報を探し出し、必要な部分だけを読み込んで処理すればよいわけです。
しかもわざわざリモートに情報を取りに行く必要もないわけですから、非常に効率的です。
repositoryにドキュメントが置いてあったとしても、それは大抵Markdownでしょう。2025年現在何かドキュメントを書くとした場合に、それがMarkdownでない確率の方が低いと考えられます。
ドキュメントをpublishしよう
ローカルにドキュメントやコードを置いておくことは効果的であることは明らかです。 ではこの仕組みをどうやったら一般化できるでしょうか？ libraryの提供者はどうやれば最小手で自分のlibraryやframeworkをLLMフレンドリーにできるでしょうか? 上の方法では解決していないバージョンによる違いなどはどのように解決すればいいのでしょうか。
筆者は、library提供者がドキュメントをnpm packageに同梱する。あるいは @foo/docs のような形でドキュメント専用packageを提供することを提案します。(JavaScriptエコシステムの場合)
なぜnpm packageなのか
npm packageとしてドキュメントを提供することにはいくつかの利点があります。
ローカルへの自動配置
npmの大きな特徴として、インストールしたpackageがnode_modulesディレクトリに実体として配置されることが挙げられます。
パスは常に./node_modules/<package-name>と予測可能で、Coding Agentが参照しやすい構造になっています。
ドキュメントをnpm packageとしてpublishすれば、npm installするだけで自動的にプロジェクト内にドキュメントが配置されるのです。
ドキュメント参照容易性
ドキュメントをCoding Agentに参照させるのは非常に簡単です。
If you need to implement feature X, use the `@your-library` package.
Please refer to the documentation located at `./node_modules/@your-library/docs/**/*.md` for more information about how to use the library.これをそのままCLAUDE.mdやAGENTS.mdに書くこともできますし、より具体的にはAgent Skillsの一つとして定義することで、必要に応じて参照させることもできるでしょう。
配布容易性
あなたがlibraryの作者である場合、ドキュメントとlibrary本体をモノレポで管理している場合がほとんどでしょう。その場合、ドキュメントを管理しているrepositoryを同時にバージョンを付けてpublishすることができます。 またすでにrepositoryにあるMarkdownをそのままコピーしてpublishするだけで完了するのでとても簡単です。
バージョン管理容易性
新しいpackageをpublishするごとに、同時にドキュメントをpublishしていけば、ユーザーはlibraryとドキュメントのバージョンを合わせてダウンロードすることができます。 Coding Agentは、使用しているlibraryのバージョンに対応するドキュメントを確実に参照することができます。
実際の運用例
実はこの方法はすでにいくつかのlibraryで行われているものです。
bun-types
BunはJavaScriptランタイムですが、その型定義を提供するためにbun-typesというpackageを提供しています。
このpackageにはBunの型定義だけでなく、Bunのドキュメントも同梱されています。
また面白いことにbun init -yコマンドでプロジェクトを生成させると、bunはCLAUDE.mdファイルを自動生成します。その中にはBunのドキュメントを参照する指示が含まれています。
gunshi
gunshi by KAZUPON はTypeScriptでCLIツールを作成するためのlibraryです。筆者が今もっとも愛用しているCLI libraryです。
このlibraryはgunshi packageとは別に@gunshi/docsというドキュメント専用packageを提供しています。Coding Agentはbun-typesと同様にこのドキュメントを参照することで、gunshiの使い方を学習することができます。
また、bunx @gunshi/docsコマンドを叩くと、CLAUDE.mdやCursor Ruleを自動生成してくれる仕組みも提供しています(注)。
実際に gunshi のドキュメントを参照させた場合とWeb検索を使った場合を比較すると:
- コストは1.37USD -> 0.44 USD
- 実装は3:31 -> 0:40
- 手戻りも0回に！
などの効果がありました。
@gunshi/docsを使った場合
Web検索のみ使用した場合
byethrow
また同じく筆者が愛用している新しいResult型libraryであるbyethrow by KARIBASH も同様に @praha/byethrow-docs というドキュメント専用packageを提供しています。 byethrowは以前からmcpを提供していましたが、docs packageの方が高速に実装をすることができます。
注意点
この方法を採用する際にはいくつか考慮すべき点があります。
packageサイズの増加
ドキュメントを同梱することで、当然packageのサイズは増加します。ただし、Markdownファイルはテキストベースであり、画像などを含めなければサイズの増加は限定的です。また、@foo/docsのように別packageとして提供する場合は、本体のサイズには影響しません。
メンテナンスコスト
ドキュメントをpackageに含める場合、リリースのたびにドキュメントも一緒に更新・publishする必要があります。CIパイプラインを整備することで、このコストは最小化できます。 またモノレポで管理している場合、ドキュメントとコードのバージョンを同期させるのが容易です。
おわりに
この1年間、Context Engineeringという名前のもとで、どのようにドキュメントを整備して、LLMひいてはCoding Agentに渡すかということが広く議論されてきました。
筆者の中での現在の最適な方法は、ローカルにドキュメントを落とし、Coding Agentを信頼して、自由に情報を探索させることだと結論づけています。
npm registryへのドキュメントpublishは、それを推し進めるための良い解決策なのではないでしょうか。
P.S.
僕はgunshiというtypescript製のcliを構築するためのライブラリが好きです(ccusageでもsitemcpでも使ってる）。 しかし、このライブラリ、めちゃくちゃ新しいのでLLMがgunshiについての知識は持っていません。なのでvibe codingと相性がめっちゃ悪い。 そこで @kazu_pon
So actually, if I took a benchmark of how effective our Claude code skills for Gunshi are, the result is amazing: With Skills • 0.44 USD • 40s for implementation • 1:05 for implementation + debugging Without Skills • 1.37 USD • 3:31 for implementation • 3:52 for
面白い。DaaP(Documents as a Package)と言うのかな？これ普及すればContext7のMCPが不要になるかもしれませんね。デフォルトはこれになって欲しいですし、Context7ではなくDeepWikiみたいなものでMCPを消費したいですね。
新しい記事！ ドキュメントをnpm packageとしてpublishしよう | blog | ryoppippi ryoppippi.com/blog/2025-12-1…