工場で作業標準書を改訂したときに、QC工程表・検査基準書・前後工程の標準書との食い違いを判定し、承認前に指摘一覧を出す

処理の起点を決める

改訂申請の状態が「整合確認待ち」になったことを起点にします。 申請の登録そのものを起点にしないのは、改訂者が書きかけの申請を保存することがあるためです。改訂者が「確認を依頼する」を押した時点で動かします。

文書管理システムが状態の変化を外へ知らせる仕組みを持たない場合は、30分ごとに状態の一覧を書き出し、Python が新しく「整合確認待ち」になった申請を拾う形にします。どちらの方式でも、処理が終わったら申請の状態を「指摘一覧あり」に、失敗したら「要再実行」に変えます。

1日1回のまとめ処理にはしません。 改訂は設備の立ち上げや不具合の対策に合わせて急ぐことが多く、承認の待ち時間がそのまま現場の旧手順の期間になります。

入力データを集める

質を決めるのは、変更した管理項目の欄と、項目名の対応表です。 変更した管理項目が書かれていないと、すべての食い違いが既存の不整合か波及漏れかを決められず、判断不能に寄ります。 項目名の対応表が無いと、AIは似た名前の別の項目を同じものとして対応づけることがあります。

前後工程は1つずつに限ります。 2つ先の工程まで含めると、文書の数が増えて対応づけの精度が落ちます。理由は「前処理」で述べます。

データの取得方法を決める

関連文書は必ず台帳で最新版を引きます。 改訂者が添付した関連文書を使うと、手元に保存していた古い版で比べることになります。比べる相手が古いと、食い違いの指摘そのものが誤ります。

治具・ゲージの台帳はAIに渡しません。 番号の照合は Python で済み、台帳には工場全体の治具の一覧と保管場所がまとまっているためです。

AIへ渡す前に整形する

1. 版の確認 … 関連文書が台帳の最新版であることを確かめます。改訂の手続き中の文書が他にあれば、印を付けます
2. QC工程表の切り出し … 該当する工程番号の行だけを、見出し付きの表の文字にします。結合セルは、上の行の値で埋めてから文字にします
3. ページの向きと鮮明さ … 公式のドキュメントでは、ページの向きを正しく直してから渡すこと、ぼやけたページを避けることが勧められています。横向きにスキャンされた標準書は回転させます
4. 1回に渡す文書を絞る … 1回の呼び出しで渡すのは、改訂後の標準書と、比べる相手の文書1本です。QC工程表、検査基準書、前工程、後工程の4回に分けます
5. 問いを最後に置く … 文書を先に、指示を後に置きます
6. 項目名の対応表を添える … 品番の分類で絞ったものだけを渡します

4番目を省かないでください。 公式のドキュメントでは、Gemini は100万トークンの文脈を受け付ける一方、探す情報が複数あるときは、1つを探すときと同じ精度では動かないと書かれています。改訂1件で比べる管理項目は数十あり、まさに「複数の情報を探す」使い方です。全部の文書を1回に入れるより、相手の文書ごとに分けるほうが取りこぼしが減ります。

5番目も同じドキュメントにある助言で、長い文書を扱うときは問いをプロンプトの最後に置くほうが性能がよいとされています。

AIに処理させる

させるのは、管理項目を拾い、文書をまたいで同じ項目を対応づけ、数値以外の食い違いを判定することです。

数値は原文のまま返させます。 「12±1 N・m」「11〜13N・m」「12N・m（11-13）」のような書き方の違いを、AIに範囲へ直させると、直し方の誤りと文書の食い違いが区別できなくなります。 範囲への変換は Python が原文から行い、AIが返した参考の範囲と合わなければ ask にします。

2行目がいちばん起きやすい失敗です。 単位の違う値を「換算すると同じ」と答えさせると、現場で使うトルクレンチの目盛りと標準書の単位が合っていない、という本当の問題が消えます。

指示内容を固定する

あなたは工場の品質保証課で、作業標準書の改訂案と関連文書の整合を確かめる担当者の補助です。
渡された2つの文書だけを見て答えてください。文書に無い知識で値を補わないでください。

【文書A】改訂後の作業標準書（品番 {part_no}、工程 {process_no}、版 {rev_a}）
【文書B】比べる相手（種類 {doc_b_type}：qc_chart / inspection / prev_process / next_process、版 {rev_b}）
【項目名の対応表】{alias_table}

【やること】
1. 文書Aの管理項目をすべて拾ってください。項目名、値と公差、単位、
   治具・ゲージ番号、頻度、ページを書いてください。写真の書き込みも対象です。
2. 文書Bについても同じように拾ってください。
3. 文書Aの各項目が、文書Bのどの項目に当たるかを対応づけてください。
   名前が違っても、対象の部位と特性が同じなら同じ項目です。対応表も使ってください。
   候補が複数あれば ambiguous、文書Bに無ければ no_counterpart としてください。
4. 対応づけた項目について、測定方法、頻度、記録の様式、作業の順序が違うかを答えてください。
5. 文書Bが前後の工程のときは、受け渡しの条件（印、置き方、確認の手順）を比べてください。

【厳守事項】
- 値と公差は、文書に書かれたとおりの文字で value_raw に入れてください。
  「±」「〜」「（ ）」の書き方を変えないでください。
