Media > AI活用ユースケース > 購買 > 金券ショップが持ち込まれた商品券・切手の写真を Gemini で読み、券種・額面・枚数の買取の明細と古物の帳簿の下書きを作る

金券ショップが持ち込まれた商品券・切手の写真を Gemini で読み、券種・額面・枚数の買取の明細と古物の帳簿の下書きを作る

実装ステータス:構成例 技術的に実現可能な構成として設計したもの。自社未検証

金券ショップの窓口で、持ち込まれた商品券や切手を買取の台に並べて撮り、Gemini に券種・額面・有効期限と1枚ずつの位置を読ませます。買取率の表と照らして買取の明細と古物の帳簿の下書きを作り、担当が枚数と額面を確かめます。

サマリー
生成AI
ChatGPT/Claude/Gemini
連携・自動化
Google Apps Script/Python
対象業界
その他/小売
対象部門
購買
対象業務
データ入力・転記/内容確認・チェック
主な課題
人手が足りない/入力作業が多い/確認ミスが多い
AIで行う処理
画像認識
主な効果
入力漏れ削減/対応スピード向上/工数削減
導入難易度
★★☆☆☆
実装レベル
本格構成
費用感
API連携(中)
人間の確認
条件付き
現在工数
90h/月
AI導入後
30h/月
想定削減
67%
年間削減
720h
モデル条件による試算値です。実在企業の実績ではありません。

01導入前 / 導入後の業務フロー

導入前(Before)
  1. お客様から金券を受け取り、窓口の台に出してもらう
  2. 担当が券種ごとに仕分け、券面の発行元の名前と額面と有効期限を見る
  3. 額面ごとに枚数を数え、もう一度数え直す
  4. 買取の管理の画面に、券種・額面・枚数を打ち込み、買取率の表から金額を出す
  5. 破れ・汚れ・記名・期限切れのものを分け、買い取れないものをお客様に返す
  6. 金額をお客様に伝え、了承されたら相手方の確認をする
  7. 明細の控えに品目・数量・特徴を書き、代金を払う
導入後(After)
  1. 人お客様から金券を受け取り、担当が買取の台に券種ごとに重ならないよう並べる
  2. 人書画カメラで台を撮る(多いときは台を分けて2〜3枚)
  3. 自動Python のサーバーが写真の向きと大きさを整え、Gemini API に送る
  4. 【AI】 Gemini が、1枚ずつの位置の枠と、券面の発行元の名前・券種・額面・有効期限の文字を返す
  5. 【AI】 Gemini が、破れ・汚れ・記名・スタンプの候補を返す
  6. 自動Python が、券種と額面を買取率の表と照らし、期限を今日と比べ、明細の下書きを作る
  7. 自動画面の写真に番号つきの枠を描き、明細の下書きと並べる
  8. 人担当が枠の数と実物の枚数を見比べ、額面と期限を確かめ、直すところを直す
  9. 人担当が金額をお客様に伝え、了承されたら相手方の確認をし、代金を払う
  10. 自動確かめた明細から、古物の帳簿の「品目及び数量」「特徴」の下書きを作る
各工程の詳しい説明を読む
  1. お客様から金券を受け取り、窓口の台に出してもらう
  2. 担当が券種ごとに仕分け、券面の発行元の名前と額面と有効期限を見る
  3. 額面ごとに枚数を数え、もう一度数え直す
  4. 買取の管理の画面に、券種・額面・枚数を打ち込み、買取率の表から金額を出す
  5. 破れ・汚れ・記名・期限切れのものを分け、買い取れないものをお客様に返す
  6. 金額をお客様に伝え、了承されたら相手方の確認をする
  7. 明細の控えに品目・数量・特徴を書き、代金を払う

(a)数え直しと打ち込みで窓口が混む。 3番と4番に時間がかかり、お客様の前で数え直すほど、後ろの列が延びます。 担当は急ぐほど、次の(b)を起こします。

(b)枚数と額面の数え違い。 2枚重なった商品券を1枚と数えた、84円の切手を94円の行で打ち込んだ。多く払えば店の損、少なく払えばお客様とのもめごとになります。 どちらも、レジを締めるまで気づかないことがあります。

