GASの保守運用費は月額いくら？3ケース試算と算式で出す

GAS（Google Apps Script）で作った自動化は、作った時より「作った後」でお金が動きます。見積書に「保守運用 月額◯円」と書かれていても、その数字がどこから出てきたのかは書かれていないことが多いはずです。

結論：GASの保守運用費は「壊れる確率 × 復旧工数 ＋ 追従工数」で決まる

GASの保守運用費は、作業量（どれだけ手を動かすか）では決まりません。「壊れる確率 × 壊れた時の復旧工数」＋「Google側と業務側の仕様変更に追従する工数」の合計に、社内で持てない割合と時間単価をかけたものが月額になります。平常時は何も起きないので、月額の中身の大半は「起きた時のための待機」と「黙って止まらないための点検」です。

この構造になる理由は、GASの壊れ方がコードの出来とは別のところから来るからです。たとえば1回の実行は6分で打ち切られ、時間主導型トリガーの合計実行時間は無料のGoogleアカウントで1日90分、Google Workspaceで1日6時間までと公式に定められています（Apps Script の割り当てと制限）。コードを1行も変えていなくても、スプレッドシートの行が増えただけでこの線に当たります。つまり「今月は何も触っていないのに止まった」が普通に起きるのがGASで、保守の月額はそこに備える費用です。

作る側の費用（初期開発）がどう決まるかは別の話なので、GAS開発の外注費用を規模別に整理した記事のほうを先に読んでください。この記事は「作り終わった後、誰がいくらで持つか」だけを扱います。

GASの保守運用費を出す算式と9つの変数

単価表を見ても自分の月額は出ません。自分の環境の数字を入れて計算できる形にしたほうが早いので、変数を9つに絞った算式を置きます。

算式は2段です。まず月間の総工数 T を出します。

T ＝ (A ＋ B) × C × D ＋ E ＋ F ＋ G

言葉にすると、「壊れる口の数（トリガー本数＋連携の数）に、口ごとの壊れる確率と1件の復旧工数をかけた“事故の期待工数”」に、「見張りの工数」「Google側の変更への追従」「業務側の変更の受け入れ」を足したものです。壊れる確率Cと復旧工数Dの掛け算になっているのが大事なところで、口が多いシステムほど月額が上がるのは作業が多いからではなく、掛け算の項が増えるからです。

次に、そのうち外に出す分を金額にします。月額固定の見張り料（監視・定時報告などの基本料）を J とすると、

月額 ＝ T × (1 − H) × I ＋ J

社内で持てる割合 H が 1 に近いほど月額はゼロに近づきます。逆に、H を上げる（社内で読める人を作る）ことが唯一、構造的に保守費を下げる手で、単価Iを値切るのは一時的な効果しかありません。なお C と D は公表された統計が存在しないので、過去6か月の自社の実績から出すしかありません。ここを「たぶん月1回くらい」で埋めると月額も当たらないので、止まった履歴を先に数えてください。実行ログが出ない時の3系統の切り分けを使えば、過去の停止回数は実行数画面から数えられます。

GAS固有の「壊れ方」と、月額のどの変数に効くか

GASの壊れ方は数えられるほど種類が限られています。どれが算式のどの変数を押し上げるかを先に一覧にします。

6分の実行時間上限は「ある月から突然」当たる

公式の割り当て表では、スクリプトの実行時間は消費者アカウント・Workspaceアカウントともに6分／回、カスタム関数は30秒／回です。問題は、この線がデータ量に比例して近づいてくることです。1行あたり0.2秒かかる処理なら1,000行で約3分、2,000行で約6分です。運用開始時点では余裕だったものが、1年後の行数で当たります。

したがって保守の月額には「まだ当たっていないが、いつ当たるかを見ておく」費用が含まれているのが正しい姿です。これは算式の E（定期点検）に相当します。実際に当たった時の直し方は6分の実行時間超過エラーを分割実行で直す手順にまとめていますが、直すには一括読み書きへの書き換えや継続トリガーによる分割が必要で、1件の復旧工数 D が大きく出る種類の事故です。

こうした「いつ当たるか」を見ておく仕事は、コードを書くことよりも業務の中身を知っていないと決められません。私たちも独自AI開発サポートでは、作るところだけでなく「誰がいくらで持ち続けるか」まで一緒に決めてから着手しています。記事の途中で恐縮ですが、保守の持ち方から迷っている段階でも相談していただける窓口なので、よろしければ合わせてご覧ください。

一番大きい単発リスクは「トリガーの持ち主」

公式ドキュメントには、インストール可能なトリガーは常に作成した人の権限で実行されると明記されています（インストール可能なトリガー）。つまり、作った担当者が退職してアカウントが停止されれば、そのアカウントが作ったトリガーは全部止まります。コードは無傷なのに自動化が全滅する、という形です。

