社内の経費精算や売上集計で、生成AIに表計算データの集計を任せた経験がある方に向けた内容です。AIが出した合計値が、実はこっそり行を読み飛ばしていた場合、その誤りにどう気づくかを整理します。
大規模言語モデル（LLM、文章や数値の並びを予測して応答を生成するAIの仕組み）に「この列を合計して」と頼むと、もっともらしい数字が返ってきます。ところが、その数字が正しいという保証はありません。LLMは電卓のように計算しているわけではなく、次に来る単語（トークン）を予測しているだけだからです。
ある開発者が、AIに売上シートの合計を出させたところ、行が静かにスキップされた誤った合計を、何の警告もなく提示された経験を公開しています。この問題は個人の作業ツールだけでなく、業務システムにAIを組み込む場面でも同じ構造で起こり得ます。
LLMは「計算」ではなく「推測」している
まず押さえておきたいのは、LLMの内部動作です。表データをAIに渡すと、モデルはセルの値を1つずつ足し算しているわけではありません。
シリアライズ（表形式のデータを文字列の並びに変換すること）されたテキストを読み込み、そこから「答えらしい文字列」を生成しています。桁数が少なく単純な合計なら正解することもありますが、行数が増えたり列の意味が曖昧だったりすると、誤りが混入しやすくなります。
しかも厄介なのは、AIが誤りに気づいていない点です。「たぶん違うかもしれません」といった留保（ヘッジ）なしに、確信を持った口調で誤答を返すことがあります。業務システムの検収データや月次決算のように、数値の正確性が問われる場面では、この「確信を持った誤り」が最も危険なパターンです。
解決策の構造 - AIに計算させず、コードに計算させる
この問題への対処法として紹介されているのが、AIの役割を「計算」から「計算方法の提案」に限定する設計です。仕組みは次の3段階に分かれます。
- AIは列名（region、revenueなど）と型、サンプル行だけを見て、集計ロジックをJavaScriptのコードとして書く
- そのコードはブラウザなどローカル環境で、実データ全件（検証では10万行まで）に対して実行される
- 実行結果は表示前に、AIを介さない別の検証ロジック（監査役）が再チェックする
この設計のポイントは、AIが数値そのものに触れない点です。AIは「地域ごとにグループ化して合計し、降順に並べる」という方針だけを決め、実際の四則演算はプログラムが担当します。次のトークンを予測する処理と、実際の演算処理を完全に分離することで、推測が数値に紛れ込む余地をなくしています。
業務システムの設計に馴染みのある言葉で言い換えると、これは「AIをオーケストレーション層（処理の指揮者）に置き、実行はデターミニスティック（決定的、同じ入力なら必ず同じ結果になる）なロジックに任せる」アーキテクチャです。マイクロサービスの世界で、リクエストのルーティングだけを担う軽量なゲートウェイと、実処理を担うバックエンドサービスを分離する発想と近いものがあります。
表示前の再検証 - クロスフッティングという古典的な会計手法
コードが正しく実行されても、ロジック自体にバグがある可能性は残ります。列の取り違えや、境界条件（エッジケース）の見落としは、人間が書くコードでも珍しくありません。
そこで導入されているのが、表示前の監査プロセスです。具体的には4つの検証が行われます。
- トレーサビリティ - 表示された合計が、実データの行を積み上げた値と一致するか
- パーセント計算の検算 - 「北地域は売上の40%」なら、実際に400/1000という割り算が成立しているか
- クロスフッティング - 地域別の合計と製品別の合計など、切り口を変えた集計が同じ総額に一致するか
- クレームの裏付け - 「ノートPCが最も売れた製品」という文章の主張が、実際の計算結果と整合しているか
クロスフッティングは、経理・会計監査の現場で古くから使われている検算手法です。表を縦に足しても横に足しても同じ総額になるかを確認するもので、Excelのピボットテーブルでも同じ発想の検算が可能です。AIの出力にこの古典的な手法を組み合わせている点は、目新しい技術というより、枯れた検証手法をAI時代に持ち込んだ工夫と見るのが実態に近いところです。
いずれかのチェックに1つでも失敗すると、その数値は「近似値として表示」ではなく、表示自体がブロックされます。あいまいな数字を出すくらいなら、何も出さない方が業務上安全という判断です。
既存の業務システムへの当てはめ方
この仕組みを自社の業務システムに応用する場合、まず確認したいのは「AIにどこまでの計算を任せているか」です。
請求書処理、在庫集計、KPIダッシュボードなど、LLMの出力をそのままユーザーに見せている箇所があれば、そこは要注意です。特にAPI連携でLLMに集計クエリの結果解釈やサマリー生成を任せている場合、生成された数値がどこにも検算されずにそのまま画面に出ていないか、確認する価値があります。
確認の実務手順としては、次のような順序が現実的です。
- AIの出力のうち「数値そのもの」と「数値の解釈・説明文」を切り分けてログに残す
- 数値の生成元がAIの自由記述か、実行されたコードの戻り値かを特定する
- 自由記述であれば、既存の集計ロジック（SQLやBIツールの計算式）と突き合わせる検証バッチを別途用意する
- クロスフッティングが可能な指標（合計と内訳の一致など）は、既存のテストコードに検算アサーションとして組み込む
紹介されている実装はReact 19とTypeScriptとViteで構成され、バックエンドを持たずブラウザ内で完結する構成になっています。またAGPL-3.0ライセンスで公開されており、GitHub上でコード全体を確認できます。社内システムへの応用を検討する際は、ライセンス条件を必ず確認したうえで、監査ロジックの実装部分だけを参考にする、といった使い方も考えられます。
無料で使える範囲（ダッシュボード、KPI算出、トレンド分析、需要予測）はAI不要でローカル完結する一方、対話的な質問応答や深掘り分析にはOpenAIやGemini、DeepSeekなど利用者自身のAPIキーが必要とされています。自社のAPIキー管理ポリシーと照らして、キーがどこにも送信されずブラウザから直接プロバイダに通信する設計になっているかは、セキュリティ観点で確認しておきたいポイントです。
まとめ
AIに数値集計を任せる際は、「AIが計算しているのか、コードが計算しているのか」を切り分けて考える視点が出発点になります。
既存の業務システムでLLMの出力をそのまま画面表示している箇所があれば、クロスフッティングのような古典的な検算ロジックを後付けできないか、まず洗い出してみる価値があります。
AIオーケストレーションと決定的な実行・検証を分離する設計は、目新しい流行というより、会計監査や既存のテスト設計の考え方をAI時代に応用したものです。手元のシステムでAIが数値を「提案」しているのか「断定」しているのかを、今日一度確認してみるとよいかもしれません。