「生成 AI を業務に入れたいので、まず PoC からやりたい」という相談は、ここ数年で一気に増えました。ところが実際に進めてみると、デモは動いたのに本番に乗らないまま立ち消えになる、いわゆる「PoC が PoC で終わる」状態に陥るケースが後を絶ちません。原因の多くは技術ではなく、検証の設計にあります。何をもって成功とするかを決めないまま「とりあえず賢いエージェントを作ってみる」と始めてしまうため、動いた後に「で、これは使えるのか?」という問いに誰も答えられないのです。

私たち FIXIT は AI 駆動開発のクリエイティブスタジオとして、Claude Code や Cursor、AI エージェントを実プロジェクトに組み込んで開発・運用してきました。その経験から言えるのは、AI エージェントの PoC の成否は、検証を始める前の「設計」でほぼ決まるということです。本記事では、発注者の目線で、成功基準の置き方、評価ハーネスの作り方、本番移行を見極める条件、そして費用と期間の目安までを実務に基づいて整理します。これから PoC を検討している方が、自社の検証を「動いた/動かない」ではなく「使える/使えない」で判断できる状態を目指します。

結論: PoC は「動いた」ではなく「評価指標を満たした」で判定する

最初に結論を述べます。AI エージェントの PoC は、デモが動いたかどうかではなく、あらかじめ決めた評価指標を満たしたかどうかで判定すべきです。これが本記事を通じて最も伝えたい一点です。

理由はシンプルで、LLM の出力は同じ入力でも揺れる確率的な性質を持つからです。通常のソフトウェアであれば、一度動けばその挙動は変更を加えるまで固定されます。ところが LLM は、たまたまうまく答えたケースをデモで見せられても、同じ品質が安定して出るとは限りません。「触ったら賢かった」という印象は、本番で毎日数千件をさばける保証にはならないのです。

そこで PoC では、検証を始める前に「何件中、何件が、どの基準を満たせば合格とするか」を数値で定義します。たとえば「代表的な 200 件の問い合わせに対して、人間が許容できる回答を 85% 以上返せること」「事実誤りを含む回答が 2% 以下であること」といった形です。この基準を満たしたかどうかを、評価ハーネスという仕組みで自動的に測ります。逆に言えば、この基準を先に置かない PoC は、終わった後に成否を判断する物差しがなく、関係者の主観で「なんとなく良さそう/不安」と評価が割れて止まります。

「動いた」で満足しないことが、PoC を本番につなげる出発点です。以降では、この判定の仕組みをどう設計するかを順に見ていきます。

PoC が本番に乗らない典型的な失敗パターン

検証設計の話に入る前に、なぜ多くの PoC が本番に乗らないのかを整理しておきます。私たちが相談を受ける中で繰り返し見てきた失敗パターンは、おおむね次の 4 つに集約されます。

ひとつ目は、成功基準を決めないまま始めてしまうパターンです。先述のとおり、これが最も多く、かつ根が深い失敗です。基準がないため、デモを見た人の数だけ評価が生まれ、合意形成ができません。「もう少し賢くなれば」という曖昧な期待が際限なく続き、ゴールのないチューニングに時間が溶けていきます。

ふたつ目は、対象範囲を最初から広げすぎるパターンです。業務全体を一度にエージェント化しようとすると、どの部分が効いていて、どこが詰まっているのかを切り分けられません。一部の処理は十分使えるのに、別の処理の精度が出ないせいで「全体としてダメ」という結論になり、せっかく勝てる領域まで一緒に捨ててしまいます。

3 つ目は、検証用のデータを軽視するパターンです。きれいに整えた数件のサンプルではうまく動くのに、現場の実データを入れた途端に崩れる。表記揺れ、欠損、想定外の言い回し、長文や添付ファイルといった現実の入力に対して、検証段階で向き合っていないと、本番投入後に「こんなはずでは」となります。

