Codexで作った業務ツールを使い続けられる形へ育てる｜ローカルDB（IndexedDB）でマスタと請求データを保存する実装記録

前回作った見積書・請求書ツールを使ってみると、すぐに次の壁にぶつかる。毎回、同じ取引先名を入れて、同じ住所を入れて、同じ商品名と単価を入れている。請求書を作ったあとは、別の表へ金額を転記して、月の合計を電卓で計算している。作れるツールにはなったけど、使い続けられるツールにはなっていない。 ここを越えるのが第2回のテーマや。

この記事では、Codexで作った見積書・請求書ツールに、ブラウザ標準のローカルDB（IndexedDB）を接続して、取引先マスタ・商品マスタ・請求データ保存・売上集計までを追加した過程をまとめる。サーバーもクラウドも使わへん。個人事業主が自分の事業のために一人で使うことを前提に、ブラウザの中だけで完結する形へ育てた実装記録や。

なお、第1回（MVP構築）を読んでへん人は、先にこちらから読むと話がつながりやすい。

→ Codexで業務ツールを自作する第一歩｜見積書・請求書ツールをMVPで作って分かった完成基準と修正点

結論｜業務ツールは「作れる」から「使い続けられる」へ育てる段階で、保存と再利用と集計が要る

第1回MVPと第2回の違いを、一文でまとめるとこうなる。

第1回は「作れるツール」、第2回は「使い続けられるツール」。

この差を埋めるのが、保存と再利用と集計の3つや。

毎回、宛先を打ち直さんでええ。毎回、商品名と単価を打ち直さんでええ。請求書を作ったら、その記録が自動で残る。残ったデータから、今月いくら請求したか、顧客別にいくら請求しているかが、その場で分かる。これだけで、毎日の作業時間と、月末の集計時間が、ガクッと減る。

そのために、第2回ではブラウザ標準のローカルDB（IndexedDB）を接続して、4つの保存先を追加した。サーバーもクラウドも使わへん。ファイルを開けばすぐ動く、第1回MVPと同じ構成のままや。

このツールは、実際に触れる形で公開している。マスタ登録や集計画面の動きを確認したい人は、こちらから試してほしい。

→ 見積書・請求書ツールを試す

第1回MVPで見えた「次の詰まり」｜毎回の再入力と、別表への転記

第1回MVPを実際に使い始めると、次に困る場所はかなり分かりやすかった。

取引先・商品名・単価を毎回入れ直している

同じ取引先へ毎月請求する場合、会社名、住所、担当者名を毎回入れる。明細に並ぶ商品名や単価も、案件ごとに使い回しているのに、毎回ゼロから打ち直している。1件あたりは数分の手間や。でも、月に何件も発行していると、地味に重くなる。

請求額を別の表へ転記して集計している

請求書を作ったあと、金額をスプレッドシートやノートへ転記して、月末に合計を出している。これも1件あたりは数十秒の作業や。でも、転記漏れや桁間違いが入ると、月末の集計が合わへん原因になる。

詰まりが大きい順に解消するから、ローカルDBを足す

業務ツールを育てるとき、「思いついた順」に機能を足すと、ツールが膨らみすぎて壊れる。だから、詰まりが大きい順に直していく。

この判断軸は別記事で詳しくまとめている。改善点を「品質リスク・出力不足・操作の手間・入力項目不足」の4分類で振り分けて、優先度を決める考え方や。

→ AIで作ったツールを壊さずに育てる｜改善点を4つに分けて優先度を決める方法

第1回MVPで一番大きかった詰まりは、「操作の手間」と「入力項目不足」やった。毎回の再入力と、別表への転記。この2つを解消する手段が、ローカルDBの接続とマスタ化や。

なぜローカルDBで十分なのか｜「自分が使えればええ」という前提を最初に決める

ここで、ローカルDBを選んだ理由を整理しておく。技術的な話の前に、もっと大事な前提がある。

このツールは、個人事業主が自分の事業のためだけに使うことを前提に設計している。

複数人で同時編集する必要はない。別端末から見る必要もない。サーバーへ預ける必要もない。クラウドで共有する必要もない。「自分が使えればええ」という前提を最初に置く。 これが第2回の設計判断の根っこにある。

