Media > AI活用ユースケース > 営業 > 骨董・古美術の買取店が、作家の号や読みの違いを吸収して過去の買取・販売の記録を OpenSearch で引き、作家・時代・状態の近い品の価格を並べる

骨董・古美術の買取店が、作家の号や読みの違いを吸収して過去の買取・販売の記録を OpenSearch で引き、作家・時代・状態の近い品の価格を並べる

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

骨董・古美術の買取の相談で届く品について、過去の買取と販売の記録から、作家・作品の種類・時代・状態の近い品を探します。近い品の買取額・販売額・販売の経路と時期を、記録の番号付きで並べます。

サマリー
生成AI
Azure OpenAI Service/ChatGPT/Claude
AIサービス
Azure AI/Google Vertex AI/OpenSearch
対象業界
EC/小売
対象部門
営業/購買
対象業務
情報検索/比較検討
主な課題
判断に時間がかかる/属人化している/情報が見つからない
AIで行う処理
検索(RAG)
主な効果
判断支援/属人化解消/検索時間短縮
導入難易度
★★★☆☆
実装レベル
本格構成
費用感
RAG・個別開発(大)
人間の確認
条件付き
現在工数
75h/月
AI導入後
30h/月
想定削減
60%
年間削減
540h
モデル条件による試算値です。実在企業の実績ではありません。

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

導入前(Before)
  1. 受付の担当が、相談の文と写真から、作家・種類・状態・箱の有無を書き出す
  2. 買取の担当が、台帳を作家の名前で検索する
  3. 出てこなければ、号・本名・旧字体・ひらがなで引き直す
  4. 出てきた行から、同じ種類で時代と状態の近い品を目で選ぶ
  5. 選んだ品の買取額・販売額・販売の経路・時期を見比べる
  6. 状態と付属品の違いを考えて、査定の額を決めて返す
導入後(After)
  1. 人受付の担当が、相談の文と、箱書きや落款から読めた範囲を画面に貼る
  2. 自動生成AIが相談から、品ごとに作家・種類・時代・状態・付属品を書かれたまま取り出す
  3. 自動Lambda が作家の台帳を引き、作家の番号の候補と、当たった道(台帳・同義語・読み)を付ける
  4. 自動OpenSearch が、作家の番号か名前の同義語と読みで引き、種類で絞り、時代・状態の近さで並べる
  5. 自動Lambda が、候補ごとに相談の品と違う項目(状態・付属品・代・時代)を記録から並べる
  6. 自動生成AIが、候補・違う点・当たった道・確かめる点を、記録のまま並べた表にする
  7. 人買取の担当が、写真で状態と箱書きを確かめ、査定の額を決めて返す
各工程の詳しい説明を読む
  1. 受付の担当が、相談の文と写真から、作家・種類・状態・箱の有無を書き出す
  2. 買取の担当が、台帳を作家の名前で検索する
  3. 出てこなければ、号・本名・旧字体・ひらがなで引き直す
  4. 出てきた行から、同じ種類で時代と状態の近い品を目で選ぶ
  5. 選んだ品の買取額・販売額・販売の経路・時期を見比べる
  6. 状態と付属品の違いを考えて、査定の額を決めて返す

(a)書き方の違いで漏れる。 3番目で、作家の号や旧字体を知っていれば引き直せますが、知らなければ「記録なし」のまま額を決めます。 ひらがなで書かれた相談は、どの漢字の作家かを担当が当てるところから始まります。

(b)同じ名前の別の作家。 号は代々受け継がれることがあり、同じ号でも代が違えば値が違います。 台帳に代が書かれていない行は、担当の記憶で見分けています。

(c)状態と付属品の見比べが省かれる。 5番目で、ニュウや直しの有無、共箱の有無を記録の備考で確かめるのは時間がかかります。急ぐと、共箱つきの品の値で、箱の無い品を見積もります。

(d)販売の経路の違いが見えない。 店頭で売れた値と業者の市で売れた値は違います。経路を見ずに値だけを見ると、買い取った後にどこで売るかが読めません。

  1. 【人】 受付の担当が、相談の文と、箱書きや落款から読めた範囲を画面に貼る
  2. 【自動】 生成AIが相談から、品ごとに作家・種類・時代・状態・付属品を書かれたまま取り出す
  3. 【自動】 Lambda が作家の台帳を引き、作家の番号の候補と、当たった道(台帳・同義語・読み)を付ける
  4. 【自動】 OpenSearch が、作家の番号か名前の同義語と読みで引き、種類で絞り、時代・状態の近さで並べる
  5. 【自動】 Lambda が、候補ごとに相談の品と違う項目(状態・付属品・代・時代)を記録から並べる
  6. 【自動】 生成AIが、候補・違う点・当たった道・確かめる点を、記録のまま並べた表にする
  7. 【人】 買取の担当が、写真で状態と箱書きを確かめ、査定の額を決めて返す

