Googleフォトの商品写真をAIに渡すなら、対象を選んでダウンロードし、写真から分かる事実と人が確認した情報を合わせて説明文を作る方法から始められる。外観だけで型番、動作状態、付属品、購入時期を確定させることはできない。
写真を探す手間と説明文を整える手間を減らすための独自ワークフローだ。自動出品、価格の決定、購入者とのやり取りまでは含めない。写真を選ぶ、事実を補う、原稿を確認する、の3つを分けると、商品の状態を盛った文章が入りにくい。
手動ダウンロードとPicker APIの違い
| 方法 | 向く場面 | 確認すること |
|---|---|---|
| Googleフォトからダウンロード | 少数商品の原稿作成 | 対象写真と保存先 |
| Google Photos Picker API | 自社アプリへ選択写真を取り込む開発 | 認証、選択画面、選択完了と取得 |
| 写真ライブラリー全体をAIに渡す | この記事では前提にしない | 不要な写真を含めない対象設計 |
Googleの公式案内では、PCで写真を選び、その他メニューからDownloadを選ぶとローカルコピーを保存できる。Picker APIはユーザーが選んだ写真・動画をアプリへ渡す仕組みであり、記事の手順を読むだけでGoogleフォトとAIの接続が有効になるわけではない。
1商品から始める6ステップ
- Googleフォトで対象商品の写真を探す。全体、型番ラベル、傷、付属品の4種類がそろうか確認する。
- 必要な写真だけを選択し、PC版のその他メニューからダウンロードする。
- 住所・伝票・人物・機密資料などが写り込んでいないか確認する。必要な範囲の画像だけを用意する。
- 画像入力に対応したAIへ対象写真と確認済みの事実メモを渡す。利用するAIの画像対応とデータ設定を確認する。
- 観察できること、事実メモにあること、不明点を分けて出力させる。
- 原稿と実物を照合し、確認担当が採用する。出品先に入力する場合も内容を再確認する。
AIへ渡す事実メモの型
商品ID: DEMO-001
商品名: 確認済みの名称を記入
型番: ラベルを読んで人が確認
動作確認: 未確認
付属品: 写真に写したものを列挙
傷: 場所と程度を記入
購入時期: 不明
禁止表現: 未確認の新品同様・完動品・正規品保証上記は入力テンプレートで、特定商品の実績ではない。動作未確認なら「動作未確認」と書く。写真にケーブルが見えるだけでは、その商品に同梱するケーブルなのか、撮影時の背景なのかは確定しない。付属品欄は人が決める。
写真から説明文へ変える構成例
| 出力欄 | 書く内容 | 根拠 |
|---|---|---|
| 商品概要 | 確認済みの商品名・型番 | ラベルと事実メモ |
| 状態 | 見える傷・欠け、確認した動作 | 写真番号と確認記録 |
| 付属品 | 実際に渡すもの | 人の確定リスト |
| 未確認 | 未測定・不明の事項 | 未確認と明記 |
| 掲載前チェック | 実物と文章の差 | 担当者の確認 |
原稿例は「本体側面に小さな傷がある。状態は写真03で確認できる。動作は未確認。付属品は記載したもののみ」といった、根拠を追える形にする。「ほぼ新品」「必ず動く」などの評価は、写真だけを見て補わない。
作業に使える依頼文6例
1．写真の一覧
For each supplied image, list the visible product, readable labels, damage, and uncertainty. Refer to image numbers. Do not identify an exact model from appearance alone.2．事実を分ける
Separate observed facts, facts confirmed in the supplied memo, and unknowns. Do not infer purchase date, authenticity, or working condition.3．追加写真を決める
List missing views needed to describe this product accurately: full view, model label, damage, and included accessories. Do not request unrelated personal photos.4．原稿を作る
Draft a Japanese product description using only confirmed facts. Include condition, included items, and unverified points. Do not add promotional superlatives.5．根拠を監査
Check every factual sentence against the image numbers and fact memo. Flag unsupported claims and any contradiction about accessories or condition.6．掲載前に整える
Prepare the final description and a human review checklist. Do not set a price, create a listing, send messages, or publish anything.アプリへ組み込むときのPicker APIの流れ
開発する場合は、認証後に選択用セッションを作り、返されたpickerUriをユーザーに開いてもらう。選択完了を確認し、選ばれたメディアの一覧と内容を取得する。具体的な設定はGoogleのPicker API公式ガイドで確認する。独自アプリの実装やAPI連携の実機検証はこの記事の範囲外だ。
うまくいかない場合
| 症状 | 見直すこと |
|---|---|
| 型番が読めない | ラベルを近くで撮影し、人が文字を確認 |
| 商品と背景を取り違える | 対象商品を明示し、不要な写真を除く |
| 未確認なのに動作品と書く | 事実メモと禁止表現を再提示 |
| 写真の日付が変わった | ダウンロード時刻と撮影メタデータを区別 |
| 同じ商品に別の説明ができる | 商品IDと写真の対応を固定 |
よくある質問
Googleフォト全体を連携する必要があるか
少数商品の説明文なら、必要な写真を選んで渡す方法から始められる。
AIが型番を言い当てたら採用してよいか
ラベルや公式資料で人が確認する。見た目が似た別型番もある。
中古品の価格も写真だけで決められるか
この手順では扱わない。状態、型番、付属品、相場など追加情報が必要だ。
写真をきれいに加工してよいか
説明文作成では状態を示す原本も維持する。傷や欠品を消した画像を商品の実態として使わない。
APIを使えば自動で全写真を取得できるか
ここで扱うPicker APIはユーザーによる選択を伴う。選択と認証を省略して全ライブラリーを取得する説明ではない。
画像から制作を広げる場合はHiggsfieldへの参照画像の渡し方、商品ごとのタスク管理にはPM Hub型のタスク設計も利用できる。
小さく始める3ステップ
- 今日：記事の入力例を、自分の仕事1件に置き換えて準備する。
- 今週：確認担当を決め、下書きと実際の原本を照合して1件を完了させる。
- 来月：手戻り、確認時間、失敗件数を振り返り、対象を広げるか判断する。
出典・検証範囲
確認日：2026年10月31日。公式資料と公開情報に基づく設計例。編集部による対象アプリの実機検証、処理時間・費用の実測は行っていない。画面名、提供地域、料金、接続条件は変更されるため、導入時は公式案内を再確認する。
企画の参考：4人の対談：写真を使った仕事の組み立て。動画内の利用成果を編集部の実績として扱っていない。
LIFRELLへの相談
AIに渡す資料、担当者の確認、成果物の保存まで含めた業務フローの設計は、LIFRELLの無料相談で相談できる。
