結論: PoC が止まるのは技術ではなく、目的設定・業務接続・成功基準の三点が事前に整理されていないためです。越えるには、PoC 着手前にこれらを明文化する必要があります。
PoC は動くのに、本番に乗らない
公開されている国内の DX 動向調査では、生成 AI 活用について「実証は進むものの本格利用に至っていない」という傾向が継続的に報告されています。PoC を一定数こなした事業者の側にも、そのまま停滞局面に入る層が観察される構造です。これは士業業界に限った話ではなく、業種を問わず広く見られます(ただし本番化に進む割合は規制度合いなどによって業種ごとに差があります)。士業事務所も例外ではなく、伴走前に各事務所の状況をヒアリングしてみると、同様のパターンが繰り返されていることが見えてきます。
PoC が止まる原因は、技術的な精度不足ではありません。主要な商用 AI チャットツールは、業務に組み込む水準には到達しています。失敗してしまうのは、技術ではなく事前準備の構造です。
なお、PoC が本番運用で止まる構造そのものは、当ブログでも AI PoC が本番運用で止まる理由・AIの PoC が「本番稼働しない」本当の理由・PoC が日々の業務に乗らないときに見直したい場面 で扱ってきました。本記事はそれらを踏まえ、「PoC 着手前に明文化しておくべき三点」という事前準備の切り口で再整理し、終了時の判定を機械的に行うための二段階の成功基準まで踏み込みます。以下、士業事務所で観測される典型的な三つの失敗パターンを整理します。
パターン 1:「AI を試してみたい」から PoC が始まってしまうケース
最も多いのが、目的設定が「AI を試してみたい」で止まっているケースです。きっかけは多様で、業界誌で他事務所の事例を読んだ、経営層がセミナーに参加した、ベンダーから提案を受けた、などがあります。どれも自然な動機ですが、そのまま PoC を開始すると、「動くデモを作る」ことが PoC の目的になってしまいがちです。
具体的には次のようなフローが繰り返されます。商用 AI チャットツールで試算表の要約をやってみる→動いた→「これで何ができますか」と関係者に問われる→「業務に組み込めば効果が出るかもしれません」と答える→経営層からは「で、何が変わるのか」と問われる→「もう少し検証期間が必要です」と回答することになります。ここで PoC が止まってしまいます。何度繰り返しても、「動く」と「業務が変わる」の間に橋がかからないままです。
この構造を抜けるには、PoC 着手前に「何が変われば成功か」を業務指標として定義しておく必要があります。例えば、月次決算の平均工数を 30% 削減する、顧問先面談の準備時間を一人あたり週 5 時間短縮する、申告書最終レビューに使う時間を半分にする、といった具体的な目標を、経営層と現場で合意してから PoC を始めます。この合意がない PoC は、動くデモを作るだけのコストとして終わってしまいます。
パターン 2: 業務に踏み込まずに PoC が進んでしまうケース
二つ目のパターンは、PoC が情報システム担当や外部ベンダーだけで進み、実際に業務を回している現場の所員が関与しないままに完了してしまうケースです。完成したシステムは技術的には動作しますが、既存の業務フローと整合しないため、本番展開しても誰も使ってくれません。
士業事務所では、業務フローは事務所ごとに大きく異なっています。月次決算の手順は事務所の伝統と顧問先の業種で決まり、顧問先面談の準備は担当者ごとの暗黙知に依存し、申告書の最終チェックは代表者の判断基準で行われています。これらの暗黙的な業務文脈を踏まえずに PoC を組んでしまうと、出力は出ても現場では「これでは使えない」と判断される結果になりがちです。
例えば、試算表を AI で要約するツールを PoC で構築してみたとします。技術的には動きます。しかし現場の所員が見ると、「ここで触れている数字は、顧問先 X 社では特殊な処理をしているので、一般的な要約では意味を持たない」と判断されることがあります。こうした業務文脈は事前ヒアリングでは出てこないことが多く、実際に使う段階で初めて表面化してきます。結果として、PoC は技術的に成功したが業務には組み込めない、という状態で終わってしまうことになります。
これを避けるには、PoC の設計段階から現場の所員を巻き込み、業務フローの暗黙知を AI に取り込むプロセスを並走させていく必要があります。FDE モデル は、まさにこの統合を一人の責任で持つ役割設計になります。
パターン 3: 成功基準を決めずに PoC が走ってしまうケース
三つ目は、PoC を始める段階で「何が成功か」が定義されていないケースです。パターン 1 と似ていますが、こちらは目的は曖昧でも始まってしまう、という違いがあります。結果として、PoC が終わった後に「これは成功と言えるのか」を判定できません。判定できないため、本番展開の稟議が通らず、PoC のまま放置されてしまいます。
成功基準は二段階で定義しておく必要があります。一段階目は業務指標で、工数削減率、出力品質、所員の利用率、顧問先からの評価といった、PoC 終了時に観測できる指標です。二段階目は組織指標で、PoC で得られた成果を本番展開した場合に、何が経営に貢献するか、という指標になります。例えば、月次決算の工数が 30% 削減できれば、浮いた時間で顧問先を一社あたり 0.5 件追加で対応できる、という形で換算します。
この二段階の指標を PoC 着手前に経営層と合意しておくと、PoC 終了時の判定が機械的に行えるようになります。業務指標を達成→本番展開の稟議へ。業務指標を達成できないが原因が特定できる→PoC のスコープを調整して継続。業務指標を達成できず原因も不明→PoC を中止して別のアプローチを検討。この三択を事前に合意しておくと、PoC が漂流しなくなります。
PoC を越えるための三つの前提条件
PoC を本番展開につなげるには、着手前に三点を明文化しておく必要があります。業務指標で表現された具体的な目標(「業務効率化」ではなく「月次決算の工数を 30% 削減」のような数字)、現場の所員が PoC 設計に関与する体制(情報システム担当やベンダー単独では業務文脈が抜け落ちる)、そして PoC 終了時の判定基準と次のアクション(業務指標の達成度に応じた三択の事前合意)。この三点が揃っていない PoC は、動くデモを作るコストとして終わります。
これらは技術より組織の話になります。だからこそ、PoC を越えられるかどうかは、ベンダーの提案力ではなく、事務所側の事前準備で決まる。伴走の最初に時間をかけるのも、この三点の整理になります。関連して AI 導入で最初にレビューすべき業務フロー で、業務指標を設定する具体的なチェックリストを公開しています。
初回相談で確認できること
自事務所の PoC が止まっている場合、三つのパターンのうちどれに該当しているかを 60 分の初回相談で整理することが可能です。受注前提ではなく、整理だけして社内検討に戻していただく形でも構いません。まずは現状を客観視するための時間として活用いただければと思います。