「業務日誌、サービス提供記録、勤務表、請求書。全部 Excel でバラバラに運用していて、月末になると管理者が数時間張り付き。毎日の記録も、選択肢で済むはずの項目をひとつずつ手で打ち直している」
そんな現場、皆さんの周りにもありませんか？
今回ご紹介するのは、まさにその状態だった、ある福祉施設（生活介護事業所）の業務を、Google Apps Script（GAS）4 本でまるごと書き直した事例です。
正直に先に書いておくと、この約 3 週間が成立したのは、生成 AI（Claude / Claude Code）をフル活用したからです。 ヒアリング議事録を AI に読ませて仕様書のドラフトを起こさせる、その仕様書を AI と対話しながら磨き込む、確定した仕様を Claude Code に渡して GAS のコードを並列で生成させる——という回し方をしました。
1 人のフリーランスが 3 週間で 4 本の業務 GAS を納めるのは、5 年前の自分なら絶対に無理だったと断言できます。AI の使い方が変わると、フリーランスが取れる案件の規模が一段変わる、というのを今回の案件で身をもって感じました。
結論から言うと、毎日の業務日誌・サービス提供記録で 1 日あたり 10〜15 分短縮、月次の勤務表作成も 30 分 → 15 分に。請求書・領収書のワンクリック PDF 一括出力は、5 月の実請求業務で運用効果を検証予定です。
ただ、この記事で本当に伝えたいのは時短の話ではありません。
管理者が事務作業から解放された時間は、そのまま利用者支援の質につながっていきます。 時間を作ることは、支援の質を作ることと直結している。 福祉現場における自動化の本当の意味は、ここにあると私は思っています。
この記事では、その約 3 週間の構築プロセスを、AI とどう協働したかも含めてまとめます。
まずは自己紹介：医療現場の技師が、なぜ福祉施設の案件を？
私は診療放射線技師として 16 年、うち 14 年は3次救急を担う総合病院で働いてきました。今も技師として現場に立ちながら、医療現場のアプリ制作・AI 導入支援と Web 制作をしています。屋号は Arocode、肩書きは「医療 AI エンジニア／診療放射線技師」です。
普段の開発で使っている主な技術は、
- Python / Django：医療現場向けの業務アプリ（骨密度管理「BoneCare+」、放射線照射録「らくらく照射録」、リハビリ計画書作成アプリなど）
- Google Apps Script（GAS）/ JavaScript：今回の案件のような Sheets ベースの業務自動化
- HTML / CSS / WordPress（SWELL）：Web 制作案件
- Claude Code / Cursor：AI コーディング支援ツール。実装スピードと品質を底上げするために日常的に使用
- Ollama（gemma3）：ローカル LLM での試作・検証
このあたりが中心です。診療放射線技師として臨床現場にも今なお複数のクリニックで関わっており、「現場で動かない仕組みは作らない」を一つの基準にしています。
普段は医療現場の課題が仕事の中心です。
ただ今回は、知人からの紹介で「医療外の現場で困っている法人があるんだけど、相談に乗ってもらえないか」と声をかけていただきました。
最初は「お話を聞かせていただくだけでも」というスタンスでお伺いしました。
医療と福祉では、制度も書類のフォーマットも違います。
それでもヒアリングを重ねるうちに確信したのは、医療現場で培ってきた「業務を分解して、自動化できる箇所を見つける視点」は、福祉の現場でもそのまま使える、ということでした。
ここから先は、その施設で実際に何を作って、現場がどう変わったかを順番に書いていきます。
依頼の背景：勤務表を「1 マスずつコピー」で作っていた現場
理事長と話をさせていただいたあと、実際に勤務管理を担当されている方にも時間をいただいてヒアリングをしました。
聞けば聞くほど、管理の大変さが見えてきました。
なかでも一番衝撃だったのが、勤務表の作り方です。
この施設はもともと Microsoft Excel で全ての記録・帳票を管理していました。 小規模な施設には IT 専任の担当者がいないことが多く、Excel の使い方も独学です。 そのため、たとえば翌月の勤務表を作るときには、
- 1 マスずつ日付を移動させて
- その下のスタッフ配置を手でコピーして
- 休日や夜勤の色付けも手で塗り直して…
という作業を、毎月手でやっていたのです。
作業時間は 1 か月分でだいたい 30 分前後。
「30 分なら大した話じゃないのでは？」と思われるかもしれません。
ですが、コピペの一発ミスで配置がずれると修正にさらに時間がかかる作業を、毎月手でやり続けるのは地味に効きます。しかも勤務表だけでなく、業務日誌・サービス提供記録・請求書まで、似た構造の手作業が日常のあちこちに散らばっていました。
ヒアリングして初めて見えてきたのは、こういう「Excel の中で完結しているはずなのに、実は手作業だらけ」のポイントが、業務のあちこちに散らばっているということでした。
整理した状況は、ざっくりこんな感じです。
- 既存運用：Microsoft Excel ファイルが複数、月末は管理者が転記作業に張り付き
- 請求書：1 人ずつ手作業で印刷、送付
- スタッフ：IT に強い人はいないが、Excel には日常的に触れている
- 予算：新しい有料 SaaS は契約したくない。固定費を増やさず改善したい
「Excel で一応回っているけど、月末になると管理者が数時間張り付く。日々の記録も、選択肢で済むはずの項目を毎日手で打ち直している」状態。 これをなんとかしたい、というのが出発点でした。
ヒアリング議事録は、AI で仕様書に落とし込んだ
ここで、今回の案件で特に手応えのあった進め方を 1 つ書いておきます。
ヒアリングのときは、こちらは聞くことに集中したいので、メモは最小限の箇条書きにとどめ、現場の方が話してくださった内容は基本的に IC レコーダーで録音させていただきました（事前に許可をいただいています）。
そして帰ってから、文字起こしツールで音声をテキスト化し、その全文を Claude にそのまま渡して、
「この議事録から、業務フローと困りごとを項目ごとに整理して、それぞれの困りごとが GAS で解決可能かどうかを一次評価してほしい」
と投げました。
すると、自分が現場でメモしきれなかった発言まで AI が拾ってくれて、「業務日誌」「サービス提供記録」「勤務表」「請求書」の 4 領域に困りごとが自然と分かれていく流れが見えました。
ここから「じゃあ GAS 4 本構成で行こう」という方針が固まったわけですが、これを自分の頭の中だけでやろうとすると、たぶん 1 〜 2 日まるごと消えていたと思います。
AI に下処理をさせて、自分は「現場の温度感を読み解く」「優先度をつける」というところに時間を使えたのが大きかったです。
ヒアリングで一番大事なのは「現場の声を拾う」ことで、それを構造化するのは AI の得意分野です。役割分担をはっきりさせると、ヒアリングの精度と速度が両方上がります。
なぜ業務 SaaS ではなく GAS を選んだのか？ 3 つの理由
ここで当然、「業務 SaaS を導入したほうが早いのでは？」という選択肢もあります。福祉業界向けの業務 SaaS は複数存在します。
それでも今回 GAS を選んだのには、3 つの理由があります。
理由 1：現場の Excel 様式と運用フローを壊したくなかった
長年使い込まれた Excel ファイルには、現場の文脈（項目の並び、欄外のメモ、配色のルール）が詰まっています。 SaaS に乗り換えると、この資産が一旦リセットされ、業務を SaaS 側の様式に合わせ直すことになります。
GAS と Google Sheets の組み合わせなら、Excel 様式をほぼそのまま持ち込めます。 「現場の見た目をできるだけ変えない」という方針が取れたのが大きかったです。
理由 2：月額の固定費が乗らない
NPO・小規模法人にとって、毎月数万円の固定費は重いです。
GAS は無料の Google アカウントだけで動きます。新しい有料 SaaS は契約せず、追加課金もゼロで運用できます。
理由 3：「無料の範囲で完結させたい」という希望
この施設は、業務管理は Microsoft Excel、メールなどは無料の Google アカウント、という運用でした。Google 自体への抵抗感はなく、「ただし、新しい有料サービスは増やしたくない」という希望がはっきりありました。
GAS と Google Sheets は、まさにこの希望に素直に応えられる組み合わせです。 無料アカウントの範囲で完結し、ログインも 1 つで済みます。
詳しい判断軸はブログ記事「SaaS か GAS か、AI 時代の判断軸」にまとめていますが、要するに「現場の運用文化を壊さず、固定費を増やさない」という方針が決め手でした。
構築した 4 本の GAS アプリ
最終的に納品したのは、以下の GAS アプリ 4 本です。
Excel から Google Sheets に持ち込み、現場の作業を一つひとつ自動化に置き換えていきました。
実装前にやったこと：仕様書を AI と壁打ちして磨いた
コードを書き始める前に、もう 1 ステップ AI を挟みました。
先ほどのヒアリング整理から起こした仕様書のドラフトを、Claude に対して「このアプリを使う管理者の視点で、抜けや矛盾、想定外の入力を全部指摘してほしい」と投げます。 Claude は、
- 「設定シートに項目を追加したとき、本体シートの再生成は誰が／いつ実行するんですか？」
- 「利用者が月の途中で入所・退所した場合、請求の按分はどう扱いますか？」
- 「権限エラーで GAS が止まったとき、現場の管理者は何を見て復旧するんですか？」
といった、自分一人ではすぐに気づきにくい質問を返してきます。 そこに対して答えを書き、また仕様書を更新し、再度 Claude にレビューさせる。この壁打ちを 3 往復ほど回すと、仕様書の解像度が一段上がります。
この「AI を仕様書のレビュアーとして使う」やり方は、フリーランス案件において特に効きます。 クライアントが IT に詳しくない場合、「仕様の抜け」は納品後の追加対応として跳ね返ってくるからです。Claude にレビューしてもらった時点で潰しておけば、納品後のトラブルがぐっと減ります。
そうやって仕様が固まったうえで、ようやくコードに入ります。
全体の流れをざっくり図にすると、こんな構造になっています。
[毎日の記録]
業務日誌 GAS ──┐
サービス提供記録 GAS ──┤
│
▼
[月次の集計]
勤務表配置 GAS
│
▼
[月末の請求]
昼食費請求＋請求書／領収書 PDF 一括生成
│
▼
Google Drive に集約
（Excel・紙・メール添付 → 1 か所へ）毎日の入力 → 月次の集計 → 月末の請求 → Drive 集約、という流れが GAS 4 本でつながっています。 それぞれを順番に見ていきます。
1. 業務日誌 GAS
毎日の支援内容を記録して、月次まとめを自動生成する仕組みです。
ただ「Excel をそのまま Sheets にした」わけではありません。 現場で何を毎日記録しているかを全部洗い出して、それを入力しやすい形に作り変えるところに一番時間をかけました。
具体的には、
- 毎日記録する項目を全部リスト化し、いちいち手で打たなくて済むようにした
- 日付は自動入力
- 自動でできるところは全部自動化
- チェックボックスで済むところはチェックボックスに変更
「打つ手間」を一つずつ削った結果、現場の入力負担はかなり軽くなりました。
2. サービス提供記録 GAS
利用者ごとのサービス提供記録を、サイドバー UI から入力して PDF 出力する仕組みです。
このサービス提供記録は、施設を利用される方それぞれに対して、毎日 1 件ずつ記録する必要があります。 管理者がまとめて記入していたので、これだけで毎日 20〜30 分の作業になっていました。
ここに AI を組み込んだことで、所要時間は 3 分以内に短縮されました。
- Google Sheets のサイドバーに入力フォームを表示
- 行政提出用の書式に沿って出力
- AI を活用して、定型部分の文章生成を補助
- 利用者選択 → 毎日分の記録を一括 PDF 化
サイドバー UI を載せたのは、「Sheets の素のセル入力だと、どうしても入力ミスが増える」という現場の声があったからです。
3. 勤務表配置 GAS
4 本のなかで一番ロジックが重いのがこれです。 冒頭で書いた「1 マスずつコピー」の作業は、この GAS で完全に消えました。
- 職種ごとに配置パターンを統一／職員の入れ替わりにも対応
- シフトが増えても管理画面で柔軟に設定可能
- 出勤日数・出勤時間・常勤換算率を自動で算出（給与計算の元データもそのまま使える）
- 翌月の勤務表はワンクリックで自動生成
「翌月の勤務表を 1 マスずつコピーして 30 分かけて作る」という作業を、ワンクリック生成＋選択式の微調整に置き換えられたのがこの GAS のポイントです。納品後の現場からも「15 分程度の短縮ができている、慣れたらさらに短縮できそう」という声をいただいています。
4. 昼食費請求＋請求書／領収書 PDF 一括生成
利用者ごとの昼食提供回数を月別に集計し、入浴回数も加味して合計請求額を計算、最後に請求書 PDF を全員分まとめて生成する仕組みです。
- 利用者・職員の増減にも対応（マスタを更新するだけで OK）
- 請求書・領収書ともにワンクリックで PDF 出力 → そのまま印刷
毎月の運用フローはこうなりました。
① 月末：昼食請求一覧の入力完了
↓
② メニューから「請求管理シートを作成・更新」を実行
→ 昼食データが自動反映される
↓
③ 入浴回数を手入力（必要な人だけ）
↓
④「請求書を一括 PDF 出力」を実行
→ 全員分の PDF が Drive に保存 → 印刷して配布
↓
⑤ 入金確認後、領収日を手入力
↓
⑥「領収書を一括 PDF 出力」を実行
→ 領収日入力済みの人だけ PDF 生成 → 印刷して配布ここが、今回もっとも構造的な変化が大きかった部分です。 請求書を 1 人ずつ Excel テンプレに打ち込んで印刷、という毎月 30 分〜1 時間のルーチンを、ファイル統合とワンクリック PDF 出力に置き換えました。
一括印刷の実運用効果は 5 月の請求業務で検証予定ですが、納品時点で現場からは「同じファイルで管理できる」「日付や曜日が自動で出る」という、日常運用面での好感触をいただいています。
4 本すべてに通した共通設計：「項目はクライアント自身が増減できる」
4 本の GAS アプリを作るうえで、最初から強く意識した設計方針があります。
「項目をハードコーディングしない」ということです。
ヒアリングを重ねる中で、「これは納品後に必ず “項目を追加したい／変えたい” が出てくるな」と感じていました。
- 業務日誌で記録する活動内容や支援項目は、利用者や事業所方針の変化で増える
- サービス提供記録の項目は、行政の様式変更や事業所側のチェック観点の追加で変わる
- 勤務表のシフト区分・職員も、当然ながら入れ替わる
- 請求対象の品目（昼食・入浴など）も、サービス内容次第で増える可能性がある
ここで、開発者（私）がコードを書き直さないと項目が増やせない作りにしてしまうと、「ちょっとした 1 項目の追加で、毎回開発者に依頼 → 見積もり → 改修 → 検証」という流れになり、現場のスピード感が一気に落ちます。コストもかさみます。
そこで全 4 本に、「設定シート」を用意しました。
設定シート方式の中身
各アプリには、本体シートとは別に「設定」用のシートが同梱されています。
たとえば業務日誌 GAS の場合：
- 「設定」シートに、毎日の記録項目（例：朝の体調確認、昼食提供、入浴、レクリエーション…）が行ごとにリストアップされている
- 行を追加すれば、その項目が次回作成する業務日誌シートに自動で反映される
- 不要になった項目は、設定シートから消すか非表示にすれば、本体側にも出てこなくなる
つまり本体シートは「設定シートを読み込んで毎月生成される」構造になっていて、項目の増減はクライアントが Google Sheets を編集するだけで完結します。
サービス提供記録・勤務表・請求書（昼食メニュー、利用者マスタなど）も、同じ思想ですべて設定シート経由です。
なぜそこまでするのか
理由はシンプルで、「現場が一番、自分たちの業務の変化を知っているから」です。
開発者は、納品時点のスナップショットしか知りません。半年後・1 年後に「こういう項目を増やしたい」と思ったとき、いちいち外注しなければ動けない仕組みは、現場の業務改善のスピードを開発者の稼働に縛りつけてしまうことを意味します。
それは、私が今回の案件で目指したかった「自走できる現場」とは正反対です。
設定シート方式にしておけば、
- 軽い項目追加はクライアントが自分で完結
- どうしてもロジックを変えたい場合だけ、開発者に相談
という棲み分けができます。これは納品後の客先からも、サービス提供記録についていただいた「自分でも入力できるので自動作成だけではないところが良いです」という声と、同じ思想です。 「全部自動・全部開発者任せ」ではなく、「現場が触れる余地を残す」ことを、設計レベルから貫きました。
Before / After：何がどう変わったか
納品後のヒアリングで現場の方からうかがった、主観的な体感値ベースですが、こういう変化がありました。
※ 数字は管理者へのヒアリングでの体感値で、ストップウォッチでの実測値ではありません。施設規模や利用者数によって前後します。
体感としては、「1 件あたりは 10 分・15 分の短縮だけれど、毎日・全員分・全業務に効くので、月で見ると管理者の時間がまとめて戻ってきた」という言い方が一番近いと思います。
そして冒頭でも書いたとおり、これは単なる時短ではありません。 浮いた時間が、支援計画の見直しや利用者ご家族への対応に使えるようになる。 時間を作ることは、利用者支援の質を作ることと直結しています。
実際のお客様の声｜納品後、現場で運用していただいた感想
ここまでの数字は私の側から見た設計値・体感値です。 ですが、本当に意味があるのは使う側がどう感じているかです。
納品後、実際に毎日運用していただいている管理者の方から、各機能について感想をいただきました。現場の言葉そのままで掲載します。
① 昼食費請求＋請求書／領収書 PDF 一括生成
請求書・領収書を一括印刷できるようになった事の確認は 5 月請求の時になりますが、同じファイルで管理でき、また、日付や曜日もすぐに出るためとても使いやすくなりました。
請求書の一括印刷は月次運用の機能なので、効果実感はこれからとのことですが、「同じファイルで管理できる」「日付や曜日が自動で出る」という日常運用の部分で、すでに手応えを感じていただけているようです。
② サービス提供実績記録表
選択するだけで文章も作成してくれるため、15 分程度の大幅な時間短縮ができ、また、自分でも入力できるので自動作成だけではないところが良いです。
特に印象的だったのが、「自分でも入力できるので自動作成だけではないところが良い」というコメントでした。
AI 連携や自動化は「全部任せきり」になりがちですが、現場の方が「自分で書き換えたい時に書き換えられる」ことの安心感は、設計時に意識したとおりの形で機能しているようです。
③ 業務日誌
選択式なので 10 分程度の時間短縮となりました。
「打つ手間をチェックボックス・選択式に置き換える」という、地味だけど効く設計方針が、毎日 10 分の短縮として現場に届いていました。
④ 勤務表
選択していくため、作成時間も 15 分程度は短縮できているかと思います。今から 2 回目の作成なので、慣れてきたらさらに短縮できそうです。 日付も自動でしてくれるため使いやすいです。
こちらは「まだ 2 回目の作成」という段階での感想。慣れていただくにつれて、設計上の上限（ワンクリック自動生成）に近づいていくものと見ています。
全体を通して
全てにおいて時間も短縮され、短縮された時間を他の業務に回すことができるようになり、効率もよくなったように思っています‼
「短縮された時間を他の業務に回すことができる」——この一文が、今回の案件で私が一番届けたかった価値そのものでした。
冒頭で書いた「時間を作ることは、支援の質を作ることと直結している」という話は、抽象論ではなく、納品後の現場でちゃんと起きていることなんだと、このコメントをいただいて改めて確信しました。
「無料 Google アカウント＋ AI 連携、セキュリティは大丈夫？」とよく聞かれます
ここまで読んで、こう思った方もいるかもしれません。
「業務 SaaS じゃなく、無料の Google アカウントで運用？ しかも個人情報の入った記録に AI を使ってる？……それ、セキュリティ大丈夫なの？」
結論から言うと、設計と運用ルールを最初に決めておけば、十分実用レベルで運用できます。 ただし「適当に作ってもなんとかなる」とは絶対に言いません。 ここは案件を受ける前から決めておかないと、後で取り返しがつかなくなる部分です。
今回の案件で具体的に何をしたかを、無料 Google アカウントと AI 連携の 2 つに分けて整理しておきます。
① 無料 Google アカウントを業務利用するときの最低ライン
無料の Google アカウントは、もともと個人で使う前提の作りです。これを法人業務で使うなら、最低限以下を整える必要があります。
- 法人専用のアカウントを 1 つ作って、業務関連のシートはそこに集約する
- 2 段階認証は必須（電話番号 or 認証アプリ）
- パスワードは管理者で共有（個人のパスワードを混ぜない）
- 共有は特定のメールアドレスにだけ（「リンクを知っていれば誰でも閲覧」は絶対にしない）
- 退職者・異動者が出たら、共有設定を即座に見直す
特に 1 つめの「法人専用アカウント」は重要で、管理者個人のアカウントで作ってしまうと、その方が異動・退職した瞬間にデータが宙に浮きます。
なお、Google のサーバそのものは、通信・保存ともに暗号化されています。データの「外側のセキュリティ」は Google が担保してくれる前提で、「内側（誰にどう共有するか）」を運用ルールで縛るイメージです。
② サービス提供記録 GAS の AI 連携で気をつけたこと
サービス提供記録 GAS では、定型部分の文章生成補助に AI を使っています。 ただし、福祉現場の記録は個人情報そのものです。利用者のお名前、ご家族構成、健康状態などが含まれます。
そこで設計時に決めたルールが、ざっくり以下です。
- API 経由でのみ AI を呼ぶ（ChatGPT のチャット画面に直接貼り付ける運用は禁止）
- 利用する API は学習に使われない仕様のものを選定（主要な API はデフォルトで学習対象外）
- AI に送るプロンプトには氏名・住所・固有の医療情報を含めない（イニシャルやコードに置き換える）
- AI が返した文章はそのまま使わない。必ず管理者がチェックしてから保存する
「AI が便利だから全部任せる」ではなく、AI は下書き屋として使い、判断と固有情報は人間側に残すというのが原則です。
セキュリティの考え方の本質
正直に言うと、無料 Google アカウントだろうと有料の業務 SaaS だろうと、運用ルールが緩ければ事故は起きます。逆に、無料でも運用ルールが固ければ十分実用に耐えます。
「ツールが安全か」ではなく「運用が安全か」を見る視点が大事です。
実は、コードを書く前に勝負は決まっていた
実装が始まる前の段階で、強く感じたことがあります。
それは、「何を作るか」より「何で困っているかを正確に把握すること」が圧倒的に大事、ということです。
小規模な現場ほど、悩みが言語化されないまま「そういうものだ」として固定化されています。
- 翌月の勤務表は 1 マスずつコピーして作るもの
- 請求書は 1 人ずつ印刷するもの
- 月末は管理者が数時間張り付くもの
当事者からすると、それが変えられるという発想自体が出てこないのです。
なので私は、初回ヒアリングでは仕様の話より、
- 日々の業務で何が一番面倒か
- 月末に何時間溶けているか
- 「これは仕方ない」と諦めている作業はないか
を細かく聞き出すことに時間を使いました。
ここで漏らした不便は、納品後にも残ります。逆に、ここで一つでも多く拾えれば、それがそのまま納品物の価値になります。
「何が必要ですか？」と聞いても、現場からは答えが出てこないことがほとんどです。
「何で困っていますか？」を、しつこく細かく聞いていく。これが、今回の案件で一番効いた動き方でした。
そしてここが、現場経験のある人ほど圧倒的に強い領域です。 医療職、福祉職、教育、士業——どの業界でもそうですが、「現場で何年か実務をやった人」にしか分からない違和感や、業界特有の暗黙ルールが必ずあります。コードはあとから AI で書けますが、その違和感は、実務をした人でないとなかなか気づけません。 「Excel で月末に張り付くのが当たり前」という状態を、自分が当事者として味わったことがあるかどうか。
どう作ったか｜Claude Code で 4 本を並列開発、人間が現場目線で仕上げる
ここまでで一番気になっているのは、「3 週間で本当に GAS 4 本作れたの？」というところかもしれません。 正直に書きます。生成 AI、特に Claude Code がなければ無理でした。
逆に言えば、「全部を自分でゼロから実装できる人」である必要は、もうなくなっています。
私自身も、GAS の細かい API 仕様を全部暗記しているわけではありません。仕様の組み立て方と、AI に正しく渡すための整理の仕方さえ押さえておけば、コードの細部は AI が埋めてくれます。
Claude Code で「並列に走らせる」開発スタイル
今回の開発は、ターミナルから動かす AI コーディングツール「Claude Code」を中心に進めました。 これがなぜ強いかというと、
- 仕様書と既存コードをまるごと文脈として持たせられる
- 「この設定シート方式を踏襲して、勤務表配置 GAS を実装して」と書くと、思想を引き継いだコードを書いてくれる
- リポジトリ単位で扱えるので、4 本の GAS を頭の中で並列に進められる
の 3 点が大きいです。
具体的な進め方は、こんな感じでした。
- 仕様書（先ほど Claude と壁打ちして磨いたもの）を Claude Code に読み込ませる
- まず「業務日誌 GAS」の骨格を生成させて、自分の環境で動かす
- 動かしながら気づいた違和感をフィードバックして修正
- 骨格が固まったら、隣のターミナルで「サービス提供記録 GAS」の骨格生成を並行スタート
- 同様に「勤務表配置 GAS」「請求書 GAS」も、自分が片方をテストしている間にもう片方を生成
この「自分がレビュー・修正している間に、AI が別アプリのコードを書いている」という状態を作れるのが、Claude Code を使う最大の旨みです。 人間の作業と AI の作業が、シリアル（直列）ではなくパラレル（並列）になるので、体感の開発速度が 2〜3 倍くらいに変わります。
AI に任せたところ／人間が必ずやったところ
ただし、何でも AI 任せにしたわけではありません。線引きはかなり意識しました。
AI（Claude Code）に任せたのは、
- 既存仕様に沿った関数の骨格生成
- 似た構造のコードの量産（4 本の GAS で似ているパターンの実装）
- ユニットテスト相当の動作確認シナリオの提案
- エラーメッセージや UI 文言の日本語化
逆に、自分の手で必ずやったのは、
- 仕様の最終確定（現場の温度感は AI には判断できない）
- 個人情報を扱う箇所のロジック・ログ設計
- 設定シート方式の思想がブレていないかのレビュー
- 納めたコードを 1 行ずつ読み返す最終チェック（変数名・関数名が現場の用語と噛み合っているか、ハードコーディングが紛れ込んでいないか、権限エラーや空セル・想定外の入力に耐えるか、個人情報を扱う箇所で余計な情報をログや一時変数に残していないか）
AI が出すコードは「だいたい動く」までは恐ろしく早いです。 ですが、「現場で 1 年運用しても破綻しない」状態に持っていくには、結局のところ人間側の読み返しと書き直しが必要になります。
なぜこの話を強調するか
「AI を使った制作」というだけで身構える方は、まだ一定数いらっしゃいます。「AI が書いたコードを納めるなんて、品質的に大丈夫なのか」という疑問は当然です。
私のスタンスははっきりしていて、AI は実装スピードを上げるための道具であって、品質責任を肩代わりしてくれる存在ではない、ということです。 診療放射線技師として 16 年、患者さんの画像を撮ってきた身としては、「最終チェックは必ず人間の目で」というのは染み付いた習慣です。 AI を使うかどうかの議論より、「AI が出したものをどう人間が責任を持って仕上げるか」のほうが、これからのフリーランスにとって 100 倍大事だと思っています。
逆に言うと、ここを押さえてしまえば、AI を使うことで個人が請けられる案件の規模は明確に上がります。 今回 3 週間で 4 本納められたのが、その一番分かりやすい証拠です。
納品して終わりじゃない｜マニュアルとサポートの話
GAS を納めると、必ず質問が来ます。
- 「ボタンが反応しない」
- 「PDF がどこに保存されたか分からない」
- 「メニューが消えた」（権限の再認証が必要なだけ、というケースが多い）
事前テストで問題ないのが理想ですが、こうした問い合わせは、実運用が始まってから出てきます。ゼロにはなりません。
なので私は、「何かあったら聞いてください」と必ず伝えるようにしています。
ただ正直なところ、サポート連絡が増えすぎるとフリーランスの稼働は簡単に圧迫されます。 そこで必須になるのが、納品時のマニュアル整備です。
私はマニュアルを Google Docs（あるいは PDF）で 1 本作って、納品物と同じ Drive フォルダに置くようにしています。 スクリーンショット付きで、操作手順とトラブルシュート（権限再認証の方法、データのバックアップ方法など）まで含めると、サポート問い合わせは目に見えて減ります。
ちなみに、このマニュアルのドラフトも Claude に書かせています。 「このコードを、IT に詳しくない福祉施設の管理者向けに、操作マニュアルとしてまとめてほしい。専門用語は使わないこと」 と投げると、章立てから操作手順まで一気にドラフトが出てきます。あとは現場で実際に使っていただく方の表情を思い浮かべながら、言い回しと例示を直していくだけ。マニュアル作成の所要時間は、AI 導入前と比べて 1/3 以下になりました。
「ヒアリングで悩みを拾い切る → 作って納める → マニュアルで支える → 何かあれば対応する」。
このサイクルが回れば、案件は次の紹介を呼びます。実際、今回の案件もそうやって続いています。
まとめ：今回の事例から伝えたい 3 つのこと
長くなったので、最後に箇条書きで整理しておきます。
① 福祉・小規模法人の業務は、GAS で十分自動化できる
業務 SaaS に乗り換えなくても、無料の Google アカウントの範囲内で十分業務改善は可能です。 「Excel で何とか回っているけど、月末は誰かが数時間張り付き、日々の記録も手打ちで時間を取られている」現場には特に効きます。
② 何を作るかより、何で困っているかを聞き出すほうが大事
小規模な現場ほど、悩みが言語化されないまま放置されています。 ヒアリングは仕様より「諦めている作業」を聞き出すことに時間を使うのがおすすめです。
③ 納品後のマニュアル整備も、納品物の一部
サポート連絡を減らすためのマニュアル整備は、もはや納品物の一部だと考えています。
おわりに：「うちもできないか？」と感じた方へ
「Excel で何とか回っているけど、月末になると誰かが数時間張り付いている」
このパターンは、福祉に限らず NPO・小規模法人・士業・教室系などでもよく見かけます。
GAS は地味な技術ですが、こういう「あと一歩で自動化できるのに、Excel のままだから手作業が残っている」業務を、低コストでつなぎ直すのに向いています。
「うちの現場でも同じことができないか？」と感じた方は、お問い合わせからお気軽にご相談ください。規模感に応じて、構築やツール選定のご相談に乗ります。
医療現場のアプリ制作・AI 導入支援が中心ですが、今回のように医療外の小規模法人のご相談も、紹介経由で受けています。
最後まで読んでいただき、ありがとうございました。