3番目で「当たった道」を付けるのは、確からしさが違うためです。 作家の台帳の号で当たった候補と、読みが同じだけで当たった候補では、同じ作家である確からしさが違います。読みだけの候補は、画面で「読みのみ一致」と出します。

7番目で額を決めるのは担当です。 画面には記録の値だけを出し、「この品は〜円です」という提案は出しません。 真贋の見立て、状態の傷み、今の需要を見て決めるのは、買取の担当です。

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

構成図
買取と販売の台帳(品名・作家・種類・時代・状態・付属品・買取額・販売額・経路・日付)
   ▼【トリガー】毎晩の書き出し
AWS Lambda ── 作家の台帳で作家の番号を付け、状態と付属品を区分にする
   ▼
Amazon OpenSearch Service
   │   記録の索引:作家の番号・作家名(kuromoji+同義語)・作家名の読み(readingform)
   │               種類・時代(西暦の範囲)・状態の区分・付属品・代
   │               買取額・販売額・販売の経路・日付
   ▼【人】受付の担当が相談を貼る
AWS Lambda
   ├──▶ Claude(Amazon Bedrock)── 相談を品ごとの条件に読み替える
   ├──▶ 作家の台帳 ── 作家の番号の候補と当たった道
   ├──▶ OpenSearch ── 作家と種類で引き、時代・状態の近さで並べる
   ├──▶ 違う項目を並べる
   ├──▶ Claude(Amazon Bedrock)── 候補と違う点を記録のまま並べた表
   ▼
買取の担当の画面 ──【人】写真を確かめ、額を決めて返す
役割想定する製品代替候補
検索基盤Amazon OpenSearch Service(kuromoji、kuromoji_readingform、synonym_graph)Azure AI Search、Vertex AI Search(Agent Search)
生成AIClaude(Amazon Bedrock の Converse API、構造化出力)Azure OpenAI(Microsoft Foundry)、OpenAI API
連携AWS Lambda(取り込み、作家の台帳の照合、違う項目の作成、検索の呼び出し)AWS Step Functions
保管Amazon S3(取り込みの写し、相談と候補と決めた額の記録、作家の台帳)社内のファイルサーバー

買取と販売の台帳と古物の帳簿には、この構成から書き込みません。 買取が決まった後の帳簿への記載は、いつもの手順で行います。

買取の記録には、売り手の情報が付いています。 古物営業法の第16条は、古物商が古物を受け取り、又は引き渡したときに、取引の年月日、古物の品目及び数量、古物の特徴、相手方の住所・氏名・職業・年齢などを帳簿等に記載し、又は電磁的方法により記録しておかなければならないとし、第18条は帳簿等を最終の記載をした日から3年間備え付けるか保存しておくことを求めています。この構成の索引に入れるのは、品の特徴と金額と日付だけです。 相手方の情報は、帳簿の側にだけ置きます。

OpenSearch Service には、日本語の kuromoji が全ドメインに入っています。 AWS の公式ページの表では、Japanese (kuromoji) Analysis と ICU Analysis が全ドメインに含まれるとされています。

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

Step1

処理の起点を決める

起点は3つあります。毎晩の台帳の取り込み、作家の台帳の更新、受付の担当の検索のボタンです。

台帳の取り込みは、前の日までの買取と販売の記録を書き出し、管理番号で1つの文書にして索引に加えます。買取の時点では販売額が空で、売れた日に同じ文書を上書きします。

作家の台帳は、買取の担当が号・別名・旧字体・読みを足したときに更新します。同義語は検索の側の analyzer に入れるので、更新したら設定を直して反映します。 手順は前処理で書きます。

検索のボタンは、受付の担当が相談を貼った後に押します。遺品の整理で何十点もまとめて来たときは、品ごとに分けて引きます。

Step2

入力データを集める

