毎月の​請求書作成を、​「来月も​回る​仕組み」に​作り変える​ ──取得・整形・計算・PDF・記録まで​一本化した​経理自動化の​制作事例

毎月だるい請求書作成。つらさの正体は計算ではなく「手順の散らばり」だった。スプレッドシート取得→当月シート抽出→フォント整形→金額計算→請求書PDF→保存・記録までを、AIで"来月も回る一本のフロー"に作り変えた話。出力できるPDFを角印入り・実用品質まで引き上げ、毎月の反復タスクを「今月分に差し替えて再実行」へ。反復実務の本体は成果物でなく"再実行基盤"だ、という制作事例。

甲斐ショウジ甲斐ショウジ
CAG主宰/合同会社ATK CAIO(最高AI責任者)
制作事例10分で読めます
制作事例技術毎月の請求書作成を、「来月も回る仕組み」に作り変える ──取得・整形・計算・PDF・記録まで一本化した経理自動化の制作事例

制作事例 | AI駆動開発の、動く証拠

毎月どうしても気が重い作業がある。請求書づくりだ。

正直に言うと、つらいのは計算そのものではない。つらさの正体は「手順が毎回散らばっていること」だった。元データをスプレッドシートから取り、当月分だけ残し、見やすく整え、ルール通りに金額を出し、体裁よくPDFにして、決まった場所へ保存する——一つひとつは難しくないのに、毎回それを思い出しながら通しでやるのが重い。しかもこれは、毎月決まった日に繰り返す反復タスクだ。

だから今回のゴールは「今月分の請求書を作ること」ではなかった。「この散らばった手順を、来月以降も同じ品質で回せる"一本のフロー"に作り変えること」だ。AI(コーディングエージェント)を相棒に、取得から記録までを通しで設計した制作事例として書く。

ダークでシネマティックな画面。左にスプレッドシートの表、右に整然とした請求書PDF、その間を一本の処理フローが繋いでいる構図。実データを含まない一般化モック
スプレッドシートから請求書PDFまで、散らばった手順を一本のフローに束ねる(実データなしの一般化イメージ)

01つらさの​正体は​「計算」ではなく、​「手順の​散らばり」

最初にやったのは、コードを書くことではなく手順の棚卸しだった。受け取った実務手順は、こういう連なりだ(内容は一般化している)。

ステップ散らばった手作業一本のフローに束ねる
取得業務報告のスプレッドシートを開く指定シートを自動取得
抽出当月のシートを探して残す当月シートだけを自動抽出
整形フォント・見た目を手で直す視認性の高い体裁に自動整形
計算電卓で請求額・消費税・税込生成ロジックに固定(決定論)
出力体裁を整えてPDF化実用品質のPDFを自動生成
保存決まった場所へ手で配置保存先へ自動配置+記録

※ 手順・項目は一般化。実際のクライアント情報・金額は含まない。

ポイントは、個々は簡単でも"分散"していること。取得・整形・計算・出力・保存が別々の場所に散っていると、毎回それを頭の中で再構築することになる。だから設計の第一歩は「請求書を作る」ではなく、この一連を曖昧さなく再現できる"仕様"に翻訳することだった。仕様にしてしまえば、あとはAIに実装を任せて高速に組める。

"曖昧さを潰す"とは、具体的にはこういうことだ。「2番目のシート」とは何を指すのか(当月か、固定位置か)、「見やすく」とは何をどう変えることか、保存名の規則は何か——人の頭の中では暗黙でも、自動化するには**判断の余地をゼロにする**必要がある。ここを詰めずにAIへ投げると、毎回少しずつ違う成果物が出て、結局人がチェックする羽目になる。仕様化は、自動化の前工程ではなく、自動化そのものの中核だ。

02取得から​整形まで​:現場の​"仕様差分"を​吸収する

まず、業務報告のスプレッドシートをExcel形式で取得し、当月シートだけを残す処理を組んだ。ここで現場ならではの罠に当たった。

  • スプレッドシート側のシート名が 2026/05 のようなスラッシュ区切りだった
  • ところが Excelのシート名にスラッシュは使えない

そのまま持ち込むと壊れる。だから出力側で 2026-05 に変換して吸収した。さらに、視認性の悪さも放置せず、全セルのフォントを見やすいもの(Meiryo系)に寄せる整形まで処理に含めた。「人が後で手直しする余地」を、できるだけ設計段階で潰しておく——これが後の"そのまま使える"に効いてくる。

こういう"仕様差分"は、ドキュメントを読むだけでは気づきにくい。実際にデータを通してみて初めて「あ、ここで壊れる」と分かる類のものだ。だからこそ、一度きりの手作業では毎回同じ箇所で引っかかる。フローに組み込んで吸収しておけば、来月は誰も気づかないまま素通りする。地味だが、これも"運用化"の一部だ。