(c)期限切れや記名のものを見落とす。 有効期限の印刷は小さく、券によって場所が違います。期限切れの券を買い取ると、売り物になりません。

(d)帳簿の品目と数量の書き漏れ。 「商品券 一式」のようなまとめ書きは、後から品触れ(盗品の照会)が来たときに、その券を買い取ったかどうかが分かりません。

  1. 【人】 お客様から金券を受け取り、担当が買取の台に券種ごとに重ならないよう並べる
  2. 【人】 書画カメラで台を撮る(多いときは台を分けて2〜3枚)
  3. 【自動】 Python のサーバーが写真の向きと大きさを整え、Gemini API に送る
  4. 【AI】 Gemini が、1枚ずつの位置の枠と、券面の発行元の名前・券種・額面・有効期限の文字を返す
  5. 【AI】 Gemini が、破れ・汚れ・記名・スタンプの候補を返す
  6. 【自動】 Python が、券種と額面を買取率の表と照らし、期限を今日と比べ、明細の下書きを作る
  7. 【自動】 画面の写真に番号つきの枠を描き、明細の下書きと並べる
  8. 【人】 担当が枠の数と実物の枚数を見比べ、額面と期限を確かめ、直すところを直す
  9. 【人】 担当が金額をお客様に伝え、了承されたら相手方の確認をし、代金を払う
  10. 【自動】 確かめた明細から、古物の帳簿の「品目及び数量」「特徴」の下書きを作る

8番目が、この設計の分かれ目です。 担当は数え直す代わりに、枠の番号と実物を見比べます。 枠が抜けている券、枠が2つ重なっている券は、写真の上ですぐに分かります。数えるより見比べるほうが速く、しかも確かめた跡が残ります。

6番目で金額を Python が出すのは、買取率の表がその日の版で変わるからです。 Gemini に金額を出させると、表に無い率や、前の日の率で計算した金額が混ざります。 表の版の番号も明細に記録します。

02今回想定するシステム構成

構成図
窓口の書画カメラ(買取の台に券種ごとに並べて撮る)
   ▼【トリガー】担当が「読み取る」を押したとき
Python のサーバー
   ├── 写真の向き・大きさを整える、写り込みを塗りつぶす
   ▼
Gemini API(画像の理解・構造化出力)── 台の写真
   │   1枚ずつの枠、発行元・券種・額面・有効期限の文字、傷みの候補
   ▼
Python ── 券種の一覧と照らす → 買取率の表から金額 → 期限を今日と比べる
   │       明細の下書き、帳簿の「品目及び数量」「特徴」の下書き
   ▼
買取の管理の画面(枠つきの写真と明細を並べる)
   ▼
【人】枠と実物を見比べる → 金額を伝える → 相手方の確認 → 代金
役割想定する製品代替候補
処理Gemini API(台の写真から券面の文字と1枚ずつの枠、傷みの候補を返す)Claude API、OpenAI API
連携Python(写真の受け取り、前処理、呼び出し、券種の照合、買取率の表の参照、帳簿の下書き)Google Apps Script
買取率の表店長が毎朝見直す券種・額面ごとの買取率-
買取の管理窓口の端末の買取の管理の画面と古物の帳簿-

新しく足すのは、Python のサーバーと Gemini API の契約です。 買取率の表と買取の管理の画面は今のものを使い、画面に枠つきの写真と明細の下書きの表示を足します。

写真を見る土台は、Gemini API の画像の理解です。 公式の案内では、対応する形式は PNG、JPEG、WEBP、HEIC、HEIF で、画像を直接入れる場合は、指示の文と合わせたリクエスト全体が20MBまでです。大きいファイルや、同じ画像をくり返し使う場合は Files API を使うとされています。

位置は枠で返させます。 枠は box_2d として [ymin, xmin, ymax, xmax] の順で返り、画像の大きさに対して0〜1000に正規化されます。サーバーが元の大きさに戻して写真に番号つきの枠を描き、担当が1枚ずつ目で追えるようにします。

