GASで発注フォームを作ると何が便利になるのか｜中小企業の業務改善例

発注業務は、会社によってやり方が大きく違います。

メールで発注を受ける会社もあれば、電話で受けてからExcelに入力している会社もあります。Googleスプレッドシートで一覧管理しているものの、発注番号の付与、担当者への連絡、発注書PDFの作成は手作業というケースもあります。

こうした運用は、最初は問題なく回ります。しかし件数が増えると、確認漏れ、転記ミス、連絡遅れ、ファイルの探しにくさが目立つようになります。

GAS（Google Apps Script）を使うと、発注フォームから送信された内容をスプレッドシートに保存し、発注Noを付け、担当者へ通知し、必要に応じてPDF発注書を作る流れを自動化できます。

この記事では、GASで発注フォームを作ると何が便利になるのかを、実務目線で整理します。コードの細かい話ではなく、中小企業の発注業務でどのように役立つのかを中心に解説します。

1. この記事で伝えたいこと

GASで発注フォームを作る目的は、発注業務をいきなり大きなシステムに置き換えることではありません。

まずは、今あるスプレッドシート運用を活かしながら、手作業が多い部分を小さく自動化することです。

たとえば、発注内容をメールで受け取り、担当者が内容を確認して、スプレッドシートに転記し、発注番号を付け、担当者へ連絡し、必要なら発注書をPDFで作る。この流れをすべて人が行っていると、件数が少なくても地味に時間がかかります。

GASを使うと、フォーム送信をきっかけに次のような処理をまとめて行えます。

• 発注内容をスプレッドシートに保存する
• 発注Noを自動で付ける
• 担当者や管理者へメール通知する
• 顧客や取引先へ受付メールを送る
• 必要に応じてPDF発注書を作成する
• 添付ファイルをGoogleドライブに保存する
• ステータスや対応履歴を一覧で確認する

もちろん、GASを使えばすべての発注業務が完璧になるわけではありません。大量の発注をリアルタイムに処理する仕組みや、在庫・会計システムと厳密に連携する仕組みでは、別のシステムを検討した方がよい場合もあります。

それでも、毎日の手作業を減らし、発注内容を整理し、確認漏れを防ぐための小さな改善には、GASは使いやすい選択肢です。

たとえば、フォーム送信後にスプレッドシートへ行を追加するだけでも、メールを見ながら転記する作業は減ります。そこに発注No、自動通知、PDF発注書、添付ファイル保存、ステータス管理を少しずつ追加すると、発注業務全体の流れを整えやすくなります。

GASは、今あるGoogleスプレッドシートを活かして小さく始められる点が強みです。一方で、発注業務は社内外の連絡や納期に関わるため、入力ミス、通知漏れ、権限設定、保守担当まで含めて設計しておく必要があります。

2. 発注業務でよく起きる困りごと

発注業務では、入力、確認、連絡、保存、帳票作成が何度も発生します。

たとえば、取引先からメールで発注内容が届いた場合、担当者はメールを開いて内容を確認し、必要な情報をスプレッドシートへ転記します。その後、発注番号を付け、関係者へ連絡し、場合によっては発注書や控えを作ります。

この運用でよく起きるのが、転記ミスです。

商品名、数量、納期、金額、送付先などを手入力していると、どうしても入力ミスが発生します。メールに書かれている内容を見ながら別の画面に入力するため、数字の桁や日付を間違えることもあります。

確認漏れも起きやすくなります。

メールや電話で受けた発注は、担当者が気付かなければ処理が進みません。忙しい時間帯に届いたメールが埋もれたり、担当者が休みだったりすると、対応が遅れることがあります。

発注番号の管理も手作業だと面倒です。

連番を人が付けている場合、同じ番号を使ってしまう、番号が飛ぶ、どの発注にどの番号を付けたのか分かりにくくなる、といった問題が出ます。

PDF作成や控えの保存にも時間がかかります。

発注書テンプレートを開き、発注内容を入力し、PDFとして保存し、ファイル名を付け、メールに添付する。この作業を毎回行うと、1件あたり数分でも積み重なります。

さらに、添付ファイルや備考がメールの中に散らばると、後から探しにくくなります。

「あの発注の仕様書はどのメールに添付されていたか」「最新版のファイルはどこか」「誰がいつ確認したか」が分かりにくいと、確認作業だけで時間を取られます。

発注内容の確認状況が見えないこともよくあります。受付は済んでいるのか、担当者が確認中なのか、取引先へ発注済みなのか、納品待ちなのかが一覧で分からないと、関係者が何度も確認することになります。

