印刷会社が入稿データのメールを n8n で受け、PDFの解像度・塗り足し・フォントの埋め込みを注文の仕様と照らして判定し、不備の連絡をお客に返す

処理の起点を決める

Email Trigger（IMAP）で、入稿用のアドレスにメールが届くたびに動かします。 公式ページでは、受け取るメールボックスを指定でき、添付をダウンロードする設定と、添付をバイナリとして持つ形式（Resolved）があります。添付の取得は処理を重くするので必要なときだけ有効に、とされていますが、この構成は添付が主役なので有効にします。

受け取ったメールは「既読にする」設定にします。 公式ページでは、受け取ったメールを既読にするかを選べます。既読にしておけば、同じメールを二度処理しません。 あわせて、処理したメールの Message-ID を Data Table に残し、二重に動いたときに弾きます。

1日の締めでまとめて動かすことはしません。 入稿は納期の直前に集中し、連絡が数時間遅れるだけで作り直す時間が無くなります。

入力データを集める

質を決めるのは、いちばん下から2つ目の入稿ガイドの表です。 Webに文章で載っているガイドを、品目ごとの数値の表に直します。名刺・チラシ・冊子・ポスターそれぞれの塗り足しの幅と、必要な解像度。この表が無いと、AIは一般論の数字で判定します。

受注の管理表は、毎晩 Data Table に写します。 管理表の列の変更でワークフローが止まらないよう、写すときに必要な列だけをそろえます。

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

注文番号は、まず決まった形で探します。 「W-」で始まる7桁、のように自社の番号の形を正規表現で探し、見つからなければAIに探させず、人へ回します。 本文の「先日電話した○○です」から注文を推測させると、別のお客の注文に結び付きます。

検査サーバーには、PDFをそのまま送ります。 公式ページでは、HTTP Request の本文に Form-Data を選び、受け取ったバイナリのファイルを入れられます。検査サーバーは3つの命令を動かした結果を JSON で返します。

pdfinfo には最初と最後のページを指定します。 公式の説明では、-f と -l で複数のページを指定するとページごとの大きさとボックスを出し、指定しなければ1ページ目だけを調べるとされています。冊子の途中のページだけ大きさが違うPDFを見逃さないためです。

pdfimages -list の解像度は、ページに置かれたときの値です。 公式の説明では、width と height は埋め込まれた画像の大きさで、描かれる大きさではないとされ、x-ppi と y-ppi はページに描かれたときの解像度です。判定には x-ppi と y-ppi を使います。 透過のための mask・smask の行は、type の列で除きます。

AIへ渡す前に整形する

1. 添付の形式を見る … PDF以外（ai、psd、jpg、zip など）は検査に回さず、「形式」の項目を判定の材料にします
2. 大きすぎる添付 … メールに付けられない大きさのデータは、ファイル転送のサービスのリンクで届きます。リンク先からは自動で取りに行かず、人へ回します
3. パスワード付きのPDF … 検査サーバーが開けなければ、その旨を判定の材料にします
4. 複数のPDF … 表紙と本文のように分かれて届くものは、ファイルごとに測り、注文の仕様とは合計のページ数で照らします
5. ボックスを大きさに直す … 検査サーバーの側で、ボックスの値を幅と高さのミリに直し、仕上がりサイズとの差と、TrimBox と BleedBox の差を出します
6. 規則で先に決まる項目 … フォントの emb が no のものがある、ページ数が注文と違う、は規則で先に印を付けます

2番目でリンクを取りに行かないのは、送り主の確かめが要るからです。 メールに書かれたリンクを自動で開く仕組みは、偽のメールからのリンクも開きます。 入稿のメールの差出人が、注文のお客と同じかも分かりません。

5番目で、TrimBox が無いPDFも扱えるようにします。 自分で作ったPDFには、MediaBox しか無いものが少なくありません。MediaBox が仕上がりサイズと同じなら「塗り足しなし」、仕上がりサイズに塗り足しの幅を足した大きさなら「塗り足しあり」、どちらでもなければ「人が見る」とし、トンボ付きのPDFもこの3つ目に入れます。

AIに処理させる

させるのは、測った値と注文の仕様と入稿ガイドを突き合わせ、6つの項目それぞれに判定を付けることと、不備のある項目をお客向けの言葉で説明することです。

判定は ok（問題なし）・ng（不備）・warn（注意）・needs_human（人が見る）の4つです。 warn は、刷れるがお客に伝えておくべきもので、RGB の画像が入っているときの色の変わり方が典型です。どこまでを ng にし、どこからを warn にするかは、入稿ガイドの表に品目ごとに書いておきます。

4行目がいちばん起きやすい失敗です。 注文が A4 なのにPDFが B5 なら、それは不備です。AIに「PDFが B5 なので、B5 の注文と思われます」と判断させると、不備が消えます。

指示内容を固定する

Basic LLM Chain のシステムメッセージに、次のように書きます。

あなたは印刷会社のDTP担当として、入稿データの点検の結果を判定します。
入力の数値だけを使ってください。PDFの見た目は判断材料にしません。

【入力】
- 注文の仕様（品目、仕上がりサイズ、ページ数、片面/両面、色数、製本の方法）
- 入稿ガイドのうち、その品目の条件（塗り足しの幅、必要な解像度、受け付ける形式、ng と warn の区分）
- 測った値（ファイルごとのボックスの大きさ、ページ数、フォントと emb、画像ごとの x-ppi・y-ppi・color）
- 規則で付いた印（フォントの emb=no、ページ数の不一致）

