飲食チェーンの本部で、店舗の衛生点検と保健所の立入検査の過去の指摘記録を設備・工程・言葉で探し、似た指摘と効いた是正を根拠付きで店長への指導に使う

処理の起点を決める

点検アプリに指摘が登録されたことを起点にします。 本部の担当が点検で指摘を付けたとき、点検アプリから通知を受けます。巡回は日中に行われるので、担当が店を出るころには、似た指摘の結果がそろっているようにします。

保健所の指摘は、店長の報告の登録を起点にします。 表計算の様式を受付フォームに置き換え、送信されたら同じ流れで探します。保健所の指摘には「保健所」の印を付け、結果の先頭に出します。 行政の指導は、本部の点検の指摘より先に手当てが要るからです。

索引の更新は別に動かします。 是正の報告が上がったとき、その指摘の是正の欄だけを入れ直します。次回の点検が終わったら、前回の指摘ごとに再指摘の有無を書き込みます。 これは夜に1日分をまとめて行います。

入力データを集める

質を決めるのは、設備と工程の区分です。 指摘の文は自由に書かれますが、設備と工程を選択肢で付けておけば、絞り込みで外さなくなります。 点検アプリの指摘の入力に、設備と工程の選択欄を必須で置きます。

店舗の設備の型も、索引に持たせます。 食器洗浄機の指摘は、型によって効く是正が違います。同じ型の店の是正を先に見られるようにします。

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

過去の指摘は、是正の報告が上がっているものを中心に入れます。 是正の無い指摘も入れますが、結果では「是正の報告なし」と分かるようにします。 是正の無い指摘を外すと、是正が進まなかった店の傾向が見えなくなります。

同義語の辞書は、パッケージとしてドメインに対応付けます。 公式のドキュメントでは、同義語のファイルを Amazon S3 に置いてパッケージとして取り込み、ドメインに対応付けると、analyzers/<パッケージのID> を synonyms_path に指定して使えるとされています。辞書の書き方は synonym_graph のフィルタで、synonyms か synonyms_path のどちらかを指定し、format の既定は solr、expand の既定は true です。

辞書は、検索のときだけ効かせます。 公式のドキュメントでは、"updateable": true は検索のアナライザーにだけ使え、OpenSearch 7.8 以降のドメインで検索のアナライザーだけに使っていれば、パッケージを更新すると _plugins/_refresh_search_analyzers で索引が自動で更新されるとされています。索引を作り直さずに言葉を足せるので、担当が新しい呼び方に気づいたその週に辞書へ足せます。

辞書は、1行に同じ意味の言葉をカンマで並べる形で書きます。

製氷機, 製氷器, アイスメーカー
ダスター, 台ふきん, 台拭き
シンク, 流し, 洗い場
まな板, カッティングボード
食器洗浄機, 食洗機, ディッシュウォッシャー
グリストラップ, 阻集器, グリス阻集器

行は設備と道具の名前に限ります。 「汚れ」「ぬめり」「カビ」のような状態の言葉を同じ行に入れると、別々の指摘がまとめて当たり、効いた是正の並びが崩れます。 状態の言葉は辞書に入れず、指摘の文の一致に任せます。索引に入れる側のアナライザーには辞書を入れず、検索の側だけに入れます。 これで辞書を直しても、索引の中身は変わりません。

AIへ渡す前に整形する

1. 区分をそろえる … 設備と工程を選択肢の値にそろえます。自由入力の古い指摘は、辞書で区分の候補を付けます
2. 出どころを付ける … 本部の点検か保健所かを keyword の項目に入れます
3. 再指摘を結び付ける … 同じ店舗・同じ設備・同じ工程で、次回の点検に指摘があったかを recurred に入れます
4. 名前を外す … 店長や従業員の名前は、探すのに要りません。店舗の番号に置き換えます
5. 写真は索引に入れない … 写真は点検アプリに残し、索引には写真への参照だけを入れます

