生成AIのPoCが止まる理由——「動いた」を不合格にする、上司が問う３つの合格基準

あなたが上司として、部下からAI Agentに関するPoC報告を受け取る立場にいるなら、これは少し役に立つ話かもしれない。PoC（概念実証）の設計を間違えると、何度やっても同じところで詰まる。そして、メンバーが持ってくる報告の「合格」と「不合格」を見極めるのは、あなたの仕事だ。
「とりあえず動かしてみた」で終わったPoCは、合格ではない。PoCが止まるのは技術の問題ではなく、何を検証するかを決めていないからだ。これを最初に言っておきたい。

PoCで確認すべき合格基準は、何なのか

多くの組織でAI AgentのPoCが始まる。始まるのだが、上位層——特に経営層——は「何を検証するか」を知らないまま進めてしまうことが多い。あるいは担当と最初は決めていても、途中で忘れてしまい、「うまく動いたかどうか」だけで判断してしまう。
「動いた」というのは、何と比べて動いたのか。精度は上がったのか。工数は削減できたのか。業務として回るのか。この問いに答えられないまま、「動きました」「いい感じです」で報告が上がってくる。それを見て「ついに当社でも」と実施Goを出してしまう。
本来、PoCで検証すべきことは三つだ。

合格基準① 業務として回るか

ツールが動くことと、業務フローに組み込めることは別の話だ。AI Agentに業務を覚えさせるためのRAGデータを、どのような形式でインプットするのか。日本語や社内専門用語、同音異義語に対応できているか。法務部門が問題ないと言えるか。これらは地味だが、「業務として回るか」の核心だ。途中報告を求めると、ここが上がってくるはずだ。

合格基準② 精度が業務レベルに達しているか

「それなりに答えが出る」では足りない。間違えた時に何が起きるか。誰がそれを検知して、どう補正するか。この設計がないPoCは、本番に持っていけない。

合格基準③ 工数が削減できる構造になっているか

AIを入れても、工数はすぐに下がらない。慣れてくると下がる。業務を見直す中で下がる。最初から削減効果を期待してPoCの合否を判断すると、「効果が出なかった」という結論になりやすい。PoCで問うべきは「削減できているか」ではなく、「削減できる構造になっているか」だ。加えて、Agentのインプットとアウトプットがほかのシステムと連携する場合、そこが手作業のままでは工数は結局減らない。この設計まで検証できているか、あなたは確認すべきだ。

なぜ「動いた」だけでPoCを合格にしてはいけないのか

PoCでもう一つ見落とされることがある。LLMは、プログラムとは違うということだ。
プログラムは、同じ入力に対して同じ出力を返す。バグがなければ、昨日動いたものは今日も動く。
LLMはそうではない。バージョンが上がると、出力が変わる。同じプロンプトを入れても、モデルが更新されれば、返ってくる内容が変わる可能性がある。「動いた」は、そのバージョンの、そのタイミングでの話でしかない。
さらにもう一つのリスクがある。モデルそのものが、外部要因で突然使えなくなる可能性だ。Claude Fable 5は2026年6月9日にリリースされたが、わずか3日後に米政府の輸出規制指令により全世界で停止になった。特定のモデルに依存した構成を組んでいたチームにとって、一夜にして労力が水泡に帰する出来事だった。AIには、こうしたカントリーリスク・規制リスクも存在する。
これをPoCの設計に織り込んでいない組織が、後で詰まる。

接客Agentがバージョンアップで壊れた日

以前、店舗の営業と同じような接客ができないかと、接客用のAI Agentを作っていた時期があった。試しにOpenAIで構築を進めていたところ、モデルの新バージョンがリリースされた。それまで使っていたプロンプトをそのまま使おうとしたら、アウトプットが変わってしまった。
具体的に何が起きたか。競合他社の料金プランを比較に出してきたり、実際には存在しないプランを案内するようになってしまった。顧客接点で使うAgentが、これをやってしまうのは致命的だ。
また別の場面では、パートナー企業が作ってくれたプロンプトを、異なるLLMの環境で実行したところ、うまく動かなかった。同じ指示でも、モデルが変わればプロンプトが素直に機能しない。これはプログラムの世界では起きない種類の問題だ。