実務で多いのは、誰のアカウントで動いているかを誰も把握していないケースです。だから保守の初月にやるべき仕事は、コードを読むことより先に「どのアカウントが、どのトリガーの持ち主か」の棚卸しになります。ここを専用の運用アカウントに寄せておくと、人の出入りで F が跳ねなくなります。専用アカウントを1つ用意する費用は、執筆時点のGoogle Workspaceの通常価格でBusiness Starterが1ユーザーあたり月額800円（Google Workspace 料金ページ。キャンペーン価格は別途、価格は改定されることがあります）なので、保守費の変動を抑える手としては安いほうです。

トリガーが動かなくなった時に、まずどこを見るかはトリガーが動かない原因を6系統に分けて切り分ける手順で整理しています。

認可の再承認は「忘れた頃」に来る

Googleの OAuth 2.0 のドキュメントには、OAuth同意画面の公開ステータスが「テスト」のプロジェクトに発行されるリフレッシュトークンは7日で失効する、6か月使われなかったリフレッシュトークンは失効する、1つのクライアントIDにつき1Googleアカウントあたり100本までしか保持できないと書かれています（Google の OAuth 2.0 の使用）。

月1回しか動かない処理や、年度末だけ動く処理ほどここに引っかかります。「去年は動いたのに今年は認可を求められた」はほぼこれです。再承認は作業自体は数分ですが、権限を持つ人が誰で、管理者の許可が必要かどうかでかかる時間が桁で変わります。自分で直せる範囲かどうかの見分け方は承認できない原因を5系統に分けた整理のほうに書きました。

ランタイムとAPI世代の追従は、年単位で必ず来る

公式の移行ガイドによれば、互換性テストを通ったスクリプトのV8ランタイムへの自動移行は2020年2月18日に始まっており、旧Rhinoランタイムはマニフェスト上 DEPRECATED_ES5 として扱われます（V8 ランタイムへの移行）。終了日が公表されているわけではありませんが、「非推奨」と明示されているものに乗り続ける限り、いつかは移行工数が発生します。

同じことがAdvanced Services（高度なGoogleサービス）にも言えます。公式ドキュメントでは、これらは使う前に有効化が必要なサービスとして扱われ、サンプルも特定のAPIバージョンに紐づいています（Advanced Google services）。参照しているAPIの世代が上がれば、動いているコードのほうを合わせる必要があります。これらはすべて算式の F に入り、「使っている人が1人もいない月でも発生する」性質の工数です。保守を契約しない選択をすると、この追従だけが数年分まとまって請求される形になります。

3ケースの月額試算

算式に実際の数字を入れます。ここで使う時間単価は相場の提示ではなく、算式がどう動くかを見せるための仮の値です。自社の見積書の単価に差し替えて計算してください。発生率 C と復旧工数 D も、公表統計ではなく「この規模ならこのくらい」という仮定値です。

ケース1：トリガー2本・社内だけで使う通知

毎朝スプレッドシートを読んで、締切が近い行をチャットに流すだけの自動化。外部APIは使わず、止まっても人が目で見れば代替できる。

• A＝2、B＝0、C＝0.05、D＝1.5時間、E＝0.5時間、F＝0.3時間、G＝0.5時間
• 事故の期待工数 ＝ (2＋0) × 0.05 × 1.5 ＝ 0.15時間
• T ＝ 0.15 ＋ 0.5 ＋ 0.3 ＋ 0.5 ＝ 1.45時間／月
• 社内で半分持てる（H＝0.5）、仮単価 I＝8,000円、J＝0円
• 月額 ＝ 1.45 × 0.5 × 8,000 ＝ 5,800円（おおむね月1万円未満の帯）

この帯は、そもそも保守契約という単位にならないのが結論です。月1万円未満の作業に請求書と窓口を用意するコストのほうが大きいので、社内で持つか、止まった時だけ都度払いにするほうが合います。

ケース2：トリガー8本・外部APIとスプレッドシートの連携

フォーム受付から台帳への転記、外部SaaSのAPIからの日次取り込み、月次の集計と帳票出力までを1つのスクリプトで回している。業務部門から月に数回「項目を足して」が来る。

• A＝8、B＝3、C＝0.08、D＝2.5時間、E＝1.5時間、F＝0.8時間、G＝2.0時間
• 事故の期待工数 ＝ (8＋3) × 0.08 × 2.5 ＝ 2.2時間
• T ＝ 2.2 ＋ 1.5 ＋ 0.8 ＋ 2.0 ＝ 6.5時間／月
• 社内で2割持てる（H＝0.2）、仮単価 I＝10,000円、見張り料 J＝10,000円
• 月額 ＝ 6.5 × 0.8 × 10,000 ＋ 10,000 ＝ 62,000円（おおむね月5〜8万円の帯）

