GASで請求書送信を自動化する方法：PDF作成・メール送信・履歴管理までの考え方

請求書の作成と送信は、毎月くり返し発生する業務です。

請求データを確認し、請求書テンプレートに転記し、PDFとして保存し、メールに添付し、送信済みかどうかを記録する。ひとつひとつは難しくなくても、件数が増えると確認に時間がかかります。

特に、請求書は金額や宛先の間違いが業務上のトラブルにつながりやすい書類です。送信を急ぐあまり、古いPDFを添付したり、宛先を間違えたり、送信済みの記録を残し忘れたりすると、後から確認するだけでも大きな手間になります。

GAS（Google Apps Script）を使うと、スプレッドシートにある請求データをもとに請求書PDFを作成し、Googleドライブへ保存し、Gmailで送信し、送信履歴を残す流れを自動化できます。

この記事では、GASで請求書送信システムを作るときの考え方を、実務目線で整理します。コードの細かい話ではなく、中小企業の請求業務でどのように役立つのかを中心に解説します。

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

GASで請求書送信システムを作る目的は、請求業務をすべて自動で終わらせることではありません。

大切なのは、毎月くり返している定型作業を減らし、確認すべきところを確認しやすくすることです。

たとえば、請求金額を確認し、請求書をPDFで作成し、顧客ごとにメールを作り、PDFを添付し、送信後に「いつ、誰に、何を送ったか」を記録する。この流れをすべて手作業で行っていると、件数が少なくても気を使います。

GASを使うと、請求データを起点に次のような処理をまとめて行えます。

• 請求データをスプレッドシートで管理する
• 請求書テンプレートへ内容を差し込む
• 請求書をPDFとして作成する
• PDFをGoogleドライブに保存する
• 顧客ごとにメール本文を作る
• 請求書PDFを添付して送信する
• 送信日時や送信先を履歴として残す

もちろん、請求書送信は何でも自動化すればよいわけではありません。請求金額の確定、宛先の確認、送信前の承認など、人が判断すべき工程もあります。

そのため、GASで作る場合は「自動で送る仕組み」だけでなく、「送ってよい状態を確認できる仕組み」として考えることが重要です。

請求書送信の自動化で大切なのは、担当者の確認をなくすことではありません。確認すべき項目を見やすくし、毎月同じ作業を同じ手順で進められるようにすることです。

たとえば、請求金額が確定していない行は処理対象にしない、PDF作成済みでも未承認なら送信しない、送信済みの行は再送確認なしに送らない、といった制御があるだけで、運用の安心感は大きく変わります。

GASは、スプレッドシート、Googleドキュメント、Googleドライブ、Gmailをつなげやすいため、請求業務の小さな自動化に向いています。一方で、請求書は社外へ出る正式な書類なので、便利さだけでなく、確認、承認、履歴、権限をセットで考える必要があります。

2. 請求書送信でよく起きる困りごと

請求書送信では、作成、保存、添付、送信、記録の作業が何度も発生します。

たとえば、月末に請求一覧を確認し、顧客ごとに請求書を作り、PDFに変換して、メールに添付して送る。送信後は、別の表に送信済みと記録する。この流れを手作業で行っている会社は少なくありません。

この運用でまず起きやすいのが、転記ミスです。

請求金額、請求日、支払期限、顧客名、担当者名などをテンプレートへ手入力していると、数字や日付の間違いが起こります。前月の請求書をコピーして使っている場合、古い月や古い金額が残ることもあります。

PDFの保存ミスも起きやすくなります。

ファイル名の付け方が人によって違うと、後から探しにくくなります。最新版がどれか分からない、顧客名が抜けている、保存先が担当者ごとに分かれている、といった状態になると確認に時間がかかります。

メール送信でもミスが発生します。

宛先を入力し、件名を書き、本文を作り、PDFを添付して送る。この作業を顧客ごとに繰り返すと、添付忘れ、宛先間違い、本文の修正漏れが起きやすくなります。

送信履歴が残りにくいことも問題です。

メールボックスを見れば送信済みかどうか分かる場合もありますが、請求一覧と結びついていないと、どの請求書をいつ送ったのかを確認しにくくなります。担当者が変わったときや、顧客から問い合わせがあったときに、過去の履歴を探すのに時間がかかります。

さらに、送信前の確認ルールが曖昧だと不安が残ります。

「この請求書は確認済みか」「まだ下書きなのか」「送信してよい状態なのか」が一覧で分からないと、送り忘れや二重送信につながる可能性があります。

