「三谷さん」を超えて

前回のエントリでの反省も踏まえて、HieronymusにAI機能を付加しています。

もうちょっとで公開できそうなので、どんなことをしているか書いておきます。

やったこと

「経費精算」という機能の追加と「銀行元帳」周辺の強化をしました。

弊社のような零細企業ですと、ほとんどの会計処理は「経費の精算」と見做すことができます。

もうちょっと正確に言えば、だいたいほとんどの伝票が「計上損益」に対することで、その中身は「売上高」と「売上原価」に属するものだということです。「経費の精算」は「売上原価」の話ですね。

幸いなことに、売上原価に相当する支出は、会計素人であってもちょっと話を聞けば理解できます。そして、その支出(つまり「経費」)についてのことは「現場の人」が一番わかっています。

そこで、「経費」のうち比較的わかりやすい部分については、「現場の人」でも入力できるように、「経費精算」の画面を用意することにしました。つまり、支出をした人が入力できる、伝票よりもわかりやすい画面を用意しました。

経費精算の時にレシートや領収書をアップロードすると、証憑として扱われるようになります。

そしてもう一つのお金の出入りを見ているのが「通帳」です。

これは元々銀行関係だけ扱っていて「銀行元帳」としていましたが、弊社でも法人クレジットカードも使うようになりましたし、個人クレジットカードでの立替精算とかします。 Amazonとかは「あなたの売上のうち、広告にはこれだけ手数料はこれだけなので引いてあります」みたいな文書が来たりとかします。そこで、この辺をまとめて「通帳」という単位で扱うことにしました。

この強化で、ほとんどの計上損益の処理が伝票の直接入力から解放されました。そのうちのほとんどの「経費」の処理が「現場にお任せ」にできるようになりました。

AIの採用

前回のエントリで書いたように、MCPを作ってAIを使って会計をすることは絶大な威力があります。前回の決算は本当に楽ができました。

しかし、前回のエントリの最後の方で書いたように、「汎用エージェントの限界」と感じることも結構ありました。あらためて整理すると、

一々エージェントと会話するのはダルい
意図が通じない時はイライラする
APIのコストが結構なものになる
待ち時間が長い
検証の手間は減らない

というようなことです。

「エージェントに証憑渡したら自動で起票してくれる」とか、確かにカッコイイですが、ルーチンワークとしての会計業務(担当者がいるちょっと大き目の会社)やたまに思いついた時にまとめて会計する(零細企業あるある)というスタイルには向いていません。つまり、デモとしては面白いのですが、まともに会計業務をやろうとすると、あまり使い勝手が良くありません。この延長で改良しても、APIコストが重くなるだけです。

余談ですが、「AIシステムのPoC死」はおそらくこの辺の見通しが甘いからではないでしょうか？ 「AIスゲーーー」というものを作っても、実用にするには使い勝手が良くない。かと言って使い勝手を追求すると「AIとは？」となる

会計なんてのは基本的にはルーチンワークに過ぎないはずなのに、なんか手間がかかるわけです。 AIエージェント使うと確かに随分と楽にはなるのですが、別の意味で疲れるとゆーか。

そこで、

会話しなくても「ボタン」だけで発動する
処理の基本はルールベースとして、ルール生成にAIを使う
画像処理(スキャンした証憑のOCRとか)は極力AIじゃない処理で行う

という方針で作りました。つまり、極力AIを使わずに、「ここぞ」という箇所にだけAIを使うようにしました。さらにAIを使うにしても「外部エージェントではなく直接AI処理を行う」ことにしました。つまり、Hieronymus自体がAIエージェントとなるわけです。

他方、決算日にある特殊な仕訳とか計上損益以外の処理とかは、ルールを作って適用とか「専用画面」を作るよりはAIエージェントに任せてしまった方が楽になります(ということがわかっています)。ここはMCPを使って外部エージェントにさせた方が便利です。

AIの処理はLegionのネイティブエージェントエンジンを切り出してライブラリ化したものを使いました。特別に凄いことをしているわけではありませんが、複数キーの切り替えとか、MCP呼び出しとかメモリーとか最初から装備しているので、ライブラリとして使うのは便利だろうというだけの考えです。

経費精算

経費精算は

「精算書」を作る
証憑を入れる
支払いの明細(日付、金額、内容、出金元)を入れる
明細に証憑を結びつける

というステップで行います。多分どんなシステムでもそうなると思います。

精算書には「取引先」や「案件」を任意で入れることができます。入れた場合は「取引先管理」と連結されます。つまり、取引先や案件単位でまとめることも用意されているわけです。

ここで明細には「仕訳」を入れる必要はありません。これは支払先を元に自動的に(ルールベースで)振り分けられます。

現状、科目(補助科目)単位の仕訳は、だいたい支払先レベルで決まってしまいます。これで足りなくなれば、明細とかもルールに足すとか、選択可能にするとかすればいいと思いますが、現状はそこまで必要ありませんでした。

証憑はアップロードするとOCRで認識処理がされます。

画像でアップロードしたものはマルチモーダルLLMで認識されます。この時、支払先(取引先)、科目、日付、金額… 等も併せて処理されます。

画像でなくPDFのものは、テキストが存在していればテキストの方からルールで認識します(無駄にLLMを使わない)。

複数枚の証憑をまとめてスキャンして、個々の証憑画像に分割することもできます。

こういった雑なスキャンを元に、個々の証憑の画像を切り出し、形状補正(回転とか)をかけて、綺麗な画像にします。

こんな感じです。拡大して見ると、回転補正の跡が見えると思います。ここもAIを使わずに、単純な(？)画像認識(Hough変換)と回転だけで行っています。

通帳の管理

今までは銀行科目の元帳が通帳のレイアウトに近いレイアウトで見えるだけの「銀行元帳」だったのですが、今回はもっと攻めてみました。

定常的に入出金があるもの、一般の会計では「補助記入帳」に分類されるものをまとめる単位を「通帳」として処理できるようにしました。この中には、

預金通帳
法人カード(クレジットカード)
立替で使った個人カード
自動的な入出金の後に送られて来る「計算書」

が入れられるようにしました。

個々の通帳を開くと、

こんな感じです。

ルールにあるものは自動的に起票されます。ルールにないものは「仮起票」ということで、相手方勘定が「入金仮」や「出金仮」になっているので、これを正しくしてやれば「起票済」となります。

ルールを作る/修正するには、摘要のリンクをクリックするとダイアログが開いて「この摘要(完全一致です)はこう起票する」というルールを入れてやると、次からはそのルールが摘要されるようになります。

ルールが「完全一致」にしてあるのは、緩くし過ぎて間違った処理をしてしまうのを避けるためです。人間、結果が出ているとつい正しいつもりでそのままにしてしまいがちです。「完全一致」であれば、「正しく処理できるか、処理が全くできないか」のいずれかになります。

緩くマッチさせた方が「よしな」にしてくれることが多いのですが、間違いが怖いので。

こんな感じで以前は「通帳から間違いなく起票する」という面倒臭い作業だったものが、通帳を読み込ませるだけで処理できるようになりました。通帳のフォーマットも、Excel, CSV, PDF, 画像に対応しています。

「計算書」はもっと凄い処理になっているのですが、長くなるので割愛します。わかる人にはわかると思いますが、Amazonから落とせる意味不明の計算書をいい感じに自動的に仕分けるようにできています。