GASツールの保守費の考え方｜月額保守・追加改修・障害対応

公開日：2026/05/20

GAS GAS × 業務改善 GAS実務運用 GAS Google Apps Script Google Workspace 保守費月額保守業務改善社内ツール追加改修障害対応顧客納品

GAS（Google Apps Script）で作った業務ツールは、納品して終わりではありません。

発注フォーム、請求書送信、進捗管理、日報入力、メール通知など、業務で使うツールであれば、運用開始後に確認、修正、問い合わせ対応、Google側の仕様変更対応が必要になることがあります。

最初は小さなツールでも、利用者が増える、業務ルールが変わる、担当者が変わる、スプレッドシートの列が増える、といった変化が起きると、保守の必要性が出てきます。

そのため、GASツールを顧客へ納品する場合は、初期開発費だけでなく、保守費をどう考えるかも整理しておくことが大切です。

この記事では、GASで作ったツールの保守費について、月額保守に含める作業、追加改修として分ける作業、障害対応やGoogle仕様変更対応の考え方を実務目線で整理します。

具体的な金額表ではなく、見積、契約、顧客説明で使いやすい判断軸を中心に解説します。

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

GASツールの保守費を考えるときに大切なのは、「何でも月額保守に含める」としないことです。

保守費には、日常的な確認、軽微な修正、問い合わせ対応、障害時の一次確認などを含めることができます。

一方で、新しい機能の追加、画面の大幅変更、帳票レイアウトの作り直し、別システムとの新規連携などは、追加改修として別見積にした方が分かりやすいです。

最初に線引きをしておかないと、顧客側は「保守費を払っているから全部対応してもらえる」と考えやすくなります。

開発者側は、想定以上の作業が増えても追加費用を請求しにくくなります。

そのため、GASツールの保守では、次の点を先に決めておくことが重要です。

月額保守に含める作業
追加改修として扱う作業
障害対応の範囲
対応時間と対応方法
Google仕様変更時の扱い
バックアップや復旧確認の範囲
顧客側で行う作業
保守対象外になる条件

保守費は、単なる「修正費」ではありません。

業務ツールを安心して使い続けるための確認、相談、切り分け、軽微な調整に対する費用として考えると、顧客にも説明しやすくなります。

2. GASツールに保守費が必要になる理由

GASツールは、比較的低コストで業務改善を始められる便利な仕組みです。

ただし、Googleサービス、スプレッドシート、Gmail、Googleドライブ、トリガー、外部APIなどと連携するため、運用中に変化の影響を受けることがあります。

たとえば、次のようなことが起きます。

スプレッドシートの列やシート名が変更される
担当者のGoogleアカウントが変わる
共有権限が変更される
トリガーが停止する
Gmail送信数やURL Fetchの制限に近づく
Google側の仕様変更や画面変更がある
業務ルールが変わり、入力項目が増える
利用者から操作方法の問い合わせが来る
エラーが出たが原因が分からない

これらは、初期開発時に完全には防げません。

もちろん、設計やテストでリスクを減らすことはできます。しかし、業務で使い続ける限り、運用中の確認や調整は発生します。

特に顧客向けに納品する場合、納品後に開発者が一切関与しない前提だと、トラブル時に誰が確認するのかが曖昧になります。

GASツールは、Googleアカウントや共有権限と強く結びついているため、顧客側の操作や環境変更が原因で動かなくなることもあります。

そのようなときに、原因を切り分け、軽微な調整を行い、必要であれば追加改修の見積へつなげる役割が保守です。

3. 月額保守に含める作業

月額保守に含める作業は、あらかじめ範囲を決めておくと運用しやすくなります。

一般的には、日常運用の安心につながる軽めの作業を含めると説明しやすいです。

たとえば、次のような作業です。

操作方法の簡単な問い合わせ対応
エラー発生時の一次確認
トリガーや実行ログの確認
軽微な文言修正
メール本文の軽微な修正
帳票内の小さな表記修正
管理用スプレッドシートの軽微な調整
バックアップ手順の確認
Google側の仕様変更情報の確認
保守対象ツールの簡単な動作確認

