🔄 R653 拡張：プロンプトエンジニアリング を SSDSE-B-2026 実データで叩く

ここから先は、 プロンプトエンジニアリング（以下 PE）を 「LLM 出力を SSDSE-B-2026 の都道府県統計に対して正確に動かす」という具体課題で総ざらいする実践拡張パートです。 LLM が出す数字（人口・高齢化率・出生率など）には 幻覚が必ず混入するため、 PE の真価は「数値タスクの誤り率を計測し、 プロンプト変更で再現性のある改善を出せるか」に集約されます。

R653 では (1) 4 種類のプロンプトテンプレート（v1〜v4）を 47 都道府県データに当てて正答率と数値誤差を測る手順を示し、 (2) 箱ひげ図で誤差分布を読み、 (3) 表 + Python 4 ブロックで「テンプレ → 評価 → 改善」のループを再現可能にします。 注意：このパートに出てくる v1〜v4 の誤差・MAE・正答率・出典明記率・トークン数・unknown 率などは、 LLM を実際に呼んで測った値ではなく、 評価の流れを説明するための仮の値です。 実データは正解側の SSDSE-B-2026（2023 年度の総人口など）だけで、 Python ブロックの回答も乱数で作った架空の値です。 自分のプロンプトの性能は、 ② の評価器に実際の LLM の回答を入れて測ってください。

• 核となる問い：プロンプトのどこをどう変えると、 47 都道府県の人口推定誤差は何 % 縮むか？
• 計測軸：(a) 正答数 / 47, (b) 平均絶対誤差 MAE [千人], (c) 大都市バイアス（東京・神奈川での過大評価）, (d) 出典明記率
• 合格基準：v4 (CoT + 形式指定 + 出典強制) で MAE ≤ 200 千人かつ正答率 ≥ 80%

📊 箱ひげ図で「プロンプト差」を読む

PE の良し悪しを「感覚」ではなく「分布」で見ます。 箱ひげはテンプレ間のばらつき差を一度で可視化できます。 下の図は ③ のコードで描いた figures/pe_template_error_box.png で、 回答は実際の LLM ではなく乱数で作った架空の値です。

📊 評価基準のほうを実データで点検する：「年度違いの回答」は ±5% で見逃される

上の箱ひげは回答が架空なので、 プロンプトの良し悪しそのものは語れない。 一方で、 評価の物差しが何を見逃すかは、 正解側の SSDSE-B-2026 だけで確かめられる。 表 R653-A の v1・v2 の「代表的失敗」に挙げた年度の取り違えを例に、 正解は 2023 年度の値なのに、 回答が 5 年前の 2018 年度の値だった場合を実データで計算した（code/glossary_figs/prompt-engineering.py、 LLM は呼んでいない）。

図から読み取ること: 同じ「5 年前の値を答えた」という誤りが、 総人口の「±5% 以内なら正答」という基準では 47 県中 35 県で正答として数えられ、 高齢化率の「±0.5pt 以内」という基準では 45 県で誤答になる。 表 R653-C の「正答率」が上がったとき、 それが本当に正しい値に近づいた結果なのか、 基準が緩くて年度違いを通しているだけなのかは、 正答率だけでは区別できない。 年度の取り違えを検出したいなら、 許容幅を「年度が 1 つずれたときの変化」より狭くするか、 回答に年度を書かせて年度そのものを採点する。 人口のように年に 0〜1.5% しか変わらない量では、 ±5% の許容幅は年度の誤りに対してほとんど無力である。

📋 表 R653-A：4 テンプレートの設計表（SSDSE-B-2026 人口推定タスク）

『47 都道府県の 2023 年（SSDSE-B-2026 の最新年度）の人口を答えよ』というタスクを、 4 テンプレートで実行して同じ評価軸 (MAE / 正答率 / 出典明記率) で比較する。 v1 から v4 へ進むほど構造が増え、 LLM の自由度が下がる。

📋 表 R653-B：代表 10 県の誤差の例（説明用の仮の値）

SSDSE-B-2026 の人口実値（千人、 2023 年度）と、 各テンプレートの回答の誤差（回答 − 実値、 千人）。 実値の列だけが実データで、 v1〜v4 の誤差は LLM を呼んで測ったものではなく、 「大都市ほど絶対誤差が大きく、 v1 → v4 で縮む」 という典型的な形を示すための仮の値。

📋 表 R653-C：47 県全体の集計指標（説明用の仮の値）

この表は LLM を呼んで測った値ではなく、 読み方を示すための仮の値。 仮の値の上では、 v4 はトークン消費が 45 → 410 と約 9 倍に膨らむ代わりに正答率が 17% → 85% の 5 倍、 出典明記率が 0 → 98% になる、 という読み方をする。 実際にどこまで改善するかはモデル・時期・タスクで大きく変わるので、 ② の評価器に自分の回答を入れ、 同じ 4 指標を並べて確かめる。

📊 MAE（千人）は何を測っているか：一律 5% ずれた回答で分解する

表 R653-C の 1 行目の MAE は、 47 県の絶対誤差（千人）の単純平均である。 仮にどの県でも実値からちょうど 5% ずれた回答が返ってきたとすると、 MAE は 2023 年度の総人口の 5% の平均で 132.3 千人になる。 この 132.3 千人の内訳を、 誤差の大きい順に並べた。

図から読み取ること: MAE を下げる最短の方法は、 大都市の数値を当てることである。 東京都の誤差を 5% から 0% に直すだけで MAE は 15.0 千人（約 11%）下がるが、 鳥取県の誤差が 5% から 20% に悪化しても MAE は 1.7 千人しか増えない。 小さい県での劣化は、 MAE ではほとんど見えない。 県の大小を問わず同じ重みで採点したいなら、 相対誤差の平均（MAPE）や「±5% 以内の県の数」を MAE と並べて報告し、 どの物差しで改善したのかを明記する。 どれか 1 つの指標だけで v1〜v4 を比べると、 物差しの性質をプロンプトの性質と取り違える。

🐍 R653 Python ハンズオン（4 ブロック × 4 要素パターン）

