GASツールを顧客に納品する方法：所有者・権限・保守まで実務目線で解説

GAS（Google Apps Script）で業務ツールを作るときは、機能を作ることだけでなく、納品後に誰が所有し、誰が使い、誰が保守するのかを決めておくことが大切です。

スプレッドシート、Googleドライブ、Gmail、Webアプリ、トリガーなどを組み合わせたGASツールは、Googleアカウントや権限設定と強く結びつきます。そのため、作ったファイルを渡すだけでは、運用開始後に困ることがあります。

たとえば、開発者の個人アカウントが所有者のままになっている、顧客側で編集できない、退職した担当者のアカウントにトリガーが残っている、保守時にどこまで触ってよいか決まっていない、といった問題です。

この記事では、GASツールを顧客に納品するときの方法を、所有者、権限、保守の考え方を中心に整理します。契約書や法務の細かい話ではなく、実務で迷いやすいポイントを顧客説明にも使える形でまとめます。

1. この記事で伝えたいこと

GASツールの納品では、「動くものを作る」だけでは不十分です。

納品後に顧客が安心して使い続けられるように、所有者、実行アカウント、共有権限、保守方法、バックアップ、問い合わせ先を整理しておく必要があります。

GASツールは、単体のアプリというより、Google Workspace上の複数の要素を組み合わせて動くことが多いです。

• スプレッドシート
• Googleドライブのフォルダ
• Googleドキュメントやテンプレート
• Gmail送信
• 時間主導トリガー
• WebアプリURL
• 外部API連携

これらは、どのGoogleアカウントが所有しているか、誰に共有されているか、どの権限で実行されているかによって、動作や保守のしやすさが変わります。

そのため、GASツールを顧客に納品するときは、次のような点を先に決めておくことが大切です。

• 顧客環境に設置するのか
• テンプレートとしてコピー納品するのか
• 自社環境で運用して提供するのか
• 誰のアカウントでトリガーを動かすのか
• 保守時に開発者がどこまでアクセスできるのか
• 納品時にどの資料を渡すのか

この整理をしておくと、納品後の引き継ぎや保守対応で迷いにくくなります。

2. GASツール納品でよく起きる困りごと

GASツールの納品でよく起きるのは、所有者と権限の問題です。

開発時は、開発者のGoogleアカウントでスプレッドシートやGASプロジェクトを作ることが多いです。そのまま顧客に共有して使い始めると、ツールの所有者が開発者のまま残ります。

この状態でも動く場合はありますが、長期運用では不安が残ります。

たとえば、開発者側のアカウントでトリガーが動いていると、顧客は何が実行されているのか分かりにくくなります。開発者がアカウントを変更したり、権限を外したりすると、突然処理が止まる可能性もあります。

顧客側の担当者が個人アカウントで所有している場合も注意が必要です。

担当者が異動や退職をしたときに、スプレッドシート、ドライブフォルダ、GASプロジェクト、トリガーの引き継ぎが必要になります。会社として使うツールであれば、個人任せにしすぎない運用が必要です。

権限を広くしすぎる問題もあります。

保守しやすくするために開発者へ編集権限を残す場合がありますが、どの範囲までアクセスできるのかを顧客が理解していないと不安につながります。逆に、納品後に開発者の権限をすべて外すと、障害時に調査できないことがあります。

納品物が曖昧なこともトラブルになります。

WebアプリURLだけ渡して終わりにすると、管理用スプレッドシート、テンプレート、保存先フォルダ、操作方法、バックアップ方法、保守窓口が分からなくなります。納品時に何を渡したのかを明確にしておくことが重要です。

3. 顧客環境に設置して納品する方法

実務で分かりやすい方法の一つは、顧客のGoogle環境にGASツールを設置して納品する形です。

この方法では、顧客のGoogle Workspaceまたは顧客が管理するGoogleアカウント上に、スプレッドシート、ドライブフォルダ、GASプロジェクト、テンプレート類を配置します。ツールの所有者を顧客側に寄せられるため、長期運用では説明しやすい方法です。

顧客環境に設置する場合、まず管理用のアカウントを決めます。

会社で使うツールであれば、担当者個人のアカウントだけでなく、会社として管理できるアカウントや共有ドライブを使う方が引き継ぎしやすくなります。Google Workspaceを使っている場合は、共有ドライブの利用も検討できます。

次に、GASを実行するアカウントを決めます。

時間主導トリガーやメール送信は、設定したアカウントの権限や制限に影響されます。誰のアカウントで実行するのか、送信元メールアドレスはどう見えるのか、トリガー管理者は誰かを確認しておきます。

顧客環境に置くメリットは、顧客が自分たちの資産として管理しやすいことです。

スプレッドシートやドライブ内のデータも顧客側に残ります。開発者との契約が終わった後も、顧客側で権限を管理しやすくなります。

一方で、初期設定には顧客側の協力が必要です。

権限承認、トリガー設定、共有設定、テスト送信などは、顧客の環境で確認する必要があります。顧客がGoogle Workspaceに慣れていない場合は、設定手順を丁寧に案内することが大切です。

4. テンプレートとしてコピー納品する方法

もう一つの方法は、GASツールをテンプレートとして作り、顧客ごとにコピーして納品する形です。

たとえば、発注フォーム、請求書送信、進捗管理など、似た構成のツールを複数の顧客へ提供する場合、元になるテンプレートを用意しておくと効率的です。

テンプレート納品では、元のスプレッドシートやGASプロジェクトをコピーし、顧客名、メール文面、保存先フォルダ、テンプレートID、通知先などを顧客ごとに差し替えます。

この方法のメリットは、品質を揃えやすいことです。

