PROJECT 04｜請求書をかっこよくしたかった。それだけやったのに。

ちょっと見た目を変えたかっただけやで？

愛媛の事務所で使っていたExcelの請求書。
以前、チャッピーが別の仕事で作った請求書を見て、うちの請求書ももう少しかっこよくしたいと思った。
そんな小さな相談から始まった仕事が、やがて大阪の既存システムも巻き込み、会社の業務システムを作る話になっていった。

有限会社ティムス／TIMS Documents

発端

「こっちの請求書の方が、かっこええやん。」

以前、チャッピーが別の仕事で作った請求書があった。
すっきり整理されたレイアウト。文字の配置も、余白の取り方も、なかなかいい。
一方、愛媛の事務所では、これまでExcelで見積書や請求書を作っていた。
使い慣れたExcelだし、仕事はできている。
ただ、見た目をもう少し何とかしたい。
そこでタカシは、普段使っているExcelをチャッピーに見せた。
最初の目的は、請求書のデザインをよくすること。
顧客管理システムを作りたいわけでも、新しいデータベースを構築したいわけでもなかった。
ましてや、会社の業務システムを一新するような話ではなかった。
ところが、この相談は思いがけない方向へ進んでいく。
このプロジェクトでやったこと
Excelの見積書・請求書を解析
大阪の既存WordPressシステムを確認
顧客・案件・帳票管理システムを構築
過去の帳票415件を移行
実務に合わせた帳票デザインを作成
本番稼働後も継続して改修
実写素材：元のExcel請求書、以前チャッピーが作った請求書、新しいTIMS Documentsの請求書。
手書き一言：「最初はデザインの話やったんやけどなぁ。」

このプロジェクトでやったこと

Excelの見積書・請求書195シートを解析
大阪のWordPressから顧客・帳票データを抽出
顧客・案件・見積・請求を一元管理するシステムを構築
過去の帳票415件を新システムへ移行
実際の業務で検証・改修し、本番稼働まで実現

請求書をかっこよくしたかっただけやのに、えらいことになったなぁ（笑）

01-1

最初は、ただ請求書をかっこよくしたかった。

きっかけは、以前チャッピー（ChatGPT）が別の仕事で作った請求書だった。
余白の取り方や文字の配置が整理されていて、すっきりしている。見慣れた事務書類なのに、ちょっとかっこいい。
「うちの請求書も、こんな感じにならんかな？」
愛媛で仕事をしているタカシは、それまで見積書や請求書をExcelで作っていた。
Excelは便利だ。必要な項目を並べて、計算式を入れれば金額も計算してくれる。前に作った請求書をコピーして、取引先や金額を書き換えれば、新しい請求書も作れる。
長年使ってきたし、仕事そのものはできている。
ただ、以前チャッピーが作った請求書と見比べると、やっぱり見た目が違う。
そこで、普段使っているExcelの請求書をチャッピーに見せた。
この時点では、新しい業務システムを作るつもりなどなかった。
顧客管理も、データベースも、サーバーも関係ない。
いつものExcelの請求書を、もうちょっとかっこよくしたい。
本当に、それだけの話だった。

01-2

そのExcelには、何年分もの仕事が入っていた。

タカシが使っていたExcelは、単なる請求書のひな形ではなかった。
見積書と請求書のファイルがあり、取引先ごと、仕事ごとにシートを作って保存していた。
実際に解析したところ、見積書は78シート、請求書は117シート。合わせて195シートが存在した。
記録されていた発行日は2022年9月から2026年9月まで。約4年間の仕事の履歴だ。
そこには、地元の学校や企業、団体などとの取引が残されていた。
ホームページの制作や管理、動画の撮影・編集、デザイン、印刷物の制作。タカシが実際に請け負ってきた仕事の記録である。
1枚のシートには、取引先、発行日、件名、作業内容、数量、単価、消費税、合計金額などが入っている。
つまり、普段は請求書を作るために使っていたExcelが、結果として過去の取引記録の保管場所にもなっていた。
しかし、ExcelにはExcelの事情がある。
過去の書類を探すには目的のシートを見つけなければならないし、同じ顧客でも名前の表記が違うことがある。
新しい請求書を作るたびに、以前のシートを参考にして入力する部分もある。
もちろん、それまで大きな問題にならずに仕事を続けてこられたのだから、Excelが悪いわけではない。
ただ、改めて中身を見てみると、請求書のデザイン以外にも、改善できそうな部分が見えてくる。

