ripgrepを自動除外と正規表現検索の実務で使う
ripgrep は正規表現でディレクトリを再帰的に検索するコマンドラインツール。デフォルトで gitignore ルールを尊重し、隠しファイルやバイナリファイルを自動的にスキップする。
ひと目でわかる
- これは何？
- ripgrepのrgコマンドがgitignore、隠しファイル、バイナリをどう扱い、-uuuや型指定で検索範囲を変えるかを整理します。
- 誰に向いている？
- ripgrepはコードリポジトリで、Git管理の対象を正規表現で再帰検索したい開発者に向きます。バックアップ媒体やバイナリを含む全探索が常に必要なら既定の除外を解除する設計が要ります。
- 商用利用できる？
- できます。Unlicense は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 42 日前です。
- 何の言語で書かれている？
- 主に Rust です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月14日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
rgの既定範囲を理解する
ripgrepは現在のディレクトリを再帰的に検索する行指向のツールです。READMEでは、既定でgitignoreの規則に従い、hidden files/directoriesとbinary filesを自動的に飛ばすと説明されています。コード検索で不要な生成物や依存ディレクトリを避ける設計ですが、対象を暗黙に狭める挙動でもあります。
全ての自動filteringを無効にする入口はrg -uuuです。.gitignore、.ignore、.rgignoreのどれが効いたかを意識し、検索結果が少ないときは除外規則を調べます。まず小さなリポジトリで、追跡ファイル、ignored file、hidden file、binary fileを一つずつ置き、既定結果と-uuuの差を記録すると、コマンドの意味を取り違えません。
正規表現と行番号の出力
READMEの基本例はrg -n -w '[A-Z]+_SUSPEND'のように、行番号と単語境界を指定して検索します。Unicode対応の正規表現、文字クラス、リテラル最適化を利用でき、結果は行単位で返ります。検索語を広くしすぎるとマッチ件数が増え、端末出力と処理時間の双方へ影響します。
単一ファイルとディレクトリ全体では挙動を分けて確認します。-nを付けると行番号出力のコストが変わる例がREADMEにあり、結果を別処理へ渡す場合は行番号の形式も入力仕様になります。正規表現が意図した行だけを拾うか、エスケープとshellの引用を含めた実際のコマンドでテストします。
-tと-Tでコード種別を絞る
ripgrepはファイル種別による検索に対応します。READMEにはrg -tpy fooでPythonだけを対象にし、rg -Tjs fooでJavaScriptを除外する例があります。新しいファイル種別を教える設定もGUIDEに案内されています。拡張子だけでなく、既定filteringと組み合わせた結果を読む必要があります。
型指定は検索対象を明確にする一方、拡張子のないスクリプトや生成コードを落とします。Pythonプロジェクトで.py、設定ファイル、テンプレートを別々に検索し、必要な対象が抜けていないか確認します。CIのコマンドを共有するなら、.ignoreとtype定義をリポジトリへ置くか、実行環境に依存させるかを決めます。
ベンチマークは条件付きの数字
READMEにはLinux kernel source treeや大きな単一ファイルで他ツールと比べた数字があります。例ではUnicodeのripgrepが0.082秒、別の検索が0.063秒と記載され、13GB級の展開済みファイルでは1.042秒という測定も示されています。これらは特定CPU、入力、正規表現、キャッシュ状態での結果です。
README自身が一つのbenchmarkだけでは足りないと注意しています。リテラルを含む検索、長い正規表現、高いmatch count、-nの有無で差が変わります。自環境では対象リポジトリ、ロケール、ストレージ、warm cacheを固定し、時間だけでなく行数が一致するかも比べます。
巨大ファイルと全件ヒットの崖
ripgrepでも全ての検索が同じ速度になるわけではありません。READMEは[A-Za-z]{30}のようにリテラル最適化の余地が少ないパターンや、rg theのように大量にマッチする検索では性能差が縮まる、または処理量が支配的になると説明します。高速という性質を、任意の正規表現に対する時間保証として扱えません。
本番のログ調査では、対象ファイルのサイズ、検索語の出現密度、出力先を先に決めます。端末へ数千万行を流すより、-lでファイル名だけを得る、必要な型に絞る、結果を保存するなど、目的に応じた出力を選びます。タイムアウトがある自動処理では、遅いパターンを小さなサンプルで発見します。
配布、設定、Unlicense
ripgrepはWindows、macOS、Linuxをfirst class supportの対象とし、各releaseにbinary downloadがあるとREADMEに記載されています。CHANGELOG、User Guide、FAQ、regex syntax、configuration file、shell completions、buildingへのリンクもあります。導入後はrg --versionと検索結果を固定し、OS間でshellの引用差を確認します。
ライセンスはMITまたはUNLICENSEのデュアルライセンスです。社内配布や組み込みではリポジトリの条件を確認します。素材のreleaseには15.2.0が含まれます。更新時は既定のignore挙動、Unicode、type指定、終了コードを同じテストツリーで再確認し、見つからなかったファイルが運用上問題にならないことを確かめます。
検索結果と終了コードを固定する
ripgrepの試験ツリーには追跡ファイル、ignore対象、hidden file、binary file、空白を含む名前を置きます。rg -n、rg -tpy、rg -uuuを同じ語で実行し、行数、ファイル数、除外結果を比較します。matchあり、matchなし、引数エラー、権限エラーの終了コードをCIの条件と照合します。巨大ファイルでは出力を端末へ流さず、語の出現密度と正規表現の形を変えて時間を測ります。Unicodeとロケールも固定し、15.2.0へ更新した後に検索対象が変わらないことを確認します。ファイル名出力を別処理へ渡す場合は、改行や空白を含む名前の扱いを確認し、端末表示用の結果と機械処理用の結果を分けます。改行や空白を含む名前の扱いを確認し、端末表示用の結果と機械処理用の結果を分けます。改行や空白を含む名前の扱いを確認し、端末表示用の結果と機械処理用の結果を分けます。実施記録には対象版と入力条件を残し、成功した結果だけでなく失敗した場合の出力も保存します。設定を変更した前後で同じ確認を繰り返せるようにし、READMEに書かれた機能と自分の環境で確認できた事実を分けます。採用判断では、導入できたかだけでなく、更新、障害、切り戻し、権限、ライセンスを同じ担当者が追跡できるかを確かめます。
BurntSushi/ripgrep の star 数は README 本文に無い
README取得時点のメタデータ（スター数、フォーク数、未解決issue件数）はREADME本文に含まれず、GitHubリポジトリページから得た補助情報です。これらの数値は採用判断の唯一の根拠にはなりません。評価では必ず公式ドキュメント、リリースノート、LICENSEファイルを参照し、READMEがリンクする一次資料と照合してください。
burntsushi-ripgrep-deep-analysisのREADMEは、上記各節で引用した機能説明と手順以外の運用保証（SLA、性能数値、セキュリティ監査結果）を提供していません。
編集部の結論
ripgrepはコードリポジトリで、Git管理の対象を正規表現で再帰検索したい開発者に向きます。バックアップ媒体やバイナリを含む全探索が常に必要なら既定の除外を解除する設計が要ります。導入前にrg -n、-t、-uuuを同じ小さなツリーで比べ、.gitignoreの影響、Unicode、巨大ファイル、マッチ件数、終了コードを確認してください。
コミュニティノート