Slack Incoming Webhook 完全ガイド：設定・送信・テキスト処理

Incoming Webhook の概要と取得手順

What is Incoming Webhook?

• シンプルな HTTP POST エンドポイントです。認証は URL に埋め込まれているため、別途トークンや OAuth は不要です。
• ペイロードは JSON 形式で送信し、text（プレーンテキスト）または blocks（Block Kit）をトップレベルに配置すれば Slack が自動的にレンダリングします。

取得手順

※ セキュリティ上の注意
- Webhook URL は機密情報です。Git リポジトリや公開サーバーに平文で保存しないこと。
- 必要に応じて IP 制限（Enterprise Grid の場合）や 環境変数 で管理してください。

最小構成の JSON と送信例

cURL（Linux/macOS/Windows Subsystem for Linux）

PowerShell（Windows）

まとめ（この章の要点）

• URL を取得 → JSON を POST が基本フロー。
• text と blocks のいずれかを必ず含め、Content-Type: application/json を付与すれば即座にメッセージが届く。
• Webhook URL は機密情報として扱い、環境変数やシークレット管理ツールで保護すること。

テキストタイプと改行コードの正しい扱い方

Slack がサポートしているテキストタイプは大きく分けて 2 種類 です。

改行コードに関するベストプラクティス

1. JSON 内では常に LF (\n) のみを使用

2. Windows で作成したファイルは CRLF (\r\n) が混入しやすいが、Slack は \r を無視してしまうため必ず除去する。

3. 文字列リテラルのエスケープ
   json
{
"blocks": [
{
"type": "section",
"text": {
"type": "mrkdwn",
"text": "*ログ*\n\nLine1\nLine2\n"
}
}
]
}

4. 上記は \n が 2 回 エスケープされている点に注意（JSON 文字列内部でのエスケープと Slack の改行解釈）。

5. プレーンテキストでも \n は有効
   json
{
"blocks": [
{
"type": "section",
"text": {
"type": "plain_text",
"text": "1 行目\n2 行目"
}
}
]
}

文字コード

• Slack は UTF‑8 のみを受け付けます。
• curl や PowerShell で送信する際は必ず charset=utf-8 をヘッダーに含めるか、ツール側のエンコーディング設定を確認してください。

まとめ（この章の要点）

• 多行テキストは mrkdwn + エスケープされた \n が最も汎用的。
• Windows の CRLF は除去し、常に LF (\n) に統一する。
• ペイロード全体を UTF‑8 でエンコードし、ヘッダーに明示的に指定する。

section ブロックで多行テキストを表示するベストプラクティス

基本構造

コードブロックやインラインコードを混在させる例

特殊文字のエスケープ表

ポイント：mrkdwn のパーサは上記エスケープが無いと意図しない装飾や構文エラーになることがあります。

文字数・サイズ制限

• 1 ブロックあたり 最大 3000 文字（改行含む）。
• Webhook 全体のペイロードは 最大 1 MB。超過した場合は 400 invalid_payload が返ります。

まとめ（この章の要点）

• section + mrkdwn が多行テキスト・コードブロック共通で最も扱いやすい。
• 特殊文字は必ず JSON エスケープし、サイズ上限に注意する。

Rich Text 系ブロックの利用 – 現状と注意点

「公式に推奨」かどうか？

2023 年 9 月時点の Slack API ドキュメント（https://api.slack.com/block-kit）では、rich_text_* 系ブロックは「サポート対象」として記載されていますが、「推奨される」旨の明言はありません。
そのため、本稿では 「利用可能だが公式にプライオリティ付けされた推奨項目ではない」 と表現します。

注釈：2025‑2026 年版 Block Kit Builder でも rich_text は選択肢の一つとして表示されますが、従来の section/mrkdwn に比べて UI が限定的（テーブルやインデントはサポート外）である点に留意してください。

主な Rich Text 要素

例：箇条書きリスト

Block Kit Builder の活用手順

1. ブラウザで Block Kit Builder（https://app.slack.com/block-kit-builder）にアクセス。
2. 左側エディタに上記 JSON を貼り付け、右側プレビューで見た目を確認。
3. 「Copy JSON」ボタンで確定したコードを自分のスクリプトへ組み込む。

使いどころと制限

注意点：一部クライアント（モバイル版など）では rich_text_* の描画が若干異なる場合があります。重要な情報は併せて section/mrkdwn でも提供すると安全です。

まとめ（この章の要点）

