法務・経理 AI 化 — 改善ループとガードレールの設計（事例リサーチ込み）¶

作成日: 2026-06-27 目的: 「現場は signal 源」という芯を軸に、プロンプト改善ループの回し方とガードレール整備を、他社事例リサーチ込みで1つの資料に統合した内部資料。芯（1行）: 法務経理 AI で作るべきは “賢い初期プロンプト” ではなく、現場の毎日の操作がそのまま改善の燃料(signal)になる構造。現場はプロンプトを書く人でなく、正解を教える人。関連: 法務経理ai_芯_現場はsignal源_1枚整理（芯の1枚） / dspy_現場プロンプト改善ループ_metricと所有権境界_整理（ループ詳細） / データ基盤_メタデータとgcsで法務経理ai_整理（基盤詳細）

0. この資料の主張（30秒）¶

AI 化の成否は初期プロンプトの出来ではなく、現場の訂正が metric→ゲート→再配信に回る“配管”を持てるか。事例横断（Vic.ai / Robin AI / Harvey / Nubank …）で共通する設計。
それを安全に回すには ガードレール＝「どこまで AI に触らせていいかを会社が明示する枠組み」が前提。エンジニア領域の権限・CI/CD に相当するものを、コーポレートでは データ分類 × リスク階層 × 承認 × 監査証跡で組む。
改善ループはガードレールの“内側”で回す。この2つは別物でなく入れ子。

1. 改善ループの全体像 — 現場の操作が燃料になる¶

flowchart TD
    Field([現場: 請求書アップ / 質問入力]) --> AI[AI が出力<br>抽出・チェック / 回答生成]
    AI --> Correct[現場が訂正・判定<br>承認 / 差戻し / ○×]
    Correct -->|これが signal| Log[(利用ログ + 訂正を回収)]
    Log --> Dataset[ラベル付きデータセット<br>train / eval に分割]
    Dataset --> Metric[metric で数値化<br>rule + LLM-judge]
    Metric --> Compile[DSPy compile<br>instruction + few-shot を最適化]
    Compile --> Gate{"eval gate<br>held-out で baseline 超え?"}
    Gate -->|Yes 昇格| Release[段階リリース<br>shadow / canary / A-B]
    Gate -->|No 却下| Compile
    Release --> Field

signal 源 = 現場の訂正（請求書チェックなら承認/差戻し、調査ツールなら答えへの○×）。ここがループの起点であり燃料。
metric = 良し悪しを1個の数値に変換する関数。rule（形式・必須項目・金額一致）で安く弾き、judge（中身の質）で補う合成が現実的。
gate = held-out で baseline を一定マージン超え＋回帰なしを昇格条件に。
自分の harness 用語との対応: optimizer=proposer / eval gate=checker / registry+rollout=deploy。既存の改善ループのプロンプト版。

2. 現場はプロンプトに触れない（Path A 配信）¶

請求書チェックも経理調査も、現場はツールを使うだけ（アップ／質問）でプロンプトを編集しない。だから最適化成果物（artifact）は裏で差し替わる。「最適化プロンプトをどう現場に伝えるか」という悩みは、この2例では発生しない。

flowchart LR
    subgraph Front["現場が見える範囲"]
        U([現場担当]) --> Tool[ツール UI<br>アップ / 質問]
        Tool --> Out[出力を受け取る]
        Out --> Fix[訂正 / ○×]
    end
    subgraph Back["裏側 platform"]
        Reg[(artifact レジストリ<br>compile済 program v1..vN)]
        Run[ランタイム<br>最新 artifact を load]
    end
    Tool --> Run
    Run --> Out
    Fix -.->|signal| Reg
    Reg -->|artifact 差し替え| Run

artifact = compile の出力（instruction＋選ばれた few-shot を固めた JSON）。人が手で書き換える物ではなく、レジストリに版付きで積みランタイムがロードする。
現場への“伝達”はゼロ。「最近このツール精度上がったね」と感じるだけ。
現場が「この方がいい」と思った直しは、artifact に直接マージせず、signature 編集や seed として同じ eval gate を通す（人の直感もデータ検証してから入れる）。

3. 2つの具体例で芯を確かめる¶

	請求書チェックツール	経理データ調査ツール
現場の操作	請求書をアップする	質問を自然文で打つ
AI の仕事	項目抽出＋ルール/データ照合（重複・金額一致・税率・契約整合）	質問→クエリ変換→集計→出所付きで答える
必要なデータ基盤	請求書(非構造)＋取引先/契約/PO マスタ	仕訳・元帳(構造)＋メタデータ(列の意味)＋lineage
正解(metric)の源	現場の最終判定（承認/差戻し）← rule 寄り	答えの正否＋数値一致 ← rule＋judge
現場の関わり	AI の指摘を訂正（誤検知/見逃し）	答えに○×/言い直し
レジーム	Path A（裏で差し替え）	Path A（裏で差し替え）
最初に着手	◎ metric が作りやすく改善ループを体感しやすい	土台①(metadata/lineage)の重さが先に来る→2本目

4. 事例リサーチ① — 改善ループの実運用¶

