着工前の施工検討会に向けて、構造・工法・立地が近い過去の現場の不具合と是正の記録を探し、リスクを根拠付きで資料に載せる

処理の起点を決める

取り込みと検索で、起点が2つあります。

取り込みは、不具合の是正が完了したとき、または引き渡し後のクレームの対応が完了したときを起点にします。 是正の途中の記録を取り込まないのは、原因が確定していない見立てや、効かなかった是正を検索結果に出さないためです。 完了を通知できない仕組みなら、毎晩、完了日で絞った一覧を取りに行きます。

過去の約2万4,000件は、別に一括で取り込みます。 このときは担当者の確認が取れないので、記録に「未確認」の印を付けます。検索結果では未確認の記録を区別して表示し、検討会の資料に載せるときに、その場で元の記録と写真を確かめてもらいます。

検索は、担当者が検索画面で「探す」を押したときに動きます。 施工計画の概要が固まった段階で一度探し、工法が変わったら探し直します。

入力データを集める

質を決めるのは、現場の属性と用語の辞書です。 現場の台帳に所在地の座標が無ければ、近隣の現場は探せません。住所しか無い現場は、取り込みの前に座標に直しておきます。 主な工法の欄も、現場ごとに自由に書かれていると絞り込みが効かないので、外壁、防水、杭、床の仕上げなどの区分から選ぶ形にそろえます。

部位と不具合の区分は最初に固定します。 部位は、基礎・躯体・外壁・屋上防水・開口部・内装・設備の7つ程度、不具合は、漏水、ひび割れ、剥離・浮き、沈下・傾き、結露、仕上げ不良、騒音・振動、その他、です。

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

不具合とクレームの記録は、それぞれの仕組みから文字で取り出します。写真は取り込みの対象にせず、記録番号から元の仕組みで開けるようにします。 現場の属性は、現場番号で現場の台帳から引き、記録ごとに持たせます。

「工法が近い現場」の検索では、新しい現場から2つのサブクエリを作ります。 1つは主な工法と検討したい部位の言葉による言葉の一致（kuromoji で解析した項目）、もう1つは「RC造・14階・外壁タイル張り・屋上はアスファルト防水」のように属性を文にしたものの埋め込みによる近さです。構造は filter で絞ります。

「近隣の現場」の検索は、構造で絞りません。 半径の中にある現場の記録を、部位と不具合の区分ごとに数件ずつ集めます。半径は立地の条件で変えます。 既定は10kmで、沿岸と埋め立て地は同じ立地の条件の現場に限ったうえで30kmまで広げます。

AIへ渡す前に整形する

1. 用語の辞書の反映 … 現場の用語を kuromoji の user_dictionary_rules に入れ、「打継ぎ」「コールドジョイント」を1語として扱います
2. 表記のゆれ … 「打ち継ぎ」「打継ぎ」「打継」を同じ語にそろえ、「豆板」と「ジャンカ」の言い換えを辞書に入れます
3. 全角と半角 … cjk_width で、「ＲＣ」と「RC」、半角カタカナをそろえます
4. 座標の確認 … 所在地の座標が無い、または日本の範囲の外にある現場は、取り込みを止めて一覧に載せます。geo_distance の validation_method は既定の STRICT のままにし、不正な座標を黙って受け入れないようにします
5. 埋め込みの対象を絞る … 内容・原因・是正の文だけを埋め込みます。Titan Text Embeddings V2 の入力は最大8,192トークンまたは50,000文字で、検索では段落などの単位に分けることが勧められています
6. 重複の検知 … 同じ不具合が施工中の記録とクレームの記録の両方にあるときは、両方を残し、互いの記録番号を持たせます

4番目を軽く見ないでください。 座標が緯度と経度を取り違えて登録されていると、現場が海の上や外国に置かれ、近隣の現場の検索から黙って抜け落ちます。 取り込みの最初に、全現場の座標を地図に落として確かめます。

1番目と2番目は、品質管理部の仕事です。 辞書が足りないと言葉の一致が効かず、ハイブリッド検索の片方がほとんど働きません。最初は30語ほどで始め、検索で拾えなかった言葉を毎月足します。

AIに処理させる

AIの仕事は2か所です。取り込み時の項目の取り出しと、検索結果のまとめです。

3行目がいちばん起きやすい失敗です。 不具合の記録の原因の欄は空欄が多く、AIは内容と部位から原因を補いたくなります。補われた原因は、次の検討会で「過去の記録にあった原因」として扱われます。 書かれていなければ「記載なし」とします。

1行目も外せません。 「発生の可能性が高い」と書かれたリスクは、資料の上で目立ち、記録の件数が多いだけの不具合が、検討会の時間を取ります。

指示内容を固定する

取り込み時（項目の取り出し）：

あなたは建設会社の品質管理部で、完了した不具合とクレームの記録を整理する担当です。
記録に書かれたことだけを根拠にしてください。推測で埋めないでください。

【区分】
部位：基礎 / 躯体 / 外壁 / 屋上防水 / 開口部 / 内装 / 設備
不具合：漏水 / ひび割れ / 剥離・浮き / 沈下・傾き / 結露 / 仕上げ不良 / 騒音・振動 / その他
原因：材料 / 施工 / 設計 / 立地・気象 / 経年 / 不明

【やること】
次の項目を取り出してください。
- 部位、不具合、原因の区分（上の一覧から1つずつ）
- 原因：記録に書かれた文をそのまま写す
- 是正：記録に書かれた文をそのまま写す
- 発生した工程、または引き渡しからの年数

【厳守事項】
- 原因が書かれていなければ、原因の区分は「不明」、原因の文は「記載なし」にしてください。
  内容や部位から原因を推測しないでください。