データ中身取得元
買取の相談相談の文、受付の担当が箱書き・落款から読んだ名前、状態のメモ受付の担当が貼る
買取と販売の記録管理番号、品名、作家名(書かれたまま)、種類、時代、状態、付属品、買取額、販売額、販売の経路、日付買取と販売の台帳
作家の台帳作家の番号、正の名前、号・別名・本名、旧字体の書き方、読み、代、活動の時期、分野買取の担当で作る台帳
状態の言い換えの表「ひび」→ニュウ、「欠け」「ホツ」→欠け、「金継ぎ」「共直し」→直し などの表買取の担当で作る表

質を決めるのは、作家の台帳です。 台帳に無い作家は、記録の書かれたままの名前と読みでしか引けません。台帳は全部の作家を一度に作る必要はなく、記録の点数の多い作家から作ります。

代と活動の時期は、同じ号を見分けるために持ちます。 代が分からない記録は「代不明」として持ち、相談の品の代が分かっていても、代不明の記録を同じ代とはみなしません。

売り手の名前と住所は、索引にも生成AIにも渡しません。 相談の文に依頼者の名前や住所が書かれていれば、貼る前の画面で伏せます。

Step3

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

取るものどこからどう取るか
作家の番号が同じ記録記録の索引filter の term(artist_id)
名前の同義語で当たる記録記録の索引match(artist_name。検索の側で同義語を広げる)
読みで当たる記録記録の索引match(artist_name.reading)
種類と時代記録の索引filter の term(category)と、should の range(year_from・year_to)
違う項目の材料記録の索引_source の condition・accessories・generation・channel

作家名は3つの項目で持ちます。 作家の番号の keyword、kuromoji で分けた artist_name、読みにした artist_name.reading です。検索は3つを別々に投げ、どの項目で当たったかを Lambda が候補に付けます。 1つの bool の should に混ぜると、どれで当たったかが分からなくなります。

PUT /antique_records
{
  "settings": { "analysis": {
    "tokenizer": { "ja_artist": { "type": "kuromoji_tokenizer", "mode": "search",
      "user_dictionary_rules": [
        "〇〇山人,〇〇 山人,マルマル サンジン,カスタム名詞" ] } },
    "filter": {
      "artist_synonyms": { "type": "synonym_graph",
        "synonyms": [ "〇〇山人, 〇〇太郎, 〇〇山人造" ] },
      "ja_reading": { "type": "kuromoji_readingform", "use_romaji": false } },
    "analyzer": {
      "artist_index": { "tokenizer": "ja_artist", "filter": ["cjk_width"] },
      "artist_search": { "tokenizer": "ja_artist", "filter": ["cjk_width", "artist_synonyms"] },
      "artist_reading": { "tokenizer": "ja_artist", "filter": ["ja_reading"] } } } },
  "mappings": { "properties": {
    "artist_id": { "type": "keyword" },
    "artist_name": { "type": "text", "analyzer": "artist_index", "search_analyzer": "artist_search",
      "fields": { "reading": { "type": "text", "analyzer": "artist_reading" } } },
    "category": { "type": "keyword" }, "year_from": { "type": "integer" },
    "year_to": { "type": "integer" }, "condition": { "type": "keyword" },
    "accessories": { "type": "keyword" }, "generation": { "type": "keyword" } } }
}

同義語は検索の側の analyzer にだけ入れます。 公式のドキュメントでは、synonym_graph は検索の analyzer でだけ使うよう書かれ、索引の時に使うと複数語の同義語が後ろの語の位置をずらすため、索引の時には synonym を使うよう案内されています。検索の側だけに置けば、同義語を足しても索引に入っている語そのものは変わりません。

読みの項目は、kuromoji の読みの形で作ります。 公式のドキュメントでは、kuromoji_readingform は kuromoji のトークナイザーが持つ読みの情報を使って、各トークンをカタカナ(既定)かローマ字の読みに置き換えるとされています。辞書に無い作家名は読みが正しく付かないので、user_dictionary_rules に名前・分け方・読み・品詞の行を足します。 公式のドキュメントでは、辞書の行は <text>,<subtokens>,<readings>,<part of speech> の形で、user_dictionary のファイルと一緒には使えないとされています。

Step4

