GAS副業の始め方｜実行アカウント・納品テストと保守の決め方

※本記事にはPRを含む場合があります。

こんにちは。『脱会社員』脱サラを応援し続けるブログ、運営者の『なかびー』です。

GASで自分の日々の集計を楽にできると、「この作業を副業として引き受けられるかな」と考えますよね。Google Apps Scriptを使う仕事では、コードを書く力に加えて、依頼者のアカウントで動き、担当者が変わっても運用を続けられる状態を渡す力が必要です。

自分の画面で成功した処理でも、納品先では承認が必要だったり、自動実行が制作者のアカウントに残ったりします。集計結果が正しいことと、その後も安心して使えることを、受注前から一緒に考えておきましょう。

この記事では、架空の日報集計を例に、最初の案件の範囲、見本の作り方、所有者と実行者の違い、顧客側の試運転、障害時の連絡、保守の区切りを整理します。実在する依頼や稼働実績を紹介するものではありません。例の数値は説明用で、読者の環境で動作を保証するコードや自動化ツールの提供も行っていません。

GAS副業の最初の案件は、日報集計のどこまでを受けるか決める

GASは、Googleのサービスを使う作業をまとめたり、繰り返し処理を自動化したりするための選択肢です。ただし、依頼者が欲しいものは「GASを使った仕組み」とは限りません。毎週の集計を短くしたい、転記ミスを減らしたいなど、困りごとから聞くと必要な範囲が見えてきます。

自動化したい作業を、入力・判断・出力に分ける

ここでは、架空の小さな制作チームが記入する日報を考えます。日報には受付ID、作業日、作業区分、件数があり、担当者は前日分の区分別合計を確認します。顧客名、連絡先、売上、健康情報は入れない設定です。最初の見本は、架空データだけを使って作れます。

入力は日報の行、判断は「対象日が一致するか」「必要な項目がそろっているか」「受付IDが重複していないか」、出力は集計表です。この三つを文章にできれば、何を実装し、何を依頼者に確認してもらうかが具体的になります。入力側が自由記述だらけなら、その整理が先になることもあります。

「日報を便利にする」という相談に、メール送信、承認、請求書、顧客管理までまとめて提案すると、確認先と失敗時の影響が増えます。初回は集計表の更新までに区切り、通知を加える場合は、その必要性と宛先の決め方を別に確認しましょう。

※表は横にスクロールできます。

表の右端が埋まらないまま、機能数だけで価格を決めないことが大切です。たとえば同じ「転記」でも、転記先の一部を更新するのか、毎回すべて置き換えるのかで、必要な確認と復旧の方法が違います。依頼者が普段手で判断している部分も、聞き取りの対象に入れます。

関数や標準機能で足りる部分を先に見極める

集計結果を常に表示したいだけなら、スプレッドシートの関数やピボットテーブルで目的を満たせる場合があります。処理の実行記録を残したい、特定の時点で値を確定したいなど、GASが必要になる理由を一つずつ説明できるようにしましょう。使わない機能を減らすと、引継ぎも簡単になります。

依頼者がExcel中心で業務を進めている場合は、Google環境へ移すこと自体が負担になるかもしれません。Excel VBA副業の記事ではExcelの版やマクロの利用条件を扱っています。普段使う環境と納品先の条件に合わせて、担当できる仕事を選んでください。

初回に背負う業務上の影響を小さくする

売上確定、給与計算、決済、重要な対外連絡などは、少しの誤りでも影響が大きくなります。経験が浅い段階では、担当者が結果を確認してから次へ進められる補助的な処理を候補にします。日報集計でも、集計結果がそのまま請求に使われるなら、単なる一覧表として扱わず確認工程を増やす必要があります。

引き受ける前には、依頼者が入力を整える担当者と、完成を判断する担当者を用意できるかも確かめます。正解を判断する人がいない案件では、コードが動いても合否が決まりません。判断基準を決める時間を仕事の範囲に含めるか、条件が整ってから制作するかを相談しましょう。

架空の日報で、結果と限界を説明できる見本を作る