出力は構造化出力で受けます。 /v1beta/interactions に送り、response_format で mime_type を application/json にし、schema にスキーマを入れます。文字列は enum で決まった値に絞れ、配列の minItems・maxItems は守られるとされています。一方で minLength・maxLength はエラーにならずに外されるとされ、値が正しいかはアプリ側で検証するよう公式に書かれています。

03どうやって実装するのか

Step1

処理の起点を決める

担当が買取の台に並べ終えて「読み取る」を押したときに動きます。 写真は書画カメラから窓口の端末に入り、受付の番号と一緒にサーバーに送られます。 並べている途中で読ませないよう、ボタンは担当が押します。

並べ方を決めておきます。 台には升目を印刷したマットを敷き、1つの升に1枚、券種ごとに行を分けて並べます。 重ねない、裏返さない、帯や封筒から出す。この決まりが、枠の数を実物の枚数に近づけます。

切手のシートは、シートのまま1枚として置きます。 シートの面の数は Gemini に数えさせ、枠はシート全体に1つ、面の数は別の欄で返させます。 バラの切手は、升に1枚ずつ置きます。

この構成を使うのは窓口の担当と店長だけで、全員が18歳以上の社員です。 Gemini API の規約は、18歳以上であることを利用の条件とし、18歳未満の人に向けた、または使う見込みのあるアプリでの利用を認めていません。 お客様が端末を触ったり、AIの結果を直接見たりすることはありません。

Step2

入力データを集める

データ中身取得元
台の写真升目のマットに並べた金券を真上から撮ったもの(1件に1〜3枚)窓口の書画カメラ
受付の情報受付の番号、店、担当、日時買取の管理の画面
券種の一覧店が扱う券種の正式な名前、券面の発行元の表記、よくある表記ゆれ、額面の種類店のスプレッドシート
買取率の表券種・額面ごとのその日の買取率と、表の版の番号店長が毎朝見直す表
買い取らない条件期限切れ、破れ・汚れの程度、記名、使用済みの印などの店の決まり店の決まりの文書

質を決めるのは、券種の一覧です。 券面には発行元の名前、券の種類、額面、注意書きが小さく印刷されていて、似た名前の券が何種類もあります。 一覧に「券面の表記」と「表の行の名前」の対を持たせておけば、Gemini が読んだ文字を表の行に結び付けられます。

相手方の情報は、AIに渡しません。 お客様の名前・住所・年齢・身分証の写真は、買取の写真とは別の画面で扱い、Gemini API に送る写真には含めません。 買取の台の上に身分証を置かないことも、窓口の決まりにします。

Step3

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

写真は書画カメラから窓口の端末を通して、サーバーに直接届きます。 受付の番号のフォルダに元の写真を保存し、保存が終わってから AI を呼びます。

Gemini API へは、台の写真1枚ごとに1回呼びます。 台を分けて撮ったときは写真ごとに呼び、サーバーが写真の番号と枠の番号を組み合わせて明細にします。 1回に複数の写真を入れることもできますが、枠がどの写真のものかが混ざらないよう、1枚ずつにします。

券種の一覧と買取率の表は、サーバーが朝に1回読み込みます。 店長が表を直したら読み直し、その版の番号を、明細の下書きと一緒に記録します。

有料の利用枠で使い、store を false にします。 Gemini API の規約では、有料のサービスではプロンプトと応答が製品の改善に使われないとされています。Interactions API は既定でやり取りを保存し(有料の枠で55日)、store=false で保存しない動きにできると案内されています。

Step4

AIへ渡す前に整形する

  1. 向きの補正 … 端末の写真の向きの情報で回転しているだけのものは、画素を回転させます
  2. 大きさの確認 … 券面の小さな文字が読めるよう、縮めすぎません。写真と指示の文を合わせて20MBを超えないかを見ます
  3. 写り込みの塗りつぶし … 台の外に写ったお客様の手、身分証、レシートを塗りつぶします
  4. 升目のマットの検出 … マットの四隅が写っていない写真は、その場で撮り直してもらいます
  5. 明るさとぶれの確認 … 暗い・ぶれている写真は、AIに渡さずにその場で撮り直してもらいます

4番目は、枠の数を確かめる手がかりのためです。 升目が写っていれば、サーバーは升の数と枠の数を比べられます。 升に券が置かれているのに枠が無い、1つの升に枠が2つある、という食い違いを先に印にできます。