毎回ゼロから作るのではなく、基本構成、シート設計、画面、エラー処理、操作説明を共通化できます。改善した内容を次の案件にも反映しやすくなります。

ただし、コピー後の管理には注意が必要です。

テンプレート元と顧客環境のコピーは別物になります。テンプレート元を修正しても、納品済みのツールに自動反映されるわけではありません。納品後に不具合修正や機能追加を行う場合、どの顧客にどの版を納品したのかを記録しておく必要があります。

また、テンプレート内に開発用のIDやメールアドレスが残らないように確認します。

スプレッドシートID、フォルダID、通知先、APIキー、テスト用メールアドレスなどが残っていると、顧客環境で誤動作する可能性があります。納品前チェックリストを作り、差し替え漏れを防ぐことが大切です。

5. 自社環境で提供する場合の考え方

顧客環境ではなく、自社環境でGASツールを動かして提供する方法もあります。

この方法では、開発者や提供会社が管理するGoogle環境にツールを置き、顧客にはWebアプリURLや入力画面を提供します。顧客側でGoogle環境を細かく設定しなくても使えるため、導入しやすい場合があります。

自社環境で提供するメリットは、保守しやすいことです。

開発者側でGASプロジェクト、トリガー、ログ、保存先、テンプレートを管理できるため、障害調査や改修を行いやすくなります。複数顧客向けに同じ仕組みを提供する場合も、運用を統一しやすくなります。

一方で、データ管理の責任が重くなります。

顧客の業務データ、メールアドレス、添付ファイル、帳票などを自社環境で扱う場合、アクセス権限、保存期間、バックアップ、削除方法、情報管理の説明が必要になります。

顧客ごとにデータを分ける設計も重要です。

同じスプレッドシートやフォルダに複数顧客の情報を混在させると、管理ミスのリスクが高くなります。顧客ごとにフォルダやスプレッドシートを分ける、必要に応じてプロジェクトを分けるなど、境界を明確にします。

自社環境提供は、単なる納品というより、サービス提供に近い考え方になります。

月額保守、障害対応、データ管理、利用停止時のデータ返却や削除なども含めて、運用ルールを整理しておく必要があります。

6. 納品時に渡しておきたいもの

GASツールを納品するときは、URLやファイルだけでなく、運用に必要な情報も渡しておくと安心です。

まず、利用者向けの情報です。

WebアプリURL、入力画面の使い方、管理画面の見方、通常操作の流れ、よくある入力ミスなどを簡単にまとめます。利用者が迷わず使えることが大切です。

次に、管理者向けの情報です。

管理用スプレッドシート、保存先フォルダ、テンプレートファイル、通知先、トリガー、エラー通知先などを整理します。どのファイルが何の役割を持つのかを一覧にしておくと、引き継ぎがしやすくなります。

保守用の情報も必要です。

GASプロジェクトの場所、主な設定項目、変更してよいシート、触らない方がよいシート、バックアップ方法、障害時の連絡先をまとめておきます。コードの全説明までは不要でも、運用に関わる入口は明確にします。

納品時には、動作確認の結果も残しておくとよいです。

入力、保存、メール送信、PDF作成、権限確認、通知、エラー時の動きなど、主要な処理を確認した記録があると、納品後の認識違いを減らせます。

特に、メール送信や外部連携がある場合は、テスト送信先や本番送信先を間違えないように注意します。

7. 保守範囲と権限をどう決めるか

GASツールは、納品後もGoogle側の仕様変更、顧客業務の変更、担当者変更、メール送信制限、データ増加などの影響を受けます。

そのため、納品時点で保守範囲を決めておくことが重要です。

たとえば、次のような作業を保守に含めるのか、追加改修として扱うのかを整理します。

• 軽微な文言修正
• 通知先メールアドレスの変更
• シート列の追加
• PDFテンプレートの変更
• エラー調査
• Google仕様変更への対応
• 新機能追加
• 利用者への操作説明

保守権限も合わせて決めます。

開発者が継続して保守する場合は、GASプロジェクト、管理用スプレッドシート、保存先フォルダにどの権限を残すのかを明確にします。編集権限が必要なのか、閲覧だけでよいのか、障害時だけ一時的に付与するのかを決めます。

顧客側の管理者も決めておきます。

誰がユーザー追加を行うのか、誰がトリガーや権限を管理するのか、誰が問い合わせ窓口になるのかを明確にすると、運用開始後の連絡がスムーズになります。

バックアップと復旧方法も保守の一部です。

スプレッドシートを定期的にコピーするのか、重要な設定を別ファイルに記録するのか、誤ってデータを消した場合にどこまで戻せるのかを決めておくと安心です。

GASツールは小さく作れる反面、業務に組み込まれると止めにくくなります。だからこそ、納品時に保守と権限の線引きをしておくことが大切です。

8. まとめ

GASツールを顧客に納品するときは、機能だけでなく、所有者、権限、保守の考え方を整理しておく必要があります。

顧客環境に設置する方法は、顧客が自社の資産として管理しやすい一方、初期設定や権限承認に顧客側の協力が必要です。テンプレートとしてコピー納品する方法は、品質を揃えやすい一方、版管理や差し替え漏れに注意が必要です。自社環境で提供する方法は、保守しやすい一方、データ管理やサービス提供としての責任が大きくなります。

どの方法が正解かは、顧客のGoogle環境、保守契約、扱うデータ、運用体制によって変わります。

大切なのは、納品前に「誰が所有するのか」「誰が実行するのか」「誰が保守するのか」「どこまで開発者がアクセスできるのか」を明確にすることです。

GASツールは小さな業務改善に向いていますが、納品後に使い続けるためには運用設計が欠かせません。作って終わりにせず、顧客が安心して使える状態で渡すことが、実務では重要になります。