GASの副業用ポートフォリオは、機能の多さだけで評価しようとすると説明が長くなります。一つの日報集計について、どんな入力を受け取り、どう確認し、どこへ結果を出すかをそろえたほうが、依頼者は自社の業務と比べやすくなります。見本では、成功するデータと止まるデータの両方を用意します。

三つの行から、正解を先に決める

架空の日報に、受付ID「R001」は作業Aが3件、「R002」は作業Aが4件、「R003」は作業Bが2件と入れます。作業日はすべて同じ日とします。このとき期待する結果は、作業Aが7件、作業Bが2件、合計9件、集計した受付IDが3件です。コードを書く前に、この答えを手で計算して控えます。

同じR002の行がもう一度届いたときは、内容も同一なら集計済みの同一受付として一度だけ数える、というルールを例として採用します。入力は4行でも、採用する受付IDは3件、合計は9件のままです。元の件数だけを見ると重複の見落としに気づきにくいので、入力行数と採用件数を分けて表示します。

一方、R002の件数が4と5に分かれていたら、同じIDの内容が食い違っています。どちらが正しいかをコードに推測させず、その回の集計更新を止めて担当者へ確認する設計にします。「重複は削除する」とだけ書くと、訂正まで消してしまうため、同一内容と不一致の扱いを分けるのがポイントです。

入力の約束と、変更してよい場所を説明する

列の見出し、作業日の書き方、作業区分の選択肢、件数に使える値を一覧にします。「件数は0以上の整数」「作業区分はAまたはB」など、受け付ける条件が決まれば、文字や負の数が入ったときの対応も決められます。日付に時刻を含めるなら、どの地域の一日として区切るかも必要です。

利用者が変更できる設定と、変更時に相談してほしい設定は分けましょう。対象日の指定は担当者が変更できても、列名や集計先シート名の変更には調整が必要かもしれません。すべてを編集禁止にするのではなく、業務で日常的に変わる項目を先に聞き、運用しやすい形を考えます。

見本では、入力用・集計結果用・確認用の領域を分けると説明しやすくなります。入力用の元データを自動処理で消さずに残し、確認用には入力行数、採用件数、重複件数、対象日、実行結果を表示する想定です。画面を整える前に、数字の意味を短い説明で添えてください。

• 目的：前日分の日報を作業区分ごとに集計する
• 対象：指定した入力表と、承認された集計結果の範囲
• 対象外：給与・請求の確定、外部への送信、元データの自動削除
• 結果の確認：手計算した合計と採用件数を照合する
• 利用者の操作：対象日を選び、内容を確認して集計を実行する

動作の動画だけでなく、失敗の説明を添える

短い動画や画面例を作るなら、実行ボタンを押して表が変わるところだけで終えず、集計対象と結果を確認する場面を入れます。エラーがある入力では更新を止め、何を直すべきかが分かる説明も示します。エラーを隠して成功したように見せると、受注後の期待がずれてしまいます。

自分の開発用アカウントで確認した結果は、その環境での結果として記録します。依頼者のGoogle Workspaceの制限、共有設定、他の処理の利用状況まで確認済みとは書けません。見本の末尾に、確認したデータ件数と実行方法、未確認の条件を添えると、仕事で追加検証する範囲が伝わります。

生成AIを補助にして作ったコードでも、入力の判定、書込み先、利用する権限、失敗時の挙動は制作者が説明する必要があります。出力された内容を理解できない部分は、そのまま顧客の環境で試さず、架空データで仕組みを学び直してください。実データや認証情報を、許可なく外部のAIサービスへ送らないことも大切です。

見本の構成や公開範囲を整理する際は、ポートフォリオの作り方も参考になります。顧客の画面や案件名を出さなくても、目的、制約、確認方法を説明することで、自分が担当できる範囲を示せます。

所有者・実行者・編集者・通知先を、納品前に分けて確認する

GASの受渡しで特に確認したいのが、アカウントの役割です。ファイルを持つ人、コードを変更する人、処理に権限を使う人、異常を受け取る人が、いつも同じとは限りません。納品前に四つを分けて書き出すと、制作者が抜けたあとに何が残るかを確認できます。

顧客が管理するファイルを納品先にする

