Google Workspace活用・承認自動化に関する記事

典型的な構成は、Googleフォームを申請の入口、スプレッドシートを申請台帳、GASを承認処理のエンジンにするものです。フォーム送信をトリガーにGASが承認者へメールを送り、メール内のリンクをクリックするとスプレッドシートのステータスが更新される、という流れになります。ここまではスクリプト100行程度で構築できます。

課題は承認の「認証」です。メール内のリンクをクリックした人が本当に承認者本人かを、素朴な実装では保証できません。URLを知っていれば誰でも承認できてしまう状態は、内部統制上の欠陥です。Googleアカウントでの認証を挟む、ワンタイムトークンを発行するといった対策を入れると、実装の難易度は一段上がります。

稟議として成立させるには、金額による承認ルートの切り替え、承認順序の保証、差し戻しと再申請、承認済み内容の改ざん防止、そして証跡の保全が要ります。GASでもひとつずつ実装できますが、スプレッドシートを台帳にしている限り「承認済みの行を後から手で書き換えられる」という構造的な弱点は残ります。保護範囲の設定で緩和はできても、管理者権限を持つ人には開いたままです。

内製を選ぶかどうかの判断軸は、コストではなく監査要件です。監査法人や親会社から証跡の提出を求められる可能性があるなら、台帳が編集可能である前提のまま運用を広げるのは避けたほうがよいでしょう。

出張申請や購買申請は、承認が終わってからが本番です。承認後に誰かが予約サイトや購買サイトを開いて手配し、その結果をまたスプレッドシートに戻す——この往復がある限り、申請の電子化だけでは総工数はあまり減りません。しかも手配の段階で在庫切れや満室が判明すると、金額が変わり、再申請が発生します。

Google Workspace側で解くなら、承認済みデータを手配システムのAPIへ渡す連携をGASで書くことになります。書ける規模かどうかは連携先次第なので、対象サービスのAPI仕様を確認してから設計に入ってください。