Claude Code: ローカルファイルを用いた簡易 RAG に意味があるか？
bluegrass一部のプロンプトを CLAUDE.md や agents / commands の定義ファイルには含めず、必要に応じてインポートしたいケースがある。例えば言語・フレームワークごとに固有のルールや、TDD の具体的な方法論についてなど。agent は backend-developer などのくくりで作成しつつ、必要に応じて ~/.claude/docs/ などに作成した言語固有の知識に関するテキストファイルをナレッジソースとして外付けしたい。
公式ドキュメントにも 「CLAUDE.mdファイルは@path/to/import構文を使用して追加ファイルをインポートできます」とあるため、知識の外部ファイル化は可能。ではこれにあたり、主にコンテクストのサイズ等の点で留意すべき点があるか？
bluegrass言語やフレームワーク、ライブラリなどの公式ドキュメントは Context7 を用いて参照する。また一般に広く知られ、具体的な実例も多いソフトウェア開発哲学や原則などは、Claude がすでにその内容についての知識を持っているため名称を指定するだけでよく、非常な厳密性を求めないのならわざわざプロンプトに記述する必要はない。
以前「プロンプトに”t-wadaさんの推奨する進め方に従ってください”と書くとテスト駆動開発のプラクティスを実践してくれる」という Tips が話題になっていたことからも、著名な人物が提唱する開発手法の内容についても知識があるらしい。
参考：https://blog.lai.so/t-wada-vs-tesuto-daisuki-rou/
しかし Kent Beck 氏は自身のリポジトリの CLAUDE.md 内で、文量は多くないものの TDD の具体的な実践方法について記載している。これはやはり厳密性を求めてのことか。（なお、この記述が追加されたのが5月のため、最新の Claude Code の状況を反映しているかは不明）
参考：https://github.com/KentBeck/BPlusTree3/blob/main/rust/docs/CLAUDE.md）
bluegrassとりあえず Gemini の Deep Research で調査を依頼したところ、大まかに下記のような返答が。
ベクトルデータベースを用いたRAG（検索拡張生成）は、大規模な知識ベースから関連性の高い情報を「検索」してコンテキストに注入する高度なアプローチですが、ローカルのMarkdownファイルを知識ソースとして利用することで、よりシンプルに同様の目的を達成できます。
これは、Subagentが持つ基本的なツール、特にファイルシステムを操作する能力を活用することで実現します 。
仕組み
ベクトルデータベースを直接利用するRAGとは異なり、この方法はSubagentに搭載された標準ツールを使って機能します。ツールの利用: Subagentの定義ファイルで、ReadやBash（catやgrepなどのコマンドを実行できる）といったツールへのアクセスを許可します 。
プロンプトによる指示: Subagentのシステムプロンプト内で、「~/.claude/docs/STYLE_GUIDE.mdを読み込み、その内容に従ってコードをレビューしてください」というように、特定のローカルファイルを読むように明確に指示します 。
効率性: ファイルが小さい、または数が少ない場合に非常に効率的。大きなファイル全体を読むとコンテキストを大量に消費する可能性がある。知識ベースが大規模な場合に非常に効率的。関連部分のみをコンテキストに含めるため、トークンの消費を抑えられる 。
最適な用途: プロジェクト固有のスタイルガイド、アーキテクチャドキュメント、特定のAPI仕様書など、参照すべきファイルが明確に決まっている場合。
bluegrass「ファイルが小さい、または数が少ない場合」の基準を明らかにしてもらう。
bluegrass| 階層 | 文字数 (概算) | トークン数 (概算) | 推奨モデル | コストプロファイル | レイテンシープロファイル | 主なユースケース | 主要な考慮事項 |
|---|---|---|---|---|---|---|---|
| 階層1 (高効率) | 2,000 - 8,000 | 500 - 2,000 | Haiku, Sonnet | 低 | 低 | FAQ、用語集、アトミックな知識単位 | 高いシグナル対ノイズ比を維持。 |
| 階層2 (包括的) | 8,000 - 40,000 | 2,000 - 10,000 | Sonnet | 中 | 中 | ブログ記事、レポート、自己完結型ドキュメント | 単一ドキュメント内の文脈理解が必要な場合。 |
| 階層3 (バルク) | 40,000 - 600,000 | 10,000 - 150,000 | Haiku/Sonnet (チャンク検索後) | 高 | 高 | 書籍、マニュアル、大規模契約書 | ファイル全体ではなく、チャンクを検索・生成の対象とする。 |
Gemini が出してくれた表。この数字がどれほどの妥当性を持っているかは要調査。
bluegrass以下の記事も参考に、ちょうど良さげな分割を探ってみる。