① テンプレ生成器：v1〜v4 を関数で量産

このコードでやること：県名を 1 つ受け取り、 v1〜v4 の 4 種類のプロンプト文字列を返す関数 build_prompts(pref) を定義する。 後段の評価ループで使い回す。

📥 入力データ：SSDSE-B-2026 の県名（例：『東京都』『鳥取県』）。 ファイル data/raw/SSDSE-B-2026.csv の 都道府県 列から取得。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

def build_prompts(pref: str) -> dict:
    v1 = f"{pref}の人口は？"
    v2 = (
        "あなたは政府統計官です。 2023 年 10 月 1 日時点の値で答えてください。\n"
        f"質問: {pref}の総人口を千人単位で。"
    )
    v3 = (
        "例: 北海道=5092 / 鳥取県=537 / 沖縄県=1468 (単位: 千人, 2023/10/1)\n"
        f"同じ単位・同じ年度で {pref} の総人口を答えてください。"
    )
    v4 = (
        "あなたは SSDSE-B-2026 を参照できる統計官です。\n"
        "次の順で出力:\n"
        "1) 参照列名 (SSDSE-B-2026 の列)\n"
        "2) 数値 (千人, 2023/10/1)\n"
        "3) 桁チェック (1 万千人 = 1000 万人 であることを明示)\n"
        "4) 出典 (SSDSE-B-2026, 統計表番号)\n"
        f"対象: {pref}"
    )
    return {"v1": v1, "v2": v2, "v3": v3, "v4": v4}

print(build_prompts("鳥取県")["v4"])

📤 実行例：

💬 v4 だけが 桁チェック行を強制する。 これが「鳥取 537 と 5370 を取り違える幻覚」を抑える鍵で、 v1〜v3 にはない構造要素。

② 評価器：MAE / 正答率を 47 県で集計

このコードでやること：SSDSE-B-2026 の実値 df_true と、 各テンプレで得た予測値 preds を受け取り、 MAE と ±5% 正答率を計算する。 実 LLM 呼び出しは別途。

📥 入力データ：df_true: pd.DataFrame(columns=["都道府県","総人口"])（47 行）、 preds: dict[str, list[float]]（key=v1..v4, value=47 要素の予測値リスト）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

# ── この抜粋で使うデータを用意します（SSDSE-B の 47 都道府県・最新年度）──
import pandas as pd

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', header=1)
df = df[df['地域コード'].astype(str).str.match(r'^R\d{5}$', na=False)].copy()
df['年度'] = pd.to_numeric(df['年度'], errors='coerce')
df = df[df['年度'] == df['年度'].max()]
for _c in df.columns[3:]:
    df[_c] = pd.to_numeric(df[_c], errors='coerce')
df['高齢化率'] = df['65歳以上人口'] / df['総人口'] * 100

# 見本でよく使われる仮の列名を、実データから作っておく
df['income'] = df['消費支出（二人以上の世帯）']
df['population'] = df['総人口']
_region = {'北海道': '北海道', '青森県': '東北', '岩手県': '東北', '宮城県': '東北',
           '秋田県': '東北', '山形県': '東北', '福島県': '東北', '茨城県': '関東',
           '栃木県': '関東', '群馬県': '関東', '埼玉県': '関東', '千葉県': '関東',
           '東京都': '関東', '神奈川県': '関東'}
df['region'] = df['都道府県'].map(_region).fillna('その他')
df['地域'] = df['region']

import pandas as pd
import numpy as np

def evaluate(df_true: pd.DataFrame, preds: dict) -> pd.DataFrame:
    rows = []
    y = df_true["総人口"].to_numpy(dtype=float)
    for k, v in preds.items():
        yhat = np.asarray(v, dtype=float)
        err = yhat - y
        mae = np.mean(np.abs(err))
        sigma = np.std(err)
        within5 = np.mean(np.abs(err) / y <= 0.05)
        rows.append({"template": k, "MAE": round(mae,1),
                     "sigma": round(sigma,1),
                     "acc_within5pct": round(within5,3)})
    return pd.DataFrame(rows)

# df_true は答え合わせ用の正解表。上で読んだ df をそのまま使う。
df_true = df
_y = df_true["総人口"].to_numpy(dtype=float)
_rng = np.random.default_rng(0)
# preds は LLM の回答をパースした結果。ここでは<架空の>4 通りの回答を、
# 誤差の大きさを変えて作る（プロンプトの良し悪しを比べる練習台）。
preds = {f"v{_i+1}": _y * (1 + _rng.normal(0, _s, size=_y.size))
         for _i, _s in enumerate([0.20, 0.10, 0.05, 0.02])}
result = evaluate(df_true, preds)
print(result)

📤 実行例（実測。 preds は誤差 20%・10%・5%・2% の正規乱数で作った架空の回答、 seed=0）：

💬 MAE と σ の単位は「人」で、 v1 の MAE 437,972 人から v4 の 33,195 人まで、 作ったときの誤差率 20% → 2% にほぼ比例して縮む。 ±5% 以内の正答率は v4 で 47 県すべて（1.000）、 v3 では 0.617（29 県）。 v1 の σ が 105 万人と MAE の 2 倍以上あるのは、 誤差が人口に比例するため東京都 1 県の外れ（655 万人）が効いているからで、 σ・MAE は大きな県に引っ張られるので、 相対誤差の正答率と併せて読む。 実際の LLM の回答ではなく乱数で作った練習台なので、 この数字をプロンプトの性能として引用しない。

③ 可視化：誤差分布の箱ひげ

このコードでやること：v1〜v4 の絶対誤差を 1 枚の箱ひげで並べ、 中央値・IQR・外れ値を比較する。 図 R653-3 の生成相当。

📥 入力データ：errors_df: pd.DataFrame（行 47 × 列 v1..v4、 各セルは絶対誤差 [千人]）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

import os
os.makedirs('figures', exist_ok=True)  # 保存先のフォルダを作っておく

