デモは導入そのものではない

デモはサンプル請求書を読み、金額を抽出して整った承認用の要約を投稿します。実際の業務では請求書が3経路から届き、一部は別の法人のもので、承認システムは特定の役割の利用者しか受け付けません。抽出は動きますが、ワークフローは動きません。これは説明用の事例であり、顧客からの報告ではありません。

古い業務システムへの AI 導入に関する対談では、データ、既存ソフトウェア、現場の習慣を導入の難所として挙げます。話者が説明するのは一企業の実践であり、一般的な成功率ではありません。有益なのは、部品の実証と実務への導入を分けることです。

デモは環境を選べる

デモではきれいな入力を選び、アカウントを事前に承認し、待ち行列を省き、失敗した実行をリセットし、作成者が曖昧な出力を説明できます。能力を実証するには妥当な選択です。しかし、能力試験を運用準備の証明と見なすと危険です。

請求書の例では抽出は1手順にすぎません。どの受信箱を正本とするか、重複をどう検知するか、提出後に金額を変更できるか、誰が承認できるか、投稿が失敗したときどこへ送るかを決める必要があります。生成された要約が巧みになっても、これらの問いには答えられません。

作業1件を到着から受け入れまで追うと、境界がよく見えます。

デモの能力 準備済み入力

現場での連携 データ 権限 復旧

担当者の業務 受け入れた結果

実証された能力が役立つ仕事になるには、現場のデータ、権限、復旧が実際の担当者のワークフローにつながる必要があります。

段階	デモの問い	導入の問い
入力	この例をモデルは読めますか？	許可された全形式を受け取り、他を拒否できますか？
文脈	金額を見つけられますか？	正しい仕入先、法人、方針の版と照合できますか？
行動	要約を作れますか？	許可された行動だけを行い、重複を避けられますか？
失敗	発表者が再試行できますか？	誰が停止中の案件を見つけ、修正し、安全に再開しますか？
定着	出力は役立ちそうですか？	責任者は実際の待ち行列で使い、信頼しますか？

この比較は概念上のものです。AI プロジェクトの失敗率を測ったものではありません。

現場の状態を追う

データ連携は最後の工程と呼ばれ、製品完成後につなぐケーブルのように扱われがちです。しかし現場のデータモデルは製品の意味を変えます。請求書が受信箱に届いた時点を「受領」とする企業もあれば、発注書との照合後に初めて数える企業もあります。誤った状態に基づいて行動すれば、技術的に有効な API 呼び出しでも業務上は誤りになります。

各事実の出所と修正権限を持つ人を尋ねます。次に、事実が食い違うときの動作を尋ねます。モデルが承認案を作った後に元記録が変わったら、案を無効にすべきでしょうか。作業が待ち行列にある間に権限が取り消されたら、実行担当は行動前に再確認するでしょうか。これらの問いこそ導入の中身であり、周辺の仕上げではありません。

ワークフロー発見の記事は担当者の実際の行動の観察から始めます。ここでは、実証された能力がそのワークフローで働くには何が必要かを問います。

能力を試作し、その後ワークフローを試す

モデルが中心の仕事をできるか調べるには、小さな試作が最速かもしれません。初日から本番用の統制をすべて備える必要はありません。残る仕事を調べず、軽い仕上げとして予定するのが誤りです。

役立つ試作は境界を明示します。「承認済みの請求書サンプルを読み、項目を提案するが、外部では行動しない」といった形です。次は投稿を無効にしたまま、許可された実際の記録を使えます。データの照合、権限、復旧を理解してから承認システムに書き込みます。各段階が別の問いに答えます。

導入には人の側面もあります。曖昧な請求書を処理してきた人が、提案を修正し、何が変わったかを見て、同じ誤りが繰り返されるか分かる必要があります。新しい業務で確認作業が減るどころか増えるなら、使用状況に現れます。デモの成功から定着を推測してはいけません。

公開の判定基準は運用上の問いにできます。デモ作成者がいない場で、別の権限を持つ担当者が作業1件を完了し、失敗から復旧できますか。その担当者は元の入力を見つけ、提案された行動と権限の根拠を確認し、失敗を適切に振り分けられるべきです。最初の成功だけでは重複や部分的な書き込みは分からないため、戻す手順も試します。既存ワークフローへの AI 導入ガイドには広い展開の枠組みがあります。この判定では試験範囲を狭く保ち、通常経路を壊しそうな例外1つでも繰り返します。

数えるべき結果は生成された出力ではありません。実際の業務で受け入れられ、例外の扱いも明らかな作業1件です。その経路が動くまでは、デモは1つの部品についての有益な証拠です。仕事全体の完了を示す証拠ではありません。