Case 05 / 飲食店の月次レポート

集計をコード側に寄せると、0/19 が 18/19 になった

架空の飲食店の日次売上から月次レポートを生成させ、生データを渡す条件と集計済みの表を渡す条件で比較しました。同じモデル・同じプロンプトでスコアが 0/19 から 18/19 に変わっています。

  • 実施 2026年8月
  • 試行 各モデル3回（n=3）
  • 対象 Qwen3 32B / 14B / 8B ＋ Sonnet 5
  • 出力 全24件

Conclusion

結論

架空の飲食店の日次売上から月次レポートを生成させ、生データを渡す条件と集計済みの表を渡す条件で比較しました。同じモデル・同じプロンプトでスコアが 0/19 から 18/19 に変わっています。

  1. 01

    渡すデータの形を変えただけで、点数が0点から18点になった

    飲食店の日次売上から月次レポートを作らせました。生の明細を渡すと19項目中0件しか正しく計算できなかった32Bが、集計済みの表を渡すと18件を正解しました。モデルもプロンプトも同じで、変えたのは入力の形だけです。

  2. 02

    間違っていても、レポートの見た目は整っていた

    計算を誤ったときも、出力は体裁の整ったレポートとして返ってきます。明らかに壊れた出力なら気づけますが、数字が違うだけの整った文章は、検算しない限り誤りに気づけません。レポート生成をAIに任せるうえで、もっとも警戒すべき失敗の形です。

  3. 03

    「集計はプログラム、解釈はAI」という切り分けが有効だった

    前のケース（アクセス解析）で出た「ローカルLLMに実数の導出は任せられない」という結論は、「計算を外に出せば任せられる」と更新できます。AIに何をさせないかを決めることが、そのまま精度の設計になります。

Input

入力：何を渡したか

この検証が答えを出す問い

小規模飲食店の月次レポートは、POSデータは持っているのに活用できていない典型例。 数字を集計する手間と、そこから何が言えるかを考える手間の両方が店主一人にのしかかる。 売上データは取引先・原価・従業員数と紐づく機微情報でもあり、閉域で回せる価値があります。

QUESTION 1

計算をコード側に寄せれば、ローカルLLMでも実務水準の月次レポートが書けるのか

QUESTION 2

集計とインサイト抽出の、どちらが弱点なのか

QUESTION 3

母数の小さい区分から、誤った結論を導かないか

QUESTION 4

提案がデータに紐づくか、それとも一般論に流れるか

サンプルデータ

架空の店舗「みなも亭」（カフェ&ダイニング／20席／水曜定休）の2026年5月・6月の日次売上。 実在の店舗とは無関係です。

CSVの列：日付／曜日／天候／営業／ランチ客数／ランチ売上／ディナー客数／ディナー売上／備考

仕込んだ事実（レポートで指摘されるべきもの）

ID内容根拠となる数値
I1 必須 減収の構造は「客数減 × 単価増」 売上 -7.6%、客数 -10.1%、客単価 +2.8%
I2 必須 ランチ新メニューが客単価を押し上げた 1,177円 → 1,422円（+20.8%）
I3雨天のディナー客数が明確に少ない 雨 10.8人 vs 晴 16.9人
I4金曜ディナーの客単価が突出 金 4,829円 vs 他曜日 3,517〜3,603円
I5月曜が最も弱い 月 19.2人／60,712円 vs 土 29.7人／114,017円
I6ディナーの席回転率が1.0を下回る ディナー 0.76（ランチ 1.22）

仕込んだ罠

