こんにちは！日々の開発、本当にお疲れ様です。
コードを書いて、テストをパスさせて、無事にデプロイが完了する――エンジニアにとって最高の瞬間の一つですよね。
でも、こんなストレスを感じたことはありませんか？
「今、誰がどのブランチを本番環境にデプロイしたんだっけ？」
「Slackの通知が多すぎて、本当に必要なデプロイ完了の通知が埋もれてしまう……」
今回は、GitLabのWebhookとSlackを組み合わせて、「見たい情報だけが、美しく流れてくる最強のデプロイ通知システム」を作る方法を解説します。
これをマスターすれば、「あれ、デプロイ終わった？」とチャットでチームメンバーに聞き回る必要は一切なくなります。毎日の開発作業が劇的に快適になりますよ。一緒に一歩ずつ、スマートな自動化の世界へ進みましょう！
—
1. そもそも「GitLab Webhook」と「Slack」って何をするもの？
まずは基礎から優しく紐解いていきましょう。
- GitLab Webhook（ウェブフック）とは：
GitLab上で「コードがプッシュされた」「マージされた」「パイプラインが成功した」といった何らかのイベント（出来事）が起きた時、外部の指定したURLへ自動的に「今こんなこと起きたよ！」とお知らせ（HTTPリクエスト）を飛ばす機能です。
- Slack Incoming Webhookとは：
外部サービスからの「お知らせ」を受け取って、Slackの特定のチャンネルにメッセージを投稿してくれる専用の受け渡し口（URL）です。
つまり、「GitLabで何かが起きたら（Webhook）、そのデータをSlackのURLに投げて、チャンネルに通知させる」という連携プレイを行います。
—
2. 基礎セットアップ：Slackの準備をする
まずは、GitLabからの通知を受け取る「宛先」をSlack側に作ります。
1. [Slack API: Applications](https://api.slack.com/apps) にアクセスし、「Create New App」をクリックします。
2. 「From scratch」を選択し、App名（例: `GitLab Deploy Bot`）と、通知を飛ばしたいワークスペースを選んで作成します。
3. 左メニューの「Incoming Webhooks」をクリックし、機能を「On」にします。
4. ページ下部の「Add New Webhook to Workspace」をクリックし、通知を表示させたいSlackチャンネル（例: `#deployments`）を選んで許可します。
5. 発行された 「Webhook URL」 をコピーして、メモ帳などに控えておいてください。（これが宛先住所になります）
—
3. GitLab Webhookの基本設定と「HelloWorld」的動作確認
次は、GitLab側に「このURLに通知してね」と教え込みます。まずは一番シンプルな状態でテストしてみましょう。
手順
1. GitLabの通知したいリポジトリを開きます。
2. 左側メニューの [Settings] ＞ [Webhooks] を開きます。
3. URL 欄に、先ほどSlackでコピーした「Incoming Webhook URL」を貼り付けます。
4. Secret token は今回は空欄でOKです。
5. トリガー（どんな時に発火させるか）を選びます。今回は手始めに 「Push events」 にチェックを入れてみましょう。
6. 一番下の [Add webhook] ボタンをクリック！
動作確認（HelloWorld！）
追加したWebhookの一覧に、今登録したURLが表示されているはずです。その右側にある [Test] ボタンを押してみましょう。プルダウンから 「Push events」 を選んで実行します。
…おめでとうございます！Slackの該当チャンネルに、GitLabからのデフォルトの通知メッセージが飛び込んできたはずです。「おっ、繋がった！」という感動の瞬間ですね。
—
4. 現場で役立つ！「特定のタグ・ブランチ」のみに絞るフィルタリング
さて、基本設定はできたものの、このままだと「開発中の細かなプッシュ」のたびに通知が飛んできて、Slackが通知の嵐になってしまいます。これでは誰も見なくなってしまいますよね。
ここからが腕の見せ所です。「本番環境へのデプロイ（特定のタグやmainブランチへのマージ）の時だけ通知する」というフィルターをかけましょう。
GitLabのWebhook設定画面、あるいは後述するカスタムペイロードを活用することで、不要なノイズを完全に排除できます。
GitLabのWebhook設定では、「Push events」のサブオプションとして、特定のブランチ名（例: `main` や `release/`）に限定してトリガーさせることができます。
Webhook編集画面で、「Enable SSL verification」の近くにある 「Push events」の条件設定（Wildcardなど） を活用し、通知したい条件を絞り込みましょう。
—
5. 【極上のカスタマイズ】見やすく美しいカスタムJSONペイロードの作成
GitLabのデフォルト通知は少し情報量が多すぎたり、英語で味気なかったりします。
ここで、中級者から一歩抜け出すためのハック、「カスタムペイロード（Custom webhook payloads）」を使ってみましょう！
GitLabのWebhookでは、送信するJSONの形を自分で自由にデザインできます（GitLab Ultimateや、セルフホスト環境などで強力に使える機能ですが、基本的な概念は共通です）。
SlackのIncoming Webhookが理解できるJSONの形に整形して送ることで、以下のようにリッチで視認性の高い通知を作ることができます。
Slackに送るカスタムJSONの例
{
“text”: “🚀 本番デプロイが完了しました！”,
“attachments”: [
{
“color”: “#36a64f”,
“fields”: [
{
“title”: “リポジトリ”,
“value”: “my-awesome-project”,
“short”: true
},
{
“title”: “トリガーした人”,
“value”: “Taro Yamada”,
“short”: true
},
{
“title”: “対象ブランチ / タグ”,
“value”: “`main`”,
“short”: false
}
],
“footer”: “GitLab CI/CD Notification Bot”
}
]
}
このように、Slackのブロックキットやアタッチメントの仕様に合わせたJSONをGitLabから直接（あるいは間に軽量なAPIサーバーやAWS Lambdaなどを挟んで）送信するようにカスタマイズすると、チームメンバー全員が「ひと目で状況を把握できる」最高にエレガントな通知チャンネルが完成します。
—
まとめ：自動化で開発をもっと楽しく
お疲れ様でした！
今回は、GitLab WebhookとSlackを連携させて、デプロイ通知を自動化する基本からカスタマイズの考え方までを解説しました。
- Slack側でIncoming WebhookのURLを取得する
- GitLabのWebhooks設定にURLを登録し、イベントを選ぶ
- ノイズを減らすためにフィルターを検討する
- 必要に応じて通知のデザイン（JSON）をリッチにする
これを一度構築しておけば、チーム全体の安心感が段違いになります。「通知の確認」という人間がやるべきではない認知コストをシステムに肩代わりさせ、私たちは「より良いコードを書くこと」に集中しましょう。
あなたの開発ライフが、この連携によってより快適でエキサイティングなものになることを心から応援しています！