不具合の一次切り分けをAI社員に任せる前に、熟練者の着眼点を言葉にする

製造現場で不具合の報告が上がったとき、熟練者は症状を聞いただけで「まずここを見よう」と動き出すことがあります。この動き出しの部分、つまり一次切り分けをAI社員に任せられないか、というご相談を想定して、この記事では「任せる前に、熟練者の着眼点をどう言葉にするか」を整理します。

なお、本文中の場面は、一般的な利用イメージとして「例えば」の形で書いたものです。実在の企業や事例ではありません。

§ 一次切り分けで、AI社員に任せるタスク

Kneweava AI社員は、これまで人が行っていたタスクをAIが自動で担う「AI社員」を、お客様の業務に合わせて構築し、定着まで伴走するサービスです。不具合の一次切り分けを例にすると、任せるタスクは次のように設計できます。

• 不具合の報告を受け付ける
• 原因の候補を整理する
• 現場で確かめる項目を整理する

ここでAI社員が出すのは、「原因を特定した答え」ではなく、「候補」と「確かめる項目」です。確かめるのは現場で、原因を確定するのも現場です。

§ 手順にできる部分と、できない部分

報告を受けて、記録を調べて、候補を並べるという流れは、手順書にできます。一方で、熟練者が「まず何を見るか」「どの症状なら、どちらを疑うか」は、手順書には残りにくいものです。

例えば、同じ「寸法が合わない」という報告でも、熟練者は発生した時間帯、直前の段取り替え、材料のロットなど、いくつかの点から当たりをつけることがあります。その理由が記録されていない場合は、実際の不具合を題材に、なぜその点を確認したかをうかがいます。

§ 着眼点を取り出す問い：ACTAの考え方

熟練者の判断の取り出しには、ACTA（応用認知的タスク分析）の考え方が使えます。「何に着目し、どう見分け、どちらを選ぶか」を、過去の具体的な不具合を題材にうかがう手法です。例えば、次のような問いが考えられます。

§ 何に着目しているか

• 不具合の報告を受けたとき、最初に確認することは何ですか？
• 報告の文面のうち、どの言葉に注意を向けますか？
• 現場に行く前に、記録のどこを見ておきますか？

§ どう見分けているか

• 「いつもの原因」と「いつもと違う原因」は、何の違いで分けていますか？
• 似た症状でも、原因が違ったことはありましたか？そのとき、何で気づきましたか？
• 新人が見誤りやすいのは、どんな場面ですか？

§ どちらを選ぶか

• 原因の候補が2つに割れたとき、先に確かめるのはどちらですか？その理由は？
• 現場ですぐ確かめられる項目と、時間がかかる項目を、どう使い分けていますか？
• どんなときに「これは自分たちだけで判断しない」と考えますか？

これらは一般的な設計の例です。実際の問いは、御社の設備や製品、過去の不具合の記録に合わせて組み替えます。問いは抽象的な「コツ」ではなく、具体的な過去の件を思い出してもらう形にすると、答えが出やすくなります。

§ 取り出した着眼点を、使える形にする

うかがった内容は、次のような形で整理します。

1. 着眼点：まず何を見るか、その理由
2. 見分け方：似た症状の中から、どう絞り込むか
3. 過去の対策とその理由：何を行い、なぜ効いたのか
4. 出典：その判断が、誰のどの説明に基づくか

これらを出典つきでRAGに格納すると、AI社員は不具合の報告を受けたときに、格納した着眼点を参照して候補を整理できます。さらに、候補を出した根拠として、参照した判断を示せます。人が候補を見て「ここは違う」と感じたときは、格納した判断を直すことで、AI社員の振る舞いも直る設計です。

また、着眼点を言葉にする作業は、AI社員のためだけのものではありません。若手が熟練者の見方を学ぶための材料にもなります。この考え方は技能継承のページでも紹介しています。

§ 人に返す境界：安全と品質は現場が決める

不具合対応には、人が判断を持つべき場面があります。最終判断は人に残し、AI社員は判断の案と根拠を出し、判断できない境界は人に返す設計にします。不具合の一次切り分けでは、例えば次を現場に返す境界にすることが考えられます。

• 候補が絞れないとき
• 安全や品質に関わる判断
• 原因の確定と、対策の決定

特に安全や品質に関わる場面は、AI社員が案を出す場合でも、現場の人が確認してから動くことを前提にします。どの場面でどこまで任せるかは、業務ごとに一緒に決めます。

不具合・設計・部品・保全などの情報を探し直す手間を減らし、根拠を示して判断できる状態をつくる考え方は、根拠ある判断で紹介しています。

§ 当社の運用と、お客様ごとの構築について

正直にお伝えすると、Data Insightが運用しているAIマーケティング社員は、RAGを使っていません。手順と品質ゲートだけで動いています。ここで書いた「熟練者の着眼点をRAGに載せてAI社員が参照する」部分は、当社の運用の紹介ではなく、お客様の業務に合わせて構築する内容です。

人の判断をRAGに格納し、AI社員が参照する部分は、お客様ごとに構築するもので、既製の機能としてお約束するものではありません。

§ よくある質問

§ Q1. 熟練者に時間を取ってもらうのが難しいのですが、どうすればよいですか？

一度に長時間を求めず、過去の不具合を1件ずつ題材にして、短い対話を重ねる進め方が考えられます。既存の不具合記録があれば、それを手がかりにすることもできます。

§ Q2. AI社員が出した候補が外れていたら、どうなりますか？

候補が外れること自体は起こりえます。そのため、候補は「確かめる項目」とセットで出し、現場で確認する前提にします。外れた理由が分かれば、格納した判断を直すことで、次からの候補に反映する設計です。

§ Q3. まず何から始めればよいですか？

最初から全社に広げず、1つの業務で確かめる進め方をおすすめしています。限定検証では、実際の案件で確かめてから広げることができます。

§ まとめ

不具合の一次切り分けをAI社員に任せる前に、「任せるタスク」「参照する人の判断」「人に返す境界」を決めます。熟練者の着眼点は、過去の不具合を題材に「何に着目し、どう見分け、どちらを選ぶか」と問うことで取り出せます。原因の確定、対策の決定、安全や品質に関わる判断は、現場に残します。