HazelのContents Containが効かないときの原因と直し方

HazelのContents Containが効かないなら、まず疑うべきはファイルそのものではありません。この条件が実際に読んでいるのは、ファイルではなくSpotlightによるそのファイルのインデックスです。新しいファイル、クラウドストレージから同期されたファイル、検索から除外されたフォルダなど、Spotlightがまだインデックスしていないものに対しては、文字が確かに書かれていても条件は何も見つけられません。Noodlesoft自身のサポートフォーラムが直し方をはっきり示しています。ルールをContents Contain Matchに切り替え、Spotlightを完全に迂回することです。速度は落ちます。Noodlesoftもそう明言しています。それでも、遅くて正しいほうが、速くて外れるよりましです。

この直し方だけで、たいていのケースは1分もかからず解決します。この記事では、なぜこの問題が起きるのか、条件を切り替えても直りきらないときに確認すべき3つのこと、そしてHazelの内容マッチングが今もFile Arborを含むどの代替ツールより優れている点まで解説します。

なぜHazelのContents Containはマッチしなくなるのか

Hazelには、ファイルの中身を調べる条件が2つあり、まったく違う仕組みで動いています。Contents Containは、ある単語がファイルに含まれているかをSpotlightに尋ねるだけで、ファイル自体は開きません。Contents Contain Matchはファイルを開き、文字を直接検索します。

この設計自体は理にかなっています。Spotlightのインデックスは高速で、たいていの場合は正確です。問題は「ファイルが存在する」ことと「Spotlightがそのファイルのインデックスを終えている」こととの間にあるずれです。監視フォルダに数秒前に届いたばかりのファイルは、まだ検索可能になっていないことがあります。iCloud Drive、Dropbox、OneDriveから同期されたファイルは、特に同期の途中やベータ版のクライアントでは、何分もインデックスされないまま残ることがあります。外付けドライブやネットワーク共有、あるいはmacOSのSpotlightプライバシーで除外されている場所にあるファイルは、そもそもSpotlight検索に一切出てきません。つまりContents Containは、ルールを何回実行してもそのファイルを見つけられません。

これはルールの不具合ではありません。ルールが調べているのはインデックスであり、遅れているのはインデックスのほうです。Hazelはルール自体を毎回正しく実行しています。ただ、本当は「まだです」が正直な答えのところで、Spotlightから「いいえ」という返事を受け取っているだけです。

本当の直し方：「Contents Contain Match」に切り替える

ルールを開き、内容条件を見つけて、ポップアップメニューをContents ContainからContents Contain Matchに変更してください。多くの人にとって、これがすべてです。マッチ失敗の正体がインデックスの遅れだったと判明したとき、Noodlesoftのフォーラムがいつも案内しているのもこの方法です。

Contents Contain MatchはSpotlightに何も尋ねません。ルールが実行された瞬間にファイルを開き、文字を抽出して検索します。遅れているインデックスもなければ、引っかかる除外リストもなく、バックグラウンド処理が追いつくのを待つ必要もありません。代償は速度です。ファイルを直接読むほうが、参照テーブルを調べるより時間がかかります。とはいえ、ダウンロードフォルダや書類フォルダ程度の量であれば、その差はまず気になりません。

Contents Containを使ったルールが何十個もある場合でも、作り直す必要はありません。ひとつずつ開き、ポップアップメニューを変更して保存するだけです。ルールの数が多いと地味に手間ですが、設計をやり直す作業ではなく、機械的な編集です。

すべてのルールを作り直す前に確認すべき3つのこと

Contents Contain Matchへの切り替えは症状を直します。なぜSpotlightがそのファイルを見逃したのかを知りたい場合や、安全な範囲では速いほうの条件を使い続けたい場合は、次の3つが現実に多い原因をカバーします。

1. 該当フォルダを再インデックスする。 SpotlightまたはFinderのウィンドウで、ファイルに含まれているとわかっている単語を検索します。ファイルが出てこなければ、Spotlightは本当にまだインデックスしていません。Appleが案内する方法は、そのフォルダを一度Spotlightのプライバシーリストに追加し、数秒待ってから削除するというものです。削除された瞬間、Spotlightはそのフォルダをゼロから再インデックスすべき合図として受け取り、ボリューム全体を再インデックスするより早く終わります。
2. プライバシー除外リスト自体を確認する。 システム設定 → Spotlight → 検索のプライバシー（古いmacOSではシステム環境設定 → Spotlight → プライバシー）を開き、監視しているフォルダや、それが置かれている親フォルダ・外付けドライブ・ネットワークボリュームがすでに除外されていないか確認します。バックアップからの復元や新しいMacへの移行のあとなど、フォルダが意図せずここに入り込むことは珍しくありません。
3. ファイルに本当にテキストレイヤーがあるか確認する。 PDFをプレビューで開き、1行の文字をドラッグして選択してみます。何もハイライトされなければ検索対象の文字が存在せず、その書類はスキャンした画像か写真です。この場合、HazelのどちらのContents条件も、次に説明するOCRなしにはマッチしません。

