GitHubリポジトリをテキストに変換する：コード全体をLLMが読める1ファイルにまとめる
上の入力欄にGitHubのURLを貼ると、リポジトリのファイルツリーがチェックボックス付きで表示されます。必要なものにチェックを入れて生成すれば、テキストファイルが1つ出来上がります。先頭にディレクトリ構造、その下に選択したファイルが並び、それぞれパス入りのヘッダーで区切られます。ChatGPT、Claude、Gemini、DeepSeek、そのほか貼り付け先を選ばず通用する形式です。モデルはプロジェクトの全体像とコードを同時に見られるので、1ファイルだけを見て推測するのではなく、各部分がどう噛み合っているかを踏まえて答えられます。
クローンもインストールも会員登録も不要で、無料です。リポジトリはブラウザから直接GitHub APIで読み込むため、手元にプロジェクトを落としておく必要はありません。他人のコードを覗くとき、採用を検討中の依存ライブラリを見るとき、アクセス権をもらったばかりのリポジトリを確認するとき、まさにここが効いてきます。
URLはブランチやタグごと貼って構いません
素の https://github.com/owner/repo でも動き、その場合はデフォルトブランチが対象になります。ただしURLはそれ以上の情報を持っていて、使わないのはもったいない話です。GitHubを見ている最中にアドレスバーをコピーすれば、いま見ている状態がそのまま反映されます。
- ブランチ —
/tree/developや機能ブランチ。mainの内容ではなく、作業中のコードを変換できます。 - タグやリリース —
/tree/v2.1.0。実際に出荷しているバージョンについて質問したいとき、あるいは2つのリリースをそれぞれ変換して会話の中で比較したいときに便利です。 - サブディレクトリ —
/tree/main/packages/api。モノレポで効くのはこれです。目的のパッケージを起点にすれば、返ってくるツリーは最初から絞り込まれています。1万ファイル分のチェックを外す作業から解放されます。
ブランチやパスが存在しない場合は、どの部分が解決できなかったかが表示されます。たいていはブランチ名のタイプミスか、使っているトークンから見てプライベートなリポジトリです。
プライベートリポジトリと、トークンの行き先
プライベートリポジトリはGitHubのパーソナルアクセストークンで扱えます。GitHubの開発者設定で、必要なリポジトリへの読み取り権限を付けて発行してください。単一リポジトリに絞ったfine-grainedトークンで十分ですし、そうすべきです。トークン欄に貼れば、パブリックリポジトリと同じようにツリーが読み込まれます。
トークンは毎回入力し直さずに済むようブラウザの localStorage に保存され、送信先は1か所だけです。あなたのマシンからリクエストヘッダーに載って api.github.com へ行くだけで、それ以外はありません。トークンを紐づけるアカウントもなければ、経路上に当方のバックエンドもありません。欄を空にすればストレージからも消えます。共有マシンなら作業後にクリアしてください。確実を期したいなら、あとからGitHub側でトークンを失効させれば済みます。ワンクリックで、コストはゼロです。
トークンはパブリックリポジトリでも役立ちます。未認証のGitHub APIリクエストはレート制限がかなり厳しいので、大きなリポジトリを変換する場合や、続けて何個も処理する場合、トークンの有無が「動く」か「1時間待つ」かの分かれ目になります。
生成する前にチェックを外すべきもの
出力が使い物になるかどうかは、この工程で決まります。リポジトリには、バージョン管理する理由はあってもモデルへの入力としては無価値なファイルが大量に含まれています。ツリーを見て、次のものは落としてください。
- ベンダリングされた依存 —
node_modules、vendor、third_party。リポジトリに入っていること自体は稀ですが、入っていると壊滅的です。他人のソースコードが自分のコードを完全に押し流します。 - ビルド成果物 —
dist、build、out、.next、target、カバレッジレポート。トランスパイルなり圧縮なりされた自分のコードなので、モデルは同じものを2回読んで、2回目からは何も学びません。 - ロックファイル —
package-lock.json、yarn.lock、poetry.lock、Cargo.lock。ほとんど意味を持たないハッシュが数万トークン分あるだけです。代わりにマニフェストを残してください。使っている技術スタックをモデルに伝えるのはpackage.jsonやpyproject.tomlのほうです。 - 生成コード — protobufやgRPCの出力、GraphQLのcodegen、OpenAPIクライアント、DBマイグレーション、スナップショットテスト。機械が書いた繰り返しの多い内容で、しかもどうせ再生成されるファイルをモデルが直そうとし始めます。
- 大きなデータファイル — フィクスチャ、シードのダンプ、サンプルのCSV、何年も前にコミットされた圧縮済みバンドル。この手のファイルは1つでコンテキストウィンドウを食い潰します。
リポジトリが大きいときは拡張子での絞り込みが手っ取り早い方法です。.ts と .tsx だけ、あるいは .py だけに絞れば、ノイズの大半が一手で消えます。そのうえで、プロジェクトを説明している設定ファイルやドキュメントを数点だけ戻します。READMEと主要な設定、スキーマあたりです。
結局いちばん重要なのはトークンカウンター
生成された出力にはトークン数が付いてきます。文字数を4で割った概算ではなく、gpt-tokenizer ライブラリで計算した値です。貼る前に必ず確認してください。これから使うコンテキストウィンドウに収まるかどうかが事前に分かること、それがすべてです。分からないまま進めると、貼って、待って、長すぎるというエラーを読むはめになります。
確認するだけでなく、舵取りに使ってください。上限の倍もあるなら、末尾で切り詰めるのではなくツリーに戻ってディレクトリのチェックを外します。途中で切れたダンプは、モデルに実装の半分だけを渡したうえに、欠けていること自体を気づかせません。それと、コンテキストウィンドウが広いことと質が高いことは別物です。対象のモジュールとそのテスト、importしている2ファイルに絞った8,000トークンのほうが、何もかも詰め込んだ20万トークンよりたいてい上です。設計レベルの質問ならリポジトリ全体を、局所的な質問なら一部だけを渡してください。
出来上がったら、テキストをクリップボードにコピーするか、.txt としてダウンロードします。1つに結合された文書よりファイルのままがよければ、選択したファイルをZIPで取得することもできます。
使い方
実際にどう使われているか
- 知らないコードベースのキャッチアップ。 転職先、異動先のチーム、コントリビュートしたいOSS。変換して貼り、エントリポイントと中心的な抽象、そして新任メンテナが驚くであろう点を3つ挙げてもらいます。READMEを読んで1日ファイルをクリックして回るより、はるかに早く土地勘がつきます。
- プルリクエストを周辺ごとレビューする。 差分は何が変わったかを示しますが、何に影響するかは示しません。ブランチ全体、あるいは該当パッケージだけを変換して、変更された関数をほかにどこが呼んでいるか、新しいコードがその関数に何を前提しているかを聞きます。
- 実態と合ったドキュメントを書く。 READMEが腐るのは一度しか書かれないからです。アーキテクチャの概要、モジュールごとの要約、環境変数の本当の一覧を、今日のmainのコードから生成します。
- テストを書かせる。 対象モジュールに加えて、既存のテストファイルを1つスタイルの見本として入れておきます。モデルが誰も使っていない流儀を発明せず、こちらのフレームワーク、命名、フィクスチャに合わせてくれます。
- 移行やリファクタリングの計画。 クラスコンポーネントからフックへ、JavaScriptからTypeScriptへ、あるORMから別のORMへ。呼び出し箇所を全部見られるモデルは、汎用的なチェックリストではなく実際の手順を出してきます。
- 監査やデューデリジェンス。 引き継ぐ、買収する、あるいは依存先として検討しているリポジトリの評価です。1ファイルにまとまっていれば、機密情報がどこで扱われているか、エラー経路がどうなっているか、危ういパターンがどこにあるかを現実的に質問できます。
- RAGや埋め込み。 パスで区切られたセクションはきれいに分割できるので、ほとんど前処理なしでベクトルストアに投入できます。
よくある質問
GitHubリポジトリをテキストファイルに変換するには？
上の欄にリポジトリのURLを貼ると、ファイルツリーがチェックボックス付きで表示されます。モデルに要らないものを外して生成すれば、テキストファイルが1つできます。先頭にディレクトリ構造、その下に選択した各ファイルがパス入りのヘッダー付きで並びます。クローンもインストールも不要、無料で会員登録もありません。
プライベートなGitHubリポジトリを変換するには？
URLと一緒にパーソナルアクセストークンを貼ってください。そのリポジトリ1つだけに絞ったfine-grainedトークンを、Contentsの読み取り専用権限と短い有効期限で作成します。この用途でAPIが受け付ける最小権限がこれです。トークンはブラウザからGitHubを呼ぶために使われるだけで、当方には保存されません。
自分のコードベースは何トークンで、コンテキストに収まりますか？
カウンターはファイルにチェックを入れるたびに更新されるので、何かを貼る前に数字が分かります。目安として、ソースコードは1トークンあたり3〜4文字程度なので、500 KBの選択で14万トークン前後になります。200Kのコンテキストウィンドウには収まりますが、たいていのチャットUIでは1メッセージには収まりません。
リポジトリをLLMに渡す前に除外すべきファイルは？
まず node_modules、vendor、その他の依存ディレクトリです。バイト数の圧倒的多数を占めるうえ、自分のコードについては何も語りません。次にロックファイル、ビルド成果物、圧縮済みバンドル、テストのフィクスチャ、バイナリ素材。典型的なJavaScriptプロジェクトなら、この一手だけでトークンの9割以上が消えることも珍しくありません。
gitingestやrepomix、code2promptとはどう違いますか？
どれも良いツールで、正直なところ差は機能ではなくワークフローです。あちらはコマンドライン前提でスクリプトに組み込めるので、CIやバッチ処理の中ならそちらが正解です。こちらはブラウザのタブ1つで、チェックボックス付きのツリーを見ながらリポジトリを眺め、要らないものを外し、トークン数が動くのを確認できます。何を含めるかまだ決めかねている単発の作業に向いています。
自分のコードをここに通しても大丈夫ですか？
パブリックリポジトリはブラウザからGitHub APIで読むので、コードはGitHubからあなたへ直接届きます。機密性のあるものなら、ローカルフォルダ変換のほうが確実です。こちらは一切アップロードしません。いずれの場合も、モデルに貼る前にAPIキーや認証情報が混ざっていないか選択内容を確認してください。ここを飛ばす人が多いのです。
ローカルフォルダ、GitLab、そしてコード以外のすべて
変換したいものがGitHubにあるとは限りません。 ローカルフォルダをテキストに変換するツールは、ディスク上のディレクトリをそのまま読んで1ファイルに結合します。アップロードは一切なく、ネットワーク通信も発生しません。受託案件のコード、未コミットのブランチ、そもそもgitリポジトリですらないプロジェクトには、これが必要です。GitLabなら GitLabをテキストに変換するツールが、パブリック・プライベート・セルフホストのいずれのプロジェクトでも同じ仕事をします。
それに、コードは文脈の半分でしかないことがほとんどです。仕様はPDF、スキーマはJSON、古い設定はXML、サンプルデータはCSVという具合です。リポジトリと一緒に PDFからMarkdown、 JSONからMarkdown、 XMLからMarkdown、 CSVからMarkdown、 HTMLからMarkdownで変換してください。アーカイブを渡された場合は ZIPからテキストが中身の読める部分を取り出しますし、ページを選ぶのが面倒なら File2Txtが対応13形式すべてを受け付けます。Web上にしか存在しないドキュメントには Web2Txtがあり、JavaScriptで描画されるページも含めてURLをきれいなMarkdownに変換します。取得したAPIリファレンスと変換済みリポジトリを組み合わせれば、コーディングアシスタントが両側を同時に見られます。
ブログではもう少し踏み込んで書いています。 GitHubリポジトリをLLM向けに変換する完全ガイド、 コードベースをLLM向けの1ファイルにする方法、 リポジトリ丸ごとをAIに読ませる、 ローカルディレクトリについては フォルダからテキストへの手順解説 をどうぞ。
Repo2Txtの開発と運用は v12heroが行っています。プライバシーを最優先にネイティブアプリとWebアプリを作っている個人開発者です。