受発注処理をGASで自動化する5ステップ｜FAX・メール・電話を一元化【2026年版】

FAX注文書をスプレッドシートに転記して、メール注文をまた別の形式で打ち直して、夕方には電話注文を思い出して入力する。気づいたら受発注処理だけで一日が終わっていた。中小企業で実際に経理担当者から聞いた現場の声です。

本記事では、受発注処理をGoogle Apps Script（GAS）で自動化する具体的な実装手順と、実装後に陥りやすい失敗パターン、そして導入後に効果を継続させるための運用ポイントまでを順を追って解説します。

スプレッドシートと無料で連携できるGASは、追加システム導入が難しい中小企業の受発注業務に最も適した自動化ツールです。

受発注処理に潜む「見えないコスト」と中小企業の現状

本記事のテーマに関連するサービスとして、BoostXではAI自動化の支援を提供しています。

受発注処理は、売上に直結する反面、効果や工数が経営層から見えにくい業務です。請求書・発注書・納品書の照合、注文データの転記、在庫との突合といった作業は、エラーの一次防衛線でありながら属人化しやすい領域でもあります。

中小企業の経理担当が実際に抱える工数

弊社が支援したある中小企業の経理担当者は、取引先50社以上・月100件超の請求書・発注書・納品書を目視でチェックし、月8時間以上を突合作業に費やしていました（出典：BoostX一次情報DB登録の社内実態調査・許容誤差は消費税端数±1円／品名類似度80%以上／請求日30日以内）。「気合いと残業で回している」状態は、人が辞めた瞬間に止まる業務でもあります。

なぜ手作業の受発注処理は壊れるのか

受発注の手作業がリスクとして顕在化するのは、注文経路がFAX・メール・電話・EDIと分散したときです。同じ注文情報を複数のツールに転記する瞬間に、桁違い・型番違い・納期違いといった人的ミスが入り込みます。中小企業の場合、ダブルチェックの工数すら捻出できず、「受注ミスは出荷後に発覚する」のが実態です。

GASで自動化できる受発注処理の範囲とできないこと

受発注処理の自動化は、いきなり全工程を狙うと必ず失敗します。GASで効果が出やすい範囲を見極めることが、最初に決めるべき設計です。

GASで自動化に向く処理

スプレッドシートに集まった注文データを、決まったルールで整形・転記・通知する処理はGASの得意領域です。具体的には、メール本文の自動パース、Googleフォームからの注文受付、注文一覧シートからの発注書PDF自動生成、Slackやメールでの社内通知、freee・kintone・HubSpotとのAPI連携といった処理が中心になります。Google Workspace を中心に運用している中小企業であれば、追加コストほぼゼロで導入できる点が他のRPA・自動化ツールと比較しても優位です（出典：BoostX一次情報DB登録の自社実装構成／Google Spreadsheet＋GAS中心構成）。

GASでは自動化しないほうが良い処理

紙のFAX注文書のOCR、複雑な値引き計算、与信判断、在庫の引き当てロジックといった「判断が伴う処理」は、GAS単体では脆弱です。OCR精度の揺らぎや業務ルールの例外を吸収できず、誤発注を量産する危険があります。これらは別途、AI-OCRサービスや基幹システム側に任せ、GASは「受け取った構造化データを動かす」役割に絞り込みます。

範囲設計の判断基準

「ルールが文章で書ける処理だけGASに任せる」が判断基準です。例外パターンが3つを超える業務は、自動化前にまず業務ルール側を整理する必要があります。受発注の現場で「この場合だけは別」が連発する業務は、GAS実装に進む前に立ち止まることが、結果的に自動化を成功させる近道になります。

受発注GAS自動化の実装手順5ステップ

ここからは、受発注処理をGASで自動化する実装手順を5ステップで具体的に解説します。スプレッドシートをハブにして、注文受付から社内通知・帳票出力までを一気通貫で組む構成です。

ステップ1：注文データの入口をスプレッドシートに統一する

まずは注文データの入口を1枚のシートに統一します。Googleフォーム経由の注文はそのままシートに蓄積、メール注文はGmailのフィルタとGASの onChange 連携でシートに自動転記、FAX注文は当面は手入力ですが「同じシートに同じ列構成で貯める」運用を徹底します。データの形が揃った瞬間に、GASでできることが一気に増えます。

ステップ2：注文行のバリデーションを onEdit で組む

