館内の忘れ物を写真と特徴で台帳にして、宿泊客からの問い合わせと照合する

処理の起点を決める

起点は2つあります。忘れ物の登録と、問い合わせの受付です。 どちらも AppSheet のテーブルに行が追加されたことをきっかけに、オートメーションから Apps Script を呼びます。

1つ目の登録は、見つけた人がその場で行います。 清掃スタッフなら客室で、宴会場なら片付けのときに、アプリで場所を選んで写真を撮ります。フロントへ届けてから登録する形にはしません。 届ける前に登録しておけば、宴会の事務所に数日置かれたままの品も台帳に載ります。第3章の（c）を、登録の場所で解きます。

2つ目の問い合わせは、フロントの担当者が受けたときに入力します。電話でもメールでも、担当者が問い合わせの画面に入力するところから同じ流れにします。 メールをそのまま取り込む形は、最初は作りません。客の説明が長く、宿泊日や部屋番号が書かれていないことが多いため、担当者が聞き取って入力するほうが、照合の材料がそろいます。

3つ目に、毎朝決まった時刻に、提出期限の近い品を一覧にする処理を置きます。これは Apps Script の時間で動くトリガーで動かします。

入力データを集める

質を決めるのは、いちばん下の品目の一覧です。 AIに自由に品名を書かせると、「充電ケーブル」「USBケーブル」「スマホの充電器」と、また人が書いたときと同じばらつきが出ます。種類は一覧から選ばせ、一覧に無いものだけ「その他」にします。

撮る写真の決まりも入力データの一部です。 1枚目は全体、2枚目は目印（傷、ステッカー、キーホルダー）、3枚目は文字（ブランド名、名入れ）。「全体だけ」の写真では、似た品が並んだときに区別する材料が残りません。

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

写真は、AppSheet が保存した Google ドライブのファイルを Apps Script から読みます。 Call a script の引数に、行のキーと写真のパスを式で渡します。Apps Script はドライブからファイルを取り出し、Gemini API のリクエストに画像として入れます。

問い合わせのときは、先に Apps Script の側で候補を絞ります。 宿泊日の前日から3日後までに見つかったもの、場所が同じ部屋か同じ宴会場のもの、状態が「保管中」のもの。絞った候補の特徴の文だけを Gemini API に渡し、写真は渡しません。 写真は担当者の画面に出すためのもので、照らし合わせは確定済みの特徴の文で行います。

日付と場所の条件を広げる規則も決めておきます。 候補が0件なら、日付を前後7日に、場所を同じ階に広げてもう一度絞ります。「部屋だと思ったがロビーだったかもしれない」という問い合わせは珍しくありません。 広げた条件で出た候補には、その旨の印を付けます。

AIへ渡す前に整形する

1. 写真の枚数と向きの確認 … 1枚も無い行は処理せず、登録した人へ撮り直しを求めます。向きが横倒しの写真は回転させます
2. 大きさの確認 … 写真と指示の文を合わせて20MBを超えないかを見ます。超える場合は縮小するか、Files API を使います
3. 写ってはいけないものの確認 … 財布の中身、カードの表面、身分証が写っている写真は、Gemini API に渡さずに担当者へ戻します
4. 品目の一覧の読み込み … 種類の選択肢として、最新の一覧を指示に入れます
5. 問い合わせの日付の正規化 … 「先週の土曜」のような言い方は、担当者が入力の時点で日付に直します
6. 候補の件数の確認 … 絞った候補が30件を超えるときは、種類で先に絞ってから渡します

3番目を軽く見ないでください。 財布や定期入れは、中身を確かめる途中で写真を撮りがちです。カードの番号や身分証の氏名が写った写真を外部のAPIへ送る理由は、この業務にはありません。 財布は外側だけを撮る決まりにし、中身は人が金額と枚数を記録します。

1番目の向きの確認は、Gemini API のドキュメントにもベストプラクティスとして書かれています。 画像が正しく回転しているかを確かめ、ぼやけていない画像を使うこととされています。

AIに処理させる

させることは2つです。写真から特徴を書き出すことと、問い合わせの説明と候補を照らし合わせることです。

1つ目の書き出しで返させる項目：