- 是正が効いたかどうかが書かれていなければ、effective を null にしてください。
- 区分は記録の書き方に従ってください。迷ったら「その他」にし、
  uncertain に理由を書いてください。
- 現場の住所や関係者の名前を、原因や是正の文に書き足さないでください。

検索時（結果のまとめ）：

あなたは施工検討会の資料作りを助ける担当です。
渡された検索結果だけを根拠に、過去の不具合を部位ごとに並べてください。

【新しい現場】{new_site}
【工法が近い現場の記録】検索結果として渡します（group: method）
【近隣の現場の記録】検索結果として渡します（group: nearby）

【書くこと】
1. 部位ごとに、不具合・原因・是正（記録の記載どおり）と記録番号
2. 記録ごとに、工法が近いから出てきたのか、近隣だから出てきたのか
3. 両方のグループに出てきた部位と不具合

【厳守事項】
- 新しい現場で起きる可能性や重大度を書かないでください。
- 対策や施工計画の変更を提案しないでください。
- 原因を言い換えたり、付け足したりしないでください。
- 件数の多さを、起きやすさとして書かないでください。
- 「未確認」の印のある記録は、その旨を必ず書いてください。

検索結果は、Claude の検索結果ブロックで渡します。 1件の記録を1つの search_result にし、source に記録番号と現場番号、title に部位と不具合の区分、content に内容・原因・是正を別々のテキストブロックで入れます。グループの別は title の先頭に「[工法]」「[近隣]」と付けて示します。 引用を有効にすると、まとめの文ごとにどの記録を根拠にしたかが付き、資料のリスクの欄から元の記録へたどれます。

「件数の多さを起きやすさとして書かない」を明記しないと、「外壁の剥離が最も多く、注意が必要です」とまとめます。 件数は、過去にその工法の現場が多かっただけかもしれません。

出力形式を固定する

取り込み時の項目は、次の形のJSONで受け取ります。

{
  "record_id": "DF-2021-03318",
  "site_id": "S-2019-112",
  "source": "defect | claim",
  "part": "基礎 | 躯体 | 外壁 | 屋上防水 | 開口部 | 内装 | 設備",
  "defect": "漏水 | ひび割れ | 剥離・浮き | 沈下・傾き | 結露 | 仕上げ不良 | 騒音・振動 | その他",
  "cause_category": "材料 | 施工 | 設計 | 立地・気象 | 経年 | 不明",
  "cause": "",
  "remedy": "",
  "effective": null,
  "phase": "",
  "years_after_handover": null,
  "uncertain": ""
}

1つ目の理由は、部位と不具合を決まった値に限れることです。 担当者によって「雨漏り」「漏水」「浸水」と書き方が違っても、区分は1つにそろいます。検討会の資料を部位ごとに並べる処理は、この値で行います。

2つ目は、cause_category に「不明」を持てることです。 原因が書かれていない記録を「不明」として残すと、どの部位の不具合で原因の記録が抜けているかが数えられます。品質管理部が記録の書き方を直す材料になります。

3つ目は、source と years_after_handover で、いつ起きる不具合かを示せることです。 施工中に見つかった不具合と、引き渡しの数年後に出てきた不具合では、検討会で考える対策の時期が違います。

検索の要求は、次の考え方で組みます。

システムへ連携する

埋め込みの次元は、索引を作る前に決めます。 Titan Text Embeddings V2 の出力は1,024（既定）、512、256から選べます。索引の次元を同じ値にそろえます。 英語に最適化されたモデルで、日本語は多言語対応の一覧に入っていますが、100以上の言語はプレビューとされています。 第8章の試しで検索の質を確かめ、足りなければ言葉の一致の重みを上げるか、代替候補に切り替えます。

不具合報告の仕組みと現場の台帳には書き込みません。 資料への書き出しは下書きまでで、検討会に出すのは担当者です。

人が確認する

確認は2か所です。取り込み時の担当者と、資料作りの担当者です。

1. 担当者が項目を確定する … 是正の完了の直後に、部位・不具合・原因の区分を確かめます。uncertain が付いた記録と、原因が「不明」の記録を優先して見ます
2. 資料作りの担当者が根拠の記録を開く … 資料に載せる記録は、引用の付いた記録と写真を必ず開いて確かめます
3. 未確認の記録を確かめる … 一括取り込みの記録を載せるときは、その場で元の記録と照らし、確かめたら「確認済み」に変えます
4. 近隣の現場の記録は、立地の条件が同じかを見る … 半径の中でも、埋め立て地と台地では起きることが違います。同じ条件の現場の記録かどうかを確かめてから載せます

1件の検討会あたり75分を目安にします。 2つの検索結果を読み、うち数件の記録と写真を開いて確かめ、リスクの欄を整える時間です。

例外に対処する

上から2行目までが、取り込みの失敗の大半です。 どちらもAIの問題ではなく、現場の台帳と記録の書き方の問題です。 原因が「不明」の記録の割合を部位ごとに数えると、記録の様式を直すべき箇所が見えてきます。

記録を残す

• 取り込んだ記録の番号、完了日、取り込んだ日時、現場の属性
• Claude が返した項目のJSONと、担当者が確定した時に直した項目
• 検索のたびの新しい現場の条件、2本の検索の結果、半径
• Claude に渡した検索結果と、返ってきたまとめと引用
• 担当者が資料に載せた記録と、載せなかった記録
• 言葉の一致で拾えなかった用語の記録

5つ目の記録は、引き渡し後に見直します。 検討会で載せたのに同じ不具合が起きたのか、載せなかった不具合が起きたのか。新しい現場の不具合の記録と突き合わせると、検索の条件を直すべきか、検討会の進め方を直すべきかが分かります。