Slack通知botをAIで作る5つの設計ポイント

Slack通知botは、作ること自体より、何を知らせるかを決めるほうが難しい。ここを曖昧にすると、便利なはずのbotがただの騒がしい同僚になる。Webhook、GitHub Actions、OpenAI APIをどう組み合わせれば、通知が増えても破綻しないのかを、設計から運用まで順に整理する。

読後には、通知botの基本構成、AIを入れるべき場面、コストの見積もり方、権限設計で外せない点がつかめるはずだ。「まず何を作るか」ではなく「どこまで自動化するか」から考えると、実装の迷いがぐっと減る。

Slack通知botの基本構成

結論はシンプルで、Slack通知botは受信・整形・送信・必要ならAI処理の4層に分けると扱いやすい。いきなりAIを中心に置くより、まず通知の流れを単純にしたほうが壊れにくい。

Webhookは外部サービスのイベントを受け取る入口であり、GitHub Actionsはその後の処理を自動実行する土台だ。Slack APIでチャンネルへ投稿し、必要なときだけOpenAI APIで要約や分類を加える。この分け方なら、通知の責任範囲が見えやすい。botの中心はAIではなく業務イベントだと押さえておくと、設計がぶれにくい。

公式情報は、Slack APIの公式ガイド、GitHub Actionsの公式ドキュメント、OpenAI APIの公式ドキュメントを起点に確認するとよい。仕様は動く。だからこそ、一次情報を前提に組み立てるほうが安全である。

この構成のよさは、AIが止まっても通知自体は動く点にある。逆に、全部をAIに寄せるとモデルの応答や利用制限に運用が引っ張られる。壊れにくいbotは、AIを補助輪として使っているのである。

WebhookとGitHub Actionsのつなぎ方

最初の一歩は、Webhookの入口を1種類に絞ることだ。GitHub、Stripe、フォームサービスなど、イベントの種類はいくらでもあるが、初手で増やすとテストが複雑になる。通知botは小さく始めたほうが、結局は早い。

GitHub Actionsを使うと、イベント検証、整形、分岐、再送処理をワークフローとして管理しやすい。たとえば、受け取ったJSONをチェックし、条件に合うものだけSlackへ送る流れは相性がいい。Webhookの署名検証、重複排除、失敗時のログ保存は、地味だが欠かせない。ここを省くと、同じ通知が何度も飛んでくる“通知のカレー食べ放題”が始まる。

実務で大切なのは、IDを持つイベントだけを処理し、再実行時は同じ通知を二重送信しないことだ。特に外部サービスは再送を行うことがあるため、1回だけ動いたように見えて実は2回送っている、という事故が起きやすい。botの信頼性は、この小さな気配りでかなり変わる。

SecretsにはSlackのBot TokenやOpenAI APIキーを入れ、コードに直書きしない。これは基本中の基本だが、現場では案外抜ける。鍵を机の上に置かないのと同じで、認証情報はコードから切り離すのが鉄則である。

編集部としては、見落としがちなのは「早く作れること」と「長く使えること」を同じだと考えてしまう点だと見る。試作はWebhook直結でも十分だが、運用に乗せるなら再送、失敗、監視まで含めて設計したほうがいい。作成速度より、翌月も静かに動いているかが本番の評価軸である。

AI要約を入れる場面と外す場面

AIは長文を短くする、分類する、次のアクションを提案する用途に強い。Slack通知botでは、問い合わせ本文の要点抽出、Issueの概要化、ログの異常箇所のハイライトなどがわかりやすい使いどころだ。

一方で、最終判断までAIに任せるのは危うい。承認、請求、顧客対応のように誤判定が痛い業務では、人間の確認を残すほうが現実的だ。AIは下書き係、決裁者は人間という役割分担が、今のところは一番筋がいい。

たとえば問い合わせbotなら、AIに「緊急」「要確認」「定型返答でよい」の3分類をさせるだけでも十分役に立つ。返信文そのものを自動送信するより、優先度付けに使うほうが失敗が少ない。ここは地味だが、現場では効く。

AIが長い文章を扱うときは、投入前に余計な定型文を落とすと精度が安定しやすい。文脈を保てる長さには限りがあるため、本文の丸投げより、件名・本文・発生時刻のような要点を先に整えるほうがいい。要約の質は、入力の整頓でかなり決まる。

OpenAIの公式ドキュメントでは、APIの使い方や制約が確認できる。要約中心なら軽量なモデルで足りることも多く、むやみに高性能モデルへ寄せればよいわけではない。料金や使い分けの感覚をつかみたいなら、主要AIのAPI料金比較も合わせて読むと判断しやすい。