照明の映り込みにも気をつけます。 商品券の中には、券面に光沢のある箔や印刷が使われているものがあります。真上の照明が箔に映ると、額面の数字がその部分だけ白く飛びます。 書画カメラの照明は斜めから当て、映り込みで読めない件が続く券種は、券種の一覧に「斜めから撮る」と書いておきます。

Step5

AIに処理させる

させるのは、券面に印刷された文字を写すことと、1枚ずつの位置を枠で返すことです。

見るもの返し方判断できないときの扱い
1枚ずつの位置枠(box_2d)重なっていれば overlap の印
発行元の名前と券種券面の文字のまま読めなければ unreadable
額面券面の数字と単位のまま読めなければ unreadable
有効期限券面の文字のまま。無ければ none_printed読めなければ unreadable
シートの面の数切手のシートのときだけ、見えている面の数欠けがあれば partial
傷みの候補破れ・汚れ・記名・スタンプ・書き込みのどれか迷えば uncertain

右端の列が大事です。 unreadable は「券面にあるはずの文字が読めない」、none_printed は「期限の印刷が見当たらない」で、前者は撮り直すか担当が読むもの、後者は券種の一覧で期限の有無を確かめるものです。 混ぜると、期限のある券を期限なしとして買い取ることになります。

させないこと理由
本物かどうかの判断透かしや手ざわりは写真では確かめられない。担当が実物で見る
買い取るかどうかの判断店の決まりと担当が決める
買取の金額の計算買取率の表の版で Python が出す
期限の切れ・切れないの判断今日の日付との比べは Python が行う
読めない額面の推し量り券種から「たぶん1,000円」と埋めない
券種の一覧に無い名前への言い換え券面の文字のまま返させる

5行目がいちばん起きやすい失敗です。 百貨店の商品券は1,000円が多いので、額面が指で隠れていても1,000円と返したくなります。 読めないものは unreadable にさせ、担当が実物で読みます。

1行目を AI に任せないのは、写真で分かることではないからです。 古物営業法は、古物を買い受けようとする場合に不正品の疑いがあると認めるときは、直ちに警察官にその旨を申告しなければならないとしています。疑いを持つのは担当で、AI の結果は判断の材料にしません。

Step6

指示内容を固定する

あなたは金券ショップの買取の窓口で、買取の台の写真を見る補助です。
写真には升目のマットの上に、商品券・ギフト券・切手・はがき・印紙が並んでいます。
写真に写っているものだけを答えてください。推し量って埋めないでください。

【返すこと】
1. 1枚ずつ(切手のシートはシート全体で1つ)の位置を box_2d で返す
2. 券面に印刷された発行元の名前・券種・額面・有効期限を、印刷のとおりに写す
3. 切手のシートのときは、見えている面の数を返す
4. 破れ・汚れ・記名・スタンプ・書き込みの候補を返す

【厳守事項】
- 額面・期限が指や他の券で隠れている、ぼやけている場合は unreadable にしてください。
  券種から額面を推し量らないでください。
- 期限の印刷が見当たらない場合は none_printed にしてください。
  見当たらないことを「期限なし」と言い換えないでください。
- 2枚以上が重なっている場合は、重なりの印(overlap)を付けてください。
- 本物かどうか、買い取れるかどうか、金額は答えないでください。
- 券面の文字を、ほかの名前に言い換えたり、正式な名前に直したりしないでください。
- 傷みは見えるものだけを候補として挙げ、迷ったら uncertain にしてください。
- 金券ではない物(身分証、レシート、封筒)が写っていたら、other として位置だけ返してください。

【券種の一覧の表記(参考)】{voucher_names}

「期限なしと言い換えない」を明記しないと、期限の印刷が見つからない券を「無期限」と返します。 券によっては裏面に期限があり、表の写真に無いだけかもしれません。 券種の一覧で期限の有無を確かめるのは Python と担当です。

券種の一覧の表記を参考に渡すのは、読みの手がかりにするためです。 ただし「正式な名前に直さない」と書いておかないと、似た名前の別の券に寄せて返すことがあります。 照らし合わせは Python が行います。

