「作ってほしい。けど毎月の固定費は厳しい」
今回の案件、最初に施設の管理職の方とお会いしたとき、こちらが「業務改善のツールのようなものを作れます」と切り出した瞬間、開口一番こう言われました。
私が反射的に「あ、ではサブスクではなく……」と返すと、
「そう。1 回きり、最初に作ってもらって、その分の対価はちゃんと払う。あとで変更が必要になったら、その都度払って直してもらえばいい。毎月いくらか引かれ続けるのは、厳しい」
——と、はっきり言われました。
この一言で、今回の技術選定の方向性は 8 割決まったと言ってもいいくらいです。 月額固定費に対する小規模法人の警戒感は、想像以上に強い。そしてこの感覚は、福祉に限らず NPO・士業・教室系・小規模クリニックなど、SMB 全般に共通しています。
はじめに
制作実績「福祉施設の業務を GAS 4 本で自動化」では、この施設の業務(業務日誌、サービス提供記録、勤務表、昼食費の請求書)を GAS 4 本でまるごと自動化し、Claude Code で並列開発しながら約 3 週間で納品した話を書きました。
そのなかで「なぜ業務 SaaS ではなく GAS を選んだのか?」と書いた部分について、今回はもう少し深掘りします。
「業務効率化といえば SaaS」というのが、ここ数年のスタンダードでした。それでも今回あえて GAS を選んだ判断の中身を、AI が前提になった今だからこそ見えてきた視点 と合わせて整理しておきます。
大前提:AI で「選定の土俵」そのものが変わった
数年前までの選択肢は、ざっくり「既製の SaaS を契約して業務をそれに合わせる」か「それなりの予算でフルスクラッチを発注する」かの二択でした。小規模法人がフルスクラッチを持つのはコスト的に非現実的で、現場は SaaS か Excel のままかしか選べなかった。
生成 AI(Claude / Claude Code)が実用レベルに入ってから、ここが変わりました。 「現場の運用にそのまま乗る小さなカスタム実装を、現実的なコストで持てる」 ようになったんです。
その事例で言えば、1 人のフリーランスが約 3 週間で GAS を 4 本納めるのは、3 年前ならまず無理でした。
AI が仕様レビュー・コード生成・マニュアル作成まで肩代わりしてくれるからこそ、見積もりが SaaS と勝負できるレンジに入ってきた。
SaaS か GAS かを考える土俵そのものが、AI 以前と以後で違うんです。
前提:SaaS と GAS の違い(ざっくり整理)
スマホでも読みやすいよう、最も効く 4 点に絞ります。
このマトリクスを念頭に、今回 GAS を選んだ理由を 3 つ挙げます。
理由 1:現場の Excel 資産・運用フローを壊さなかった
最大の理由はこれです。
小規模な福祉施設には、長年使い込まれた Excel ファイル群があります。
帳票の様式、配色、項目の並び順、欄外のメモ書き——どれもが「現場の文脈」を含んだ資産です。
SaaS に乗り換えると、この資産は一旦リセットされます。
「これまでの 10 年の運用、何だったの?」という気持ちが現場に生まれやすい。
GAS + Google Sheets であれば、既存の Excel 様式をほぼそのまま持ち込めます。
今回も、納品物のシート見た目は既存 Excel と「ほぼ同じ」です。
違うのは、月末に走る処理が手作業から GAS に変わっただけ。 現場のスタッフからすれば、「いつもの帳票がそのまま、ただラクに動くようになった」 という体験になります。
さらに AI 時代の今、「既存 Excel を AI に読み込ませて、それに合わせた GAS を生成する」流れが現実的になっています。
様式を尊重したまま実装する、その再現コストが以前より大きく下がっているのも追い風です。
理由 2:月額の固定費が乗らない
NPO・小規模法人にとって、毎月数万円の固定費は重いです。
業務 SaaS はおおむね「ユーザー数 × 月額」の課金です。
スタッフ 10 人なら数千円 × 10 = 月数万円、5 年で 100 万円超になることもあります。
今回の施設は管理者 1 名がすべて入力を担当する運用だったので、SaaS を入れても 1 ユーザー分の課金で済むケースでした。
それでも、月数千円が 5 年続けば 20 万円前後。「永続的に発生する固定費」という構造そのものへの抵抗感は、規模に関係なく強いものでした。
これに対して GAS は、無料の Google アカウントの範囲内で動きます。追加課金はゼロ。
「初期に開発委託費は払うが、その後は固定費が乗らない」という構造は、長期で見れば SaaS より安く収まります。
特に「補助金次第で運営方針が変わる」「数年先の見通しが立てづらい」フェーズの法人にとって、月額固定費の有無は経営判断に直結します。
ここでも AI 効果が効いていて、初期開発費そのものが従来比で大きく下がりました。
昔は「SaaS のほうが安いに決まっている」だった構図が、今は「初期費を 1〜2 年でペイできるなら、月額ゼロの GAS のほうが 5 年トータルで安い」という比較に変わっています。
理由 3:「Google の中で完結させたい」という現場の希望
この施設は、業務管理は Microsoft Excel、メールなどは無料の Google アカウント、という運用でした。
そのうえで「新しいサービスを増やすのではなく、できるだけ今使っている Google の中で完結させたい」という希望がはっきりありました。
GAS は Google の中でそのまま動きます。新しいアカウントもパスワードも増えません。 データは法人自身の Google Drive に置かれ、管理者が変わっても引き継ぎが楽です。
「ベンダーロックインを避けたい」と言うと堅苦しいですが、要するに 「自分たちの手の届く範囲で完結させたい」 ということ。
AI 時代の文脈で補足すると、コードとシートが自分の Drive にあるということは、ベンダーが消えても AI に読み込ませて引き継げる ということでもあります。「自分のデータと、自分のコードを、自分で持っている」安心感は、AI 時代だからこそ価値が上がっています。
逆に「SaaS のほうが向く」パターン
ここまで GAS 推しに見える書き方をしましたが、SaaS が圧倒的に向く場面ももちろんあります。
今回の話を「いつでも GAS が正解」と読まれてしまうと、それはそれで違います。
- 法令対応が頻繁に発生する業務:法改正への追従が必要なものは、ベンダーが追従してくれる SaaS のほうが安全
- 業界標準の帳票・連携が必須:レセプト、請求書 EDI、行政への電子提出データなど、フォーマットが厳密に決まっているものは SaaS
- 多拠点・多人数で同時編集が常態化:規模が大きいほど SaaS の権限管理・同時編集が効く
- 担当者の入れ替わりが頻繁:SaaS のサポート窓口があるほうが引き継ぎコストは低い
逆に、単一拠点／少人数(〜30 人)／既存 Excel 運用が固まっている／月額固定費を増やせない／法令追従の頻度が少ない、という条件が揃うなら、GAS は十分現実的な選択肢です。
今回の福祉施設は、後者にきれいに当てはまっていました。
だから「GAS」と即決できたわけです。
ちなみに:Excel VBA は最初から候補に入れませんでした
「既存 Excel を活かすなら、いっそ VBA で作ればいいのでは?」と聞かれることがあります。たしかに Excel をそのまま使える点では素直な選択肢です。
実は今回も、設計を始める前にいったん Claude Code に 「この施設の業務、Excel VBA とスプレッドシート GAS のどちらで作るのが良いか?」 と相談しました。
返ってきた答えは、根拠付きで 「圧倒的に GAS が良い」。
自分も納得したので、そのまま GAS で進めました。
その「圧倒的に GAS が良い」の中身を 3 つに絞って書いておきます。
① 複数人で同時に編集できる ／ オンラインで直接修正できる
これがいちばん大きいと感じています。
Google Sheets は最初からクラウドで動くので、現場の管理者と私が 同じ画面を同時に見ながら相談する ことができます。
それより大事なのが、納品後の 「ちょっとここを直してほしい」への対応 です。 VBA だと、ブック自体を送り返してもらって、こちらで開いて修正して、また送り返して……と、毎回ファイルが行ったり来たりします。
バージョンの食い違いも起きやすい。
GAS なら、こちらが現場に行けないタイミングでも オンライン上でコードを直して、その場で本番に反映 できます。
緊急で直したいときに、お互い移動も発送も待たなくていい。
これはクライアントにとっても、私にとっても、地味にものすごく助かるポイントです。
もちろん、その分セキュリティ(共有相手の管理・二段階認証など)はしっかり締める必要があります。ここは制作実績のページで書いた運用ルールで対応できます。
② AI コーディング支援との相性
これはAI時代ならではの理由です。
今回の開発では Claude Code をフル活用していますが、Claude Code や Cursor のようなAI支援ツールは、JavaScript系のコードを比較的得意としており、GASはその恩恵を受けやすいです。
VBAでも実装は可能ですが、現場で1年運用に耐える品質まで仕上げるには、GASより工数が増えやすいと感じています。
先に書いた「AIで開発コストが下がった」というメリットを、いちばん素直に受け取りやすいのが GAS、という言い方もできます。
③ 正直に書くと、自分が過去に VBA でうまく作れなかった
これは技術論というより、個人的な経験談です。
実は過去に一度、似たような業務改善で自分で VBA を試したことがあります。結果、何度修正しても、自分が思うような形にはなりませんでした。
一番大きい理由は、はっきり言って 自分に VBA の理解が足りなかった ことです。
ただ、その経験から強く思っているのは、自分が深く分かっていない言語で、お客様の業務に何年も乗る仕組みを作るのは怖い ということ。
バグが出ても直しきれない、修正にも時間がかかる、というのは、納品する側として誠実ではないと感じます。
自分が日常的に触れていて、AI 支援も最大限に効く GAS で作るほうが、結果的に クライアントへの責任の取り方として一番フェア だと判断しました。
おまけ:実は私も、GAS の専業ではありません
ここまで「GAS で作りました」と書いてきましたが、正直に書くと、私自身、もともと GAS / Google Sheets の開発を主軸にしてきたわけではありません。
普段の本業は Python / Django で医療系アプリを作ることが中心で、GAS は過去に数回触ったことがある程度 でした。
それでも今回、約 3 週間で 4 本の業務 GAS を納めきれたのは、Claude Code がコードの細部を全部引き受けてくれたから です。
自分の役割は、現場の業務を分解して「ここをこういう形で動かしてほしい」と AI に渡すところまで。GAS の細かい流儀やお作法は、AI 側がきれいに補ってくれます。
これは、私がいつも書いている 「AI × 現場経験」 の話そのものです。
「自分は GAS や JavaScript が書けないから、こういう案件は無理」と思っている方こそ、実は今いちばん追い風が吹いている側だと思います。現場で何年も実務を積んできた感覚と、AI の実装力を組み合わせれば、コード経験が浅くても案件として十分成立する——それを、今回の私自身の経験が証明してくれました。
ただし、誤解されると困るので一つだけ書いておきます。
「AI に丸投げすればコード経験ゼロでも作れる」という話ではありません。
最低限の基礎(GAS なら「シートの読み書き」「関数の書き方」「権限の概念」あたり)は、自分でもざっくり押さえておく必要があります。
そして、AI が出してきたコードは 100% 信じず、必ず自分で読んで確認する。ここは外せません。
逆にこの工程を「仕事をしながら自分の勉強にもなる一石二鳥の時間」と捉えると、すごく楽しい時間になります。
実際、今回の案件で私自身、GAS まわりの理解は一気に深まりました。
ただ、相手はお客様で、これはお仕事です。「AI が書いたものなので」では済まされません。現場で 1 年回しても破綻しないものを納めるための努力 は、AI を使う／使わないに関係なく必要——そこは絶対に手を抜かない、というのが私のスタンスです。
「Excel を活かす」という目的そのものは、GAS + Google Sheets でも十分達成できます。あえてプラットフォームごと Microsoft 側に閉じる必然性は、今回はありませんでした。
さらにその先:医療現場では「院内ローカル LLM」という第 3 の選択肢
ここまで SaaS vs GAS の話をしてきましたが、医療・福祉でも個人情報の機微度が一段上がる現場では、そもそも外部にデータを出さない「院内ローカル LLM 運用」 という第 3 の選択肢があります。
クラウドにすらデータを出さず、院内ネットワークの中だけで AI を回す構成です。電子カルテと同じ「外に出ない」前提で運用できるので、患者の個人情報を扱う書類業務に向きます。
ただし、サーバ準備・モデル選定・運用ルールの設計など、SaaS や GAS とは別の専門性が必要です。
詳しくは別記事で書きます ので、ここでは「医療現場では第 3 の選択肢としてアリ」とだけ覚えておいてください。
判断軸の整理:AI 時代版
私が新規案件で「SaaS か GAS か」を考えるときの判断軸は、ざっくりこの順番です。
- 法令追従が必要な業務か? → Yes なら SaaS
- 業界標準フォーマットの厳格運用が必要か? → Yes なら SaaS
- 拠点・人数の規模は? → 大きいなら SaaS
- 既存 Excel 資産の量は? → 多いなら GAS が有利
- 月額固定費を増やせるか? → No なら GAS が有利
- 現場の IT リテラシーは? → 低いなら「見た目を変えない」GAS が有利
- 現場の業務変更が頻繁か? → Yes なら GAS(+ AI で即日改修)が有利 ← AI 時代に追加した軸
今回の福祉施設は、1〜3 のいずれにも当てはまらず、4〜7 がすべて GAS 寄りでした。 だから「迷わず GAS」になりました。
まとめ
- SaaS と GAS は対立構造ではなく、判断軸ごとに使い分けるもの
- 法令追従・業界標準・規模感が必要なら SaaS、それ以外なら GAS が現実的
- AI が前提になった今、「現場の仕様をそのまま形にできる」「初期費もペイしやすい」「改修も即日」 という GAS の弱点だった部分が一気に強みに変わってきている
- 今回の案件では「Excel 資産を残せる」「月額固定費が乗らない」「Google 内で完結できる」の 3 つで GAS を選んだ
AI 時代の本当の価値は「現場をどれだけ知っているか」 にあります。
SaaS か GAS かという技術選定も、結局は「現場で何が起きているか」を正確に掴めているかで答えが変わる。
スペック比較より、現場の言葉を聞き切ることのほうが何倍も効きます。
もし「うちは SaaS と GAS、どっちが向いているかな?」と気になった方がいれば、お問い合わせからお気軽にご相談ください。
