製品ラベルと取扱説明書の表示事項を、出荷前に社内の表示ルールに照らして点検する

処理の起点を決める

点検フォルダにファイルが保存されたことを起点にします。 制作会社からの戻りは日付がばらけるため、まとめて処理すると指摘が出るのが出荷の直前になります。直す手は社外にあり、差し戻して戻るまでの時間を残さなければ意味がありません。

n8n では、取りこぼしを拾う見回りとして Schedule Trigger を足せます。間隔は秒・分・時・日・週・月とカスタム（Cron）から選べ、Cron は「秒 分 時 日 月 曜日」の6フィールドです。 タイムゾーンはワークフローの設定を、無ければインスタンスの設定を使うとされ、セルフホストの既定は America/New_York、Cloud は検出できなければ GMT です。

トリガーに使うワークフローは、保存して公開する必要があります。 Cron式の中の変数は公開時にのみ評価され、指定した日が無い月は実行されません。

入力データを集める

太字の2つが、この構成の質を決めます。 ルール表が無ければAIは「何がそろっているべきか」を知らず、対応表が無ければラベルが古い版かを見る手がかりがありません。読み取りの精度を上げても、この2つが無いところでは何も出ません。

表示ルール表の列は、rule_id（指摘はこの番号で返る）、製品区分、仕向地、表示項目、表示先、規定の文言、一致の見方、版と発効日です。「一致の見方」を省かないでください。 定型文は完全一致、定格の数字はマスタの値と一致するか、と扱いが違い、無いと数字の違いと言い回しの違いが同じ重さで出ます。

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

読み取り結果から使うのは5つです。paragraphs の content で該当する記載を探し、role で見出しと脚注を見分けてページを絞ります。tables の cells はラベルの表組みから項目と値の対を取り、boundingRegions の polygon は人が原本を開くときに見る場所を指し示します。words の confidence は、書かれていないのか読めていないのかを分けるためで、ここが要です。 styles の isHandwritten は校正の赤字が残った入稿を拾います。

ラベルと取説は別々に呼びます。 どちらに書かれていたかが分からなくなると、3種類目の指摘が作れません。社内の2つの表を引く順は、製品コードが先、仕向地が後です。 先に仕向地で絞ると、そこに規則が1行も無い製品が「指摘なし」で通り抜けます。版の照合は、AIに渡す前に機械で済ませます。 マスタの版と対応表の版を比べ、一致しなければ rev_match に mismatched を立てるだけです。

AIへ渡す前に整形する

1. 形式の確認 … PDF、画像（JPEG/JPG、PNG、BMP、TIFF、HEIF）、Office形式が入ります
2. ページ数とサイズ … PDFとTIFFは最大2,000ページ（Freeは最初の2ページのみ）、サイズは有料（S0）で500MB、Free（F0）で4MB
3. 画像の寸法 … 50×50から10,000×10,000ピクセルの間である必要があります
4. 解像度 … テキストの最小の高さは1024×768の画像で12ピクセル。150dpiで約8ポイント相当
5. ロックの解除 … パスワード付きのPDFは、提出前に解除が必要です
6. 該当ページの絞り込み … 取説は pages で指定します
7. 製品コードと仕向地の取り出し … 取れないものは人へ回します

4番目を軽く見ないでください。 ラベルの注意書きは、面積の都合で小さく印刷されます。下限に近い文字は、読めなかっただけなのに「書かれていない」と同じ見た目になります。 書き出しの解像度を先に決めておくと、取りこぼしが減ります。6番目は費用にも効きます。 取説が80ページあっても、表示事項が載るのは数ページです。

AIに処理させる

させるのは、ルール表の規則1行ずつについて、該当する記載が読み取り結果にあるかを見て、指摘を3種類に分けることだけです。 記載が見当たらなければ missing_item、あるが規定の文言と違えば wording_diff、ラベルと取説で食い違えば label_manual_conflict です。

判断できないものは、指摘と混ぜずに undecidable に置きます。 理由は3つで、ルール表に規則が無い no_rule（新しい仕向地、新しい規格はここ）、信頼度が低く確定できない unreadable、文字の大きさや表示の位置に関わる size_or_position です。no_rule を「指摘なし」に落とさないことが、この構成の要です。 ルール表に無い表示を見たとき、機械は「ルールに反していない」と判定できてしまいますが、それはルール表がその表示を知らないだけです。

4行目がいちばん起きやすい失敗です。 定格の数字が1桁かすれたラベルを渡すと、製品マスタの値を見て埋めます。その瞬間、見つけたかった印刷の不備が消えます。

指示内容を固定する

あなたは品質保証部で、出荷前の製品ラベルと取扱説明書の表示事項を点検する立場です。
渡された読み取り結果と表示ルール表だけを見て判定し、推測で埋めないでください。
【手順】規則を1行ずつ見て、求める表示がラベル側・取説側にあるかを確かめ、
missing_item ／ wording_diff ／ label_manual_conflict に分けてください。
判断できないものは no_rule ／ unreadable ／ size_or_position として undecidable へ。

【厳守事項】
- その製品にその表示が必要かどうかを、あなたが判断しないでください。
  必要かどうかはルール表に書いてあります。ルール表に無いものは no_rule です。
- 制度に適合しているかを書かず、規則と照らした結果だけを返してください。
- 読み取れなかった値を製品マスタやほかのページの記載で補わないでください。
  信頼度が低いものは unreadable です。missing_item にしないでください。
- 「一致の見方」が「完全一致」の規則は句読点と送り仮名の違いも wording_diff、
  「どちらでもよい」の規則は指摘しないでください。
