%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
AI PoCは、AIが動くかを試すだけの企画ではありません。評価基準を開始前に定め、本番移行の条件から逆算して小さく検証することが核心です。
AI PoCは、AIが動くかを試すだけの企画ではありません。評価基準を開始前に定め、本番移行の条件から逆算して小さく検証することが核心です。
「AIで何かできないかと言われたものの、何から検証すべきかわからない」「試作品は動いたが、投資を続ける判断材料がない」「現場では使えたのに、本番環境へ移せない」——こうした状態は、技術よりもPoCの設計に原因があるケースがあります。
AI PoCとは、AIを使った施策が技術面と業務面の両方で成立するかを、限定した範囲で検証する取り組みです。解決したい業務課題、評価方法、本番移行後の運用をひとつの流れとして設計します。開始前に「何を確認できれば進めるか」と「何が残れば止めるか」を決めておくと、結果を次の判断に使えます。
関連する記事の一覧はAI経営・戦略ガイドをご覧ください。
この記事でわかること
AI PoCの企画や評価を担当する方に向けて、対象業務の選定から本番移行まで、各段階で決めることを順番に整理します。現状との比較方法、結果が分かれたときの判断、未達項目の見直し方を確認しながら、自社の検証計画に落とし込めます。
- PoCが途中で止まる原因 — 目的、評価基準、データ、実施環境、推進体制のどこで問題が起きやすいかを整理します。
- 検証するユースケースの選び方 — 業務への影響、実現可能性、測定可能性を使って候補を比較します。
- 評価基準の設計方法 — 技術精度だけに偏らず、業務効果、運用性、利用者評価を組み合わせます。
- Go、Conditional Go、No-Goの判断方法 — 結果に応じて本番移行、追加検証、見直しを選ぶ基準を解説します。
- CRMデータを使った本番移行の考え方 — PoCで使ったデータを、その後の営業や顧客対応へつなげる方法を説明します。
AI PoCとは何を判断する取り組みか
AI PoCでは、試作品が動いたかだけでなく、対象業務に導入する価値があるかを判断します。技術、業務、運用の評価を分け、それぞれの結果を投資判断へつなげます。最初に判断対象を明確にすると、検証範囲が広がったときも、今回扱うべき課題かどうかを見分けられます。
実験ではなく投資判断の材料を作る
PoCの成果物は、AIの画面やデモだけではありません。導入前の業務と比較できる測定結果、利用者の評価、残された課題、本番移行に必要な対応をまとめた判断材料までが成果に含まれます。
例えば、回答を生成できたとしても、担当者による修正が多く、既存業務より確認負荷が増えるなら、そのまま本番へ進める状態とはいえません。反対に、精度に改善余地があっても、利用範囲を限定すれば業務に組み込める場合は、条件付きで次へ進む選択肢があります。
判断資料には、良好だった結果と失敗した場面を同じ方法で記録します。記録ごとに、対象業務、入力の状態、期待した結果、実際の結果、人による修正、最終的な処理結果を対応付けます。失敗を除いた結果だけでは、本番で誰が確認し、どの例外を人へ戻す必要があるかを決められません。
判断会議では、まず主要基準に必要な記録が揃っているかを確認します。揃っていれば結果を評価し、欠けていれば不足した利用場面を特定します。記録の不足と基準の未達を分けることで、「測れていない状態」を成果不足として扱ったり、良好な一部の結果で埋め合わせたりせずに済みます。
判断資料には、評価項目ごとに次を並べます。
- 確認した利用場面
- 結果
- 残る条件
- 次に行うこと
例えば通常の問い合わせで結果が良好でも、情報が欠けた問い合わせを試していなければ、その場面の扱いは未確認です。追加で試せるなら検証し、試せないなら適用範囲から外して移行判断を行います。
このとき、結果のよかった場面だけをまとめず、本番で発生するが検証できなかった場面も別に示します。その場面を人が処理できるなら、担当者と引き渡し方法を移行条件にします。人による処理方法も決められないなら、対象範囲を広げる判断を保留します。
技術検証と業務検証を分ける
技術検証では、必要なデータを入力できるか、期待する形式で結果を返せるか、既存システムと連携できるかを見ます。業務検証では、処理時間、作業手順、確認負荷、利用者の使いやすさがどう変わるかを見ます。
| 検証領域 | 主な問い | 次へ進める状態 |
|---|---|---|
| 技術 | 必要な入力から期待する出力を得られるか | 主要な利用場面で再現できる |
| 業務 | 現在の業務課題を軽減できるか | 導入前後の差を説明できる |
| 運用 | 担当者が継続して扱えるか | 責任者と対応手順が決まっている |
| 投資 | 継続する価値を判断できるか | 効果と必要コストを比較できる |
技術面だけが良好でも、業務上の使い道や運用責任が曖昧なら、本番移行の判断はできません。各領域の評価を同じ資料にまとめ、達成済み、未達、測定できなかった項目を分けて示します。測定できなかった項目が導入判断に必要なら、良好な項目だけでGoとは判定しません。
領域ごとに結果が異なる場合は、未達がどの作業に影響するかを追います。出力形式の問題なら設定を見直して再測定できます。一方、出力を受け取る担当者や承認手順が決まっていないなら、技術評価を繰り返す前に業務の流れを決める必要があります。
投資の評価では、利用料だけでなく、設定、担当者の確認、例外対応、運用後の見直しに必要な作業を洗い出します。効果として示す作業も同じ範囲で比較します。必要な作業を見積もれない段階では費用対効果を断定せず、運用手順を確かめてから判断します。
例えば作業時間の変化を投資判断へ使うなら、短縮された作業と新たに発生した確認・修正・記録の作業を同じ業務範囲で並べます。確認作業の担当者が未定なら、その作業を「発生しないもの」として扱わず、担当と手順を決めてから比較します。
比較結果を読む順序も決めておきます。まず、顧客対応などに影響する失敗を検知して止められるかを確認します。次に、確認や修正を含めた業務全体の負担を比べます。両方を確認できて初めて、継続に必要な作業と得られる効果を並べます。前の条件が未確認なら、後の項目が良好でも移行判断に進みません。
本番移行後の姿から逆算する
検証を始める前に、AIの出力を誰が受け取り、どの業務で使い、どのシステムへ記録するのかを描きます。PoC終了後の流れが見えていれば、試験環境だけで成立する機能に時間を使いすぎる事態を避けられます。
自動化する範囲と人が判断する範囲も、この段階で分けます。AIの出力をそのまま実行するのか、担当者の確認後に反映するのかによって、必要な評価項目や承認手順が変わるためです。確認者と記録先を決められない場合は、出力の品質を測る前に業務の受け渡し方法を整理します。
想定する運用を、入力の取得、AIによる処理、担当者の確認、承認、記録、例外時の対応まで順にたどります。各地点で担当者と記録先を示せない場合は、その部分を移行前の課題として残します。試験中も同じ流れを通しておけば、出力単体の評価と業務全体の評価を混同しません。
手順を描いたら、途中で入力が欠ける場合と、出力が承認されない場合もたどります。誰が処理を止め、何を確認し、どこへ記録を戻すかを決められれば試験へ進めます。決められなければ、例外時の運用を設計してから評価範囲を確定します。
PoCが途中で止まる主な原因
PoCが止まる背景には、目的の曖昧さ、評価基準の欠如、データ不足、本番環境との乖離、推進者の不在があります。これらは個別の問題に見えますが、「何を判断するPoCなのか」が共有されていないことから連鎖します。開始前に原因と対策を対応付け、問題が起きたときに検証を続けるか、準備へ戻るかを決めます。
目的と評価基準が結び付いていない
「AIを使うこと」が目的になると、機能を試す範囲が広がり、結果を評価できなくなります。目的は「どの業務の、どの負担や品質課題を変えたいか」という形で表現します。
| 起こりやすい状態 | 設計時の対策 | 判断の分かれ目 |
|---|---|---|
| 試したい機能が増え続ける | 対象業務と対象外業務を明記する | 対象外の要望は次の検証候補へ回す |
| 結果を見て基準が変わる | 開始前に評価項目を合意する | 基準変更が必要なら同じPoCの合否には使わない |
| 関係者ごとに成功像が違う | 経営、現場、技術の期待を分ける | 共通して判断できる項目だけを主要基準にする |
目的と基準を一文で結べない場合は、検証対象が広すぎる可能性があります。「対象業務にAIを導入するか判断するために、何を測るか」まで言語化してから実施へ進みます。途中で新たな要望が出た場合は、今回の判定に必要な変更かを確認し、対象外なら別の検討事項として記録します。
関係者の意見が分かれたときは、まず「改善したい業務」と「許容できない失敗」をそれぞれ確認します。前者から業務効果の評価項目を、後者から本番移行を止める条件を作ります。どちらかについて合意できないまま試験を始めると、結果を見ても判断が分かれるため、開始前に決め直します。
例えば現場が確認負荷の軽減を求め、経営側が処理の速さを重視するなら、完了までの時間と確認・修正に要した作業を分けて測ります。どちらか一方の改善だけで導入を決めるのか、両方を必要条件にするのかも事前に合意します。
データと実施環境が本番から離れている
整えすぎたサンプルデータだけで検証すると、表記揺れ、欠損、重複といった本番データの問題が評価から抜けます。反対に、準備されていないデータをそのまま使うと、AIの能力ではなくデータ不備だけを測る結果になりかねません。
まず、利用可能なデータ、欠けているデータ、PoC前に整備するデータを分けます。そのうえで、本番でも再現する揺れは検証対象に残し、入力ミスなど事前に修正すべき問題は分離します。どの記録を除外し、なぜ除外したかを残せば、都合のよいデータだけで評価することを避けられます。
データを選ぶ際は、通常の処理ができる記録だけでなく、入力が欠けている記録、判断が分かれる記録、人へ引き渡すべき記録も識別します。それぞれについて、PoCで評価するのか、対象外にするのか、事前に修正するのかを決めます。対象外にした記録が本番では発生するなら、その扱いを移行条件に残します。
実データの利用が難しい場合は、匿名化したデータで業務手順を検証し、実データへ切り替える前に再確認する項目を一覧化します。匿名化によって失われた項目が判断に影響するなら、その結果だけで本番移行を決めず、追加検証へ進みます。
記録の除外理由を確認するときは、「本番でも対象外にできる条件か」を業務責任者に確かめます。本番では受け付ける入力を試験から除いたなら、その入力を人へ渡す方法を試すか、移行判断を保留します。試験用の整備だけで消えた問題は、本番の入力手順でも防げることを確認してから解消済みとします。
推進者と本番移行の担当が決まっていない
PoCの実施担当と、本番移行後の運用担当が別の場合、検証結果が引き継がれないことがあります。開始時点で、業務責任者、技術担当、利用者、最終判断者の役割を分けておく必要があります。
役割分担は、担当者の熱意だけに依存させず、会議、記録、承認、問い合わせ対応の流れとして仕組み化します。担当者が変わっても、目的、設定、評価結果、残課題を追える状態にします。本番の運用担当が未定なら、PoCの結果を評価することはできても、移行のGo判定は保留します。
引き継ぎでは、設定の説明だけでなく、「どの入力なら使うか」「どの出力なら人へ戻すか」「問題が起きたら誰が判断するか」を運用担当と一緒に確認します。担当者が試験結果を見て同じ判断を再現できなければ、手順を明確にしてから移行を判断します。
運用担当が決まっていても、例外対応を試していなければ引き継ぎは完了しません。試験中に生じた修正や差し戻しの記録を使い、担当者が原因の確認から処理の再開までたどれるかを確かめます。たどれない箇所があれば、手順か記録の残し方を直して再確認します。
AI PoCのユースケースを選定する方法
最初のPoCには、効果を説明しやすく、必要なデータを準備でき、結果を測定できる業務を選びます。経営への影響が大きくても、データや担当部門の協力を得られない業務は、最初の検証には向きません。候補を同じ評価軸で比較し、小さく始められる範囲へ絞ります。
現在の手作業から課題を見つける
スプレッドシート、メール、紙の記録に情報が分かれ、転記や集計を人が行っている業務は、検証候補を探す出発点になります。まず業務の開始から完了までを書き出し、入力、判断、転記、確認、報告のどこに負担があるかを分けます。
AIを先に置くのではなく、現在の作業で発生している待ち時間、確認の重複、入力漏れ、判断のばらつきを確認します。そのうえで、分類、要約、下書き、情報検索など、AIに任せる処理を限定します。課題の原因が入力ルールの不統一なら、AIの設定より先に業務ルールを揃える必要があります。
候補を挙げたら、作業の発生条件と完了条件を言葉にします。同じ名称の業務でも、担当者によって含める確認作業が異なるなら、比較前に範囲を揃えます。揃えられない場合は別の業務として扱い、それぞれの測定方法を決めます。
候補を絞る際は、負担の大きさだけでなく、原因を切り分けられるかも見ます。転記に時間がかかる業務でも、元の情報が欠けているなら、転記の自動化だけでは完了しません。まず入力を整えれば解決する課題か、情報が揃った後も残る課題かを確認します。
共通の選定軸で候補を比較する
候補ごとに評価方法を変えると、担当者の期待が高い企画だけが優先されやすくなります。業務への影響、実現可能性、測定可能性、運用への組み込みやすさを共通の軸として比較します。
| 評価軸 | 評価する内容 | 優先しやすい状態 |
|---|---|---|
| 業務への影響 | 解消したい負担や品質課題 | 対象業務と期待する変化を説明できる |
| データ | 入力に使う情報の所在と品質 | 必要なデータへアクセスできる |
| 技術 | 既存ツールで検証できる範囲 | 独自開発を始める前に試せる |
| 測定 | 導入前後を比べる方法 | 現状値と検証後の値を同じ方法で取れる |
| 運用 | 現場で使う手順と責任者 | 利用者と確認者が決まっている |
各軸の評価理由を文章で残すと、優先順位の説明がしやすくなります。例えば、業務への影響が大きい候補でも、現状の作業記録がなく比較方法を決められないなら、記録方法の整備を先に行います。必要なデータと利用者が揃い、現行手順と比較できる候補をPoCへ進めます。評価が低い候補は、データ整備や業務整理を終えた後の検討事項として管理します。
候補の比較では、各軸を漠然と「高い」「低い」と評価する前に、その根拠となる業務記録や担当者を示します。根拠を示せない軸が導入判断を左右するなら、候補を選ぶ前に確認します。複数の候補が残った場合は、現状を測れ、人による確認まで一巡できる候補から検証します。
候補の優先順位で迷ったら、欠けている条件が準備で解消できるかを調べます。現状の作業記録だけがないなら、記録方法を決めてから比較できます。一方、期待する出力について業務責任者が合意できないなら、測定を始めても合否を決められません。その場合は業務ルールの整理を先行し、合意できた時点で選定し直します。
選定結果には、選んだ理由と見送った理由を同じ軸で残します。見送った候補も、欠けていたデータや担当者が揃えば再比較できます。選んだ候補に未解決の条件がある場合は、PoCで確かめる条件なのか、開始前に満たす条件なのかを分けます。
スモールスタートの範囲を決める
最初から部門全体を対象にせず、業務の一部、限定したデータ、協力を得られる利用者から始める方法をおすすめします。範囲を絞る目的は、見栄えのよい結果を作ることではなく、原因を切り分けられる状態で学ぶことです。
対象を狭めるときは、業務の途中だけを切り出して前後の流れを失わないようにします。例えば、AIが下書きを作る部分を検証するなら、元データの取得、担当者の確認、承認後の記録までを含めて評価します。利用するデータの種類、扱う例外、確認者を先に固定しておけば、検証途中で範囲が変わった場合も結果を分けて読めます。
範囲を決めたら、含めない業務やデータも明記します。試験中に対象外の依頼が発生したときは、今回の評価へ混ぜず、本番移行時に追加確認が必要な条件として記録します。限定した範囲で良好な結果が出ても、対象外の条件まで同じ結果になるとは判断しません。
対象範囲を確定する前に、実際の運用でその範囲だけを切り分けられるか確認します。担当者が入力時点で対象を見分けられないなら、限定運用の手順を先に決めます。見分ける方法を用意できない場合は、対象の定義を見直してから試験へ進みます。
AI PoCの評価基準を設計する
評価基準は、結果を見てから決めるのではなく、PoC開始前に合意します。主要基準と補助基準を分け、どの結果なら本番移行、追加検証、見直しへ進むのかを対応付けます。技術精度だけでなく、業務効果と運用負荷を同時に評価します。
業務、技術、運用の指標を組み合わせる
評価項目が精度だけだと、現場で使えるかどうかを判断できません。業務の変化、出力品質、利用者の受け入れ、運用に必要な確認作業を組み合わせます。
| 評価カテゴリ | 確認すること | 評価結果の使い方 |
|---|---|---|
| 業務効果 | 処理時間や手作業がどう変わったか | 継続投資の価値を判断する |
| 出力品質 | 求める内容や形式を満たしたか | 利用できる業務範囲を決める |
| 利用者評価 | 使いやすさと修正負荷はどうか | 操作や業務手順の改善に使う |
| 運用性 | エラー時の対応や責任分担が回るか | 本番運用の体制設計に使う |
| コスト | 利用料、設定、保守に何が必要か | 業務効果と比較して判断する |
主要基準には、導入判断を左右する項目を置きます。補助基準には、改善によって解消できる項目を置き、主要基準の未達と同じ扱いにしないようにします。例えば問い合わせの分類なら、誤分類が顧客対応へ影響する場面を主要基準として扱い、表示のわかりにくさなど、手順の調整で改善できる項目を分けて評価します。
評価項目ごとに、記録する担当者、記録を残す場所、確認する利用場面を決めます。出力品質が良くても人への引き渡しに失敗すれば業務上は使えないため、関連する項目を一緒に確認します。評価結果は項目ごとに示し、ひとつの印象で全体の判定を代用しません。
主要基準を決める際は、「その項目が満たされなければ、どの業務を止めるか」を問いにします。止めるべき業務があるなら、その条件を補助基準の改善予定だけで扱わず、移行の判定条件に含めます。表示方法などを変えれば解消できる課題は、変更担当者と再確認方法を決めて補助基準として管理します。
各基準には、合格とする状態に加え、判定に必要な記録を対応付けます。例えば「担当者が誤分類を検知できる」を条件にするなら、正しい分類結果だけを集めても判定できません。誤分類を見た担当者が、何を根拠に気付き、どこへ差し戻したかまで確認します。該当する場面を試せなければ、達成ではなく未確認として扱います。
基準値は現在の業務を測ってから決める
基準値は他社の数値をそのまま使わず、自社の現在値と目的から決めます。まず、対象業務の開始と終了、扱う入力、確認する担当者を定義します。そのうえで現状の処理時間、確認回数、差し戻しの発生状況などを記録し、PoC後と比較できるようにします。現状を測れない項目は、推測した値で埋めず、記録方法を整えてから判断基準に使います。
比較する前に、作業の開始と終了、担当者による確認、修正、差し戻しをどこまで含めるかを決めます。現行業務では確認時間を含め、PoCではAIの出力時間だけを数えると、業務全体の負担を比べられません。対象となる業務の種類や難しさも揃え、条件が違う結果は分けて示します。
例えば問い合わせの分類を比べるなら、現行業務もPoCも「問い合わせを受け取ってから、担当者が分類を確認し、次の担当へ渡せる状態になるまで」を同じ作業範囲にします。分類結果を出すまでの時間と、確認・修正を終えるまでの時間は分けて記録します。前者だけが改善して後者が重くなった場合は、業務効果が得られたと判定せず、修正が必要になった入力や分類条件を調べます。
この例では、評価表の各記録に次の項目を対応付けます。
- 入力の状態
- AIが示した分類
- 担当者が確定した分類
- 修正した理由
- 次の担当へ渡せたか
現行業務ではAIによる分類の欄を設けず、担当者が確定するまでの作業を同じ開始点と終了点で記録します。比較できる記録が揃ったら、まず誤分類を担当者が検知できたかを確認し、その後に完了までの負担を比べます。検知できない誤りが残るなら、作業が早くなっていても移行を保留します。
測定する記録には、対象業務の種類、入力情報の状態、作業者が行った確認と修正、完了までの流れを残します。現行業務とPoCで同じ種類の記録を対応付けられるなら、その差を確認します。対応付けられない場合は、業務の種類や入力条件ごとに分けて読み、条件の違いを効果として説明しないようにします。
記録を見直すときは、通常の入力、情報が欠けた入力、判断が分かれた入力を区別します。通常の入力だけで良好な結果が出た場合は、その範囲での評価にとどめます。欠けた入力を本番でも扱うなら、人へ戻す手順を試してから適用範囲を決めます。
判断基準は、単に「現状よりよい結果」とせず、業務責任者が受け入れられる状態まで言葉にします。例えば処理が早くなっても、修正を終えるまでの負担が増えるなら移行を保留する、と先に決めます。出力品質を優先する業務なら、処理時間が改善しても、確認者が誤りを見分けられない状態は許容しないと定めます。どの指標を優先し、どの失敗があれば止めるかを揃えてから試験します。
そのうえで、評価項目ごとに判断の分岐を記録します。
- 業務負担が軽くなっても、重要な出力を人が確認できない ── 本番移行を保留します
- 品質は満たすものの、確認作業が現行業務より重い ── 確認手順を変えて追加検証します
- 主要基準を満たさず、改善に必要なデータや担当体制も用意できない ── 対象業務や手段を見直します
基準を決める際は、望ましい変化に加え、受け入れられない失敗も明文化します。たとえば、担当者が出力の根拠を確認できない状態を移行上の課題とするなら、その有無を試験中に記録します。測定結果が良好でも移行上の課題が残れば、何を解消すれば再判定できるかを示して保留します。
検証途中で測定方法に問題が見つかった場合は、都合のよい結果へ合わせて基準を変えません。測定方法を修正したうえで同じ条件のデータを取り直せるなら再評価し、取り直せないなら判断保留として記録します。
AIと人間の役割分担を評価に含める
AIには、情報の分類、記録の要約、下書き、データの整理などを任せやすい一方、利用範囲、業務ルール、承認、最終的な実行判断は人が担う設計をおすすめします。特に顧客への回答や事業判断に関わる処理は、出力を確認してから次の操作へ進む流れにします。
以下の画面は、HubSpotの顧客対応エージェントでガイドラインを設定する画面です。トーンと応答スタイルの入力欄が表示されており、AIの振る舞いを運用側で定義する構成を確認できます。
ガイドラインを設定したことだけで評価を終えず、想定した表現で回答できたか、担当者の修正がどこに集中したかを記録します。修正内容に共通点があればガイドラインを調整し、個別判断が必要な内容は人への引き渡し条件として整理します。引き渡し条件を設けた後は、担当者がその状態を見分け、業務を止めずに対応できるかも試します。
引き渡しを試す際は、担当者に何が表示され、どの情報を見て判断できるかまで確認します。人に戻す設定があっても、理由や元の入力を確認できなければ対応が滞ります。その場合はAIの出力だけを調整せず、表示内容と受け渡し手順を見直して再評価します。
確認者の役割も、単に「承認する」とせず、確認する項目と差し戻す条件を決めます。担当者によって承認判断が分かれたら、AIの設定を変える前に判断理由を比べます。業務ルールを揃えられれば同じ条件で再評価し、揃えられなければ、その判断を人が担う範囲として残します。
AI PoCの実施計画と進め方
実施計画では、準備、試験運用、改善、評価、判断をひとつの流れにします。各段階に完了条件を置き、前段の課題を残したまま次へ進まないようにします。期間の長さを先に固定するより、何を確認できれば次へ進めるかを明確にします。
段階ごとの完了条件を決める
PoCの進行表には、作業内容だけでなく、各段階から退出する条件を記載します。これにより、設定作業が終わっただけの状態と、検証準備が整った状態を区別できます。
| 段階 | 主な作業 | 次へ進む条件 |
|---|---|---|
| 準備 | 目的、対象、役割、データを整理する | 評価方法と対象範囲が関係者に共有されている |
| 設定 | ツール、権限、入力データを用意する | 想定する業務手順を一巡できる |
| 試験運用 | 利用者が実際の手順で使う | 成功と失敗の両方の記録が集まっている |
| 改善 | 設定や手順を調整する | 変更理由と影響を説明できる |
| 評価 | 基準に照らして結果を整理する | Go、Conditional Go、No-Goを判断できる |
| 移行設計 | 本番環境と運用体制を設計する | 責任者、教育、監視、対応手順が決まっている |
前段の完了条件を満たさない場合は、予定だけを理由に次へ進めません。例えば、評価用の記録が不足しているなら、判断会議の前に不足した利用場面を特定します。その場面を追加で検証できるか、検証できない理由を判断資料に残すかを決めます。
各段階の終了時には、完了した作業と未確認の条件を分けて記録します。設定段階で通常の業務手順しか試せていなければ、例外時の引き渡しを試験運用に組み込みます。試験運用でも確認できなかった条件は、移行時の前提として明示し、その条件を含む範囲へ広げる前に検証します。
段階を進める前には、未確認の条件が次の作業を妨げるかを確かめます。例えば出力を記録する場所が未定なら、試験運用で後続の担当者まで流れを確認できません。この場合は記録先を決めてから進みます。対象外の例外として切り分けられる条件なら、その範囲を明示して試験します。
成功だけでなく失敗の条件を記録する
AIが期待どおりに動かなかった場面は、原因を入力データ、指示、設定、システム連携、業務ルールに分けます。「精度が低かった」という記録だけでは、改善できる問題か、ユースケース自体が向いていないのかを判断できません。
記録には、入力、期待した出力、実際の出力、利用者の修正、業務への影響を残します。同じ原因が繰り返されるなら設定改善の対象とし、個別事情によって判断が変わるなら人へ引き渡す条件として扱います。顧客対応へ影響する失敗と、表現を整えれば使える失敗は分けて報告します。
原因を分けた後は、変更できる箇所と再測定する箇所を対応付けます。入力不足なら必要な項目の取得方法を、業務ルールの不一致なら合格条件を、引き渡しの失敗なら担当者への通知と確認手順を見直します。原因が特定できない失敗は、都合のよい推測で分類せず、再現条件を確認してから扱いを決めます。
失敗の影響を確認するときは、AIの出力が誤った時点で止まったか、後続業務まで進んだかも記録します。担当者が検知して修正できた場合と、検知できず次の担当者へ渡った場合では、必要な対策が異なります。後者が主要基準に関わるなら、検知方法と停止手順を試せるまで移行を保留します。
フィードバックを設定と業務手順へ戻す
利用者からの意見は、機能要望、操作上の問題、業務ルールの不足に分類します。機能を追加すれば解決するとは限らないため、設定変更と業務手順の変更を分けて検討します。
例えば、AIの出力後に同じ修正が繰り返されるなら、指示や入力項目を見直します。一方、担当者ごとに求める内容が異なるなら、AIの設定より先に業務上の合格条件を揃えます。改善後は、変更前と同じ評価方法で再測定します。入力データや対象業務も変えた場合は、設定変更だけによる差として扱わず、条件の違いを明記します。
変更履歴には、何を変えたかだけでなく、どの問題に対応したか、どの評価項目へ影響するかを残します。改善後も同じ問題が起きるなら、設定以外の原因を確認します。別の問題が生じた場合は、その影響を含めて再評価し、以前の良好な結果だけで移行を判断しません。
改善を続けるか迷う場合は、未達の原因と、次の試験で確かめる内容を対にします。改善案はあるが再測定できないなら、達成を見込んでGoとはしません。変更後の結果を同じ条件で確かめられる場合に追加検証へ進み、原因も確認方法も定まらない場合は対象業務や評価方法を見直します。
Go・No-Go判断と本番移行
PoCの終了時には、結果を評価基準へ照らし、本番移行、追加検証、見直しのどれを選ぶか決めます。判断理由は、担当者の印象ではなく、開始前に合意した主要基準と補助基準に結び付けます。見送る場合も、得られた知見を次の検討に使える形で残します。（出典：AI・データの利用に関する契約ガイドライン（経済産業省））
判断区分と次の行動を対応付ける
Go、Conditional Go、No-Goの区分は、結果を評価するだけでなく、次の行動を決めるために使います。判断会議では、達成項目、未達項目、未達の原因、改善に必要な条件を同じ形式で示します。
| 判定 | 判断する状態 | 次の行動 |
|---|---|---|
| Go | 主要基準を満たし、運用上の課題へ対応できる | 本番移行計画を確定する |
| Conditional Go | 一部が未達でも、原因と改善方法が明確 | 対象を限定して追加検証する |
| No-Go | 主要基準を満たさず、改善条件も整わない | ユースケース、データ、手段を見直す |
Conditional Goでは、追加検証の対象を未達項目に限定します。例えば、通常の問い合わせでは基準を満たし、例外的な問い合わせの引き渡しが未確認なら、対象範囲を限定し、引き渡し手順を検証します。何を確認できればGoへ移れるか、確認できなければどの範囲を見送るかまで決めます。
判定が分かれる場合は、未達項目が主要基準か補助基準かを先に確認します。主要基準に必要な記録が欠けているなら、良好な補助基準で埋め合わせず、判断保留または追加検証とします。
判断資料には、判定とともに適用範囲を明記します。限定した業務とデータでGoと判定した場合、その範囲で必要な運用条件を示します。新しい業務やデータを加える判断は別に行い、PoCで確認していない条件へ判定を広げません。
Conditional Goを選ぶ場合は、未達のまま使ってよい範囲と、改善後に再判定する範囲を混ぜません。前者は確認済みの条件で運用できるかを確かめ、後者は担当者、変更内容、再測定方法を決めて追加検証します。主要基準に関わる失敗を運用で検知できない場合は、その範囲を移行対象から外します。
問い合わせ分類の評価で判断が分かれたら、入力条件ごとに結論を示します。必要な情報が揃った問い合わせで、担当者が分類と引き渡しを確認できたなら、その条件での移行を検討できます。情報が欠けた問い合わせについて引き渡しを試せていなければ、そこは未確認として追加検証します。誤分類を担当者が検知できなかった条件は、検知方法を確かめるまで移行対象に含めません。
本番移行では規模より運用を先に整える
本番移行では、対象人数やデータ量を広げる前に、権限、承認、エラー対応、教育、効果測定の担当を決めます。PoCの担当者だけが理解している設定を残さず、利用者が変わっても同じ手順で運用できる状態を作ります。
| 本番移行の観点 | 決める内容 |
|---|---|
| 対象範囲 | 利用部門、対象業務、対象データ |
| 権限 | 閲覧、編集、承認を行う担当 |
| 人への引き渡し | AIが処理を止める条件と連絡先 |
| 教育 | 利用方法、禁止事項、問い合わせ方法 |
| 監視 | 品質、利用状況、エラーの確認方法 |
| 改善 | 設定変更の申請、検証、反映の手順 |
PoCで使った設定をそのまま全社へ展開すると、対象外の業務や例外処理へ対応できないことがあります。まず限定した本番範囲で運用し、PoCと同じ評価項目を継続して記録します。新しい利用者やデータで問題が起きた場合は、原因を確認し、手順や設定を見直します。対応方法を説明でき、運用担当が処理できる状態になってから、次の範囲へ広げます。
範囲を広げる際は、新たに加わる業務とデータが、検証済みの条件に収まるかを確認します。条件が異なる場合は、その差を追加検証の対象にします。運用中に主要基準へ関わる問題が見つかった場合は、対象範囲を広げる判断を保留し、原因と対応後の結果を確認します。
移行後の見直し条件も開始前に決めます。例えば、確認者が誤りを見分けられなくなった場合、入力項目の意味が変わった場合、例外時の引き渡しが機能しない場合は、運用担当が記録を確認し、対象範囲や手順を見直します。問題の影響を確認できるまで、新しい条件への適用を広げません。
向かない業務を見極める
判断基準が担当者ごとに大きく変わる業務、必要なデータが記録されていない業務、誤った出力を人が検知できない業務は、PoCの対象を見直したほうがよいケースがあります。AIの性能だけで解決しようとせず、先に業務ルールやデータ入力の仕組みを整えます。
見極める際は、問題を業務ルール、入力データ、人による確認の順に調べます。
- 業務ルール ── 揃えれば期待する結果を説明できるなら、ルールを整えてから再検討します
- 入力データ ── 必要な情報を取得できないなら、データ整備を先行します
- 人による確認 ── 誤りを検知する担当者や確認方法を用意できないなら、その業務へ反映する範囲を広げません
例えば、担当者ごとに正解が違う場合は、過去の判断を増やして試す前に、判断が分かれた理由を業務責任者と整理します。共通のルールを定められれば、そのルールで期待する出力を記録して再検証できます。共通のルールを定められず、人による確認でも誤りを見分けられない場合は、その判断をAIに任せる計画を見直します。
データ不足も、取得できる情報が入力されていない場合と、業務上そもそも取得できない場合を分けます。前者なら入力手順を整えて再検討できます。後者なら不足を人が補えるかを確認し、補えないなら対象業務かAIに任せる処理を変えます。誤りを検知できない場合は、確認者を置くだけで解決したとせず、確認に必要な情報を提示できるかを先に試します。
この順序で調べると、次に進む条件を具体化できます。ルールの不一致が原因なら、責任者が判断条件を合意した後に試験を再開します。入力漏れが原因なら、入力時点で必要な情報を取得できるようにしてから測り直します。確認者が誤りを見分けられないなら、判断に必要な情報の提示と停止手順を試します。いずれの条件も整えられなければ、その業務をPoCの対象から外して別の処理を検討します。
No-Goは、PoCの進め方そのものを否定する判定ではありません。導入しない理由が明確になれば、追加投資を止める、別の業務へ切り替える、データ整備を先行するという次の判断ができます。見直し後に再検討する場合は、前回の未達原因が解消したことを開始条件にします。
CRMデータを活用したAI PoCの進め方
AI PoCに必要な顧客情報、商談情報、活動履歴、問い合わせ履歴は、CRMに蓄積されている場合があります。これらを利用するときは、データが存在するかだけでなく、入力基準と関連付けが揃っているかを確認します。PoCで得た結果をCRMへ戻すところまで設計すると、検証をその後の業務へつなげやすくなります。
データの一元管理から始める
顧客情報をスプレッドシート、メール、担当者のメモへ分けて管理していると、同じ顧客について異なる内容が入力されることがあります。その状態でAIへ情報を渡すと、どのデータを根拠にしたのかを追いにくくなります。
CRMでは、コンタクト、会社、取引、顧客対応の情報を関連付け、AIが参照する範囲を明確にします。PoCでは、必要な項目だけを対象にし、使っていない項目まで一度に整備しないことをおすすめします。情報が食い違う場合は、どの記録を確認し、誰が修正するかを決めてから評価に使います。
対象項目を選んだら、次の点を確認します。
- 入力される時点
- 更新する担当者
- 値が欠けた場合の扱い
同じ項目名でも業務によって意味が異なるなら、評価に使う前に定義を揃えます。定義が揃わない記録を混ぜて結果を比較せず、確認できた範囲と未確認の範囲を分けます。
情報の食い違いが見つかったら、AIの出力を評価する前に、参照すべき記録と修正の責任者を特定します。修正できるなら記録を整えて再評価します。食い違いを解消できないなら、その情報に依存する判断をPoCの対象から外すか、担当者の確認を必須条件にします。
コンタクトから請求までの流れに置く
AI機能を単独で考えず、コンタクトの登録、取引の進行、顧客化、請求へ続く業務のどこで使うかを決めます。入力元と出力先が明確になれば、AIの結果が次の担当者へどう渡るかを評価できます。
例えば、問い合わせ内容の分類を検証する場合は、分類結果を表示するだけでなく、次までを対象にします。
- 担当者への割り当て
- 取引への関連付け
- 対応履歴の記録
分類が適切でも、担当者が結果を確認できない、履歴が残らないといった問題があれば、業務への組み込みは未達です。一元管理、自動化、可視化を個別機能ではなく、業務全体の流れとして評価します。
HubSpotでのAI活用を検討する際も、Breezeの出力だけを見るのではなく、CRM内のレコード更新や担当者の確認、その後のレポートまでを含めて設計します。AIの結果が業務データとして残れば、PoC後も改善の材料として利用できます。
業務への組み込みを評価するときは、AIの出力と、その出力を受けて人が行った操作を区別して記録します。後続の担当者が結果を見つけられない場合は、出力品質が良くても記録先や受け渡しを見直します。後続業務まで一巡できたことを確認してから、その範囲の運用判断へ進みます。
後続業務で必要な情報が欠ける場合は、AIの出力項目を増やす前に、誰がその情報を使い、どの時点で必要かを確かめます。既存の記録で足りるなら受け渡し方法を直します。新たな入力が必要なら、入力担当者と確認方法を決めてから再試験します。
データ品質を人の注意ではなく仕組みで保つ
データ品質を担当者への呼びかけだけで維持するのは難しいため、次を仕組みとして設計します。
- 入力項目
- 必須条件
- 選択肢
- 権限
入力項目を増やしすぎず、AIの判断と業務上の報告に使う項目へ絞ります。
データが欠けている場合は、AIに推測させるのではなく、人へ確認を戻す条件を設定します。入力者、確認者、修正履歴が追えるようにします。欠損を補った後に評価へ戻せる業務と、欠損がある時点で処理を止める業務を分けておくと、例外時の対応も判断できます。
項目の不足が見つかったら、まずその項目がAIの処理に必要なのか、人による確認に必要なのかを確かめます。必要なら入力時に取得するか、処理前に確認する手順を決めます。不要なら項目を増やさず、既存の記録で判断できるかを再確認します。
入力ルールを変えた後は、新たに記録された情報だけでなく、既存の記録をどう扱うかも決めます。既存の記録に必要な項目がないなら、その範囲は人へ戻すか、情報を確認してから処理します。新しい入力ルールで得た結果を、条件の異なる既存記録にもそのまま当てはめません。
既存事例から見るPoC運営のポイント
KDDIと東京海上日動の取り組みを紹介します。自社へ応用するときは、取り組みの規模や結果をそのまま基準にせず、候補の選定、検証、次の判断をどうつなぐかに注目します。
KDDIのPoCから本番化への流れ
KDDIは、社内のAI活用をPoCから本番化へ進める体制を構築し、各事業部門から集めた活用アイデアについて、優先順位を付けて検証する流れを運用しています。個別のアイデアをその場で試すのではなく、候補の受付、選定、検証、本番化をひとつのパイプラインとして扱う考え方です。
自社で取り入れる場合は、次の役割を分け、すべての候補を同じ選定軸で比較します。
- 提案者
- 評価者
- 実施責任者
- 導入判断者
候補が増えたときは、業務課題と必要なデータを説明できるものから評価し、測定方法を決められないものは準備へ戻します。経営データを判断材料へ変える考え方は、経営データの可視化でも紹介しています。
受付時には、提案された機能名だけでなく、次を確認します。
- 対象業務
- 現状の課題
- 使うデータ
- 結果を判断する担当者
これらが揃えば共通の軸で比較し、揃わなければ提案者へ確認を戻します。PoCへ進めた後も、選定時に想定した評価方法で判断できるかを確認します。
本番化へ進める段階では、選定時に期待した効果だけでなく、試験で判明した確認作業や例外対応を判断資料へ戻します。想定外の運用作業が必要になったなら、担当と手順を決めて再評価します。そこで判断材料が揃わなければ、候補の優先順位も見直します。
東京海上日動の審査業務におけるPoC
東京海上日動は、保険金請求の審査業務にAIを導入するPoCを行い、定型的な請求を対象として審査時間の削減を検証し、その後の展開へ進みました。対象業務を限定し、測定する効果を審査時間として明確にした点が、判断しやすい設計につながっています。
この考え方を応用する場合は、判断が複雑な案件まで一度に対象にせず、ルールを説明できる業務から始めます。定型処理をAIへ任せ、例外や高い影響を伴う判断を人へ戻す流れを作ります。そのうえで、処理時間だけでなく、人へ戻した後の確認負荷や対応の完了までを比較します。
自社の対象業務へ当てはめる際は、何を定型とするか、どの条件で人へ戻すかを先に定義します。判断に必要な情報が揃わない案件を試験結果から黙って除かず、対象外とした理由を記録します。定型の範囲で得た結果は、その範囲に限定して判断します。
人へ戻した案件については、引き渡した時点ではなく、担当者が判断を終えた時点までを確認します。AIが処理した部分だけで審査時間を比べると、後続の確認負荷が見えません。定型と例外の境界で迷う案件があれば、その条件を整理してから適用範囲を決めます。
よくある質問
AI PoCでは、期間や精度だけでなく、何を判断するための検証かを揃えることが重要です。ここでは、成功基準、対象範囲、未達時の対応、人による確認の要否を整理します。計画を立てるときは、各回答を自社の業務記録、担当者、次へ進む条件に置き換えて確認してください。
PoCの成功基準はどのように設定しますか？
現在の業務を測り、PoCで変えたい項目を主要基準として定めます。出力品質だけでなく、次を組み合わせます。
- 処理時間
- 修正負荷
- 使いやすさ
- 既存業務への組み込みやすさ
各基準について、何を同じ条件で比較するか、どの失敗を人へ戻すかを先に決めます。結果に応じた次の行動は次のとおりです。
- 主要基準を満たし運用方法も決まった場合 ── 本番移行を検討します
- 原因が限定された未達の場合 ── 追加検証します
- 改善条件を用意できない場合 ── 見直します
結果を見た後で基準を変えた場合は、変更後の条件で再測定します。
判断に迷う場合は、まず必要な記録が揃っているかを確認します。揃っていなければ測定を補い、揃っていれば主要基準と運用上の課題を確認します。未達の項目については、原因、改善する担当者、再測定する方法を決められるかが次の分かれ目です。
例えば処理時間の改善を基準にするなら、AIが出力するまでと、人が確認・修正して次の担当へ渡すまでを分けて記録します。後者が現状より重くなった場合に移行するかどうかも、開始前に決めます。顧客対応に影響する誤りを検知できないなら、時間の結果が良好でも移行を保留します。
PoCの期間と対象範囲はどう決めますか？
期間は、準備、試験運用、改善、評価を一巡できる長さから決めます。対象範囲は、利用者が協力でき、必要なデータを準備でき、導入前後を同じ方法で比較できる業務へ絞ります。
予定期間が終わっても判断材料が揃っていない場合は、そのまま合否を出しません。不足している評価項目を特定し、その項目だけを追加検証します。測定方法そのものを用意できない場合は、対象業務や検証方法を見直します。
対象を狭める際も、入力から人による確認、結果の記録までの流れは残します。対象外にした業務や例外は明記し、それを含む範囲へ進む前に何を確認するかを決めます。
期間を延ばすかどうかは、残る課題を追加の試験で確かめられるかで判断します。未確認の利用場面と記録方法が明確なら追加検証を計画できます。何を測るか定まらないなら、試験を続ける前に目的と評価基準を整理します。
PoCで期待した結果が出なかった場合はどうしますか？
原因をユースケース、データ、指示や設定、ツール、業務手順に分解します。
- 設定の変更で改善できる場合 ── 対象を限定して追加検証します
- 必要なデータが存在しない場合 ── データ整備を先行します
業務課題とAIに任せる処理が合っていない場合は、同じPoCを続けず、対象業務を見直します。再検討するときは、前回の未達原因が解消したかを確認します。見送った理由と検証結果は、次の判断材料として残します。
原因を特定できない場合は、失敗した入力と業務上の影響を確認し、同じ条件で再現できるかを調べます。改善策を決められないまま試験範囲だけを広げず、調査に必要な記録を揃えてから次の判断をします。
追加検証へ進むときは、変更する設定や手順と、再測定する評価項目を対応付けます。変更しても主要基準の未達が解消しない場合は、入力データや業務ルールを調べ直します。必要な条件を整えられないなら、その業務への導入は見送ります。
AIの出力をそのまま業務へ反映してもよいですか？
顧客対応や事業判断へ影響する処理では、人が内容を確認してから反映する流れをおすすめします。PoC中に、どの出力なら承認でき、どの状態なら担当者へ戻すかを定義します。
確認作業が多すぎて業務効果を得られない場合は、自動化範囲を狭めます。分類や下書きはAIへ任せ、最終判断と実行は人が担うなど、役割を分けて再評価します。確認者が判断に必要な情報を見られない場合は、反映を進めず、表示内容や手順を見直します。
人による確認を設けた後は、担当者が誤りに気付ける情報を見られるか、差し戻し先が決まっているかを試します。確認者を置いただけで安全と判断せず、確認を含む業務全体の負担と結果を評価します。
確認者が判断を再現でき、例外を止めて記録する手順まで試せた範囲から運用を検討します。判断が分かれる出力や必要な情報が欠けた出力は、反映対象から外して人へ戻します。その扱いを決められない場合は、反映範囲を広げません。
まとめ
AI PoCの進め方で重要なのは、AIが動くかだけでなく、対象業務へ導入する価値と運用可能性を判断することです。目的、評価基準、データ、実施手順、本番移行をひとつの流れとして設計します。主要基準を満たさない場合も、原因を分解すれば、追加検証、データ整備、見直しのどれへ進むかを判断できます。
最初の一歩は対象業務の整理から
まずは、現在の業務で手作業や判断のばらつきが発生している箇所を書き出してください。その中から、必要なデータがあり、導入前後を比較できる業務をひとつ選びます。
次に、AIへ任せる処理と人が判断する処理を分けます。現行業務とPoCで同じ範囲の作業を測れるか確認し、測れない項目は記録方法を整えます。最後に、どの結果なら本番移行、追加検証、見直しへ進むのかを評価表へまとめます。
評価表を使うときは、主要基準の結果に加え、測定できなかった項目と対象外にした業務を確認します。判断材料が揃っていれば移行条件を検討し、足りなければ不足した場面に絞って検証します。これにより、次の行動を結果から選べます。
評価表には、各項目の測定範囲、記録する担当者、受け入れられない失敗も記載します。結果が良好でも重要な失敗を検知できないなら移行を保留し、検知方法を試します。問題が限定され、担当者と再測定方法を決められるなら追加検証へ進みます。
自分で進めるための次の行動
- 対象業務の開始から完了までを書き出し、入力、判断、転記、確認のどこに課題があるかを整理します。業務の開始条件と完了条件も決め、現状の記録を取れるようにします。
- 業務効果、出力品質、利用者評価、運用性の評価項目を決め、導入前の状態と測定方法を記録します。主要基準、受け入れられない失敗、人へ戻す条件を開始前に合意します。
- 限定した範囲で試験運用し、成功と失敗の両方を確認します。未達の原因と改善条件を整理してから、Go、Conditional Go、No-Goを判断します。移行後も同じ項目を確認し、新しい業務やデータを加える前に条件の違いを検証します。
企業様によって最適な形は異なります。CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのStartLinkまでお気軽にお問い合わせください。
あわせて読みたい
このテーマと関連する内容を、次の記事でも詳しく解説しています。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
