「おい！全然数値違うやんけ！」

30ページほどの意見書を、ある複雑なスキームの分析でAIに作成させていたときのこと。Claudeに読み込ませたはずの数値が、なぜか別の金額に化けていた。「全然数値違うやんけ！」と画面の前で思わず声が出た。

AIに業務文書を作らせたことのある方なら、似た経験があるのではないだろうか。

最初の数回のやりとりは精度が高い。ところが文書（コンテキスト）が長くなるにつれ、徐々に数値や記述がおかしくなっていく。指示し直してもどこか直りきらない。最後には、一から書き直した方が早いのではと思えてくる。

これは個別のミスではなく、構造的な問題だと考えている。本記事では、なぜこれが起きるのか、そしてどう防ぐかを書いてみたい。結論から言えば、答えはエンジニアリングの世界にも、そして我々会計の世界にも、昔から同じ形で存在していた。

二種類の失敗パターン

失敗パターン①：数値の化け

最初に出会った典型的な失敗は、読み込ませたはずの数値と実際にAIが扱っている数値が食い違うというもの。

元資料には「評価額：◯◯円」と書いていたはずなのに、よくチェックしてみると「評価額：××円」に化けている。本人（AI）に指摘すると素直に認めて修正するが、別の箇所がまた化けている。完全にモグラ叩きである。

失敗パターン②：勝手な効率化

もう一つ印象的だった失敗は、AIが自分で法則性を見出して計算してしまうケース。

複数の繰り返し作業をやらせていたら、9件目までは指示通り元資料から数値を拾ってきていたのに、10件目で「これは前のデータからこう計算できますね」と勝手に推論で数値を出していた。本来は元資料の別ページから拾わなければいけない数値だったので、当然ズレる。

この失敗、慣れてきた中級者が陥るミスとそっくりではないか。「これは前期と同じパターンだろう」と決め打ちして、元資料を当たらずに処理してしまう。慣れて失敗する、というやつだ。AIも同じことをやる。

なぜ起きるのか――自己参照ループ

原因を構造的に整理してみたい。

AIが長い文書を書き進めるとき、後半の出力は自分が前半で書いた内容を参照しながら生成されている。ところが会話が長くなると、AIの「記憶」（コンテキストウィンドウと呼ばれる作業領域）は圧縮対象になり、前半の正確な出力が徐々に曖昧化していく。

すると次のことが起きる。

1. 圧縮で曖昧になった過去の出力を、再構成しながら次を書く
2. 再構成された（やや不正確な）値を前提に、さらに次を書く
3. それをまた参照して次を書く

誤差が累積する自己参照ループである。しかも厄介なのは、AIは「自分が前にこう書いたはずだ」という記憶に自信を持っていて、元資料に立ち返ろうとしないこと。

ある時点でバグが発生すると、それが「前提」として固定化されてしまい、後続の出力すべてに波及する。気付いたときには、もはや部分修正では直しきれない状態になっている。

会計で言えば、間違った仕訳を前提に次の仕訳を切り続けている状態だ。試算表が合わなくなった時点で全部やり直すしかなくなる、あの感じである。

こういう、コンテキストが長くなってぐちゃぐちゃになっていくことを一般に、コンテキスト汚染という。

「これ、バックエンドはどうしてるん？」

実はこの問題への答えは、私が気付くずっと前に、別の形で示されていた。

今年の二月、現役エンジニアの弟とClaudeの活用について話していたときのこと。当時取り組んでいた業務をひと通り説明したら、彼は最初にこう聞いてきた。

「これ、バックエンドはどうしてるん？」

正直、当時の私はその質問の意味をよく理解していなかった。「フロントエンド」「バックエンド」というのはエンジニアの業界用語で、ユーザーが直接目にする部分（フロントエンド）と、その裏でデータを処理・保存する部分（バックエンド）を分ける考え方だ。Webサービスでもアプリでも、何かを作るときの基本的な構造分離である。

弟に言われるがままに、私はAIにバックエンド――つまりデータを保存する置き場――を裏で構築する運用を組み立てた。ただその時はその効果の真髄がよく分からないまま、必要な作業の一つとしてやっていた。

バックエンドとしてのExcel同時生成

冒頭の私に戻るが、コンテキスト汚染に悩まされていた私は、ずっとこの問題に対する対策を考えていた。

「CLAUDE.md」を作ると良いよ

とか、なんとなく正しそうなアイデアも大いに参考にした。

だが、いちいち全部の業務でそういったものを作るのは実に面倒だった。

偶然ある時、コンテキストが長くなってもかなり精度が保たれていたケースがあった。

 

