データセンターの運用担当が、設備の作業手順書と過去の障害報告を Vertex AI Search で検索し、監視の画面に出た設備の警報に合う対処の手順を、設備の番号と冗長の系統で絞った根拠付きで引く

処理の起点を決める

設備の監視の画面に、重要度が中以上の警報が出たことを起点にします。 監視の仕組みが外へ出す通知（メールや外部への送信の口）を中継プログラムが受け取ります。当番が画面で点の名前を打ち込む形にはしません。 夜間に点の名前を打ち間違えると、別の設備の手順書を読むことになるからです。

同じ設備の警報が続けて出たときは、同じ件として束ねます。 5分以内に同じ設備から出た警報は1件にまとめ、答えを作り直さずに、警報の一覧に足していきます。 当番が操作のあとの状態を書き足して問い直すときは、公式ページにある前の問い合わせのセッションの ID を渡す方法で、同じ会話として続けます。

入力データを集める

質を決めるのは、手順書の節の「誰が行うか」と、障害報告の「改訂した手順書と版」の2つです。 手順書は、表示の確かめと現地の目視は運用担当、電路の開閉と設備の内部の作業は電気主任技術者と保守会社というように、節ごとに付けます。付けるのは設備の経験のある3名と電気主任技術者です。

障害報告からは、お客様の名前とラックの番号を外して入れます。 検索に要るのは設備と機種と経緯で、どのお客様に影響したかは要りません。

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

手順書は、節ごとに1つの文書に分け、メタデータに機種・版・誰が行うか・手順の種類を持たせます。 公式ページでは、非構造のデータのメタデータは JSON Lines（NDJSON）のファイルで、各行に id、structData（または jsonData）、Cloud Storage の文書を指す content の mimeType と uri を持たせるとされています。1つの節は、たとえば次の1行にします。

{"id": "sop-ups-m500-v4-s0302",
 "structData": {"doc_kind": "sop", "equip_type": "ups", "model_code": "M500",
                "sop_ver": "v4", "actor": "operator",
                "proc_kind": "alarm_response", "section": "3.2 バイパス運転の表示"},
 "content": {"mimeType": "application/pdf", "uri": "gs://<bucket>/sop/ups/M500/v4/s0302.pdf"}}

actor は operator（運用担当）、engineer（電気主任技術者）、vendor（保守会社）の3つにします。 障害報告は doc_kind を incident にし、equip_id、model_code、改訂した手順書の revised_sop と revised_ver を持たせます。公式ページでは、取り込めるファイルの上限は200MBで、一度に100,000ファイルまで取り込めるとされています。

手順書の PDF は、データストアを作るときに文書の分割とレイアウトの解析を有効にします。 公式ページでは、レイアウトの解析は PDF の段落・表・画像・見出しを検出し、表や画像に説明を付ける設定もあるとされています。単線結線図や操作の盤面の図は、画像の説明を有効にして、図の中の名前が検索に当たるようにします。 分割はデータストアを作ったあとに切り替えられず、見出しを各チャンクに付ける includeAncestorHeadings は既定で無効です。「前提条件」の節の見出しが本文から離れないよう、作るときに有効にします。

AIへ渡す前に整形する

1. 点の名前の引き当て … 点の名前を設備台帳で引き、設備の番号・機種・系統・相手の系統の設備を決めます
2. 警報の言葉のそろえ … 「吸込温度高」「RETURN AIR HIGH」のような表示を、手順書の言葉の候補に置き換えて問い合わせ文に足します
3. 相手の系統の読み取り … 相手の系統の設備の現在の警報と主な値を読みます
4. 絞り込みの条件の組み立て … 答えの側は機種・手順書の版・運用担当、一覧の側は機種と障害報告に分けて組み立てます
5. 重い警報の見分け … 漏水・煙の検知・消火の設備の作動・受電の喪失なら、検索を待たずに画面に緊急の連絡の手順を出します

5番目は、検索の前に置きます。 消火の設備が作動したときに、手順書を検索している時間はありません。重い警報は、設備台帳に「緊急」の印を付けておき、印があれば社内の緊急時の連絡の手順を先に出します。

絞り込みの条件は、たとえば次のようになります（公式ページの書き方による）。

filter（初動の答え）:
  doc_kind: ANY("sop")
  AND model_code: ANY("M500") AND sop_ver: ANY("v4")
  AND actor: ANY("operator")
filter（呼ぶかの材料の一覧）:
  (doc_kind: ANY("incident") AND model_code: ANY("M500"))
  OR (doc_kind: ANY("sop") AND model_code: ANY("M500")
      AND actor: ANY("engineer", "vendor"))

公式ページでは、ANY は指定した値のどれかに完全に一致するときに真になり、AND・OR と括弧で組み合わせられるとされています。絞り込みに使う項目は、スキーマの画面でインデックス可能にしておく必要があります。

AIに処理させる

answer メソッドにさせるのは、その機種の手順書の運用担当向けの節から、警報に当たる前提条件・確かめる箇所・行ってよい操作・連絡先を、手順書の順番と言葉のまま引用付きでまとめることです。 原因の判断はさせません。

3行目がいちばん大事です。 答えを短くまとめさせると、モデルは「前提条件」を前置きとして省き、操作の手順から書き始めがちです。 前提条件を1番目に、見つからなければ「記載なし」と明記させます。

