目次
結論、Google Chat Botは、Webhookでは扱えない双方向処理を担います。メンション応答、コマンド、カードのボタン、ダイアログ、承認フローが必要になった時点で、Bot（Chatアプリ）に切り替えます。通知だけならWebhookで足りますが、操作を返すならBotの領域です。
通知だけならWebhookで十分です。しかし、ボタンで承認したい、メンションへ返したい、入力を受けて分岐したいとなると、Chatアプリが必要になります。この記事では、単なる機能一覧ではなく、どの要件でBotに切り替えるかを整理します。
先に判断する
| 方式 | 向く要件 | 強み | 限界 |
|---|---|---|---|
| Webhook | 固定スペースへの一方向通知 | 最小構成で早い | 受信や応答はできない |
| Chatアプリ | メンション応答、承認、対話 | 双方向の操作ができる | 認証と実行環境が必要 |
| Apps Script | Google Workspace起点の小規模連携 | 実装開始が早い | 大規模運用には限界がある |
| Chat API + 外部基盤 | 複雑な業務ロジックや高可用性 | 保守と拡張に強い | 構成と運用が重い |
Botは便利ですが、何でもBotにすると重くなります。通知だけの要件に双方向処理を載せる必要はありません。逆に、承認や問い合わせをWebhookで済ませようとしても、これは設計として無理がある。この線引きを最初にやるだけで、あとの実装がずいぶん楽になります。
Expert Q&A
設計に入る前に確認すること
湯田英也SakuraAI株式会社 代表 / ソフトウェアエンジニアQ. Botにするかどうかの判断はどこで？
A. ユーザーから返答を受ける、ボタンで状態を変える、対話で分岐する——このどれかが入ったらBotです。逆に言えば、一つも当てはまらないならWebhookで十分。判断はこれだけでほぼ決まります。
Q. 承認フローを作るとき、最初の論点は？
A. UIではありません。誰が承認できるか、承認結果をどこに残すか、後から監査できるか。この3つを先に決めます。見た目のカードから作り始めると、記録と権限が後回しになって、あとで作り直すことになります。
Q. 小さく始めたいのですが、どこから？
A. まずWebhookかApps Scriptで通知を出すところから。ユーザーの操作を受けたくなった時点でBotに広げれば十分です。最初から全部を見込んで大きく作る必要はありません。
BotとWebhookの違い
| 観点 | Webhook | Bot（Chatアプリ） |
|---|---|---|
| 方向 | 一方向 | 双方向 |
| できること | 通知を送る | 応答、承認、入力、状態更新 |
| 準備 | URLを発行する | Cloud設定と受信処理が必要 |
| 向く用途 | 監視、バッチ、定期報告 | FAQ、申請、承認、問い合わせ |
Webhookは送るだけです。Chatアプリは受けて返す仕組みです。ここを曖昧にすると、要件に対して過剰に作るか、逆に足りないものを無理に押し込むことになります。
Bot開発に必要なもの
一般には、Google Cloudプロジェクト、Chat APIの有効化、受信エンドポイント、実行環境が必要です。実行環境はサーバーアプリでもApps Scriptでも構いません。小さく始めるならApps Script、運用まで見るなら外部基盤という整理が現実的です。
ユーザーがメンションやコマンドを送る
対話の起点
Chatアプリがイベントを受ける
入力を解釈する
業務ロジックで判断する
承認、検索、分類を実行
Chatへ返答する
結果と次アクションを返す
Bot開発の構成手順は、機能追加や権限制御の見直しで変わります。実装前に公式の Chat アプリ概要と認証関連の最新情報を確認し、要件に対して最小権限で設計します。
設計パターン1：メンション応答Bot
スペースでメンションされたら、内容に応じて返答します。社内FAQ、用語検索、ステータス確認に向きます。一次対応をBotに寄せると、担当者の取りこぼしが減ります。
設計パターン2：スラッシュコマンドBot
決まったコマンドで操作を呼び出します。勤怠の打刻、定型レポートの取得、検索など、入力を構造化したい場面に向きます。
| コマンド設計 | 向く用途 | 注意点 |
|---|---|---|
| /status | 稼働状況や申請状態の確認 | 返答を短くする |
| /report | 定型レポートの取得 | 対象期間を明示する |
| /search | 社内検索 | 結果件数が多いときの絞り込みを用意する |
設計パターン3：承認フローBot
承認依頼をボタン付きカードで投稿し、押されたアクションに応じて状態を更新します。Botの価値が最も出やすいのは、この手の業務です。
| 設計要素 | やること | 目的 |
|---|---|---|
| 申請内容 | カードで見せる | 判断材料を揃える |
| ボタン | 承認、却下、差戻しを置く | 操作を限定する |
| 記録 | 押下者と時刻を保存する | 監査可能にする |
| 通知 | 結果を申請者と関係者へ返す | 放置を防ぐ |
承認フローは見た目より記録が重要です。誰がいつ何を承認したかを残し、権限のないユーザーが操作できないようにします。表示できることと、変更できることは分けて設計します。
設計パターン4：問い合わせ対応Bot
社内問い合わせを受け、内容を分類し、担当へ振り分けます。よくある質問は自動回答し、難しいものは人へエスカレーションする構成が現実的です。
| 応答の種類 | Botの役割 | 人へ渡す条件 |
|---|---|---|
| 定型FAQ | 即時回答 | 根拠が曖昧なら渡す |
| 分類 | 担当先を振り分ける | 情報不足なら追質問する |
| 例外 | 受付だけする | 権限や判断が必要なら人へ回す |
どこから通知で、どこからBotか
- 通知で十分: 一方向のアラート、レポート、定期投稿
- Botが必要: 応答、コマンド、承認、対話
- 迷う時: まずWebhookやApps Scriptで始め、受信が必要になった時点でBotへ広げる
全体像はGoogle Chat APIの解説を参照してください。
Expert Q&A
実装前に確認すること
湯田英也SakuraAI株式会社 代表 / ソフトウェアエンジニアQ. Bot開発で最初に決めるべきことは？
A. 機能ではなく境界です。通知で終わるのか、入力を受けるのか、承認までやるのか。ここを先に決めておかないと、機能を足すたびに認証や実行環境を作り直すことになります。
Q. 承認Botで一番やりがちな失敗は？
A. 見た目のカードにこだわって、記録と権限を後回しにすることです。承認は『誰がいつ何を承認したか』が残らないと意味がありません。表示できることと変更できることを分けて設計してください。
Q. Apps Scriptと外部基盤、どちらで作るべき？
A. 小さく試すならApps Scriptで十分です。処理量が増えたり、監視や高可用性が要るようになったら外部基盤へ。最初から大きく作らず、必要になってから移すほうが結果的に速いです。
SakuraAIで支援できること
SakuraAIでは、Google Chat Botの設計と実装を支援しています。承認フロー、問い合わせ対応、社内コマンドを、通知で足りる範囲とBotが必要な範囲に切り分け、過剰開発を避けた構成で実装します。「とりあえずBotを作る」ではなく、通知で済むところは通知で済ませる。この見極めが、運用の軽さに直結します。
よくある質問
BotとWebhookはどう使い分けますか？
一方向の通知だけならWebhookで十分です。メンションやコマンドに応答する、ボタンで承認・操作を受け付ける、対話的に処理するなど双方向の動作が必要な場合にBot（Chatアプリ）を使います。
Bot開発には何が必要ですか？
一般に、Google Cloudプロジェクトの作成、Chat APIの有効化、Botの構成（受信エンドポイントや実行環境）が必要です。Apps Scriptを実行環境にする方法もあります。要件に応じて構成を選びます。
承認フローはBotで作れますか？
作れます。承認依頼をボタン付きカードで投稿し、押されたアクションに応じて状態を更新する設計が一般的です。誰がいつ承認したかを記録し、監査できるようにすることが重要です。
どこまでWebhookで、どこからBotにすべきですか？
一方向の通知で完結するならWebhookで十分です。ユーザーのメッセージやメンションに応答する、ボタンで承認や状態変更を受け付ける、対話で分岐する——このどれかが必要になった時点でBot（Chatアプリ）に切り替えます。要件がないのに双方向を作り込むと、認証と運用が重くなるだけです。
参考・一次情報
開発相談
Google Chat Bot・Webhook開発を相談する
通知・承認・問い合わせ連携のBotとAPI実装を支援します。
開発を相談する