INSIGHT
デモが動いた。それだけで、現場への導入を押し切るな
デモで回答案が出ても、受付から承認、送信、訂正まで仕事が通るとは限りません。受渡し、例外、承認、手戻りを確かめ、導入できる範囲を決めます。
会議室の画面では、質問を入れると数秒で回答案が出た。用意した資料も参照できている。役員の一人が「来月から全員に使わせよう」と言い、導入日を決める話が始まる。
その場で、決裁を止めてほしい。
見えたのは、選んだ人が、選んだデータと質問で、画面を動かせたことだ。問い合わせを受け取る前の準備、回答を送る人の承認、資料不足の例外、誤答後の訂正、担当不在時の引継ぎまでは確認していない。そこを「現場で調整する」と残したまま、利用を義務づければ、未完成の工程と責任を現場へ渡すことになる。
受渡し、例外、承認、手戻りが未確認なら、全社導入や利用義務づけの決裁へ進めない。
デモの成功条件を、拡大解釈しない
デモには大切な役割がある。欲しい画面を具体化し、利用者が早い段階で意見を言える。だからこそ、成功した条件を短く残す。誰が操作したか。どのデータと質問を使ったか。回答案を作っただけか、外部送信や記録更新まで行ったか。人はどこで確認したか。
デモは、機能や体験を目に見える形で確かめる場である。実業務条件は、通常の量と時間制約の中で、前後の工程、権限、例外、記録まで含めて仕事が成立する条件だ。前者の成功は、後者の確認を始める根拠にはなる。しかし、そのまま置き換える根拠にはならない。
導入会議の資料も二列に分けたい。左に、今回確認できた条件。右に、まだ試していない利用者、データ、操作、繁忙時、例外を書く。「回答案が表示された」を「問い合わせ対応が完了した」と言い換えない。この区別が、デモの成果を小さくすることはない。次に確かめる範囲を正確にする。
一件の仕事を、受渡しまで通して見る
問い合わせ対応なら、画面に質問を入れるところから始めない。依頼を受け付け、扱ってよい情報か判断し、資料を探し、回答案を作り、担当者が承認し、相手へ送り、対応記録を残す。誤りが分かれば訂正し、必要な相手へ連絡する。ここまでが一件の仕事だ。
受渡しは、前の工程の結果を次の担当者や仕組みへ渡し、仕事を続けられる状態にすることをいう。AIの回答案を誰が受け取るのか。根拠不足を誰へ戻すのか。承認待ちが期限を越えたら誰が引き取るのか。次の担当者、渡す情報、期限の三つが決まらなければ、画面の外に滞留が生まれる。
通常の一件に加え、少数でも重要な例外を通す。必要な入力が足りない。参照資料が古い。承認者が休んでいる。利用者が対象外の案件を入れる。目的は、すべての異常を予測することではない。止める人、判断する人、連絡する相手、残す記録を確かめることだ。
「現場が補えば回る」で済ませず、誰が、いつ、何を補うかを決める。担当と時間がない手作業は、未設計の仕事として残っている。
PoCで止まることを、失敗と決めつけない
PoC（概念実証）は、限られた条件で、技術や業務上の仮説を確かめる試行である。そこで「役立つ条件が狭い」「前後工程の負担が大きい」「必要なデータを用意できない」と分かったなら、PoCは判断材料を生んでいる。全社導入へ移らなかったという一事だけで、失敗とは言えない。
PoCの出口は、本番導入だけではない。対象を絞って試行を続ける。業務手順やデータを整えてから再開する。費用と手戻りを見て見送る。別の課題へ移る。最初に、この複数の出口と判断者を決めておけば、「ここまで費用をかけたから」という理由で導入を押し切らずに済む。
RANDの研究報告 は、65人への聞き取りから事業課題と技術のずれ、データや基盤の問題を整理している。既存の大規模言語モデルをプロンプトで使うだけの案件は調査対象外であり、生成AIのPoCが本番へ進まない割合を測った研究ではない。ここでは、解く課題と実装条件の対応を見るという観点を借りている。
承認と手戻りを、利用開始前に設計する
現場が使い始めた事実は、現場が業務責任まで受け入れた証拠ではない。受入れ条件は、どの結果なら使い、どの結果なら人へ戻すかを、業務側が利用前に合意した条件である。根拠が表示されない回答は送らない。期限が近い案件は人が処理する。対象外の質問は窓口へ戻す。こうした境界を、利用者、業務責任者、仕組みの担当で決める。
承認は、AIが出した案を眺める作業ではない。誰が、何を根拠に、送信や更新を許可するかを決める判断だ。承認者が修正した場合は、修正後の内容を正式な結果として残し、同じ問題をどこへ返すかも決める。
この戻し先を持つ流れが手戻りである。資料不足なら文書管理者へ、業務ルールが曖昧なら業務責任者へ、画面や連携の不具合なら仕組みの担当へ戻す。何でも利用者が書き直す運用にすると、問題が記録されず、改善の費用だけが現場へ積み上がる。
支援企業が公表したJALの生成AI活用事例 では、対象業務を三つに絞った試作、空港での実証、回答根拠の表示や情報更新を含む展開が紹介されている。これは支援企業による顧客事例であり、独立した効果測定でも、同じ進め方が自社で成功する保証でもない。対象を絞り、根拠と更新を実業務の確認へ含めるという検討材料として読める。
再開条件が書けるまで、導入日を決めない
止めるのは、デモや小規模な試行ではない。前後工程を確かめず、利用者へ使用を義務づける決裁である。再び導入を議題に載せる条件を、先に五つ置く。
第一に、代表的な一件を受付から完了、必要なら訂正まで通し、残る手作業を記録している。第二に、受渡しごとの担当、渡す情報、期限が決まっている。第三に、重要な例外で、停止、承認、連絡、手戻りの経路を試している。第四に、対象業務、利用者、データ、許可する操作を限定した受入れ条件へ現場が合意している。第五に、見直す日と、継続・縮小・停止を決める人が決まっている。
条件を満たさないなら、回答案の作成だけに戻す、対象の問い合わせを絞る、外部送信や更新を外す。すでに利用を始めている場合は、元の手順へ戻れることも確認する。導入を再開する条件と、元へ戻す条件を同じ決裁書に置く。
これは外部資料が直接命じている手順ではない。研究や公表事例で確認できる論点を、自社の一件の業務へ当てはめた判断である。採用する条件は、自社の業務フロー、権限、試験結果、現場の合意で確かめる。
導入日を決める前に、一件の業務を通して再開・撤退の条件を合意する
デモが動いたことは、次の確認へ進む成果だ。PoCで条件が合わないと分かったことも、止める判断に使える成果である。どちらも、現場へ導入する理由へ自動的に変わるわけではない。
会議でいま戻すべきなのは、試作そのものではなく、導入日を先に決める議題だ。一件の受渡し、例外、承認、手戻りを通し、再開と撤退の条件を現場と合意する。その後に、確認できた範囲だけを導入する。そこまでが、デモの成功を仕事の成功へつなぐ判断である。