指示内容を固定する

answer メソッドでは、回答の口調や詳しさをプロンプトの前置き（preamble）で指定できます。前置きを次のようにします。

あなたはデータセンターの運用センターの当番のための、設備の作業手順書の資料係です。
検索で見つかった作業手順書の、運用担当向けの節だけを根拠に、次の順で答えてください。

1. 前提条件（手順の前に確かめること）
2. 確かめる箇所（表示、値、現地で見る場所）
3. 行ってよい操作（手順書の順番のまま）
4. 連絡先と、呼ぶ条件

守ること：
- 1の前提条件を必ず最初に書いてください。見つからなければ「前提条件の記載なし」と書いてください。
- 手順書の言葉と順番のまま書いてください。言い換えないでください。
- 開閉器・遮断器の操作、盤の扉を開ける作業、設備の内部の作業を書かないでください。
- 原因を断定しないでください。
- 機器の名前、番号、値、単位は原文の表記のまま写してください。
- 見つからない項目は「記載なし」と書いてください。
- 検索結果に無いことを書かないでください。

「機器の名前と番号を原文のまま」を入れるのは、空調機や遮断器の番号が1文字違うだけで別の機器になるからです。 「CRAH-3F-07」を「3階の7番の空調機」と言い換えると、当番は盤面の表示と照らせなくなります。

あわせて、answer メソッドの設定を次のようにします。

公式ページでは、支持が基準に届かない答えは返されず、理由として LOW_GROUNDED_CONTENT が返るとされています。引用の位置は UTF-8 のバイト単位なので、日本語の答えに印を差し込むときは文字の位置に直します。

出力形式を固定する

中継プログラムが、応答と設備台帳・監視の画面の値を次の形にそろえて当番の画面に渡します。

{
  "alarm_id": "",
  "point_name": "",
  "equip_id": "",
  "model_code": "",
  "sop_ver": "",
  "system": "A | B",
  "peer_status": { "equip_id": "", "active_alarms": [], "load_pct": null },
  "emergency": false,
  "first_response": "",
  "skipped_reason": "",
  "citations": [
    { "sentence": "", "doc_id": "", "section": "", "quote": "" }
  ],
  "callout_material": {
    "incidents": [ { "incident_id": "", "summary": "", "cause": "",
                     "revised_sop": "", "revised_ver": "", "before_revision": false } ],
    "engineer_sections": [ { "doc_id": "", "section": "", "actor": "engineer | vendor" } ]
  },
  "session_id": ""
}

1つ目の理由は、peer_status を答えと別に、監視の画面の値のまま持てることです。 相手の系統に警報があれば、画面のいちばん上を赤くし、初動の答えより先に「相手の系統にも警報。責任者と電気主任技術者へ」を出します。

2つ目は、first_response と callout_material を分けて持てることです。 当番が行う初動と、呼ぶかを決める材料が、画面の別の枠に出ます。 当番が電気主任技術者向けの節を読んで操作してしまう取り違えを、画面の作りで防ぎます。

3つ目は、before_revision で改訂前の障害報告を見分けられることです。 障害報告を受けて手順書が改訂されていれば、報告の中の「そのときの対処」は、いまの手順と違うことがあります。 真なら一覧で灰色にし、改訂後の版を並べて出します。

システムへ連携する

電気主任技術者と保守会社への連絡は、いまどおり当番が電話で行います。 画面に連絡先と呼ぶ条件を出しますが、呼ぶかどうかは当番と責任者が決めます。 呼ばれた側は、画面の警報の経緯と過去の障害報告の一覧を共有されるので、着く前に見当を付けられます。

人が確認する

1. 相手の系統を見る … 画面のいちばん上の相手の系統の状態を、監視の画面でも確かめます
2. 設備を確かめる … 画面に出た設備の番号と設置の場所が、警報の点と合っているかを見ます
3. 前提条件を読む … 答えの1番目を、手順書の原文で確かめてから先へ進みます
4. 行ってよい操作だけを行う … 運用担当向けの節の操作だけを行い、それ以外は呼びます
5. 経緯を書く … 行った確認と操作、値の変化を引継ぎの記録に書きます

1番目と3番目を省かないでください。 片方の系統の警報に手を付ける前に相手の系統を見ることは、手順書の正しさとは別に、毎回の決まりとして行います。

目標は、240件をならして1件13分です。 相手の系統と設備を確かめ、原文を読み、経緯を書く時間です。設備の経験のある3名は、毎週、答えと実際の対処を見比べます。 運用担当向けの節で対処できなかった警報が同じ機種に偏っていれば、その機種の節の付け方か、警報の言葉の置き換えに抜けがあります。

例外に対処する

3行目の「検索を待たない」は、常に残しておきます。 この構成は、手順書を探す時間を縮めるためのもので、人と建物の安全に関わる初動には使いません。

記録を残す

• 警報（点の名前、値、時刻、重要度）と、束ねた警報の一覧
• 特定した設備・機種・版・系統と、そのときの相手の系統の状態
• 絞り込みの条件、answer メソッドと search メソッドの応答の全文
• 当番が行った確認と操作、呼んだ相手と時刻
• 障害報告と、それを受けて改訂した手順書の版

2つ目の「そのときの相手の系統の状態」は、後から振り返るときにいちばん要る記録です。 当番がどの状態を見て手順を進めたかが残ります。