ここで大切なのは、「軽微」の意味をできるだけ具体的にすることです。

たとえば、「メール本文の1〜2行程度の修正」「表示文言の変更」「既存項目名の変更」など、作業の種類を例示しておくと認識違いを減らせます。

また、対応回数や対応時間の目安も決めておくと安全です。

月額保守費の中で無制限に対応する形にすると、問い合わせが増えたときに保守が赤字になりやすくなります。

そのため、「月に何時間まで」「軽微対応は月に何件まで」「大きな改修は別見積」といった考え方を持っておくと、顧客にも説明しやすくなります。

月額保守で扱いやすいのは、既存機能を安定して使い続けるための作業です。たとえば、エラー通知の確認、軽微なログ確認、定期実行トリガーの状態確認、送信件数や処理件数の簡単な確認、担当者変更に伴う通知先の差し替えなどです。これらは毎月大きな改修が発生しなくても、業務ツールとして止めないために必要になることがあります。

一方で、保守費を「何でも相談できる費用」として受けてしまうと、作業範囲が広がりすぎます。ボタン名を少し変える、通知先を1件追加する、といった軽微な作業は保守に含めてもよいかもしれません。しかし、入力項目を増やす、承認フローを追加する、PDFレイアウトを作り直す、別部署でも使えるようにする、といった作業は、既存機能の維持ではなく追加改修に近くなります。

月額保守の説明では、「毎月必ず大きな作業をする費用」ではなく、「問題が起きたときに状況を確認し、既存機能を維持するための窓口と確認作業の費用」と伝えると誤解が少なくなります。顧客にとっては、何も起きていない月にも費用が発生する理由が分かりやすくなります。

保守に含める時間の上限も決めておくと安心です。たとえば、月に何時間まで、問い合わせは何件まで、一次確認は何営業日以内、軽微な修正はどこまで、という形です。上限を決めずに受けると、実質的には常時サポートになってしまい、小さな案件ほど採算が合わなくなります。

4. 追加改修として分ける作業

月額保守と追加改修の線引きは、最初に決めておくべき重要なポイントです。

保守は、既存ツールを安定して使うための確認や軽微な調整です。

追加改修は、ツールの機能や構成を変える作業です。

たとえば、次のような作業は追加改修として扱う方が分かりやすいです。

新しい入力画面を追加する
新しい帳票を作成する
PDFレイアウトを大きく変更する
承認フローを追加する
権限管理を新しく作る
外部API連携を追加する
Supabaseなど外部DBへ移行する
スプレッドシート構成を大きく変える
複数拠点や複数顧客に対応させる
既存コードを大きく作り直す

顧客から見ると、「少し項目を増やすだけ」に見える作業でも、内部ではデータ構造、画面、帳票、メール、ログ、テストに影響することがあります。

そのため、影響範囲が広い変更は、月額保守の中で対応せず、追加改修として見積もる方が安全です。

保守費の説明では、「既存機能を保つための対応」と「新しい価値を追加する対応」を分けると伝わりやすくなります。

追加改修として分けた方がよい作業には、業務ルールの変更が含まれることが多いです。たとえば、請求書送信ツールで承認者を追加する、発注フォームで商品マスタを参照する、進捗管理で写真添付を追加する、日報ツールで集計単位を変更する、といった内容です。見た目には小さな変更でも、データ構造、権限、通知、帳票、過去データへの影響を確認する必要があります。

顧客から見ると、「項目を1つ足すだけ」「メール文を少し変えるだけ」に見えることがあります。しかし、実際にはフォーム、スプレッドシート、GASコード、PDFテンプレート、メール本文、履歴シート、既存データの整合性まで関係することがあります。そのため、追加改修では、作業前に影響範囲を確認し、見積として切り出す方が安全です。

追加改修の判断基準は、事前に文章で用意しておくと説明しやすくなります。たとえば、「既存機能をそのまま使い続けるための軽微な修正は保守範囲」「新しい入力項目、集計条件、通知条件、帳票形式、利用部門追加は追加改修」という線引きです。厳密にすべてを分類する必要はありませんが、顧客と作り手の認識を合わせる材料になります。