4 つ目は、捨てる前提で作ったものを本番に流用しようとするパターンです。検証だけを急いだ PoC には、本番運用に不可欠なログ、権限管理、ガードレール、監視が入っていません。それを無理に本番へ乗せようとして、結局ほぼ作り直しになり、移行コストが膨らんで頓挫します。

これらに共通するのは、いずれも技術力ではなく検証の設計で防げる失敗だということです。AI エージェントの設計そのものについては AI エージェント設計パターン入門 でも詳しく扱っていますが、PoC の文脈では「どう作るか」の前に「どう測るか」を先に決めることが何より効きます。次の章から、その設計手順を具体的に見ていきます。

検証設計の手順: 成功基準・評価ハーネス・データ準備

PoC の検証設計は、大きく 3 つの要素で組み立てます。成功基準、評価ハーネス、データ準備です。この順番で固めていくと、検証が「動いた/動かない」ではなく「合格ラインに届いた/届かない」で進むようになります。

成功基準を業務の言葉で定義する

最初にやるのは、成功基準を業務の言葉で定義することです。ここで重要なのは、技術的な指標だけでなく、その業務にとって何が許容できて何が許容できないかを関係者で合意することです。

たとえば問い合わせ対応であれば、「一次回答として人間が手直しなく送れる回答の割合」「誤った案内をしてしまう割合」「人間にエスカレーションすべきケースを正しく見送る割合」といった軸を設定します。これらに対して、合格ラインを数値で置きます。誤案内のように業務リスクが大きい項目は、精度の高さよりも「危険なケースを確実に人間へ回せること」を基準にする、といった具合に、項目ごとに何を重視するかを変えるのが実務的です。

この段階で、達成できなくても致命的でない項目と、これを満たさなければ本番に出せない項目を切り分けておくと、後の判断がぶれません。

評価ハーネスで自動的に測る仕組みを作る

成功基準を決めたら、それを自動で測る仕組み、すなわち評価ハーネスを用意します。評価ハーネスとは、代表的な入力と期待される振る舞いをデータセットとして固定し、エージェントの出力を自動採点して合格率を出す仕組みです。

採点の方法は、項目の性質で使い分けます。事実の正誤や、特定のツールを正しく呼べたか、必須項目が出力に含まれているかといった機械的に判定できる部分は、ルールベースで採点します。一方、回答の自然さや要件への沿い方のように主観が入る部分は、判定用の LLM に採点させる「LLM as a judge」を使います。判定 LLM には合格条件を具体的に与え、判定理由も出力させて根拠を確認できるようにしておくのが要点です。評価ハーネスの作り込みについては LLM アプリの評価ハーネス構築 で実装視点の詳細を解説しています。

評価ハーネスを最初に作る効果は 2 つあります。ひとつは、PoC の合否を客観的に判定できること。もうひとつは、プロンプトやモデルを変えるたびに自動で再評価でき、「直したら別のところが壊れた」という回帰を検出できることです。これにより、改善が安全に試せるようになり、検証のスピード自体が上がります。

現場の実データで検証する

3 つ目はデータ準備です。評価ハーネスに入れるデータは、きれいに整えたサンプルではなく、現場で実際に発生している入力から集めます。過去の問い合わせ履歴、実際のドキュメント、現場担当者が「これは判断が難しい」と感じたケースを意図的に含めます。

データには、表記揺れ、欠損、想定外の言い回しといった現実のノイズが含まれます。これらに対してエージェントがどう振る舞うかを検証段階で見ておくことが、本番投入後の事故を防ぎます。個人情報を含むデータを扱う場合は、評価に使う前にマスキングや匿名化の仕組みを用意しておくことも、この段階で設計しておきます。

代表的なケース、件数の多いケース、判断が難しいケース、過去に問題が起きたケースをバランスよく集めて、数十件から数百件のデータセットを作る。このデータセットこそが、PoC の品質を測る物差しであり、本番移行後も育て続ける中核資産になります。

