AIのPoCとは何を確かめる工程か

「AIを使えないか」という検討が社内で始まると、多くの場合まずPoC（概念実証、Proof of Concept）という言葉が出てきます。ところが、PoCを「AIが動くかどうか試すこと」と捉えたまま始めると、動くものができたのに次の判断ができない、という状態に陥りがちです。

実際に判断が必要なのは、「この仕組みを業務に入れて、事業として割に合うか」です。本記事では、AIのPoCで何を確かめる工程なのかを、既製のAI APIを組み込む前提で整理します。

PoCで確かめるのは「動くか」ではない

生成AIを使った処理は、多くの場合「とりあえず動く」ところまでは驚くほど早く到達します。OpenAIやAnthropic、GoogleといったサービスのAPIに文章を投げれば、要約も分類も抽出も、それらしい結果がすぐ返ってきます。だから「動くか」は、もはや検証の主題になりません。

主題になるのは次の問いです。

• 実務で使える水準の結果が、安定して出るか
• その結果を、今の業務の流れのどこに、どう挟めるか
• 1件あたりいくらかかり、それは今のコストに見合うか
• 結果が誤っていたとき、誰がどう気づいて、どう直すか

この4つのうち最初の1つだけを確かめて終わるPoCが、最もよく見る失敗です。デモは成功し、社内の反応も良く、それでも本番化の稟議が通らない。判断材料が揃っていないからです。

PoCの成果物は「動くもの」ではなく、「本番化するかしないかを決められる材料」だと考えてください。

技術検証・業務検証・経済性検証の3種に分ける

確かめたいことを一度に混ぜると、結果の解釈ができなくなります。3つに分けて、それぞれ別の問い・別の判断者を置くと見通しがよくなります。

技術検証

既製のAI APIに対して、実際のデータに近い入力を与え、出力の質を見ます。ここで大事なのは、「うまくいった例」ではなく「うまくいかなかった例」を集めることです。どういう入力で崩れるかが分かって初めて、業務に入れたときの影響が見積もれます。

なお、この段階で「モデルを自社向けに学習させる」といった話に進む必要があるケースは、実務ではそう多くありません。まず既製のAPIと指示文（プロンプト）の工夫、必要なら参照する社内文書を渡す形で、どこまで届くかを確かめるのが先です。既製品で足りるなら、費用も期間も抑えられ、後の保守も軽く済みます。

業務検証

出力の質が実務に足りていても、業務の流れに入らなければ効果は出ません。誰がその画面を開くのか、どのタイミングで結果を見るのか、結果をそのまま使うのか人が直すのか。ここは技術ではなく業務設計の話で、現場の担当者が実際に数日使ってみないと分かりません。

よくあるのは、「AIの出力を確認する手間が、元の作業とほぼ同じだった」という結果です。これはPoCとして正しい成果です。本番化して初めて気づくより、はるかに安く済んでいます。

経済性検証

AIのAPI利用料は処理量に比例して増えます。PoCの段階で、1件あたりの概算費用と処理時間を出しておくと、本番の規模に掛け算したときに成立するかが見えます。加えて、確認や修正にかかる人の時間も費用です。削減できる手間と、増える手間・費用を並べて初めて判断ができます。

3つの検証をどの順で回すか

順番は、最も不確かなものから、が原則です。ただし現実には、経済性検証を最後に回すと手戻りが大きくなります。おすすめは次の進め方です。

1. 経済性の当たりを先に付ける。「1件あたりこのくらいなら成立する」という上限を、業務側が先に言葉にしておきます
2. 技術検証を小さく行う。失敗例を集めることを目的にします
3. 技術検証の結果が上限の範囲に収まりそうなら、業務検証へ進みます
4. 業務検証で流れに乗らなければ、AI以外の解き方に戻ります

この順にすると、「技術的には素晴らしいが単価が合わない」という最も無駄の大きい結末を避けられます。PoCの合格ラインを先に決めるで扱うとおり、上限や合格ラインを先に紙に書くことが、この順序を成り立たせます。

想定例：問い合わせメールへの返信下書きをAIに作らせたい、という検討があったとします。業務側が先に「1件あたり数円の範囲で、担当者の作業時間が半分になるなら導入したい」と上限を言葉にします。技術検証では、実際の問い合わせを数十件、特に過去に対応が難しかったものを中心に試し、どういう問い合わせで下書きが使い物にならないかを洗い出します。ここで「定型的な問い合わせは十分だが、契約内容に踏み込むものは危険」と分かれば、業務検証の範囲は「定型的な問い合わせだけ自動で下書きを出し、それ以外は従来どおり」に絞れます。

AIでやらない判断も成果のうち

PoCの結論が「やらない」になることは、失敗ではありません。むしろ、次のような場合は早めにそう結論づけるほうが健全です。

• 対象の業務が月に数件しかなく、自動化しても効果が小さい
• 判断基準が明文化されており、条件分岐のルールで十分に処理できる
• 誤りの許容度が極端に低く、結局すべて人が確認することになる
• 入力になるデータが紙や口頭のままで、まずデジタル化のほうが先

特に2つ目は見落とされがちです。ルールがはっきりしている処理は、従来の条件分岐で書いたほうが、安く、速く、結果も安定します。AIは「基準を言葉にしづらい判断」「入力の形が揃わない情報」に向いた道具で、それ以外に使うと費用も不確かさも増えるだけです。

弊社はAI活用開発として既製のAI APIをプロダクトや業務に組み込む開発を行っていますが、ご相談の中で「これはAIを使わないほうが安く済みます」とお伝えすることは珍しくありません。PoCの入口で、まずその線引きから一緒に整理します。

判断できる材料を持って次へ進む

AIのPoCは、動くものを作る工程ではなく、本番化の可否を決める材料を揃える工程です。技術検証・業務検証・経済性検証の3種に分け、経済性の上限を先に置いてから技術を試し、業務の流れに乗るかを現場で確かめる。この順序を守れば、PoCは短く終わり、次の判断がその場でできます。

範囲の切り方はPoCの範囲を最小にする切り方を、進めるにあたっての期間と費用の考え方はPoCの期間と費用の考え方をあわせてご覧ください。何から確かめるべきか迷う場合は、お問い合わせからご相談ください。オンラインで状況を伺い、そもそもPoCが要るかどうかから整理します。

本記事は一般的な情報であり、個別の事案は専門家・所管官庁にご確認ください。