②AIが「たまに間違える」のは欠陥じゃない｜現場担当者が知っておくべきAIの本質

AIは"従来のシステム"ではない

─ 性質を理解し、"許容設計"で価値を出す

はじめに

前回、こんな問いを立てた。

「業務に組み込む思想がなければ、AIは検索どまりで終わる」

では、業務に組み込もうとしたとき、次に何が起きるか。

多くの企業が、ここで躓く。 ツールの使い方は覚えた。ユースケースも決めた。いざ業務に組み込もうとした瞬間に、想定外のことが起きる。

「思ったより精度が出ない」 「たまに明らかに間違った答えを返してくる」 「どこまで信頼していいかわからない」

この戸惑いの正体は、AIを「従来のシステムの延長」として捉えていることから来ている。

AIは、従来のシステムとは根本的に異なる性質を持つ。 この違いを理解しないまま業務に組み込もうとすると、必ず事故る。

そして、その性質を正しく理解した上で「どう設計するか」まで落とし込めた企業だけが、AIで本当の成果を出している。

1｜従来システムの世界観

まず、従来のシステムがどういうものかを整理しておく。

従来のシステムは、ルールベースで動く。

「もし○○ならば△△する」 「この条件を満たしたら、このフローに進む」 「この入力値が来たら、この計算をして返す」

人間がルールを定義し、そのルールに従って動く。 例外が発生したら、例外処理のルールを追加する。 バグがあれば修正する。 一度正しく動くようになれば、同じ入力に対して必ず同じ出力を返す。

これが従来システムの「信頼」の前提だ。

再現性がある。予測可能だ。責任の所在が明確だ。

システムが間違えたなら、ルールの定義が間違っていたか、実装にバグがあったかのどちらかだ。原因を特定して修正すれば、同じミスは二度と起きない。

企業がシステムを信頼してきたのは、この「確実性」があったからだ。

2｜AIの本質──確率的に動く、という設計思想

AIは、この前提を根本から覆す。

AIは確率的に動く。

同じ入力を与えても、毎回まったく同じ出力が返ってくるとは限らない。 明確なルールで動いているのではなく、大量のデータから学習したパターンに基づいて「もっともらしい答え」を生成している。

だから、曖昧な問いにも答えられる。 文脈を読んで、行間を埋めて、人間のような判断をしてくれる。 これがAIの強みだ。

しかし同時に、100%の精度は原理的に出ない。

これはバグではない。欠陥でもない。 AIという技術の設計思想そのものだ。

従来システムが「ルールの範囲内で確実に動く」ものだとすれば、 AIは「ルールでは定義できない曖昧な領域で、高い確率で正しい判断をする」ものだ。

この違いを理解しているかどうかが、AI活用の成否を分ける。

3｜現場で見た2つの事故パターン

AIの性質を誤解したまま業務に組み込もうとすると、だいたい2つのパターンで事故る。

実際に私が見た事例を交えて話す。

パターンA｜完璧主義トラップ

「AIの精度が100%にならないとリリースできない」

このパターンにはまった企業は、永遠にPoC（概念実証）を続けることになる。

精度95%のモデルができた。でも5%は間違える。 「業務に使うには不安だ」という声が上がる。 精度を上げるためにデータを追加する。チューニングを繰り返す。 97%になった。今度は別のパターンで精度が落ちた。また修正する。

「リリースできるのはいつですか」という問いに、誰も答えられなくなった。

予算が尽きる。担当者が異動する。プロジェクトは静かに終了する。 結論は「AIは使えなかった」。

でも本当の問題は、100%という存在しないゴールを設定したことだ。

パターンB｜丸投げトラップ

逆のパターンもある。

「AIが答えを出してくれるんだから、それをそのまま使えばいい」

精度の検証もせず、人間のチェックも入れず、AIの出力をそのまま業務に組み込む。 顧客対応のChatbotを作って、回答をそのまま送信する設計にする。

