PoCの範囲を最小にする切り方

PoCの範囲を決めるとき、多くの現場で自然に起きるのは「とりあえず典型的な例から試す」という進め方です。一見、順当に見えます。けれど、この順番こそがPoCを長引かせ、判断を先送りにします。

典型的な例、つまり簡単なケースでうまくいっても、それは本番化してよいという根拠にならないからです。

簡単なケースの成功は、何も証明しない

生成AIを使った処理は、整った入力に対しては高い確率でそれらしい結果を返します。書式の揃った文書、短い文章、前例の多いパターン。こうした入力での成功率は、たいてい期待を上回ります。

問題は、本番の業務で時間を食っているのが、その部分ではないことです。人が手を止めて考えているのは、次のような場面です。

• 書式が崩れている、項目が欠けている、複数の解釈ができる
• 例外的な取り決めがあり、通常の手順が当てはまらない
• 判断に前提知識が要り、担当者によって結論が分かれる

AIに任せたいのは、本来ここです。ところが簡単なケースだけで検証すると、「うまくいった」という印象だけが残り、実際に手間がかかっている部分の見込みは何も分かっていません。本番化してから「肝心なところで使えなかった」と気づくことになります。

だから、PoCの範囲は「最も判断が難しいケース」から切り出します。

難しいケースを先に試すと、範囲は小さくなる

一見、難しいケースを扱うと検証が大がかりになりそうですが、実際は逆です。難しいケースは数が少なく、条件も具体的なので、対象が絞れます。

範囲を切るときは、次の順で考えます。

1. 業務のどの工程か：受付から完了までの流れのうち、一工程だけを選びます。全体を通す必要はありません
2. その工程のどのケースか：過去に人が判断を迷った事例、差し戻しが起きた事例、ベテランでないと処理できなかった事例を集めます
3. 何件か：数十件で足ります。数百件を集める労力を、1件ごとの丁寧な評価に回すほうが有益です

この3段階を通すと、検証対象は「受付工程のうち、過去に差し戻しが発生した30件」のような、極めて具体的な形になります。ここまで絞れば、実装は既製のAI APIに投げる短いプログラムで足り、数日で結果が出ます。

「この難しさで足りるなら、簡単なほうは足りる」

難しいケースを先に置く根拠は単純です。難しいほうで実務に足る結果が出るなら、簡単なほうは自動的に足ります。逆は成り立ちません。検証の順序として、含意の向きが正しいほうを先にやる、というだけの話です。

そして、難しいケースで足りなかった場合も収穫があります。「難しいケースは人が担当し、簡単なケースだけAIに回す」という現実的な設計が、そこで初めて根拠を持って描けるからです。この線引きこそ、本番設計で最も重要な情報です。

作らないことを先に決める

範囲を最小にするもう一つの軸は、「検証のために作らないもの」を明文化することです。PoCで作りたくなるが、多くの場合は不要なものを挙げます。

これらを作らないと決めるだけで、PoCは数か月から数週間に縮みます。ここで削ったものは消えるわけではなく、PoCと本番の間にある壁で扱うとおり、本番化を決めたあとに設計する対象として残ります。

注意したいのは、削ってはいけないものがあることです。検証対象の処理そのものの質は削れません。指示文の作り込みや、参照させる社内文書の準備は、結果を左右するので手を抜くと検証自体が無意味になります。削るのは周辺であって、中心ではありません。

想定例：ある企業が、見積依頼のメールから必要な情報を抜き出して見積書の下書きを作れないか、と検討したとします。最初の案は「メール受信から見積書のPDF出力まで一通り」でした。これを切り直すと、対象は「メール本文から、品目・数量・納期・特記事項の4項目を抜き出す」という一工程だけになります。さらにケースを絞り、過去に担当者が電話で確認し直した依頼メール25件を対象にします。実装は、メール本文を貼り付けると4項目が表形式で出てくる、それだけのものです。結果は表計算ソフトに並べ、営業担当者2名がそれぞれ確認します。数日で終わり、「特記事項の抽出だけが難しく、他3項目は実用に足る」という具体的な結論が得られます。

既製品で足りる範囲を先に確かめる

範囲を絞るときに、もう一つ効く問いがあります。「そもそも、作らずに済まないか」です。

• 既に使っている業務システムやSaaSに、同様の機能が搭載されていないか
• 汎用のAIサービスの画面に、担当者が手で貼り付けて使う形で足りないか
• 条件分岐のルールや、表計算ソフトの関数で処理できる部分はないか

特に2つ目は見過ごされがちです。月に数十件の処理なら、専用の仕組みを作らず、担当者が汎用のAIサービスに貼り付けて使うほうが、開発費も運用の手間もかかりません。仕組みとして作る価値が出るのは、件数が多い、記録が必要、複数人で同じ基準で処理したい、といった条件が揃ったときです。

弊社はAI活用開発として既製のAI APIを業務やプロダクトに組み込む開発を行いますが、PoCの相談の入口では「まず既製のサービスをそのまま使ってみて、それで足りないところを教えてください」とお伝えすることがよくあります。足りないところが具体的になってから作るほうが、範囲は小さく、結果は確かです。

難しい一工程だけを、現実のデータで

PoCの範囲は、業務の一工程に絞り、その中でも最も判断が難しいケースを、現実のデータ数十件で試す。画面も連携も権限管理も作らない。この形にすると、PoCは数週間で結論が出て、結果は本番設計にそのまま使えます。

合格の判定基準はPoCの合格ラインを先に決めるで、必要なデータの用意はPoCに必要なデータの用意で扱います。どこを切り出すべきか整理したい場合は、お問い合わせからご相談ください。オンラインで業務の流れを伺い、一緒に切り口を探します。