購買部が仕入先の工場を訪問したときの写真とメモから、Gemini で訪問報告の下書きと気付き事項の一覧を作り、前回の宿題の確認状況と並べる

処理の起点を決める

訪問から戻った当日を起点にします。 遅くとも翌営業日です。写真が何を写したものかは、現場の記憶がある間にしか正しく名前を付けられません。 訪問が続く週も、写真の選り分けと名前付けだけは当日に済ませます。

Gem に渡すのは、写真の選り分けが済んでからです。 選り分けの前に渡すと、外すべき写真が Gemini とのやり取りに入ります。1番目と2番目の人の作業が終わったことを、フォルダの名前に「済」を付けて示す決まりにします。

前回の宿題の一覧は、訪問の前日に用意しておきます。 前回の報告書の「合意事項と宿題」の欄を写し、訪問の当日に現場で確かめる項目として持っていきます。現場で写真を撮るときに、宿題の項目を意識して撮れるので、照合の精度が上がります。

入力データを集める

質を決めるのは、気付き事項の観点表です。 観点表が無ければ、Gemini は写真に写ったものを何でも書きます。観点表で見る場所を決めれば、担当者ごとの違い（第3章の（b））も同時にそろいます。

観点表は、自社の品質管理部と一緒に作ります。 何を良い点とし、何を懸念とするかは、自社が仕入先に求めている品質の決まりで決まるからです。

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

写真は、Gemini アプリに直接アップロードします。 公式の案内では、同じプロンプトでアップロードできるファイルは10個まで（利用できる場合）で、動画以外のファイルは1つ100MBまでとされています。訪問の写真は10枚を超えるので、工程ごとに分けて、同じチャットで続けて渡します。

写真ごとの書き出しを先にさせ、まとめを最後にするのは、根拠を残すためです。 いきなり報告書を頼むと、どの写真から書いたかが分からない文になります。書き出しの段階で写真の名前と見えることを並べさせ、まとめではその書き出しだけを使わせます。

ドライブから写真を足すこともできますが、設定が要ります。 公式の案内では、ドライブのファイルを使うには、組織の管理者が Gemini のアプリへのアクセスを有効にしている必要があるなどの条件があります。使えない組織では、端末からアップロードします。

AIへ渡す前に整形する

1. 写真を選り分ける … 仕入先の図面、他社の製品、人の顔、パソコンの画面が写った写真を外します。外せない場合は、その部分を切り取ります
2. 写真に名前を付ける … 「工程の順の番号＋場所」にします。Gemini が一覧で根拠を示すときに、この名前を使います
3. 写真の向きを直す … 横倒しの写真は回転させます。Gemini API の公式の案内でも、画像の向きが正しいかを確かめ、ぶれの無い画像を使うよう勧めています
4. メモを1つのテキストにまとめる … 手帳のメモは打ち直します。聞いたことと自分が思ったことを分けて書きます（「聞いた：」「所感：」）
5. 前回の宿題に番号を振る … 「前回1」「前回2」と振り、照合の結果をその番号で返させます

1番目が、この構成でいちばん大事な前処理です。 仕入先との取り決めで撮影を認められた範囲でも、図面や他社の製品が背景に写り込むことがあります。 Gemini とのやり取りが組織の中にとどまるとしても、仕入先の秘密を自社の外へ出さない約束は、写真を渡す前に守ります。

4番目の「聞いた」と「所感」の区別も効きます。 区別しないと、購買担当の所感が「仕入先の説明」として報告書に載ります。根拠の欄で、メモのどちらの行かを示させます。

AIに処理させる

させるのは、写真ごとの書き出し、報告書の下書き、気付き事項の一覧、宿題の照合の4つです。

区分の「要確認」を必ず使わせます。 写真だけでは良いとも悪いとも言えないもの、たとえば「床に部品箱が置かれている」は、作業中の一時置きかもしれません。決めきれないものを懸念に寄せず、要確認として購買担当に返させます。

