研究所の分析担当が、分析装置に出たエラーの文面から取扱説明書の節と過去のトラブルの記録を OpenSearch で引き、近い事例と対処を並べる

処理の起点を決める

起点は2つあります。毎晩の取り込みと、担当者の検索のボタンです。

取り込みは、説明書の追加・差し替えと、記録の表に足された行を拾って索引を更新します。説明書は古い版を消さず、版の番号を付けて残します。 古い版のソフトで動く装置が残っているからです。

検索のボタンは、担当者が装置を選び、エラーの文面を貼った後に押します。装置を選ばないと検索できない画面にします。 型式と版で絞らない検索は、第3章の（a）をそのまま繰り返すからです。

入力データを集める

質を決めるのは、装置の台帳のソフトの版です。 版が空の装置は、説明書の版で絞れません。取り込みのときに版の空の装置を数え、画面に「版の記録なし。全部の版の説明書を出しています」と出します。

事例の番号が無い行には、取り込みのときに番号を振ります。 同じ装置で7日以内に同じ文面の行があれば同じ事例とし、番号は表に書き戻して担当者が直せるようにします。

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

説明書の節は、エラーの文面の定型部分を語の並びで引きます。 OpenSearch の公式のドキュメントでは、match_phrase は決まった順に語が並ぶ句を含む文書に一致し、slop を付けると語の間に他の語が入ることや、順の入れ替わりを許すとされています。既定の slop は0です。制御ソフトの文面と説明書の文は、助詞や「〜しました」「〜です」で少しずつ違うので、slop を2から始めます。

日本語の本文は kuromoji で語に分けます。 AWS の公式ページでは、Japanese（kuromoji）Analysis がすべてのドメインに入っているとされています。Sudachi も選べますが、辞書を付け直しても次の blue/green の更新まで反映されないとされているので、言い換えを頻繁に足すこの構成では kuromoji で始めます。

記録は、症状のメモに似た記録を引きます。 公式のドキュメントでは、more_like_this は入力の文からその文を特徴づける語を選び、その語を含む文書を探すとされ、like には文そのものも、索引の中の文書も渡せます。既定では、入力の中で2回未満の語（min_term_freq）と、5件未満の文書にしか出ない語（min_doc_freq）が無視されます。症状のメモは短いので、min_term_freq を1に下げます。 下げないと、1回しか書かれていない「異音」が捨てられます。

GET /lab-trouble/_search
{
  "size": 10,
  "_source": ["case_no", "date", "device_no", "error_text", "symptom", "action", "result"],
  "query": { "bool": {
    "filter": [ { "term": { "model": "LC-A20" } } ],
    "must": [ { "more_like_this": {
      "fields": ["symptom", "action"],
      "like": "ポンプの圧力が上がる 夜間の連続測定で止まった 送液の音が大きい",
      "min_term_freq": 1, "min_doc_freq": 2, "max_query_terms": 25 } } ] } },
  "collapse": { "field": "case_no",
    "inner_hits": { "name": "steps", "size": 5, "sort": [ { "date": "asc" } ] } },
  "sort": [ "_score" ]
}

事例ごとに1件にまとめるのは、collapse です。 公式のドキュメントでは、collapse は項目の値ごとに一番上の文書だけを返し、項目は keyword か数で、doc values が有効で、1文書に1つの値である必要があるとされています。まとめた1件ごとに、inner_hits で同じ事例の記録を広げられます。inner_hits を日付の順にして、発生から対処・その後までを並べます。

応答の件数（hits の total）は、まとめる前の文書の数とされているので、画面の事例の数は Lambda で数え直します。

説明書の該当の文は、強調で取り出します。 公式のドキュメントでは、既定の強調は unified で、文を単位に分けて BM25 で点数を付け、fragment_size の既定は100文字、number_of_fragments の既定は5とされています。1つの文を途中で切らずに返すには、fragment_size を0にするとされています。説明書の手順の文が途中で切れると、意味が変わることがあるので、0にします。