その時、（偶然）やっていた方法はこうだ。

・報告書を、Wordで作成する。

・計算資料としてインプットデータからの計算過程が記されたExcelを同時に作成する

これだけだ。

こうすることで、どれだけコンテキストが圧縮されても、claudeが毎回作業中にexcelを参照しに行くので、出力が全然ぶれない。

答えは、元データをバックエンドに組み込んで、フロントエンドはバックエンドを参照して整形する役割に徹することだった。

振り返れば、会計の構造そのものだった

そして振り返ってみると、この構造、我々の業界でも昔からやっていることだった。

会計の業務は、必ず以下の流れを取る。

証憑 → 仕訳 → 試算表 → 財務諸表

クライアントから受け取った領収書や契約書（証憑）を、仕訳という形で原帳簿に転記し、試算表で集計の整合を確認し、最終的に財務諸表という”成果物”を作る。財務諸表上のすべての数値は、仕訳まで降りられ、仕訳は必ず証憑まで遡れる。これがあるから決算書は信頼できる。

これをAI業務に当てはめると、こうなる。

層	会計	AI業務
原データ	証憑（契約書・領収書等）	元資料（PDF・依頼内容）
原帳簿	仕訳帳・総勘定元帳	Excel（計算用資料）
成果物	財務諸表	Word（報告書）

エンジニアリングの世界では「フロントエンド／バックエンド分離」という言葉で発達した知恵が、会計の世界では何百年も前から「複式簿記」という形で存在していた。表現が違うだけで、根っこは同じ――情報の信頼性を担保するためには、最終成果物だけを作るのではなく、その背後に確定された中間記録のバックエンドの層を持たねばならない、という普遍的な原理だ。

異なる業界で独立に発達した同型の知恵が、同じ問題を解いている。これは知的にも面白い発見だった。

そして、AI時代に入って改めて分かったのは、この複式簿記的な発想は会計だけのものではなく、人間の認知の限界を補うための普遍的な技術だったということだ。

AIも結局のところ「気の利く新人」のようなもので、長時間の作業を任せれば曖昧な記憶のまま暴走する。だから人間と同じく、確定された中間記録に逐次戻させる仕組みが必要になる。

AIを使うとはレビューを構造化することだ

最後に、士業の同業者へのメッセージとして書いておきたい。

AIを業務で使い始めると、ある段階で「楽になる」という幻想が崩れる瞬間がある。出力の精度が信頼できないので、結局すべてを人間がレビューする必要が出てくる。それなら最初から自分で書いた方が早い――そう挫折する声をよく聞く。

ここで考え方を変える必要がある。

AIを使うことは、レビュー責任が減ることではなく、レビューの構造を作り直すことだ。

会計監査でも、財務諸表だけ見ていては監査にならない。仕訳まで降り、証憑まで遡る。それと同じで、AI成果物（Word）だけ見てレビューしてもミスは見つからない。Excel（原帳簿に相当）まで降り、元資料（証憑に相当）まで遡る。これがAI時代の品質管理だと思う。

逆に言えば、この三層構造を最初から設計してAIに業務をやらせれば、レビューは劇的にやりやすくなるし、そうでなければ、フロントエンドの全てがブラックボックス化してレビュー不能となる。

この、いったん作れるが、どうやってできているかが不明で、作成過程がブラックボックス化して生産性が爆下がりする現象を、エンジニアの用語で「理解負債」という。

理解負債についてわかりやすい動画があるので、こちらを見ていただければと思う。

会計士・税理士は、この種の構造化された業務設計が本職の人間であるという点で、実はエンジニアと近い部分があるのだと思う。

結び

AIは優秀だが、ときどき、人間の新人（あるいはベテラン）のようなミスをするところがある。長時間の作業を任せれば、勝手に効率化したり、自分の過去の仕事を曖昧に思い出したりする。

その性質を理解した上で、適切な業務設計（バックエンドの並走）をしてやれば、十分実務に耐える成果物が出てくる。私自身、複雑な税務意見書を含めて、この方法でかなりの業務をAIに任せられるようになったという自信がある。

それにしても、エンジニアの弟が最初に投げかけた「これ、バックエンドはどうしてるん？」という一言が、こんなにも本質的な問いだったとは。異分野の専門家との会話には、自分の業界では見えなくなっている当たり前を、改めて言語化させる力がある。

「AIで業務をやらせたが、いまいち精度が出ない」と感じている士業の方は、ぜひこの三層構造を試してみてほしい。

 

公認会計士・税理士　富村亮超