第一幕：SLM パイプラインのその後 — 品質を「重要度」で測る
この記事について
AI 対話ログと実験記録をもとに Claude Code が下書きを作成し、私が加筆修正しました。
本記事の内容は、個人開発プロジェクトで運用中の SLM パイプラインに対する品質評価の記録であり、一般的な LLM 評価手法の提示を意図するものではありません。
第二部では、ローカル SLM で対話ログを要約するパイプラインを構築した。動機から始まり、前処理、チャンク分割、カテゴリ設計、測定と収束、そして GroupReduce まで。6つの幕を経て、パイプラインは「動く」状態になった。
しかし、「動く」と「品質が安定する」は違う。
「項目数が多い = 品質が低い」と結論づけていた。
だが本当にそうだろうか？
この第五部では、パイプラインを運用し続ける中で見えてきた品質評価と再現性の課題を扱う。今回はその第一幕として、評価の軸そのものを作り直した話。
はじめに
やること
- 旧評価（項目数倍率）の限界を整理する
- 新しい評価フレームワーク eval-kit2 の設計を共有する
- 487B のシンプルなプロンプトと 3,789B の詳細プロンプトの比較実験を報告する
- SLM の非決定性が品質に与える影響を、重要度の観点で分析する
やらないこと
- LLM/SLM の評価手法に関する網羅的なサーベイ
- 他モデルとの性能比較
- eval-kit2 のコード公開や利用手順の解説
旧評価の限界 — 「6.4 倍多い」の先が見えない
私の SLM パイプラインでは、AI 対話ログの要約をカテゴリ別に抽出している。YATTAKOTO（やったこと）、WAKATTAKOTO（分かったこと）、DECISION（決定事項）など、カテゴリごとにプロンプトを用意し、qwen2.5:14b に投げる。
旧評価フレームワーク（eval-kit）の仕組みはこうだった。
- 同じ対話ログを Claude Opus（T4 = Tier 4、最上位モデル）に処理させ、出力を「正解」とする
- SLM の出力項目数と T4 の出力項目数を比較し、倍率を測る
- 倍率が 1.0 に近いほど良い
結果は 6.4x〜8.3x。SLM は T4 の 6〜8 倍の項目を出力していた。情報カバレッジは 85〜90% ある。つまり T4 が拾った情報はほぼ含んでいるが、重複排除と抽象化が弱く、大量の冗長項目が混ざっている。
問題は、この評価では次の一手が見えないことだった。
- 「多すぎる」とは分かる。しかし何が余計なのか？
- 本当に重要な情報はカバーできているのか？
- プロンプトを変えたとき、改善されたのか悪化したのかの判断基準がない
「項目数の比率」は、品質の代理指標としては粗すぎた。
eval-kit2 の設計 — 5段階の重要度で測る
eval-kit2 では、評価の軸を「項目の数」から「重要項目のカバー率」に変えた。
Ground Truth の作り方
Claude Opus に対話ログを読ませ、要約として「必ず拾うべき項目」のリストを作らせる。ここまでは旧 eval-kit と同じだ。
ただし前提として、この Ground Truth 自体が完全ではない。T4（Claude Opus）も非決定的であり、重要度のラベル付けも T4 の判断に依存している。今回は「実用上の参照点」として T4 を採用した。絶対正解ではなく、運用上の基準線という位置づけだ。
違いは、各項目に5段階の重要度を付与する点にある。
| レベル | 意味 | 例 |
|---|---|---|
| Lv1 | 必須 — これがないとサマリの意味がない | 「AES-256-CBC + PBKDF2 で暗号化を実装」 |
| Lv2 | 重要 — 主要な成果・決定事項 | 「next.md をクリアした」 |
| Lv3 | 有用 — 技術的知見、背景情報 | 「GZip 圧縮率が想定より低かった」 |
| Lv4 | 補足 — あれば良い | 「ファイル名を変更した」 |
| Lv5 | 不要 — ノイズ | 「cd コマンドで移動した」 |
合格基準
Lv1-2 のカバー率 100% を合格基準とした。
Lv3 以下は拾えていなくてもよい。Lv1-2 さえ全てカバーされていれば、そのサマリは「重要な情報を漏らしていない」と判断する。
旧 eval-kit が「全体の量」を測っていたのに対し、eval-kit2 は「外してはいけないものを外していないか」を測る。「理論的に完璧な出力」ではなく「運用上、致命傷がない出力」を基準にしている。
なお、今回の検証は対話ログ 2 本（操作系 1 本、技術解析系 1 本）に対してそれぞれ 2〜3 回の実行で行った。大規模な統計検証ではなく、パイプライン運用者としての実感を数値で裏付ける規模だ。
SIMPLE 実験 — 487B で 3,789B に並ぶ
eval-kit2 を使って、ひとつの実験をした。
カテゴリ別の詳細プロンプト（YATTAKOTO）は 3,789B ある。役割定義、出力形式、バリデーションルール、抽出観点が細かく記述されている。
対して、カテゴリ固有の指示を極限まで削ぎ落とした「SIMPLE」プロンプトを作り、どこまで戦えるかを試した。
v1: 「要約して」だけ
カテゴリ固有の指示なし。共通部分（役割定義と出力形式）のみ。
結果: Lv1-2 カバー率 22%。話にならない。
SLM は「要約して」と言われても、何を拾うべきか分からない。チャンク分割で入力は適切なサイズに切ってあるのに、出力は漠然とした概要にしかならなかった。
v2: 「数値・決定・発見にも注目」を追加
カテゴリ固有の指示を 2 行追加した。「数値や具体的な値が出てきた場合は記載してください」「決定事項やアイデアも含めてください」。
結果: 質は向上した。具体的な数値（「1,187 行」など）が出力に含まれるようになった。しかし項目数自体は増えず、Lv1-2 カバー率は大きく改善しなかった。
v3: 「永続オブジェクトの変更点」を追加
さらに 2 行追加。「ファイル操作など永続オブジェクトの変更点も含めてください」「作業の完了状態が分かる情報を残してください」。
結果: Lv1-2 カバー率 5/5 = 100%。完全カバー達成。
合計 4 行、487B。YATTAKOTO の 3,789B に対して約 1/8 のサイズで、同等以上のカバレッジが出た。
ただし万能ではない
別のテスト対話ログ（暗号実装のセキュリティ検証セッション）では様相が異なった。
- SIMPLE: 「暗号化を実装した」とは書くが、「AES-256-CBC + PBKDF2 + GZip」という具体的な方式名を落とす
- YATTAKOTO: 具体的な技術名を拾える
対話ログの性質によって得意不得意がある。
- 操作系ログ（ファイル整理、タスク管理）: SIMPLE が有利。Lv1-2 カバー率 100% vs YATTAKOTO 80%
- 技術解析ログ（暗号実装、アルゴリズム設計）: YATTAKOTO が有利。具体名を落とさない
プロンプトの長さではなく、「何を拾うかの指示がどれだけ明確か」が品質を決めている。短くても的確な指示があれば十分で、長くても焦点がぼやけていれば SLM は迷う。
ただし、これは「長いプロンプトが不要」という意味ではない。SIMPLE が強いのは、抽出の軸が限定されている場合だ。汎用的なカテゴリ設計や、将来の拡張を見据えた場合には、詳細プロンプトの構造が意味を持つ。今回の発見は「短いプロンプトでも戦える局面がある」であって、「長いプロンプトを捨てろ」ではない。
非決定性の正体 — ブレるのは Lv3 以下だけ
eval-kit2 を構築する過程で、SLM の非決定性について発見があった。
同一プロンプト・同一入力で 2 回実行したところ、出力が 4 項目と 7 項目で大きくブレた。項目数だけ見れば、再現性がないように見える。
しかし eval-kit2 の重要度で分析すると、景色が変わる。
- Lv1 の項目: 2 回とも全て出力されている。安定
- Lv2 の項目: 2 回とも全て出力されている。安定
- Lv3 の項目: 片方にだけ含まれるケースがある。ここがブレの本体
- Lv4-5 の項目: 出たり出なかったり
つまり、SLM の非決定性は品質に致命的な影響を与えていなかった。ブレているのは「あれば良いが、なくても困らない」レベルの情報だけだ。
旧 eval-kit では「4 項目 vs 7 項目」を見て「再現性が低い」と結論づけていたかもしれない。eval-kit2 では「重要な情報は安定して拾えている。ブレは許容範囲内」と判断できる。
temperature 未指定（ollama のデフォルトは 0.8）が非決定性の原因のひとつだ。temperature=0 に固定すれば出力は安定するが、それは次回で扱う。
まとめ
この記事では、SLM の出力品質を「項目数の倍率」から「重要度付きカバー率」に変えた eval-kit2 の設計と、そこから見えた知見を報告した。
- 評価軸の転換: 「量」から「重要度」へ。Lv1-2 カバー率 100% を合格基準にすることで、「何が足りないか」が見えるようになった
- プロンプトの本質: 3,789B の詳細プロンプトと 487B のシンプルプロンプトが同等のカバレッジを出せる場合がある。長さではなく「何を拾うか」の明確さが効く
- 非決定性の許容: SLM の出力ブレは Lv3 以下に限定される。重要な情報は安定している。評価軸を変えることで、非決定性の「深刻さ」を正しく測れるようになった
この先に残った課題
非決定性は「許容できる」と分かった。しかしプロンプトの改善効果を正確に測るには、そもそも出力が毎回変わっては困る。次回は、3台の Mac で SLM の出力を安定させるために何をしたかを報告する。
上演目録（docs × AI による開発記録）
※本シリーズでは、試行錯誤のプロセスを「上演」に見立て、進行単位を「幕」として記述します。
第一部：docs × AI（全五章）
第二部：対話ログの整理（全六幕 + 幕間）
第三部：ワークフローとタスク管理（全四幕）
第四部：初めてのアプリを作る（全五幕）
第五部：SLM パイプラインのその後（幕数未定）
- 第一幕：SLM パイプラインのその後 — 品質を「重要度」で測る ← 今ここ
作成日: 2026-03-02
生成元: slm.2026-03-02.claude.08.md / slm.2026-03-02.claude.16.md（AI 対話サマリ）
記事作成プロセス
- プロット作成: Claude Code（対話サマリから抽出）
- 初期作成: Claude Code
- 初回レビュー: 私
- 添削: ChatGPT
- 投稿前レビュー: （未実施）
- 投稿後レビュー: NotebookLM
※ プロットは /dev-log-to-article-plot スキルで生成し、/zenn-blog-writing スキルで下書きを作成しました。
Discussion