# ── この抜粋で使う誤差表を用意します ──
# 前のブロックと同じ<架空の>4 通りの回答から、県ごとの絶対誤差を作る。
import numpy as np
import pandas as pd
import matplotlib.pyplot as plt

_d = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=1)
_d = _d[_d['年度'] == _d['年度'].max()]
_y = _d['総人口'].to_numpy(dtype=float)
_rng = np.random.default_rng(0)
errors_df = pd.DataFrame({
    f'v{_i+1}': np.abs(_y * _rng.normal(0, _s, size=_y.size)) / 1000
    for _i, _s in enumerate([0.20, 0.10, 0.05, 0.02])})


fig, ax = plt.subplots(figsize=(8,5))
ax.boxplot([errors_df[c] for c in ["v1","v2","v3","v4"]])
# labels= は matplotlib 3.9 で tick_labels= に改名された。
# どの版でも動くよう、目盛りは後から付ける。
ax.set_xticks([1, 2, 3, 4])
ax.set_xticklabels(["v1 Zero", "v2 +Role", "v3 +Few", "v4 +CoT"])
ax.set_ylabel("|誤差| (千人)")
ax.set_title("テンプレート別 絶対誤差 (SSDSE-B-2026, 47 県)")
ax.grid(alpha=0.3, axis="y")
plt.tight_layout()
plt.savefig("figures/pe_template_error_box.png", dpi=140)
print("saved: figures/pe_template_error_box.png")

📤 実行例：

💬 絶対誤差の中央値は v1 128 千人・v2 116 千人・v3 63 千人・v4 17 千人と下がり、 v4 の箱（IQR 8.8〜38.6 千人）が最も低く狭い。 外れ値（◯）は v1 で東京都 6,550 千人・福岡県・大阪府、 v4 でも東京都・大阪府・兵庫県・千葉県に残る。 誤差を人口に比例する形で作っているので、 大きな県ほど絶対誤差が大きく出るのは当然で、 プロンプトの良し悪しとは切り分けて読む。 図は figures/pe_template_error_box.png に保存される。

④ プロンプト改善ループ：A/B 検定の最小骨格

このコードでやること：候補プロンプト 2 種類（旧 / 新）を同じ 47 県データに対して走らせ、 MAE の差が統計的に有意か scipy.stats.wilcoxon で検定する。

📥 入力データ：err_old, err_new: list[float]（47 県、 絶対誤差）。 上のループから取得。

1
2
3
4
5
6
7
8
9
10
11
12
13

from scipy.stats import wilcoxon
import numpy as np

err_old = errors_df["v3"].to_numpy()
err_new = errors_df["v4"].to_numpy()
stat, p = wilcoxon(err_old, err_new, alternative="greater")
print(f"old MAE = {np.mean(err_old):.1f}")
print(f"new MAE = {np.mean(err_new):.1f}")
print(f"Wilcoxon W = {stat:.1f}, p = {p:.4g}")
if p < 0.05:
    print("=> 新プロンプトの優位は統計的に有意 (片側 5%)")
else:
    print("=> 有意差なし、 サンプル増やすか別軸で検証")

📤 実行例：

💬 同じ 47 県で v3 と v4 の絶対誤差を対にして比べると、 平均は 112.4 千人 → 33.2 千人。 W = 1026 は 47 県の順位和の最大値 1,128 に近く、 ほとんどの県で v4 のほうが誤差が小さいことを示し、 片側 p = 4.2×10⁻⁸ となる。 alternative="greater" の片側検定なので、 判定文も「片側 5%」と書く。 ただし v3・v4 の誤差は乱数で作った架空の値で、 v4 を誤差 2%・v3 を 5% と決めて作った差を検定で確かめ直しているだけである。

⚠️ R653 追加の落とし穴 6 件（実数値タスク特有）

1. 単位の取り違え：『千人』『万人』『人』の混在は LLM が最も頻繁に外す。 v4 で『単位: 千人』を 2 回繰り返し明示すべし。 鳥取県の 537 千人を「537 万人」と返されると 10 倍、 誤差率 +900% になる。
2. 年度ずれ：SSDSE-B-2026 の最新年度は 2023 年（10 月 1 日時点）。 LLM の学習データに 2020 年国勢調査の値が多いと、 大阪府なら国勢調査の 8,838 千人と 2023 年の 8,763 千人のように 75 千人の年度ずれが混じる。 v4 で年月日を必ず固定。
3. Few-shot の引きずり：v3 で例として『鳥取=537』を入れると、 例にない島根（実値 650）を 『547』のように例の数字に近づけて答えることがある（数字は説明用の例）。 解決策は「例と桁が違う県を 1 つ混ぜる」（例：東京 14,086）。
4. 桁チェックの省略癖：v4 で『桁チェック行を出せ』と書いても、 トークン節約モデルが省略する。 system プロンプトで『省略禁止』を二重宣言。 監査では桁チェック行の存在率を測り、 下限（たとえば 98%）を決めておく。
5. 過信プロンプト：『絶対に正しい値で答えよ』と書くと、 LLM は確信度を上げるだけで精度は上がらない。 むしろ『不明なら "unknown" と返せ』を入れた方が幻覚が減りやすい。 その場合は unknown の件数も必ず一緒に報告する。
6. 温度設定の見落とし：temperature=0.7 のまま実験すると同じプロンプトでも県によって値が揺れ、 プロンプトの差と乱数の差が区別できない。 数値タスクは temperature=0 + seed 固定が前提。 PE 比較の手前で必ず固定する。

📝 R653 理解度チェック（6 問、 自己採点）

