Google Workspaceで承認フローを作成する方法
標準機能のできること・限界とは

まずは、追加費用なしで使える標準機能を使った基本的な承認依頼の手順を簡潔に紹介します。

① ドキュメント / スプレッドシートでのリクエスト手順

1. 申請書フォーマットの準備

申請書フォーマットの準備：Google ドキュメント等で申請書のフォーマットを作成し、誤って変更されないよう「閲覧権限のみ」で共有します。

2. フォーマットのコピーと記入

申請者は「ファイル」＞「コピーを作成」を選択して自分のフォルダに保存し、申請内容を記入します。

3. 承認の依頼

「ファイル」> 「承認」 を選択します。「承認のリクエスト」ウィンドウが表示されるので、「リクエストを送信」 をクリックして承認申請を行います。

4. 承認者の設定とリクエストを送信

承認を依頼する相手のメールアドレス、メッセージ、期限を設定します。承認中にファイルが編集されるのを防ぐ場合は「承認リクエストを送信する前にファイルをロックする」にチェックを入れ、「リクエストを送信」をクリックします。

すべての設定が終わったら、「リクエストを送信」をクリックします。

5. 承認の操作

承認者には通知メールが届きます。ドキュメントを確認し、問題なければ「承認」、不備があれば理由を添えて「拒否（却下）」をクリックします。

6. 承認履歴の確認

履歴は「ツール」内の「アクティビティ ダッシュボード」またはGmailから確認できます。

申請書の内容に問題がなければ、「承認」をクリックします。「リクエストを承認しますか？」という確認画面が表示されるので、必要に応じてメッセージを記入し、「承認」をクリックします。

申請内容に不備があれば、「拒否」をクリックします。「リクエストを不承認にしますか？」という確認画面が表示されるので、却下の理由などを記入して「拒否」をクリックします。却下されたドキュメントは、申請者が修正して新たな承認プロセスを開始することができます。また、承認プロセスはメッセージとともに履歴として残るので、修正指示など簡単なやりとりも可能です。

社内アンケートや休暇申請などの定型フォーマットには「Google フォーム」を活用できますが、フォーム単体には承認機能がありません。
そのため、以下のいずれかの方法で運用をカバーする必要があります。

1. スプレッドシートでのステータス管理

申請用フォームの作成：Google フォームで申請項目を作成します。
回答先シートの連携：「回答」タブから「スプレッドシートにリンク」をクリックし、回答を集約するシートを作成します。
管理列の追加：連携したシートの右端に「承認ステータス（承認待ち・承認済みなど）」の列を手動で追加し、承認者が直接シートを見てステータスを更新・管理します。

2. GASを用いた自動メール通知（応用編）

シートを毎回目視で確認する手間を省くため、GASを利用して「承認者へ自動で通知メールを送る」仕組みを構築します。
スクリプトエディタの起動：連携したスプレッドシートの「拡張機能」から「Apps Script」を開きます。
プログラムコードの記述：開いたエディタ画面に、宛先（承認者のメールアドレス）や、通知メールの件名・本文などを指定するための専用コードを記述して保存します。

トリガー（実行条件）の設定：記述したプログラムが「フォームが送信された時」に自動で動くように、実行タイミング（トリガー）を設定します。
※運用上の注意点 この方法は無料で自動通知を構築できる反面、実際のコード記述や「条件によって宛先を変える」といった設定を行うにはプログラミング知識が必須です。作成者以外は修正できなくなる「属人化（ブラックボックス化）」に陥るリスクが高いため、実運用における管理負荷やメンテナンス性に不安がある場合は、専用ワークフローの活用をご検討ください。

ここまで、ドキュメントやスプレッドシートを使った承認リクエストの手順を解説しました。数ステップで手軽に依頼できるため、少人数のチーム内での簡易な確認作業には非常に便利です。
しかし、これらの標準アプリケーションには明確な仕様上の制限（できないこと）が存在します。そのため、全社規模での「稟議」や「経費精算」など、社内規程に則った運用が求められるプロセスには不向きです。

具体的には、専用ワークフローと比較するとGoogle Workspace には以下の4つの限界があります。

1. 承認ルートの「条件分岐」ができない（ストレートルートのみ対応）
スプレッドシートやドキュメントの標準承認機能は、指定した相手にそのまま回す「ストレートルート」の仕様であり、途中で枝分かれするような設定ができません。
そのため、「10万円以上は部長承認」「50万円以上は役員承認」といった金額や条件によるルート分岐が不可となります。社内規程に則って厳密にルートを変えなければならない稟議プロセスには向かず、申請者が都度マニュアルを見て手作業で宛先を設定する（誤送信の温床になる）事態を招きます。

2. 「代理承認」や「引き上げ承認」ができない
標準機能では、あらかじめ設定された本人しか承認アクションを実行できません。
承認者が急病や長期出張で不在の場合、別の人に権限を委譲する「代理承認」や、上位役職者が代わりに完了させる「引き上げ承認」ができないため、承認フローがそこで完全にストップしてしまいます。

3. 監査に耐えうる証跡（ログ）管理が難しい
承認プロセス自体の履歴は残りますが、ベースがスプレッドシートやドキュメントである以上、ファイル自体の直接編集（セルの書き換えなど）が容易にできてしまいます。
「いつ・誰が・どのような内容で承認したか」という改ざん不可能なログを厳密に保護することが難しく、内部統制や監査の観点からは適していません。

4. フォーム＋GASでの無理な構築は「属人化」を生む
前述の通り、Google フォーム単体には承認機能がないため、無理に自動化しようとするとGAS（Google Apps Script）などを使ってプログラムを組むことになります。
しかし、このような独自システムは、作った担当者が異動・退職すると誰もエラーを直せなくなる「ブラックボックス化（属人化）」のリスクが非常に高くなります。

こうした標準機能の限界や、手作業による摩擦（フリクション）を解消するために多くの企業が導入しているのが「専用ワークフローシステム」です。
専用ワークフローを導入し、適切に設定すれば、以下のように業務プロセスが改善されます。

申請者の負担減： 申請フォームに入力するだけで、金額や部門などの条件をシステムが読み取り、正しい承認ルートへ自動で配信してくれます。手動で宛先を探す必要はありません。
業務の滞留防止： 「代理承認」や、チャットツールへの自動通知機能により、承認スピードが格段に上がります。
脱属人化： プログラミング知識（GASなど）がなくても、ノーコードで簡単に画面上でルート変更やメンテナンスが可能です。

もし「標準機能を使って10人の承認が必要な稟議」を回す場合、誰に回すかを確認し、都度10回の手動依頼操作（宛先設定やメッセージ入力）を繰り返すという膨大な手間が発生します。
しかし、Google Workspace とシームレスに連携する専用ワークフロー「グルージェントフロー（Gluegent Flow）」なら、申請ボタンを1クリックするだけで最適ルートへ自動配信されます。

・Google Workspace の組織階層（グループ情報）をそのまま活用でき、ユーザーの二重管理が不要。
・承認されたデータをGoogle ドライブやスプレッドシートに自動出力・蓄積できる。
・使い慣れたGoogle環境のまま操作できるため、社内への定着が早い。

「今のGoogle環境の利便性を活かしつつ、手作業によるミスや承認の手間だけを減らしたい」という企業様は、ぜひ以下の資料で詳細な機能や導入事例をご覧ください。