Slack API の新メソッドを試してみた【検証・CI 編】
2026 年に入ってから、Slack の Block Kit に新しいブロックが続々と追加されています。本シリーズでは、これらの新ブロックと関連する API を実際に試しながら紹介していきます。
- 第 1 弾: データ編
- 第 2 弾: 汎用表示編
- 第 3 弾: エージェント編
- 第 4 弾: ストリーミング編
- 第 5 弾: 検証・CI 編（本記事）
今回は最終回として Block Kit ペイロードを検証する blocks.validate メソッドを紹介します。
これまでは、Block Kit の JSON を検証するにはBlock Kit Builder に貼り付けて目視で確認するのが定石でした。この方法は手軽ですが、ペイロードの数が増えると 1 つずつ貼り付けるのは手間ですし、CI での自動チェックもできません。
blocks.validate はこのスキーマ検証を API として提供するもので、これによって Block Kit の検証を CI に組み込めるようになりました。本シリーズで見てきたとおり、新しいブロックは caption が必須だったり、ラベルと categories の一致が求められたりと制約が増えているため、投稿前に機械的に検証できるのは便利です。
検証には前回と同じく Slack CLI の slack api コマンドを使います。こちらのコマンドについては以下の記事をご参照ください。
blocks.validate の概要
| 項目 | 内容 |
|---|---|
| エンドポイント | POST https://slack.com/api/blocks.validate[1] |
| 引数 | blocks / view / message のいずれか 1 つだけを渡す |
| 必要なスコープ | なし。認証トークンなしでも呼び出せる |
blocks にはブロックの配列を、view にはモーダルなどのビューを、message にはメッセージのペイロード全体を渡します。
重要なのは認証トークンなしで呼び出せるという点です。渡した JSON をスキーマに照らして検証するだけなので、認証処理が不要なためです。
検証に失敗した場合、レスポンスの errors 配列に不正な箇所の情報が返ります。
| 項目 | 内容 |
|---|---|
pointer |
不正な箇所を指す JSON ポインタ |
code |
エラーコード |
message |
エラーの説明 |
constraint |
違反した制約の詳細 |
ペイロードを検証する
まずは正常なペイロードで試します。
$ slack api blocks.validate --no-auth blocks='[{"type":"section","text":{"type":"mrkdwn","text":"Hello"}}]'
{
"ok": true
}
次にエラーを確認します。第 1 弾で紹介した data table block は caption が必須でしたので、あえてそこを省略したペイロードで検証してみます。
$ slack api blocks.validate --no-auth blocks='[
{
"type": "data_table",
"rows": [
[ { "type": "raw_text", "text": "週" } ],
[ { "type": "raw_text", "text": "6/29 週" } ]
]
}
]'
{
"ok": false,
"error": "invalid_blocks",
"errors": [
{
"code": "missing_field",
"message": "missing required field: caption",
"field": "caption",
"pointer": "/0"
}
]
}
pointer の /0 は、渡した blocks 配列の 0 番目のブロックを指しており、そのブロックで caption フィールドが不足している、というレスポンスが返ってきています。
このように、どのブロックのどのフィールドが制約に違反しているかが pointer で返るため、ブロックの数が多いメッセージでも修正箇所をすぐ特定できます。
CI に組み込む
Block Kit の JSON ファイルをプルリクエストのたびに検証する GitHub Actions を組んでみます。
前提として、通知やレポートで使うペイロードを blocks/ ディレクトリに JSON ファイルとして置いている構成を想定します。ここでは簡単のため curl で直接呼び出します。
なお、JSON ボディでの送信は Authorization ヘッダーでトークンを渡す前提の形式のため、認証なしで呼び出す場合はフォーム形式を使う必要があります。
name: validate-block-kit
on:
pull_request:
paths:
- 'blocks/**.json'
- '.github/workflows/validate-block-kit.yml'
jobs:
validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Validate Block Kit payloads
run: |
status=0
shopt -s nullglob
files=(blocks/*.json)
if [ ${#files[@]} -eq 0 ]; then
echo "blocks/*.json が見つかりません"
exit 1
fi
for f in "${files[@]}"; do
res=$(curl -s -X POST https://slack.com/api/blocks.validate \
--data-urlencode "blocks@$f")
if [ "$(printf '%s' "$res" | jq -r '.ok')" = "true" ]; then
echo "OK: $f"
else
echo "NG: $f"
printf '%s' "$res" | jq .
status=1
fi
done
exit $status
検証に失敗したファイルがあればレスポンスをログに出力し、ジョブを失敗させます。
これで、ブロックの必須フィールドの漏れや文字数超過のようなミスをプルリクエストの段階で検出できるようになりました。
まとめ
本記事では、Block Kit ペイロードを検証する blocks.validate メソッドと CI への組み込み例をご紹介しました。
本シリーズはこれで最終回です。データ編から検証・CI 編まで、5 回にわたって Block Kit の新ブロックと関連 API を紹介してきました。
Block Kit がデータ表示・エージェント応答・ストリーミングなど多方面を担うようになり、どんどんエージェント向けに変化していっている潮流を感じていただけたなら嬉しいです。
ここまでお読みいただきありがとうございました！