- 値が合っているか、一致しているかを書かないでください。
- 単位を換算しないでください。単位が違うときは、それぞれの単位をそのまま書いてください。
- 写真の書き込みが読めないときは、推測せず unreadable としてください。
- 部位や特性が同じか判断できないときは、無理に対応づけず ambiguous としてください。
- 改訂の内容が適切かどうかを書かないでください。
- evidence には、根拠にした文字をそのまま写し、ページを書いてください。

以上の文書を読んだうえで、指定のJSONスキーマで答えてください。

「値が合っているかを書かない」を明記しないと、一致・不一致の判定まで返ってきます。 それ自体は便利に見えますが、換算や丸めを黙って行った判定が混ざります。比較は Python に一本化し、AIの判定とは二重に持ちません。

最後の一文を末尾に置いているのは、前処理の5番目のとおりです。 長い文書を先に、問いを後に置きます。

出力形式を固定する

レスポンスのMIMEタイプを application/json にし、JSONスキーマを渡して、次の形で受け取ります。 公式のドキュメントでは、構造化出力は構文として正しいJSONを返すが、値が意味の上で正しいとは限らないため、アプリケーションの側で値を検証し、スキーマに沿っていても意味が誤っている出力に備えたエラー処理を実装するよう案内されています。

{
  "request_id": "",
  "doc_a": { "doc_id": "", "rev": "" },
  "doc_b": { "doc_id": "", "rev": "", "type": "qc_chart | inspection | prev_process | next_process" },
  "pairs": [
    {
      "item_a": { "name": "", "value_raw": "", "unit": "", "tool_ids": [""], "frequency": "", "page": 0 },
      "item_b": { "name": "", "value_raw": "", "unit": "", "tool_ids": [""], "frequency": "", "page": 0 },
      "match_status": "paired | ambiguous | no_counterpart | unreadable",
      "other_diffs": ["method | frequency | record | sequence"],
      "evidence": ""
    }
  ],
  "handover": [ { "condition": "", "status": "consistent | differs | not_stated | unclear", "evidence": "" } ]
}

match_status と status は、スキーマの enum で値を固定します。公式のドキュメントでは、文字列に enum を使って分類に使えるとされています。

1つ目の理由は、AIの答えと機械の比較を別の層に置けることです。 pairs はAIが埋め、値の範囲と単位の比較、治具の照合、種類の付与は Python が行います。比較の規則を変えても、AIの呼び出しはやり直さずに済みます。

2つ目は、Python の側で検証できることです。 公式の案内どおり、value_raw を Python が自分で範囲に直し、直せない書き方なら ask にします。page の値が文書のページ数を超えていないか、tool_ids の形式が台帳の番号の形式に合っているかも確かめます。

Python が最後に付ける種類は次の5つです。

一覧の1行は、たとえば次のようになります。 改訂申請の変更点が「工程30 ハウジング締結 M6 締付トルク 10±1N・m → 12±1N・m」で、検査基準書の判定基準が「締付トルク 9〜11N・m（トルクチェッカ TC-07）」のままだった場合です。

担当者はこの1行から、検査基準書の4ページを開けば済みます。 何を探すかが先に分かっているので、確かめるのは数十秒です。

システムへ連携する

QC工程表と検査基準書には書き込みません。 波及漏れを見つけても、直すのはそれぞれの文書の持ち主です。自動で書き換えると、品質保証課の承認を経ない値が正式な文書に入ります。

人が確認する

品質保証の担当者は、指摘一覧の種類の順に確かめます。 propagation_gap → ledger_issue → ask → one_side_only → preexisting の順です。

1. propagation_gap を原文で確かめる … 引用とページで文書Bを開き、本当に改訂前の値のままかを見ます
2. ledger_issue を確かめる … 台帳の更新が遅れているだけのこともあります
3. ask を判断する … AIが対応づけられなかった項目です。担当者の仕事の中心はここです
4. one_side_only を見る … QC工程表に載せるべき項目かを決めます
5. preexisting は今回の承認と切り離す … 別の改訂として起票します
6. 扱いを記録する … 指摘ごとに「今回直す／別件で起票／問題なし」を付け、理由を一言残します

5番目が、承認を止めないための手順です。 既存の不整合も放置はしませんが、今回の改訂の承認の条件にはしません。 別件として起票し、持ち主に返します。

指摘の無い項目も、改訂した項目だけは原文で見ます。 AIが対応づけを誤ると、その項目は paired として一致の側に流れます。変更した管理項目は件数が少ないので、全部を目で確かめる時間を確認の20分に含めています。

例外に対処する

変更した管理項目の欄が空の申請を、通常どおり処理しないでください。 欄が空だと、すべての食い違いが preexisting に分かれ、波及漏れが「別件」として後回しになります。

記録を残す

• 改訂申請と、そのとき比べた関連文書の文書IDと版数
• Gemini API に渡した文書の組と、返ってきたJSONの全文、使ったモデル名
• Python の比較の結果と、付けた種類
• 担当者の扱い（今回直す／別件で起票／問題なし）と理由
• 別件で起票した既存の不整合と、その後の改訂の記録

1つ目で版数を残すのは、比べた相手が後から改訂されるためです。 監査で「この改訂のとき、検査基準書のどの版と比べたか」を問われたときに、版数が残っていないと説明できません。

4つ目は、項目名の対応表を育てる材料になります。 ask を担当者が「同じ項目」と判断した組は、対応表に足します。