通知メール

メール通知によりGitLabで何が起こっているかを常に把握できます。イシュー、マージリクエスト、エピック、およびデザインのアクティビティーに関する更新を受信できます。

GitLab管理者がユーザーにメッセージを送信するために使用できるツールについては、GitLabからのメールをお読みください。

GitLab 17.2以降では、通知は、24時間ごとにプロジェクト/グループまたはユーザー単位でレート制限されます。

通知を受け取るユーザー

イシュー、マージリクエスト、またはエピックで通知が有効になっている場合、GitLabはそこで発生するアクションを通知します。

次のいずれかの理由で通知を受信する場合があります。

• イシュー、マージリクエスト、エピック、またはデザインに参加している。コメントや編集をしたり、誰かがユーザー名に言及すると、あなたはそのスレッドの参加者になります。
• イシュー、マージリクエスト、またはエピックで通知を有効にしている。
• プロジェクトまたはグループの通知を設定している。
• パイプラインメールインテグレーションを介して、グループまたはプロジェクトのパイプライン通知をサブスクライブしている。

GitLabは、次の場合に通知を送信しません。

• アカウントがプロジェクトボットである。
• アカウントがデフォルトのメールアドレスを持つサービスアカウントである。
• アカウントがブロック（BAN）または非アクティブ化されている。
• コメントが編集され、ユーザーメンションが含まれている。
• 管理者が通知をブロックしている。

グローバル通知設定

グローバル通知設定は、プロジェクトまたはグループに対して別の値を指定しない限り、デフォルトの設定になります。たとえば、特定のプロジェクト内のすべてのアクティビティーについて通知を受けたい場合があります。他のプロジェクトでは、名前でメンションされた場合のみに通知を受けたいと考えています。

これらの通知設定は、自分のみに適用されます。他の人が受け取る通知には影響しません。

通知設定の編集

通知設定を編集するには:

1. 右上隅でアバターを選択します。
2. 設定を選択します。
3. 左側のサイドバーで、通知を選択します。
4. グローバル通知メールで、通知の送信先メールアドレスを入力します。デフォルトでは、プライマリメールアドレスになります。
5. グローバル通知レベルで、デフォルトの通知レベルを選択して、通知に適用します。
6. 自身のアクティビティーに関する通知を受信するチェックボックスをオンにすると、自分のアクティビティーに関する通知を受信できます。デフォルトでは選択されていません。

通知レベル

各プロジェクトとグループの右側で、通知レベルを選択できます:

通知スコープ

プロジェクトおよびグループごとに異なる通知レベルを選択することで、通知のスコープを調整できます。

通知スコープは、最も広範なレベルから最も具体的なレベルに適用されます。

• アクティビティーが発生したプロジェクトまたはグループの通知レベルを選択していない場合、グローバルまたは_デフォルト_の通知レベルが適用されます。
• グループ設定は、デフォルト設定よりも優先されます。
• プロジェクト設定は、グループ設定よりも優先されます。

プロジェクトまたはサブグループに対して通知レベルをグローバル設定しても、グローバル通知設定は直接継承されません。代わりに、グローバル通知レベルよりも階層が高い設定済み通知レベルを次の順序で継承します。

1. プロジェクト設定。
2. 親グループ設定。
3. 祖先グループ設定（階層を上がります）。
4. 最終的なフォールバック設定としてのグローバル通知の設定。

たとえば、デフォルトのグローバル通知設定をすべて通知に設定し、グループとプロジェクトの通知レベルを次のように設定します。

%%{init: { "fontFamily": "GitLab Sans", 'theme':'neutral' }}%%
flowchart TD
  accTitle: Notification hierarchy
  accDescr: Example of a group, subgroup, and project

    N[Default/global notification level set to Watch]
    N --> A
    A[Group A: Notification level set to Global]
    A-. Inherits Watch level .-> N
    A --> B[Subgroup B: Notification level set to Participate]
    B --> C[Project C: Notification level set to Global]
    C-. Inherits Participate level .-> B

プロジェクトCは、サブグループBから参加通知レベルを継承します。グローバル通知設定からすべて通知通知レベルを継承しません。

