repo2txt: GitHubリポジトリをLLMプロンプト用の単一テキストに変換するブラウザツール

repo2txtが埋めるのは「コンテキスト組み立て」の手作業

LLMにコードを読ませるとき、最初に発生するのはモデルの能力ではなく、渡すテキストを作る作業である。対象ファイルを選び、除外すべきものを外し、1つのファイルに連結し、トークン数が上限に収まるか確認する。repo2txtはこの一連の作業をブラウザ上のGUIに置き換える。READMEの冒頭には Convert repositories to plain text for LLM prompts とあり、対象はAI支援開発を行う開発者とされている。想定読者は、ClaudeやChatGPTのプロジェクト機能やチャットにリポジトリ全体を渡したいが、シェルスクリプトを毎回書きたくない人である。リポジトリの規模が大きいほど、ファイル選択のUIとトークン計測の価値が出る。

入力ソースが5系統あることの意味

GitHub、ローカルファイル、zipアップロード、GitLab（Beta）、Azure DevOps（Beta）の5つが読み込み元として挙げられている。GitHubは公開・非公開の両方に対応し、パーソナルアクセストークンを渡すと非公開リポジトリの取得とレート制限の緩和（READMEでは60回/時に対し5000回/時と記載）ができる。URLの解釈は https://github.com/owner/repo 形式に加え、/tree/branch-name や /tree/branch-name/path/to/folder の形も受け付ける。スラッシュを含むブランチ名 feature/test/branch-name が例として挙げられている点は、URLのパースを正規表現で済ませている実装では壊れやすい箇所であり、そこを明示しているのは実装上の配慮と読める。GitLabとAzure DevOpsはBeta表記であり、READMEは対応の深さについて何も説明していない。本番のワークフローに組み込むなら、まず自分のリポジトリで試すべき部分である。

ブラウザ内で完結する処理の流れ

READMEが Privacy First として挙げているのは、100% Browser-Based、No Tracking、GitHubトークンはsessionStorageのみに保存、という3点である。サーバーへのアップロードがないため、非公開リポジトリのコードやトークンが外部に送られる経路は、GitHub APIへの直接リクエスト以外に存在しない、という主張になっている。技術スタックはReact 19 + TypeScript、Vite 5、Tailwind CSS 3、状態管理にZustand、zip展開にJSZip、トークン化にgpt-tokenizer、仮想スクロールにTanStack Virtual。トークン化はWeb Workerで実行され、UIスレッドを止めないと説明されている。ファイル内容はProgressive Loadingとして読み込みながら流し込む方式で、大規模リポジトリでも画面が固まりにくい設計だ。ただし処理がクライアント側に閉じるということは、巨大なリポジトリではブラウザのメモリとタブの寿命が上限になるということで、これは設計上のトレードオフとして受け入れるしかない。

絞り込み機能はどこまで実務に耐えるか

フィルタは拡張子単位の選択、.gitignoreパターンの尊重、独自パターンの追加、ディレクトリ単位の選択という4段構成になっている。ファイルツリー上で個別に選ぶUIもあり、仮想スクロールによって10,000ファイル超のリポジトリを扱えるとREADMEは述べている。出力はクリップボードへのコピーか.txtとしてのダウンロード。トークン数はGPT換算でリアルタイムに表示され、ファイル単位のトークン数と行数も出る。ここで注意したいのは、トークン計測がgpt-tokenizerによるGPT系のトークナイザである点だ。ClaudeやGeminiに渡す場合、表示される数値は目安であって実際の消費トークンとは一致しない。上限にぎりぎりまで詰める使い方をするなら、この差は無視できない。

ローカル環境で動かす場合の手順

オンライン版は https://abinthomas.in/repo2txt/ で公開されている。手元で動かす場合、READMEのQuick Startは次の流れを示している。git clone https://github.com/abinthomasonline/repo2txt.git で取得し、cd repo2txt の後 npm install、npm run dev で開発サーバーを起動、http://localhost:5173/repo2txt/ を開く。本番ビルドは npm run build で、出力は ./dist に置かれる。テストはVitestとPlaywrightの2系統で、npm run test:unit と npm run test:e2e が用意されている。デプロイはGitHub Actionsのdeploy.ymlで、READMEのバッジがそのワークフローを指している。ソースから動かす前提の構成であり、ビルド済みの成果物を配布する形にはなっていない。npm installの依存解決が通るかどうかは、手元のNode.jsのバージョンに左右される。

READMEの性能値はそのまま受け取れない

READMEにはBundle Size約330KB（gzip後）、First Load 3G回線で2秒未満、Lighthouse 95以上、テストカバレッジ100% E2E pass rateといった数値が並ぶ。これらは計測条件も計測日も書かれておらず、どのコミット時点のものかも特定できない。リリースノートは取得できておらず、タグやバージョン番号も確認できないため、これらの数値が現在のmasterブランチの状態を反映しているかは判断できない。互換性についてもChrome 90+、Firefox 88+、Safari 14+、Edge 90+と記載があるが、これは対象ブラウザの下限を示すもので、実機検証の記録ではない。採用判断の材料としては、数値そのものより、テストが2系統用意されているという構成のほうが参考になる。

向かない場面と、代わりに使われるもの

repo2txtが向かないのは、変換をCIやスクリプトに組み込みたい場合である。ブラウザGUIが操作の起点なので、ヘッドレスで走らせて成果物をパイプラインに流す使い方は想定されていない。同種の用途では、リポジトリを1ファイルに連結するCLIツール（repomixなど）や、git archiveとfindを組み合わせた自作スクリプトが使われる。アプローチの違いは明確で、CLI系は設定ファイルやコマンド引数でフィルタを定義し、出力をファイルに落として再現できる。repo2txtは逆に、その場でツリーを見ながら選ぶ操作を重視しており、再現性よりも対話的な選別を優先している。もう1つの制約は、GitHub APIのレート制限である。トークンなしでは60回/時とREADMEにあり、大きなリポジトリを何度も読み込み直すとここで止まる。頻繁に試行錯誤するならトークンは必須と考えたほうがよい。

ライセンスと維持コストの見通し

READMEのバッジとLicense節はMIT Licenseと記載し、LICENSEファイルを参照するよう案内している。ただしリポジトリのメタデータ上はライセンスがunknownとして返っており、GitHub側がMITとして認識していない状態である。法的な判断はここではできないが、社内導入の稟議に使うならLICENSEファイルの実物を開いて確認する作業は省けない。維持コストの面では、依存がReact 19、Vite 5、Tailwind CSS 3、Zustand、JSZip、gpt-tokenizer、TanStack Virtualと多く、フロントエンドのメジャーアップデートに追随する作業が発生する。リリースが取得できていないため、更新頻度から保守の勢いを推し量ることはできない。フォークして自組織向けに改変する場合、この依存の多さがそのまま引き継がれる点は見積もりに入れておきたい。

編集部の結論

すでに手元のエディタとコマンドでリポジトリをテキスト化している人には不要だが、非エンジニアの同僚に「このリポジトリを読ませたい」と頼まれる場面や、複数ソースを同じUIで切り替えたいチームには向く。導入前に確認すべきは、LICENSEファイルの実際の内容と、READMEの性能値がどのコミット時点の計測なのかという2点。どちらもリポジトリ側の記述だけでは確定できない。

公式情報源

1. abinthomasonline/repo2txt on GitHub
2. Issues
3. Project website
4. README