罠内容誤答したときの値
罠1 客単価を、日別客単価の単純平均で出す 2,278円（正解 2,325円・差47円）
罠2 休業日（6/10）を平均の母数に含める 日平均売上 88,863円（正解 92,281円）
罠3 貸切日（6/20・22名132,000円）を通常営業の傾向に混ぜる 「土曜のディナー客単価が高い」
罠4 母数5日の「曇」から結論を導く 「曇の日が最も売れる」
罠4の作り方。 天候別のディナー平均客数は 晴16.9 / 曇19.6 / 雨10.8 で、曇が晴を上回ります。 これは曇が5日しかなく、うち金・土が2日含まれるため（晴は10日中3日が月曜）。 曜日構成の偏りによる見かけの差であって、「曇の日が売れる」とは言えません。 言えるのは「雨天のディナー客数が明確に少ない」だけです。
入力データと正解値がズレない設計。 日次CSV・集計表・正解値のすべてを1つの生成スクリプトから作っています。 データを作り直しても正解が追随するため、「サンプルの見た目」と「採点基準」が食い違うことが起きません。

Process

処理：どう投げたか

プロンプトは全モデルで同一、1文字も変えていません。

prompt.txtプロンプト全文TEXT · 3KB

実行手順

1

プロンプトを固定する。

両条件・全モデルへ1文字も変えず投入する。 差し込むデータだけが違う状態を保つ。

2

レポートを生成する。

3モデル × 2条件 ×

n≧3

＝ 18件（＋クラウド6件）。

3

数値を機械照合する。

19項目の一致と、罠1〜4の踏み方、5セクションの有無、前月比の方向が判定される。

4

採点する。

7軸に ◎○△× を付け、判定理由を1行ずつ残す。

条件AとBのスコア差を必ず記録する

——これがこのケースの中心的な数字。

採点スクリプトは動作確認済み。 正解どおりのレポートで19/19一致・罠ゼロ、誤答レポートで罠1〜4と前月比の方向の誤りをすべて検出することを、 モデルを動かす前に確かめてあります。

Output

出力：何が返ってきたか

全23件を公開しています。クリックで出力のJSONを開きます。

モデル条件A 生データ条件B 集計済み
claude-sonnet-5クラウドrun1run2run3run1run2run3
qwen3:32brun1run2run3run1run2run3
qwen3:14brun2run3run1run2run3
qwen3:8brun1run2run3run1run2run3

Scoring

採点：どう測ったか

採点キーはモデル出力を1件も見ないうちに確定させています。実行後に基準を足したり緩めたりしていません。

answer-key.md採点キー（正解値19項目・罠4種）MARKDOWN · 10KB

評価軸（7軸・4段階）

全ケース共通の7軸を、このタスク用に読み替えて使う。採点キーはモデル出力を1件も見ないうちに確定させてある。

軸共通の名称このケースでの読み替え
①網羅性指定した5セクションと必須指標を漏れなく出せているか
②抽出の正確性集計値の計算精度（客単価・平均・前月比・回転率）
③属性の正誤曜日・時間帯・天候の区分に、正しい数値が紐づいているか
④曖昧な事項の扱い母数の小さい区分・休業日・貸切日を適切に扱えるか
⑤ハルシネーションデータにない数値・事実の創作
⑥ノイズ除外特異日を一般傾向として扱わない。一般論の施策を並べない
⑦フォーマット遵守・日本語品質5セクション構成、見出し、日本語の自然さ
重大な誤りは1箇所で△以下。 総売上・客単価の誤り／前月比の方向の反転／罠1〜3を踏む／データにない数値の創作。 いずれも店主が意思決定を誤る種類の誤りです。

Result

結果

7軸の評価

◎=誤りゼロ ／ ○=軽微な誤り1〜2 ／ △=誤り3以上または重大な誤り1 ／ ×=破綻

条件A：生の日次CSVを渡す

軸Sonnet 532B14B8B
①網羅性○◎△◎
②抽出の正確性◎×××
③属性の正誤◎×××
④曖昧な事項の扱い◎△△△
⑤ハルシネーション◎×××
⑥ノイズ除外◎△△△
⑦フォーマット・日本語◎◎×○

条件B：集計済みの表を渡す

