ローカルフォルダーからテキストへのコンバーター

マシン上のフォルダーを LLM 対応の 1 つのテキスト ファイルに変換します。何もアップロードされません。ファイルはすべてブラウザーで読み取られます。無料、インストール、サインアップは不要です。

ローカルフォルダをテキストに変換する：アップロードせずにコードベースを1つのファイルへ

自分のマシン上のフォルダを指定すると、1つのテキストファイルが返ってきます。先頭にディレクトリの ツリー、その下に選択したファイルが並び、それぞれパスを書いたヘッダーで区切られています。コード ベースを1つのファイルにまとめる、ソースファイルを連結する、ディレクトリを1つのドキュメントに統合 する——呼び方は何であれ、やっていることはこれだけです。LLMが最も扱いやすい形式でもあります。モデル はプロジェクトの形と中身を同時に見られるので、あるファイルが別のファイルとどう関係しているかを 踏まえて考えられます。

無料で、サインアップもインストールも不要です。フォルダを選び、モデルに不要なもののチェックを外し、 プロジェクトを1つのテキストファイルとして出力すれば、あとはどこにでも貼り付けられます。

多くの人が気にするのはここでしょう。何もアップロードされません。この処理にサーバー は一切関与しません。ファイルはブラウザ内で読み込まれ、メモリ上で組み立てられ、そのまま手元に返され ます。コードベースがクライアントのものだったり、NDAの対象だったり、単に第三者のサービスへ貼り付けて よいものではなかったりして、オンラインの変換ツールを避けてきたのなら、その懸念はここでは当てはまり ません。次のセクションでその理由を具体的に説明します。「安全なので信用してください」は、誰も受け 入れるべきでない答えだからです。

アップロードせずにソースコードをまとめてテキスト化する仕組み

最近のブラウザは、ファイルをどこにも送らずにディスクから読み取れます。フォルダを選ぶと、ブラウザは ページにファイルハンドルの一覧を渡します。それぞれを標準のFileReader APIで読み、バイト列 をタブ自身のメモリ内で文字列にデコードします。ディレクトリツリーの構築、トークン数の計算、連結、 そのすべてがあなたのマシン上で動くJavaScriptの中で完結します。fetchもXHRもAPIエンド ポイントもなく、ファイルの中身を運ぶ第三者の計測リクエストもありません。変換中にブラウザのネット ワークタブを開いておけば、何も流れないことが目で確認できます。

この仕組みには、プライバシー以外にも都合のいい副作用がいくつかあります。

  • オフラインで動きます。ページさえ読み込まれていれば、LANケーブルを抜いても変換 は動きます。エアギャップ環境や、外部通信を厳しく制限した社内ネットワークで効きます。
  • アップロード制限もレート制限もありません。APIがないので、使い切るAPIクォータも 存在しません。上限はブラウザのメモリと、あなたの忍耐力だけです。
  • コミットしていないコードでも扱えます。使い捨ての作業ブランチ、追跡していない 実験、git initすらしていないフォルダ。 GitHubリポジトリのテキスト変換は GitHub APIから読むのでこれらには手が出せませんが、こちらはディスクから読むため、バージョン管理の 状況を一切気にしません。
  • 何も残りません。タブを閉じれば状態は消えます。消すべき履歴も、ソースの控えを 持つアカウントもありません。

ローカルディレクトリを1つのファイルにまとめる3つの方法

ディレクトリピッカーからフォルダをたどるか、Finderやエクスプローラーからフォルダをそのままドロップ 領域にドラッグしてください。どちらも木構造を再帰的にたどるので、トップレベルだけでなく入れ子のサブ ディレクトリを含むプロジェクト全体が入ります。

ZIPアーカイブをドロップすることもでき、ブラウザ内で展開されます。プロジェクトをメールで送られてきた ときや、そもそも展開したくないときに便利です。ひとつ区別しておくとよいのは、アーカイブの中身が コードのプロジェクトならこのページを使う、という点です。ディレクトリツリーとファイルごとの パスヘッダーが欲しいからです。レポートや表計算、PDFといった書類の寄せ集めなら、 ZIPをテキストに変換や ZIPをMarkdownに変換のほうが 向いています。あちらはファイルをソースコードとして扱わず、各ドキュメントから読める内容を抽出します。

どのIDEでも、どのエディタでも。必要なのはフォルダだけ

