AI PoC を、本番運用に
乗せるための 5 つの設計判断
AI PoC は驚くほど簡単に動きます。が、業務に乗せた瞬間に壊れます。Xiora が現場で繰り返し問われる、PoC から本番運用へのギャップを埋める 5 つの設計判断を、実装目線でまとめました。
「動く PoC」と「業務に乗る AI」は別物
ChatGPT 経由のプロンプト試行や、ノーコードツールでの自動化は、半日もあれば PoC として動かせます。デモを見れば誰でも「これは使える」と感じます。
一方で、本当の難しさは、その後にやってきます。担当者だけが動かせる仕組みから、現場 100 人が毎日使い、月次でレビューされ、必要に応じて差し替えられる仕組みに格上げするフェーズです。ここで失敗する PoC が、私たちの現場感覚では大半を占めます。
PoC が「面白い」で終わるか「業務に効く」に変わるかは、技術ではなく設計判断の問題です。順序を間違えると、半年かけても本番には乗りません。
判断 1：「業務フローのどこに着地させるか」を最初に決める
PoC でよくあるのは、「AI とチャットで会話できる UI を作る」で終わってしまうケースです。これは、業務フローに何も組み込まれていません。
本番運用に乗せたいなら、最初に決めるべきは 「AI の出力が、最終的に何のフィールドを埋め、誰に通知し、どの SaaS に着地するか」です。
- 問い合わせ仕分け AI → CRM の「優先度」「担当」「ステータス」フィールドを更新
- 見積ドラフト AI → kintone の「見積案」レコードを下書き状態で保存
- 議事録要約 AI → Notion の議事録テンプレートに自動投稿し、Slack で通知
ここを決めずに UI から作ると、後で必ず「結局運用されない」結果になります。
判断 2：プロンプトを「秘伝のタレ」にしない
PoC では、担当者が試行錯誤して育てたプロンプトが、Slack のスレッドや個人の Notion に散らばっていることがよくあります。これでは、誰も改善できません。
本番化する段階で、プロンプトは コードと同じく、バージョン管理と差分レビューの対象にします。
- Git 管理または DB の
promptsテーブルに集約する - 変更前後を比較する評価データ（10〜30 件）を準備する
- 差し替え時は、評価データで自動回帰テストを通してから本番反映する
// プロンプトはコードと並列にバージョン管理する
import { loadPrompt } from "@/lib/prompts";
const prompt = await loadPrompt("invoice_draft", { version: "2026-05-04" });
const result = await llm.generate({
prompt: prompt.compile({ customer, items }),
guardrails: prompt.guardrails,
});判断 3：ガードレールをコードに書く
LLM は確率的に振る舞います。本番に乗せた瞬間に、想定外の出力（個人情報の漏出、不適切な金額、空欄、過剰な約束）が混じります。
これを「プロンプトでお願いする」のは無理です。必ずコード側で「やってはいけないこと」を強制する ガードレール層を実装します。
- PII（個人情報）パターンを検出してマスクする
- 金額・日付など、構造化フィールドはバリデータで弾く
- 必須項目が欠けたら、ユーザーに再入力を求める
- 1 リクエストあたりトークンとコストの上限を超えたら停止する
ガードレールを最初から書いておくと、本番運用での事故が桁違いに減ります。
判断 4：観測（Observability）を最初に組み込む
PoC では、「動いた」「動かなかった」を目視で確認することが多いと思います。本番では、これでは絶対に運用できません。
最低限、次の指標を最初から収集します。
- リクエスト件数、成功率、エラー率
- レスポンス時間（p50 / p95 / p99）
- 1 リクエストあたりのトークン数とコスト
- AI ドラフトが、現場で採用された率（accept rate）
- ユーザーフィードバック（👍 / 👎、コメント）
特に accept rate を最初から取ることをおすすめします。「AI が動いているか」ではなく「AI が役立っているか」を見るための指標になります。
判断 5：失敗時の「人へのフォールバック」を必ず設計する
AI は必ず失敗します。失敗時に「ごめんなさい、わかりません」で終わるのではなく、人にスムーズに引き継ぐ動線を、業務フローの一部として設計します。
- AI が回答に自信がない場合は、担当チャネル（Slack / 担当者の LINE / メール）に自動エスカレーション
- その際、過去の文脈・関連ドキュメント・推定優先度をセットで渡す
- 引き継ぎ後の対応結果を、AI 改善のフィードバックとして蓄積する
AI 単体の精度を 90% から 95% にチューニングするより、失敗時の人へのフォールバックを設計するほうが、現場の信頼を圧倒的に早く獲得できます。
まとめ：PoC → 本番運用のチェックリスト
5 つの判断を、最後にチェックリストとしてまとめておきます。
- AI の出力が「業務フロー上のどこに着地するか」を決めたか
- プロンプトをバージョン管理 + 評価データで運用できる状態か
- ガードレール（PII / バリデーション / コスト上限）をコードで実装したか
- 件数 / 成功率 / レイテンシ / コスト / accept rate を可視化したか
- 失敗時に人へ引き継ぐ動線が、業務フロー上に定義されているか
このどれかが欠けている状態で本番に出すと、ほぼ確実に「導入したが定着せず、半年後にひっそり止まった」となります。
AI の本番運用は、モデルではなく、業務フローと運用設計が決める。
Xiora では、御社の業務と既存システムに合わせて、PoC から本番運用までを一気通貫で支援しています。「PoC は動いたが、その先が見えない」段階の方は、ぜひ 30 分の無料相談からどうぞ。