建築設計事務所が過去の物件の特記仕様書・仕上表・打合せ記録を横断して検索し、用途と規模の近い物件で採用した仕様とその理由を根拠付きで探す

処理の起点を決める

処理の起点は2つあります。 設計者が検索画面から条件と質問を送ったときと、毎晩の取り込みで、新しく竣工した物件の書類と補足の記録をデータストアに入れるときです。条件を変えた検索は別の1件として記録します。

取り込みは、竣工を起点にします。 設計中の物件の書類は版が日々変わるので入れません。設計中の物件を入れると、決まっていない仕様が「採用した仕様」として返ります。

入力データを集める

質を決めるのは、物件の属性と変更の記録です。 属性が空いていると、その物件は絞り込みから落ちます。変更の記録が無いと、竣工までに変わった仕様が見分けられません。打合せ記録は、700件分を書き直せないので日付ごとのまま入れます。

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

物件ごとに、どの版を入れるかを技術管理室が決めます。 フォルダの中の「最終」「最終2」から竣工時の版を選ぶのは、機械ではできません。竣工時の版が分からない物件は、監理の記録の日付と照らして選び、選べないものは入れないで一覧に残します。

メタデータの1行は、次のように書きます。

{"id": "P0412-finish-completed",
 "structData": {"project_id": "P0412", "doc_type": "finish_schedule",
   "doc_stage": "completed", "use_type": "nursery", "floor_area": 1980,
   "floors": 2, "structure": "RC", "completed_year": 2019,
   "designer": "設計部 担当A", "confidential": false},
 "content": {"mimeType": "application/pdf",
   "uri": "gs://archive-bucket/P0412/finish_completed.pdf"}}

仕上表は、XLSX のままか PDF にするかを第8章の試行で決めます。 結合したセルの多い表は、室名と材料が同じ塊に入るかを見ます。

絞り込みに使う属性は、スキーマで Indexable にします。 公式のページは、絞り込みに使う項目をアプリの Data のページの Schema のタブで Indexable にするよう求めています。use_type、floor_area、structure、completed_year、doc_stage、doc_type、confidential を Indexable にします。

AIへ渡す前に整形する

1. 竣工時の版を選ぶ … フォルダから竣工時の仕上表と特記仕様書を選びます。選べない物件は入れずに一覧に残します
2. 物件の属性を埋める … 一覧表の延べ面積と構造の空欄を、図面の表紙から埋めます。空欄のまま入れると、絞り込みで落ちます
3. 用途の語をそろえる … 「保育園」「保育所」を、絞り込みの語（nursery）にそろえます
4. 見出しを確かめる … 打合せ記録の「議題」「決定事項」、特記仕様書の章と節が、文書の見出しとして書かれているかを見ます。太字の文字だけの見出しは、見出しとして検出されないことがあります
5. 発注者の名前と個人の名前を外す … 打合せ記録の出席者の個人名は役割（園長、施設長、発注者の担当）に置き換えます。発注者の名称は物件番号に置き換えます
6. 守秘の物件を分ける … 発注者との取り決めで社内でも閲覧を限る物件は、confidential: true を付けるか、別のデータストアに入れます
7. 分割の設定 … 文書の分割を有効にし、見出しを各塊に含めます（第7章「AIに何をさせるのか」で詳しく）

4番目を軽く見ないでください。 「決定事項」が見出しとして検出されないと、床の理由の段落が前の議題の塊とつながって切り出されます。

分割の設定は公式のページの値に合わせます。 chunkSize は1塊あたりのトークンの上限で100〜500（既定500）、見出しを各塊に含める includeAncestorHeadings の既定は false です。途中の塊に見出しを足すと文脈が失われにくいとされ、「9章 左官工事 ／ 2節 床仕上げ」が無いと何の工事の話か分からないので true にします。

AIに処理させる

させるのは、条件に合う物件の書類から、部位の仕様と採用の理由の箇所を探し、引用付きで並べることだけです。 新しい物件で何を使うべきかは言わせません。

右端の列の3行目が、いちばん大事な決まりです。 補った理由は引用を持たないので、引用の有無で機械的に見分けます。

検索は2段で行います。 まず search メソッドで、絞り込みの条件に合う書類を探し、物件番号でまとめて候補の物件の一覧を作ります。次に answer メソッドで、同じ絞り込みのもとで仕様と理由を探させます。

絞り込みの条件は、公式のページの書き方に合わせます。 文字の項目は ANY で完全一致、数値は IN の範囲か比較の演算子、日付は ISO 8601 の文字列で比べ、AND、OR、NOT で組み合わせます。数値の範囲の IN は、既定で下限を含み、上限を含みません。

use_type: ANY("nursery") AND floor_area: IN(1500, 2500e)
AND structure: ANY("RC") AND completed_year >= 2012
AND confidential = "false"

延べ面積の範囲は、今の物件の前後3割を画面の初期値にします。

answer メソッドの主な設定は次のとおりです。

指示内容を固定する

answer メソッドの promptSpec.preamble に入れる指示です。

あなたは建築設計事務所の技術管理の担当として、設計者の質問に、
過去の物件の書類から該当箇所を探して答える立場です。
検索結果に含まれる書類だけを根拠にしてください。

【答え方】
- 物件ごとに分けて書いてください。物件番号を必ず書いてください。
- 物件ごとに、次の順で書いてください。
  1. 採用した仕様（材料・品番・施工の条件）
  2. 竣工までの変更（あれば）
  3. 採用の理由
