税理士事務所に1ヶ月住み込んで、会計AIを作ってきた話

こんにちは！「Zeimee」という税理士事務所向けのAI記帳サービスを作っている、佐次本（さじもと）といいます。

タイトルの通りなんですが、7月から広島県の税理士事務所に住み込んで開発をしています。この記事を書いている時点で、ちょうど1ヶ月ほどです。広島県に拠点があり、顧問先は2,000件を超える、けっこう大きな税理士法人さんです。エンジニア二人で乗り込みました。

「住み込み」といっても、寝る場所だけは事務所から徒歩5分のホテルでした。朝から晩まで事務所の机で開発して、お昼もご一緒して、土曜には野球にまで誘ってもらったので、気分としては完全に住み込んでいました。

先にZeimeeの説明を軽くしておくと、会計事務所って、顧問先から届くレシートや通帳や請求書を見て仕訳を入力する「記帳」という仕事を、大量に抱えているんですね。Zeimeeは、この記帳をAIがかわりにやるサービスです。AIがレシートや請求書などの証憑を読んで仕訳の候補を作って、職員さんは画面で確認して、承認したものが会計ソフトに入る。freeeやミロクみたいな会計ソフトを置き換えるのではなくて、その手前で動くものです。

ちなみにこういう「顧客の現場に入り込んで、製品をその現場で動く形に仕上げる」働き方、最近はFDE（Forward Deployed Engineer）と呼ばれているらしいです。AI企業がこぞって採用しはじめている、いまいちばんホットな職種の一つなんだとか。名前は立派なんですが、やっていたことは、隣の職員さんに「これ、どうやってます？」と聞いてはその場で作る、の繰り返しでした。

今日は、この1ヶ月で分かったことを書いてみます！

先に言っておくと、着地は2つです。「記帳まわりでAIに渡せない作業は、2つしかなかった」ということと、「AIって、使い方のうまさよりも、引き出した正解をどこに置くかのほうが大事っぽい」ということです。

この事務所は、もうAIを使っていた

打ち合わせの段階で分かっていたことですが、この事務所は、とっくにAIを使っていました。

職員さんは、手書きの日計表（毎日の売上や経費を書いた帳簿ですね）をGeminiに読ませ、その結果を会計ソフトへの入力に使っていました。誰かに教わったのではなく、自分で試しながらたどり着いた使い方だそうです。この話を聞いた時点で、「あ、これはAIを教えに行く話じゃないな」と思いました。

じゃあ何も困っていないのかというと、そうでもなくて。「普段AIを使っていて、物足りないところってありますか？」と聞いたら、こう返ってきたんです。

最初、この「簡易版」が何のことか分からなかったんですが、会計ソフトの取込機能の名前でした。整理すると、状況はこうです。

AIは日計表を読んで、日付や金額や勘定科目の見当をつけるところまでは、ちゃんとやってくれる。ただ、その結果を会計ソフトに一括で入れる手段がなくて、画面を見ながら一行ずつ、エンターを押して確定させていた。100行あったら、100回です。

この話を聞いて、問題はAIの読み取りではなく、その結果を会計ソフトへ渡すところにあると分かりました。AIが読み取った内容を、人が一行ずつ移していたわけです。

「いや、プロンプトで『会計ソフトの形式で出して』って頼めば済むのでは？」と思いますよね。僕も一瞬そう思って、ちょっと考えて、無理だと気づきました。

理由は2つあります。まず、会計ソフトに一括で入るファイルを作るには、その事務所がその顧問先のために設定した専用ルールを全部知っている必要があるんです。勘定科目の番号の振り方ひとつ、顧問先ごとに違います。チャットに毎回それを全部貼るのか、という話になる。

もう一つは数字の問題で、AIが出した100行のうち1行だけ金額が違っていた場合、一括で取り込んでしまうと、その1行を探す作業のほうが、100回エンターを押すより重くなります。間違いが混ざる前提に立つなら、一行ずつ確認しながら入れるほうが、実はぜんぜんまともな運用でして、職員さんのやり方は合理的だったんです。