用途の整理をもう少し広げたいなら、長文PDFの扱い方をまとめた以下の記事で詳しく紹介している。

AIでPDFを読む5ステップと実践比較

コスト管理の考え方

Slack通知botのコストは、実行回数、AI呼び出し回数、送信先数の3つでほぼ決まる。WebhookとSlack投稿だけなら軽いが、要約や分類を毎回AIに投げると、トークン消費が地味に積み上がる。通知は1件ずつは小さくても、毎日回すと侮れない。

費用を見るときは、1回の通知が何秒の手作業を削るかで考えるとよい。ROIは「削減された手作業時間」で見るとぶれにくい。たとえば、5分かかっていた確認が30秒で済むなら、botの価値は十分にある。逆に、botの出力を毎回人が添削するなら、自動化のうまみは薄い。

料金や仕様は変わるので、固定観念で覚えないほうがいい。Slack、GitHub、OpenAIの各公式ページで最新情報を確認し、botの設計は「少し余裕を持たせる」くらいがちょうどよい。予算はいつも、あとで増えがちだ。

セキュリティで外せない確認項目

最初に守るべきなのは、トークン管理、アクセス権限、送信データの最小化である。AIを挟むと「便利だから何でも送る」が起きやすいが、それが一番危ない。Slackの権限は必要最小限にし、投稿先も限定するのが基本だ。

たとえば顧客問い合わせをAIに送るなら、氏名、メールアドレス、注文番号などをどこまで伏せるかを決める必要がある。個人情報を見えなくする処理、つまりマスク処理を通してから送るほうが安全だ。社内利用でも、機微情報はそのまま投げない。これは徹底したい。

Slackの認証と権限に関する公式情報では、アクセストークンやスコープの考え方が確認できる。ここを曖昧にしたまま進むと、あとで「誰がどこまで見られるのか」が分からなくなる。便利なbotほど、権限は静かに細くするのが正解だ。

編集部の見立てでは、bot導入初期に価値があるのはAIの高度化より、運用ルールの言語化である。誰が止めるのか、失敗したらどこへ通知するのか、ログを何日残すのか。この三点が曖昧だと、botは動いていても安心して任せられない。自動化は、責任の置き場まで設計して初めて回る。

AIに渡す前の情報整理や、長文の切り分け方を押さえたいなら、以下の記事で詳しく紹介している。

AIが長文を忘れる理由は？トークンと文脈の実践ガイド

最短で形にする導入手順

最短ルートは、通知1種類・送信先1つ・AIは任意から始めることだ。いきなり「要約も分類も返信案も全部やる」構成にすると、テスト項目が増えすぎる。まずは動く最小単位を作り、その後にAIを足すほうが、結果として速い。

• Webhookでイベントを1種類受け取る
• GitHub Actionsで検証と分岐を行う
• Slackの特定チャンネルへ投稿する
• 必要な場合だけOpenAI APIで要約を付ける
• 失敗時のログと再実行ルールを決める

この順番なら、動作確認もしやすい。まずAIなしで通知だけ通し、その後に要約や分類を加える。土台→装飾の順で作ると、壊れたときの原因が追いやすい。家でいえば、先に壁紙より骨組みを固める感じである。

Slack連携の自動化そのものをもう少し広く見たい場合は、以下の記事で詳しく紹介している。

Make・Zapier・n8n比較：業務自動化の決定的な違い

実装で迷いやすいのは、AIの出力をそのまま使うか、ルールで整えるかだ。結論から言えば、最初はルールで整える比率を高くし、AIは短い補助に留めるのが安全である。出力形式を固定しておくと、Slack上で読みやすさも保ちやすい。

たとえば、Slack投稿は「件名」「要点」「推奨アクション」の3行にそろえるだけで、受け手の理解速度がかなり変わる。AIで自由作文にすると見栄えはよくても、必要情報が散りやすい。通知は小説ではなく、路線図に近い。一目で次の行動が分かることが、botの正義である。

この記事のポイント

• Slack通知botは、受信・整形・送信・AI処理の4層で考えると設計しやすい。
• WebhookとGitHub Actionsを分けると、通知の入口と実行基盤を整理しやすい。
• AIは要約や分類に向くが、最終判断まで任せる設計は避けるべきだ。
• コストは実行回数とAI呼び出し回数で膨らむため、先に見積もる必要がある。
• トークン管理、権限最小化、重複排除が、運用で最も効く安全対策になる。

参考情報（主要ソース）

• Slack API 公式ガイド
• Slack 認証と権限の公式情報
• GitHub Actions 公式ドキュメント
• OpenAI API 公式ドキュメント