飲食チェーンの本部が店舗からクレームの報告を受けたときに、過去の対応記録から似た事案を探し、対応の経緯・お詫びの範囲・再発防止策を根拠の記録付きで返す

処理の起点を決める

取り込みと検索で、起点が2つあります。

取り込みは、店舗報告の仕組みで事案が終結したことを起点にします。 対応中の事案を取り込まないのは、まだ決まっていないお詫びの範囲を、前例として検索結果に出さないためです。 終結を通知できない仕組みなら、毎晩、終結日で絞った一覧を取りに行きます。

過去の約1万8,000件は、別に一括で取り込みます。 このときは終結させた担当者の確認が取れないので、お詫びの種類と再発防止策に「未確認」の印を付けます。古い記録ほど、社内の基準が今と違うことがあるので、発生日も検索結果に必ず出します。

検索は、担当者が店舗報告の仕組みで報告を開き、「似た事案を探す」を押したときに動きます。 押さなくても自動で出す形にしないのは、報告の本文が書きかけのまま検索されることがあるためです。 店長が追記したら、押し直してもらいます。

入力データを集める

質を決めるのは、お詫びの欄の書き方です。 「お詫びし、ご納得いただいた」だけでは、何を渡したのかが分かりません。取り込みのときに、お詫びの種類と金額の帯を項目にし、確定するのは担当者にします。 記録に書かれていなければ「記載なし」とし、補いません。

お客様の氏名・電話番号・住所は、最初から取り込みの対象にしません。 同じお客様からの繰り返しの申し出かどうかは、連絡先の台帳の側で、権限のある担当者が確かめます。 検索基盤には、個人を結びつける項目を持たせません。

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

報告は、店舗報告の仕組みから文字で取り出します。写真は取り込みません。 異物の写真は品質保証が別に保管しており、記録番号から元の記録を開けば見られます。

埋め込みは、Lambda から Amazon Bedrock を呼んで作ります。 取り込みのときは本文と経過を、検索のときは新しい報告の本文を同じモデルに通します。OpenSearch Service の側から Bedrock を呼ぶ ML コネクタもありますが、IAM のロールと、細かなアクセス制御を使う場合の ml_full_access の対応付けが要ります。最初は Lambda で作るほうが、どこで失敗したかを追いやすくなります。

索引の項目は、次のように持たせます。

AIへ渡す前に整形する

1. 氏名と連絡先の除去（取り込み時） … 本文と経過の文に残ったお客様の名前・電話番号を、正規表現と、取り込み時の Claude の確認で伏せます
2. 回付の言葉の照合（検索時） … 品質保証が作った一覧の言葉が本文にあれば、検索をせずに回付します
3. お詫びの項目の取り出し（取り込み時） … 経過とお詫びの欄から、お詫びの種類と金額の帯を取り出し、担当者が確定します
4. 長い経過の分割 … 経過が長い記録は、やり取りごとの段落に分け、段落の番号を付けます
5. 埋め込みの作成 … 本文と経過を合わせた文を Titan Text Embeddings V2 に通し、1,024次元で受け取ります
6. 業態の付与 … ファミリーレストランと定食店で、提供の工程が違うため、業態を必ず項目に入れます

2番目は、言葉の一覧で機械的に行います。AIに判断させません。 「お腹が痛くなった」と書かれた報告を、AIが「軽い申し出」と読んで検索に回すと、品質保証が知るのが遅れます。 一覧は広めに作り、当たりすぎるぶんは品質保証が受けて戻します。

5番目で、本文と経過を合わせるのには理由があります。 本文はお客様が何を言ったか、経過は店舗と本部が何をしたかで、似た事案として見たいのは、両方が似ているものです。ただし、経過が長い記録で埋め込みが経過に引っぱられないよう、経過は最初の段落までにします。

AIに処理させる

AIの仕事は2か所です。取り込み時の項目の取り出しと、検索結果のまとめです。

1行目がいちばん外せない線です。 10件のうち7件で代金を返していると、AIは「返金が妥当です」と書きたくなります。この一文を店長に伝えると、社内の基準を通らずにお詫びの範囲が決まります。

