食品工場の保全員が、包装ラインの症状やアラーム番号から、取扱説明書と過去の保全記録を根拠付きで調べ、点検と復旧の手順を決める

処理の起点を決める

保全員がライン脇の端末で、設備のQRコードを読み、症状を入れたことを起点にします。 設備にはすでに設備台帳の番号を書いたラベルが貼ってあるので、そこにQRコードを足します。設備を選ぶ操作を QR コードにするのは、似た型式の設備を選び間違えないためです。

症状は、端末に言葉で入れます。「シールが甘い」「フィルムが右に寄っていく」「横シールのところで噛む」のように、見たままを書いてもらいます。 説明書の言葉に置き換えてから入れる必要はありません。置き換えられないことが、第3章の（a）の原因だからです。アラーム番号が出ていれば、別の欄に入れます。

検索は、入れた時点で1回だけ動きます。 結果が合わなければ、症状の書き方を変えて入れ直します。入れ直した回数も記録に残し、何度も入れ直した症状は、説明書と標準書に書かれていない不具合の候補として後で見直します。

入力データを集める

質を決めるのは、保全記録の「原因」の列です。 原因が空の記録や「不明」の記録は、検索に引っかかっても点検の順番の役に立ちません。取り込むときに、原因が空の記録には印を付け、一覧の下に並べます。

保全標準書には、対象の機種と設備を書いてもらいます。 標準書は書いた人の頭の中で対象が決まっていて、表紙に機種が書かれていないことがあります。取り込む前に、保全課で1冊ずつ対象を確かめます。

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

文書は1冊ずつ、保全記録は1件ずつファイルにして Cloud Storage に置きます。公式では、非構造化データは TXT・JSON・Markdown・PDF・HTML・DOCX・PPTX・XLSX・XLSM に対応し、1ファイルの上限は200MB、一度に取り込めるのは10万ファイルまでです。メタデータは JSON Lines で、1行ごとに id、structData、content（mimeType と uri）を書きます。

{"id":"rec-2026-0915-L07-P2","structData":{"doc_kind":"record",
 "line":"L07","equipment_id":"L07-P2","model":"HP-300",
 "cause_class":"ヒーター","has_cause":"true","date":"2026-09-15"},
 "content":{"mimeType":"text/plain",
 "uri":"gs://maint-search/records/rec-2026-0915-L07-P2.txt"}}

保全記録は、表計算の1行を1つのテキストファイルにします。 「症状：」「原因：」「処置：」「交換部品：」の見出しを付けて並べ、症状の文が検索の主な手がかりになるようにします。 日付や設備はメタデータの側に持たせ、絞り込みと並べ替えに使います。

絞り込みには ANY() を使います。 公式の構文では、文字の項目は ANY() に並べた値のどれかと完全に一致するかを見られ、AND／OR で組み合わせられます。項目はスキーマで索引可能（Indexable）にしておかないと絞り込みに使えません。

model: ANY("HP-300") AND doc_kind: ANY("manual", "standard")

保全記録の一覧は、answer メソッドではなく検索で取ります。 公式のドキュメントで絞り込みが説明されているのは servingConfigs/default_search:search の呼び出しで、結果は文書ごとに structData 付きで返るので、中継プログラムが原因の分類ごとに数えられます。 生成した要約は使いません。

AIへ渡す前に整形する

1. 取扱説明書はレイアウト パーサーで取り込む … 公式では、段落・表・リスト・見出し・ヘッダ・脚注を検出し、スキャンしたPDFにはレイアウト パーサーを有効にすることが勧められています
2. チャンクに見出しを含める … includeAncestorHeadings を有効にします。既定は無効です。「シール部の調整」のような章の見出しがチャンクに入り、手順がどの章のものかが回答に残ります
3. チャンクの大きさを決める … chunkSize は100〜500トークンで、既定は500です。手順の工程が途中で切れないよう、既定のまま始めます
4. チャンク分けはデータストアを作るときに決める … 公式では、チャンク分けはデータストアを作った後に有効・無効を切り替えられません。 パーサーの設定は変えられますが、変えた後に取り込んだ文書にだけ効きます
5. 保全記録を整える … 1行を1ファイルにし、原因の分類を付け、作業者の名前を外します
6. 言語ごとに分ける … 英語の説明書は英語のデータストアへ入れます

4番目を先に読んでください。 チャンク分けを後から有効にすることはできないので、データストアを作り直すことになります。 試しに作るときから、本番と同じ設定にします。

AIに処理させる

answer メソッドにさせるのは、説明書と標準書から、症状に当てはまる点検と復旧の手順を引用付きで返すことだけです。 保全記録は answer メソッドに渡しません。

標準書を「標準書として分けて」示させるのは、出どころを区別するためです。 メーカーの手順と保全課の手順が同じ回答の中で混ざると、どちらに従ったのかが記録に残りません。

3行目がいちばん起きやすい失敗です。 シール温度の調整を聞くと、一般的な値を答えたくなります。フィルムの銘柄と機種で値が違うので、引用元に書かれた値だけを、引用元と一緒に出させます。

指示内容を固定する

answer メソッドの preamble に、次のように書きます。

