企業ギフトの自動化を「フォーム送信後に商品を発送する仕組み」とだけ捉えると、資格判断、予算、個人情報、配送責任が一枚の表に集中します。安定した設計では Google Workspace を申請と協働の入口に限定し、判断の責任者、発送イベントの一意性、例外の解決経路を最初から明確にします。
Google Workspaceが担う範囲を先に決める
スクリプトを書く前に業務境界を決めます。申請は Google Forms API から受け取り、審査待ちの情報は Google Sheets API を通じて表示し、限定的な調整処理を Google Apps Script に任せられます。しかし、これらの部品が支出の合法性、受取人の税務、従業員の適格性、配送可能国を独自に判断してはいけません。責任者と統制された業務システムが下した判断だけを運ぶ役割にします。
Forms は構造化された申請、Sheets は確認可能な作業列、Apps Script は検証・通知・発送連携、ギフト基盤は受取体験と履行に使います。適格性の規程、予算権限、本人管理、法務解釈、給与処理は、それぞれの正規システムに残します。セルが緑色でも承認記録とは限らず、タブの複製は復旧可能なバックアップではなく、外部呼び出しが成功しても配送完了ではありません。
実装前に一ページの運用規程を作ります。対象となる機会、申請者、承認者、予算源、受取人区分、必要証拠、禁止用途、保存期間を記載します。判断記録には承認者、日時、規程版、予算番号、受取人参照、申請内容の要約値を含めます。これにより、自動化が誰も委任していない権限まで徐々に引き受ける事態を防げます。
各事実には一つの正規情報源を指定します。雇用状態は人事、顧客適格性は顧客管理、利用可能予算は財務、履行状態は実行基盤が所有します。表は参照と確認用の時点情報だけを持ち、別の原簿を作りません。「誰がこの項目を訂正できるか」を答えられない場合、自動発送を始める準備はまだ整っていません。
各段階とデータに一人の責任者を置く
信頼できる流れは、申請、補完、承認、発送、照合の五段階に分けられます。各段階に一人の説明責任者、明確な入出力、期限超過時の引継先を設定します。人事、情報技術、イベント、調達、財務が曖昧に共同所有すると、例外は私信に散らばり、なぜ発送されたかを後から説明できません。
表：統制された企業ギフト業務の責任境界と証拠。
| 段階 | 主担当 | システムの処理 | 必要な証拠 |
|---|---|---|---|
| 申請 | 企画運営 | 必須項目と同意経路を検証 | 申請番号、申請者、目的、規程版 |
| 補完 | 本人情報またはデータ担当 | 安定した受取人参照と市場を解決 | 検索結果、情報源、時刻、確度 |
| 承認 | 予算・規程承認者 | 承認、否認、修正差戻し | 承認者、判断、理由、予算番号 |
| 発送 | 自動化サービス担当 | 実行基盤へ一度だけ有効な要求を送信 | イベント鍵、申請要約値、応答番号 |
| 照合 | 企画運営と財務 | 受付、選択、出荷、配達、失敗、返金を照合 | 状態履歴、金額、例外担当、完了証拠 |
表示項目と制御項目を分けます。氏名は人が読みやすい一方、重複防止には変わりにくい従業員番号や顧客番号が必要です。企画名は運営に便利ですが、再実行を安全にするのは機械用イベント鍵です。国は経路選択に必要でも、住所は多人数が編集する社内表ではなく、原則として受取人が管理された受取画面で入力します。
表に置く情報を最小にします。審査者に必要なのは機会、業務目的、地域、予算帯、申請者、承認者、状態です。自宅住所、私用電話、商品選択、詳細な配送履歴は通常不要です。項目区分ごとに保存期限と削除担当を決め、判断、発送、照合のどれにも使わない項目は削除します。
作業表は自由なキャンバスではなく、版管理された待ち行列として扱います。列名を固定し、制御列を保護し、許容値を文書化し、コードでも再検証します。編集者は無効値の貼付、列移動、旧版復元、数式の上書きを行えるため、発送処理は安定した見出し名で読み、構造版を確認してから動作します。
修正と取消ができる安全な申請を設計する
申請フォームでは、申請者が正当に提供できる情報だけを尋ねます。勤続記念なら従業員番号、機会、基準日、企画番号、業務理由を受け取り、配送先と希望は後の招待で本人に入力してもらいます。顧客イベントなら顧客管理上の参照、組織、関係担当者、イベント、国、承認済み予算を受け取り、便利だからという理由で私的住所を貼らせません。
自由記述は検証が難しく、過剰共有されやすく、部分削除もしにくい形式です。申請時に住所が本当に必要なら、名前付き項目に分け、利用目的と保存期間を説明し、回答先の閲覧者を限定します。販促への同意と配送のための情報利用は別の目的であり、一つの同意欄でまとめません。
重要な変更は承認済みの行を直接書き換えず、新版として記録します。旧版の要約値、変更者、日時、理由を保存します。国、予算、受取人、機会が承認後に変わった場合は再審査へ戻し、以前の承認表示を残しません。取消も独立したイベントにして、予算確保と発送待ち行列を同時に解放します。
安全な初期値は、未完成の申請を下書きに置く、必須不足を承認できない、未知の市場へ発送しない、超過予算を自動縮小しない、同一イベントを上書きしない、時間切れを即失敗と解釈して再送しない、というものです。拒否時には修正方法を返し、利用者が行の複製で統制を回避しないようにします。
Forms API の通知先は Cloud Pub/Sub で、監視は最長一週間なので更新が必要です。通知に含まれるのは識別情報であり、実際の回答は別途取得します。この方式を使う場合は監視更新、重複通知、遅延、欠落を監視し、定期走査を復旧手段として残します。通知受信と回答処理完了を同じ状態にしてはいけません。
本人確認と送付許可を分離する
Google Workspace Directory API は会社アカウント、別名、状態の確認に役立ちますが、対象者が見つかったことは贈呈許可を意味しません。ディレクトリは「誰か」と一部のアカウント状態を答え、規程、人事、商務の正規システムが「今回の対象か」を答えます。両方の結果を別々に記録します。
氏名やメールアドレスではなく、安定した識別番号を優先します。退職、異動、改姓、ドメイン統合、別名により表示値は変わります。検索結果には情報源、検索時刻、利用範囲、結果要約を含め、有効期限を決めます。発送直前に雇用状態を再確認しても、完全なディレクトリ情報をギフト表へ複製する必要はありません。
権限は最小範囲にします。読み取りだけなら、更新可能な広い権限ではなく閲覧専用の範囲を選びます。技術用アカウントの所有者、用途、承認者、有効期限、失効手順を台帳に記録します。全社ディレクトリを読める資格情報を、退職と同時に消える個人所有の設定へ依存させません。
検索不能には少なくとも三種類あります。番号誤り、情報源の一時障害、社内ディレクトリ外の対象者です。番号誤りは申請者へ戻し、一時障害は再試行可能な技術例外にし、外部対象者は顧客・外部受取人向けの統制経路へ移します。すべてを「未検出」とまとめると、運営担当が手入力で埋め、監査性を壊します。
承認をチェック欄ではなく状態機械にする
状態と許可される遷移を明確に定義します。下書き、情報不足、規程審査待ち、予算承認待ち、発送待ち、発送中、受付済み、配達済み、例外、取消、完了などを用意します。遷移ごとに実行者、時刻、理由、規程版、前後状態を記録します。
表：承認から発送までの最低限の統制。
| 現在の状態 | 許可する操作 | 実行者 | 前提条件 |
|---|---|---|---|
| 下書き | 提出または削除 | 申請者 | 必須項目と構造版が有効 |
| 規程審査待ち | 承認、否認、差戻し | 規程担当 | 適格性の情報源と業務理由を確認 |
| 予算承認待ち | 承認または否認 | 予算担当 | 予算番号が有効で金額を確保 |
| 発送待ち | 発送または取消 | 発送サービス | 要約値不変、イベント鍵一意、対象地域対応 |
| 例外 | 再試行、取消、手動完了 | 指定された例外担当 | 原因、証拠、次の行動を記録 |
高リスクの申請では、同じ人が申請、承認、変更をすべて行わないよう職務を分けます。金額、受取人区分、市場に応じて段階承認を使います。低リスクの従業員施策を一括承認する場合でも、固定した対象版、総額、規程版、責任者を保存します。
承認は同じセルの「はい／いいえ」を上書きするのではなく、変更不能な出来事として残します。発送処理は現在の申請要約値と承認時の値を比較し、異なれば停止します。これにより、承認後に受取人、金額、国が変更されても承認表示だけが残る事故を防げます。
期限超過も種類別に扱います。未承認は待機または取消であり、自動同意ではありません。外部サービスの時間切れは結果不明として検索後に再試行を判断します。人手の例外対応が期限を超えたら代替責任者へ引き上げます。異なる期限超過を一つの「エラー」列にまとめません。
イベント鍵、要約値、短期ロックで重複を防ぐ
危険なのは明確な失敗より、「要求は成功したが応答を受け取れなかった」状況です。利用者がボタンを再度押すか定期処理が走ると、同じギフトが二重に送られます。派送可能な出来事ごとに決定的で一意なイベント鍵を作り、再送前に既存結果を照会します。
イベント鍵は企画、機会、安定した受取人番号、版から作れます。行番号は並べ替えや挿入で変わるため使いません。申請要約値には市場、予算帯、規程版、受取人参照など判断に影響する標準化項目を含めます。承認後に要約値が変われば再承認します。
フォーム起動、定期処理、手動ボタンが同じ行を同時処理することがあります。LockService は短い重要区間の競合を防げますが、永続的な待ち行列でも外部の重複防止でもありません。ロック取得後に状態を読み直し、まだ発送可能なら発送中と試行番号を書き、すぐ解放して外部呼び出しへ進みます。
構造と承認時の要約値を検証
イベント鍵を生成または読取
短期のスクリプトロックを取得
未発送であることを再確認
発送中と試行番号を記録
ロックを解放
イベント鍵付きで実行基盤へ送信
同じ鍵で結果を照会して照合記録を更新
再試行には上限と待機時間を設けます。再試行可能な障害、恒久的な検証失敗、結果不明を分けます。時間切れは結果不明なので先に照会し、入力不正は人が修正し、権限拒否は停止してサービス担当へ通知します。より広い権限へ切り替えて回避してはいけません。
最小権限で発送し、止まり方を観測する
Google OAuth 2.0 のクライアント情報とトークンは安全に保管し、コード、表、版管理庫へ書きません。必要最小の権限を段階的に付与し、所有者と失効手順を記録し、不要時は失効して削除します。個人が作成した起動設定は作成者として動くため、サービス所有と引継ぎが不可欠です。
Apps Script の設置型起動設定は通常のプログラムや外部接続による変更では再起動せず、作成者の権限で実行されます。作成者の無効化、権限変更、割当量超過で処理が静かに停止する可能性があります。最後の成功時刻、待ち行列の最古年齢、起動設定の所有者、認可状態を監視し、失敗通知メールだけに頼りません。
公式の割当量では、一回の実行は六分、同時実行は利用者当たり三十、スクリプト当たり千、起動設定は利用者・スクリプト当たり二十です。プロパティ値と保存総量にも上限があります。数値は変更され得るため、容量計画では最新の公式情報を確認し、永続的な保証としてコードに固定しません。
処理量は平均だけでなく集中時で見積もります。記念日が月初に集中する、イベント直前に対象者が増える、失敗後に再試行が重なる、といった条件を組み合わせます。一回で全件を処理せず、取得上限と時間余裕を持つ小さな単位に分け、次回が安全に続けられる処理点を事件単位で保存します。待ち行列の増加速度が処理速度を超えたら、新規受付を抑えるか別の実行基盤へ移す判断が必要です。
日次割当量の残りを直接取得できない場合は、利用回数と失敗傾向から余裕を管理します。上限近くまで使う設計ではなく、通常負荷を十分低く保ち、突発的な再処理の余地を確保します。割当量超過を入力不正と同じ表示にせず、技術担当へ通知して利用者には処理保留を伝えます。
発送要求は小さく一定にします。イベント鍵、企画番号、受取人参照または招待先、地域、承認予算、言語、規程版、折返し参照だけを送ります。行全体、社内メモ、承認者のコメント、無関係なディレクトリ情報を送らず、ログには秘密や完全な個人情報ではなく要求要約値と応答番号を残します。
観測項目には、待機数、最古待機時間、承認から発送までの時間、一意イベント数、重複阻止数、結果不明数、恒久失敗数、取消数、配達率、未解決例外を含めます。警告には担当者と手順書を結び付けます。次の行動を示さない警告は雑音になります。
初日から照合と監査証拠を組み込む
照合は月末の書き出し作業ではなく、状態変更の一部です。内部申請、実行基盤の応答、財務記録をイベント鍵と外部応答番号で結びます。氏名と金額による推測照合は、同姓同名、同額、反復企画で破綻します。
照合規則にも版を付けます。状態名、返金の認識方法、為替日、手数料計算が変わっても、過去の出来事は当時の規則で解釈し、新しい出来事だけに新版を適用します。報告書には規則版、データ締切時刻、まだ期限内の未完了イベントを示し、通常の履行中の招待を紛失と誤認しません。複数通貨では原通貨額、換算率、換算日、報告通貨を別々に保存します。
毎日、承認済み未発送、発送中の期限超過、外部受付済みだが内部未更新、取消済みの費用、返金済みの未解放予算、配達済みの証拠不足を抽出します。例外には経過日数、金額、担当者、次の行動、約束日を持たせ、閉じるまで追跡します。
監査履歴には判断と必要な技術証拠を残し、余分な個人情報を残しません。イベント鍵、申請版、要求要約値、規程版、承認者、予算番号、発送時刻、外部応答番号、状態履歴、例外処置、削除証明が中心です。機密内容は適切なシステムに残し、監査側は逆引きできない参照だけを保持します。
証拠のつながりは定期的に抽出検査します。完了、取消、失敗から無作為に選び、申請から承認、外部応答、費用、最終状態まで所定時間内に再構成できるか確認します。特定の担当者の記憶が必要なら、後続版に不足する構造化イベントを追加します。過去データを推測で埋めず、補足記録には作成時刻と理由を明示します。
バックアップは復元試験まで行います。作業表を複製しても、起動設定、権限、秘密、保護範囲、外部状態は同時に復元されません。四半期ごとに、表の削除、作成者の退職、トークン失効、外部処理の部分成功を想定し、正規情報源から待ち行列を再構築しても重複発送しないことを確認します。
復旧目標はデータと業務の両面で定義します。表を一時間で戻せても、滞留承認と結果不明の発送を安全に処理できなければ復旧とは言えません。訓練では許容するデータ損失時間、復旧後の処理能力、手作業で確認する事件数、申請者や受取人への連絡条件を測ります。照会と照合を省いて速さだけを求めると、停止事故が重複発送へ変わります。
先に削除する情報と、残すべき証拠は何か
住所、電話、自由記述、嗜好は履行と必要な異議申立期間の後に優先して削除します。イベント鍵、規程版、判断時刻、金額、承認者、逆引きできない外部参照は財務・監査方針に従って保存できます。実際の期限はプライバシー、法務、財務、人事の責任者が決定し、スクリプト作者だけで決めません。
実例一：三か国の勤続記念
米国、日本、ドイツの勤続記念を想定します。人事システムは毎月、初期条件を満たす従業員番号、記念日、勤務国、企画番号を出力し、住所は出しません。運営が件数と予算帯を確認し、地域人事が雇用状態と現地規程を確認し、財務が予算を確保します。
各従業員のイベント鍵は企画、記念月、安定した従業員番号、版で構成します。承認は固定した対象版と規程版を参照します。発送前に雇用状態を再確認し、退職、休職、国変更なら地域審査へ戻します。住所と希望は実行基盤が本人から受け取り、Workspace は招待状態と外部参照だけを持ちます。
四百件目で実行時間上限へ近づく障害を加えます。正しい設計は一回の取得件数を制限し、各イベントに処理点を保存し、次回は発送待ちのものだけを続行することです。現在の行番号を処理点にせず、バッチ未完了を理由に前の三百九十九件を再送しません。
十二人がドイツから日本へ異動した場合、国は選択肢、費用、規程に影響するので申請要約値が変わり、旧承認は失効します。新版を作り、旧版の取消を残し、対象十二件だけを地域人事と予算担当が再確認します。全体を再承認する必要はありません。
終了時には、一意な承認イベント、外部受付、受取選択、配達、取消、失敗、返金の数を照合します。財務合計はイベント単位の金額から予算確保へ戻せなければなりません。差異は指定された例外として解決し、集計値の手動調整で隠しません。
実例二：顧客イベントの直前変更
百二十名の顧客会合を想定します。顧客管理は関係と連絡資格、イベント管理は出席、財務は予算、ギフト企画は規程と履行を担当します。フォームは講演者謝礼、交換、国変更など、承認された例外にだけ使います。
候補には顧客連絡番号、イベント番号、国、関係担当者、企画番号、予算帯を含めます。マーケティングが業務目的と利益相反確認を行い、より慎重な受取人は会社方針に従い調達または法令順守担当が審査します。表には顧客管理から住所を取り込みません。
開催七日前に主対象版を固定します。直前追加は新版とし、既存行を黙って変更しません。発送前の取消は予算を解放し、外部受付後は実行基盤の取消規則に従います。国変更は商品、費用、期間が変わるため市場審査へ戻します。
三十件が時間切れになったものの、外部では二十件を受け付けた部分障害を考えます。三十件すべてを再送せず、イベント鍵で照会し、二十件を受付済みにし、存在しないことを確認した十件だけ再試行します。最終報告では受付件数が一意な承認イベント数と一致することを示します。
成功とはスクリプト完了ではありません。全発送に有効な承認があり、意図しない重複がなく、例外に担当者が付き、財務合計が一致し、個人情報が適切な場所に留まることです。この基準なら、イベント終了後も判断を説明できます。
可逆的に導入し、運用判断を残す
段階的に構築します。境界、データ区分、状態を文書化し、合成データで構造を検証します。次に閲覧専用の本人検索、承認イベント、模擬発送を追加します。脅威確認後に本番資格情報を入れ、小規模試行では全件を手作業でも照合し、自動報告との差がなくなってから拡大します。
-
サービス、データ、規程、予算、安全、運営の責任者を指定する。
-
本人、適格性、予算、履行の正規情報源を確認する。
-
申請と審査の構造を版管理し、制御列を保護する。
-
認可範囲、資格情報所有者、起動設定所有者、失効手順を登録する。
-
イベント鍵、要約値、短期ロック、有限再試行、再送前照会を実装する。
-
重複、時間切れ、割当量、権限、取消、配達失敗を試験する。
-
保存、削除、アクセス確認、バックアップ、復元の証拠を定義する。
-
小規模試行で、全受付イベントを完了まで照合する。
重要処理をApps Scriptの外へ移す時期はいつか
実行時間、同時処理、安全統制、配備規律、地域要件、復旧目標がスクリプトで確実に満たせなくなった時です。使い慣れたフォームと表は画面として残せますが、永続待ち行列、秘密、記録、連携処理は所有者が明確な管理サービスへ移します。
長く使える形は「フォームから表を経由してギフト」ではなく、統制された申請、版管理された承認、重複しない発送、証拠に基づく照合です。Google Workspace は身近な協働画面として有効ですが、各部品の権限を狭くし、障害時に推測で再送しない設計によって初めて安全になります。
組織が適格性と規程判断を終えた後、Giftpack は最小化された発送情報を受け取り、受取人の選択と国際的な履行を調整する実行層として利用できます。Giftpack は Workspace 管理、本人統制、同意、税務、給与、法務、雇用主判断を代替せず、それらの責任は組織と専門家に残ります。