印刷会社が刷り出しの写真を Gemini で入稿のデータと見比べ、汚れ・見当ずれ・色の差・文字の違いの候補を拾って検品の記録を作る
刷り出しのたびに観察台で撮った用紙の写真を、入稿のデータから作った見本の画像と区画ごとに並べて Gemini API で見比べます。汚れ・見当ずれ・色の差・文字の違いの候補を枠つきで拾い、台ごとの検品の記録の下書きを作ります。
- 生成AI
- ChatGPT/Claude/Gemini
- 連携・自動化
- Google Apps Script/Python
- 対象業界
- 広告/製造
- 対象部門
- 品質管理/生産
- 対象業務
- 内容確認・チェック/記録・議事録作成
- 主な課題
- 属人化している/書類作成に時間がかかる/確認ミスが多い
- AIで行う処理
- 画像認識
- 主な効果
- 入力漏れ削減/品質標準化/工数削減
- 導入難易度
- ★★★☆☆
- 実装レベル
- 本格構成
- 費用感
- API連携(中)
- 人間の確認
- 条件付き
01導入前 / 導入後の業務フロー
- オペレーターが刷り出しを観察台に置き、校正紙と面付けの指示書を並べる
- 品質管理の担当が全面を見渡し、気になる所にルーペを当てて汚れ・こすれ・版の欠けを探す
- 見当マークをルーペで見て、色の版のずれを確かめる
- 校正紙と文字や絵柄を見比べ、差し替えた所が新しい版になっているかを確かめる
- オペレーターが濃度計で色を測り、校正紙との見た目の差を確かめて調整する
- 本刷りに進めると決めたら、検品の記録の用紙に項目のレ点、気づき、測った値を書き、印を押す
- 記録の用紙を仕事の袋に入れ、月末に品質管理の担当がつづる
- 人オペレーターが刷り出しを観察台に置き、上に付けたカメラで全面を撮る
- 自動サーバーが生産の管理の仕組みから仕事の番号と台を引き、面付けのPDFから見本の画像を作る
- 自動写真の傾きと大きさを見本にそろえ、紙面を区画に分け、見当マークの所を切り出す
- 自動Gemini API が、区画ごとに見本と写真を見比べ、汚れ・色の差・文字の違いの候補と枠、見比べられない区画を返す
- 自動見当マークの切り出しを見せ、ずれて見える色の版を返させる
- 自動サーバーが候補に印を描き、台ごとの検品の記録の下書きを作る
- 人品質管理の担当が、印の所にルーペを当てて確かめ、「該当」「該当なし」を選ぶ
- 人オペレーターが濃度計で色を測り、値を記録の画面に入れ、2人で本刷りに進めるかを決める
- 自動決めた結果と測った値を検品の記録に書き、仕事の番号でつづる
各工程の詳しい説明を読む
- オペレーターが刷り出しを観察台に置き、校正紙と面付けの指示書を並べる
- 品質管理の担当が全面を見渡し、気になる所にルーペを当てて汚れ・こすれ・版の欠けを探す
- 見当マークをルーペで見て、色の版のずれを確かめる
- 校正紙と文字や絵柄を見比べ、差し替えた所が新しい版になっているかを確かめる
- オペレーターが濃度計で色を測り、校正紙との見た目の差を確かめて調整する
- 本刷りに進めると決めたら、検品の記録の用紙に項目のレ点、気づき、測った値を書き、印を押す
- 記録の用紙を仕事の袋に入れ、月末に品質管理の担当がつづる
(a)見る所が人によって違う。 2番目と4番目は、全面を等しく見る作業ではありません。ベテランは誤りの出やすい所を知っていて、そこから見ます。 その順番は言葉になっておらず、若い担当は大きな絵柄から見ます。
(b)差し替えの漏れが隅で起きる。 お客様の直しで1ページだけ版を作り直したとき、古い版のまま刷ってしまう誤りは、直した所が小さな文字ほど見つかりません。 刷り上がって折った後に見つかると、刷り直しになります。
(c)汚れは区画の端で見落とす。 インキの小さな汚れ(ヒッキー)やこすれは、ルーペを当てた所でしか見えません。菊全の紙面を全部ルーペでなぞる時間はありません。
(d)何を見たかが残らない。 記録の用紙のレ点は「汚れを見た」という項目で、どの区画を見たかは残りません。 後で問い合わせが来ても、見たのに見落としたのか、見ていなかったのかが分かりません。
- 【人】 オペレーターが刷り出しを観察台に置き、上に付けたカメラで全面を撮る
- 【自動】 サーバーが生産の管理の仕組みから仕事の番号と台を引き、面付けのPDFから見本の画像を作る
- 【自動】 写真の傾きと大きさを見本にそろえ、紙面を区画に分け、見当マークの所を切り出す
- 【自動】 Gemini API が、区画ごとに見本と写真を見比べ、汚れ・色の差・文字の違いの候補と枠、見比べられない区画を返す
- 【自動】 見当マークの切り出しを見せ、ずれて見える色の版を返させる
- 【自動】 サーバーが候補に印を描き、台ごとの検品の記録の下書きを作る
- 【人】 品質管理の担当が、印の所にルーペを当てて確かめ、「該当」「該当なし」を選ぶ
- 【人】 オペレーターが濃度計で色を測り、値を記録の画面に入れ、2人で本刷りに進めるかを決める
- 【自動】 決めた結果と測った値を検品の記録に書き、仕事の番号でつづる
7番目と8番目が、この設計の分かれ目です。 AIが返すのは見比べの候補までで、本刷りに進めるか、色が許されるかは2人が決めます。 担当の時間は、紙面を見渡してルーペを当てる場所を探す作業から、印の付いた所を確かめる作業に移ります。
3番目で紙面を区画に分けるのも、意図してのことです。 紙面全体を1枚で渡すと、細かい汚れは見えません。区画ごとに見本と並べて答えさせ、全部の区画に答えがあることを記録に残します。
02今回想定するシステム構成
刷り出し(観察台の上のカメラで全面を撮る) ▼【トリガー】撮影のボタン Python のサーバー ├── 生産の管理の仕組みから仕事の番号・台・面付けを引く ├── 面付けのPDFから見本の画像を作る ├── 写真の傾き・大きさを見本にそろえる、区画に分ける、見当マークを切り出す ▼ Gemini API(画像の理解・構造化出力)── 区画ごとの見本と写真の組 │ 汚れ・色の差・文字の違いの候補と枠、見比べられない区画、見当のずれ ▼ Python ── 区画の数の確認、写真に印を描く、検品の記録の下書き ▼ 【人】品質管理の担当がルーペで確かめる + オペレーターが濃度計で測る ▼ 検品の記録(仕事の番号でつづる)
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| 処理 | Gemini API(区画ごとに見本と刷り出しの写真を見比べ、候補と見比べられない区画、見当のずれを返す) | Claude API、OpenAI API |
| 連携 | Python(写真の受け取り、見本の画像の作成、傾きの補正と区画の切り分け、呼び出し、印の描画、記録の組み立て) | Google Apps Script |
| 撮影 | 観察台の上に固定したカメラ | - |
| 生産の情報 | 生産の管理の仕組み(仕事の番号・台・面付けの読み取りだけ) | - |
新しく足すのは、観察台のカメラ、Python のサーバー、Gemini API の契約です。 生産の管理の仕組みと面付けのPDFは今のものを読むだけにします。印刷機の紙面の検査の装置は、この構成と別の選び方です。 装置を付けられる機械なら、そちらが刷り出しから本刷りまでを見ます。この構成は、装置の無い機械で、刷り出しの検品と記録を補うものです。
写真を見る土台は、Gemini API の画像の理解です。 公式の案内では、対応する形式は PNG、JPEG、WEBP、HEIC、HEIF で、画像を直接入れる場合は、指示の文や画像を合わせたリクエスト全体が20MBまでです。1回のリクエストに入れられる画像は最大3,600枚とされていますが、区画の画像は大きめに残したいので、数区画ずつに分けて呼びます。
位置は枠で返させます。 枠は [ymin, xmin, ymax, xmax] の順で、画像の大きさに対して0〜1000に正規化され、元の大きさに戻して使うよう案内されています。サーバーは区画の中の枠を紙面全体の位置に直し、写真に印を描きます。
細かい所を見るには、media_resolution を上げます。 公式の案内では、この設定は画像1枚あたりのトークンの上限を決め、高い値は細かい文字や小さな部分を読むのに向く一方、トークンと待ち時間が増えるとされています。
出力は構造化出力で受けます。 /v1beta/interactions に送り、response_format で mime_type を application/json にし、schema にスキーマを入れます。文字列の enum、配列の minItems・maxItems が使えます。一方で minLength・maxLength は効かず、エラーにならずに外されるとされているので、文の長さはサーバーで見ます。値が正しいかはアプリ側で検証するよう公式に書かれています。
03どうやって実装するのか
処理の起点を決める
オペレーターが観察台の撮影のボタンを押したときに、その台の分が動きます。 ボタンの前に、生産の管理の仕組みの画面で仕事の番号と台(表・裏)を選びます。選ばずに撮ると、見本の画像を作れないので、撮影をはねます。
本刷りの途中の抜き取りでも、同じボタンで動かせます。 抜き取りのときは見本ではなく、本刷りに進めると決めた刷り出しの写真と見比べます。最初の見本との違いではなく、刷っている間に出た変化を見るためです。
結果はその場で出るように作ります。 印刷機が止まっている間に待たせないよう、区画の呼び出しは並べて送り、返った区画から画面に出します。 全部の区画が返る前に担当が確かめ始められる形にします。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 刷り出しの写真 | 観察台の上のカメラで撮った全面。撮った時刻と機械の番号 | 観察台のカメラ |
| 見本の画像 | 面付けのPDFから作った、刷り出しと同じ向きと大きさの画像 | 面付けのPDFの置き場 |
| 仕事の情報 | 仕事の番号、台(表・裏)、使う色の版(4色、特色)、用紙、刷る順 | 生産の管理の仕組み |
| 直しの記録 | お客様の直しで版を作り直したページと、直した所 | 生産の管理の仕組み、または製版の担当の記録 |
| 区画の割り方 | 紙面を何行何列に分けるか、見当マークの位置 | サーバーに持たせる(面付けごと) |
| 候補の種類の一覧 | インキの汚れ、こすれ、版の欠け、文字の違い、絵柄の違い、色が違って見える所、見当がずれて見える所 | サーバーに持たせる |
質を決めるのは、写真の撮り方です。 観察台の照明を毎回同じにし、カメラの位置と設定(露出、ホワイトバランス)を固定します。光沢のあるコート紙は照明が映り込むので、映り込みの出ない照明の角度を最初に決めます。 撮り方がぶれると、色の差の候補が照明の違いを拾います。
直しの記録は、文字の違いを見るときの手がかりになります。 直したページの区画は、AIへの指示の文に「この区画は直しのある所」と書き添えます。直した所が見本どおりかどうかを、他の区画より先に担当に見せます。 第3章の(b)を防ぐのは、ここです。
データの取得方法を決める
仕事の情報と直しの記録は、生産の管理の仕組みから読みます。 書き出しの機能かAPIがあればそれを使い、無ければ毎朝の書き出しを読みます。つなぎ方は、使っている製品が出せる形式に合わせて個別に作ります。
見本の画像は、面付けのPDFからサーバーが作ります。 刷り出しの向きと合わせ、トンボの位置が写真のトンボと重なるよう大きさをそろえます。見本は印刷用の色をそのまま画面の色に直しただけのものなので、色は参考です。 校正紙の色と同じではありません。
写真の傾きは、紙面の四隅のトンボを手がかりに直します。 Python の画像処理のライブラリで、写真のトンボと見本のトンボの位置を合わせ、写真を見本の形にそろえます。そろえた後で、同じ割り方で写真と見本を区画に切り分けます。
Gemini API へは、区画ごとに見本と写真を1組ずつ並べて渡します。 1回の呼び出しには数区画を入れ、区画の番号と「直しのある所」かどうかを添えます。見当マークは、各色の版のマークを切り出した画像を別の呼び出しで渡します。
有料の利用枠で使い、store を false にします。 Gemini API の規約では、有料のサービスではプロンプトと応答が製品の改善に使われないとされています。Interactions API は既定でやり取りを保存し(有料の枠で55日、無料の枠で1日)、store=false で保存しない動きにできると案内されています。store=false にすると前の回のやり取りを引き継ぐ使い方はできないので、呼び出しは毎回、必要な見本と写真をそろえて送ります。
AIへ渡す前に整形する
- 傾きと大きさの補正 … 四隅のトンボで、写真を見本の形にそろえます。トンボが見つからない写真は、撮り直しにします
- 区画の切り分け … 面付けごとの割り方で、写真と見本を同じ区画に分けます。隣の区画と少し重ねて切り、区画の境目の汚れを落とさないようにします
- 見当マークの切り出し … 見当マークの位置を、写真と見本の両方から大きめに切り出します
- 映り込みとぶれの確認 … 照明が白く飛んだ区画、ぼけた区画は、AIに渡さずに「見比べられない区画」として記録します
- 大きさの確認 … 1回分の区画の画像と指示の文を合わせて20MBを超えないかを見ます。超えるときは区画の数を減らして呼びます
- 区画の情報の付け足し … 区画の番号、そのページの番号、直しのある所かどうかを指示の文に入れます
4番目を軽く見ないでください。 映り込みで白く飛んだ区画では、汚れも文字も見えません。AIは見えない区画を「違いなし」と返しがちで、それがいちばん危ない見落としです。 前処理で見比べられない区画をはじき、検品の記録に「見比べられない区画」として残します。
AIに処理させる
させるのは、区画ごとに見本との見比べの結果を返すこと、候補を枠で返すこと、見当マークのずれて見える色の版を返すことだけです。
| 返すもの | 中身 | 判断できないときの扱い |
|---|---|---|
| 区画ごとの状態 | 区画の一覧の1つずつに no_difference_looking(違いが見えない)/candidates(候補あり)/not_comparable(見比べられない) | 映り込み・ぼけがあれば not_comparable |
| 候補 | 区画の番号、枠、種類、見え方の短い説明 | 汚れか紙の地合いか分からなければ unclear |
| 文字の違い | 見本と写真で文字が違って見える所と、両方の読み取り | 小さすぎて読めなければ unclear |
| 見当のずれ | 色の版ごとに aligned_looking/shifted_looking/not_visible | マークが写っていなければ not_visible |
区画ごとに no_difference_looking と not_comparable を分けて返させるのが、この構成の要です。 見比べられなかった区画を「違いが見えない」と同じに扱うと、第3章の(d)がそのまま残ります。 not_comparable が残る台は、サーバーが記録の下書きの先頭に「ルーペで見る区画」として並べます。
文字の違いは、両方の読み取りを並べて返させます。 「見本:2026年11月1日(土)」「写真:2026年10月1日(水)」のように並べれば、担当は印の所にルーペを当てる前に、直しの漏れかどうかの見当がつきます。 直しのある区画で文字の違いが出たら、サーバーは担当の画面のいちばん上に出します。
| させないこと | 理由 |
|---|---|
| 刷り出しの合否、本刷りに進めるかの判断 | オペレーターと品質管理の担当が、お客様の基準と見比べて決める |
| 色の濃度や色差を数字で書くこと | 写真の色は照明とカメラで変わる。測るのは濃度計と測色計 |
| 見当のずれの量を数字で書くこと | 写真の解像度で変わる。必要ならルーペの目盛りで測る |
| インキの量や機械の調整の方法を書くこと | オペレーターの仕事で、AIの見立てに寄せない |
| 文字の誤りを直して書くこと | 見本と違うことだけを返す。見本自体の誤りは別の工程 |
2行目がいちばん起きやすい失敗です。 色が違って見える区画を見せると、AIは「マゼンタが約10%強い」のように書きたがります。その数字が検品の記録に残ると、測っていない値が測ったように読めます。 返すのは「見本より赤みが強く見える」のような見え方までにし、値はオペレーターが濃度計で測ったものだけを記録します。
指示内容を固定する
あなたは印刷会社で、刷り出しの写真を見本の画像と見比べる手伝いをする係です。
これから区画ごとに、左に見本(入稿のデータから作った画像)、右に刷り出しの写真を
1組ずつ渡します。見本の色は参考で、校正紙の色ではありません。
【区画の一覧】
{A1(p.1 右上), A2(p.1 右下), B1(p.16 左上・直しのある所), ...}
【やること】
1. 区画の一覧の1つずつについて、no_difference_looking / candidates /
not_comparable のどれかを選ぶ。一覧にない区画を足さない。一覧の区画を飛ばさない。
2. 次の種類の候補を探し、写真の側の枠を [ymin, xmin, ymax, xmax] の順で、
0〜1000 に正規化して返す。種類と見え方を短く書く。
インキの汚れ、こすれ、版の欠け、文字の違い、絵柄の違い、
見本と色が違って見える所
3. 文字の違いは、見本の読み取りと写真の読み取りを両方書く。
4. 直しのある所と書かれた区画は、文字と絵柄の違いを特に細かく見る。
【厳守事項】
- 映り込みやぼけで見比べられない区画を no_difference_looking にしないでください。
not_comparable にしてください。
- 汚れか紙の地合いか分からないもの、小さくて読めない文字は kind を unclear にしてください。
- 色の濃さや差を数字やパーセントで書かないでください。
「見本より赤みが強く見える」のように見え方だけを書いてください。
- 合格・不合格、本刷りに進めてよいか、機械の調整の方法を書かないでください。
- 文字を正しく直して書かないでください。見えたとおりに写してください。
「一覧の区画を飛ばさない」「見比べられない区画を no_difference_looking にしない」を並べているのは、どちらも同じ失敗を防ぐためです。 何も言わないと、AIは候補のあった区画だけを返し、残りの区画について何も言いません。 その沈黙をサーバーが「違いなし」と読むと、見ていない隅が記録に「確認済み」と載ります。
「見本の色は参考」と最初に書いているのは、色の候補を出しすぎないためです。 見本の画像と刷り出しの写真は、もともと色の出方が違います。それを言わないと、全部の区画が「色が違って見える」になります。 色の候補は、区画の中で一部だけ色が違って見える所(隣の区画と比べて目立つ所)に絞らせます。
見当マークは別の指示で呼びます。 色の版ごとのマークを切り出した画像を渡し、「各色のマークの線が重なって見えるか、ずれて見えるか、写っていないかを、色の版ごとに選ぶ。ずれの量は書かない」と指示します。
出力形式を固定する
1回の呼び出しごとに、次の形の JSON で受け取ります。 status、kind は enum で決まった文字列に絞り、zones は渡した区画と同じ数を minItems・maxItems で求めます。
{
"job_id": "P-26-4417",
"sheet": "第2台 表",
"zones": [
{ "zone": "B1", "status": "no_difference_looking | candidates | not_comparable" }
],
"findings": [
{ "zone": "B1", "box_2d": [612, 140, 655, 470],
"kind": "ink_spot | scuff | plate_defect | text_diff | image_diff | color_diff_looking | unclear",
"note": "日付の行が見本と違って見える",
"text_ref": "2026年11月1日(土)", "text_print": "2026年10月1日(水)" }
],
"registration": [ { "plate": "C | M | Y | K", "status": "aligned_looking | shifted_looking | not_visible" } ]
}
1つ目の理由は、zones をそのまま「見た区画の記録」にできることです。 区画の数がそろっていなければサーバーが呼び直し、not_comparable の区画は、担当がルーペで見る一覧に自動で入ります。
2つ目は、text_ref と text_print を並べて担当に見せられることです。 文字の違いは、ルーペを当てる前に読めます。直しのある区画の文字の違いは、本刷りに進む前に必ず担当が見る項目にします。
3つ目は、検品の記録をそのまま組み立てられることです。 担当とオペレーターが確かめた結果と、濃度計の値を足して、次のような台ごとの記録にします。
| 項目 | 記録 |
|---|---|
| 見た区画 | 24区画(AIの見比べ 22、ルーペで見た not_comparable 2) |
| 候補と確かめた結果 | 汚れ 1(該当・拭き取り後に再刷り出し)、文字の違い 1(該当・版の差し替え)、色 2(該当なし) |
| 見当 | C・M・Y・K とも重なって見える(ルーペで確認) |
| 測った値 | オペレーターが濃度計で測った値(AIの値は載せない) |
| 判断 | 再刷り出し後に本刷りへ(担当・オペレーターの名前と時刻) |
システムへ連携する
| つなぎ先 | 方式 | 内容 |
|---|---|---|
| 観察台のカメラ | サーバーが受け取る | 刷り出しの写真、撮った時刻、機械の番号 |
| 生産の管理の仕組み | 読み取り | 仕事の番号、台、色の版、面付け、直しの記録 |
| 面付けのPDFの置き場 | 読み取り | 見本の画像のもと |
| Gemini API | API呼び出し(/v1beta/interactions、store=false) | 区画ごとの見比べ、見当のずれ |
| 検品の記録 | 書き込み | 確かめた結果、測った値、判断、担当の名前 |
生産の管理の仕組みへは書き込みません。 本刷りに進めたかどうかは、今までどおりオペレーターが仕組みに入れます。AIの結果から機械の工程を進める経路は作りません。
検品の記録は、仕事の番号でつづります。 紙の用紙をつづる作業はなくなり、お客様から問い合わせがあったときは、仕事の番号で台ごとの記録と写真を開けます。
人が確認する
- 直しのある区画の文字の違いを先に見る … 版の差し替えの漏れかどうかを、ルーペと直しの記録で確かめます
not_comparableの区画をルーペで見る … 見比べられなかった区画は、人の目で見たことを記録します- 汚れ・こすれ・欠けの候補を確かめる … 印の所にルーペを当て、「該当」「該当なし」を選びます
- 色の候補と見当を確かめる … オペレーターが濃度計で測り、校正紙と見比べます
- 本刷りに進めるかを2人で決める … 判断と名前を記録に残します
1番目を後回しにしないでください。 文字の違いは、本刷りに進んでから見つかると刷り直しになります。汚れは拭き取りや再刷り出しで直せますが、版の取り違えは版を作り直すまで刷れません。
目標は、480台をならして1台3分です。 撮る作業に1分、印の所を確かめる作業に2分という想定です。区画の多いカタログの台は、候補が多く5分を超えます。
例外に対処する
| 起きること | 対応 |
|---|---|
| 四隅のトンボが写真に見つからない | 撮り直す。2回見つからなければ従来どおりルーペで全面を見る |
| 映り込みやぼけの区画が多い | 照明とカメラの設定を見直す。その台は not_comparable をルーペで見る |
区画の一覧と zones の数が合わない | 呼び直す。2回合わなければ担当が全面を見る |
| 面付けのPDFが最新の版でない | 直しの記録の日付と比べ、古ければ見比べを止めて製版の担当に確かめる |
| 特色や白インキで見本の色が出ない | その色の区画は色の候補を出さず、汚れと文字だけを見る |
| 指示に反して色の数字や合否を書いた | その出力を保存せずに捨て、呼び直す |
JSON の値が enum に無い | 候補を出さず、担当が全面を見る |
| API が応答しない・時間がかかる | 待たずに従来どおりルーペで見る。写真は残し、後で見比べて記録に足す |
上から2行目までが大半を占めます。 どれもAIの精度の問題ではなく、撮り方と照明の問題です。 4行目は、見本そのものが古いと、AIは正しく「違いなし」と返しても誤りを見逃すことになるので、見本の版を確かめる手順を前に置きます。 8行目のとおり、印刷機を止めて結果を待たせないことを優先します。
記録を残す
- 刷り出しの写真と、作った見本の画像、区画の切り分けの結果
- Gemini API に渡した区画と指示、返った JSON
- 候補ごとに担当が付けた「該当」「該当なし」と、ルーペで見た
not_comparableの区画 - オペレーターが測った値、本刷りに進めた判断、担当とオペレーターの名前と時刻
- そのときの面付けのPDFの版と、直しの記録
3つ目が、撮り方と指示を直す材料になります。 「該当なし」が多い候補の種類(紙の地合いを汚れと言う、など)を数えると、指示の文と照明のどちらを直すべきかが分かります。機械ごとの汚れの件数も出せますが、オペレーターの評価に使うかは、別に話し合って決めます。
04実装レベルの3段階
最小構成では台数がさばけません。 区画を手で切って貼るので、刷り出しの場では使えません。確かめるための段階です。 半自動化で、1台7分が5分程度になります。 ルーペを当てる場所を探す作業は減りますが、見当マークの確認と記録の記入が手作業で残ります。 本格構成で3分になり、この段階が本記事の想定です。 段階を飛ばさないでください。 半自動化の記録を1か月見ると、どの面付けで not_comparable が多いか、どの候補を担当が外すことが多いかが分かります。
05工数削減シミュレーション
導入後 480件 × 3分 ÷ 60 = 24 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 枚葉のオフセット印刷機を数台持ち、チラシ・パンフレット・カタログの仕事を月に数百台刷っている印刷会社。刷り出しのたびにオペレーターや品質管理の担当がルーペで校正紙と見比べ、手書きの検品の記録を残している場合。版の差し替えの漏れや文字の違いが刷り上がった後に見つかることがある場合。印刷機に紙面を検査する装置が付いていない場合。
- 印刷機に紙面の検査の装置があり、刷り出しの見比べと記録がすでに機械で残っている場合。刷る仕事が月に数十台で、ベテランの目で足りる場合。色を数値で管理する仕事が中心で、写真の見た目の比べが役に立たない場合。開示前の決算の資料や試験問題のように、社外のサービスに画像を出せない仕事。なお、刷り出しの合否、色が許される範囲かの判断、お客様の色の承認は、この構成では代替できません。
07最小構成で試す方法
- 先月の刷り出しから20台を選ぶ(うち数台は、刷り上がった後に誤りが見つかった仕事を入れる)
- その20台について、当時の検品の記録と、後で見つかった誤りを書き出す
- 保管してある刷り出しを観察台で撮り、面付けのPDFから見本の画像を作り、区画ごとに切って手元の Gemini の画面に貼り付ける
- 「左の見本と右の写真を見比べて、インキの汚れ、こすれ、版の欠け、文字の違い、絵柄の違いを探してください。文字の違いは両方の読み取りを書いてください。見比べられない区画はそう答えてください。色の数字と合否は書かないでください」と指示する
- 出てきた候補を、当時の記録と後で見つかった誤りと突き合わせる
20台は必ずやってください。 サーバーを作る前に、「今の観察台で撮った写真から、見比べの候補が返せるのか」を確かめます。
| 出てきた内容 | 判断 |
|---|---|
| 後で見つかった誤りが候補か「見比べられない」に出た | サーバーと区画の切り分けの作成に進む |
| 見比べられない区画を「違いなし」と答えた | 指示の書き方で直る。構成は有効 |
| 映り込みで文字が読めない区画が多い | 照明と撮り方が先。 AIの問題ではない |
3行目が出ることは珍しくありません。 失敗ではなく、観察台の照明の映り込みが、人の目の見落としにも効いていたと分かったということです。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 見比べられない区画が「違いなし」に紛れる | 区画の一覧を渡して区画ごとに答えさせ、not_comparable を分ける |
| 映り込みで白く飛ぶ | 照明の角度を決め、前処理で飛んだ区画をはじく |
| 全区画が「色が違って見える」になる | 見本の色は参考と指示に書き、区画の中で目立つ所だけに絞らせる |
| 色の濃さを数字で書く | 指示で禁じ、note に数字や%が入っていないかをサーバーで見る |
| 見本が古い版のまま | 直しの記録の日付と面付けのPDFの版を先に比べる |
| 区画の境目の汚れを落とす | 隣の区画と少し重ねて切る |
| 傾きの補正がずれる | 四隅のトンボで合わせ、見つからなければ撮り直す |
| 結果を待って印刷機が止まる | 区画を並べて呼び、返った区画から画面に出す。遅ければ従来の見方に戻す |
| 文字の違いを直して書く | 見えたとおりに写させ、見本と写真の読み取りを並べる |
| 汚れの件数がオペレーターの評価になる | 人について書かせず、評価に使うかは別に決める |
上の2行が、この構成の失敗のほとんどです。 どちらも「見えなかった」を「違いが無かった」と読むことから出ています。見比べられない区画を、違いなしとは別の答えとして返させることが、指示と規則の両方で守る線です。
5行目も早く効いてきます。 見本そのものが古ければ、AIが正しく見比べても誤りは止まりません。
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: お客様の入稿のデータ、面付けのPDF、刷り出しの写真です。発売前の商品のカタログ、公開前のキャンペーンのチラシ、価格の改定の告知など、公開の日まで外に出せない内容が含まれます。
- お客様との取り決めを先に確かめる … 入稿のデータと刷り出しを社外のサービスに出してよいかは、お客様との契約や秘密の取り決めによります。 出せない仕事は、生産の管理の仕組みで印を付け、この構成に流さず従来の見方で検品します
- 出せない仕事を決めておく … 開示前の決算の資料、株主総会の招集の通知、試験の問題のように、公開前に漏れると取引や試験に関わる仕事は、最初から対象から外します
- この構成は品質の判断を代替しません … 刷り出しの合否、色が許されるか、本刷りに進めるかは、オペレーターと品質管理の担当がお客様の基準と見比べて決めることです。 この構成が出すのは、写真で見比べた候補だけです
- 測っていない値を記録に残さない … 色の数字はオペレーターが測った値だけを記録します。AIの見え方の説明を、測った値の欄に入れません
- 使うのは社内の担当だけにする … AIの結果を見るのは品質管理の担当とオペレーターだけです。Gemini API の規約は、18歳以上であることを利用の条件とし、18歳未満の人に向けた、または使う見込みのあるアプリでの利用を認めていません。お客様がAIに触れる画面は作りません
- AI側にやり取りを残さない … 有料の利用枠で使い、
store=falseを付けます。写真と見本は社内のサーバーに残し、見られる人を品質管理と生産の担当に限ります
誤りが起きた場合のリスクは、誤りのある刷り出しを本刷りに進めることと、問題の無い所で機械を止めて刷り出しをやり直すことの2つです。 前者は見比べられない区画を「違いなし」と扱うと起き、後者は色の候補を測らずに信じると起きます。どちらも、見え方と判断を分けることから外れたときに起きるので、そこを設計で守ります。
10まず何から始めるか
1週目:撮り方と対象から外す仕事を決める
観察台にカメラを仮に固定し、映り込みの出ない照明の角度と、露出・ホワイトバランスの設定を決めます。あわせて、社外のサービスに出せない仕事の種類を書き出し、生産の管理の仕組みで印を付ける決まりを作ります。
2週目:20台で試す
先月の刷り出しから20台を撮り、区画に切って手元の Gemini の画面に貼って見比べさせます。見比べられない区画を「違いなし」と答えていないか、色の数字を書いていないかを最優先で見ます。
3週目:区画の割り方と見本の作り方を決める
よく使う面付けごとに、何行何列に切るか、見当マークがどこにあるかを表にします。面付けのPDFから見本の画像を作り、トンボで写真とそろえる処理を作ります。
4週目:まとめて見比べる
撮った写真をサーバーが補正して区画に切り、まとめて API に渡して印の付いた写真を出すところまで作ります。この時点では記録の下書きを出さず、担当のルーペの確認と並べて見ます。
2か月目: 撮影のボタンのトリガーと、直しのある区画の優先、見当マークの見比べを足します。3か月目以降: 検品の記録の下書きと仕事の番号でのつづりを足し、1台7分が何分になったかを実測します。刷り上がった後に見つかった誤りを、区画ごとの記録と並べて見直すようになった時点で、この構成は完成です。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
対応する画像の形式が PNG・JPEG・WEBP・HEIC・HEIF であること。画像を直接入れる場合は指示の文などを合わせたリクエスト全体が20MBまでであること。1回のリクエストの画像が最大3,600枚であること。位置が [ymin, xmin, ymax, xmax] の順で0〜1000に正規化されて返り、元の大きさに戻して使うこと。384ピクセル以下の画像が258トークンで、それより大きい画像はタイルに分けて数えること。media_resolution が画像1枚あたりのトークンの上限を決め、高い値は細かい文字や小さな部分に向くがトークンと待ち時間が増えること。呼び出しが /v1beta/interactions であること | Google AI for Developers: Image understanding | 2026-10-28 |
構造化出力を /v1beta/interactions の response_format(mime_type に application/json、schema)で指定すること。文字列の enum、配列の minItems・maxItems が使えること。minLength・maxLength はエラーにならずに外されること。値はアプリ側で検証するよう書かれていること | Google AI for Developers: Structured output | 2026-10-28 |
Interactions API が既定でやり取りを保存し(有料の枠で55日、無料の枠で1日)、store=false で保存しない動きにできること。store=false では前のやり取りを引き継ぐ使い方ができないこと | Google AI for Developers: Interactions API | 2026-10-28 |
| 利用には18歳以上であることが必要で、18歳未満の人に向けた、または使う見込みのあるアプリでの利用を認めていないこと。有料のサービスではプロンプトと応答が製品の改善に使われないこと | Gemini API Additional Terms of Service | 2026-10-28 |
どの候補を刷り出しのやり直しとするか、色をどこまで許すかは、お客様との取り決めと社内の品質の基準に合わせて決めてください。 本記事は上の公式の情報で確認できた範囲だけを扱っています。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-2188)についてのご相談はこちらから。