01-3

請求書の見た目と、中身のデータは別のもの。

請求書には、毎回変わる情報と、ほとんど変わらない情報がある。
取引先の名前や住所、ティムスの会社情報、振込先。これらは、一度登録しておけば何度も使える情報だ。
一方、件名、作業内容、数量、単価、発行日などは、仕事のたびに変わる。
そして、こうした情報を紙のどこに配置するのかという「デザイン」は、本来、入力するデータとは別に考えられる。
Excelでは、それらが一枚のシートの中にまとめられている。
見た目を直そうとすると、セルの結合、罫線、文字サイズ、印刷範囲なども気になってくる。
しかし、もし必要な情報を入力するだけで、決まったデザインの請求書が出来上がるならどうだろう。
取引先は登録済みの一覧から選ぶ。件名と明細を入力する。保存して、必要なら印刷する。
デザインは毎回作り直さなくてもいい。
最初は見た目の話だったのに、こう考えると、帳票の作り方そのものに別の可能性が見えてくる。
請求書をかっこよくすることと、請求書を作りやすくすること。
この2つを、同時に考えられるようになった。

01-4

作り方が変わると、管理の仕方も変わる。

請求書の作成方法を考えていくと、その前後の仕事も関係してくる。
通常、いきなり請求書だけを作るわけではない。
仕事の相談を受け、内容を確認し、見積書を作る。受注して作業を進め、納品したら請求書を発行する。
その後、入金を確認する。
それぞれ別の作業に見えるが、すべて一つの仕事につながっている。
例えば、見積書に入力した顧客名や件名、作業内容を、請求書でもう一度入力する必要はあるだろうか。
同じ顧客から別の仕事を依頼されたとき、過去の取引をすぐ確認できたら便利ではないか。
発行済みの請求書が入金されたかどうかも、同じ場所で分かれば確認しやすい。
こうした機能は、請求書のデザインを直すだけなら必要ない。
けれど、日常の仕事全体を見渡せば、決して特別な機能でもない。
どれも、ティムスが普段から行っている作業だからだ。
新しい帳票の作り方を考えることが、仕事の流れを整理することにもつながっていった。

01-5

小さな相談が、大きな仕事に育っていく。

AIと一緒に仕事をしていると、最初に考えていた範囲を越えて話が広がることがある。
一つの問題を解決しようとすると、その隣に別の問題が見つかる。
それを調べていると、今まで当たり前だと思っていた作業にも、違うやり方があることに気づく。
今回も、最初から完成形の設計図があったわけではない。
タカシがやりたいことを伝え、チャッピーが実現方法を考える。
提案された内容を見て、タカシが「それなら、こっちもできるんちゃう？」と考える。
そうして、少しずつ仕事の範囲が変わっていく。
ただし、AIができると言ったことを、全部やればいいわけではない。
本当に必要なのか。今までの仕事と合っているのか。使いやすくなるのか。
それを判断するのは、実際に仕事をしている人間だ。
請求書のデザインを直すだけで終わることもできた。
でも、今回はそこでは終わらなかった。
新しい仕組みを考え始めたところで、もう一つ重要な存在が関係してくる。
大阪のティムス本体で使っていた、別の業務システムだ。

02-1

愛媛はExcel、大阪はWordPress。

ティムスには、愛媛とは別に、大阪で使われている業務管理の仕組みがあった。
大阪側では、WordPressに導入したBillVektorを使い、顧客情報や見積書、請求書を管理していた。
一方、愛媛ではExcelで見積書や請求書を作っていた。
つまり、同じティムスの仕事でありながら、帳票を作る環境が二つに分かれていた。
愛媛はExcel。大阪はWordPress。
それぞれ、必要に応じて運用してきた仕組みだ。
ここで重要なのは、大阪のWordPressが単なるホームページではなかったということ。
顧客や帳票を管理する、実際の業務システムとして使われていた。
もし愛媛のExcelだけを新しい仕組みに置き換えるなら、大阪側は今までどおりでもいいかもしれない。
しかし、新しい帳票管理の仕組みを構築するのであれば、すでに大阪で使っているシステムをどうするかという問題が出てくる。
同じ会社で、似たような業務を別々の仕組みで行い続けるのか。
それとも、この機会にまとめるのか。
話は、請求書の見た目から会社全体の業務管理へと広がっていった。