AIへ渡す前に整形する

  1. 作家の番号を付ける … 記録の作家名を作家の台帳の正の名前・号・別名・旧字体と照らし、当たれば artist_id を付けます。当たらなければ空のまま残します
  2. 代を持つ … 「二代」「三代目」「初代」などを generation に分けます。書かれていなければ unknown にします
  3. 時代を西暦の範囲にする … 「江戸後期」「明治」「昭和初期」を、買取の担当で決めた表で year_from・year_to にします。「時代不明」は範囲を空にします
  4. 状態を区分にする … 状態の言い換えの表で crack(ニュウ)・chip(欠け)・repair(直し)・stain(シミ)などの配列にします
  5. 付属品を区分にする … 共箱・識箱(後から別の人が箱書きをした箱)・合わせ箱・鑑定書・栞を配列にします
  6. 販売の経路をそろえる … 店頭・業者の市・通販の3つにします

同義語は、作家の台帳から行を作り、検索の側の analyzer の設定を更新して反映します(更新のしかたは使う版の手順に従います)。反映の前に、_analyze で新しい同義語が広がるかを試します。 公式のドキュメントでは、synonym_analyzer で名前を指定した analyzer が見つからないとき、エラーを返さずにその filter のある analysis chain で規則を解釈するとされています。黙って別の解釈になるので、_analyze で確かめる手順を省きません。

Step5

AIに処理させる

AIの仕事は2つです。 相談を品ごとの条件に読み替えることと、候補と違う点を記録のまま並べた表を作ることです。

させることさせないこと
品ごとに、作家名・種類・時代・状態・付属品を書かれたまま取り出す箱書きや落款の写真の文字を、似た作家に読み替えること
種類を、決められた区分から選ぶ金額を計算すること、平均や値幅を出すこと
候補ごとに、Lambda が作った違う項目と当たった道を並べる査定の額を提案すること
確かめる点(箱書きの読み直し・代の確認など)をまとめる真贋や作家の真筆かどうかを書くこと

真贋を書かせないのが、この構成でいちばん大事な線です。 作家名が当たった記録の値を並べると、その品が本物であることを前提にした値に見えます。 画面の上部に「真贋の確認前の参考の記録」と必ず出し、AIの文にも「本物」「真作」を書かせません。

査定の額を提案させないのも同じ理由です。 過去の買取額と販売額を渡せば、それらしい額を返します。その額には、写真で見た傷み、今の需要、真贋の見立てが入っていません。

作家を推し量らせないのは、別の作家の値で見積もらないためです。 作家の番号を付けるのは、AIではなく作家の台帳の照合です。

Step6

指示内容を固定する

1回目(相談の読み替え)の指示です。

あなたは骨董・古美術の買取店で、買取の相談を整理する立場です。
【相談】から、品ごとに過去の記録を探すための条件を取り出してください。

【取り出すもの(品ごと)】
- category: 種類。【種類の区分】から1つ選ぶ。選べなければ空
- artist_raw: 作家名。箱書き・落款・相談の文に書かれたまま(ひらがなでもそのまま)
- artist_source: その名前がどこに書かれていたか(箱書き・落款・相談の文・不明)
- generation_raw: 代。書かれたまま。無ければ空
- period_raw: 時代。書かれたまま。無ければ空
- condition_raw: 状態。書かれたまま
- accessories_raw: 箱・鑑定書などの付属品。書かれたまま
- missing: 書かれていない項目の名前

【厳守事項】
- 作家名を直さないでください。似た名前の作家に読み替えないでください。
- 書かれていない代・時代を、作家名や種類から推し量らないでください。
- 本物か偽物か、価値があるかを書かないでください。
- 金額について何も書かないでください。
- 依頼者の名前・住所・電話番号は写さないでください。

【種類の区分】{categories}
【相談】{inquiry_text}

2回目(候補の表)の指示です。

あなたは骨董・古美術の買取店で、買取の担当に過去の記録を示す立場です。
【候補】は過去の買取と販売の記録です。【違う項目】【当たった道】はシステムが作ったものです。

【書き方】
- 候補ごとに、記録の番号・作家名(記録の書き方のまま)・代・種類・時代・状態・付属品・
  買取額・販売額・販売の経路・日付を、記録の値のまま書いてください。
- 【当たった道】と【違う項目】は、文言を変えずにそのまま書いてください。
- 売れていない候補は、販売額を「未販売」と書いてください。
- 最後に、受付で確かめる点(箱書きの読み直し、代の確認など)をまとめてください。

