← 戻る

Slack Bot を Cloudflare Workers で構築するプロセスと知見

cloudflare-workers slack-api ai-automation github-api

概要

社内ドキュメントサイト（VitePress + Cloudflare Pages）に対して、Slackから自然言語でドキュメント追加・修正を指示するとAIがMarkdownを生成しGitHub PRを自動作成するBotを構築した。

アーキテクチャ

Slack (/update-doc コマンド)
  → Cloudflare Workers（署名検証・ルーティング）
    → Claude API（AI Gateway経由、自然言語→Markdown変換）
    → GitHub REST API（ブランチ作成・ファイル追加・PR作成）
  → Slack（response_url にPRリンク返信）

実装プロセスの流れ

  1. マイルストーン定義 → タスク自動分解（15タスク、5マイルストーン）
  2. 基盤構築（MS20: 5タスク直列）→ Slack App登録・Workers雛形・署名検証・コマンドハンドラ・デプロイ
  3. 機能実装（MS21: 3タスク、一部並列）→ Claude API連携・GitHub API連携・フロー統合
  4. 各タスクをサブエージェントに委譲し、メインコンテキストを軽量に保つオーケストレーターパターン

技術的な知見

Slack Bolt は使わない

Workers環境ではNode.js依存が問題になるため、fetchハンドラに直接実装。Web APIベースで署名検証もHMAC-SHA256をWeb Crypto APIで自前実装。

3秒タイムアウト対策

Slackはコマンド応答を3秒以内に要求する。ctx.waitUntil()でバックグラウンド処理を起動し、即座に「処理中です…」を返す。完了後はresponse_urlにフォローアップ送信。

Workers のサブドメインは予測できない

wrangler deployの出力で初めてURLが確定する。READMEにプレースホルダーを書くと後で修正が必要になる。デプロイ後に確認して設定するフローにすべき。

Event Subscriptions の URL Verification

Slackの設定画面でRequest URLを入力すると即座にchallengeリクエストが飛ぶ。Workerがデプロイ済み＋Secrets設定済みでないと検証が失敗する。設定手順の順序が重要。

GitHub App JWT認証（RS256）on Workers

PEM秘密鍵をcrypto.subtle.importKey("pkcs8", ...)でインポートし、crypto.subtle.sign("RSASSA-PKCS1-v1_5", ...)で署名。Installation Tokenはメモリキャッシュで有効期限管理。

設計判断

判断理由
Octokit不使用依存を増やさない。fetchベースで軽量実装
Zod不使用devDependencyに入っていないため型ガードで手動バリデーション
AI Gateway経由ログ・レート制限・モニタリングをCloudflareに委譲
PRベースレビューによる品質担保。誤った内容が直接公開されない