02-2

大阪には、過去の取引記録が残っている。

大阪のBillVektorを調べると、顧客情報だけでなく、過去に発行した見積書や請求書も保存されていた。
移行対象として確認されたのは、顧客53件、見積書37件、請求書185件。
見積書と請求書だけでも222件になる。
これらは、過去の実際の取引に関する記録だ。
新しいシステムを作るからといって、不要になるものではない。
昔の仕事について問い合わせが来ることもあれば、以前の見積内容を参考にすることもある。
そうしたときに、古いシステムを開かなければ確認できない状態では、せっかく新しい仕組みを作っても仕事が分散したままになる。
かといって、過去の記録をすべて手入力するのも現実的ではない。
まずはBillVektorにどんなデータがあり、どのような形式で保存されているのかを調べる必要があった。
新しい画面を作る作業とは別に、過去のデータを引き継ぐための準備が始まった。

02-3

顧客と仕事と書類は、別々に考える。

TIMS Documentsでは、業務を管理する基本構造として「顧客」「案件」「帳票」を分けることにした。
例えば、ある企業からホームページ制作を依頼されたとする。
企業そのものが「顧客」。
ホームページ制作という仕事が「案件」。
その仕事のために発行する見積書や請求書が「帳票」だ。
同じ企業から翌年に別の依頼があれば、顧客はそのままで、新しい案件を作る。
その案件に、また別の見積書や請求書が紐付く。
こうしておけば、同じ顧客との複数の取引を整理して管理できる。
逆に、顧客と請求書を直接結び付けるだけでは、一つの顧客から複数の仕事を受けた場合、どの請求書がどの仕事のものなのか分かりにくくなる。
これは難しいプログラムの話ではない。
実際の仕事がどのように流れているかを、システムの構造に置き換える作業だ。
チャッピーは、その構造をプログラムとして組み立てる。
タカシは、実際のティムスの仕事に照らし合わせて、使いやすいかどうかを判断する。

02-4

見積書から請求書へ。その間には仕事がある。

実務では、見積書と請求書は別の役割を持っている。
見積書は、これから行う仕事の内容と金額を提示するもの。
請求書は、実際の仕事に対して支払いを求めるものだ。
だから、新しいシステムには、見積書から請求書を作成する機能を用意した。
顧客名や件名、明細など、引き継げる情報は利用する。
ただし、見積書の内容がそのまま請求書になるとは限らない。
実際に仕事を進める途中で、作業内容が変わったり、項目が追加されたりすることもある。
そこで、請求書を作った後は見積書と独立して編集できる設計にした。
元になった見積書を勝手に書き換えることはしない。
また、請求書には発行済み、未入金、入金済みという状態を持たせ、入金日も記録できるようにした。
請求書を発行することがゴールではなく、その後に入金を確認するところまでが仕事だからだ。
帳票の作成機能を考えることが、仕事の進行状況を管理する仕組みへとつながっていった。

02-5

過去の書類には、過去の事情がある。

新しいシステムでは、原則として案件を登録し、その案件に見積書や請求書を紐付ける方針にした。
しかし、過去の帳票はどうするのか。
昔のExcelやWordPressに保存されている書類には、新しいシステムで使う「案件」という管理単位が設定されていないものもある。
それらに無理やり案件を設定しようとすると、本来存在しなかった情報を作ってしまう可能性がある。
そこで、これから作成する新しい帳票と、移行する過去の帳票を区別した。
新しく作る帳票は、原則として案件と紐付ける。
一方、過去の帳票は案件が未設定でも保存できるようにする。
新しい管理方法を採用しながら、昔の記録を無理に変えない。
さらに、過去のデータは元の情報を保持する構造とした。
これはシステムの都合だけで考えると、少し面倒な設計かもしれない。
しかし、長年営業してきた会社の記録を扱う以上、過去の事実を守ることは重要だった。

02-6

既存の仕事を、新しい仕組みへつなぐ。