この前提を決めへんと、技術選定が一気に膨らんでしまう。複数人運用を考えた瞬間に、認証フローが要る。別端末同期を考えた瞬間に、サーバーDBとAPIが要る。クラウドへ預けた瞬間に、セキュリティ設計と運用コストが乗ってくる。「誰が使うか」を最初に決めることで、技術選定はびっくりするほどシンプルになる。

そのうえで、ローカルDB（IndexedDB）を選んだ理由を補足する。

静的HTML・CSS・JavaScript構成のまま動かせる

第1回MVPは、静的なHTML・CSS・JavaScriptで作っている。サーバーを立てる必要も、ビルドツールを使う必要もない。ファイルを開いたら動く。

IndexedDBはブラウザに標準搭載されているローカルDBや。サーバーを立てずに、複雑なデータ構造を扱える。第1回MVPの「ファイルを開けば動く」良さを、そのまま維持できる。

認証・デプロイ・セキュリティ設計を一気に持ち込まずに済む

サーバーDBを使うと、認証フロー、デプロイ環境、セキュリティ設計、運用コストが一気に乗ってくる。個人事業主が一人で使うツールに、ここまでの装備は要らへん。

MVPの次の段階としては、ローカルDBで十分や。 これが今回の判断や。

この前提を超えた瞬間に、サーバーDBへ進む

逆に言うと、次のような状況になったら、サーバーDBへ進む判断が要る。

• 別端末（スマホ・別PC）から見る必要が出てきた
• 複数人で同時編集する必要が出てきた
• データを長期保存して、ブラウザ更新の影響を受けへん場所へ移したい
• 自分以外の人に渡して使ってもらう

この記事は、こうした状況になっていない段階の話や。ツールの規模やなく、運用の前提で技術選定を変える。 これは業務ツールを長く使うときの基本やと思う。

第2回で追加した4つの保存先｜役割を分けたほうが整理しやすい

第2回で追加した保存先は4つや。

保存先	何を保存するか
取引先マスタ	宛名・住所・担当者・連絡先
商品・項目マスタ	品名・説明文・単価・税区分
発行者マスタ	自社情報・連絡先
請求データ	発行した請求書の記録（取引先・発行日・件名・請求額・状態・明細）

最初の3つはマスタや。何度も使い回す情報を保存しておく場所。最後の1つは記録や。発行した請求書をそのまま残しておく場所。

マスタは「使い回す情報」、記録は「残しておく情報」。 この役割を最初に分けたから、画面構成も整理しやすかった。

取引先マスタ｜宛名と連絡先の保存

取引先マスタは、宛名や連絡先を保存しておく場所や。一度登録しておけば、帳票作成画面でプルダウンから選ぶだけで呼び出せる。

検証で使った架空データは次の3件や。

• ミライ架空商店
• つむぎ試作工房
• 七色サンプル企画

全部架空データで、実在する会社名や個人名は使っていない。

商品・項目マスタ｜明細でよく使う項目の保存

商品・項目マスタは、明細に並ぶ品名・単価・税区分を保存しておく場所や。フリーランスや個人事業主は、よく使う作業メニューが決まっていることが多い。そこを登録しておけば、明細を作るたびに打ち直さんで済む。

検証で使った架空データは次の5件や。

• 架空サイト初期設計
• 説明文ライティング
• 月次保守サポート
• 告知バナー制作
• 操作説明ミニ講座

品名だけやなく、説明文・単価・税区分まで持たせた。

発行者マスタ｜自社情報の保存

発行者マスタは、自社（自分）の情報を保存しておく場所や。屋号、住所、振込先、代表者名など、毎回同じ情報を打ち直さなくて済む。

第2回時点では1件だけ登録しておけば十分やけど、複数の屋号で活動している人は、複数件を切り替えられるようにしておくと便利や。

請求データ｜発行した請求書の記録

請求データは、発行した請求書をそのまま残しておく場所や。ここがあるから、あとで集計に使える。

保存する項目は次のとおりや。

• 取引先
• 発行日
• 件名
• 請求額
• 状態（下書き・請求済み・入金済み）
• 明細

画面に表示するだけ、PDFを出すだけでは、後から集計に使えへん。記録として残すと、別表への転記が不要になる。 ここが、保存と再利用の差や。

取引先マスタの作り方｜帳票画面と分離するのが正解やった

取引先マスタを作るとき、最初に迷ったのが「画面構成」やった。

初回版は帳票画面に同居していた、それで混乱した

