新しい改善テーマに取りかかるときに、他の工場・ラインの過去の改善報告書と効果の記録を探し、横展開できる対策を根拠付きで返す

処理の起点を決める

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

取り込みは、改善報告書の承認を起点にします。 承認済みの報告書だけを取り込むのは、途中で方針が変わった対策や、差し戻された原因の推定を検索結果に出さないためです。 ファイルサーバーの承認済みフォルダへの保存を毎晩見に行き、新しく入った報告書を Lambda が取り込みます。

効果確認の記録は、品質保証部の表の更新を起点に取り込み直します。 1か月後・3か月後の数値は報告書の承認より後に入るので、報告書のカードに後から効果を結び付ける形になります。結び付けはテーマの番号で行います。

過去10年の約9,000件は、別に一括で取り込みます。 このときは書いた担当者に確認が取れないので、カードに「未確認」の印を付け、検索結果で区別して出します。

検索は、改善テーマの登録で動きます。 登録票が保存されたら Lambda が動き、結果を登録票に添付します。改善担当が条件を変えて探し直せるように、検索画面からも同じ検索を呼べるようにします。

入力データを集める

質を決めるのは、下から2つ目と3つ目です。 設備台帳で型式と設備番号を対応させておかないと、「M-0312」と書いた報告書と「成形機 XX-180」と書いた報告書が同じ設備だと分かりません。 同義語の辞書は、最初は各工場の改善担当に10語ずつ挙げてもらうところから始めます。

効果確認の記録を入力に入れることが、この構成の要です。 報告書だけで探すと、対策直後の「不良率 2.1% → 0.3%」が並びます。3か月後に1.8%に戻っていた事例は、横展開の候補ではなく注意事例です。

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

報告書の本文は、Word と文字の入った PDF から取り出します。スキャンした画像だけの古い報告書は、この構成の対象外にします。 取り出せなかったものは一覧にして、別に文字起こしの作業を回します。

検索時には、登録票から2種類の問い合わせを作ります。 1つは設備の型式・現象の名前（同義語で広げたもの）の言葉の一致、もう1つはテーマの説明文の埋め込みによる近さです。この2つをハイブリッドクエリのサブクエリにし、filter で公開範囲を絞ります。filter はすべてのサブクエリに効き、条件が複数あるときは bool クエリで包みます。

工場では絞りません。 他の工場の事例を探すのがこの構成の目的なので、自分の工場だけに絞る設定を既定にしないでください。 設備の型式で絞るかどうかは、改善担当が検索画面で選べるようにします。

AIへ渡す前に整形する

1. 欄への分割 … 報告書を「現象」「原因」「対策」「効果」「水平展開の可否」の欄に分けます。欄の名前が工場ごとに違うので、対応表で読み替えます
2. カードへのまとめ … 1件の報告書を1枚のカードにし、欄ごとの文を別々に持ちます
3. 設備の名寄せ … 設備番号から型式を引き、カードに両方を持たせます
4. 現象の名寄せ … 同義語の辞書で、現象の正規の名前をカードに付けます。元の言葉も残します
5. 効果の結び付け … テーマの番号で効果確認の記録を引き、1か月後・3か月後の値をカードに入れます
6. 埋め込みの対象を絞る … 現象と原因と対策の文だけを埋め込みます。数値は埋め込まず、数値の項目として持ちます
7. 重複の検知 … 同じテーマの中間報告と最終報告があれば、最終報告を正とします

1番目を軽く見ないでください。 欄に分けずに本文をまとめて1つにすると、引用したときに「対策」の文なのか「原因の推定」の文なのかが分からなくなります。 第7章の後半で、欄ごとに引用を返す形にするための下ごしらえです。

同義語の辞書は、Sudachi の辞書として登録します。 ドキュメントでは、Sudachi の辞書ファイルを関連付け直してもすぐにはドメインに反映されず、次のブルー／グリーンデプロイで更新されるとされています。すぐ反映したいときは、新しいパッケージで新しいインデックスを作って再インデックスし、インデックスのエイリアスを切り替えます。 辞書の更新は月に1回にまとめます。