しばらくは動いている。 でもある日、AIが明らかに間違った情報を顧客に返信してしまう。 クレームが来る。信頼を失う。 「やっぱりAIは怖い」という結論になる。

でも本当の問題は、AIの不完全性を前提にした業務設計をしなかったことだ。

2つの事故の根っこは同じ

この2つは対極のように見えて、根っこは同じだ。

AIを「確定装置」として扱ったこと。 「必ず正しい答えを出すもの」という前提で設計したから、どちらも破綻した。

そしてここに、①で紹介した「ツールを導入したが、現場でほぼ使われない」という状況が重なってくる。

ある企業でこんなことがあった。 生成AIを全社導入し、「自由に使っていい」と通達が来た。 しばらく経って現場を見ると、たまに検索代わりに使っている人がいるだけで、ほぼ誰も触っていない。

理由を聞くと、みんな同じことを言った。 「自分の業務のどこで使えばいいか、わからないんです」

完璧主義トラップも、丸投げトラップも、そしてこの「使われない」状況も、全部同じ問題の別の顔だ。 「AIをどう業務に組み込むか」という設計思想が、最初からない。

4｜責任は誰にあるか

AIが間違えたとき、誰が責任を取るのか。

答えははっきりしている。 責任は業務設計者にある。

AIは道具だ。 道具が間違えたとき、責任を負うのは道具を設計した人間だ。 包丁で怪我をしても、包丁のせいにはならない。 どう使うかを決めた人間の責任だ。

AIも同じだ。 AIが間違った回答を顧客に返信したとき、「AIが勝手にやった」は通らない。 そういう設計をした人間の責任だ。

現時点の国内外のAIガイドラインでも、AIの利用責任は利用者・設計者側に帰属するという考え方が基本になっている。 AIベンダーではなく、業務にAIを組み込んだ側が責任を負う。 この前提を理解した上で設計に臨む必要がある。

だからこそ、人間の目と組み合わせた業務設計が肝要になる。

では、責任を持てる設計とは何か。具体的には以下の3点を設計段階で明確にすることだ。

AIが出力した内容を、誰がどのタイミングで確認するか。 AIの判断が間違っていた場合、どのフローで検知・修正するか。 AIの出力をそのまま使ってよい範囲と、必ず人間が判断する範囲をどこで線引きするか。

この3点が設計に落とし込まれていない状態でAIを業務に組み込むことは、ハンドルのない車を走らせるようなものだ。 問題が起きたとき、誰も止められない。

5｜「何%なら業務に乗るか」を先に決める

では、どう設計すればいいのか。

出発点はシンプルだ。 「何%の精度なら、この業務に使えるか」を先に決めること。

精度を上げてからリリースを考えるのではなく、許容できる精度の基準を最初に設定する。 この順序の違いが、永遠のPoCから抜け出せるかどうかを分ける。

ただし、ここに落とし穴がある。 「何を精度の指標にするか」の設計を間違えると、意味のない数字を追いかけることになる。

具体例を挙げる。

製造ラインで不良品を検出するAIを作るとしよう。 「正解率」をKPIに設定した場合、何が起きるか。

不良品の発生率が1%のラインでは、AIが何も検出しなくても正解率は99%になる。 全部「良品」と判定するだけで、99%という高精度が出てしまう。 でもこのAIは、不良品を一つも見つけられていない。

この場合に測るべきは「不良品の検出率」だ。 実際に不良品だったものを、どれだけ正しく「不良品」と判定できたか。 この指標でなければ、AIが本当に機能しているかどうかを測れない。

何を測るかがKPIの本質だ。 業務の目的に合わせて、何を正解とするかを定義することが、精度設計の第一歩になる。

6｜人間をベンチマークにする

許容精度の参考値として、もう一つ重要な視点がある。

人間をベンチマークにすることだ。

AIに100%の精度を求める前に、問い直してほしい。 今、その業務を人間がやったとき、精度は何%か。

人間も間違える。ミスをする。見落とす。判断がブレる。 「人間がやれば正確」という前提自体が、多くの業務では幻想だ。

