AI化しやすい業務は、「効果が大きい業務」ではないのかもしれない

ブログ

企業でAI活用を進めるとき、どの業務からAI化するか、という議論があります。工数が多い業務、関わる人数が多い業務、AIによって大きな効果が期待できる業務が、候補として挙がることが多いと思います。

それは当然の考え方なのですが、実際にAIを使って業務を変えていこうとすると、効果の大きさだけではうまく説明できない部分があります。最近は、AI化しやすい業務には、別の条件があるのではないかと考えるようになりました。

それは、失敗したときに、その結果を次の改善へ戻せることです。

手順書に書かれているのは、だいたい正常系である

業務をAI化する場合、まず手順書やマニュアルを読ませる、というアプローチが考えられます。入力項目、処理手順、承認経路、出力形式などが整理されているため、業務を理解させる材料として有用です。

ただし、手順書に書かれているのは、基本的には想定どおりに業務が進む場合です。実務で判断が難しくなるのは、必要な情報がない、規定同士が矛盾して見える、過去の事例と条件が少し違う、といった場面です。

こうしたとき、経験のある担当者は、単に手順を実行しているわけではありません。どの情報を重視するか、どの異常を無視しないか、どの時点で通常の手順を離れるかを判断しています。

この判断には、一般に暗黙知と呼ばれるものが含まれています。

マイケル・ポラニーは、暗黙知について「人は語ることができる以上のことを知っている」という考え方を示しました。暗黙知とは、単に文書化されていない情報ではなく、経験の中で複数の手掛かりを結び付けて判断する、言語化しきれない知識も含む概念です。

だとすると、熟練者から知識を得るために「正しい手順を教えてください」と聞くだけでは、十分ではないことになります。むしろ「どんな場合にその手順が使えなかったか」「何を見落として失敗したか」と聞いた方が、実際の判断に使われている知識が見えてきます。

失敗すると、知識の境界が見えてくる

この話に近い概念として、ネガティブ・ナレッジがあります。これは、何をしてはいけないか、どの方法が機能しないか、どの条件では通常の方法を使えないか、という知識です。

ネガティブ・ナレッジの研究では、専門家の能力には、正しい手順を知っていることだけでなく、状況に合わない行動や、避けるべき判断を知っていることも含まれるとされています。失敗を振り返り、原因を分析し、別の方法を試すことが、こうした知識の形成につながります。

正常系の手順は「この条件なら、この行動を取る」と教えてくれます。これに対して失敗事例は、「この条件まで来ると、その行動は通用しない」という境界を教えてくれます。

例えば、AIに文書を要約させる場合、良い要約の例を与えることは有効です。ただ、それだけでは、何を省略してはいけないかまでは分かりません。

対象期間を削ったため、古い情報が現在も有効に見えた。検討中の選択肢を、決定事項として要約した。個人の発言を、会社の公式見解のように扱った。

こうした失敗を記録しておけば、AIに避けさせるべき判断を具体化できます。ただし、悪い出力を保存するだけでは不十分で、何が問題だったのか、なぜ起きたのか、どう直したのかまで残す必要があります。

つまり、必要なのは失敗のログそのものではなく、意味づけされた失敗の知識です。

死にゲーは、失敗が前提になっている

失敗から学ぶ仕組みを考えていて、いわゆる「死にゲー」に似ていると思いました。

死にゲーでは、プレイヤーは何度も失敗します。敵の攻撃を避けられなかったり、罠にかかったり、攻撃を欲張って反撃を受けたりします。

しかし、ただ理不尽に難しいだけでは、ゲームとして面白くなりません。敵の予備動作や攻撃範囲、自分が判断を誤った瞬間を観察できるからこそ、次の攻略法を考えられます。

プレイヤーは、失敗するたびに仮説を変えます。もう少し待ってから攻撃する、回避する方向を変える、装備を変える、といった修正を加え、再び同じ敵に挑みます。

最初は倒せなかった敵を倒せるようになるのは、何度も失敗したからではありません。失敗の原因を観察し、次の試行へ戻す閉ループがあるからです。

逆に、何が起きたか分からないまま即死したり、結果がほとんど運で決まったりする場合、学習は進みません。失敗の回数よりも、そこから得られるフィードバックの質が重要です。

AI活用にも、かなり似たところがあります。

AIに失敗例を渡せば、勝手に学習するわけではない

ここで少し注意が必要なのですが、失敗事例を蓄積しただけで、利用している生成AIが自動的に学習するわけではありません。失敗から得た知識を、どのように次の利用へ戻すかを設計する必要があります。

簡単な方法としては、注意事項や反例としてプロンプトへ加えることが考えられます。「この情報が不足している場合は結論を出さない」「この条件では人間に確認する」といった制約です。