こうしてTIMS Documentsは、単に見積書や請求書を作るだけのアプリではなくなっていった。
顧客を登録する。
案件を作る。
見積書を発行する。
仕事を進め、請求書を作る。
入金を確認する。
さらに、過去の取引履歴を参照する。
それまで愛媛のExcelと大阪のWordPressで行われていた仕事を、一つの仕組みの中で扱えるようにする。
ここでタカシが判断しなければならなかったのは、どんな機能が作れるかだけではない。
これまでの業務を、どういう形で残し、どういう形に変えていくのかということだった。
チャッピーがコードを書くことはできる。
しかし、ティムスの仕事をどう整理するべきかという最終判断は、会社の業務を知るタカシの役割だった。
そして、設計が進むにつれて、もう一つの大きな作業が待っていた。
過去の見積書や請求書を、実際に新しいシステムへ引っ越すことだ。

03-1

Excelの195シートlを、どうやって読み取る？

愛媛で使用していたExcelには、195シートの見積書・請求書があった。
これらをすべて新しいシステムに移すには、シートごとに保存されている情報を取り出す必要がある。
顧客名、発行日、件名、明細、数量、単価、金額、税額、備考。
Excel上では、人間が見れば帳票として理解できる。
しかし、新しいシステムに取り込むためには、それぞれの値を決まった項目として整理しなければならない。
さらに、帳票ごとにシート名や入力内容が異なる。
過去に作ったシートをコピーしながら運用してきたため、すべてが完全に同じ状態とは限らない。
この作業を人間が一件ずつ手入力することもできる。
ただし、195件となると相当な手間だ。
しかも、日付や数字を一つ入力し間違えただけで、元の帳票と異なる記録になってしまう。
そこでExcelの内容を解析し、移行用のデータに変換する方法を取った。
チャッピーの役割は、Excelの中にある情報を読み取り、新しいシステムで利用できる形に整理することだった。

03-2

同じ顧客なのに、名前が違う。

データを整理していくと、人間にとっては当たり前でも、コンピューターにとっては問題になることが出てくる。
その一つが、顧客名の表記揺れだ。
例えば、会社名の途中にスペースが入っていたり、全角と半角が混在していたりする。
人間なら同じ会社だと気づく場合でも、コンピューターは別の文字列として扱う。
そのまま登録すると、同じ会社が複数の顧客として作られる可能性がある。
そこで、表記を整理し、同じ顧客と判断できるものを結び付ける処理が必要になった。
移行データでは、元の顧客名と、整理した顧客名を区別して記録した。
こうしておけば、後から元のExcelでどのように書かれていたかも確認できる。
ただし、名前が似ているからといって、勝手に同じ顧客だと決めてしまうのは危険だ。
異なる法人や部署を誤って統合してしまう可能性もある。
データを整える便利さと、元の記録を正しく残すこと。
その両方を考えながら作業を進める必要があった。

03-3

コピーされたシートと、重複データ。

Excelで帳票を管理していると、以前のシートをコピーして新しい書類を作ることがある。
そのため、シートが複数あるからといって、すべてが別の取引とは限らない。
移行対象の195シートを解析すると、重複しているデータも見つかった。
重複は2組、合計4シート。
移行時には、それぞれの組から重複分を除外し、195シートから193件の帳票を登録した。
ここで注意したいのは、単に同じ顧客名や同じ金額だからといって、重複とは限らないことだ。
同じ取引先に、同じ金額を複数回請求する仕事もあり得る。
大切なのは、帳票の内容を比較し、同じ記録を二重に登録しないこと。
移行用データには、元のファイル名やシート名なども保存した。
どのデータが、どのExcelシートから来たものなのかを確認できるようにするためだ。
ただ数を減らせばいいのではない。
過去の取引記録を、重複させず、欠落させずに引き継ぐ必要があった。

03-4

請求書の金額は、勝手に直せない。

