驚異の精度！GLM 5.2がプロの会計士レベルに到達？

GLM 5.2の精度が、ついに人間の会計士と遜色ないレベルまで向上したようです。業務効率化に革命が起きる予感？

「人間のブックキーパー（経理担当者）とほぼ同じ正確さ」って、メトリックシステムを使わないためなら何でもするんだな。ていうか、真面目な話、この指標は何？LLMが人間の経理担当者と同じくらい正確かどうかなんて、何で気にしなきゃいけないの？人間だって完璧に物事を記憶できるわけじゃないだろうに。

興味深い記事だね。ずっと昔に経理をやっていた身としては、LLMベースのシステムで自動化される余地があるっていうのはそんなに驚きじゃないかな。彼らが遭遇したエラーの種類も、関連する税法についてのスキル向上やナレッジベースへのアクセス改善で対処できそうだし。彼らのソフトウェアで重要なのは、もしHMRC（英歳入関税庁）から指摘があったときに彼らが結果に責任を持ってくれるのかってことだね。それがなければ、ユーザーはリスクを背負い込むことになる（HMRCとのやり取りは本当に面倒だからね）。逆に責任を持ってくれるなら、多くの中小企業にとって素晴らしい節約になるだろうけど、会計事務所の従業員にとっては厳しい話になるだろうね。

全然驚かないな。この手の問題は制約を厳しくしてコンテキストを極限まで絞れば、かなり信頼性が高くて再現性のある結果を出せるよ。自分も「vibe-coded」なDeepSeekでの経理でかなり良い結果を出せてる。https://github.com/traverseda/beansync メールや他のソースを解析して数字を抽出し、トランザクションを関連付けてウェブ検索もして質問も投げられる。メモを保存する機能（正規表現ベースのすごくシンプルなやつ）もあるよ。難しいのは良質なデータを取得することだね。Lexus Nexusのような会社なら銀行口座やクレジットカードのAPIアクセスを取得できるだろうけど、個人じゃ無理だし。結局、ほとんどのプロバイダーにとってはメールが一番確実だった。今のところ2段階認証を回避できてるけど、必要になったら面倒だろうな。

自分なら怖すぎてこんなの試せないよ。綺麗なウェブサイトと動画、ブログ記事があるだけじゃないか。創業者についての情報もLinkedInにも何も見当たらないし、昨年設立されたVineyard Finance LTDっていう会社があるだけだし。みんなLLMに渡すデータに対しては無頓着だけど、自分はここで一線を引くね。今の少額の顧問料を払ってプロに頼むほうが安心だよ。

自分はパソコン上のフォルダでbeancountを使って管理してるよ。MercuryのCLIアクセス権を使ってビジネス用の銀行口座を読み取り専用トークンでつなぎ、メールもIMAPで同期させてる。Claude CodeとOpusを使えばすべてシームレスにつながるから、会計データは常に最新。年末にはその情報を使ってビジネスの確定申告をやって、その後オーナーとしての自分の分も申告してる。2025年は少し複雑な申告が必要で、事業形態の変更や、ビジネス宛ではなく自分宛に誤送金された1099関連の処理なんかもあったけど、Claude Codeのアドバイスを受けてすべて税務ソフトで完結させた。結果は上々。案の定、税務調査（というより詳細な確認）が入ったけど、唯一のミスは妻の非課税の障害手当（カリフォルニア州の産休手当の仕組みなんだけど、実際は障害者じゃない）の割り当てについてだけだった。IRS（米内国歳入庁）から指摘されて、その分を納付したら（本当は雇用主から請求すべきものだったんだけど）、すべて丸く収まったよ。正直、金額が少額だったから深く追及しなかったし、まだ妻の雇用主への返還請求もしてない。正直なところ、会計士と税理士を雇って彼らの言う通りにしていれば全部避けられたはずだけど、結局IRSは説明すれば理屈が通じる相手だし、現代的なエージェントを使えばプロセスはかなりシンプルだよ。最終的に、自分はソフトウェアと対話しながら進める方が好みだね。たいていの会計士や弁護士は、資料を一度に全部渡せと言うタイプで小出しに対応してくれないから。今回は少しずつ申告書を作れたし、疑問点を質問してその場でクリアにできたのが良かった。今年も同じやり方でやるつもり（もっと申告内容はシンプルになるだろうけど）。

これは正確性が大事なのはもちろんだが、最終的に誰が刑務所に行くことになるのかっていう問題の典型例だよね。勝手な予想だけど、LLMが刑務所に行くことはないだろう。誠実にやっていて会計士が何かヤバいことや悪いことをしたなら、責任は限定的だ。追徴課税はあっても刑務所行きにはならないだろうね。でも、もしLLMが独断で脱税を始めたら、未知の領域に突入だよ。結局、銃を撃ったのは道具だとしても、銃を持っていたのは自分だから。世の中の仕事の多くはそういうもの。サービスを買っているというより、「心配しなくていい権利」を買っているんだよ。

この議論でここを見落としちゃいけないよ。「人間が実行した仕事は、ベンチマークでモデルに要求されたものより広範囲だった。人間は関連する請求書を見つける（メールボックスを探したり、プロバイダーに請求したりする）必要があり、銀行取引や請求書・領収書単体からは推論できない状況についても推論する必要があった。ベンチマークでは、こうした状況はモデルに対して『ユーザーメモ』として提示されている」。これは、ホワイトカラー向けのAI能力について、企業が何度も直面する「細かい注釈」の正体だよ。まともなオフィスワークなら、判断力や経験を要する、ドキュメント化されていない（あるいはドキュメント化不可能な）問題が山ほどあるから。それに、最先端のLLMに請求書を取得させるなんて神経質になるね。「Claudeが5月6日のサプライヤーの請求書を見つけたとログに残したけど、それが勝手に捏造したものでない保証はないし、さらにエージェントが推論の中で捏造された請求書に基づいて反復処理をしてエラーを増幅させる可能性もある。最初の30回は問題なかったとしてもね！」

関係ないけど、「bookkeeper」の真ん中にスペースを入れることで、3文字連続で重なる文字が2つ並ぶっていうあの独特な綴りを台無しにするのは、なんとなく不公平な気がする。

「モデルが作成したVAT申告書は本質的に正しかった。申告書の中で最も重要な数字である、税務当局から還付されるVATの額は、人間が作成したものとわずか7ペンスの差だった」……ヨーロッパの税制がどうなってるかは知らないけど、アメリカのIRSに対して「本質的に」正しいなんて言葉は通用しないぞ。しかもこの段落の後に、LLMが犯した他のミスについて説明してるよね？ひえっ。

これまで見てきたエラーを考えると、LLMの方が正確でも驚かないな。いつも帳簿には目を通してるんだけど、資産シートに1万5000ポンドの建物が突然現れたときは困惑したよ。結局、「ワークショップ（研修会）」が、実際はそうじゃないのに購入した「建物」として分類されてたんだ。これが、チェック機能が重層的で複数の目を通すことの重要性だよね。もし自分が見逃していたとしても、年末には会計士が疑問に思うはずだけど、LLMのミスでも同じことが言えるかもしれないしね。