Contents
ESET Protect が生成する多行変数と Slack への送信概要
ESET Protect はアラート発生時に ALERT_MESSAGE などのテキスト変数を自動で作成します。これらは 改行が \n エスケープシーケンスとして埋め込まれたプレーンテキスト です。そのまま Slack の Incoming Webhook に渡すと、\n が文字列リテラルとして扱われて改行が失われたり、JSON パースエラーになることがあります。本セクションでは、変数の構造を確認しつつ、なぜ正しいエスケープ処理が必要かを解説します。
- 目的:
ALERT_MESSAGEの内容と内部表現を把握する - 重要性:改行が失われると情報が読めなくなり、インシデント対応に支障が出ます
- 結論:Slack に送る前に必ず
\n→\\nの二重エスケープ(または Block Kit で実際の改行を利用)を行う
ALERT_MESSAGE の内部表現と \n の位置付け
以下は典型的なアラートメッセージです。画面上では改行が入っていますが、ESET Protect が保持している文字列は \n で区切られています。
|
1 2 3 4 5 6 7 |
アラート種別: ウイルス検出 デバイス名: SERVER01 発生日時: 2026-04-30 14:22:05 詳細: - ファイル: C:\malware.exe - 検出エンジン: ESET NOD32 |
内部文字列(可視化)
|
1 2 |
アラート種別: ウイルス検出\nデバイス名: SERVER01\n発生日時: 2026-04-30 14:22:05\n詳細:\n- ファイル: C:\malware.exe\n- 検出エンジン: ESET NOD32 |
ポイント
-\nは「改行文字そのもの」を意味するエスケープシーケンスです。
- JSON に埋め込む際は、\が特別なエスケープ文字になるため、JSON 文字列中で\nをそのまま書くと\が抜け落ちてしまい Slack が正しく解釈できません。
Slack Incoming Webhook の JSON ペイロード仕様と最新制限
Slack 側の受信ロジックは公式ドキュメントに詳述されています(Incoming Webhooks – Slack API)。ここでは、ペイロード全体のサイズ上限やテキストフィールドの文字数上限を最新情報とともにまとめます。
| 項目 | 公式上限 (2024‑12 更新) | 備考 |
|---|---|---|
| HTTP リクエスト本文(JSON 全体) | 1 MiB (約 1,048,576 バイト) | text フィールドだけでなく、blocks 配列全体を含む |
text フィールド文字数 |
最大 40,000 文字 (UTF‑8 エンコード時に約 40 KB) | 実際には Slack が内部的に 40 KB のバイトサイズで制限 |
blocks 配列の各テキスト要素 |
最大 3,000 バイト(1 要素あたり) | Block Kit のドキュメント参照: Block Kit Builder – Limits |
根拠:上記数値はすべて Slack 公式 API リファレンスに掲載されている制限です。従来「40 KB」だけが語られることが多いですが、実際には「1 MiB」のリクエストサイズ上限があり、テキストフィールドごとに別個の制限があります。
JSON エスケープの基礎:\n と実際の改行 (\r\n) の違い
JSON 文字列は UTF‑8 でエンコードされ、次のような特殊文字は必ずバックスラッシュでエスケープする必要があります。
| エスケープ対象 | JSON 表記例 | 説明 |
|---|---|---|
バックスペース (\) |
\\ |
1 つのバックスラッシュを表す |
ダブルクオート (") |
\" |
文字列リテラル内で引用符を使用できる |
| 改行 (LF) | \n |
Unix 系 OS の改行コード |
| 復帰+改行 (CRLF) | \r\n |
Windows 系の改行コード |
Slack に送信したい「実際の改行」 は、JSON 文字列中では \n と書きます。ここで混乱しやすい点は、「エスケープされた \n(= \\n)」を送ると Slack がそれを テキスト として表示し、改行にはなりません。一方、二重エスケープ (\\n) を使うと、Slack が受け取った後に内部で 1 つのバックスラッシュが残り \n という文字列になるため、実際の改行として機能します。
エスケープ変換フロー(図解)
|
1 2 3 4 5 |
元テキスト (ESET) : "行A\n行B" JSON に埋め込む → "行A\\n行B" ← 二重エスケープ Slack が受信 → 文字列は "行A\n行B" 表示結果 → 行A(改行)行B |
ペイロード作成時のベストプラクティス
1. 二重エスケープを自動化する PowerShell スニペット
以下の例では、ConvertTo-Json が内部で必要なエスケープ(\ → \\)を行う点に注目してください。改行だけは手動で二重エスケープします。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
# ① ALERT_MESSAGE を取得(改行は LF のみ想定) $rawMessage = Get-Content -Path "alert.txt" -Raw # ② 改行を二重エスケープ (\n → \\n) $escapedMessage = $rawMessage -replace "`n", "\\n" # ③ JSON ペイロード作成(ConvertTo-Json が残りのエスケープ処理を担当) $payload = @{ text = $escapedMessage } | ConvertTo-Json -Depth 5 -Compress # ④ Webhook へ POST Invoke-RestMethod -Uri $env:SLACK_WEBHOOK_URL ` -Method Post ` -Body $payload ` -ContentType 'application/json' |
ポイント解説
| 手順 | 説明 |
|---|---|
-Raw オプション |
ファイル全体を 1 つの文字列として取得し、余計な配列化を防止 |
" |
PowerShell の改行コードは n(LF)なので、これを二重エスケープ |
ConvertTo-Json -Compress |
不要な空白や改行を除去し、1 MiB 以下に収めやすくする |
2. Bash / curl + jq で安全にエスケープ
jq -R . は「生文字列 → JSON 文字列リテラル」変換を自動で行い、\, ", 制御文字をすべて正しくエスケープします。さらに sed で改行だけ二重エスケープします。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
#!/usr/bin/env bash set -euo pipefail # ① ALERT_MESSAGE を取得(LF のみ想定) raw_message=$(cat alert.txt) # ② jq で JSON エンコード → "行A\n行B" json_encoded=$(printf '%s' "$raw_message" | jq -R .) # ③ 改行だけ二重エスケープ escaped_message=$(echo "$json_encoded" | sed 's/\\n/\\\\n/g') payload=$(cat <<EOF { "text": $escaped_message } EOF ) curl -X POST -H 'Content-Type: application/json' \ -d "$payload" "$SLACK_WEBHOOK_URL" |
| コマンド | 役割 |
|---|---|
jq -R . |
生文字列 → JSON リテラル(\, ", 制御文字を自動エスケープ) |
sed 's/\\n/\\\\n/g' |
改行エスケープだけ二重にする |
curl -d "$payload" |
1 MiB 未満であれば問題なく送信可能 |
3. Block Kit を使って「実際の改行」だけで済む方法
Block Kit の mrkdwn テキストは 実際の LF 改行 がそのまま表示されます。したがって、二重エスケープは不要です。ただし文字列長に 3 KB の上限がある点に注意してください。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
{ "blocks": [ { "type": "section", "text": { "type": "mrkdwn", "text": "*アラート概要*\nアラート種別: ウイルス検出\nデバイス名: SERVER01\n詳細:\n- ファイル: C:\\malware.exe\n- エンジン: ESET NOD32" } } ] } |
公式リファレンス:Block Kit のフィールド仕様は Blocks – Slack API に掲載されています。
テスト・デバッグ手順とチェックリスト
1. curl での送信結果を即時確認
|
1 2 3 4 |
curl -s -o /dev/null -w "%{http_code}\n" \ -X POST -H 'Content-Type: application/json' \ -d @payload.json "$SLACK_WEBHOOK_URL" |
200が返れば成功、400系は JSON 構文エラーです。-s(サイレント)で余計なプログレス表示を抑制し、%{http_code}のみ出力します。
2. Slack デバッグページの活用
Webhook 作成時に表示される Incoming Webhooks デバッグツール に JSON を貼り付ければ、Slack が受信したときの内部パース結果が即座に確認できます。エラーが出たら、\\n の有無や文字エンコードを再チェックしてください。公式ガイドは Incoming Webhooks – Slack API を参照。
3. ペイロードサイズの測定
|
1 2 |
wc -c payload.json # バイト数を出力 |
- 1 MiB (1,048,576 バイト) を超えないか必ず確認してください。
textフィールドだけであれば、40 KB(約 40,000 文字)以内に収めるのが安全です。
トラブルシューティングチェックリスト
| # | 確認項目 | 判定方法 |
|---|---|---|
| 1 | ALERT_MESSAGE に改行 (\n) が含まれているか |
cat alert.txt | cat -A( $ が改行位置)で可視化 |
| 2 | JSON 内の改行が二重エスケープ (\\n) になっているか |
jq . payload.json で整形後に \\n を検索 |
| 3 | Webhook URL が正しい環境変数に設定されているか | echo "$SLACK_WEBHOOK_URL" の出力を確認 |
| 4 | HTTP ステータスが 200 かつレスポンスボディが空でないか | 上記 curl コマンドの %{http_code} と -i オプションでヘッダーも表示 |
| 5 | Block Kit 使用時は blocks 配列構造が正しいか |
JSON Lint(https://jsonlint.com/)や Slack のデバッグツールで検証 |
| 6 | ペイロードサイズが 1 MiB 以下、かつ text は 40 KB 未満か |
wc -c payload.json と grep -o '\\n' で文字数を算出 |
実装例のまとめと CI/CD への組み込み
PowerShell 関数化(再利用性向上)
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
function Convert-ESETMessageForSlack { param( [Parameter(Mandatory)][string]$Message ) # LF 改行だけを二重エスケープ return $Message -replace "`n", "\\n" } # GitHub Actions での呼び出し例 # steps: # - name: Send ESET alert to Slack # run: | # $msg = Get-Content alert.txt -Raw # $payload = @{ # text = $(Convert-ESETMessageForSlack -Message $msg) # } | ConvertTo-Json -Compress # curl -X POST -H "Content-Type: application/json" -d "$payload" ${{ secrets.SLACK_WEBHOOK_URL }} |
Bash 関数化(CI パイプライン向け)
|
1 2 3 4 5 6 7 8 9 10 11 12 |
encode_message() { local raw="$1" # jq が JSON エスケープ、sed が改行二重エスケープを担当 printf '%s' "$raw" | jq -R . | sed 's/\\n/\\\\n/g' } # GitLab CI の例 # script: # - raw=$(cat alert.txt) # - esc=$(encode_message "$raw") # - payload="{\"text\": $esc}" # - curl -X POST -H "Content-Type: application/json" -d "$payload" "$SLACK_WEBHOOK_URL" |
まとめ
- ESET Protect の
ALERT_MESSAGEは\nが埋め込まれた文字列 であり、Slack にそのまま送ると改行が失われます。 - 公式ドキュメント(Incoming Webhooks – Slack API)に基づき、ペイロード全体は 1 MiB、
textフィールドは 40 KB が上限です。 - 二重エスケープ (
\\n) を行うか、Block Kit のmrkdwn/sectionで実際の LF 改行を使用することで、正しい改行表示が可能になります。 - PowerShell と Bash それぞれに安全なエスケープ手順を示しました。どちらも
jqやConvertTo-Jsonの自動エスケープ機能を活用すれば、手作業ミスを大幅に削減できます。 - テスト・デバッグ は curl と Slack デバッグツールで即時確認し、チェックリストで定期的に検証するとトラブルが未然に防げます。
これらの実装例とベストプラクティスを社内の自動化ジョブやインシデント対応フローに組み込めば、ESET Protect のアラート情報が Slack で見やすくなるだけでなく、運用ミスによる誤送信やエラー発生も大幅に減少します。ぜひ本稿の手順を試し、継続的改善に活かしてください。