この帯で効くのは G（業務側の「ちょっと直して」）です。事故の期待工数2.2時間より、仕様変更の受け入れ2.0時間のほうが同じくらい大きいことに注目してください。見積の交渉で「障害対応は要らないから安くして」と言っても、この構成では月額はほとんど下がりません。

ケース3：トリガー20本・複数部署が使う基幹寄りの処理

受注・在庫・請求の一部がGASで繋がっており、止まると他部署の業務が止まる。連携先も複数あり、月締めの日付に合わせた処理が多い。

• A＝20、B＝6、C＝0.1、D＝3.0時間、E＝3.0時間、F＝1.5時間、G＝5.0時間
• 事故の期待工数 ＝ (20＋6) × 0.1 × 3.0 ＝ 7.8時間
• T ＝ 7.8 ＋ 3.0 ＋ 1.5 ＋ 5.0 ＝ 17.3時間／月
• 社内でほぼ持てない（H＝0.1）、仮単価 I＝12,000円、見張り料 J＝30,000円
• 月額 ＝ 17.3 × 0.9 × 12,000 ＋ 30,000 ＝ 約217,000円（おおむね月15〜25万円の帯）

この規模になると、トリガー上限が20本／ユーザー／スクリプトであることが設計上の壁として効いてきます。A＝20はもう天井で、次の自動化を足すにはスクリプトを分けるか、GASの外に出すかの判断が必要です。月20万円を保守に払い続ける前に、保守費の総額ではなく「この構成を続けるのか」を先に決めたほうが安いのが普通です。

保守を外に頼まないほうがいい4つの場合

正直に書くと、GASの保守を外注すべきでないケースははっきりあります。次の4つに当てはまるなら、保守契約を結ばないほうが合計の支出は小さくなります。

1. トリガーが1〜2本で、止まっても手作業で代替できる。ケース1のとおり、算式上の工数が月1〜2時間に収まる場合、月額の大半は窓口を維持する費用になります。止まった時だけ都度払いにしたほうが安いです。
2. 作った本人が社内にいて、これからも触り続ける（H が 0.8 以上）。この場合に外注で足せるのは第三者の点検だけで、算式の T はほとんど減りません。ただし「その人が辞めたら全部止まる」という形で F が跳ねるリスクが残るので、代わりにドキュメントとトリガーの持ち主の棚卸しだけを単発で依頼するのが合理的です。
3. その業務自体が半年以内に変わる／やめる予定がある。保守は「現状を保つ」ための費用なので、保つ対象が消える予定なら払い損になります。この場合は保守ではなく、新しい業務に合わせて作り直す前提で予算を取るべきです。
4. Google Workspace の標準機能やノーコードで置き換えられる。たとえば単純な転記や通知が、フォームの設定・スプレッドシートの関数・標準の通知ルールで済むなら、スクリプトを無くすのが最も安い保守です。保守費を下げる最強の手は、保守の対象を減らすことです。

逆に、ケース2・ケース3のように連携の口が複数あり、止まると他部署の業務が止まり、社内に読める人がいない場合は、外注しないという選択が一番高くつきます。止まってから探す場合、算式の D（1件の復旧工数）に「状況を把握するための調査時間」が丸ごと乗るためです。

見積書を受け取ったら確認する3点

「保守運用 月額◯円」の1行だけを見ても判断できません。算式のどこを指しているのかを、次の3点で確認してください。

• 何時間分なのか（T × (1−H) に相当する部分）。時間が書かれていない月額は、超過時の扱いも決まっていないことが多いです。
• 何が含まれないのか。特に G（業務側の仕様変更）と F（Googleの仕様変更への追従）は、含まれる・含まれないで金額が倍近く変わります。ランタイム移行のような数年に1回の工数が別請求なのかも確認してください。
• トリガーの持ち主を誰にするのか。外注先のアカウントで動かす場合、契約が切れた時点で自動化が止まります。自社の運用アカウントに寄せるところまでを初月の作業に入れてもらうのが安全です。

同じ「月額の数字だけでなく中身を確認する」という考え方は、ホームページの保守費用でも使えます。詳しくは制作会社の保守費用が高い｜契約書で見る4点で整理しています。

まとめ

GASの保守運用費は、月額の数字を他社と比べても判断できません。(A＋B) × C × D ＋ E ＋ F ＋ G で月間の工数を出し、× (1−H) × I ＋ J で金額にする、という順番で自分の数字を作るのが先です。そのうえで、トリガーが2本なら契約しない、口が複数あって社内に読める人がいないなら契約する、という判断になります。

手元に止まった履歴も、トリガーの持ち主の一覧も無い状態であれば、まずその棚卸しだけでも効果があります。算式の C と D が埋まれば、見積書の妥当性はその場で判断できるようになります。自動化の持ち方から整理したい場合は、下のお問い合わせからご相談ください。無理に契約をおすすめするより、社内で持てるならその形をお伝えするほうが結果的に良いと思っています。