Hazel 6にできて、File Arborにできないこと

正直に言っておく価値があります。ファイルの多くが暗号化PDFなら、この先を読んでもその結論は変わりません。今回の用途にはHazelのほうが向いています。

Hazel 6は、その場でのテキスト認識機能を追加しました。Noodlesoft自身のマニュアルは、これを「画像に対して、そしてテキストレイヤーをまだ持たないPDFに対して」マッチング前に走るOCRだと説明しています。つまり、スキャンした請求書やスマートフォンで撮影した領収書のように、抽出できる文字がそもそも存在しないファイルでも、Hazelのルールにマッチさせられます。Hazel 6は暗号化PDFにパスワードを与える機能も追加しており、ロックされた書類が黙って失敗するだけでは終わりません。

File Arborは1.3.0より前は、このどちらも行いませんでした。それ以降は、スキャンした文書も読み取るよう設定したProのルールが、スキャンしたPDFと、JPEG、PNG、TIFFの画像にOCRをかけ、それぞれの最初と最後のページを読み取ります。パスワード保護されたPDFは今も読み取れません。パスワードのオプションがないためで、これは些細な注記ではなく実際の弱点です。暗号化された書類を扱うMacユーザーがFile Arborに乗り換えるのではなくHazelを使い続けるべき、最もはっきりした理由です。

「Contents Contain」と「Contents Contain Match」の比較

File Arborが向いている場面、向いていない場面

Spotlightのことを気にせず同じ種類の内容ルールを使いたい、というのがここにたどり着いた本当の理由なら、File Arborが最も近いのはContents ContainではなくContents Contain Matchのほうです。Pro限定の「内容に含む」条件は、Windows・macOSどちらのOS上でもファイルの文字を直接読み取り、検索インデックスをまったく介しません。たとえばフランス語圏の取引先から届く請求書に印字された社名Françoisに対して、ウムラウトやアクセント記号なしのfrancoisという条件を書いておくだけで同じファイルにマッチします。大文字・小文字も区別しないため、Invoiceでもinvoiceでも構いません。この条件はWindowsでもmacOSでも同じように動きます。

実際の違いとして言っておく価値があるのはここです。Hazelの内容条件はmacOS専用です。File Arborの内容条件はクロスプラットフォームで、同じルールが1つのアプリから、WindowsでもmacOSでも、フォルダを監視しながら動きます。Macだけのワークフローであれば、これは乗り換える理由になりません。Hazelはすでに必要なことをこなしており、暗号化PDFの分だけむしろ上を行っています。Windowsのマシンでもルールを保守していて、それを一致させたい場合にだけ意味を持ちます。

File Arborの内容条件が何をするかについても、正確に言っておく必要があります。決めるのは移動先のフォルダだけです。書類から抜き出した文字を新しいファイル名に組み込むのは別のPro機能で、1.3.0で追加されました。サンプル書類上で請求書の日付のような値を一度クリックすると、ルールがその値からファイル名とフォルダを組み立てます。同じく、Hazelにはそれができます。マッチした部分をトークンとして取り込み、リネームアクションに使えます。ツール横断で内容による振り分けができること・できないことをもう少し広く知りたい方は、ファイルの中身でフォルダに自動振り分けする方法をご覧ください。

どの直し方を試すべきか

「昨日までマッチしていたルールが、今日になって同じフォルダ・同じファイルなのにマッチしなくなった。」 まずそのルールをContents Contain Matchに切り替えてください。ほぼ間違いなくインデックスの遅れが原因で、Matchのほうならこの問題をまるごと避けられます。

「ファイルがOneDrive、Dropbox、または外付けドライブにある。」 何より先に、そのボリュームがSpotlightプライバシーに入っていないか確認してください。クラウド同期クライアントや外付けドライブは、誰も意図していないのにフォルダが除外リストに入り込みやすい場所です。

「PDFから自分で文字をコピー&ペーストしていて、確かに中に入っているはずだ。」 次に疑うべきはテキストレイヤーです。プレビューでの選択テストは10秒で済み、OCRが本当に足りていないピースなのかどうか即座にわかります。

「スキャンした書類やパスワード保護されたPDFばかりで、ここまでの話が当てはまらない。」 Hazelを使い続け、そのOCRとパスワード機能を活用してください。Spotlight関連の修正ではそこに到達できず、File Arbor Proは1.3.0以降スキャンを読み取れるものの、パスワード保護されたPDFは開けません。これはHazelの本当の強みであり、この記事がその判断を覆すことはありません。