GET /lab-manual/_search
{
  "size": 5,
  "_source": ["model", "version", "section_title", "page", "has_warning"],
  "query": { "bool": {
    "filter": [ { "term": { "model": "LC-A20" } }, { "term": { "version": "3.2" } } ],
    "must": [ { "match_phrase": { "body": { "query": "ポンプ 圧力 上限 超え", "slop": 2 } } } ] } },
  "highlight": { "fields": { "body": { "fragment_size": 0, "number_of_fragments": 3 } } }
}

AIへ渡す前に整形する

1. 数値を外す … エラーの文面から「25.3 MPa」「40 ℃」のような数値と単位を外し、values の項目に移します。定型部分だけで match_phrase を引きます
2. 番号をそろえる … 「E-0123」「E0123」「Err.123」を E0123 のような形にそろえます。メーカーごとの番号の書き方は、言い換えの表で持ちます
3. 言い換えをそろえる … 「プレッシャー高」を「圧力上昇」、「AS」を「オートサンプラー」のように、分析室の表で置き換えます。置き換えの前の語も残します
4. 説明書を節に分ける … PDFを章・節の見出しで分け、1節を1文書にします。警告・注意の枠の文は、その節の warning の項目にも写します
5. 記録を事例でそろえる … 事例の番号の無い行に番号を振り、同じ事例の行を日付の順に並べます
6. 個人の名前を伏せる … 記録の「書いた人」は索引に入れず、表の行番号だけを持ちます

1番目が、第3章の（b）を防ぎます。 外した数値は捨てずに一覧に出します。 どれだけ超えたかは文面の数値にしか無いからです。

3番目で置き換えの前の語を残すのは、表の誤りに気づくためです。 質量分析計の真空の「リーク」とポンプの液の「漏れ」は別の症状です。4番目で警告を別の項目に写すのは、警告の枠が節の頭にあり、強調の文に入らないことが多いからです。

AIに処理させる

AIの仕事は2つです。 エラーの文面と症状のメモを検索の条件に読み替えることと、検索の結果を原文のまま並べた一覧を作ることです。

説明書の手順を言い換えさせないのが、この構成でいちばん大事な線です。 「パージバルブを開けてから流量を上げる」を「流量を上げてパージする」と書き換えると、順番が入れ替わり、装置を傷めることがあります。 手順は強調で返ってきた文をそのまま写させます。

結論を書かせないのは、過去に再起動で直った事例でも今回も同じとは限らないからです。

指示内容を固定する

1回目（検索の条件への読み替え）の指示です。

あなたは研究所の分析室で、分析装置のエラーを整理する立場です。
【エラーの文面】と【症状のメモ】から、検索に使う条件を取り出してください。

【取り出すもの】
- error_code_raw: エラーの番号。書かれたまま。無ければ空
- fixed_text: エラーの文面から、数値と単位を除いた部分。語順は変えない
- values: 文面に出てくる数値と単位。書かれたまま（「25.3 MPa」など）
- unit_raw: ユニットの名前。書かれたまま（「ポンプ」「AS」など）。無ければ空
- symptom_terms: 症状のメモに書かれた症状の語。書かれたまま
- since_raw: いつからか。書かれたまま。無ければ空

【厳守事項】
- 書かれていないユニットや原因を推し量らないでください。
- 数値を丸めたり、単位を換算したりしないでください。
- エラーの文面の語順を変えないでください。
- 症状のメモに無い症状を足さないでください。
- 人の名前は写さないでください。

【装置】{device}
【エラーの文面】{error_text}
【症状のメモ】{memo}

2回目（一覧の作成）の指示です。

あなたは研究所の分析室で、エラーの切り分けの材料を並べる立場です。
【説明書の節】は取扱説明書の索引の検索結果、【過去の事例】は分析室のトラブルの
記録の検索結果です。どちらも原文です。

【書き方】
- 最初に、【説明書の節】の warning を、文言を変えずにすべて写してください。
- 説明書の節ごとに、型式・版・節の見出し・ページと、強調の文をそのまま写して
  ください。
- 過去の事例ごとに、日付・装置・エラーの文面と、steps の「やったこと」と
  「結果」を日付の順にそのまま写してください。