初回版では、帳票作成画面に取引先マスタの登録フォームを同居させていた。請求書を作る画面で、新しい取引先も登録できる。一見、便利そうに見える。

でも、実際に触ってみると、操作対象が多すぎて混乱した。「請求書を作る作業」と「取引先を管理する作業」が、同じ画面の中で混ざってしまう。 マスタを登録したいのに、帳票画面の入力欄まで触ってしまう。逆に、請求書を作りたいのに、マスタ画面の登録ボタンに目が行く。

マスタ画面と帳票作成画面を別ページに分けた

そこで、取引先マスタは別ページに分けた。

帳票作成画面では、登録済みの取引先を選ぶだけ。選んだら、宛名情報が読み取り専用で表示される。修正したい場合は、取引先マスタ画面で直す。

帳票画面では「使う」、マスタ画面では「管理する」

画面の役割を、こう分けた。

画面	何をする場所か
帳票作成画面	登録済みデータを「使う」場所
マスタ画面	データを「管理する」場所

使う場所と管理する場所を分けると、操作対象が一つに絞られる。 これは、複雑な機能を持つツールほど効いてくる設計や。

商品・項目マスタで明細入力を速くする｜単価と税区分まで持たせる

商品・項目マスタも、取引先マスタと同じ考え方で作った。

よく使う項目を登録できる

フリーランスや個人事業主は、よく使う作業メニューが決まっていることが多い。「初期設計」「ライティング」「保守」「バナー制作」など、案件ごとに繰り返し使う項目を、マスタへ登録しておく。

帳票画面で選ぶだけで明細へ反映される

明細を作るとき、マスタから項目を選ぶ。すると、品名・説明文・単価・税区分が、明細行へ自動で入る。数量だけ変えれば、合計金額も自動で計算される。

毎回ゼロから打つのと、選ぶだけで済むのとでは、1案件あたりの入力時間が全然違う。

重複登録・空欄・0円入力を弾く設計にした

マスタは、便利な反面、雑に登録するとあとで管理が崩れる。

第2回の検証では、次の3つを保存できないように設計した。

• 商品名が未入力
• 単価が0円
• 同じ商品名で重複登録

価格改定履歴や有効期間まで考える場面もあるけど、第2回では持ち込んでへん。「よく使う項目を登録できる・選べる・間違った登録を防げる」までで十分と判断した。ここから先は、使いながら必要になったときに追加すればええ。

請求データを保存し、後から集計できる形にする

ここからが、第2回で一番効いてくる部分や。

取引先・発行日・件名・請求額・状態・明細を保存

請求書を作って保存すると、次の項目が請求データとして残る。

• 取引先
• 発行日
• 件名
• 請求額
• 状態（下書き・請求済み・入金済み）
• 明細の内容

画面にきれいな請求書が表示されることと、請求記録が残ることは、別の話や。第1回MVPは前者まで、第2回は後者まで進めた。

削除・初期化・復元は人間の確認を残す

請求データは、消したり初期化したりするのを雑に扱ったらあかん。

第2回の検証では、削除前に確認ダイアログが表示されることを確認した。「本当に削除しますか」が出る。確認ボタンを押さない限り、削除は実行されへん。

削除、初期化、復元は、便利な機能やけど慎重に扱う場所や。 人間が最後に確認する流れを残したほうがええ。

このあたりは、第1回MVPの「正確性」基準と地続きや。便利さを優先して確認ステップを省くと、事故が起きたときに取り返しがつかんようになる。

保存した請求データから売上を集計する｜架空データで検証した結果

請求データが残っていると、その場で集計できる。

今月・月別・顧客別の3軸で集計

第2回では、次の3軸で集計できるようにした。

• 今月の請求額合計
• 月別の請求額（過去数ヶ月分）
• 顧客別の請求額（取引先ごと）

期待値と実測値が一致したケース

検証では、複数月にまたがる架空の請求データ6件を入れて、集計結果を確認した。基準日は2026年6月16日や。

今月の請求額合計：

• 期待値：181,500円
• 実測値：181,500円 → 一致

月別請求額：

月	集計結果
2026年4月	165,000円
2026年5月	125,400円
2026年6月	181,500円
2026年7月	25,000円

顧客別請求額：

取引先	集計結果
ミライ架空商店	239,500円
つむぎ試作工房	198,000円
七色サンプル企画	59,400円