あなたは食品工場の保全課で、包装ラインの不具合の点検と復旧の手順を調べる担当です。
検索で見つかった取扱説明書と保全標準書の内容だけを使って答えてください。

【答え方】
- 症状またはアラーム番号に当てはまる箇所を示し、点検と復旧の手順を
  番号の順に、工程を省かずに書いてください。
- 各工程に、引用元の文書の箇所を付けてください。
- メーカーの取扱説明書の手順と、保全標準書の手順は、見出しを分けて書いてください。
  混ぜないでください。両者が食い違うときは、両方を並べて「食い違いあり」と書いてください。
- 温度・圧力・すき間・トルクなどの数値は、引用元に書かれている値だけを書いてください。
  書かれていなければ「記載なし」としてください。一般的な値を書かないでください。
- 警告・注意として書かれている文は、言い換えずにそのまま写してください。
- 原因を1つに決めつけないでください。説明書に原因の候補が並んでいれば、その順に並べてください。
- 当てはまる箇所が見つからなければ、「説明書と標準書に記載なし」とだけ答えてください。
- 運転を止めるかどうか、作業をしてよいかの判断は書かないでください。

呼び出しの設定は次のとおりです。

filteringLevel を指定しないと、根拠のスコアによる絞り込みはかかりません。 公式の説明どおり、指定しなければ回答はそのまま返ります。手順の回答では、根拠の弱い回答を出さないほうを選びます。

出力形式を固定する

中継プログラムは、2つの呼び出しの結果を次の形にまとめて端末に返します。

{
  "query_id": "",
  "equipment_id": "",
  "model": "",
  "symptom_text": "",
  "alarm_no": "",
  "procedure": {
    "state": "answered | skipped",
    "skipped_reason": "",
    "answer_text": "",
    "citations": [ { "start_byte": 0, "end_byte": 0, "doc_title": "", "uri": "" } ],
    "grounding_score": 0
  },
  "past_records": {
    "total": 0,
    "by_cause": [ { "cause_class": "", "count": 0, "latest_date": "" } ],
    "items": [ { "date": "", "symptom": "", "cause": "", "action": "", "uri": "" } ]
  }
}

procedure と past_records を別の枝に置くのが、この形の要点です。 端末の左右に分けて出すので、保全員は、どちらが説明書の手順でどちらが過去の処置かを見間違えません。

引用の位置は、文字ではなくバイトで返ってきます。 公式の説明では、引用の startIndex・endIndex は UTF-8 のバイトで数えられ、日本語のように1文字が複数バイトの文字では、文字の数と合いません。 中継プログラムで、回答の文をバイト列にしてから切り出し、端末で引用の範囲を色付けします。

回答が返らなかったときは、answerSkippedReasons を skipped_reason に入れます。公式の例では、関係のある内容が無いときの NO_RELEVANT_CONTENT、根拠の基準を満たさないときの LOW_GROUNDED_CONTENT があります。どちらの場合も、過去の記録の一覧は出します。 説明書に無い不具合こそ、過去の記録が役に立つからです。

システムへ連携する

保全記録の表計算には書き込みません。 処置の後の記録は、いまと同じく保全員が表計算に書きます。端末の結果の画面から、使った結果の番号を記録の行に貼れるようにしておきます。

人が確認する

決めるのは保全員です。端末の結果は、調べものの材料です。

1. 引用元を開いて確かめる … 手順の工程ごとに引用元のページを開き、機種と版が合っているかを見ます
2. 数値は引用元で確かめる … 温度や圧力の値は、回答の文ではなく引用元のページの値で作業します
3. 過去の記録の件数を見る … 同じ原因が何度も出ていれば、そこから点検します。件数が少なくても、直近の日付のものは見ます
4. 安全の手順は社内の手順書に従う … 運転を止める、電源を切る、残圧を抜くといった工程は、回答に書かれていなくても社内の手順書のとおりに行います
5. 処置の後に記録を書く … 決まった様式で書き、使った結果の番号を貼ります

4番目を省かないでください。 回答は説明書と標準書の該当の箇所を返すもので、作業の前後に要る安全の工程が、同じ箇所に書かれているとは限りません。

目標は、240件をならして1件10分です。 結果がそのまま当てはまれば数分、説明書に記載が無く過去の記録を読み比べると15分ほどかかります。

例外に対処する

1行目の記録が、この構成でいちばん役に立つ記録です。 説明書と標準書に書かれていない不具合が、件数とともに積み上がるので、どの標準書を新しく書くべきかが分かります。

記録を残す

• 問い合わせ（設備・症状の文・アラーム番号・保全員・日時）と、入れ直した回数
• answer メソッドの回答、引用、根拠のスコア、回答しなかった理由
• 過去の記録の一覧と、原因ごとの件数
• 保全員が使った結果 … 手順の回答か、過去の記録のどれか
• 処置の後の保全記録の行への結び付き

使った結果の記録は、検索の質を見るための唯一の手がかりです。 回答が出ても使われていない設備や症状は、取り込んだ説明書の版が古いか、チャンクの切れ目が悪いか、標準書が足りないことを示しています。月に一度、保全課で見直します。