【厳守事項】
- 金額を計算しないでください。平均・値幅・差を書かないでください。
- 今回の査定の額を提案しないでください。
- 「本物」「真作」「価値が高い」など、記録に無いことを書かないでください。
- 候補の順位を変えないでください。

【相談の条件】{conditions}
【候補】{hits}
【違う項目】{differences}
【当たった道】{match_routes}

「似た名前の作家に読み替えない」を書かないと、ひらがなの名前を有名な作家の漢字に直します。 直した名前で引くと、別の作家の値が並んでも、画面の上では区別がつきません。

Step7

出力形式を固定する

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

{
  "inquiry_no": "",
  "item": { "category": "", "artist_raw": "", "artist_id": "", "generation": "",
            "year_from": 0, "year_to": 0 },
  "candidates": [
    { "record_no": "", "artist_name": "", "match_route": "artist_id | synonym | reading",
      "generation": "", "condition": [""], "accessories": [""],
      "buy_price": 0, "sell_price": 0, "channel": "store | dealer_market | online | unsold",
      "differences": [""] } ],
  "to_confirm": [""]
}

AWS の公式ページでは、Converse API の outputConfig.textFormat に JSON スキーマを渡すと応答がスキーマに沿い、enum が使えるとされています。すべての object に additionalProperties: false が要り、数値の minimum・maximum は使えません。 当たった道と販売の経路は enum で縛ります。

1つ目の理由は、AIが返した金額と当たった道を索引の値と照合できることです。 record_no ごとに、buy_price・sell_price と match_route が Lambda の持つ値と一致するかを確かめ、違えば索引の値で置き換えて記録します。

2つ目は、differences を Lambda が作った文と照合できることです。 違う項目は次の規則で作ります。

比べる項目違うときの文
condition状態が違います(相談:〜/記録:〜)
accessories付属品が違います(相談:〜/記録:〜)
generation代が違います(相談:〜/記録:〜)
どちらかが unknown〜が分かりません。確かめてから比べてください

4行目が大事です。 代や付属品のどちらかが分からなければ、「同じ」とも「違う」とも出さず、確かめる点として出します。

Step8

システムへ連携する

つなぎ先方式内容
買取と販売の台帳毎晩の書き出し(読み取りのみ)買取と販売の記録
作家の台帳S3 の表(買取の担当が更新)作家の番号・号・別名・読み・代
Amazon OpenSearch ServiceLambda からの登録・検索記録の索引、同義語と読み
Amazon BedrockConverse API(Claude)読み替えと候補の表
買取の担当の画面社内の画面相談の貼り付け、候補と違う点、決めた額の記録

決めた査定の額は、「見た記録の番号」と一緒に S3 に残します。 査定の返信と帳簿への記載は、担当がいつもの手順で行います。

Step9

人が確認する

  1. 作家名の読みを見る … 箱書きと落款の写真で、取り出した名前が正しいかを確かめます
  2. 当たった道を見る … 「読みのみ一致」の候補は、作家の台帳で同じ作家かを確かめます
  3. 代を見る … 代の違う候補と代不明の候補は、値の参考にとどめます
  4. 状態と付属品を見る … 写真でニュウ・欠け・直しと、箱の有無を確かめます
  5. 真贋を見立てる … 担当が品を見て判断します
  6. 額を決めて残す … 見た記録の番号と、額を決めた理由を残します

2番目を省かないでください。 読みが同じだけの別の作家の記録は、作家名の文字が違うので画面で気づけますが、急ぐと見落とします。

Step10

例外に対処する

起きること対応
作家名が台帳に無い書かれたままの名前と読みで引き、台帳に足す候補として記録する
作家名が分からない種類と時代と状態だけで引き、「作家不明」として出す
同じ作家の記録が0件同じ分野で時代の近い作家の記録の件数を示す
時代が分からない時代の近さを使わずに引き、「時代不明」として出す
近い記録がすべて未販売未販売の点数と、買取からの日数を示す
AIの金額が索引と合わない索引の値で置き換え、置き換えたことを記録する
構造化出力が返らない候補の一覧と違う項目だけを出す

不正品の疑いは、この表の外です。 古物営業法の第15条第3項は、古物を買い受けようとする場合に不正品の疑いがあると認めるときは、直ちに警察官に申告しなければならないとしています。その判断と申告は担当が行い、この構成は関わりません。

Step11