軸Sonnet 532B14B8B
①網羅性◎○◎○
②抽出の正確性◎◎○○
③属性の正誤◎◎○○
④曖昧な事項の扱い◎○◎△
⑤ハルシネーション◎◎○×
⑥ノイズ除外◎◎◎○
⑦フォーマット・日本語◎◎◎◎

①網羅性 ②抽出の正確性 ③属性の正誤 ④曖昧な事項の扱い ⑤ハルシネーション ⑥ノイズ除外 ⑦フォーマット遵守・日本語品質

Discussion

考察

最も危険な失敗の形

条件Aで32Bが出したレポートは、5セクション構成を守り、前月比の方向（減収）も当てていた。 読める形をしているのに、数字だけが全部違う。

項目32Bの出力正解誤差
総売上4,444,100円2,399,310円1.85倍
営業日数29日26日+3日
客単価4,297円2,325円1.85倍
ランチ客単価3,666円1,303円2.8倍
店主がこれを見れば、売上を倍近く過大に認識する。 「明らかに壊れた出力」なら気づけるが、体裁が整っているぶん、検算しない限り誤りに気づけない。 レポート生成をローカルLLMに任せるうえで、最も警戒すべき失敗の形。

「たくさん考えて、間違える」

条件Aでは、出力トークンが本文量に対して異常に膨らんだ。

モデル条件出力トークン本文文字数比応答時間
qwen3-14bA11,3562,1655.21,389秒（23分）
qwen3-14bB2,1081,5561.433秒
qwen3-8bA9,0302,0294.4—
qwen3-8bB3,1691,8221.7—
14Bは3試行のうち1件がタイムアウト（1,800秒）、1件が23分かかった。 それでいて精度は 4/19 と 1/19。GPU時間が課金対象であることを踏まえると、 生データを渡す構成は「遅くて・高くて・不正確」という三重の不利になる。 条件Bでは同じ14Bが33秒・14/19で返している。

母数の小さい区分は乗り越えられたか

天候別のディナー平均客数は 晴16.9 ／ 曇19.6 ／ 雨10.8 で、曇が晴を上回る。 これは曇が5日しかなく金・土が2日含まれるため（晴は10日中3日が月曜）で、 曜日構成の偏りによる見かけの差。「曇の日が売れる」とは言えない、という罠を仕込んだ。

モデル結果実際の記述
14B（条件B）明示的に回避 「日数が少ない曜日（例：土曜日3日）や天候（例：曇り5日）については、傾向として断定できない」
Sonnet 5（条件B）明示的に回避 雨の落ち込みを正しく指摘したうえで「金曜は4日分のみのデータであり、傾向として断定はできません」
Sonnet 5（条件A）保守的に回避 「天候別の売上影響については、区分ごとの日数が少なく本レポートの分析対象外とした」
32B・8B（条件B）触れずに回避 天候別の分析に言及しなかった。罠は踏んでいないが「配慮した」わけではない
「曇の日が最も売れる」と断定したモデルはゼロだった。 ただし内訳は「母数に言及して避けた」ものと「触れなかっただけ」に分かれる。 後者は罠を踏んでいない一方、指摘すべき事実（雨天の落ち込み）も落としている。 集計側で「n=5」のように件数を併記しておけば、モデルの判断を助けられるという設計上の示唆になる。

条件Bでも残った誤り

集計済みを渡しても、すべてが解決したわけではない。

モデル出力問題
8B 「ディナーの売上は貸切イベントを除くと前月比1.2%増加（1,572,160円 vs 1,550,000円推定）」 集計表に5月のディナー売上は載っていない。実際は1,764,660円。推定値を創作している
8B 「客単価が前月比21.7%上昇」 新メニュー前後の変化は+20.8%、月次の前月比は+2.8%。2つを混同したうえでどちらとも違う値
14B 「6月15日以降のランチ客数が前半比で10%増加」 正しくは+4.8%（310人→325人）。表に載っている値の誤読
「根拠らしきものが付いている」ことと「根拠が正しい」ことは別。 提案そのものは4モデルとも数値を伴っており、「SNSを活用する」型の一般論は見られなかった。 しかし8Bは根拠に創作値を混ぜている。提案の説得力だけで判断すると見落とす。