3番目が、この構成の要です。 「次回の点検」は、その店で指摘の日より後に行われた最初の巡回の点検とします。次回の点検がまだ無い指摘は recurred を空にし、「未確認」と出します。 空を「再指摘なし」と読むと、まだ確かめていない是正が効いたものに見えます。

保健所の指摘の再指摘は、本部の次回の点検で見ます。 保健所の立入検査は毎月あるわけではないので、保健所の次回の検査を待つと、いつまでも未確認のままです。本部の点検票で同じ設備・同じ工程に指摘が出なければ「再指摘なし」とし、出どころが違うことを recurred_by に残します。

再指摘の結び付けは、次回の点検で同じ設備の点検項目を実際に見たときだけ行います。 巡回の時間が足りず、その設備の項目を飛ばした点検もあります。見ていないのに指摘が無いのは、効いたのではなく見ていないだけなので、その場合も未確認にします。

AIに処理させる

似た指摘を探すのは OpenSearch の more_like_this です。 問い合わせは、たとえば次の形になります。

{
  "query": {
    "bool": {
      "filter": [
        { "term": { "equipment": "{設備}" } },
        { "terms": { "process": ["{工程}"] } }
      ],
      "must": [
        {
          "more_like_this": {
            "fields": ["finding_text"],
            "like": "{新しい指摘の文}",
            "min_term_freq": 1,
            "min_doc_freq": 2,
            "max_query_terms": 25
          }
        }
      ],
      "should": [
        { "term": { "recurred": false } },
        { "term": { "source": "health_center" } }
      ]
    }
  }
}

min_term_freq を1に下げるのが、この問い合わせの要です。 公式のドキュメントでは、more_like_this は入力の中で出現が少なすぎる語を無視し、その既定は2とされています。指摘の文は「製氷機の内側にぬめり」のように短く、同じ語が2回出ることはまずありません。 既定のままだと、どの語も選ばれず何も当たりません。min_doc_freq（既定5）も、珍しい設備の指摘を拾うために下げます。 max_query_terms の既定は25、minimum_should_match の既定は30％です。

設備と工程は、点数ではなく絞り込みで効かせます。 冷蔵庫の指摘を探しているのに、言葉が似ているだけの製氷機の指摘が上に来ては困ります。should の再指摘なしと保健所の印は、同じくらい似た指摘の中で順を上げるためだけに使います。

生成AIにさせるのは、当たった指摘を3つの見出しで並べ、指導の要点の案を書くことだけです。

1行目が、この構成の線引きです。 是正の報告は店長が書いたもので、「徹底した」「注意した」と書けば効いたように読めます。 効いたかは記録から決まった値だけを使わせます。

指示内容を固定する

あなたは飲食チェーンの本部の品質管理部で、店舗への衛生の指導を準備する担当を手伝う立場です。
渡した過去の指摘と是正の記録だけを根拠にしてください。

【今回の指摘】店舗：{store}／設備：{equipment}／工程：{process}
              出どころ：{source}／指摘の文：{finding}
【今回の店の設備の型】{equipment_model}
【過去の指摘】指摘ごとに、指摘の文・是正の報告・recurred を渡します。
  recurred = false ... 次回の点検で同じ設備・同じ工程の指摘なし
  recurred = true .... 次回の点検で再び指摘あり
  recurred = null .... 次回の点検がまだ無い（未確認）

【やること】
1. recurred が false の指摘の是正を「効いた是正」に、true の指摘の是正を
   「効かなかった是正」に分けてください。null のものは「未確認」に入れてください。
2. 効いた是正をもとに、今回の店長に伝える指導の要点の案を2〜3点書いてください。

【厳守事項】
- 渡した記録に書かれていない是正のやり方を書かないでください。
- 是正が効いたかどうかは recurred の値だけで決めてください。
  是正の報告の書きぶり（「徹底した」など）で判断しないでください。