人間の精度が85%の業務に、AIが80%の精度で対応できるなら、十分に検討に値する。

さらに言えば、AIが自信を持って回答できるものだけを自動化し、自信のないものだけ人間が対応する設計にすれば、全体の精度はさらに上がる。

例えば、100件の問い合わせがあるとする。 AIが回答の確信度も合わせて出力し、閾値を超えた60件は自動回答する。 残り40件は確信度が低いと判定されたものだけを人間が対応する。 この設計なら、人間が対応する件数を60%削減しながら、回答品質を担保できる。

ただし、一点注意が必要だ。 AIが出力する確信度自体が、必ずしも正確ではない。 特に生成AIは、ハルシネーションを起こしているときほど流暢に、自信ありげに答えるケースがある。 確信度を閾値として使う場合は、その確信度自体の精度も合わせて検証することが必須だ。

7｜「どこで人を介在させるか」が設計の核心

AIと人間の役割分担を設計するとき、判断の核心はここだ。

どこに閾値を設け、どこで人を介在させるか。

ミスのインパクトが大きい業務ほど、人間のチェックポイントを手前に置く。 ミスが起きても影響が小さい業務ほど、AIに任せる範囲を広げる。 コストと品質のバランスを見ながら、閾値を調整していく。

判断の目安として、業務を以下の軸で分類すると整理しやすい。

AIに任せる範囲を広げやすい業務は、ミスが起きても修正が容易なもの、処理量が多く人間のコストが高いもの、判断の根拠がデータや規則に基づくものといった特徴を持つ。議事録の要約やデータの分類・整理などが典型だ。

一方、人間のチェックを厚くすべき業務は、ミスが顧客や法令に直結するもの、判断に文脈や関係性の理解が必要なもの、結果の責任を組織として負う必要があるものといった特徴を持つ。顧客への回答・契約判断・コンプライアンス対応などがこれにあたる。

この設計判断を支える現実的な軸のひとつが、コストだ。 人件費とAI運用コストを天秤にかけたとき、どちらが合理的か。 今後日本の労働人口が減少していく中で、この天秤は徐々にAI側に傾いていく。 今のうちにAIと人間の役割分担を試行しておくことが、将来への備えになる。

今後、AIエージェントの技術が進化していくと、この設計はさらに精緻になる。 複数のAIが連携して業務を処理するエージェント型の仕組みでは、各プロセスの境目に人間のチェックポイントを設けることで、自動化の範囲を広げながら品質を担保する設計が可能になる。

重要なのは、「AIに任せる」か「人間がやる」かの二択ではないことだ。 AIと人間が各プロセスで役割を分担し、互いの弱点を補い合う設計が、AI活用の本質だ。 その設計ができる人間、つまり業務もわかりAIもわかる翻訳者の存在が、ここでも鍵になる。

おわりに──次回予告

ここまでで、AIの性質と許容設計の考え方を整理した。

「AIは判断支援装置であり、確定装置ではない」 「精度は100%を目指すのではなく、何%なら業務に乗るかを設計する」 「人間をベンチマークに、閾値で役割を分担する」

では次に、この設計を実際の業務プロセスにどう落とし込むか。

次回は「人とAIで業務を再設計する」を掘り下げる。 具体的な業務のBefore/Afterを通じて、設計の実務イメージを持ってもらう。

① AI導入したのに現場が使わない理由｜ツール展開だけでは業務は変わらない
② AIが「たまに間違える」のは欠陥じゃない｜現場担当者が知っておくべきAIの本質（本ページ）
③ AIに丸投げしても、人がやり直すだけ｜成果を出す企業が実践する役割分担の設計
④ 社内データをAIに入れるだけでは危ない｜メンテナンス設計なきAI活用が招く静かな失敗
⑤ 今日から使えるAI活用11選｜現場支援で見えた、業務を変えるユースケース実例

#創作大賞2026 #ビジネス部門