【判定する6項目】
format / trim_size / bleed / image_resolution / fonts / page_count

【status の選び方】
- ok ........... 条件を満たす
- ng ........... 条件を満たさない。お客に直してもらう
- warn ......... 刷れるが、お客に伝えておく（入稿ガイドで warn とされたもの）
- needs_human .. 入力だけでは決められない
迷ったときに ok を選ばないでください。

【厳守事項】
- 注文の仕様と測った値が食い違うときは、注文の仕様を正として ng にしてください。
  PDFの大きさに合わせて注文を読み替えないでください。
- 解像度は x-ppi と y-ppi の小さいほうで判定してください。
  type が mask または smask の行は判定に使わないでください。
- 入稿ガイドに条件が無い項目は needs_human にしてください。一般的な数値で補わないでください。
- デザイン、文字の内容、誤字には触れないでください。
- 刷ってよいかの結論を書かないでください。
- customer_message は、ng と warn の項目だけを、専門用語を避けて説明してください。
  「何が」「どのページで」「どう直せばよいか」を1項目ずつ書き、
  直し方が分からない場合の連絡先として担当の窓口を書いてください。
  入稿ガイドのページの URL を添えてください。
- 全項目が ok なら customer_message は空にしてください。

【入力】{order}{guide}{measured}{flags}

「注文を正として ng に」が要の一文です。 書かないと、AIは食い違いを「どちらかの誤り」として、数字のそろっているPDFの側に寄せて説明しようとします。 注文の受け付けの段で決まったことは、点検の段で変えません。

「一般的な数値で補わない」も効きます。 ガイドの表に冊子の表紙の条件が無いとき、AIは印刷で一般によく言われる数値を持ち出します。自社の条件ではない数字で ng を出すと、お客は直さなくてよいものを直します。

出力形式を固定する

Structured Output Parser で、次の形に決めます。 公式ページでは、JSON の例から生成するとすべての項目が必須として扱われ、JSON Schema で書くこともでき、$ref には対応しないとされています。

{
  "order_no": "",
  "files": ["front.pdf"],
  "checks": [
    { "item": "image_resolution", "status": "ok | ng | warn | needs_human",
      "pages": [2], "measured": "", "required": "", "note": "" }
  ],
  "verdict": "ready | return_to_customer | needs_human",
  "customer_message": ""
}

checks には6つの項目を並べます。measured は測った値（「x-ppi 142」など）、required は入稿ガイドの条件をそのまま写します。

1つ目の理由は、verdict を規則で決め直せることです。

ワークフローは、AIが書いた verdict を使わず、checks からこの表で決め直します。 AIが ng を書きながら ready と結論しても、製版のフォルダには置かれません。

2つ目は、measured と required で担当の確認が速くなることです。 担当はPDFを開く前に、どの数字がどの条件に足りないかを一覧で読めます。

3つ目は、pages で「2ページ目の写真」と具体的に書けることです。

システムへ連携する

担当の確認には、Slack の Send and Wait for Response を承認の形で使います。 公式ページでは、Slack の中で承認・却下でき、承認できる人を限ることができ、誰が応じたかが出力に残るとされています。n8n が公開の HTTPS で届くこと、Slack のアプリで Interactivity の受け口を設定すること、資格情報に Signing Secret を入れることが要るとされています。

お客への連絡は、Send Email で送ります。 公式ページでは、SMTP の資格情報で送り、Reply To を指定できます。ただし、このノードは In-Reply-To と References のヘッダーを付けられず、メールがスレッドにならないとされています。件名に注文番号と「入稿データの確認」を入れ、お客の受信箱で元のメールと結び付けられるようにします。スレッドにしたい場合は、公式ページが示す Gmail ノードの返信の操作を使います。

人が確認する

DTPの担当が、Slack に届いた判定を確かめます。

1. needs_human を先に見る … 注文番号が無い、ボックスが合わない、ガイドに条件が無い。PDFを開いて自分で判断します
2. return_to_customer の下書きを読む … measured と required を見て、不備が本当かを確かめ、説明がお客に伝わる言い方かを直します
3. ready で warn のあるものを見る … RGB の画像の色の変わり方を伝えるか決めます
4. ready を流し見る … 製版へ回します

2番目の言い方は、担当が最後に見ます。 不備が続くお客に電話を勧める一文を足す、といった判断は担当がします。

目標は、1,200件をならして1件1分です。 ready は流し見るだけで数秒、return_to_customer と needs_human は数分かかります。

例外に対処する

3行目は、仕組みを作る前に決めておいてください。 大きいデータほど転送のリンクで届き、リンクを自動で開く仕組みは、入稿を装ったメールのリンクも開きます。 手間でも、ここは人が開きます。

記録を残す

• 受信したメールの Message-ID、差出人、受信日時、添付のファイル名と大きさ
• 結び付けた注文番号と、そのとき引いた注文の仕様
• 検査サーバーが返した測った値の全文
• AIの判定（checks、customer_message）と、規則で決め直した verdict
• 担当の選択（送る／直して送る／製版へ）と、応じた人と時刻、直した後の文面
• 再入稿との対応と、前回の ng が直ったか
• 製版や刷り出しの段で見つかった不備（点検で見落としたもの）

最後の行が、点検の答え合わせです。 製版で見つかった不備が、測った値にあったのに判定で ok になったのか、そもそも測っていない項目だったのか。前者なら指示かガイドの表を、後者なら測る項目を足します。