Eval 駆動ループ（配管そのもの）¶

Hamel Husain "Your AI Product Needs Evals" — 改善を「①測る(eval)→②デバッグ(トレース閲覧)→③挙動変更」の好循環と定式化。③だけに偏ると詰まる、①②の配管が律速と明言。LLM-as-judge は人手判断との一致率を継続測定しながら使え。 https://hamel.dev/blog/posts/evals/
LangSmith — 「本番トレース→失敗をデータセット化→evaluator→最良の変更だけを versioned release」を製品化。本番の失敗を恒久的な回帰テストに変える。 https://docs.langchain.com/langsmith/evaluation-concepts
Langfuse(OSS) — tracing＋prompt versioning＋eval（LLM-judge / human annotation）を1基盤に。online(本番)と offline(デプロイ前)を同一基盤で。 https://langfuse.com/docs/evaluation/overview

DSPy 本番（artifact 化までやった例）¶

JetBlue × Databricks — metric で最適化した program を MLflow でラップして Model Serving にデプロイ。手動プロンプト調整の破綻を解消。 https://www.databricks.com/blog/optimizing-databricks-llm-pipelines-dspy
Nubank（1億ユーザー規模のサポート AI） — GEPA で judge プロンプト自体を最適化、eval 精度 68.9%→88.9%、5ドメイン本番化。inter-rater κ を測って judge を較正。 https://arxiv.org/html/2606.08867v1
DSPy 本番採用: Shopify / Databricks / Dropbox / JetBlue / Moody's / AWS 等。 https://dspy.ai/community/use-cases/

法務 AI（専門家の正解観を metric 化）¶

Harvey — BigLaw Bench — 実際の billable 業務を positive/negative ルーブリックで採点。「弁護士品質の成果物を何%完成させたか」。どこを human-in-the-loop に残すかの配備判断に使う。 https://www.harvey.ai/blog/introducing-biglaw-bench
Robin AI — LeMAJ — 回答を Legal Data Points に分解し Correct/Irrelevant/Incorrect/Missing でタグ→P/R/F1。弁護士の構造化 annotation を点別 metric に変える配管。 https://robinai.com/news-and-resources/blog/earning-your-confidence-evaluations-at-robin

経理・請求書 AI（訂正を学習に直結）¶

Vic.ai（AP 自動化） — AI が不確実な請求書を human review にフラグ→訂正を捕捉して再学習。recurring vendor は数ヶ月で 95%+ と主張。 https://www.vic.ai/how-it-works
AppZen（経費監査） — 監査担当の承認/却下を一つ一つ学習し自社ポリシーに特化。判断が要る例外だけ人間が介入。 https://www.appzen.com/ai-for-expense-audit

落とし穴（必ず織り込む）¶

judge が単一障害点 — LLM-judge を無検証で使うと goodharting。人手ラベルで judge を較正し続けよ（Evidently / LangChain / Eugene Yan）。最小実装はスプレッドシートで一致率測定。 https://eugeneyan.com/writing/llm-evaluators/
eval set は陳腐化・overfit する — 「better なプロンプトが実利用で悪化」する現象あり。新しい訂正・インシデントを継続的に eval set へ環流させる運用が精度維持の生命線。 https://arxiv.org/pdf/2601.22025

含意: 「現場＝正解を教える人」「本質は訂正→metric→gate→再配信の配管」はベンダー横断の共通設計で裏付く。法務経理でも metric さえ作れれば同じ構造を狙える。

5. 事例リサーチ② — ガードレール（どこまで触らせていいか）¶

問題意識（社内議論より）: エンジニア領域はガードレールが整い高速に走れるが、人事・法務・財務は「データをどこまで AI に触らせていいか」未整備。「どこまで OK か」を会社として明示するのが経営の責任。

エンジニアの「権限・検証・CI/CD」に相当するものを、コーポレートでは データ分類 × リスク階層 × 承認 × 監査証跡で組む。

flowchart TD
    Data[全データ] --> Classify[データ分類<br>Public / Internal / Confidential / Restricted]
    Classify --> Tier{"リスク階層で<br>承認の重さを分岐"}
    Tier -->|Low 要約・ドラフト| Auto[自動承認で速く走る]
    Tier -->|Medium 意思決定に影響| Review[人間レビュー必須]
    Tier -->|High 財務確定・法的分析・人事決定| HITL[上位承認 + human-in-the-loop]
    Auto --> Filter
    Review --> Filter
    HITL --> Filter
    Filter[AI に渡る前のフィルタ<br>ラベル連動マスキング / DLP / PII 除去] --> Tool2[AI ツール<br>closed・学習不使用]
    Tool2 --> Audit[(監査ログ<br>誰がいつ何を)]

制度の枠組み¶

NIST AI RMF — Govern/Map/Measure/Manage の4機能。「どう管理するか」の共通言語（任意・認証なし）。 https://www.nist.gov/itl/ai-risk-management-framework
ISO/IEC 42001:2023 — AI マネジメントの認証可能規格。「やったことを監査人・取引先に証明する」。 ISO 27001 の AI 版。
AI 利用ポリシー(AUP) × データ分類マトリクス — Public は任意ツール可 / Confidential 以上は原則禁止、顧客 PII・財務記録・M&A・人事評価・特権文書は明示禁止。テンプレ: Salesforce AUP / FS-ISAC / SHRM。 https://www.tenable.com/blog/security-for-ai-a-practical-guide-to-enforcing-your-ai-acceptable-use-policy