「Windowsのマシンでも同じ内容ルールを使いたい。」 File Arborを検討する価値があるのは、まさにこのケースだけです。Hazelの置き換えとしてではなく、Hazelが届かないもう一つのプラットフォームで同等のルールを動かす手段としてです。

内容ルールをこの先も安定させるために

クラウドストレージと同期しているフォルダや、リムーバブルメディア上のフォルダを監視するルールには、デフォルトでContents Contain Matchを選んでください。わずかな速度の代償は、Spotlightが追いついているかどうかを気にせずに済む安心感に見合います。純粋なContents Containは、内部ドライブ上にあり、インデックスが実際に追いついていると確認できたフォルダに限って使うのが、速さを活かせる場面です。

新しい内容ルールを作ったら、新着ファイルに信頼して使う前に、すでにマッチするとわかっているファイルで一度テストしてください。何も起きないルールは、誤って発火するルールよりずっと気づきにくいものです。内容条件は、SpotlightにせよファイルからのDirect Readにせよ、テキスト抽出が空振りしたときに黙って失敗する種類のルールだからこそ、この確認が効きます。

FAQ

なぜHazelのContents Contain条件はファイルにマッチしないのですか？

Contents Containはファイル本体ではなくSpotlightのインデックスを検索しているためです。新しいファイル、クラウドストレージから同期されたファイル、外付けドライブ上のファイル、Spotlightのプライバシーで除外されたフォルダなどはインデックスされておらず、文字は確かに書かれているのにルールは何も見つけられません。Noodlesoft自身のフォーラムも、これが最も多い原因だと述べています。

HazelのContents ContainとContents Contain Matchの違いは何ですか？

Contents ContainはSpotlightのインデックスを調べるため高速ですが、Contents Contain Matchはファイルそのものを直接読み取るため低速な代わりにSpotlightに一切依存しません。Contents Containが見つけるはずのファイルを見逃したときは後者に切り替えるよう、Noodlesoftは推奨しています。インデックスが古くても不完全でも、直接読み取りなら惑わされないからです。

HazelのContents Containが効かないとき、どう直せばいいですか？

ルールを開き、条件をContents ContainからContents Contain Matchに変更してください。これはNoodlesoft自身が推奨する直し方で、Spotlightに頼らずファイルの文字を直接読み取るためうまくいきます。それでも解決しない場合は、Spotlightがそのフォルダを実際にインデックスしているか、ファイルに本物のテキストレイヤーがあるかを確認してください。

Hazelはスキャンした書類や写真のPDFも読み取れますか？

Hazel 6であれば読み取れます。Noodlesoftは、テキストレイヤーを持たない画像やPDFに対してその場でOCRを実行してからマッチングする機能と、暗号化PDFにパスワードを与える機能を追加しました。それ以前のHazelや多くのルールベースツールは、テキストレイヤーがまったくないファイルを読み取ることができません。File Arbor Proは1.3.0以降なら読み取れますが、パスワードのオプションはありません。

File ArborもHazelと同じくSpotlightに依存しているのですか？

いいえ。File Arborの内容条件はファイルの文字を直接読み取るため、HazelのContents Contain Matchと同じ方式で、古くなるインデックスも除外されるフォルダも存在しません。ただし直接読み取りである以上、インデックス確認より低速だという代償はHazel自身の直接読み取りオプションと同じです。Spotlightが先にそのファイルへたどり着いたかどうかに結果が左右されることはありません。

File ArborはOCRや暗号化PDFの用途でHazelの代わりになりますか？

スキャンについては1.3.0以降なら代わりになりますが、File Arbor Proが読み取るのは最初と最後のページだけです。暗号化PDFについては代わりになりません。パスワード保護されたPDFを開くことはできないため、暗号化された書類はFile Arborの内容ルールに一致しません。Hazel 6はどちらにも対応しています。ファイルの多くが暗号化PDFなら、Hazelのほうが向いています。File Arborの強みは、Spotlightに依存せず同じ内容ルールをWindowsとMacの両方で動かせる点です。

まとめ

HazelのContents Containは壊れているわけではありません。Spotlightがインデックスした内容について、正直に答えているだけです。それは必ずしも、ファイルに実際に書かれている内容と同じではありません。ルールをContents Contain Matchに切り替えれば、Spotlight由来のずれは完全になくなります。暗号化PDFがワークフローの一部なら、Hazel 6のパスワード対応は、Spotlightの修正でもFile Arborのルールでも今のところ届かない領域をカバーしています。

Windowsでもファイルを扱っていて、そちらでも同じ種類の内容ルールを使いたいなら、File Arborをダウンロードして無料版でまず名前・種類ルールが自分のワークフローに合うか試してみてください。内容条件自体はPro限定の機能なので、Hazelの代わりではなく併用する価値があるかどうかは、料金ページにあるPro版の内容条件を見てから判断できます。