GitHubで2万7千スターを突破したRepomix。ソースコード一式を1ファイルに束ねてAIに丸食いさせる「AI-friendly」ツールが、開発現場を席巻している。だが、この熱狂は本当にperfectなのか。誰も口にしないリスクを、まず私が言う。
何が起きたか
ヤマダショウ氏（yamadashy）が開発したRepomixが、GitHubスター数27,635を記録した。用途は明快だ。リポジトリ全体を1つのテキストファイルに圧縮し、ClaudeやChatGPTにコンテキストごと丸投げする。従来、ファイル単位でしか読ませられなかったコードベースを、AIに「全体像として」認識させることができる。
結果、バグ調査の突き合わせ、仕様書の自動生成、レガシーコードの解読といった作業が、明らかに加速している。README上のキャッチコピーは "Perfect for when you need..."。この "perfect" という一語が、開発者コミュニティの飢餓感をよく表している。要するに、既存のAIコーディング環境は「コード片を渡すことしかできない」という致命的な不便を抱えていた、ということだ。Repomixはその隙間を、驚くほど素朴なアプローチ（テキスト連結）で埋めた。技術的発明ではなく、運用発明である。
なぜこのニュースが重要か
経営者がこれを「開発現場の便利ツール」と片付けるなら、判断ミスだ。Repomixの本質は、自社の全ソースコードを外部AIベンダーのサーバーに一括送信する運用が、現場で既に常態化しつつあるという事実にある。
CTOも法務も知らないうちに、若手エンジニアが「便利だから」という理由で、基幹システムのソースをOpenAIやAnthropicに流している。これはコピペとは訳が違う。Repomixは「まとめて渡す」ことを前提設計にしている以上、送信されるのは断片ではなく設計思想と資産の総体だ。競合が同じツールでリバースエンジニアリングを試みたら、あなたの十年分の知的資本は、プロンプト一発で外部モデルの学習素材と同等の粒度で露出する。
さらに悪いのは、多くの日本企業が「AI利用ポリシー」を、まだファイル単位のコピペ想定で書いていることだ。ルールが現実に追いついていない。この乖離を放置した企業から、数年内に情報漏洩事故が続発すると私は推定する。
過剰評価への反論
「AIに丸ごと読ませれば属人化が解消する」──ナレーションのこの主張は、半分嘘だ。
第一に、Repomixが渡せるのはコードとコメントだけである。ベテランの頭の中にある「なぜこの設計を捨てたか」「どの顧客のためにこの分岐を残しているか」という意思決定の履歴は、コードには書かれていない。AIが吐き出すのは、あくまで表層の構造説明にすぎない。属人化の本丸である暗黙知は、微塵も溶けない。
第二に、「新人でも構造を把握できる」も楽観的すぎる。20万行のコードをAIが要約したところで、新人がその要約を評価する眼力を持たなければ、誤読した仕様書を根拠に改修が走るだけだ。むしろ「AIが言ったから」という新種の思考停止を生む。
第三に、2.7万スターという数字への礼賛にも待ったをかけたい。GitHubスターはブックマーク的性格が強く、実運用者の数を反映しない。「試したが本番投入していない」層が大半だと想定する。バズと定着を混同すべきではない。Repomixは便利だが、"perfect" とはほど遠い。少なくとも、機密管理・要約精度・トークンコストの三点で明確な欠陥を抱えている。
経営者として次に取るべき動き
第一に、今週中にエンジニア組織へ「Repomix類似ツールの利用実態」をヒアリングせよ。禁止ではなく、まず可視化だ。使っていない企業はほぼ存在しないと想定する。知らないのは経営者だけ、という状況を終わらせる。
第二に、AI利用ポリシーを「ファイル単位」から「リポジトリ単位」の想定に書き換える。外部送信の対象範囲、マスキング義務、送信ログの保管、この3点を明文化する。オンプレ版LLMまたはVPC内API利用への段階的移行予算を、次期期中に確保すべきだ。
第三に、自社の「AIに食わせやすい資産」を棚卸しする。整理されていない設計書、Wiki、議事録は、そのままではAIの燃料にならない。Repomix的発想を社内ドキュメントに拡張し、構造化テキストとして残す文化を作った企業だけが、次の3年で優位に立つ。便利さの裏で、勝敗は静かに決まりつつある。