たとえば顧客側が管理するスプレッドシートを納品先にし、必要な範囲だけ制作者に編集権限を与える方法を検討します。最初から納品先の管理主体を決めておけば、個人アカウントで作ったものを後から移す前提にせずに済みます。利用できる共有方法は、顧客の管理者や組織の規則に確認してください。

スプレッドシートに紐づいたコンテナバインド型のスクリプトは、親ファイルと所有者・閲覧者・編集者の一覧を共有します。Googleのコンテナバインド型スクリプトの説明でも、この関係が示されています。表への編集権限を与える際は、紐づくコードも編集できることを踏まえて対象者を決めます。

「みんなが入力する表だから、全員に同じ編集権限でよい」と単純に考えないことも大切です。自動処理の内容を変えられる人を絞りたいなら、入力方法やプロジェクトの構成から見直します。スクリプトの置き場所だけでなく、誰が何を変えられるかを顧客の管理方針と合わせましょう。

※表は横にスクロールできます。

インストール型トリガーは作成者の権限で動く

手動実行と自動実行では、権限を使う人を別に確認します。GoogleのGoogleサービスへの承認に関する説明では、エディタなどから実行するスクリプトと、インストール型トリガー、ウェブアプリで実行主体が異なることが整理されています。ファイルの所有者だけを見ても、実際に誰の権限で動くかは決まりません。

インストール型トリガーは、作成したユーザーのアカウントで動きます。また、他のアカウントが設置したトリガーを自分の一覧から確認することはできません。Google公式のインストール型トリガーの説明にある重要な点です。制作者が設定した自動実行を残したまま、ファイルを共有して納品終了にしないようにします。

今回の例では、試運転の段階までは手動で集計し、定期実行が必要と判断された後に、顧客側の承認された担当者が設定する計画にします。その前に、制作者が試験用に作った自動実行が残っていないか、作成者本人の側でも確認します。別の人の画面が空だからといって、全トリガーがないとは判断できません。

担当者が異動する場合も、ファイルの管理者変更と実行担当の変更を別の作業として扱います。後任が必要なデータへアクセスできるか、承認を確認できるか、自動実行を引き継ぐ方法が決まっているかを調べます。共有パスワードを渡す方法で担当交代を済ませず、組織が認めたアカウント運用に沿って進めましょう。

OAuthの承認は、何を許可するのか説明する

OAuthのスコープは、アプリが利用を求めるアクセス範囲です。顧客には、使うサービス、読み取る情報、書き込む先を説明し、要求される権限と仕事内容を照合してもらいます。日報の集計しか依頼されていないのに、説明できないサービスへの権限が出るなら、そのまま進めずコードと設定を確認します。

Googleは承認スコープの説明で、必要最小限の権限を使うことを求めています。対応するサービスでは現在の文書に範囲を絞る方法もありますが、すべての処理を一つの注釈だけで制限できるわけではありません。実装に必要なアクセス範囲を確認し、過不足のない設定を選びます。

また、納品後の改修で新しいサービスを使うようになると、追加の承認が必要になる場合があります。変更内容と増える権限を説明し、顧客側で確認する時間を予定に入れましょう。動かなくなったからといって、必要性を確認せず広い権限を追加する方法は避けます。

共有ドライブを利用できる環境では、ファイルを組織で管理しやすくなります。ただし、トリガーまで自動的に共有されるわけではありません。関連するGoogle Cloudプロジェクトにも別の権限があるため、利用している場合は管理者を確認します。詳しくはGoogleの共同編集の案内を照合してください。

社外公開のウェブアプリは、この日報集計とは分けて検討しましょう。ウェブアプリの公式説明では、デプロイ時の設定によって実行主体が変わります。誰がURLへアクセスでき、誰の権限で処理するかを設計する必要があり、「URLを渡せば使える機能」を気軽に追加しないことが安全な範囲設定につながります。

納品テストは、正しい集計と止まる場面を顧客側で確かめる

制作が終わったら、まず架空データで仕様どおりの結果になるかを確認し、その後に顧客が認めた検証環境で試運転します。制作者の環境の成功だけを納品条件にすると、顧客側の権限不足や運用の違いを見落とします。実データを使う必要がある場合は、対象、閲覧できる人、保存先、終了後の扱いを先に合意してください。