Excelのデータを解析すると、小数点以下の端数を含む金額も存在していた。
消費税の計算や、過去の計算式によって生じたものだ。
こうした値を新しいシステムに取り込むとき、表示上の金額と内部の計算結果が一致しないことがある。
例えば、帳票に表示されていた金額を、新しいシステムで改めて計算し直した場合。
計算方法や端数処理が異なれば、結果が変わる可能性がある。
見積書や請求書において、これは無視できない問題だ。
過去に発行した請求書の金額が、新しいシステムへ移しただけで変わってしまっては困る。
そこで、新しいシステムで管理する情報とは別に、移行元の内容を残す仕組みが必要になった。
TIMS Documentsでは、旧帳票の元データを「legacy」として保持する設計を採用した。
新しい画面上では帳票を編集できるようにしながら、移行前の情報も残す。
そうすれば、後から数字の違いが見つかったときも、元の記録を確認できる。
AIがデータを読み取れることと、そのデータを安心して仕事に使えることは、同じではない。
特にお金に関する記録では、元の情報を残すこと自体が重要な機能になる。

03-5

大阪のWordPressにも、別の形式のデータがある。

愛媛のExcelの次は、大阪側のBillVektorだ。
こちらはExcelのシートではなく、WordPressで管理されていたデータになる。
顧客情報も、見積書や請求書も、Excelとは異なる形式で保存されている。
移行対象として確認したのは、顧客53件、見積書37件、請求書185件。
帳票だけで222件になる。
新しいTIMS Documentsでは、ExcelとBillVektorという異なる保存形式の情報を、同じ仕組みの中で扱えるようにする必要があった。
それぞれのデータを読み取り、必要な項目を整理し、新しい管理構造に合わせて登録する。
ただし、元の形式が違う以上、すべての情報が最初から同じように揃っているわけではない。
だから、旧データを無理に新しい入力ルールへ合わせるのではなく、必要に応じて例外を許容する設計とした。
これは、最初から新しいシステムだけを使って仕事を始める場合には発生しない作業だ。
長年使ってきた仕組みを置き換えるからこそ、必要になる仕事だった。

03-6

415件の帳票が、新しいシステムに入った。

2026年9月24日。
愛媛のExcelから193件、大阪のBillVektorから222件。
合わせて415件の旧帳票を、TIMS Documentsへ登録した。
さらにBillVektorの顧客53件も取り込んだ。
もちろん、415件の帳票が登録されたからといって、すべての過去業務が自動的に整理されたわけではない。
新しい管理方法に合わせて案件を登録する必要があるものもある。
それでも、これまで別々の場所に保存されていた見積書や請求書を、一つのシステムから扱うための土台ができた。
新しく作ったシステムを、空っぽの状態から使い始める必要はない。
過去の仕事の記録を引き継いだ状態で、新しい運用を始められる。
ここまでの作業は、データをコピーするだけの単純な移行ではなかった。
Excelの解析、重複の確認、顧客名の整理、金額の扱い、旧データの保存、新しい管理構造への登録。
一つひとつを考えて進める必要があった。

03-7

データを引き継ぐことは、仕事の履歴を守ること。

データ移行が終わると、次に考えなければならないのは、その情報をどう扱うかだ。
例えば、もう取引が終わった顧客がいたとする。
新しい案件を登録する予定がないからといって、その顧客の情報を完全に削除してしまうとどうなるか。
過去の見積書や請求書との関係が失われる可能性がある。
そこでTIMS Documentsでは、取引が終了した顧客の履歴を保持し、関連する案件や帳票が存在する場合は完全削除を禁止する仕組みを用意した。
顧客番号も、削除したからといって別の顧客に再利用しない方針とした。
これらは、見積書をかっこよくするという当初の目的とは、ずいぶん離れた話に見える。
しかし、会社の取引履歴を扱うシステムである以上、必要な考え方だった。
新しいシステムを作ることは、今後の仕事を便利にするだけではない。
過去の仕事を、これからも確認できる形で残していくことでもある。
そして、データを移す大きな作業が終わると、いよいよタカシが最初にやりたかったことに戻ってくる。
肝心の請求書は、ちゃんとかっこよくなったのか。

04-1

システムが動いた。けれど、それだけでは完成じゃない。

