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

> 言語モデルを使えば、現場の自由記述から品番や工程や原因を取り出して、集計できるデータにできる。ただし保証されるのは形式までで、中身の正しさは別に確かめる必要がある。向く文書と向かない文書、始め方をまとめた。

- URL: https://weaveai.jp/journal/field-reports-to-data/
- カテゴリ: 現場データ
- 公開: 2026-10-04 / 更新: 2026-10-04
- 執筆: weaveAI 編集部（株式会社サオス）

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

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

労働政策研究・研修機構（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）。文書は紙でも電子でもよく、形式は問われません。それでも、記録が文章のまま積み上がっていると、同じ不具合が何回起きたか、どの工程に多いかを答えるのに、誰かが全部を読み直すことになります。

## 何を取り出すか

![工場の作業台で記録を書く作業者](https://weaveai.jp/journal/img/31335983.jpg)

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

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

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

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

![グラフの資料を虫眼鏡で確かめる](https://weaveai.jp/journal/img/7947669.jpg)

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

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

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

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

## 向く文書と向かない文書

| 向く | 理由 |
|---|---|
| 不具合報告・クレームの記録 | 書き方はばらばらだが、拾う項目（現象、原因、処置）が決まっている |
| 作業日報 | 毎日大量に出て、集計したい項目がはっきりしている |
| 点検・保全のメモ | 設備と現象を揃えれば、傾向が見える |
| 引き継ぎメモ・申し送り | 後から検索できるだけで価値がある |

| 向かない | 理由 |
|---|---|
| 検査の測定値の記録 | 数値の読み違いがそのまま合否の誤りになる。最初から入力画面で数値として入れるべき |
| 手書きの図や写真が中心の記録 | 文字以外の情報が主で、取り出せる項目が少ない |
| 法令や契約で原本の保存が必要な記録 | データ化は検索用の写しと考え、原本は別に残す |

## 始め方

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

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

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

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

## 出典

- 労働政策研究・研修機構「ものづくり産業における人材確保・定着と技能継承に関する調査」結果（2026年5月27日、PDF） https://www.jil.go.jp/press/documents/20260527.pdf
- ISO/TC 176/SC 2「Guidance on the requirements for Documented Information of ISO 9001:2015」（PDF） https://www.iso.org/files/live/sites/isoorg/files/archive/pdf/en/documented_information.pdf
- Anthropic「Structured outputs」 https://platform.claude.com/docs/en/build-with-claude/structured-outputs
- OpenAI「Structured Outputs」 https://developers.openai.com/api/docs/guides/structured-outputs
- Google「Structured output（Gemini API）」 https://ai.google.dev/gemini-api/docs/structured-output