GitLab リポジトリからテキストへのコンバータ

GitLabリポジトリをテキストに変換する：LLMが本当に読める1つのファイル

チャット画面にコードを1ファイルずつ貼っていくのは、午後の潰し方として最悪の部類です。モデルは鍵穴 から覗いたような視野で毎回答え、こちらは「待って、これがimportしている別のファイルはこれ」と言い 続ける羽目になり、文脈がそろう頃には会話そのものが脱線しています。対処法は地味で、そして効きます。 関係するリポジトリの範囲を最初にまとめて、1つのテキストの塊として渡すことです。

このページがやるのはそれです。GitLabのリポジトリからLLMのコンテキストまでの最短経路になります。 https://gitlab.com/...のプロジェクトURLを貼ると、GitLabのAPI経由でリポジトリの木構造を 読み取り、全ファイルがチェックボックスのツリーとして並びます。必要なものにチェックを入れ、不要な ものはチェックを外し、生成を実行してください。ディレクトリの地図に続いて、選んだファイルの中身が まるごと出てきます。収まるかどうか分かるようにトークン数も付きます。コピーする、テキストとして ダウンロードする、選択したファイルをZIPで受け取る、どれでもかまいません。

いま見ているURLをそのまま貼る

調べておくプロジェクトIDも、名前空間を入れる別の欄もありません。ブラウザのアドレスバーからURLをコピー して貼るだけです。入れ子のサブグループにも対応しています。GitLabでよくある company/platform/services/billingのように3階層も4階層も下に埋まったプロジェクトも、 APIに渡す前にプロジェクトパスをURLエンコードしているので問題ありません。

コピーしたURLにブランチやタグが含まれていれば、そのrefが使われます。素のプロジェクトURLだけなら、 既定のブランチが自動で解決されるので、このリポジトリがmainなのかmasterなのか developなのかを思い出す必要はありません。ツリーは再帰的に、ページングしながら取得します。 これは地味に見えて重要で、GitLabのモノレポは数千ファイルに達することが珍しくなく、ページングなしの 1リクエストでは黙って途中までのプロジェクトが返ってくるからです。

プライベートプロジェクトと、トークンの行き先

公開プロジェクトには何も要りません。非公開のものにはGitLabのパーソナルアクセストークンを添えてください。 トークンはPRIVATE-TOKENヘッダーとして GitLabのAPIへの リクエストに載ります。ウェブツールにトークンを貼ることを警戒するのは正しい感覚なので、そのまま書いて おきます。トークンはブラウザのlocalStorageに保存され、あなたのブラウザから gitlab.comを直接呼ぶためだけに使われます。こちらのサーバーには送られません。そもそも リクエストがそこを経由しないからです。

必要な権限は読み取りだけで、read_apiかread_repositoryで足ります。使いもしない 書き込み権限を渡さないでください。トークン画面にいるうちに有効期限も設定しておきましょう。公開リポジトリ でもトークンを添える価値はあります。GitLab APIへの未認証の呼び出しにはレート制限があるので、大きな プロジェクトを取得するときや同じ変換を何度か回すときは、認証済みかどうかが、すんなり取得できるか エラーの壁に当たるかの分かれ目になります。

セルフマネージドのGitLabについて、正直なところ

このツールが話す相手はgitlab.comで、gitlab.comだけです。独自インスタンスのURLを入れる欄はなく、 gitlab.yourcompany.internalを貼っても動きません。セルフホストやセルフマネージドの インスタンスをお使いなら、答えはきっぱり「無理」です。

ただ、セルフマネージドのインスタンスに対する良い答えは、もともとAPI呼び出しではありませんでした。 リポジトリをcloneして（認証情報はすでにお持ちのはずです）、そのフォルダを ローカルディレクトリの変換ツールに 渡してください。ブラウザのファイルAPIで読むので、何もアップロードされず、マシンの外へは出ません。 社内ファイアウォールの内側にあるインスタンスなら、どのみちセキュリティ担当が求めるのはそちらの形です。 同じチェックボックスのツリー、同じ出力、同じトークン数です。cloneよりアーカイブを書き出したい場合は、 ZIPも受け付けます。

GitLabのソースコードをまとめて出力するとき、何を選び何を外すか