1. 表 R653-C の仮の値で v1 → v4 の MAE が 240 → 22 千人に縮んだとき、 もっとも寄与の大きい要素はどれか？ — (A) Role, (B) Few-shot, (C) CoT 桁チェック, (D) 出典強制 ／ 想定する正解：C。 絶対誤差の大きな外れは桁の取り違えから生じやすいので、 桁チェックが最も効くと考えるのが自然。 ただし表は仮の値なので、 実際にどの要素が効くかは 1 要素ずつ変えて測って確かめる。
2. 東京・神奈川・北海道で v4 でも誤差が残るのはなぜか？ — 正解：LLM の学習コーパスでは大都市が頻繁に登場し、 過去複数年の値が混ざって平均化されているため。 PE では消せず、 RAG（外部知識参照）が必要。
3. v3 の σ が v4 より小さいのに正答率は v4 が高い理由は？ — 正解：v3 は中央値が高めに揃って分散は小さいが偏りが残る。 v4 は中央値がほぼ 0 で僅かに外れ値が大きく出るが、 ±5% 内に入る件数は多い。 分散と精度は別軸。
4. 『絶対に正しく答えよ』というプロンプトはなぜ逆効果か？ — 正解：確信度が上がるだけで正解情報が増えるわけではない。 むしろ unknown 許容で幻覚率が減る。
5. temperature を 0 に固定する目的は？ — 正解：PE 改善の A/B 検定で差がプロンプト由来か温度ノイズかを区別するため。
6. Wilcoxon を使った理由は t 検定ではダメか？ — 正解：誤差分布が右に長い裾を持つため正規性が崩れる。 ノンパラのほうが頑健。 また 47 県は対応のある対なので符号付き順位検定が自然。

🗺 学習ロードマップ L1→L2→L3

📖 R653 ミニ用語辞書（12 項目）

❓ R653 追加 FAQ（実務でよく聞かれる 10 問）

1. Q. 業務でテンプレを 4 種類も維持するのは面倒。 1 個に絞れないか？
   A. タスクの数値性が低い（要約・分類・対話）なら v2 で十分。 SSDSE のような数値出力タスクは v4 が事実上の必須で、 v3 までに落とすと出典の明記が大きく減る（表 R653-C の仮の値では 98% → 26%）。 タスク種別ごとに 2 系統を持つ運用が現実解。
2. Q. v4 はトークン課金が 9 倍。 コスト的に厳しい場合は？
   A. 桁チェック行を残しつつ Few-shot 例を 3 → 1 件に削ると、 プロンプトのトークン数は大きく減る。 正答率がどれだけ落ちるかはタスクとモデル次第なので、 ② の評価器で v4 と削った版を並べて測り、 コストと精度の釣り合いで選ぶ。
3. Q. v4 で『unknown と返してよい』と書くと、 LLM が逃げて精度が下がるのでは？
   A. 逆になることが多い。 unknown を許すと、 答えた県だけの MAE は下がりやすい。 ただし全県に unknown と答えれば誤差 0 に見えてしまうので、 unknown と返した県の数も必ず併記して評価する。 分からないものを無理に答えない方が全体精度が上がるのは PE の鉄則。
4. Q. SSDSE-B-2026 を直接渡せば全部解決するのでは？ なぜ PE が必要？
   A. データ全量を context に貼ると 35 万トークン超でモデル上限を超える。 PE は「どの列を見るべきか」をモデルに正しく指示するインデックス役。 RAG（外部検索）と組み合わせる前提でも、 検索した断片をどう読ませるかは PE 設計次第。
5. Q. 同じプロンプトでも GPT-4 と Claude では結果が違う。 PE は再利用できる？
   A. 構造（CoT / 桁チェック / 出典強制）はモデル横断で効果が高いが、 細かい文言は再チューニング必須。 47 県評価器を CI に組み込み、 モデル切替時に MAE 退行を検知する運用が安全。
6. Q. 評価指標は MAE と正答率だけで十分か？
   A. 業務によっては出典明記率・最大誤差・桁誤りの数を追加すべき。 桁誤り 1 件は MAE では平均化されて見えにくい（鳥取県 537 → 5,370 で誤差 4,833 千人でも、 47 県の MAE には 4,833 ÷ 47 ≈ +103 千人しか効かない）。 最大誤差を別途モニタすべし。
7. Q. プロンプトを長くするほど良い？
   A. ある閾値で飽和し、 むしろ『遠い指示が無視される』現象（lost-in-the-middle）が出る。 v4 を超えて『役割 + 制約 + 例 + フォーマット + 否定例 + 監査基準』を全部盛りにすると、 正答率がかえって下がることがある。 短く強い指示が王道。
8. Q. system プロンプトと user プロンプトの違いは？
   A. system は会話全体に効く前提・人格・禁止事項、 user はその都度の質問。 桁チェック・出典強制のような横断ルールは system へ、 県名のような変数は user へ置くのが正しい分離。
9. Q. PE と Fine-tuning はどう使い分ける？
   A. データ更新頻度が高い（SSDSE は毎年更新）タスクは PE + RAG。 ドメイン語彙が独特で量が多い（医療診断書など）は FT。 47 県のような更新あり・量少なめは PE のスイートスポット。
10. Q. PE 改善の最初の一歩は何をすべき？
    A. ① 47 サンプルの正解データを CSV で作る、 ② v1 で MAE を計測しベースラインを保存、 ③ 1 要素だけ変えた v2 を作って Wilcoxon で差を見る。 これを 4 回繰り返せば v4 相当に到達する。 闇雲な書き換えは禁物。

✅ R653 査読チェックリスト（プロンプト提出前 20 項目）

1. 役割 (Role) を 1 文で明示しているか
2. 対象タスクの入力形式を例示しているか
3. 出力フォーマットを JSON / Markdown 等で明示しているか
4. 単位（千人・万人・人・%）を 2 箇所以上で固定しているか
5. 年月日（2023/10/1 等）を固定しているか
6. 桁チェック行を強制しているか
7. 『不明なら unknown』を許容しているか
8. Few-shot を入れる場合、桁が異なる例を 1 つは含めたか
9. system プロンプトで禁止事項（推測禁止・幻覚禁止）を宣言したか
10. temperature を 0 に固定したか
11. seed（または乱数固定）を設定したか
12. 出力に出典 (SSDSE-B-2026 等) を明記させているか
13. 47 県（または全件）に対する評価データセットがあるか
14. MAE / 正答率 / 出典明記率の 3 指標を CSV に出力するか
15. 変更時に Wilcoxon 検定が回るか
16. 過去ベスト v* のプロンプト全文を git に保存したか
17. モデル名 / バージョン / 日時を実行ログに残しているか
18. 失敗例（最大誤差ワースト 3）を一覧化したか
19. レビュー担当者が同条件で再実行できる手順書があるか
20. 本番投入後の監視指標（MAE 上限・出典明記率下限）を定めたか