RAG / エージェントの精度をどう測るか

精度の測り方は、対象が RAG（検索拡張生成）なのか、ツールを使うエージェントなのかで観点が変わります。それぞれ何を見るべきかを整理します。

RAG の精度は、2 つの段階に分けて測るのが基本です。ひとつは検索の精度で、質問に対して関連する文書を正しく拾えているか。もうひとつは生成の精度で、拾った文書に基づいて正しく答えられているかです。この二段階を分けて測らないと、回答が間違っていたときに、そもそも必要な文書を取れていないのか、文書は取れているのに使い方を誤っているのかが切り分けられません。検索が弱いのに生成側のプロンプトをいくら直しても改善しないため、どちらがボトルネックかを数値で特定することが先決です。RAG の構築手順そのものは RAG 構築の実践ガイド で詳しく扱っています。

特に注意すべきは、根拠のない回答（ハルシネーション）をどう測るかです。RAG では「検索した文書に書かれていないことを答えていないか」を評価項目に入れます。回答が文書の記述に裏付けられているかを判定し、根拠のない断定が混じる割合を測る。業務によっては、自信のない場合は「分かりません」と答えて人間に回す方が、誤った断定よりはるかに望ましいため、その振る舞いも合格基準に含めます。

ツールを使うエージェントの場合は、最終的な回答の正しさに加えて、途中の判断と行動を分けて測るのが勘所です。正しいツールを選べたか、引数を正しく渡せたか、ツールの結果を踏まえて適切に次の一手を判断できたか。最終出力だけを見ていると、たまたま正解にたどり着いたが途中の判断はおかしい、という不安定なエージェントを見逃します。ステップごとの判断を評価することで、本番で安定して動くかどうかを見極められます。

加えて、コストと応答速度も精度と並ぶ評価軸です。1 件あたり何回 LLM を呼び、いくらかかり、何秒で返るか。精度が出ても、コストや速度が業務要件に合わなければ本番には乗りません。PoC の段階でこれらを同じ評価ハーネスで一緒に測っておくと、本番のコスト最適化の土台になります。

PoC から本番運用へ橋渡しする条件と移行設計

評価指標を満たしたとして、では本番に進めてよいかというと、判断材料はもう少し必要です。PoC から本番運用へ橋渡しする条件を整理します。

まず確認すべきは、評価指標が安定して満たされているかです。一度だけ合格ラインに届いたのではなく、データセットを入れ替えても、何度実行しても同じ水準を保てるか。確率的に揺れる以上、ぶれ幅も含めて見て、最低ラインが業務の許容範囲に収まっているかを確認します。

次に、費用対効果が成り立つかです。本番運用で月いくらかかり、それによってどれだけの工数やコストが削減されるか。PoC で測ったコストをもとに、運用規模での試算を行い、投資に見合うかを判断します。ここが成立しなければ、技術的に動いても本番化は見送るべきです。

そして、本番運用に必要な基盤が設計できているかです。検証だけの PoC には、ログ、権限管理、ガードレール、監視が欠けていることが多く、これらを足す設計が必要になります。具体的には、危険な操作（外部送信、課金、データの削除や更新、本番反映など）の前に人間の承認を挟むガードレール、各ステップの入力・出力・判断理由を残すログ、合格率や異常をリアルタイムに把握する監視です。

ここで効いてくるのが、PoC の段階で本番を見据えた構造にしておくことです。私たちは「捨てる前提の PoC」ではなく「育てる前提の PoC」を勧めており、ガードレールとログを最初から組み込んでおきます。こうしておくと、本番移行は作り直しではなく、欠けている運用基盤を足していく作業になり、移行のコストと期間を大きく抑えられます。AI を任せるパートナー選びの観点は AI ソフトウェア開発の発注先の選び方 も参考にしてください。

費用と期間の目安