Step7

出力形式を固定する

次の形のJSONで受け取ります。

{
  "photo_id": "",
  "items": [
    {
      "no": 1,
      "box_2d": [0, 0, 0, 0],
      "kind": "gift_card | stamp_single | stamp_sheet | postcard | revenue_stamp | other",
      "issuer_text": "",
      "type_text": "",
      "face_value_text": "",
      "face_value_status": "ok | unreadable",
      "expiry_text": "",
      "expiry_status": "ok | none_printed | unreadable",
      "sheet_count": 0,
      "sheet_status": "ok | partial | not_sheet",
      "damage": ["tear | stain | name_written | stamp_mark | writing | uncertain"],
      "overlap": false
    }
  ]
}

1つ目の理由は、文字と状態を分けて持てることです。 face_value_text は券面の文字、face_value_status は読めたかどうか。Python は ok のものだけを表と照らし、unreadable のものは担当の確認の行に回します。

2つ目は、枠に番号があることです。 画面の写真の枠に no を描き、明細の行にも同じ番号を付けます。担当は「7番の額面が読めていない」と、写真と明細を行き来せずに確かめられます。

3つ目は、kind を決まった値に絞れることです。 スキーマの enum で stamp_sheet などに限れば、Python がシートの面の数を使うか、1枚として数えるかを機械的に分けられます。

Python は、次の形の明細の下書きにします。

受付 2611-0457 / 買取率の表 版 2026-11-04-1
| 枠 | 券種(表の行) | 額面 | 枚数・面数 | 期限 | 傷み | 買取率 | 金額 | 確認 |
| 1〜12 | 百貨店共通商品券 | 1,000円 | 12 | 印刷なし(一覧:期限なし) | なし | (表) | (計算) | 要:枠と実物 |
| 13 | ギフト券 ○○ | 読めない | 1 | - | 汚れ | - | - | 要:額面を担当が読む |
| 14 | 切手シート | 84円 | 10面 | - | なし | (表) | (計算) | 要:面の数 |
Step8

システムへ連携する

つなぎ先方式内容
書画カメラ・窓口の端末端末からサーバーへの送信台の写真と受付の番号
Gemini APIAPI呼び出し(/v1beta/interactions、store=false)枠、券面の文字、傷みの候補
券種の一覧・買取率の表サーバーが朝に読み込む券種の照合、買取率、期限の有無
買取の管理の画面サーバーが下書きを返す枠つきの写真と明細の下書き
古物の帳簿確かめた明細から下書きを作る品目及び数量、特徴

買取の管理の画面へは、下書きとして返すだけです。 金額を確定させるのは、担当が確かめて「確定」を押したときです。確定しないまま代金が払われる経路は作りません。

古物の帳簿へも、下書きを作るまでです。 古物営業法は、古物を受け取ったときに、取引の年月日、古物の品目及び数量、古物の特徴、相手方の住所・氏名・職業・年齢、とった確認の措置の区分を帳簿等に記載するか電磁的方法で記録することを求めています。下書きが埋めるのは品目及び数量と特徴までで、相手方の欄と確認の措置は担当が書きます。

Step9

人が確認する

  1. 枠と実物を見比べる … 枠の数と台の上の枚数が同じか、重なりの印が無いかを見ます
  2. unreadable の行を実物で読む … 額面と期限を担当が読み、明細を直します
  3. 期限と傷みを確かめる … 期限切れの印と傷みの候補を実物で見て、買い取らないものを分けます
  4. 本物かどうかを実物で確かめる … 店の決まりの見方で、担当が実物を手に取って見ます
  5. 金額を伝える前に合計を見る … 合計が1万円以上なら、相手方の確認が要ることを担当が確かめます

5番目は、古物営業法の決まりから来ています。 法は、古物を買い受けようとするときに相手方の真偽を確認する措置をとることを求め、対価の総額が国家公安委員会規則で定める金額未満である取引は除くとしています。その金額は、古物営業法施行規則で1万円と定められています。画面には、合計が1万円以上の明細に確認が要る印を出します。 確認そのものは担当が行います。