二重送信も避けたいミスの一つです。送ったかどうかがメールボックス頼みになっていると、担当者が変わったときや複数人で作業したときに、同じ請求書をもう一度送ってしまうことがあります。請求一覧に送信日時、送信先、送信者、添付PDFのURLを残しておけば、送信済みかどうかを表から判断できます。

添付ファイルの取り違えも起きやすい問題です。PDFを手作業で選んで添付していると、別の顧客のPDFや古い月のPDFを選んでしまう可能性があります。

請求書番号やファイル名のルールが揃っていないことも、後から効いてきます。問い合わせがあったときに、対象の請求書をすぐ開けないと確認に時間がかかります。請求月、顧客名、請求書番号を組み合わせるなど、誰が見ても分かる命名ルールを決めておくと管理しやすくなります。

また、送信失敗が見落とされることもあります。メールアドレスが間違っている、PDFが作成されていない、添付ファイルが見つからない、といったエラーがあっても、ログやエラー記録がなければ担当者が気付きにくくなります。自動化するときほど、失敗した処理を見えるようにすることが大切です。

3. GASで請求書送信システムを作るとできること

GASで請求書送信システムを作ると、請求データの管理からPDF作成、メール送信、履歴保存までを一つの流れにできます。

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

• スプレッドシートに請求データを用意する
• 請求対象を選ぶ
• テンプレートに請求内容を差し込む
• 請求書PDFを作成する
• PDFをGoogleドライブに保存する
• 顧客宛てのメールを作成する
• PDFを添付して送信する
• 送信結果をスプレッドシートに記録する

請求データは、スプレッドシートで管理できます。

請求月、顧客名、請求金額、支払期限、宛先メールアドレス、担当者、ステータスなどを一覧にしておけば、どの請求が未作成で、どれが送信済みかを確認しやすくなります。

請求書PDFの作成にもつなげられます。

Googleドキュメントやスプレッドシートで請求書テンプレートを用意し、顧客名、金額、明細、支払期限などを差し込んでPDF化する流れを作れます。毎回同じ形式の請求書を作っている場合は、手作業を減らしやすい部分です。

メール送信も自動化できます。

顧客ごとに宛先、件名、本文を組み立て、作成したPDFを添付して送ることができます。本文には顧客名や請求月、支払期限などを差し込めるため、定型文を使いながらも必要な情報を入れられます。

送信履歴を残せることも重要です。

送信日時、送信先、添付したPDFのファイル名、送信結果、エラー内容などをスプレッドシートに記録しておけば、後から確認しやすくなります。単にメールを送るだけでなく、業務の記録として残せる点が便利です。

請求データは、顧客マスタと分けて管理する方法もあります。請求一覧には請求月、顧客コード、金額、ステータスを持たせ、顧客マスタには顧客名、宛先メールアドレス、CC、担当者名、敬称、支払条件などを持たせます。宛先が変わったときにマスタだけ直せるため、修正漏れを減らしやすくなります。

PDF作成とメール送信を分けることもできます。まずPDFだけ作成して一覧で確認し、問題がなければ次の操作で送信する形です。いきなりPDF作成と送信を同時に行うより、確認工程を挟めるため、請求金額や宛先の不安を減らせます。

メールは、最初から本番送信にせず、下書き作成やテスト送信から始める方法もあります。Gmailの下書きに保存して担当者が確認する、管理者宛てにテスト送信する、承認済みの行だけ本番送信する、といった段階を作ると導入しやすくなります。

送信履歴には、成功だけでなく失敗も残します。成功した行には送信日時とPDF URLを記録し、失敗した行にはエラー内容を残します。

GASで作る請求書送信システムは、単なる一括送信ツールではなく、請求業務の状態管理にも使えます。未作成、PDF作成済み、確認待ち、送信待ち、送信済み、エラーといったステータスを持たせることで、今どこで止まっているのかが分かりやすくなります。

4. 請求書PDFを作成する基本の流れ

請求書PDFを作るには、まず元になる請求データを整理します。

請求先、請求日、支払期限、請求金額、明細、振込先、担当者など、請求書に必要な項目をスプレッドシートに持たせます。データが整理されていない状態でPDF作成だけを自動化しても、確認作業はあまり減りません。

次に、請求書テンプレートを用意します。

テンプレートは、GoogleドキュメントやGoogleスプレッドシートで作れます。会社名、請求書番号、請求日、顧客名、明細、合計金額、振込先など、毎回変わる部分を差し込みできる形にしておきます。

