The Bespoke Half — ソフトウェアが取り残した経理作業を、エージェントに教える

Progressive Export 論の実地報告 — ホワイトカラー労働について。

要旨

ホワイトカラー業務の一部が自動化されずに残ってきたのは、知的に難しいからではない。一社ごとに個別で、量が少なすぎて、ソフトウェアを書く採算が合わなかったからである。経理の証憑集めはその典型だ。会社ごとに領収書の在り処が違う——e-invoice、複数の受信箱、ベンダーのポータル——ので、どのコネクタも開発費を回収できない。

私は自分の会社の帳簿で、別の経済を試した。手順を AI エージェントに自然言語で一度だけ教え、以後の作業はエージェントにやらせる。 教えるコストはベンダーあたりおよそ8行。エージェントは13か月・149件の銀行取引を処理した——19ベンダーの領収書が、銀行内の e-invoice、2つのメールアカウント、ログイン必須のポータルに散らばっている。領収書を要する全取引に125枚の文書が付き、欠落はゼロ。会計事務所への受け渡しも、手動アップロードとメール添付から、観客1社のための小さな web アプリに変わった。

範囲を正直に言う。13か月のうち12か月は一度の遡及パスで再構築したもので、ベンダー辞書はその同じ12か月から書かれ、前向きに月次処理をしたのは正確に1か月である。そして「collected」は文書が保存されたという意味であって、その文書が正しいという意味ではない。

得られた知見は、時間スケールで割れた分業の形だ。毎月残るのは強認証だけ——法が人間に固定している。散発的に人間が呼び戻されるのは教えるときだけ——新しいベンダーが初めて現れたとき、教えた手順が壊れたとき。どちらの検出も無料だ。銀行明細は「処理すべき全件」の外部・法定の列挙であり、エージェントが取れなかったものは missing として勝手に浮上する。恒常的に残るのは承認と責任。コードは圧力が正当化した場所にだけ現れた——証跡は git に、会計士向けインターフェースは小さな web アプリに——それ以外には現れなかった。orchestration は prose に落ち着いた。月10件の量では、教えることは自動化の試作ではなかった。その継ぎ目にとって、教えることが自動化そのものだった。

ホワイトカラー置換が実際に取る形は、これだと思う。コネクタは高い固定費を多数の顧客で償却し、標準化された頭を取る。教えることは手順あたりほぼゼロ円で、bespoke な尾を取る——人間がいまだに手でやっている仕事の多くはこちら側だ。人間に残ったのは難しい部分でも知的な部分でもない。法が個人に固定した認証、教える価値がないほど稀な判断、そして責任。自動化は責任を消さなかった。再配置し、集中させた。

これが他所に移るのは、外部の正解データがあり、失敗が安く表面化し、量がソフト化の閾値を下回っている場所である。

1. 主張

どの会社にも、自動化をすり抜けてきた仕事の山がある。理由は誰もはっきり言わないが単純で、自動化する価値がなかったからだ。難しいのではない。一社に固有すぎて、量が少なすぎて、ソフトウェアが正当化されない。私の場合それは経理の証憑集めだった。毎月、銀行明細の全取引について、その裏にある領収書をどこにあろうと探し出し、会計事務所に渡す。

試した賭けは単純だ。手順を AI エージェントに自然言語で一度だけ教え、以後はエージェントにやらせる。新しいものが現れたら、もう一度だけ教える。コネクタなし、新しい会計プラットフォームなし、workflow の特定の部分が要求しない限りコードもなし。

観察されたのは、職がひとつの単位として消える光景ではなかった。workflow が継ぎ目で裂けた。 反復実行はエージェントへ移り、安定した部分はファイルとひとつの小さなアプリに固まり、人間の役割は教えること・例外・責任に縮んだ。前のエッセイ Progressive Export はこのパイプラインを理論として描いた。これはその実地報告である——理論の著者（私）の最初の読みどおりに行かなかった部分も含めて。

2. 実際にやったこと、やらなかったこと

素材は私の1人会社の帳簿だ。13か月で149行の銀行明細、月あたり7〜17行。うち125行は領収書を要し、現在すべてに文書が付いている。24行は不要（銀行手数料、税金、入金）。欠落はゼロ。その裏に19本のベンダー別レシピ——各およそ8行の自然言語——と、エージェントが最初から最後まで従う1本の runbook がある。

合計値より、どう走らせたかの方が重要だ。13か月のうち12か月は、一度の遡及パスで再構築した——ベンダー単位の一括処理で、あるベンダーの欠落月を全部まとめて取り、次のベンダーへ移る形だ。ベンダー別レシピはこのパスから書かれた。その後、本来の運用どおり前向きに処理した月は正確に1つ。つまり held-out の証拠は1か月分であり、これは脚注ではなくここに書いておく。辞書は12か月で訓練され、1か月でテストされた。

もうひとつ、この報告全体が寄りかかる定義がある。「collected」は取引に対して文書が保存された、という意味でしかない。失敗には音量差がある。エージェントが領収書を取得できなければ、その取引は missing のまま残る——うるさく、見え、検出は無料だ。だがもっともらしくて間違った文書を正しい取引に付けた場合、それは黙って通る。coverage 1.0 が測っているのは収集の完全性であって、正確性ではない。正確性の監査はまだ行っていない。