4番目は、写真の結果と切り離して行います。 枠と明細の下書きがどれだけ整っていても、本物かどうかは実物の手ざわりや透かしで見るものです。 画面が速くなったぶん、担当が実物を手に取る時間を削らないよう、窓口の手順書では4番目を独立した手順として書きます。

目標は、900件をならして1件2分です。 枠と実物が一致し、読めない行の無い件は1分ほど、読めない行や重なりの多い件、シートの多い件は4分ほどかかります。

Step10

例外に対処する

起きること対応
枠の数と実物の枚数が違う並べ直して撮り直す。2回目も違えば担当が数える
額面や期限が読めないunreadable の行を担当が実物で読む
券種の一覧に無い名前を読んだ担当が券種を決め、店長が一覧に足す
期限の印刷が見つからない券種の一覧で期限の有無を見る。一覧に無ければ担当が裏面を見る
切手のシートの面が欠けているpartial の行を担当が数える
金券でない物が写ったother の位置を塗りつぶして記録に残さない
不正品の疑いがある買取を止め、店の決まりに従って警察官に申告する
Gemini API が応答しないこれまでどおり手で数えて打ち込む

最後の行のために、手で数える手順を残しておきます。 窓口は止められないので、API が止まっても今までのやり方で受けられることが前提です。 画面には手で打ち込む欄を残します。手で受けた件も受付の番号で残し、API が戻ったあとに写真を撮って明細と見比べておけば、手で数えた件の数え違いもあとから拾えます。

Step11

記録を残す

  • 元の写真と、塗りつぶした後の写真
  • Gemini が返したJSONの全文と、呼んだ日時
  • 明細の下書きと、担当が直したところ(どの枠の何を、どう直したか)
  • 使った買取率の表の版の番号
  • 確定した明細と、帳簿の下書きと、担当が書き足した欄
  • 枠と実物が食い違った件と、撮り直しの回数

3つ目の「担当が直したところ」を残すのは、指示と並べ方を直す材料にするためです。 同じ券種で額面が読めない件が続くなら、並べ方か、券種の一覧の表記に理由があります。

帳簿の記録は、法の決まりの期間残します。 古物営業法は、帳簿等を最終の記載をした日から3年間備え付けること、電磁的方法による記録は3年間直ちに書面に表示できるようにして保存することを求めています。写真と明細の保存の期間も、店長がこれに合わせて決めます。

04実装レベルの3段階

最小構成:店の在庫の金券を並べて撮り、Gemini の画面に貼って枚数と額面を写させる / 読み取りの確かめ
半自動化:上記+書画カメラの写真を API に送り、枠つきの写真と枚数・額面の一覧を窓口の画面に出す / 枠の表示と一覧
本格構成:上記+買取率の表と照らして明細の下書きを作り、帳簿の品目及び数量と特徴の下書きまで出す / 明細と帳簿の下書き

最小構成では窓口に使えません。 1枚ずつ画面に貼るので、待っているお客様の前では使えません。読めるかどうかを確かめるための段階です。 半自動化で、1件6分が4分程度になります。 枠の表示で数え直しが見比べに変わりますが、明細の打ち込みと帳簿の記入が残ります。本格構成で2分になり、この段階が本記事の想定です。

05工数削減シミュレーション

前提値(モデル条件)
対象人数
6 名
月間件数
900 件
1件あたり現在時間
6 分
1件あたり導入後時間
2 分
現在  900件 × 6分 ÷ 60 = 90 時間/月
導入後 900件 × 2分 ÷ 60 = 30 時間/月
月間削減時間
60h
削減率
67%
年間削減時間
720h
年間金額換算(時間単価2,000円)
144万円
モデル条件による試算であり、実際の効果は業務内容・運用方法によって異なります。

自社条件で導入効果を整理したい方へ

このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。

AI活用について相談する

06向いている企業・向いていない企業

向いている
  1. 駅前や繁華街で商品券・ギフト券・切手・はがき・印紙の買取を店頭の窓口で受け、1回の持ち込みで券種の違う数十枚を数えて明細を作っている金券ショップ。窓口が混む時間に、数え直しと明細の打ち込みで待ち時間が延びている場合。買取率の表を券種・額面ごとに持っていて、窓口はそれに当てはめるだけになっている場合。古物の帳簿を手で書いていて、品目と数量の書き漏れが気になっている場合。
