法務経理 AI の芯 — 現場は「プロンプトを書く人」ではなく「正解を教える人」¶
作成日: 2026-06-27 目的: データ基盤＋DSPy 改善ループの散漫な議論を、請求書チェック／経理データ調査の2具体例で研いで「一番伝えたい芯」を1枚に蒸留した内部メモ。 素材（詳細）: データ基盤_メタデータとgcsで法務経理ai_整理 / dspy_現場プロンプト改善ループ_metricと所有権境界_整理
芯（1行）¶
法務経理 AI で本当に作るべきは “賢い初期プロンプト” ではなく、現場の毎日の操作がそのまま改善の燃料(signal)になる構造。現場は「プロンプトを書く人」ではなく「正解を教える人」。
2つの具体例で確かめる¶
| 請求書チェックツール | 経理データ調査ツール | |
|---|---|---|
| 現場の操作 | 請求書をアップする | 質問を自然文で打つ |
| AI の仕事 | 項目抽出＋ルール/データ照合（重複・金額一致・税率・契約整合） | 質問→クエリ変換→集計→出所付きで答える |
| 必要なデータ基盤 | 請求書(非構造)＋取引先/契約/PO マスタ | 仕訳・元帳(構造)＋メタデータ(列の意味)＋lineage |
| 正解(metric)の源 | 現場の最終判定（承認/差戻し）← rule 寄り | 答えの正否＋数値一致 ← rule＋judge |
| 現場の関わり | AI の指摘を訂正する（誤検知/見逃し） | 答えに○×を付ける/言い直す |
| レジーム | Path A（裏で artifact 差し替え） | Path A（裏で artifact 差し替え） |
具体に落とすと、散漫だった論点が2つ自動で決着する¶
- 「最適化プロンプトをどう現場に伝えるか」問題が蒸発する — どちらも現場はツールを使うだけ（アップする／質問を打つ）でプロンプトを編集しない＝Path A 確定。artifact は裏で差し替わり、現場への“伝達”はゼロ。さんざん議論した A/B 配信の悩みは、この2例では考えなくていい。
- 現場の役割が一本化する — 両方とも現場は「プロンプト作者」でなく「正解を教える signal 源」（訂正する／○×する）。設計の問いは「どう良いプロンプトを書くか」ではなく、「現場の訂正をどう metric に変えて回すか」。
だから芯は、見えない2つの土台に絞れる¶
| 土台 | 請求書チェックで | 経理調査で |
|---|---|---|
| ① 統制されたデータ（メタデータ） | マスタと照合できる・どの請求がどの契約か辿れる | 列の意味が分かるから質問を変換できる・数字の出所を示せる |
| ② 改善ループ（現場の訂正→metric→gate→再配信） | 誤検知を直す→次から減る | 言い直し→次から当たる |
→ 派手な AI 機能ではなく、この2つの“見えない土台”を最初の1ツールに最初から組み込めるかが分かれ目。 これが「縦1本で通せ」の中身。
最初の一手¶
- 請求書チェックから始める。 rule 寄りで metric が作りやすく、現場の訂正がそのまま正解になるので、改善ループ（土台②）を最初に体感しやすい。
- 経理データ調査は metadata/lineage への依存度が高く土台①の重さが先に来るので2本目向き。
一言サマリ¶
ツールの賢さより、「現場の操作 → 訂正 → 改善」が毎日回る配管。現場は最良の judge であって、prompt engineer ではない。
作成: 2026-06-27 ／ 最終更新: 2026-06-27