Contents
簡易ハンズオン：まず試すMakeとSlackの連携
まず動く最小構成で確認します。
ここではGoogle Sheets→Slack通知とGitHub PR承認の簡易ワークフローを示します。
各手順は短時間で再現でき、ログで動作を確認できます。
Google Sheets から Slack へ通知する手順
Google SheetsをトリガーにSlack通知する最低構成です。
- Google Sheetsで通知用シートを作る。ヘッダ例: ID, Title, Description, Link, Notified。
- MakeでScenarioを作成。トリガーはGoogle Sheets → Watch Rows（New or Updated Rows）。
- アクションに Slack → Post a Message モジュールを追加し接続を選択します。
- Block Kitで見やすく整形し、シートの各カラムをマッピングします。
- Scenarios画面で「Run once」を実行し、テスト行を追加して確認します。
- 実行ログで入力ペイロードとSlackのレスポンス（okやts）を確認します。
Slackモジュールで対応できない細かい制御はHTTPモジュール（Make: HTTP → Make a request）を使います。
HTTPモジュールでトークンを使う際は、トークンを直接記載せず外部ブリッジか秘密管理で注入してください。
GitHub PR の承認ワークフロー（簡易）
GitHub PRを起点に承認ボタンでマージする簡易フローです。
-
GitHubでWebhookを作成し、MakeのCustom webhook URLを登録します。
代替: MakeのGitHubモジュールで Watch Pull Requests を使います。 -
MakeでWebhookトリガー → SlackにBlock Kitメッセージを Post（Approve/Reject ボタン）。
- ボタン押下は署名検証済みのブリッジ経由でMakeに転送します（下で詳細）。
- 承認時はGitHub APIを呼んでマージします（GitHubモジュールまたはHTTP）。
- 結果を chat.update で元メッセージに反映し、スレッドに詳細を投稿します。
以下はBlock Kit例で、action_idとvalueを明確に渡す例です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
{ "channel": "<CHANNEL_ID>", "text": "PR #<ID> の確認が必要です", "blocks": [ { "type": "section", "text": { "type": "mrkdwn", "text": "PR <title> がオープンしました" } }, { "type": "actions", "elements": [ { "type": "button", "text": { "type": "plain_text", "text": "Approve" }, "style": "primary", "action_id": "approve_pr", "value": "{\"repo\":\"owner/repo\",\"pr\":123}" }, { "type": "button", "text": { "type": "plain_text", "text": "Reject" }, "style": "danger", "action_id": "reject_pr", "value": "{\"repo\":\"owner/repo\",\"pr\":123}" } ] } ] } |
value に JSON を入れておくと、押下イベントで PR 情報がそのまま得られます。
詳細実装パターン：署名検証・Socket Mode・Interactive
ここでは実務で間違いやすい実装を補足します。
署名検証やSocket Modeの扱い、Interactive payloadのパース例を示します。
Makeでの直接検証が難しい場合のブリッジ実装も載せます。
署名検証の正確な手順（HMAC-SHA256）
署名検証はraw bodyを用いて厳密に行う必要があります。
- ヘッダ X-Slack-Signature と X-Slack-Request-Timestamp を取得します。
- basestring を "v0:" + timestamp + ":" + raw_body として作ります。
- signing_secret で HMAC-SHA256 を計算し "v0=" を先頭に付けます。
- timing-safe 比較で Slack の署名と比較します。
- タイムスタンプ差（例: 5分）を超えていたら拒否します。
- url_verification の場合は challenge をそのまま返します。
以下は Node/Express と Python/Flask の実装例です。
Node（Express）例:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
// 必要: express, raw-body または express.raw const express = require('express'); const crypto = require('crypto'); const axios = require('axios'); const app = express(); app.use(express.raw({ type: '*/*' })); app.post('/bridge', async (req, res) => { const raw = req.body.toString(); const ts = req.get('X-Slack-Request-Timestamp'); const sig = req.get('X-Slack-Signature'); if (Math.abs(Date.now() / 1000 - Number(ts)) > 60 * 5) { return res.status(400).send('timestamp_out_of_range'); } const basestring = `v0:${ts}:${raw}`; const mySig = 'v0=' + crypto.createHmac('sha256', process.env.SLACK_SIGNING_SECRET) .update(basestring).digest('hex'); if (!crypto.timingSafeEqual(Buffer.from(mySig), Buffer.from(sig))) { return res.status(401).send('invalid_signature'); } const body = JSON.parse(raw); if (body.type === 'url_verification') { return res.json({ challenge: body.challenge }); } res.status(200).send(); // まずACK // 非同期でMakeへ転送 await axios.post(process.env.MAKE_WEBHOOK_URL, body); }); |
Python（Flask）例:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
from flask import Flask, request, jsonify import hmac, hashlib, time, os, requests app = Flask(__name__) @app.route('/bridge', methods=['POST']) def bridge(): raw = request.get_data(as_text=True) ts = request.headers.get('X-Slack-Request-Timestamp') sig = request.headers.get('X-Slack-Signature') if abs(time.time() - float(ts)) > 60*5: return 'timestamp_out_of_range', 400 basestring = f'v0:{ts}:{raw}' mySig = 'v0=' + hmac.new( os.environ['SLACK_SIGNING_SECRET'].encode(), basestring.encode(), hashlib.sha256 ).hexdigest() if not hmac.compare_digest(mySig, sig): return 'invalid_signature', 401 body = request.get_json() if body.get('type') == 'url_verification': return jsonify({'challenge': body['challenge']}) # ACK requests.post(os.environ['MAKE_WEBHOOK_URL'], json=body) return '', 200 |
MakeのCustom Webhookは受信内容をパースしますが、raw バイト列の取得が難しい場合があります。
そのため署名検証はブリッジ側で行うことを推奨します。
ブリッジ実装例：署名検証→ACK→Make転送（Node/Express）
Makeでの署名検証が困難な場合は、軽量ブリッジを用意して検証とACKを担当させます。
上のNode例のようにACK後にMakeのWebhookへ非同期転送します。
ブリッジはログと再送機能を持たせると運用が安定します。
Socket Modeブリッジ（Node + @slack/socket-mode）
公開エンドポイントを用意できない場合はSocket Modeで受けます。
App-level token（xapp-）を使いSocket Modeクライアントでイベントを受けてMakeへ転送します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
const { SocketModeClient } = require('@slack/socket-mode'); const axios = require('axios'); const client = new SocketModeClient({ appToken: process.env.SLACK_APP_LEVEL_TOKEN }); (async () => { await client.start(); client.on('events_api', async ({ body, ack }) => { await ack(); // 即時ACK await axios.post(process.env.MAKE_WEBHOOK_URL, body); }); })(); |
Socket Mode用のapp tokenには connections:write が必要です。
Interactive / Block Kit のフィールドとMakeでのマッピング例
Block Kitの押下イベントはpayloadにJSONで格納されます。
重要フィールドは action_id、value、callback_id、response_url、user.id、channel.id です。
例: 押下イベントをブリッジでJSON化してMakeへ渡すと次のように扱えます。
- payload.actions[0].action_id → フロー分岐キーに使う。
- payload.actions[0].value → ボタン固有データ（JSON推奨）をデコードして利用。
- payload.response_url → 非同期更新用にHTTPで呼ぶ。
- payload.user.id / payload.channel.id / payload.message.ts → chat.update 等に利用。
Make側の受け取り例（概念）:
- Webhookトリガーで payload を受け取る。
- Tools → Parse JSON で payload を展開する。
- Routerで action_id または value の内容で分岐する。
- 必要に応じて HTTP モジュールで response_url に結果を投げる、または Slack モジュールで chat.update する。
response_url は署名不要で、そのまま使えます。重い処理はACK後に非同期で response_url を叩くか chat.update を呼んでください。
運用・監視・セキュリティ（MakeとSlackの連携）
運用段階ではレート制限や再試行、コスト管理が重要です。
ここでは監視項目、レート制御、テンプレート移行時の注意点を整理します。
運用チェックリスト（起動前・稼働中）
導入前後に確認すべき項目を運用チェックリストにまとめます。
- インポート後に全ての接続を自分の環境へ差し替える。
- Run once で動作確認しエラーログを精査する。
- 古いシナリオは無効化して重複実行を防ぐ。
- 監視: シナリオ失敗率、エラー数、遅延をアラート化する。
- トークンローテーションと権限レビューの運用を決める。
- ステージング環境で負荷試験と異常系テストを実施する。
レート制限の扱いと推奨閾値（運用例）
Slackのレート制限はメソッドやワークスペースで変動します。
429時は Retry-After を尊重し、無い場合は指数バックオフを実装します。
- 推奨バックオフ: base=1秒、attempts上限5回、max_delay=60秒、ジッターを加える。
- 429受信時: Retry-After があればその秒数だけ待機する。
- 実務目安（保守的）: chat.postMessage は継続的に 1 req/sec を超えないようにする。
- バッチ処理: 一度に送る件数は 20〜50 件を目安にし、バッチ間に短い遅延を入れる。
- conversations.list 等は limit=100 とし cursor で分割して取得する。
Make上では Flow Control の Delay や外部キューでスロットリングを行ってください。
テンプレート運用の具体手順とトラブル回避
テンプレートの取り込みと切り替え時に発生しやすい問題を防ぎます。
- テンプレートをImportしたら直ちに各モジュールの接続を差し替える。
- スコープ不足で起きる missing_scope は再インストールで解消する。
- 本番切替はステージングでフルテスト後に行い、切替時は旧シナリオを停止する。
- 事前に影響範囲（通知先やAPI実行回数）を確認する。
- 接続の権限不足で失敗した場合は Make の実行ログと Slack App の監査ログを照合する。
コスト最適化
Makeは操作数で課金されるため最適化が重要です。
- ポーリングを減らしてWebhookへ切り替える。
- 複数の更新をまとめて1回のAPI呼び出しにする。
- 条件で処理を分岐し不要なモジュール呼び出しを抑える。
免責事項と参考リンク
このガイドは実務的な手順を示す参考情報です。
詳細仕様や最新の挙動は公式ドキュメントを参照してください。
組織のセキュリティポリシーやSlackのサポート窓口に従って運用してください。
- Slack署名検証: https://api.slack.com/authentication/signing-requests
- App-level token（Socket Mode）: https://api.slack.com/authentication/token-types#app-level-tokens
- Socket Mode ドキュメント: https://api.slack.com/apis/connections/socket
- Block Kit / インタラクティビティ: https://api.slack.com/block-kit, https://api.slack.com/messaging/interactivity
- chat.postMessage 等のWeb API: https://api.slack.com/methods/chat.postMessage
- Make ヘルプセンター（Webhooksやモジュール）: https://www.make.com/en/help
まとめ
ここまでの要点を押さえて段階的に導入してください。
まずは小さなテンプレートで動作確認を行い、段階的に本番投入します。
- OAuthは最小権限で発行し、スコープ変更後は再インストールする。
- 署名検証はraw bodyで厳密に行い、Makeで直接取れない場合はブリッジを使う。
- Socket ModeはApp-level token（connections:write）を用い、ブリッジでMakeへ転送する。
- Interactiveは action_id/value/response_url を明確に設計し、Makeでパースして分岐する。
- レート制御は Retry-After を尊重し、指数バックオフとジッターでリトライ設計を行う。