技術ガードレール（AI に渡る“前”で効かせる）¶

Microsoft Purview — 秘密度ラベル＋DLP で Copilot のグラウンディングを制限、機微情報を含むプロンプトをブロック。ユーザーがアクセス権を持つ範囲しか参照しない。 https://learn.microsoft.com/en-us/purview/ai-microsoft-purview
Google BigQuery 列レベルポリシー / Dataplex / Sensitive Data Protection — 列にポリシータグ→権限に応じ自動マスキング。機微データの所在をプロファイリング。 https://cloud.google.com/security/products/dlp
Amazon Bedrock Guardrails — PII を Block/Mask、複数アカウントへ中央集権適用、サードパーティモデルにも一貫適用。 https://aws.amazon.com/bedrock/guardrails/
実行時レール — NeMo Guardrails（input/dialog/retrieval/execution/output の5レール）、Llama Guard（入出力モデレーション）。 https://github.com/NVIDIA-NeMo/Guardrails
エージェントの最小権限＋承認ゲート＋監査 — 「ID（スコープ付き）→認可（allowlist）→ランタイム（ポリシー強制＋承認ゲート＋証跡）」の3層。 https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html

領域別の勘所¶

法務（特権リスクが現実） — 2026年判例 US v. Heppner 等で「公開生成 AI との対話は弁護士・依頼者特権の対象外＝機密放棄」。closed・学習不使用・弁護士の指揮下なら維持されやすい。 https://perkinscoie.com/insights/update/federal-court-rules-clients-use-generative-ai-not-privileged
財務・経理（内部統制） — COSO/SOX を AI 制御に適用。policy-as-code（事前承認コネクタ・閾値超で人間サインオフ・証跡自動取得）。仕訳テストは標本でなく全件を AI で。説明可能性・監査ログが導入の壁。 https://www.finrep.ai/blog/the-new-sox-how-ai-is-strengthening-internal-controls-over-financial-reporting
人事（最も機微） — 個人データ＋透明性。最終成果物に使う前に人間レビュー必須。採用では「どのデータが使われたか知りたい/決定前に訂正したい」が大多数。 https://www.shrm.org/labs/resources/closing-the-employee-data-trust-gap--practical-guardrails-hr-can-ship-now

含意: 「会社として範囲を明示する」＝ AUP（範囲）＋リスク階層（承認の重さ）＋ RACI（責任分界）の3点セットを経営承認の文書にすること。基盤づくりは概ね4〜6ヶ月。「ダメ」でなく「ここまでは OK」を出すことが現場の恐怖心を消す最大の効果。

6. 改善ループ × ガードレール — 2つは入れ子¶

flowchart LR
    subgraph Guard["ガードレール（範囲の枠）"]
        direction TB
        Loop[改善ループ<br>現場の訂正→metric→gate→再配信]
    end
    Policy[データ分類 + リスク階層 + AUP] --> Guard
    Guard --> Audit2[(監査ログ + 証跡)]

ループはガードレールの内側で回る。 signal を回収する＝現場のデータに触れる、なので「どのデータを・どの階層で・誰の承認で」がループの前提になる。
例: 請求書チェックの訂正ログには取引先・金額（Confidential）が含まれる→signal 回収・学習も分類とアクセス制御の対象。ガードレール無しにループだけ回すと統制が崩れる。
逆にガードレールだけでループが無いと「安全だが改善しない」AI になる。両輪。

7. 最初の一手（縦1本）¶

対象 = 請求書チェックツール（rule 寄りで metric が作りやすく、改善ループを最初に体感できる）。
先にガードレール1枚 — このツールが触るデータ（請求書・取引先・契約マスタ）の分類と「許可/禁止＋承認の重さ」を1枚で明示。closed・学習不使用・監査ログを必須要件に。
ループを最小で回す — 現場の承認/差戻しを signal として回収→rule＋judge の metric→held-out で gate→裏で artifact 差し替え。judge は人手で定期較正、訂正を eval set へ環流。
2本目に経理データ調査（metadata/lineage の土台①が主役）へ展開。

8. 注意点まとめ（事例から）¶

judge(metric)は単一障害点 → 人手ラベルで較正し続ける（最小実装＝一致率をスプレッドシートで）。
eval set は腐る → 新インシデント/訂正を継続環流。「一度作って終わり」にしない。
法務: 公開 AI は特権放棄リスク → closed・学習不使用・指揮者ありを徹底。
財務: SOX 向けに説明可能性＋全操作ログ。仕訳は全件分析が可能になる強み。
注記: Heppner 等の判例は解説記事ベース、Nubank/"When Better Prompts Hurt" は査読前プレプリント。自社適用時は一次情報・専門家確認を。

作成: 2026-06-27 ／最終更新: 2026-06-27