記録を残す

  • 相談ごとの、相談の文(依頼者の名前を伏せたもの)、1回目の JSON、担当が直した箇所
  • 検索の条件、候補、当たった道、違う項目と照合の結果
  • AIの金額を索引の値で置き換えた記録
  • 担当が決めた査定の額と、見た記録の番号、額を決めた理由
  • 作家の台帳と同義語を更新した日、更新した担当、_analyze で確かめた結果

5つ目を残すのは、同義語が検索の結果を変えるためです。 ある日から候補の顔ぶれが変わったとき、どの同義語の更新が原因かを後から追えます。

04実装レベルの3段階

最小構成:手元のAIサービスで相談を読み替え、表計算で作家の表を引く / 相談の整理
半自動化:上記+OpenSearch に記録の索引を作り、作家の番号・同義語・読みで引く / 近い品の検索
本格構成:上記+当たった道と違う項目の作成、候補の表と索引の値との照合、決めた額の記録 / 相談から候補の表まで

半自動化で、1点15分が9分程度になります。 書き方を変えた引き直しはほぼなくなりますが、状態と付属品と代の見比べが残ります。本格構成で6分になり、この段階が本記事の想定です。 段階を飛ばさないでください。 半自動化を1か月使うと、台帳に無い作家と、読みだけで当たる候補の多い作家が分かります。台帳を厚くしてから本格構成に進むほうが、候補が確かになります。

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

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

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

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

AI活用について相談する

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

向いている
  1. 陶磁器・掛軸・茶道具・漆器・金工などの骨董・古美術を買い取り、店頭・業者の市・通販で売っていて、買取の相談が毎月数百点ある買取店。過去の買取と販売の記録は台帳に残っているのに、作家の号や別名、読み方、旧字体の書き方がばらばらで、近い品の値を探すのがベテランの記憶に頼っている場合。出張買取や遺品の整理で一度に何十点もの相談が来る場合。AWS を使える担当か委託先がいる場合。
向いていない
  1. 扱う品が特定の作家や分野に限られ、担当が全部の相場を覚えている場合。過去の記録に作家名や品の種類が入っておらず、金額しか無い場合(先に記録を整えます)。なお、品の真贋の判断、査定の額を決めること、不正品の疑いの判断と警察への申告、品触れとの照合は、この構成では代替できません。過去の記録から近い品を探し、記録のまま並べるまでです。

07最小構成で試す方法

  1. 先月の買取の相談から30点を選ぶ(号で書かれた作家、ひらがなの名前、代のある作家を混ぜる)
  2. それぞれについて、担当が当時思い浮かべた近い品と、決めた査定の額を書き出す
  3. 台帳を表計算に書き出し、記録の点数の多い作家50人分の号・別名・旧字体・読みの表を作る
  4. 30点の相談を手元のAIサービスに貼り、「作家名・種類・時代・状態・付属品を書かれたまま取り出してください。作家名を直さず、金額を書かないでください」と指示する(依頼者の名前は伏せてから貼ります)
  5. 取り出した名前を3番目の表で照らし、当時の担当が思い浮かべた品が台帳から出てくるかを見る

5番目で出てこない品が多ければ、作家の台帳を厚くするのが先です。

出てきた内容判断
当時の品が見つかり、違う点も並べられたOpenSearch の索引に進む
作家名を直した・額を書いた指示の書き方で直る。構成は有効
記録に作家名や種類が無いものが多い台帳の整備が先

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

問題対策
号や旧字体で同じ作家が引けない作家の台帳と同義語でそろえ、どの道で当たったかを出す
複数語の同義語で語句の検索が外れるsynonym_graph は検索の analyzer にだけ入れる
同義語の規則が黙って別の解釈になるsynonym_analyzer が見つからないとエラーにならない。_analyze で確かめる
作家名の読みが正しく付かない辞書に無い名前は user_dictionary_rules に読みの行を足す
読みだけ同じ別の作家が混ざる「読みのみ一致」と出し、台帳で確かめる
代の違う品の値で見積もる代を違う項目として出し、代不明は同じとみなさない
AIが額や真贋を書く書かせない。照合で止める

上の4行は、検索がきれいに動いているように見えて起きる失敗です。 第8章の30点で、当時の担当が思い浮かべた品が出てくるかを必ず見てください。

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