GASでは、対象行のデータを読み取り、テンプレートに差し込み、PDFとしてGoogleドライブに保存する流れを作ります。

このとき、ファイル名のルールを決めておくと後で探しやすくなります。たとえば、請求月、顧客名、請求書番号を組み合わせて保存すれば、一覧からもドライブからも確認しやすくなります。

PDFを作成したら、そのPDFの保存先URLやファイル名をスプレッドシートに記録します。

こうしておくと、請求一覧からPDFを開けるようになります。メール送信時にも、どのPDFを添付するのかを明確にできます。

ただし、PDF作成前の確認は大切です。

請求金額や宛先が未確定のままPDFを作ると、誤った請求書が保存されてしまいます。ステータス列に「確認中」「送信待ち」「送信済み」などを用意し、送信してよい状態だけを処理対象にする考え方が必要です。

請求書テンプレートは、できるだけ変更しやすい形にしておくと運用しやすくなります。会社名、住所、登録番号、振込先、備考文など、将来変わる可能性がある項目は、テンプレート側か設定シート側で管理します。コード内に直接書くと、変更のたびに開発者が修正する必要が出てしまいます。

明細行の扱いも先に決めておきます。1請求につき1行で管理するのか、1請求に複数明細を持たせるのかで、シート構成が変わります。明細が複数ある場合は、請求ヘッダーと明細シートを分け、請求書番号で結びつける構成が分かりやすいです。

PDF保存先は、顧客別、請求月別、年度別などのルールを決めます。毎月増えるPDFを一つのフォルダに入れ続けると、後から探しにくくなります。請求月ごとのフォルダを自動作成する、顧客ごとに保存先を分ける、といったルールを作ると整理しやすくなります。

PDFを作り直す場合の扱いも重要です。金額修正などで再作成する場合、古いPDFを上書きするのか、版を分けて保存するのかを決めます。請求書は証跡として残したい場合があるため、安易に上書きせず、再作成日時や版数を分かるようにしておくと安心です。

PDF作成時には、作成済みフラグを残しておきます。PDF URL、作成日時、作成者、テンプレート名、請求書番号を記録しておけば、どのデータからどのPDFが作られたかを追いやすくなります。

5. メール送信と送信履歴を残す考え方

請求書送信では、メールを送ること自体よりも、正しい相手に正しい内容を送ったことを確認できる状態が大切です。

まず、宛先情報をどこで管理するかを決めます。

請求一覧にメールアドレスを直接入れる方法もありますが、顧客マスタを別シートにして、顧客名や顧客コードから宛先を参照する方法もあります。件数が少ないうちはシンプルな管理で十分ですが、顧客が増える場合はマスタ化した方が修正漏れを防ぎやすくなります。

件名と本文もテンプレート化しておきます。

毎月同じ文面を手で書くのではなく、請求月、顧客名、支払期限などを差し込める形にします。定型文を使えば、文章のばらつきや修正漏れを減らせます。

送信前に確認できる状態を作ることも重要です。

いきなり自動送信するのではなく、最初は下書き作成やテスト送信から始める方法もあります。運用に慣れてから、ステータスが「送信待ち」のものだけを送信する形にすると安心です。

送信後は、送信履歴を残します。

送信日時、送信先、件名、添付PDF、処理結果、エラー内容などをスプレッドシートに記録します。これにより、問い合わせがあったときに「いつ送ったか」「どのPDFを送ったか」を確認しやすくなります。

エラー時の扱いも決めておきます。

メールアドレスが空欄だった、PDFが見つからなかった、送信に失敗した、といった場合に、そのまま処理を終えるのではなく、エラー内容を記録して担当者が確認できるようにします。

メール本文テンプレートは、顧客向けの文面として統一しておくと安心です。件名には請求月や会社名を入れ、本文には請求書を添付していること、支払期限、問い合わせ先を入れるなど、毎月同じ品質で送れるようにします。

CCやBCCの扱いも決めます。社内担当者や経理共有アドレスを入れる場合、受信者数が増えるため、GmailやGASの送信制限にも関係します。すべてのメールに同じCCを入れるのか、顧客ごとに担当者を変えるのかを整理します。

送信前確認の画面や確認シートを用意する方法もあります。送信対象件数、合計金額、未PDF作成件数、宛先未設定件数、エラー件数を表示してから送信すれば、担当者が全体を見て判断できます。特に本番送信では、送信ボタンを押す前に確認できる状態が重要です。