担当者への連絡漏れも問題です。メールで発注を受けた場合、担当者がメールを見落とすと処理が進みません。チャットで連絡している場合も、投稿が流れてしまうと、誰が対応するのか分からなくなることがあります。

また、履歴が残らない運用では、後から経緯を追いにくくなります。いつ受け付けたのか、誰が確認したのか、いつPDFを作ったのか、誰に通知したのかが分からないと、問い合わせ対応に時間がかかります。発注フォームを作るなら、入力データだけでなく、処理履歴も残す前提で考えると実務で使いやすくなります。

3. GASで発注フォームを作るとできること

GASで発注フォームを作ると、発注受付から保存、通知、帳票作成までを一つの流れにできます。

基本的な流れは、次のような形です。

• 入力者が発注フォームに必要事項を入力する
• 送信された内容をGASが受け取る
• スプレッドシートに発注内容を保存する
• 発注Noを自動採番する
• 担当者や管理者へメール通知する
• 必要に応じてPDF発注書を作成する
• PDFや添付ファイルをGoogleドライブに保存する

発注フォームは、Googleフォームでも作れます。ただし、業務に合わせた見た目や入力制御が必要な場合は、HTMLフォームとして作る方法もあります。

HTMLフォームにすると、会社名、担当者名、商品、数量、納期、備考、添付ファイルなどを業務に合わせて配置できます。入力内容に応じて項目を出し分けたり、送信前に確認画面を挟んだりすることもできます。

送信された内容は、スプレッドシートに自動保存できます。

発注日、発注No、会社名、商品名、数量、納期、ステータス、担当者、備考などを一覧にしておけば、後から検索しやすくなります。発注内容がメール、紙、個人のメモに分散しにくくなります。

発注Noの自動採番も便利です。

たとえば、PO-202605-001 のように年月と連番を組み合わせた番号を自動で付ければ、管理しやすくなります。人が番号を付ける必要がなくなるため、重複や付け忘れも減らせます。

メール通知も自動化できます。

フォームが送信されたら、担当者へ「新しい発注が入りました」と通知する。入力者へ「発注を受け付けました」と控えメールを送る。管理者へ重要な発注だけ通知する。このような処理を、発注内容に応じて分けることもできます。

PDF発注書の作成にもつなげられます。

スプレッドシートやGoogleドキュメントのテンプレートに発注内容を差し込み、PDFとしてGoogleドライブに保存する流れを作れます。必要であれば、そのPDFをメールに添付して送ることもできます。

ステータス管理も組み合わせられます。たとえば、フォーム送信直後は「受付済み」、担当者が内容を見たら「確認中」、取引先へ送ったら「発注済み」、納品が終わったら「完了」といった形です。ステータスを持たせると、発注一覧を見るだけでどこで止まっているのかが分かります。

履歴シートを分けておくこともできます。現在の発注一覧とは別に、ステータス変更、通知送信、PDF作成、添付ファイル保存などを履歴として追記しておくと、後から確認しやすくなります。トラブル時に「いつ誰が何をしたか」を追えることは、業務ツールでは大きな安心材料です。

添付ファイルを扱う場合は、フォームから受け取ったファイルをGoogleドライブへ保存し、そのURLをスプレッドシートに記録できます。メールの添付を探すのではなく、発注一覧から関連ファイルへ移動できるようになるため、確認作業を減らしやすくなります。

4. GoogleフォームではなくHTMLフォームを使う理由

発注受付だけであれば、Googleフォームでも十分な場合があります。

Googleフォームは作成が簡単で、回答をスプレッドシートに保存できます。社内アンケート、簡単な申請、項目数が少ない受付であれば、Googleフォームの方が早く始められます。

一方で、発注業務ではHTMLフォームの方が合う場面もあります。

たとえば、入力画面の見た目を業務に合わせたい場合です。

発注フォームでは、会社情報、発注内容、納品先、添付ファイル、備考など、入力項目が多くなりがちです。HTMLフォームであれば、項目をグループ分けしたり、画面上の説明文を細かく調整したりできます。

確認画面を入れたい場合にも向いています。

発注内容は、数量や納期の間違いがそのまま業務に影響します。送信前に確認画面を表示し、「この内容で送信してよいか」を確認できるようにすると、入力ミスを減らしやすくなります。

入力制御を細かくしたい場合にも便利です。