さらにやっかいなのは、この工夫が職員さん個人のGeminiの画面にしかないことです。

同じ日計表を別の担当者が受け取ったら、ゼロから自分の聞き方で始めることになります。結果は聞き方次第で変わるし、この職員さんが休んだら、この流れごと止まる。個人がプロンプトでAIを使う運用って、うまくなればなるほど、その人にしかできない仕事が増えていきます。AIが属人化するわけです。

しかも顧問先は2,000件超えで、証憑の形は顧問先ごとにバラバラです。手書きの帳簿で来るところもあれば、レシートの束のところも、銀行明細のPDFのところもある。この全部に、職員さんが各々、手元のChatGPTやClaudeやGeminiで聞き方を工夫して立ち向かうのは、どれだけ現場が優秀でも構造的に無理があります。

つまり、この事務所に足りないのは、AIでもAIを使う能力でもなくて、「AIの出力が業務ソフトまでまっすぐ流れる道」と「個人の工夫が個人の外に溜まっていく場所」の両方でした。どちらも、業務の側に誰かが作り込むしかないものです。

僕らの1ヶ月は、ずっとこれを作っていました。

住み込むと、開発の速度がおかしくなる

その1ヶ月がどうだったかというと、まず驚いたのは開発の回転の速さです。

初日から飛ばしすぎなくらいで、朝10時に事務所に着いて、お昼前には「証憑データと、相続の帳票と、現金出納帳をください」とまとめてお願いして、午後は隣でヒアリングして、夜には新しい機能をリリースしていました。1日がとにかく長い。体感、リモートの3日分くらい進みます。

これは、単純に距離の問題です。

例えば2日目に、こんなことがありました。銀行の取引履歴PDFを読んでExcelの一覧表にするツールを相続担当の方に渡していたんですが、午後に「この銀行が読めませんでした」と、未対応の銀行のPDFが5つ、ばばばっと送られてきたんですね。

で、49分後には「対応しました！」と返せています。なんなら、頼まれていなかったチェック機能まで付けました。

同じ建物の中にいると、ファイルが届いた瞬間に「あ、来た」と分かって、その場で開いて、直して、返せる。これがメールの往復だったら、どんなに頑張っても2日かかると思います。1回ごとの差は数時間でも、1ヶ月積み重なると、進み方にはかなり差が出ます。

それって受託開発では？という話

そろそろ「それって受託開発では？」と思った人もいそうです。ここで、その話をします。

分かります。SaaSの会社が顧客1社に1ヶ月張り付くのって、教科書的にはアウトです。SaaSは、一度作ったソフトウェアを何社にも配ることで成立するビジネスです。創業初期に調達したばかりのお金を、機能開発ではなく移動と滞在に使っているわけで、、我ながらけっこう無茶をしていると思います。

それでもこうしたのは、パッケージを配るだけだと、使われないからです。

Zeimeeの中核部分は、パッケージとして作り込んであります。証憑を取り込んで、AIが仕訳候補を出して、担当者が承認して、会計ソフトに流れる。ここはどの事務所でも同じ形で動きます。

問題は、その手前なんですよ。

別の会計事務所と導入の話をしていたとき、「何に困っていますか」と聞いたら、こう言われたことがあります。

会計入力そのものじゃなくて、その前段です。顧問先から資料を集めて、同じ領収書が二重に来ていないか見て、足りないものを催促する。しかも、この前段のやり方が、連絡手段から締切、「何を足りない資料と見なすか」の基準まで、事務所ごと、なんなら顧問先ごとに違ったりします。リース料は毎月見なくていいけどスポットの取引は目で見たい、みたいな暗黙のルールが、そこら中にあります。

ここが手作業のままだと、真ん中だけAIにしても、全体はほとんど速くなりません。月次業務は一本の流れで、いちばん遅い工程が全体の速度を決めてしまいます。『ザ・ゴール』で有名な制約理論ってやつと同じ構造ですね。

