findとgrepを組み合わせて文字列を含むファイルを検索
特定の文字列を含むファイルを探すならfindとgrepの組み合わせが便利！
みなさん、こんな経験はありませんか？「システムでエラーが起きたから原因を調べたいのに、対象のファイルがどこにあるかわからない……」。私もエンジニアになりたての頃、数万件もあるログファイルの山を前に途方に暮れたことがあります。手作業で一つひとつファイルを開いて確認するなんて、気が遠くなりますよね。
実は、そんな悩みを一瞬で解決してくれる強力なコマンドがLinuxには用意されています。それが「find」と「grep」を組み合わせた検索テクニックです。この2つのコマンドを掛け合わせることで、膨大なファイルの海から特定の文字列を含むファイルを爆速で見つけ出すことができるようになります。
なぜfindとgrepを組み合わせる必要があるの？
まずはなぜこの2つのコマンドを組み合わせる必要があるのか、その理由からお話ししましょう。findコマンドは「ファイルを探す」ことに特化したコマンドで、grepコマンドは「ファイルの中身の文字列を探す」ことに特化したコマンドです。つまり、それぞれ単体では得意なことが違うんですね。
例えば、findコマンドだけでは「ファイル名はわかるけど中身はわからない」という状態になります。逆にgrepコマンドだけでディレクトリ全体を検索しようとすると、「すべてのファイルを順番に開いて確認する」ため、対象ファイルが多いと時間がかかってしまいます。
しかし、この2つを組み合わせると魔法のようなことが起こります。findコマンドで「条件に合致するファイルだけをピックアップ」し、その結果をgrepコマンドに渡して「中身の文字列を検索」する。この分業体制により、驚くほど効率的な検索が実現するのです。
私は以前、本番環境で謎のエラーが発生した際、数千あるログファイルから特定のエラーメッセージを探さなければならない事態に直面しました。手動で探していたら何日かかっても終わらなかったでしょう。でもfindとgrepを組み合わせることで、わずか数秒で原因のファイルを特定できたんです。この体験から、私はこのテクニックの重要性を身をもって知ることになりました。
この記事でわかること・解決できるお悩み
この記事では、「大量のファイルから特定のキーワードを含むファイルを見つけたい」「検索範囲が広すぎて時間がかかってしまう」といったお悩みを解決する方法を、丁寧に解説していきます。
具体的には以下のような内容を網羅的に取り扱いますね。まず基本的なfindとgrepの使い方から、両者を組み合わせる3つの方法を順を追って説明します。さらに、実際の開発現場でよく使われる便利な検索パターンや、検索速度を劇的に向上させるテクニックも紹介します。
また、実務でよくある問題として「検索結果に不要なファイルが大量に含まれてしまう」という悩みもありますよね。例えば、node_modulesや.gitといったディレクトリまで検索対象になってしまい、関係ない結果が山ほど表示されてしまうケースです。こうしたノイズを減らすための除外設定についても、具体的なコマンド例を交えながら詳しく解説します。
私自身、試行錯誤しながら身につけた知識をまとめましたので、きっと皆さんのお役に立てると思います。記事を読み終わる頃には、ターミナルを開いて自信持って検索コマンドを叩けるようになっているはずです。
対象読者と前提となる環境
この記事は、Linuxの基本的なコマンド操作を学び始めた初心者から、より効率的な検索方法を知りたい中級者までを対象としています。「ターミナルってちょっと苦手……」という方でも、できる限りわかりやすく説明しますのでご安心くださいね。
前提となる環境としては、ターミナルが使えればどこでもOKです。Macのターミナル、UbuntuなどのLinuxディストリビューション、AWSのEC2インスタンスなど、Linux系のコマンドが実行できる環境があれば、すぐに手を動かして試すことができます。Windowsをご利用の方は、WSL（Windows Subsystem for Linux）をインストールしていただければ同じように実践可能です。
特別な準備は必要ありません。findコマンドとgrepコマンドは、ほぼすべてのUnix系システムに標準でインストールされています。あなたの今の環境で、すぐに学習を始められます。
それでは次のセクションから、findコマンドとgrepコマンドの基礎知識をおさらいしていきましょう。すでにご存知の方も、復習のつもりで軽く目を通していただけると、後の理解がよりスムーズになると思います。
findとgrepのコマンド基礎知識をおさらいしよう
findとgrepを組み合わせた検索テクニックを学ぶ前に、まずはそれぞれのコマンドがどんな役割を持っているのか、基礎的な知識をしっかりおさえておきましょう。私も最初はこの2つを混同してしまうことがあったのですが、役割を整理するととてもシンプルなんです。
findコマンドとは？ファイルを条件付きで探す基本
findコマンドは、その名の通り「ファイルを探す」ためのコマンドです。ファイル名やサイズ、更新日時、パーミッション（アクセス権限）など、さまざまな条件を指定してファイルを検索できます。
たとえば、「過去7日間に更新された.logファイルだけを抽出したい」といった場合、以下のようなコマンドが使えます。
find /var/log -name "*.log" -type f -mtime -7このコマンドを実行すると、/var/logディレクトリ以下にある全サブディレクトリを再帰的に（どんどん深く潜って）検索し、7日以内に変更されたログファイルだけをリストアップしてくれます。出力結果は次のようにファイルパスがずらっと表示されます。
/var/log/app/app.log
/var/log/system/syslog.log
/var/log/debug/debug_20231201.logfindの便利なところは、条件を細かく絞り込める点ですね。ファイルの種類を指定する-type f（通常ファイル）や、ファイル名のパターンを指定する-name "*.txt"などを組み合わせることで、数千、数万あるファイルの中から目的のものをピンポイントで見つけ出せるんです。
私の場合、トラブルが起きたときに「最近書き換わった設定ファイルはどれだ？」と調べる場面がよくあります。そういうときにfindの-mtimeオプション（更新日時での絞り込み）が非常に重宝しています。
grepコマンドとは？ファイル内の文字列を検索する基本
一方、grep（グレップ）コマンドは、「ファイルの中身」に含まれる特定の文字列を検索するためのコマンドです。findが「ファイルそのもの」を探すのに対し、grepは「ファイルの中に書かれているテキスト」を探すという違いがあります。
たとえば、エラーログの中から「error」という単語が含まれる行だけを抽出したい場合は、次のように使います。
grep "error" /var/log/app.log実行結果としては、マッチした行がそのままターミナルに表示されます。
[2023-12-01 10:15:32] ERROR: Database connection failed
[2023-12-01 10:16:45] error: Invalid user credentials
[2023-12-01 10:17:01] ERROR: File not found: /tmp/data.csvまた、-Eオプションを使えば正規表現も使えるため、「errorまたはfatalまたはcriticalのいずれかを含む行」のような複雑なパターン検索も可能です。
grep -E "error|fatal|critical" /var/log/app.loggrepには他にも便利なオプションがたくさんあります。大文字小文字を区別しない-iオプションや、マッチした行の前後数行も一緒に表示してくれる-A（後の行）、-B（前の行）オプションなどは、トラブルシューティングの際に本当に助けられますね。
両方を組み合わせることで何ができるのか？
ここまでの説明で気づかれた方もいるかもしれませんが、findとgrepはそれぞれ単独でも強力なツールです。しかし、この2つを組み合わせることで「ファイルの条件で絞り込みつつ、その中身も検索する」という、さらに強力で精密な検索が可能になります。
例を考えてみましょう。あなたのプロジェクトディレクトリには、ソースコード、設定ファイル、ログファイル、さらにはnode_modulesのような外部ライブラリまで含まれているとします。この中から「設定ファイル（.conf）の中に書かれている特定のタイムアウト設定値を探したい」というケースですね。
grepだけの-rオプション（ディレクトリ内を再帰的に検索）でも検索はできますが、.confファイル以外もすべて検索対象になってしまい、余計な結果が大量に表示されてノイズだらけになってしまいます。何千何万という不要なファイルの中身まで全部チェックするので、処理に時間がかかってしまうんです。
そこでfindの出番です。findで「.confファイルだけ」を条件付きで抽出し、その結果をgrepに渡して「中身の文字列」を検索する。この2段構えにすることで、不要なファイルは最初から除外し、狙い撃ちで目的の情報だけを素早く見つけ出せるというわけです。
次のセクションからは、この組み合わせを具体的にどう実現するのか、3つの代表的な方法を詳しく解説していきますね。どの方法にも一長一短がありますが、それぞれの特徴を理解しておくと、場面に応じて最適な選択ができるようになりますよ。
findとgrepを組み合わせる基本的な3つの方法を試してみよう
前のセクションでfindとgrepの基礎知識をおさらいしましたね。いよいよここからは、この2つのコマンドを連携させて特定の文字列を含むファイルを検索する具体的な方法について解説していきます。私も実際の開発現場で膨大なログファイルやソースコードからエラーの原因を探す際、これから紹介する方法を毎日のように使っています。状況に合わせて使い分けられるよう、基本的な3つのアプローチをしっかりマスターしていきましょう。
find -execコマンド{} ;を使った検索方法
一番基本となるのが、findの検索結果をそのままgrepに渡す-exec（エグゼック）オプションを使う方法です。例えば、手元にあるlogsディレクトリの中の全ファイルから「error」という文字列を探したい場合、次のように入力します。
find ./logs -type f -exec grep "error" {} \;このコマンドが何をしているかというと、まずfindが./logsディレクトリ以下のすべてのファイル（-type f）を探します。見つかったファイルそれぞれに対して、-exec以降に書かれたgrep "error"コマンドを実行していくのです。ここでの最大のポイントは{}と\;の存在ですね。
{}は「findで見つかったファイルのパス」に置き換えられるプレースホルダー（穴埋めの場所）です。そして、最後の\;（バックスラッシュとセミコロン）は、コマンドの終わりを示す記号となります。つまり、裏側では見つかったファイルの数だけgrepコマンドが何度も立ち上がっているんですね。そのため確実に検索できる一方で、対象のファイル数が増えれば増えるほど、その分だけ時間がかかってしまうという特徴があります。
実際に実行すると、次のようにマッチしたファイルの内容が表示されます。
./logs/app.log:[2023-12-01 10:15:32] ERROR: Database connection failed
./logs/app.log:[2023-12-01 10:16:45] error: Invalid user credentials
./logs/debug.log:[2023-12-01 11:20:10] ERROR: Timeout exceededこのように、ファイル名と一緒にマッチした行が表示されるため、どのファイルに問題があるか一目でわかりますね。
find -execコマンド{} +を使った高速な検索方法
先ほどの方法でも検索は可能ですが、ファイル数が100件、1000件と増えてくると、いちいちgrepコマンドを1つずつ立ち上げるため処理速度がかなり遅くなってしまいます。「検索開始したのに数分間ターミナルが固まってしまった」という経験がある方もいるかもしれません。そこで私が実務で非常によく使っているのが、終端子を\;から+に変更する方法です。
find ./logs -type f -exec grep "error" {} +一見すると先ほどとほとんど同じに見えますが、最後が+になっていますね。この+を指定すると、見つかったファイルを1つずつバラバラに渡すのではなく、まとめて（一括で）grepに渡すことができます。例えるなら、スーパーのレジで商品を1つずつ会計するのではなく、カートごと一気に会計するようなイメージですね。
これにより、grepコマンドの起動回数を大幅に減らすことができます。1000個のファイルがあった場合でも、数回のgrep実行で済むため処理速度は劇的に向上します。実務では対象ファイルが膨大になることがほとんどですので、特別な理由がない限りは、この+を使うクセをつけておくことを強くおすすめします。
xargsコマンドを組み合わせた検索方法
最後にご紹介するのは、パイプ（|）とxargs（エックスアーグズ）コマンドを組み合わせる方法です。私は以前、ファイル名にスペースが含まれているデータを扱った際にこの方法の重要性を痛感した経験があります。
find . -type f -print0 | xargs -0 grep "error"少しだけコマンドが複雑になりましたね。まずxargsとは、標準入力（ここではパイプで渡されたfindの結果）を、後ろに続くコマンド（ここではgrep）の引数として組み替えて実行してくれる便利なコマンドです。先ほどの-exec {} +と同じように、ファイルをまとめてgrepに渡せるため処理が非常に高速です。
しかし、単純にfind . -type f | xargs grep "error"と繋ぐだけでは問題が起こることがあります。例えば「my file.txt」のように、ファイル名にスペースが含まれている場合です。通常、スペースはデータの区切り文字として認識されるため、システムが「my」と「file.txt」という2つの別々のファイルだと勘違いしてしまうんですよね。これが原因で「そのようなファイルは存在しない」というエラーが出て、しばらく原因がわからず焦った思い出があります。
それを防ぐのが-print0と-0というオプションです。find側で-print0を指定すると、見つかったファイル名の区切りをスペースや改行ではなく、null文字という目に見えない特殊な文字に変更します。そして、xargs側で-0を指定することで、そのnull文字を正しい区切りとして受け取ってくれるのです。これにより、どんなファイル名が来ても安全に、かつ高速に検索できるようになります。少し難しく感じるかもしれませんが、非常に強力で安全なテクニックなのでぜひ覚えておいてくださいね。
さて、今回はfindとgrepを組み合わせる3つの基本メソッドを試してみました。次のセクションからは、さらに実践的でよく使う便利な検索パターンについて、具体的なオプションを交えながら掘り下げていきます。
実践！よく使う便利な検索パターンとオプション
ここまで基本的な組み合わせ方を学んできましたが、いざ実際の業務で使おうとすると「どんなコマンドを打てばいいんだっけ？」と迷ってしまうことも多いと思います。私も最初はそうでした。何度もmanページ（マニュアル）を読み返しては、忘れてしまうの繰り返しでしたね。
そこでこのセクションでは、現場で本当に使える実践的な検索パターンを3つ厳選してご紹介します。これらを覚えておけば、大半のトラブルシューティングでスピーディに原因を追えるようになります。
特定の拡張子（.logや.txtなど）のファイルのみを対象に検索する
サーバー運用をしていると、ディレクトリの中には画像ファイルや実行ファイルなど、さまざまな種類のファイルが混在しています。そんな中から「ログファイルだけを調べたい」「設定ファイル（.conf）の中身だけを確認したい」という場面は非常に頻繁に訪れます。
例えば、すべてのファイルを対象に検索してしまうと、バイナリファイル（画像や圧縮ファイルなどのこと）まで読み込んでしまい、ターミナルが文字化けで埋め尽くされることがあります。これを防ぐためにも、拡張子で絞り込むテクニックは非常に重要です。
具体的には、findコマンドの-nameオプションを使って次のように記述します。
find . -name "*.log" -type f -exec grep "Timeout" {} +このコマンドを実行すると、カレントディレクトリ以下にある「.log」という拡張子がついたファイルだけをピンポイントで検索し、その中から「Timeout」という文字列を含む箇所を抜き出してくれます。ヒットした場合は次のように表示されます。
./logs/api.log:[2023-12-01 14:22:31] Timeout: Request to external API exceeded 30s
./logs/api.log:[2023-12-01 14:25:15] Timeout: Retry limit reached, aborting
./logs/system.log:[2023-12-01 15:01:02] WARNING: Connection timeout after 60sもし該当する文字列が見つからなかった場合は、何も表示されずにプロンプトに戻ります。これが「ヒットしなかった際の表示」ですね。
私は以前、数千ファイルがひしめくディレクトリで「全ファイル検索をかけてしまい、結果が出るまでに数分も待たされる」という痛い経験をしました。しかし、拡張子を「.log」に絞るだけで対象ファイルが数十件に減り、わずか数秒で結果が返ってくるようになったのです。このように、検索範囲を適切に絞り込むことは、単にノイズを減らすだけでなく、処理速度の劇的な向上にもつながります。
直近24時間に更新されたファイルからエラーを検索する
本番サーバーのログファイルは、1日で数ギガバイトにも肥大化することが珍しくありません。そんな巨大なログ全体を検索するのは、時間も計算リソースも無駄に消費してしまいます。特に「昨日発生したトラブルの原因を今すぐ調べたい」という緊急事態では、できるだけ素早く目的の情報にたどり着きたいですよね。
そんな時に活躍するのが、findコマンドの-mtimeオプションです。このオプションを使うと、ファイルの最終更新日時を基準にして検索対象を絞り込むことができます。
find /var/log -type f -mtime -1 -exec grep "fatal" {} +-mtime -1という指定は、「最終更新日時が現在時刻から24時間以内（1日以内）のファイル」という意味になります。つまり、過去1日間に変更されたファイルだけを抽出できるのです。
これを応用すれば、「過去7日間に更新されたファイル」なら-mtime -7と指定できますし、「ちょうど3日前に更新されたファイル」なら-mtime 3（マイナスなし）と指定できます。
実際の運用では、深夜に自動バッチ処理が失敗した際の原因調査などで、このパターンをよく使います。数百メガバイトのログファイルがあっても、直近の数ファイルだけを対象にすれば、数秒でエラーの痕跡を見つけ出すことができます。緊急時のトラブルシューティングでは、この時間短縮が大きな安心感につながりますね。
大文字小文字を区別せずに検索したり、前後の行も表示したりする
ここまでfind側のテクニックを中心にお話ししてきましたが、grepコマンド側にも非常に強力なオプションが用意されています。その中でも、現場で最も重宝するのが「-i」と「-A・-B」の2つのオプションです。
プログラムの出力するエラーメッセージは、開発者やシステムによって表記がバラバラです。「ERROR」と大文字で出力されることもあれば、「error」と小文字の場合もありますし、「Error」と先頭だけ大文字のケースもあります。grepはデフォルトで大文字と小文字を厳密に区別するため、通常の検索では見落としが発生してしまいます。
そこで-iオプション（ignore case、大文字小文字を無視するという意味）の出番です。
find ./app -type f -exec grep -i "error" {} +このように指定すれば、「ERROR」「error」「Error」など、あらゆるパターンのエラーメッセージを一括で検索できます。これだけで見落としのリスクが大幅に減りますね。
さらに、エラーを見つけた後の原因特定をスムーズにするのが、-A（After）と-B（Before）のオプションです。
find ./logs -type f -exec grep -i -A 3 -B 3 "error" {} +-A 3は一致した行の「後ろ3行」を、-B 3は「前3行」を合わせて表示するオプションです。エラーメッセージだけを見ても、その直前の処理や直後のシステム応答がわからなければ、根本原因を特定するのは難しいものです。前後の行も表示しておくことで、「あ、このエラーはDB接続のタイムアウトが原因なんだな」といった文脈を素早くつかめるようになります。
実際の出力例を見てみましょう。
[2023-12-01 10:15:30] INFO: Starting database connection...
[2023-12-01 10:15:31] INFO: Connection string: mysql://prod-db:3306
[2023-12-01 10:15:32] ERROR: Database connection failed - Timeout after 30s
[2023-12-01 10:15:32] WARNING: Retrying connection (attempt 1/3)
[2023-12-01 10:15:33] INFO: Reconnecting to database...
[2023-12-01 10:15:33] INFO: Connection established successfullyこのように前後の行が表示されることで、エラーの発生状況が一目で理解できます。私はこれらのオプションを知るまでは、エラーを見つけるたびにそのファイルをエディタで開いて前後を確認する、という非効率な作業をしていました。しかし、-Aと-Bを組み合わせることで、検索結果だけで原因の全体像を把握できるようになり、作業時間が劇的に短縮されました。皆さんも、ぜひこの便利なオプションを活用してみてください。
検索ノイズを減らす！特定のディレクトリやファイルを除外する方法
findとgrepを組み合わせると非常に強力な検索ができるようになりますが、ここで一つ大きな落とし穴があります。それは「検索ノイズ」に悩まされることです。
私もエンジニアになりたての頃、プロジェクト全体から特定のエラーメッセージを探そうとして、おもいっきり後悔した経験があります。検索を実行した瞬間、ターミナルの画面が大量の文字列で埋め尽くされ、数分間フリーズしてしまったのです。原因は、「node_modules」や「.git」などの、自分が書いたコードではない巨大なフォルダまで片っ端から検索してしまったことでした。
今回は、こうした余計なフォルダを検索対象から外し、目的の情報だけをスマートに見つけるための除外テクニックを紹介します。
findの-pruneオプションを使って特定のディレクトリを回避する
findとgrepの組み合わせにおいて、除外をfind側で行うのが最も効率的です。ここで使うのは-prune（プリューン）というオプションです。日本語に訳すと「刈り込む」という意味で、不要な枝を切り落とすようなイメージですね。
実務をしていると、Webアプリケーションのキャッシュファイルや、一時的なログを保存する「cache」や「tmp」といったフォルダが生成されることがあります。これらの中身は検索する意味がほとんどありません。find側で検索対象から外したいディレクトリがある場合は、この-pruneオプションを使用します。
例えば、カレントディレクトリ内の「cache」フォルダを無視してファイルを探したい場合は、次のようなコマンドになります。
find . -path ./cache -prune -o -type f -print | xargs -0 grep "error"より実践的には、安全にxargsを使うために-print0を組み合わせます。
find . -path ./cache -prune -o -type f -print0 | xargs -0 grep "error"このコマンドを初めて見ると、「なんだか記号が多くて複雑だな」と思うかもしれません。私も最初は戸惑いました。仕組みを噛み砕いて説明しますね。
まず-path ./cacheで除外したいフォルダを指定し、続く-pruneで「このフォルダには立ち入らないでね」と指示を出します。その後の-oは「または（OR）」という意味の記号です。つまり、「もしパスが./cacheだったら検索をスキップし、それ以外（-o以降）だったら通常のファイル（-type f）として出力（-print）してください」という論理的な命令になっているのです。
これにより、余計なファイルを読み込む手間が省けるため、検索速度そのものも向上します。
findの-not -pathでシンプルに除外する方法
-pruneは論理的な構造が少し複雑なので、もう少し直感的な除外方法もあります。それは-not -pathを使う方法です。
find . -type f -not -path "*/node_modules/*" -not -path "*/.git/*" -exec grep "error" {} +このコマンドでは、「node_modulesディレクトリの中にあるファイル」と「.gitディレクトリの中にあるファイル」を明示的に除外しています。-notは「〜ではない」という否定条件で、-path "*/node_modules/*"は「パスの中にnode_modulesを含む」という意味になります。つまり、「パスの中にnode_modulesを含まないファイルのみ検索する」という指定になるわけですね。
この方法のメリットは、除外するディレクトリを追加したい場合、-not -path "*/除外したいディレクトリ/*"を続けて書くだけで済む点です。初心者の方でも直感的に理解しやすいのではないでしょうか。
実際にこのコマンドを実行して、除外が正しく機能しているか確認してみましょう。除外対象のディレクトリがあれば、その中のファイルは一切検索されず、結果に表示されません。
grep —exclude-dirとの併記と比較
ここまでfind側での除外方法を主軸に解説してきましたが、参考までにgrep単体の除外方法とも比較しておきましょう。grepには--exclude-dir（エクスクルード・ディレクトリ）というオプションがあり、指定したフォルダを検索対象から完全にスルーしてくれます。
grep -r "error" --exclude-dir=node_modulesこのように、grep単体で再帰検索（-r）を行う場合には非常に便利なオプションです。しかし、本記事のテーマである「findとgrepの組み合わせ」においては、find側で除外する方がより効率的であることが多いです。なぜなら、findで最初から不要なファイルを弾いておけば、grepに渡すファイル数自体が減り、結果的にメモリ消費も処理時間も節約できるからです。
ただし、プロジェクト内で「手軽に検索したい」という場合は、grep -rと—exclude-dirの組み合わせも実用的です。状況に応じて使い分けるのが良いでしょう。
複数のディレクトリを一気に除外して快適に検索する具体例
ここまで単一のフォルダを除外する方法を解説してきましたが、実際の開発現場では「node_modules」「.git」「dist（ビルド後の出力先）」など、複数のフォルダを同時に除外したいケースがほとんどです。findの-not -pathを複数繋げても良いですが、よりスマートな書き方もあります。
例えば、findの-pruneを複数のディレクトリに対して使う場合は、次のように記述できます。
find . \( -path ./node_modules -o -path ./.git -o -path ./dist \) -prune -o -type f -print0 | xargs -0 grep "error"\(と\)で囲むことで、複数の除外パスをグループ化できます。これを実行すると、主要なノイズ発生源をすべて一気にスルーして検索してくれます。
具体的な効果として、以前私が関わったプロジェクトでは、何も指定しないと約15,000ファイルを検索して数十秒かかっていた処理が、この除外指定を追加しただけで対象が約500ファイルに絞られ、結果がわずか0.5秒で表示されるようになりました。
不要なデータに惑わされず、自分が本当に知りたい情報だけを瞬時に引き出す。この除外テクニックは、エンジニアの日常業務を快適にする必須スキルですので、ぜひご自身の環境で試してみてくださいね。
トラブルシューティング成功例：実践ケーススタディ
ここまでfindとgrepの組み合わせについて、さまざまなテクニックを解説してきました。しかし、「実際の現場でどう使われているのか」がイメージできないと、いざというときに活用できませんよね。
そこでこのセクションでは、私が実際に経験したトラブルシューティングの成功例を3つご紹介します。これらのケーススタディを通じて、findとgrepの組み合わせがいかに強力な武器になるかを実感していただけると思います。
ケース1：本番環境での謎の500エラー原因究明
ある金曜日の夕方、本番環境でユーザーから「500エラーが頻発している」と報告がありました。私は当時、このシステムの担当エンジニアの一人として原因調査に加わりました。
問題は、システムがマイクロサービスアーキテクチャで構築されており、数十のサービスがそれぞれ独自のログを出力している点でした。エラーメッセージは「Internal Server Error」という非常にシンプルなものだけで、どのサービスでエラーが起きたか特定できていない状態です。
まず、私は過去1時間以内に更新されたログファイルに絞り込みをかけました。
find /var/log -name "*.log" -type f -mmin -60 -exec grep -i "500\|internal\|fatal" {} +-mmin -60は「過去60分以内に更新されたファイル」という指定です。これにより、数あるログファイルの中から直近のものだけが抽出されました。
結果、次のような出力が得られました。
/var/log/payment-service/app.log:[2023-12-01 17:32:15] FATAL: Payment gateway connection refused
/var/log/payment-service/app.log:[2023-12-01 17:32:16] ERROR: Retry failed after 3 attempts
/var/log/payment-service/app.log:[2023-12-01 17:32:16] WARNING: Transaction TX-98765 marked as failedこれで決済サービスのログに原因があることがわかりました。さらに、エラーの前後の行も確認するため、次のコマンドを実行しました。
find /var/log/payment-service -name "*.log" -type f -exec grep -B 5 -A 5 "FATAL" {} +その結果、エラー発生の数秒前に設定ファイルの読み込みに失敗しているログが見つかり、最終的には「決済ゲートウェイのAPI設定ファイルが午後の定期メンテナンスで誤って上書きされていた」ことが原因と判明しました。設定を正しい値に戻すことで、問題は数分で解決しました。
この時の経験から、findとgrepの組み合わせは「異常の発生場所を素早く特定する」ための最強のツールだと確信しました。
ケース2：大量の設定ファイルからの特定値の一括置換確認
別のケースでは、セキュリティ監査の一環で「すべての設定ファイルから古いパスワードハッシュアルゴリズムの記述を確認する」というタスクがありました。プロジェクトには数百の設定ファイルが散在しており、手作業での確認は不可能です。
私はまず、設定ファイル（.conf、.yml、.yaml、.json）のみを抽出し、そこから古いハッシュアルゴリズムを示す文字列を検索しました。
find . -type f \( -name "*.conf" -o -name "*.yml" -o -name "*.yaml" -o -name "*.json" \) -not -path "*/node_modules/*" -not -path "*/.git/*" -exec grep -i "md5\|sha1" {} +このコマンドでは、複数の拡張子を-oで繋ぎ、同時にnode_modulesと.gitを除外しています。実行結果として、約30ファイルで古いアルゴリズムが使用されていることが判明し、計画的な修正作業に移ることができました。
ケース3：巨大プロジェクトでの非推奨関数の洗い出し
あるプロジェクトで、使用しているフレームワークのバージョンアップに伴い、非推奨となった関数の洗い出し作業が必要になりました。プロジェクトには数万のソースファイルが存在し、さらに外部ライブラリも多数含まれていました。
この場合、find側で対象を自前のソースコードに絞り込むことが重要です。
find ./src -type f -name "*.php" -exec grep -n "deprecated_function\|old_api_call" {} +./srcディレクトリに限定し、拡張子を.phpに絞ることで、外部ライブラリを完全に排除しています。また、grepの-nオプション（行番号表示）を付けることで、後でファイルを開いた際に該当箇所をすぐに見つけられるようにしました。
出力例は次のようになります。
./src/controllers/UserController.php:45: $result = deprecated_function($input);
./src/models/LegacyModel.php:128: return old_api_call($params);
./src/views/dashboard.php:67: $data = deprecated_function($cache_key);行番号付きで表示されるため、「UserController.phpの45行目に非推奨関数がある」と一目でわかりますね。この情報を基に、バージョンアップに必要な修正箇所をリストアップすることができました。
findとgrepの使い分けとベストプラクティス
ここまでfindとgrepを組み合わせた様々な検索方法を見てきましたが、「結局どのコマンドを使えばいいの？」と迷ってしまうこともありますよね。私も駆け出しの頃はコマンドの種類が多すぎて、いつも同じ書き方ばかり使っていました。しかし、目的や状況に合わせて使い分けることで、作業効率は劇的に上がります。ここでは、実務でのベストプラクティスとして、それぞれのコマンドの使い分け方とパフォーマンスを上げるためのコツをまとめておきます。
grep -r 単体とfind+grepを使い分ける基準
一番シンプルな「ディレクトリ内の文字列を検索したいだけ」というケースでは、grep -r（または高速な検索ツールであるrgコマンド）を使うのが手軽で最速です。例えば、「このプロジェクトフォルダの中で、’TODO’と書かれているファイルをすべて見つけたい」というような場合、特別な条件がなければgrep -r "TODO" .と打つだけで済みますね。私はちょっとしたキーワードの検索や、設定ミスを探す際には、もっぱらこちらを使っています。
一方で、「更新日時が新しいもの」「特定の拡張子（.logなど）」「特定のファイルサイズ以上」といった複合条件でファイルを絞り込んでから文字列検索をしたい場合は、findとgrepの組み合わせが必須となります。たとえば、「過去1週間に更新されたログファイルの中から、’Error’という文字列を探す」という要件には、grep -r単体では対応できません。findが持つ強力なファイルのフィルタリング機能と、grepの文字列検索機能を掛け合わせることで、狙い撃ちの精密な検索が可能になります。迷ったときは、「ファイルそのものに条件（日付やサイズなど）をつけたいかどうか」を基準に選ぶと良いと思います。
処理速度の違いとパフォーマンスを上げるコツ
findとgrepを組み合わせる際、処理速度に大きく影響するのが「-execの終端子」の選び方です。具体的には「{} \;」を使うか「{} +」を使うかで、数分かかる処理が数秒で終わるほどの雲泥の差が出ます。
例えば、1万件のログファイルに対して検索をかけるケースを考えてみましょう。-execで「{} \;」を使うと、ファイルを1つ見つけるたびにgrepコマンドが新しく起動します。つまり、1万回もgrepコマンドを立ち上げることになるわけですね。これにはかなりのオーバーヘッド（余計な処理の負担）がかかり、対象が1万件を超えると完了するまでに数分待たされることも珍しくありません。
しかし、「{} +」や「xargs」を使って引数をまとめて渡すクセをつけておくことで、同じ1万件の検索でも数秒で終わらせることができます。「{} +」は、見つかったファイル群をひとまとめにして、1回（または数回）のgrepコマンドにまとめて渡す仕組みだからです。毎回コマンドを起動する手間が省かれるので、劇的に速くなるのですね。私は過去に数万件のログから原因調査をしていた際、{} \;のせいでターミナルがフリーズしたかと勘違いしたことがあります（笑）。大量のファイルを扱うときは、ぜひ「{} +」や「xargs -0」を使って処理をまとめることを意識してみてください。
まとめ：findとgrepをマスターして効率的な検索マスターになろう
ここまで、findとgrepを組み合わせた検索テクニックについて、基礎から実践的な応用まで幅広く解説してきました。最後に、この記事の重要なポイントを振り返ってまとめておきましょう。
この記事で学んだ重要なポイント
まず、findとgrepはそれぞれ異なる役割を持ったコマンドであり、findが「ファイルを探す」担当、grepが「ファイルの中身を検索する」担当であることを学びました。この2つを組み合わせることで、ファイルの条件絞り込みと文字列検索を同時に実現できるようになります。
次に、findとgrepを連携させる3つの方法を理解しました。
find -exec {} \;：確実だがファイル数が多いと遅いfind -exec {} +：ファイルをまとめて渡すため高速find -print0 | xargs -0 grep：ファイル名にスペースが含まれていても安全に検索可能
実務では、特段の理由がない限り{} +を使うか、より安全なxargsとの組み合わせを使うことをおすすめします。
また、検索ノイズを減らすための除外テクニックも重要ですね。findの-pruneや-not -pathを使って、node_modulesや.gitなどの不要なディレクトリを事前に除外することで、検索精度と速度の両方を向上させることができます。
日常業務で活用するための次のステップ
この記事で学んだ内容を実際の業務で活用するために、まずはご自身の環境で試してみることをお勧めします。最初はコマンドの文字列が長くて呪文のように見えるかもしれません。しかし、使い続ければ必ず手に馴染んできます。
私自身、最初は「findとgrepの組み合わせなんて難しそう」と敬遠していましたが、一度便利さを知ったらもう手放せなくなりました。皆さんもぜひ、自分なりの使い方を見つけてみてください。
次のステップとして、以下のような課題に取り組んでみるのはいかがでしょうか。
- 自分のプロジェクトで「TODO」と書かれたファイルをすべて見つけてみる
- 過去1週間に更新されたファイルから特定のキーワードを検索してみる
- node_modulesを除外して、自分が書いたコードだけを検索してみる
これらの練習を通じて、findとgrepの組み合わせに対する理解がさらに深まるはずです。
findとgrepは、Linuxを扱うエンジニアにとってまさに「盾と剣」のような必須道具です。この2つを使いこなせるようになれば、どんなに深い階層に隠されたファイルでも、一撃で探し出せるようになります。今回紹介したテクニックを組み合わせれば、実務で遭遇するどんなに複雑な条件でも、ストレスなく検索できるはずです。
皆さんのエンジニアライフが少しでも快適になれば、私としても嬉しい限りです。それでは、快適なターミナルライフを！