グループ通知

グループごとに、通知レベルとメールアドレスを選択できます。

グループ通知のレベルを変更

グループの通知レベルを選択するには、次のいずれかの方法を使用します。

1. 右上隅でアバターを選択します。
2. 設定を選択します。
3. 左側のサイドバーで、通知を選択します。
4. グループセクションでグループを見つけます。
5. 目的の通知レベルを選択します。

または:

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. ベルアイコン（ ）の横にある通知ドロップダウンリストを選択します。
3. 目的の通知レベルを選択します。

グループ通知に使用されるメールアドレスを変更

自分が所属するグループごとに、通知を受信するメールアドレスを選択できます。たとえば、フリーランスで仕事をしている場合、クライアントのプロジェクトに関するメールを個別に管理したいときに、グループ通知を使用できます。

1. 右上隅でアバターを選択します。
2. 設定を選択します。
3. 左側のサイドバーで、通知を選択します。
4. グループセクションでグループを見つけます。
5. 目的のメールアドレスを選択します。

プロジェクト通知のレベルを変更

最新情報を常に把握できるように、プロジェクトごとに通知レベルを選択できます。

プロジェクトの通知レベルを選択するには、次のいずれかの方法を使用します。

1. 右上隅でアバターを選択します。
2. 設定を選択します。
3. 左側のサイドバーで、通知を選択します。
4. プロジェクトセクションでプロジェクトを見つけます。
5. 目的の通知レベルを選択します。

または:

1. 上部のバーで、検索または移動先を選択して、プロジェクトを見つけます。
2. ベルアイコン（ ）の横にある通知ドロップダウンリストを選択します。
3. 目的の通知レベルを選択します。

新しいリリースが利用可能になったときに通知を受け取る方法については、リリースの通知をご覧ください。

通知イベント

ユーザー、プロジェクト、またはグループイベント、および作業アイテムのアクティビティーの通知が送信されます。

ユーザーイベント

ユーザーの通知イベント:

プロジェクトイベント

プロジェクトの通知イベント:

グループイベント

グループの通知イベント:

イシュー、マージリクエスト、およびエピックイベント

イベントは、選択された通知レベルに基づいて通知を生成します。一部の通知は、オプションでカスタム通知レベルを選択し、目的のイベントを選択することで有効にできます。エピック、イシュー、またはマージリクエストの通知をサブスクライブすることもできます。

デフォルトでは、作成したイシュー、マージリクエスト、またはエピックの通知は受信しません。自分自身のアクティビティーに関する通知をオンにすることができます。

エピックイベントの通知は、次の通知レベルで送信されます:

イシューイベントの通知は、次の通知レベルで送信されます:

マージリクエストの通知は、次の通知レベルで送信されます:

パイプラインイベントの通知は、次の通知レベルで送信されます:

サービスアカウントパイプラインイベントの通知は、次の通知レベルで送信されます:

イシュー501083は、すべてのイベントをすべて通知レベルに追加することを追跡します。

特定のイシュー、マージリクエスト、またはエピックの通知をサブスクライブ

特定のイシュー、マージリクエスト、またはエピックの通知を切り替えるには:

1. 右側のサイドバーの上部で、次を選択します:
   • 通知オン（ ）を選択して通知を有効にします。
   • 通知オフ（ ）を選択して通知を無効にします。

通知の移動

通知をオンにすると、ディスカッションに参加していなくても、更新ごとに通知を受け取るようになります。エピックで通知をオンにしても、エピックにリンクされたイシューは自動的にサブスクライブされません。

通知をオフにすると、更新に関する通知の受信が停止されます。この切替をオフにすると、このイシュー、マージリクエスト、またはエピックに関連する更新のみからサブスクライブ解除されます。GitLabからのすべてのメールをオプトアウトする方法をご覧ください。

特定のイベントを無効にする

always sent GitLab Self-ManagedインスタンスとGitLab Dedicatedで通知のセキュリティメールを無効にするには、インスタンスの管理者が個々のバックグラウンドジョブを無効にできます。

例:

• personal_access_tokens_expiring_worker
• personal_access_tokens_expired_notification_worker
• ssh_keys_expiring_soon_notification_worker
• ssh_keys_expired_notification_worker
• send_recurring_notifications_worker
• deploy_tokens_expiring_worker
• members_expiring_worker

不明なサインインに関する通知

ユーザーが以前に不明なIPアドレスまたはデバイスから正常にサインインすると、GitLabはメールでユーザーに通知します。このようにして、GitLabは潜在的に悪意のあるまたは不正なサインインをユーザーに事前に警告します。この通知メールには以下が含まれます。

• ホスト名。
• ユーザーの名前とユーザー名。
• IPアドレス。
• 地理的な場所。
• サインインの日時。

GitLabは、既知のサインインを識別するためにいくつかのメソッドを使用します。通知メールが送信されるには、すべてのメソッドが失敗する必要があります。

• 最終サインインIP: 現在のサインインIPアドレスは、最終サインインIPアドレスと照合されます。
• 現在のアクティブセッション: ユーザーが同じIPアドレスからの既存アクティブセッションを持っている場合。アクティブセッションを参照してください。
• Cookie: 正常なサインインの後、暗号化されたCookieがブラウザに保存されます。このCookieは、最後の正常なサインインから14日後に期限切れになるように設定されています。

誤った確認コードを使用したサインインの試行に関する通知

GitLabは、誤った2要素認証（2FA）コードを使用してアカウントにサインインしようとする試みを検出した場合、メール通知を送信します。これにより、悪意のある第三者がユーザー名とパスワードにアクセスし、2FAをブルートフォース攻撃しようとしていることを検出できます。

デザインに関する通知

誰かがデザインにコメントすると、参加者にメール通知が送信されます。

参加者は次のとおりです:

• デザインの作成者（異なる作成者が異なるバージョンのデザインをアップロードした場合、複数の人がいる可能性があります）。
• デザインに関するコメントの作成者。
• デザインに関するコメントでメンションされたすべてのユーザー。

グループまたはプロジェクトのアクセス有効期限に関する通知

ユーザーのグループまたはプロジェクトへのアクセスが7日後に期限切れになる場合、GitLabはメール通知を送信します。これにより、グループまたはプロジェクトのメンバーは、必要に応じてアクセス期間を延長するように促されます。

すべてのGitLabメールをオプトアウトする

メール通知をもう受信したくない場合は、次の手順を実行します。

1. 右上隅でアバターを選択します。
2. 設定を選択します。
3. 左側のサイドバーで、通知を選択します。
4. グローバル通知レベルを無効に設定します。
5. 自身のアクティビティーに関する通知を受信するチェックボックスをオフにします。
6. グループまたはプロジェクトに所属している場合は、通知設定をグローバルまたは無効に設定します。

GitLab Self-ManagedインスタンスとGitLab Dedicatedのインスタンスでは、これを実行した後でも、特定のイベント通知が送信されます:

• インスタンスの管理者は引き続きメールを送信できます
• 通知イベントはalways sentです

通知メールをサブスクライブ解除する

リソース単位（たとえば、特定のイシュー）でGitLabからの通知メールをサブスクライブ解除できます。

サブスクライブ解除リンクを使用する

GitLabからのすべての通知メールの下部に、サブスクライブ解除リンクが含まれています。

サブスクライブ解除するには:

1. メールのサブスクライブ解除リンクを選択します。
2. ブラウザでGitLabにサインインしている場合は、すぐにサブスクライブ解除されます。
3. サインインしていない場合は、アクションを確認する必要があります。

メールクライアントまたはその他のソフトウェアを使用する

メールクライアントは、GitLabからのメールを表示するときに配信停止ボタンを表示する場合があります。サブスクライブ解除するには、このボタンを選択します。

GitLabからの通知メールには、特別なヘッダーが含まれています。これらのヘッダーにより、サポートされているメールクライアントおよびその他のソフトウェアがユーザーのサブスクライブを自動的に解除できるようになります。次に例を示します。

List-Unsubscribe: <https://gitlab.com/-/sent_notifications/[REDACTED]/unsubscribe>,<mailto:incoming+[REDACTED]-unsubscribe@incoming.gitlab.com>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