正常系の正解と、異常系の止まり方を同じ票に残す

テスト票には、試す条件、期待する結果、実際の結果、確認した人、日時を残します。正常に動いたことだけでなく、入力が変わったときに既存の集計を壊さないかを確かめます。チェック欄だけでは後から再現しにくいため、使った見本データの版や対象日も記録しましょう。

※表は横にスクロールできます。

たとえば「前回の成功結果を残す」設計でも、今回失敗したことが見えなければ古い集計が最新と誤解されます。対象日、最終成功日時、今回の実行結果を別に表示すると判断しやすくなります。最終成功日時は処理開始時ではなく、必要な確認を終えた段階で更新する仕様にします。

再実行と訂正が、別の結果を生まないか見る

日報のR003が後から2件から3件へ訂正された場合、日別集計を元データから作り直す方式なら、作業Aが7、作業Bが3、合計10になります。これは、本記事の見本で選んだ再集計方式の結果です。前回結果へ新しい数だけを足す方式では、訂正や取消を別に設計する必要があります。

「一度処理したIDは二度と処理しない」という管理だけでは、後からの訂正に対応できない場合があります。受付自体の重複防止と、訂正の取り込みは別の判断です。何をもって同じ入力とするか、過去の日付を再集計してよいか、締めた後の変更は誰が承認するかを確認しましょう。

書込みが途中で止まった場合に備えて、元データ、確認用の結果、利用者が使う確定結果をどの順で扱うかを決めます。作業用の領域で検算してから反映する方法も考えられますが、それだけですべての更新が一括で成功する保証にはなりません。想定する停止地点ごとに、実際に残る状態を調べる必要があります。

手動実行と定期実行が重なったときの扱いも検討します。先の処理が終わるまで後の処理を待たせるか、中止して記録するかを決める場面です。GoogleのLock Serviceは、共有資源への同時アクセスを制御するための機能ですが、業務上の重複判定や送信済み確認まで自動的に解決するものではありません。

顧客側の試運転は、利用者が説明書を読むところから始める

説明しながら制作者が全部操作すると、使い方が分かりにくい部分が隠れます。顧客側の担当者に説明書を読んでもらい、対象日の選択、結果の照合、エラー時の確認まで進めてもらいましょう。操作を迷った箇所は利用者の問題にせず、説明や表示の改善点として記録します。

1. 検証用データと確認票の版をそろえ、実データと混在させない
2. 顧客側の実行担当が、必要なアクセスと承認内容を確認する
3. 正常入力を実行し、件数・合計・対象日を手計算と照合する
4. 空欄や重複などの試験を行い、止まり方と案内を確認する
5. 説明書だけで再実行と問い合わせができるか確認する
6. 残った不具合、対応しない条件、再試験する項目を双方で記録する

試験用に権限不足を再現するときは、検証用ファイルやあらかじめ合意した対象を使います。普段使っている業務ファイルの共有を外したり、本番のトリガーを無断で変えたりしてはいけません。顧客の業務が止まる変更は、検証であっても実施範囲と復旧方法の確認が必要です。

テストの合格は、その条件と確認時点での結果です。件数、列、担当者、送信先などが変われば、追加確認が必要になることがあります。納品書には万能な動作保証を書くのではなく、何件のデータで、どの実行方法を、どの担当者と確認したかを残してください。

実行上限・情報の扱い・障害時の連絡を運用に織り込む

GASがクラウド上で動くからといって、処理量や運用確認を考えなくてよいわけではありません。依頼者のアカウント種別、データ件数、実行頻度、同じアカウントで動く他の処理が、運用条件に関わります。小さな見本が成功したら、日々の使い方を想定した試験へ進めます。

上限の数字と、実際に処理できる量を混同しない

2026年10月7日確認時点のGoogle公式の上限一覧では、通常のスクリプトの実行時間は個人用・Google Workspaceともに1実行6分、トリガーの合計実行時間は個人用が1日90分、Google Workspaceが1日6時間とされています。種類別の制限や関連サービスの上限もあり、数値は予告なく変更される可能性があります。