また、追加改修は急ぎ対応にしない方がよい場合があります。業務上は急ぎでも、十分な確認なしに修正すると、既存処理が壊れたり、過去データとの整合性が崩れたりします。特にGASツールは、スプレッドシートの列順やシート名に依存していることがあるため、影響調査を省くと後で大きな障害につながります。

5. 障害対応・Google仕様変更対応の考え方

GASツールの保守で難しいのが、障害対応とGoogle仕様変更対応です。

障害といっても、原因はいくつかに分かれます。

ツール側の不具合
顧客側の操作ミス
スプレッドシート構成の変更
共有権限の変更
Googleアカウントの変更
Googleサービス側の一時的な障害
Google側の仕様変更
外部API側の変更

原因によって、対応の扱いは変わります。

開発時の不具合であれば、一定期間は無償修正にする場合があります。

一方で、顧客側の設定変更や業務ルール変更が原因であれば、保守対応または追加改修として扱うことが多くなります。

Google側の仕様変更は、開発者にも顧客にも完全にはコントロールできません。

そのため、契約時に「Google側の仕様変更や制限変更により改修が必要になった場合は、影響確認までは保守、改修作業は別見積」といった考え方を説明しておくと、後から話しやすくなります。

また、障害対応では、復旧時間を保証するかどうかも重要です。

小規模なGASツールでは、24時間365日の即時対応を前提にしないことが多いはずです。

対応可能な曜日、時間帯、連絡方法、初回返信の目安を決めておくことで、顧客側の期待値を調整できます。

障害対応では、まず原因を切り分ける時間が必要です。GASコードの不具合なのか、Google側の仕様変更なのか、アカウント権限の変更なのか、スプレッドシートの列やシート名を利用者が変えたのか、メール送信数や実行時間の制限に当たったのかを確認します。原因が分からないまま修正すると、別の問題を増やしてしまうことがあります。

障害対応を保守費に含める場合でも、どこまでを一次確認とするかを決めておく必要があります。ログ確認、再現確認、設定確認、Google側のエラー確認までは保守範囲に含める。一方で、仕様変更に合わせた大幅な作り直し、権限設計の変更、データ復旧、別方式への移行は別見積にする、という整理です。

Googleの仕様変更や制限変更は、作り手だけでは防ぎきれません。たとえば、認証画面の表示、セキュリティ警告、トリガーの停止、Gmail送信制限、Drive権限、HTML Serviceの挙動などは、利用環境やGoogle側の変更によって影響を受ける可能性があります。保守契約では、こうした外部要因があることを最初に説明しておくと、トラブル時に話が進めやすくなります。

障害時の優先度も決めておくと実務で助かります。全員が使えない、請求書送信が止まっている、締め処理に影響する、といったものは優先度が高いです。一方で、表示文言の違い、集計表の軽微なズレ、月次処理まで時間があるものは、通常対応にできます。優先度の基準がないと、すべてが緊急扱いになり、保守対応が破綻しやすくなります。

6. 顧客へ説明しておきたいこと

保守費は、顧客にとって分かりにくい費用になりやすいです。

初期開発費は「ツールを作る費用」として理解されやすいですが、保守費は「何に対して払うのか」が曖昧になりがちです。

そのため、契約前や納品時に、次のような点を説明しておくとよいです。

保守費に含まれる作業
保守費に含まれない作業
追加改修になる例
問い合わせ方法
対応時間
緊急対応の扱い
顧客側で変更してよい範囲
顧客側で変更してはいけない範囲
バックアップや復旧の考え方
Google仕様変更時の扱い

特に大事なのは、顧客側で触ってよい場所と、触ると壊れやすい場所を分けることです。

スプレッドシートの列名、シート名、非表示シート、設定値、テンプレートファイル、ドライブフォルダ、トリガーなどは、変更するとツールに影響することがあります。

顧客が自由に編集してよい範囲を決めておくことで、トラブルを減らせます。