3行目もよく起きます。 「髪の毛の混入」の事案を並べると、AIは「調理担当の帽子の着用不備が原因です」とまとめがちです。過去の原因は過去の事案のもので、今回の原因ではありません。

指示内容を固定する

取り込み時（項目の取り出し）：

あなたは飲食チェーンの本部のお客様相談室で、終結したクレームの記録を整理する担当です。
対応の経過、お詫びの内容、再発防止策の欄だけを根拠にしてください。推測で埋めないでください。

【取り出す項目】
- お詫びの種類：remake（作り直し） / refund（返金） / voucher（商品券・割引券）
  / visit（訪問） / call（電話） / letter（書面） / none（なし） から、書かれたものをすべて
- 渡したものの金額の帯：〜1,000円 / 〜3,000円 / 〜10,000円 / それ以上 / 記載なし
- 再発防止策の工程：receiving / prep / cooking / plating / serving / checkout / reservation
- 再発防止策の対象：その店舗だけ / 業態の全店 / 全店 / 記載なし

【厳守事項】
- 書かれていないお詫びや策を足さないでください。書かれていなければ「記載なし」です。
- 金額は書かれた数字から帯を選んでください。計算や推定で帯を決めないでください。
- お客様の氏名、電話番号、住所が文の中に残っていたら、該当箇所を示し、項目には入れないでください。
- お客様の人柄や態度についての記述は、項目に含めないでください。

検索時（結果のまとめ）：

あなたは飲食チェーンの本部で、クレームの担当者の調べものを助ける係です。
渡された検索結果だけを根拠に、過去の事案の収め方を並べてください。

【新しい報告】{report}
【過去の事案（上位10件）】検索結果として渡します

【書くこと】
1. 各事案の要旨、経緯、お詫びの種類、再発防止策（記録番号と発生日を添える）
2. お詫びの種類が事案によって違うときは、記録に書かれた違い（業態、店舗での対応、申し出の内容）
3. 同じ再発防止策が複数の事案で出ていれば、その策と記録番号

【厳守事項】
- 今回どこまでお詫びすべきかを書かないでください。
- 件数の多いお詫びの種類を、今回の対応として勧めないでください。
- 今回の事案の原因を書かないでください。過去の原因は、その事案の原因として書いてください。
- お客様の人柄や態度に触れないでください。
- 発生日が3年より前の記録には「当時の基準」と添えてください。

検索結果は、Claude の検索結果ブロックで渡します。 1件の記録を1つの search_result にし、source に報告番号、title に区分と業態と発生日、content に本文・経過・お詫び・再発防止策を別々のテキストブロックで入れます。 引用は、テキストブロックを単位に付きます。分けておけば、「お詫びの欄から引いた」のか「再発防止策の欄から引いた」のかが、引用の位置で分かります。

「件数の多いお詫びを勧めない」は、お詫びの範囲を書かせない指示とは別に書きます。 範囲だけを禁じると、「多くの事案で返金しています」という形で同じことを書きます。

出力形式を固定する

取り込み時の項目は、次の形のJSONで受け取ります。

{
  "report_id": "CR-2025-011482",
  "occurred_at": "2025-08-17",
  "brand": "family | teishoku",
  "category": "foreign_matter",
  "apology_types": ["remake", "refund"],
  "amount_band": "~1000 | ~3000 | ~10000 | over | none",
  "contact": ["call"],
  "prevention": [ { "step": "plating", "scope": "store | brand | all", "paragraph": 3 } ],
  "pii_found": false,
  "unconfirmed": false
}

1つ目の理由は、apology_types と amount_band で、お詫びの範囲を数えられることです。 文の中に書かれていたお詫びが項目になり、同じ区分の事案で、どの種類のお詫びが何件あったかを一覧で示せます。 担当者は、自分の判断が過去とどれだけ違うかを、決める前に知ることができます。

