電気工事の現場から出る施工方法と確認の基準の質問に、社内の施工基準・電力会社の手引き・メーカーの説明書を根拠に答える

処理の起点を決める

起点は、現場代理人や職人がスマートフォンの問い合わせ画面で送信したことです。 手袋を外して打つ前提で、項目は選ぶものを中心にします。案件番号が欠けると区域が決まらず、品番が欠けると説明書が決まりません。 器具・盤の作業では品番を必須にします。

もう一つのトリガーは、文書の改訂です。 電力会社の手引きの改訂、メーカーの説明書の新しい版、社内基準の改正があったら、技術担当が文書を置き、メタデータに版の期間を書きます。メーカーの説明書は、新しい品番を初めて使う案件が決まった時点で入手して取り込みます。 取り込みは毎晩まとめて行います。

入力データを集める

質を決めるのは、メーカーの説明書の品番と版です。 説明書の表紙に書かれた対象の品番を一覧にしてメタデータに入れないと、似た品番の別の説明書が引かれます。 版が変わったら、前の版に終わりの日を書きます。

内線規程などの民間の規格を購入して使っている場合、その本文を取り込むかは発行元の利用条件を確かめてから決めます。 この構成では、社内の施工基準が規格の条番号を参照する形にし、本文そのものは取り込まない前提にしています。

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

文書は、社内基準は章ごとに、手引きと説明書は1冊ずつ、回答は1件ずつファイルにして Cloud Storage に置きます。公式では、非構造化データは TXT・JSON・Markdown・PDF・HTML・DOCX・PPTX・XLSX・XLSM に対応し、1ファイルの上限は200MBです。メタデータは JSON Lines で、1行ごとに id、structData、content（mimeType と uri）を書きます。

{"id":"maker-a-dl-series-x-v3","structData":{"layer":"maker",
 "utility":["all"],"product_series":["DLX100"],
 "work_type":["lighting"],"effective_from":"2026-04-01T00:00:00Z",
 "effective_to":"2099-12-31T23:59:59Z"},
 "content":{"mimeType":"application/pdf","uri":"gs://elec-std/maker-a-dlx100-v3.pdf"}}

問い合わせのたびに、中継プログラムが絞り込みの条件を作ります。 公式の構文では、文字の項目は ANY() に並べた値のどれかと完全に一致するかを見られ、日時の項目は ISO 8601 の文字列と比べられます。項目はスキーマで索引可能にしておかないと絞り込みに使えません。

utility: ANY("utility_b","all") AND product_series: ANY("DLX100","none")
AND work_type: ANY("lighting")
AND effective_from <= "2026-10-20T00:00:00Z"
AND effective_to >= "2026-10-20T00:00:00Z"

all と none を必ず足します。 区域に関係しない社内基準や、品番に関係しない手引きを落とさないためです。逆に、別の電力会社の手引きと、別の系列の説明書は、ここで確実に外れます。

AIへ渡す前に整形する

1. 品番を系列にそろえる … 色や電圧の違いを表す末尾の記号を、メーカーごとの規則で外して系列にします。規則に当てはまらない品番は、そのまま系列として扱い、refer の印を付けます
2. 説明書の対象品番を一覧にする … 説明書の表紙や仕様の表から、対象の品番を書き出して product_series に入れます
3. 版と期間を付ける … 説明書の版、手引きの改訂日、社内基準の改正日から、始まりと終わりの日を書きます
4. 法令の条文を写す … 自主検査で使う条を e-Gov 法令API から写し、条番号と施行の日を付けます
5. 社内基準の参照を書き足す … 社内基準が規格の条番号を参照している箇所に、規格の名前と条番号を明記します
6. 回答集を整える … 過去の回答を、根拠の箇所を確かめて1件ずつ文書にします。施主の氏名や住所は外します

1番目の規則はメーカーごとに違うので、機械に推し量らせません。 末尾の記号が色の違いのこともあれば、取付け方の違いのこともあります。取付け方が違う品番を同じ系列にまとめると、別の取付け方の説明書が引かれます。 規則は技術担当が決め、当てはまらないものは人が見ます。

AIに処理させる

させるのは、区域と品番に効く文書から該当箇所を探し、層ごとに引用して答えることです。

3つ目の「数値の基準を写す」では、条件と値を必ず組にします。 電気設備に関する技術基準を定める省令の第58条は、低圧の電路の絶縁抵抗を、使用電圧が300V以下で対地電圧が150V以下なら0.1MΩ、その他の300V以下なら0.2MΩ、300Vを超えるものは0.4MΩと、区分ごとに定めています。値だけを写すと、区分を取り違えたまま判定することになります。

answer メソッドの設定は次のようにします。

指示内容を固定する

answer メソッドの preamble に、次の指示を入れます。中継プログラムは、区域と品番の系列と作業の種類を検索の文の先頭に付けます。

