請求書発行をGASとfreeeで仕組み化する手順｜月12時間→1時間にした実装

月末になると、請求書の作成と送付で半日以上が消えていく。50社分の取引先マスタを毎回スプレッドシートからコピーして、Wordで雛形に貼って、PDFに変換して、メールで送る。最後にfreeeに転記する作業まで手動。本業の経営判断が後回しになっていく感覚があった。これは私自身が、請求書発行を手作業のまま続けていた頃の本音です。

この記事では、Google Apps Script（以下GAS）とfreee APIを組み合わせた請求書発行の仕組み化手順を解説します。発行から会計登録まで、つまずきポイントを含めてお伝えします。

請求書発行を手作業のままにすると、月12時間以上が消える

まず数字で現状を直視するところから始めます。私自身が請求書を手作業で発行していた頃、月50件前後の請求業務にかかっていた時間は合計12時間を超えていました。内訳は以下のとおりです。

手作業の請求業務、5つの工程と時間内訳

• 請求書作成（2〜4時間）：取引先名・金額・件名・期日をスプレッドシートからWord雛形へ転記
• PDF変換と命名（1〜2時間）：Wordから書き出してファイル名を「YYYYMM_社名_請求書.pdf」へ手動修正
• メール送付（1〜3時間）：取引先ごとに本文を書き分け、PDF添付、CC設定
• 入金照合（2〜4時間）：通帳・freeeの入金記録と請求台帳を目視で突合
• 未入金フォロー（1〜2時間）：入金されていない取引先へ催促メール送付

12時間というのは「単純作業に12時間使っている」という意味です。経営者としての判断業務、新規顧客への提案、社員との1on1に充てるべき時間が、毎月この単純作業に吸い取られていました。

freeeも認める「中小企業の請求業務はまだ手作業が主流」

クラウド会計シェアは弥生55.4%・freee24%・マネーフォワード14.3%（MM総研調査・2025年3月末）です。上位3社で93.7%を占めますが、請求書発行のプロセスはWord・Excel・専用ソフトに分散しているのが実情です。

freeeは2025年にAIエージェント連携用のfreee-mcp（Model Context Protocol）をOSS公開しました。APIから会計操作を行う流れは年々太くなっており、今からGASで仕組み化しておく価値は大きい局面です。

GASとfreeeを組み合わせた請求書発行の全体像

私が実装した仕組みの全体像は、次の3層構成です。複雑なツールを増やすのではなく、Googleスプレッドシート＋GAS＋freee APIという最小構成で月12時間→月1時間以下を実現しています。

3層構成の役割分担

1. データ層：Googleスプレッドシート
   • 取引先マスタ（社名／請求先メール／支払サイト／消費税区分）
   • 請求明細（取引先ID／品目／単価／数量／請求月）
   • 請求書発行ログ（発行日／PDF URL／送付ステータス／freee登録ID）
2. 処理層：GAS（Google Apps Script）
   • 請求書テンプレート（Googleドキュメント）への差し込み
   • PDF変換とDriveへの自動命名保存
   • Gmail下書き作成（人間の最終確認用に「下書き」で止める）
   • freee APIへの請求書登録
3. 会計層：freee API
   • 請求書の登録と取引先IDとの紐付け
   • 入金消込のための取引照合
   • 月次レポートへの自動反映

ポイントは「メール送付は完全自動化せず、Gmail下書きで止める」設計です。最初の1〜2ヶ月は人間が下書きを確認してから送ります。誤送信ゼロを担保したうえで、慣れたら下書きから自動送信へ段階的に切り替えていきます。

【手順1】請求書マスタと取引先DBをスプレッドシートで設計する

最初の手順は、データ構造の整理です。GASは強力ですが、スプレッドシートのデータ形式がバラバラだと一切動きません。私自身、最初の試作で「取引先名の表記揺れ（株式会社／（株）／㈱）」だけで3日溶かしました。先にデータ設計を済ませることが、仕組み化成功の8割を決めます。

3つのシートを用意する

同じスプレッドシートファイルの中に、以下3つのシートを作成します。

• 取引先マスタ：列は「取引先ID／正式社名／請求先メール／CC／支払サイト（日数）／消費税区分／freee取引先ID」
• 請求明細：列は「取引先ID／請求月（YYYY-MM）／品目／単価／数量／備考」
• 発行ログ：列は「発行日／取引先ID／請求金額／PDF URL／メール下書きURL／freee登録ID／ステータス」

表記揺れを排除する3つのルール

手作業で転記していた頃は気にならなかった表記揺れも、GASに渡したときに即エラーになります。私は以下3つのルールを最初に決め、取引先マスタを統一しました。