モデル別の総括

claude-sonnet-5

生データでも集計できる。 ただし保守的に落とす

両条件で17〜19項目一致。貸切日の除外計算まで自発的に行う。 一方、条件Aでは天候分析を丸ごと「対象外」とした。慎重さと網羅性がトレードオフになっている。

qwen3:32b

集計させなければ 最良のローカルモデル

条件Bで18/19。貸切日の扱いも正確で提案も根拠付き。 条件Aでは0/19。体裁を保ったまま全数値を誤るため気づきにくく危険。

qwen3:14b

母数への配慮まで届く。 ただし条件Aは実務不能

罠4を明示的に回避した唯一のローカルモデル。 一方で条件Aは1件タイムアウト・1件23分。条件Bでも表の値の誤読があり14/19。

qwen3:8b

条件Bでも 推定値を創作する

数値一致は16.7/19と健闘するが、集計表にない値を作った。 前月比と新メニュー効果の混同もある。速いが、出力をそのまま信じられない。

検証03からの持ち越しに答える

検証03（GA4データ → 解析インサイトレポート）の結論は「3サイズとも実務水準に未達」でした。 そのとき積み残しになったのが「計算はコード側に寄せれば解けるのか」という問い。 このケースは2条件を並べることで、それに答えます。

CONDITION A

生データを渡す

日次CSV 2か月分（54行） → モデル → レポート

  • 集計 ＋ インサイト抽出の両方を任せる
  • 検証03と同じ土俵
  • 入力 3,209文字

CONDITION B

集計済みの表を渡す

集計表（Markdown） → モデル → レポート

  • インサイト抽出だけを任せる
  • 計算はプログラム側で担保済み
  • 入力 2,376文字

プロンプトは両条件で1文字も変えません。 差し込むデータだけが違う。 A と B のスコア差が、そのまま「計算をコード側に寄せた効果」になります。 これは検証04で得た「用語集はプロンプトで守らせるより後処理の一括置換が確実」、 検証03の「ガードレールはプログラム側で担保する設計が必須」と、同じ方向の問いです。

Implications

実務への示唆

実務への示唆

集計はプログラムで、解釈はLLMで。

検証03の「ガードレールはプログラム側で担保する設計が必須」、 検証04の「用語集はプロンプトで守らせるより後処理の一括置換が確実」と、同じ方向を指している。 3ケース連続で、「LLMに任せる範囲を狭めるほど実用に近づく」という結果が出た。

月次レポート業務に落とすなら

  • POSデータの集計はSQL／スクリプトで行う。ここは決定論的に正確に出せる領域で、LLMに渡す理由がない
  • 集計結果の表をLLMに渡し、インサイトと提案を書かせる。この範囲ならローカル3サイズとも実務水準に近い
  • 母数の小さい区分には、集計側で「n=5」のように件数を併記しておく。モデルの判断を助けられる
  • 出力の数値は、集計表と機械的に突き合わせる。8Bのように「表にない値」を作る場合がある
検証03の結論を更新できる。 「実数から新しい値を導出するタスクは3サイズとも未達」は、 「生データを渡す構成では不可。集計を外に出せば可」と書き換えられる。

Files

使用した資料一式

実際に投入したデータ、プロンプト、採点キー、出力の実物です。加工していないため、同じ条件で再現できます。

prompt.txtプロンプト全文TEXT · 3KB answer-key.md採点キー（正解値19項目・罠4種）MARKDOWN · 10KB outputs/モデル出力の実物（全23件）JSON · 一覧は「出力」セクション
検証レポート一覧へ

生成系AI活用、DX推進についてご相談ください

レビュー分析やインサイト生成、戦略支援など、生成系AIの活用やDX推進について幅広く支援いたします。

お問い合わせ