AIが嘘をつく理由と、工場が不良を直せない理由は同じかもしれない

そんな声を、本当によく聞きます。

ChatGPTやClaudeのような生成AIを使ったことがある人なら、一度は経験があるはずです。

存在しない論文を引用してきたり、実在しない機能の使い方を、堂々と説明してきたりする。

いわゆる「ハルシネーション（幻覚）」と呼ばれる現象です。

僕自身、調べ物をAIに頼んだら、それらしい規格番号と発行年付きで「存在しない規格」を紹介されたこともあります。

口調があまりに自然なので、危うく信じるところでした。

あの自信満々の口調で間違ったことを言われると、騙された気分になりますよね。

実際、製造業の中小企業でAI活用の支援をしていても、「結局AIは嘘をつくんでしょう」という警戒感が、導入の入り口で立ちはだかる場面によく出会います。

▼製造業のIT活用についてはこちらもご参考に。

でも僕は、この「嘘をつく」という表現に、ずっと違和感がありました。

そしてあるとき、気づいたんです。

ということに。

僕はもともとPETボトルの製品開発をしていた技術者で、今は製造業の現場改善を支援するコンサルタントをしています。

この記事では、開発時代に品質課長から言われた忘れられない一言を軸に、AIのハルシネーションと、ものづくりの量産現場に共通する「失敗の知識」の話を書いてみます。

「嘘をつく」という表現への違和感

嘘というのは、本当のことを知っていて、それを意図的に偽ることです。

AIはそうではありません。

AIは、自分が間違っていることを知らないんです。

もっと言えば、「自分の出力が間違っている」という状態を認識するための知識を、そもそも十分に持っていないのではないか。

ハルシネーションの原因は複合的で、確率的に文章を生成する仕組みそのものに由来する部分も大きいので、これはあくまで原因の一つの捉え方です。

それでも僕は、こう考えています。

正解だけを大量に教わって、間違いをほとんど教わっていない。

だから、間違えたことに自分で気づけない。

性格の問題ではなく、知識の構造の問題です。

間違いに気づくには、正解よりはるかに膨大な知識が要る

ここで少し立ち止まって考えてみます。

「自分の出力が間違っている」と自分で気づいて、正しい方向に修正する。

これができるためには、何が必要でしょうか。

まず、「間違っている」と認識できなければいけません。

つまり、間違いに関する知識を持っている必要があります。

さらに修正までするなら、「どう間違っているのか」を理解できるだけの知識が要ります。

• どの前提がずれたのか。

• どこで論理が飛んだのか。

• 正解からどの方向に、どれだけ外れているのか。

これは、正解だけを知っている状態と比べると、果てしなく膨大な知識量です。

正解は一つでも、間違い方は無数にあります。

一つの正解の周りには、無数の「惜しい間違い」「方向違いの間違い」「前提からおかしい間違い」が広がっています。

それらを間違いだと判定し、修正の方向まで示せる知識は、正解そのものの知識の何倍、何十倍にもなります。

人間の専門家が専門家たる所以は、実はここにあると思っています。

ベテランは、正解を知っているだけではありません。

「やってはいけないこと」「こうすると失敗すること」「この兆候が出たら危ないこと」を、イヤというほど知っています。

この構造に気づいたとき、僕は「これ、どこかで見たことがあるぞ」と思いました。

20年近く前、PETボトルの製品開発をしていたときに、まさにこの構造を叩き込まれたことがあったんです。

品質課で見た、「正解しか知らない現場」の苦しさ

僕は新卒で入った会社で、PETボトルの製品開発を担当していました。

入社4〜5年目にはジョブローテーションで生産工場の品質課に異動して、2年ほど量産現場の品質管理を経験しています。

品質課にいた2年間で目に焼き付いたのは、不良が出たときの現場の苦しさです。

検査をすれば、規格を外れていることは分かります。

「正しいものができていない」ことは検出できるんです。

データを見れば、いつから、どのくらい外れているかも分かります。

問題は、その先です。

ここで、手が止まります。

不良の現物を前に、製造、品質、生産技術が集まって首をひねる。

設備のログを遡って、原材料のロット切り替えのタイミングと突き合わせて、「怪しい」順に仮説を並べる。

でも、その仮説の確からしさを裏付ける知識が、現場にはありません。

なぜなら、その条件を振ったら何が起きるかを、誰も一度も見たことがないからです。

現場が持っているのは、開発から引き継いだ「標準条件」だけ。

この条件で作れば良品ができる、という一点の知識です。

その条件の周辺で何が起きるのか、どのパラメータがどの品質特性にどう効くのか。

そういう知識は、引き継ぎ資料のどこにも書かれていませんでした。

