製造現場で手書きされる工程内検査の記録表を読み取り、品番・ロット・寸法の測定値を品質のデータにそろえて、規格外れと傾向の変化を拾う
加工ラインで作業者が手書きする工程内検査の記録表をスキャンして読み取り、品番・ロット・寸法の測定値を品質のデータにそろえます。規格を外れた値と、規格内でも同じ向きにずれ続けている寸法を、その日のうちに品質管理課へ出します。
- 生成AI
- ChatGPT/Claude/Gemini
- AIサービス
- Azure AI/Google Document AI
- 連携・自動化
- Google Apps Script/Python
- 対象業界
- 製造
- 対象部門
- 品質管理/生産
- 対象業務
- データ入力・転記/内容確認・チェック
- 主な課題
- データ分析に時間がかかる/入力作業が多い/確認ミスが多い
- AIで行う処理
- 読み取り(OCR)
- 主な効果
- 判断支援/対応スピード向上/工数削減
- 導入難易度
- ★★★☆☆
- 実装レベル
- 本格構成
- 費用感
- API連携(中)
- 人間の確認
- 条件付き
01導入前 / 導入後の業務フロー
- 作業者が初品・中間・終品の時刻に寸法を測り、記録表に手書きする。判定欄に合否を付ける
- 直の終わりに班長が記録表を回収し、品質管理課の棚に置く
- 翌朝、品質管理課の担当が記録表を1枚ずつ取り、品番とロットを品質データのファイルで探す
- 測定値を1つずつ打ち直す。読みにくい数字は作業者に聞きに行く
- 打ち直した値を検査基準書の規格と見比べ、外れた値に印を付ける
- 管理図を見て、気になる動きがあれば製造課に伝える
- 備考欄の「刃具交換」「段取り替え」などを、品質データの備考の列に書き写す
- 人直の終わりに班長が記録表を回収し、ラインの近くの複合機でスキャンする
- 自動スキャンの保存をきっかけに Python のプログラムが動き、形式・ページ数・解像度を確かめる
- 自動Google Document AI の Form Parser が、上部の欄のキーと値、測定値の表、読み取りの信頼度を返す
- 自動Claude API が、表のセルを品番・ロット・測定項目・時刻・測定値にそろえ、備考を出来事の種類に分ける
- 自動Python が測定値を検査基準書の規格と比べ、外れた値と、桁や小数点が不自然な値に印を付ける
- 自動Python が品番・測定項目ごとに直近の値を並べ、管理図の規則に当たる並びを拾う
- 自動規格外れの候補は、記録表の写しの該当セルに枠を付けて、品質管理課と班長に知らせる
- 人品質管理課の担当が、印の付いた値を写しと見比べて確定する
- 人確定した規格外れは、不適合品の手順に沿って製造課と処置を決める
- 人傾向の知らせは、品質管理課が翌朝の打合せで製造課と見る
各工程の詳しい説明を読む
- 作業者が初品・中間・終品の時刻に寸法を測り、記録表に手書きする。判定欄に合否を付ける
- 直の終わりに班長が記録表を回収し、品質管理課の棚に置く
- 翌朝、品質管理課の担当が記録表を1枚ずつ取り、品番とロットを品質データのファイルで探す
- 測定値を1つずつ打ち直す。読みにくい数字は作業者に聞きに行く
- 打ち直した値を検査基準書の規格と見比べ、外れた値に印を付ける
- 管理図を見て、気になる動きがあれば製造課に伝える
- 備考欄の「刃具交換」「段取り替え」などを、品質データの備考の列に書き写す
(a)打ち直しに時間がかかる。 1枚あたり測定値が40個前後あります。数字を1つずつ目で追って打つ作業は、急ぐほど打ち間違いが増えます。 打ち間違いは、そのまま管理図の1点の飛びになります。
(b)管理図が遅れる。 記録表が品質管理課に届くのは翌朝で、打ち直しが終わるのはその日の夕方か、忙しい週は数日後です。管理図の上で傾向が見えたときには、そのロットはもう次工程に流れています。
(c)規格内のずれに気づけない。 外径が規格の中心から少しずつ上限に寄っていくような動きは、1枚の記録表では分かりません。作業者は合否を見て「合」を付けます。刃具の摩耗が原因なら、規格外れが出るのは時間の問題です。
(d)読み違いと本当の外れが混ざる。 打ち直した値が規格を外れていたとき、担当はまず自分の打ち間違いを疑い、次に作業者の書き間違いを疑います。作業者に聞きに行くまで、それが本当に外れているのかが決まりません。 聞きに行った先の作業者が別の直なら、答えは翌日になります。
- 【人】 直の終わりに班長が記録表を回収し、ラインの近くの複合機でスキャンする
- 【自動】 スキャンの保存をきっかけに Python のプログラムが動き、形式・ページ数・解像度を確かめる
- 【自動】 Google Document AI の Form Parser が、上部の欄のキーと値、測定値の表、読み取りの信頼度を返す
- 【自動】 Claude API が、表のセルを品番・ロット・測定項目・時刻・測定値にそろえ、備考を出来事の種類に分ける
- 【自動】 Python が測定値を検査基準書の規格と比べ、外れた値と、桁や小数点が不自然な値に印を付ける
- 【自動】 Python が品番・測定項目ごとに直近の値を並べ、管理図の規則に当たる並びを拾う
- 【自動】 規格外れの候補は、記録表の写しの該当セルに枠を付けて、品質管理課と班長に知らせる
- 【人】 品質管理課の担当が、印の付いた値を写しと見比べて確定する
- 【人】 確定した規格外れは、不適合品の手順に沿って製造課と処置を決める
- 【人】 傾向の知らせは、品質管理課が翌朝の打合せで製造課と見る
8番目が、この設計の分かれ目です。 担当が見るのは400枚のすべてではなく、印の付いた値だけです。 印の無い値はそのまま品質データに入り、管理図が更新されます。
7番目で班長にも知らせるのは、規格外れの候補が出たのが直の終わりだからです。 品質管理課が翌朝に確かめるまで待つと、次の直が同じ条件で加工を続けます。読み違いかもしれない段階でも、写しを付けて先に知らせます。
02今回想定するシステム構成
工程内検査の記録表(A4、品番・ロット・工程ごと) │ 直の終わりに班長がスキャン ▼【トリガー】共有フォルダへの保存 Python ── 形式・ページ数・解像度の確認 ▼ Google Document AI(Form Parser) │ 上部の欄のキーと値、測定値の表、信頼度を返す ▼ Claude API ── 表のセルを品番・ロット・測定項目・時刻・値にそろえる │ 備考を出来事(刃具交換・段取り・材料ロット変更など)に分ける ▼ Python ── 規格との比較、桁・小数点の確認、管理図の規則 ▼ 品質データ(品番・測定項目ごと) ├──▶ 規格外れの候補 ── 写しに枠を付けて品質管理課と班長へ └──▶ 傾向の知らせ ── 翌朝の打合せへ ▼ 【品質管理課が印の付いた値を確定】
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| OCR | Google Document AI(Form Parser) | Azure AI Document Intelligence |
| 生成AI | Claude API(表のセルを測定項目と値にそろえる) | OpenAI API、Gemini API |
| 連携 | Python(フォルダの監視、品質データへの書き込み、通知) | Google Apps Script |
| 集計 | Python(規格との比較と管理図の規則) | Google Apps Script |
| 保管 | 社内のファイルサーバー | Google ドライブ |
新しく作るのは、検査基準書のデータ化と、記録表の書式の見直しの2つです。 品番ごとの測定項目、規格の中心値と上下限、測定器の最小の読み取り単位を1つの表にします。この表が無いと、読み取った値を何と比べればよいかが決まりません。
土台は Document AI の Form Parser です。 公式のプロセッサ一覧では、OCRのテキストに加えてキーと値のペア、チェックボックス、表を抽出するとされ、言語の一覧で日本語(ja)は手書きに対応する言語として示されています。上部の「品番」「ロット」はキーと値のペアとして、測定値の格子は表として読めます。
Form Parser の注意書きのうち、この題材でいちばん効くのは表の制限です。 公式のページでは、行や列をまたぐセルの無い、単純な表から抽出するとされ、応答の説明でも、Form Parser では rowSpan と colSpan が常に1になるとされています。「測定項目」の見出しを2行にまたがせた記録表は、そのままでは列がずれます。 書式から結合セルをなくすのが、最初の準備作業です。
処理する場所は、リージョンの一覧から選びます。 マルチリージョンの us と eu、シンガポール(asia-southeast1)などの単一リージョンがあり、日本のリージョンはありません。 記録表には品番と寸法、作業者の名前が書かれているので、顧客との取り決めで図面の情報の扱いに制限がないかを確かめます。
03どうやって実装するのか
処理の起点を決める
共有フォルダにスキャンが保存されたことを起点にします。 直の終わりに班長がスキャンすれば、その直の測定値は数分で品質データに入ります。翌朝の回収を待たないことが、この構成の目的の半分です。
スキャンはラインの近くの複合機で行い、直ごと・ラインごとに保存先を分けます。 ファイル名は複合機の既定のままで構いません。品番とロットは記録表の上部から読み取ります。
Python のプログラムは1分おきにフォルダを見ます。処理が終わったファイルは処理済みのフォルダへ移し、移すのは成功したときだけにします。元のフォルダに残っている数が、未処理の枚数です。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 記録表のスキャン | PDF。スキャン日時、ライン、直 | 共有フォルダ |
| 読み取り結果 | 上部の欄のキーと値、測定値の表、セルごとの信頼度 | Google Document AI |
| 検査基準 | 品番ごとの測定項目、規格の中心値と上下限、測定器の最小の読み取り単位 | 検査基準の表(新しく作る) |
| 品質データ | 品番・測定項目ごとの過去の測定値 | 品質データのファイル |
| 機械の台帳 | 機械番号、ライン、担当の班長 | 既存の設備台帳 |
質を決めるのは、測定器の最小の読み取り単位の列です。 マイクロメータで0.001mmまで読む項目に「12.03」と書かれていれば、桁が足りないと分かります。ノギスで0.01mmまで読む項目に「12.035」と書かれていれば、桁が多すぎます。桁の不自然さは、読み違いを見つけるいちばん確かな手がかりです。
データの取得方法を決める
読み取りは、Python から Form Parser のプロセッサを呼ぶだけです。オンラインの処理は1回の要求で最大15ページで、記録表は1枚ずつ送るので上限に届きません。
| 取るもの | どこから | 何に使うか |
|---|---|---|
| 上部の欄 | 各ページの formFields(fieldName/fieldValue) | 品番、ロット、工程、機械番号、作業者 |
| 測定値の表 | 各ページの tables(headerRows/bodyRows) | 測定項目と時刻の格子 |
| 信頼度 | 各要素の layout の confidence | 読めたセルと怪しいセルの区別 |
| 位置 | layout の boundingPoly | 確認の画面で、写しの該当セルに枠を出す |
| 判定欄 | 表のセル(✓ や ☐ の文字として出ることがある) | 作業者が付けた合否 |
判定欄の印は、表の中では文字として返ります。 公式の応答の説明では、表の中のチェックボックスは ✓ と ☐ の文字で表されるとされています。作業者が手で「合」「否」と書く欄にすると、文字として読めます。 どちらにするかは書式の見直しで決めます。
検査基準と品質データは、表計算ファイルを読むだけです。品番は記録表から読み取った値で引きますが、検査基準に無い品番なら処理を止めます。 似た品番に寄せて引くことはしません。
AIへ渡す前に整形する
- 形式の確認 … 公式の対応形式は PDF、GIF、TIFF、JPEG、PNG、BMP、WebP などです。複合機の保存は PDF にします
- 解像度の確認 … 公式のページでは、スキャンは最低200dpiが望ましく、300dpi以上が一般に最もよいとされています。小数点が読めるかどうかが決まるので、300dpiに設定します
- 白黒2値にしない … 鉛筆の薄い数字や小数点が、2値化で消えます。グレーかカラーで保存します
- 1ファイル1枚にそろえる … まとめてスキャンされたものは、ページで分けます
- 向きの確認 … 横向きの記録表は回転させます
- 重複の確認 … 同じ品番・ロット・工程の記録表が2枚あれば、両方を担当に回します。どちらかを捨てない
3番目を軽く見ないでください。 複合機の既定の設定は、文書向けに白黒になっていることがあります。小数点が消えた「1203」は、12.03 とも 120.3 とも読めます。 桁の確認で拾えはしますが、拾う前に消さないほうが確実です。
6番目で両方を回すのは、書き直しの可能性があるからです。 作業者が書き損じて新しい記録表に書き直し、古いほうも回収されることがあります。どちらが正しいかは、作業者と班長にしか分かりません。
AIに処理させる
させるのは、Form Parser が返した表のセルを、品番・ロット・測定項目・時刻・測定値の行にそろえることと、備考を出来事の種類に分けることです。 規格との比較も、傾向の判断も、Python が行います。
| させること | 中身 | 判断できないときの扱い |
|---|---|---|
| 測定項目の対応付け | 表の見出し(「外径」「φ12」など)を、検査基準の測定項目コードに対応させる | 対応が決まらなければ unmapped |
| 時刻の対応付け | 列の見出し(「初品」「10:00」「終品」)を測定の回にそろえる | 決まらなければ unknown |
| 測定値の写し | セルの文字を、そのまま文字列で写す | 読めなければ unreadable |
| 空欄の区別 | 測っていない回と、読めない回を分ける | 空欄は blank |
| 判定欄の写し | 作業者が付けた合否を写す | 印が無ければ blank |
| 備考の分類 | 刃具交換・段取り替え・材料ロット変更・機械の停止・その他 | 当てはまらなければ other |
備考の分類が、傾向を読むときに効きます。 外径が10時から少しずつ大きくなり、14時に急に戻っているとき、14時の備考に「刃具交換」とあれば、ずれの原因の候補が1つ見えます。 管理図の点と出来事を同じ時刻で並べるために、備考を種類に分けておきます。
| させないこと | 理由 |
|---|---|
| 測定値の修正(桁を足す、小数点を補う) | 読み違いの補正に見えて、本当の外れを消す |
| 規格との比較 | Python が検査基準の数値で行う。AIの計算に頼らない |
| 傾向の判断 | 管理図の規則で決める。AIの印象にしない |
| 作業者の判定欄の書き換え | 規格内なのに「否」が付いていても、そのまま写す |
| 不適合品の処置の判断 | 品質管理課と製造課が手順に沿って決める |
1行目がいちばん起きやすい失敗です。 「1203」を見たAIは、規格の中心値が12.03なら「12.03」と書き直したくなります。その値が本当に120.3と書かれていたなら、書き損じという事実が消えます。 補正は人が写しを見て行います。
指示内容を固定する
あなたは品質管理課で、工程内検査の記録表の読み取り結果を
品質データの形にそろえる立場です。OCRが返した結果だけを見て、
表のセルを1つずつ写してください。推測で埋めないでください。
【やること】
1. 上部の欄から、品番、ロット番号、工程、機械番号、作業者を写す
2. 表の見出しを、下の測定項目の一覧のコードに対応させる
3. 列の見出しを、測定の回(first、mid_1〜mid_6、last)にそろえる
4. セルの測定値を、書かれたとおりの文字列で写す
5. 判定欄の合否を写す
6. 備考を、tool_change/setup/material_lot/machine_stop/other に分ける
【厳守事項】
- 測定値は文字列のまま写してください。桁を足す、小数点を補う、
0を足す、規格の値に近づける、といった修正をしないでください。
- 小数点が見当たらない値も、そのまま写してください(例:"1203")。
- 規格と比べないでください。合否を判断しないでください。
- 判定欄は作業者が書いたとおりに写してください。
値が規格内に見えても、「否」と書かれていれば「否」です。
- 空欄のセルは status を blank にしてください。
文字はあるが読めないセルは status を unreadable にしてください。
空欄と読めないセルを混ぜないでください。
- 見出しが一覧のどの測定項目にも対応しないときは、
item_code を unmapped にしてください。似た項目に寄せないでください。
- 備考は原文を note_text にそのまま写し、種類だけを付けてください。
原因を推測して書かないでください。
【読み取り結果】{ocr_result}
【この品番の測定項目の一覧】{inspection_items}
「小数点が見当たらない値もそのまま写す」を例付きで書いているのは、書かないと必ず補うからです。 測定項目の一覧に規格の中心値を渡していないのも同じ理由で、AIには項目の名前とコードだけを渡し、数値は渡しません。 比べる材料が無ければ、比べて直すこともできません。
「似た項目に寄せない」は、見出しの手書きの略記で効きます。 「外φ」と「内φ」が読み違えられて同じ項目に寄せられると、1つの測定項目に2つの寸法の値が混ざり、管理図が意味を失います。
出力形式を固定する
次の形のJSONで受け取ります。 Claude API の構造化出力(output_config.format に JSON スキーマを渡す方式)を使い、形を固定します。
{
"part_no": "",
"lot_no": "",
"process": "",
"machine_no": "",
"operator": "",
"measurements": [
{
"item_code": "",
"timing": "first | mid_1 | mid_2 | mid_3 | mid_4 | mid_5 | mid_6 | last | unknown",
"value_text": "",
"status": "read | blank | unreadable",
"cell_ref": ""
}
],
"operator_judgement": "pass | fail | blank",
"notes": [
{ "timing": "", "event": "tool_change | setup | material_lot | machine_stop | other", "note_text": "" }
]
}
1つ目の理由は、value_text を文字列で持てることです。 数値型にすると、「1203」は1203として入り、桁の不自然さが見えなくなります。Python が文字列のまま桁と小数点を確かめ、そのあとで数値に直します。
2つ目は、比較と判定を Python の規則で持てることです。
| 条件 | 扱い |
|---|---|
| 小数点以下の桁が、測定器の最小の読み取り単位と合わない | suspect(写しで確かめる) |
| 中心値からの差が、規格の幅の数倍を超える | suspect(桁の読み違いの疑い) |
| 規格の上下限を外れる(上の2つに当たらない) | out_of_spec(規格外れの候補) |
| 作業者の判定欄と、規格との比較が食い違う | judgement_mismatch |
| 該当セルの OCR の信頼度が基準を下回る | low_confidence |
suspect と out_of_spec を分けるのが、(d)の失敗への答えです。 桁がおかしい値は、まず読み違いか書き違いを疑います。桁が合っていて外れている値は、本当の外れの可能性が高いので、すぐに班長へ知らせます。 どちらも写しを付けて人が確定します。
3つ目は、管理図の規則を Python で回せることです。 NIST の工学統計ハンドブックでは、管理図の不安定を示す Western Electric の規則として、中心線の同じ側に8点続く、6点続けて上がる(または下がる)などが示されています。あわせて、規則を足すほど誤報も増えるとされています。どの規則を使うかは品質管理課が決め、Python がその規則で品番・測定項目ごとの並びを見ます。
公式のページでは、列挙の値の大文字・小文字までは保証されないとされているので、timing と status は Python で小文字にそろえてから使います。stop_reason が max_tokens のときは出力が途中で切れているので、品質データに書かずに呼び直します。
システムへ連携する
| つなぎ先 | 方式 | 内容 |
|---|---|---|
| 共有フォルダ | Python で1分おきに確認 | 新しいスキャンを見つけ、処理済みへ移す |
| Google Document AI | API呼び出し | 上部の欄、測定値の表、信頼度を返す |
| Claude API | API呼び出し | セルを測定項目と値にそろえ、備考を分ける |
| 検査基準の表 | 表計算ファイルの読み取り | 規格と最小の読み取り単位を引く |
| 品質データ | 表計算ファイルへの追記 | read で印の無い値と、確定した値だけを入れる |
| 通知 | 社内のチャットまたはメール | 規格外れの候補を、写しの画像付きで品質管理課と班長へ |
品質データには、印の付いた値を確定前に入れません。 確定前の値は別のシートに置き、管理図には確定した値だけが載るようにします。読み違いの1点が管理図に入ると、規則が誤って当たり、誰も見なくなります。
検査基準の表は読み取りだけです。 図面の改訂で規格が変わったときは、品質管理課が表を直します。この構成から規格を書き換えることはしません。
人が確認する
品質管理課の担当が見るのは、印の付いた値だけです。
out_of_specを先に見る … 写しの該当セルを見て、書かれた値が読み取りどおりかを確かめます。読み取りどおりなら、規格外れとして確定し、不適合品の手順に回しますsuspectを見る … 桁や小数点の読み違いなら、写しを見て値を直して確定します。書き違いの疑いがあれば、作業者と班長に確かめますjudgement_mismatchを見る … 規格内なのに「否」が付いている、またはその逆です。作業者が見た規格が古い版だった、ということがありますlow_confidenceを見る … 写しと見比べて確定します- 傾向の知らせを見る … 管理図の規則に当たった品番・測定項目を、備考の出来事と合わせて見ます
1番目は、確定の前に班長へ知らせが届いています。 班長は写しを見て、次の直の加工を続けるか、測り直すかを先に判断できます。 品質管理課の確定は、その後の記録と処置のためです。
目標は、400枚をならして1枚1.5分です。 印の無い記録表は一覧で品番とロットを流し見て終わり、印の付いた値のある記録表だけ写しを見ます。
例外に対処する
| 起きること | 対応 |
|---|---|
| 品番が検査基準に無い | 処理を止めて品質管理課へ。似た品番に寄せない |
見出しが測定項目に対応しない(unmapped) | その列を品質データに入れず、担当が対応を決める |
| 結合セルで列がずれている | 表を品質データに入れず、写しから担当が打つ。書式の見直しの候補に挙げる |
| 小数点が消えている | suspect。写しで確かめる |
| 同じロットの記録表が2枚ある | 両方を担当へ。作業者と班長に確かめる |
| 記録表が回収されていない | ラインの生産実績と照らし、記録表の無いロットを翌朝に出す |
| 備考に不具合の記載がある | other でも原文を担当に見せる |
| OCR・AIが応答しない | スキャンをフォルダに残す。処理済みへ移すのは成功時だけ |
下から3行目は、この構成だから拾えるものです。 生産実績にあるロットの記録表が届いていなければ、測っていないのか、記録表が失われたのかを確かめる必要があります。これまでは打ち直しの遅れに紛れて気づけませんでした。
記録を残す
- 元のスキャンと、スキャン日時・ライン・直・スキャンした班長
- OCRが返したJSONの全文と、Claude API の応答の全文
- Python の比較結果(
suspect、out_of_specなど)と、そのとき参照した検査基準の版 - 担当が値を直した記録(どのセルを、何から何へ、誰が)
- 班長への通知の日時と、班長の対応の記録
- 品番・ラインごとの
suspectの発生率
3つ目で検査基準の版を残すのは、図面の改訂で規格が変わるためです。 過去の値が規格外れだったかどうかは、当時の規格で判断しなければなりません。
最後の行は、書式とスキャンの見直しの材料になります。 特定のラインで suspect が多ければ、鉛筆の濃さか、記録表を置く場所の明るさか、複合機の設定に理由があります。
04実装レベルの3段階
最小構成は確かめるための段階です。 1枚ずつ貼り付けるので、400枚には使えません。 半自動化で、1枚6分が3分程度になります。 打ち直しは無くなりますが、規格との見比べと、値を品質データへ移す確認が残ります。本格構成で1.5分になり、この段階が本記事の想定です。 差が大きいのは、規格との比較と桁の確認が、人の目から Python の規則に移るためです。 段階を飛ばさないでください。 半自動化の確定前のシートを1か月見ると、どの見出しが unmapped になりやすいか、どのラインで小数点が消えやすいかが分かります。そこを直してから規則を足すほうが、誤報が少なく済みます。
05工数削減シミュレーション
導入後 400件 × 1.5分 ÷ 60 = 10 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 機械加工・樹脂成形・プレスなどのラインで、作業者が初品・中間・終品の寸法をノギスやマイクロメータで測り、紙の検査記録表に手書きしている工場。回収した記録表を品質管理課が表計算ソフトへ打ち直し、管理図を描くのが数日遅れになっている場合。規格内で少しずつずれていく傾向を、規格外れが出てから知ることがある場合。記録表の書式を見直せる場合。
- 測定器から値を直接データとして取り込めており、手書きの記録表がほとんど無い場合。品番が数種類で、記録表が月に数十枚にとどまる場合。顧客の指定で記録表の書式を一切変えられず、結合したセルの多い表を使い続ける必要がある場合。なお、不適合品の処置や出荷の可否の判断は、この構成では代替できません。
07最小構成で試す方法
- 先月の記録表から、品番の違うものを20枚選ぶ(規格外れのあったロットと、管理図で傾向が見えたロットを必ず入れる)
- その20枚について、品質データのファイルに打ち直した値を用意する
- スキャンを手元のAIサービスの画面に1枚ずつ貼り付ける
- 「この記録表の測定値を、測定項目と時刻ごとに表にしてください。書かれたとおりの文字列で写し、桁や小数点を補わないでください。読めない値は『読めない』としてください」と指示する
- 出てきた表を、打ち直した値と1つずつ突き合わせる
記録表は、顧客との取り決めで認められた環境でだけ扱ってください。 図面の情報が含まれるため、試す段階でも社内の決まりを先に確かめます。
| 出てきた内容 | 判断 |
|---|---|
| 打ち直した値とほぼ一致した | OCRとプログラムの連携に進む |
| 小数点を補った・規格に近づけた | 指示の書き方で直る。構成は有効 |
| 列がずれて測定項目が入れ替わった | 書式の見直しが先。 結合セルを探す |
| 読めない値が多い | スキャンの設定が先。 AIの問題ではない |
3行目が出たら、記録表の見出しを見てください。 たいてい、測定項目の見出しが2段になっているか、時刻の列が途中で結合されています。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 小数点や桁をAIが補う | 文字列で写させ、規格の数値をAIに渡さない |
| 読み違いが規格外れに見える | 桁の確認で suspect と out_of_spec を分ける |
| 結合セルで列がずれる | Form Parser は単純な表が対象。書式から結合セルをなくす |
| 見出しの略記で項目が混ざる | unmapped を許し、似た項目に寄せさせない |
| 白黒のスキャンで小数点が消える | グレーかカラーで300dpi |
| 確定前の値が管理図に入る | 確定前のシートを分け、管理図は確定値だけで描く |
| 管理図の規則で誤報が多い | 規則を足すほど誤報も増える。使う規則を品質管理課が選ぶ |
| 規格の改訂が反映されない | 検査基準の表に版を持たせ、比較のたびに版を記録する |
| 作業者の判定欄を書き換える | 書いたとおりに写させ、食い違いは別の印で出す |
| 班長への通知が遅れる | 規格外れの候補は確定を待たずに写し付きで知らせる |
| 国外での処理を確かめていない | 日本のリージョンが無い。顧客との取り決めを確かめる |
上の2行が、この構成の失敗のほとんどです。 どちらも、書かれた値と品質データの値がずれるという同じ型の失敗です。補わせないことと、補う必要がある値に印を付けることを、AIとプログラムで役割を分けて持ちます。
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 品番、ロット番号、寸法の規格と測定値、機械番号、作業者の名前です。寸法の規格は顧客の図面から来ているものが多く、顧客との取り決めで扱いが決まっていることがあります。
- 国外で処理することを確かめる … Document AI のリージョンの一覧に日本はありません。顧客の図面に由来する寸法を国外のリージョンで処理してよいかを、顧客との取り決めと社内の情報管理の決まりで確かめます
- 外部へ渡す範囲を絞る … AIに渡すのは記録表の読み取り結果と、測定項目の名前とコードだけです。規格の数値はAIに渡さず、比較は社内の Python で行います
- 不適合品の処置を判断させない … AIも Python も、出すのは規格外れの候補と傾向の知らせまでです。選別、手直し、出荷の可否は、品質管理課と製造課が手順に沿って決めます
- 元のスキャンを残す … 品質の記録の拠り所は、作業者が書いた記録表です。AIが整えたデータではなく、スキャンを原本として残すことを保存の決まりにします
- 作業者の評価に使わない …
suspectの発生率は書式やスキャンの見直しの材料です。特定の作業者の書き方を責める材料にすると、記録表が正直に書かれなくなります
誤りが起きた場合のリスクは、本当の規格外れを読み違いとして流すことと、読み違いを規格外れとして止めることの2つです。 前者は不良の流出、後者はラインの無駄な停止につながります。桁の確認と写しでの確定は、両方を防ぐために外さないでください。
10まず何から始めるか
1週目:検査基準をデータにする
記録表の枚数が多い品番を10選び、測定項目、規格の中心値と上下限、測定器の最小の読み取り単位を1つの表にします。あわせて、その10品番の記録表の書式に結合セルが無いかを見ます。
2週目:20枚で試す
先月の記録表20枚を手元のAIサービスに貼り付け、測定値を表にさせます。打ち直した値と突き合わせ、小数点や桁を補っていないかを最優先で見ます。
3週目:書式とスキャンを直す
結合セルのある記録表の書式を直し、複合機の保存の設定をグレー・300dpiにします。 判定欄を「合/否」の文字にするか、印刷のチェックボックスにするかを決めます。
4週目:フォルダから確定前のシートまでをつなぐ
Python でフォルダを見張り、OCRを呼び、値を確定前のシートに書き出すところまで作ります。この時点では規格との比較を出さず、担当がこれまでどおり打ち直した値と見比べます。
2か月目: 規格との比較と桁の確認を足し、suspect と out_of_spec の印を出します。班長への通知もここで始めます。3か月目以降: 管理図の規則を足し、1枚6分が何分になったかを実測します。使う規則と誤報の数を品質管理課が見直し、傾向の知らせが翌朝の打合せで使われるようになった時点で、この構成は完成です。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
Form Parser がOCRのテキストに加えてキーと値のペア、チェックボックス、表を抽出すること。言語の一覧で日本語(ja)が手書きに対応する言語として示されていること。オンラインの処理が1回の要求で最大15ページであること | Google Cloud: Processor list | 2026-10-08 |
| 表の抽出が行や列をまたぐセルの無い単純な表を対象にすること | Google Cloud: Form Parser | 2026-10-08 |
項目名と値の組が formFields の fieldName/fieldValue で、表が headerRows/bodyRows で返ること。Form Parser では rowSpan と colSpan が常に1であること。表の中のチェックボックスが ✓/☐ の文字で表されること。信頼度と位置が各要素の layout に入ること | Google Cloud: Handle the processing response | 2026-10-08 |
| 対応形式が PDF、GIF、TIFF、JPEG、PNG、BMP、WebP などであること。スキャンは最低200dpiが望ましく300dpi以上が一般に最もよいこと | Google Cloud: Supported files | 2026-10-08 |
マルチリージョンが us と eu で、単一リージョンにシンガポール(asia-southeast1)などがあり、日本のリージョンが一覧に無いこと | Google Cloud: Regional and multi-regional support | 2026-10-08 |
| Western Electric の規則として、中心線の同じ側に8点続くこと、6点続けて上がる(下がる)ことなどが示されていること。規則を足すと感度が上がる一方で誤報も増えること | NIST/SEMATECH e-Handbook of Statistical Methods: What are Variables Control Charts? | 2026-10-08 |
output_config.format に JSON スキーマを渡して応答の形を固定できること。列挙の値の大文字・小文字は保証されないこと。max_tokens で打ち切られたときはスキーマに合わない出力になりうること | Claude API: Structured outputs | 2026-10-08 |
どの管理図の規則を使うか、不適合品をどう処置するかは、自社の品質管理課と製造課が決めてください。 本記事は各製品の公式ページと NIST の公開資料で確認できた範囲だけを扱っています。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-0971)についてのご相談はこちらから。