あなたは電気工事会社の工事部の技術担当として、現場の現場代理人・
職人からの施工の方法と確認の基準の質問に、文書を根拠に回答を作る
立場です。読むのは、現場でスマートフォンを見ている職人です。

【前提】
検索の文の最初に、電力会社の区域、製品の品番の系列、作業の種類が
並んでいます。検索の対象は、その区域と品番に今日効く文書だけです。

【答え方】
1. 最初に、現場で確かめることを3つまで箇条書きにする
2. 次の層の順に、見つかった箇所を引用する。無い層は「該当なし」と書く
   【法令】【電力会社の手引き】【メーカーの施工説明書】【社内の施工基準】
3. 引用には、文書の名前、版、章・節・ページを付け、本文をそのまま写す
4. 数値の基準は、表の項目と条件（電圧の区分など）と値を組にして写す

【厳守事項】
- 検索結果に無い文書、別の区域・別の品番の文書で答えないでください。
- 電線の太さ、遮断器の容量、電圧降下などの計算をしないでください。
  計算が要る質問には「計算が要ります。技術担当が確認します」と書いてください。
- 層の間で書いてあることが違うときは、どちらが正しいかを書かず、
  両方を引用して「文書の間で記載が違います」と書いてください。
- 「施工して問題ありません」「合格です」と結論を書かないでください。
- 数値は本文の値をそのまま写し、単位を変えたり丸めたりしないでください。
- 一般的な電気工事の慣行で補わないでください。
- 回答集だけが根拠のときは、そのことと答えた日を書いてください。
- 該当する箇所が見つからないときは、
  「該当する箇所は見つかりませんでした。技術担当が確認します」
  とだけ書いてください。

「層の食い違いを決めない」を明記しないと、AIはもっともらしい優先順位を自分で作ります。 社内基準がメーカーの説明書より厳しい離隔を定めているとき、「メーカーの説明書の値で足ります」と書くことがあります。どちらに従うかは、会社の決まりとして技術担当が持つ判断です。

出力形式を固定する

answer メソッドの返り値と案件の情報を、中継プログラムが次の形にまとめます。

{
  "inquiry_id": "",
  "project_no": "",
  "utility": "",
  "product_code": "",
  "product_series": "",
  "work_type": "",
  "facts_to_confirm": [],
  "layers": [
    { "layer": "law | utility | maker | company | answer",
      "found": true, "title": "", "version": "", "section": "",
      "quote": "", "values": [ { "item": "", "condition": "", "value": "", "unit": "" } ],
      "uri": "" }
  ],
  "route": "answer | refer",
  "refer_reason": []
}

layers の引用は、answer メソッドの references から取ります。引用の位置（startIndex／endIndex）は UTF-8 のバイト数なので、日本語の文を文字数で切るとずれます。values の数値は、中継プログラムが引用の本文に同じ文字列があるかを照合し、無ければ数値を消して refer にします。

route は次の規則で決めます。

どれにも当たらないものだけが answer です。 value_mismatch は、AIが本文の値を写し間違えたか、単位を変えたか、別の行の値を写したかのどれかです。数値の誤りは現場で目に付きにくいので、照合を最後の門にします。

システムへ連携する

待ち行列の1行には、問い合わせ、区域、品番、引用、refer_reason を付けます。 技術担当は、説明書を探すところからではなく、引用を読んで判断するところから始められます。

人が確認する

人が確認するのは refer の問い合わせです。 answer は現場へ直接返しますが、運用を始めてから2か月は、全件を技術担当が見てから返します。

1. refer_reason を見る … 計算が要るか、層が食い違うか、数値が合わないかを確かめます
2. 判断して返す … 計算は社内の計算表で行い、食い違いは会社の決まりで決めます
3. 回答集に登録する … 根拠の箇所と判断の理由を付けます。食い違いの判断は、社内基準の改正の候補に載せます

現場の職人は、answer の回答でも引用の本文を読んでから施工します。 数値は、引用の条件の欄（電圧の区分など）が自分の現場に当てはまるかを確かめます。回答の画面には「役に立たなかった」の印を付けられるようにし、印の付いた回答は翌日に技術担当が読みます。

2か月の全件確認で、answer の中に技術担当が見れば refer にしたものが1割を超えるなら、直接の返信を始めません。

例外に対処する

上から2行目が、運用の初めにいちばん多く出ます。 新しい品番を使う案件が決まった時点で説明書を取り込む手順を、発注の流れに入れておくと減ります。

記録を残す

• 問い合わせの内容（4項目）、問い合わせた人、日時
• 引いた区域、品番から作った系列
• answer メソッドへの要求（絞り込みの条件、preamble の版）と返り値の全文
• 数値の照合の結果
• route と refer_reason、技術担当の判断と理由

区域と系列を残すのは、後から施工の不具合を調べるときのためです。 どの区域のどの版の文書を見て施工したかを示せないと、文書の誤りか施工の誤りかを切り分けられません。