GASで承認フローを自動化する方法と限界

GASを使えば、Googleフォームとスプレッドシートを組み合わせて承認フローを無料で構築できます。総務・経理から「紙の稟議やExcel運用をどうにかしたい」と相談を受けた情シス担当者が、まず検討する選択肢の一つです。しかし実装のハードルや運用面での限界も存在するため、仕組みの理解と自作の限界の両方を押さえておく必要があります。本記事では、GASによる承認フロー自動化の作り方から、業務が複雑化した際の限界、そして専用ツールへの乗り換え基準まで解説します。

GASによる承認フロー自動化とは？仕組みと基本構造

GASによる承認フロー自動化とは、Googleフォームで受け付けた申請データをスプレッドシートに蓄積し、Google Apps Scriptで承認者へのメール通知や承認処理を自動実行する仕組みです。追加コストなしでGoogle Workspace環境内に構築できる点が最大の特徴です。

Google Apps Script（GAS）でできることの基本

GASはGoogle Workspace上で動作するJavaScriptベースのスクリプト環境で、Googleフォーム・スプレッドシート・Gmail・Chatなど各サービスをAPI経由で連携操作できます。コード自体は数十行程度で、フォーム送信をトリガーにメール送信やスプレッドシートへの書き込みを行う処理を記述できます。

Googleフォーム×スプレッドシート×GASによる承認フローの仕組み

基本構造は「フォームで申請受付→スプレッドシートに自動転記→GASが承認者へ通知→承認者がスプレッドシート上のセルを更新→ステータス変更を検知して申請者に結果を通知」という一連の流れです。承認・否認の判定は、多くの場合スプレッドシートのステータス列（プルダウン等）の値変更をトリガーに処理されます。

onFormSubmit・onEditトリガーの役割と違い

onFormSubmitはフォーム送信時に発火するトリガーで、申請受付通知に使われます。一方onEditはスプレッドシートのセル編集時に発火するトリガーで、承認者がステータスを変更した際の処理に使われます。onEditはシンプルトリガーとして自動設定されますが、Gmail送信などの権限が必要な処理を行う場合は、インストール可能トリガーとして手動設定・承認が必要になる点に注意が必要です。

GASで承認フローを自動化する具体的な手順

GASでの承認フロー実装は「フォーム準備」「スクリプト実装」「トリガー設定と動作確認」の3ステップで完結します。いずれもGoogle Workspace管理者権限があれば、外部ツールを導入せずに着手できます。

Step1：申請フォーム（Googleフォーム）とスプレッドシートの準備

経費精算であれば「申請者名」「金額」「用途」「承認者メールアドレス」といった項目をフォームに設定し、回答の連携先スプレッドシートを紐付けます。承認ステータス列（未承認／承認／否認）と承認日時列をあらかじめスプレッドシート側に追加しておきます。

Step2：承認メール自動送信・承認リンク（ワンクリック承認）のスクリプト実装

フォーム送信をトリガーに、GmailApp.sendEmailで承認者宛に申請内容と承認リンクを送信するスクリプトを実装します。承認リンクにはWebアプリとして公開したGASのURLにパラメータ（行番号や申請ID）を付与し、クリック時にスプレッドシートのステータスを自動更新する仕組みを組み込むことで、承認者はメールを開いてリンクをクリックするだけで承認が完了します。

Step3：トリガー設定と動作確認・権限承認（authorization）の注意点

スクリプトエディタでトリガーを設定した後、初回実行時にはGoogleアカウントへの権限承認（このアプリは確認されていません、という警告画面を含む）が発生します。組織のセキュリティポリシーによってはこの警告画面で承認がブロックされるケースがあるため、事前にGoogle Workspace管理者側でアプリの信頼設定を確認しておく必要があります。

GAS承認フローの活用シーン別ユースケース

GASによる承認フローは、承認ルートが1〜2段階で完結する定型業務との相性が良好です。具体的には以下のような業務との相性が良いとされています。

経費精算・購買申請への活用例