なぜプロンプトは、プログラムのようには動かないのか

当時（2025年頃）のRAGの強制力は、今とは違った。「この文書だけを参照して答えなさい」という指示を出しても、モデルが必ずそれに従うとは限らなかった。
今は改善されている。Claude Sonnet 4.6のような現行モデルは、インストラクション追従の精度が上がっている。しかし、RAGシステム全体でも5〜15%のケースでまだハルシネーションが発生しているというデータがある。「絶対に守る」とは言えない状態は、程度の差こそあれ続いている。
つまりLLMとは、進化し続けているソリューションだということだ。プログラムは完成したら動き続ける。LLMは、使い続ける中でモデルが変わり、同じプロンプトが違う出力を返すことがある。この前提を持った上でPoCを設計しないと、バージョンアップのたびに「また壊れた」が繰り返される。

では、技術的にどう備えるか

LLMがバージョンアップしても壊れにくくするための手段はいくつかある。
一つは、バージョンを固定することだ。OpenAIもAnthropicも、特定のモデルバージョンを指定して呼び出せる。新バージョンの恩恵を受けられない代わりに、動作の安定性を確保できる。
二つ目は、RAGを強化し、プロンプトへの依存を減らすことだ。「LLMはあくまで読んで整理するだけ」「判断の根拠は全て外部のドキュメントに置く」設計にすると、バージョンが変わっても壊れにくくなる。ただし100%ではない。
三つ目が、現時点で最も現実的な答えだ。プロンプトをコードと同じように扱い、自動テストで管理することだ。モデルをアップグレードする前に、プロンプトの出力が期待通りかを自動検証する。コードのユニットテストと同じ発想で、「バージョンを上げる＝テストを通してから本番適用」という運用にする。
コードとLLMの間に抽象化レイヤー（LiteLLMやLangChainといったゲートウェイ）を挟むことで、プロバイダー間の切り替えをワンライン化する技術も広まっている。ただしこれはコードの移植性を解決するものであって、プロンプトの移植性は別問題だ。ゲートウェイを入れても、プロンプトが別のモデルで同じように動くとは限らない。
PoC段階でこの設計まで含めて検証できているかどうかが、「動いた」と「合格」の分かれ目になる。これを提案してくれるメンバーがいれば、そのチームはとても良いチームだ。もし報告に一切触れられていなければ、あなたは一言聞いてみるといい。「新しいバージョンのLLMが出てきたら、どうするの？」と。

AIのPoCで、本当に見るべきは何か

もう一つ、PoCで見落とされやすいことがある。AIが動くためのデータが、どう流れているかだ。モデルを選ぶことよりも、必要なデータを正しい形でAIに渡し続けられる環境を設計することの方が、ずっと重要なことが多い。
これは「CDP連携、手作業は絶対悪です」で書いたことと同じ構造だ。ツールを入れることが目的になり、データの流れを設計しないまま動かし始めると、最初は動いても、詰まっていく。AIも同じだ。モデルが優秀でも、渡すデータが整っていなければ、精度は出ない。構造化されたデータならまだ良いが、非構造化データや図で示されたフロー図のままでは、人間には理解できてもAIには伝わらないことがある。業務のノウハウをどうインプットするか、まだ多くの組織でノウハウが溜まっていない部分だ。
本体は、箱ではなくデータの流れにある。

最後に

「AIを導入した」「PoCをやった」「動いた」。
この言葉を聞くたびに、私は問い返したくなる。何を検証したのか。精度の基準は何だったのか。バージョンが変わっても同じように動くか確認したか。データは自動で流れ続けているか。あなたは、確認すべきだ。
花のある話ではない。でも、これがAI導入を本当に機能させるための、地味で重要な問いだと思っている。
「動いた」は、スタートラインだ。ゴールではない。

【分類】⑥ AI×今これから ／ 公開順 10本目 ／
関連記事：CDP連携、手作業は絶対悪です（データの流れが本体という同じ構造）、「買い忘れていませんか」は、なぜ刺さらなかったのか（PDCAを高速に回すことが勝ち筋）

#生成AI #PoC #AI導入 #業務設計