- 説明書と過去の事例で、やったことが食い違うときは、両方の文を並べて
  conflicts に書いてください。

【厳守事項】
- 説明書の手順を要約・言い換え・並べ替えしないでください。
- 「この対処で直ります」「続けて問題ありません」と書かないでください。
- 装置を止めるか、部品を外すかについて、あなたの考えを書かないでください。
- 検索結果に無い手順や数値を書かないでください。
- 検索結果が0件のときは、0件であることだけを書いてください。

【エラーの条件】{conditions}
【説明書の節】{manual_hits}
【過去の事例】{case_hits}

「warning をすべて最初に写す」を指示の先頭に置くのは、警告がいちばん落ちやすいからです。 AIは一覧を読みやすくしようとして、エラーの文面に関係の薄い警告を省きます。写した警告は、後で warning の項目と照合します。

「0件のときは0件と書く」も外せません。 何も当たらないと、AIは一般的な知識で手順らしいものを書くことがあります。

出力形式を固定する

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

{
  "request_no": "",
  "device": { "device_no": "", "model": "", "version": "" },
  "warnings": [ { "doc_id": "", "text": "" } ],
  "manual_sections": [
    { "doc_id": "", "section_title": "", "page": 0, "quotes": [""] } ],
  "cases": [
    { "case_no": "", "date": "", "error_text": "",
      "steps": [ { "date": "", "action": "", "result": "" } ] } ],
  "conflicts": [ { "manual_quote": "", "case_quote": "" } ],
  "zero_hit": "none | manual | cases | both"
}

AWS の公式ページでは、Converse API では outputConfig.textFormat に JSON スキーマを渡すと応答がスキーマに沿うとされています。すべての object に additionalProperties: false が要り、数値の minimum・maximum、文字列の minLength・maxLength は使えず、minItems は0と1だけとされています。新しいスキーマは初めの1回に最大約90秒かかるとされているので、呼び出しの待ち時間を120秒以上にします。

1つ目の理由は、写した文を原文と照合できることです。 quotes と warnings の text が、検索で返った強調の文と warning の項目にそのまま含まれているかを Lambda で確かめます。 1文字でも違えば一覧を出さず、検索の結果だけを出します。

2つ目は、zero_hit で引けなかった側を画面に出せることです。 cases なら「分析室で初めての事例です。結果を必ず記録に足してください」、both なら「説明書も記録も当たりません。メーカーのサポートへ」と出します。

システムへ連携する

人が確認する

1. 装置と版を見る … 画面の型式とソフトの版が、目の前の装置と合っているかを確かめます
2. 警告を読む … 一覧の先頭の警告を、手を動かす前に読みます
3. 説明書の節を開く … 強調の文だけでなく、節の前後をPDFのページで確かめます
4. 過去の事例を読む … 当時の装置の版と、今の版が同じかを確かめます
5. 止めるか直すかを決める … 自分で直す範囲を超えるものは、装置を止めてメーカーに連絡します
6. 結果を記録に足す … やったことと結果を、画面から記録に書きます

3番目を省かないでください。 強調の文は検索の語を含む文だけで、その前の文に「電源を切ってから」と書かれていることがあります。

例外に対処する

2行目で slop を広げないのは、広げるほど違う節が当たるからです。 「圧力」と「上限」が離れて出てくる別の節が上に来ます。4行目で訳をさせないのも、訳語が説明書の語と合う保証が無いからです。

記録を残す

• 検索ごとの、装置・版・エラーの文面・症状のメモ・1回目の JSON
• 説明書の検索の条件と、当たった節・強調の文・警告
• 記録の検索の条件と、当たった事例・inner_hits
• 2回目の JSON と、原文との照合の結果
• 担当者が決めたこと（自分で直した／止めてメーカーに連絡した）と、記録に足した行の番号
• 言い換えの表を更新した日と担当

5つ目は、引けた事例が役に立ったかを見る材料です。 0件のまま記録に足されなかった件は、毎月数えて分析室の会議で確かめます。