RAGなどを使い、現在の入力と似た過去の失敗事例を検索して、原因や適切だった対応をAIに参照させる方法もあります。より重要なのは、過去に失敗した入力を評価データとして残し、プロンプトやモデルを変更した後に、同じ失敗を繰り返さないか確認することです。

これは、ソフトウェア開発の回帰テストに近い考え方です。

実運用される機械学習システムでは、モデルを作ることだけでなく、データや出力を継続的にテストし、監視することが重要だとされています。Googleが公開したML Test Scoreでも、実験時の精度だけではなく、本番環境でのテストとモニタリングが重要な要素として整理されています。

NISTの生成AI向けリスク管理資料も、AIを導入時に一度評価して終わりにするのではなく、設計、利用、評価を通じて継続的に管理する考え方を取っています。

AIの精度は、最初にどれだけ多くの情報を与えたかだけでは決まりません。失敗を発見し、原因を考え、次の利用へ戻せる仕組みを持っているかにも左右されます。

AIを使う人も、失敗から学ぶ必要がある

この閉ループが必要なのは、業務へ組み込まれたAIだけではありません。AIを道具として使う人にも、同じことが言えます。

企業のAI活用では、成功事例が共有されます。議事録の作成時間が短くなった、資料作成が速くなった、情報収集の範囲が広がった、といった事例です。

こうした情報は、AIで何ができるかを知るきっかけとして有用です。ただ、完成した成果物やプロンプトだけを見ても、自分の業務で同じ結果を出せるとは限りません。

実際に使ってみると、期待した答えが返らない、根拠が弱い、修正を繰り返すうちに文章全体が崩れる、といった問題が起こります。そこで「AIは使えなかった」と終わるか、なぜ失敗したかを考えて次の試行へ戻すかで、その後の使い方は変わります。

残すべきなのは、完成したプロンプトだけではないのだと思います。最初に何を期待し、実際には何が出力され、何が問題で、どのように指示を変えたかという修正の履歴です。

成功したプロンプトだけを共有すると、他の人はそれを呪文のようにコピーします。失敗と修正の過程まで共有すれば、なぜその指示が必要なのか、どの条件では通用しないのかを理解できます。

死にゲーの攻略動画でも、最後に敵を倒した場面だけを見ても、あまり参考になりません。どこで攻撃を受け、何を見落とし、どのタイミングで戦い方を変えたのかという過程に、再現可能な知識があります。

効果が大きい業務ほど、AI化しやすいとは限らない

ここまで考えると、AI化する業務の選び方も少し変わってきます。

一般的には、工数が多い業務や、人件費の削減効果が大きい業務が優先されます。投資判断として、効果を見積もることは当然必要です。

ただし、効果が大きい業務が、必ずしもAI化しやすい業務とは限りません。

経営戦略の策定や重要顧客への提案、人材の評価などは、AIによって得られる潜在的な効果が大きい業務です。一方で、出力の良し悪しを短期間で判定しにくく、成果がAI以外の要因にも強く影響されます。

AIの提案が良かったから成果が出たのか、それとも市場環境や営業担当者の能力によって成果が出たのかを、簡単には切り分けられません。失敗した場合も、どこに原因があったのかを特定するのが難しくなります。

反対に、文書からの項目抽出、問い合わせ内容の分類、社内規定との照合、定型文の下書きなどは、効果が小さく見えるかもしれません。しかし、正誤や人間による修正を記録しやすく、同じ条件で再評価できます。

結果を観測できる。失敗を分類できる。修正した後に、もう一度試せる。

この条件がそろった業務は、死にゲーのように攻略法を更新できます。最初の精度が完璧でなくても、使いながら評価データと失敗知識を蓄積し、実用性を高められます。

成功事例より、学習ループを共有する

これまで、AI推進では成功したユースケースを増やし、横展開することが重視されてきました。それ自体は間違っていませんが、成功した結果だけを共有しても、他の人が同じ方法を再現できるとは限りません。

むしろ共有した方がよいのは、最初にどう失敗し、何が原因だと考え、どこを変えたのかという過程です。まだ解決できていない問題も含めて共有した方が、AIの適用範囲を理解しやすくなります。

成功事例を共有すると、結果をまねることができます。失敗と修正の過程を共有すると、学び方をまねることができます。

AI化の対象を選ぶときも、期待効果だけではなく、失敗から学べるかという視点を加えた方がよいのだと思います。大きな効果が期待できる業務でも、評価方法がなければ改善は止まります。

逆に、効果が中程度であっても、結果を観測し、失敗を次の試行へ戻せる業務には価値があります。そこで蓄積された評価方法や運用経験は、より複雑な業務をAI化するときにも使えるからです。

AI化しやすい業務とは、AIが最初から正しい答えを出せる業務ではありません。

失敗したときに、その一回を次の攻略法へ変えられる業務なのだと思います。

コメント

タイトルとURLをコピーしました