Claude Codeエージェント実践 Day 12｜フィードバックで精度を上げる — ナレッジ蓄積の実践
TL;DR
- Day 11 で見つけた3つの問題（日付ハードコード、考察混入、スコープ逸脱）に対してフィードバックし、ナレッジを修正した
- 修正後の再テストで、日付・考察の問題は改善を確認。一方で「レポート再利用時にルール違反SQLが混入する」という新たな問題も見つかった
- 蓄積したナレッジを「スキル候補」と「一般」に仕分ける記録方法を導入した。これが Day 13 の昇格チェックの材料になる
GitHub: akira-cloudjob-public/agent-scaffold-factory
今日やること
Day 11 でエージェントに売上分析を依頼した。結果は概ね良好だったが、3つの気になる点が見つかった。今日はそれらに対してフィードバックを行い、改善されるかを確認する。
部下育成に例えるなら、Day 11 は「初めての仕事をやらせた日」。今日は「レビューして指摘する日」にあたる。
このサイクルを1周回すのが今日のゴール。加えて、蓄積したナレッジを将来の Skills 化に備えて仕分ける方法も整える。
Day 11 で見つけた3つの問題
問題1: 日付がハードコードされる
「先月の売上を地域別に見たい」と依頼したら、生成されたSQLはこうだった。
WHERE date >= '2026-01-01' AND date < '2026-02-01'
結果は正しい。ただし、このSQLを来月実行すると「2026年1月」のデータが返ってくる。「先月」は今日の日付から相対的に決まるはずなので、正しくはこう書くべき。
WHERE date >= DATE_TRUNC(DATE_SUB(CURRENT_DATE(), INTERVAL 1 MONTH), MONTH)
AND date < DATE_TRUNC(CURRENT_DATE(), MONTH)
ここは少し驚いた。初回テスト時には CURRENT_DATE() を使っていたのに、本番テストではハードコードに変わっていた。LLM の出力は非決定的なので、同じ依頼でも毎回同じSQLが返るとは限らない。ルールとして明文化しないと安定しないということ。
問題2: 考察が混じっている
カテゴリ別粗利益の分析レポートに、こんな記述が入っていた。
「売上拡大できれば利益への貢献度が最も高い」
「バンドル戦略で粗利改善の余地あり」
分析担当に求めたいのは ファクトの整理 であって、ビジネス上の提案ではない。「Software の粗利率は81.3%で最も高い」はファクト。「だから売上を伸ばすべき」は考察。判断は人間がするものなので、エージェントの出力にはファクトだけを求めたい。
問題3: レポートを勝手に統合した
Day 11 の分析結果を report_v2.md に出力するよう依頼した。すると、エージェントは依頼していない行動を取った。
- ディレクトリ内の
report.md（v1）を自分で見つけて読み込んだ - 「v2 だから v1 の改良版だろう」と独自に解釈した
- v1 の内容（地域別・カテゴリ別）を v2 に統合した
結果、v1 に含まれていたハードコード日付の SQL がそのまま v2 に混入した。せっかく問題1のルールを追加したのに、ルール適用前の旧データを検証なしで引き継いだことになる。
「なぜ v1 を読んだのか？」とエージェントに聞いたところ、回答はこうだった。
ディレクトリの存在確認で ls を実行した際に report.md が目に入り、「v2 = v1 の改良版だろう」と勝手に解釈して読みに行きました。ファイル名から意味を推測し、確認せずに行動しました。
依頼は「今回の2つの分析結果を出力して」であって、v1 との統合は頼んでいない。確認ファースト の原則に反している。
フィードバック: ナレッジを修正する
3つの問題に対して、それぞれナレッジファイルを修正した。
修正1: CURRENT_DATE() ルールの追加
bigquery.md の「SQL 方言・注意点」セクションに以下を追加。
- 「先月」「直近3ヶ月」など相対的な期間指定は CURRENT_DATE() を使う（ハードコードしない）
- 先月: WHERE date >= DATE_TRUNC(DATE_SUB(CURRENT_DATE(), INTERVAL 1 MONTH), MONTH)
AND date < DATE_TRUNC(CURRENT_DATE(), MONTH)
- 特定月を指定された場合のみ明示的な日付を使う
修正2: レポートはファクトのみ
query.md の出力形式を修正。
Before: サマリー（3行以内）+ 考察
After: サマリー（3行以内）+ ファクトの整理。データから読み取れる事実を説明する。
考察・推測・提案は入れない
修正3（問題3への対処）
問題3はナレッジファイルの修正では解決しない。これはエージェントの「行動パターン」の問題であり、スコープの逸脱。対処は2つ考えられる。
| 対処 | 方法 | 効果 |
|---|---|---|
| CLAUDE.md に原則を追記 | 「依頼の範囲を超えた行動はしない」 | 汎用的だが効果は不確実 |
| 依頼を明確にする | 「v1 は無視して新規作成して」 | 確実だが毎回の手間 |
今回は後者で対処した。ルールを増やすよりも、依頼を具体的にするほうが確実に効く。エージェントのルール遵守は完璧ではないので、重要な依頼ほど指示を明確にする方針で進める。
再テスト: 修正は効いたか
ナレッジを修正した状態で、新しい分析を2本依頼した。
テスト1: 顧客セグメント別の売上
依頼: 「顧客セグメント別の先月の売上を見たい」
結果:
- SQL:
CURRENT_DATE()を正しく使用 → 改善 - JOIN: sales × customers を自分で判断 → OK
- レポート: ファクトのみ、考察なし → 改善
SELECT c.segment, SUM(s.amount) AS total_amount,
SUM(s.quantity) AS total_quantity,
COUNT(DISTINCT s.customer_id) AS customer_count
FROM analytics.sales s
JOIN analytics.customers c ON s.customer_id = c.customer_id
WHERE s.date >= DATE_TRUNC(DATE_SUB(CURRENT_DATE(), INTERVAL 1 MONTH), MONTH)
AND s.date < DATE_TRUNC(CURRENT_DATE(), MONTH)
GROUP BY c.segment ORDER BY total_amount DESC
| セグメント | 売上金額 | 構成比 | 顧客数 | 客単価 |
|---|---|---|---|---|
| SMB | 16,980,000円 | 58.1% | 23社 | 738,261円 |
| Enterprise | 8,830,000円 | 30.2% | 6社 | 1,471,667円 |
| Individual | 3,410,000円 | 11.7% | 11名 | 310,000円 |
テスト2: 直近3ヶ月の月次推移
依頼: 「直近3ヶ月の月次売上推移を見たい」
結果:
- SQL:
DATE_TRUNC(DATE_SUB(CURRENT_DATE(), INTERVAL 3 MONTH), MONTH)→ 改善 - レポート: ファクトのみ → 改善
- 追加: 前月比を自主計算、ASCIIチャートを生成 → 依頼外だが有用
| 月 | 売上金額 | 前月比 | 数量 | 顧客数 |
|---|---|---|---|---|
| 2025-11 | 34,440,000円 | — | 256 | 37 |
| 2025-12 | 42,420,000円 | +23.2% | 287 | 43 |
| 2026-01 | 29,220,000円 | -31.1% | 175 | 40 |
フィードバック効果のまとめ
| 問題 | 修正前（Day 11） | 修正後（Day 12） |
|---|---|---|
| 日付ハードコード | '2026-01-01' |
CURRENT_DATE() |
| 考察混入 | 「バンドル戦略で〜」 | ファクトのみ |
| v1 統合 | — | 依頼を明確化して回避 |
2つのルール修正はどちらも効いた。ナレッジに書いたことは、次の実行から反映される。これが Commands 期のフィードバックサイクルの基本形になる。
ナレッジの記録方法を整える
ここまでの検証で、ナレッジが増えてきた。Day 11 で5件、Day 12 でさらに追加。このまま何でもナレッジに放り込むと、将来 Skills に昇格させるときに仕分けが大変になる。
スキル候補ナレッジと一般ナレッジ
ナレッジには2種類ある。
| 分類 | 性質 | Skills 化 | 例 |
|---|---|---|---|
| スキル候補 | 再現性のある判断・手順 | 対象 | SQLルール、出力形式、解釈パターン |
| 一般 | 背景情報・一回限りの記録 | 対象外 | 環境トラブル、調査メモ |
見分け方は「この知識がないと、エージェントが同じ業務を自律的にこなせるか？」で判定する。
- いいえ → スキル候補ナレッジ（タグ付けして記録）
- はい → 一般ナレッジ（lessons/ に記録）
タグで仕分ける
スキル候補ナレッジにはタグを付ける。タグは将来スキル化される単位に対応する。
[analytics.sales] = 売上分析スキルの候補
このタグが付いたナレッジだけを抽出すれば、そのままスキルの定義ファイルに使える。
今日の知見を仕分ける
Day 11-12 で得た知見を、この2分類で整理してみる。
スキル候補ナレッジ [analytics.sales]:
| 知見 | 内容 | 確認状態 |
|---|---|---|
| 相対期間ルール | 「先月」は CURRENT_DATE() を使う |
再テストで確認済み |
| レポート形式 | ファクトのみ。考察・推測・提案は入れない | 再テストで確認済み |
| セグメント別パターン | customers テーブルとの JOIN で集計 | 動作確認済み |
| 月次推移パターン |
FORMAT_DATE + INTERVAL N MONTH
|
動作確認済み |
一般ナレッジ（タグなし）:
| 知見 | 内容 | 理由 |
|---|---|---|
| v1 統合問題 | ファイル名から意図を推測し確認なしで行動 | 一回限りの事象、環境依存 |
| ASCII チャート生成 | 時系列データに棒グラフを自主追加 | 挙動の記録、ルール化不要 |
スキル候補ナレッジは再現性がある。「先月の売上を見たい」と言われるたびに CURRENT_DATE() は必要になるし、レポートはいつもファクトのみであってほしい。一方、v1 統合の問題は特定の状況で起きた一回限りの事象で、スキルに含めるものではない。
Commands 期の「指導」パターン
今日の検証で、Commands 期のフィードバックサイクルが見えてきた。
このサイクルで重要なのは ④ と ⑥ だと感じた。
④ ナレッジを修正する — 口頭で「次からこうして」と言っても LLM は覚えていない。ナレッジファイルに書くから、次の実行で反映される。部下育成でいえば「マニュアルを更新する」に相当する。口頭指導だけでは属人化するのと同じ構造。
⑥ 記録する — 修正して終わりではなく、スキル候補かどうかを仕分けて記録する。このひと手間が、将来の Skills 化をスムーズにする。実務でも、OJT の記録を残さないと昇格評価ができないのと同じ。
まとめ
- Day 11 の3つの問題にフィードバックし、ナレッジを修正した
- 再テストで2つのルール修正の効果を確認。ナレッジに書けば次から反映される
- 「レポート再利用で旧SQLが混入する」という新たな問題も見つけた — 依頼の明確化で対処
- ナレッジを「スキル候補」と「一般」に仕分ける記録方法を導入した
- このフィードバックサイクルが Commands 期の日常業務になる
正直、1件の分析依頼に対してこれだけフィードバックが発生するのは手間がかかる。ただ、これは部下育成の初期段階と同じで、最初に手間をかけるからこそ後が楽になるはず。スキル候補の仕分け方もまだ試行錯誤中で、もっと良い基準があるかもしれない。Day 13 では、ここまでに蓄積したナレッジで「もう任せていいか」を判定する。
検証環境
| 項目 | 値 |
|---|---|
| OS | Windows 11 Pro |
| シェル | Git Bash (MINGW64) |
| IDE | Cursor + Claude Code |
| BigQuery | 個人検証用プロジェクト / analytics データセット |
| 検証日 | 2026-02-12 |
参考資料: エージェントが出力した売上分析レポート（report_v2.md）
フィードバック反映後にエージェントが出力したレポートの全文（※ 分析対象はサンプルデータ）。「ファクト」セクションに考察が含まれていないこと、SQLが CURRENT_DATE() を使っていることを確認できる。
エグゼクティブサマリー
- 1月売上: 2,922万円 / 粗利益: 1,555万円（粗利率 53.2%）
- 月次推移: 12月 4,242万円をピークに、1月は前月比 -31.1% と大幅減
- 顧客セグメント: SMB が売上の58.1%を占め最大。Enterprise は客単価147万円で最も高い
直近3ヶ月 月次売上推移
| 月 | 売上金額 | 前月比 | 数量 | 顧客数 |
|---|---|---|---|---|
| 2025-11 | 34,440,000円 | — | 256 | 37 |
| 2025-12 | 42,420,000円 | +23.2% | 287 | 43 |
| 2026-01 | 29,220,000円 | -31.1% | 175 | 40 |
ファクト: 12月が売上・数量・顧客数すべてで最大。1月は12月比で売上 -31.1%、数量 -39.0%。顧客数は40社を維持（-7.0%）。
顧客セグメント別売上（2026年1月）
| セグメント | 売上金額 | 構成比 | 顧客数 | 客単価 |
|---|---|---|---|---|
| SMB | 16,980,000円 | 58.1% | 23社 | 738,261円 |
| Enterprise | 8,830,000円 | 30.2% | 6社 | 1,471,667円 |
| Individual | 3,410,000円 | 11.7% | 11名 | 310,000円 |
ファクト: SMB が顧客数・数量・売上すべてで最大。Enterprise は6社で30.2%、客単価はSMBの約2倍。
地域別売上（2026年1月）
| 地域 | 売上高 | 構成比 | 顧客数 | 客単価 |
|---|---|---|---|---|
| 関東 | 15,450,000円 | 52.9% | 17 | 908,824円 |
| 関西 | 7,440,000円 | 25.5% | 12 | 620,000円 |
| 九州 | 6,330,000円 | 21.7% | 11 | 575,455円 |
ファクト: 関東が売上の52.9%、客単価も約91万円で最高。関西と九州は売上規模が近いが、関西の客単価が約4.5万円上回る。
カテゴリ別売上高・粗利益（2026年1月）
| カテゴリ | 売上高 | 粗利益 | 粗利率 | 数量 |
|---|---|---|---|---|
| Service | 12,710,000円 | 7,660,000円 | 60.3% | 55 |
| Software | 7,550,000円 | 6,140,000円 | 81.3% | 61 |
| Hardware | 8,960,000円 | 1,745,000円 | 19.5% | 59 |
ファクト: Software は粗利率81.3%で最高。Service は粗利額で最大（766万円）。Hardware は売上規模はあるが粗利率19.5%。
参考資料: ナレッジログ（knowledge-log.md）
Day 11〜12 で蓄積したナレッジの記録。タグ付き（[analytics.sales]）がスキル昇格候補、タグなしが一般ナレッジ。
スキル候補ナレッジ
[analytics.sales] 相対期間は CURRENT_DATE() を使う
-
状況: 「先月の売上を地域別に」と依頼したら
WHERE date >= '2026-01-01'とハードコードされた -
判断: 「先月」「直近3ヶ月」など相対的な期間指定は
CURRENT_DATE()を使う -
確認: ルール追加後の再テストで2回とも
CURRENT_DATE()が使われた
[analytics.sales] レポートはファクトのみ、考察不要
- 状況: カテゴリ別粗利益のレポートに「バンドル戦略で粗利改善の余地あり」等の考察が混入
- 判断: 分析レポートにはファクトの整理のみ記載する。考察・推測・提案は入れない
- 確認: ルール修正後の再テストで考察なしのレポートが出力された
[analytics.sales] 地域別売上パターン
- 判断: sales テーブルの region でグループ化。JOINなしで完結
[analytics.sales] カテゴリ別粗利益パターン
- 判断: sales × products を JOIN し、SUM(amount) - SUM(cost × quantity) で粗利益を計算
[analytics.sales] 顧客セグメント別売上パターン
- 判断: sales × customers を JOIN し、segment でグループ化
[analytics.sales] 月次売上推移パターン
- 判断: FORMAT_DATE で月単位に変換、INTERVAL N MONTH で期間指定
一般ナレッジ
レポート再利用時のルール適用漏れ
- report_v2.md の出力を依頼したら、v1 を勝手に読んで統合。v1 のハードコード日付 SQL がそのまま混入
- 対処: 依頼を明確にする（「v1 は無視して新規作成して」）
ASCII チャートの自主生成
- 月次推移の分析で、依頼していない ASCII 棒グラフを自主的に生成。有用だが指示外
次回: Day 13 では、Commands 期に蓄積されたナレッジで昇格チェックを実施します。「もう任せていいか？」を判定して、Sales Skill にパッケージする — Commands から Skills への転換点です。
シリーズを追いかける
Discussion