顧客を登録できる。
案件を作れる。
見積書や請求書を保存できる。
過去の帳票も移行できた。
プログラムとしては、かなり多くの機能が揃ってきた。
しかし、ここでもう一度、最初の目的を思い出してほしい。
「Excelの請求書を、もっとかっこよくしたい」
そう。そもそもはデザインの話だった。
いくら立派な顧客管理機能ができても、出来上がる請求書の見た目が気に入らなければ、最初の目的を達成したことにはならない。
しかも、請求書は社内だけで使う画面ではない。
取引先に提出する正式な書類だ。
会社名、住所、件名、明細、金額、振込先。
必要な情報が正しく表示されることはもちろん、受け取った相手が読みやすいことも重要になる。
だから、帳票が表示できたというだけでは終われなかった。
ここからは、実際の請求書の見た目を仕上げる作業が続いた。

04-2

人間には普通に読めても、プログラムには分からない。

帳票のデザインを調整するとき、意外に難しいのが文字の配置だ。
例えば、取引先の法人名が長い場合。
人間なら、どこで改行すれば自然に読めるかを感覚的に判断できる。
しかし、プログラムは文字数や表示幅によって機械的に改行するため、不自然な場所で法人名を分割してしまうことがある。
会社名の途中で改行され、その次に担当者名が続く。
画面上では大きな問題に見えなくても、正式な請求書としては違和感がある。
TIMS Documentsでも、この宛名の表示調整を繰り返した。
長い法人名と担当者名が、不自然に分割されないようにする。
一見すると小さな修正だ。
けれど、見積書や請求書の宛名は、書類の中でも最も目に入る部分の一つ。
こういうところこそ、実務で使う人間の判断が必要になる。
AIはコードを修正できる。
でも、その見た目が相手に失礼ではないか、会社の書類として違和感がないかを判断するには、人間の目が必要だった。

04-3

文字、余白、罫線、数字。細かい修正が続く。

帳票には、さまざまな情報が並ぶ。
発行日、請求番号、宛名、件名、明細、金額、振込先、備考。
それらを一枚のA4用紙の中に、見やすく整理しなければならない。
文字の大きさを変えれば、隣の項目とのバランスも変わる。
余白を狭くすれば情報は多く入るが、窮屈な印象になる。
金額欄を大きくすると見やすくなる一方、ほかの情報との配置を調整する必要がある。
こうした部分を一つずつ確認していった。
特に金額は、見間違えないことが重要だ。
小計、消費税、合計金額が分かりやすく並び、請求額が一目で理解できる必要がある。
帳票を作るプログラムには、正しい金額を表示する機能が必要になる。
しかし、それをどう見せるかは別の仕事だ。
データとして正しいことと、書類として読みやすいこと。
両方が揃って、初めて仕事に使える帳票になる。

04-4

ロゴも角印も、ちゃんと入れたい。

新しい帳票には、ティムスのロゴや角印も配置した。
見積書、請求書、領収書、納品書。
書類によって必要な項目や表現は異なる。
領収書には、収入印紙を貼る場所も用意した。
こうした要素を入れていくと、単に同じデザインを使い回すだけでは済まない。
必要な情報を整理し、それぞれの書類として適切な見た目に仕上げる必要がある。
タカシは、チャッピーが作った帳票プレビューを確認する。
気になる部分があれば修正を依頼する。
チャッピーがコードを変更し、再び表示を確認する。
このやり取りを繰り返していった。
ここで大切なのは、チャッピーが最初に提示したデザインを、そのまま正解にしないことだ。
AIが「できました」と言っても、実際の仕事に使う人間が納得できなければ完成ではない。
最終的にどのデザインを採用するかを判断するのは、タカシだった。

04-5

画面でよくても、印刷すると違う。

見積書や請求書は、パソコンの画面だけで使うものではない。
PDFで送ることもあれば、A4用紙に印刷することもある。
そのため、画面上で見やすいだけでは十分ではない。
印刷したときに文字が小さすぎないか。
余白は適切か。
表が途中で切れないか。
ロゴや角印が正しい位置に表示されているか。
こうした点も確認する必要があった。
実際の開発では、A4プレビューと印刷レイアウトを何度も調整している。
プログラムの画面を作ることと、紙の書類を仕上げることは、少し違う仕事だ。
そして、ここでもタカシのデザインや実務の経験が生きてくる。
チャッピーはレイアウトを実装できる。
タカシは、その書類を会社の名前で取引先に出せるかどうかを判断できる。
AIと人間が、それぞれ違う役割を担っている。

04-6

サーバーに置いたら、また問題が出た。

