荷崩れ・破損・誤配送の事故が起きたときに、過去の事故報告と原因分析から似た事故を探し、原因と効いた対策を根拠の報告書付きで返す

処理の起点を決める

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

取り込みは、原因分析の報告書が承認されたときです。 共有フォルダの承認済みの場所にファイルが置かれたことを検知して動かします。承認前の下書きは取り込みません。 原因が確定していない報告書が検索に混ざると、仮の原因が「過去の事故の原因」として返ります。

効果の確認表は、登録されるたびに付け足します。 再発防止策を打ってから一定の期間（たとえば3か月）が過ぎたところで、品質管理の担当が「再発なし」「再発あり」「中止」を記入します。その記入を起点に、該当する事故の対策の項目を更新します。 報告書そのものは取り込み直しません。

検索は、品質管理の担当が新しい事故を調べ始めたときに動きます。 事故台帳に新しい事故が入った時点で自動で検索することもできますが、第一報の段階では状況の書き方が粗く、似た事故の精度が出ません。 担当が状況を整理してから、画面で検索を始める形にします。

入力データを集める

質を決めるのは、報告書の「状況」と「原因」が節として分かれて書かれているかです。 なぜなぜ分析の書式で書かれた報告書なら、状況・1回目のなぜ・2回目のなぜ……と分かれています。分かれていない報告書は、取り込みで状況と原因を切り分けられず、意味の検索が状況の近さだけで当たることになります。

効果の確認表は、対策の番号で報告書と結びつけます。 報告書の対策が「①フィルムの巻き数を3周から5周に」「②上段の重量物の禁止」のように番号で書かれていれば、確認表の結果を対策ごとに付けられます。番号が無い報告書では、どの対策が効いたかを分けられません。

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

報告書は Word で作られ、承認時に PDF にしています。取り込みは、元の Word から文字を取り出し、見出しで節に分けます。 PDF しか残っていない古い報告書は、文字が取り出せるものだけを対象にし、スキャンした画像だけのものは後回しにします。

索引の項目は、次のように持たせます。 1件の文書は「事故1件の1つの節」です。

意味のベクトルは、Amazon Titan Text Embeddings V2 で作ります。 公式のドキュメントでは、入力は最大8,192トークンまたは50,000文字、出力のベクトルは1,024（既定）、512、256次元から選べます。対応言語は英語で、100以上の言語がプレビューとされているので、日本語の報告書で使う前に、手元の事故で近さが出るかを必ず確かめます。

AIへ渡す前に整形する

1. 節に分ける … 報告書を、状況・原因・対策の見出しで分けます。なぜなぜ分析の段は、原因の節にまとめます
2. 個人名を外す … ドライバーや作業者の氏名を、「ドライバーA」「作業者B」のような役割の記号に置き換えます
3. 呼び方の揺れを記録する … 拠点ごとの呼び方（ラップ／ストレッチフィルム、カゴ車／ロールボックスパレット）を一覧にし、言葉の検索の同義語として使います
4. 荷物の種類をそろえる … 荷主ごとの商品名ではなく、「飲料ケース」「大型家電」「小型段ボール」「温度管理品」のような共通の区分に付け直します
5. 対策の番号を確かめる … 対策が番号付きで書かれているかを確かめ、無いものは取り込みで印を付けて品質管理に戻します
6. ベクトルを作る … 状況の節と原因の節について、Titan Text Embeddings V2 でベクトルを作ります

2番目を軽く見ないでください。 事故の報告書には、ドライバーの氏名と、その人が以前にも事故を起こしたかが書かれていることがあります。検索の目的は起き方の近さで、人を探すことではありません。 氏名を残すと、似た事故の一覧が「同じ人の事故の一覧」として読まれます。

AIに処理させる

AIの仕事は、検索で出た似た事故を、決まった項目で引用付きで並べることだけです。 似た事故を探すのも、事故ごとにまとめるのも検索基盤で行います。

2行目が、いちばん外せない線です。 報告書の対策の欄には「フィルムの巻き数を増やした」と書かれていて、その後の再発が無ければ、AIは「この対策は有効でした」と書きがちです。再発が無かったのは、荷主が変わったからかもしれません。 効いたかどうかは、効果の確認表に人が書いた結果だけを根拠にします。

3つ目の「違う点」を必ず書かせるのも、同じ理由です。 似ている点だけを並べると、担当は当時の対策をそのまま写したくなります。温度管理品と常温品、自社の車両と委託の車両の違いで、同じ対策が効かないことがあります。

指示内容を固定する

あなたは物流会社の品質管理部で、新しい事故の検討のために過去の似た事故を整理する係です。
渡された検索結果だけを根拠にしてください。一般的な物流の知識で補わないでください。

【新しい事故】
工程：{process}　荷物の種類：{cargo_type}　区分：{category}
状況：{situation}
分かっている範囲の原因：{known_cause}

【検索結果】
事故番号ごとに、状況（situation）、原因（cause）、対策（measure）の節と、
対策ごとの効果の確認結果が渡されます。

【事故ごとに書くこと】
1. 事故番号、発生日、センター、工程、荷物の種類、区分
2. 当時の状況（報告書の文を引用）
3. 当時の原因（報告書の文を引用）
4. 新しい事故と似ている点（工程・荷物・起き方のどこが同じか）
5. 新しい事故と違う点（工程・荷物・車両・環境のどこが違うか）
6. 対策ごとの効果の確認結果を、記録のまま
   （再発なし／再発あり／中止。記録が無ければ「効果未確認」）

