AIは数字に弱い？LLMでデータ分析を正しく進める方法

生成AIは、複雑な質問に答え、長い文章を要約し、分析用のプログラムまで作成できます。ところが、簡単に見える足し算や小数の比較を間違えることがあります。説明が整っているほど、利用者が誤りを見落としやすい点も厄介です。

この問題を「AIは賢いのか、賢くないのか」という能力論だけで捉えると、本質を見誤ります。LLMは文章を扱う仕組みであり、電卓や表計算ソフトとは役割が異なります。大切なのは、AIに計算結果を直接答えさせることではありません。AIに分析手順とプログラムを作らせ、計算は実行環境へ任せたうえで、ロジックを別の方法で検証できる工程を整えることです。

なぜAIは簡単な計算を間違えるのか

LLMが計算を誤る理由は、数字をまったく理解できないからではありません。モデルや問題の形式、桁数、利用できるツールによって結果は変わります。ただし、LLMの基本的な仕組みは、決められた計算手順を正確に繰り返す電卓とは異なります。この違いを理解すると、高度な説明ができるAIが単純な計算でつまずく理由も見えてきます。

LLMは計算機ではない

現在のLLMの基礎となったTransformerは、文章に含まれる要素の関係を注意機構によって捉えるモデルです。離れた位置にある言葉同士の関係を扱いやすく、翻訳や文章生成を大きく進歩させました。GPT-3の論文でも、大規模な自己回帰型の言語モデルが、少数の例や指示を文脈として与えられることで、多様な課題へ対応できることが示されています。

しかし、LLMが行っているのは、入力に続くトークンを確率的に選ぶ処理です。トークンとは、AIが文章を扱う際の文字や単語のまとまりを指します。計算式を入力した場合も、内部で電卓と同じ手順を必ず実行しているわけではありません。学習した文章や数式のパターンを基に、もっともらしい続きを生成します。注意機構によって数字同士の関係を捉えられても、筆算の規則を必ず守り、正解へ到達することまでは保証されません。文章を自然に続ける能力と、演算を厳密に実行する能力は別物です。

数字もテキストとして処理される

利用者から見れば、123456という数字は一つの数です。LLMにとっては、必ずしも一つのまとまりではありません。数字はモデルごとの方式に従って複数のトークンへ分割されます。同じ桁数でも区切り方が異なる場合があり、各桁の位置関係をそのまま保持できるとは限りません。桁上がりや桁借りが続く計算では、ある桁で生じた結果を次の桁へ正しく引き継ぐ必要があります。文章の続きを予測する仕組みだけで、この状態を最後まで正確に保つのは容易ではありません。

数字のトークン化と算術性能の関係を調べた研究では、2023年3月版のGPT-3.5とGPT-4を対象に、数を左から区切る標準的な形式と、右から桁をそろえる形式を比較しています。カンマを使って右から左へ区切る形式では、算術課題の性能が大きく改善しました。この結果は、モデルが数字を処理する際に、桁の対応関係をどのように与えるかが精度へ影響することを示しています。ただし、特定のモデルと条件を使った実験であり、すべてのLLMが同じ傾向を示すと断定はできません。それでも、数の見た目が同じでも、内部での分け方によって答えが変わり得ることは、LLMの「計算結果」を単純に信頼できないことを示しています。

「論理的な正しさ」と「数値的な正しさ」

数値を扱う課題では、「何を計算するか」と「その計算を正しく実行できるか」を分けて考える必要があります。前者が論理的な正しさ、後者が数値的な正しさです。売上の伸び率を求める場面なら、比較する期間、母数、返品の扱いを正しく定めることが論理に当たります。決めた式を使い、桁や小数を間違えずに結果を出すことが数値計算です。

AIが正しい式を立てても、途中の掛け算や足し算を誤れば最終結果は合いません。反対に、計算が正確でも、前年同期ではなく前月を比較したり、顧客数ではなく明細行数を数えたりすれば、問いに対する答えにはなりません。Number Cookbookは、日常的な数値理解を幅広く評価し、小数の比較や分数の加算を含む単純な規則の課題でもLLMが失敗する場合があると報告しています。段階的に考えさせる方法は問題の分解に役立ちますが、計算まで言語生成だけで完結させれば、各段階に誤りが入り込む余地が残ります。AIの説明が筋道立っていることを、答えの正しさの証明として扱ってはいけません。

