施工管理から届く「この納まり・この施工方法は認められるか」の質問に、施工基準書・標準仕様書・技術通達を根拠に答え、基準に無いものを技術部へ回す

処理の起点を決める

起点は、現場の担当が問い合わせ画面から質問を送ったことです。 工事番号は一覧から選ばせ、工種と部位は選択肢にします。質問の本文は自由文で書かせますが、工事番号だけは必須にします。 工事番号が無いと、どの現場の特記仕様書を見ればよいかが決まらず、社内基準の層しか答えられません。

問い合わせは1件ずつ、送られたその場で処理します。 現場は協力会社の作業を止めて待っていることが多く、まとめて処理する理由がありません。

技術通達が発行されたときも、別の起点として動かします。 通達の管理表に行が足されたら、改められた節を出典にして過去30日に返した回答を拾い、技術部に一覧で知らせます。改正の前に返した回答で、まだ施工していない現場があるかを確かめるためです。

入力データを集める

質を決めるのは、通達の管理表と、現場の設計図書に工事番号が付いていることです。 管理表が無ければ旧い記述を見分けられず、工事番号が無ければ別の現場の特記仕様書が根拠として返ります。 隣の現場の特記で「可」と答えるのは、何も答えないより悪い失敗です。

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

基準書・通達・標準仕様書・現場の設計図書は、Cloud Storage に置いて1つのデータストアに取り込みます。 文書ごとのメタデータに、文書の種類、編と節、状態、工事番号、発行日を持たせます。

絞り込みの式は、社内文書と現場の文書で条件を分けて OR でつなぎます。 例えば (doc_type: ANY("internal_standard","notice","std_spec") AND status: ANY("current")) OR (doc_type: ANY("project_spec") AND project_id: ANY("K-2611")) のように書けます。絞り込みは AND・OR・NOT と括弧で組み立てられ、使う項目はスキーマで索引可能にしておく必要があるとされています。民間の工事で標準仕様書を引いていない場合は、std_spec を式から外します。

AIへ渡す前に整形する

1. 基準書の版をそろえる … 現行版だけに status: current を付け、置き換えられた版には retired を付けます
2. 節番号を断片から読めるようにする … 見出しに「防水編 4.3」のような編と節の番号が入っていることを確かめます
3. 通達の管理表を作る … 通達ごとに、改めた編と節を1行ずつ書き、基準書に反映済みかの列を持たせます
4. 標準仕様書は正誤表を反映した版を入れる … 国土交通省のページは最新版の使用を求めています。制定版と改定版を両方入れません
5. 現場の設計図書に工事番号を付ける … 共有フォルダの名前からではなく、工事台帳の工事番号をメタデータに書きます
6. 竣工した現場の設計図書を外す … 竣工したら status: closed にし、絞り込みで除きます
7. 文書の分割を設定する … データストアを作るときに分割を有効にし、見出しを各断片に付けます

7番目は、データストアを作る前に決めます。 分割の設定はデータストアの作成後に変えられないとされています。断片の大きさは100〜500トークンで指定でき、見出しを断片に含める設定（既定は無効）を有効にすると、「防水編の4.3節の表の行」であることが断片だけで分かります。 節番号が断片に入らないと、第7章の後段で通達の管理表と照らせません。

4番目を軽く見ないでください。 制定版と改定版が両方入っていると、正誤表で直された箇所について、直る前の記述が出典として返ることがあります。

AIに処理させる

させるのは、質問の部位と施工方法に当たる記述を、社内基準の層と設計図書の層に分けて見つけ、それぞれの可否と出典を短く返すことです。

2つの層を混ぜないことが、この構成で最も大事な点です。 社内基準は自社が品質を守るための決まりで、設計図書は発注者との契約の中身です。社内基準で認める納まりでも、特記仕様書が別の材料を指定していれば、その現場では使えません。 逆に、特記仕様書に定めが無くても、社内基準で認めていない納まりは使いません。

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

回答が返ったら、中継プログラムが出典の doc_type で層に分け、社内基準の層の出典の節番号を通達の管理表と照らします。 改められた節で、まだ基準書に反映されていなければ、その通達の断片が出典に入っているかを見ます。入っていなければ、回答を現場に返さず技術部へ回します。

次に、回答の主張ごとに check grounding API にかけます。 根拠の断片には、出典になった断片を doc_type の属性付きで渡します。社内基準の層の主張が設計図書の断片だけで支えられていたら、層の取り違えとして扱います。

2行目が最も起きやすい失敗です。 回答を作るモデルは、シーリングの打ち替えや水切りの一般的な納まりを知っています。それで答えると、社内基準に無い「この納まりで可」が、基準書の答えと同じ顔で届きます。 検索結果の文書だけで答えることを指示で明記し、さらに裏付けの検査で数値として確かめます。

指示内容を固定する

answer メソッドの preamble に、次の指示を入れます。

あなたは建設会社の技術部で、現場の施工管理の担当からの質問に、
社内の施工基準と現場の設計図書の該当箇所を示す担当です。
読むのは現場の担当で、あなたの回答を見て出典の節を開きます。

【答え方】
1. 最初に「社内基準」として、施工基準書または技術通達の該当箇所を書き、
   「認める」「認めない」「承認が要る」「記載なし」のどれか1つを書いてください。