最初はすべてにチェックが入っていますが、実際のプロジェクトでそれが正しい選択になることはまずありません。 GitLabのリポジトリをテキストに変換するとき、つい全部を持っていきたくなります。そこは我慢してください。 使えるリポジトリの出力は取捨選択されたものです。生成されたノイズに使ったトークンの分だけ、モデルが 本来のコードに使える分が減ります。まずは次のチェックを外しましょう。

• ベンダリング済み・インストール済みの依存関係——node_modules、vendor、 .venv、パッケージレジストリから入れてコミットしたもの一式。Expressがどんなコードかは モデルもすでに知っています。
• ロックファイル。package-lock.json、yarn.lock、 poetry.lock、Gemfile.lock。ロックファイルは数万トークンのハッシュと バージョン固定になることもありますが、誰かが尋ねる問いに答える情報は入っていません。マニフェストを 残し、ロックは落としてください。
• ビルド成果物と圧縮済みアセット——dist、build、 .next、コンパイル済みバンドル、ソースマップ。これも自分のコードが、何も推論できない形 で言い直されているだけです。
• スナップショットとフィクスチャ。大きなテストフィクスチャやスナップショットは、 設計上どうしても繰り返しになります。代表的なものが2、3あれば400個分の価値があります。
• マイグレーションは、たいてい不要。6年分の差分マイグレーションが積み上がった スキーマのディレクトリを含める価値があるのは、マイグレーションの履歴そのものが論点のときだけです。

意図を説明するものは残してください。ソースファイル、README、マニフェスト、そして .gitlab-ci.ymlです。最後のものはGitLabならではの勘所で、CIの設定にはビルド手順、テスト コマンド、デプロイ先、環境の前提が1か所にまとまっています。これを含めておくと、「なぜCIでは落ちて ローカルでは通るのか」にモデルが推測ではなく根拠で答えられます。

ディレクトリ表示の切り替えがもう半分です。Fullにすると、選択したファイルに印を付けた リポジトリ構造の全体が出力に入るので、含めていなくてもpaymentsモジュールが存在することを モデルが把握できます。文脈として有用で、トークンの消費も少ない部分です。Filteredに すれば、選択したものだけが出ます。モノレポから1つのサービスを選んだときはたいていFullが既定として 適していますし、絞り込んだ数ファイルを送るときはFilteredのほうが整理されて見えます。

これが本当に得意な仕事

• 知らないプロジェクトに入る。ソースのディレクトリ、README、CIの設定を選び、 エントリポイントと、リクエストが届いてからどこを流れるのかを説明してもらってください。20分かかる 全体把握が、1つのプロンプトに圧縮されます。
• マージリクエストを周辺ごとレビューする。差分は何が変わったかは教えますが、変わった 関数を他にどこが呼んでいるかは教えません。触れたディレクトリとその近隣を出力し、差分を並べて貼れば、 体裁ではなく影響についてのレビューコメントが返ってきます。
• 誰も書かなかったドキュメントを書く。モジュールを渡して、README、アーキテクチャの メモ、あるいはコードの既存の書き方に沿ったdocstringを求めてください。新しい流儀を勝手に持ち込まれる ことがなくなります。
• テストを生成する。対象のモジュールに加えて既存のテストを2、3ファイル含めてください。 後半こそが出力を使い物にする部分で、モデルはフィクスチャ、命名、アサーションの書き方をまねるので、 テストスイートから浮いたものが出てきません。
• 移行やアップグレードの作業。フレームワークのバージョン上げ、言語の書き換え、ORMの 差し替え。呼び出し箇所を漏らさないにはコードベース全体が見えている必要があり、それこそ1つの テキスト出力が与えるものです。
• 監査。秘密情報がどこで読まれているか、どのエンドポイントが認証を飛ばしているか、 非推奨の内部APIをまだ叩いているのはどこか。この手の広い問いは、ファイルを1つずつ見ても答えが 出ません。