だから条件を動かすにも根拠がなく、経験と勘で一つずつ振ってみるしかない。

ときには間違った方向の調整をしてしまって、エラーモードがより複雑になる。

その間も生産は止まり、納期は迫ってきます。

当時の僕は、製品開発をそれまでに3年経験してきていたので発生したエラーがどんなエラーなのかを分かることも多かったんですが、そうした経験がない工場では、そらが宿命なんだと思っていました。

でも、本当の原因はもっと上流にあったんです。

元上司の品質課長に言われた、忘れられない一言

入社6年目、僕は開発部門に戻りました。

そして新製品のテストのために、かつて自分がいたあの工場へ行くことになります。

テストの目的は、もちろん「良品ができる条件を見つけること」でした。

量産前の開発では、とにかく良品を作ろうと条件調整をしてしまいがちです。

温度はこれ、圧力はこれ、時間はこれ。

試行錯誤の末に良品ができる条件セットを見つけ出して、それを「標準条件」として工場に引き渡す。

それが開発の仕事だと、当時の僕は思っていました。

そのとき、品質課時代の元上司である品質課長に、こう言われたんです。

頭を殴られたような気がしました。

品質課で2年間、「正解しか知らない現場」の苦しさをさんざん見てきたはずなのに。

開発に戻った途端、自分はその苦しさの原因を作る側に回っていました。

良品ができる一点を見つけて満足して、その周りに広がる「ダメになり方の地図」を描かずに帰ろうとしていたんです。

開発が渡すべきは「良品の作り方」ではなく「管理範囲の地図」

この言葉は、開発という仕事の成果物の定義を変えてしまいます。

開発が工場に渡すべきものは、「良品の作り方」ではありません。

です。

温度をどこまで上げたら、どんな不良モードが出るのか。

圧力が下がったら、製品のどの特性から先に悪化するのか。

PETボトルで言えば、成形条件のわずかな振れが、肉厚の偏りや白化、強度の低下といった形で現れます。

同じ「規格外れ」でも、どの不良モードが、どの順番で出てくるかは条件によって違う。

その出方を知っているかどうかが、トラブル時の診断力を決めます。

せっかく工場を借りてテストをするなら、良品ができたところで終わるのではなく、わざと条件を振って、わざとダメなものを作って、ダメになる境界と、ダメになり方を地図にする。

その地図があって初めて、工場は「この範囲内に収めれば良品ができる」という管理ができます。

そして何かが起きたときに、「この不良モードが出ているということは、あのパラメータが振れたな」という診断ができます。

品質管理の世界でいう、プロセスウィンドウ（良品ができる条件範囲）の考え方そのものです。

原材料のロットは変わります。

設備は経年で微妙にずれます。

季節で環境温度も変わります。

品質的なバラツキが避けられないものづくりにおいて、開発とは本来そういう仕事なんだと思います。

良品を一個作る仕事ではなく、良品ができる空間の境界線を引く仕事。

そして境界線を引くためには、境界の外側、つまり失敗を意図的に踏みに行かなければなりません。

▼量産の立ち上げに関しては、こちらもご参考に！

今、製造業の中小企業を支援するコンサルタントとして多くの開発と量産の現場に関わっていますが、量産トラブルの少なくない部分は、この「失敗の知識の引き継ぎ不足」に行き着きます。

開発が悪いのでも、工場が悪いのでもありません。

「開発の成果物は良品の作り方である」という定義そのものに、穴があるんです。

では、開発は具体的に何をすればいいのか

「どこまでいったらどうダメになるかをテストする」を、もう少し実務に落とすと、次の3つになります。

1. 「良品条件を見つける実験」と「境界を探る実験」を分けて計画する

量産前テストの計画段階で、この2つを分けて設計します。

前者だけで日程を使い切ってしまうのが、典型的な失敗パターンです。

良品ができたら終わり、ではなく、そこから各条件を意図的に振る枠を、あらかじめ確保しておきます。

2. 「何が・どの順番で・どう悪化するか」を記録する

条件を振ったときの結果を、規格に対する合否だけでなく、不良モードそのものとして言葉と現物で残します。

このとき作った「わざとダメにしたサンプル」は、そのまま量産後の限度見本や教育用サンプルになります。

捨ててはいけません。

ただ、開発の時点で失敗を見せることは、その後の安定量産をしなければいけない現場に不安を与えるとも思えます。

そうだとしても、ここはしっかりを不良モードを見せましょう。

3. 引き継ぎ資料の様式を変える

「標準条件表」だけでなく、

• このパラメータが上限側に振れるとこの不良モードが出る

• この不良モードを見たらまずこの条件を疑う