そこで、真ん中だけじゃなくて、業務の流れ全体に合わせてAIを組み込む必要があります。流れは事務所ごとに違うので、組み込みも事務所ごとにやる。つまり、Zeimeeを事務所ごとに作り直す、ということになります。

そうと決めると、勝負は要件定義です。業務フローを理解するって、結局、工程を一つずつ並べて「これはAIに渡せるか、人に残すか」と線を引いていくことで、線を引くには、その工程で何をしているかが言葉になっている必要があります。コードはもうAIが書いてくれるので、実装では詰まらない。詰まるのは要件定義だけです。

その要件定義の材料は、事務所の人の頭の中にしかありません。リモートの30分ミーティングで出てくるのは、すでに言語化されている困りごとだけです。

だから住み込みました。遠回りに見えて、たぶんこれが最短でした。

ちなみにお金の面は、滞在費はこちら持ちで、先方の初期費用は抑えて、かわりに汎用化できる改善はZeimee本体に入れさせてもらう、という形です。きれいに言えば共同開発、身も蓋もなく言うと、開発費を被って現場の暗黙知を持ち帰る取引ですね。

現場でやっていた4つのこと

1ヶ月やっているうちに、現場での動き方がだんだん固まってきました。あとから数えたら4つあったので、並べてみます。

1. 区切りのいいところまで作らない

開発って普通、「ある程度ちゃんと動くようになったら見せる」じゃないですか。あれをやめました。画面が1枚出たら見せる。ボタンが1個動いたら見せる。相手は同じ建物にいるので、見せるコストがほぼゼロです。

2. エラーが出る状態で渡す

初日の夜、資料せん（税務署に出す取引先一覧の資料です）を集計するツールについて送ったチャットが残っているんですが、こんな感じです。

エラーが出るかも、と自分で言いながら渡しています。もちろん本番データにいきなり当てたわけではなくて、試せるデータを用意してもらって、隣で一緒に動かしながらの話です。

なんでこうするかというと、動作確認よりも「認識のズレを早く見つけること」のほうが大事だからです。実際、翌日にでかいズレが見つかりました。現金出納帳のチェックツールについて「この2つのファイルのずれを見る認識で合ってますか？」と確認したら、こう返ってきたんです。

MFというのは、マネーフォワード クラウド会計のことです。僕が作ろうとしていたものは、役割から違っていました。完成させてから見せていたら、これが分かるのは1週間後でした。

3. 仕様書を最初に書かない

上の工程の話には、事前に僕がどれだけ考えても出てこない情報があります。実物のExcelとPDFを挟んで、隣で聞いて初めて出てくる。だから仕様書は書きませんでした。書いても捨てることになるので。

4. 全部いっぺんに聞いて、全部同時に作る

「まずはこの機能から」と一つずつ進めるのもやめました。困りごとを最初にまとめて聞いて、複数のツールを並列で作って、できたものから見せていく。AIで開発すると、作るコストも捨てるコストも安いので、外したら捨てればいい。聞き方の順番が変わるくらい、開発の前提が変わったなと思います。

1ヶ月で何を作ったか

この進め方で1ヶ月やって、何ができたか。成果物は、大きく2種類です。

一つはZeimee本体の作り替えで、こっちが本業です。証憑がどう届いて、誰がどう処理しているのかを聞いて、言葉にして、どこをAIに任せてどこを人間に残すのかを設計して、実装する。さっきの「線を引く」を、証憑処理の端から端までやりました。

もう一つは、聞いているうちに出てきた困りごとを、その場でツールにしたものです。並べてみますね。

• 日計表変換 — 手書きの日計表を撮影すると、会計ソフトにそのまま取り込める形式に。一行ずつエンターを押す作業が要らなくなった

• 現金出納帳チェック — 顧問先が入力した仕訳帳と、提出されたレシート画像を突合して、月次で指摘すべき点を洗い出す

• 相続税 預金履歴表 — 金融機関ごとの取引履歴PDFを読んで、全口座を日付で揃えた一覧表をExcelで出す

