Google Chatで承認フローを回す方法と実装の勘所

承認が遅れる原因の多くは、承認者が申請システムを開かないことにあります。Google Workspaceを使っている組織であれば、Google Chatを承認の入口にすることで、承認者が普段見ている画面に依頼を届けられます。この記事では、Webhookによる通知から、カード上のボタンで承認を受け付けるChatアプリの実装まで、3段階に分けて整理します。

この記事の要点

• Google Chatで承認を扱う方法は、Webhook通知／Chatアプリのカード＋ボタン／GASでの本格実装の3段階に分かれる。
• Webhookは実装が最も軽いが、通知を送るだけで承認の受け取りはできない。
• カードのボタンから承認を受け付けるにはChatアプリの登録が必要で、ここから実装の難易度が一段上がる。
• Chatアプリ方式の本当の価値は利便性ではなく、承認者の本人確認を構造的に解決できる点にある。

Google Chatで承認を扱う3つの段階

段階1：Webhookで承認依頼を通知する

Google Chatのスペースには、外部からメッセージを投稿するためのWebhook URLを発行できます。GASからこのURLにPOSTすれば、申請が発生したタイミングでスペースに通知を流せます。実装は数行で済み、Chatアプリの登録も不要です。

申請内容と、承認画面（スプレッドシートやGoogleフォーム）へのリンクをメッセージに含めておけば、承認者はChatから1クリックで承認画面に移動できます。

ただしWebhookは一方向です。Chat上のボタンを押して承認する、という操作は受け取れません。承認者はリンク先に移動して操作することになるため、「Chatで完結する」わけではありません。また、Webhook URLを知っていれば誰でもスペースに投稿できるため、URLはスクリプトプロパティに格納し、コードに直接書かないようにしてください。

申請件数が少なく、承認そのものはスプレッドシート上で行う運用が定着している組織であれば、この段階で十分です。承認待ちの可視化と通知だけでも、承認までの時間は短くなります。GASでの承認フローの基本構成はGASで承認フローを自動化する方法と限界で詳しく扱っています。

段階2：Chatアプリでカードとボタンを出す

Chatアプリ（旧称：bot）として登録すると、メッセージをカード形式で表示し、カード上にボタンを配置できます。ボタンが押されると、その情報がアプリのエンドポイント（GASのWebアプリなど）に届くため、Chat上で承認を完結させられます。

カードには、申請者・金額・用途・添付リンクといった判断に必要な情報を並べられます。承認者はカードを見るだけで判断でき、別画面への遷移が不要になります。次章で、この実装を4つの手順に分けて解説します。

段階3：本格運用に必要な作り込み

カードで承認できるようになった後、運用に耐えるには承認ルートの外出し、台帳の改ざん防止、二重実行の防止、そして引き継ぎ体制の整備が必要になります。ここが最も手間のかかる部分で、記事の後半で扱います。

Chatアプリで承認を受け付ける実装手順

【手順1】Google Cloudでプロジェクトを作り、Chat APIを有効化する

Google Cloudのコンソールでプロジェクトを作成し、Google Chat APIを有効化します。ここで作るプロジェクトは、Chatアプリの登録情報を保持するための入れ物です。

この時点で決めておくべきなのが、プロジェクトの所有者です。個人アカウントで作成すると、その人の退職時にアプリごと失われます。組織の共有アカウントか、情シスが管理するプロジェクトの配下に作ってください。この判断を後から変えるのは面倒なので、最初に決めます。

【手順2】GASでWebアプリを作り、イベントを受け取る

GASのプロジェクトを作成し、Chatからのイベントを受け取る関数を用意します。受け取るイベントは主に2種類で、メッセージが送られたときと、カード上のボタンが押されたときです。

ボタン押下のイベントには、**操作したユーザーの情報が含まれます。**これが後述する本人確認の鍵になります。GASをWebアプリとしてデプロイし、そのURLをChatアプリの接続先として控えておきます。

【手順3】Chatアプリを登録し、接続先を設定する

Google Chat APIの設定画面で、アプリの名前・アバター・説明を登録し、接続先として手順2のWebアプリURLを指定します。あわせて、アプリをスペースに追加できる範囲（組織全体か特定のグループか）を設定します。

ここで、アプリが応答する機能（スペースへの追加を許可するか、1対1のチャットを許可するか）も選びます。承認用途であれば、スペースと1対1の両方を有効にしておくと、承認依頼を個人チャットに送る構成も取れます。

【手順4】承認者マスタと突き合わせ、台帳を更新する

ボタン押下のイベントを受け取ったら、まず**操作したユーザーが、その申請の承認者として登録されているかを確認します。**承認者マスタのシートと突き合わせ、一致しない場合はエラーを返してください。この確認を入れていないと、スペースの参加者なら誰でも承認できる状態になります。

権限が確認できたら、申請台帳のステータスを更新し、カードを「承認済み」の表示に差し替えます。あわせて、承認イベントを追記専用のログシートにも書き出しておくと、後から経緯を追えます。

メールリンク方式との決定的な違い

GASで承認フローを組む一般的な方法は、承認者にメールを送り、メール内のリンクをクリックするとステータスが変わる、というものです。この方式の弱点は、URLを知っていれば誰でも承認できてしまう点にあります。転送されたメールから第三者が承認する余地が残り、内部統制上の欠陥になります。

Chatアプリのボタン方式は、イベントに操作者の情報が含まれるため、この問題を構造的に回避できます。承認をChatに寄せる最大の理由は、利便性よりもこの本人確認にあると言っても差し支えありません。

なお、メール方式でも本人確認を担保する方法はあります。承認画面をGASのWebアプリとして公開し、実行ユーザーを「アクセスしているユーザー」に設定すれば、ログイン中のアカウントを取得できます。ただしこの場合、承認者は必ずブラウザで画面を開く必要があり、Chatで完結する手軽さは失われます。

