GoogleフォームをGASに任せる境目｜転記のムダと比較表

フォームの回答は自動で集まるのに、その先は手作業のまま残ります。「回答が届くたびにスプレッドシートを開いて、管理台帳に写して、お礼のメールを打って、担当者に転送する。1件は数分でも、積み重なると半日が消える」——Googleフォームを問い合わせや申込みの受付に使っている会社では、この構造の悩みが定番です。

結論から言うと、Googleフォームの回答処理は自動化（Google Apps Script）に通知・転記・自動返信・振り分け・カレンダー登録・重複チェック・PDF生成・ドライブ保存・集計・外部API連携の10の型まで任せられ、境目になるのはGoogle公式が定める1回6分の実行上限や1日のメール送信上限と、それを守り続ける人がいるかどうかです。本記事では、任せられる10の型と、自前で組んだときに出る限界を比較表で整理します。

Googleフォームと自動化の連携とは、フォームが送信された瞬間をきっかけにGoogle Apps Scriptの処理を自動で走らせ、回答データを通知・転記・返信・保存といった次の作業へ渡す仕組みです。フォーム単体でできるのは「回答をスプレッドシートに並べる」ところまでで、その先にある「人が見て、写して、送る」の部分が自動化の担当範囲になります。

連携の定義と任せられる範囲

任せられる範囲は、フォームの外側と内側の2つに分かれます。外側とは、回答が届いた後の処理です。チャットへの通知、管理台帳への転記、回答者への返信、担当者への振り分け、カレンダーへの登録、重複の除外、PDFの発行、添付ファイルの整理、集計、外部システムへの登録という10の型があり、本記事の中心はここです。

内側とは、フォームそのものの扱いです。自動化にはFormAppという仕組みがあり、設問を組み立ててフォームを自動作成する形や、回答欄をあらかじめ埋めた事前入力URLを生成して自動入力に使う形も作れます。毎月同じ申込フォームを手で作り直している、顧客ごとに氏名や会社名を入れた状態のフォームを配りたい、といった場面はこちらの範囲です。外側の10の型ほど件数は多くありませんが、「フォームを作る作業」自体が繰り返しになっているなら、先にここを畳む方が早い会社もあります。

どちらの範囲でも共通するのは、自動化が動く条件を人が決めるという点です。何をきっかけに、どのデータを、どこへ渡すか。この3つを決めない限り、自動化は1行も動きません。逆に言えば、この3つさえ言葉にできれば、コードを書く前に任せられるかどうかの見当はつきます。

転記のムダはどこで生まれるか

フォームの回答処理を手作業で回すと、次の作業が1件ごとに繰り返されます。スプレッドシートを開いて新着を目視で確認する、回答を別の台帳や社内システムにコピーする、回答者にお礼や受付確認のメールを送る、内容に応じて担当者へ転送する、月末に回答を集計して報告用にまとめる。1つひとつは小さく、だからこそ「自動化するほどではない」と放置されやすい作業です。

目安として、1件あたりの確認・転記・返信に5分、月に100件の回答があると置くと、月500分、8時間ほどが受付まわりの手作業に使われている計算になります。自社の件数や1件あたりの時間がこれと違うなら当てはまらない部分が出ますが、件数に比例して増える構造は同じです。回答が増えるほど楽になるのではなく、回答が増えるほど手作業が増える。フォームを受付に使う会社が、どこかの時点で必ず突き当たる壁がここにあります。

こうした手作業の自動化は、中小企業の中でも珍しい選択ではなくなっています。商工中金「中小企業の生成AIの利用にかかる調査」（2026年3月公表、2026年9月確認）では、生成AIの活用事例として「メール・報告書・議事録の作成・要約」が74.0%で最多、次いで「デスクワーク作業支援・自動化」が48.7%でした。半数近い会社が、デスクワークの自動化をすでに使い方の1つに数えています。フォームの回答処理は、その中でも入口と出口がはっきりしていて、自動化の対象として切り出しやすい部類です。私が支援してきた会社でも、出発点は「どのツールで組むか」ではなく、「回答が届いた後に人が何をしているかを1件分だけ書き出す」ところに置いています。

他の自動化ツールではなく自動化が向く3つの場面

