Google Workspaceで購買申請を仕組み化する方法

購買申請をGoogle Workspaceで仕組み化する場合、Googleフォームを申請の入口、スプレッドシートを台帳、GASを承認処理のエンジンにする構成が基本になります。追加費用なしで構築でき、小〜中規模であれば十分に実用的です。一方で、承認が終わった後の発注をどう扱うかは、この構成の外側に残ります。この記事では、作れる範囲と残る課題を分けて整理します。

この記事の要点

• Googleフォーム＋スプレッドシート＋GASで、申請から承認までは内製できる。
• 購買申請で最初に決めるべきは承認ルートではなく、申請フォームの項目設計。
• 金額別の承認ルートは、コードではなく別シートのマスタで管理する。
• 承認と発注が分断されている限り、在庫切れや価格変動による再申請は残る。

内製できる範囲と、外に残るもの

先に全体像を示します。Googleフォームで申請を受け、スプレッドシートを台帳にし、GASで承認処理を書く——ここまでは追加費用なしで構築できます。外に残るのが発注です。承認が下りた後、購買担当者が購買サイトにログインして手で注文する工程は、この構成では自動化されません。

この前提を最初に置いておくと、どこまで作り込むかの判断がぶれなくなります。

まず決めるのは、承認ルートではなく申請項目

購買申請の仕組み化というと承認ルートから設計しがちですが、先に決めるべきは申請フォームの項目です。ここが曖昧だと、承認者が判断できず、差し戻しと再申請が増えます。

最低限必要な8項目

品目、数量、単価、金額合計、希望納期、用途、発注先、予算科目——この8項目が揃っていれば、承認者は追加の問い合わせなしに判断できます。逆に「品名と金額だけ」の申請は、用途の確認で1往復、予算の確認でもう1往復が発生します。

金額合計は、申請者に入力させるのではなく、数量×単価でフォーム送信後にGASが計算して台帳に書く形にしてください。手入力させると、承認者が検算することになり、その分だけ判断が遅れます。

発注先と品目は選択式にする

「30万円超は役員承認」といったルールを決めると、29万円の申請を2件に分ける運用が必ず生まれます。これを検知するには、同一の申請者・発注先・品目を後から集計できる形で記録しておく必要があります。発注先と品目を自由記述にすると集計できないため、選択式にするかマスタから引く設計にしてください。

検知の実装としては、承認処理の中で過去30日の同一組み合わせを台帳から検索し、合算額が閾値を超える場合に承認カードや通知メールへ警告を出す形が現実的です。自動で却下するのではなく、承認者が気づける状態にするのが落としどころです。

統制設計の考え方は消耗品購買の内部統制｜リスクと承認フロー設計で金額帯ごとに整理しています。

添付の扱い

見積書の添付を求める場合、Googleフォームのファイルアップロード機能を使うと、回答者がGoogleアカウントでログインしている必要があります。社内利用であれば問題ありませんが、ファイルの保存先フォルダの共有設定は事前に確認してください。承認者が開けない状態だと、その時点で差し戻しになります。

金額別の承認ルートをどう組むか

ルートはコードに書かない

GASで承認処理を書く際、承認者のメールアドレスをスクリプト内に直接書くのは避けてください。組織改編や異動のたびにスクリプトを編集することになり、触れる人が限られていきます。

承認者マスタ用のシートを別に用意し、部門コードと金額帯をキーに承認者を引く構成にします。これにより、ルートの変更はシートの更新だけで済みます。あわせて、マスタシートのバージョン履歴を有効にしておくと、監査で過去の承認の妥当性を問われた際に当時のルートを示せます。

さらに踏み込むなら、台帳の各行に「適用した承認ルートのバージョン」を記録しておきます。これがあると、後から当時のマスタと突き合わせられるため、承認者の権限が正しかったことを示せます。

多段階承認の実装

台帳に「現在の承認ステップ」の列を持たせ、GASで現在のステップに応じた承認者へ順に依頼を送る形が基本です。ステップごとに承認日時と承認者を別の列に記録しておくと、後から承認の経過を追えます。

実装上の注意として、ステップを数値で持つだけでなく、そのステップに対応する承認者も台帳側に書き出してください。マスタが後から変更された場合、ステップ番号だけではその時の承認者を再現できなくなります。

承認の経路をどこまでGASで表現できるかという論点はGASで承認フローを自動化する方法と限界で詳しく扱っています。

承認の本人確認

GASで組む承認フローの最大の弱点が、承認者の本人確認です。メール内のリンクをクリックするとステータスが変わる、という素朴な実装だと、URLを知っていれば誰でも承認できてしまいます。転送されたメールから第三者が承認する余地が残り、購買申請においては実害に直結します。

対策は2つあります。ひとつは、承認画面をGASのWebアプリとして公開し、実行ユーザーを「アクセスしているユーザー」に設定して、ログイン中のアカウントと承認者マスタを突き合わせること。もうひとつは、Google Chatのアプリとして実装し、ボタン押下イベントに含まれる操作者情報で確認することです。後者の実装はGoogle Chatで承認フローを回す方法と実装の勘所で解説しています。

差し戻しと再申請をどう扱うか

見落とされやすいのが差し戻しの設計です。差し戻した申請を「元の行を編集して再提出」にすると、当初の申請内容が失われ、何が変わって承認に至ったかを追えなくなります。

