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

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

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

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

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

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

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

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

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

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

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

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

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

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

特に顧客向けのGASツールでは、納品時点の便利さだけでなく、半年後、一年後にも使い続けられるかを見ておく必要があります。最初の担当者が使えていても、別の担当者が同じように操作できるとは限りません。Googleアカウント、共有ドライブ、メール送信元、トリガー、保存先フォルダの関係が分からないままだと、少し設定を変えるだけでも不安が残ります。

そのため、納品方法は技術的な都合だけで選ばず、顧客側の管理体制に合わせて決めることが大切です。Google Workspaceを使い慣れている会社なら顧客環境への設置が向いていることが多く、Google環境に詳しい担当者がいない場合は、テンプレート納品や自社環境提供の方が説明しやすい場合もあります。

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

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

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

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

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

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

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

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

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

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

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

この不安を減らすには、納品前に必要な権限を説明しておくことが大切です。たとえば、請求書PDFを作るためにDriveへの保存権限が必要、通知メールを送るためにGmail送信権限が必要、管理表を更新するためにスプレッドシート編集権限が必要、というように用途と権限を結びつけて説明します。

トラブルは、機能不足よりも説明不足から起きることがあります。ツールの動作だけでなく、誰の権限で、どのファイルに、どの処理を行うのかを共有しておくと、顧客も安心して運用しやすくなります。

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

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

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

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

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

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

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

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

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

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

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

顧客環境に設置する場合は、初回設定の手順をできるだけ固定しておくとスムーズです。たとえば、最初に保存先フォルダを作る、次に管理用スプレッドシートを置く、テンプレートファイルを同じフォルダにまとめる、最後にGASのトリガーを設定する、というように順番を決めます。

顧客環境設置は、所有者を顧客側に寄せられる一方で、開発者が自由に確認できない場面も増えます。そのため、障害時にどのログを見ればよいか、保守時に一時的な編集権限を付与するのか、常時保守権限を残すのかを事前に決めておく必要があります。

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

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

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

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

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

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

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

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

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

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

テンプレート納品で特に重要なのは、設定値をどこに集約するかです。顧客ごとに変わる値がコードの中に散らばっていると、コピー時の差し替え漏れが起きやすくなります。通知先、フォルダID、テンプレートID、会社名、担当者名、メール文面などは、設定シートやPropertiesにまとめておくと管理しやすくなります。

また、納品済みの版を記録しておくことも大切です。たとえば、A社には2026年5月版、B社には2026年6月版を納品している場合、不具合対応時にどのコードが入っているのかを確認できなければ、修正範囲を判断しにくくなります。簡単な一覧でよいので、顧客名、納品日、バージョン、主な機能、変更履歴を残しておくと保守が楽になります。

テンプレート方式は、同じようなツールを複数顧客へ提供する場合に強い方法です。ただし、納品後の各コピーは独立して動くため、共通テンプレートを改善しただけでは既存顧客の環境は変わりません。更新作業を保守に含めるのか、別途改修として扱うのかも決めておく必要があります。

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

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

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

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

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

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

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

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

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

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

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

自社環境で提供する場合は、顧客から見ると「ツールを納品された」というより「外部サービスを利用している」に近くなります。そのため、稼働時間、障害時の連絡方法、データの保管場所、バックアップ、解約時のデータ返却や削除方法を説明できる状態にしておく必要があります。

また、複数顧客を同じGASプロジェクトで扱う場合は、顧客間のデータ分離を慎重に設計します。設定ミスで別顧客のデータを参照できてしまうような構成は避けるべきです。顧客ごとにフォルダ、スプレッドシート、設定値、ログを分け、アクセス権限も最小限にします。

自社環境提供は保守性が高い一方、提供側の責任も大きくなります。小規模な業務支援として始めたつもりでも、顧客の業務に深く組み込まれると、停止時の影響が大きくなります。単発納品ではなく継続運用として、保守費、対応時間、変更依頼の扱いを決めておくことが重要です。

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

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

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

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

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

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

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

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

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

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

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

納品資料は、詳しすぎる技術資料である必要はありません。管理用スプレッドシートのURL、WebアプリURL、保存先フォルダ、通知先、トリガーの有無、保守連絡先を1枚にまとめるだけでも、引き継ぎ時の負担はかなり減ります。

操作説明では、通常操作だけでなく「やってはいけないこと」も書いておくと安心です。たとえば、管理シートの列名を変えない、テンプレートファイルを削除しない、保存先フォルダを移動しない、トリガーを勝手に削除しない、といった注意点です。

また、納品時点の状態を残す意味で、バックアップを取っておくのも有効です。スプレッドシートやテンプレートを納品時点でコピーしておけば、顧客側で誤って設定を変えた場合でも、元の構成を確認できます。バックアップを誰が持つのか、どこまで戻せるのかも説明しておくと、保守対応がしやすくなります。

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

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

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

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

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

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

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

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

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

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

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

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

保守範囲で曖昧になりやすいのは、「軽微な修正」と「追加開発」の境界です。通知先の変更や文言修正は軽微な保守に含めるのか、シート列の追加や帳票レイアウト変更は追加費用にするのかを決めておかないと、後から認識がずれます。

障害時の対応も同じです。原因調査まで保守に含めるのか、Google側の仕様変更や顧客側の権限変更による停止は別対応にするのか、対応時間は平日日中だけなのかを整理しておくと、双方が動きやすくなります。

担当者変更時の引き継ぎも、保守の重要なテーマです。顧客側の管理者が変わったときに、どのアカウントが所有者なのか、どこにファイルがあるのか、誰がトリガーを管理しているのかが分からないと、ツールは動いていても管理できない状態になります。納品時の資料を更新し、担当者変更のたびに確認する運用にしておくと安全です。

8. 納品方式を選ぶときの判断ポイント

GASツールの納品方式は、顧客の体制、扱うデータ、保守契約、利用人数によって選びます。

顧客がGoogle Workspaceを使っていて、管理者や共有ドライブの運用がある程度整っているなら、顧客環境に設置する方法が向いています。データやファイルを顧客側で管理でき、開発者との契約が終わった後も引き継ぎしやすいからです。

同じような仕組みを複数顧客に提供するなら、テンプレート納品が向いています。設定項目を整理し、納品前チェックリストを用意しておけば、品質を揃えながら効率よく展開できます。ただし、版管理と差し替え漏れには注意が必要です。

顧客側でGoogle環境を管理するのが難しい場合や、提供側で継続的に保守したい場合は、自社環境で提供する方法も選択肢になります。この場合は、データ管理とサービス提供の責任が大きくなるため、保守契約や運用ルールまで含めて設計します。

判断に迷う場合は、次の順番で考えると整理しやすくなります。

• 顧客がデータを自社管理したいか
• 顧客側にGoogle管理者がいるか
• 開発者が継続保守する契約か
• 複数顧客へ同じ仕組みを展開するか
• メール送信や個人情報を扱うか
• 担当者変更後も顧客だけで運用したいか

9. まとめ

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

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

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

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

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