第一幕：ローカルSLMで対話ログを要約する — 動機・アーキテクチャ・最初の壁
この記事について
AI対話ログと実験記録をもとに Claude Code が下書きを作成し、私が加筆修正しました。
この連載は、個人開発プロジェクトで使っている AI 対話ログ要約パイプラインの構築記録です。
ローカル環境の Small Language Model（Ollama + qwen2.5:14b）を使い、14回のプロンプト改善を経て到達したパイプラインの試行錯誤を3回に分けて紹介します。
はじめに
やること
- なぜ対話ログの要約が必要になったかを説明する
- なぜクラウド API ではなくローカル SLM を選んだかを説明する
- bash オーケストレーション + Ollama の全体構成を示す
- 最初の素朴なプロンプトから改善5までの試行錯誤を追う
- SLM の限界がどこで見えたかを示す
やらないこと
- 「正しいプロンプトの書き方」の提示
- SLM と LLM の網羅的な比較
- Ollama のインストール手順や環境構築ガイド
- クラウドAPI/ローカルの優劣を断定する結論（用途と制約で最適解が変わるため）
この記事は、個人開発や研究用途で「AIとの対話ログを資産として扱いたい人」を主な読者として想定しています。
対話ログが溜まるという問題
私は個人開発プロジェクトで Claude Code や ChatGPT と頻繁に対話しています。
設計の壁打ち、コードレビュー、ドキュメント整理、企画の検討。
対話のたびにログが残ります。
docs/ai_dialog/raw/
├── 2026-02-01.claude.01.txt (211KB)
├── 2026-02-01.claude.02.txt (42KB)
├── 2026-02-01.claude.03.txt (130KB)
├── 2026-02-01.claude.04.txt (137KB)
├── 2026-02-04.claude.01.txt (88KB)
├── 2026-02-04.claude.02.txt (104KB)
├── ...
1日に複数セッション、1セッションで 40KB〜200KB。
1週間で数百 KB、1ヶ月で数 MB になります。
これらのログには、設計判断の理由、却下した選択肢、TODO、技術的な気づきなど、後から振り返りたい情報が含まれています。
しかし、raw ログをそのまま読み返すのは現実的ではありません。
- コードブロックやツール呼び出しの出力が大量に含まれる
- 「はい」「了解しました」のような定型応答がノイズになる
- 重要な判断が会話の途中に埋もれている
要約が必要になりました。
使用モデルと実行環境
qwen2.5:14b — 実験用モデルとしての採用
この連載で使用しているモデルは qwen2.5:14b です。
ただし、これは「このモデルがベストだ」という結論ではありません。
パイプラインの構造を固めるための実験用モデルとして採用しています。
実利用に耐えるモデルの選定は未着手です。
今後、パイプラインが安定した段階で、より高精度・成果物の商用利用可能なモデルへの切り替えを検討する予定です。
現時点では「パイプラインの設計と検証」が優先であり、モデル性能の追求はその後の話です。
なお、複数モデルで試したところ、Few-shot 例が出力に漏れるケースがあり、今回の実験では qwen2.5:14b を採用しました。
実行環境 — 開発用 Mac と実運用 Mac
このパイプラインは、役割を分けた 2 台の Mac で運用しています。
| 用途 | スペック | 役割 |
|---|---|---|
| 開発Mac | M4 MacBook Pro / 48GB メモリ | 開発全般、job 作成、プロンプト改善、テスト実行 |
| 運用Mac | M4 Mac mini / 16GB メモリ | 各種サーバ、Ollama 常駐、bulk 実行、SLM 推論 |
開発用 Mac で試行錯誤したプロンプトやスクリプトを整え、
それを実運用の Mac mini に反映して bulk 処理を回す、という分業構成です。
実運用 Mac mini の位置づけと制約
実運用に使っている M4 Mac mini（16GB） は、
14b モデルを常時稼働させるには 決して余裕のある構成ではありません。
- 16GB メモリで 14b を動かすと、メモリ使用量はほぼ上限
- 推論速度にも十分な余裕があるとは言えない
- 発熱も無視できない
そのため、
job の実行間隔を空ける／深夜にまとめて回す など、
運用上の工夫で無理のない形に調整しています。
それでもなお、この構成を採用している理由は明確です。
なぜ「小さい」モデル（14b）なのか
14b は、近年の LLM の基準ではかなり小さいモデルです。
70b や 100b 超のモデルを使えば、当然ながら精度は向上します。
しかし、大きなモデルには相応のハードウェアが必要になります。
- 70b クラスをローカルで快適に動かすには 64GB 以上のメモリ + 高性能 GPU が現実的に必要
- 初期費用・電気代ともに一気に跳ね上がる
私が目指しているのは、
「トータルコストを極力抑えた常時運用環境」 です。
コスト感覚で見る Mac mini + SLM
M4 Mac mini は、整備済み中古で 10万円前後から入手できます。
消費電力も低く、24時間稼働させても電気代の負担はほとんどありません。
Mac mini の運用コスト（24時間常駐）
| 項目 | 値 |
|---|---|
| 消費電力 | 10〜15W（平均） |
| 電気代 | 約 300 円 / 月 |
| 年額 | 約 3,900 円 / 年 |
| ソフトウェア費用 | すべて無料（Ollama / モデル） |
同等の推論性能をクラウドで確保しようとすると、
月額数万円〜十万円規模になるのが一般的だと考えています。
Windows GPU マシンとの比較（2年運用）
| 構成 | 初期費用 | 電気代/月 | 2年合計 |
|---|---|---|---|
| Mac mini (M4 / 16GB) | 約10万円 | 約300円 | 約11万円 |
| Windows Mini-ITX (RTX 4060 Ti) | 18〜25万円 | 約1,000〜1,500円 | 約21万円 |
この比較から分かる通り、
「常時回せる実験環境」としては、Mac mini + SLM が突出して安価
と判断しました。
ただし、サーバとして利用する前提では、
外部 SSD によるストレージ拡張やバックアップ体制の構築、
UPS を用いたグレースフルシャットダウンなど、
インフラを自分で管理する責任が発生します。
これはクラウドでは不要な手間ですが、
その分、月額コストや実行制約から解放される、というトレードオフでもあります。
制約を理解したうえで使う、という選択
M4 Mac mini（16GB）は、
14b モデルを常時フル回転させるにはシビアな構成です。
しかし、
- 月額約 300 円の電気代で 24 時間動き続ける
- ハード・ソフトともに追加コストなし
- 手元で、いつでも、何度でも回せる
- エアフローがMacBook Proよりも余裕がありそう
- 壊れても消耗品としてなんとか諦めがつく価格
という条件を満たす環境としては、
最もコストパフォーマンスが高い選択肢でした。
高精度が必要な場面では、クラウド API を使えばいい。
一方で、
「思いついたときに、無料で、何度でも試せる」
この性質こそが、ローカル SLM 最大の価値だと感じています。
なお、開発用 Mac ではより大きなモデルも動かせますが、
ノートPCであること・高価なハードウェアであることを踏まえ、
本当に必要なときだけ実行する運用にしています。
普段の bulk 処理は運用 Mac に寄せ、
役割を明確に住み分けています。
なぜクラウド API ではなくローカル SLM か
要約の手段として、クラウドの LLM API（Claude API、GPT API）を使う選択肢は当然あります。
精度は高い。しかし、いくつかの理由でローカル SLM を選びました。
1. コスト
対話ログは日々増えます。
1ファイル 100KB のログを API に送ると、入力トークンだけでかなりのコストになります。
実験段階では「プロンプトを書き換えて再実行」を何十回も繰り返します。
その都度 API 料金がかかるのは、個人開発には重い。
2. プライバシー
対話ログには、プロジェクトの内部構造、ファイルパス、設計判断が含まれています。
外部 API に送信すること自体がリスクになり得ます。
ローカルで完結すれば、その心配がない。
3. 実験の自由度
ローカル SLM は「何回でも、無料で、好きなだけ試せる」。
プロンプトを少し変えて再実行。チャンクサイズを変えて再実行。モデルを変えて再実行。
この自由度が、14回の改善を可能にしました。
本連載での評価軸は「最高精度」ではなく、以下の３点としました。
(1) 低コストで継続運用できること
(2) ログを外部に出さないこと
(3) 試行回数を制限しないこと
そのため、クラウドAPIの方が高精度になり得る点は認めた上で、今回はローカルSLMを選びます。
全体アーキテクチャ
このパイプラインは、bash スクリプトが Ollama の API を叩くだけの素朴な構成です。
bundle 構造
SLM に渡すプロンプトは、複数の .md ファイルに分割して管理しています。
bundle/
├── bootstrap/
│ ├── 00_context.md # 「あなたは対話ログの要約担当です」
│ └── 10_io.md # 入出力仕様
├── role/
│ └── 00_summarizer.md # ロール定義・制約
├── tasks/
│ ├── 01_requirements.md # 要約ルール
│ └── 07_implementation.md # 出力フォーマット
├── playbook/
│ └── 07_implementation.md # 設計上の注意点
└── runs/ # 実行履歴
manifest.txt がこれらのファイルを列挙し、実行時に連結して SLM に渡します。
input.md（要約対象の raw ログ）は実行のたびに動的生成されます。
オーケストレーションの処理フロー
summarize_one() {
# 1. raw ファイルから input.md を生成
generate_input "${in_file}" "${input_file}"
# 2. manifest に input.md を登録
build_manifest "${run_rel}" "${input_file}"
# 3. SLM を実行（Ollama API 呼び出し）
output_md="$(execute_run "${run_rel}")"
# 4. 出力をアトミックに書き込み
cp -f "${output_md}" "${tmp_out}"
mv -f "${tmp_out}" "${out_file}"
}
ディレクトリ内の raw ファイルを順に処理し、slm. プレフィックス付きの要約ファイルを生成します。
すでに出力が存在すればスキップし、--force で再生成できます。
この構造は単純ですが、後の改善で前処理やチャンク分割が入る際の拡張点が明確になっています。
最初のプロンプトとその結果
初期のプロンプトは非常にシンプルでした。
ロール定義 (role/00_summarizer.md):
あなたは「対話ログの要約担当」です。
入力として与えられる raw テキストを、日本語で要約してください。
## 重要
- 推測や断定は禁止。入力に書かれていることだけを要約する。
- 個人情報、APIキー等は出力しない。見つけた場合は *** でマスクする。
- 余計な前置き、自己紹介は不要。要約本文のみを出力する。
出力フォーマット (tasks/07_implementation.md):
# Summary
## 概要（2〜3行）
## 要点（最大7点）
## 決定事項（あれば）
## 未決・確認事項（あれば）
## TODO（あれば）
## リスク/注意（あれば）
この構成で 100KB 超の raw ログを要約させた結果、問題がすぐに見えました。
出力の問題点:
- 要点が漠然としている（「技術的な議論が行われた」程度の情報しかない）
- 具体的なファイルパスや数値が落ちる
- 決定事項と確認事項の区別が曖昧
- 100KB を超える入力だと、後半の情報がほぼ無視される
SLM は指示に忠実に要約を生成しますが、何を拾うべきかの判断基準がないと、全体をぼんやりと要約するだけになります。
改善1〜5: プロンプトの工夫で精度を上げる
ここから、プロンプトを繰り返し改善していきました。
改善1: 抽出チェックリストの追加
「何を拾うか」を明示しました。
## 優先して残すべき情報（漏らさないこと）
1. 新企画・アイデア・コンセプト名
2. 重要な決定事項・方向転換
3. TODO・次のステップ
4. 具体的な数値・成果物のパス
5. 技術的な課題と解決策
6. 他者からのフィードバック
効果: 具体的なファイルパスや数値が要約に現れるようになった。
残った問題: 項目は拾うが、文脈が薄い。
改善2: Few-shot 例の詳細化
入力と期待出力の具体例を追加しました。
### 良い出力例
入力: 「Claudeでdocs/api.mdを作成。FastAPIを採用し、
エンドポイントは15個。レスポンスタイムが200msから50msに改善。」
出力:
- 成果物: docs/api.md を作成
- 技術選択: FastAPI を採用
- 数値: エンドポイント15個
- 数値: レスポンスタイム 200ms → 50ms に改善
効果: 出力の粒度が揃いはじめた。
残った問題: Few-shot の例に引っ張られすぎて、例にない種類の情報を落とすことがある。
改善3: 禁止事項の追加（ハルシネーション抑制）
SLM が入力にない情報を「補完」してしまうケースが発生しました。
## 禁止事項
- ハルシネーション禁止: 元テキストにない情報を追加しないこと
- サマリや感想を書かない: 情報の列挙のみ
- 冗長な引用は避ける（原文のコピペ中心にしない）
効果: 捏造された情報が減った。
残った問題: 禁止事項が多いと、SLM が保守的になりすぎて情報を落とす傾向が出た。
改善4: 設計上の注意点を追加
playbook に「ノイズの扱い」「確認事項と決定事項の区別」を明記しました。
## Design Concerns / Known Pitfalls
### 1. ノイズの多いログ構造
- raw には発話のないターン、確認用の定型文が多く含まれる
- 事実・結果・構造のみを抽出すること
### 2. 「確認事項」と「決定事項」の混同
- 仕様を説明・確認しているだけの場合、それは決定事項ではない
- 今後の挙動や運用を拘束する合意が明示された場合のみ
「決定事項」として扱う
効果: 「確認事項」と「決定事項」の混同が減った。
残った問題: 改善はされたが、依然として長い入力では後半の情報が薄い。
改善5: 抽出項目の拡張
要約のセクションに「新企画・気づき・感情」の抽出項目を追加しました。
企画の壁打ちログでは、技術的な決定事項だけでなく「面白い」「これは使える」といった評価や、新しいアイデアの萌芽が重要です。これらを拾えるようにしました。
効果: 質的に豊かな要約になった。
残った問題: 入力が長いと、改善1〜5のすべてが効かなくなる。
ここまでの改善で「短い入力を丁寧に読む」能力は引き出せましたが、「長い入力を構造的に処理する」段階には到達できませんでした。
14回の改善の全体像
この記事では改善1〜5を紹介しましたが、パイプラインはその後も改善を重ねています。
全体像を示しておきます。
| 改善 | 内容 | 記事 |
|---|---|---|
| 1〜5 | プロンプトの工夫（チェックリスト、Few-shot、禁止事項 等） | 第1回（本記事） |
| 6〜7 | Multi-Pass Category Extraction の導入・チャンクサイズ縮小 | 第3回 |
| 8〜9 | 前処理スクリプト作成・識別子保持の工夫 | 第2回 |
| 10 | Reduce プロンプト全面改善 | 第3回 |
| 11〜12 | 前処理の統合・複数ログ形式への対応 | 第2回 |
| 14 | チャンクサイズ最適化（10KB 採用） | 第3回 |
注: 改善13は欠番です（実験の過程で統合されました）。
改善の番号は必ずしも時系列順ではなく、前処理（第2回）とMulti-Pass（第3回）は並行して進めた部分があります。
改善の効果と、見えてきた限界
改善1〜5を経て、短い入力（〜30KB 程度）に対する要約品質は明らかに向上しました。
| 段階 | 主な変更 | 効果 |
|---|---|---|
| 初期 | シンプルな指示のみ | 漠然とした要約 |
| 改善1 | 抽出チェックリスト | 具体的な情報が拾われるように |
| 改善2 | Few-shot 例 | 出力の粒度が安定 |
| 改善3 | 禁止事項 | ハルシネーション抑制 |
| 改善4 | 設計注意点 | 分類の精度向上 |
| 改善5 | 抽出項目拡張 | 質的な豊かさ |
しかし、100KB を超える raw ログに対しては、根本的な問題が残りました。
SLM の限界
-
長い入力に弱い: コンテキスト長の制約に加え、入力が長くなると中盤〜後半の情報が抜け落ちやすい（いわゆる Lost in the Middle 現象）。プロンプトをどれだけ工夫しても、モデルが入力を十分に読めなければ意味がない。
-
フォーマットを守れないことがある: 入力が長くなると、指定した Markdown テンプレートから逸脱する頻度が上がる。セクションが消える、箇条書きが崩れる、といった問題が発生する。
-
言語の混入: qwen2.5 は多言語モデルであるため、入力が長くなると英語や中国語が混入することがある。
これらはプロンプトの工夫では解決できません。
入力データそのものを扱いやすい形に変える必要がありました。
まとめ
この記事では、ローカル SLM による対話ログ要約パイプラインの動機と初期構築を紹介しました。
- 対話ログは溜まる一方で、raw のまま読み返すのは現実的ではない
- ローカル SLM は、コスト・プライバシー・実験の自由度で優位
- bash + Ollama + bundle 構造で、素朴だが拡張可能なパイプラインを構築した
- プロンプト改善1〜5で短い入力への精度は上がったが、長い入力への限界が見えた
SLM は「LLMと比べると物足りないが、ローカルで自由に回せる」存在です。
その限界は、プロンプトの工夫だけでは超えられません。
この段階で得られた最大の教訓は、「SLM は万能ではないが、制約が見えた瞬間から設計が始まる」ということでした。
次回は、この限界を突破するために導入した前処理の話をします。
174KB のログを 12KB まで圧縮しつつ、重要な識別子を保持する方法です。
補足：より高精度が必要な場面ではクラウドAPIを使うのが合理的です。本連載は「ローカルで回せる運用」を先に成立させるための記録です。
上演目録（docs × AI による開発記録）
※本シリーズでは、試行錯誤のプロセスを「上演」に見立て、進行単位を「幕」として記述します。
第一部：docs × AI（全五章）
- 序章：docs × AI による開発記録 – このプロジェクトのコンセプト
- 第一章：人 × 複数AI の協働フロー — 1記事目はこうして作られた
- 第二章：internal-first — GitHub事故を防ぐための(local.gitという)舞台設計
- 第三章：docs の全体像 — 舞台装置としての構造
- 第四章：docs をどう使っているか — 運用と循環
第二部：対話ログの整理（全六幕 + 幕間）
- 第一幕：ローカルSLMで対話ログを要約する — 動機・アーキテクチャ・最初の壁
- 第二幕：前処理で80%削減 — コードブロックと識別子の扱い
- 第三幕：Multi-Passカテゴリ抽出とチャンクサイズの最適化
- 第四幕：カテゴリ設計の失敗 — 増やせば良くなるという幻想
- 第五幕：測定と収束 — Eval-Kit とカテゴリ統合
- 幕間：5つの幕で得た学びと失敗
- 第六幕：GroupReduce — パイプラインの再利用で新しい問題を解く
作成日: 2026-02-06
ステータス: 公開
生成元: pg5-automation-internal/next.md, job1004-ai-dialog-summary/bundle/, job1004-ai-dialog-summary/scripts/main_impl.sh
記事作成プロセス
- 初期作成: Claude Code
- 初回レビュー: 私
- 添削: ChatGPT
- 投稿前レビュー: Zenn AI
- 投稿後レビュー: Google Gemini
※ この記事は、プロジェクトの実験記録・プロンプト改善履歴・スクリプトのソースコードをもとに Claude Code が整理・再構成しました。
Discussion