という対応表を付けます。

トラブル時に現場が最初に開く一枚が、標準条件表ではなくこの対応表になっていれば、診断のスピードはまるで変わります。

どれも、特別な設備投資は要りません。

要るのは、「開発の成果物は良品ではなく、管理範囲の地図である」という定義の転換だけです。

正解しか知らないAI、良品しか知らない工場

ここまで来ると、冒頭のAIの話と完全に重なります。

正解データを大量に学習したAIは、「標準条件」だけを渡された工場と同じです。

順調なときは、それらしい正解を出し続けられます。

良品を作り続けられます。

でも、何かがずれたときや、前提が想定から外れたとき。

工場は「規格を外れた」ことは検出できても、原因の診断と修正ができません。

AIはさらに深刻で、そもそも「自分の出力が規格を外れている」ことすら検出できずに、自信満々のまま間違いを出力し続けます。

言ってみれば、検査工程のない工場です。

品質管理の現場には「限度見本」というものがあります。

「ここまでは良品、これを超えたら不良」を判定するための、不良側の実物サンプルです。

良品サンプルだけを渡された検査員は、判定ができません。

間違いを間違いと認識するには、間違いの知識が要る。

修正するには、間違い方の知識が要る。

そしてそれは、正解の知識よりも圧倒的に膨大である。

AIも、工場も、人間の専門家も、この構造から逃れられないんだと思います。

「AIは平気で嘘をつく」という現象の少なくとも一部は、AIの性格の問題ではなく、知識の構造の問題です。

そう捉え直すと、ハルシネーションへの向き合い方も変わってきます。

嘘つきを矯正するのではなく、限度見本を持たない検査員に、限度見本を渡していくという発想になります。

AIを使う僕たちにできること

この構造を理解すると、ハルシネーションへの実務的な向き合い方も見えてきます。

要するに、工場でやってきた品質管理と同じことをすればいいんです。

1. 検査工程を入れる

AIの出力をそのまま使うのは、検査工程なしで製品を出荷するのと同じです。

重要な数値や固有名詞、引用元は人間が確認する。

出典や根拠を一緒に出力させて、検証可能な状態にしておく。

「全数検査」に近い使い方です。

2. AIに限度見本を渡す

指示（プロンプト）の中で、求める正解の例だけでなく、「こういう出力はダメ」という失敗例や禁止事項を併せて示します。

良い例と悪い例の両方を渡されたAIは、片方だけのときより明らかに判定が安定します。

これは、検査員教育で良品見本と限度見本をセットで見せるのと、まったく同じ理屈です。

「AIは嘘をつくから使えない」のではありません。

検査工程と限度見本のない工程が信頼できないのと同じで、仕組みを整えずに使うから信頼できないんです。

▼デジタル人材の育成はこちらもご参考に！

失敗の知識は、コストではなく資産です

結論はシンプルです。

開発段階で「わざとダメなものを作るテスト」に工数を割くのは、一見遠回りに見えます。

良品ができたのに、なぜわざわざ条件を振って不良を作るのか、と。

でも、そこで得られる「ダメになり方の地図」こそが、量産が始まってから十年効き続ける資産になります。

FMEA（故障モード影響解析）や不良モードの蓄積が品質管理の中核に据えられているのは、偶然ではありません。

あれは、組織として「失敗の知識」を資産化する仕組みです。

そしてAIの世界でも、おそらく同じことが起きていきます。

「正解を教え込む」だけでなく、「何がどう間違いなのかを教え込む」方向の研究や工夫は、実際に進んでいます。

AIが自分の間違いに自分で気づけるようになるには、人間の専門家やベテラン工場が持っているような、分厚い失敗の知識が必要になるはずです。

「AIは平気で嘘をつく」と切り捨てる前に、こう問い直してみてもいいかもしれません。

• 僕たちは自分の組織に、自分の工場に、自分の後輩に、「正解」だけを渡していないだろうか。

• どこまでいったらどうダメになるか、その地図を一緒に渡せているだろうか。

あの日、品質課長が僕に渡してくれたのは、まさにその問いでした。

失敗を知らないものは、自分の失敗に気づけない。

それはAIも、工場も、人も同じです。

あなたの職場でも、似たようなことは起きていませんか？

• 引き継がれたのは「正解のやり方」だけで、なぜそうするのかは誰も知らない。

• マニュアル通りにやれば回るけど、外れたときに誰も直せない。

• 失敗事例が共有されず、同じトラブルが繰り返される。

もし思い当たることがあれば、ぜひコメントで教えてください。

失敗の知識をどう残すかこそ、現場の強さの分かれ目だと思っています。

▼個別のご相談はこちらから！