金額に上限を設けず一律で上長1名が承認するシンプルな経費精算や、備品購入申請などに向いています。紙の押印回覧に比べて、申請から承認までのリードタイムを大幅に短縮できるケースが多く見られます。ただし、承認が完了した後の支払いは結局のところ従業員による立て替えとなり、経理は月末にまとめて精算処理を行うケースがほとんどです。この「承認は自動化されたが、支払いは個人の立て替えのまま」というギャップは、GAS運用でよく見落とされるポイントです。

休暇申請・稟議書申請への活用例

休暇申請のように承認者が固定されている業務にも適用しやすく、承認結果をカレンダーへ自動反映する処理を追加することも可能です。

Slack／Chatwork連携による承認通知の自動化例

GASからWebhook経由でSlackやChatworkに通知を送ることで、メールを開く手間を省き、チャットツール上で承認依頼から承認完了までを完結させる運用も可能です。

GAS自作の承認フローが抱える限界と注意点

GASによる承認フローは、申請内容や承認ルートが複雑化すると保守が困難になります。理由は、条件分岐や複数承認者を扱うロジックが増えるほどコードが肥大化し、少人数のエンジニアリソースでは変更対応が追いつかなくなるためです。

金額・部署による条件分岐や複雑な承認ルートに対応できない

「10万円以上は部長承認、50万円以上は役員承認」といった金額別の承認者分岐や、部署によって承認ルートを変えるロジックは、スプレッドシートのVLOOKUPやGASの条件文を組み合わせて実装可能ですが、ルートが増えるたびにコードの分岐が増え続け、変更のたびに全体テストが必要になります。

代理承認・引き上げ承認、承認履歴（内部統制・監査対応）の証跡管理が弱い

承認者が休暇中の場合の代理承認や、一定期間未承認の場合に上位者へ自動的にエスカレーションする「引き上げ承認」は、GAS単体では標準機能として用意されておらず、個別にロジックを組む必要があります。また承認履歴はスプレッドシートの編集履歴に依存するため、改ざん防止や監査対応の証跡としては脆弱です。

実行時間制限・属人化・メンテナンスコストという技術的・運用的リスク

GASの実行時間には上限があり、一般的なGoogleアカウントでは1回の実行につき6分程度（Google Workspaceアカウントでは30分程度）に制限されているため、大量データ処理を伴う場合はエラーの原因になります。さらに、スクリプトを書いた担当者が異動・退職すると誰も保守できなくなる属人化リスクも、発生しうる課題です。

なお、申請の入口をGoogleフォームにする場合は、フォーム単体でどこまでできるかを先に押さえておくと設計がぶれません。詳しくはGoogleフォームで承認ワークフローは作れる？限界と対策で整理しています。

金額分岐や代理承認を含む稟議ルートを内製でどこまで作り込めるかという論点は、Microsoft 365でも同じ形で現れます。判断の目安はPower Automateで稟議フローは作れる？内製の限界が参考になります。

GASの限界を超える選択肢｜Google Workspaceに最適化された承認フローシステムという選択

GASで運用の限界を感じた企業の多くは、無料アドオンではなく専用ワークフローシステムへの移行を検討します。理由は、条件分岐・証跡管理・権限設計といった機能が標準搭載されており、コードを書かずに運用開始できるためです。

無料アドオンとワークフローシステムの違い

フォーム回答をもとに承認可否を判定する無料アドオンは、GASを自作するよりも導入は容易ですが、複数段階の承認ルートや外部システム連携には対応していないことが多く、機能面では自作GASと同程度の限界を抱えています。

Google Workspace環境にネイティブ対応する「1Approval for Google Workspace」の特徴

1Approval for Google Workspaceは、Googleアカウントでのシングルサインオンや組織部門情報との連携など、Google Workspace環境と一体化した運用を前提に設計されています。すでに運用しているGoogleフォームやGASポータルの承認ルートをそのまま使えるため、条件分岐や多段階承認のためにルートを組み直す必要がありません。代理承認者の事前設定にも対応しており、スクリプトを書かずに導入できる点が自作GASとの大きな違いです。

