第0章 PoCの死の谷
中小企業においても、AI（人工知能）や業務自動化の PoC（概念実証）は増えている。しかし、経理をはじめとする実業務への本番接続まで到達する事例は限られる。本章は、経営者・業務責任者・情報システム担当者が共通言語で議論できるよう、PoC が「死の谷」で止まる構造要因と、本番接続に耐える設計原則を整理する。数字はすべて仮説・要実測であり、効果を保証するものではない。税務・会計・法律・投資の助言ではない。
30秒役員要約
- PoC の失敗の多くはモデル精度ではなく、評価指標の未定義・データ権限の未整理・HITL（人が最終判断に入る設計）の欠如・監査証跡の不足に起因する。
- 「デモで動く」と「経理の本番フローに載る」は別問題である。本番接続には、責任分界・承認ゲート・コスト上限の事前設計が不可欠である。
- HITL は段階的に自動化範囲を広げても、最終段階でも Human Approval Gate（人による承認ゲート）を残し、閉鎖してはならない。
- 本番接続前に、短縮分×件数などの測り方で ROI（投資対効果）を仮説として置き、実測で検証する。時給・OpEx（運用経費）はオーダー感の示意に留め、仮説・要実測と明示する。
- 監査・内部統制の観点では、Zero Data Retention（業務データ・試算入力を学習・二次利用のために保管しない）、Audit Trail、Token Capping、Human Approval Gate は、読者側の本番接続における設計原則である（本サイトの機能提供宣言ではない）。
- 本章の次ステップは、経理シナリオ（適格請求書照合 → 三点照合 → 経費精算）への具体接続である。
現場視点 / アーキテクト視点（双軌）
現場視点（経理・業務担当）
現状
経理現場では、請求書の突合、仕訳の確認、経費精算のチェックといった反復作業が日常である。PoC では「請求書の文言を読める」「類似案件を提案できる」といったデモが示されることが多い。しかし現場が求めるのは、既存の承認フロー・勘定科目体系・締めスケジュールとの両立である。デモ画面と本番の画面・権限・例外処理が一致しないまま試行が終わると、「面白いが使えない」という評価に収束する。
また、誤判定が起きたときの責任の所在が不明確なままでは、現場はエージェント（業務を代行・提案するソフトウェア）の出力を信頼して採用できない。人が最終確認する設計が明示されない限り、現場は従来どおり手作業を維持する合理的判断を取る。
設計示唆
- PoC の評価対象を「正答率」だけでなく、「既存フローへの埋め込み可否」「例外時のエスカレーション手順」「締め日までの処理完了可否」に拡張する。
- 現場が許容できる誤判定の種類と、人による再確認が必須なケースを事前に列挙する。
- 出力には根拠（参照した請求書項目・マスタ・ルール）を併記し、現場が短時間で検証できる形にする。
アーキテクト視点（情シス・推進・基盤）
現状
情シス・推進側では、PoC 環境と本番環境のギャップが過小評価されがちである。検証用のサンプルデータ、緩い権限、監査ログの簡易実装で「成功」と判定しても、本番では ID 管理、権限分離、ログ保管期間、ベンダー契約上のデータ取り扱いが障壁となる。また、LLM（大規模言語モデル）呼び出しのトークン費用や再試行コストが、件数増加に伴い想定外の OpEx となるケースがある。
技術選定が先行し、業務プロセスの再設計が後回しになると、エージェントは「便利なチャット」に留まり、経理システムのトランザクション（仕訳・照合結果の確定）には接続されない。
設計示唆
- 本番接続の前提条件（権限モデル、Audit Trail、データ保持方針、Token Capping）を PoC 開始前にチェックリスト化する。
- 評価指標は業務 KPI（例：照合完了までの時間、差戻し率）と運用 KPI（例：トークン消費、人承認待ち時間）を併記する。
- エージェントの出力は「提案」に限定し、確定操作は Human Approval Gate 経由でのみ実行する設計を既定とする。
現場で起きる対立
以下は、経理現場担当と情シス／推進担当のあいだで繰り返し生じる摩擦の例である（架空の対話）。
経理現場： 先月の PoC、請求書の読み取りは確かに速かった。でも、うちの承認ルートと勘定科目の例外ルールが入っていない。本番で使ったら、月末に差戻しが爆発する。
情シス／推進： 例外ルールは次フェーズで入れる想定です。まずは正答率 90% を目標にしています。（誤った目標設定の例）
経理現場： 正答率の分母は何ですか。サンプル 50 件のうち、うちが普段扱う「海外関連・値引き・複数税率」は何件入っていましたか。そこに載っていないなら、現場の成功基準になっていない。
情シス／推進： …検証セットはベンダー提供の標準サンプルが中心でした。実データでの再評価は、個人情報と取引先情報の取り扱いが未整理で止まっています。
経理現場： それで「本番準備完了」と言われても困る。誤った仕訳候補を誰が止めるのか。止まらなかったときの責任は誰か。人が最終承認しないなら、監査に説明できない。
情シス／推進： HITL は入れる方針です。ただし、毎回人が全部見るなら効果が薄い、という社内の声もあります。
経理現場： 効果が薄いのではなく、人の見る範囲を設計していないだけです。定型はエージェント、例外と確定は人、と分けてください。締め前に人の承認キューが溢れる設計は、現場としては受け入れられない。
情シス／推進： 了解しました。次は実データでの評価指標、権限、承認ゲート、監査ログをセットで設計し直します。数字の効果は仮説・要実測として、現場と合意した測り方で検証します。
現状分析：PoC が止まる典型要因
PoC が本番導入に到達せず停止する要因は、単一の技術欠陥ではなく、以下の構造が複合して発生する。
1. 評価指標の未定義・ズレ
- デモ向けの正答率・体感速度が主指標となり、締めスケジュール遵守・差戻し率・監査指摘件数など業務指標が欠落する。
- 「成功」の定義が推進側と現場側で共有されないまま終了判定が行われる。
2. データ品質・代表性の不足
- 標準サンプルのみで評価し、例外パターン（複数税率、値引き、部分請求、海外取引など）が未カバー。
- マスタ不整合・履歴データの欠損が本番で顕在化し、PoC 時の精度が再現されない。
3. 権限・セキュリティ境界の未整理
- PoC 環境では広範な参照権限が許容されても、本番では職務分離・最小権限が必須。
- 外部モデルへのデータ送信可否、保管期間、再学習への利用禁止が契約・ポリシー未確定のまま進行する。
4. HITL の欠如または形骸化
- 「人が見る」と書いてあっても、承認画面・差戻し理由の記録・エスカレーション経路が実装されていない。
- あるいは、人承認を省略する圧力により、ゲートが実質無効化される。
5. コストの見えにくさ
- トークン課金、再生成、人手による後工程修正が OpEx として積み上がる。
- PoC 期間の無料枠・低件数が、本番件数でのコスト構造を隠蔽する。
6. 監査・内部統制への接続不足
- 誰が・いつ・何を根拠に承認したかの Audit Trail が残らない。
- 変更管理・アクセスログ・例外処理の記録が、既存の内部統制プロセスと接続されない。
これらの要因は相互に強化する。指標がズレれば現場は採用せず、採用されないため実データが集まらず、権限と監査の設計も後回しになり、最終的に「次年度再検討」で棚上げされる。これが PoC の死の谷の典型経路である。
Human-in-the-loop（HITL）の4段階 — 自動化の広げ方
HITL は「人がたまに確認する」ことではなく、自動化の段階を明示し、最終段階でも Human Approval Gate を残す設計である。HITL は閉鎖不可とする。
なお、各成熟度段階の中で、単一件の作業循環として「下書き生成 → 例外の提示 → 承認（Human Approval Gate）→ 記録（Audit Trail）と Token Capping」を回す（適格請求書照合ページと同じ4段階）。
| 段階 | 名称 | エージェントの役割 | 人の役割 | 本番接続上の位置づけ |
|---|---|---|---|---|
| 段階1 | 補助・下書き | 文書の要約、項目抽出、候補リスト提示 | 全件を人が確認・編集・確定 | 学習・評価フェーズ。確定権限は人のみ |
| 段階2 | 条件付き提案 | 定型条件を満たす案件に提案を生成 | 例外・低信頼度を重点確認。定型も承認必須 | 信頼度しきい値は仮説・要実測 |
| 段階3 | 準自動＋例外抽出 | 定型を一括提案し、例外のみキュー化 | 例外対応と、バッチ確定前の承認 | 件数増加時も承認キュー設計が必須 |
| 段階4 | 運用組込み | 業務システム連携で提案を連続生成 | Human Approval Gate による最終承認を維持。監査照会対応 | ゲート閉鎖不可。確定操作は人承認後のみ |
設計原則（全段階共通）
- エージェントは「確定」せず「提案」する。仕訳の確定、照合の完了、支払指示の発行などは、人の承認後にシステムが実行する。
- 信頼度スコアや例外フラグは補助情報であり、人承認の代替ではない。
- 段階を上げる条件は、事前に合意した業務 KPI・運用 KPI の実測結果に基づく（仮説のまま段階移行しない）。
責任分界表
| 領域 | 人（業務・承認者） | エージェント | システム（基盤・業務アプリ） |
|---|---|---|---|
| 業務判断の最終責任 | 最終承認・差戻し・例外判断 | 候補提示・根拠提示・例外フラグ付与 | 承認結果の記録・ワークフロー制御 |
| データ取扱い | 取扱範囲の業務判断、機微情報の取扱指示 | 許可された範囲内での参照・加工提案 | アクセス制御、暗号化、保持／削除方針の執行 |
| 出力の正確性 | 提案の採否、誤りの訂正 | 抽出・照合・要約の実行（保証なし） | 入出力ログ、版管理、再実行制御 |
| 監査対応 | 判断理由の説明、証跡の業務的意味付け | 参照根拠の提示（可能な範囲） | Audit Trail の保管および、改ざんの検知を検討し得る記録の保管・照会手段 |
| コスト管理 | 件数・優先度の業務判断 | トークン消費の発生源（呼び出し） | Token Capping、予算アラート、利用量レポート |
| インシデント対応 | 業務影響判断・対外説明 | 停止指示に従った処理中断 | キルスイッチ、権限剥奪、ログ保全 |
補足：エージェントの出力品質に関する数値的効果は仮説・要実測であり、本章は効果を保証しない。責任分界は組織の職務権限規程・内部統制に合わせて調整する。
ROI デフォルトパラメータ説明
なぜ本番接続前に測る必要があるか
PoC の体感速度や少数サンプルの正答率だけでは、本番の費用対効果は判断できない。本番接続前に、(1) 何を短縮するのか (2) 件数がいくらか (3) 人件費・OpEx のオーダー感 (4) 人承認の残コスト を仮説として置き、実測で検証する枠組みが必要である。測らずに段階を上げると、コストと監査リスクが後から顕在化する。
示意パラメータ（すべて仮説・要実測）
以下はオーダー感の示意であり、採用値ではない。必ず実測で置き換えること。
| 項目 | 示意（仮説・要実測） | 使い方 |
|---|---|---|
| 業務担当の時給換算 | 例：3,000 円／時間（仮説・要実測） | 短縮時間 × 時給で人件費インパクトの概算 |
| エージェント／基盤の OpEx | 例：月 5,000 円級のオーダー感（仮説・要実測。件数・モデル・再試行で変動） | 固定＋従量の合計として並記 |
| 測り方の基本式 | 短縮分（分）× 件数 × 時給換算 − OpEx − 人承認コスト | 分子・分母の定義を現場と合意してから計測 |
経理3ユースケースへの橋渡し（測り方のみ）
本章では経理の3ユースケースへ進む前提として、次の測り方を共通化する（数値の効果は示さない。仮説・要実測）。
- 適格請求書照合
1件あたりの照合・確認に要する時間の短縮分 × 月間件数。差戻し再作業時間も別計測する。 - 三点照合（発注・検収・請求の突合）
突合完了までの時間短縮分 × 対象件数。不一致検知後の人対応時間は削減対象から除外するか、別ラインで計測する。 - 経費精算
申請内容の一次チェック時間の短縮分 × 申請件数。最終承認時間は Human Approval Gate 残存コストとして明示する。
いずれのユースケースでも、ROI 算出に用いる数字は仮説・要実測とし、効果を保証しない。
監査チェックリスト
内部監査・内部統制担当が、AI／自動化の PoC から本番接続を評価する際の確認項目例。
A. 目的・範囲
B. データ・権限
C. HITL・責任
D. 監査証跡・運用
E. 変更管理
コンプライアンス上の遵守事項
本章および以降の経理シナリオ設計において、以下を越えてはならない境界とする。
禁止
- 根拠不明な資格・基準への準拠主張
- 効果・精度・ROI の保証表現
- 幻の認証・幻の準拠（実態のない適合宣言）
必須言及・必須設計
- Zero Data Retention：業務データおよび試算の入力は、学習・二次利用のために保管しない。アクセスログや承認記録まで「存在しない」という意味ではない。
- Audit Trail（監査証跡）：誰が何を承認したかの記録
- Token Capping（トークン上限）：費用と濫用の制御
- Human Approval Gate（人による承認ゲート）：確定操作前の人承認。HITL は閉鎖不可
- 仮説・要実測：すべての数値・効果表現に付す条件。効果保証は行わない
技術アーキテクチャの独自拡張や、経理以外の業種への適用拡大は本章の範囲外とする。
次ステップ CTA：経理シナリオへ
PoC の死の谷を越えるには、抽象論ではなく、経理の具体フローに HITL・責任分界・監査要件を接続する必要がある。次章以降では、次の順で场景を展開する。
- 適格請求書照合 — 記載要件・税率・取引先の突合を、提案＋人承認で設計する
- 三点照合 — 発注・検収・請求の不一致を例外キュー化し、Human Approval Gate で確定する
- 経費精算 — 一次チェックの自動化範囲と、最終承認に残す人の判断を分界する
各ユースケースでは、本章の評価指標・ROI の測り方（短縮分×件数）・監査チェックリスト・コンプライアンス上の遵守事項を共通前提として引き継ぐ。数字は引き続き仮説・要実測とし、効果は保証しない。
行動喚起： 役員会・情シス・監査は、次の経理シナリオに進む前に、本章の責任分界表と HITL 4段階、監査チェックリストの自社版を確定すること。自社で入口条件を確定すること（本章は情報提供であり、認証・準拠の判定ではない）。