家計簿を作っていたら、「システム化するほどではない業務」が消えることに気づいた

今日、ChatGPTに家計簿を作ってもらった。

正確には、家計簿ですらない。

私は家計を細かく管理したいわけではなかった。ただ、「我が家では食費や日用品に、実際いくら使っているのか」を測りたかった。

目的は節約でもない。

生活費の実測値が分かれば、自分が今後どれだけ働き、いくら稼ぐ必要があるのかを計算できる。それが分かれば、将来に対する漠然とした不安を数字に変えられる。

だから必要な機能は、ほとんどなかった。

• 日付は今日の日付を自動表示
• 区分を選ぶ
• 金額を入れる
• 必要ならメモを書く
• 保存する

以上。

毎日PCを使うので、スマートフォンアプリである必要すらない。

そこでChatGPTと話しているうちに、

「これ、HTML一枚でいいのでは？」

となった。

そして、本当にHTMLファイルが一枚できた。

ブラウザで開けば動く。サーバーはいらない。インストールもいらない。入力したデータはブラウザに保存する。必要になったらCSVに書き出せる。

月末にCSVをChatGPTへ渡せば、月間食費や日用品費を集計してMarkdownに加工することもできる。

ここまでは、単に「AIに家計簿を作ってもらった」という話である。

問題は、このあとだった。

Excelを入力画面にする必要はあるのか？

私は会社で、ExcelやVBAを使った業務改善をしたことがある。

その中には、複数の参照テーブルと大量の変換ロジックを持ち、最終的には印刷・製本まで考慮しなければならない処理もあった。

そういう仕事なら、VBAやPythonを使う意味がある。

ところが、毎月10件程度しか発生しない仕事ならどうだろう。

Excelの指定フォーマットに、人間が一件ずつ入力している。

Excelだから、入力するセルを間違える。セルを結合する。書式を変える。数式を壊す。

入力規則のために別シートへリストを持たせたり、非表示シートを作ったりする。

そしてマニュアルには、

「このセルだけ入力してください」
「このシートは変更しないでください」
「この列は削除しないでください」

と書く。

そこで、家計簿のHTMLを見ながら思った。

Excelを最終的なフォーマットとして使うことと、Excelを入力画面として使うことは、まったく別の話ではないか。

入力だけHTMLにすればいい。

HTMLフォームに必要事項を入力させる。

選択肢はこちらで固定する。

日付なら日付入力欄にする。

必須項目が空なら、その場で止める。

条件によって必要な項目が変わるなら、JavaScriptのIFで必要な入力欄だけ表示する。

そして最後にボタンを押したら、既存システムが読み込めるCSVを出力する。

Excel側は、そのCSVを取り込めばいい。

既存のExcel資産を捨てる必要すらない。

マニュアルを「読ませる」必要もない

さらに考えると、HTMLにはもう一つ利点がある。

操作説明を画面そのものに埋め込める。

たとえば、

「中途採用」を選択したら中途採用に必要な項目だけを表示する。

ある条件を選択したときだけ注意事項を表示する。

入力値が不正なら、

「この項目は8桁の数字で入力してください」

と、その場で表示する。

画面の右側に操作ガイドを常時表示して、現在入力している項目に応じて説明を切り替えてもいい。

つまり、

Excel入力様式 + 入力マニュアル + 業務手順書 + 担当者が覚えている例外処理

の一部を、HTMLそのものへ埋め込める。

マニュアルを読ませて正しく操作してもらうのではない。

業務ルールをUIにしてしまう。

利用者は、画面から聞かれたことに答えればいい。

そして、先に「要件定義.md」ができる

ここで、もう一つ副産物に気づいた。

HTMLをAIに作らせるには、まずAIへ説明しなければならない。

誰が使うのか。

何を入力するのか。

どの項目が必須なのか。

選択肢は何なのか。

どんな条件分岐があるのか。

何をエラーとするのか。

最後に、どんなCSVを出力するのか。

だったら、コードを書く前に、それをMarkdownへまとめればいい。

要件定義.md

である。