AIに処理させる

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

3行目がいちばん起きやすい失敗です。 3か月後の記録が空の事例を渡すと、AIは対策直後の値から「効果あり」とまとめます。記録が無いことと、効果が続いたことは別の話です。 記録が無ければ「記録なし」と書かせ、並びも下げます。

並べ直しは、Lambda で行います。 ハイブリッドクエリは検索の最上位に置くクエリで、function_score などの中には入れられないとされています。効果の持続（3か月後の値が対策前より改善しているか）と設備の型式の一致で、候補を集めたあとに並べ直します。

指示内容を固定する

取り込み時（カードの取り出し）：

あなたは生産技術部で、承認済みの改善報告書を整理する担当です。
報告書の本文だけを根拠にしてください。推測で埋めないでください。

【取り出すもの】
- 現象：不良や停止の様子。報告書の言葉のまま写す
- 原因：報告書が「原因」として結論づけた文。推定と書かれていれば推定と記す
- 対策：実施した対策。実施しなかった案は含めない
- 効果：報告書に書かれた対策前後の数値と単位
- 条件：設備、材料、工程、金型、治具など、報告書に書かれたもの

【厳守事項】
- 書かれていない欄は null にしてください。他の欄から補わないでください。
- 原因が「推定」「可能性」と書かれていれば、confirmed を false にしてください。
- 対策の案と、実施した対策を分けてください。案は proposals に入れます。
- 数値は単位とともに写し、換算や丸めをしないでください。
- 顧客名や取引先名が本文にあれば、contains_customer_name を true にしてください。

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

あなたは工場の改善担当を助ける担当です。
渡された検索結果だけを根拠に、改善テーマと過去の事例を比べてください。

【改善テーマ】{theme}

【書くこと】
1. 各事例の対策を、報告書の記載どおりに短く
2. 各事例と改善テーマの条件の違い（設備の型式、材料、工程、数値の水準）
3. 効果の持続：1か月後・3か月後の記録。無ければ「記録なし」
4. 3か月後に対策前の水準へ戻った事例は、「注意事例」として分けて書く

【厳守事項】
- 横展開できるかどうかの結論を書かないでください。
- 新しい対策や、検索結果にない対策を提案しないでください。
- 報告書に書かれていない原因を書かないでください。
- 「未確認」の印のある事例は、その旨を必ず書いてください。
- 近い事例が1件も無ければ、「近い過去の事例は見つかりませんでした」と書いてください。

検索結果は、Claude の検索結果ブロックで渡します。 1件の事例を1つの search_result にし、source に報告書の番号、title に工場・ライン・テーマ名、content に欄ごとのテキストブロックを並べます。引用を有効にすると、まとめの文ごとに、どの検索結果のどのブロックを根拠にしたかが付きます。

欄ごとにブロックを分けるのは、引用の単位がブロックだからです。 ドキュメントでは、テキストブロックが引用の最小単位で、Claude はブロックの一部ではなくブロック全体を引用するとされています。報告書を1つのブロックにすると、どの文を引用しても報告書の全文が返ってきます。

「横展開できるかの結論を書かない」を明記しないと、最後に「この対策は適用可能と考えられます」と添えてきます。 改善担当が条件の違いを確かめる前に、結論のほうが先に目に入ります。

出力形式を固定する

取り込み時のカードは、次の形のJSONで受け取ります。 Lambda が形を確かめ、欠けた項目があれば取り込みを止めて一覧に出します。

{
  "report_id": "KZ-B2-2019-042",
  "plant": "B工場",
  "line": "成形2ライン",
  "equipment": { "asset_no": "M-0312", "model": "" },
  "phenomenon": { "text": "", "normalized": "バリ" },
  "cause": { "text": "", "confirmed": false },
  "countermeasure": "",
  "proposals": [],
  "effect_reported": { "metric": "", "before": "", "after": "" },
  "conditions": { "material": "", "mold": "", "process": "" },
  "contains_customer_name": false
}