TIMS Documentsは、hetemlのusersAサーバー上で運用することにした。
認証にはFirebase Authentication、データ管理にはCloud Firestoreを採用。
一方、PDFやDOCXなどの実ファイルは、Firebase Storageの課金要件を考慮し、heteml側に保存する構成とした。
さらに、外部からアクセスできる公開部分と、設定ファイルや保存データなどを扱う非公開部分を分離した。
既存のWordPressも同じサーバーで動いているため、それを壊さないように公開先を分ける必要もあった。
ところが、本番サーバーへ配置すると、開発環境では正しく動いていた一部のファイル参照に問題が発生した。
原因は、公開するディレクトリの違いだった。
開発環境ではサイトのルートを基準に動いていたが、本番では /xxxxxxx-xxxxxxxxx/ というサブディレクトリで公開する。
そのため、画像やプログラムの読み込み先が正しく合わなくなっていた。
そこでViteの設定を修正し、ロゴや角印の参照先も公開ディレクトリに合わせて変更した。
プログラムを再ビルドし、もう一度サーバーへ配置する。
実際のURLでログインし、帳票を表示し、ロゴや角印が正しく表示されていることを確認した。

04-7

9月25日、ついに本番稼働。

2026年9月25日。
TIMS Documentsは、初めて本番環境での稼働確認を完了した。
顧客、案件、見積書、請求書などを管理できる仕組みが整い、旧データも移行された。
本番URLでのログインも成功し、帳票のプレビューも確認できた。
このときの本番対応ソースは、v0.7.15として資産化された。
ここまでの作業を振り返ると、最初の相談からずいぶん遠くまで来たことが分かる。
始まりは、Excelの請求書のデザインだった。
そこから、データの保存方法、顧客管理、案件管理、過去データの移行、帳票の印刷レイアウト、認証、データベース、サーバー構築まで進んだ。
タカシが最初から、これだけのシステムを設計していたわけではない。
チャッピーが一人で完成させたわけでもない。
必要なことを一つずつ考え、作り、確認し、修正してきた。
そして、ついに実際の仕事で使えるところまで来た。
ただし、このときはまだ、もう一つ大切なことに気づいていなかった。
システムは、実際に使い始めてからも変わっていくということだ。

05-1

完成した。と思ったら、まだ続きがあった。

2026年9月25日、TIMS Documentsは本番稼働を開始した。
新しい帳票を作成し、顧客や案件を管理し、過去の記録も参照できる。
最初に考えていた「請求書をかっこよくする」という目的からすれば、想像以上に大きなものが出来上がった。
しかし、業務システムというのは、完成した画面を眺めるためのものではない。
毎日の仕事で実際に使うものだ。
新しい取引先の見積書を作る。
過去の案件を探す。
請求書を発行する。
金額を確認する。
そうやって使っていくうちに、開発中には見えていなかった細かな問題が現れる。
TIMS Documentsも、本番稼働をもって開発が終了したわけではなかった。
9月26日以降も改修が続き、10月2日にはv0.7.19まで更新された。
本番で動いたことと、実務に合わせて使い続けられることは、別の話だった。

05-2

税込金額が、最初から決まっている。

実際の請求業務で出てきた課題の一つが、税込金額の扱いだった。
一般的な請求書では、税抜の単価や金額を入力し、消費税を加えて税込合計を計算する。
ところが、すべての取引がそうとは限らない。
例えば、Yahoo!関連の請求では、税込金額が先に確定している場合がある。
その金額を請求書に記載したいのに、システムが税抜金額として扱い、さらに消費税を加算してしまえば、当然、請求額は変わってしまう。
だからといって、すべての明細を税込入力に変更すればよいわけでもない。
通常どおり税抜金額を入力する仕事もある。
しかも、一枚の請求書の中に、税抜入力の明細と税込入力の明細が混在する場合も考えられる。
必要なのは、どちらか一方の方式に統一することではなかった。
仕事の内容に応じて、入力方法を選べること。
そこで、明細ごとに税抜入力と税込入力を切り替える機能を追加することになった。

05-3

税抜と税込を、明細ごとに切り替える。