入れるプラグインも、承認が要る拡張機能もありません。そもそもエディタとは連携しないからです。必要なの はディレクトリです。それがVS Codeのワークスペースでも、IntelliJ IDEAやPyCharmのプロジェクトでも、 Visual Studioのソリューションでも、Android Studioのモジュールでも、Xcodeのプロジェクトでも、Eclipseの ワークスペースでも、Neovimでしか開いたことのないフォルダでも、同じディスク上の同じファイル群です。 ピッカーでそこを指定すれば終わりです。

わざわざ書いておくのは、「VS Codeのプロジェクトを1つのTXTに書き出したい」「IntelliJのプロジェクトを 1ファイルに出力したい」といった疑問を、まずエディタ側で解決しようとする人が多いからです。たいてい エディタは探す場所として間違っています。エディタが書き出すのはファイルで、しかも1つずつです。 マーケットプレイスの拡張機能で半分だけ解決できるものもありますが、多くはそうではなく、解決の仕方も それぞれ違うので、あるIDE向けの答えは乗り換えた瞬間に無駄になります。共通項はフォルダです。

プロジェクトをZIPに固めて送るよりも筋のいい手でもあります。アーカイブは開発者どうしなら問題ありません が、チャットモデルが欲しいのはコンテナではなくテキストですし、レビューする側は1行読む前に展開しなけれ ばなりません。1つにまとめた.txtならそのまま読めます。会話に貼り、チケットに添付し、メール のスレッドに置けます。逆にあなたがZIPを受け取った側なら、先に展開せずそのままこのページへ ドロップできます。

生成する前に思い切って削る

ここが飛ばされがちで、しかも出力が使い物になるかを決める工程です。チェックボックスの木構造は最初 すべてにチェックが入っているので、そのままだとモデルが見る必要のないものを大量に含めることになります。

ひとつ有利な点があります。フォルダに.gitignoreがあれば読み込まれ、そのルールが適用され ます。ツリーの深い場所にある入れ子のものも、それぞれのディレクトリを基準に効き、コメント行は読み 飛ばされます。ふつうのリポジトリなら、手を動かす前に厄介なものの大半が静かに消えます。出力を膨らませる ものは、たいていgitに無視するよう指示済みのものと同じだからです。.gitディレクトリ自体は 常に除外されます。

とはいえ頼り切らないでください。.gitignoreがないフォルダ、たとえば展開したZIP、外注先から 渡された一式、そもそもリポジトリだったことのないディレクトリには、その保護が一切効きません。それに、 ノイズになるものの多くは正当な理由でgit管理下にあります。ツリーを眺めて、次のものはチェックを外して ください。

  • node_modules、vendor、.venv、 site-packages。依存関係のツリーは巨大で、しかも1行もあなたのコードでは ありません。整理していないnode_modulesだけで、他人のソースが数十万トークンに達する こともあります。本体のプロジェクトを飲み込み、モデルの回答はライブラリの内部実装のほうへ流れて いきます。
  • ビルド成果物——dist、build、.next、 target、out、カバレッジレポート。これも自分のコードが、圧縮または トランスパイルされて重複しているだけです。純粋なノイズです。
  • ロックファイル。package-lock.json、yarn.lock、 poetry.lock、Cargo.lock。ハッシュが数千行並ぶだけで、意味のある情報は ほとんどありません。残すのはマニフェスト（package.json、pyproject.toml）の ほうです。どのスタックを使っているかをモデルに伝えるのはそちらです。
  • 生成コードとフィクスチャ——protobufの出力、GraphQLのコード生成、データベースの マイグレーション、大きなシードデータやスナップショット。
  • 秘密情報を含むもの。何も送信されないとはいえ、出力したファイルは最終的に チャット画面へ入ります。.envは外しておきましょう。

バイナリファイルは自動で処理されます。画像、フォント、コンパイル済みの成果物などは拡張子の時点で 除外されてツリーに現れませんし、すり抜けたものもnullバイトの検査で捕まえ、文字化けを垂れ流す代わりに 短いプレースホルダーへ置き換えます。1 MBを超えるファイルもサイズを書いたプレースホルダーになる ので、紛れ込んだCSV1つがコンテキストの予算を食い潰すことはありません。

出力の先頭に置くディレクトリツリーには切り替えがあります。filteredは選択したものだけ、 fullは選択状態を印付きで示した構造全体を表示します。アーキテクチャについて尋ねるなら fullが向いています。含めていなくてもtests/ディレクトリが存在することをモデルが把握できる からです。範囲を絞って集中させたいときはfilteredのほうが適しています。