また、保守契約を結ぶ場合は、簡単な運用資料やチェックリストを用意しておくと説明しやすくなります。

顧客へ説明するときは、技術用語だけでなく業務影響に置き換えると伝わりやすくなります。たとえば、「GASの実行時間制限があります」だけではなく、「大量データを一度に処理すると途中で止まる可能性があるため、件数が増えたら分割処理や再開設計が必要です」と説明します。

また、「保守費を払えば何でも直る」という印象にならないようにします。保守は既存ツールを安定して使うための確認と軽微対応であり、業務ルールの変更や機能追加は別途相談になることを明確にします。顧客側にとっても、費用の見通しを立てやすくなります。

納品時には、誰がツールの所有者なのか、どのGoogleアカウントでトリガーが動いているのか、エラー通知は誰に届くのか、スプレッドシートやDriveフォルダの権限は誰が管理するのかを確認します。これらが曖昧なままだと、担当者退職や部署異動のタイミングでツールが止まることがあります。

説明資料や契約書に、連絡方法と対応時間も入れておくとよいです。チャットで随時受けるのか、メールで受けるのか、緊急対応はあるのか、休日夜間は対象外なのかを決めます。小さな保守契約でも、この点を曖昧にすると、作り手側が常に待機しているような状態になってしまいます。

7. 保守契約が向いているケース・不要なケース

すべてのGASツールに月額保守が必要なわけではありません。

小さな個人用ツールや、利用頻度が低い単発処理であれば、必要なときだけスポット対応にする方が合う場合もあります。

一方で、次のような場合は保守契約を検討しやすいです。

毎日または毎週使う業務ツール
メール送信やPDF作成を含む
トリガーで自動実行している
複数人が使う
顧客や取引先に影響する
業務停止につながる可能性がある
スプレッドシートや権限を顧客が操作する
Google Workspace環境で運用する
納品後も問い合わせが想定される

保守契約が不要なケースもあります。

たとえば、単発のデータ整形ツール、社内の一時的な集計ツール、利用者が1人だけの小さな補助ツールなどです。

この場合は、月額保守ではなく、必要時に都度見積で対応する形でもよいでしょう。

大切なのは、ツールの重要度、利用頻度、影響範囲に応じて保守の形を選ぶことです。

保守契約が向いているのは、止まると業務に影響が出るツールです。請求書送信、発注受付、顧客への自動メール、日次レポート、承認処理、外部取引先が使うフォームなどは、問題が起きたときにすぐ状況確認できる体制があった方が安心です。特に、月末月初や締め日など、処理の失敗が売上や顧客対応に直結する場合は、保守費を前提にした方が現実的です。

逆に、社内の補助集計、担当者が手動で代替できる一覧作成、月に一度しか使わない簡易変換ツールなどは、都度対応でも十分なことがあります。保守契約を無理に付けるより、トラブル時にスポット対応する前提にした方が、顧客にとっても納得しやすい場合があります。

判断のポイントは、停止時の影響、利用頻度、利用者数、データの重要度、担当者変更の可能性です。利用者が多く、権限や通知先が変わりやすく、処理結果が顧客や取引先に届くツールほど、保守の必要性が高くなります。

保守契約を提案するときは、金額だけでなく、保守がない場合に顧客側で担う作業も説明します。エラー通知を確認する、トリガー停止に気づく、Googleアカウントの権限を維持する、仕様変更時に影響を判断する、といった作業です。保守費は、これらを外部に任せるための費用だと整理できます。

8. 保守契約前に決めるチェックポイント

保守契約を始める前には、作業範囲、連絡方法、対応時間、費用の考え方を決めておくことが大切です。

まず、対象ツールを明確にします。スプレッドシート、GASプロジェクト、フォーム、Driveフォルダ、PDFテンプレート、通知メール、外部サービス連携など、どこまでが保守対象なのかを一覧化します。似たファイルが複数ある場合は、対象外のファイルも分かるようにしておくと、後から混乱しません。