フォーム起点で承認を組む場合の全体像はGoogleフォームで承認ワークフローは作れる？限界と対策にまとめています。

本格運用に必要な作り込み

承認ルートの外出し

金額や部門によって承認者を変える場合、ルート定義をコードに書かず、別シートで管理してください。スクリプトを書き換えずにルートを変更できる状態にしておかないと、組織改編のたびに開発作業が発生します。

あわせて、ルート定義シートの変更履歴が残るようにしておきます。監査で過去の承認の妥当性を問われた際、当時のルートを示せるかどうかが分かれ目になります。

台帳の改ざん防止

スプレッドシートを申請台帳にしている限り、承認済みの行を後から書き換えられるという構造的な弱点が残ります。シートの保護範囲で一般ユーザーの編集は制限できますが、編集権限を持つ管理者には開いたままです。

緩和策としては、承認イベントを別の追記専用シートにログとして書き出し、台帳と突き合わせられるようにする方法があります。完全な解決にはなりませんが、単一の台帳だけを持つ状態よりは説明可能性が上がります。稟議として成立させるために必要な要件はGoogle Workspaceで稟議・ワークフローを電子化する方法で整理しています。

エラーと再送の設計

Chatアプリのエンドポイントが一時的に応答しなかった場合、ボタンを押した承認者にはエラーが表示されます。この時、承認が記録されたのかどうかが承認者にはわかりません。

対策は、申請IDと操作の組み合わせで冪等性を確保することです。「この申請IDに対する承認は、すでに記録済みか」を先に確認してから書き込めば、同じボタンが二度押されても結果は変わりません。あわせて、処理完了時にカードの表示を「承認済み・処理者・日時」に差し替えれば、承認者から見ても状態が明確になります。

応答時間の制約に注意する

Chatアプリは、イベントに対して一定時間内に応答する必要があります。承認処理の中で重い集計や外部APIの呼び出しを同期的に行うと、タイムアウトして承認者にエラーが見えることがあります。

重い処理が必要な場合は、まず「受け付けました」と応答してカードを更新し、実処理はトリガーで非同期に実行する構成にしてください。設計時に見落とされやすい制約です。

運用の引き継ぎ

GASで組んだ仕組みは、書いた人以外が保守できなくなりやすいものです。Chatアプリの登録情報（Cloudプロジェクト、認証情報、Webアプリのデプロイ）まで含めると、引き継ぎの対象は単なるスクリプトより広くなります。

引き継ぎ資料として最低限そろえるべきは、Cloudプロジェクトの場所と所有者、GASプロジェクトのURL、Webアプリのデプロイ設定、承認者マスタと台帳のシートURL、そしてエラー時の確認手順の5点です。誰が引き継ぐのかを決めないまま全社展開に進むと、その担当者の異動時に止まります。

内製するか、サービスを使うか

Google Chatを承認の入口にする発想自体は正しく、効果もあります。判断が必要なのは、それを自前で実装し続けるかどうかです。

内製で無理なく回るのは、申請の種類が数種類に収まり、承認ルートが固定的で、承認後に自動実行する処理がない場合です。逆に、承認後に発注や精算が続く業務では、Chat上で承認できるようになっても、その後の手作業は残ります。出張申請でこの構造がどう効くかはGoogle Workspaceの出張申請システム構築方法と限界を解説、購買申請についてはGoogle Workspaceで購買申請を仕組み化する方法で扱っています。

1Approval for Google Workspaceは、Google Chatを含むGoogle Workspaceの日常の画面を申請承認の入口にしながら、承認と同時に発注・決済までを確定させます。承認者の本人確認、承認ルートの管理、証跡の保全は仕組み側で担保されるため、GASでの作り込みと引き継ぎの問題から解放されます。

よくある質問（FAQ）

Google ChatのWebhookだけで承認フローは作れますか？

作れません。Webhookは一方向の通知手段で、承認の操作を受け取れないためです。Chat上で承認まで完結させるには、Chatアプリとして登録する必要があります。

Chatアプリの実装にはGoogle Cloudのプロジェクトが必要ですか？

必要です。Chat APIを有効化し、アプリの接続設定を行うためにGoogle Cloudのプロジェクトを作成します。処理そのものはGASのWebアプリで受けられます。

承認者以外がボタンを押した場合はどうなりますか？

実装次第です。Chatアプリに届くイベントには操作者の情報が含まれるため、承認者マスタと突き合わせて権限を確認する処理を入れておけば弾けます。この確認を入れていないと、スペースの参加者なら誰でも承認できる状態になります。

メールでの承認とChatでの承認はどちらが安全ですか？

Chatアプリのボタン方式のほうが安全です。メール内のリンクによる承認は、URLを知っていれば誰でも実行できるため、転送された場合に第三者が承認する余地が残ります。

同じボタンを二度押してしまった場合はどうなりますか？

冪等性の実装が無ければ、二重に記録される可能性があります。申請IDと操作の組み合わせで処理済みかを先に判定し、処理後はカードの表示を差し替えて状態を明示してください。

まとめ

Google Chatを承認の入口にすると、承認者の導線が日常業務の中に入り、承認待ちが短くなります。Webhookによる通知だけなら数行で実装でき、Chatアプリまで進めばChat上で承認を完結させられます。そして最大の利点は、ボタン押下イベントに操作者情報が含まれることで、承認者の本人確認を構造的に解決できる点です。

ただし、承認ルートの管理、台帳の改ざん防止、冪等性、引き継ぎ体制という4点は、Chatに寄せても自動的には解決しません。この4点を自前で維持できるかどうかが、内製とサービス利用を分ける判断軸になります。