取り組みの事例
「昔、似たトラブルがあった」を、会社の記録にする
過去の不具合対応の記録を、質問すれば該当事例が返ってくる形に整理します。答えには必ず、元になった文書名と日付を添えます。根拠を示せない答えは、この用途では使えないからです。
- 全工程
- 20工程
- 初回の人間の工程
- 11工程
- 2回目以降の人間の工程
- 6工程
人がやること（範囲の決定・読み取りの確認・出典の裏取り） AIがやること（読む・拾い出す・切り分ける） プログラムがやること（決まった手順の繰り返し）
STEP 1
対象を決めて集める
どの記録を、どこまで対象にするかを先に決める
3工程 人 3
「昔、似たトラブルがあったはずだ」。
不具合が起きたとき、現場でよく出る言葉です。そして多くの場合、その先は「誰々さんなら覚えているはずだ」に続きます。
これが、この施策が向き合っている問題です。過去の対応は、報告書としては残っています。残っているのに、探せない。だから結局、記憶している人に聞くしかない。
その人が休んでいたら、その日は分かりません。その人が辞めたら、会社としては最初から無かったのと同じになります。
やろうとしているのは、記憶を記録に移す事です。過去の是正処置報告書やクレーム対応記録を、質問すれば該当事例が返ってくる形に整えます。
ただし、この取り組みには前半と後半で性格の違う二つの顔があります。前半（S1〜S4）は「過去の記録を使える形にする」準備。後半（S5〜S6）は「不具合が起きたときに実際に使う」運用です。
まずは、どこまでを対象にするかを決めるところから始めましょう。
対象にする文書の種類と年数を決める
最初に、範囲を区切ります。
「社内にある紙を全部」から始めてはいけません。量が多いほど準備は長引き、長引くほど「本当に役に立つのか」が確かめられないまま時間だけが過ぎます。
直近3年分など、区切って始めます。3年あれば、同じような不具合が二度起きている事例がいくつか含まれています。その重なりが見つかれば、この仕組みが効くという証拠になります。
これは人間の判断です。どの年からどの文書を選ぶかは、その会社の事情でしか決められません。
後から絞り込むための切り口を決める
集めた記録を、後からどう絞り込みたいかを決めます。
- 製品種別（どの製品で起きたか）
- 工程（どの工程で起きたか）
- 発生時期（いつ起きたか）
- 客先（どこからの指摘か）
この4つを軸として決めておきます。
なぜ先に決めるのか。後から「工程でも絞りたい」と言い出すと、集めた記録を全部やり直す事になるからです。聞く事と、付ける事と、絞る事を同じ軸で揃えておくと、工程の間で情報が落ちません。
決めるのは最初の一度だけです。2件目からは、同じ軸に沿って中身が入っていきます。
散らばっている記録を集めてくる
決めた範囲の記録を、実際に集めてきます。
ここが、思っているより骨の折れる工程です。是正処置報告書はキャビネットの中、変更記録は品質保証の共有フォルダ、クレーム対応記録は営業担当者の手元。一つの会社の中で、置き場所も形式もばらばらになっているのが普通です。
これは人間にしかできません。どこに何があるかを知っているのは、その仕事をしてきた人だけだからです。
このとき、無理に整理しようとしなくて構いません。形式を揃えるのも、名前を付け直すのも、後の工程が引き受けます。今は「対象の記録が全部、手元に集まった」状態を作れば十分です。
STEP 2
紙とデータを読み取る
紙で残った書類も、中身の文字にする
4工程 人 2 プログラム 2
この施策が、他の取り組みと決定的に違う点がここにあります。
紙が混ざるという事です。
是正処置報告書もクレーム対応記録も、多くの会社では紙で残っています。様式に手書きで書き込み、上長が押印し、綴じてキャビネットに入る。その運用が長く続いてきたので、古い記録ほど紙の割合が高くなります。
紙は、検索できません。どれだけ丁寧に綴じられていても、中身の文字がデータになっていなければ、機械には一文字も見えていません。ですから、まず読み取る工程が要ります。
紙で残っている書類をスキャンする
綴じられている書類を、画像にします。
複合機でまとめて読み込ませるだけの作業ですが、ここでいくつか気をつける事があります。
薄い字で書かれたもの、コピーを重ねて薄くなったもの、押印が文字に重なっているもの。こういう紙面は、後の読み取りで間違いが出やすくなります。読みにくいと感じた紙は、解像度を上げてもう一度取り込んでおくと、後がずっと楽になります。
逆に言えば、気をつけるのはそれくらいです。向きが揃っていなくても、少し傾いていても、後の工程で吸収できます。
画像から文字を読み取ってデータにする
画像になった紙面から、書かれている文字を取り出します。
これは、画像の中の文字の形をAIが解析して、文字として起こす技術です。昔からある読み取り技術と何が違うかというと、様式が決まっていない紙面や、手書きが混ざった紙面にも耐える点です。「この位置に必ず品番が書いてある」という前提を置かずに、紙面全体を読んで文字を拾えます。
この工程は機械に向いています。何百枚あっても、同じ手順で同じように読む。人がやれば単調で、しかも途中から集中力が落ちて見落としが出る作業です。
ただし、完璧ではありません。だからこの工程の出口は「完成したデータ」ではなく、「人が確かめる前の下書き」です。
電子ファイルからも本文を取り出す
新しい記録は、文書ファイルや表計算で残っている事が多いはずです。そちらからも、同じように本文を取り出します。
やっているのは、形式の違う入れ物から中身の文字だけを抜き出して、同じ形にそろえる事です。紙から起こした文字と、ファイルから抜いた文字が、この時点で同じ形の本文になります。
ここを揃えておく意味は大きいです。そろえておかないと、後の検索が「紙由来のものしか出てこない」「新しいものしか出てこない」という偏りを起こします。探している人からは、その偏りは見えません。出てこなかった事例が、無かったのか、届いていなかっただけなのかが分からないからです。
読み取った結果を人が確かめて直す
読み取った結果を、人が見て直します。
ここを省いてはいけません。機械の読み取りは、たいてい正しく読めています。しかし、正しく読めているように見えるのが、いちばん危ないところです。
特に間違いやすいのは、この施策でいちばん大事な部分です。
- 型番や品番（似た文字が入れ替わる）
- 数値と単位（桁や小数点がずれる）
- 日付（元号と西暦の混在）
- 手書きの氏名や社名
不具合の記録で型番が一文字違えば、それはもう別の製品の記録です。検索しても出てきませんし、間違って出てきた方がもっと悪い。
ここで見るべきなのは、文章として読めるかどうかではなく、事実として合っているかどうかです。読み取りの正しさを、読み取った機械自身に採点させる事はできません。必ず、元の紙と突き合わせられる人が見ます。
STEP 3
絞り込める形にする
製品・工程・時期・客先で絞り込めるようにする
3工程 人 1 AI 1 プログラム 1
本文が揃っただけでは、まだ使えません。
「この製品の、この工程で、去年」という絞り込みができないと、似た言葉を含む記録が何十件も返ってきて、結局全部読む事になります。
この段でやるのは、一件ずつの記録に、絞り込むための情報を付ける事です。そして——この施策でいちばん重要な、出典を結び付ける工程がここに入ります。
記録から絞り込みの情報を拾い出す
本文を読んで、製品種別・工程・発生時期・客先をAIが埋めます。
これは、AIが得意にしている仕事です。「平成30年8月、○○社向けの××ラインで、△△の寸法不良が発生」という一文から、時期・客先・工程・製品を切り分けて、決められた欄に入れる。文章の意味を読んで分類する作業なので、決まった位置に書いてある必要はありません。
数百件あっても、同じ基準で埋まります。人が手で台帳に打ち込んでいくのに比べて、かかる時間が桁で変わります。
ただし、AIが埋めたものは、まだ下書きです。
拾い出した情報を社内の呼び方に揃える
AIが埋めた情報を、人が見て直します。
見るべきなのは、正しいかどうかよりも、社内の呼び方と合っているかどうかです。
同じ工程を、現場では「二次加工」、報告書では「仕上げ工程」、客先向けには別の名前で呼んでいる。こういう食い違いは、どの会社にもあります。AIは書いてあるとおりに拾うので、拾ったままでは呼び方が三つに割れます。
呼び方が割れていると、絞り込みが効きません。「仕上げ工程」で絞った人には、「二次加工」と書かれた記録が見えなくなります。
ですからここで、社内の呼び方に寄せて揃えます。これは現場の人にしか判断できない仕事です。
元の文書名と日付を1件ずつ結び付ける
一件ずつの記録に、それがどの書類の、いつの記録なのかを結び付けます。ここは自動処理の担当です。
この工程が、この施策の背骨です。
答えだけが返ってきても、使えません。どの文書のどの記録から来たのかが分からなければ、客先にも社内にも示せないからです。
「以前、同じ不具合の際にはこう対応しました」と言うだけなら、記憶でも言えます。それが会社の回答になるのは、「平成30年8月17日付の是正処置報告書 第○号に、この対応が記録されています」と示せた時です。根拠を示せない答えは、この用途では使えません。
だから、出典を後から付けるのではなく、本文と一体にして持たせます。人が付け忘れる余地を残さない、という事です。自動処理にしてあるのは、この一点のためです。
STEP 4
質問できる形にする
聞けば、出典つきで該当事例が返る状態にする
3工程 プログラム 3
ここまでで、出典の付いた記録が揃いました。
最後に、聞けば返ってくる状態にします。この段は全部、機械の仕事です。
記録を意味で引ける形に整えておく
言い回しが違っても、同じ意味なら届く状態にします。
現場の人が使う言葉と、報告書に書かれた言葉は、たいてい違います。現場では「バリが残る」、報告書では「除去不良」。現場では「寸法が出ない」、報告書では「寸法公差外れ」。
文字が一致しない限り出てこない検索では、この差で届かなくなります。探している人には、届いていない事が分かりません。「無かった」と思って、また同じ失敗を繰り返します。
そこで、言葉を文字の並びとしてではなく、意味の近さとして扱えるようにしておきます。こうすると、報告書の中の言葉づかいを知らなくても、自分の言葉で聞けば届きます。
意味と語句の両面から候補を集める
意味での検索と、文字そのままの検索を、両方かけます。
意味で引けるようにすると、今度は逆の弱点が出ます。型番、図番、ロット番号、客先の管理番号。こういう記号は「意味」を持たないので、意味の近さでは引っかかりにくくなります。
ですから、二本立てにします。意味で引く経路と、文字そのままで引く経路の両方から候補を集めて、最後にどちらが本当に関係あるかを機械が並べ直す。
この作りは、母艦（開発側の環境）で実際に検証してあります。どちらか片方だけより、両方から集めて順位を付け直した方が良い結果になる事が、実測で確かめられています。
回答に必ず出典と該当箇所を添える
答えと一緒に、文書名・日付・そして元の一節を返します。
これも自動処理です。人が「今回は出典を付けよう」と判断するのではなく、出典の無い答えは返らない作りにします。
大事なのは、文書名だけではなく、元の一節まで返す事です。文書名と日付だけだと、結局その書類を最初から読み直す事になります。「この記録の、この部分に、そう書いてあります」という抜粋まで返って初めて、その場で判断できます。
そして、抜粋があると、間違いにも気づけます。AIが要約した一文はもっともらしく読めますが、元の一節と並べれば、話が膨らんでいないかを人が見て確かめられます。
なお、この用途では、機械が文章を作って答える必要はありません。必要なのは「該当する記録はこれです」と、根拠つきで示す事だけです。文章を作らせなければ、作り話が混ざる余地もなくなります。
STEP 5
本物の不具合で試す
実際に起きた不具合で引いて、出るかを確かめる
3工程 人 2 AI 1
ここからが後半——実際に使う段です。
ただし、いきなり全社で使い始めるのではありません。その前に、本当に役に立つのかを確かめます。
この段は、最初の一度だけの工程です。
実際に起きた不具合で検索してみる
過去に実際に起きた不具合を持ってきて、それで検索します。
大事なのは、答えを知っている事例を選ぶ事です。「この不具合には、あの時こう対応した」と分かっている件で引いてみて、その記録が返ってくるかを見ます。
答えを知らない事例で試すと、返ってきたものが正しいのか分かりません。出てきた結果を見て「それらしいから合っているだろう」と判断してしまう。これでは、確かめた事になりません。
期待した事例が出たかを採点する
出た・出ないを、一件ずつ数えて記録します。
「だいたい良さそう」で終わらせないという事です。10件試して、期待した記録が返ってきたのは何件か。返ってこなかったのは何件か。
数えておく意味は、後で比べられる事です。手を打った後にもう一度同じ10件で試せば、良くなったのか変わっていないのかが分かります。印象で判断していると、直したつもりが悪くなっていても気づけません。
これは人間の工程です。「期待した記録」がどれなのかを知っているのは、その不具合を扱った人だけだからです。
出なかった原因を切り分けて手を打つ
返ってこなかった件について、なぜ出なかったのかを切り分けます。
原因は、たいてい三つのどれかです。
- 読み取りが間違っていた（型番や用語が別の文字になっていた）
- 言葉づかいが違いすぎた（現場の言い方と記録の言い方が離れていた）
- そもそも、その記録が対象範囲に入っていなかった
この三つは、打つ手がまったく違います。一つ目なら読み取りの確認をやり直す。二つ目なら呼び方の揃え方を見直す。三つ目は、仕組みの問題ではありません。範囲を広げるかどうかの判断です。
切り分けそのものはAIが得意です。出なかった記録と、実際に返ってきた記録を並べて、どこで食い違ったかを見つけられます。その上で、どう手を打つかは人が決めます。
STEP 6
現場で使い、広げる
不具合が起きたその場で使い、対象を広げていく
4工程 人 3 プログラム 1
準備が終わり、効くと確かめられました。
ここからが本番です。不具合が起きたその日に、その場で使う段になります。
不具合が起きたその場で類似事例を聞く
新しい不具合が発生したら、まず聞きます。
「昔、似たトラブルはあったか」。
これまでは、この問いに答えられる人を探すところから始まっていました。心当たりのある人が居るか、居ても手が空いているか、覚えているか。そこで止まっていたものが、その場で確かめられるようになります。
聞き方に決まりはありません。現場で使っている言葉のまま、起きている事をそのまま書けば届きます。報告書の中でどう表現されているかを、知っている必要はありません。
返ってきた出典に当たって確かめる
返ってきた文書名と日付を頼りに、元の記録に当たります。
これは人間の工程です。そして、省いてはいけない工程です。
似た事例が返ってきたからといって、同じ原因とは限りません。似た症状で、原因がまったく違うという事は、不具合の世界では普通に起こります。返ってきたのは「候補」であって、「答え」ではありません。
元の記録を開けば、その時の条件、対応の中身、その後どうなったかまで分かります。そこまで見て初めて、今回に当てはめられるかが判断できます。
そして、この工程があるから、客先に示せます。「過去に同種の事象があり、この時はこう対応しました」という説明が、記憶ではなく、日付の入った社内記録を根拠として成り立ちます。客先に見せる可能性のある情報なので、示す前に人が中身を確かめるという順番は、変えられません。
今回の対応記録を同じ形で台帳に足す
今回の不具合について書いた対応記録を、同じ形で足します。ここは自動処理の担当です。
この工程があるかどうかで、この仕組みの寿命が決まります。
足す手順が面倒だと、そのうち誰も足さなくなります。そして数年経つと、「あの検索は古い記録しか入っていないから」と言われて使われなくなる。最初は動いていた仕組みが死ぬのは、たいていこの経路です。
ですから、いつも通りに報告書を書いて確定させたら、そこから先は自動で積み上がる形にしておきます。書く人にとっては、これまでと同じ作業のままです。
再発防止が形骸化するのは、担当者が交代した時です。書いた本人が居なくなっても記録が残り、聞けば返ってくるなら、引き継ぎに頼らずに済みます。
対象の年数と文書の種類を広げる
効くと確かめられてから、初めて範囲を広げます。
3年分で試して、実際に「これは助かった」という場面が出た。その時に、5年分に広げる、対象の文書に別の種類を加える、という判断をします。
順番が逆になりがちなところです。全部入れてから使い始めた方が早い気がしますが、実際には遅くなります。量が増えるほど準備が長引き、その間に効くかどうかが分からないまま熱が冷めます。そして効かなかった時に、どこが悪かったのかを切り分けられません。
小さく作って、効くと確かめて、それから広げる。広げる判断は人間がします。どこまで広げる価値があるかは、実際に使った手応えでしか決められません。
なお、この種の記録は社外に出せない情報を含みます。客先名、指摘の内容、社内の不備。ですから、外に出さない形で持てる作り方が要ります。社内の設備の中だけで完結させ、記録も検索も外部の事業者に渡さないという構成は、機微な情報を扱う現場向けに実際に組んだ事があります。
残ったもの
設備・製品が1件増えるたびに、
人がやるのはこの6つだけ。
人の手が要るのは20工程のうち11工程。うち5工程は最初の1回だけの準備。残りは、記録を1件足すときの4工程と、不具合が起きたときの2工程に分かれる。
ご相談
自社の設備・製品でも同じことができるか、確かめませんか。
扱う点数や素材の状態を伺えば、どこまで自動化できるかをお伝えできます。