管理会社の担当から出る建物の設備・仕様の質問に、物件ごとの竣工図書・設備の仕様書・修繕履歴を根拠にチャットで答える

処理の起点を決める

管理担当がボットで物件を選び、質問を送ったときに動きます。 物件の選択は一覧から行い、自由入力にしません。一覧には物件番号・物件名・所在地を並べ、似た名前の物件を所在地で見分けられるようにします。

同じ会話の続きの質問は、選んだ物件を引き継ぎます。 別の物件の質問に移るときは、選び直してもらいます。会話の途中で物件名が出てきても、絞り込みは変えません。

図書の側の更新も、別のきっかけで動かします。修繕の工事が完了して報告書が保存されたときに、その報告書にメタデータを付けて取り込みます。ここが止まると、第3章（c）がそのまま残ります。

入力データを集める

質を決めるのは、4行目のメタデータです。 物件番号が付いていなければ、物件で絞り込めません。図書の日付が付いていなければ、竣工時の値と修繕後の値を並べられません。AIの性能より先に、この一覧の正しさが答えの正しさを決めます。

設備台帳は表計算のまま取り込みます。 型式や容量は台帳がいちばん新しいことが多いからです。ただし台帳は誰がいつ更新したかが分からないことがあり、図書の日付と並べて示します。

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

図書は Cloud Storage に物件ごとのフォルダで写し、メタデータは JSON Lines のファイルで渡します。 1行が1ファイルで、id、structData（物件番号などの項目）、content（mimeType と uri）を持たせます。

{"id": "B0123-as-built-elec-01", "structData": {"building_id": "B0123", "doc_type": "as_built", "doc_date": "2006-03-20", "discipline": "electrical"}, "content": {"mimeType": "application/pdf", "uri": "gs://bucket/B0123/as_built_elec_01.pdf"}}

絞り込みに使う項目は、スキーマで「インデックス可能」にします。 公式ページでは、インデックス可能にしても絞り込みに使えることが保証されるわけではないとされています。取り込んだ後に、物件番号の絞り込みが効くことを必ず試してください。 1ファイルの上限は200MBです。それを超える竣工図書は、分野ごとに分けて写します。

検索の呼び出しでは、searchSpec.searchParams.filter に building_id: ANY("B0123") を入れます。 物件番号はボットで選ばれた値をそのまま入れ、質問の文章から作りません。

AIへ渡す前に整形する

1. 紙の図書のスキャン … 300dpi 程度を目安にPDFにします。図面の寸法や容量の文字は小さいので、既定の設定では読めないことがあります
2. 大きなPDFの分割 … 1ファイル200MBを超えるものは、電気・給排水などの分野ごとに分けます
3. メタデータの付与 … 1ファイルずつ物件番号・図書の種類・日付・分野を付けます。日付は図書の表紙か報告書の完了日から取り、ファイルの更新日時を使いません
4. データストアの設定 … チャンク分割を有効にし、既定のパーサーをレイアウト パーサーにします。includeAncestorHeadings を有効にし、チャンクに上位の見出しを付けます
5. 取り込み … Cloud Storage からインポートします。フォルダの中は再帰的に取り込まれます
6. 絞り込みの確認 … 物件を1つ選んで検索し、別の物件の図書が1件も混ざらないことを確かめます

4番目の見出しの付与は、図書の構成に効きます。 仕様書の途中のチャンクは「容量 75kVA」のような行だけになりがちです。上位の見出し（「受変電設備」「変圧器」）が付いていないと、何の容量かが分からないチャンクになります。

チャンクの大きさは100〜500トークンで、既定は500です。 機器表のように1行ずつ意味が完結する図書が多いので、既定のまま始め、引用が細切れすぎるかどうかを見て決めます。

AIに処理させる

させるのは、選んだ物件の図書から質問に当たる記載を探し、書かれている値を引用つきで答えることだけです。

4行目が、この構成の線引きです。 増設の可否は、図書の値に加えて現在の使用状況や法令の確認が要ります。図書の値を示すところまでは答え、可否の判断は技術担当へ回します。

2行目がいちばん起きやすい失敗です。 「変圧器が75kVAで、現在の契約が50kVAなら残りは25kVA」と答えたくなりますが、残りの容量は機器の構成と実際の負荷で決まります。 計算させず、値と出典だけを返させます。

指示内容を固定する

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

あなたは建物管理会社の図書係です。管理担当からの建物の仕様の質問に、
検索された図書の記載だけを根拠に答えてください。

【答え方】
- 図書に書かれている値と記載を、そのまま答えてください。
  数値は単位も含めて、図書の表記どおりに写してください。
- 答えの各文には、根拠にした図書の引用を付けてください。
- 竣工図書と修繕の工事報告書の両方に記載がある場合は、
  日付の新しいほうを先に書き、古いほうを「竣工時の記載」として後に書いてください。
- 竣工図書の値だけが見つかった場合は、文末に
  「竣工時の図書の記載です。その後の改修の有無は確認できていません」と書いてください。

【してはいけないこと】
- 数値の計算をしないでください。容量の残り、荷重の合計、
  単位の換算をしないでください。
