{"meta":{"title":"受信トレイフィルター","intro":"GitHub の受信トレイで通知をフィルタリングする方法について学びましょう。","product":"サブスクリプションと通知","breadcrumbs":[{"href":"/ja/enterprise-cloud@latest/subscriptions-and-notifications","title":"サブスクリプションと通知"},{"href":"/ja/enterprise-cloud@latest/subscriptions-and-notifications/reference","title":"リファレンス"},{"href":"/ja/enterprise-cloud@latest/subscriptions-and-notifications/reference/inbox-filters","title":"受信トレイフィルター"}],"documentType":"article"},"body":"# 受信トレイフィルター\n\nGitHub の受信トレイで通知をフィルタリングする方法について学びましょう。\n\n次のサポートされているフィルターを使って、受信トレイ用のカスタム フィルターを作成できます。 カスタム フィルターの作成について詳しくは、「[インボックスからの通知を管理する](/ja/enterprise-cloud@latest/subscriptions-and-notifications/how-tos/viewing-and-triaging-notifications/managing-notifications-from-your-inbox#customizing-your-inbox-with-custom-filters)」をご覧ください。\n\n## カスタムフィルタの制限\n\nカスタムフィルタは現在、以下をサポートしていません。\n\n* インボックス内の全文検索では、プルリクエストやイシューのタイトルも検索できます。\n* `is:issue`、`is:pr`、および `is:pull-request` クエリ フィルターの区別。 これらのクエリは、Issue と pull request の両方を検索結果として表示します。\n* 15 個以上のカスタムフィルタの作成\n* デフォルトのフィルタまたはその順序の変更\n* [除外](/ja/enterprise-cloud@latest/search-github/getting-started-with-searching-on-github/understanding-the-search-syntax) 検索を `NOT` または `-QUALIFIER` を用いて行う\n\n## カスタムフィルタでサポートされているクエリ\n\n使用できるフィルタの種類は次のとおりです。\n\n* リポジトリによるフィルター (`repo:` を使用)\n* ディスカッションの種類によるフィルター (`is:` を使用)\n* 通知理由で絞り込む `reason:`\n* 通知作成者によるフィルター (`author:` を使用)\n* を使用して組織別にフィルター処理する `org:`\n\n### サポートされている `repo:` クエリ\n\n`repo:` フィルターを追加するには、リポジトリの所有者をクエリに含める必要があります: `repo:owner/repository`。 所有者は、通知をトリガーする GitHub 資産を所有する組織またはユーザーです。 たとえば、`repo:octo-org/octo-repo` は、octo-org 組織内の octo-repo リポジトリでトリガーされた通知を表示します。\n\n### サポートされている `is:` クエリ\n\nGitHubの特定のアクティビティの通知をフィルター処理するには、`is` クエリを使用できます。 たとえば、リポジトリの招待の更新のみを表示するには、 `is:repository-invitation`を使用し、 Dependabot alertsのみを表示するには、 `is:repository-vulnerability-alert`を使用します。\n\n* `is:check-suite`\n* `is:commit`\n* `is:gist`\n* `is:issue-or-pull-request`\n* `is:release`\n* `is:repository-invitation`\n* `is:repository-vulnerability-alert`\n* `is:repository-advisory`\n* `is:discussion`\n\nDependabot alertsの通知からのノイズを減らす方法については、[Dependabot アラートの通知を構成する](/ja/enterprise-cloud@latest/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-dependabot-notifications) を参照してください。\n\n`is:` クエリを使用して、通知がトリアージされた方法を記述することもできます。\n\n* `is:saved`\n* `is:done`\n* `is:unread`\n* `is:read`\n\n### サポートされている `reason:` クエリ\n\n更新を受信した理由で通知をフィルター処理するには、`reason:` クエリを使用します。 たとえば、自分 (または自分が所属する Team) が Pull Request のレビューを要求されたときに通知を表示するには、`reason:review-requested` を使用します。 詳しくは、「[通知について](/ja/enterprise-cloud@latest/subscriptions-and-notifications/concepts/about-notifications#reasons-for-receiving-notifications)」をご覧ください。\n\n| クエリ                       | 説明                                                                  |\n| ------------------------- | ------------------------------------------------------------------- |\n| `reason:assign`           | 割り当てられている Issue またはプルリクエストに更新があるとき。                                 |\n| `reason:author`           | プルリクエストまたは Issue を開くと、更新または新しいコメントがあったとき。                           |\n| `reason:comment`          | Issue またはプル リクエストでコメントをした際。                                         |\n| `reason:participating`    | issue や pull request にコメントした場合、または @mentioned された場合。                |\n| `reason:invitation`       | チーム、組織、またはリポジトリに招待されたとき。                                            |\n| `reason:manual`           | まだサブスクライブしていない Issue または Pull Request で **\\[サブスクライブ]** をクリックしたとき。   |\n| `reason:mention`          | 直接 @mentioned されたとき。                                                |\n| `reason:review-requested` | あなたまたはあなたが所属しているチームがプルリクエストのレビューを依頼されました。                           |\n| `reason:security-alert`   | リポジトリに対してセキュリティアラートが発行されたとき。                                        |\n| `reason:state-change`     | プルリクエストまたはイシューの状態が変更されたとき。 たとえば、Issue がクローズされたり、プルリクエストがマージされた場合です。 |\n| `reason:team-mention`     | メンバーになっている Team が @mentioned されたとき。                                 |\n| `reason:ci-activity`      | リポジトリに、新しいワークフロー実行ステータスなどの CI 更新があるとき。                              |\n\n### サポートされている `author:` クエリ\n\nユーザーごとに通知をフィルター処理するには、`author:` クエリを使用します。 作成者は、通知を受け取るスレッド (例: issue、pull request、gist、ディスカッション) の元の作成者です。 たとえば、Octocat ユーザーによって作成されたスレッドの通知を表示するには、`author:octocat` を使用します。\n\n### サポートされている `org:` クエリ\n\nOrganization を指定して通知をフィルター処理するには、`org` クエリを使用できます。 クエリで指定する必要がある組織は、 GitHubに通知されるリポジトリの組織です。 このクエリは、複数の Organization に属していて、特定の Organization の通知を表示する場合に便利です。\n\nたとえば、octo-org の Organization からの通知を表示するには、`org:octo-org` を使用します。\n\n## Dependabot カスタム フィルター\n\nDependabotを使用して依存関係を最新の状態に保つ場合は、次のカスタム フィルターを使用して保存できます。\n\n* `is:repository_vulnerability_alert` を選択すると、 Dependabot alertsの通知が表示されます。\n* `reason:security_alert`\n  Dependabot alerts とセキュリティ更新プログラムのプル リクエストの通知を表示するには。\n* `author:app/dependabot` を選択すると、 Dependabotによって生成された通知が表示されます。 これには、 Dependabot alerts、セキュリティ更新プログラムのプル要求、バージョン更新プログラムのプル要求が含まれます。\n\nDependabot の詳細については、「[Dependabot アラート](/ja/enterprise-cloud@latest/code-security/concepts/supply-chain-security/dependabot-alerts)」を参照してください。"}