• 社名は「正式社名（登記簿どおり）」のみを使う。「（株）」や「㈱」は禁止
• 金額は半角数字のみ。「￥」「円」「,」を含めない（GASで桁区切りは後から付ける）
• 日付は「YYYY-MM-DD」形式に統一。「2026/4/30」「令和8年4月30日」を排除

この3ルールをスプレッドシートのデータ入力規則（プルダウン・正規表現）で強制すると、人間がうっかり崩すリスクをゼロに近づけられます。

【手順2】GASでPDF化→Drive保存→ファイル命名を統一する

データが整ったら、次はGASで請求書PDFを発行する処理を組みます。流れは「Googleドキュメント雛形をコピー→差し込み→PDF書き出し→Driveに保存→Gmail下書き作成」の5ステップです。

Googleドキュメントを雛形にする理由

私はWord雛形ではなくGoogleドキュメントを請求書テンプレートに使っています。理由は3つあります。

• GASからネイティブで読み書きできるためライブラリ追加が不要
• Driveの権限管理だけで雛形のバージョン管理が完結する
• PDF書き出しがGAS標準APIで1行で済む（doc.getAs(MimeType.PDF)）

差し込み変数は4つに絞る

雛形の中に置く差し込み変数は、最小限に絞るのがコツです。私の運用では以下4つだけ置いています。

• {{社名}}：取引先マスタから自動取得
• {{請求番号}}：「YYYYMM-取引先ID-連番」で自動採番
• {{明細表}}：請求明細シートから動的に表組みを生成
• {{支払期日}}：取引先マスタの支払サイトから自動計算

ファイル命名規則を最初に固定する

PDFファイル名は「YYYYMM_社名_請求書_請求番号.pdf」で固定しました。命名規則を最初に決めておかないと、後から発行ログから過去請求書を引くのに苦労します。Driveの保存先フォルダも「年／月」で階層化しておくと、税務調査時の証憑提示もスムーズです。

【手順3】freee API連携で会計仕訳までつなげる

PDF発行ができたら、最後の仕上げがfreee API連携です。ここまでで「請求書を発行する」作業は仕組み化されますが、freeeへの登録を手作業のままにすると結局月3〜4時間が残ります。freee APIを使うと、ここも完全に消えます。

freee APIで使うエンドポイントは3つだけ

請求書発行を会計につなげるfreee APIエンドポイントは、最低限以下の3つです。

• /api/1/invoices（POST）：請求書を新規登録
• /api/1/partners（GET）：取引先IDを取得（取引先マスタとの突合用）
• /api/1/deals（GET）：入金取引を取得（入金消込用）

OAuth認証はGASのスクリプトプロパティに保存する

freee APIはOAuth 2.0認証です。アクセストークンとリフレッシュトークンを安全に保管する必要があります。

GASではPropertiesService.getScriptProperties()でスクリプトプロパティに保存し、getProperty()で参照する設計が安全です。コード内に直書きすると、他メンバーとスプレッドシートを共有した瞬間に漏洩します。

入金消込まで仕組み化する

請求書を発行しただけでは終わりません。「入金されたかどうか」をfreeeから取得し、発行ログに自動で「入金済み」フラグを立てる処理まで組み込みます。

私は週次で/api/1/dealsから入金取引を取得し、発行ログの請求番号と金額で突合するスクリプトをトリガー実行しています（毎週月曜9時）。これで未入金フォローまでスプレッドシートだけで完結します。

つまずきやすい3つの落とし穴と対処法

ここまで読むと「すぐ作れそう」と思うかもしれませんが、私自身は最初の3週間でこの3つの壁にぶつかりました。先に共有しておきます。

落とし穴1：GASの6分実行制限

GASは1回の実行が6分（無料）または30分（Workspace有料）で強制終了します。50件を1回で回すと途中で止まります。対処法は2つです。

• 1件ずつ処理して、進捗を発行ログに保存し、次回トリガーで未処理分から再開する設計にする
• 10件ずつバッチ化して、Utilities.sleep()で間引きながら処理する

落とし穴2：データ形式バラバラで動作不能

手順1で書いたとおり、表記揺れがあるとGASは即エラーで止まります。私は最初の試作で、取引先名「株式会社○○」「（株）○○」「㈱○○」が混在していて、取引先マスタとの突合が一切できず、3日かけて全データを正規化し直しました。データ入力規則を最初に仕込むことで、このやり直しは防げます。

落とし穴3：エラー通知が来ないと事故に気づかない

GASは静かに失敗します。トリガー実行で月初に動かしていたつもりが、実は1ヶ月止まっていた——という事故が起きえます。対策として、私は以下2つを必ず仕込んでいます。

• try-catchで例外をキャッチして、エラー時にSlackやLINE通知で本人へ即知らせる
• 毎月1日に「今月の請求書発行は○件、freee登録○件、エラー○件」のサマリーをメールで自動送信する

この2つを入れるだけで、仕組みの信頼性が一段上がります。

よくある質問