業務自動化のツールは他にもありますが、Googleフォームの回答処理に限れば自動化が第一候補になる場面が3つあります。1つ目は、回答データがGoogle Workspaceの中で完結している場面です。自動化はフォーム・スプレッドシート・Gmail・カレンダー・ドライブと同じ土台で動くため、外部ツールで必要になるAPI認証の設定やWebhookの受け口が要りません。回答データに直接手が届きます。

2つ目は、費用を増やしたくない場面です。自動化はGoogleアカウントがあれば追加費用なしで使えます。外部の自動化サービスは処理件数に応じた有料プランになることが大半で、フォームの回答件数が増えるほど費用も増える構造です。件数が読めない受付では、この差が効いてきます。

3つ目は、「あと一歩」の条件分岐が要る場面です。ノーコードのツールは定番の流れは速く組めますが、「この選択肢のときだけ別の担当者へ」「過去に同じメールアドレスがあれば止める」といった自社固有の判断が入ると手が届かなくなります。自動化はJavaScriptをもとにした言語なので、こうした分岐や照合を自由に書けます。ただし、この自由さが後述する「組んだ人しか直せない」限界と表裏一体である点は、先に知っておくべき境目です。

10の型のどれを選ぶにしても、共通の土台が3つあります。スクリプトをどちら側から開くか、何をきっかけに動かすか、回答データをどの形で受け取るか。この3つは後から変えると型を組み直すことになるため、先に決めておく方が結果として早く進みます。

この領域でつまずきやすいのは、ツール選定よりも「業務の中のどこに組み込むか」の設計です。BoostXのAIコンサルティングは、業務のヒアリングから設計、定着までをサービス対応範囲としてカバーできる領域です。

スクリプトをフォーム側と回答シート側のどちらで開くか

自動化のスクリプトエディタは、Googleフォームの編集画面のメニューからも、回答が集まるスプレッドシートの「拡張機能」メニューからも開けます。どちらから開くかで、後述するトリガーの設定先と、回答データの受け取り方が変わります。フォーム側で開くと回答は「設問と回答の組」として届き、回答シート側で開くと「列名と値の組」として届きます。

向き不向きの目安は、回答シートを台帳として使い続けるかどうかです。回答シートに対応状況の列を足して台帳を兼ねるなら、シート側で開く方が列の操作と相性がよくなります。回答シートは触らず、別の台帳や外部システムへ渡すだけなら、フォーム側で開く方が設問の並びに引きずられません。どちらでも10の型は組めますが、途中で切り替えるとデータの受け取り方を書き直すことになります。

onFormSubmitトリガーが1回の送信ごとに走る

連携の起点になるのが、フォーム送信時に関数を呼び出すonFormSubmitトリガーです。トリガーの画面で「イベントのソース」をフォーム、「イベントの種類」をフォーム送信時にして保存すると、以後は1回の送信ごとに指定した関数が1回走ります。初回にGoogleアカウントの権限許可を求められるのは、スクリプトが回答者のデータやメール送信に触るためで、ここで許可した内容がそのまま自動処理の権限範囲になります。

設計上の前提として押さえておきたいのは、トリガーがそれを設定した人のアカウントに紐づいて動くことです。返信メールはその人のアカウントから送られ、その人の権限で台帳やドライブに書き込みます。設定した人が異動や退職でアカウントを失うと、トリガーごと止まります。「誰のアカウントで動かすか」を、個人ではなく受付用の共有アカウントにするかどうかは、組む前に決めておく事項です。

トリガーには数と時間の上限もあります。Google Apps Script 公式ドキュメント「Quotas for Google Services」（2026年9月確認）によると、トリガー数は1ユーザー1スクリプトあたり20本、同時実行は1ユーザーあたり30、トリガーの1日合計実行時間は無料アカウントで90分、Google Workspaceで6時間です。フォーム送信のたびに数秒で終わる処理なら余裕がありますが、送信のたびに回答一覧を全部読み直す設計だと、件数が増えたときにこの合計時間を消費していきます。

回答データをイベントオブジェクトのどこから受け取るか

フォーム送信で呼ばれた関数には、送信内容をまとめたイベントオブジェクトが引数として渡されます。フォーム側で開いた場合はそこから「設問ごとの回答」を順に取り出す形になり、回答シート側で開いた場合は「列名をキーにした値」として受け取る形になります。どちらも数行で回答に手が届きますが、鍵になるのは設問名です。

