月末の締め日、経理担当の手が売上シートの前で止まる。「営業3人分のスプレッドシートを開いて、マスターに貼って、ピボットを直して、freeeに転記して……今月も丸1日これで終わる。自動化で自動化したいけれど、社内に書ける人はいない。外注するとして、いくらかかるのか見当がつかない」
結論を先に書きます。自動化開発の外注費用は「作る機能の数」では決まりません。要件定義書に書ける工程の数と、受入テストと保守の当番を社内の誰が持つかで決まります。この記事では月次の売上集計を例に固定し、発注側の仕事を7工程に分けて、外注した場合と内製した場合でどの工程が消え、どの工程が増えるかを整理します。
- 費用は「設計・実装・受入テスト・引き継ぎ資料・保守」の5つの欄の合計で決まる。1行で書かれた一式見積は、受入テストの後に追加請求が出やすい
- 自動化には1回の実行が6分までという割当があり、トリガーの1日の合計は無料アカウントと Google Workspace で別枠(出典:Google公式ドキュメント)。内製が止まる場所と、外注の見積が跳ねる場所は同じここ
- 外注しても社内に残す判断は4つ。対象シートの権限、社外へ渡すデータの範囲、受入基準、止まった日の当番。この4つを決めてから見積を取ると、金額の幅が自社の数字で読める
目次
自動化開発の外注とは何か|スクリプトと一緒に受け取るもの
自動化開発の外注とは、Googleスプレッドシート・Googleフォーム・Gmail・freeeなどをつなぐ処理をGoogle Apps Scriptで書く仕事について、要件定義から実装、受入テスト、引き継ぎ資料の作成までを社外の開発者や開発会社に委ねる契約です。納品物はスクリプト本体だけではありません。どの列を読みどこへ書き、失敗したら誰に何が届くかを書いた仕様書と、止まった日に社内の誰が何を見るかを書いた引き継ぎ資料。この2つが契約に含まれるかで、費用も納品後の安心も変わります。
例にする業務:月末締めの売上集計(担当・入力・出力・例外)
例は月次の売上集計です。担当は経理担当1人。トリガーは締め日の翌営業日の朝。入力は営業担当3人がそれぞれ更新している「売上入力シート」と、freee会計の請求書一覧。出力は部門別・商品別に集計した「月次売上マスター」1本と、経営会議に出す集計表。例外は、値引き欄の記入漏れと、月をまたいで取り消しになった案件。この2つは今も担当が営業に電話して確かめています。
内製と外注の線引きは「書ける人」ではなく「止まった日に直せる人」
社内にJavaScriptを書ける人がいるかどうかは、線引きの材料としては弱いです。書けた人が異動や退職でいなくなった月に、スクリプトが止まってから困る。線を引くなら、止まった日にログを読んで直せる人が社内に1人以上いるか、その人の時間が月に何時間空いているか、で引くほうが外れません。
人の話は精神論ではなく数字の話です。IPA『DX動向2026調査のポイント』(出典PDF・2026年7月公表、2026年9月確認)では、DXを推進する人材が不足していると回答した企業が85.5%を占めています。書ける人を採るより、書けなくても受入テストと保守の当番を回せる体制を先に作るほうが、会社として現実的な順番です。
費用の話に入る前に:自動化が触れる範囲と触れない範囲
自動化が得意なのはGoogle Workspaceの中と、APIを公開している外部サービスとの往復です。freee会計やHubSpot、LINEはAPI経由でつなげます。逆に、画面をマウスで操作しないと入れないシステムや、社内ネットワークの中にしかないデータベースは自動化の外です。対象の1つでも自動化の外にあると、RPAや別の仕組みが要り、見積の桁が変わります。
自動化開発の外注費用はいくらで決まる?見積書の5つの欄で読む
問いに先に答えると、自動化開発の外注費用は「設計」「実装」「受入テスト」「引き継ぎ資料」「保守」の5つの欄の合計です。相場を1つの金額で書くことはしません。同じ売上集計でも、freee連携の有無と例外処理の深さで見積は3倍ほど動きますし、発注サイトの提示額は「実装」の欄しか含んでいないことが珍しくないからです。金額は、自社の要件定義書を同じ形で2〜3社に渡して返ってきた見積書で確かめるものです。
5つの欄の中身:設計・実装・受入テスト・引き継ぎ資料・保守
| 欄 | 何が含まれるか | 一式見積で聞き返す質問 |
|---|---|---|
| 設計 | 対象シートの列定義、処理の順番、例外時の分岐、通知先。要件定義書と仕様書に落とす | 「仕様書は納品物ですか、社内資料ですか」 |
| 実装 | スクリプト本体。トリガーの設定、freee等のAPI認証、ログの出力先 | 「認証は誰のアカウントで動きますか」 |
| 受入テスト | 実データに近いテストデータで正常系と例外系を確かめる。確認表を付ける | 「確認表の項目は誰が書きますか」 |
| 引き継ぎ資料 | 操作手順、止まった日の見方、変更時に触る箇所の一覧 | 「担当が替わっても読めますか」 |
| 保守 | Google側の仕様変更やシート構造の変更への追随。月額か都度か | 「月1回までですか、何を直しますか」 |