再送の扱いも設計しておきます。送信に失敗したものだけ再送するのか、送信済みの請求書を顧客依頼で再送する場合は履歴をどう残すのかを決めます。再送日時と理由を残しておくと、後から経緯を確認しやすくなります。

エラー通知は、担当者が気付ける形にします。送信処理の最後にエラー件数を管理者へ通知する、エラー行だけを一覧に出す、といった工夫が役立ちます。

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

請求書送信システムを作る前に、業務ルールを整理しておくことが大切です。

まず、請求データの元を決めます。

スプレッドシートに手入力するのか、別の管理表からコピーするのか、会計ソフトから出力したCSVを使うのかによって、作り方が変わります。最初はスプレッドシートに必要項目を整理するだけでも十分な場合があります。

次に、請求書テンプレートを決めます。

会社情報、請求書番号、請求日、支払期限、明細、消費税、振込先など、どの項目をどの形式で表示するかを整理します。この記事では法制度の詳細には踏み込みませんが、実際の運用では社内ルールや税理士への確認も必要です。

宛先情報の管理方法も重要です。

請求先のメールアドレス、CC、担当者名、送付先部署などをどこで管理するかを決めます。宛先ミスは影響が大きいため、担当者が確認しやすい形にしておく必要があります。

メールの件名と本文も決めておきます。

請求月、顧客名、支払期限、問い合わせ先など、毎回入れる情報を整理します。社外向けの文面になるため、表現を統一しておくと安心です。

送信前の承認者も決めておきます。

すべて自動送信にするのか、担当者が確認してから送るのか、管理者が承認したものだけ送るのか。請求金額や顧客によって確認ルールを変える場合もあります。

送信履歴とエラー対応も最初に考えておきます。

送信済みの記録をどこに残すか、送信失敗時に誰へ通知するか、再送する場合にどのように記録するかを決めておくと、運用開始後に迷いにくくなります。

承認フローも導入前に決めておきたい項目です。担当者が請求データを入力し、管理者が確認し、承認済みになったものだけ送信する、という流れにするのか、少額の請求は担当者確認だけで送るのかによって、ステータス設計が変わります。

テスト送信と本番送信の切り替えも必要です。開発中や初回導入時には、顧客宛てではなく社内の確認用アドレスへ送る方が安全です。テストモードでは宛先を固定し、本番モードでは顧客マスタの宛先を使う、といった切り替えがあると事故を防ぎやすくなります。

権限管理も重要です。請求データのスプレッドシート、PDF保存先フォルダ、GASプロジェクト、テンプレートファイルを誰が編集できるのかを決めます。請求書は金額や取引先情報を含むため、必要以上に広く共有しない方が安全です。

送信元アカウントも確認します。担当者個人のアカウントから送るのか、会社の共有アドレスから送るのか、顧客から見た差出人名をどうするのかによって、運用の見え方が変わります。退職や異動を考えると、個人アカウントに依存しすぎない構成が望ましいです。

運用担当も決めます。請求データを作る人、PDFを確認する人、送信する人、エラーを見る人、顧客からの問い合わせに対応する人が曖昧だと、便利な仕組みを作っても止まりやすくなります。

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

GASの請求書送信システムは便利ですが、向いていない使い方もあります。

まず、大量送信を前提にする場合です。

GASやGmailには送信数や実行時間に関する制限があります。毎月少数から中規模の請求書を送る用途であれば検討しやすいですが、大量の請求書を一度に送る場合は、専用サービスや別の構成を検討した方がよいことがあります。

会計ソフトや基幹システムとの厳密な連携が必要な場合も注意が必要です。

請求データを会計システムと双方向に同期する、入金消込まで自動化する、承認ワークフローと連携する、といった要件がある場合は、GASだけで簡単に作るよりも、全体設計を先に整理する必要があります。

セキュリティと権限管理も重要です。

請求書には取引先名、金額、振込先などの重要な情報が含まれます。スプレッドシート、PDF保存先、GASプロジェクト、送信元アカウントの権限を曖昧にしたまま運用しないことが大切です。

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

担当者個人のGoogleアカウントで仕組みを作り、そのまま業務で使い続けると、退職や異動時に引き継ぎで困ることがあります。会社や顧客の運用に合わせて、所有者と保守担当を決めておくべきです。

また、自動送信は便利な反面、間違ったデータもそのまま送ってしまう可能性があります。

そのため、最初から完全自動送信にするのではなく、PDF作成、確認、送信、履歴記録を段階的に導入する方が安全です。運用に慣れてから自動化範囲を広げると、現場にも定着しやすくなります。