10の型のほとんどは、「メールアドレス」「お名前」「お問い合わせの種類」といった設問名を手がかりに回答を拾います。つまり、フォームの設問名を後から1文字でも変えると、その設問を探していた処理は黙って空振りします。設問名は変えない前提にするか、変えてもよいように設問の順番で拾うか。この判断を先にしておかないと、フォームを少し直した翌日から返信が届かなくなる、という止まり方をします。

ここからが、検索している方がいちばん知りたい「自動化で何ができるか」の地図です。10の型はどれも、フォーム送信をきっかけに、回答データを取り出し、どこかへ渡すという同じ骨格でできています。違うのは渡す先と、渡す前の加工です。それぞれについて、何を・どこへ渡す形になるか、向いている場面、自前で組んだときにつまずきやすい所を見ていきます。完成したコードではなく、設計の粒度で書いています。

10の型を一覧で比較（向く場面・自前だとつまずく所）

任せる先の型	向いている場面	自前だとつまずく所
通知（Slack・Chatwork）	問い合わせ・採用・クレームなど初動の速さが要る受付	全項目を流して通知が読まれなくなる。Webhook URLの直書き
転記（管理台帳へ整形）	対応状況を追う受付。複数フォームを1つの台帳に集約	設問名の変更で空振り。台帳に手で行を挿入して追記位置がずれる
自動返信メール	受付完了の連絡。回答内容に応じた文面の出し分け	送信先の1日上限。送信元がトリガー設定者のアカウントになる
担当者への振り分け	営業・サポート・採用など窓口が分かれている会社	対応表にない選択肢の逃がし先を決めておらず黙って落ちる
カレンダー登録	セミナー申込・面談予約・施設予約	自由記述の日時が読めない。枠の重複は別の型が要る
重複チェック	アンケートの精度確保。申込の二重登録防止	全行照合が件数増で実行時間の上限に近づく
PDF生成	受付票・申請書・見積依頼書など書類の発行	設問名とテンプレートの差し込み名の不一致。添付上限
ドライブ保存	履歴書・写真・見積書など添付ファイルの整理	フォルダの命名規則と権限を決めていない
集計・ダッシュボード更新	申込状況の共有。アンケートの途中経過	列位置固定の集計が設問追加で崩れる
外部API連携（CRM等）	CRMへの見込み客登録。案件管理への起票	認証切れやレート制限で黙って落ちる。APIキーの管理

表の右列を見ると、つまずく所の大半がコードの難しさではなく、「決めていなかったこと」から来ていると分かります。設問名を変えない、逃がし先を決める、命名規則を決める。10の型の順に見ていくと、この傾向がさらにはっきりします。

型1：回答をSlack・Chatworkに即時通知する

フォーム送信をきっかけに、回答の内容を1本のメッセージに整形し、SlackのIncoming WebhookやChatworkのAPIへUrlFetchAppで渡す形です。メール通知と違い、チャットならチーム全員が同じ画面で回答を確認できます。問い合わせ、採用エントリー、クレーム報告のように、届いてから動き出すまでの速さが価値になる受付に向いています。

設計の勘所は、通知に何を載せるかです。回答の全項目を流すと通知が長くなり、読まれなくなります。種別・連絡先・要点の3項目に絞り、詳細は台帳へのリンクで見に行く形にすると、通知が「気づくための道具」として機能し続けます。つまずきやすいのは、Webhook URLをコードに直書きしたまま共有すること、そして外部への呼び出しが他の型と枠を共有することです。Google公式のクォータ表（2026年9月確認）では、URL Fetchの呼び出しは無料アカウントで1日20,000回、Google Workspaceで100,000回が上限で、通知・外部API連携・チャット送信はすべてこの枠を使います。

型2：スプレッドシートに自動整形して転記する

フォームの回答シートは設問の順に列が並ぶだけで、そのままでは台帳として使いにくいことがあります。日付の書式を揃える、姓と名を結合する、対応状況の列を持つ管理台帳へ1行追加する。こうした整形と転記を、送信のたびに行う形です。対応状況を追いたい受付や、複数のフォームの回答を1つの台帳に集約したい場面に向いています。

勘所は、台帳側の列の並びを先に固定し、「未対応」「対応中」「完了」のような状態の列を用意しておくことです。転記そのものは1行を追記する処理なので難しくありませんが、台帳に人が手で行を挿入したり列を入れ替えたりすると、追記される位置や列がずれます。台帳を「自動化が書く場所」と「人が書く場所」に分けておくかどうかで、半年後の姿が変わります。