🚫 R653 アンチパターン集 ── 業務で見かける『悪い PE』5 連

実プロジェクトで頻発する『悪化させる PE』を 5 つに整理しました。 良いプロンプトの裏返しとして、 何を避けるべきかを言語化しておくことが新人 PE 担当の最短学習路です。

1. 禁忌の長文化：『精度を上げたい』と思って役割・制約・例・否定例・監査基準を全部盛り込み、 プロンプトが 2,000 トークン超に。 LLM は中盤の指示を忘れ（lost-in-the-middle）、 正答率がむしろ低下。 短く強い指示が原則。
2. 命令だけで例示なし：『JSON で返せ』と書いても LLM はキー名を勝手に作る。 必ず {"prefecture":"東京", "population":14086, "year":2023} の具体例 1 つを貼る。 例示が無いと、 キー名や数値の型が回答ごとに揺れやすい。
3. 禁止語の山積み：『憶測しない、 創作しない、 不正確な数字を避ける』と否定形を 5 個以上並べると LLM は防御的になり、 ほとんど『unknown』ばかり返す。 禁止は 2 個まで、 残りは肯定形に置換すべし。
4. 役割の演技指示：『あなたは天才統計学者になりきって…』のような演技指示は、 LLM の文体は変えるが数値精度には寄与しない。 業務 PE では『あなたは SSDSE-B-2026 を参照できる統計官』のように能力と情報源だけを指定するのが筋。
5. プロンプト変更とモデル変更の同時実行：『新プロンプトと新モデルを同時に試す』と、 改善が PE 由来かモデル由来か判別不能。 必ず『片方ずつ』動かす。 同時変更は A/B 検定として無効。

これらは「やってはいけない」の集合ですが、 裏返すと 『短く / 例示あり / 肯定形 / 能力指定 / 一変数ずつ』という PE 設計の 5 原則になります。 R653 の v4 はこの 5 原則を満たすように設計したテンプレートです（表 R653-C の MAE 22・正答率 85%・出典明記率 98% は説明用の仮の値で、 実際の達成度は自分の評価データで測って確かめます）。

📝 R653 まとめ

プロンプトエンジニアリングは『何となく書き換えて感触で判断する』段階から、 『47 都道府県の SSDSE 実値で MAE と正答率を回し、 Wilcoxon で有意性を判定する』段階へ移ることで初めて実務品質に到達します。 R653 で示した 4 段階テンプレ・箱ひげ図・表・4 Python ブロックは、 そのまま自分のチームの数値タスクに横転できる骨格です。 PE は「黒魔術」ではなく 「測定可能なエンジニアリング」であることを忘れないでください。

特に SSDSE-B-2026 のような公的統計を扱う場面では、 『どの列を、 いつの値で、 どの単位で、 どの出典から』という 4 点を毎回プロンプトに明示すると、 年度や単位の取り違えによる誤答を減らしやすい（どれだけ減るかは評価データで確かめる）。 本ページの v4 テンプレートはその 4 点を強制する最小実装であり、 議会説明資料・自治体ダッシュボード・学術論文の下書きなど、 数値の正確性が求められるあらゆる文書生成タスクの共通骨格として機能します。

最後に R653 の3 つの行動指針を要約します。 (1) 必ず 47 サンプル以上の評価データセットを持つ（小さくても定量化が命）、 (2) 変更は 1 要素ずつ、 Wilcoxon で有意性確認（同時変更は A/B として無効）、 (3) 本番投入後も MAE と出典明記率を CI で監視（SSDSE 改訂時の沈黙的退行を検出）。 この 3 つを守れば、 PE は属人芸ではなくチームの再現可能な技術資産になります。

補足として、 ここで示した v1〜v4 の構造は『公的統計データを LLM に正しく答えさせる』という具体目標に最適化したものですが、 同じ枠組み（役割固定・年度固定・桁チェック・出典強制・unknown 許容・temperature=0・Wilcoxon 検定）は、 医療文献の用量確認、 法律条文の引用、 製品仕様の数値抽出、 金融商品の利率説明など、 数値正確性が求められる多くのドメインに横展開できます。 SSDSE-B-2026 のような 47 サンプル規模の評価セットを各ドメインで用意すれば、 同じ改善ループが回せます。 これが R653 のもっとも持ち帰るべきメッセージで、 個別技法ではなく『数値タスクを PE で攻めるための統一プロトコル』を学んだと位置づけてください。 本ページの拡張ブロックを自分のチームの共有ドキュメントとして再利用し、 各ドメイン固有の評価データセットを差し替えていけば、 短期間で実務水準の PE 基盤を立ち上げられるはずです。 統一プロトコルを共有資産化することで、 担当者交代やモデル更新があっても再現性のある精度改善ループを回し続けられます。

🧮 数式に値を入れて手で計算する: プロンプト工夫による精度差

合成データでプロンプト戦略別精度を比較する。

Step 1: 戦略別

Step 2: 改善幅

🐍 Python で再現

1
2
3
4
5

import numpy as np
acc = np.array([0.45, 0.68, 0.75, 0.82])
diff = np.diff(acc)
print(f"段階改善: {diff}")
print(f"総改善: {acc[-1] - acc[0]:.2f}")

📤 実行結果

💬 手計算 (Step 2) +0.37 と Python 出力が完全一致。

🔗 隣接手法への橋渡し (補足)

プロンプトエンジニアリングは、 SSDSE-B-2026 のような実数値データを LLM で扱う場面で隣接領域との連携が不可欠になる。