• JDL出納帳取込CSV — Excel間でコピーと貼り付けを繰り返していた5工程を、1画面に置き換えた

• TKC → マネーフォワード変換 — TKCの仕訳帳を、マネーフォワードで読める形式に変換

• 資料せん集計 — 税務署に出す資料に載せる取引先を、仕訳帳から自動で抽出

ひとつ補足しておくと、さっきの「1行だけ間違っていたら、探すほうが大変」という問題は、ツールの側で潰してあります。AIにやらせるのは画像の読み取りだけで、金額の検算は、AIではない普通のプログラムでやる。で、検算が通ったときだけ、取り込める形式のファイルになる、という作りです。間違い探しの場所を、会計ソフトの中から取り込みの手前に移した、ということですね。

余談ですが、最後の資料せん集計だけは、僕が作ったものではありません。職員さんの自作ツールです。21ページの操作マニュアル付きで。普通にすごくないですか。僕がやったのは、これを事務所のツール置き場に載せて、住所が自動で入るようにした、それだけです。職員さんが、すでに答えを作っていました。

「2階へ降りてきてもらってもいいですか？」

少し時間を戻して、住み込み2週目ごろの話です。このあたりから、事務所との距離感が変わってきました。

チャットグループの人数が、勝手に増えていきました。最初は日計表の担当の方だけだったのが、相続の方、月次チェックの方、別の事務所の方、併設の行政書士法人の方と増えていって、「うちの業務もできますか？」という相談が来るようになりました。中には、業務の工程を①から⑦まで自分で書き出して送ってくださる方もいました。頼んでもいないのに、要件定義された依頼が届くんです。

いちばん嬉しかった連絡が、これです。

「2階へ降りてきて」って、完全に社内の人への言い方じゃないですか。こんな連絡は、リモートのベンダーにはなかなか来ません。ここまで来ると、ヒアリングとか要件定義とかは、もう日常会話と区別がつきません。

ただ、いい話っぽく書いていますが、これは僕に都合のいい面だけの話で。質問に答え続けてくれていたのは職員さんたちで、それは全部、本来の業務に上乗せされた時間です。1ヶ月でこれだけ作れたのは、僕らが速かったというより、現場が時間を差し出してくれたからでした。

AIに渡せない作業は、2つだけでした

1ヶ月かけて工程に線を引き続けた結果なんですが、記帳まわりでAIに渡せなかった作業は、2つだけでした。

1つ目は、紙の証憑の電子化です。物理はどうにもならないので、誰かがスキャンするしかない。ただ、これは「人がスキャンします」の一行では済まなくて、紙が郵送で届くのか持参されるのか、誰がスキャンするのか、原本をどう保管するのか、が事務所ごとに違います。ここが分からないと、電子化した後の工程を設計できません。

2つ目は、人間による最終チェックです。例えばある銀行の取引履歴PDFでは、AIの読み取りエラーが最初33件あって、作り込んで1件までは減らせたんですが、0件にはどうしてもなりませんでした。最後の1件は人が見るしかないですし、税務の責任は人が負う以上、ここは残るべきところだとも思っています。

ここで「いや、できあがったCSVを会計ソフトに取り込む操作も人間では？」と気づいた人もいると思います。おっしゃる通りで、そこは人がやっています。ただ、それは判断の要らない数秒の操作で、仕組みが変われば消えるものですから、ここでは数えていません。紙のスキャンと最終チェックは、そうはいきません。どれだけ仕組みが良くなっても、物理は残るし、責任を持つ人の目も残る。「渡せない」というのは、そういう意味です。

ちなみに、前のほうで出てきた「資料の回収・重複チェック・網羅性確認・追加督促」はどっちなのかというと、あれは渡せる側です。「何を足りない資料と見なすか」の基準さえ言葉にできれば、チェックも催促の連絡も、AIに渡せます。渡せないのは、紙が物理として存在することのほうで、これは1つ目に含まれています。