• rich_text_* は 「利用可能」 な機能であり、公式に「推奨」されているわけではない。
• 箇条書きや等幅コードブロックなど、特定用途で便利だが互換性を確認しつつ使用すること。

実務事例：ESET Protect の多行テキスト問題と対策

背景（何が起きたか）

• ESET Protect が生成したアラート変数 ALERT_MESSAGE には改行 (\n) が含まれる。
• 従来のペイロードでは mrkdwn に \n を入れず、plain_text を使用していたため Slack 側で改行が失われ、1 行に潰れて表示 された。

出典について：本事例は 2025 年 1 月 27 日に ESET 社公式フォーラム（[ESET Community – Alert Formatting]）で報告された内容を元にしています。投稿者が示したサンプルコードとその後のコメントから情報を抽出しましたが、正式なドキュメント化はされていない点をご留意ください。

解決策概要

1. 変数側で改行文字をエスケープ
2. Bash 例：ESCAPED=$(printf '%s' "$ALERT_MESSAGE" | sed 's/"/\\"/g; s/$/\\n/')
3. ペイロードは rich_text_preformatted に切り替える（等幅で改行が保持されやすい）
4. テストは Block Kit Builder と Webhook テストページで二段階検証

手順詳細

1️⃣ 変数エスケープ（シェルスクリプト例）

• sed で 二重引用符 と 改行 をエスケープ。
• 必要に応じて awk '{printf "%s\\n",$0}' 等でも可。

2️⃣ ペイロード（Rich Text Preformatted）

• ${ESCAPED} はシェル変数展開後の文字列がそのまま入ります。
• rich_text_preformatted が等幅フォントで 改行を忠実に再現。

3️⃣ テストフロー

追加のベストプラクティス

• 変数は必ずシングルクオートで囲む → シェル展開時の予期せぬ文字置換防止。
• ペイロードサイズ：ESET のアラートは長文になることがあるため、1 MB 超過しないように事前に wc -c でバイト数を測定。
• デバッグ情報の付加：失敗時に Slack が返すエラーオブジェクト（例: invalid_blocks) を標準出力へリダイレクトして CI/CD パイプラインで検知。

まとめ（この章の要点）

• ESET Protect の改行が失われる問題は 「変数側で \n エスケープ + rich_text_preformatted」 に置き換えることで解決できる。
• 出典がフォーラム投稿に基づくため、実装前に自社環境で必ず検証すること。

テスト・デバッグ手法とよくあるエラー

1. Webhook テストページの活用

• URL 発行画面右上の 「Test this webhook」 ボタンから直接 JSON を貼り付けて送信可能。
• 成功時はステータス 200 OK、失敗時はエラーメッセージ（例: invalid_payload, invalid_blocks）が返る。

2. Block Kit Builder での事前検証

3. コマンドラインでのデバッグテクニック

• -v オプションで リクエスト/レスポンスヘッダー と ステータスコード を取得。
• エラーメッセージは JSON の "error" フィールドに格納されていることが多い。

4. よくあるエラーと対処法

5. ログとモニタリング

• Slack の API ダッシュボード（https://api.slack.com/apps → 「Incoming Webhooks」）でリクエスト履歴が確認できる。
• 外部監視ツール（Datadog, New Relic 等）に curl のステータスコードを送信し、失敗時のアラートを設定すると運用上安心。

まとめ（この章の要点）

1. テストは必ず二段階：Webhook テストページ → Block Kit Builder。
2. エラーは JSON 構文かブロック定義ミスが多い。Linter とビルダーで事前検証を徹底する。
3. 文字コード・サイズ制限に注意し、UTF‑8 かつ 1 MB 未満で送信する。

全体まとめ & 参考リンク

主な公式ドキュメント

• Slack API – Incoming Webhooks: https://api.slack.com/messaging/webhooks
• Block Kit Builder: https://app.slack.com/block-kit-builder
• Block Kit 文法リファレンス（2023 年版）: https://api.slack.com/reference/block-kit/blocks

参考情報（外部リンク）

• JSON Lint: https://jsonlint.com/
• ESET Community – Alert Formatting (2025‑01‑27) （※公式フォーラム投稿、内容は非公式）
• 「Slack アプリ開発入門」Tech Blog（2024 年更新版）

この記事は 2026 年 4 月現在の情報を基に作成しています。Slack の機能や API は随時変更されるため、実装前には必ず最新公式ドキュメントをご確認ください。