Gmailのフィルタは、受信したメールを「条件で判定し、指定した処理を自動実行する」機能です。条件を一つだけにすると、うまく絞れずに不要メールまで巻き込みやすくなります。一方で、条件を増やすと意図どおりに動かない、あるいは「ORをどう書けばよいのか分からない」といった壁にぶつかりがちです。
本記事では、複数条件の設計の考え方、設定手順、コピペできるテンプレ、動かない場合の切り分け、そして安全な運用方法までを、実際に設定して使い続けられる粒度で整理いたします。なお、フィルタ設定は“いきなり本番”にしないことが重要です。最初はラベル付けなど軽い処理で様子を見てから、アーカイブや転送など強い処理へ段階的に移行するのが安全です。
※本コンテンツは「記事制作ポリシー」に基づき、正確かつ信頼性の高い情報提供を心がけております。万が一、内容に誤りや誤解を招く表現がございましたら、お手数ですが「お問い合わせ」よりご一報ください。速やかに確認・修正いたします。
Gmailフィルタ複数条件でできることと設計の考え方
Gmailフィルタの条件は基本がANDになる
Gmailのフィルタ作成画面では、一般的に「複数の欄に入力した条件は、同時に満たすもの（AND）」として絞り込まれます。これが、複数条件を理解するうえでの最初の重要ポイントです。
たとえば、次のように設定したとします。
From（差出人）に「vendor@example.com」
件名に「請求書」
この場合、対象は「差出人が vendor@example.com で、かつ件名に請求書が含まれるメール」です。差出人だけ一致するメール、件名だけ一致するメールは対象になりません。この性質は、重要メールの取りこぼしを防ぐうえで役に立ちます。つまり、最初はAND中心に狭く作ることで、誤処理の範囲を小さくできます。
一方で、ANDの理解が曖昧なまま条件を足していくと、今度は「まったくヒットしない」状態になりがちです。これは「狭くしすぎ」や「表記ゆれ」などが原因です。以下のような例が典型です。
件名に「請求書」と入れたが、実際の件名は「ご請求書」「請求書（12月分）」「Invoice」などで表記が揺れている
Fromにアドレスを入れたが、実際は送信代行サービスの別ドメインから来る
取引先が複数部署から送ってくるため、差出人が一つに固定できない
このような場合は、「必須条件は何か」「許容条件は何か」を分けて設計し、許容条件の部分にORを使う、またはフィルタ自体を分割する、という発想が必要になります。
GmailフィルタでORにしたいときの選択肢
ORは「どれか一つでも一致したら対象にする」という論理です。複数条件の相談で最も多いのが、次の2パターンです。
送信者が複数（A社・B社・C社など）なので、まとめて同じラベルを付けたい
件名が複数（請求書・領収書・見積書など）なので、まとめて処理したい
ORを実現する方法には、実務上大きく2つの選択肢があります。
選択肢1：検索演算子を使ってOR条件を一つのフィルタにまとめる
検索ボックスで OR を使った検索式を作り、狙いどおりにヒットすることを確認したうえで、その検索条件からフィルタを作成します。ORが必要な条件が増えても、検索式として一括管理できる点が利点です。
選択肢2：フィルタを分割して管理する
ORで無理に一つへまとめず、「送信者A用フィルタ」「送信者B用フィルタ」と複数に分けます。見通しが良く、原因切り分けが容易です。とくに転送や削除など“強いアクション”が絡む場合は、この分割方式のほうが事故を起こしにくいです。
どちらが正解というより、「目的」と「安全性」で選ぶのが現実的です。たとえば、単にラベルを付けるだけなら選択肢1でまとめてもリスクは比較的小さいです。一方、転送や削除、受信トレイスキップなどが絡む場合は、選択肢2（分割）のほうが安全性を確保しやすいです。
Gmailフィルタと検索演算子の関係を押さえる
Gmailのフィルタは、実質的に「検索条件の保存＋自動処理」と捉えると理解が進みます。つまり、検索で作れる条件はフィルタ条件としても活用できます。この考え方が、複数条件を失敗しないための土台になります。
複数条件の設計では、次の順番を強く推奨いたします。
まず検索で条件を作り、結果を確認する
想定どおりのメールだけがヒットする状態に調整する
その検索条件をフィルタに変換し、処理内容（ラベル付け等）を設定する
この流れにすると、ORや除外条件（NOT）を含む複雑な条件でも、フィルタ作成前に“答え合わせ”ができます。逆に、いきなりフィルタを作ると、条件の解釈違いに気づかないまま運用に入ってしまい、重要メールの見落としや誤転送などの事故につながります。
また、検索演算子の理解は「表記ルールを守る」ことにも直結します。特にORは、表記が崩れると意図した論理として扱われないことがあります。後半のトラブルシューティングで、確認ポイントをチェックリスト化して解説いたします。
Gmailフィルタ複数条件の設定手順
ここでは、複数条件フィルタを“再現性高く”作るための設定手順を、作業の流れとして整理いたします。ポイントは「テスト→フィルタ化→軽い処理→強い処理の追加」です。これにより、ミスがあっても影響を小さく抑えられます。
検索で先に試してからフィルタを作成する
複数条件は、まず検索ボックスで試すのが安全です。理由は単純で、検索結果を見れば「当たっている範囲」がすぐに分かるからです。フィルタ作成画面だけで条件を組むと、結果の確認が後手になります。
推奨手順は次のとおりです。
Gmailの検索ボックスに条件を入力して検索します
検索結果を確認し、狙いのメール以外が混ざっていないか、逆に狙いのメールが漏れていないかを確認します
漏れがあれば、表記ゆれ対応（例：請求書 OR Invoice）や、必須条件（例：from:）の追加で調整します
絞り込みが適切になったら、検索オプションからフィルタ作成へ進みます
最初は「ラベル付け」など軽いアクションだけで作成し、数日観察します
この時点で重要なのは、“最初から完成形を目指さない”ことです。現場のメールは、例外が必ず出ます。最初に100点を目指すより、60点で回し、例外を見て80点、90点へ改善するほうが失敗が少ないです。
フィルタ作成画面で条件を組み立てるコツ
フィルタ作成画面では、From、To、件名、含む、含まない等の入力欄があります。複数条件を扱う際のコツは、「どの欄で何を指定するか」を最初に決め、設計を分割することです。
以下は、設計の目安になる早見表です。
| 目的 | 主に使う欄 | 推奨理由 | 失敗しやすい点 |
|---|---|---|---|
| 差出人で絞る | From | ノイズが少なく、誤ヒットが減る | 送信代行・別ドメインで届く場合 |
| 宛先で絞る | To | 共有アドレス・別名運用で有効 | Bccや転送経由は想定外がある |
| 件名で絞る | 件名 | 目的に直結しやすい | 表記ゆれ・言語違いが多い |
| 本文の語句で絞る | 含む | 検知範囲を広げられる | 署名・定型文で誤ヒットしやすい |
| 除外する | 含まない | 事故防止に効く | 除外が過剰だと取りこぼす |
複数条件を組む場合は、次の設計順を推奨いたします。
必須条件（ANDで狭める）：差出人、宛先、取引先ドメインなど、ぶれにくい条件
許容条件（ORで広げる）：件名のパターン、文面のキーワードなど、複数候補がある条件
安全装置（除外）：自動返信、メルマガ、配信停止など、誤処理の温床になりやすい条件
この順に組むと、意図より広く当たる問題も、まったく当たらない問題も、原因を分解して確認しやすくなります。
既存メールにフィルタを適用する手順
フィルタは基本的に「今後届くメール」へ適用されます。ただし、作成時に既存メールへ適用する選択肢が表示されることがあります。この機能は便利ですが、複数条件の場合は特に慎重に扱う必要があります。理由は、過去のメールは表記ゆれや仕様変更（件名のテンプレ変更、送信元ドメイン変更など）が混在しやすく、想定外の範囲まで処理されるリスクが高いからです。
安全な進め方は次のとおりです。
まず検索で対象範囲を確認します（過去メールがどれだけヒットするかを把握します）
フィルタを作成し、最初は「ラベル付け」だけにします（アーカイブや削除は避けます）
既存メールに適用する場合は、対象が想定どおりかをラベルで可視化して確認します
問題がなければ、受信トレイスキップやアーカイブなど強い処理を段階的に追加します
なお、転送が絡む場合は注意が必要です。転送は“新着のみ”といった制約があるため、既存メールを後から一括転送したい目的には適合しないことがあります。既存分の取り扱いは、別の方法（手動転送、他の運用設計等）も検討する必要があります。
Gmailフィルタ複数条件の例文テンプレ集
ここでは、実際に現場で頻出するパターンを、コピペしやすい形で整理いたします。重要なのは、テンプレをそのまま使うのではなく、必ず検索でヒット範囲を確認してからフィルタ化することです。メールの実態は環境ごとに異なり、送信代行や件名テンプレの違いが想定外を生みます。
送信者を複数指定するテンプレ
| 目的 | コピペ例 | 使いどころ | 注意点 |
|---|---|---|---|
| A社またはB社をまとめる | from:a@example.com OR from:b@example.com | 取引先が少数で固定 | OR表記ゆれに注意 |
| 複数部署をまとめる | from:(@example.com) | 同一企業の複数アドレス | 送信代行だと外れることあり |
| 特定送信者だけ除外 | (from:a@example.com OR from:b@example.com) -from:noreply@example.com | 自動返信が混ざる | 除外過多は取りこぼしに注意 |
実務のコツとしては、「まずは from: 条件だけで成立するか」を確認し、難しければ件名や本文の条件を“補助的に”足すのが安全です。本文条件を主条件にすると誤ヒットの温床になりやすいです。
件名を複数指定するテンプレ
| 目的 | コピペ例 | 使いどころ | 注意点 |
|---|---|---|---|
| 請求書または領収書 | subject:請求書 OR subject:領収書 | 会計関連メールの整理 | 表記ゆれ（ご請求書等） |
| 見積・発注・請求をまとめる | subject:(見積 OR 発注 OR 請求) | 購買フローの整理 | 語が短いとノイズ増 |
| 特定案件＋書類種別 | subject:案件名 (請求書 OR 見積) | 案件単位で管理 | 案件名の表記ぶれ |
件名は便利ですが、同じ目的でも「Invoice」「Receipt」のように言語が混在するケースがあります。海外ベンダーが絡む場合は、最初から日英併記でORを組むと安定します。
本文キーワードと除外を組み合わせるテンプレ
| 目的 | コピペ例 | 使いどころ | 注意点 |
|---|---|---|---|
| 特定プロジェクト名を拾う | “プロジェクトX” | 固有名詞での抽出 | 引用符は厳密寄り |
| 重要語AまたはB | A OR B | 表記が複数ある | A/Bが短いと誤ヒット |
| 重要語を拾いメルマガ除外 | (A OR B) -メルマガ -配信停止 | ノイズを削る | 除外が多いと漏れる |
本文条件は、署名やテンプレ文面、フッター（配信停止リンク等）で誤ヒットしやすいです。そのため、本文条件を使う場合は、必ず「誤ヒットの理由」を検索結果で確認し、除外語を最小限で調整してください。
添付ファイル条件と組み合わせるテンプレ
| 目的 | コピペ例 | 使いどころ | 注意点 |
|---|---|---|---|
| 添付あり＋請求書系 | has:attachment (subject:請求書 OR subject:領収書) | 会計書類を拾う | 添付なし請求もあり得る |
| PDFを優先抽出 | filename:pdf (請求書 OR Invoice) | PDF運用が前提 | ファイル名依存の例外 |
| 特定拡張子 | filename:xlsx subject:見積 | 見積のExcel | xls/xlsx混在に注意 |
添付条件は便利ですが、「リンク共有（Driveリンク）で添付がない」「ファイル名が自動生成でpdf表記がない」などの例外が必ず発生します。最初はラベル付けだけで数日観察し、例外パターンを拾ってから条件を改善するのが確実です。
ラベル付けとアーカイブの定番パターン
フィルタは「条件」と「アクション」の組み合わせです。複数条件に気を取られると、アクション設計が雑になり、使い勝手が悪くなることがあります。ここでは、定番の運用パターンを整理いたします。
パターン1：ノイズを見えなくする（ただし消さない）
条件：ニュースレター、通知系（差出人＋本文の特徴語など）
アクション：ラベル付け＋受信トレイスキップ＋既読
運用ポイント：週1回ラベルを見て“取りこぼし”がないか点検します
パターン2：重要だけ目立たせる（取りこぼし対策）
条件：主要取引先ドメイン＋件名キーワード
アクション：ラベル付け＋スター（必要なら重要マーク）
運用ポイント：受信トレイスキップは最初は避け、誤判定を観測してから追加します
パターン3：処理キュー化（やることリスト）
条件：依頼・確認・承認などの件名キーワード（ただし誤ヒットしやすいので差出人等で補強）
アクション：ラベル付け（例：要対応）
運用ポイント：ラベルに未処理が溜まる前提で、定期的に消化するルールを作ります
Gmailフィルタ複数条件がうまく動かない原因と直し方
複数条件で失敗する原因の多くは、「意図した論理がGmailに伝わっていない」「条件の表記ゆれ」「設計が広すぎる／狭すぎる」のいずれかです。ここでは、代表的なトラブルを“原因→対処”で潰し込みます。とくにORが絡む場合、チェックリスト方式で確認すると復旧が早いです。
ORが効かないときに確認するポイント
次のチェック項目を上から順に確認してください。1つでも該当すると、ORが意図どおりに解釈されない、または検索結果が崩れます。
ORが大文字半角で入力されているか（例：
A OR B）ORの前後に余計な文字が入っていないか（全角スペース、改行、句読点など）
全角のＯＲになっていないか（見た目が似ていても別文字です）
まず検索ボックスで同じ条件が想定どおりにヒットするか（フィルタ作成前の答え合わせ）
OR以外の条件が厳しすぎていないか（ANDが強すぎてヒットゼロになる）
引用符を付けた結果、完全一致に近い挙動になっていないか（表記ゆれがあると漏れます）
日本語の表記ゆれ（全角半角・記号・旧字体・英語表記）を吸収できているか
いったんORを外し、単独条件（Aだけ、Bだけ）でヒットするかを確認したか
対処の基本は、「最小構成に戻す」ことです。たとえば、from:○○ subject:(A OR B) -C が動かない場合、次の順に分解します。
from:○○だけでヒットするかfrom:○○ subject:Aでヒットするかfrom:○○ subject:Bでヒットするかfrom:○○ subject:(A OR B)で期待どおりか最後に
-Cを足して取りこぼしがないか
このように段階的に復元すれば、どの要素が問題を起こしているか特定できます。
意図より広くヒットするときの典型原因
「関係ないメールまでラベルが付く」「大量にアーカイブされてしまう」といった問題は、条件が広すぎることが原因です。典型原因は次のとおりです。
短い一般語を条件にしている（例：「見積」だけで本文検索している）
本文検索を使っていて、署名やフッターの定型文に引っかかっている
ORの候補が増えすぎ、対象領域が拡張し続けている
必須条件（差出人、宛先、ドメイン等）を置いていない
対処は、次の順に行うと安全です。
必須条件を足して狭める：まずfrom:やTo、ドメイン条件で基礎を固めます
OR候補を減らす／分割する：一つのフィルタに詰めず、フィルタを複数に分割します
除外語を最小限追加する：原因となっている定型文をピンポイントで除外します
重要なのは、除外語を増やしすぎないことです。除外語は“効きすぎる”と取りこぼしの原因になります。最小限で運用し、例外が見つかったら足す、という順序が安全です。
フィルタが競合したときの挙動と整理方法
複数のフィルタが同じメールに当たることは十分あり得ます。その場合、ラベルが複数付く、スターが付く、アーカイブされるなど、複数の処理が同時に走ったように見えることがあります。これ自体が必ずしも悪いわけではありませんが、強い処理が絡むと事故につながります。
整理の基本方針は、次の3点です。
強い処理（削除、転送、受信トレイスキップ、既読化）を行うフィルタは最小限にする
ラベル付与で観測できる状態を作ってから、強い処理を追加する
似た目的のフィルタが増えたら統合または役割分担を明確化する
具体的な手順としては、以下のやり方が有効です。
問題が起きたメール（誤ラベル、誤アーカイブ等）を開き、どの条件に当たった可能性があるか仮説を立てます
フィルタ一覧から関連しそうなフィルタを2〜3個抽出し、一時的に無効化またはアクションを軽くします（ラベル付けだけにする等）
再発状況を観測し、原因フィルタを特定します
原因フィルタは、必須条件を足して狭めるか、OR候補を分割して見通しを良くします
「フィルタが増えるほど複雑になる」のは自然な現象です。運用前提で、定期的に棚卸しすることが、長期的には最もコストが低くなります。
転送フィルタの制約と運用上の注意
転送は便利ですが、誤転送が起きると情報漏えい等のリスクにつながります。複数条件で転送を行う場合は、次の方針を強く推奨いたします。
転送条件は“狭く”作る（差出人＋件名＋必要なら宛先など）
最初はラベル付けで観測し、誤判定がないと分かってから転送を有効化する
ORを多用するなら、転送は分割フィルタで管理する（見通しを最優先します）
転送先が複数ある場合は、転送ミスの影響が増えるため、転送対象をさらに狭めるか、承認フロー（人手確認）を挟む運用も検討する
また、過去メールの扱いは転送の制約により思いどおりにならない場合があります。転送を「過去分も含めて一括で流したい」という設計にすると、想定どおりに動かず手戻りが増えるため、目的に応じて別手段を含めて設計することが重要です。
Gmailフィルタ複数条件を安全に運用するコツ
フィルタは「作って終わり」ではなく、メール運用の変化に合わせて育てるものです。取引先の送信環境変更、件名テンプレ変更、担当者変更、通知サービス追加などにより、条件が徐々に合わなくなります。したがって、保守性（直しやすさ）を意識した設計と、点検の仕組みが重要です。
フィルタのバックアップと移行
フィルタを増やしていくと、設定そのものが資産になります。誤って削除したり、アカウント移行で失ったりすると復旧コストが大きくなります。可能であれば、以下のタイミングでバックアップを取得する運用が望ましいです。
重要なフィルタを追加した直後
強い処理（受信トレイスキップ、削除、転送）を導入する前
PC買い替え、ブラウザ移行、アカウント切替の前
組織変更や担当者交代の前
バックアップを取得しておけば、「条件を試しに大きく変える」こともやりやすくなります。保守性を上げるという意味でも、バックアップは単なる保険ではなく、改善を促進する基盤になります。
定期的な見直しチェックリスト
フィルタが増えるほど、例外が見えにくくなります。月1回程度、以下を点検するだけで、誤処理や取りこぼしを大幅に減らせます。
送信元アドレスやドメインが変わっていないか（送信代行の切替等）
件名テンプレが変わっていないか（番号形式や言語が変わる等）
OR条件が増えすぎていないか（1フィルタが巨大化していないか）
除外条件が増えすぎていないか（取りこぼしが起きていないか）
強い処理をするフィルタが増えていないか（削除・転送・既読等）
似たフィルタが重複していないか（競合の原因になっていないか）
重要ラベルにノイズが混ざっていないか（誤ヒットの兆候）
直近1か月で例外メールが発生していないか（改善の種を拾う）
この点検を行う際は、「誤ヒットを探す」だけでなく「取りこぼしを探す」視点も重要です。重要メールがラベルに入っていない場合、条件が狭すぎるか、表記ゆれが吸収できていない可能性があります。
重要メールを取りこぼさない設計指針
重要メールのフィルタは、次の3層で設計すると安全性が高まります。
第1層：可視化（ラベル、スター、重要マーク）
まず“見える化”で観測できる状態を作ります。誤判定があっても致命傷になりにくいです。第2層：整理（アーカイブ、受信トレイスキップ、カテゴリ整理）
受信トレイのノイズを減らします。ただし誤判定があると見落としに直結するため、観測後に導入します。第3層：強制処理（転送、削除、既読化）
効果は大きい一方、誤判定のダメージも最大です。導入は最終段階にし、条件は最小限かつ堅牢にします。
この層構造で設計すると、「見落としリスク」と「整理効率」のバランスが取りやすくなります。特に仕事用アカウントでは、最初に第1層を整え、例外パターンが落ち着いてから第2層へ進めるほうが、結果として手戻りが少なくなります。
よくある質問
GmailフィルタでANDは書かなくてもよいのか
一般的な運用としては、フィルタ作成画面で複数の欄に条件を入れると「すべて満たす（AND）」として絞り込まれます。したがって、ANDを明示的に書かなくても、複数条件を同時に満たすものだけが対象になりやすいです。
ただし、検索式として入力する場合や、複雑な条件で意図が崩れる場合もありますので、最も確実なのは「検索でヒット範囲を確認してからフィルタ化する」運用です。
ORで何個まで条件をつなげられるのか
実務上の観点では、「何個までつなげられるか」よりも「つなげすぎないほうが保守性と安全性が上がる」という点が重要です。ORを増やし続けると、次の問題が発生します。
条件が巨大化し、どの語が効いているのか分からなくなる
誤ヒットが増え、除外条件が増え、さらに取りこぼしも増える
変更時の影響範囲が大きくなり、事故が起きやすくなる
したがって、一定以上に増える場合は、フィルタを分割し、役割別（請求系、通知系、社内系など）に整理することを推奨いたします。これにより、原因切り分けと修正が容易になります。
スマホだけでフィルタは作れるのか
スマホでも検索やラベル操作は可能ですが、複数条件のフィルタ作成はPCのほうが操作性・視認性が高く、ミスが減ります。特にORや除外条件を含む場合、文字入力の全角半角混入やスペース混入などが起きやすいため、可能であればPCで作成し、スマホは運用（閲覧・処理）中心にするのが安全です。
フィルタを削除するとラベルは消えるのか
フィルタは「自動処理のルール」であり、ラベルは「メール管理の分類」です。一般的には、フィルタを削除しても、既に付与されたラベルまで即座に消えるわけではありません。ただし、運用や設定の状況により挙動の確認が必要な場合もあります。安全に進めるには、次の手順が堅実です。
いきなり削除せず、まずフィルタを編集してアクションを軽くする、または一時的に運用を止める
影響がないことを確認してから削除する
重要なフィルタは削除前にバックアップを取得しておく
まとめ
Gmailフィルタの複数条件は、基本がANDで絞り込みになり、ORで許容条件を広げる設計が基本です。
ORは表記ゆれ・全角混入・条件過多で崩れやすいため、「検索でテスト→フィルタ化→軽い処理→段階的に強い処理」の順で導入すると安全です。
誤ヒットや取りこぼしが出た場合は、最小構成へ分解して原因を特定し、ORの分割や必須条件の追加で保守性を上げるのが有効です。
運用を長期で安定させるには、バックアップと月1回の棚卸し（ORの巨大化、除外過多、強い処理の増加）をルール化することが重要です。