型3：回答者に自動返信メールを送る

Googleフォームの標準機能にも「回答のコピーを送信」がありますが、文面は固定です。自動化で返信を組むと、回答内容に応じて文面を出し分ける、氏名や会社名を差し込む、HTML形式でロゴやボタンを入れる、といった形が作れます。受付完了の連絡や申込内容の確認のように、届いてすぐ返すことに意味がある場面に向いています。

つまずきやすい所は2つです。1つは送信元で、返信はトリガーを設定した人のアカウントから送られます。個人名のアドレスから受付メールが飛ぶのを避けたいなら、受付用のアカウントで設定するかどうかを先に決めます。もう1つは送信先の数で、Google公式のクォータ表（2026年9月確認）ではメールの送信先は無料アカウントで1日100件、Google Workspaceで1日1,500件、1通あたりの宛先は50までです。回答者への返信と担当者への通知メールを両方送る設計なら、1回の送信で2件を消費します。

型4：条件分岐で担当者に振り分け通知する

「お問い合わせの種類」の選択肢をキーにして、営業に関する質問は営業部へ、技術的な質問はサポート部へ、採用は人事へと通知先を変える形です。人が内容を読んで転送する作業を、選択肢の時点で片づけます。窓口が部署ごとに分かれている会社に向いています。

勘所は、振り分けの対応表をコードの中ではなく別のシートに置くことです。「選択肢」と「宛先」の2列の表を読みに行く形にしておけば、担当者が替わってもコードを触らずに済みます。つまずくのは、対応表にない選択肢が来たときの逃がし先を決めていない場合です。既定の宛先を1つ置いておかないと、該当なしの回答は誰にも届かず、しかもエラーにもならずに黙って落ちます。

型5：回答データをGoogleカレンダーに自動登録する

セミナー申込、面談予約、施設予約のように日時を含む回答は、必ずカレンダーへの登録作業が発生します。希望日時の回答を日付型に変換し、CalendarAppで予定を作り、回答者をゲストに追加する形にすると、招待メールまで自動で飛びます。

安定して動くかどうかは、日時の設問形式でほぼ決まります。フォームの「日付」「時刻」の設問を使えば変換は安定しますが、自由記述で「9/25の15時から」のように書かれると機械には読めません。もう1つ、同じ枠に2件入ることを防ぐ処理はこの型には含まれておらず、型6の照合と組み合わせる設計が要ります。

型6：重複回答を自動チェック・除外する

同じ人が2回送信してしまう、申込が二重に登録される、アンケートの集計が歪む。これを防ぐために、メールアドレスや電話番号をキーにして過去の回答一覧と照合し、重複なら記録用のシートに残して通常の処理をスキップする形です。キーを1項目にするか、会社名と氏名の組み合わせにするかで精度が変わります。

設計で決めるべきは、重複を見つけたときに「止める」のか「印だけ付けて通す」のかです。止めると誤判定のときに正当な申込が消え、通すと後で人が見る必要が残ります。つまずきやすいのは実行時間で、送信のたびに回答一覧を全行読み直す設計は、件数が数千行になると1回あたりの処理が伸びていきます。Google公式のクォータ表（2026年9月確認）にある1回の実行時間6分の上限に、いつ近づくかを件数から見積もっておく必要があります。

型7：回答内容からPDFを自動生成する

受付票、申請書、見積依頼書のように、回答をもとに書類を発行する場面で使う型です。Googleドキュメントのテンプレートを複製し、「{{お名前}}」のような差し込み名を回答で置き換えて、PDFに変換し、メール添付やドライブ保存へ渡す形になります。書類発行の手作業が回答のたびに発生している会社では、この型が1件あたりの時間をいちばん大きく削ります。書類作成の自動化を検討する入口にもなります。

勘所は、フォームの設問名とテンプレートの差し込み名を一致させておくこと、複製したドキュメントを処理後に片づけることの2点です。つまずくのは、テンプレートを誰かが直したときに差し込み名が壊れる場合と、添付の上限です。Google公式のクォータ表（2026年9月確認）では添付は1通あたり250ファイル、合計25MBが上限なので、画像を多く含むPDFを複数添付する設計は先に容量を確かめておきます。

型8：Googleドライブにファイルを自動保存する