これらの多くで焦点になるのは、グループ全体ではなく1つのサービスのディレクトリです。その部分木を選び、 残りは置いておき、貼る前にトークン数を確認してください。数値はgpt-tokenizerライブラリで 出しているので、推測ではなく、使うモデルのコンテキストウィンドウとそのまま比較できる実測値です。 GitLabのコードをAIのレビューにかけるときも、GitLabのプロジェクトをChatGPTやClaude、Gemini向けの テキストファイルにするときも、出てくるものは同じです。1つのファイルで、送る前に自分で読めます。

コードの隣に置かれているファイル

リポジトリにあるのはソースファイルだけではありません。設定、スキーマ、シードデータ、仕様も一緒に コミットされていて、そのまま吐き出すと読みにくいものもあります。構造化された形式はMarkdownにしたほうが 収まりがよくなります。設定やAPIのペイロードには JSONをMarkdownに変換、 MavenやAndroid、いまだに残るSOAPのファイルには XMLをMarkdownに変換、 シードデータやエクスポートには CSVをMarkdownに変換、 テンプレートや生成済みのドキュメントには HTMLをMarkdownに変換が あります。PDFで届いた仕様書も 変換できますし、ZIPアーカイブは そのままテキストへ展開できます。ページを選ぶのが面倒なら File2Txtがまとめて引き受けます。

よくある質問

GitLabリポジトリをテキストファイルに変換するには？

上でプロジェクトURLを貼ると、ファイルの木構造がチェックボックスの一覧として読み込まれます。必要なファイルを選び、1つのテキストファイルとして出力してください。先頭にディレクトリ構造、その下に各ファイルがパスのヘッダー付きで並びます。無料、インストール不要、サインアップ不要です。

セルフホストのGitLabでも使えますか？

セルフマネージドのインスタンスもgitlab.comと同じREST APIを公開しているので、到達できるインスタンスなら同じように動きます。問題はネットワークの到達性です。社内VPNやプライベートネットワークの内側にあるインスタンスにはブラウザのタブから届きませんし、トークンを何枚積んでも変わりません。その場合はプロジェクトをcloneしてローカルフォルダの変換ツールを使ってください。

プライベートなGitLabプロジェクトを変換するには？

read_repositoryスコープのパーソナルアクセストークンを渡してください。「Preferences」→「Access Tokens」で作成し、作業時間をぎりぎり覆う程度の短い有効期限を設定し、終わったら削除します。必要なのは読み取りだけで、書き込みやAPI全体のスコープを持つトークンは、作業に対して余分な露出になります。

cloneするのではなく、これを使う理由は？

cloneして手に入るのは作業ツリーで、この用途には形が合いません。モデルが欲しいのは、構造と中身が一緒に入っていてノイズが落ちた1つのドキュメントです。cloneでは履歴も依存関係も丸ごと取ってくるので、実際に考えたいソースよりはるかに多いバイト数になるのが普通です。

サブグループや入れ子のプロジェクトパスにも対応していますか？

対応しています。GitLabの入れ子グループの構造上、プロジェクトのパスは何段階も深くなり、その完全なパスがプロジェクトを識別します。手で組み立てるのではなく、ブラウザのアドレスバーからURLをそのままコピーして貼ってください。そうすれば正しく解決されます。

プロジェクト全体ではなく、マージリクエストの差分だけ変換できますか？

このページからはできません。扱うのは指定したrefのリポジトリツリーです。レビュー用途でよく使われるのは、マージリクエストが触れたファイルを変換して文脈として貼り、その下に差分そのものを貼るという手順です。変更の是非を判断するには周辺のコードが要りますが、差分だけではまず足りません。

ツールキットのその他

コードがGitHubにある場合は、GitHubリポジトリを テキストに変換が同じように動きます。手元のマシンにしかない場合や、セルフマネージドのインスタンスから cloneした場合は、ローカルディレクトリの 変換ツールを使ってください。ソースではなくドキュメントサイトのほうが必要なら、 Web2TxtがURLをMarkdownとして 取得します。

この辺りの背景をもう少し長く書いたものとして、 リポジトリをAIモデルに読ませるガイド、 コードベースをLLM向けの1ファイルにする記事、 LLM向けにリポジトリを変換する完全ガイド、 それにもう少し広くAIツール向けにファイルを整える話があります。

Repo2Txtは、プライバシーを重視したネイティブアプリとウェブアプリを作る独立系開発者 v12heroが 開発・保守しています。