これは「6分以内なら何件でも処理できる」という意味ではありません。同じ行数でも、外部サービスへのアクセス、書込み回数、数式、処理内容によって時間は変わります。依頼者が普段扱う量だけでなく、月末など増える日も想定し、十分な余裕を持って動くかを測定します。

この日報集計なら、通常日の架空データ、行数を増やした架空データ、重複や形式違いを混ぜたデータで、処理時間と結果を記録します。「何行まで使える」と案内する場合は、試験した条件を付けてください。別のアカウントや別の書式へコピーしただけで、同じ性能が出るとは限りません。

上限を超えると例外が発生し、処理が止まる場合があります。制限を避けるために無断でアカウントを増やすのではなく、対象データを減らす、処理方法を見直す、実行頻度を下げる、別の仕組みを検討するといった方向で依頼者と相談します。必要な業務量が当初の想定を超えるなら、追加設計の対象です。

読み書きの回数と、実行時刻の要求を確認する

一行ずつ読み書きを繰り返すより、必要な範囲をまとめて読み、処理した結果をまとめて書くほうが効率的な場面があります。Googleのベストプラクティスでも、サービス呼出しを減らす方法が紹介されています。ただし、速くする変更の後は、空行や訂正を含めて結果が変わっていないか再確認します。

時刻指定にも注意が必要です。時間主導型トリガーでは、設定によって実行時刻に幅が生じます。毎朝決まった時刻ぴったりに完了しなければ困る業務なら、最初の相談でその条件を伝えてもらいます。日報の例なら「始業前の確認に間に合う必要があるのか」「遅れたら手動集計で対応できるのか」を具体的に聞きます。

単純なトリガーとインストール型トリガーも同じ扱いにはできません。単純なトリガーの公式説明には、承認を必要とするサービスを使えないことや、実行時間の制限が示されています。関数名を決めただけで、どのサービスも自由に自動実行できると考えないようにしましょう。

失敗を受け取る人と、残す情報を決める

エラー時には、顧客側で誰が実行履歴や通知を確認するかを決めます。担当者が一人だけなら、休暇や異動の際の連絡先も必要です。制作者が通知を受け取っているから大丈夫とせず、契約終了後も顧客側で異常に気づける運用を確かめます。通知方法には種類ごとの違いがあるため、採用した方式で確認してください。

記録には、処理を見分けるID、対象日、開始と終了、採用件数、失敗した工程などを残すと調査しやすくなります。メールアドレス、日報の本文、個人情報を必要以上に記録しないようにしましょう。Googleのログの説明でも、個人情報を記録しない配慮が案内されています。

問い合わせの文章は「動きません」だけでは調査が進みません。「対象日」「操作した時刻」「表示された案内」「変更した項目」「最後に正常だった日時」を伝えてもらう形にします。画面を共有する場合も、関係のないタブや顧客情報を隠すなど、確認に必要な範囲に絞ります。

日報集計が使えない間に、担当者が手計算や既存の表で集計できるなら、その代替方法も説明書へ入れます。自動化した工程の前後に人の確認を残しておくと、副業の制作者がすぐ対応できない時間帯にも、依頼者が次の判断をしやすくなります。

引渡し資料・保守範囲・応募条件をそろえて受注へ進む

GAS副業の納品物には、コードだけでなく、依頼者が使い続けるための情報を含めます。毎回長い説明書を作る必要はありませんが、担当者が変わったときに探す場所が分かるようにまとめましょう。今回の日報集計なら、仕様、実行担当、試験結果、止め方、連絡条件を一組にします。

引渡し確認票を、制作開始時から埋めていく

※表は横にスクロールできます。

コードの控えを渡すときは、どの状態を納品版としたかを明記します。日付と版番号を付け、以後の変更は何を変えたか残す運用にすると、障害時に確認する対象がそろいます。控えに秘密情報や不要な実データが混ざらないようにし、保存先と保管期間も顧客の方針に合わせてください。