フォームのファイルアップロード設問で届いた履歴書、写真、見積書などを、日付と回答者名でフォルダを作って移す形です。アップロードされたファイルはIDの並びとして回答に含まれるので、DriveAppでそのIDを引いて指定のフォルダへ移動します。後から探す人が迷わないことが、この型の価値です。

先に決めるのは、フォルダの命名規則と保存先の権限です。「日付_氏名」にするか「氏名_日付」にするかで、後の並び順と探しやすさが変わります。もう1つ、ファイルアップロード設問は回答者側にGoogleアカウントでのログインを求める仕様なので、社外向けのフォームで使うなら、回答者がその条件を受け入れられるかを先に確かめておきます。

型9：回答データを集計してダッシュボードを自動更新する

申込状況やアンケートの途中経過を常に最新で見たい場面では、送信のたびに件数や種別ごとの内訳を集計シートに書き込み、グラフと組み合わせる形が使えます。共有設定をしておけば、チームの誰もがブラウザから最新の数字を見られます。データ集計・可視化の自動化の入口として、フォームは扱いやすい題材です。

設計で分かれるのは、送信のたびに全件を集計し直すか、日次のトリガーで1日1回にまとめるかです。送信のたびに全件を読む形は件数が増えるほど1回の処理が重くなり、Google公式のクォータ表（2026年9月確認）にあるトリガーの1日合計実行時間、無料アカウント90分・Google Workspace 6時間の枠を削っていきます。つまずきやすいのは、「4列目が種別」のように列の位置で集計を書いてしまい、設問を1つ足した翌日から数字が狂うことです。

型10：外部API連携で他システムに自動データ送信する

回答をCRM、案件管理ツール、基幹システムへ登録する型です。HubSpot、kintone、Salesforce、NotionなどのREST APIに対して、UrlFetchAppで回答を整形して送ります。見込み客の登録や案件の起票が回答から手作業で行われている会社では、転記の二重入力を根本から消せます。

必ず守るべきはAPIキーの置き場所で、コードに直書きせずPropertiesServiceのスクリプトプロパティに保存します。設計で考えるのは、失敗したときの再送です。相手側のAPIは認証の期限切れやレート制限で受け取りを拒むことがあり、そのとき自動化側は何事もなかったように終わります。「送ったつもりで送れていない」を検知する仕組みがないと、この型は最も静かに壊れます。ここは次の章で扱う限界そのものです。

10の型は、どれも自動化の手が届く範囲にあります。届くことと、続くことは別です。自前で組んだ処理が半年後も動いているかどうかは、コードの出来より、次の3つの限界をどう扱ったかで決まります。実行時間の制限、止まったときの気づき方、日次のクォータ。そして3つの底にある「人」の問題です。

限界1：実行時間の制限に当たる

Google公式のクォータ表（2026年9月確認）にあるとおり、自動化には1回の実行に6分という上限があり、超えた処理はそこで打ち切られます。フォーム送信1件の処理は通常数秒で終わりますが、型6の重複チェックや型9の集計のように、送信のたびに回答一覧を全行読み直す設計は、件数が増えるほど1回の処理が伸びます。数百件のうちは気づかず、数千件になった頃に途中で止まり始める、という現れ方をします。

方向としては、送信時に走る処理を「台帳への追記と通知」だけに絞り、重い照合や集計は時間ベースのトリガーで別に回すという分け方があります。ただし、どこで分けるか、分けた処理同士の順序をどう保つかは、フォームの件数と台帳の構造を見ないと決まりません。自前で組むと、この分割は「止まってから」考えることになりがちです。

限界2：止まったことに誰も気づけない

フォーム送信で動く処理がエラーで止まると、回答者に返信が届かない、台帳に行が増えない、担当者に通知が来ない、という実害がそのまま出ます。しかも、止まったことを知らせてくれる人はいません。回答者は「返事がない」と思うだけで、社内は「今日は申込が少ない」と思うだけです。気づくのは、回答者から催促が来たときか、月末の集計で件数が合わないときになります。

対策の方向は、処理全体を例外の捕捉で包み、失敗したときに管理者へメールやチャットで知らせる形です。加えて、スクリプトエディタの実行ログを定期的に見る習慣が要ります。ここで難しいのは仕組みではなく運用で、「通知を誰が見るか」「見た人が直せるか」が決まっていなければ、通知が飛んでも止まったままです。自前で組んだ処理は、この2つが決まらないまま動き始めがちです。