5行目がいちばん起きやすい失敗です。 前回の宿題が「不適合品の置き場に表示を付ける」で、今回の写真に赤い箱が写っていると、表示が読めなくても「確認できた」と書いてきます。 根拠の写真で、表示そのものが読めるかを人が確かめます。

指示内容を固定する

Gem の指示（Gem「仕入先訪問報告」に保存）：

あなたは製造業の購買部で、仕入先の工場を訪問した後に
訪問報告書の下書きを作る担当です。

【使うもの】
- Knowledge の「報告書の型」の欄の並びで書いてください。
- Knowledge の「気付き事項の観点表」の観点だけで気付き事項を拾ってください。
- 写真の名前（例：03_塗装前の検査台）を、根拠として必ず書いてください。

【写真を渡されたとき】
写真ごとに、写真の名前｜当てはまる観点｜写真に見えること を書き出してください。
見えないこと、写真の外のことは書かないでください。

【「まとめて」と言われたとき（この順で）】
1. 報告書の下書き（型の欄ごと）
2. 気付き事項の一覧：番号｜観点｜内容｜区分｜根拠（写真の名前／メモの行）
   区分は 良い点／懸念／要確認 のいずれかです。
3. 前回の宿題の照合：宿題の番号｜状況｜根拠
   状況は 確認できた／写真では確認できず／記載なし のいずれかです。

【厳守事項】
- 根拠の無い気付き事項を書かないでください。根拠は写真の名前かメモの行だけです。
- 写真だけで良いとも悪いとも決められないものは、要確認にしてください。
- 原因を推し量らないでください。メモの「聞いた：」の行にある説明だけを使ってください。
- メモの「所感：」の行は、仕入先の説明として書かないでください。
- 仕入先の評価点や、取引についての意見を書かないでください。
- 是正を求める文を書かないでください。
- 宿題の表示や掲示が写真で読めなければ「写真では確認できず」にしてください。
- 写真に人の顔や図面が写っていたら、その写真の書き出しを止めて知らせてください。

チャットの1回目に貼る文：

仕入先：〔A社〕（塗装）／訪問日：2026-11-12／面談者：工場長、品質の担当
【前回の宿題】
前回1：不適合品の置き場に表示を付ける
前回2：塗装前の検査の限度見本を新しくする
【メモ】
聞いた：塗装ラインの乾燥炉を9月に入れ替えた
聞いた：限度見本は10月に作り直した
所感：出荷場の通路が狭く感じた
（このあとに、受け入れから加工までの写真9枚）

指示を Gem とチャットに分けるのは、変わるものと変わらないものを分けるためです。 型と観点と禁止事項は Gem の指示に一度だけ書き、訪問ごとに変わる宿題とメモと写真だけをチャットに渡します。 6名の誰が使っても、同じ型の下書きが返ります。

「所感」の行を仕入先の説明として書かせないのは、報告書が仕入先の評価の材料になるからです。 「出荷場の通路が狭い」は購買担当の感想で、仕入先がそう説明したわけではありません。 混ざると、品質管理部は仕入先の認めた事実として読みます。

出力形式を固定する

報告書の下書きと2つの一覧を、決まった順と列で受け取ります。

【1. 報告書の下書き】
訪問の目的：定期の訪問（四半期）。塗装工程と保管の状態の確認、前回の宿題の確認
見た工程：受け入れ、前処理、塗装、乾燥、検査、梱包、出荷
（以下、型の欄ごと）

【2. 気付き事項の一覧】
番号｜観点｜内容｜区分｜根拠
1｜作業の手順の掲示｜検査台に限度見本と作業手順書が掲示されている｜良い点｜05_検査台、メモ「聞いた：限度見本は10月に作り直した」
2｜不適合品の区分｜赤い箱が置かれているが、表示の文字が読めない｜要確認｜08_検査台の横
3｜保管と梱包｜当社の部品の箱が床に直に置かれている｜要確認｜12_出荷場
4｜計測器の管理｜膜厚計に校正のラベルが貼られている｜良い点｜06_膜厚計