2つ目の照らし合わせで返させる項目： 候補ごとに、客の説明の要素（種類、色、目印など）が一致するか、食い違うか、説明に無いかを1つずつ付け、全体の一致の度合いを high ／ medium ／ low で返させます。

3行目がいちばん起きやすい失敗です。 傘の持ち手に「TAN」までしか見えないとき、AIはよく知られたブランド名に補って書こうとします。補った名前が台帳に入ると、客が本当の名前で問い合わせたときに一致しません。

最後の行も大事です。 客の説明は不正確なことが多く、「黒」と言われた品が実際は濃紺ということがあります。一致の度合いの低い候補も、順番を下げて残します。

指示内容を固定する

1つ目（写真からの書き出し）の指示：

あなたはホテルの遺失物の担当です。忘れ物の写真から、台帳に載せる特徴を書き出してください。
写真に写っていることだけを書いてください。推測で埋めないでください。

【書き出す項目】
- 種類：次の一覧から1つ選ぶ。当てはまらなければ other とし、other_name に書く
  {item_categories}
- 色：主な色と2番目の色。照明で色が判断しにくい場合は color_uncertain を true に
- 柄・素材：見て分かる範囲。分からなければ空欄
- 写っている文字：ブランド名・型番・名入れを、写っているとおりに写す
- 目印：傷、ステッカー、キーホルダー、付属品
- 大きさの目安：small / medium / large。比べる物が無ければ空欄

【厳守事項】
- 文字が一部しか読めない場合は、読める部分だけを写し、読めない部分は「?」にしてください。
  知っているブランド名や製品名に補わないでください。
- 「高級そう」「新品のよう」「子ども用と思われる」など、写真から言えない評価を書かないでください。
- 金額や価値を書かないでください。
- 写真にカードの番号、身分証、書類の中身が写っている場合は、それを書き出さず、
  sensitive_detected を true にしてください。
- 複数の品が1つの写真に写っている場合は、multiple_items を true にしてください。
- 各項目の根拠がどの写真か（1枚目・2枚目・3枚目）を evidence_photo に書いてください。

【見つけた場所】{location}

2つ目（問い合わせとの照らし合わせ）の指示：

あなたはホテルの遺失物の担当です。宿泊客の説明と、台帳の候補を照らし合わせてください。
持ち主かどうかは判断しないでください。候補の順番を付けるだけです。

【やること】
- 客の説明を、種類・色・柄・文字・目印・大きさ に分けてください。
- 候補ごとに、各要素を match（一致）/ conflict（食い違う）/ not_mentioned（説明に無い）で付けてください。
- 全体の一致の度合いを high / medium / low で付けてください。
- 色は近い色（黒と濃紺、白と生成り）を conflict にせず、near として扱ってください。

【厳守事項】
- 候補を除外しないでください。一致の度合いが低くても、すべての候補に結果を返してください。
- 客の説明に無い特徴を、候補に合わせて補わないでください。
- 担当者が客に確かめるための質問を、ask_guest に2つまで書いてください。
  候補の特徴を答えとして含む質問（「持ち手は赤ですか」）にせず、
  客に答えてもらう質問（「持ち手の色を教えてください」）にしてください。

【客の説明】{inquiry_text}
【候補】{candidates}

「候補の特徴を答えとして含む質問にしない」を明記しないと、AIは親切に「持ち手に赤いテープはありますか」と書きます。 担当者がそのまま読み上げれば、持ち主でない人にも答えを教えることになります。 禁じるのは、確かめる質問の形そのものです。

出力形式を固定する

Gemini API の構造化出力で、スキーマを渡してJSONで受け取ります。 出力の形式にJSONを指定してスキーマを渡すと、構文上正しいJSONが返ります。スキーマでは properties、required、enum などが使えます。

1つ目（書き出し）：

{
  "category": "umbrella",
  "other_name": "",
  "color_main": "black",
  "color_sub": "red",
  "color_uncertain": false,
  "pattern": "無地",
  "text_on_item": "TAN?",
  "marks": ["持ち手に赤いテープ"],
  "size": "medium",
  "evidence_photo": { "color_main": 1, "marks": 2, "text_on_item": 3 },
  "sensitive_detected": false,
  "multiple_items": false
}

