AIの下書きを「人が実際に送った文」で育てる — 添削台帳の作り方

AI に問合せ返信の下書きを作らせている運用で、精度を継続的に上げるための仕組み。 追加学習(fine-tune)を使わず、費用ゼロで回せる。

前提となる運用

問合せ到着 → AIが返信案を作る → 人が直す → 人が送信

この「人が直した差分」が唯一の正解データになる。これを捨てずに貯める。

設計の要点（ここを間違えると作り直しになる）

1. 突き合わせの鍵は「宛先メールアドレス + 日時」にする

下書きIDやスレッドIDをDBに保存して紐付ける設計にしがちだが、やめたほうがいい。 送信経路に手を入れる必要があり、しかも仕組みを入れる前に送ったメールが永久に使えない。

代わりに 問合せテーブルの相手メールアドレス と 送信済みメールの宛先 を突き合わせ、 「その問合せの受信日時以降に、そのアドレスへ送られた最初のメール」を対応付ける。

• 送信経路を一切変えなくていい
• 過去に送ったメールを全部さかのぼって取り込める（初日から学習データが揃う）
• 同一アドレスから複数問合せが来る場合だけ、件名の近さを補助に使う

2. 台帳に入れる列

列	用途
問合せID	一意キー。送信メールIDとの複合で重複防止
問合せ本文（マスク済み）	後でお手本として AI に読ませる
AIが作った案	比較元
実際に送った本文	正解
編集量 0〜100%	効果測定の主指標。レーベンシュタイン距離で算出
分類	金額／日程／商品選択／言い回し／丸ごと破棄

**「丸ごと破棄された」も必ず記録する。**AI が的外れな提案をしたケースがここに溜まり、 最も重要な改善材料になる。

3. 個人情報は保存前に伏せる

このデータは後で AI の指示文に差し込む。生の氏名・社名・メール・電話を残さない。 マスクは保存時に行い、台帳には伏字しか入れない。

4. 学習のさせ方（追加学習はしない）

(a) お手本の自動入れ替え — よく直される種類について、人が送った最終文を 指示文に 10〜20 件差し込む。種類が偏らないよう選ぶ。言い回しは一気に寄る。

(b) 直し方のルール化 — 差分を定期的にまとめ、3回以上繰り返された直しだけをルール文にする。 例:「スタッフ費を問われていないときは書かない」「日数が読めないときは日数を書かない」

ルールは承認制にする。 自動反映にすると、たまたま変な直し方をした1件で全体が壊れる。 候補を通知して、人が OK を出したものだけ有効にする。日付つきで保存し、1手で戻せるようにする。

5. 金額は学習対象から外す

計算はお手本から学ぶものではなく、ルールで固定して単体テストで守るもの。 金額を学習させると、過去の例外的な値引きを一般則として覚えてしまう。

効果の測り方

編集量の中央値を定期的に記録する。 これを出さないと「なんとなく良くなった気がする」で終わる。 導入時 60% → 数ヶ月後 30% なら効いている。下がらなければやり方が間違っている。 計算は無料なので必ず入れる。

段階導入

段階	やること	効果
1	台帳に溜めるだけ（AIの挙動は変えない）	まだ上がらないが、データが貯まる
2	編集量の計測と定期レポート	どこが一番直されているかが見える
3	お手本の自動入れ替え	ここで体感が変わる
4	ルール抽出と承認フロー	同じ直しの繰り返しが消える

第1段階は既存の動作を一切変えないので、本番運用中でも安全に入れられる。

実装上の注意

• 取り込みCLIは 再実行しても重複行が増えないこと（問合せID+送信メールIDで一意制約）
• --dry-run を必ず付ける。実データに入れる前に件数と一致結果を見る
• 送信済みメールの走査は、そのメールアカウントの権限で動く仕組み（例: Google なら Apps Script） を使うと、管理者による権限委任の設定が不要になる
• 一致0件で終わることがある。件数を突き合わせるまで「成功」と呼ばない

落とし穴: この仕組みは「言い回し」しか直せない

商品の選び間違いや日数の誤読といったロジックの不具合は、お手本を増やしても直らない。 精度を上げる投資先は (1) ロジックのバグ修正 → (2) この台帳 の順。 台帳は「毎回同じ直しをしている」を消す仕組みであって、間違いを直す仕組みではない。