- 仕様は、仕上表と特記仕様書の書きぶりのまま写してください。
  品番や寸法を言い換えたり、まとめたりしないでください。

【書類の段階】
- 竣工時の書類（doc_stage が completed）を優先してください。
- 実施設計の書類（design）しか無い物件は、
  「実施設計の版による。竣工時の版は未確認」と書いてください。
- 変更の記録（change）に、その部位の変更があれば、
  変更前と変更後と、変更の理由を書いてください。

【採用の理由】
- 理由は、打合せ記録・変更の記録・補足の記録に書かれた文だけを
  根拠にしてください。
- 理由が書かれた箇所が見つからないときは、「理由の記録なし」と書いてください。
- 一般的な性能や、ふつう選ばれる理由で補わないでください。
  「〜と考えられます」「〜のためと推測されます」と書かないでください。
- 打合せで出た要望と、決まったことを分けてください。
  要望が出ただけで決まっていないものを、採用の理由にしないでください。

【書かないこと】
- 今の物件でどの仕様を使うべきかを書かないでください。
- 法令に適合するか、その製品が今も買えるかを書かないでください。
- 発注者の名称と個人の名前を書かないでください。

「〜と考えられます」を名指ししているのは、理由の補いがこの言い方で出るからです。 「推し量らないでください」とだけ書くと、和らげた言い方で推し量ります。

「要望と決まったことを分ける」は、打合せ記録に特有の決まりです。 「園長より、床は柔らかいものを希望」の回と「クッション性のあるシートに決定」の回があり、前者だけを返すと、決まらなかった要望を採用の理由として受け取ります。

出力形式を固定する

answer メソッドの返り値を、中継プログラムが次の形のJSONに組み直して画面に渡します。

{
  "query_id": "Q-20261015-0031",
  "conditions": {"use_type": "nursery", "floor_area": [1500, 2500],
                 "structure": "RC", "completed_year_from": 2012},
  "projects": [
    {
      "project_id": "P0412",
      "floor_area": 1980, "completed_year": 2019,
      "spec": {"text": "", "doc_stage": "completed", "citation_ids": [1]},
      "change": {"exists": true, "before": "", "after": "",
                 "reason": "", "citation_ids": [3]},
      "reason": {"status": "cited | no_record | request_only",
                 "text": "", "citation_ids": [2]},
      "designer": "設計部 担当A"
    }
  ],
  "citations": [
    {"id": 1, "document": "P0412-finish-completed",
     "uri": "gs://archive-bucket/P0412/finish_completed.pdf",
     "quote": ""}
  ],
  "ask_list": [{"project_id": "", "part": "", "designer": ""}],
  "answer_skipped": ""
}

1つ目の理由は、reason.status を引用の有無から機械的に決められることです。 引用元が打合せ記録・変更の記録・補足の記録なら cited、無ければ no_record で、モデルが理由を書いていても、引用が無ければ no_record にします。

2つ目は、request_only を分けられることです。 引用の段落の見出しが「要望」で「決定」でないものを、中継プログラムが分けます。3つ目は、ask_list で聞く先を出せることです。

引用の位置は、UTF-8 のバイト単位です。 公式のページは、startIndex と endIndex が文字ではなくバイトで数えられるとしています。日本語の回答を文字の位置で切ると、引用がずれます。 バイト列にしてから切り出して文字に戻し、startIndex が0のときは省かれることにも注意します。引用の本文は references の chunkInfo.content から、書類の場所は documentMetadata の uri から取ります。

システムへ連携する

物件のフォルダには書き込みません。 竣工時の版を Cloud Storage に写したものを検索するだけです。検索画面は社内の認証の後ろに置き、守秘の物件は閲覧を許された設計者の検索にだけ含めます。

人が確認する

設計者は、使う仕様について必ず引用の原文を開きます。 回答の文は、引用の箇所をまとめ直したものです。品番や寸法が写し間違えられていないかは、原文でしか確かめられません。

1. 物件の一覧を見る … 候補が本当に似ているかを、延べ面積・構造・竣工年で確かめます
2. 仕様の引用を原文で開く … 品番・寸法・施工の条件を原文で確かめます
3. change を見る … 変更の理由が施工上の不具合なら、その仕様は避ける材料になります
4. reason.status を見る … request_only は決まったかを記録で確かめ、no_record は担当した設計者に聞きます
5. 今の物件の条件と照らす … 法令、発注者の要望、製品が今も買えるかを、設計者が確かめます。この構成はここを代わりません

5番目を省かないでください。 竣工が10年前の物件の品番は、廃番になっていることがあります。

例外に対処する

上から3行目までは、AIの失敗ではありません。 「該当なし」を失敗と見なして答えを作らせると、理由の補いと同じことが物件の単位で起きます。

記録を残す

• 検索の条件（用途、延べ面積の範囲、構造、竣工年の範囲、部位、質問の文）と、条件を広げたかどうか
• search メソッドが返した物件の一覧と、answer メソッドの回答の全文
• 引用の一覧（文書、uri、引用の本文）と、reason.status の判定
• 設計者が原文を開いた引用と、no_record の聞き取りの結果
• その時点のデータストアの物件の数と、取り込みの日付

3つ目の reason.status の記録は、理由の記録がどこで欠けているかの地図になります。 特定の年代や設計者の物件で no_record が多ければ、そこが聞き取りを急ぐ先です。