費用と期間は、検証範囲と本番運用の規模によって幅がありますが、相談時の目安として整理しておきます。いずれも税抜の概算です。

PoC は、対象を 1 つの業務タスクに絞り、評価ハーネスとデータセットを整えて合否を判定するところまでで、おおむね 300 万円〜 が目安です。期間は範囲によりますが、数週間から 2 か月程度を見込みます。この段階で、業務分析、評価設計、評価ハーネスの構築、複数モデルの比較検証、そして合否判定までを行います。私たちは PoC の納品物に評価ハーネスそのものを含めることを基本にしており、検証が終わった後も貴社が品質を測り続けられる状態でお渡しします。

本格運用 に進む場合は、本番運用に必要なガードレール、権限管理、ログ、監視、既存システムとの連携までを含めて、規模に応じて 800 万〜1,800 万円 がひとつの目安になります。期間は数か月規模です。連携先のシステム数や、扱うデータの機密性、求められる可用性によって変動します。

これらはあくまで一般的なレンジであり、実際の見積もりは検証範囲と要件を伺ったうえで個別に算出します。重要なのは、PoC の費用を「動くものを作る費用」ではなく「本番に進めるかを数値で判断できる状態を作る費用」と捉えることです。評価ハーネスという測る仕組みが手元に残るぶん、PoC 後の意思決定も、本番でのモデル乗り換えやコスト最適化も、勘ではなく数値で進められます。

実例: 月 6,000 件の問い合わせの 80% を一次対応した運用設計

最後に、実際の取り組みから一例を紹介します。ある企業（顧客対応を多く抱える業種・中規模）では、月およそ 6,000 件の問い合わせがオペレーターの工数を圧迫していました。

私たちはまず、全カテゴリを一度に扱おうとせず、件数が多く回答パターンが安定している上位カテゴリに対象を絞って PoC を始めました。過去の問い合わせ履歴から数百件の評価データセットを作り、「人間が手直しなく送れる一次回答の割合」「誤案内の割合」「人間に回すべきケースを正しく見送る割合」を合格基準に置いて、評価ハーネスで測りながらチューニングしています。

検証では、高性能なモデルでまず「このタスクは解けるのか」の上限を確認し、解けると分かってから精度を保てる範囲でより安価なモデルに置き換えて、コストを抑えています。本番設計では、自信のないケースや業務リスクの高いケースは断定せず人間にエスカレーションする線引きを業務ごとに設計し、各判断のログを残す構造にしました。

結果として、問い合わせの 80% 程度を一次対応で処理し、人間は残りの判断が必要なケースと最終確認に集中できる体制になりました。この成果を支えたのは、賢いモデルそのものではなく、「どこまでを自動で処理し、どこから人間に回すか」をリスクに応じて設計し、評価ハーネスで品質を測り続けられる仕組みを最初から組み込んだことです。詳しい取り組みは 顧客対応オペレーションの自動化事例 でも紹介しています。

まとめ

AI エージェントの PoC を本番につなげる鍵は、技術力よりも検証の設計にあります。デモが「動いた」で満足せず、成功基準を業務の言葉で定義し、評価ハーネスで合否を客観的に測る。対象は最も勝てる 1 つのタスクに絞り、現場の実データで検証する。そして本番を見据えた構造で作り、評価指標が安定して満たされ、費用対効果が成り立つことを確認してから移行する。この順序を守れば、「PoC が PoC で終わる」状態は十分に防げます。

私たち FIXIT は AI 駆動開発のクリエイティブスタジオとして、業務分析から評価設計、評価ハーネスの構築、本番運用までを一気通貫で伴走しています。PoC の検証設計でお悩みの方、あるいは止まってしまった PoC を本番につなげたい方は、お問い合わせ からお気軽にご相談ください。自社のどの業務から、どんな基準で始めるべきかを、評価ハーネスの設計とあわせてご提案します。