スプレッドシート業務報告 当月シート抽出対象月だけ残す シート名を変換2026/05 → 2026-05Excelの仕様差分を吸収 フォント整形視認性を担保
取得→当月抽出→シート名変換(`2026/05`→`2026-05`)→フォント整形。現場の仕様差分は取得時に吸収する

03金額計算は、​人が​電卓を​叩かない

請求額の計算はシンプルだ。当月シートの所定列(稼働時間など)の合計を読み取り、時間単価を掛けて請求額、消費税を加えて税込額を出す。式そのものは難しくない。

だが、ここで大事にしたのは——この計算を"人が目で見て電卓を叩く手順"として残さなかったことだ。合計の読み取りから税込額の算出まで、請求書を生成するロジックの中に固定した。人が介在するほど、転記ミス・計算ミス・「先月どうやったっけ」が入り込む。数値はコード(決定論)に任せ、人は判断に集中する——CAGが一貫して大事にしている考え方が、ここでもそのまま効いている。

請求書は「お金の書類」だ。だからこそ、計算は**毎回まったく同じ手順で、同じ結果になる**ことが信頼の土台になる。気分や疲労で結果がぶれる人の手計算より、**同じ入力なら必ず同じ出力を返すコード**のほうが、この用途には圧倒的に向いている。AIにやらせるのは「読み取り」と「組み立て」まで。**金額そのものは決定論的なロジックが出す**——この境界の引き方が、安心して任せられる自動化と、こわくて結局見直す自動化を分ける。

「LLMに、計算をさせない。」記事のサムネイル 関連記事 | 同じ「数値はコード」の方針LLMに、計算をさせない。──口コミ分析SaaSで「数値はコードで、言葉はAIで」を貫いた話

04​「出力できる」を​「そのまま​使える」へ​:PDFの​実用品質

最初に出したPDFは、正直クオリティが低かった。出力はできた。でも、実務でそのまま出せる品質ではなかった。指摘された問題はこうだ。

  • 罫線が重なっている
  • 文字が太く大きく、圧迫感がある
  • 印鑑が入っていない

そこでPDF生成(帳票ライブラリ)側を作り直した。罫線と余白を整理し、文字サイズと太さを調整し、右上の情報ブロックを再配置し、角印画像を差し込み、備考文だけ細く小さくする。「出力できる」から「そのまま提出できる」へ引き上げた。ここは地味だが本質的だ——見た目の品質も、自動化の一部である。出力はできても「見づらいから結局手直し」になるなら、自動化としては弱い。実務で本当に使えるところまで持っていって、初めて仕組みになる。

帳票のレイアウトは、コードで座標とスタイルを一つずつ決めていく地道な作業だ。罫線をどこに引くか、余白をどれだけ取るか、どの情報を右上にまとめるか、角印をどの位置にどの大きさで重ねるか——これらを"パラメータ"としてコードに落とすと、次回以降も同じ体裁が一発で再現される。一度きりの見た目調整を手作業でやれば来月また同じことをするが、レイアウトをロジックに固定すれば、品質は無料で繰り返せる。見た目を作り込む手間こそ、自動化で報われる部分だ。

請求書PDFのBefore/After。左=罫線が重なり文字が圧迫し印がない状態、右=罫線整然・文字バランス良好・角印あり・備考は控えめ。実データを含まない一般化モック
Before(罫線重なり・文字圧迫・印なし)→ After(整然・角印・備考は控えめ)。見た目の品質も自動化対象(一般化モック)

05本体は​「1回分の​PDF」ではなく、​「再実行できる​基盤」

ここが、この制作事例でいちばん伝えたい設計判断だ。

今月分のPDFは、もちろん成果物だ。だが本当の中核成果物は、再利用できる生成スクリプトのほうだった。当月・対象シート・日付・出力ファイル名といったパラメータを差し替えれば再実行できる形に固めた。来月は「またゼロから思い出す」のではなく、今月分に更新して走らせるだけになる。

単発スクリプト 今月だけ・使い捨て 再実行基盤(CAG) 毎月 21日 当月・日付・出力名 差し替えて再実行
使い捨てスクリプトと、パラメータ差し替えで毎月回る再実行基盤は別物。価値があるのは後者

反復タスクで価値が高いのは、1回の出来栄えではない。"次回も同じ品質で回せること"だ。だから私たちは、単発の作業を頼まれても、可能ならその場限りでなく"運用できる形"に設計する。一度きりのスクリプトと、毎月回る基盤は、見た目は似ていても価値がまるで違う。

そのために効くのが、「変わるもの」と「変わらないもの」を分けておく設計だ。毎月変わるのは当月・日付・出力名といった少数のパラメータだけで、取得・整形・計算・レイアウトといった処理本体は変わらない。変わる部分を入口に集め、変わらない部分はロジックとして固める。こうしておくと、来月の作業は「入口の数値を直して走らせる」だけになり、ミスの入り込む余地も最小になる。再実行基盤とは、つまり"変更点を最小化する設計"のことだ。

