LLMにコードを読ませようとするとき、ファイルをひとつひとつ開いてコピーし、チャット欄に貼り付けている人は少なくないと思います。あるいはプロジェクト全体を渡したいのに、どのファイルを含めるべきか迷って、結局必要な文脈を渡しそびれた経験もあるのではないでしょうか。code2prompt は、そういう手作業をまるごと引き受けてくれるCLIツールです。今回は紹介と設計の両面から掘り下げてみます。
どんなツールか
code2prompt は、指定したディレクトリのコードベースを走査して、ひとつのLLMプロンプトとしてまとめるCLIツールです。mufeedvh氏が開発し、現在スター数7,600超。Rustで実装されており、Cargo・Homebrew・pip（Pythonバインディング経由）の3経路でインストールできます。
基本的な使い方は code2prompt . と打つだけで、カレントディレクトリを走査してクリップボードに出力します。ファイルのソースツリー、各ファイルの内容、そしてトークン数の概算がセットになったプロンプトが生成されます。.gitignore のルールを自動で尊重するので、node_modules や dist のような不要なディレクトリが混入するのを気にせずに使えます。
CLI単体として使う以外にも、Python SDKとしてAIエージェントのパイプラインに組み込んだり、MCPサーバーとしてローカルサービス化したりと、エコシステムとして広がっています。コードをLLMに渡す作業を「準備の手間」ではなく「設計できるステップ」に変えようとしている意図が、構成から読み取れます。
設計でここが上手い
Rustコアの分離
ファイル走査・フィルタリング・Gitメタデータの取得を担うコアライブラリが、CLIツール本体とは別クレートとして切り出されています。これは単に「速い」という話ではなく、Python SDKがこのRustコアをバインディングで呼び出せるという構造的な恩恵を生んでいます。速度の保証と多言語対応を、コードの重複なく実現しているわけです。もしPythonだけで書かれたツールだったとしたら、大きなコードベースを走査するたびに待ち時間が積み上がっていたでしょう。Rustを選んだことがここで効いています。
Handlebarsテンプレートによる出力の柔軟性
生成されるプロンプトは固定形式ではなく、Handlebarsテンプレートでカスタマイズできます。たとえばコードレビュー用に「このコードの問題点を指摘してください」という指示を前置きしたり、ドキュメント生成用に別のフォーマットを用意したりするのが、設定ファイルひとつで切り替えられます。テンプレートを使わずデフォルトで動かすこともできるので、初めて触るときにハードルがありません。使いながら徐々に自分の用途に合わせていける設計になっています。
トークンカウントの組み込み
LLMを使うとき、コンテキストウィンドウの上限を超えないかどうかは実際に投げてみるまでわからない、という経験をしたことがある人は多いはずです。code2prompt はプロンプト生成と同時にトークン数を表示するため、投げる前に「このコードベースは入る/入らない」が分かります。大きなリポジトリを扱うとき、どのファイルを除外してトークンを削るかを判断する材料になります。送ってからエラーで返ってきて削り直す、という往復を省けます。
インタラクティブTUIの存在
最小限のCLIとTUIを両方用意している点も注目できます。TUIでは含めるファイルをインタラクティブに選べるため、「まず全部を見渡してから絞り込む」という作業が端末を離れずにできます。CLIとTUIを別ツールとして分けず、同じバイナリ内に収めているのは、インストールコストを最小化しながら操作の幅を確保するための判断だと思います。
こういう人に向くかも
プロジェクト全体のコードをChatGPTやClaudeに渡してアーキテクチャの相談をしたい人に、素直に向いています。ファイルを手動で集める手間がなくなるだけで、LLMへの質問の精度がかなり変わります。
一方、AIエージェントを作っている人にとっては、Python SDKとしての活用が現実的かもしれません。RAGパイプラインのインデクシング前処理として、特定ディレクトリのコードをまとめて渡す用途が考えられます。コードの変更差分をプロンプトに含めるGit連携機能もあるので、CIの中でコードレビュープロンプトを自動生成する、という使い方も面白そうです。
MCPサーバーとして動かしてエージェントにローカルコードベースを読ませる構成は、コンテキストウィンドウを節約しながら必要なファイルだけを都度取り出すオンデマンド設計として、大きなリポジトリを扱うときに効いてきます。
設計の良し悪しをどこで見るか
code2prompt の設計を評価するときに気になる軸をいくつか挙げます。
機能の単一性という観点では、「コードベースをプロンプトにまとめる」という役割に徹していて、ブレがありません。LLMへの送信やAPI呼び出しはこのツールの範囲外で、前処理専門のツールとして割り切っています。この割り切りが、CLI・SDK・MCPサーバーという3形態への展開を可能にしています。全部入りにしようとしていたら、Rustコアの再利用という設計は成立しなかったでしょう。
想定外の使われ方への備えという点では、グロブパターンによるファイルの絞り込みが効いています。巨大なモノレポで特定のサービスだけを渡したいとき、あるいはテストコードを除外してプロダクションコードだけを渡したいときに、--include や --exclude オプションで対応できます。.gitignore との自動連携もあるため、特別な設定なしにある程度の安全網が働いています。
ドキュメントの深度については、専用サイト（code2prompt.dev）が存在しており、READMEと分けて管理されています。インストール手順・テンプレートのカスタマイズ方法・各種オプションの説明と、情報の構造が整っています。ただし、テンプレートをどこまで作り込めるかという実例は、もう少し充実するとより使いやすくなるかなとは感じます。
トークン経済性という観点でも触れておくと、MCPサーバーモードはここに直接効いています。エージェントが毎回リポジトリ全体をコンテキストに詰め込む代わりに、必要なファイルだけをサーバーに問い合わせて取り出せるなら、コンテキストウィンドウの消費はかなり抑えられます。コードベースが大きくなればなるほど、この差は広がっていきます。
メンテナンスの継続性については、CIが設定されており、crates.ioとPyPIへの公開フローも整っています。Discordコミュニティもあるため、活発に動いているプロジェクトと見てよいでしょう。
自分が書くなら、どこを変えるか
現状のツールで気になるのは、テンプレートのプリセット管理です。Handlebarsテンプレートで出力をカスタマイズできるのは良いのですが、「コードレビュー用」「ドキュメント生成用」「バグ調査用」といったよく使うパターンを名前付きプリセットとして保存・切り替えできる仕組みがあると、日常的に使うハードルがさらに下がると思います。現状は自分でファイルを管理することになるため、プリセットのディレクトリ規約とショートカット指定（例：--template review）があれば、チームでのテンプレート共有もしやすくなるでしょう。
もう一点、出力のサイズ最適化について。トークン数は表示されますが、「このファイルが全体のトークンのうち何割を占めているか」といったファイル単位の内訳が見えると、どこを削れば上限に収まるかの判断がしやすくなります。大きなリポジトリを扱うとき、削るべきファイルを手探りで探す手間が省けるのではないでしょうか。
導入を検討するときのチェック観点
- コードベースのサイズは現実的か（大きすぎる場合はMCPサーバーモードやファイル絞り込みの組み合わせが必要になります）
.gitignoreの設定は整っているか（自動除外の恩恵を受けるには、除外ルールが適切に書かれていることが前提です）- 出力先はクリップボードで足りるか、ファイルやstdoutへの書き出しが必要か
- テンプレートのカスタマイズが必要な用途か、デフォルト出力で事足りるか
- 使う場面がワンショットのCLI操作か、エージェントへの組み込みか（後者ならPython SDKかMCPサーバーの選択になります）
- チームで共有するテンプレートを管理する仕組みが別途必要かどうか
- 対象リポジトリにGitの差分情報を含めたいか（コードレビュー用途ではここが大きな決め手になります）
手作業の境界線
code2prompt が解いているのは、「コードをLLMに渡す準備」という地味で繰り返しの多い作業です。ファイルをひとつずつ開いてコピーしていた時間が、コマンド1行に置き換わります。それ自体はシンプルな改善ですが、Rustコアの分離・テンプレートの柔軟性・MCPサーバーへの展開という構成を見ると、「使い捨てのスクリプト」ではなく「育てていけるツール」として設計されていることが伝わります。自分のワークフローのどこに当てはめるかを考えながら試してみると、思いのほか使いどころが見つかるツールだと思います。
