OneFileLLM: 複数ソースを1つのXMLに束ねるCLIの実力と境界

手作業でコンテキストを組み立てる時間を削る道具

LLMにコードベースや論文を読ませるとき、最初に発生するのは入力の収集作業だ。GitHubからファイルを落とし、PDFをテキストに変換し、YouTubeの字幕をコピーし、それらを1つのプロンプトに貼り付ける。ソースが3つを超えると、この作業だけでかなりの時間が消える。OneFileLLMはこの収集と整形を1つのコマンドにまとめる。READMEの説明では「automates data aggregation from various sources」とあり、ローカルファイル、GitHubリポジトリ、Webページ、PDF、YouTube字幕などを単一の構造化XMLに変換し、クリップボードへ自動コピーする。対象読者は、LLMに渡す資料を頻繁に切り替える開発者や研究者だ。コードレビュー、論文の要約、ドキュメントの調査といった場面で、毎回同じ手順を繰り返している人に向く。

入力の種類ごとに分岐するパーサーとXML出力

READMEとコマンドヘルプから読み取れる構造は、入力の種類を判定して専用の取得処理に振り分け、最終的に1つのXML文書へまとめるという流れだ。GitHubのURLならAPI経由でリポジトリ内容を取得し、tree/を含むURLではrefパラメータとしてブランチやタグを渡す。arXiv、PMID、DOIといった識別子はプレフィックス付きで受け付け、YouTubeのURLは字幕を取得する。ローカルパスは拡張子に応じて処理され、--formatで検出を上書きできる。出力形式はXMLで、クリップボードへのコピーが既定の動作になっている。つまりパイプでファイルに落とすのではなく、そのままチャット欄に貼る前提の設計だ。複数入力を同時に渡せる点も重要で、コマンド例ではGitHubリポジトリ、YouTube、アライアスを1行で混在させている。

導入はpipとeditable installの2通り

インストール方法はREADMEに2つ示されている。pipパッケージとして入れる場合は pip install onefilellm を実行する。CLIをソースから使う場合はリポジトリをcloneして pip install -r requirements.txt の後、プロジェクトルートで pip install -e . を実行する。editableモードではソースの変更が即座にコマンドへ反映されるため、挙動を確認しながら使う場合に向く。GitHub APIを使う場合は export GITHUB_TOKEN="your_personal_access_token" でトークンを環境変数に設定する。Pythonから呼ぶ場合は from onefilellm import run として run(["./docs/"]) のようにリストで入力を渡す。CLIの書式は onefilellm [OPTIONS] [INPUT_SOURCES...] で、例として onefilellm ./docs/ https://github.com/user/project/issues/123 が挙げられている。

アライアスとプレースホルダで繰り返し入力を短縮する

よく使う入力の組み合わせはアライアスとして登録できる。READMEの例では python onefilellm.py --alias-add mcp "https://github.com/anthropics/mcp" のように単一URLを登録する方法と、複数URLを空白区切りでまとめて登録する方法が示されている。さらに {} を含むURLを登録すると動的なプレースホルダとして機能する。gh-search や gh-user、arxiv-search といった例が挙げられており、検索クエリ部分を実行時に差し替えられる。アライアスの管理は --alias-add、--alias-remove、--alias-list、--alias-list-core の4つのオプションで行う。--alias-list-core が何を「core」として扱うかはREADMEの抜粋からは確認できない。この点は実際にインストールして --alias-list-core を実行するまで判断を保留したい。

Webクロールはオプションが多く、既定値の確認が要る

Webページを対象にする場合、クロール関連のオプションが多数用意されている。深さは --crawl-max-depth、ページ数は --crawl-max-pages、待機時間は --crawl-delay、同時実行数は --crawl-concurrency で制御する。含めるURLと除外するURLは --crawl-include-pattern と --crawl-exclude-pattern で指定する。HTML処理に関しては --crawl-no-clean-html、--crawl-no-strip-js、--crawl-no-strip-css、--crawl-no-strip-comments といった無効化フラグが並ぶ。robots.txtの尊重は --crawl-respect-robots で制御され、--crawl-restrict-path は同一パス内にクロールを限定する。PDFの取り込みは --crawl-no-include-pdfs、EPUBは --crawl-no-ignore-epubs で切り替える。オプション名からは「既定で有効な機能を無効化する」設計だと読み取れるが、各フラグの初期状態がREADMEの抜粋では明記されていない。クロールを本番で使う前に --help-topic crawling を実行して既定値を確認する必要がある。

向かないケースと代替手段の考え方

このツールは入力を1つのXMLにまとめることに特化しており、取得した内容の要約や圧縮は行わない。巨大なモノレポや数百ページのドキュメントサイトをそのまま渡すと、出力XMLがLLMのコンテキスト上限を超える可能性がある。READMEにはトークン数の自動調整や分割出力についての記述が見当たらないため、サイズ管理は利用者の責任になる。代替としては、RAGパイプラインを構築して必要なチャンクだけを検索時に渡す方式がある。OneFileLLMが「全量を1回で渡す」のに対し、RAGは「質問に応じて部分を検索して渡す」。一回性の調査や論文精読のように対象が明確で全体を読ませたい場合はOneFileLLMが向き、継続的に同じ大規模コードベースへ問い合わせる場合はRAGのほうが適する。また、認証が必要なページやJavaScriptで描画されるSPAは、クロール機能では内容を取得できない可能性がある。

ライセンスと保守の見通し

ライセンスはMITで、商用利用や改変、再配布が許容される寛容な条件だ。ただしMITライセンスは無保証であり、取得したコンテンツの権利処理は利用者側の責任になる。arXiv論文やYouTube字幕、Sci-Hub関連の取得機能を使う場合、各ソースの利用規約と著作権法の確認が別途必要になる。これは法的助言ではないため、社内で利用する場合は法務への確認を検討されたい。保守面では、リポジトリはアーカイブされておらず、最終pushは2026年6月であることが確認できる。ただし取得先のAPI仕様は外部要因で変わるため、GitHub APIやYouTube字幕取得の挙動は時間とともに壊れる可能性がある。依存パッケージはrequirements.txtで固定されているか不明であり、定期的な更新の有無はリポジトリの履歴を追う必要がある。

編集部の結論

ローカルの複数ファイル、GitHubリポジトリ、arXiv論文、YouTube字幕などをまとめてLLMに渡す用途では、OneFileLLMは入力の組み立てをコマンド1行に圧縮できる。MITライセンスなので社内ツールへの組み込みも比較的容易だ。一方、大規模リポジトリや大量のPDFを扱う場合はトークン上限と処理時間を事前に確認する必要があり、Webクロール機能を使うなら--crawl-max-pagesと--crawl-respect-robotsの挙動を実際の対象サイトで検証してから本番運用に移すべきだ。まずpip install onefilellmでCLIを入れ、自分の代表的な入力1つで出力XMLの構造とサイズを確認するのが最初の一歩になる。

公式情報源

1. Issues
2. jimmc414/onefilellm on GitHub
3. License: MIT
4. README