商品を選んだら関連する項目だけ表示する、部署によって通知先を変える、必須項目の条件を変える、添付ファイルの有無でメッセージを変える、といった動きは、HTMLフォームの方が作り込みやすいです。

ただし、何でもHTMLフォームにすればよいわけではありません。

項目が少なく、社内だけで使い、見た目や入力制御にこだわらない場合は、Googleフォームで十分です。大切なのは、業務に必要な自由度と、作成・保守の手間のバランスを考えることです。

Googleフォームが向いているのは、入力項目が比較的単純で、回答を集めることが主目的の場合です。たとえば、社内の簡単な発注依頼、備品申請、単発の受付などであれば、Googleフォームの方が早く導入できます。

HTMLフォームが向いているのは、入力の流れを業務に合わせたい場合です。商品カテゴリによって入力項目を変える、数量や納期に応じて注意文を出す、送信前に確認画面を出す、入力者の部署によって通知先を変える、といった要件があるなら、HTMLフォームの方が柔軟です。

発注フォームでは、入力ミスを防ぐための制御も重要です。数量は数値だけにする、納期は日付で選ばせる、メールアドレス形式を確認する、必須項目が未入力なら送信できないようにする。こうした基本的な入力チェックだけでも、後工程の確認負担を減らせます。

一方で、HTMLフォームは作り込みすぎると保守が重くなります。項目追加や文言修正を誰が行うのか、商品リストや通知先をコードではなく設定シートで変えられるようにするのかを、最初に考えておくと運用しやすくなります。

5. 発注フォームをGASで作るメリット

発注フォームをGASで作る一番のメリットは、手作業の流れを減らせることです。

フォームに入力された内容がそのままスプレッドシートに保存されれば、メールを見ながら転記する作業が減ります。転記が減れば、入力ミスや確認漏れも減らしやすくなります。

発注内容が一か所に集まることも大きなメリットです。

メール、電話メモ、紙、個人のExcelに分散していると、後から確認するだけで時間がかかります。スプレッドシートに集約すれば、発注日、取引先、商品、ステータス、担当者などで探しやすくなります。

受付から通知までの時間も短くできます。

人がメールを確認してから担当者に連絡する運用では、どうしてもタイムラグが出ます。フォーム送信時に自動通知すれば、担当者は発注が入ったことに早く気付けます。

発注書PDFや控えメールを自動化できる点も便利です。

毎回同じ形式の発注書を作っている場合、テンプレートに内容を差し込んでPDF化する仕組みを作ると、作成時間を減らせます。控えメールも自動で送れば、入力者側にも記録が残ります。

ステータス管理にもつなげやすくなります。

スプレッドシートに「受付済み」「確認中」「発注済み」「完了」などのステータス列を用意すれば、今どこまで進んでいるかを一覧で見られます。担当者別、期日別、未対応だけの抽出もしやすくなります。

さらに、小さく作って後から改善しやすいのもGASの利点です。

最初は、フォーム受付、スプレッドシート保存、メール通知だけで始める。運用してみて必要になったら、PDF発注書、添付ファイル保存、ステータス通知、月次集計を追加する。このように段階的に広げられます。

発注Noを自動採番できることも、実務では大きなメリットです。人が番号を付ける運用では、重複や抜けが起きやすくなります。GASで年月や連番を組み合わせて採番すれば、発注一覧、PDF、保存フォルダ、メール通知を同じ番号で結びつけられます。

メール通知を自動化すると、初動も早くなります。フォーム送信と同時に担当者へ通知されれば、発注メールを探す時間が減ります。通知文に発注No、取引先名、商品名、納期、発注一覧へのリンクを入れておけば、担当者はすぐに内容を確認できます。

PDF発注書を自動作成できると、正式な控えを残しやすくなります。テンプレートに発注内容を差し込み、発注Noをファイル名に含めて保存すれば、後から探しやすくなります。必要に応じて、PDF URLをスプレッドシートへ記録し、一覧から開けるようにします。

ステータス管理を加えると、発注後の追跡もしやすくなります。受付済み、確認中、発注済み、納品待ち、完了、保留などを一覧で管理すれば、未対応や遅れを見つけやすくなります。担当者別、期日別、ステータス別に絞り込むだけでも、管理者の確認時間を減らせます。

6. 導入前に決めておきたいこと

発注フォームを作る前に、業務ルールを整理しておくことが大切です。

まず、誰が入力するのかを決めます。

社内担当者だけが入力するのか、取引先にも入力してもらうのかで、フォームの作り方や公開範囲が変わります。外部の人が使う場合は、見た目、説明文、入力ミスへの対応も重要になります。

