社内の請求管理を作り直しています。まだ途中です。

きっかけは、すでに動いていた表が、自動化の土台にならなかったことでした。壊れていたわけでも、使いにくかったわけでもありません。むしろ人にとっては見やすい表でした。

うちはタレント事務所を経営していて、社員3人で所属80名を回しています。人を増やせないので、実務はAIに寄せています。この記事は、その過程で詰まった話です。

ゴールが3つあった

作り直すにあたって、満たしたい条件が3つありました。

1. 管理しやすいこと（更新や修正が面倒でない）
2. 人が見て分かりやすいこと（社内の誰が見ても読める）
3. Claude Codeで自動化できること（処理を任せられる）

今の表は、2番はできていました。 人が見れば分かるし、実際に運用も回っていました。

詰まったのは3番です。

見やすい表が、自動化できないことがある

自動化しようとしたときに分かったのは、人が見て同じ意味に見えるものが、機械にとっては別物として扱われるということでした。

人は文脈で補って読みます。書き方が多少ばらついていても、「これとこれは同じことを指している」と判断できる。機械はそれをしません。 少しでも形が違えば、別のものとして処理します。

結果として何が起きるか。データに共通性がないので、処理のルールが作れません。

「この場合はこう、ただしこの場合は例外で……」と条件を足し続けることになり、例外を書き足す作業が自動化そのものより重くなります。これでは意味がありません。

表が悪かったのではなく、人向けに最適化された表を、そのまま機械に渡そうとしたことが間違いでした。

「見やすさを捨てる」という話ではない

ここでよくある誤解が、「じゃあ機械が読みやすい形に作り直せばいい」というものです。

うちも一度そう考えました。ただ、それをやると2番のゴール（人が見て分かりやすい）が壊れます。機械が扱いやすい形は、たいてい人にとっては読みにくい。

3つのうち1つを捨てる、という選択になってしまいます。

データと、人が見る表を分ける

たどり着いた結論はこうです。

データ自体は機械が扱える形で持っておいて、人が見る表はそこから作る。

同じ表で両方を満たそうとするから、どちらかを諦めることになります。役割を分ければ、3つとも成立します。

	持ち方	目的
データ	機械が扱える形。表記や構造を揃える	自動化の土台
表示	データから生成する	人が見て分かる

人が見る表は、データから作られる結果という位置づけになります。表を直接編集するのではなく、データを更新すれば表も変わる。

この形にすれば、見やすさを捨てずに自動化できます。

先に決めるべきだったこと

この件で得た教訓は、順番の問題です。

自動化しようとすると、つい「どのツールを使うか」から考えます。うちも最初はそこから入りました。でも、土台が揃っていないと、何で作っても同じところで詰まります。

• ツールを変えても詰まる
• AIの性能が上がっても詰まる
• 書き方を工夫しても、例外が増え続ける

詰まっているのは実装ではなく、データの持ち方だからです。

だから今回は、実装より先にデータの形から手をつけています。遠回りに見えますが、ここを飛ばすと後で全部やり直しになります。

今の状態

まだ作り直している最中です。うまくいったかどうかは、まだ書けません。

分かっているのは、次のことだけです。

• 人が見て同じでも、機械には別物として扱われるものがある
• 見やすい表と、自動化できる表は、同じではない
• 両立させるなら、データと表示を分ける
• 道具を変える前に、データの形を直す

結果が出たら、また書きます。うまくいかなかった場合も、そのまま書きます。

---

このアプリでは、肝心の機能より先にCSV書き出しを作りました。理由は今回と同じで、先に土台を用意しておかないと、あとから直せなくなるからです。

なお、この作り直しの前段として、領収書のスキャンからデータ化までは自動化が済んでいます。そちらは完了しているので、比較すると「何が違ったのか」が見えてきそうです。 それも別の記事にまとめる予定です。