納品側も変わった。領収書と照合済み明細を会計事務所へ渡す作業は、手動アップロードとメール添付だった。今はアーカイブの上に載る小さな読み取り専用 web アプリだ。パスワードログイン、月ごとに1ページ、各取引から文書へのリンク。観客は正確に1社の会計事務所で、変更の要望が来ればその日のうちに出せる。

測っていないもの、したがって主張しないもの：削減された人間の時間、トークンコスト、介入回数、いかなる「ゼロタッチ率」も。

3. ソフトウェアが取り残した仕事

なぜこの仕事は会計ソフト20年の歴史を生き延びたのか。領収書の実際の在り処を見ればいい。あるものは銀行の UI の中から取れる e-invoice で届く。あるものは会社の受信箱に届き、数件は私の個人受信箱に個人宛で届く——何年も前にそうやってアカウントを作ったからだ。あるものはメールの本文としてしか存在せず、ダウンロードする添付がない。あるものはログイン済みブラウザを要するポータルの奥にある。あるベンダーは同じ月に同じ送信元から2回請求する——ユーロのサブスクリプションとドルの API 従量課金——そして両者を混同してはならない。ドルで請求して銀行はユーロで引き落とすベンダーが複数あり、領収書の額面と明細の額面は一致しない。チャージに中国の VAT を上乗せするベンダーもある。

この散らばり方は二社として同じではない。ソフトウェアベンダーがやるなら、ソースごとにコネクタを作って保守し、それぞれ異なる部分集合しか必要としない顧客たちで償却することになる。長い尾では、この算術は永遠に閉じない。この仕事が手作業のまま残ったのは難しいからではなく、bespoke だからだ——技術的には可能、経済的には不合理。

この算術は身をもって証言できる。この収集作業は創業以来ずっと頭痛の種だった。私はカーネルエンジニアを20年やった。解決するシステムを作る技術は十分手の内にあった。それでも作らなかった。私自身の時間予算が、ソフトウェアベンダーたちと同じテストに落ちたからだ。

変わったのは初期実装のコストである。私はシステムを設計しなかった。エージェントと並んで実際の作業をした——受信箱を検索し、ポータルを歩き、失敗し、やり直した——そして成功した run が2つの成果物に蒸留された。各ベンダーの領収書の在り処と取り方を記録する辞書（ベンダーあたり約8行、注意点込み）と、エージェントが毎月従う runbook だ。前のエッセイは LLM CLI を「新しい REPL」と呼んだが、実践での感触はまさにそれだった。アーキテクチャは先に描かれたのではない。動く作業セッションから析出した。

4. ひとつの workflow、複数の成熟度

結果に対する私の最初の読みは間違っていて、その訂正がこの報告で一番役に立つ部分だ。私は「パイプラインは skill 段階で止まった——prose が終着点だった」と言いたかった。だが現存するシステムはその要約を拒む：

継ぎ目	現在の居場所	成熟度
ベンダー固有の知識	辞書	教えた prose（procedural memory）
orchestration・例外判断	runbook	教えた prose
メール／ブラウザ／銀行の操作	既存の型付きツール	MCP
証跡・監査trail	アーカイブ（git 上のプレーンファイル）	決定論的
状態と欠落の可視化	取引ごとに1行の status	構造化テキスト
会計事務所への納品	web アプリ	コード
無人実行（スケジュール、リトライ）	—	未実装
正確性の検証	—	未実装

システムは skill 段階で止まらなかった。orchestration だけがそこに落ち着いた。 同じ workflow の異なる継ぎ目が、異なる深さまで export された——そしてその深さは、前のエッセイが列挙した export 圧力と、両方向で一致する。

圧力があった場所では、export が起きた。証跡は私以外の人間が検査できる耐久性を要した：初日から git 上のプレーンファイルへ。納品は外部の当事者に消費される必要があった：web アプリへ。

圧力がなかった場所では、それでも export を試みて——失敗した。教えた手順の一部をコードに置き換えようと2回動いた。1回目は動くコードまで到達した。決定論的なマッチングエンジンと回帰ベンチだ。そこから学んだのは主に、私が間違った継ぎ目を選んだということだった——形式化できるのは matching だったが、ボトルネックは retrieval だった——しかもベンチ自体が、テストした唯一の月で訓練していたことが判明した。2回目のより重い設計は実装前に停止し、その判定は設計書のヘッダに残っている：over-engineered for ~10 receipts/month。この量では、prose は置き換えるコードより安く、コードの方が良いと証明するためのベンチマークよりはるかに安い。

圧力があるのにまだ支払われていない場所：スケジューラは今もなく——人間が月を起動する——正確性の検証器もない。そして export が不可能な継ぎ目がひとつある。銀行と行政の認証は、ツールがどれだけ良くなろうと、法によって個人に固定されている。

つまり前のエッセイのパイプライン——explore、skill、MCP、app——は実在するが、アプリケーション全体が登る梯子ではない。継ぎ目ごとに適用される圧力の地図である。orchestration の継ぎ目にとって、月10件の量では、教えることは自動化の試作ではなかった。自動化そのものだった。