2つ目（照らし合わせ）：

{
  "inquiry_parsed": { "category": "umbrella", "color": "black", "marks": "", "text": "" },
  "candidates": [
    { "item_id": "", "score": "high | medium | low",
      "elements": [ { "element": "color", "result": "match | near | conflict | not_mentioned" } ] }
  ],
  "ask_guest": ["", ""]
}

1つ目の理由は、category を enum で縛れることです。 種類の値を品目の一覧に限れば、台帳の検索で同じ種類がばらばらの名前で出ることがなくなります。 第3章の（a）は、この1行で半分解けます。

2つ目は、elements で一致の中身が見えることです。 担当者は high の一言ではなく、色は一致、目印は説明に無い、という内訳を見て客に何を聞くかを決めます。

3つ目は、値をアプリの側で確かめられることです。 Gemini API のドキュメントでは、構文上は正しくても値の意味が正しいとは限らないため、アプリケーションの側で値を検証するよう書かれています。item_id が候補に無い値なら捨て、候補の数と結果の数が合わなければやり直します。

システムへ連携する

台帳の「確定した特徴」の列は、Apps Script から書きません。 Apps Script が書くのは「AIの書き出し」の列までで、担当者が現物と見比べて直したものを「確定」の列に入れます。 照合に使うのは確定の列だけです。AIの書き出しをそのまま確定にすると、照明で紺に見えた黒い傘は、黒で問い合わせても一致しなくなります。

「持ち主でなければ言えない特徴」の列も、Gemini API には渡しません。 財布の中身、鍵に付いたタグの文字、衣類のポケットに入っていた物。担当者が客に言ってもらい、画面と見比べるための列です。

提出期限は、見つけた日から計算して台帳の列に入れます。 神奈川県警察のページでは、施設占有者は交付を受け、または自ら拾得してから1週間以内に警察署長へ提出する必要があり、期限内に提出しないと拾得物件に係る権利を失うとされています。期限の日数は自施設の区分に合わせ、所轄の警察署に確かめてから設定します。

人が確認する

人が確かめるのは3か所です。登録の確定、持ち主の確認、提出の準備です。

1. 登録の確定 … 現物を受け取ったとき、AIの書き出しを現物と見比べて直し、確定の列に入れます。持ち主でなければ言えない特徴をここで書き足します
2. 持ち主の確認 … 候補の写真を見ながら、ask_guest の質問で客に特徴を言ってもらいます。確定の特徴と、持ち主でなければ言えない特徴の両方が合ったときだけ、返却へ進みます
3. 提出の準備 … 期限の近い品の一覧を見て、問い合わせの途中の品が無いかを確かめてから、提出の書類を作ります

2番目では、候補の特徴を先に言いません。 「黒い傘が1本ありますが」と言ってしまうと、それだけで答えが伝わります。「どんな傘でしたか」から始めます。

3番目は、返却の手配中の品を提出してしまわないための確認です。 客と連絡がついて発送を待っている品は、状態を「返却手配中」にして一覧から外します。

例外に対処する

上から3行目までは、撮り方の決まりで減ります。 財布は外側だけ、1枚に1品、文字は寄りで。AIの精度を上げるより、撮り方を1枚の紙にして部署に配るほうが効きます。

6行目を守ってください。 一致の度合いが低いという理由で「ございません」と答えると、棚にある品を返せなくなります。 答えるのは、担当者が候補を見てからです。

記録を残す

• 登録した写真、見つけた日時・場所・見つけた人
• Gemini API が返した書き出しのJSONと、担当者が確定させた特徴との差
• 問い合わせの内容、照らし合わせの結果、担当者が見た候補
• 持ち主と確認した根拠 … どの特徴が合ったか
• 返却の方法と日時、または警察へ提出した日時
• 撮り直しを求めた件数と理由

2つ目の差は、書き出しの傾向を見る材料です。 色を毎回直しているなら照明の問題、種類を直しているなら品目の一覧の問題です。直す場所が、指示文なのか撮影の環境なのかが分かります。

4つ目は、返した後で「自分の物ではなかった」と言われたときに使います。 どの特徴を確かめて渡したかが残っていれば、確認のやり方のどこに穴があったかを後から見直せます。