2. 次に「この現場の設計図書」として、特記仕様書・質問回答書・現場説明書・
   標準仕様書に同じ部位の定めがあれば、文書名と箇所と定めの内容を書いてください。
   定めがなければ「定めなし」と書いてください。
3. 技術通達で改められた節は、通達の番号と改正後の内容を書いてください。

【厳守事項】
- 社内基準と設計図書を1つの文にまとめないでください。必ず分けて書いてください。
- 社内基準の可否は、施工基準書と技術通達に書かれていることだけで答えてください。
  一般的な施工の知識で補わないでください。
- 標準仕様書だけを根拠に、社内基準の可否を書かないでください。
- 特記仕様書と社内基準の内容が違うときは、どちらがよいかを書かず、
  「社内基準と特記仕様書の定めが異なります。技術部の確認が必要です」と書いてください。
- 設計図書に定めの無い工法や材料に替える質問には、可否を書かず、
  「設計図書と異なる施工になるため、技術部の確認が必要です」と書いてください。
- 寸法や数値は、文書に書かれているとおりに書いてください。換算しないでください。
- 廃止された基準書や、竣工した他の現場の文書を使わないでください。
- 該当する記述が見つからないときは、
  「社内基準に該当する記述が見つかりません。技術部へ回します」とだけ書いてください。

「1つの文にまとめない」が、この指示の要です。 何も言わなければ、モデルは「社内基準では可ですが、特記仕様書も確認してください」のように滑らかにまとめます。読み手は前半だけを読んで施工に進みます。 層ごとに見出しを分けさせ、中継プログラムが層ごとの値を取り出せる形にします。

検索の文は、中継プログラムが画面の入力から組み立てます。 例えば「工種：防水、部位：屋上の立上り端部、質問：アスファルト防水の立上り端部の押さえ金物を、アルミ製から樹脂製に替えてよいか」のように、工種と部位を先に並べ、質問の本文を最後に置きます。

出力形式を固定する

answer メソッドの応答と裏付けの検査の結果を、中継プログラムが次の形に整えます。

{
  "inquiry_id": "",
  "project_id": "",
  "project_type": "public | private",
  "work_type": "",
  "location": "",
  "status": "answered | routed | skipped",
  "route_reason": "not_in_standard | layer_conflict | design_change | approval_required | notice_missing | low_support | none",
  "internal": {
    "verdict": "allowed | not_allowed | approval_required | not_found",
    "refs": [ { "doc_id": "", "section": "", "version": "", "uri": "" } ],
    "amended_by": [ { "notice_no": "", "issued_on": "", "cited": true } ]
  },
  "design_docs": {
    "has_provision": true,
    "refs": [ { "doc_type": "project_spec | std_spec", "doc_id": "", "location": "", "summary": "" } ]
  },
  "claim_scores": [ { "layer": "internal | design_docs", "score": 0 } ],
  "answer_text": ""
}

1つ目の理由は、2つの層の結論を別々の値で持てることです。 振り分けは文を読んで決めるのではなく、internal.verdict と design_docs.has_provision の組み合わせで決めます。

2つ目は、amended_by で通達の確認を記録に残せることです。 改められた節を出典にした回答には、通達の番号と、それを回答に含めたかが残ります。通達の発行後に「この節を出典にした回答」を拾うのも、この値で行います。

システムへ連携する

工事台帳と設計図書には書き込みません。 協議の結果で設計図書が変わるときは、これまでどおり現場が監督職員と協議し、変更の手続きを取ります。この構成が設計図書の変更まで記録すると、協議を経ない変更が記録の上で成立します。

人が確認する

現場へ直接返った回答も、施工に進む前に現場の担当が出典の節を開きます。

1. 工事番号と出典の現場が合っているかを見る … 設計図書の層の出典が、自分の現場の特記仕様書であることを確かめます
2. 社内基準の節を原文で読む … 回答の文ではなく、基準書の節の納まり図と表を見ます
3. 通達の有無を見る … amended_by に通達があれば、通達の本文を開きます
4. 所長に報告する … 回答の出典を添えて報告し、施工に進むかを所長が決めます

技術部の担当は、待ち行列に回ってきたものだけを見ます。 回答の候補と層ごとの出典が付いているので、文書を探すところからではなく、判断するところから始められます。 設計図書と異なる施工になるものは、現場が監督職員と協議するための資料の作り方まで指示します。

例外に対処する

2行目は、基準書を育てる材料になります。 同じ工種の同じ部位で「記載なし」が毎月出ているなら、その納まりを基準書に足すべきだという合図です。 技術部が扱いを決めたら、通達にするか次の改訂に入れるかを月次で決めます。

記録を残す

• 問い合わせの全文（工事番号、工種、部位、質問、図面の写し）と日時
• 中継プログラムが組み立てた検索の文と、使った絞り込みの式
• answer メソッドの応答の全文（回答、出典、回答しなかった理由）
• check grounding API の結果（主張ごとの支持の度合いと出典）
• 振り分けの結果と、技術部が最終的に決めた扱い
• そのとき参照した基準書の版と、通達の管理表の内容

最後の行を残すのは、通達が後から出るためです。 回答した時点で改正が無かったのか、改正があったのに見落としたのかは、当時の管理表が残っていないと区別できません。