さらに、経費精算まで含めて考えると、購買や申請が実行された時点でそのデータがそのまま経費データとして自動生成され、会計・経費精算システムと連携できる点も見逃せません。GASとスプレッドシートだけの運用では、承認は承認、経費精算は精算と別プロセスになりがちですが、1Approvalなら申請・承認・経費の情報を一括で確認できるため、情シス・総務・経理それぞれの二重入力や突合作業の負担を減らせます。また、複数サービス・複数取引先にまたがる利用料も月1回の法人一括請求にまとめられるため、経理の支払い処理もシンプルになります。具体的な機能や料金体系は1Approval for Google Workspaceの詳細を見るから確認できます。

自作から乗り換える際に比較すべきポイント（コスト・導入工数・拡張性）

乗り換え検討時は、初期構築コストだけでなく、承認ルート変更にかかる工数、監査対応時の証跡出力の容易さ、担当者不在時の保守体制という3点を比較軸に据えることをおすすめします。

メールのリンクによる承認ではなく、Google Chatのカード上のボタンで承認を受け取る方法もあります。承認者の本人確認を構造的に解決できる点で有利で、実装手順はGoogle Chatで承認フローを回す方法と実装の勘所にまとめています。

よくある質問（FAQ）

GASだけで承認フローの内部統制・監査対応は可能ですか？

いいえ、GAS単体での監査対応は限定的です。スプレッドシートの編集履歴を承認証跡として利用できますが、改ざん防止機能や承認者本人性の確認機能は標準搭載されておらず、内部統制の観点では別途仕組みを追加する必要があります。

GASで作った承認フローに条件分岐（金額に応じた承認者変更）を追加できますか？

はい、GASのスクリプトに条件分岐ロジックを追加すれば実装可能です。ただし承認ルートのパターンが増えるほどコードが複雑化し、変更時の動作確認に要する工数も増加するため、頻繁にルート変更が発生する業務には不向きです。

Googleフォーム＋GASの承認フローは何人規模の会社まで運用できますか？

承認ルートがシンプルであれば、数十名規模の企業でも十分に運用できます。一方で、部署をまたぐ複雑な承認ルートや同時申請件数が増える組織では、実行時間制限やメンテナンス負荷の観点から専用システムへの移行を検討する企業が多くなります。

GASの承認フローからワークフローシステムへ乗り換えるタイミングの目安は？

条件分岐や代理承認の要望が月に数回以上発生するようになった時点、またはスクリプトの保守担当者が1人しかいない状態が続いている場合が、乗り換え検討の目安です。属人化リスクが顕在化する前に移行を検討することをおすすめします。

まとめ｜GAS承認フローは「小規模・シンプルな業務」に、複雑化したら専用ツールの検討を

GASによる承認フロー自動化は、承認者が固定された1〜2段階のシンプルな業務であれば、コストをかけずに紙・メール運用からの脱却を実現できる有効な手段です。一方で、条件分岐や代理承認、証跡管理が必要になった段階では、自作の保守コストが導入コストを上回るケースが少なくありません。

GAS自作が向いているケース・向いていないケースの整理

承認者数が変わらず、承認ルートも固定されている定型業務にはGAS自作が向いています。逆に、金額や部署による承認者分岐、監査対応の証跡管理が求められる業務には専用ツールの導入が適しています。

なお、承認フロー単体ではなく、申請画面まで含めた社内システムをGASで作る場合の手順と運用上の注意点は、GAS Webアプリで社内システムを作る方法と運用の注意点にまとめています。

1Approval for Google Workspaceで解決できること

1Approval for Google Workspaceを導入すれば、いま使っている承認ルートを活かしたまま、代理承認や、承認から購買・経費精算までのつなぎ込みを、コーディングなしでGoogle Workspace環境に組み込むことができます。加えて、従業員個人の立て替えに頼らない法人一括請求の仕組みを組み合わせることで、承認フローの自動化と経費精算の効率化を同時に進めることも可能です。GASでの限界を感じ始めたタイミングこそ、次の運用体制を検討する好機です。まずは1Approval for Google Workspaceの詳細を見るから、自社の運用にどこまで当てはまるか確認してみてください。