製造業で生成AIを導入するとき、最初のデモは簡単に作れても、実務へ定着させる段階で止まることがあります。数件のサンプルでは良い回答が出たのに、現場データでは精度が安定しない。利用ルールや責任者が決まらず、本番利用へ進めない。こうした「PoC止まり」を避けるには、技術検証と業務検証を一緒に設計する必要があります。
この記事では、テーマ選定から評価、運用、展開までを8つの手順で解説します。
図：現状測定から評価、現場試用まで進め、業務・品質・リスク・運用の条件で本番移行を判断する
PoCの前に決める3つのこと
解決する業務課題
「生成AIを試す」ではなく、「不具合報告の確認に時間がかかる」「過去トラブルを探せない」「標準書改訂の負荷が高い」のように、現在の業務課題を定義します。
対象者と利用場面
品質担当者が報告書を作るとき、保全担当者が設備停止時に調べるとき、教育担当者が教材を作るときなど、誰が、いつ、何のために使うかを決めます。
PoC後の判断
継続、条件付き継続、中止を判断する基準を先に決めます。基準がなければ、印象の良いデモだけが残り、投資判断ができません。
PoC企画書を1ページで作る
詳細な技術資料より先に、関係者が同じ目的を見られる企画書を作ります。
| 項目 | 記載内容 |
|---|---|
| 業務課題 | 現在の作業、困りごと、件数、時間、品質上の問題 |
| 対象・対象外 | 利用者、工程、文書、AIに任せない判断 |
| 現状値と目標 | 時間、抜け漏れ、検索成功、修正率など |
| 評価データ | 通常例、難例、情報不足、禁止例、件数 |
| 利用環境 | サービス、データ範囲、権限、保存、ログ |
| 体制 | 業務責任者、専門評価者、IT、セキュリティ、現場利用者 |
| 期間・費用 | 開始・終了、会議、利用料、データ整備、評価工数 |
| 終了判断 | 継続、条件付き継続、中止の基準 |
ここで対象外を明記すると、PoC中に「せっかくなので自動送信も試す」と範囲が広がるのを防げます。
生成AIに向くテーマの選び方
最初のテーマは、次の条件を多く満たすものが向いています。
- 発生頻度が高く、現在の作業時間を測れる
- 必要な文書やデータを準備できる
- 出力の良し悪しを専門家が評価できる
- 誤りがあっても人の確認で止められる
- 一部門で試し、他部門へ横展開できる
- 現場自身が改善を望んでいる
品質の最終判定、設備の自動制御、安全に直結する指示などは、最初のPoCとしてはリスクが高くなります。まず、要約、分類、検索、下書き、確認質問の作成から始めます。製造業のAI・生成AI活用事例15選も候補選びに使えます。
生成AI導入・PoCの8ステップ
1. 現状を測る
対象業務の件数、作業時間、手戻り、検索時間、担当者ごとの差を測ります。導入前の数値がなければ、導入後の効果を説明できません。
2. 利用範囲と禁止範囲を決める
入力できる情報、利用サービス、対象者、出力の用途を決めます。機密情報を使う場合は、契約、保存、学習利用、権限、ログを確認します。詳しくは製造業で生成AIに機密情報を入力してよいかをご覧ください。
3. 評価用データを作る
日常的な例だけでなく、難しい例、情報不足の例、過去に判断が割れた例を含めます。正解が一つでない業務では、「含めるべき項目」「してはいけない回答」「人へ確認すべき条件」を定義します。
4. 現行業務を基準に評価する
AI出力だけを見るのではなく、人だけで作業した場合と比較します。時間、抜け漏れ、修正量、再現性、利用者の負荷を確認します。
5. 人の確認を業務フローへ入れる
誰が出力を確認し、どの条件で差し戻し、どこへ記録するかを決めます。「必ず確認する」だけでは運用できません。数値、規格、顧客条件、引用元など、確認項目をチェックリストにします。
6. 例外時の動きを決める
回答できない、文書が見つからない、矛盾する情報がある、サービスが停止した、といった場合の代替手順を決めます。AIを使えないと業務が止まる設計にしないことが大切です。
7. 現場で試し、改善する
開発担当者のデモだけでなく、実際の利用者が通常業務の中で試します。使われなかった場合は、抵抗感と決めつけず、入力負荷、画面、回答粒度、確認責任を調べます。
8. 本番移行と横展開を判断する
目標を満たした場合も、データ更新、権限管理、問い合わせ、モデル変更時の再評価、費用管理を決めてから本番へ移します。横展開では、部門ごとの用語や承認手順の違いを確認します。
PoCチームの役割分担
小規模でも、役割を省略すると評価と承認が同じ人に集中します。
| 役割 | 主な責任 |
|---|---|
| スポンサー | 目的、予算、許容リスク、本番移行を判断する |
| 業務責任者 | 現行フロー、対象範囲、最終確認者を定義する |
| 専門評価者 | 出力の正しさ、重大度、修正内容を判定する |
| 現場利用者 | 操作、回答粒度、通常業務での負荷を評価する |
| IT・セキュリティ | 認証、権限、保存、ログ、障害時対応を確認する |
| 推進担当者 | 計画、課題、評価結果、変更履歴を管理する |
業務責任者と専門評価者が同一でも構いませんが、生成AIの試作担当者だけで合否を決めないようにします。
PoCの評価指標
評価は、効果、品質、リスク、定着の4群に分けると整理しやすくなります。
| 評価群 | 指標例 |
|---|---|
| 効果 | 一件当たり作業時間、検索時間、処理件数 |
| 品質 | 必須項目の充足、誤り、見落とし、修正率 |
| リスク | 機密情報、根拠不明回答、権限逸脱、ログ追跡 |
| 定着 | 利用率、継続率、問い合わせ、満足度、教育時間 |
「回答精度90%」のような一つの数字だけでは不十分です。残り10%の誤りが軽微な表現なのか、安全や顧客要求に関わる内容なのかで、意味が大きく異なります。
受入条件は重大度と一緒に定義する
たとえば「必須項目の充足率95%以上」に加え、「安全・法令・顧客要求に関する重大な誤りは0件」「根拠がない場合に要確認と表示できる」「確認を含む総作業時間が現行より短い」と定義します。
誤りは、表現修正、業務上の軽微な誤り、判断を誤らせる重大な誤りに分けます。また、平均値だけでなく、利用者別、文書種類別、通常例・難例別に確認します。受入条件を満たさない場合は、モデル変更だけでなく、対象範囲、元文書、入力様式、人の確認方法を見直します。
評価用データの作り方
たとえば不具合報告の整理なら、次のようなケースを含めます。
- 情報が十分で、原因と対策が明確な例
- 事実と推測が混ざっている例
- 必須項目が欠けている例
- 類似するが原因が異なる例
- 複数製品・工程に影響する例
- 顧客情報や個人情報を含む例
- AIが回答せず、人へ確認すべき例
評価者が同じ基準で判定できるよう、正解文だけでなく、確認観点と許容範囲を用意します。
6週間の進行例
| 期間 | 主な活動 |
|---|---|
| 1週目 | 業務課題、現状値、対象者、リスクの整理 |
| 2週目 | データ選定、情報区分、評価基準の作成 |
| 3週目 | プロンプト・検索・画面の試作 |
| 4週目 | 代表例と難例による専門家評価 |
| 5週目 | 現場利用、手順・チェックリストの改善 |
| 6週目 | 効果測定、本番条件、継続・中止判断 |
期間は対象業務とセキュリティ審査により変わります。短期間にすること自体より、判断に必要なデータをそろえることを優先します。
PoC費用で見落としやすい項目
生成AIの利用料だけで見積もると、本番で費用が増えます。業務整理、文書の選別と匿名化、正解・評価基準の作成、専門家レビュー、画面や既存システムとの連携、セキュリティ審査、教育、運用保守を分けて見積もります。
本番費用は、利用者数、質問数、文書量、モデル単価だけでなく、文書更新、問い合わせ、ログ確認、再評価の担当工数を含めます。PoC中に一件当たりの処理量と専門家の確認時間を記録すると、横展開時の費用を試算しやすくなります。
PoCが失敗しやすいパターン
成功条件が「動くこと」だけ
生成AIが文章を返せば技術デモは成功ですが、実務効果は分かりません。業務KPIと受入条件を決めます。
良いサンプルだけで評価する
難しい例や情報不足の例を含めないと、本番での事故や修正負荷を予測できません。
現場が最後に参加する
完成後に説明するのではなく、テーマ選定、評価項目、試用の段階から現場に参加してもらいます。
文書とデータの管理者がいない
検索対象が古くなれば、AI回答も古くなります。文書の所有者と更新手順を決めます。
PoC後の予算と責任者がない
本番環境、運用、教育、改善の費用と責任者を、PoC開始前から想定します。
本番移行の4つのゲート
本番へ進む前に、次の四つをそれぞれ合格・条件付き合格・不合格で判定します。
- 業務：現行より総作業時間や品質が改善し、利用場面と対象外が明確
- 品質：難例を含む評価で重大な誤りを管理でき、専門家の確認手順が機能
- リスク：契約、機密情報、権限、ログ、誤入力・障害時対応を確認済み
- 運用：文書所有者、問い合わせ、教育、費用、モデル変更時の再評価が決定
条件付き合格では、残課題、暫定対策、責任者、期限を明記します。本番移行後も、初月・3か月・6か月などの時点でKPIと事故・修正傾向を確認し、利用範囲を広げるか戻すか判断します。
まとめ
製造業への生成AI導入では、デモの見栄えより、業務課題、評価用データ、人の確認、セキュリティ、運用を一体で設計することが重要です。PoCは技術の品評会ではなく、本番で使える条件と使わない条件を明らかにする活動です。
全体の前提を整理したい場合は製造業DXの課題と生成AI活用の進め方もご覧ください。
製造業向けの講座については、製造業DX実践シリーズをご確認ください。