どれも、電卓で計算した期待値と実測値が一致した。

「売上集計」と呼んでいるけど、入金管理ではない

ここは、表現に注意が要る。

この記事では「売上集計」と呼んでいるけど、実装上は保存済み請求額の集計や。

• 入金管理ではない
• 会計ソフトの代替でもない
• 税務上の売上判定でもない

入金が完了したかどうか、会計仕訳がどうなるか、税務上の売上計上時期がいつか。これらはツールの外で判断する話や。ツールが見ているのは、保存済み請求データから計算した請求額の合計だけという線引きを、最初に意識しておいたほうがええ。

ここを混ぜると、ツール側が無限に複雑になる。「会計ソフトと連携したい」「入金消込まで自動でやりたい」「税区分ごとの集計が欲しい」と、要求がどんどん膨らむ。第2回では、あくまで請求額の合計までで線を引いた。

Codexへ実装条件を渡すときに決めた範囲

第2回でCodexへ実装を依頼するとき、第1回と同じく「要件」と「受け入れ条件」を分けて渡した。さらに、「今回入れない機能」も明示した。

入れる機能・入れない機能を最初に明示

第2回でCodexへ渡した条件は、こんな構成や。

【今回の追加実装】
・ブラウザ標準のIndexedDBを接続する
・取引先マスタ（CRUD）を作る
・商品・項目マスタ（CRUD）を作る
・発行者マスタ（CRUD）を作る
・請求データ保存（作成・編集・削除）を作る
・今月・月別・顧客別の請求額集計を作る
・架空データだけで動作確認する

【受け入れ条件】
・マスタの登録・編集・削除がエラーなく動く
・帳票作成画面からマスタを呼び出せる
・削除前に確認ダイアログが表示される
・必須未入力・重複登録・0円登録を弾く
・今月・月別・顧客別の集計値が期待値と一致する
・バックアップと復元が動く

【今回入れない機能】
・サーバー側DBへの接続
・クラウド同期
・認証・複数ユーザー
・会計ソフト連携
・税務判断
・請求データの検索・絞り込み・並び替え
・CSV出力
・集計グラフ
・状態別表示・状態管理の高度化

「検索」「CSV」「グラフ」は今回入れへんかった

「入れない機能」のリストを明示したのが、今回特に効いた。

検索、CSV出力、集計グラフ、状態管理の高度化。どれも便利そうやし、思いつく機能や。でも、ここを最初から全部入れようとすると、Codexも迷うし、検証範囲が一気に膨らむ。「今回入れない」と明示することで、Codexが余計な機能を作り込まへんようになる。

範囲を絞ると、Codexの出力もブレへん

第1回の記事でも書いたけど、Codexへの依頼は「範囲を決める」ことが一番効く。

機能を削るのは、欲しくないからやない。今回検証したい範囲を、明確にするためや。

これは第2回でも同じや。範囲を絞ることが、依頼の精度を上げる最短ルートやと思う。

画面構成を5つに分けた理由｜帳票・マスタ・レポートを混ぜへん

第2回で、初回版から大きく変えたのが画面構成や。

初回版は1画面に同居していた

初回版では、帳票作成画面に取引先マスタ・商品マスタ・集計レポートを全部同居させていた。1画面で全部できる、と言えば聞こえはええ。でも、実際に触ってみると、操作対象が多すぎて、何をする画面か分からんようになる。

5画面に分けたら、操作対象が一つに絞られた

そこで、画面を5つに分けた。

画面	役割
帳票作成	見積書・請求書を作る
取引先マスタ	取引先を登録・編集・削除する
商品・項目マスタ	商品・項目を登録・編集・削除する
発行者マスタ	発行者情報を登録・編集・削除する
請求レポート	保存済み請求データを集計する

分けたことで、各画面で「何をする画面か」がはっきりした。帳票画面では「使う」ことに集中できる。マスタ画面では「管理する」ことに集中できる。レポート画面では「確認する」ことに集中できる。

これは、実際に作って触ったから分かった改善点や。頭の中で設計図を眺めているだけでは、ここまで踏み切れへんかった。

動作確認した13項目｜架空データだけで検証する

practice記事で一番大事なのは、「作れそう」やなくて「作って確認した」ことや。

第2回でも、本文を書く前に実装と動作確認を済ませた。確認した項目は次のとおり。