限界3：日次のクォータを超える

自動化には1日あたりのサービス利用上限があり、無料アカウントとGoogle Workspaceで枠が異なります。Google Apps Script 公式ドキュメント「Quotas for Google Services」（2026年9月確認）の値を、フォーム連携で関係の深い項目に絞って並べます。原文には、これらの上限は予告なく撤廃・削減・変更されうるという注記があり、組む時点で最新値を確かめる前提の数字です。

表を見ると、日常の受付件数で当たりやすいのはメールの送信先とトリガーの合計実行時間の2つだと分かります。無料アカウントで型3の自動返信と担当者通知を両方送る設計なら、1日50件の回答でGoogle公式のクォータ表にある送信先の上限100件に達します。上限に達した後の回答をどう扱うか、翌日に回すのか人が送るのかまで決めておかないと、月末や繁忙期にだけ止まる処理になります。

3つの限界の底にあるのは「組んだ人しか直せない」こと

実行時間も、気づき方も、クォータも、仕組みとしては対処できます。それでも自前の処理が止まったままになるのは、直せる人が社内に1人しかいない、あるいはもういないからです。トリガーは設定した人のアカウントに紐づいて動くため、その人の異動や退職で処理そのものが止まり、コードの中身を読める人が残っていなければ、そこで受付は手作業に戻ります。

この構造は個社の事情ではなく、規模の問題として数字に出ています。IPA「DX動向2026調査のポイント」（2026年7月公表、2026年9月確認）によると、DXを推進する人材の「量」が不足している（やや不足と大幅に不足の合計）と答えた企業は85.5%で、この値は3年横ばいです。AI導入の実施率も規模差が大きく、1,001人以上の企業は8割近くが導入している一方、101人以下では16.6%にとどまります。一方で、導入した企業が挙げる具体的な効果は効率化・迅速化が91.6%、企画提案の品質向上が48.9%、残業削減が29.2%で、効果自体は出ています。効果は出るのに担い手が足りない。フォーム連携の自動化が「組んだ人しか直せない」状態で残るのは、この構造がそのまま1つの会社の中で起きているからです。BoostXがAI顧問として中小企業のAI導入を支援するなかで大切にしているのは、コードそのものより先に、何をきっかけに何をどこへ渡しているかを組んだ本人以外が読める形で残すことです。

商工中金の同じ調査（2026年3月公表）でも、導入を検討する段階の課題の最多は「導入を推進する人材がいない」で3割強、導入した後の課題の最多は「社内ルールや方針整備」で4分の1でした。組む前は人がいない、組んだ後はルールがない。自前の自動化が抱える限界は、この2つの間に落ちています。

ここでは、申込フォームに週25件（平日1日5件）の回答が届き、1件あたりの確認・転記・返信に5分かかっている受付を前提に話を進めます。自社の件数や所要時間がこれと違うなら当てはまらない部分が出ますが、転記が消えたときに週の中で何が変わるかの構造は同じです。

違いを生むのはコードではなく、止まったときの設計

BeforeとAfterの差を数えると、転記と返信に使う時間は週125分から0分へ、人が使う時間は週125分から例外対応の20分程度へ、差し引き週105分程度が浮きます。4週で420分、月に7時間程度が、他の仕事に回る計算です。返信までの待ち時間は数時間から翌営業日だったものが送信直後になり、見落としは「起きうる」から「通知が残る」に変わります。数字はこの前提での目安ですが、件数が増えるほど差が広がる方向は変わりません。

ただし、Afterの1週間が半年後も続いているかどうかは、コードの出来では決まりません。設問名を変えないルールがあるか、止まったときに通知が誰に届くか、トリガーを設定した人が抜けても動く構成か。この3つが決まっているAfterと、決まっていないAfterは、動き始めた週は同じに見えます。違いが出るのは、フォームを少し直した翌日や、担当者が替わった月です。転記が消えることの価値は、消えた状態が続いて初めて手元に残ります。

Before寄りの会社が動き出すなら、10の型を全部組む必要はありません。回答が届いた後に人がしていることを1件分だけ書き出し、そのうち「毎回同じで、判断が要らない」作業を1つ選ぶ。それが転記なら型2、返信なら型3から入り、動いた状態を1か月見てから次の型を足す。この順序なら、上限にも、止まったときの気づき方にも、小さいうちに当たれます。