この構成で扱うデータ: 買取の相談(遺品の整理など、家の事情が分かる文と写真)、過去の買取と販売の記録(品の特徴・金額・日付)です。買取の記録の元には、古物の帳簿として売り手の住所・氏名・職業・年齢が付いています。

  1. 売り手の情報を外す … 古物の帳簿の相手方の情報は、索引にも Claude にも入れません
  2. 帳簿は帳簿として残す … 古物営業法の第16条の帳簿等への記載と第18条の保存は、この構成の索引で代えません
  3. 真贋と額を決めさせない … 画面に出すのは記録の値と違う項目までです
  4. 不正品の疑いと品触れは担当が扱う … 古物営業法の第19条は、品触れを受けた日にその古物を所持していたときなどに、直ちに警察官に届け出なければならないとしています。この構成の候補の表は、品触れとの照合の代わりになりません
  5. 相談の写真を必要な範囲で持つ … 家の中が写った写真は、査定に必要な部分だけを残します
  6. 索引への接続を限る … OpenSearch には、Lambda と買取の担当の画面だけが接続できるようにします

誤りが起きた場合のリスクは、別の作家や代の値で見積もること、AIの文の金額を根拠にすること、売り手の情報が索引に入ることの3つです。 当たった道の表示と代の扱い、索引の値との照合、取り込みの項目の限定で防ぎます。

10まず何から始めるか

1週目:記録を見る

台帳を書き出し、作家名が空の記録と、同じ作家が何通りに書かれているかを数えます。点数の多い上位100人の作家の書き方を並べます。

2週目:30点で試す

第8章のとおり、先月の相談30点で、当時の担当が思い浮かべた品が出てくるかを見ます。作家名を直していないか、額を書いていないかを最優先で見ます。

3週目:作家の台帳と言い換えの表を作る

上位100人の号・別名・旧字体・読み・代を台帳にし、状態と付属品の言い換えの表を作ります。同じ号で代の違う作家を一覧にします。

4週目:索引を作る

OpenSearch に記録の索引を作り、作家の番号・同義語・読みで引けるようにします。この時点では、違う項目と候補の表は使いません。

2か月目: 当たった道と違う項目、候補の表と照合、決めた額の記録を足します。3か月目以降: 台帳に無かった作家の数、「読みのみ一致」の候補の数、遺品の整理の相談に査定を返すまでの日数を毎月数えます。新しい担当が、ベテランと同じ記録を見て違う点を確かめ、額を決めて根拠を残せた時点で、この構成は完成です。


11関連ユースケース

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

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

技術仕様確認日:2026-10-29/最終更新:2026-10-29
確認した内容情報源確認日
Amazon OpenSearch Service の全ドメインに Japanese (kuromoji) Analysis と ICU Analysis が含まれることAWS: Plugins by engine version in Amazon OpenSearch Service2026-10-29
kuromoji のトークナイザーが IPAdic の辞書で形態素解析をし、既定が search モードであること。user_dictionary_rules の行が <text>,<subtokens>,<readings>,<part of speech> の形で、user_dictionary と一緒には使えないことOpenSearch: Kuromoji tokenizer2026-10-29
kuromoji_readingform が kuromoji のトークナイザーの読みの情報で、各トークンをカタカナ(既定)かローマ字の読みに置き換えることOpenSearch: Kuromoji reading form token filter2026-10-29
synonym_graph を検索の analyzer でだけ使うよう書かれ、索引の時には synonym を使うよう案内されていること。synonym_analyzer で指定した analyzer が見つからないときに、エラーを返さずその filter のある analysis chain で規則を解釈することOpenSearch: Synonym graph token filter2026-10-29
古物営業法の第15条第3項で不正品の疑いがあると認めるときは直ちに警察官に申告しなければならないこと。第16条で取引の年月日、品目及び数量、特徴、相手方の住所・氏名・職業・年齢などを帳簿等に記載又は記録すること。第18条で最終の記載をした日から3年間の保存。第19条で品触れを受けた日にその古物を所持していたときなどに直ちに警察官に届け出ることe-Gov 法令API: 古物営業法2026-10-29
Converse API の outputConfig.textFormat で JSON スキーマに沿った出力が得られ、enum が使えること。additionalProperties: false が要ること。数値の minimum・maximum に対応しないことAWS: Structured outputs(Amazon Bedrock)2026-10-29

真贋、査定の額、不正品の疑いの判断と申告、品触れとの照合、古物の帳簿の扱いは、買取の担当と自社の決まり、古物営業法に沿って判断してください。 本記事は上記の資料で確認できた範囲だけを扱っています。

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

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

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

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