使っているライブラリや外部サービスがあれば、その名前、用途、必要な契約やアクセスも引き継ぎます。今回の見本は外部サービスを使わない想定ですが、案件で追加した場合は説明書も更新します。コードのファイルだけを渡しても、依存するサービスや設定が不足すれば運用は続けられません。

自動実行の切替は、旧設定と新設定を同時に確認する

手動の試運転が完了し、自動実行を採用する場合は、顧客と切替の時間帯を決めます。試験用の処理と運用用の処理が重複しないよう、作成者ごとの設定を確認し、必要な停止を行ったうえで顧客側の運用設定を確認します。実施する人、承認する人、切替がうまくいかない場合の扱いも決めておきます。

顧客側の設定で最初の定期実行を確認したら、対象日、件数、集計結果、通知、実行履歴を一緒に照合します。コードが同じでも、実行するアカウントが変われば見えるデータや承認状態が変わり得ます。この一回を確認せずに、制作者側のアクセスを外して引渡し終了にしないようにしましょう。

その後、契約上不要になった制作者のアクセスを、顧客の手順に沿って整理します。作業用コピーや取得したデータの返却・削除も合意した方法で行い、必要な記録を残します。保守が続く場合は、何の目的でどの範囲のアクセスを残すかを明確にし、何となく編集者のままにしないことが大切です。

不具合修正と追加の希望を分けて見積もる

「納品後も対応します」という一言では、どこまで料金に含まれるか分かりません。合意した仕様と異なる動作の修正、入力項目の追加、集計方法の変更、新しい通知先への対応、アカウント変更による再設定を区別します。無償・有償の範囲や期間は、案件ごとに契約前に確認してください。

たとえば、合意した区分A・Bの集計が誤るなら仕様どおりに動いているかを調査する対象です。あとから区分Cを増やしたい、複数部署へ同時通知したいという希望は、影響を調べてから追加変更として相談できます。原因が不明な段階では、先に受付と調査範囲を決め、誰の責任かを急いで断定しないようにします。

見積もりでは、聞き取り、仕様整理、制作、権限の確認、顧客側の試運転、説明書、修正の時間を分けて考えます。コードを書く時間だけで見積もると、納品先での調整が続いたときに苦しくなります。相場の数字を先に当てはめるより、自分が確実に担当する工程を明示して相談するほうが、条件の違いを説明しやすくなります。

保守に含める場合も、常時監視や即時復旧を当然の約束にしないことが重要です。本業の勤務中に対応できないなら、連絡を確認できる時間と、対応開始の目安を事前に伝えます。即時対応が不可欠な業務であれば、一人の副業受託で支えられる条件かを再検討しましょう。

応募時は、できることと確認したいことを短く伝える

応募文では、抽象的な「業務効率化が得意です」より、見本の目的と確認内容を示します。たとえば「架空の日報を日付と区分で集計する見本を作成しました。重複入力と再実行の確認票があります。御社の実行アカウント、入力形式、保守担当を伺ったうえで対応範囲をご相談したいです」と伝える形です。実際に用意していない見本や試験を実施済みと書かないでください。

募集文に「GAS」とあっても、外部API、社外公開、複数組織の連携、既存コードの引継ぎが含まれることがあります。Googleサービスだけの小さな集計と同じ難易度ではありません。資料を見てから判断する条件や、調査だけを先に行う範囲を相談し、理解できない運用を一括で引き受けないようにします。

案件を探す経路や応募先の比較は、フリーランス案件の探し方を整理した記事で確認できます。応募前には、本業の副業規則、利用してよい時間・端末、機密情報の扱いも見直しましょう。勤務先の資料やアカウントを、副業の見本や納品先に流用しないことが基本です。

GASを仕事にする準備では、一度動くものを作った後の確認が信頼につながります。日報集計のような小さな業務でも、結果の根拠、担当者、変更方法、停止時の判断がそろえば、依頼者は使い方を想像できます。まずは一つの見本を、他の人が説明書を見て確認できるところまで仕上げてみてください。

技術仕様の確認について

技術仕様の確認日：2026年10月7日。制限値、権限、管理機能は変更される場合があります。受注時と納品前に、利用するアカウントと実行方式に対応する最新の公式資料を確認してください。