コンテキストウィンドウに収める

生成された出力には実測のトークン数が付きます。文字数を4で割った当て推量ではなく、 gpt-tokenizerライブラリで算出した値です。貼り付ける前に、使うモデルの上限と照らし合わせて ください。貼って、待って、長さ超過のエラーを読むよりはるかにましな進め方です。

どこまで送るかの目安です。プロジェクト全体を送るのは、余裕を持って収まる規模で、かつ 質問がアーキテクチャに関わるときです。「認証は実際どこで強制されているのか」「このインターフェースを 変えたら何が壊れるのか」「リクエストからデータベースまでのデータの流れを説明してほしい」といった問い ですね。こうした問いに誠実に答えるにはモデルに全体像が必要で、部分的な出力しか渡さないと、見ていない ファイルについて自信満々に推測し始めます。

質問が局所的なときは一部だけを送ります。1つのモジュールと、それを覆うテスト、そこから importしている2、3ファイルで十分です。コンテキストが小さいほど回答は鋭くなり、話も逸れにくくなります。 無差別な20万トークンより、よく選んだ5,000トークンのほうがたいてい良い結果になります。

モノレポは意識して扱う必要があります。リポジトリのルートごと変換してはいけません。 パッケージを1つずつ変換し、そのパッケージが共有の内部ライブラリに依存しているなら、そのライブラリの 公開部分も一緒に含めます。パッケージをまたいだ文脈が要るなら、2回に分けるのが有効です。1回目はファイル をほとんど選ばずツリー全体だけを渡して地図を持たせ、2回目に実際に作業するパッケージをファイルごと厚めに 渡します。

catやシェルスクリプトで済ませないのはなぜか

もっともな疑問で、正直に言えば済ませてよい場面もあります。決まった3ファイルをつなぐだけなら、ブラウザ を開くよりcat auth.py models.py routes.py > out.txtのほうが速いです。それをやめさせ ようという話ではありません。

割に合わなくなるのは、プロジェクト全体に向けた瞬間です。実際のリポジトリで find . -type f -exec cat {} +を走らせると、こうなります。

  • ソースの合間にバイナリが混ざります。PNG、フォント、コンパイル済みオブジェクト、 紛れ込んだSQLiteのフィクスチャ。すべてテキストとしてデコードされ、すべて文字化けします。そこから 拡張子のホワイトリストを保守する羽目になります。
  • 依存関係ツリーが丸ごと入ります。node_modules、.venv、 vendor、target、それに.gitの中身まで。これらを除くには 除外式を書き、関わるプロジェクトごとに最新に保たなければなりません。こちらでは、あなたの .gitignoreがすでにその内容を書いていて、入れ子のものも含めて自動で適用されます。
  • どれだけ大きいか分かりません。連結して分かるのはバイト数でトークン数ではあり ませんし、文字数を4で割るのは上にも下にも外れる推測です。収まらないことは、モデルに拒否されて 初めて分かります。
  • 選択的な制御はスクリプトが膨らみます。「src配下から生成済みのAPI クライアントだけ除き、ルートの設定ファイル2つを足す」は、フラグが1つと正規表現が1つ増えるという ことです。チェックボックスの木構造なら4クリック程度で済みます。
  • 先頭に地図がありません。素の連結は構造のヘッダーがない文字の壁なので、モデルは どこでファイルが切り替わるのかも、プロジェクトの構成がどうなっているのかも判断できません。パスで 区切られたセクションとディレクトリツリーこそ、出力を読めるものにしている部分の大半です。

どれも自作できますし、実際に作った人はたくさんいます。スクリプトを書くのに午後いっぱい、そのあとは 小さなツールを保守し続けることになります。スクリプトが欲しいのか出力が欲しいのか、という交換条件です。