差し戻し時は元の行をステータス変更のみで残し、再申請は新しい行として起票して元の申請IDを参照させる——この形にしておくと、経緯が台帳上に残ります。行数は増えますが、監査で経緯を説明する際にこの差が効きます。

承認の後ろ側——発注をどうするか

手作業で残るのが標準

ここまでの構成で、申請から承認までは仕組みになります。しかし承認後の発注は、購買担当者が購買サイトにログインして手で行うのが標準です。承認済みの台帳を見ながら、品目と数量を購買サイトのカートに入力し直す——この転記が残ります。

転記そのものの時間も無視できませんが、より問題なのは時間差です。承認を待っている間に在庫が切れる、価格が変わる。金額が上振れすれば再申請となり、承認がもう一巡します。この往復は業務フロー上は例外扱いなのに、実態としては高い頻度で発生します。同じ構造は出張手配でも起き、出張申請の手動再予約はなぜ多発するのかで詳しく分解しています。

API連携で埋められるか

購買サイト側にAPIやPunchOut等の連携手段があれば、GASから発注を投げる構成は組めます。ただし、認証情報の管理、エラー時のリトライ、二重発注の防止といった実装が必要になり、難易度は一段上がります。

とくに二重発注の防止は必須です。GASの実行がタイムアウトした場合、発注が通ったのかどうかが分かりません。申請IDを発注側のリファレンスに渡し、送信前に同じIDの注文が存在しないかを確認する——という形で冪等性を確保しておく必要があります。

そして現実問題として、購買先は1社に収まりません。オフィス用品、工具、PC周辺機器はそれぞれ強いサイトが異なるため、3〜5サイトを使い分けている組織が珍しくありません。連携先の数だけ実装と保守を持つことになります。サイトごとの性格の違いはオフィス用品通販6社比較｜主要サイトの違いと選び方で比較しています。

個人立替が残る

もうひとつ見落とされるのが支払手段です。承認が電子化されても、現場の担当者が自分のカードで購入して後から精算する運用が残れば、経費精算の工数が別途発生します。月末に精算処理が集中する状況も変わりません。

スプレッドシートでの精算管理が何に詰まるかはスプレッドシートの経費精算管理が破綻する理由で整理しています。

買ったあとの台帳につながらない

発注が手作業だと、購入した物品が資産台帳に載るかどうかも担当者の運用次第になります。PCや什器のように貸与管理が必要なものは、購買と台帳が分かれた時点で、入社・退職のたびに現物と記録がずれていきます。備品台帳と端末管理の役割の違いは備品管理システム比較7選｜選定の進め方で扱っています。

内製の範囲をどう決めるか

Google Workspaceでの内製が無理なく回るのは、次の条件が揃っている場合です。

• 月あたりの購買申請が数十件程度
• 発注先が1〜2サイトに収まる
• 承認ルートが固定的で、年に数回しか変わらない
• 監査で過去分の証跡提出を求められる可能性が低い

逆に、発注先が複数に分かれ、承認後の発注作業が担当者の恒常的な負担になっているなら、承認と発注が最初から一体になっている仕組みを検討する段階です。判断のサインとして分かりやすいのは、購買担当者が承認待ちの一覧を自分用のメモに転記し始めたときです。仕組みが担うべき状態管理を人が肩代わりし始めた合図になります。

1Approval for Google Workspaceは、申請の時点で購買カタログから商品を選び、在庫を仮押さえした状態で総額つきの承認依頼を出します。承認された瞬間に発注が確定するため、承認後の発注作業と、在庫・価格の変動による再申請がなくなります。承認から支払までの証跡も1本につながった状態で残ります。

よくある質問（FAQ）

Googleフォームだけで購買申請は運用できますか？

申請の受付までは可能ですが、承認のステータス管理や承認者への依頼はできません。スプレッドシートを台帳にし、GASで承認処理を書くか、ワークフロー専用サービスと組み合わせる必要があります。

購買申請の承認ルートは金額で分けるべきですか？

分けることを推奨します。全件に同じ重さの承認をかけると現場が止まり、すべて軽くすると統制が効きません。少額は事後承認と月次モニタリング、一定額以上は事前承認、という段階を決めるのが実務的です。

GASで組んだ購買申請は監査に耐えられますか？

承認者の本人確認、承認ルートの変更履歴、承認済みレコードの改ざん防止という3点を満たせていれば一定の水準には達します。ただしスプレッドシートを台帳にしている場合、管理者が後から値を書き換えられる点は弱点として残ります。

承認後の発注を自動化できますか？

購買サイト側にAPI等の連携手段があれば可能です。ただし認証情報の管理、リトライ、二重発注の防止といった実装が必要で、発注先が複数ある場合はその数だけ保守対象が増えます。

分割発注はどう検知すればよいですか？

同一申請者・同一発注先・同一品目の申請を、一定期間で合算して閾値と比較します。検知しても自動で却下せず、承認者への通知に警告として表示するのが実務的です。この検知には、発注先と品目が選択式で記録されている必要があります。

まとめ

Google Workspaceで購買申請を仕組み化する場合、申請フォームの項目設計、承認者マスタの外出し、承認の本人確認という3点を最初に押さえれば、申請から承認までは無理なく内製できます。

残るのは承認後の発注です。ここが手作業のまま残る限り、購買のリードタイムは短くならず、在庫や価格の変動による再申請も消えません。発注先の数と、承認後の作業負担の大きさを見て、どこまでを内製で賄うかを判断してください。