通知メール

メール通知により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. 目的の通知レベルを選択します。

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

通知イベント

ユーザーには、次のイベントが通知されます:

GitLab Self-ManagedおよびGitLab Dedicatedでalways sentメールを無効にするには、個々のバックグラウンドジョブを無効にする必要があります。例:

• 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

バックグラウンドジョブを無効にするには、管理者である必要があります。

イシュー、マージリクエスト、およびエピックに関する通知

イシュー、マージリクエスト、およびエピックで発生するイベントに関する通知も受信します。

イシュー、マージリクエスト、およびエピックに関する通知を受信するユーザー

イシュー、マージリクエスト、およびエピックでは、ほとんどのイベントについて、通知は以下に送信されます:

• 参加者:
  • 作成者と担当者。
  • コメントの作成者。
  • タイトルまたは説明でユーザー名でメンションされたユーザー。
  • 通知レベルが「参加」以上のコメントでユーザー名でメンションされたユーザー。
• ウォッチャー: 通知レベルが「すべて通知」のユーザー（いくつかの例外がある）。
• サブスクライバー: 通知に手動でサブスクライブしたすべてのユーザー。
• カスタム: 通知レベルが「カスタム」で、適切なタイプのイベントの通知をオンにしたユーザー。

アクションを必要としない通知の数を最小限に抑えるため、適格な承認者には、プロジェクト内のすべてのアクティビティーについて通知されません。

すべてのイベントに関する通知を受け取るには、ユーザー通知の設定をカスタムに変更し、すべてのオプションを選択します。

「すべて通知」レベルに含まれないイベント

通知レベルをすべて通知に設定すると、ほとんどすべてのイベントについて通知されますが、次の例外があります:

• 誰かがマージリクエストにプッシュする。
• イシューが翌日に期限を迎える。
• パイプラインが成功する。
• 承認可能なマージリクエストが作成される。

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

イシュー、マージリクエスト、エピックの通知設定を編集

イシュー、マージリクエスト、またはエピックの通知を切り替えるには、右側のサイドバーで、縦方向の省略記号（ ）を選択し、通知切替をオンまたはオフにします。

通知の移動

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

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

イシュー、マージリクエスト、エピックに関する通知イベント

次の表に、イシュー、マージリクエスト、およびエピックの通知を生成するイベントを示します:

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

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

ユーザーが以前に不明な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および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リクエストを送信すると、サブスクライブ解除する代わりに確認ダイアログが表示されます。
• ソフトウェアがサブスクライブ解除メールを送信するためのメールアドレス。メールの内容は無視されます。

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

通知メールメッセージには、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アドレスをメールプロバイダーの許可リストに追加することで解決できます。手順については、メールプロバイダーのドキュメントを確認してください。