AIを業務に入れようとして止まる場所は、だいたい決まっています。しかも技術の問題ではないことが多い。
先に知っておけば避けられるものを5つ挙げます。
①効果を測る指標を決めていない
「便利になった気がする」で終わると、次の予算が通りません。
かといって、利用率や利用回数を指標にするのも危うい。担当者がひとりで増やせる数字は、指標として弱いからです。
置くなら、外に相手がいる数字。ある業務が何時間で終わるようになったか。手戻りが何件減ったか。同じ人数で処理できる件数が増えたか。どれも測るのは面倒ですが、面倒だからこそ作れません。
導入の前に、いまの状態を測っておくのが肝心です。後から比べようとしても、前がどうだったか誰も覚えていません。
②入れてよい情報の線引きがない
現場が最初に困るのがここです。この資料を貼っていいのか分からない。
禁止事項を並べるより、許可するものを挙げるほうが機能します。「公開情報と、社内で共有可の資料は入れてよい」と書けば、それ以外は相談に回る。列挙漏れが起きません。
線がないと、判断できる人は使わなくなり、気にしない人はそのまま進めます。どちらも困った結果です。
③向いていない仕事に使っている
出てきた答えが正しいかを、人がすぐ判断できる仕事。ここは安全です。文章の下書き、要約、コードの叩き台、翻訳。間違っていれば読めば分かります。
危ないのは、確認するほうが自分でやるより手間のかかる仕事。数十件の数値を突き合わせる、法令の条番号を拾う、出典を集める。全部を検算するくらいなら最初から自分でやったほうが早くなります。
この線引きは、モデルの性能が上がっても動きません。精度が99%になっても、残る1%を見つける手間は同じだからです。
④確認の工程を人の作業として組んでいない
「確認すること」とだけ書いたルールは、実行されません。
誰が、何を、いつ確認するのかまで決める。特に数字と出典は、目で追う工程を明示的に置いたほうがよい。もっともらしい嘘が混ざる構造がある以上、そこを人が受けるしかありません。
工程として組めば、時間の見積もりにも入ります。「AIで10分」ではなく「生成5分、確認15分」。この形にしておくと、期待値がずれません。
⑤費用の見張りをしていない
人が手で押しているうちは知れた額ですが、自動で回し始めると桁が変わります。
上限の設定を先にしておく。警告の通知も入れておく。そして週に一度は履歴を見る。月末にまとめて見るのでは、異常に気づくのが1か月後になります。
まとまった量を処理する前に1件だけ試して実際の消費を測る、という一手間も効きます。100倍すればおおよその額が出る。想定と違えばその時点で止まれます。
小さく始める形
全社に一斉に入れるより、ひとつの業務で試すほうが早い。
選ぶなら、毎日発生していて、間違いがすぐ分かって、いまも人手でやっている作業。問い合わせの下書き、議事録の整理、資料の要約あたりが当てはまります。
その業務で1か月回してから、指標の数字を見る。効いていれば横に広げ、効いていなければ別の業務を試す。この単位なら、失敗しても損が小さい。
最初から大きく組むと、うまくいかなかったときに何が原因か分からなくなります。道具なのか、業務の選び方なのか、使い方なのか。
続かない理由
導入自体はうまくいったのに、数か月で使われなくなる。これもよくある形です。
理由の多くは、確認の手間が想定より重かったこと。生成は速いのに、確かめる工程で時間が食われる。結局は自分で書いたほうが早い、という結論になります。
③の線引きに戻る話です。確認が軽い仕事を選べていれば、この形にはなりにくい。
もうひとつが、使う人が変わったとき。導入した担当者が異動すると、なぜその使い方なのかが引き継がれずに止まります。指示の内容と、その理由を書き残しておくと持ちます。
共通しているもの
5つとも、決めていなかったことが原因でした。モデルの性能や道具の選定ではありません。
逆に言えば、始める前の30分で大半は避けられます。何を測るか、何を入れてよいか、どの仕事に使うか、誰が確認するか、いくらまで使ってよいか。
この5つを紙1枚に書いてから始める。それだけで、後から止まる確率がだいぶ下がります。
紙1枚に書いておけば、引き継ぎのときもそれを渡せば済みます。
出典
確認の工程が必要になる理由については、下記の論文が背景を示しています。