- 図書に書かれていない値を、一般的な仕様や推測で答えないでください。
  見つからないときは「図書に記載が見つかりませんでした」とだけ答えてください。
- 増設・設置・変更をしてよいかという質問には、可否を答えないでください。
  「可否の判断は技術担当が行います」と書き、関係する記載だけを示してください。
- 物件名や物件番号が質問に出てきても、それを理由に別の物件の話をしないでください。

「単位も含めて図書の表記どおり」を書くのは、図書の単位が年代で違うからです。 古い図書には kgf/m² のような旧い単位が残っていることがあり、換算されると、元の図書と突き合わせられなくなります。

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

3行目の FILTERING_LEVEL_HIGH は、数値を答える構成には欠かせません。 根拠づけの基準を満たさない答えは、LOW_GROUNDED_CONTENT として答えが出ません。答えが出ない件数は増えますが、それは技術担当に回る件数として見えます。 根拠の弱い数値がテナントに届くより、ずっと扱いやすい失敗です。

出力形式を固定する

answer メソッドの応答から、中継プログラムが次の形に組み直してチャットへ返します。

{
  "building_id": "B0123",
  "answer_text": "",
  "skipped": false,
  "skipped_reasons": [],
  "sources": [
    {
      "title": "",
      "uri": "",
      "doc_type": "as_built | repair | ledger",
      "doc_date": "",
      "quote": ""
    }
  ],
  "newer_repair_exists": false,
  "route_to_engineer": false,
  "route_reason": ""
}

1つ目の理由は、skipped と skipped_reasons で「答えなかった」ことを明示できることです。 answer メソッドは、関連する内容が無いとき NO_RELEVANT_CONTENT を、根拠づけの基準を満たさないとき LOW_GROUNDED_CONTENT などを answerSkippedReasons に返します。これらが返ったものは、答えとして表示せず技術担当へ回します。

2つ目は、doc_date で竣工時と修繕後を並べ直せることです。 引用の referenceId から参照を引き、参照の文書からメタデータの日付を取ります。同じ分野の修繕報告が竣工図書より新しければ newer_repair_exists を立て、答えの冒頭に出します。

3つ目は、引用の位置の扱いです。 citations の startIndex と endIndex は、文字数ではなく UTF-8 のバイト数で返ります。日本語は1文字が複数バイトなので、文字の位置として使うとずれます。答えの文に引用の印を差し込むときは、バイト列で切ってから文字に戻します。

チャットに表示する答えの例です。

【物件】B0123 〇〇ビル（〇〇区〇〇町）
【答え】
屋上の防水は、2016年の改修工事で塩ビシート防水の機械的固定工法に
改修されています。［修繕報告：屋上防水改修工事 完了報告書 p.3／2016-11-30］
竣工時の記載は、アスファルト防水の露出工法です。
［竣工図書：建築仕様書 p.12／2006-03-20］
【確認してください】
引用のページを開いて、工法と範囲を確かめてから回答してください。

物件名と所在地を答えの先頭に必ず出すのは、第3章（d）の対策です。 管理担当が問い合わせの物件と見比べられるよう、答えの中身より先に、どの物件の答えかを見せます。

システムへ連携する

中継プログラムは、検索の絞り込みを組み立てる唯一の場所です。 チャットから受けた物件番号を filter に入れ、質問の文章は query にだけ渡します。 物件番号を質問の文章に混ぜて検索に任せると、似た名前の物件の図書が上位に来ることがあります。

判断を求める質問の見分けは、中継プログラムで行います。 「してよいか」「置けるか」「足りるか」などの言い回しを辞書で拾い、route_to_engineer を立てます。拾い漏れがあっても、指示で可否を答えさせないので二重の守りになります。

人が確認する

管理担当は、テナントやオーナーへ数値を答える前に、引用の箇所を開いて確かめます。 ボットの答えをそのまま転記しません。

1. 物件を確かめる … 答えの見出しに出る物件名と所在地が、問い合わせの物件と合っているか
2. 図書の日付を確かめる … 竣工時の記載だけなら、修繕で変わっていないかを相手に断るか、技術担当に確かめる
3. 引用の箇所を開く … 数値は図書のそのページで目で見る

技術担当が見るのは、回ってきた質問だけです。 答えを書いたら、その答えと根拠にした図書の箇所を記録に残します。同じ質問が別の担当から来たとき、記録が次の答えの材料になります。

例外に対処する

5行目は避けられません。 レイアウト パーサーは図面の文字も読もうとしますが、図面の中の小さな寸法や容量の文字は、スキャンの品質しだいで読めません。 読めなかった質問の記録が溜まった図書から、スキャンし直すかを決めます。

記録を残す

• 質問の日時、質問者、選んだ物件番号、質問の文章
• answer メソッドの応答の全文（答え、引用、参照、answerSkippedReasons）
• 中継プログラムが組み直した答えと、newer_repair_exists・route_to_engineer の値
• 技術担当に回したものの答えと、根拠にした図書の箇所
• 管理担当が答えを使わなかった記録（「違っていた」ボタン）

最後の記録が、図書の整備の材料になります。 同じ物件で「違っていた」が続くなら、メタデータの物件番号か日付が誤っているか、修繕報告が取り込まれていません。