空港の遺失物の窓口が、利用者から届く遺失物の問い合わせを拾得物の台帳と OpenSearch で照らし、特徴の近い拾得物の候補を出す

処理の起点を決める

起点は3つあります。15分ごとの台帳の取り込み、問い合わせの受信、担当者の検索のボタンです。

台帳の取り込みは、遺失物の管理の仕組みから、前回から増えた拾得物と状態の変わった拾得物（引渡し済み・警察署長へ提出済み・保管の場所の移動）を書き出して索引を更新します。引渡し済みの拾得物が候補に出続けると、すでに持ち主に返ったものを「ございます」と答えることになります。 返事の前に、候補の状態だけは管理の仕組みに照会し直します。

問い合わせの受信は、フォームの送信と共有のメールボックスへの到着です。電話は担当者がメモを打ち込んでからボタンを押します。 電話の録音を文字にして自動で流す形にはしません。聞き取りの途中で担当者が聞き返した答えが、メモにしか残らないためです。

照らし直しは、取り込みのたびに動かします。 「照らし直し待ち」の問い合わせのうち、なくした日から30日以内のものだけに、新しく入った拾得物を相手にした同じ検索をかけます。

入力データを集める

質を決めるのは、拾った担当が書く特徴の文です。 「黒いかばん」とだけ書かれた拾得物は、どれだけ検索を工夫しても B より上がりません。ブランドの刻印、ファスナーの色、付いているキーホルダーなど、見て分かることを書く決まりが、この構成の土台です。

本人確認用の特徴は、索引に入れません。 索引に入れれば検索に当たり、候補の説明として画面や下書きに出てきます。担当者が候補を開いたときに、管理の仕組みの側で見るだけにします。

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

2つの検索の点数は、そのままでは足せません。 OpenSearch の公式のドキュメントでは、hybrid クエリは複数のクエリの関連度の点数を1つにまとめるもので、検索パイプラインで点数をそろえて合わせるとされています。normalization-processor の既定は min_max（各クエリの点数を0〜1にそろえる）と arithmetic_mean で、weights は合計が1.0になるように指定します。

PUT /_search/pipeline/lost-item-hybrid
{
  "phase_results_processors": [
    { "normalization-processor": {
        "normalization": { "technique": "min_max" },
        "combination": { "technique": "arithmetic_mean",
                         "parameters": { "weights": [0.4, 0.6] } } } }
  ]
}

GET /found_items/_search?search_pipeline=lost-item-hybrid
{
  "size": 20,
  "query": {
    "hybrid": {
      "queries": [
        { "match": { "description": "黒 リュック 保安検査場 ノートパソコン" } },
        { "knn": { "description_vec": { "vector": [0.012, -0.044], "k": 50 } } }
      ],
      "filter": { "bool": { "filter": [
        { "range": { "found_at": { "gte": "2026-10-19", "lte": "2026-10-27" } } },
        { "terms": { "status": ["stored", "submitted_to_police"] } } ] } }
    }
  }
}

hybrid クエリはいちばん外側に置きます。 公式のドキュメントでは、hybrid クエリは function_score や constant_score などの複合クエリの中に入れられないとされています。新しい拾得物の点数を上げたくなっても、hybrid の中では行わず、取り出した後に規則で並べ替えます。 1つの hybrid に入れられるクエリは5つまでで、filter はすべてのクエリにかかります。

knn の filter を別に書かないのは、hybrid の filter で足りるからです。 k-NN の公式のドキュメントでは、knn の filter は faiss か lucene のエンジンでだけ使えるとされています。索引を作るときのエンジンの選び方と合わせて確かめます。

AIへ渡す前に整形する

1. 品目の分類をそろえる … 台帳の品目を、品目の分類の表で社内の分類（bag、wallet、device など）に置き換えて category に入れます。表に無い品目は category を空にして残します
2. 色をそろえる … 「黒系」「ブラック」「黒」を black に、「紺」「ネイビー」を navy にします。「暗い色」のような書き方は、値を入れずに説明の文に残します
3. 区域をそろえる … 拾得の場所を区域の表で security、gate_area、baggage_claim などにします
4. 検索用の文を作る … 品目・色・ブランド・特徴の文をつないだ1つの文にし、本人確認用の特徴は入れません
5. ベクトルにする … 検索用の文を Titan Text Embeddings V2 に渡し、1,024次元のベクトルを description_vec に入れます
6. 問い合わせから個人の情報を外す … 名前、電話番号、メールアドレス、住所は、Claude に渡す前に伏せます

2番目で、空の色に推測の値を入れないでください。 「暗い色」を black にすると、紺の問い合わせで出なくなります。分からない値は空のまま残し、規則で「記録なし」にします。

AIに処理させる

AIの仕事は2つです。 問い合わせを探す条件と日本語の検索文に読み替えることと、規則で照らした候補を台帳の記録のまま並べ、聞き返しの下書きを書くことです。

「候補の特徴を利用者向けの文に書かない」が、この構成でいちばん大事な線です。 「黒いリュックで、青いキーホルダーが付いたものがございます」と返せば、次に問い合わせてきた人は青いキーホルダーと言うだけで本人になれます。 聞き返しは「かばんの中身と、付いている飾りの色をお知らせください」の形にします。

指示内容を固定する

1回目（問い合わせの読み替え）の指示です。

あなたは空港の旅客ターミナルビルの遺失物の窓口で、問い合わせを整理する立場です。
【問い合わせ】から、拾得物の台帳を探すための条件を取り出してください。