List-Unsubscribeヘッダーには次の2つのエントリがあります。

• ソフトウェアがPOSTリクエストを送信するためのリンク。このアクションは、ユーザーをリソースから直接サブスクライブ解除します。このリンクにGETリクエストを送信すると、サブスクライブ解除する代わりに確認ダイアログが表示されます。
• ソフトウェアがサブスクライブ解除メールを送信するためのメールアドレス。メールの内容は無視されます。

メールによる登録解除は、メールによる返信と同じ2年間の保持ポリシーの対象となります。

メールのフィルタリングに使用できるメールヘッダー

通知メールメッセージには、GitLab固有のヘッダーが含まれます。通知をより適切に管理するために、これらのヘッダーの内容に基づいて通知メールをフィルタリングできます。

たとえば、マージリクエストまたはイシューが割り当てられている特定のプロジェクトからのすべてのメールをフィルタリングできます。

次の表に、GitLab固有のすべてのメールヘッダーを示します。

X-GitLab-NotificationReason

X-GitLab-NotificationReasonヘッダーには、通知の理由が含まれています。値は次のいずれかであり、優先度順に並べられています。

• own_activity
• assigned
• review_requested
• mentioned
• subscribed

通知の理由は、通知メールのフッターにも含まれています。たとえば、理由がassignedのメールには、フッターに次の文が含まれています。

You are receiving this email because you have been assigned an item on <configured GitLab hostname>.

オンコールアラート通知

オンコールアラート通知メールには、アラートの次のいずれかの状態が含まれています。

• alert_triggered
• alert_acknowledged
• alert_resolved
• alert_ignored

インシデントエスカレーション通知

インシデントエスカレーション通知メールには、インシデントの次のいずれかの状態が含まれています。

• incident_triggered
• incident_acknowledged
• incident_resolved
• incident_ignored

X-GitLab-NotificationReasonヘッダーに含めるイベントのリストを拡張することについては、イシュー20689で追跡されています。

トラブルシューティング

通知の受信者のリストをプルする

プロジェクトから通知を受信する受信者のリストをプルする場合は（主にカスタム通知のトラブルシューティングに使用）、Railsコンソールでsudo gitlab-rails cを実行し、プロジェクト名を必ず更新してください。

project = Project.find_by_full_path '<project_name>'
merge_request = project.merge_requests.find_by(iid: 1)
current_user = User.first
recipients = NotificationRecipients::BuildService.build_recipients(merge_request, current_user, action: "push_to"); recipients.count
recipients.each { |notify| puts notify.user.username }

存在しない失敗したパイプラインに関する通知

存在しなくなった失敗したパイプラインに関する通知（メールまたはSlack経由）を受信する場合は、メッセージをトリガーした可能性のある重複したGitLabインスタンスがないか再確認してください。

メール通知は有効になっているが、受信されない

GitLabでメール通知を有効にしたのに、ユーザーが期待どおりに通知を受信しない場合は、メールプロバイダーがGitLabインスタンスからのメールをブロックしていないことを確認してください。多くのメールプロバイダー（Outlookなど）は、あまり知られていないSelf-ManagedメールサーバーのIPアドレスからのメールをブロックします。確認するには、インスタンスのSMTPサーバーから直接メールを送信してみてください。たとえば、Sendmailからのテストメールは次のようになります。

# (echo subject: test; echo) | $(which sendmail) -v -Am -i <valid email address>

メールプロバイダーがメッセージをブロックしている場合は、次のような出力が表示される場合があります（メールプロバイダーとSMTPサーバーによって異なります）。

Diagnostic-Code: smtp; 550 5.7.1 Unfortunately, messages from [xx.xx.xx.xx]
weren't sent. For more information, please go to
http://go.microsoft.com/fwlink/?LinkID=526655 (http://go.microsoft.com/fwlink/?LinkID=526655) AS(900)

通常、この問題は、SMTPサーバーのIPアドレスをメールプロバイダーの許可リストに追加することで解決できます。手順については、メールプロバイダーのドキュメントを確認してください。