日本発OSS「Repomix」がGitHubで2万8千スターを突破した。リポジトリ全体を1ファイルに畳んでClaudeやChatGPTに食わせる、いわば『AI-friendly tarball』だ。Perfect for LLM ingestionを謳うこのツールが、なぜ開発現場の必須装備になりつつあるのか。コードと仕様書から本質を読む視点で解剖する。

何が起きたか

ヤマダショウ氏（yamadashy）が開発するRepomixが、GitHubスター28,330を記録した。機能はシンプルだ。リポジトリのソースツリー全体を単一のテキストファイルに束ね、そのままLLMのコンテキストに投入できる形にパッキングする。ディレクトリ構造、ファイル内容、トークン数の概算までを一気に出力し、.gitignoreやカスタムignoreパターンでノイズを削れる。出力形式はXML、Markdown、プレーンテキストから選択可能で、Claudeが推奨するXMLタグ形式にも一発で整形できる。日本発OSSとして海外開発者の支持を集め、AIコードレビュー・仕様書自動生成・大規模リファクタの前処理として実運用に組み込まれ始めている。

なぜこのニュースが重要か

Repomixが刺さっている本質は、LLMのコンテキストウィンドウ拡大とRAGの限界が同時に露呈しているタイミングを突いたことにある。Claude Sonnetは200Kトークン、Geminiは100万トークン超をうたうが、実運用でリポジトリを丸ごと読ませようとすると、ファイル分割・エンコーディング・トークン計上で必ず前処理が要る。RAGでチャンク検索する方式は「コード全体の構造把握」が苦手で、モジュール間依存を跨ぐリファクタや仕様抽出では精度が落ちる。Repomixは「そもそも全部詰め込めるならRAGはいらない」という割り切りで、この隙間を埋めた。

エンジニア視点で見れば、これは「LLM時代のtar czf」だ。Unix哲学的に単機能で、シェルパイプに組み込みやすく、CI/CDから呼び出しやすい。派手さはないが、AI開発ワークフローの基礎インフラ層に静かに定着する類のツールで、28,330スターという数字はその普遍性を裏付けている。

技術的な深掘り

Repomixの設計で興味深いのは、トークン最適化を「圧縮」ではなく「取捨選択」で解いている点だ。--compressオプションはTree-sitterベースでコードを構文解析し、関数シグネチャとクラス構造だけを残して実装本体を削ぎ落とす。これによりTypeScriptやPythonの大規模リポジトリでもトークン数を数分の一に圧縮でき、200Kコンテキストに収まらなかったコードベースが「Perfect fit」になる。

ここに罠もある。圧縮モードは構造理解には有効だが、実装バグの検出やロジックレビューには使えない。用途で出力を切り替える運用ノウハウが必要で、無邪気にrepomix --compressをCIに組んでコードレビューを回すと、LLMは「シグネチャは正しいがロジックが破綻したコード」を見抜けない。

もう一点、セキュリティ面。Repomixはデフォルトでシークレット検出（Secretlint連携）を走らせ、APIキーや認証情報が混入した場合に警告する。ただし検出は完全ではなく、社内固有の識別子や顧客データを含むフィクスチャは素通りする。ソースコード丸ごとを外部APIに送る前提のツールである以上、DLP的なゲートウェイを別途噛ませないと、機密流出の一次責任は利用側に残る。ローカルLLM（Ollama+Qwen2.5-CoderやDeepSeek-Coder-V2）と組み合わせる構成が、現実解として推定される。

経営者として次に取るべき動き

第一に、自社リポジトリの「AI可読性」を監査せよ。命名規則の乱れ、Deadコードの放置、READMEの陳腐化は、そのままLLMの出力品質を毀損する。Repomix導入前に.repomixignoreとコード整理を進めた企業ほど、AI開発の初速で明確な差がつく。

第二に、コード送出ポリシーを今週中に策定せよ。SaaS版LLMに全ソースを投げる運用は、契約上の秘密保持義務と衝突する可能性がある。Anthropic/OpenAIのZero Data Retention契約か、社内Ollama環境か、二択の決裁ラインを引くべきだ。

第三に、開発速度3倍の主張を鵜呑みにせず、まず仕様書生成タスクで小さく実測せよ。Repomix出力→Claudeで仕様書ドラフト生成→レビュー、というパイプラインを1リポジトリで2週間試し、削減工数をKPI化する。ここで数字が出れば、全社展開の投資対効果は自明になる。