ヤマダショウ氏のRepomixがGitHubで2万5千スターを突破した。リポジトリ全体を一枚のAIフレンドリーなファイルに圧縮する、まさにperfectと謳われるツールだ。だが私は問いたい。社内コードを丸ごとAIに食わせる行為は、本当にperfectな解なのか。スター数の裏に潜む構造的リスクを、誰も語らないから私が言う。
何が起きたか
Repomixは、プロジェクト内のソースコード一式を一つのテキストファイルに束ね、ClaudeやChatGPTなどの大規模言語モデルに丸ごと読み込ませやすくするOSSツールだ。2026年6月時点でGitHubスター数は25,799。OSS界隈で2万を超える時点で「ニッチな便利ツール」を脱し、デファクト候補に入る数字である。
仕組みはシンプルだ。指定ディレクトリ配下のファイルを走査し、ディレクトリツリー構造と各ファイルの中身を、AIが解釈しやすい単一フォーマットにシリアライズする。.gitignoreの尊重、トークン数の見積もり、そしてAPIキーやパスワードといったシークレットを自動検出して除去する機能も備えている。
利用シーンは個人の趣味開発者にとどまらない。社内コードをAIにレビューさせたい、リファクタ案を相談したい、ドキュメントを自動生成させたい——そうした現場ニーズに刺さり、企業利用が一気に広がっている、というのが表向きのストーリーだ。
なぜこのニュースが重要か
私が注目するのは「便利だから」ではない。逆だ。便利すぎるからこそ、企業の情報統制が一夜で崩壊するリスクを内包しているからである。
考えてほしい。これまで社内コードがAIに渡るときは、関数単位、ファイル単位の「断片」だった。レビュアーの目視も入りやすく、ヒヤリとした瞬間に止められた。だがRepomixは、その心理的摩擦を消す。ワンコマンドで全部入りのテキストが生成され、コピペひとつで外部AIに流れていく。
シークレット除去機能があるから安心、という主張も眉唾だ。除去できるのはあくまでパターンマッチで拾える既知のキー形式だけ。ビジネスロジック、未公開アルゴリズム、顧客識別子のハードコーディング、社内独自の命名規則に潜む組織情報——これらは一切フィルタされない。つまり「機密の定義」がパスワードだけだと思っている現場ほど、Repomix導入で機密を垂れ流す。
スター2.5万という数字は、利便性の勝利であると同時に、ガバナンス敗北の予告でもある。
過剰評価への反論
ナレーションは「コード監査費用を3割削れる現実的選択肢」と謳う。私はこの数字を疑う。
第一に、AIによるコードレビューは「指摘の網羅性」と「指摘の妥当性」が外注監査と等価ではない。LLMはもっともらしい誤指摘を量産する。それを精査する人件費を計上すれば、3割削減どころか逆に工数が膨らむケースを私は何度も見てきた。Repomixが解決するのは「AIに渡す前処理」だけであり、レビュー品質そのものは別問題だ。
第二に、ツール依存の罠だ。GitHubスター2.5万は確かに勢いを示すが、OSSは作者のモチベーション次第で半年後にメンテが止まる。商用のコード解析ツールと違い、SLAも責任もない。基幹業務のレビュー工程を無償OSSに寄せる経営判断は、短期的には合理的に見えて、長期的には負債化する。
第三に、「perfect for when you need...」という公式の謳い文句そのものが過剰だ。perfectなツールは存在しない。コンテキストウィンドウを超える巨大リポジトリでは結局分割が必要になり、依存ライブラリの内部実装は当然読めない。全体像を渡したつもりで、AIは「与えられた範囲のperfect」しか見ていないのだ。
スター数とユースケースの広がりに浮かれる前に、「何ができないか」のリストを作るのが経営者の仕事である。
経営者として次に取るべき動き
第一に、Repomix利用を禁止するのではなく「承認リポジトリ制」を即日整備すること。どのプロジェクトはAIに丸投げしてよく、どれは禁止か。シークレット除去機能を過信せず、ホワイトリスト方式で線を引く。これを怠った企業から情報漏えい事案が出る、と私は推定する。
第二に、AIレビュー結果の「二次レビュー責任者」を明確に置くこと。LLMの出力を鵜呑みにするエンジニアが量産されれば、コード品質はむしろ低下する。3割のコスト削減を狙うなら、削減した分の一部を必ず検証工程に再投資せよ。
第三に、OSSツールへの依存度を可視化する台帳を持つこと。Repomixが明日アーカイブされても業務が止まらない設計——代替手段の事前検証と内製スクリプトの準備——を今のうちに進めるべきだ。便利なものほど、消えたときの痛みは深い。
perfectという言葉に酔うな。疑うことから、まともな経営判断は始まる。