5. 移ったもの、残ったもの

エージェントに移ったものは列挙しやすい。この作業を苦役にしていたものそのものだからだ。ベンダーごとの探し方を覚えておくこと。同じ検索・ダウンロード・ファイル命名の反復。各文書を取引に紐付けて保存すること。欠落リストの維持。毎月ゼロから手順全体を組み直すこと。

人間に残ったものは、時間スケールできれいに分かれる。

毎月 — 認証。銀行ログインと強い本人確認は、法的に個人の行為だ。この床はソフトウェアの向上では侵食されない。能力ではなく規制が決めている。

散発的に — 教えることと判断。新しいベンダーが現れる：レシピを一度教える、数分、翌月からはルーチンだ。教えたレシピが壊れる——ベンダーがメール書式やポータルを変える：失敗は missing の行として勝手に表面化し、レシピを一度直す。そして時折、本物の判断を要する取引がある——実は立替精算だった引き落とし、キャンセルと再確定が重なった注文——教える価値がないほど稀なケースで、status ファイル上で手で決める。

恒常的に — 承認と責任。誰かがこの月は会計事務所に出せると決め、誰かが帳簿に責任を負う。会計士の署名は技術的な成果物ではないし、この実験のどの部分もそこには触れていない。

この配置を幸運ではなく安定にしているのが、teach-and-repair のループだ。銀行明細は「計上すべき全件」の外部・法定の列挙である。エージェントが取り損ねたものは、監視コストゼロで missing の行として現れる。うるさい失敗は自分で自分を取り締まる。静かな方——間違った文書が collected として通る——がこのシステムの本当の急所であり、その率は不明である、というのが正直な記述だ。

ここで自動化は責任を消さなかった。再配置し、集中させた：実行から、教えること・例外・署名へ。

6. ふたつの経済と、ホワイトカラー置換の形

bespoke な半分を自動化する方法はふたつあり、コスト構造が正反対だ。

コネクタ経済は統合を一度作り、多数の顧客で償却する。ヘルシンキのある YC スタートアップが、この賭けを最も強い形で走らせている。会計事務所とプラットフォームの垂直統合、自社元帳、内部で手作業をこなすエージェント、結果に署名する有資格の会計士。ソースあたりの固定費は高いが、仕事が標準化され量があるところでは勝つ。分布の頭に対しては正しいアーキテクチャだ。

教える経済——この実験——は手順あたりの固定費がほぼない。ベンダーあたり8行の prose を、workflow を既に知っている本人が教える。コネクタが永遠にペイしない場所——会社固有の散らばりの長い尾——でちょうど勝つ。両者は今日は補完、周縁では競合であり、そしてひとつのレジームが両者を融合させる。私が教えたことの多くは、実は私の会社に固有ではない。「この銀行の e-invoice は明細行からダウンロードできる」「EU 域外の SaaS 請求はリバースチャージ」「Stripe の領収書はメール本文で届く」。これらは世界についての事実だ。ある国の1人会社向けレシピ集はテンプレートとして出荷でき、private に残るのはアカウント固有の情報だけになる。教えたレシピが共有可能になった瞬間、教える経済はプラットフォームの様相を帯び始め、ふたつの経済の区別は溶ける。

このひとつの小さな実験は、「AI がホワイトカラーを置き換える」という大きな主張について何を示唆するか。慎重に、4つ。

置換の単位は職名ではなく、workflow の継ぎ目である。最初に消えるのは必ずしも「簡単な」仕事ではない——ソフト化する価値がなかった長い尾であり、それは別の集合だ。LLM は判断を置き換える前に、手順化の経済を変える。高くついていたのは領収書の意味を判断する工程ではなく、市場規模1の retrieval を作る工程だった。そして現実的な到達点は人間ゼロではない。zero-touch の happy path と、例外対応の人間——実行者から、教える人・例外の所有者・署名者へ移った人間だ。

この実験がまだ答えていないこと。次の実験が答えられるように挙げておく。

前向きの月次実行は1回。次の11か月がこの報告より多くを語る。
人間の時間もトークンコストも未計測。効率の主張は定性的なものに留まる。
正確性の監査がなく、静かな失敗の率は不明。
スケジューラがなく、今も人間が月を起動する。
移植性は未検証——ここで教えた skill はすべて、1人の人間・1つの会社・1つの規模に属している。
このスタックは会計ソフトへのロックインを、ひとつの有能なエージェントランタイムへの依存と引き換えにした。それもまたロックインであり、場所が変わっただけだ。

前のエッセイは (to be researched) と印を付けた問いで終わっていた。必要になったとき LLM が skill を自動で作る機構、である。この実験はその機構を作らなかった。もっと小さな、しかしおそらく前提となることをした。欠けている機械がどこに属するかを突き止めた——export 圧力の検出、候補 skill の受け入れ、配備後の検証。検証は、この領域に限っては銀行明細と一緒に無料で付いてきた。3つの部品のうち1つだ。残りの2つが次の実験であり、この workflow はいまや、それを走らせられる field site である。