1. 既存の見積書・請求書作成画面が起動する
2. 取引先を登録・編集・削除できる
3. 取引先削除前に確認ダイアログが出る
4. 登録済み取引先を帳票へ呼び出せる
5. 商品・項目を登録・編集・削除できる
6. 商品・項目削除前に確認ダイアログが出る
7. 登録済み商品・項目を明細へ呼び出せる
8. 発行者マスタを登録・編集・削除できる
9. 請求データを保存し、一覧で確認できる
10. 今月・月別・顧客別の請求額集計が期待値と一致する
11. 0件時の空状態が表示される
12. 必須入力エラー・重複登録・不正な金額を保存しない
13. バックアップ作成・DB初期化・バックアップ復元ができる

初回版で見つかった問題もあった。

一つは、確認スクリプトのタイミングや。架空データ投入ボタンを押した直後に集計値を読んでしまい、画面更新が終わる前に検証してしまって失敗した。これは、集計表示の更新を待ってから期待値と実測値を比較するように直した。

もう一つが、先に書いた「画面構成の同居」や。これも実際に触って初めて分かった問題や。

動作確認は、画面を触る検証と、自分で数値を計算して照合する検証の両方をやる。 ここを省くと、ツールが実は動いていないのに、動いた気になる。

バックアップと復元を確認する｜「消える可能性のある保存先」への備え

第2回で重要な検証がもう一つあった。バックアップと復元や。

JSONバックアップを作成

ローカルDBは、ブラウザに保存される。ブラウザのキャッシュをクリアしたら、データは消える。だから、自分でバックアップを取れる仕組みを用意した。

第2回では、取引先・商品/項目・発行者・請求データを含むJSONバックアップを作れるようにした。ボタンを押せば、現状のデータが全部入ったJSONが書き出される。

DBを空にして、復元で戻ることを確認

検証では、次の手順で復元を確認した。

1. バックアップを作成する
2. DBを空にする（全データを削除）
3. 作成したバックアップから復元する
4. 復元後のマスタ件数と集計値を確認する

復元後、取引先3件・商品/項目5件・発行者1件・請求データ6件に戻った。集計結果も復元前と一致した。

マスタ件数と集計値が復元後も一致した

「バックアップを取れる」だけでは不十分や。復元したときに、元の状態へ確実に戻るかまで確認しておかんと、いざというときに使えへん。

第2回では、ここまで検証した。実運用へ進めるなら、定期的にバックアップを取る運用ルールを自分で決めておくとええ。たとえば、月末にバックアップを書き出して、別フォルダへ保存しておく。これだけでも、ブラウザのキャッシュクリア事故から守れる。

ここで踏み込まへんかったこと｜検索・CSV・グラフ・状態管理は次に回す

第2回で、あえて後回しにした機能もある。

• 請求データの検索
• 絞り込み・並び替え
• CSV出力
• 請求状態の編集・状態別表示
• 集計グラフ
• バックアップJSONのファイルダウンロード／読み込みUI

全部入れると、また壊れる

どれも便利や。あったほうがええ。

でも、第2回で全部入れようとすると、検証範囲が膨らみすぎて、また壊れる。第1回でも書いたとおり、思いついた順に機能を足すと、ツールが膨らみすぎて壊れる原因になる。

使ってから次の機能を決める

検索が先か、CSVが先か、グラフが先か、状態管理が先か。これは、自分の運用パターンによって変わる。全部の人に同じ答えはない。

まずは、第2回までの状態で実際に使う。 案件を回しながら、本当に困る場所が見えてきたら、そこを次に直す。これが、業務ツールを長く育てる順番や。

第3回は「メール送信機能とスプレッドシート連携」へ進む

次回（第3回）では、作った見積書・請求書をクライアントへ送るところまでを自動化する。

具体的には次の3つを進める予定や。

• 発行者マスタにメール送信情報（差出人アドレス・署名）を追加
• メール本文テンプレートをマスタとして管理
• Gmailを経由して、PDFを添付した請求書を送信

あわせて、請求一覧の外部連携も検討する。CSV出力やと、出した瞬間にデータが切り離されてしまう。Googleスプレッドシートとの連携やと、ツールと帳簿が常に同じ数字を見られる。「自分が使えればええ」前提のまま、外部サービスとの接点だけを最低限つなぐ。 第3回はそこへ進む。

まとめ｜作れるツールから、使い続けられるツールへ