• 上流 (入力整形): CSV / Markdown 表 への変換、 トークン化 / 埋め込み後の長さ確認 (47 行 × 100 列 ≒ 4-5k token)。 列名・単位 (千人/百万円) を先頭に固定。
• 並列 (代替手段): RAG で SSDSE 公式 PDF を引かせる / ファインチューニング で挙動を固定 / Function Calling で pandas を呼ぶ。 prompt 工夫より速い解決策を見極める。
• 下流 (検証): 出力を `json.loads` でパースして ハルシネーション (47 県以外の出現) を弾く。 LLM-as-judge で「人口の比較が正しいか」を 2 モデル合議で評価。

SSDSE-B-2026 で「47 県 TOP5 を JSON で」のような prompt を組む場合、 上流の表整形・下流の JSON 検証まで含めて 1 パイプラインで設計するのが現代の標準。

🌳 手法選択フロー (補足)

プロンプトエンジニアリングを採用するか、 別手段に切り替えるかは、 タスクの性質と運用制約で決まる。

1. Step 1: 出力が「形式遵守」中心か「知識正確性」中心か?
   • 形式遵守 (JSON / 表 / 箇条書きの整形) → JSON Schema + Few-shot 例 2-3 件で prompt 設計
   • 知識正確性 (SSDSE の最新値・固有名詞) → RAG で公式データを注入 + prompt は検索結果を要約する役割に
2. Step 2: 訓練データ量と再現性要件は?
   • 例 5 件以内・即時試したい → Few-shot prompt で 5 分で着手
   • 例 1000 件以上 + 挙動を恒久固定したい → ファインチューニング へ切替
   • 計算・集計が必須 → Function Calling で pandas / scipy を呼ぶ (prompt だけで人口合計を計算させない)
3. Step 3: 評価と継続改善は?
   • 評価データ 20-50 件で形式遵守率・正確率を計測 (本ページ Step 1-3 の二項検定)
   • 失敗例を Few-shot に追加 → 再評価のループを回す (prompt の A/B テスト)
   • temperature=0 で集計、 temperature=0.7 でアイデア出しと用途別に固定

SSDSE-B-2026 の集計タスクなら、 まず prompt + Few-shot で着手 → 失敗例を解析 → JSON Schema 強制 or Function Calling 切替、 の順に進めると、 どこで詰まったかを切り分けながらパイプラインを組める。

🔖 キーワード索引 (補足)

「prompt engineering」は LLM 活用の中核技術として、 統計データ分析の現場でも利用が広がっている。 SSDSE-B-2026 の都道府県集計を LLM に依頼する場面で、 役割指定・出力フォーマット制約・Few-shot 例の与え方を変えるだけで結果の正確さが大きく変わる。 本セクションでは関連用語をチップで再掲する。

これらは prompt engineering の構成要素であり、 47 都道府県 × 100 列の集計依頼を「再現可能」にする鍵となる。

🎨 直感で掴む

プロンプトエンジニアリングは「LLM への指示書を磨くことで出力品質を引き上げる」工夫の集合。 SSDSE-B-2026 の人口データを LLM に渡す場合、 「列名・行数・型・期待出力形式・例 2 件」を含むプロンプトと、 「分析して」だけのプロンプトでは、 同じモデルでも出力の正確性が大きく変わる。

📐 数式または定義

prompt engineering は、 タスク評価関数 $\mathcal{L}$ を最大化する prompt $\hat{x}_{\text{prompt}}$ を探索する離散最適化問題として定式化できる：

$$ \hat{x}_{\text{prompt}} = \arg\max_{x_{\text{prompt}} \in \mathcal{X}}\ \mathbb{E}_{(q,y^*) \sim \mathcal{D}}\Big[ \mathcal{L}\big(\text{LLM}_\theta(x_{\text{prompt}} \oplus q),\ y^* \big) \Big] $$

ここで $\mathcal{D}$ は評価セット (例: SSDSE-B-2026 由来の Q&A 100 件)、 $q$ はユーザ入力、 $y^*$ は正解、 $\mathcal{L}$ は精度・BLEU・LLM-as-Judge スコアなど、 $\oplus$ はトークン列の連結を表す。 モデル重み $\theta$ は固定で、 prompt 空間 $\mathcal{X}$ 上で離散探索する点が fine-tuning との本質的違い。 自動化手法 (APE, OPRO, EvoPrompt) は LLM 自身に prompt 改善案を生成させ、 評価セットでスコアリングして反復する。

🔬 数式を言葉で読み解く

上の最適化式の各記号を、 prompt engineering の現場で何を意味するかに翻訳する。

• $x_{\text{prompt}}$ — 設計者が書く prompt 文字列。 System 指示 + Few-shot 例 + フォーマット指示の組み合わせ。
• $\mathcal{X}$ — 可能な prompt 全体の空間。 自然言語なので組合せ爆発で、 厳密最適化は不可能。 人手 or LLM ベースのヒューリスティックで探索する。
• $\mathcal{D}$ — 評価データセット。 SSDSE-B-2026 由来の「47 都道府県の人口上位 5 を Markdown 表で」のような Q&A 集合。
• $\mathcal{L}$ — タスク評価関数。 形式遵守率・正答率・コスト・レイテンシなど複数指標の重み付け和になることが多い。
• $\text{LLM}_\theta$ — 事前学習済み LLM (GPT-4o・Claude など)。 $\theta$ は固定。 prompt engineering は $\theta$ には触れない。
• $\oplus$ — トークン列連結。 prompt の前半 (System + Few-shot) と末尾 (User の質問 $q$) を結合し、 一つの入力にする。

「重みを学習する」のではなく「prompt を探索する」という発想転換が prompt engineering の本質。 fine-tuning と異なり、 ラベル付きデータが少量でも適用でき、 即座に挙動を変えられる柔軟性が利点。

🧮 実値で計算してみる

プロンプトの良し悪しを「指示遵守率 (instruction following rate)」という単一指標で定量化する。 SSDSE-B-2026 の都道府県人口データを LLM に渡し、 「JSON 形式で人口上位 5 県を返す」というタスクを 3 種類のプロンプト (素の指示 / Few-shot 例つき / JSON Schema 指定) で 20 回ずつ実行し、 形式遵守率を比較する。 下の成功数 11/20・17/20・20/20 は LLM を実際に呼んだ結果ではなく、 計算手順を示すための説明用の仮の値。

