不具合報告と作業日報をデータに変える

#構造化出力#不具合報告#作業日報#品質

工場の作業場でタブレットを手に立つ作業者
写真:Pexels

不具合報告や作業日報のような自由記述の文書は、言語モデルで項目を取り出してデータにできます。向いているのは、書き方は人によってばらばらでも、拾いたい項目が決まっている文書です。一方で、測定値の正確さがそのまま合否になる記録には向きません。そして、言語モデルが保証してくれるのは取り出した結果の形式までです。中身が正しいかは、マスタとの照合と人の確認で別に確かめる必要があります。

なぜ今やる価値があるのか

労働政策研究・研修機構(JILPT)が2026年5月に公表した製造業4,342社の調査では、技能継承を「重視している」「やや重視している」企業が合わせて9割を超えました。一方で、技能継承が「うまくいっている」は1.9%、「ややうまくいっている」は31.4%で、合わせても3分の1ほどです。最も多い課題は「熟練技能者の高齢化・退職が進んでいる」(63.0%)でした。

ベテランが何を見て、どう判断して、どう処置したかは、不具合報告や日報の自由記述の中にあります。ただ、文章のままでは検索も集計もできません。同じ調査で、技能継承にデジタル技術を使っている企業が挙げた道具には、デジタル手順書・電子マニュアル(57.2%)、動画マニュアル(41.7%)に続いて、AI(35.1%)が入っています。

品質の面からも理由があります。ISO 9001:2015 は、不適合の内容、取った処置、特別採用、処置を決めた権限者の記録を残すことを求めています(8.7)。文書は紙でも電子でもよく、形式は問われません。それでも、記録が文章のまま積み上がっていると、同じ不具合が何回起きたか、どの工程に多いかを答えるのに、誰かが全部を読み直すことになります。

何を取り出すか

工場の作業台で記録を書く作業者

先に決めるのは、取り出す項目です。たとえば不具合報告なら次のようになります。以下は説明のための例です。

元の記述(例)取り出す項目
「10/2 夜勤、2号機の曲げ工程で扉ヒンジ部にクラック。材料ロット確認したら前回と同じ仕入先。型の摩耗かも。とりあえず手直しで出荷、型は週末に研磨予定」発生日:10/2/シフト:夜勤/設備:2号機/工程:曲げ/部位:扉ヒンジ部/現象:クラック/推定原因:型の摩耗(推定)/処置:手直し/対策予定:型の研磨(週末)

作業日報なら、作業者、案件、工程、数量、作業時間、異常の有無と内容。点検メモなら、設備、点検項目、結果、気づいたこと。項目を決めるときは、取り出したデータで何を答えたいかから逆算します。「どの設備の、どの現象が多いか」を知りたいなら、設備と現象は必ず取り出し、しかも決まった選択肢のどれかに揃えて取り出す必要があります。

形式は保証され、中身は保証されない

グラフの資料を虫眼鏡で確かめる

主な言語モデルの API には、決めた形式(JSON スキーマ)どおりに出力させる機能があります。

  • Anthropic は、構造化出力を使えば出力は常に有効な JSON になるとしつつ、安全上の理由で応答を断った場合、出力の長さの上限で途切れた場合、選択肢の値が大文字と小文字だけ違って返る場合には、形式から外れることがあると書いています。
  • OpenAI も、出力が与えたスキーマに従うことを保証するとし、同じく応答の拒否と長さの上限による途切れを例外に挙げています。
  • Google の Gemini の文書は、出力が構文として正しい JSON であっても、値は必ずアプリケーションの側で検証するよう求め、形式は合っているが意味の上で誤っている出力への対処を実装するよう書いています。

形式が守られることと、中身が正しいことは別です。「2号機」を「12号機」と読み違えても、形式としては正しい JSON です。そこで、取り出したあとに次の確認を挟みます。

  • マスタとの照合。設備番号、品番、工程、不良区分が、マスタに実在する値か。無ければ人の確認に回す。
  • 範囲の確認。数量や時間が、ありえる範囲に入っているか。
  • 書かれていないことを作らせない。元の文に無い項目は空欄で返すよう指示し、推測した値と書かれていた値を区別させる。上の例の「型の摩耗(推定)」のように。
  • 人の確認の流れ。照合で引っかかったものだけを人が見る。全部を人が見るなら、データにする意味が薄れます。

向く文書と向かない文書

向く理由
不具合報告・クレームの記録書き方はばらばらだが、拾う項目(現象、原因、処置)が決まっている
作業日報毎日大量に出て、集計したい項目がはっきりしている
点検・保全のメモ設備と現象を揃えれば、傾向が見える
引き継ぎメモ・申し送り後から検索できるだけで価値がある
向かない理由
検査の測定値の記録数値の読み違いがそのまま合否の誤りになる。最初から入力画面で数値として入れるべき
手書きの図や写真が中心の記録文字以外の情報が主で、取り出せる項目が少ない
法令や契約で原本の保存が必要な記録データ化は検索用の写しと考え、原本は別に残す

始め方

いきなり全部の帳票を対象にしないことです。

  1. 一番困っている文書を一つ選ぶ。多くの工場では不具合報告です。
  2. 取り出す項目と、その選択肢(不良区分、工程、設備)を決める。選択肢はマスタとして持つ。
  3. 過去の文書から50件ほどを選び、人が正解を付ける。
  4. 言語モデルに取り出させて、正解と比べる。項目ごとにどれだけ合っているかを見る。
  5. 合っている項目から使い始め、外れやすい項目は人の確認に回す。

軌道に乗ったら、過去の文書をあとからデータにするより、書いたその場で取り出して本人に確かめてもらう形に移るのが理想です。書いた本人なら、読み違いをその場で直せます。

取り出したデータには、受け皿が要ります。weaveAI FactorySuite の品質の画面は、不良コード別の内訳と、廃棄・手直し・特別採用などの処置を、製造の実績にひもづけて記録します。自由記述から取り出した項目を、こうした決まった形の記録に流し込めて初めて、集計や傾向の分析ができるようになります。

出典

#構造化出力#不具合報告#作業日報#品質

執筆weaveAI 編集部(株式会社サオス)

株式会社サオスで weaveAI を開発しているチームです。製造業の業務システムと AI について、一次情報と実際の検証をもとに解説しています。

運営者情報・編集方針 →

weaveAI FactorySuite

御社の工場で、動かしてみませんか。

マスタ・在庫・製造実績・品質・保全をすぐに使え、足りない画面は AI との対話で作れます。いまお使いの帳票(紙・Excel)があれば、どの画面に置き換わるかを一緒に確認します。