先日、こちらの記事を作成するにあたって、ChatGPTに集計を手伝ってもらいました。
でも、正しい数字ではありません。なぜ！？　その時に起きた、紆余曲折をまとめてみました。

サマリ
J1在籍チームを知りたいと思ってAIに質問。1993–2025年のJ1在籍年数カウントという一見単純なタスクで、LLM は「更新が止まった古い情報」を参照したまま、直近3年分（2023〜2025）を丸ごと欠落させました。
背景には、計算コストを抑える“最短経路回答”志向（AIコスパ病）と時間推論の弱さ、さらにはハルシネーションのリスクがあります。
本記事では、プロンプトと回答のやり取りを「5つのなぜ」で深掘りし、プロンプト設計と検証のベストプラクティスをまとめます。

1. 会話ログで見る「抜け漏れ」発生プロセス

シーン	ユーザー意図	ChatGPTの行動
①	「J1在籍クラブ全部挙げて」	2025年の所属クラブ＋過去の参加クラブを列挙
②	「在籍年数カウントして」	1993–2022年版の累計表を元に集計
③	「2023〜2025年は含まないの？」	「2022年まで更新の表を使ったため」と説明
④	「1993–2025年で再計算して」	“+1年ずつ加算”の簡易計算のみ実施

ポイント

最新クラブ一覧は正しく取得しつつも、年数カウントでは“更新停止ソース”のみを使い続けた

追加検証を省略し「+1年」で済ませたことで誤答が発生

2. 5 Whysで深掘り ― 真因は「AIコスパ病」

WHY	なぜ？	原因
1	なぜ2023-25が抜けた？	参照したサイト情報が2022年までしか更新されていなかった
2	なぜその表だけを使った？	“手近な一次ソース”として最も手軽に見つかったため
3	なぜ追加検索や検証をしなかった？	“既存知識＋静的表”で十分と判断し、コスト（検索・検証）を節約した
4	なぜ推論だけで安心した？	LLMは時間推論が苦手だが、自身の推論精度への過信があった
5	なぜ検算ルールをプロンプトに組み込まなかった？	“出力だけ最適化”する設計になりやすく、検証フェーズを設計から省いた結果

真因まとめ

LLMの「低コスト回答」志向（AIコスパ病）

時系列データの扱い不備

プロンプトに検算／検証フェーズが欠如

3. モデル側のメカニズム

3.1 “AIコスパ病”とは

LLMは毎トークン生成で計算リソースを消費するため、最短経路のもっともらしい応答を優先しがち。
その結果、外部検索や検証を省略し「手持ちの知識＋単純推論」で済ませる傾向がある。

3.2 ハルシネーション

自信度は高いが根拠が薄い応答が混入しやすい。
特に数値や時系列の計算では、事実確認抜きで生成されることが多い。

3.3 時間推論の弱点

カレンダー計算や期間演算はLLMの弱点領域。
静的データと動的シーズンの組み合わせで不整合が発生しやすい。

4. プロンプト設計 ─ 5つの鉄則

期間・定義を冒頭で固定
- 例: 1993–2025年のJ1在籍年数を、昇降格履歴を考慮して厳密に集計せよ
データソースを複数指定し“最新版”を必須化
- 公式JリーグDataSite、Wikipedia最新シーズン、RSSSFなど並行参照
検算ルールをプロンプトに埋め込む
- 例: 総在籍年数が (シーズン数 × クラブ数) と一致することを検証せよ
5 Whys をセルフクエリへ組み込む
- なぜそのソースだけで十分と言えるのか？ を繰り返し自問
ハルシネーション警告を義務化
- 不確かな場合は "N/A" と回答せよ などの制約を追加

5. チェックリスト & コード例

# 検算用: club_years は {クラブ名: 年数} の dict 前提
total_years = sum(club_years.values())
seasons = 33  # 1993〜2025 のシーズン数
assert total_years % seasons == 0, "年数総和がクラブ数×シーズン数と一致しません"

上記の自動アサーションを入れることで、計算ミスやデータ不整合を早期に検出できます。

6. まとめ ― “AIまかせ”にしないために

LLMはコスト最適化で“手抜き”を選びがち。静的情報の鵜呑みは危険。
ハルシネーションは前提とし、検証フェーズをプロンプトに組み込む。
数値・時系列の処理は特に要注意。複数ソース検証＋検算コードで裏を取る。
最後にもう一度――「なぜ？」を最低3回。5 Whysの習慣化でAIの“サボり癖”を叩き直しましょう。

プロンプトエンジニアリングとしては初歩の初歩かもしれませんが、結構陥りがちなポイントが見えてきました。
今後のAIとの付き合いの一助となりましたら嬉しいです。

ご意見、コメントなどお待ちしています！