使用データ: SSDSE-B-2026 の A1101 (総人口) 列。 各プロンプトで N=20 回の試行、 出力が JSON.parse 可能かを 0/1 で評価。

素の指示から JSON Schema 指定までで遵守率が 0.55 → 1.00 に上昇。 プロンプトエンジニアリングの効果がこの 0.45 という数値に表れる。 Few-shot 例だけでも 0.85 まで上がる点に注目。

🐍 Python 実装

上記 Step 1-3 の指示遵守率を Python で再現する。 LLM API 呼び出しは省略し、 説明用の仮の値 (11/20, 17/20, 20/20) を pandas で集計して 95% 信頼区間まで計算する。

🎯 このコードでやること: 3 種類のプロンプトの遵守率を二項分布で評価し、 Wilson 信頼区間で「Few-shot 効果」が有意かどうかを判定する。

📥 入力データ: 各プロンプトの試行結果 (1=JSON parse 成功 / 0=失敗) の配列。

1
2
3
4
5
6
7
8
9
10

import numpy as np
from statsmodels.stats.proportion import proportion_confint, proportions_ztest
results = {'A_bare': 11, 'B_fewshot': 17, 'C_schema': 20}
for name, succ in results.items():
    lo, hi = proportion_confint(succ, 20, method='wilson')
    print(f'{name}: 遵守率={succ/20:.2f} 95%CI=[{lo:.2f}, {hi:.2f}]')
stat, pval = proportions_ztest([11, 17], [20, 20])
print(f'A vs B: z={stat:.2f}, p={pval:.3f}')

📤 実行結果:

💬 結果の読み方: 素のプロンプト 11/20 から Few-shot 追加の 17/20 へ、 2 標本比率の z 検定で z=−2.07、 p=0.038 と 5% 水準で有意に改善。 ただし A の 95% 区間 [0.34, 0.74] と B の [0.64, 0.95] は重なっており、 各 20 回では差の推定幅がまだ広い。 さらに JSON Schema を明示すると 20/20 で失敗ゼロ。 プロンプトエンジニアリングの「効果」が二項検定で定量化できることを示している。

⚠ 落とし穴

• 曖昧な出力形式指定: 「結果を表で」だけだと、 ある時は Markdown、 ある時は HTML、 ある時は CSV と毎回バラバラ。 対策: JSON Schema や CSV 列名を明示し、 OpenAI Structured Outputs / Anthropic Tool Use で形式を強制する。
• 暗黙の前提共有不足: 「人口」と書くだけだと住民基本台帳 vs 国勢調査 vs 推計人口のどれか LLM が勝手に判断。 対策: SSDSE-B-2026 の列名と単位 (千人/年) をプロンプト先頭に明記する。
• Few-shot 例のリーク: 例に「東京 1396 万」を入れたまま「東京の人口は?」と質問すると、 LLM はモデルの知識ではなく例文をコピーして返す。 対策: 評価用と例用のデータを完全に分離。
• 温度 (temperature) の取り違え: 集計タスクで temperature=1.0 のままにすると毎回数値が変動。 対策: 集計・要約は temperature=0、 アイデア出しは 0.7-1.0 と用途で分ける。
• 幻覚 (hallucination) を「もっと丁寧に書けば消える」と誤信: 47 都道府県以外の存在しない県を生成する問題は、 プロンプト改善ではなく RAG・関数呼び出しで実データに接地する以外に根本解決はない。

🌐 関連手法・派生

LLM への入力プロンプトを設計・改善し、 望ましい出力 (分類精度・形式遵守・幻覚抑制) を引き出す技術。 SSDSE-B-2026 のような都道府県データを LLM に投入する際、 「47 行の CSV を提示 → 上位 5 県を要約」のような構造化プロンプトが代表例。

上位概念・前段・派生・競合の位置関係

主要 LLM 制御手法の比較 (47 都道府県 CSV を要約する想定)

SSDSE 級の数値データなら、 「列名・行数・型を明示 → JSON で出力指定」が安定するプロンプト設計の基本。

🔗 関連用語

プロンプトエンジニアリングを学ぶ際に併読すると理解が深まる関連用語を「前提・並列・発展」の 3 区分で整理する。

• 前提概念: 大規模言語モデル (LLM) の動作原理 (トークナイザ / 自己回帰生成 / コンテキスト長) と In-context Learning。 JSON Schema / 正規表現など出力形式の表現手段、 そして生成 AI 全般の基礎。
• 並列概念: ファインチューニング (重み更新で挙動を変える) / RAG (外部知識を渡す) / Function Calling (ツール呼び出し) — いずれも LLM 出力を制御する別アプローチ。 プロンプト工夫で済むか、 別手段が必要かを切り分ける判断軸。
• 発展概念: Chain-of-Thought / ReAct / Tree-of-Thought / Self-Consistency / Reflexion — 推論過程を明示・分岐・自己反省させる発展技法。 単発プロンプトからエージェント的なマルチステップ推論へと拡張する。

プロンプト工夫だけで解決できない問題 (幻覚、 知識の鮮度、 計算精度) には RAG や Function Calling と組み合わせるのが現代の定石。 prompt engineering を中核に、 周辺技術を組み合わせる視点で学ぶと応用範囲が広がる。

📚 関連グループ教材

プロンプトエンジニアリングは「大規模言語モデルを使う」教材群の中で、 モデルの重みに触れずに出力を変える技術にあたる。 先に LLM（トークンを 1 つずつ生成する仕組みとコンテキスト長）と プロンプト（入力文そのもの）を押さえ、 同じ目的の別手段として RAG（外部の文書を検索して渡す）と ファインチューニング（重みを追加学習する）を並べて読むと、 「書き方の工夫で済む問題」と「知識や重みを変えないと済まない問題」の境目が見える。 生成物の誤りについては ハルシネーション、 生成 AI 全体の位置づけは 生成 AI で扱う。 このページの R653 の節で見たように、 数値を答えさせる用途では、 プロンプトの工夫より「計算は Python に任せ、 LLM には手順と説明だけを書かせる」設計のほうが確実なことが多い。