2つ目は、prevention の scope で、策が店舗をまたいだかを分けられることです。 その店だけで直した策と、全店に広げた策では、今回の店舗に伝える意味が違います。

3つ目は、pii_found で、記録の書き方を直す材料になることです。 店長ごとに集計すると、報告の本文にお客様の名前を書いてしまう店舗が分かります。

検索の要求は、次のように組みます。

{
  "query": {
    "hybrid": {
      "queries": [
        { "multi_match": { "query": "{report}", "fields": ["body^3", "progress"] } },
        { "knn": { "body_vector": { "vector": [0.0], "k": 50 } } }
      ],
      "filter": { "term": { "brand": "family" } }
    }
  },
  "size": 10
}

filter を hybrid の段で書くと、2つのクエリの両方に効きます。 業態は必ず絞ります。提供の工程が違う業態の事案を並べても、再発防止策が当てはまらないためです。区分は絞らず、multi_match の側で加点に使います。 区分は店長によって付け方が違うからです。

検索パイプラインは、正規化の処理を1つ置きます。 正規化は min_max（既定）で各クエリの点数を0〜1にそろえ、組み合わせは arithmetic_mean（既定）で、weights に言葉 0.4、意味 0.6 を入れます。重みの合計は1.0、数はクエリの数と同じにする決まりです。

システムへ連携する

hybrid クエリは、function_score などの包むクエリの中に入れません。 ドキュメントでは、function_score・constant_score・script_score・boosting の中に入れると実行時のエラーになることがあるとされています。新しい記録を上げたいときは、包むのではなく、occurred_at を見る並べ替えを後段で行います。

ページを送るときは、pagination_depth を指定します。 各クエリが各シャードから返す件数の上限で、from が0より大きいときには必須です。最初の画面は10件だけにし、送る操作は最大50件までにします。

人が確認する

確認は2か所です。取り込み時の担当者と、検索時の担当者です。

1. 終結させた担当者が項目を確定する … お詫びの種類と金額の帯、再発防止策の工程と対象を確かめます。pii_found の記録は、伏せ方が正しいかも見ます
2. 検索時の担当者がお詫びの範囲を決める … 一覧とまとめを読み、元の記録を必要なだけ開き、社内の基準に照らして決めます
3. 古い記録は今の基準で読み直す … 「当時の基準」と添えられた記録は、今の基準と違うことがあります
4. 品質保証へ回った報告は、品質保証の指示を待つ … 回付の後に検索を使うのは、品質保証が求めたときだけです

1件あたり5分を目安にします。 一覧とまとめを読み、元の記録を1〜2件開き、店長への指示を書く時間です。まとめの文をそのまま店長に送る運用にはしません。

2番目で過去と違う判断をしたときは、理由を一言残します。 「今回は店舗ですでに返金済み」「お客様からの申し出は作り直しのみ」のように書いておくと、次に同じ型の事案を見た担当者が、違いの理由を読めます。

例外に対処する

1行目と5行目が、この構成でいちばん大事な例外です。 どちらも、似た事案を探すことより、人が先に動くことが要る事案です。検索の仕組みに乗せないことで、担当者が一覧を読んでいる間に対応が遅れることを防ぎます。

7行目は、止めずに落とします。 意味の検索が止まっても、言葉の検索だけで探せていた今までと同じ状態には戻れます。どちらで出した一覧かを画面に示し、担当者が読み方を変えられるようにします。

記録を残す

• 取り込んだ記録の報告番号、終結日、取り込んだ日時、pii_found
• Claude が返した項目のJSONと、終結させた担当者が確定したときに直した項目
• 検索のたびの報告番号、使った重み、上位10件と各件の言葉と意味の点数
• Claude に渡した検索結果と、返ってきたまとめと引用
• 担当者が決めたお詫びの範囲と、過去と違う判断をした理由
• 品質保証へ回付した報告と、当たった言葉

3つ目で、点数を2つに分けて残すのは、重みを直すためです。 担当者が開いた記録が、言葉の点数で上がったものか、意味の点数で上がったものかを数えると、0.4と0.6の重みが合っているかが分かります。