【厳守事項】
- 効果の確認結果が無い対策を「有効」「効果あり」と書かないでください。
  必ず「効果未確認」と書いてください。
- 新しい事故の原因を断定しないでください。
  「当時の原因は〜だった」と過去形で書き、新しい事故に当てはめないでください。
- 新しい再発防止策を提案しないでください。
- 違う点が見つからないときも「違う点：記載から判断できない」と書き、空欄にしないでください。
- ドライバーや作業者の評価を書かないでください。
- 似ていないと判断した事故は、「似ている点が少ない」と書いて最後に回してください。

「効果未確認」を2か所に書いているのは、空欄にさせないためです。 確認の記録が無い対策について何も指示しないと、AIは対策の文だけを並べ、読む人は「並んでいる＝効いた対策」と受け取ります。 記録が無いことを、文字として画面に出します。

検索結果は、Claude の検索結果ブロックで渡します。 1つの節を1つの search_result にし、source に事故番号と節、title に発生日とセンターと区分、content に節の本文を入れます。公式の説明では、引用付きの答えが返り、検索結果ブロックは Claude API、Amazon Bedrock、Google Cloud で使えます。 中に入れられるのは文字だけで、写真は渡せません。 報告書の写真は、原本へのリンクで画面に出します。

出力形式を固定する

検索パイプラインは、次のように作ります。

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

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

GET /incidents/_search?search_pipeline=incident-hybrid
{
  "size": 10,
  "query": {
    "hybrid": {
      "filter": { "bool": { "filter": [
        { "term": { "approved": true } },
        { "range": { "occurred_on": { "gte": "now-6y/d" } } }
      ] } },
      "queries": [
        { "match": { "text": "ストレッチフィルム 巻き数 カーブ 上段 崩れ" } },
        { "knn": { "text_vector": { "vector": [0.012, -0.034], "k": 50 } } }
      ]
    }
  },
  "collapse": { "field": "incident_id" }
}

重みを言葉0.4・意味0.6にしているのは、呼び方の揺れを意味の検索で拾うためです。 ただし、最初からこの値に決める必要はありません。第8章の試しで、ベテランが選んだ事故がどちらの検索で上に来るかを見て決めます。 vector の中身は、Lambda が Titan で作った1,024個の数値です。

画面に返す形は、次のJSONです。

{
  "query_incident": { "process": "積込", "cargo_type": "飲料ケース", "category": "荷崩れ" },
  "similar": [
    { "incident_id": "INC-2023-0418", "occurred_on": "2023-04-18", "center": "埼玉第2",
      "process": "積込", "category": "破損",
      "situation": "", "cause": "",
      "same_points": "", "different_points": "",
      "measures": [
        { "no": 1, "text": "", "result": "再発なし", "checked_on": "2023-07-20" },
        { "no": 2, "text": "", "result": "効果未確認", "checked_on": null }
      ],
      "citations": ["INC-2023-0418/cause"] }
  ],
  "not_found": false
}

1つ目の理由は、measures の result を画面で色分けできることです。 「再発なし」「再発あり」「中止」「効果未確認」を固定の値で返させるので、担当は文章を読む前に、効いた記録のある対策がどれかを一目で分けられます。

2つ目は、same_points と different_points を別の項目にできることです。 1つの文章にすると似ている点ばかりが長くなります。項目を分ければ、違う点が空かどうかを画面の側で確かめられます。

3つ目は、not_found で「似た事故が無い」を区別できることです。 本当に前例が無いのか、言葉の揺れで当たらなかったのかを、後から品質管理が見直す材料になります。

システムへ連携する

荷主名は、索引に入れません。 荷主の区分（食品、家電、通販など）だけを持たせます。似た事故を探すのに荷主名は要らず、別の荷主の事故が画面に荷主名付きで出ることを避けます。

人が確認する

この構成の確認は、必須です。 出てくるのは検討の材料で、原因と対策は人が決めます。

1. 並んだ事故が本当に似ているかを見る … 似ている点と違う点を読み、検討に使う事故を選びます。点数の順に上から使うことはしません
2. 原本を開いて確かめる … 検討の資料に使う事故は、報告書の原本と写真を開きます。引用された文が、原本の該当する節にあることを確かめます
3. 効果の確認結果を確かめる … 「再発なし」の対策を新しい事故に使うときは、確認表の所見も読みます。 荷主の変更や工程の変更で再発しなくなっただけのこともあります
4. 使わなかった事故を記録する … 上位に出たのに使わなかった事故と、その理由（工程が違う、荷物が違う）を一言残します

1件あたり15分を目安にします。 似た事故が5件出れば、1件3分で似ている点と違う点を読み、原本を開くのは選んだ1〜2件です。

例外に対処する

3行目は、公式のドキュメントに書かれた動きです。 hybrid クエリで collapse を使うと、既定では上位 size 件の文書の重複を除くため、同じ事故の節が上位に多いと返る事故の数が減ります。index.neural_search.hybrid_collapse_distinct_groups_enabled を有効にすると、size 件までの異なるまとまりを返せます。

記録を残す

• 取り込んだ報告書の事故番号・節・承認日と、取り込んだ日時
• 効果の確認表から付け足した結果と、付け足した日時
• 検索の入力（状況、工程、荷物の種類、区分）と、返した事故番号と点数
• Claude に渡した検索結果と、返ってきた答えと引用
• 担当が使った事故と、使わなかった事故とその理由
• 「似た事故は見つかりませんでした」になった検索

5つ目は、重みと同義語を直す材料です。 3か月分たまったところで、使われた事故が言葉の検索と意味の検索のどちらで上位に来ていたかを数え、重みを見直します。