一式で1行しかない見積書は、5つの欄のどれが抜けているかを聞き返すために使います。抜けやすいのは受入テストと引き継ぎ資料で、安く見える見積ほどこの2つが「お客様側で実施」になっています。
金額が3倍動く要因:連携先の数、例外処理、そして6分の壁
連携先が1つ増えるとAPI認証とテストが1組ずつ増えます。例外処理は正常系の2倍から3倍の工数がかかり、ここを省いた見積は動くけれど壊れやすいものになります。3つ目が自動化そのものの制限です。Google Apps Scriptの割当と制限(2026年9月確認)では、時間主導トリガーの合計実行時間が無料のGoogleアカウントで1日あたり90分、Google Workspaceのアカウントで1日あたり6時間、スクリプト1回の実行時間は6分までと定められています。自社がどちらの枠で動かすのかを先に確かめます。明細が増えて1回の集計が6分を超えると、処理を分割して途中から再開する設計が要ります。最初から入れるか、超えてから入れ直すかで、見積は別物になります。
相場の幅は、同じ要件定義書を2〜3社に渡して確かめる
見積を比べられる状態を作るのは発注側の仕事です。要件定義書1本を同じ形で2〜3社に渡し、5つの欄が分かれた見積書で返してもらう。1社だけでは高いか安いかが分かりませんし、条件がばらばらの3社分では比べようがありません。金額の幅は、この手順を踏んだときに初めて自社の数字として読めます。
外注先の型と選び方|個人に頼むか会社に頼むかで納品後に残るものが違う
頼み先は大きく3つです。クラウドソーシング経由の個人、実績のあるフリーランス、自動化を含む自動化を請け負う開発会社。金額の幅は上から順に広がりますが、見るべきは金額より「納品後に社内に残るもの」です。
| 見るポイント | 個人(クラウドソーシング・フリーランス) | 開発会社・伴走型 |
|---|---|---|
| 要件定義への関与 | 依頼側が書いた要件定義書を前提に実装する形が中心 | 棚卸しの段階から入り、要件定義書を一緒に書く形を選べる |
| 受入テストの確認表 | 依頼側が用意する前提になりやすい | 確認表の作成まで見積に含むかを最初に確かめられる |
| 引き継ぎ資料 | 見積に入っていないことがある | 仕様書・操作手順・止まった日の見方を納品物に含めやすい |
| 止まった日の対応 | 連絡が取れる時間帯が限られる | 保守契約で月の対応回数と窓口を決められる |
| 契約・秘密保持 | 個人との秘密保持契約を自社で用意する | 会社の雛形で秘密保持と再委託の有無を確かめられる |
| 費用の幅 | 狭い。実装の欄だけで提示されることがある | 広い。5つの欄が分かれる分、比べやすい |
3つの頼み先で、納品後に社内に残るものが違う
クラウドソーシングで実装だけを頼むと、動くスクリプトは手に入りますが、仕様書と引き継ぎ資料は残らないことがあります。半年後にシートの列が1本増えて止まったとき、直せる人が社内にも社外にもいない状態がいちばん高くつきます。開発会社に頼むと初期の金額は上がりますが、確認表と引き継ぎ資料が残る分、担当が替わっても回ります。
契約前に確かめる5つの質問:実績の数より「止まった日」の答え
①自動化で組んだ自動化を納品から1年以上動かし続けている案件があるか。②要件定義から入れるか、要件定義書を渡す前提か。③受入テストの確認表は誰が書くか。④本番のシートとfreeeの認証情報は誰のアカウントで、いつまで使うか。⑤止まった日に、何時間以内に誰が見るか。④と⑤の答えが曖昧な相手は、金額が安くても外したほうが安全です。
依頼から納品までの流れ|月次売上集計の7工程を内製と外注で並べる
費用の欄が分かったら、自社の業務を工程に分けます。ここを飛ばして「いい感じに自動化してほしい」と頼むと、開発者は見えないリスクを金額に乗せます。工程に分ける作業は、外注する場合も内製する場合も同じです。
いまの流れ:締め日翌朝の売上集計7工程(担当・入力・出力・判断・所要)
- 第1工程 営業担当3人が、締め日までに各自の「売上入力シート」を埋める。入力:受注メール。出力:売上入力シート。判断:値引き欄を埋めるかは営業の裁量。所要:自社で測る
- 第2工程 経理担当が3本のシートを開き、当月分をコピーして「月次売上マスター」に貼る。判断:なし。所要:自社で測る
- 第3工程 freee会計の請求書一覧をCSVで出し、マスターと突き合わせる。判断:金額が合わない行をどう扱うか。所要:自社で測る
- 第4工程 合わない行について営業に電話し、値引き漏れか取り消しかを確かめる。判断:営業と経理。所要:自社で測る
- 第5工程 部門別・商品別のピボットを更新し、前月比を目で確かめる。判断:異常値かどうか。所要:自社で測る
- 第6工程 経営会議用の集計表を作り、Gmailで経営層3人に送る。判断:なし。所要:自社で測る
- 第7工程 翌月の締め日に向けて、営業側のシートの列や商品マスターの変更を反映する。判断:変更を誰が承認するか。所要:自社で測る
時間が消えるのは第2工程と第5工程、失敗が起きるのは第3工程と第4工程です。第4工程の電話は判断を含むので、自動化には渡せません。渡せるのは判断のない第2工程、第3工程の突き合わせ、第5工程の更新、第6工程の送信です。
同じ7工程を、内製した場合と外注した場合で並べる
| 工程 | 内製した場合 | 外注した場合 |
|---|---|---|
| 第1工程 営業の入力 | 変わらない。列を増やすときは書いた人に相談する | 変わらない。列の変更は仕様変更として窓口へ出す |
| 第2工程 コピーと貼付け | 消える。書いた人が動作を見る | 消える。受入テストの確認表で動作を確かめる |
| 第3工程 freeeとの突合 | 消える。API認証が書いた人の個人アカウントになりがち | 消える。認証に使うアカウントを契約で決める |
| 第4工程 営業への確認 | 残る。対象行の一覧だけ自動化が出す | 残る。対象行の一覧の出し方を要件定義書に書く |
| 第5工程 ピボット更新 | 消える。異常値の判断は残る | 消える。異常値の閾値を人が決めて仕様に書く |
| 第6工程 会議用の送信 | 消える | 消える。宛先の変更は誰が触るかを引き継ぎ資料に書く |
| 第7工程 翌月への反映 | 増える。書いた人が毎月直す当番になる | 増える。仕様変更の窓口と保守の当番を決め、月額か都度かを選ぶ |
| 増える工程:受入テスト | 書いた本人が確かめる形になりやすい | 確認表に沿って社内の担当が検収する |
消える工程は内製でも外注でも同じ4つです。違いは第7工程と、新しく増える受入テストにあります。内製では書いた本人が毎月の当番になり、その人が休んだ月に第2工程が手作業に戻ります。外注では当番を契約で決められる代わりに、確認表を社内の誰かが読んで検収する仕事が増えます。人が残す判断は第4工程と第5工程の2か所で、ここはどちらの場合も消えません。
依頼の段取り:棚卸し表から引き継ぎ資料まで、6段で進める
進め方はBoostXがAI導入で使っている順番と同じです。①業務可視化。締め日翌朝の7工程を棚卸し表に書き、各工程の所要を1か月だけ実測する。②判断点の抽出。第4工程と第5工程の判断を書き出し、閾値にできるものと人に残すものを分ける。③範囲とKPIの合意。自動化に渡す第2・第3・第5・第6工程を要件定義書に書き、指標を「締め日翌朝に戻る時間」と「第4工程の電話件数」に決める。④PoC。営業1人分のシートだけで1か月動かし、確認表を埋める。⑤構築と定着。3人分に広げ、止まった日の見方を引き継ぎ資料に書いて経理担当に渡す。⑥効果測定と展開。翌月の締め日に指標を見て、動かなければ要件定義書から見直す。
要件定義書と受入基準を書く工程まで社外に頼みたい場合、BoostXのAIエージェント開発は自動化を含む自動化の設計・構築・現場定着を対応範囲にしています。毎月1業務ずつ小さく進めたい場合はAI顧問の範囲です。
自動化で消える手作業と担当に残る判断|効果は「戻った時間」で測る
減る時間を先に数字で置くことはしません。減る時間は第2工程と第5工程の実測から出るもので、会社ごとに違うからです。代わりに、外注しても手放せない判断と、導入前後で自社が測る項目を書きます。
発注側が手放せない4つの判断(権限・外部送信・受入基準・当番)
重いのは対象シートとfreeeの権限です。誰のアカウントでスクリプトを動かすかは退職や異動のたびに影響が出るので、契約書に書く事項として発注側が決めます。社外へ渡すデータの範囲は、開発中に本番の売上データを触らせるかダミーで進めるかの話で、秘密保持契約の条項と対応させて発注側が決めます。受入基準は短く言えます。「第3工程の突合で不一致が0件なら合格」のように金額に直結する基準は、開発者ではなく経理担当が決めないと検収ができません。止まった日の当番は責任の所在なので、月額保守か都度対応かを含めて社内で決めます。ここは私も一概に言い切れない点で、月に1回も止まらない仕組みに月額を払うのが正しいか、都度払いで対応が遅れる損を取るかは、集計が止まった日に誰がどれだけ困るかで会社ごとに答えが変わります。
効果の測り方:3つの指標を経理担当が月次で見る。回収は仮定を置いた式で見る
導入前に1か月だけ測るのは3つです。締め日翌朝に第2工程から第6工程にかかった時間(分単位)、第4工程で営業に電話した件数、第3工程で不一致だった行数。導入後は同じ3つを毎月の締め日に経理担当が記録し、四半期に1回、経理の責任者が見ます。回収期間は測った数字で出します。式は、年間で戻る時間×担当の時給が年間の効果額、外注費用の初期分をそれで割った月数が回収までの期間。仮定として、締め日翌朝の作業が8時間で毎月1回、時給を2,500円と置けば、年間96時間×2,500円で24万円が効果額の上限になり、初期費用がこの範囲に収まるなら12か月以内に回収できる計算です。数字は仮定なので、自社の実測に置き換えてから見積と並べてください。
外注でも内製でも止まるリスク|要件の丸投げ・本番データ・追加要件
外注したのに効果が出ない、内製したのに半年で止まる。どちらも、工程を分けずに始めたことに戻ります。内製側で止まる境目(6分の実行制限・トリガー・権限・属人化)は自動化開発は外注か内製かで工程ごとに書いているので、ここでは外注しても残るリスクに絞ります。
丸投げした要件定義は、受入テストの日に請求書になって返ってくる
いい感じに自動化してくださいで始めた案件は、受入テストの日に「これは要件に入っていません」が出ます。どの列を、いつ、どこへ出すかを要件定義書に書くのは発注側の仕事で、ここに使う時間は費用ではなく前払いです。開発が始まってからの「ついでにこれも」は、第2フェーズとして別見積に切り出す約束を契約前に交わしておきます。
人の面でも準備が要ります。商工中金『中小企業の生成AIの利用にかかる調査』(出典PDF・2026年1月調査、2026年9月確認)では、導入後の課題として「推進する人材がいない」を挙げた企業が32.0%、「活用場面が不明」が35.6%です。自動化の外注に置き換えると、確認表を読む人がいない、どの工程を渡すか決まっていない、という状態で見積だけ取ることに当たります。
本番データで開発させると、外部送信の範囲が契約より広がる
自動化は売上シートとGmailに直接触ります。開発者に本番の共有権限を渡した瞬間、顧客名と金額が社外に見える状態になります。開発はダミーデータのコピーで進め、本番の権限は受入テストの当日だけ期限付きで渡す。認証情報は個人のGoogleアカウントではなく、業務用の専用アカウントで持つ。この2つを契約書の別紙に書いておくと、退職者のアカウント停止でスクリプトが止まる事故も防げます。社外に渡すデータの範囲を第三者に見てもらいたい場合は、AI開発セキュリティ顧問が本番化前のレビューを対応範囲にしています。
ビフォーアフター:締め日翌朝の売上集計がここまで変わる
締め日の翌朝、経理担当の1日が集計に消える
営業3人分のシートを開いてコピーし、freeeの一覧と目で突き合わせ、合わない行を電話で確かめる。ピボットを直して会議用の表を送るころには夕方。翌月の列変更は担当の記憶頼み。所要は「丸1日」という感覚値のままで、誰も測っていない。
朝の時点で不一致の行だけが届き、担当は電話と判断に時間を使う
第2・第3・第5・第6工程はトリガーで動き、第3工程の不一致行と第5工程の異常値だけがGmailで届く。担当がするのは第4工程の電話と、閾値を超えた行の確認。確認表と引き継ぎ資料が手元にあり、止まった日は誰が何を見るかが決まっている。戻った時間は分単位で記録され、四半期に1回、責任者が見る。
よくある質問
Q.自動化開発の外注費用は、いくらくらいを見ておけばいいですか?
A.金額を1つ挙げることはしていません。設計・実装・受入テスト・引き継ぎ資料・保守の5つの欄が分かれた見積書を、同じ要件定義書で2〜3社から取ると、自社の案件の幅が読めます。実装だけの提示額は、他の4つの欄が抜けている前提で見てください。
Q.6分の実行制限があると、売上集計は自動化では無理ですか?
A.無理ではありません。Google公式の割当(出典:Apps Scriptのquotasページ)では1回の実行が6分、時間主導トリガーの合計が1日90分までなので、明細が増えたときは処理を分けて途中から再開する設計にします。この設計が最初から見積に入っているかを、要件定義の段階で確かめてください。
Q.保守契約は月額で結ぶべきですか?
A.会社ごとに答えが変わる点です。Google側の仕様変更やシートの列変更は年に1〜2回は起きるので、止まった日に社内で直せる人がいなければ月額の窓口を持つほうが安全です。直せる人が1人でもいるなら、都度対応で始めて止まった回数を記録し、1年後に見直す形でも回ります。
Q.社内にIT担当がいなくても自動化開発の外注はできますか?
A.できます。要件定義書に書く工程の棚卸しと、受入テストの確認表を読んで検収する役は経理担当が持てます。持てないのは認証情報の管理なので、業務用アカウントの作成と権限の期限だけは、外注先と一緒に最初に決めてください。
この記事のまとめ
- 最初にやるのは見積依頼ではなく、締め日翌朝の7工程を棚卸し表に書き、1か月だけ所要を実測すること
- 要件定義書には「自動化に渡す工程」と「人に残す判断(第4・第5工程)」を分けて書き、同じ1本を2〜3社に渡す
- 見積書は5つの欄で返してもらい、受入テストと引き継ぎ資料が「お客様側」になっていないかを見る
- 契約前に決めるのは権限・外部送信の範囲・受入基準・止まった日の当番の4つ。ここが空欄の見積は比べられない
- 導入後は「戻った時間」「電話の件数」「不一致の行数」を経理担当が毎月記録し、四半期に1回、責任者が見る。数字が動かなければ要件定義書に戻る
公開日:2026年9月
読んで終わりにしないために
「自社の場合は、どうすれば?」
その答えを、最大45分で持ち帰る。
記事で分かるのは、一般論まで。AI導入を専門に見ている担当が、貴社の業務に当てはめて“次の一手”だけを一緒に整理します。
この相談で持ち帰れるもの
- 01
自社業務に当てはめたAI活用マップ
- 02
投資対効果(ROI)のシミュレーション
- 03
いまの悩み・疑問への、その場の個別回答