逆に言うと、この2つ以外は、全部AIに渡せます。行く前は仮説だったんですが、1ヶ月で確信に変わりました。

ただし条件があって、「やっていることを、全部聞き出せていれば」です。

この1ヶ月でいちばん大変だったのが、まさにこの「全部聞き出す」でした。

例を一つ。ある信用金庫の取引履歴PDFに、こんな行が出てきたことがあります。

0円利率 8. 1000%最終取引日R 51010当貸契約日H28 628当貸終了日R 7 630当貸極度額 2,500千円

金額の欄に、数字じゃないものがぎっしり詰まっています。AIには、これをどうすればいいか判断できません。無視していいのか、大事な行なのか、情報がないので。

隣の職員さんに聞いたら、答えは一言でした。

この一言は、AIだけでは出てきません。その帳票のその行をどう扱うかの正解は、業務をやっている人の頭の中にしかなくて、しかも本人は、聞かれるまでそれが「知識」だとも思っていない。「人は自分が語れる以上のことを知っている」という、暗黙知って呼ばれてるやつを、毎日目の前で見ている感じでした。

なので、この仕事の本体はコードを書くことではなくて、隣に座って、手元を見て、「それ、なんで一回Excelに貼るんですか？」と聞くことなんですよね。

こういう暗黙知は、オンラインミーティングだと本当に拾えません。会議って、聞くことを決めてから聞く場じゃないですか。こっちが質問を思いつけないことは、議題に上がりません。隣で作業していると、これが逆になります。質問を用意しなくても、目の前で仕事が流れているので、「あれ、いまなんでそうしたんですか？」がいくらでも湧いてくる。さっきの信用金庫の行も、画面共有の30分ミーティングだったら、たぶん出会えなかったと思います。

引き出した正解を、どこに置くか

ここまでは、現場に入ったことのある人なら「わかる」と言ってくれそうな話だと思います。1ヶ月やって面白かったのは、その先でした。

正解を引き出すこと自体は、骨が折れますが、方法は分かっています。隣で聞けばいい。難しいのは、引き出した正解を「どこに置くか」なんですよ。

さっきの「無視していただいて構いません」を、僕がプロンプトに書き足して終わりにすると、その知識は僕のチャット履歴の中に消えます。次に同じ帳票を見た別の担当者は、またゼロから聞き直しになる。あの日計表のGeminiと、まったく同じ構図です。

そこで、引き出した正解は、ツールとZeimeeの仕様として置くようにしました。Zeimeeの中では、担当者が仕訳候補を直すと、その修正が顧問先ごとの辞書として残って、翌月から同じ明細は辞書で判定されます。担当者の仕事は「どう聞くか」ではなくて、「承認するか、直すか」になる。

例えるなら、個人のAI活用って「置き家具」みたいなものです。その人の持ち物で、退職と一緒に出ていってしまう。業務に組み込まれたAIは「造作家具」で、建物に作り付けだから、人が入れ替わっても残ります。

で、これ、たぶん税理士事務所だけの話ではなくて。全員にAIのライセンスを配って、発表会でうまい使い方を共有して、活用率を数える。いまの「全社AI活用」って、だいたいこんな形じゃないですか。これだと、置き家具が増えていきます。個人のAI活用がうまい組織と、業務にAIが組み込まれた組織は、外からは区別がつきません。活用率のグラフは、どちらも右肩上がりです。違いが表に出るのは、うまい人が異動したり辞めたりしたときかもしれません。

宣伝っぽくなってきたので、限界も書いておきます。この「辞書に溜める」方式が効くのは、毎月繰り返される判断だけです。年に一度の例外は、溜めても次に使うのが1年後で、そのころには状況が変わっている。で、会計事務所の実務でしんどいのは、往々にしてそっちだったりします（これは「渡せない3つ目」というより、渡すための仕込みが、繰り返しの少ない作業ほど割に合わない、というコスパの話です）。それでも、繰り返しの部分を機械に渡せれば、人が例外に使える時間は増えるわけで、1ヶ月で僕が納得できたのは、そこまででした。