実行時間の制限にも注意します。請求書PDFを大量に作成し、さらにメール送信まで一度に行うと、処理が長くなる可能性があります。件数が多い場合は、PDF作成とメール送信を分ける、一定件数ずつ処理する、失敗した行だけ再処理する、といった設計にします。

メール送信数の制限もあります。Googleアカウントの種類によって、1日に送れるメールの上限は変わります。請求書送信は社外宛てになることが多いため、上限ぎりぎりで運用しない方が安全です。件数が多い場合は、送信日を分ける、専用サービスを使う、Workspace環境で運用するなどを検討します。

PDFや履歴の保存期間も考えます。請求書PDFをどのくらい保存するのか、古いファイルをアーカイブするのか、顧客ごとにフォルダを分けるのかを決めておくと、後から整理しやすくなります。

会計ソフトとの連携を考える場合は、どちらを正とするかを決める必要があります。会計ソフトが請求データの正なのか、スプレッドシートが作業用なのかが曖昧だと、金額や送信状況の整合性が取りにくくなります。GASで扱う範囲を明確にしておくことが大切です。

GASだけで始める場合でも、将来的に件数が増える可能性があるなら、データ項目や履歴の残し方を整理しておくと移行しやすくなります。最初から大きな仕組みにする必要はありませんが、請求書番号、顧客コード、PDF URL、送信履歴などは後で使いやすい形にしておくべきです。

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

請求書送信の自動化は、最初から完全自動送信を目指さない方が安全です。

最初のステップは、請求データを整理することです。請求月、顧客名、請求金額、支払期限、宛先、ステータスなどをスプレッドシートにまとめ、どの項目がPDFやメールに使われるのかを明確にします。

次に、PDF作成だけを自動化します。請求一覧からPDFを作成し、Googleドライブへ保存し、PDF URLを一覧へ戻すところまでを作ります。この段階ではメール送信をまだ自動化せず、PDFの内容や保存名、保存先が正しいかを確認します。

3つ目は、送信履歴を残す仕組みを作ることです。手動でメール送信する場合でも、送信日時、送信先、PDF URL、担当者を記録するだけで、後から確認しやすくなります。自動送信の前に履歴設計を固めておくと安心です。

4つ目は、テスト送信です。顧客宛てではなく社内の確認用アドレスへ送り、件名、本文、添付PDF、差出人名を確認します。問題がなければ、送信対象を限定して本番運用を始めます。

5つ目は、承認済みの請求だけを本番送信することです。ステータスが「送信待ち」の行だけを対象にし、送信後は「送信済み」に変えるようにします。二重送信を防ぐため、送信済みの行は通常処理から除外します。

最後に、エラー対応と再送を整えます。送信に失敗した行だけ再送できるようにし、エラー内容を履歴に残します。再送時も、いつ誰が再送したのかを記録しておくと、問い合わせ対応がしやすくなります。

このように段階を分ければ、請求書送信の自動化は現場に合わせて進められます。

9. まとめ

GASで請求書送信システムを作ると、請求書PDFの作成、メール添付送信、送信履歴の記録を一つの流れにできます。

手作業で毎月行っている請求書作成やメール送信は、件数が少ないうちは何とか回ります。しかし、顧客数や請求件数が増えると、転記ミス、添付忘れ、送信漏れ、履歴確認の手間が目立つようになります。

GASを使えば、スプレッドシートの請求データをもとにPDFを作成し、Googleドライブへ保存し、Gmailで送信し、送信結果を記録する仕組みを作れます。

ただし、請求書は金額や宛先の正確さが重要です。自動化する場合でも、請求データの確認、送信前の承認、エラー時の対応、権限管理はしっかり決めておく必要があります。

まずは、請求データを整理し、PDF作成と送信履歴の記録から始めるだけでも効果があります。毎月の定型作業を少しずつ減らしたい場合、GASは使いやすい選択肢になります。

請求業務は、効率化しやすい一方で、ミスの影響が大きい業務です。金額、宛先、添付ファイル、送信履歴を確認できる状態にしておくことが欠かせません。

GASを使えば、スプレッドシートを中心に、請求データ、PDF、メール、履歴をつなげられます。ただし、すべてを一気に自動化するのではなく、PDF作成、確認、テスト送信、本番送信、再送対応の順に整える方が安全です。

毎月の請求作業を安定して回すには、自動化と確認のバランスが重要です。担当者が安心して送信でき、後から履歴を追える仕組みにすることで、請求業務の負担を減らしながらミスも防ぎやすくなります。