第2回でやったことをまとめる。

• 第1回MVPに、ブラウザ標準のローカルDB（IndexedDB）を接続した
• 取引先マスタ・商品/項目マスタ・発行者マスタ・請求データ保存・売上集計を追加した
• 画面を5つに分けて、操作対象を一つに絞った
• 架空データで13項目を動作確認した
• バックアップと復元が、復元後に元の状態へ戻ることを確認した

これで、毎回の再入力と、別表への転記が、ほぼなくなる状態になった。

ただし、これで完成やない。ブラウザ単位のローカルDBやから、別端末や別ブラウザとは共有されへん。認証・複数ユーザー・会計ソフト連携・入金消込・税務判断は持っていない。

これらは「不足」やなくて「前提」や。 個人事業主が自分一人で使うことを前提にしているから、これでええ。前提が変わったら、技術選定も変わる。

見積書・請求書ツールは、帳票を作るだけで終わらせなくていい。 取引先や商品項目を保存する。 請求データを残す。 保存した請求額を確認する。

それだけで、毎回の再入力は減る。別表への転記も減る。今月と顧客別の状況も見やすくなる。

まずは、架空データで試す。期待値と実測値を比べる。削除・復元・エラー表示を確認する。そのうえで、自分の仕事に必要な機能を一つずつ足したらええ。

今回作ったツールは、AI大将のツールページで実際に触れる。マスタ登録から集計画面までの動きは、文章で読むより、自分で動かしたほうが早い。

第3回では、メール送信機能とスプレッドシート連携へ進む。続きを追いかけたい人は、公式LINEから登録しておいてほしい。

AIは飾りちゃう。仕組みにしてナンボやで。

---

AI大将の公式LINEでは、Codexやその他AIツールを業務へ落とし込むときの実践ノウハウを、随時お届けしています。シリーズの続きの公開もLINEで先に告知するので、第3回以降を追いかけたい人は登録しておいてください。

よくある質問（FAQ）

Q. IndexedDBとlocalStorageは何が違いますか

どちらもブラウザに保存される仕組みやけど、扱えるデータの規模と構造が違う。localStorageは「キーと値」の単純な保存に向いていて、容量も小さい。IndexedDBは複雑なデータ構造（複数のテーブル相当のもの）を扱えて、容量も大きい。マスタや請求データのように、項目が多くて件数も増えるデータを扱うなら、IndexedDBのほうが向いている。

Q. なぜサーバーDBやクラウドDBを使わないのですか

このツールは、個人事業主が自分の事業のためだけに使うことを前提に設計しているからや。複数人で同時編集する必要も、別端末から見る必要もない。「誰が使うか」を最初に決めると、技術選定はかなりシンプルになる。 サーバーDBを使うと、認証・デプロイ・セキュリティ設計・運用コストまで一気に背負うことになる。一人で使う範囲なら、ブラウザ内のローカルDBで十分や。自分の運用範囲に合わせて、保存先を選ぶ。これが、業務ツールを長く使うコツやと思う。

Q. マスタ登録はどこまで項目を入れればいいですか

最初から細かくしすぎない。取引先マスタなら「会社名・住所・担当者・連絡先」、商品マスタなら「品名・説明文・単価・税区分」。これくらいで十分や。あとで必要になった項目は、使いながら足したらええ。最初に項目を増やしすぎると、登録が面倒になって、結局使われへんようになる。

Q. 売上集計と入金管理は同じものですか

違う。このツールの「売上集計」は、保存済み請求データから請求額を合計したものや。入金が完了したかどうか、会計仕訳がどうなるか、税務上の売上計上時期がいつかは、ツールの外で判断する話や。会計ソフトの代替でもないし、税務判定でもない。請求額の確認には使えるけど、会計処理の正解を保証するものやない。 ここの線引きは、最初に意識しておいたほうがええ。

Q. 第3回ではどこへ進む予定ですか

第3回は、作った見積書・請求書をクライアントへ送る部分を自動化する。発行者マスタへメール送信情報を追加して、メール本文テンプレートをマスタとして管理し、Gmailを経由してPDFを添付して送る。あわせて、請求一覧をGoogleスプレッドシートと連携させて、ブラウザの外でも数字を確認できる形を検討する。「自分が使えればええ」前提のまま、外部サービスとの接点を最低限つなぐ段階や。