検索結果は、Lambda が組み立てた次の形で登録票に添付します。

{
  "theme_id": "T-2026-10-018",
  "candidates": [
    {
      "report_id": "KZ-B2-2019-042",
      "plant": "B工場",
      "same_model": true,
      "effect_followup": { "m1": "0.4%", "m3": "0.5%", "status": "sustained" },
      "summary": "",
      "citations": [ { "report_id": "KZ-B2-2019-042", "block": "対策" } ],
      "unverified": false
    }
  ],
  "cautions": [],
  "not_found": false
}

effect_followup.status は sustained（3か月後も改善が続く）／reverted（対策前の水準に戻った）／no_record（記録なし）の3つで、効果確認の記録の数値から Lambda が決めます。 AIには付けさせません。

1つ目の理由は、AIの文と機械の値を分けられることです。 summary はAIが書き、effect_followup と same_model は記録と台帳から機械で入れます。効果が続いたかどうかを、AIの言い回しに頼らずに読めます。

2つ目は、引用を報告書の欄まで戻せることです。 Claude が返す引用の位置（search_result_location）には、検索結果の番号とブロックの範囲が入ります。Lambda がそれを報告書の番号と欄の名前に置き換え、citations に入れます。 改善担当は「No.42 の対策の欄」をそのまま開けます。

3つ目は、reverted の事例を cautions に分けられることです。 横展開の候補と注意事例が同じ並びにあると、上から順に読んで、戻った対策を採ってしまいます。

システムへ連携する

ファイルサーバーにも、効果確認の表にも書き込みません。 この構成が書き込むのは、検索基盤のインデックスと、登録票への添付だけです。報告書の正本は工場のファイルサーバーに残し、検索結果からはそこへのリンクで戻ります。

人が確認する

AIのまとめをそのまま改善の計画に写す運用にはしません。 改善担当が次の順で確かめます。

1. cautions を先に読む … 効果が戻った事例は、何が原因で戻ったかを報告書で確かめます
2. 候補の根拠を開く … citations から報告書の対策の欄を開き、まとめと食い違いがないかを見ます
3. 条件の違いを自分で確かめる … 材料のグレード、金型の年数、サイクルタイムなど、報告書に無い条件は書いた担当者に聞きます
4. 参考にした事例を登録票に記録する … どの報告書を採り、どれを採らなかったかを残します

取り込み時のカードも、確かめる人を決めます。 新しく承認された報告書のカードは、書いた担当者に取り込みの翌日に送り、欄の取り違えがないかを見てもらいます。 過去分の「未確認」のカードは、検索で参照に選ばれたときに、その場で確かめます。

4番目の記録が、この仕組みを育てます。 採られた事例と採られなかった事例が溜まると、どの工場のどの型式の事例がよく使われるかが分かり、同義語の辞書と並べ直しの重みの見直しに使えます。

例外に対処する

1行目を守ることが、信頼を保ちます。 何も見つからないときに無理に3件並べると、改善担当は次から結果を読まなくなります。 「無い」と返すことも、社内に前例が無いという情報です。

記録を残す

• 取り込んだ報告書の版と、取り出したカード（どのモデルで取り出したかを含む）
• 検索のたびの問い合わせ、同義語で広げた後の言葉、ハイブリッドクエリの上位の結果とスコア
• Claude に渡した検索結果と、返ってきたまとめと引用の位置
• 改善担当が参考に選んだ事例と、選ばなかった事例
• カードの取り違えを担当者が直した記録
• 同義語の辞書の版と更新日

2つ目で同義語を広げた後の言葉を残すのは、辞書の誤りを見つけるためです。 「ショート」を「ショートショット（充填不足）」と「電気の短絡」の両方に広げていると、成形のテーマで電気設備の報告書が出てきます。 ログを見れば、どの語の広げ方が外れを呼んでいるかが分かります。