- 営業を止める、食品を廃棄する、といった判断を書かないでください。
- 店長や従業員の責任を評価する言葉を書かないでください。
- 設備の型が今回の店と違う記録は、その違いを書き添えてください。
- 根拠にした記録の番号を、それぞれに付けてください。

「recurred の値だけで決める」を明記しないと、報告の書きぶりで分けます。 「清掃を徹底し、毎日確認するよう指導した」と書かれた是正は、生成AIには効いたものに見えます。その店が次の点検で同じ指摘を受けていても、です。

「設備の型の違いを書き添える」は、担当の確認を速くするためです。 型が違う店の是正をそのまま伝えると、店長は「うちの機械ではできない」と受け取ります。

出力形式を固定する

生成AIの応答は、OpenAI API の Structured Outputs で受け取ります。 公式のドキュメントでは、Responses API で text.format に type: "json_schema"、strict: true とスキーマを指定します。安全のために応答を断ることがあり、そのときは refusal の項目が返り、指定したスキーマに従うとは限らないので、別に扱う必要があります。上限のトークン数に達して応答が途中で終わることもあるため、解析の前に状態を確かめます。

{
  "finding_id": "",
  "effective": [
    { "record_id": "", "store": "", "action": "", "same_model": true }
  ],
  "not_effective": [
    { "record_id": "", "store": "", "action": "", "recurred_finding": "" }
  ],
  "unconfirmed": [
    { "record_id": "", "store": "", "action": "" }
  ],
  "guidance_points": ["", ""],
  "health_center_related": false
}

1つ目の理由は、効いた・効かなかった・未確認を別の配列に置けることです。 点検アプリでは、効いた是正を上に、効かなかった是正を折りたたんで表示します。担当は、効かなかったやり方を店長に勧めずに済みます。

2つ目は、health_center_related で保健所に関係する指摘を目立たせられることです。 当たった指摘に保健所の印のものがあれば、「保健所でも指摘された内容」と見出しに出します。

3つ目は、record_id で根拠に戻れることです。 担当はその番号から、元の指摘の写真と是正の写真を点検アプリで開きます。

システムへ連携する

点検アプリへは、結果の添付だけを書き込みます。 指摘の重さや是正の期限は、担当が決めて入力します。

同義語の辞書は、担当が直せる形にします。 辞書のファイルを本部の共有の場所に置き、担当が足した言葉を週に1回まとめてパッケージに反映します。反映の前に、足した言葉で過去の指摘がいくつ増えて当たるかを確かめます。

人が確認する

1. 根拠の確認（担当） … 結果の記録の番号から、元の指摘と是正の写真を開きます
2. 店の事情との照合（担当） … 効いた是正が、今回の店の設備と厨房で取れるかを確かめます
3. 指導の要点の確定（担当） … 案を直して、店長へ伝える言葉にします
4. 当たり外れの記録（担当） … 次回の点検で、伝えた是正が効いたかを点検アプリに残します

目安は、1件あたり6分です。 根拠の指摘を2件ほど開き、写真を見て、指導の要点の案を直す時間です。保健所の指摘に関わるものは、時間をかけて確かめます。

4番目は、自動で残るようにします。 次回の点検の結果から再指摘の有無が書き込まれるので、担当が別に入力する手間はありません。 その値が、次に同じ指摘が出たときの材料になります。

例外に対処する

最後の行は、この仕組みの外で動かします。 保健所から営業や食品の扱いに関わる指導を受けたときは、似た指摘を探すより先に責任者が動く必要があります。

記録を残す

• 受け取った指摘と、検索に使った設備・工程・指摘の文
• 返した過去の指摘の番号と点数
• 生成AIに渡した記録の番号と、返った応答
• 担当が直した指導の要点と、店長へ伝えた日
• 辞書を反映した日と、足した言葉

辞書を反映した日を残すのは、当たり方が変わるからです。 同じ指摘でも、辞書を足した後は当たる記録が増えます。指導の質の変化を振り返るときに、いつから言葉がそろったかが分かります。