LLMがある計算に正解したからといって、同じ種類の計算を常に実行できるとも限りません。GPT-3の論文では、3桁の算術を含む課題への対応が報告された一方、苦手とするデータセットも確認されています。学習中に多く見た形式や、入力例に近い問題では適切な答えを生成できても、桁数、表記、質問の順序が変われば結果が揺れる場合があります。これは、規則を理解しているように見える出力と、規則を例外なく適用できることを区別する必要があるという問題です。

実務では、AIが計算を間違えたかどうかだけでなく、どの段階で誤ったかを確認しなければなりません。質問を式へ変える段階で誤ったのか、式は正しいものの演算で失敗したのか、計算後の数値を文章へ写す際に取り違えたのかによって対策が変わります。式の設計に問題があれば、分析条件を明確にします。演算が不安定なら電卓やプログラムを使います。結果の転記で誤ったのであれば、出力値を機械的に参照する形へ改めます。「もう一度計算して」と頼むだけでは原因を切り分けられず、別の誤答へ置き換わる可能性が残ります。

AIに数値演算を行わせるポイント

大量の数字を会話欄へ貼り付け、「合計して傾向を分析して」と頼むだけでは、何をどう処理したのかが見えにくくなります。AIには依頼を分析手順へ変換させ、PythonやSQLでプログラムを作らせます。実際の演算は、同じ命令を再現できる実行環境へ任せる方法が適しています。

理解と計算を分担する

Program-Aided Language Models（PAL）は、LLMが自然言語の問題を読み、途中の手順を実行可能なプログラムとして生成し、計算をPythonなどの実行環境へ委ねる方法です。PALの研究では、数学、記号、アルゴリズムに関する13の推論課題でこの方法を評価しました。LLMは問題を分解してコードへ置き換え、インタープリターがコードを実行します。自然言語だけで推論と計算を完結させる方法より、高い精度を示したと報告されています。

この役割分担は、業務データの分析にも応用できます。AIには「売上の定義を整理する」「必要な列を選ぶ」「期間で絞り込む」「集計単位を決める」「結果をグラフ化する」といった手順を設計させます。Pythonやデータベースには、指定された行の抽出、合計、平均、割合などの演算を任せます。ChatGPTのデータ分析機能やOpenAI APIのCode Interpreterも、モデルがPythonコードを書き、実行環境から結果を受け取る仕組みを採用しています。実行時にエラーが起きれば、AIがコードを書き直して再実行することもできます。AIに計算させるのではなく、分析工程をコードへ変換する設計を行わせることで、それぞれの仕組みが得意な役割を担えます。

AIに正しく分析させるための条件

プログラムは、書かれた命令を忠実に実行します。命令が依頼者の意図を取り違えていれば、処理が正常に終わっても正しい分析にはなりません。AIへ「顧客別の平均売上を出して」と頼む場合も、顧客の定義、対象期間、返品や取消の扱い、税抜と税込のどちらを使うかによって結果は変わります。日付の境界やタイムゾーンが曖昧なら、月末付近の取引が別の期間へ入る可能性もあります。

AIに分析コードを作らせる際は、少なくとも次の条件を明示する必要があります。

対象データ：使用するファイル、シート、テーブル、列を指定する。
集計範囲：対象期間、母集団、部署、商品などの範囲を定める。
除外条件：取消、返品、テストデータ、無効なレコードの扱いを決める。
データ品質：欠損値、重複、表記揺れ、異常値をどう処理するか定める。
数値の定義：単位、税、通貨、丸め方、割合の分母を明示する。
時間の定義：基準となる日付列、タイムゾーン、期間の開始と終了を定める。