そして人間が確認する対象を、コードではなく要件定義にする。

業務担当者はJavaScriptをレビューできなくても、

「この条件の場合は、この項目が必要」

という業務ルールならレビューできる。

要件が正しいことを確認したら、そのMarkdownをAIに渡してHTMLを生成させる。

さらに同じ要件定義から、

• テストケース
• 操作マニュアル
• HTML内のヘルプ
• 改修時の変更箇所

まで生成できる。

つまり、

業務知識
→ 要件定義.md
→ HTML
→ CSV / JSON / Markdown

という流れが作れる。

要件定義.mdを原本として残しておけば、数か月後に改修するときにもAIへ、

「この要件定義に次の仕様を追加して、HTMLを修正して」

と依頼できる。

小さなツールなのに、仕様が残る。

以前なら、こんなことは割に合わなかった。

「システム化するほどではない」という領域

ここで、ようやく気づいた。

生成AIによって変わったのは、単に「プログラミングが簡単になった」ことではない。

ソフトウェアを作ることが採算に合う最小単位が、猛烈に小さくなったのではないか。

以前なら、月10件の入力作業のために専用アプリを開発するなんて馬鹿げていた。

要件を整理する。

設計する。

コードを書く。

テストする。

マニュアルを書く。

保守する。

そこまでやるくらいなら、Excelで我慢したほうが安い。

だから世の中には、

「不便だけれど、システム化するほどではない」

という仕事が大量に残った。

ところが生成AIが、この計算を変えつつある。

業務担当者が自然言語で要件を説明する。

AIとの対話で要件定義.mdを作る。

AIがHTMLを書く。

AIに要件と実装を照合させる。

AIにテストケースを書かせる。

AIにマニュアルを書かせる。

しかも用途によっては、HTML/CSS/JavaScriptを一つのファイルへ全部入れてしまえばいい。

サーバーもいらない。

インストールもいらない。

使わなくなったら捨ててもいい。

すると、

「これ、毎日5分面倒だな」

程度の仕事にすら、専用ソフトウェアを作ることが合理的になり得る。

使い捨てアプリという発想

この発想そのものには先行する潮流がある。

生成AIによって、個人用・短期間用のmicro appやdisposable softwareを作る動きはすでに現れている。

single-file HTMLをAIに生成させ、小さな専用ツールとして利用する例もある。

Markdownで仕様を先に定義し、それをAI実装の原本にするSpec-Driven Developmentという考え方も発展している。

だから、ここで書いている個々の技術は新発明ではない。

ただ、非エンジニアの業務改善という視点からこれらを組み合わせると、かなり面白い。

要件定義.mdを原本として、業務ごとにsingle-file HTMLを生成する。

HTMLは、入力UIと簡単な業務ルールだけを担当する。

複雑な処理が必要ならCSVを境界として、Excel、VBA、Python、既存システムへ渡す。

HTMLが複雑になり始めたら、そこで別の技術へ移る。

何でもHTMLで作る必要はない。

HTMLが強いのは、それまで「わざわざアプリを作るほどではない」とされていた領域なのだと思う。

AI時代の業務改善は、大きなDXだけではない

企業のAI活用というと、大規模なシステム導入や、AIエージェント、生成AIを組み込んだサービスなどが注目されやすい。

でも、もっと小さな革命があるのかもしれない。

一人の担当者が毎月30分困っている。

あるExcelが使いづらい。

毎回同じ説明をしている。

毎回同じ形式へデータを書き換えている。

そういう仕事一つ一つに、

その仕事専用の小さなソフトウェアを置く。

そして、そのソフトウェアを作るコストより、面倒を我慢するコストのほうが高くなった瞬間に作る。

今日、私は食費を測りたかっただけだった。

だからChatGPTと話して、家計簿のHTMLを一枚作った。

そこから、

「Excelを入力画面にする必要、そもそもなかったのでは？」

と気づいた。

もしかすると生成AIが消していくものの一つは、

「システム化するほどではないから、仕方なく人間がやる仕事」

なのかもしれない。