印刷会社の入稿チェックと見積もりを、生成AIで時短する実務手順
塗り足し漏れや黒の設定ミスを見逃して刷り直し…印刷会社の入稿データ確認と見積もり返信を、Claude Codeに任せる範囲と人が判断する範囲に分けて時短する手順をまとめました。
金曜の夕方、お客さんから「これで進めてください」とPDFが届きました。
僕(と仲間の印刷会社の現場)がよくやるのは、急いでいる金曜こそ事故が起きるパターンです。ぱっと見はきれいなチラシ。塗り足しもあるように見えた。月曜に刷ったら、断ち切りの端に白いスジが出ました。よく見たら塗り足しが2mmしかなく、しかも一番目立つ写真の縁。お客さんは「データ通りに出したはず」と言うし、こちらは刷ってしまった。誰が悪いという話の前に、紙とインクと時間がもう消えています。
入稿データのチェックと、見積もりの返信。この2つは印刷会社の利益を静かに削る場所です。今日はここを、生成AI(Claude Code)に下働きさせて、人は判断だけする形に組み替えた話を書きます。
この記事の要点
- 入稿チェックと見積もり返信は、人の集中力に頼ると金曜の夕方に必ず崩れる。ここを機械の門番で受ける。
- Claudeに任せるのは「読む・拾う・並べる・草案を書く」まで。最終OKと色校正、価格の最終決定は人が握る。
- そのまま使えるプロンプト雛形、入稿チェックリスト、見積もり返信テンプレ、PDFの体裁を機械チェックする検証スクリプトを載せた。
- 1日20件の見積もりなら、返信の下書きだけで月20時間前後は浮く計算。刷り直し1回を防げば紙代だけで数万円。
- 入稿データには個人情報や未公開の商品情報が入る。AIに渡す前の伏せ方と、外部送信のルールを先に決める。
まず読者像。誰のための話か
想定しているのは、小〜中規模の印刷会社で、営業も兼ねるDTPオペレーターです。Illustrator・InDesign・PDFを毎日触り、見積もりも自分で返す。1人で入稿受付から色校正の手配まで回している人。
こういう現場では、ツールを増やす余裕がありません。新しいシステムを入れる稟議も、覚える時間もない。だから「今あるPDFとExcelのまま、確認の抜けだけ減らしたい」が本音だと思います。この記事もそこに寄せます。大げさな基幹システムの話はしません。
印刷会社の入稿〜納品フローを、いったん並べる
任せる場所を決めるには、自分の仕事を工程に割るのが先です。だいたいこうなっているはずです。
| 工程 | やること | 事故が起きやすい所 |
|---|---|---|
| 1. 受注・ヒアリング | サイズ、部数、紙、加工、納期を聞く | 聞き漏れ。後出しの「両面でした」 |
| 2. 見積もり | 部数別の単価、版代、加工費を計算して返信 | 計算ミス、返信の遅れで失注 |
| 3. 入稿受付 | お客さんからデータを受け取る | 旧バージョン入稿、フォント未埋め込み |
| 4. データチェック | 塗り足し、解像度、色、トンボ、文字化け | 見落としによる刷り直し |
| 5. 校正・色校 | お客さんに確認してもらう | OKの言質が曖昧 |
| 6. 製版・印刷・加工 | 実際に刷る | 前工程のミスがここで顕在化 |
| 7. 発送・請求 | 納品して請求 | 数量間違い |
生成AIが効くのは、2の見積もり下書きと、4のデータチェックの一次受けです。5の色校と6以降は機械に渡しません。理由は後で書きます。
よくある手戻りと、その正体
刷り直しになるパターンは、毎回だいたい同じ顔ぶれです。
- 塗り足し(断ち切りの余白)が足りず、裁断後に白が出る
- 画像の解像度が低い。Webから拾った72dpiの写真をそのまま入稿
- 黒ベタがリッチブラックになっていて、版ズレで文字が緑や赤に滲む
- フォントが埋め込まれず、別PCで開くと別の書体に化ける
- RGBのまま入稿され、印刷で色がくすむ
- トンボがない、または仕上がりサイズが指定と違う
厄介なのは、これが全部「ぱっと見では分からない」ことです。人の目で1点ずつ拾うのは可能だけど、金曜の夕方に10件来たら集中力が持ちません。機械が向いている退屈な確認、の典型です。
Use case 1:入稿前の一次チェックを機械にやらせる
人がやると見落とす項目を、チェックリスト化してAIに先に走らせます。狙いは「人の最終確認を、ゼロから全項目見る作業から、AIが赤を付けた所だけ確かめる作業に変える」ことです。
下のチェックリストを、入稿のたびに使い回します。
- 仕上がりサイズが指定と一致しているか
- 塗り足しが上下左右3mm以上あるか
- 配置画像の実効解像度が原寸で300dpi以上か
- カラーモードがCMYKか(RGB混在がないか)
- 文字(特に小さい黒文字)がK100の単色か、リッチブラックになっていないか
- フォントがすべて埋め込み、またはアウトライン化されているか
- トンボ・センタートンボがあるか
- ページ数・面付けの向きが指定通りか
- 透明効果やオーバープリントの意図しない設定がないか
PDFのプロパティやプリフライト結果のテキストをAIに渡し、このリストで照合させると、抜けた行をそのまま指摘してくれます。
Use case 2:見積もり返信の下書きを30秒で作る
見積もりは、計算そのものより「返信を書くのが面倒で後回しになる」ことが失注の原因です。ヒアリング内容を箇条書きで渡すだけで、丁寧な返信文の草案を出させます。
価格表(単価ロジック)は自社のものをAIに教えておきます。計算の最終確認は人がやりますが、文面と項目の並びはAIに任せて構いません。
Use case 3:問い合わせメールから、聞き漏れを洗い出す
お客さんの問い合わせは、たいてい情報が足りません。「名刺を100枚お願いします」だけ来る。ここで「片面/両面は?用紙は?納期は?」を聞き返す質問リストを、AIに先に作らせます。
聞くべきことの抜けが減るので、見積もりのやり直しが減ります。これは地味ですが、往復の回数が1回減るだけで半日早く着地します。
AIに任せる範囲と、人が必ず判断する範囲
ここが一番大事です。線引きを間違えると、AIが「自信満々で間違える」事故になります。
| 作業 | AIに任せる | 人が判断する |
|---|---|---|
| チェックリストの照合 | ○ 抜けを拾う | 最終OKの判断 |
| 解像度・塗り足しの数値読み取り | ○ 数値を並べる | 写真の縁が目立つかの感覚的判断 |
| 見積もり文面の草案 | ○ 文章を書く | 価格の最終決定、値引き判断 |
| 聞き漏れの質問づくり | ○ 一覧化 | お客さんとの関係を踏まえた言い回し |
| 色校正・色の最終判断 | × | ◎ 人の目で必ず |
| 印刷機への送り出し | × | ◎ 人が押す |
色だけは絶対に渡しません。モニタの色とインクの色は別物で、紙や天候でも変わります。ここはベテランの目の仕事です。AIは「データ上の設定がおかしくないか」までで、刷り上がりの良し悪しは判断させない、と割り切ってください。
この線引きの考え方は、エンジニア以外の人がAIをどう使うかを書いたClaude Codeを非エンジニアが使うの話と地続きです。任せる範囲を狭く始めるのがコツです。
コピペで使えるプロンプト雛形
入稿チェックの一次受けに使っているプロンプトです。{ } の中を自分の案件で置き換えてください。
あなたは印刷会社のベテランDTPオペレーターです。
これから渡す入稿データの情報を、下のチェックリストで照合してください。
【案件情報】
- 仕上がりサイズ:A4(210×297mm)
- 用紙・部数:コート90kg / 1000部
- 面:両面カラー
【チェックリスト】
1. 仕上がりサイズが指定と一致するか
2. 塗り足しが上下左右3mm以上あるか
3. 配置画像の実効解像度が原寸300dpi以上か
4. カラーモードがCMYKか(RGB混在がないか)
5. 小さい黒文字がK100単色か(リッチブラックでないか)
6. フォントが埋め込みまたはアウトライン化されているか
7. トンボがあるか
【出力ルール】
- 各項目を「OK / 要確認 / NG」で判定し、理由を一言で添える
- 数値が読み取れない項目は「データ不足」と書き、推測で埋めない
- 最後に、お客さんへ確認すべき質問を箇条書きで出す
「推測で埋めるな」「データ不足はデータ不足と書け」を必ず入れます。これがないと、AIは分からない所をそれらしく埋めて、嘘の安心を返してきます。プロンプトの細かい詰め方はClaude Codeのプロンプト設計(応用)に寄せました。
見積もり返信テンプレ
返信の下書きはこの型に流し込ませます。
{お客様名} 様
お見積もりありがとうございます。下記の通りご提案いたします。
■ 仕様
- 品目:{名刺/チラシ/冊子など}
- サイズ:{サイズ}
- 用紙:{紙種・連量}
- 部数:{部数}
- 加工:{PP/箔/折りなど}
■ 金額(税抜)
- 印刷代:{金額}
- 版・データ調整費:{金額}
- 合計:{金額}
■ 納期
ご入稿確定後 {営業日数} 営業日
データチェックの結果、{確認事項があれば記載}。
ご不明点があればお気軽にお知らせください。
実行できる検証スクリプト
「塗り足しがあるか」を毎回PDFを開いて測るのは面倒です。PDFのページサイズ(MediaBox / TrimBox)を読み、トリムからの余白が3mm以上あるかをざっくり判定するNode.jsスクリプトを置いておきます。pdf-lib を使います。
npm init -y
npm install pdf-lib
node check-bleed.mjs sample.pdf
import { PDFDocument } from "pdf-lib";
import { readFile } from "node:fs/promises";
const PT_PER_MM = 72 / 25.4; // 1mm = 約2.835pt
const MIN_BLEED_MM = 3;
const file = process.argv[2];
if (!file) {
console.error("使い方: node check-bleed.mjs <PDFファイル>");
process.exit(1);
}
const bytes = await readFile(file);
const pdf = await PDFDocument.load(bytes);
pdf.getPages().forEach((page, i) => {
const media = page.getMediaBox();
// TrimBoxが無ければMediaBoxを仕上がりとみなす(塗り足しなしの可能性が高い)
const trim = page.getTrimBox?.() ?? media;
const bleedPt = Math.min(
trim.x - media.x,
trim.y - media.y,
media.x + media.width - (trim.x + trim.width),
media.y + media.height - (trim.y + trim.height)
);
const bleedMm = bleedPt / PT_PER_MM;
const ok = bleedMm >= MIN_BLEED_MM - 0.05;
console.log(
`P${i + 1}: 塗り足し約${bleedMm.toFixed(1)}mm -> ${ok ? "OK" : "要確認"}`
);
});
これで全ページの塗り足しが一覧で出ます。「要確認」が出たページだけ、人がIllustratorで開いて見ればいい。ゼロから全ページ測るより圧倒的に速いです。このスクリプトはあくまで一次フィルタで、最終判断は人がする前提です。コマンド操作に不慣れならClaude Code導入ガイドから始めると詰まりにくいです。
導入の前と後で、何が変わったか
数字でざっくり書きます。あくまで僕の周りの小規模印刷の体感値です。
| 項目 | 導入前 | 導入後 |
|---|---|---|
| 入稿1件のチェック時間 | 約15分 | 約6分(赤の所だけ確認) |
| 見積もり返信の作成 | 約12分 | 約3分(草案を直すだけ) |
| 聞き漏れによる往復 | 案件の3割 | 1割未満 |
| 刷り直し | 月1〜2回 | ほぼゼロを狙える |
時間の浮きをROIにすると、1日20件の見積もりで返信が9分短くなれば、1日3時間、月60時間規模。控えめに見ても月20時間は固い。さらに刷り直しを1回防げば、紙・インク・機械の段取りで数万円が消えずに済みます。新しいソフトを買っていないので、浮いた時間がそのまま利益側に乗ります。
セキュリティと個人情報の注意点
ここを飛ばすと、効率化どころか信用を失います。印刷会社が扱うデータは、ほぼ全部が他人の機密です。
- 名刺・DMには氏名、住所、電話番号など個人情報が載る。会員名簿の印刷ならなおさら重い。
- 新商品のチラシは、発売前の未公開情報。漏れたら取引停止もある。
- だからAIに渡すのは「サイズ・解像度・色設定・塗り足し」などの体裁データに限り、本文の個人情報や商品名は伏せ字にしてから渡す。
- 検証スクリプトのようにローカルで完結する処理は、データを外に出さないので安心度が高い。重い個人情報はこちらで処理する。
- 外部のAIサービスに送る場合は、入力が学習に使われない設定か、契約上どう扱われるかを必ず確認する。社内ルールを1枚作っておく。
線引きはシンプルです。「お客さんに見せて怒られないデータか」を渡す前に自問する。迷ったら渡さない。社内で何をAIに見せてよいかのルール作りは、CLAUDE.mdの書き方の考え方が応用できます。プロジェクトごとの約束事をファイルに書いておく発想です。
PDFの技術仕様そのものを正しく押さえたい人は、Adobeの公式情報(Adobe公式サイト)など一次情報を当たってください。塗り足しやトンボの推奨値は印刷会社ごとに違うので、自社の入稿規定が最優先です。
よくある質問
Q. AIが「OK」と言ったデータをそのまま刷っていいですか。 だめです。AIの判定は一次フィルタです。特に色と、写真の縁の見え方は人の目で必ず確認してください。AIは「データ上の設定の抜け」を拾うだけで、刷り上がりの責任は持てません。
Q. うちのオペレーターはコマンドが苦手です。検証スクリプトは必須ですか。 必須ではありません。チェックリストとプロンプトだけでも効果はあります。スクリプトは「塗り足しを毎回測るのが面倒」という人向けの追加装備です。まずプロンプトから始めてください。
Q. お客さんの個人情報をAIに読ませて大丈夫ですか。 原則だめです。体裁データ(サイズ・解像度・色)だけ渡し、氏名や住所は伏せます。本文を読ませたい場合は、外部送信されないローカルの仕組みを使うか、ダミーに置き換えてから渡してください。
Q. 見積もりの金額もAIに決めさせていいですか。 金額の最終決定は人がします。AIは自社の価格表に沿って草案を作るだけ。値引きや特急料金の判断は、関係性を知っている人にしかできません。
Q. 導入に何日かかりますか。 チェックリストと返信テンプレを整えるだけなら半日です。プロンプトを自社の入稿規定に合わせて1〜2週間運用しながら直すと、判定の精度が現場に馴染みます。
まとめ:判断は手放さず、退屈だけ手放す
入稿チェックも見積もりも、面倒なのは「判断」より「拾い出しと書き起こし」です。そこをAIに肩代わりさせ、人は赤の付いた所と、色と、価格だけを見る。役割をこう割り直すと、金曜の夕方でも事故が減ります。
会社全体で入稿の止め方や担当の役割を見直したいなら、研修・相談で現場のフローに合わせた組み立てを一緒に詰められます。まず自分の手元で試したい人は無料PDF・教材から、チェックリストとプロンプトを持ち帰ってください。
実際に試した結果
手元のサンプルPDFを数本用意して、上の検証スクリプトを回しました。塗り足し0mmで作った1枚は「P1: 塗り足し約0.0mm -> 要確認」と正しく拾い、3mmで作った版はちゃんと「OK」が出ました。MediaBoxしか持たないPDFは塗り足しなしと判定されるので、TrimBoxを持つ書き出し(トンボ付きPDF/X)でないと正確に測れない、という限界もその場で見えました。
入稿チェックのプロンプトには、わざと「解像度が読み取れない情報」を混ぜて渡してみました。指示通り推測で埋めず「データ不足」と返したのが収穫です。逆に、リッチブラックかどうかは渡したテキスト情報だけでは判定しきれず、ここは結局Illustratorを開いて人が見る必要がありました。AIに渡せる所と、目で見るしかない所の境目が、回してみて初めてくっきりしました。最初から全部任せようとせず、退屈な拾い出しだけ渡す。この距離感が、印刷会社の現場にはちょうどよさそうです。
無料PDF: Claude Code はじめてのチートシート
まずは無料PDFで基本コマンドと最初の使い方をまとめて確認してください。登録後はそのままテンプレート集や導入相談にも進めます。
スパムは送りません。登録情報は厳重に管理します。
Claude Codeを仕事で使える形にしませんか?
まず無料PDFで基本を固め、繰り返し使う作業はGumroad教材へ、チーム導入や権限設計は導入相談へ進めます。
この記事を書いた人
Masa
Claude Codeの実務活用、導入設計、収益導線改善を検証しているエンジニア。10言語の技術メディアを運営中。
関連書籍・参考図書
この記事のテーマに関連する書籍を楽天ブックスで探せます。
※ 当サイトは楽天市場のアフィリエイトプログラムに参加しています。上記リンクから商品をご購入いただくと、運営者に紹介料が支払われる場合があります。
関連記事
制作会社がClaude Codeに触らせる前に決める権限チェックリスト
クライアントサイトを壊さずにAI編集を使うための、制作会社向け権限と確認の型です。
SaaSサポートのバグ報告をClaude Codeで再現手順に変える実務フロー
問い合わせ文をそのまま開発へ投げず、再現手順、証拠、次の一手に整えるサポート向け手順です。
Obsidianの古いメモをClaude Codeの指示書に変える10分ルーチン
Obsidianに溜めたメモが毎回ゴミになる人へ。事実・決定・未確認に仕分けして、Claude Codeがそのまま動ける指示書に変える朝の10分の型を紹介します。