次に、どの項目を必須にするかを決めます。

会社名、担当者名、商品名、数量、納期、送付先、メールアドレスなど、業務上必要な項目を整理します。必須項目が多すぎると入力しにくくなりますが、少なすぎると確認の手間が残ります。

発注Noのルールも決めておきます。

年月を入れるのか、取引先コードを入れるのか、単純な連番にするのか。後から変更すると過去データとの整合性が取りにくくなるため、最初に決めておくと安心です。

通知先も重要です。

すべての発注を同じ担当者へ送るのか、商品や部署によって通知先を変えるのか、管理者にも控えを送るのかを整理します。通知が多すぎると見落とされやすくなるため、本当に必要な通知に絞ることも大切です。

PDF発注書が必要かどうかも確認します。

社内確認だけならスプレッドシートの一覧で十分かもしれません。取引先へ正式な発注書を送る必要がある場合は、PDFテンプレートやファイル名のルールを決めておきます。

添付ファイルを扱うかどうかも検討します。

仕様書、図面、見積書、画像などを一緒に受け付ける場合は、保存先フォルダやファイル名の付け方を決めておく必要があります。

最後に、誰が管理し、誰が保守するのかを決めます。

スプレッドシートの所有者、GASプロジェクトの所有者、エラー時の連絡先、フォーム項目を変更する担当者を曖昧にしたまま運用すると、担当者変更や退職時に困ります。

ステータスの種類も導入前に決めておきます。受付済み、確認中、発注済み、納品待ち、完了など、業務の流れに合った言葉にします。細かくしすぎると入力者が迷うため、最初は少ない状態から始める方が運用しやすいです。

通知ルールも整理します。すべての発注を全員に通知すると、通知が多すぎて見落とされることがあります。商品カテゴリ、部署、金額、納期などによって通知先を分けるのか、管理者には日次サマリーだけ送るのかを決めておくとよいです。

添付ファイルを扱う場合は、保存先と共有範囲を決めます。取引先の資料や図面には、社外秘の情報が含まれることがあります。Googleドライブのフォルダを誰が見られるのか、発注一覧から誰がアクセスできるのかを確認しておく必要があります。

PDF発注書を作る場合は、テンプレートとファイル名のルールも決めます。会社名、発注No、発注日、取引先名、明細、納期、納品先など、どの項目を入れるかを整理します。ファイル名には発注Noや取引先名を入れると、後から検索しやすくなります。

エラー対応も考えておきます。フォーム送信はできたが通知に失敗した、PDF作成に失敗した、といった場合に、誰へ知らせるのか、どこにエラーを記録するのかを決めます。

7. GASだけで作る場合の注意点

GASの発注フォームは便利ですが、向いていない使い方もあります。

まず、大量アクセスや大量データを扱う場合です。

月に数十件から数百件程度の発注を管理するなら、GASとスプレッドシートで十分な場合があります。しかし、毎日大量の発注が入り、複数人が同時に更新し、検索や集計も多い場合は、スプレッドシートだけでは重くなる可能性があります。

在庫管理や会計システムと複雑に連携する場合も注意が必要です。

発注を受けた瞬間に在庫を引き当てる、会計データと同期する、基幹システムへリアルタイムに反映する、といった処理は、GASだけで簡単に作れるとは限りません。必要に応じて外部DBや専用システムとの連携を検討します。

厳密な権限管理が必要な場合も慎重に考えます。

取引先ごとに見えるデータを分ける、部署ごとに編集できる範囲を変える、承認者だけが特定の操作をできるようにする、といった要件がある場合は、最初から設計を丁寧に行う必要があります。

個人アカウント所有のまま運用しないことも重要です。

担当者個人のGoogleアカウントでGASやスプレッドシートを作り、そのまま会社の業務で使い続けると、退職や異動のときに引き継ぎで困ることがあります。会社や顧客の運用に合わせて、所有者と権限を決めておくべきです。

また、保守の前提も必要です。

発注フォームは作って終わりではありません。商品項目が変わる、通知先が変わる、PDFの文言を変える、入力項目を増やす、エラーが出る、といった変更が起きます。誰がどこまで対応するのかを決めておくと、運用が安定しやすくなります。

重要業務では、手作業で戻せる運用も残しておくと安心です。

GASの処理が止まったときに、発注受付そのものが完全に止まると困ります。急ぎの発注はメールで受ける、エラー時は手動でスプレッドシートに登録する、といった代替手段を決めておくと、現場で慌てにくくなります。

