ローカルLLMでExcel・CSVを分析する2026。売上・顧客データを外に出さない3つの方式と、できること・できないこと
「この売上表をAIに読ませて、先月との差を説明させたい。でも顧客名が入っているからChatGPTには貼れない」。経理・営業企画・人事の方からこの相談を受けることが増えました。売上・顧客・人事のデータは、会社が持つ表データの中でもっとも外に出しにくく、同時にもっとも「AIに聞きたい」ものでもあります。ローカルLLMなら表を社内に置いたまま扱えますが、「Excelを渡せば何でも答えてくれる」わけではありません。
本記事では、ローカルLLMでExcel・CSVを扱う方式を3つに分け、それぞれの向き不向き、できること・できないこと、閉域で動かす構成、精度の確かめ方を整理します。結論を先に言うと、実務で使える形は「計算はコードや表計算ソフトに任せ、LLMには質問の変換と結果の説明を担わせる」構成です。LLMに暗算をさせる構成は、表が小さいうちしか成り立ちません。
この記事の要点
- ローカルLLMで表データを扱う方式は、①表をそのままプロンプトに入れる、②LLMにコードを書かせて社内で実行する、③RAGで表を検索する、の3つです。実務の本命は②で、①は小さな表の下読み、③は「表の中の文章」を探す用途に限ります
- LLMは集計・並べ替え・条件抽出・異常値の説明・自然文からコードへの変換が得意ですが、大きな表の直接計算と厳密な四則演算の保証は苦手です。「LLMに計算させない」が設計の原則です
- 方式②には、コードを書けるモデル（Qwen3-Coder系など）と、社内に閉じたコード実行環境が必要です。コンテキスト長は32K以上を目安に設定します
- 個人情報や機密列は、LLMに渡す前にマスキングするか列ごと除外します。ローカルでも「誰が何を見られるか」の統制は残ります
- 精度は「答えが分かっている集計10〜20問」を用意して正答を照合してから判断します。実測せずに「精度は高い」と書く資料は信用しないでください
誰がローカルLLMでExcel・CSVを分析する必要があるのか
クラウドの生成AIに表を貼れない理由は、たいてい表の中身にあります。
| データ | 外に出せない理由 | よくある分析の要望 |
|---|---|---|
| 売上・受注データ | 取引先名・単価・値引率が営業秘密に当たる | 前年同月比の説明、落ち込んだ顧客の抽出、商品別の傾向 |
| 顧客リスト・問い合わせ履歴 | 個人情報を含む。利用目的の範囲と第三者提供の問題 | 問い合わせの分類、解約予兆の抽出、対応漏れの検出 |
| 人事・給与データ | 個人情報の中でも機微性が高い。社内でも閲覧権限が限られる | 残業時間の偏り、離職率の推移、評価分布の確認 |
| 製造・品質データ | 工程条件や歩留まりが営業秘密に当たる | 不良率の変動要因、ロット間の差の説明 |
| 受託案件の顧客データ | 契約で外部保管・外部送信が禁止されている | 納品前のデータ検証、集計表の作成 |
個人情報保護委員会は2023年6月の注意喚起で、個人データを含むプロンプトを入力する場合は、その事業者が機械学習に利用しないことを十分に確認するよう求めています。法人契約のクラウドAIなら学習利用なしを契約で確保できますが、「社外に送信する」こと自体を社内規程や取引先との契約が禁じている場合は、ローカルLLMが受け皿になります。どのデータ区分ならクラウドの法人契約で足りるかの線引きは『社内生成AI利用規程のひな形2026』の線引き表を参照してください。
なお、ここで扱うのは「表データの分析」です。帳票の画像やPDFから項目を読み取る工程は『ローカルLLMでOCR』が担当範囲で、本記事はすでに表になっているデータが対象です。
3つの方式の比較。プロンプトに入れる・コードを書かせる・RAGで検索する
ローカルLLMで表を扱う方式は3つあります。どれを選ぶかで、必要なモデル・機材・構築の手間がまったく変わります。
| 方式 | 仕組み | 向く表 | 必要なもの | 限界 |
|---|---|---|---|---|
| ① 表をそのままプロンプトに入れる | CSVやMarkdown表をテキストとして貼り、LLMに読ませる | 数十行〜数百行程度の小さな表。下読み・要約・項目の説明 | チャットUIだけ。モデルは日本語が読めれば何でも | 行数×列数がコンテキスト長の上限に当たる。LLMが行を読み飛ばす・計算を間違えることがあり、集計結果は信用できない |
| ② LLMにコードを書かせて社内で実行する | 質問をPythonやSQLに変換させ、社内の実行環境で走らせ、結果をLLMが説明する | 数千行〜数百万行まで。集計・結合・条件抽出・可視化用の整形 | コードを書けるモデル、tool callingかコード実行機能を持つUI、閉域内の実行環境 | 列の意味をLLMに教える手間。コードの誤りを見抜く人が要る |
| ③ RAGで表を検索する | 表を行や段落に分けて埋め込み、質問に近い行を検索してLLMに渡す | 「表の中の文章」を探す用途。問い合わせ履歴の本文、備考欄の自由記述 | 埋め込みモデル、ベクトルDB、RAG基盤 | 集計には向かない。「合計はいくら」に検索で答えることはできない |
実務の本命は②です。表の大きさに関係なく正確な集計ができ、LLMは「質問をコードに変える」「結果を日本語で説明する」という得意な仕事だけを受け持ちます。①は②を組む前の下読みや、会議中に小さな表を要約させる用途に限ります。③は表を「文書」として扱う用途、たとえば問い合わせ履歴の本文から似た事例を探すときには有効ですが、「先月の合計」のような集計の質問には構造的に答えられません。RAGの作り方そのものは『社内文書RAGの作り方2026』で扱っています。
できること・できないこと
方式②を前提に、ローカルLLMに任せてよい仕事と、任せてはいけない仕事を分けます。
| 任せてよい（得意） | 任せてはいけない（苦手） |
|---|---|
| 自然文の質問を集計コード（pandas・SQL）に変換する | 大きな表をプロンプトで読んで直接計算する |
| 集計結果を日本語で説明する。前年比の増減理由の仮説を出す | 四則演算の結果を保証する（検算なしに数字を信じる） |
| 条件抽出の条件を組み立てる（「3か月連続で前年割れの顧客」） | 複雑なピボットを一発で正しく組む |
| 並べ替え・重複除去・表記揺れの正規化コードを書く | 列の意味を推測する（「金額」が税込か税抜かは分からない） |
| 異常値の候補を挙げ、確認すべき点を示す | 異常値の原因を断定する |
| グラフ用にデータを整形する | 判断そのもの（値上げすべきか等）を下す |
このうち「列の意味を推測できない」は見落とされがちです。LLMは「売上」列が税込か税抜か、「日付」列が受注日か納品日かを知りません。人が列の定義を渡す必要があります。これを怠ると、コードは正しく動いているのに業務的に間違った答えが返ります。
設計の原則は「LLMに計算させない」
ローカルLLMに限らず、LLMで表を扱うときの第一原則は「計算はコードや表計算ソフトに任せ、LLMには変換と説明を担わせる」ことです。
LLMはトークンを予測する仕組みであり、電卓ではありません。小さな表であれば正しい合計を返すこともありますが、それは「たまたま」であって保証ではありません。行数が増えるほど、読み飛ばしや桁の取り違えが起きます。方式①で集計させた結果をそのまま報告書に載せるのは、実務では避けるべきです。
役割を分けると次のようになります。
| 工程 | 担当 | 理由 |
|---|---|---|
| 質問の理解と集計コードの生成 | LLM | 自然文からコードへの変換はLLMの得意分野 |
| 集計の実行 | Python（pandas）、SQL、表計算ソフト | 計算の正確さを保証できる |
| 結果の検算 | 実行環境＋人 | 件数・合計がもとの表と合うかを機械的に確認する |
| 結果の説明と仮説出し | LLM | 数字を文章にし、確認すべき点を示す |
| 判断 | 人 | 業務上の意思決定はLLMの範囲外 |
この分担にすると、LLMの誤りは「コードが間違っている」という形で現れ、実行結果やエラーで検出できます。暗算の誤りは検出が難しいのに対し、コードの誤りは再現性があり、人が読めます。
方式②の構成例。閉域で動かすコード実行環境
方式②を社内に閉じて動かすには、3つの部品が必要です。
| 部品 | 役割 | 候補 | 注意 |
|---|---|---|---|
| 推論サーバーとモデル | 質問をコードに変換し、結果を説明する | コード生成とtool callingに対応したモデル。24GB級ならQwen3-Coder-30B-A3B、16GB級ならgpt-oss-20bなど | コンテキスト長を32K以上に設定する。表の列定義とコード、実行結果を往復させるとコンテキストを消費する |
| コード実行環境 | 生成されたコードを社内で実行する | チャットUIのコード実行機能、またはJupyterのような実行環境をLAN内に置く | 実行環境からインターネットへ出ないことを確認する。パッケージは事前に入れておく |
| ファイルの置き場 | ExcelやCSVを実行環境から読める場所に置く | ファイルサーバーの共有フォルダ、実行環境のローカルディスク | 誰がどのファイルを置けるかを決める。実行環境がファイルサーバー全体を読めないよう範囲を絞る |
モデルの選び方は、通常のチャット用途と少し違います。日本語の読み書きだけでなく、pandasやSQLのコードを正しく書き、tool callingで実行結果を受け取って続きを考えられることが要件です。『コーディングに強いローカルLLM 2026』で整理したとおり、2026年時点では24GB級でQwen3-Coder-30B-A3BのQ4量子化（約18〜19GB）が定番で、16GB級ではgpt-oss-20b（約12〜13GB）が候補です。tool callingの精度はモデルの大きさより「tool呼び出しを学習しているか」で決まるため、『ローカルLLMのtool calling』の選定基準をそのまま当てはめられます。
実用の範囲も、tool calling記事の現在地と同じです。「表を読む→集計コードを書く→実行する→結果を説明する」は1〜2ステップの連携に収まるため、ローカルでも実用になります。一方、「仮説を立てて複数の集計を自律的に繰り返し、結論を出す」ような5ステップを超える自律ループは、2026年時点ではまだクラウドが優位です。社内で使うなら、1つの質問に1つの集計で答える形に用途を絞るのが現実的です。
機材の規模感は、売上表の分析であれば『中小企業のローカルLLM2026』で扱った1台構成でも足ります。同時に何人が使うか、どのくらいの表を扱うかは、買う前に実機で確かめるのが確実です。
プロンプト例。列の説明を渡し、出力形式を指定する
方式②で精度を左右するのは、モデルの大きさよりもプロンプトに「列の定義」と「出力の形」を入れるかどうかです。
例1: 列の説明を渡す
以下はCSVファイル sales_2026.csv の列定義です。
- order_date: 受注日（YYYY-MM-DD）。納品日ではない
- customer_id: 顧客ID。顧客名は含まない
- product_code: 商品コード
- amount: 税抜金額（円）。値引き後の金額
- region: 営業拠点（東京・大阪・名古屋のいずれか）
質問: 2026年8月と9月で、拠点別の税抜売上合計と前月比を出してください。
pandasのコードを書いてください。計算はコードで行い、あなた自身は計算しないでください。例2: 出力形式を指定する
実行結果は次の形式で報告してください。
1. 集計結果の表（拠点、8月合計、9月合計、前月比%）
2. 前月比がマイナスの拠点があれば、その拠点名と減少額
3. 確認が必要な点（データの欠損、異常値の候補）を箇条書きで
数字は実行結果に出た値だけを使い、推測で補わないでください。列定義を渡すのは、LLMが「amountは税込か」を推測しないようにするためです。「計算はコードで行い、自分では計算しない」と明示するのは、方式①に戻ってしまう（表を読んで暗算する）のを防ぐためです。出力形式を固定すると、毎回同じ形で結果が返り、人の確認が速くなります。
個人情報・機密列の扱い。ローカルでも統制は残る
ローカルLLMにすれば社外送信の問題は消えますが、「社内の誰が何を見られるか」の問題は残ります。人事データを営業担当が分析できてしまう構成は、ローカルであっても事故です。
| 対策 | 内容 | 向くデータ |
|---|---|---|
| 列の除外 | 氏名・住所・電話番号など、分析に不要な列を実行環境に渡す前に落とす | 顧客リスト、人事データ |
| マスキング | 顧客名をIDに置き換える、金額を区分に丸める | 売上データで取引先名を見せたくない場合 |
| 集計済みデータだけ渡す | 明細ではなく、集計表を分析対象にする | 給与・評価データ |
| 実行環境の分離 | 人事用と営業用で実行環境とファイル置き場を分ける | 複数部門で使う場合 |
| ログの保存 | 誰がどのファイルにどんな質問をしたかを記録する | すべて。監査対応と誤用の検出 |
列の除外やマスキングは、LLMに渡す前の前処理として、実行環境側で機械的に行います。「LLMに見せないでください」とプロンプトで頼むのは対策になりません。LLMに渡したデータは、少なくともそのセッションの間はLLMが読める状態にあるからです。
どの区分のデータをどの環境で扱ってよいかは、社内規程で決めておきます。『社内生成AI利用規程のひな形2026』の線引き表は、クラウドだけでなく閉域ローカルLLMの列も持っているので、そのまま使えます。閉域に置いても残るリスク全体は『ローカルLLMは本当に安全か』で扱っています。
精度の確かめ方。答えが分かっている集計10〜20問で照合する
「ローカルLLMで表の分析ができるか」は、実測しないと分かりません。確かめ方は単純です。
- 実際に使う表（または列構成が同じサンプル）を用意します
- 答えが分かっている質問を10〜20問作ります。「2026年8月の東京拠点の税抜売上合計」「3か月連続で前年割れの顧客数」のように、表計算ソフトで正答を出せるものにします
- 同じ質問を候補モデルに投げ、生成されたコードと実行結果を記録します
- 正答と照合し、正解・不正解・コードは正しいが列の解釈が違う、の3つに分けます
- 不正解の原因が「列定義の不足」なら、プロンプトを直して再実行します。「コードの誤り」ならモデルを変えるか、質問の粒度を下げます
この手順で見るべきは正答率だけではありません。「不正解のときに気づけるか」が実務では重要です。コードが読める担当者が1人いれば、誤りの大半は実行前に見つかります。逆に、コードを読まずに結果だけ受け取る運用は、正答率が高くても危険です。
評価の軸と合否ラインの決め方は『ローカルLLM PoCの評価シート』の精度の軸と同じ考え方で、表の分析では「集計の正答率」と「列解釈の誤りの件数」を分けて記録すると改善の方向が見えます。
失敗しやすい点
表データでつまずく箇所は、LLMの賢さとは関係ない前処理の部分に集中しています。
| つまずき | 何が起きるか | 対処 |
|---|---|---|
| 日付の形式 | 「2026/8/1」「2026-08-01」「R8.8.1」が混在し、月別集計がずれる | 読み込み時に日付型へ変換するコードを定型化する。和暦は事前に西暦へ |
| 全角数字・カンマ | 「１，２００」が文字列として扱われ、合計から漏れる | 数値列は読み込み時に正規化する。列定義で「数値」と明記する |
| 単位の混在 | 千円単位の列と円単位の列を合算してしまう | 列定義に単位を書く。単位が違う列は読み込み時に揃える |
| 空セル | 空を0と扱うか除外するかで平均が変わる | 空セルの扱いを質問文に書く。「空は除外して平均」など |
| 結合セル・見出しの複数行 | Excelの見栄え用の結合が、読み込み時に列ずれを起こす | 分析用のシートは1行1レコード・1行目が見出しの形に整える |
| シートが複数 | 読み込むシートを間違える | ファイル名とシート名を質問文で指定する |
| 列名の表記揺れ | 「売上」「売上高」「売上金額」が別列として扱われる | 列名の辞書を作り、読み込み時に統一する |
これらはすべて、LLMを入れる前の「分析用の表を整える」工程で解決します。Excelを人が見るための形（結合セル、小計行、見栄えの色分け）と、機械が読むための形（1行1レコード）は違います。分析用に整えたシートを別に持つのが、もっとも手戻りの少ない方法です。
導入前チェックリスト
- 外に出せない理由（個人情報・営業秘密・契約）を特定し、クラウドの法人契約で足りないことを確認した
- 方式を決めた（小さな表の下読みは①、集計は②、自由記述の検索は③）
- 分析対象の表を「1行1レコード・1行目が見出し」の形に整えた
- 列定義（意味・単位・税込税抜・日付の種類）を文書にした
- 氏名などの不要な列を除外する前処理を実行環境側で用意した
- コード生成とtool callingに対応したモデルを選び、コンテキスト長を32K以上に設定した
- コード実行環境がインターネットへ出ない構成であることを確認した
- 答えが分かっている質問10〜20問で正答を照合した
- 生成されたコードを読める担当者を決めた
- 誰がどのファイルにどんな質問をしたかのログを残す設定にした
- 分析結果をそのまま報告に使わず、人が検算する運用にした
まとめ
- ローカルLLMで表データを扱う方式は3つあり、集計の本命は「LLMにコードを書かせて社内で実行する」方式②です。プロンプトに表を貼る方式①は小さな表の下読みに限り、RAGの方式③は表の中の文章を探す用途に限ります
- 設計の原則は「LLMに計算させない」ことです。計算はpandasやSQLに任せ、LLMは質問の変換と結果の説明を担います
- 方式②には、コード生成とtool callingに対応したモデル（24GB級ならQwen3-Coder-30B-A3B、16GB級ならgpt-oss-20b）、コンテキスト長32K以上、閉域内のコード実行環境が要ります
- 個人情報や機密列は、プロンプトで頼むのではなく実行環境側で除外・マスキングします。ローカルでも「誰が何を見られるか」の統制は残ります
- 精度は答えが分かっている集計10〜20問で照合してから判断します。コードを読める担当者がいる運用なら、誤りの大半は実行前に見つかります
よくある質問
Q. ローカルLLMにExcelファイルをそのまま渡せば分析できますか？
小さな表の下読みや要約ならできますが、集計には向きません。LLMは表をテキストとして読むため、行数が増えると読み飛ばしや計算の誤りが起きます。実務で使うなら、LLMにpandasやSQLのコードを書かせて社内の実行環境で走らせ、結果をLLMに説明させる方式が現実的です。Excelの結合セルや複数行の見出しは読み込み時に列ずれを起こすので、分析用に1行1レコードの形へ整えてから渡します。
Q. どのモデルを選べばよいですか？
日本語が読めるだけでは足りず、コード生成とtool callingに対応したモデルが要ります。2026年時点では24GB級でQwen3-Coder-30B-A3B（Q4量子化で約18〜19GB）、16GB級でgpt-oss-20b（約12〜13GB）が候補です。モデルの大きさより「tool呼び出しを学習しているか」が効くため、候補を絞ったら自社の表と質問で投げ比べて決めてください。
Q. 計算結果は信用してよいですか？
LLMが暗算した結果は信用しないでください。コードを書かせて実行した結果であれば計算自体は正確ですが、列の解釈（税込か税抜か、受注日か納品日か）を誤っている可能性は残ります。列定義をプロンプトで渡し、答えが分かっている質問10〜20問で照合し、生成されたコードを人が読む運用にすれば、誤りの大半は実行前に見つかります。
Q. 顧客名や社員名が入った表を扱っても大丈夫ですか？
ローカルLLMなら社外送信は起きませんが、社内で誰が見られるかの統制は残ります。分析に不要な氏名・住所などの列は、LLMに渡す前に実行環境側で除外するかIDに置き換えます。プロンプトで「見ないでください」と頼むのは対策になりません。部門ごとに実行環境とファイル置き場を分け、誰がどのファイルにどんな質問をしたかのログを残してください。
Q. RAGを組めば表の集計もできますか？
できません。RAGは質問に近い行や段落を検索してLLMに渡す仕組みなので、「合計はいくら」「前年比は何%」のような全体を見渡す集計には構造的に答えられません。RAGが向くのは、問い合わせ履歴の本文や備考欄のような「表の中の文章」から似た事例を探す用途です。集計はコードを書かせて実行する方式で行い、必要なら両方を組み合わせます。
Q. まず何から試せばよいですか？
実際に使う表から列定義を文書にし、答えが分かっている質問を10問作るところからです。これはモデルや機材がなくても今日できます。そのうえで、手元のPCやノートPCに16GB級の構成を作って方式②を試すか、社内設置の実現性検証（30万円〜・税別・2週間・機材貸出料込み）で貸出機材を使って、自社の表で正答率と速度を測るのが近道です。
主な参考資料: Qwen3-Coder公式ブログ、Qwen3公式ブログ、Berkeley Function Calling Leaderboard、個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」
TodoONadaでは、売上・顧客・人事データを外に出さずに分析するローカルLLMの構成を、「どの方式で」「どのモデルと機材で」「誰が検算するか」まで含めて支援しています。表の列定義と答えの分かる質問10問を用意していただければ、社内設置の実現性検証（30万円〜・税別・2週間・機材貸出料込み）やモデル選定のミニ検証（約30万円・2週間）の中で、自社の表での正答率と速度を実測できます。「うちの表で本当に使えるのか」という段階のご相談も歓迎します。
この記事に関連するサービス
TodoONada株式会社では、機密データを外部に出さないローカルLLMの導入支援を行っています。
- ローカルLLM導入支援 — GPUサーバーでの本格構成。モデル選定からRAG構築・運用まで
- Macで始める社内専用AI導入支援 — Mac 1台から始める社内専用AI。PoCから部門導入まで対応
- ローカルLLM 社内設置の実現性検証（機材貸出） — 機材を買う前に、DGX SparkやMacを貴社オフィスに2週間設置して「置けるか」を判定。機材のみの短期貸出も対応
導入・開発のご相談はお問い合わせからお気軽にどうぞ。検討段階のご相談も歓迎です。
出典・参照
- Qwen3-Coder公式ブログ（コード生成・tool calling対応モデル） （2026年10月3日確認）
- Qwen3公式ブログ （2026年10月3日確認）
- Berkeley Function Calling Leaderboard（tool callingの標準ベンチマーク） （2026年10月3日確認）
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」（2023年6月2日） （2026年10月3日確認）