入力データの形も精度を左右します。OpenAIの公式ヘルプでは、分かりやすい列名を付け、1行を1レコードとして整理する方法を推奨しています。一つのシートに無関係な表を複数置くことや、空行と空列で表を分断すること、分析対象の値を画像だけで示すことは避けるよう案内されています。AIの性能だけを上げても、列の意味やデータの境界が曖昧であれば、正しいプログラムは作れません。

実行前には、AIがデータをどのように理解したかも確認します。ファイル名とシート名、列名、データ型、先頭の数行、行数を表示させれば、対象の取り違えや読み込み漏れを見つけやすくなります。日付として扱う予定の列が文字列になっている場合や、金額の列に通貨記号を含む文字が混在する場合は、集計前の変換が必要です。欠損値を0として扱うのか、集計対象から外すのかも、コードが暗黙に決める状態を避けます。分析を依頼する文章が明確でも、読み込まれたデータの型が想定と違えば、誤った結果が得られます。

結果ではなく処理の記録を残す

AIに最終的な数値だけを答えさせると、誤りが見つかったときに原因を追えません。生成したコード、入力件数、除外件数、途中の集計、最終結果を一緒に残す必要があります。たとえば、元データが何行あり、重複を何件除き、どの列を使って集計したかが分かれば、条件の取り違えを確認できます。分析条件をコードとして固定すると、同じデータと環境で処理を再実行しやすくなり、変更した箇所も追跡できます。グラフや文章による要約は、記録された計算結果を基に作成させます。

再実行できる状態にするには、コードだけでなく、使用したデータと実行条件もそろえる必要があります。同じ処理でも、更新後のファイルを読めば結果は変わります。入力ファイルの版、実行日時、使用した列、適用した条件を結果と結び付けて残します。途中集計を保存しておけば、最終値だけが合わない場合にも、絞り込み、変換、集計のどこで差が生じたかを追跡できます。AIの回答を一回限りの会話として終わらせず、再現性のある分析記録へ変える運用が必要です。

プログラムへ任せれば、すべての数値が自動的に正確になるわけでもありません。Pythonの公式ドキュメントは、多くの10進小数を2進浮動小数点数で正確に表せないと説明しています。これはLLM固有の問題ではなく、一般的なコンピューター計算の制約です。金額や厳密な小数計算では、整数で最小単位を扱う方法や10進数型の利用を検討し、丸める段階と規則を決める必要があります。AIが正しい構文のコードを書いても、数値型の選択が目的に合っていなければ、期待した結果との差が生じます。コード実行は計算ミスを減らす手段であり、データの意味や分析目的まで正しくする保証ではありません。

AIは自分が作ったロジックを検証できるか

分析コードがエラーなく終了すると、結果まで正しいように見えます。しかし、プログラムが正常に動くことは、書かれた命令を実行できたことしか示しません。AIはレビューやテストの作成にも利用できますが、同じAIへ「自分の答えを見直して」と頼むだけでは、検証として不十分です。

「コードが動くこと」と「ロジックの正しさ」は異なる

売上合計を求めるコードが最後まで動いても、返品を除外していなければ、求めたい売上とは一致しません。顧客数を数えるつもりで明細行を集計すれば、複数回購入した顧客を重複して数えます。税抜金額と税込金額が同じ列に混在していても、プログラムは警告せず合計できる場合があります。いずれも構文エラーではなく、要件の解釈やデータの意味に関する誤りです。

AIは、生成したコードの処理内容を説明し、要件との対応を整理できます。境界値や例外を洗い出し、テストコードを作り、別の実装方法を提示することも可能です。ただし、コードを作ったAIとレビューするAIが同じ前提を共有していれば、最初の誤解をそのまま引き継ぐ場合があります。誤った仕様解釈からコードとテストを同時に作れば、誤ったコードが誤ったテストを通過します。AIによる説明やテストの存在だけで、ロジックの正しさが証明されたとは判断できません。

外部からのフィードバックの重要性

ICLR 2024で発表された研究では、外部からフィードバックを与えず、LLMに自分の推論を見直させる「内在的な自己修正」を調べています。その結果、自己修正が推論性能を改善できず、修正後に性能が下がる場合もあると報告されました。この研究は自己修正が常に不可能だと結論づけたものではありません。正解や実行結果などの外部情報がない状態で、同じモデルに再考を促すだけでは信頼できる検証にならないことを示しています。