GASの実行時間や同時実行にも注意が必要です。発注フォームの送信時に、採番、保存、通知、PDF作成、添付ファイル保存をすべて行うと、処理が重くなることがあります。件数が増える場合は、受付時には保存と通知だけ行い、PDF作成は後から処理するなど、処理を分ける設計も検討します。

発注Noの採番では、同時送信への対策も必要です。複数人が同じタイミングでフォームを送ると、単純な連番処理では番号が重複する可能性があります。必要に応じてLockServiceを使う、採番用シートを用意する、タイムスタンプを組み合わせるなどの工夫が必要です。

外部の取引先にフォームを使ってもらう場合は、公開範囲を慎重に決めます。URLを知っていれば誰でも送信できる設定にするのか、Googleアカウントで制限するのかによって、使いやすさと安全性が変わります。社外向けフォームでは、誤送信や不要な送信への対応も考えておく必要があります。

保守面では、商品項目、通知先、PDF文面、担当者一覧が変わることを前提にします。これらをコード内に直接書くと、変更のたびに開発者対応が必要になります。設定シートで管理できる項目を増やしておくと、現場での軽微な変更に対応しやすくなります。

8. 小さく始める導入ステップ

発注フォームの自動化は、最初からすべてを作り込むより、小さく始める方が定着しやすくなります。

最初のステップは、現在の発注受付方法を整理することです。どの情報をメールや電話で受けているのか、誰が転記しているのか、発注Noをどう付けているのか、PDF発注書が必要なのかを確認します。

次に、フォーム受付とスプレッドシート保存だけを作ります。会社名、担当者、商品、数量、納期、備考など、最低限必要な項目に絞り、送信内容が一覧に残る状態を作ります。この段階でも、メールからの転記はかなり減らせます。

3つ目は、自動通知を追加することです。フォーム送信時に担当者へ通知し、入力者には受付メールを送ります。通知文には発注Noや一覧へのリンクを入れ、担当者がすぐ確認できるようにします。

4つ目は、発注Noとステータス管理を整えることです。発注Noを自動採番し、受付済み、確認中、発注済み、完了などのステータスを管理します。これにより、どの発注が未対応なのかを一覧で確認できます。

5つ目は、PDF発注書や添付ファイル保存を追加することです。正式な発注書が必要な場合は、テンプレートに内容を差し込んでPDF化します。仕様書や図面がある場合は、発注Noと紐づけてGoogleドライブへ保存します。

最後に、保守と権限を整理します。フォーム項目を誰が変えるのか、通知先を誰が管理するのか、エラーが出たら誰が確認するのか、スプレッドシートやドライブを誰が所有するのかを決めます。

このように段階を分ければ、現場に負担をかけすぎずに発注業務を整えられます。

9. まとめ

GASで発注フォームを作ると、発注業務の受付、保存、通知、PDF作成、履歴管理を小さく自動化できます。

特に、メールや電話で受けた発注を手入力している、発注番号を手作業で付けている、担当者への連絡が遅れやすい、発注書PDFを毎回手作業で作っている、といった場合は改善しやすいです。

最初から大きな受発注システムを作る必要はありません。

まずは、フォームから入力された内容をスプレッドシートに保存し、担当者へ通知するところから始めるだけでも、確認漏れや転記作業を減らせます。必要になった段階で、発注Noの採番、PDF発注書、添付ファイル保存、ステータス管理を追加していけばよいです。

一方で、大量データ、複雑な在庫連携、厳密な権限管理、停止できない重要業務では、GASだけで作るべきか慎重に考える必要があります。

GASの発注フォームは、今あるスプレッドシート運用を活かしながら、発注業務を少しずつ整えるための現実的な選択肢です。まずは、毎回同じように行っている受付、転記、通知、PDF作成のどこを減らせるかを整理すると、導入しやすい範囲が見えてきます。

発注フォームは、単なる入力画面ではありません。入力された内容を正しく保存し、必要な人へ知らせ、履歴として残し、後から確認できるようにするための入口です。

GASを使えば、発注受付、スプレッドシート保存、発注No採番、メール通知、PDF作成、添付ファイル保存を段階的に追加できます。ただし、発注業務は取引先や納期に関わるため、権限、保守、エラー時の代替運用も一緒に考える必要があります。

まずは小さく始め、現場で使いながら改善していく。この進め方なら、中小企業でも大きなシステムを導入する前に、日々の発注業務を着実に整えられます。