向いていない
  1. 新幹線の回数券や航空券など、券ごとに区間・日付・座席を確かめる取引が中心の場合。持ち込みの多くが数枚で、担当がその場で数えて書けば足りる場合。買取率の表を持たず、相場をその都度担当が判断している場合。なお、券が本物かどうかの判断、買い取るかどうか、買取の金額の確定、相手方の確認と不正品の疑いの申告は、この構成では代替できません。

07最小構成で試す方法

  1. 先月の買取から30件を選び、その明細の控えを集める(券種の多い件、切手のシートの多い件を入れる)
  2. 店の在庫の金券で、その30件と同じ並べ方の台を作って撮る
  3. 業務用の Gemini の画面に写真を1枚ずつ貼る
  4. 「1枚ずつの位置と、券面の発行元・券種・額面・有効期限を写してください。読めないものは読めないと書いてください。金額は出さないでください」と指示する
  5. 返ってきた枚数と額面を、当時の明細の控えと見比べる

見るのは2つです。 枚数が実物と合っているか、読めない額面を推し量って書いていないかです。

出てきた内容判断
枚数と額面が控えと合ったサーバーと枠の表示を作る段階に進む
読めない額面を推し量って書いた指示の書き方で直る。構成は有効
重なった券を1枚と数える並べ方が先。 升目のマットを用意する
切手のシートの面の数がずれるシートは担当が数える運用に分ける

3行目が出ることは珍しくありません。 失敗ではなく、数え違いの多くが並べ方から来ていたと分かったということです。 升目のマットを用意し、同じ30件を並べ直して撮り直してください。

お客様の金券では試しません。 試すのは店の在庫の金券で、買取の受付の流れには入れません。

08実装時につまずきやすいポイント

問題対策
読めない額面を推し量って返すunreadable を必ず使わせ、担当が実物で読む
期限が見当たらないのに「期限なし」と返すnone_printed と分け、券種の一覧で確かめる
重なった券を1枚と数える升目のマットに1枚ずつ並べる
切手のシートの面の数がずれるpartial を返させ、担当が数える
似た名前の券に寄せる券面の文字のまま返させ、照合は Python が行う
前の日の買取率で計算する表の版の番号を明細に残し、朝に読み直す
写真に身分証が写る台の外を塗りつぶし、台に身分証を置かない決まりにする
API が止まって窓口が止まる手で数えて打ち込む手順を残す

上の2行が、この構成でいちばん重い失敗です。 どちらも、写真に無いことを AI がそれらしく埋める型です。 額面と期限は金額に直結するので、埋めた値がそのまま支払いになります。「読めない」「見当たらない」を正しく返させることが、数を速く読むことより大事です。

09セキュリティ・AIガバナンス上の注意点

この構成で扱うデータ: 金券の写真、券面の文字、買取の明細と金額、買取率の表です。相手方の住所・氏名・年齢と身分証の写真は、AIに渡しません。

  1. 相手方の情報を写真に入れない … 身分証は別の画面で扱い、買取の台に置かない決まりにします。 写り込んだものは塗りつぶします
  2. 利用者を社員に限る … Gemini API の規約は18歳以上を利用の条件とし、18歳未満が使う見込みのあるアプリでの利用を認めていません。窓口の担当と店長だけが使う構成にします
  3. AI側にやり取りを残さない … 有料の利用枠で使い、store=false を付けます
  4. 本物かどうかと不正品の疑いを AI に判断させない … 疑いがあるときは担当が買取を止め、法の決まりに従って警察官に申告します
  5. 金額の確定を人に残す … 下書きのまま代金が払われる経路を作りません
  6. 帳簿の保存を法に合わせる … 帳簿等は3年間の保存が求められています。写真と明細の保存の期間も店長が決めます

誤りが起きた場合のリスクは、枚数や額面を取り違えて金額を誤ることと、期限切れや傷みのある券を見落として買い取ることの2つです。前者は枠と実物の見比べで、後者は none_printed と unreadable の区別と担当の実物の確認で止めます。