06記録まで​閉じて、​初めて​"仕組み"に​なる

成果物(PDFとスクリプト)ができても、記録が飛ぶと次回また弱くなる。「先月どこに置いたっけ」「どう完了させたっけ」が毎回コストになるからだ。

だから生成で終わらせず、タスク管理の完了・進捗台帳の更新・作業ログの追記・作業フォルダのアーカイブまで、一連の締め処理を通しで閉じた。こうして初めて、この請求書作成は「今月分の作業」から"持続可能な月次フロー"になった。仕組み化とは、作る部分だけでなく、次回の自分が迷わない状態まで含めて設計することだ。

記録に残すのは、難しいことではない。「いつ・何を・どのルールで作り、どこへ置いたか」。たったこれだけでも、来月の自分は**ゼロから思い出す必要がなくなる**。反復タスクは、回せば回すほど「前回の記録」が効いてくる——一度きりの作業では生まれない、続けるほど軽くなる複利がここにある。だからCAGでは、生成と同じ重さで"記録して閉じる"ことを設計に含める。

07​締め:反復実務こそ、​AI駆動で​"運用"に​変える

請求書づくりは、派手な開発ではない。だが、こういう地味で反復する実務こそ、AI駆動開発がいちばん効く領域だと考えている。

理由は3つ。①つらさは計算でなく手順の散らばりにある——だから一本のフローに束ねる価値が大きい。②本体は成果物でなく再実行基盤——一度仕組みにすれば、毎月の認知負荷が消える。③見た目の品質まで含めて自動化する——"そのまま使える"まで持っていって初めて、人の手が空く。

CAGは、こうした反復実務を「来月も回る仕組み」に設計し切ることを得意としている。一回分を速く作るのは当たり前。その先で、次回以降も同じ品質で回り続ける形まで作るのが、AI駆動開発の本当の効きどころだ。

そして、この考え方は請求書に限らない。月次レポート、定例の集計、締め作業、定型の書類づくり——「毎回似たことを、少しだけ条件を変えて繰り返す」業務はすべて同じ型で仕組みにできる。取得・加工・出力・記録に分解し、変わる部分をパラメータに切り出し、品質をロジックに固定する。一社ごと・一業務ごとに形は違っても、"来月も回る"へ作り変える設計の型は同じだ。地味な反復ほど、積み重なる時間は大きい。そこを仕組みに変えるのが、いちばん費用対効果の高いAI活用だと考えている。

毎月21日がハイライトされたカレンダーと、その日に自動で走る取得・整形・計算・PDF・保存のフロー。手元はパラメータを少し直すだけ、という構図。実データなし
毎月決まった日に、取得→整形→計算→PDF→保存が自動で走る。人はパラメータを少し直すだけ

毎回手作業 vs 来月も回る仕組み。同じ「請求書を作る」でも、価値は別物だ。

観点毎回手作業CAG(来月も回る仕組み)
手順毎回思い出して通しで実行一本のフローに束ねて再実行
金額計算人が目で見て電卓ロジックに固定(決定論・ミス排除)
仕様差分その都度ハマる取得時に吸収(例 2026/052026-05
PDF品質出力後に手直し角印入り・実用品質を生成時に担保
中核成果物今月分のPDF再実行できる生成基盤+記録
来月またゼロからパラメータ差し替えで再実行

※ 本記事はCAGが手がけた業務自動化の制作記録を完全に匿名化し、一般化したもの。クライアント名・個人名・実金額・口座・請求先・実際の帳票・角印画像は一切含まない(v0・2026-05時点)。

脚注・出典

  1. 本記事はCAGが手がけた業務自動化の制作記録を完全に匿名化して一般化したもの。クライアント名・個人名・実金額・口座・請求先・実際の帳票・角印画像は一切含まない。図版は実データを持たない一般化モック。
  2. 構成技術:スプレッドシート取得、表計算ファイルの整形、帳票PDF生成ライブラリ(ReportLab系)、AIコーディングエージェントによる実装と反復タスク運用。いずれも一般的な技術の組み合わせ。
  3. 「数値はコードに固定し、人は判断に集中する」という方針は、CAGの別記事(口コミ分析の事例)でも一貫して採っている。

毎月の​"だる​い​繰り返し"、​来月から​回る​仕組みにしませんか。

請求書・レポート・定例の事務作業——一回分を速く作るだけでなく、次回以降も同じ品質で回る形まで設計します。あなたの反復実務、AI駆動で運用に変えます。まずはこのサイトのAIに相談してみてください。

このAIに相談する →

言語化できるものは、全て作る。

あなたの「作りたい」を、定価とスピードで形に。まずは無料の相談から。

制作事例を見る