現場に入る意味って、正解を引き出すことよりも、引き出した正解の置き場所を作って帰ることなんじゃないかなーと、いまは思っています。

配って終わりにできない、という話

ここからは少しだけ、業界の構造の話をさせてください。

会計ソフトそのものは、パッケージとして配れます。実際、いまの会計ソフトはそうやって広まってきました。配って終わりにできないのは、その手前の業務フローに踏み込むタイプのソフト、つまりZeimeeみたいなやつです。

なんでかというと、会計事務所って、事務所ごとの業務フローの差が、他の業界に比べてめちゃくちゃ大きいんです。で、その差には全部理由があります。

例えばこの事務所では、会計ソフトを複数併用しています。顧問先がそれぞれ違うソフトを使っていて、事務所がそれに合わせているからです。ツールの一覧にJDLやらTKCやらマネーフォワードやらが並んでいたのは、そういうことですね。資料の届き方も、催促の仕方も、締切の切り方も、同じです。全部、顧問先に合わせている。これは非効率というより、顧客対応そのものです。

だから、「まず業務を標準化してからソフトを入れましょう」という正論は、この業界だと「顧問先の都合を切り捨ててください」という意味になってしまって、機能しません。業務の側を標準化できないなら、ソフトの側が業務に入っていくしかない、と思っています。

考えてみると、プロンプトで個人がAIを使うのは「人がAIに合わせる」やり方で、パッケージを配って標準化を求めるのは「業務をソフトに合わせさせる」やり方で、方向は同じです。どっちも、本当は動かせない「業務」の側を動かそうとしている。行き着く先も同じで、「AI入れたけど、思ったほど楽になってないね」という感想が残ります。

残っている方向は一つで、AIとソフトの側を、業務に合わせて作り替える。業務は現場ごとに違うから、作り替えも現場ごとにやる。外から見積もってやれば受託開発と呼ばれて、中に住んでパッケージに還流させながらやればFDEと呼ばれる。呼び方はどっちでもよくて、僕らの1ヶ月は、要するにこれでした。で、AIで作る速度が上がったおかげで、これが現実的なコストでできる時代になったんだと思います。

これって真似できるの？という話

とはいえ、このやり方が万能かというと、ぜんぜんそんなことはなくて。まだ答えが出ていない部分も書いておきますね。

まず、真似するための条件がけっこう厳しいです。エンジニア二人を1ヶ月空けられる会社は、そんなに多くないと思います。

それと、このやり方を続けるには、現場で得た知識をZeimee本体に持ち帰り、次の導入でも使える形にする必要があります。今回作ったもののうち、どこまでをZeimee本体に入れて、どこからを事務所ごとの作り込みとして残すのか。現場に入ることは続けながら、毎回ゼロから作らなくていい部分を増やしていく。その切り分けは、まだ試している途中です。

滞在を始めて1ヶ月ほどたったころ、Zeimeeで処理したある顧問先の請求書の仕訳を、職員さんが確認してくれて、こんな報告をもらいました。

複合仕訳というのは、1枚の請求書やレシートの中身を2行以上に分けて記録する仕訳のことです。軽油代は、税金のぶんだけ区分が分かれるので、これが要ります。地味ですよね。でも、毎月出てくる。で、ソフトが業務で使われるかどうかは、結局こういう地味なところが合っているかで決まります。

1ヶ月、一緒に働いて、お昼を食べて、その日に作ったものをその日に触ってもらう。単純に、めちゃくちゃ楽しかったです。これからも現場で作りながら、また分かったことがあれば書いてみますね。

書いた人

佐次本脩真（X: @shosusiaruyo）。株式会社Zeimeeの代表。税理士・会計事務所向けのAI記帳SaaS「Zeimee」を作っています。この記事のような住み込み導入に興味のある事務所の方は、Xまでご連絡ください。

関連リンク

• プレスリリース（PR TIMES）

• 日本経済新聞での紹介記事