【3. 前回の宿題の照合】
宿題｜状況｜根拠
前回1｜写真では確認できず｜08_検査台の横（赤い箱はあるが表示が読めない）
前回2｜確認できた｜05_検査台、メモ「聞いた：限度見本は10月に作り直した」

一覧に分ける理由は3つあります。

1つ目は、根拠で確かめられることです。 気付き事項の一覧の右端に写真の名前があるので、購買担当は写真を1枚ずつ見返す代わりに、根拠の写真だけを開けば済みます。 品質管理部も、気付き事項からすぐ写真に行けます。

2つ目は、宿題の行方が残ることです。 「写真では確認できず」が出た宿題は、次回の訪問の宿題の一覧に残ります。 担当が替わっても、宿題が報告書から報告書へ引き継がれます。

3つ目は、仕入先ごとの変化が数えられることです。 観点ごとの懸念と要確認の件数を報告書ごとに数えると、同じ仕入先で同じ観点の懸念が続いているかが見えます。

半自動化の段階では、Gemini API の構造化出力で受けます。 公式の案内では、Interactions API の response_format に JSON のスキーマを渡す形が示されています。区分と状況は enum で固定し、一覧をスプレッドシートにそのまま書き出せる形にします。

システムへ連携する

最小構成では、どこにも自動では書き込みません。 月30件なら、画面の操作で回ります。報告書の正本は、購買担当が確かめた後の Google ドキュメントです。

半自動化では、Google Apps Script でドライブの写真を Gemini API に渡します。 公式の案内では、1回の依頼に入れられる画像は3,600枚までで、画像をそのまま埋め込む場合は依頼全体が20MBまで、大きいファイルや同じ画像を繰り返し使う場合は Files API を使うとされています。訪問の写真は1回で20MBを超えやすいので、Files API でアップロードしてから渡します。Interactions API は既定でやり取りを保存し、有料の枠では55日間保持するとされているため、store=false を付けて保存しないようにします。

人が確認する

1. 気付き事項を根拠の写真と見比べる … 内容が写真に本当に写っているかを見ます。根拠の無いものと、写真と食い違うものを消します
2. 要確認を決める … 現場にいた記憶で、良い点・懸念のどちらかに決めるか、要確認のまま次回に確かめるかを決めます
3. 宿題の照合を確かめる … 「確認できた」の根拠の写真で、表示や掲示そのものが読めるかを見ます
4. 報告書の下書きを整える … メモの「所感」が仕入先の説明として入っていないかを読みます
5. 品質管理部に回す … 懸念がある報告書は、品質管理部の担当に一言添えて回します

2番目が、この構成でいちばん人の判断が要る工程です。 写真の一瞬の状態を、いつもの状態か、その日だけの状態かで判断するのは、現場で仕入先と話した購買担当にしかできません。

目標は、1件48分です。 写真の選り分けと名前付けに15分、Gem への受け渡しに5分、気付き事項と宿題の確認に22分、下書きの整えと回付に6分を見込みます。

例外に対処する

最後の行は、この構成の外の判断です。 報告書は、重大な懸念を伝える手段としては遅すぎます。 現場で見た時点で、品質管理部に電話で伝えます。

記録を残す

• 訪問ごとに、Gem に渡した写真（選り分け後）、メモ、前回の宿題の一覧
• Gemini が返した書き出し・下書き・一覧と、購買担当が消した・直した気付き事項の記録
• 報告書の正本（Google ドキュメント）と、品質管理部に回した日
• 宿題の照合の結果と、次回に回した宿題

2つ目の記録が、観点表を育てます。 消された気付き事項が同じ観点に偏っていれば、その観点の書き方が観点表で足りていないということです。

Gemini アプリのチャットは、報告書の正本にしません。 報告書は Google ドキュメントに、根拠の写真はドライブの仕入先のフォルダに残します。チャットの履歴の扱いは組織の設定で変わるので、正本はチャットの外に置くと決めておきます。半年後に同じ仕入先を訪問する担当が見るのは、ドキュメントとフォルダです。