🗺 概念マップ

プロンプトエンジニアリング を中心に、 関連する概念・上位カテゴリ・応用領域を放射状に配置した。

プロンプトエンジニアリングを中心に、 (a) 上位として In-context Learning と LLM 制御技術、 (b) 並列としてファインチューニングと RAG、 (c) 派生として CoT / ReAct / Self-Consistency、 (d) 前段として Few-shot 例選定と JSON Schema 定義、 (e) 後段として出力検証と LLM-as-judge 評価、 (f) 応用として SSDSE-B-2026 47 県の要約・TOP5 抽出・仮説生成、 を配置した。

プロンプトエンジニアリング は単体で覚えるより、 SSDSE-B-2026 のような実データに対して「前処理 → 適用 → 検証」の流れに組み込んで運用できるようにすることが重要。

🔗 隣接手法への橋渡し

「prompt engineering」を中心に、 隣接する手法・概念との関係を以下に整理する。 単独の手法理解にとどまらず、 分析パイプライン全体での位置付けを把握することで、 適切な前段・後段・代替手法を選べる。

プロンプトエンジニアリングは単体のテクニックではなく、 「タスク分解 → Few-shot 例設計 → 出力形式制約 → 生成 → 検証」のパイプラインで運用する技術。 SSDSE-B-2026 の都道府県データを要約・分類するなど実用タスクで、 prompt の各要素を A/B 比較しながら最適化していくのが定石。

🌳 手法選択フロー

「prompt engineering」を含む手法選択は、 データの性質・分析目的・運用制約の 3 軸で決まる。 以下に典型シナリオと対応する手法の組合せを示す。

典型シナリオ別の手法選択

選んだ後の検証ステップ

1. プロンプト構造確認: 役割指示 / Few-shot 例 / 出力形式制約 / 制約条件 が漏れなく書かれているか
2. パラメータ調整: temperature / top_p / max_tokens を タスク (要約は低温度、 創作は高温度) に合わせて調整
3. 出力品質評価: 形式遵守率 (JSON Schema validate) / ハルシネーション率 / 指示追従率 を複数プロンプトで比較
4. 頑健性チェック: 同一プロンプトで 5-10 回生成し、 出力のばらつき (BLEU / Embedding 類似度) を測定
5. 解釈: LLM-as-judge や人手評価で、 SSDSE-B-2026 要約タスクなど実タスクで意図通りに動いているか検討

🧭 解説の深化：LLM に「数を数えさせるな」── 数値トークン化の壁と〈生成/計算の分離〉（追記）

LLM のページは「同じ入力でも答えがぶれる非決定性」を、 ハルシネーションのページは「出てきた数値を異常値検出の目で事後に疑う」を扱う。 ここでは第三の軸 ── そもそもプロンプトで四則演算を直接させると、 温度を 0 に下げても消えない「能力側」の誤りが出る、 という問題を SSDSE-B-2026 の実測値で示します。

🎨 直感

LLM は電卓ではなく 「次に来そうな文字列を確率で選ぶ機械」です。 しかも入力の数字は 1 桁ずつではなく、 トークナイザ都合で 1408／6000 のような意味のない塊に切られます。 人間なら筆算で桁を縦に揃えて繰り上がりを追えますが、 モデルは桁の位置を保証されないまま「それらしい続き」を生成するだけ。 だから「14086000 + 9229000 は？」と直接聞くのは、 電卓の代わりに作文の得意な人に暗算させるようなものです。 短い計算はたまたま当たりますが、 桁が多い・似た値が並ぶ・行数が増える、 の 3 条件が重なると急に外します。

⚠️ 落とし穴（重要）

統計コンペで一番やりがちなのが「CSV を丸ごと貼って合計・平均・順位を日本語で尋ねる」ことです。 モデルは自信満々に、しかし微妙にズレた数を返します。 これは非決定性（seed を固定すれば消える）とは別物で、 温度 0・同一 seed でも安定して間違えるのが厄介な点です。 下は SSDSE-B-2026 の A1101（総人口, 2023年）上位県を、 Python で正しく足した実測値です。

対策は 3 つ。 ①「計算するな、計算するコードを書け」と指示し、実行は自分（か Function Calling / コードインタプリタ）で行う。 ②プロンプトに実在の列名（A1101 等）と encoding='cp932'・skiprows=[1] を明記し、幻の列名を防ぐ。 ③検算プロンプト「上の値を df['A1101'].sum() で再計算し、一致しなければ差分を報告して」を必ず添える。

🚀 発展

• 温度では直らない：算術ミスはサンプリングの問題ではなく能力の問題。 temperature=0 でも安定して外すので、 「seed を固定して再現」しても正しくはなりません（再現性 ≠ 正確性）。
• 生成/計算の分離：Function Calling・コードインタプリタで pandas/numpy を呼び、 モデルにはコードと解釈だけを担当させる。 数値の確定は決定的な実行環境に委ねます。
• self-consistency＋検算：同じ集計を「日本語で暗算」「コードで計算」の 2 経路で出させ、 一致しなければ棄却。 一致検査自体をプロンプトの最終ステップに組み込みます。
• トークン長にも注意：47 行 × 112 列を丸ごと貼ると数千トークンになり、 長文中央の情報が薄まる（＝集計対象の取りこぼし）。 必要列だけ df[['Prefecture','A1101']] に絞って渡すのが安全です。

🔗 関連ページ

プロンプト（指示の設計そのもの）／ LLM（非決定性・再現性の軸）／ ハルシネーション（出力を事後に疑う軸）／ CSV（列名・エンコーディングの正確な受け渡し）／ 埋め込み / トークン化（数字がどう切られるか）。 関連して Function Calling / ツール使用・再現性は本用語集内に個別ページが未整備のため、 上記各ページの該当節を参照してください。