税込金額が確定している場合、その金額をもとに税抜金額を逆算する必要がある。
例えば、税込11,000円と決まっている明細なら、税率10％の場合、税抜10,000円、消費税1,000円という関係になる。
ただし、実際の業務では、いつもきれいに割り切れる数字ばかりではない。
端数が発生する場合もある。
複数の明細が並ぶ場合もある。
税抜入力と税込入力を混在させれば、それぞれの計算結果を正しく合算しなければならない。
そこでTIMS Documentsでは、明細単位で入力方式を選び、税込確定額から税抜額を逆算する処理を追加した。
さらに、入力方式そのものも保存するようにした。
これが大切だった。
入力した瞬間だけ計算が正しくても、一度保存して再び開いたときに、税込入力だったことが分からなくなっては困る。
再編集した際にも同じ入力方式が維持され、金額が正しく扱われる必要がある。
単に計算式を一つ追加するのではない。
入力画面、計算処理、保存、読み込み、再編集。
それぞれが矛盾なく動くように修正する仕事だった。

05-4

本物の請求金額と一致するか。

新しい計算機能が完成しても、それだけで正しいとは言えない。
実際の仕事で使う金額と一致するかどうかを確認しなければならない。
そこで、BORSAの実際の請求データを使って検証した。
確認する金額は、213,828円。
税抜入力と税込入力を含む明細を処理し、請求書の合計金額が正しく一致するかを確認した。
結果は、213,828円。
実際の請求金額と一致した。
さらに、保存した帳票を再び開いた際にも入力方式が維持されることを確認した。
プログラムのビルドも成功し、本番環境での動作確認も完了した。
2026年10月2日、TIMS Documents v0.7.19として反映された。
ここで重要なのは、単に「AIが計算機能を追加できた」ということではない。
実際の業務で問題が見つかり、その条件を整理し、機能を修正し、本物のデータで結果を確かめたということだ。
AIがコードを書いても、それが本当に仕事に使えるかどうかは、実際の仕事と照らし合わせなければ分からない。

05-5

自分たちの仕事に合わせて、システムを育てる。

以前なら、既存のソフトウェアに自分たちの仕事を合わせるしかない場面もあった。
使っているシステムに機能がなければ、別の方法で計算したり、Excelで補ったりする。
必要な機能を追加したくても、自分たちでプログラムを修正できなければ簡単ではない。
しかし、TIMS Documentsでは違う選択肢ができた。
実際の仕事で問題が見つかったら、タカシがその内容を整理する。
チャッピーと相談し、どう修正すればよいかを考える。
プログラムを変更し、実際のデータで確認する。
問題があれば、もう一度修正する。
この繰り返しによって、システムを自分たちの仕事に合わせて変えていくことができる。
もちろん、何でも簡単にできるわけではない。
一つの機能を変更すると、ほかの部分にも影響する可能性がある。
データを保存する仕組みを変えれば、過去の帳票との整合性も考えなければならない。
だからこそ、人間の判断と確認が必要になる。
最初に作ったものを完成品として固定するのではなく、実際の業務で使いながら必要な改善を続ける。
TIMS Documentsは、そんな仕組みとして動き始めた。
思い返せば、最初はただ、Excelの請求書をかっこよくしたかっただけだった。
それが、過去の取引記録を引き継ぎ、会社の業務を整理し、実際に使うシステムを作る仕事になった。
そして、これからも必要に応じて変えていける。
変わったのは、請求書の見た目だけではない。
「自分たちの仕事に合う仕組みを、自分たちで作っていく」という選択肢が生まれたことだった。

CONCLUSION

請求書を直したら、仕事の仕組みまで変わった。

最初にやりたかったのは、請求書をもう少しかっこよくすることだった。
それが、愛媛のExcelと大阪のWordPressを整理し、過去の帳票を移し、新しい業務システムを作る仕事になった。
タカシがやったのは、ただAIにプログラムを書かせることではない。
普段の仕事を説明し、何が必要かを判断し、出来上がったものを確認し、気に入らなければ直す。
チャッピーは、データを解析し、構造を考え、コードを作り、修正案を出す。
そのやり取りを繰り返しながら、実際に使えるものにしていった。
そして、使い始めてからも仕事は続いている。
AIで会社のシステムを作ったというより、AIと一緒に、会社の仕事を作り直し始めた。
これが今回のTIMS Documentsの記録である。

最初は請求書をかっこよくしたかっただけやのに。

タカシに話してみる →