【取り出すもの】
- language: 問い合わせの言語
- item / color / brand / features: 書かれたまま（原文の言語のまま）
- lost_date_raw / lost_place_raw / flight_no: 書かれたまま
- query_ja: 品目・色・ブランド・特徴をつないだ日本語の検索文
- item_variants_ja: 品目の別の言い方の候補（日本語）
- missing: 書かれていない項目の名前

【厳守事項】
- 書かれていない日付・場所・便名を補わないでください。
- ブランド名は原文の綴りのまま写し、日本語の検索文にも原文の綴りで入れてください。
- 色は書かれた色だけを訳し、似た色を足さないでください。
- 場所を空港の区域の名前に置き換えないでください。書かれたまま写してください。
- 名前・電話番号・メールアドレス・住所は写さないでください。

【問い合わせ】{inquiry_text}

2回目（候補の一覧と聞き返しの下書き）の指示です。

あなたは空港の遺失物の窓口で、担当者が使う候補の一覧と、利用者への返事の下書きを作る立場です。
【候補】は拾得物の台帳の記録と、規則で照らした結果と、近さの段階です。

【担当者向けの一覧】
- 候補ごとに、管理番号・品目・色・拾得の日時と区域・保管の場所・近さの段階を、台帳の記録のまま書いてください。
- 一致した項目と、記録なしの項目を分けて書いてください。

【利用者への下書き】
- 問い合わせの言語で書いてください。
- 候補があるときは「お問い合わせの内容に近いお品物があるか確認しています」とだけ書き、
  本人の確認のために聞き返す項目を2〜3個書いてください（中身、付属品、名入れなど）。
- 候補が無いときは、引き続き確認する旨と、機内の場合は航空会社の窓口になる旨を書いてください。

【厳守事項】
- 利用者への下書きに、候補の色・ブランド・特徴・付属品・保管の場所を書かないでください。
- 「お客様のお品物です」「見つかりました」と言い切らないでください。
- 送付・引取り・費用の約束を書かないでください。
- 台帳の記録に無い特徴を書かないでください。

【問い合わせの条件】{conditions}
【候補】{candidates}

「利用者への下書きに候補の特徴を書かない」を明記しないと、AIは親切のつもりで候補の説明を返事に書きます。 利用者に安心してもらうための一文が、本人の確認を崩します。 聞き返す項目だけを書かせ、特徴は担当者向けの一覧にだけ置きます。

出力形式を固定する

Bedrock の Converse API の outputConfig.textFormat に JSON スキーマを渡し、2回目は次の形で受け取ります。

{
  "inquiry_no": "",
  "candidates": [
    { "item_no": "",
      "level": "A | B | C",
      "match": { "category": "match | mismatch | not_recorded",
                 "color": "match | mismatch | not_recorded",
                 "area": "match | mismatch | not_recorded" },
      "listed": { "item": "", "color": "", "found_at": "", "area": "", "storage": "" } }
  ],
  "verify_questions": [""],
  "reply_draft": "",
  "reply_language": ""
}

AWS の公式ページでは、outputConfig.textFormat に JSON スキーマを渡すと応答がスキーマに沿い、enum が使えます。すべての object に additionalProperties: false が要り、数値の minimum・maximum には対応していません。新しいスキーマは最初の呼び出しで組み立てに最大90秒ほどかかり、24時間キャッシュされるので、最初の呼び出しの待ち時間を120秒以上にしておきます。 level と match は Lambda の規則の結果を写させ、AIには決めさせません。

1つ目の理由は、reply_draft を機械で検査できることです。 下書きに候補の listed の色・ブランド・保管の場所の文字列が含まれていないかを Lambda で調べ、含まれていれば下書きを捨てて担当者に知らせます。 本人確認の線は、指示だけでなく検査でも守ります。

2つ目は、listed を台帳と照合できることです。 値が台帳と違えば作り直します。

システムへ連携する

返事は担当者が送ります。 下書きを自動で送る経路を作りません。

人が確認する

1. 読み替えを見る … 品目・色・日付・場所が問い合わせのとおりに取り出されているかを確かめます
2. 候補を現物か写真で確かめる … 段階が A でも、保管庫の現物か写真を見てから返事をします
3. 聞き返しの答えで本人を確かめる … 管理の仕組みの本人確認用の特徴と、利用者の答えを担当者が照らします
4. 引渡しと送付は担当者が決める … 引取りのときの本人確認、送付の方法は、いつもの手順で行います
5. 警察署長へ提出済みの候補は、提出先を案内する … 窓口では返せないので、提出した警察署を伝えます

3番目を省かないでください。 拾得物の返還は、遺失物法でも施設占有者が遺失者に返還するか警察署長に提出するものとされています（第13条）。返す相手を誤れば、本当の持ち主の物を渡すことになります。 AIが出すのは候補までです。

例外に対処する

4行目の身分を証する物は、遺失物法でも拾った人が所有権を得られない物とされています（第35条）。 持ち主に返すか警察に届けるしかない物なので、取り違えたときの重さが違います。

記録を残す

• 問い合わせごとの、問い合わせの文（個人の情報を伏せたもの）、1回目の JSON、担当者が直した箇所
• 候補と照らし合わせの結果、近さの段階、2回目の JSON と下書きの検査の結果
• 本人確認で聞き返した項目と、確認できたかどうか（特徴そのものは残さない）
• 照らし直しで新たに出た候補と、連絡した日時
• 引き渡した拾得物の管理番号と、そのときの近さの段階

最後の行は、規則と言い換えの辞書を直す材料になります。 段階が C で引き渡しになった拾得物が多ければ、品目の分類の表が足りていません。