PoC で何を成功と判断したか？
PoC は限定した条件で仮説を確かめる試験です。用意した製品文書から仕様を見つけられたなら、その文書と質問における実現可能性が確認できました。すべての営業問い合わせに対応できるか、担当者を介さず案内してよいかは別に検証します。
NIST の生成 AI プロファイルは、狭い範囲の非体系的な評価や事例から性能を一般化しないよう勧めています。配備に近い条件で評価し、適用限界や生成した根拠・出典を確認します。[1]
架空の B2B 卸売会社を考えます。製品マニュアルを検索する AI を試作すると、デモでは仕様や配送案内を素早く見つけられました。それでも担当者は従来の画面を開き、返信を手で作っています。
実際の問い合わせには取引先別単価、更新された在庫、分納と取消可否が混ざります。マニュアルには情報がなく、入力された注文番号が別の取引先を指すこともあります。初めから事実を確認し直すなら、文章の作成時間が短くても全体の処理時間は下がりません。
モデルを入れ替える前に、業務のどの条件が不足していたかを洗い出します。
| デモで分かったこと | 実業務で確かめること | 残す証拠 |
|---|---|---|
| 仕様を検索できる | 顧客に開示可能な最新版を取得できる | 文書の版、権限と根拠箇所 |
| 自然な返信を書ける | 条件の抜けと根拠のない約束を判別できる | 確認項目、編集履歴、所要時間 |
| 注文番号を読み取れる | 認証済みの取引先に属する注文か | 識別と認可の結果 |
| 短時間で回答を生成する | 確認待ちと再処理を含めて早く終わるか | 受け付けから完了までの記録 |
| よくある質問に対応できる | 欠損や矛盾があるときに保留し人へ渡せるか | 例外分類と引き継ぎ記録 |
右欄が空なら、パイロットで確認する課題が残っています。未確認を明記すると次の投資対象を絞れます。
最初にどの業務を選ぶか？
ここでの AX は、AI などを使って業務の遂行方法や責任の持ち方を変える取り組みです。最初は、誰が何を受け取って何を完了するか、一文で示せる業務を選びます。
Google の People + AI Guidebook は、利用者の課題と AI の強みが重なる点を探し、自動化と人の補助を検討します。性能の向上と合わせて、誤りが起きたときの影響も考えます。[2]
下の表を候補の比較に使います。データ利用が認められないケースや、誤りの影響を抑えられないケースは、件数が多くても縮小・保留します。
| 判断項目 | まず聞くこと | 試験に有利な条件 | 縮小・保留する条件 |
|---|---|---|---|
| 頻度 | 同じ作業がどれだけ発生するか | 比較できる件数と履歴がある | 発生が少なく評価資料が不足 |
| 遅延 | 担当者の手間や待ち時間はどこにあるか | 検索・分類・下書きに明確な滞留 | 外部承認や物理配送で滞留 |
| 誤りの影響 | 間違うと誰に何が起きるか | 事前確認や取り消しができる | 金銭・権利・安全へ直ちに影響 |
| 検証可能性 | 何と比べて正しいと判断するか | 原典、業務ルール、完了状態を見られる | 正解や許容範囲が担当者ごとに異なる |
| データと権限 | 必要な事実の利用は認められるか | 出典、所有者、適用期間と権限が明確 | 共用アカウントや無制限のアクセスが必要 |
| 例外時の復帰 | 誰が続きの作業を受け持つか | 既存の手順と担当者がある | 失敗や復帰の責任者がいない |
架空の卸売会社なら、公開製品資料から根拠を探す下書きで始められます。契約単価の確定や注文変更は既存の担当者が行います。取引先や注文が不明なら、先に識別を済ませます。
各工程に適した仕組みを割り当てます。指定レートの計算と必須項目の確認はルールで処理できます。自然文の意図解釈や複数資料からの検索を AI に任せ、認可や金額確定を業務システムで確認します。
Anthropic は単純なパターンから開始することを勧めています。所定の業務では事前に決めたフローが予測可能性を高めます。自律性を上げる場合は処理できる範囲と費用・遅延を比較します。[3]
要件から承認までつながる根拠 — 要件、テスト、不具合対応、承認記録をつなぎ、共通の基準で品質を判断します。
プロンプトの前にどんな完了条件を書くか？
「正確に回答する」だけでは開発と運用で完了の意味がずれます。担当者は顧客が次へ進める状態を想定し、開発側はテキスト生成時点を正常処理として記録するかもしれません。
試験開始前に次の項目を一枚にまとめます。業務用の記載例です。
- 入力 認証済み取引先の問い合わせ、確認済み製品 ID、閲覧を許可した文書。
- 出力 下書き、根拠の位置、未確認条件、必要な追加質問。
- 完了 担当者が根拠と対象を確認し、承認した返信が送られて元の案件に履歴が残る。
- 対象外 新規契約単価、返金承認、数量変更、他社のデータ閲覧。
- 保留 文書の矛盾、現在値を確認できない状態、製品不明、認可の失敗。
- 責任 ルール所有者、システム運用者、確認者、例外を決裁する責任者。
完了を定義すると不足する画面やデータが見えます。確認者には下書きと根拠を示します。誤答を追うには文書の版と実行記録が必要です。完了案件が待ち行列へ戻るなら、モデルの外の状態管理も点検します。
NIST AI RMF はガバナンス、状況把握、測定、管理を結び付けます。この定義票はその観点を業務へ適用したものです。[4]
実業務に使えるデータとは？
重要な事実ごとに、正本、有効な期間、閲覧を認める相手を示せるようにします。
仕様の正本は製品文書でも、在庫は在庫システム、取引先別の単価は契約管理にあります。一つの文書にコピーすると検索しやすくなる一方で、更新時刻と責任が曖昧になります。事実ごとに正本と確認時刻を結び付けます。
「今週届きますか」には製品、数量、届け先、在庫の確認時刻、出荷締め時刻が必要です。不足時は一般条件を案内して追加の情報を求めます。到着の確約には確認済みの根拠が必要です。
マニュアルと告知が矛盾したときの扱いも決めます。新しいファイル名だけで判断せず、承認状態や担当者への引き継ぎを使います。閲覧権限のない資料が検索、要約、返信に出ないことを実際の権限で試します。
開発用の事例と最終評価の事例も分けます。いつも見る入力に合わせた改善と、未知の入力への改善を区別するためです。通常業務と低頻度でも損失が大きい例外を含めます。例外を厚くした評価の比率は記録して、実運用の発生率と区別します。
業務全体の負荷をどう比較するか？
導入前の処理量、実作業時間、待機時間、再処理率を同じ定義で記録します。繁忙週と閑散週の合計だけを比べると、需要の差が改善効果に見えます。
少なくとも次の三つを測ります。
| 評価層 | 確認すること | 指標の例 |
|---|---|---|
| 出力品質 | 事実と不明点を正しく扱ったか | 根拠一致、条件漏れ、誤った約束、確認者の不一致 |
| 業務遂行 | 実際に一件を終えられたか | 対象中の完了数、修正時間、再処理、引き継ぎ |
| 運用 | 利用でき、失敗後も復旧するか | 遅延、依存先障害、費用、拒否、手動復帰時間 |
分母を固定します。1,000 件から簡単な 200 件を選んだ場合、完了率はその部分集合に対する値です。全件、適格件数、利用件数、承認完了、保留と失敗を併記します。担当者へ渡した分も集計に含めます。
可能なら難易度が似た作業を従来方式と AI 支援で比較します。無作為に割り付けられないなら、問い合わせの種類、担当者の経験、時期の違いを記録します。習熟に必要な研修や時間も導入費に含めます。
Google Cloud の運用ガイドは、配備後に実際の出力や利用者のフィードバックを観察し、入力分布の変化も考慮します。試験結果は測定した条件と合わせて扱います。[5]
仮の計算では 120 時間にどんな価値があるか？
試算の例です。全問い合わせの難易度と従来の平均時間が等しいと仮定します。
| 項目 | 前提・計算 | 月の時間 |
|---|---|---|
| 従来方式 | 2,000 件 × 12 分 | 400 時間 |
| AI 利用 60% | 1,200 件 × 確認・修正を含む 5 分 | 100 時間 |
| 従来方式 40% | 800 件 × 12 分 | 160 時間 |
| 追加運用 | 文書・評価・例外処理 | 20 時間 |
| 導入後合計 | 100 + 160 + 20 | 280 時間 |
| 確保した余力 | 400 − 280 | 120 時間 |
時間単価を 3 万ウォンとすると、月の時間価値は 360 万ウォンです。月のモデル・ツール・インフラ費用を 70 万ウォンと置けば純便益は 290 万ウォンになります。整備・研修・評価に一度だけ 870 万ウォンがかかる場合、この仮定での単純回収は 3 か月です。
便益は空いた時間の使い方に依存します。給与、外注費、時間外手当が同じなら、現金支出は月 70 万ウォン増える場合があります。滞留案件の処理、応答時間、売上への寄与も別に計測します。
5 分には対象全体の修正と、失敗後の手動作業を含めます。成功例だけの平均では効果を過大に見積もります。追加の 20 時間と案件ごとの処理に同じ作業を二重計上せず、時間が極端にかかる事例も調べます。
担当者は実際に介入できるか？
確認者には回答と根拠、現在の状態を並べて見せます。送信を止める権限と修正を保持する仕組みも必要です。承認ボタンに加えて介入が働くかを試します。
Microsoft の Responsible AI Standard v2 は監督の担当者を決め、利用目的と動作を理解し、必要時に介入・停止できる機能を定めています。現実的な条件で監督機能を評価します。これは Microsoft の標準です。[6]
数値、対象、約束を根拠と照合し、修正、差し戻し、引き継ぎを選べるかを試験します。確認待ちが長引くときの優先順と、担当者が不在のときの引き継ぎ先を決めます。
採用状況はログイン件数だけで測らず、下書きが使われなくなった箇所を観察します。根拠の再検索、不要な画面遷移、権限不足、編集の消失などを扱える改善項目にします。
例外を誰に引き継ぐか？
回答できない問い合わせにも次の手順が必要です。Google のエラー対応ガイドは、失敗原因を把握し、失敗後に使える行動を示す方法を説明します。[7]
この卸売会社では、どこまで処理したかを記録し、同じ業務を繰り返さず従来のフローへ戻すようにします。
| 発見した条件 | 次の動作 | 引き継ぐ担当 | 再開前の確認 |
|---|---|---|---|
| 製品・注文が不明 | 下書きを保留し不足項目を示す | 問い合わせ担当 | ID が対象案件と一致 |
| 文書二つが矛盾 | 根拠を示し確答を保留 | 文書所有者・業務担当 | 承認済みルールと適用日 |
| 正本システムを参照できない | 照会不可を示し手作業へ | 運用者 | 処理状態と重複有無 |
| 無権限の参照を検出 | 拒否し影響を調査 | セキュリティ・データ担当 | 露出範囲、修正と再試験 |
| 送信結果が不明 | 送信履歴を照合する | 送信運用担当 | 事業側と配信側の状態 |
パイロット中に一度は復帰を訓練します。一時停止しても待機案件を保全し、既存画面から担当者が続行でき、完了済みの処理が二重に実行されないことを確認します。修正後は再現事例を回帰試験に追加します。
30 日でどんな判断材料を作れるか？
対象の小さい問い合わせ下書きを想定した日程です。データ接続、認可、試験件数に応じて延びる場合があります。
| 期間 | 作業 | 次に進む証拠 |
|---|---|---|
| 1～5 日 | 観察、業務を選択、完了・対象外と基準線を定義 | 責任者と比較指標 |
| 6～10 日 | データと権限を確認し、最小フローと保留条件を準備 | 必須データと判定条件 |
| 11～17 日 | オフライン比較、通常・例外試験、確認者の作業を検証 | 重大な漏れが修正され、限定範囲を合意 |
| 18～24 日 | 承認済み案件・担当者で実施、修正・時間・費用を記録 | 実業務と手動復帰の証拠 |
| 25～30 日 | 原因と費用を整理し、拡大・縮小・保留を判定 | 責任、停止条件、次の確認日 |
判断のしきい値は実測の基準線と業務リスクに応じて決めます。
- 拡大検討 確認・再処理込みの負荷が下がり、権限と証拠を確かめ、例外を現場で引き継げる。
- 範囲調整 便益を確認した対象を維持し、他の案件を従来の手順へ送る。
- 保留 根拠、必須データ、例外の担当が不足している。条件を整えて再評価する。
- 即停止・調査 情報の誤開示、無承認の外部操作、注文の重複などが発生した。
試験件数が少ないと重大な事象を観測できない場合もあります。対象範囲、検知方法、停止権限、次のレビュー日を残します。
次の会議で何を決めるか？
モデルの検討と合わせて、確認する業務条件を決めます。
- 最初に変える業務と、完了を判断する人は誰か。
- データの正本と閲覧権限を誰が管理するか。
- 確認・修正・例外対応込みの成果をどう比べるか。
- どの条件で止め、誰が従来の手順を引き継ぐか。
- 拡大を承認する人と次の確認日はいつか。
パイロットの範囲を決めるときは、現行手順と PoC の結果を持ち寄り、データ・連携・QA で先に調べる項目を選びます。
IXC の Qoretix は、実行結果、失敗の証拠、未検証範囲、再検査の記録を確認する QA の流れを案内しています。実際の利用経路にどの記録を対応させるか検討します。AI の回答基準、評価用データ、引き受けるリスクは業務ごとに定義します。[8]