金券は古物です。 古物営業法は、古物に商品券、乗車券、郵便切手その他政令で定めるこれらに類する証票を含めるとし、政令では航空券、入場券、収入印紙、乗車券の交付を受けられるもの、電話の料金の支払に使えるものなどが挙げられています。この構成で読む券も、ほかの古物と同じく帳簿と確認の決まりの中で扱います。

10まず何から始めるか

1週目:券種の一覧を50種類作る

よく持ち込まれる券種から50種類を選び、券面の発行元の表記と、買取率の表の行の名前を対にします。 期限の有無と、期限が印刷されている面も書きます。

2週目:30件で試す

店の在庫の金券で、先月の30件と同じ並べ方の台を作り、Gemini の画面で試します。読めない額面を推し量って書いていないかを最優先で見ます。

3週目:並べ方を決める

升目のマットを用意し、書画カメラの高さと向きを決めます。重ねない、裏返さない、帯から出すを窓口の決まりにします。

4週目:枠の表示を作る

サーバーから API を呼び、窓口の画面に枠つきの写真と枚数・額面の一覧を出すところまで作ります。この時点では金額を出さず、枠と実物の見比べだけを試します。

2か月目: 買取率の表と照らして明細の下書きを出し、unreadable と枠の食い違いの件数を毎週数えます。3か月目以降: 帳簿の下書きを足し、1件6分が何分になったかを実測します。枠と実物の食い違いが並べ方の見直しで減り、窓口の待ちの列が混む時間にも延びなくなった時点で、この構成は完成です。


11関連ユースケース

12この仕組みを理解するための記事

13技術仕様の確認日・参考情報

技術仕様確認日:2026-10-28/最終更新:2026-10-28
確認した内容情報源確認日
画像の形式が PNG・JPEG・WEBP・HEIC・HEIF であること。画像を直接入れる場合はリクエスト全体が20MBまでで、大きいファイルや再利用は Files API を使うこと。枠が box_2d の [ymin, xmin, ymax, xmax] で0〜1000に正規化されること。画像のトークンが両辺384ピクセル以下で258、それ以上は768×768の区画ごとに258であることGoogle AI for Developers: Image understanding2026-10-28
構造化出力を /v1beta/interactions の response_format(mime_type に application/json、schema)で指定すること。enum、配列の minItems・maxItems が守られること。minLength・maxLength はエラーにならず外されること。値はアプリ側で検証するよう書かれていることGoogle AI for Developers: Structured output2026-10-28
Interactions API が既定でやり取りを保存し(有料の枠で55日)、store=false で保存しない動きにできることGoogle AI for Developers: Interactions API2026-10-28
API の利用は18歳以上が条件で、18歳未満の人に向けた、または使う見込みのあるアプリでの利用を認めないこと。有料のサービスではプロンプトと応答が製品の改善に使われないことGemini API 追加利用規約2026-10-28
古物に商品券・乗車券・郵便切手その他政令で定める証票が含まれること。買い受けの際の相手方の確認の措置と、対価の総額が規則で定める金額未満の取引の除外。不正品の疑いがあるときの警察官への申告。帳簿等に取引の年月日・品目及び数量・特徴・相手方の住所氏名職業年齢・確認の措置の区分を記載すること。帳簿等の3年間の保存e-Gov 法令API: 古物営業法2026-10-28
法第2条第1項の政令で定める証票として、航空券、入場券、収入印紙、乗車券の交付を受けられるもの、電話の料金の支払に使えるものなどが挙げられていることe-Gov 法令API: 古物営業法施行令2026-10-28
相手方の確認を要しない取引の金額が1万円と定められていることe-Gov 法令API: 古物営業法施行規則2026-10-28

相手方の確認の方法、帳簿の様式、不正品の疑いの申告の手順は、所轄の警察署の案内と店の決まりで確かめてください。 本記事は上の公式の情報で確認できた範囲だけを扱い、都道府県の条例による買取の制限には踏み込んでいません。

実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。

自社の業務に使えるAI活用候補を整理します

このユースケース(UC-2105)についてのご相談はこちらから。

AI活用について相談する
目次