- label_manual_conflict は両方に記載があり内容が違うときだけで、
  片方に無いものは missing_item です。
- 文字の大きさと位置の合否は書かず、size_or_position に回してください。
- evidence には根拠の文字列を、confidence は読み取り結果の値をそのまま入れ、
  文言の直し方は提案せず規定の文言を expected に写してください。

【ラベル】{label_ocr}　【取説】{manual_ocr}
【この製品区分・仕向地の表示ルール表】{rules}
【製品マスタの値（照合用。補完に使わないこと）】{product_master}

「必要かどうかをあなたが判断しない」を最初に書く理由は、書かないと判断するからです。 何も言わなければ「この種類の製品なら普通はこの表示が要る」と考えて missing_item を出します。もっともらしいぶん、質の悪い失敗です。 missing_item と unreadable を分ける指示も同じ理由で要ります。どちらも「見当たらない」に見えますが、前者は制作データ、後者は入稿データの解像度を直す話です。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "doc_id": "", "product_code": "", "destination": "", "rule_set_version": "",
  "findings": [
    { "rule_id": "", "type": "missing_item | wording_diff | label_manual_conflict",
      "source": "label | manual | both", "expected": "",
      "found_text": "", "manual_text": "",
      "page": 0, "confidence": 0, "evidence": "" }
  ],
  "undecidable": [
    { "reason": "no_rule | unreadable | size_or_position",
      "rule_id": "", "page": 0, "confidence": 0 }
  ]
}

verdict をここに入れていないのは、わざとです。 指摘を出すのはAI、判定を決めるのはワークフローの規則にします。どの指摘で出荷を止めるかは自社の取り決めで、後から変わるからです。 規則は3行で書けます。findings も undecidable も空で rev_match が matched なら pass、undecidable が1件でもあるか rev_match が matched でなければ needs_human、それ以外で findings があれば needs_fix です。

構造化出力（structured outputs）を使うと、このJSONの形が保証されます。 Claude API では output_config の format.type に json_schema を指定してスキーマを渡すと、制約付きデコーディングによって常に妥当なJSONが返り、型と必須フィールドが保証されます。 パースの失敗を拾い直す処理が要りません。

スキーマの制約を3つ押さえてください。 すべてのオブジェクトで additionalProperties を false にすること。 enum に使えるのは文字列・数値・真偽値・null だけで、type と reason を縛れるのは利点です。 そして数値の制約（minimum ／ maximum）と文字列の制約（minLength ／ maxLength）は使えないので、confidence の範囲はワークフロー側で確かめます。初回は文法のコンパイルで遅くなりますが、24時間キャッシュされます。 旧来の output_format は output_config.format へ移りました。

システムへ連携する

製品マスタにも表示ルール表にも書き込みません。 出すのは点検の結果までで、ルール表を直すのは人の判断を経てからです。 自動で追記すると、誤った指摘がルールとして定着します。

人が確認する

人が開くのは needs_fix と needs_human のものだけです。 pass は件数の一覧を流し見て終わりにします。全件を開く設計にすると、第10章の13.5時間には収まりません。

1. needs_human を先に見る … 版のずれは、ここで止めなければ直る場所がありません
2. no_rule を読む … 正しければルール表に足し、不要なら外すよう伝えます
3. findings の根拠を確かめる … evidence と page で原本を開きます
4. 文字の大きさと位置を見る … size_or_position のものと、指摘の周辺を見ます
5. 判定を覆したら記録する … どの rule_id を、どちらに変えたかを残します

2番目を飛ばさないでください。 no_rule の件数は、そのままルール表の未整備の量です。毎月読んで足していくと、半年でほとんど出なくなります。 目標は、90件をならして1件9分です。 pass は数秒、それ以外は原本を開いて十数分かかり、指摘が3割前後という想定でならして9分です。

例外に対処する

n8n では、落ちたときの受け口を Error Trigger で作れます。 失敗したワークフローとエラーの詳細を取得して、エラーワークフローを実行するノードで、実行のIDとURL、エラーメッセージとスタックトレース、どのノードで落ちたかを示す lastNodeExecuted、ワークフローのIDと名前が届きます。ただし、自動実行で落ちたときだけ動き、手動実行では試せません。 execution.id と execution.url は実行がデータベースに保存されている必要があり、主ワークフローのトリガーノードで落ちた場合には出ません。 見張り自体が止まったときは気づけないので、点検フォルダに残った未処理の数を別に数えてください。 なお、Error Trigger を含むワークフローは既定で自分自身をエラーワークフローとして使うため、通知以外を置かないでください。

記録を残す

• 入稿データそのものと、受け取った日時・制作会社
• 読み取り結果のJSON（paragraphs、tables、confidence、styles）
• そのとき参照した表示ルール表の版（rule_set_version）と規則の内容
• 判定結果（findings、undecidable、rev_match、verdict）
• 人が判定を覆した記録 … どの rule_id をどちらに変えたか
• no_rule として出たものと、その後ルール表に足したかどうか
• rule_id ごとの発生件数と、制作会社ごとの内訳

3つ目で「そのときのルール表の版」を残すのは、表が育つ前提の構成だからです。 規則を1行足すと、それ以前の判定の意味が変わり、当時の版が残っていないとやり直す範囲が決まりません。 下から2つ目が、ルール表を育てる動線そのものです。 no_rule として出たものを一覧にし、人が「足した／足さない」を書き込む欄を作れば足ります。無いと、同じ表示が毎月出続けます。