CRITICの研究は、検索エンジンやコードインタープリターなどの外部ツールから得た情報を使い、LLMの出力を検証して修正する方法を提案しています。自由回答、数学的なプログラム合成、有害性の低減に関する評価では、外部ツールからのフィードバックによって性能が改善したと報告されています。分析コードの検証でも、AIの内省へ期待するのではなく、実行結果、既知の正解、別の集計結果など、外から比較できる材料を与える必要があります。

ロジックと数値を二重に確認する

分析の検証では、仕様を文章化し、確かめられる形へ変えることが出発点になります。重要な指標ほど、一つのコードと一つのテストだけに依存せず、複数の確認方法を組み合わせます。

要件の固定：指標の定義、対象期間、母数、除外条件、単位、丸め規則をコード作成前に文章化する。
既知の正解によるテスト：担当者が手計算または既存システムで確認した小さなデータを使い、期待値との一致を確認する。
境界値と例外の確認：0件、欠損、重複、負数、日付の境界、大きな値を含むデータを試す。
不変条件の確認：部門別合計と全社合計、構成比の合計、処理前後の件数など、必ず成立する関係を検査する。
別経路での再計算：異なる式、SQL、表計算ソフト、ピボット集計などで重要な指標を照合する。
元データとの照合：抽出されたレコードをサンプリングし、原票や基幹システムの値と比較する。
記録と承認：使用データ、コード、実行日時、ライブラリの版、出力、確認者を残し、重要な判断は責任者が承認する。

テスト駆動開発では、機能を実装するコードより先に期待する挙動をテストとして定めます。LLMのコード生成にこの考え方を取り入れた研究では、問題文にテストを加えることで、プログラミング課題の成功率が高まったと報告されています。分析業務でも、AIがコードを書いてから都合のよいテストを考えるのではなく、担当者が確認した小さなデータと期待値を先に用意する方法が有効です。

この順序には、コードとテストへ同じ誤解が入り込むのを防ぐ意味があります。たとえば、返品を除外するという要件をAIが見落とした後でテストも作らせれば、返品を含む合計を正解として扱う可能性があります。コード生成前に、通常の売上、返品、取消、重複を含む小さな例と期待値を担当者が確定しておけば、生成された処理を外部の基準と比較できます。すべてのデータを手計算する必要はありません。仕様の違いが結果へ表れる最小限のケースを用意し、その後に実データの不変条件や別経路の集計で確認範囲を広げます。

AIは、要件とコードの対応を調べ、検証項目を広げる補助者として活用できます。しかし、何を正解とするかをAIだけで決めることはできません。論理的な正しさは、明文化した要件と独立したテストで確認します。数値的な正しさは、実行環境の結果と別経路の計算を照合します。この二重の確認によって、自然な説明に惑わされず、分析結果を根拠から評価できます。

AIの役割は「分析工程の設計者」へ

LLMはトークンの続きを生成する言語モデルであり、定められた手順を厳密に繰り返す計算機とは構造も目的も異なります。数字もトークンとして処理されるため、桁の分割や問題の形式によって精度が変わる場合があります。筋道の通った説明ができても、数値計算まで正しいとは限りません。

データ分析では、AIに答えを直接計算させるのではなく、分析目的を整理し、PythonやSQLのコードへ変換させる方法が適しています。実際の集計は実行環境へ任せ、生成したコード、入力件数、除外件数、途中経過を記録します。ただし、コードが動いたことは、分析ロジックが正しいことの証明にはなりません。

分析結果の信頼性は、AIの自信や説明の自然さではなく、入力データ、明示した条件、実行コード、テスト結果、確認記録によって判断します。既知の正解、境界値、不変条件、別経路での再計算、元データとの照合を組み合わせれば、AIの得意な言語理解とプログラム作成を生かしながら、弱点を補えます。AIの価値は計算を肩代わりすることではなく、曖昧な業務上の問いを、検証可能な分析工程へ変えられる点にあります。