注文が1行増えるたびに、GASの onEdit トリガーで以下のチェックを自動実行します。商品コードがマスタに存在するか、数量が0や負数になっていないか、納期が今日より過去になっていないか、取引先が与信OKリストに載っているか。引っかかった行は背景色を赤、ステータス列を「要確認」にして、即座に視認できる状態にします。

ステップ3：発注書・受注書PDFの自動生成と保存

バリデーションを通過した行に対し、GASでGoogleドキュメントのテンプレートを差し込み生成し、PDF化してGoogleドライブの取引先別フォルダに自動保存します。ファイル名は「YYYYMMDD_取引先名_受注番号.pdf」のような検索しやすい命名規則に固定します。経理・営業・倉庫がそれぞれの作業を、同じ1枚のPDFを基準に進められるようになります。

ステップ4：社内通知と取引先連絡の自動化

PDFが生成されたタイミングで、Slackの担当者チャンネルに「受注番号・取引先・商品・納期」を整形して自動投稿します。同時に、取引先には注文確認メールをGASのMailApp経由で自動送信。手動でやっていたリマインドや控えメールが、注文発生から数秒以内に必ず飛ぶ状態になります。受注ミスの大半は「送ったつもり」「届いたつもり」で発生するため、ここを機械に任せるだけで品質が大きく上がります。

ステップ5：基幹システム連携と日次サマリ

最後に、freee や kintone、HubSpot などの基幹システム側にAPI連携で注文データを反映します。リアルタイム連携が難しければ、まずは日次バッチで十分です。あわせて、当日の受注件数・金額・要確認件数を毎朝Slackに自動投稿する「日次サマリ」を組むことで、現場と経営の両方が数字をリアルタイムに把握できる体制になります。

実装で陥りやすい3つの失敗と回避策

GAS自動化は、組み始めてから半年〜1年で必ず壊れます。前提として「壊れる」ことを織り込んで設計することが、本当の意味での自動化定着につながります。

失敗1：トリガーの実行回数上限を見落とす

GASは無料アカウントの場合、1日のトリガー実行時間や送信メール件数に上限があります。受注件数が増えてくると、ある日突然 onEdit が止まり、注文が一切通知されなくなります。回避策はGoogle Workspace 有料プランへの移行と、実行ログをスプレッドシートに必ず残し、日次で件数を監視する仕組みをセットにすることです。

失敗2：マスタ更新の運用ルールが定まっていない

商品マスタや取引先マスタの更新を「気づいた人が直す」運用にすると、受注バリデーションが誤検知だらけになります。マスタ更新は週次で担当者を1人に固定し、「いつ・誰が・何を更新したか」を別シートに自動記録するGASを組んでおくことで、後から原因追跡できる状態を保ちます。

失敗3：例外処理を本人の頭の中に残す

「この取引先だけは特別ルール」「この商品だけは納期計算が違う」といった例外を、担当者の頭の中だけに残すと、退職と同時にブラックボックス化します。受発注処理のGAS化に着手するタイミングで、例外ルールはすべてスプレッドシートの「業務ルール台帳」に文書化します。GAS本体ではなく外部シートを参照する設計にしておくと、ルール変更のたびにコードを直す必要がなくなります。

導入後の運用と継続改善のポイント

GAS自動化は、導入した瞬間がスタートです。運用フェーズに入ってからの設計が、効果を継続させるか・形骸化するかを分けます。

月次レビューで「使われていない処理」を見つける

毎月1回、自動化された各処理の実行ログを確認し、想定通り回っているか、現場が手作業に戻していないかを点検します。手作業に戻している処理があれば、それは要件設計のミスか、現場で例外が発生している証拠です。GASをリファクタリングするきっかけになります。

小さく作って、月単位で拡張する

最初から完璧な受発注自動化を目指すと、要件定義だけで数ヶ月が消えます。まずは「メール注文の整形と通知」だけを2週間で完成させ、現場で1ヶ月運用してから、次のスコープを追加する進め方が現実的です。完成度より、回り続ける状態を優先します。

担当者を1人に依存させない

GASのコードを書ける人が社内に1人しかいない状態は、属人化を業務からコードに移し替えただけです。スクリプトの仕様書をGoogleドキュメントに残し、月1回のコードレビューを別担当者と実施する運用を組み込みます。受発注の自動化は、技術ではなく組織の話だと割り切ることが、長く回し続ける条件になります。

よくある質問