次に、月額保守に含める作業を決めます。エラー確認、軽微な設定変更、通知先変更、ログ確認、トリガー確認、利用方法の簡単な問い合わせ対応などです。ここに含まれない作業は、追加改修またはスポット対応として扱います。

追加改修の例も用意しておきます。新しい帳票追加、項目追加、画面追加、承認フロー追加、外部サービス連携、別部署展開、データ移行、既存仕様の大きな変更などです。顧客が「これは保守に含まれると思っていた」と感じないよう、事前に例を見せることが有効です。

障害対応では、一次確認の範囲を決めます。ログを見る、再実行する、権限を確認する、Google側のエラーを確認する、利用者操作を確認する、という範囲です。原因が外部サービスやGoogle側の仕様変更にある場合は、対応方針を相談し、必要に応じて別見積にします。

最後に、解約時や担当者変更時の扱いも決めておきます。保守を終了した後にエラーが出た場合の対応、ドキュメントの引き渡し、所有者変更、認証情報の管理、バックアップの有無などです。保守契約は開始時だけでなく、終了時の整理まで含めておくと、双方にとって安全です。

保守契約の説明では、顧客側で行う作業も明確にします。たとえば、Google Workspaceアカウントの管理、利用者追加、部署異動時の権限変更、社内ルールの変更連絡、業務内容が変わったときの共有などです。開発者側だけで把握できない変更があるため、顧客側にも運用上の役割があります。

バックアップの考え方も確認します。スプレッドシートを日次でコピーするのか、Drive上に世代管理するのか、重要なPDFやCSVをどこに残すのかを決めます。保守費にバックアップ確認を含める場合は、確認頻度と復旧作業の範囲も分けます。バックアップの存在確認までは保守範囲、復旧作業は別見積、という整理もあります。

問い合わせの受け方も重要です。利用者全員から直接問い合わせを受けるのか、顧客側の窓口担当者を1人決めるのかで、保守負荷は大きく変わります。小規模な保守では、顧客側の窓口を決めてもらい、問い合わせを整理してから連絡してもらう方が対応しやすくなります。

保守契約には、軽微対応の判断方法も入れておくとよいです。たとえば、文言修正、通知先変更、設定値変更は軽微対応に含める。一方で、画面追加、処理分岐追加、データ構造変更、帳票追加、外部サービス連携は追加改修にする、という例です。例があるだけで、相談時の認識違いを減らせます。

最後に、保守契約は「毎月作業する保証」ではなく、「必要なときに確認できる体制を維持する費用」だと説明します。何も起きない月があっても、エラー通知や問い合わせ先、状況確認の準備があること自体に価値があります。顧客の業務にとって重要なツールほど、この考え方を共有しておくことが大切です。

保守開始前には、初期状態の記録も残しておくと役立ちます。対象スプレッドシート、GASプロジェクト、トリガー、Driveフォルダ、テンプレート、通知先、実行アカウントを一覧にしておくと、問題が起きたときに「以前と何が変わったか」を確認しやすくなります。小さなツールでも、この記録があるだけで切り分け時間を短縮できます。

また、顧客側で変更する可能性が高い項目は、できるだけ設定シートに寄せておくと保守しやすくなります。通知先、メール文面、保存先フォルダ、表示順、担当者名などをコード内に直接書くと、変更のたびに開発者対応が必要になります。保守費を抑えたい場合は、顧客が変更できる設定と、開発者が変更すべき処理を分ける設計も重要です。

保守費を提示するときは、安く見せることより、継続できる範囲にすることが大切です。無理に安い月額で広い範囲を受けると、問い合わせが増えたときに対応が雑になり、結果的に顧客満足度も下がります。対応できる時間、対象ツール、軽微対応の範囲を現実的に決めておく方が、長く付き合いやすい保守になります。

小さなGASツールでも、業務に組み込まれた時点で「止まったら困る仕組み」になります。だからこそ、保守費は後から慌てて決めるのではなく、納品時点で選択肢として提示しておくと、顧客も運用後の費用を見込みやすくなります。

保守の有無を選べる形にすると、顧客側も予算や業務重要度に合わせて具体的に判断しやすくなります。無理も減ります。