生成AIのPoCを本番移行する。動くデモを業務へつなぐ判定手順
検証環境の画面には、用意した質問へのきれいな回答が並んでいます。ところが、本番の顧客データをつなぐ段階になると、閲覧できる社員、誤回答の連絡先、夜間に止める人が決まっていません。
「生成AI PoC 本番移行」と検索している担当者へ、僕は正答例が並ぶデモだけでは公開しないと伝えます。本番へ進める条件は、実データでの受入試験、利用者ごとのアクセス制御、誤回答を業務へ流さない仕組み、運用中の監視、名前の付いた担当者、手作業へ戻す停止手順が揃うことです。
PoCでは、生成AIが業務を手伝える可能性を確かめます。本番では、生成AIが間違えても業務を安全に完了できるかを確かめます。二つの合格は別です。
生成AIのPoCを本番移行できるのは、六つの空欄が埋まったときです
生成AIのPoC止まりは、担当者の技術力だけが原因ではありません。発注範囲がデモの完成で終わり、業務部門が受け入れる条件や、公開後に使う運用時間が予算へ入っていない場合があります。検証の成功条件に「動く画面」しか書かれていなければ、開発者は動く画面まで作って仕事を終えます。
僕なら、本番移行の判定表に六つの欄を作ります。
- 対象業務では、誰が何を受け取り、どの状態まで仕上げるのかを書きます。
- 実データでは、参照元、送信する項目、保存先、保持期間、利用できる人を書きます。
- 受入条件では、許容する修正と、公開を止める重大な誤りを分けます。
- 実行範囲では、生成AIが提案だけを作るのか、送信や更新まで行うのかを決めます。
- 運用体制では、出力の確認者、アラートを見る人、事故対応を決める人を実名で置きます。
- 停止手順では、機能を切り、認証情報を無効化し、以前の業務手順へ戻す方法を試します。
六つのうち一つでも空欄なら、PoCの延長として社内の限定利用を続けます。公開日を先に決め、空欄を公開後の宿題に回す進め方は勧めません。生成AIの誤りは、運用担当者が初めて見る入力で発生しやすいからです。
NISTのAIリスクマネジメントフレームワークは、AIを導入前に試験し、運用中も定期的に評価する考え方を示しています。人が出力を監督する方法の文書化や、本番環境における挙動の監視も含まれます。
NISTの資料は任意利用のリスク管理枠組みであり、特定製品の安全性や本番移行の成功率を示す試験結果ではありません。僕は合格点を借りるのではなく、判定表の空欄を探すために使います。
生成AIの本番移行前に、実データで受入試験を作ります
PoC用の質問は、開発者が回答を作りやすい形へ整えがちです。本番には、必要な資料がない問い合わせ、古い規程を参照した文章、複数の依頼が混じった長文、入力ミス、対象外の質問も入ります。正解しやすい入力だけで測った精度は、公開後の業務を表しません。
たとえば、社内規程に基づく問い合わせ回答案を作るなら、直近の完了案件から試験用の入力を選びます。通常の質問だけでなく、根拠資料がない質問、改定前後の記述が衝突する質問、回答してはいけない質問も含めます。個人情報が不要なら削除し、必要なら本番と同じアクセス制限の中で扱います。
試験用の入力を、指示文や検索設定の調整へ使い回しません。調整に使う集合と、最後に合否を判定する集合を分けます。モデル名、指示文の版、参照資料の版、検索条件を記録し、同じ条件で再試験できるようにします。
見る数字は、回答が自然かどうかだけでは足りません。必須項目の欠落、根拠のない記述、参照箇所の誤り、人が直した箇所、確認を含む業務全体の所要時間を記録します。生成AIの処理時間が短くても、確認と修正が増えたなら業務は速くなっていません。
受入基準は、誤りが業務へ与える被害から決めます。語尾の修正と、顧客へ誤った金額を案内する出力を同じ一件として数えてはいけません。顧客との約束、支払い、合否、法的判断へ触れる重大な誤りが出た場合は、平均点が高くても外部公開を止めます。
試行前後の作業時間と手戻りを同じ単位で比べる方法は、MVP開発の費用と見積もりでも説明しています。利用回数や回答件数を、業務成果へ言い換えない測り方が必要です。試作品の目的と外注範囲を先に分ける考え方はプロトタイプ開発を外注する前の決め方で整理しています。
生成AIのPoCを本番データと利用者権限へ接続します
受入試験を通過したら、データの流れを一枚にします。利用者が入力する画面から、前処理、検索先、モデル提供者、ログ、出力の保存先まで矢印でつなぎます。矢印ごとに送る項目、暗号化、保存期間、削除方法を確認します。
外部のモデル提供者へ実データを送る場合は、入力データの学習利用、保管場所と期間、再委託、削除、事故時の通知、提供終了時の移行方法を契約書と管理画面で照合します。確認できない項目が残る間は、実データを送らない構成にします。
PoCで使った共有アカウントや開発者の認証情報は、本番へ持ち込みません。利用者ごとにログインさせ、所属部署と業務に必要な文書だけを検索できるようにします。退職済みとして無効化したテストアカウント、別部署のテスト利用者、別の顧客を担当するテスト利用者で接続を試し、権限外の文書名や要約が回答へ混じらないことを確認します。
生成AIへ渡す操作も小さくします。回答案の作成と顧客への送信、データの検索と更新、申請内容の確認と承認を分けます。取り消せない操作や顧客へ直接届く操作は、人が対象と差分を確認してから実行します。
本番の認証情報を生成AIへ直接渡さず、下流のシステムでも操作できる範囲を制限します。会社名義のアカウントと権限を引き継ぐ考え方も、判定表へ記録します。
外部文書を検索対象にする場合は、文書内の命令文が生成AIの動作を変える入力も試します。入力検査を通過した場合でも、閲覧権限のない情報を取得できず、送信や削除へ進めない構成にします。権限外の応答を一件でも再現したら、検索対象を狭めて受入試験へ戻ります。
生成AIの本番運用では、誤回答とモデル変更を監視します
一般的なシステム監視だけでは、生成AIの異常を見落とします。応答成功率、待ち時間、タイムアウト、利用額に加えて、根拠を表示できなかった回答、人が却下した回答、修正箇所、手作業へ戻した件数、利用者からの報告を見ます。
監視の単位はAPI呼び出しだけにしません。一件の問い合わせが完了するまでに複数回呼び出す場合、業務一件あたりの利用額と確認時間も記録します。月末の請求額が予算内でも、同じ回答を何度も作り直している状態は改善が必要です。
調査に使うログには、実行ID、利用者、時刻、モデルと指示文の版、参照した文書ID、出力後に人が選んだ操作を残します。入力全文や出力全文に個人情報や秘密情報が含まれる場合は、無条件に複製しません。調査に必要な項目、閲覧者、保存期間を先に決めます。
モデル、検索処理、参照資料、指示文のどれかが変われば、以前の合格結果を流用できません。変更前の受入試験を再実行し、限定した利用者へ先に公開します。重大な誤りが増えた場合に、前の版へ戻せる状態を保ちます。
デジタル庁の生成AIの調達・利活用に係るガイドライン第2.0版は、企画、構築と公開準備、提供、利用、リスク事象への対応を役割ごとに分けています。政府情報システムを対象とする規範であり、民間企業の法的義務や安全認証を示す資料ではありません。僕は、公開後の担当が開発会社だけへ残っていないかを確認する責任表として参照します。
誤回答が見つかったときは、利用者が画面から報告できるようにします。運用担当者は入力、参照資料、出力、採用した操作を実行IDで追い、同じ条件を再現します。顧客へ届いた場合の連絡、訂正、影響確認は、業務責任者が判断します。
停止条件には、権限外データの表示、顧客への誤った確約、監査ログの欠落、利用額の急増、提供者側の障害などを書きます。停止時は機能フラグを切り、認証情報を無効化し、未処理の案件を以前の手順へ戻します。停止ボタンがあるだけで安心せず、検証環境で復帰まで試します。
入力情報と誤回答を会社の利用範囲から整理したい場合は、中小企業のセキュリティ対策で最初に確認する管理画面も確認してください。本番移行では、利用者の注意力より先に、システム側で入力と実行範囲を制限します。
生成AIのPoCを本番移行する判定会議では、三つの資料を開きます
本番移行の会議で開く一つ目の資料は、受入試験の結果です。平均点だけでなく、試した入力の種類、各版の番号、重大な誤りの内容、確認者の修正を見ます。失敗例を隠した報告書では、公開後の対応を決められません。
二つ目は、データフロー図とアクセス設定の画面です。どの保存先から何を読み、外部へ何を送り、誰の認証情報で動き、どのログへ残るかを一件たどります。図と実際の設定が違う場合は、設定を直してから再判定します。
三つ目は、運用手順書です。アラートの通知先、出力を確認する人、停止を決める人、手作業へ戻す担当者、再開を承認する人を実名で読み上げます。休日や退職で名前が空いた場合に、機能が動き続けない運用も必要です。
判定は「全社公開」か「中止」かの二択ではありません。指定部署だけに公開し、承認済み文書の検索と回答案の作成まで許可できます。顧客への送信は人が続け、記録が揃ってから対象部署や操作を広げます。
明日は、PoCのデモ画面ではなく、直近の完了案件、IAMの設定画面、障害対応の連絡表を開いてください。六つの判定欄へ証拠となる資料と担当者名を記入します。空欄が残る間は回答案の作成に留め、六つを実地で確認できた段階で限定公開へ進めます。
次に読む