実際にどう使われているか

  • 引き継いだばかりのコードベース。担当者が辞め、4万行のサービスが自分のものに なった、という状況です。変換して貼り付け、エントリポイント、主要な抽象、新しい保守担当が最も 驚くであろう3点を尋ねてください。渡されるどんな引き継ぎ資料よりも早く全体像がつかめます。
  • 実際のソースから起こすドキュメント。READMEが腐るのは一度しか書かれないから です。いま存在するコードから生成しましょう。アーキテクチャの概要、モジュールごとの要約、アプリが 実際に読んでいる環境変数の正確な一覧などです。
  • テストのないコードにテストを。対象のモジュールに加えて、書き方の見本として既存の テストを1つ含めてください。使っていないテスト規約を勝手に発明する代わりに、フレームワーク、命名、 フィクスチャの流儀をそろえてくれます。
  • 移行やリファクタリングの計画。クラスコンポーネントからフックへ、JavaScriptから TypeScriptへ、あるORMから別のORMへ。すべての呼び出し箇所を見られるモデルは、一般論のチェック リストではなく実行可能な計画を出します。
  • RAGと埋め込み。パスで区切られたセクションを持つ1つのきれいなテキストファイルは、 その区切りで分割してベクトルストアへ投入するのが簡単です。

終わったら出力をクリップボードにコピーするか、.txtファイルとしてダウンロードしてください。 同じコンテキストを複数の会話で使い回すなら、取っておく価値があります。

コードはコンテキストの半分にすぎない

プロジェクトについての現実的な問いは、ソースファイル以外のものも絡んできます。仕様はPDFに、スキーマは JSONファイルに、設定はXMLに、データはCSVにあります。そうしたものは別途変換して、コードベースの出力と 並べて貼り付けてください。仕様やベンダー資料には PDFをMarkdownに変換、 要件定義書には WordをMarkdownに変換、 APIのペイロードやスキーマには JSONをMarkdownに変換、 古い設定には XMLをMarkdownに変換、 サンプルデータには CSVをMarkdownに変換、 書き出したページにはHTMLをMarkdownに変換 があります。形式を選ぶのが面倒なら、 File2Txtが何を投げても 受け取ります。

よくある質問

フォルダをテキストファイルに変換するには？

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

コードはサーバーにアップロードされますか？

されません。この処理にはサーバーが一切登場しません。フォルダはブラウザで読み込まれ、出力もブラウザで組み立てられ、ネットワークには何も流れません。開発者ツールを開いて確かめてもいいですし、ページ読み込み後にインターネットを切断しても動きます。そこがGitHubコンバーターとの違いで、あちらはAPIを呼ばざるを得ません。

会社のコードベースをオンラインで変換して安全ですか？

このページは、その問いに約束ではなく仕組みで答えられる側です。ファイルがマシンから出ないので、こちらを信用するかどうかという話になりません。問題が残るのはその次の行動です。出力をホスト型のモデルに貼り付ければ、その提供元へは送られます。所属組織のポリシーを確認し、秘密情報を取り除いてから貼ってください。

サブフォルダを含むプロジェクト全体をまとめてテキスト化できますか？

できます。ツリー全体をたどり、どの階層でも選択できます。フォルダの選択を外せば配下がすべて一度に消えるので、node_modulesや.gitを子要素まで探し回らずに落とせます。トークンカウンターは操作に応じて更新されるため、効果はその場で確認できます。

フォルダ全体を選べるブラウザは？

フォルダ選択には、Chrome、Edge、Firefox、Safariのいずれも長年サポートしているディレクトリアップロードの属性を使っているので、現行のデスクトップブラウザなら動きます。穴はモバイルで、iOSもAndroidもフォルダピッカーを提供していません。スマートフォンではディレクトリをZIPにまとめ、ZIPをテキストに変換を使ってください。

ファイルサイズの上限は？

アップロードしないので、アップロードの上限もありません。制約になるのはマシンのメモリと、そのあとどれだけのテキストを実際に貼り付けられるかです。実務ではブラウザより先にトークンカウンターが現実的な上限になります。依存関係の選択を外したうえで有用なソースが1メガバイト以内に収まるリポジトリなら、たいていのプロジェクトが当てはまります。

ツールキットの残り

コードがローカルではなくホスティング先にあるなら、 GitHubをテキストに変換と GitLabをテキストに変換が リモートのリポジトリに対して同じ仕事をします。トークンを添えればプライベートなものも読めます。ウェブ上 にしか存在しないドキュメントには、Web2Txtが URLをきれいなMarkdownとして取得します。取得したAPIリファレンスとローカルのソースを組み合わせれば、 コーディングアシスタントが両側を同時に見られます。

もっと踏み込みたいならブログにも記事があります。 コードベースをLLM向けの1ファイルにする、 フォルダをテキストに変換するツールの 手順、 リポジトリ全体をAIに読ませるガイド、 それにコード以外のすべてを扱う ファイルのテキスト変換ガイド です。

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