小売店の売場で撮ったプライスカード・POPの写真から売価と商品を読み取り、売価マスタと特売の登録に食い違う表示を拾って店へ直しを頼む
店が撮った値札とPOPの写真から、商品コード・表示の売価・特売の期間を読み取ります。売価マスタと特売の登録に照らして食い違う表示を拾い、店ごとの直しの依頼の一覧にします。
- 生成AI
- ChatGPT/Claude/Gemini
- 連携・自動化
- Make/n8n/Power Automate/Zapier
- 対象業界
- EC/その他/小売
- 対象部門
- マーケティング
- 対象業務
- 内容確認・チェック/比較検討
- 主な課題
- 人手が足りない/入力作業が多い/確認ミスが多い
- AIで行う処理
- 画像認識
- 主な効果
- 入力漏れ削減/工数削減/機会損失防止
- 導入難易度
- ★★★☆☆
- 実装レベル
- 本格構成
- 費用感
- API連携(中)
- 人間の確認
- 条件付き
01導入前 / 導入後の業務フロー
- 店の担当者が、貼り替えた棚の写真をスマートフォンで撮り、店の共有フォルダに入れる
- 本部の担当者が、店ごとのフォルダを開き、写真を1枚ずつ見る
- 値札の商品コードと売価を読み、売価マスタの表で同じ商品コードを探す
- 表示の売価とマスタの売価を見比べる
- 特売のPOPなら、特売の登録で売価と期間を確かめる
- 食い違いがあれば、店ごとのメモに書き、まとめて店へチャットで直しを頼む
- 人店の担当者が、決まりに沿って値札とPOPを撮り、本部の受付のフォルダに入れる
- 自動Make がフォルダに新しい写真が入ったことを見つけ、写真を取り出す
- 自動OpenAI のモデルが写真を読み、値札とPOPごとに商品コード・表示の売価・特売の期間・読み取れたかどうかを返す
- 自動Make が、商品コードで売価マスタと特売の登録を引き、表示の売価と期間を数字で比べる
- 自動結果を「一致」「食い違い」「読み取れない」「マスタに無い」に分け、照合の一覧に書き込む
- 人本部の担当者が、「食い違い」と「読み取れない」の写真だけを開き、写真で確かめる
- 自動担当者が確かめた食い違いについて、店ごとの直しの依頼の文を作る
- 人担当者が依頼を読んで店へ送る。店は直した後の写真を撮り直して送る
各工程の詳しい説明を読む
- 店の担当者が、貼り替えた棚の写真をスマートフォンで撮り、店の共有フォルダに入れる
- 本部の担当者が、店ごとのフォルダを開き、写真を1枚ずつ見る
- 値札の商品コードと売価を読み、売価マスタの表で同じ商品コードを探す
- 表示の売価とマスタの売価を見比べる
- 特売のPOPなら、特売の登録で売価と期間を確かめる
- 食い違いがあれば、店ごとのメモに書き、まとめて店へチャットで直しを頼む
(a)写真を見てマスタを探すのに時間がかかる。 1枚の写真に値札が3〜4枚写っていることもあり、商品コードを読み、マスタの表で探し、売価を見比べる作業を、値札の数だけ繰り返します。 13桁の数字を目で読んで検索に打ち込むので、打ち間違いも起きます。
(b)売価の違いを見落とす。 「198」と「189」、「1,280」と「1,208」のような違いは、何百枚も見ていると目が慣れて流れてしまいます。 見落とした値札は、お客様に指摘されるまで売場に残ります。
(c)終わった特売のPOPが残る。 木曜の切り替えで先週のPOPを外し忘れると、期間の過ぎた特売の売価が棚に残ります。 写真には写っていても、POPの期間の小さな文字までは見ていません。
(d)切り替えの日に写真が集中する。 木曜と金曜に週の写真の大半が届き、確かめ終わるのが週明けになることがあります。 その間、食い違った表示は売場に出たままです。
- 【人】 店の担当者が、決まりに沿って値札とPOPを撮り、本部の受付のフォルダに入れる
- 【自動】 Make がフォルダに新しい写真が入ったことを見つけ、写真を取り出す
- 【自動】 OpenAI のモデルが写真を読み、値札とPOPごとに商品コード・表示の売価・特売の期間・読み取れたかどうかを返す
- 【自動】 Make が、商品コードで売価マスタと特売の登録を引き、表示の売価と期間を数字で比べる
- 【自動】 結果を「一致」「食い違い」「読み取れない」「マスタに無い」に分け、照合の一覧に書き込む
- 【人】 本部の担当者が、「食い違い」と「読み取れない」の写真だけを開き、写真で確かめる
- 【自動】 担当者が確かめた食い違いについて、店ごとの直しの依頼の文を作る
- 【人】 担当者が依頼を読んで店へ送る。店は直した後の写真を撮り直して送る
6番目が、この設計の分かれ目です。 人が開くのは全部の写真ではありません。「一致」の写真は件数を見るだけにし、 食い違いと読み取れなかったものに時間を使います。
4番目を Make で行っているのは、比べる仕事をAIから外すためです。 売価が合っているかは、数字が等しいかどうかで決まります。決まった答えのある比較は、機械に任せたほうが確実です。
02今回想定するシステム構成
店の担当者がスマートフォンで値札・POPを撮影 │ ファイル名の決まり:店番号_日付_連番 ▼【トリガー】受付のフォルダへの保存 Make(Google Drive:Watch Files in a Folder) ├──▶ Google Drive:写真を取り出す ▼ OpenAI API(Make の OpenAI アプリ:Generate a Response、画像の入力) │ 値札・POPごとに 商品コード/表示の売価/特売の期間/読み取りの状態 ▼ Make ── 売価マスタと特売の登録を商品コードで引く(Search Rows) │ 表示の売価と期間を数字で比べる ▼ 照合の一覧(一致/食い違い/読み取れない/マスタに無い) ▼ 【人が食い違いと読み取れないものだけ写真で確かめる】 ▼ 店ごとの直しの依頼 → 店のチャット
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| ワークフロー | Make(Google Drive と Google Sheets のモジュール、条件分岐) | Power Automate、n8n、Zapier |
| 生成AI | OpenAI API(Make の OpenAI アプリから、画像を入力して呼ぶ) | Gemini API、Claude API |
| 保管 | Google スプレッドシート(売価マスタ・特売の登録の写し、照合の一覧) | データベースの表 |
| 通知 | 店と本部の連絡のチャット | メール |
売価マスタと特売の登録は、基幹の仕組みから毎朝出力している表を使います。 この構成からは基幹の仕組みに書き込みません。売価を直すのではなく、売場の表示を直してもらう構成です。
写真を読むのは、Make の OpenAI アプリの Generate a Response です。 このモジュールは、入力の種類として画像の入力(Image prompt)を選べ、出力の形としてJSON schema を選んで、名前・スキーマ・strict を指定できます。写真を渡して、決めた形のJSONで値札ごとの読み取りを受け取れます。
同じアプリにある Analyze Images (Vision) は使いません。 こちらも指示と画像(URLか画像のデータ)を渡して読ませるモジュールですが、公式の説明に挙がっている項目は指示・画像・モデル・出力の上限などで、出力の形を JSON schema で固定する項目がありません。 後段で数字を比べる構成なので、形が決まった出力を受け取れる Generate a Response を選びます。
専用のOCRの製品を置いていないのは、読むものが数字に限られるからです。 OpenAI の公式の説明では、画像の中の日本語や韓国語のような非ラテン文字は最適に読めないことがあるとされています。この構成では商品コードと売価の数字で照合するので影響を抑えられますが、商品名やPOPの手書きの文字まで読む必要が出たら、Azure AI Document Intelligence や Google Document AI のような日本語に対応したOCRの製品を前段に入れる構成を検討します。
03どうやって実装するのか
処理の起点を決める
本部の受付のフォルダに写真が保存されたことを起点にします。 Make の Google Drive の Watch Files in a Folder を使い、作成された日時(By Created Time)で新しいファイルを見ます。 更新された日時で見ると、店が同じ写真を上書きしたときにもう一度動き、照合の一覧に同じ行が二重に入ります。
1回の実行で取り出す枚数の上限(Limit)を決めておきます。 木曜に数百枚がまとめて入ったとき、1回で全部を処理しようとすると、実行の時間が延びて途中で止まります。上限を数十枚にし、実行の間隔を短くして順に処理します。
写真の種類は、Watch Files in a Folder のファイルの種類の指定で画像に絞ります。 店が誤って動画やPDFを入れても、シナリオには流れてきません。処理した写真は、店ごと・週ごとの保管のフォルダへ Move a File で移します。 受付のフォルダに残っている写真が、そのまま未処理の写真になります。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 値札・POPの写真 | 画像(JPEGなど)。ファイル名に店番号・撮影日・連番 | 受付のフォルダ |
| 売価マスタ | 店番号、商品コード、商品名、通常の税込売価、本体価格 | 基幹の仕組みから毎朝出力する表 |
| 特売の登録 | 店番号、商品コード、特売の税込売価、開始日、終了日 | 基幹の仕組みから毎朝出力する表 |
| 店の一覧 | 店番号、店名、店の連絡先のチャンネル | スプレッドシート |
質を決めるのは、写真の撮り方です。 1枚に棚の一段を丸ごと収めると、値札の数字が小さくなり読めません。撮り方の決まりを店に配ります。
| 撮り方の決まり | 理由 |
|---|---|
| 1枚に値札は4枚まで。値札の正面から撮る | 数字を大きく写すため |
| 斜めから撮らない。横向きの写真は向きを直してから送る | 回転した文字は読み違えやすいとされているため |
| 特売のPOPは期間の文字が写るように撮る | 終わった特売のPOPを見つけるため |
| 広角やパノラマの撮影を使わない | 歪んだ画像は読み取りにくいとされているため |
| ファイル名は「店番号_撮影日_連番」 | 店と日付をファイル名から取るため |
2行目と4行目は、OpenAI の公式の説明に挙げられている苦手な画像に対応したものです。 回転した文字や上下が逆の画像、パノラマや魚眼の画像は読み違えやすいとされています。読み取りの精度を上げるより、苦手な写真を撮らないほうが早く効きます。
データの取得方法を決める
| 取るもの | どこから | どのモジュール |
|---|---|---|
| 新しい写真 | 受付のフォルダ | Watch Files in a Folder |
| 写真の中身 | 受付のフォルダ | Download a File |
| 店番号と撮影日 | ファイル名 | Make の文字列の関数 |
| 売価と特売の登録 | 毎朝出力する表 | Google Sheets の Search Rows(店番号と商品コードで絞る) |
| 照合の結果の記録 | 照合の一覧 | Google Sheets の Add a Row |
売価マスタは、店番号と商品コードの2つで引きます。 同じ商品でも店によって売価が違うことがあるので、商品コードだけで引くと、別の店の売価と比べてしまいます。 Search Rows のフィルタに2つの条件を入れます。
特売の登録は、撮影日を含む期間の行を探します。 撮影日が特売の開始日から終了日の間にあれば、その特売の売価と比べます。撮影日を含む特売が無いのに、写真に特売のPOPがあれば、それは「終わった特売のPOP」か「始まる前の特売のPOP」です。
AIへ渡す前に整形する
- ファイル名を確かめる … 「店番号_撮影日_連番」の形でないものは、照合せずに「ファイル名の誤り」として店へ戻します
- 撮影日を確かめる … ファイル名の撮影日が、今日から7日より前なら、古い写真として人へ回します
- 重複を除く … 同じファイル名の写真がすでに照合の一覧にあれば、処理しません
- 大きさを確かめる … 写真が極端に小さいものは、読み取らずに撮り直しを頼みます
- 画像の細かさの指定を決める … 小さな数字を読むので、画像を縮めすぎない指定で渡します
5番目は、OpenAI の画像の入力の detail の指定のことです。 公式の説明では、low は粗い理解、high は標準の高い精度、original はOCRや小さな物の検出のように細かい部分が要る作業向けとされています。値札の数字を読むので、high か original で試し、読み取りの結果と費用を比べて決めます。 Make のモジュールの画面で指定できない場合は、OpenAI アプリの Make an API Call で API を直接呼びます。
AIに処理させる
させるのは、写真に写っている値札とPOPを1枚ずつ見分け、書かれている数字と文字をそのまま読むことだけです。
| 読むもの | 何を返すか | 読めないときの扱い |
|---|---|---|
| 表示の種類 | 棚札(shelf_label)か特売のPOP(promo_pop)か | 分からなければ unknown |
| 商品コード | 棚札に印字された数字をそのまま | 一部でも読めなければ null。桁を補わない |
| 税込の売価 | 表示された数字をそのまま | 読めなければ null |
| 本体価格 | 表示されていれば数字をそのまま | 無ければ null |
| 特売の期間 | POPに書かれた期間の文字をそのまま | 書かれていなければ null |
| 商品名 | 書かれた文字をそのまま(補助) | 読めなければ null |
| 読み取りの状態 | clear/partial(一部が隠れている・ぼやけている)/unreadable | - |
商品コードの「桁を補わない」が、この構成でいちばん大事な制約です。 13桁のうち1桁が読めないとき、AIはもっともらしい数字で埋めることがあります。埋まった商品コードは、別の商品のマスタの行に当たることがあり、 その場合は食い違いが出るか、たまたま一致して見落とすかのどちらかです。
| させないこと | 理由 |
|---|---|
| 売価が正しいかの判断 | Make が数字で比べる。AIはマスタを見ない |
| 読めない数字の補完 | 桁を埋めると別の商品に当たる |
| 商品コードの推定 | 商品名から商品コードを推定させない |
| 期間の解釈 | 「今週末」などの書き方は書かれたまま返す |
| 値札の数の推測 | 写真の端で切れている値札は partial で返す |
AIにマスタを渡さないのは、意図してのことです。 マスタの売価を一緒に渡すと、ぼやけた「198」をマスタの「198」に寄せて読みます。表示が「189」だったとしても、です。 読み取りの段階では、正解を知らせないようにします。
指示内容を固定する
あなたは小売チェーンの本部で、売場の値札とPOPの写真を読み取る立場です。
写真に書かれている数字と文字を、そのまま読み取ってください。
正しいかどうかの判断はしないでください。
【やること】
写真に写っている値札(棚札)と特売のPOPを1枚ずつ見分け、
それぞれについて次の項目を返してください。
- label_type ...... shelf_label(棚札)/promo_pop(特売のPOP)/unknown
- product_code .... 印字された商品コード(数字)をそのまま
- price_tax_in .... 税込の売価の数字
- price_tax_ex .... 本体価格の数字(表示があれば)
- promo_period .... 特売の期間として書かれた文字をそのまま
- product_name .... 商品名として書かれた文字(読めた範囲で)
- read_status ..... clear/partial/unreadable
【厳守事項】
- 数字は1桁でも読めなければ、その項目を null にしてください。
読めない桁を推測で埋めないでください。
- 商品コードを商品名から推定しないでください。
- 売価のカンマや「円」は含めず、数字だけを返してください。
- 写真の端で切れている値札や、手や商品で一部が隠れている値札は
read_status を partial にしてください。
- 期間は「10/9(木)〜10/15(水)」のように書かれたとおりに写してください。
日付に直したり、年を補ったりしないでください。
- 値札が1枚も写っていなければ、labels を空の配列にしてください。
- 写真の向きが回転している、または上下が逆だと判断したら、
rotated を true にしてください。
「1桁でも読めなければ null」を書かないと、AIは数字を埋めます。 13桁の商品コードや4桁の売価は、1桁欠けると別の値になります。読めた桁だけを返されても照合には使えないので、 全部読めたか、読めなかったかの2つにします。
rotated を返させるのは、苦手な写真を店へ戻すためです。 回転した写真は読み違えやすいとされているので、回転していると判断された写真は、読み取りの結果を使わずに撮り直しを頼みます。
出力形式を固定する
Generate a Response の出力の形を JSON schema にし、strict を有効にして、次の形で受け取ります。
{
"rotated": false,
"labels": [
{
"label_type": "shelf_label | promo_pop | unknown",
"product_code": "4901234567894",
"price_tax_in": 213,
"price_tax_ex": 198,
"promo_period": null,
"product_name": "",
"read_status": "clear | partial | unreadable"
}
]
}
1つ目の理由は、値札の枚数だけ照合を回せることです。 labels の要素1つが値札1枚で、Make はこの配列を1枚ずつ取り出してマスタと比べます。 1枚の写真に4枚の値札があれば、照合の一覧に4行が入ります。
2つ目は、読めなかったことを null で表せることです。 構造化出力では、値が無いかもしれない項目をnull を含む型で定義します。product_code を「文字列または null」にしておけば、読めなかった商品コードは空の文字列ではなく null で返り、 照合の前に確実に見分けられます。
3つ目は、照合の規則を Make の側に表で持てることです。
| 結果 | 条件 |
|---|---|
| 一致 | read_status が clear で、表示の売価がマスタ(特売の期間内なら特売の売価)と等しい |
| 食い違い | read_status が clear で、表示の売価が等しくない |
| 期間外のPOP | label_type が promo_pop で、撮影日を含む特売の登録が無い |
| 読み取れない | read_status が partial か unreadable、または product_code か price_tax_in が null |
| マスタに無い | 商品コードで売価マスタを引けない |
「期間外のPOP」の判断に、POPに書かれた期間の文字は使いません。 書かれた期間は人が確かめるための参考にとどめ、判断は撮影日と特売の登録で行います。 手書きの期間の文字を日付として読むと、読み違いがそのまま判断に入ります。
応答を断った場合は、スキーマどおりにならないことがあります。 公式の説明では、その場合は refusal という項目が返るとされているので、それがあれば照合をせずに「読み取れない」として人へ回します。
システムへ連携する
| つなぎ先 | 方式 | 内容 |
|---|---|---|
| 受付のフォルダ | Watch Files in a Folder/Download a File/Move a File | 写真の取り出しと、処理後の移動 |
| OpenAI API | Generate a Response(画像の入力、JSON schema) | 値札とPOPの読み取り |
| 売価マスタ・特売の登録 | Google Sheets の Search Rows | 店番号と商品コードで引く |
| 照合の一覧 | Google Sheets の Add a Row | 値札1枚を1行で記録 |
| 店のチャット | Make のモジュール | 担当者が確かめた直しの依頼を送る |
照合の一覧には、写真へのリンクを必ず入れます。 担当者は一覧の「食い違い」の行から、ワンクリックで写真を開いて確かめます。 リンクが無いと、店のフォルダから写真を探すところから始まり、第3章の(a)に戻ります。
店への依頼は、担当者が確かめた後にだけ作ります。 「食い違い」と出た行に担当者が「確認済み」を付けると、その店の確認済みの行をまとめて、直しの依頼の文を作ります。 読み違いによる誤った依頼が店に届くと、店は正しい値札を貼り替えることになります。
人が確認する
人が開くのは、「食い違い」「期間外のPOP」「読み取れない」「マスタに無い」の写真だけです。 「一致」の写真は店ごとの件数を見て、極端に少ない店が無いかだけを確かめます。
- 「食い違い」を写真で確かめる … 表示の売価を目で読み、マスタの売価と比べます。読み違いなら「読み違い」の印を付けます
- 「期間外のPOP」を写真で確かめる … POPの期間の文字を読み、終わった特売のものかを確かめます
- 「読み取れない」を見る … 写真が悪いなら撮り直しを頼み、写真が良いのに読めないなら目で読んで照合します
- 「マスタに無い」を見る … 商品コードの読み違いか、新商品でマスタの出力に入っていないかを確かめます
- 確認済みの行から直しの依頼を作り、店へ送る
1番目で付ける「読み違い」の印が、この構成の精度を測る記録です。 「食い違い」のうち読み違いの割合が高い店は、写真の撮り方に原因があることが多いので、 撮り方の決まりを店と見直します。
目標は、1,800枚をならして1枚1分です。 「一致」が大半で、人が開くのは2〜3割という想定です。
例外に対処する
| 起きること | 対応 |
|---|---|
| ファイル名が決まりと違う | 照合せずに店へ戻す。店番号が分からない写真は照合できない |
| 写真が回転している | rotated が true なら読み取りの結果を使わず、撮り直しを頼む |
| 値札が1枚も写っていない | 店へ確認する。棚の全体の写真だけを送っていることがある |
| 商品コードが読めない | 「読み取れない」で人へ。商品名から推定しない |
| 同じ値札が2枚の写真に写る | 店番号・撮影日・商品コードが同じ行は1つにまとめる |
| マスタの出力が古い | 毎朝の出力の日付を確かめ、当日のものでなければ照合を止める |
| 応答を断られた・出力が途中で切れた | 照合せずに「読み取れない」で人へ |
| OpenAI API が応答しない | 写真を受付のフォルダに残す。移すのは成功したときだけ |
6行目を軽く見ないでください。 特売の切り替えの朝に、マスタの出力が前日のままだと、新しい特売のPOPがすべて「期間外のPOP」になります。 照合を始める前に、出力の日付を1回確かめる手順を置きます。
記録を残す
- 元の写真と、撮影日・店番号(保管のフォルダに店ごと・週ごとに残す)
- AIの出力(
labelsの全体とrotated) - 照合の結果と、そのとき参照した売価マスタと特売の登録の出力日
- 人が「読み違い」とした記録 … どの項目を、何から何に読み違えたか
- 店へ直しを頼んだ日時と、直した後の写真が届いた日時
- Make のシナリオの実行の履歴
3つ目でマスタの出力日を残すのは、売価が日ごとに変わるためです。 後から「この照合は正しかったか」を確かめるとき、その日のマスタが分からないと、照合をやり直せません。
5つ目は、店ごとの直しの速さを見るためです。 直しの写真が届くまでの時間が長い店には、依頼の送り方や時間帯を変える相談をします。
04実装レベルの3段階
最小構成では枚数がさばけません。 月1,800枚を手で貼るのは現実的ではなく、読み取りの精度と撮り方の決まりを確かめるための段階です。 半自動化で、1枚3分が2分程度になります。 読み取りは自動になりますが、マスタを探して見比べる作業が残ります。本格構成で1分になり、この段階が本記事の想定です。 差が大きいのは、13桁の商品コードでマスタを探す作業が、値札の数だけ繰り返す手作業だからです。 段階を飛ばさないでください。 半自動化の一覧を2〜3週見ると、読み取れない写真の多い店と、マスタに無い商品の多い売場が先に分かります。撮り方とマスタの出力の抜けを直してから照合を足すほうが、「食い違い」の中の読み違いが減り、担当者が一覧を信じて使えるようになります。
05工数削減シミュレーション
導入後 1,800件 × 1分 ÷ 60 = 30 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- スーパーマーケットやドラッグストアなど、数十店舗で毎週の特売を回し、本部の販促の担当が店から送られる売場の写真で値札とPOPの貼り替えを確かめているチェーン。値札の売価がレジの売価と違うという指摘や、終わった特売のPOPが残っているという指摘を受けている場合。棚札に商品コードかJANコードの数字が印字されており、売価マスタと特売の登録を表の形で出せる場合。
- 店舗が数店で、店長が売場を歩いて確かめれば足りる場合。電子棚札を使っており、売価が売価マスタから直接表示されている場合。棚札に商品コードが無く、商品名でしか商品を特定できない場合(日本語の商品名の読み取りに頼ることになり、照合の精度が出にくい)。なお、表示が法令に照らして適切かの判断は、この構成では代替しません。
07最小構成で試す方法
- 先週の特売の切り替えで届いた写真から30枚を選ぶ(当時、食い違いが見つかった写真を数枚入れる)
- その30枚について、値札ごとの商品コードと売価を、人が読んで表にする
- 手元のAIサービスの画面に写真を1枚ずつ貼り、第7章の指示文で読み取らせる
- AIの読み取りを、人が読んだ表と1桁ずつ突き合わせる
- 読み違いのあった写真の撮り方を見る
比べるのは、照合の結果ではなく読み取りの結果です。 試す段階では、マスタとの照合はしません。AIが数字を正しく読めるか、読めないときに null にするかだけを見ます。
| 出てきた内容 | 判断 |
|---|---|
| 数字をほぼ正しく読み、読めないものは null になった | Make のシナリオを組む段階に進む |
| 読めない桁を埋めた | 指示の書き方で直る。null にすることを強く書く |
| 斜めや遠くの写真で読み違いが多い | 撮り方の決まりを作るところから始める |
3行目が出ることは珍しくありません。 今の写真は、人が目で見る前提で撮られています。撮り方の決まりを作って撮り直した30枚で、もう一度試してください。 撮り直した写真で読み取りが大きく良くなれば、それは人が目で確かめるときにも効く改善です。AIを入れる前から、本部の確認が速くなります。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 読めない桁が埋まって返る | 桁を補わないことを指示に書き、null を許す型にする |
| マスタの売価に寄せて読む | AIにマスタを渡さない。 比べるのは Make |
| 商品名で照合して外れる | 日本語の文字は最適に読めないことがある。商品コードで照合する |
| 回転した写真で読み違える | rotated を返させ、撮り直しを頼む |
| 棚の一段を1枚に収めて数字が小さい | 1枚に値札4枚までの撮り方の決まりを配る |
| 上書きした写真で照合が二重になる | 作成日時で見る。ファイル名で重複を除く |
| 別の店の売価と比べてしまう | 店番号と商品コードの2つで引く |
| 新しい特売がすべて期間外になる | マスタの出力日を照合の前に確かめる |
| 木曜にまとめて届いて止まる | 1回の上限を決め、間隔を短くする |
| 誤った依頼が店に届く | 担当者が確かめた行だけから依頼を作る |
上の2行が、この構成の失敗のほとんどです。 どちらも、AIが「正しそうな数字」を作ってしまうことから来ています。読み取りの段階では正解を知らせず、読めないものは読めないと返させる。 この2つを守れば、照合は Make の数字の比較で確実に行えます。
下の3行は、運用の初めに集中して起きます。 マスタの出力日の確認と、木曜の集中への備えは、最初の特売の切り替えの日に一度は止まるつもりで準備してください。誤った依頼が店に届くことだけは、最初から仕組みで防ぎます。店が本部の依頼を信じなくなると、正しい依頼まで後回しにされるようになります。
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 売場の写真、売価マスタ、特売の登録です。個人の情報は本来含みませんが、売場の写真には、お客様や従業員の顔や名札が写り込むことがあります。
- 人が写らないように撮る … 撮り方の決まりに、お客様や従業員が写らないように撮ることを入れます。写り込んだ写真は、照合の後も保管のフォルダで扱いを分けます
- 外部へ渡すのは写真だけにする … AIに渡すのは写真と指示文だけで、売価マスタと特売の登録は渡しません。 特売の予定は、公開前は社外に出したくない情報です
- 表示の適否の判断をこの構成に任せない … この構成が見るのは、表示がマスタと合っているかだけです。表示の仕方が法令や業界の決まりに沿っているかは、別に確かめてください
- 店への依頼は人が確かめてから送る … 読み違いによる依頼は、店に余計な貼り替えをさせます。依頼を自動で送る作りにしません
- 写真の保管の期間を決める … 写真は照合と後からの確認に要る期間だけ残し、期間を過ぎたものは消す決まりを作ります
- 使うモデルの提供元の扱いを確かめる … 写真を外部のAPIで処理することを、自社の情報の取り扱いの基準と照らして決めます
誤りが起きた場合のリスクは、食い違いを見落とすことと、合っている表示を食い違いとして直させることの2つです。 前者は読めないものを null で返させて人へ回すことで、後者は人が写真で確かめてから依頼を作ることで防ぎます。
10まず何から始めるか
1週目:撮り方の決まりを作る
値札の枚数、撮る向き、ファイル名の決まりを1枚の紙にまとめ、2〜3店に試してもらいます。 人が目で見ても数字が読みやすくなったかを確かめます。
2週目:30枚で試す
決まりに沿って撮った写真から30枚を選び、手元のAIサービスで読み取らせます。人が読んだ表と1桁ずつ突き合わせ、読めない桁を埋めていないかを最優先で見ます。
3週目:マスタの出力を整える
売価マスタと特売の登録を、店番号・商品コード・売価・期間の表で毎朝出力する段取りを、基幹の仕組みの担当と決めます。
4週目:読み取りと一覧化をつなぐ
Make で受付のフォルダを見張り、写真を読み取って一覧に書き出すところまで作ります。この時点では照合をせず、読み取りの結果だけを1週間見ます。
2か月目: 売価マスタと特売の登録との照合を足し、「食い違い」のうち読み違いの割合を店ごとに数えます。3か月目以降: 店への依頼の文を足し、撮り方の決まりを全店に広げます。特売の切り替えの日のうちに全店の確認が終わるようになった時点で、この構成は完成です。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
| Watch Files in a Folder が指定のフォルダのファイルの作成・更新で動き、作成日時か更新日時で見るかを選べること。ファイルの種類と1回の上限(Limit)を指定できること。Download a File、Move a File のモジュールがあること | Make Apps Documentation: Google Drive modules | 2026-10-06 |
| OpenAI アプリの Generate a Response で、入力の種類に画像の入力(Image prompt)があり、出力の形に Text・JSON schema・JSON object を選べ、JSON schema では名前・スキーマ・strict を指定できること。Analyze Images (Vision) の項目が指示・画像(公開URLか画像のデータ)・モデル・出力の上限などであること。Make an API Call で任意の API を呼べること | Make Apps Documentation: OpenAI modules | 2026-10-06 |
画像の入力の形式(PNG、JPEG、WEBP、アニメーションでないGIF)。detail に low・high・original・auto があり、original がOCRや小さな物の検出のように細かい部分が要る作業向けとされること。日本語や韓国語のような非ラテン文字、回転や上下逆の画像、パノラマや魚眼の画像で最適に動かないことがあるとされること | OpenAI API Docs: Images and vision | 2026-10-06 |
構造化出力が JSON Schema に沿った応答を返し、strict を有効にして使うこと。additionalProperties: false を指定すること。値が無いかもしれない項目を null を含む型で表すこと。enum に対応すること。応答を断った場合は refusal が返り、スキーマに沿わないことがあること | OpenAI API Docs: Structured outputs | 2026-10-06 |
| Search Rows がフィルタで行を探すこと。Add a Row で行を追加できること | Make Apps Documentation: Google Sheets modules | 2026-10-06 |
値札とPOPの表示の仕方が法令や業界の決まりに沿っているかは、自社の担当部署で確かめてください。 本記事は、製品の公開仕様で確認できた範囲だけを扱っています。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-0625)についてのご相談はこちらから。
