建物・設備の法定点検の要否と期限を、根拠付きで答えられるようにする

処理の起点を決める

社内ポータルの照会フォームの送信を起点にします。 メールとチャットで受けている今の形では、建物名も設備の種類も書かれていない照会が半分近くを占め、聞き返すところから始まります。

フォームで必ず取るのは3つです。建物（台帳の一覧から選ぶ）、設備の種類（建築／防火設備／建築設備／昇降機等／消防／分からない）、聞きたいこと（要否／期限／誰がやれるか／手続き／その他）。 自由記述はそのあとです。

「分からない」を選べるようにしてください。 現場は設備の区分を知りません。埋めさせると適当に選ばれ、検索が外れます。分からないと書かれていれば、自由記述から拾う経路へ回せます。 メールとチャットの窓口も残し、総務がフォームに転記します。

入力データを集める

質を決めるのは、上から3行目と4行目です。 別名列が無いと「本館」「◯◯寮」といった呼び方で台帳が引けません。取得日が無いと、いつ時点の説明なのかを回答に書けません。

点検台帳には、判定のための列を足します。 用途、階数、延べ面積、所在地の自治体。要否の話は、この4つに毎回ぶつかります。 過去の照会記録は、人がどこを直したかを見るために持ちます。

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

台帳は日次で読み、1行を1つの文書として索引に入れます。1行の中に「棟の名称・別名・用途・所在地・設備の区分・前回実施日・実施者・次回の目安」を1つの文として持たせます。 値だけを並べた行は、意味での検索にかかりません。

公開資料は月次で取り直して索引に入れます。保存するのは本文とURLと取得日、そして本文のハッシュです。 ハッシュが変われば更新されたということなので、その資料を根拠にした回答を一覧にします。

検索は、建物で先に絞り、そのうえでハイブリッド検索をかけます。 取るのは、台帳の該当行（実績）、公開資料の制度の記述（考え方と頻度の文言）、セマンティックキャプション（根拠として示す逐語の箇所）、過去の回答（人が直した箇所）の4つです。

@search.rerankerScore は0.00から4.00で返り、@search.score とは別に報告されます。 この値で足切りをするなら、しきい値を細かくしすぎないでください。 分布は環境やモデルの更新で変動しうるとされています。

AIへ渡す前に整形する

1. 必須項目の確認 … 建物・設備の種類・聞きたいことがそろっているか。不足はその場で聞き返す
2. 建物名の正規化 … 別名列と突き合わせ、台帳の建物IDに変換する。複数に当たれば候補を出す
3. 台帳の行の取得 … その建物の全設備の行を取る。区分が「分からない」でも全行を持つ
4. 公開資料の絞り込み … 所在地の自治体の資料を優先し、無ければ一般的な説明を使う
5. 取得日の確認 … 3か月以上前なら、回答に「この時点の資料です」と添える
6. 文字数の調整 … 台帳の行と資料の抜粋をあわせて、渡す量の上限に収める
7. 重複の確認 … 同じ建物・設備の照会が直近にあれば、前回の回答を添える

2番目を軽く見ないでください。 建物名の表記ゆれが、この構成で最も多い失敗です。「◯◯ビル」「◯◯ビルディング」「旧△△ビル」が同じ棟を指していることが、48棟もあれば必ず起きます。

6番目の上限には根拠があります。 要約モデルが1文書あたり最大2,000トークンを受け取り、トークンは約10文字とされています。超えた分は無視されるので、行を長くしすぎると末尾の「次回の目安」が落ちます。

AIに処理させる

させるのは、照会を切り分けて台帳と突き合わせ、関係しそうな制度を並べることまでです。 具体的には、①照会の分類、②建物の特定（名称・別名・住所との突合）、③実績の書き写し（前回実施日・実施者・次回の目安をそのまま写す）、④関係しそうな制度（資料の区分名と頻度の文言、資料のID）、⑤確認すべき点（用途・階数・延べ面積・所在地の窓口）、⑥経路の判定材料の6つです。

ここに applies: true / false のような欄を置きません。 欄があれば埋まり、埋まれば回答に出ます。適用の可否を書く場所を作らないのが設計です。

3行目がいちばん起きやすい失敗です。 「毎年」と書かれた資料と前回実施日があれば、1年後の日付を出せてしまいます。その日付は期限ではありません。 目安として出すのと期限として出すのとでは、現場の動きが変わります。

指示内容を固定する

1つ目の呼び出し（切り分けと突合）です。

あなたは総務部門で、建物と設備の法定点検についての社内照会を切り分ける立場です。
渡された資料と台帳の行に書かれていることだけを使ってください。推測で補わないでください。

【してはいけないこと】
- 個別の建物が制度の対象に当たる／当たらないという結論を書かないでください。
- 条文の解釈を書かないでください。罰則に触れないでください。
- 台帳に行が無い建物について、一般論から実績や日付を作らないでください。
- 「次回の目安」を期限として書かないでください。台帳の値をそのまま写してください。
- 所在地の自治体の資料が無いときに、他の自治体の資料をその建物に当てないでください。

【すること】
1. 照会が何を聞いているかを asked_about に入れる
2. 建物名を台帳の名称・別名・住所と突き合わせ building.match を決める
   複数に当たるときは ambiguous にし、候補を building.candidates に並べる
3. 台帳に行があれば、前回実施日・実施者・次回の目安を ledger_record にそのまま写す
   行が無ければ found を false にし、他の値は空のままにする
4. 関係しそうな制度を regime_candidates に並べる
   name は資料の区分名、frequency_text は頻度の文言をそのまま、
   source_id は根拠にした資料のID、why_it_may_apply は
   「〜であれば対象になりうる」という条件の形で書く
5. 確かめるべき点を points_to_confirm に並べる
   （主要用途、階数、延べ面積、所在地の特定行政庁、前回の報告書の有無など）
6. route を決める
   - answer_with_source … 台帳に行があり、関係しそうな制度も資料から示せる
   - needs_check ......... 台帳に行が無い、建物が複数に当たる、
                          資料からは制度の区分を絞れない
   - out_of_scope ........ 法定点検の照会ではない
   迷ったときに answer_with_source を選ばないでください。

【台帳から引いた行】{ledger_rows}
【公開資料（IDつき）】{source_docs}
【照会の本文】{inquiry_text}

2つ目の呼び出し（制度の説明）です。資料を文書として渡し、引用を有効にします。

渡した資料に書かれている範囲だけで、制度の考え方を3文から4文で説明してください。
この建物が対象に当たるかどうかは書かないでください。
「一般にはこうとされています」という書き方にし、資格に触れるときは
資料に書かれた資格の名称をそのまま使ってください。最後に次の一文を必ず添えてください。
「報告の時期と対象は所在地の特定行政庁によって異なります。
　{municipality}の窓口でご確認ください。最終的な判断は所管の窓口と有資格者が行います。」

「迷ったときに answer_with_source を選ばない」を書かないと選びます。 資料に制度の説明があり、台帳にも似た名前の行があるからです。「他の自治体の資料を当てない」も同じで、 東京都の資料しか無い状態で別の県の建物を聞かれると、手元にあるもので答えようとします。

出力形式を固定する

1つ目の呼び出しは、次の形のJSONで受け取ります。

{
  "inquiry_id": "",
  "asked_about": "requirement | deadline | qualification | procedure | other",
  "building": {
    "ledger_id": "",
    "name": "",
    "match": "matched | ambiguous | not_found",
    "candidates": [""]
  },
  "equipment_category": "building | fire_door | building_equipment | elevator | amusement | fire_service | unknown",
  "ledger_record": {
    "found": true,
    "last_done_on": "",
    "performed_by": "",
    "next_due_guide": ""
  },
  "regime_candidates": [
    { "name": "", "frequency_text": "", "source_id": "", "why_it_may_apply": "" }
  ],
  "points_to_confirm": [""],
  "route": "answer_with_source | needs_check | out_of_scope",
  "route_reason": ""
}

構造化出力は output_config.format（type に json_schema、schema にスキーマ本体）で指定します。 オブジェクトでは additionalProperties を false にする必要があり、再帰的なスキーマ、minimum などの数値の制約、minLength などの文字列の制約は非対応です。配列の minItems は0と1のみ。points_to_confirm の件数をスキーマで縛れないのは、このためです。

2つ目の呼び出しでは、構造化出力を使いません。引用と構造化出力は併用できないからです。 渡した文書（document ブロックや search_result ブロック）で引用を有効にし、あわせて output_config.format を指定すると、APIは400エラーを返します。 引用は引用ブロックとテキスト出力を交互に挟む必要があり、構造化出力の厳密なJSONスキーマの制約と両立しないためです。

1回で済ませようとすると、根拠の箇所を示せない説明文か、形の定まらない切り分け結果のどちらかを諦めることになります。 なお引用の粒度は文書の種類で変わり、PDFはページ番号の範囲（1始まり）、プレーンテキストは文字インデックスの範囲（0始まり）です。資料をプレーンテキストで持てば、引用箇所を文字位置で残せます。

システムへ連携する

台帳へ書き込まないことを、設計の線として引きます。 「前回実施日が空だったのでPDFから読んで埋めた」という処理を足したくなりますが、機械が埋めた値と人が入れた値が混ざると、台帳を根拠として示せなくなります。

人が確認する

総務が全件の回答案を開きます。 月60件なので、開かないという選択にはしません。見る順番と深さを変えます。

1. needs_check と out_of_scope を先に見る … 台帳に行が無い、建物が複数に当たる、区分を絞れないもの。ここは調べ直しになります
2. answer_with_source の引用を確かめる … 説明が引用された箇所の範囲を超えていないか
3. 台帳の値を確かめる … 前回実施日と実施者が、台帳の行と一致しているか
4. 断定になっていないかを見る … 「対象です」「期限は◯月◯日です」が混じっていないか
5. 直したら記録する … どこを、どう直したかを照会記録に残します

4番目を毎回見てください。 指示で禁じていても、文の流れで断定に寄ることがあります。「一般にはこうとされています」が「こうなります」に変わっているだけで、現場は決まったものとして動きます。 目標は60件をならして1件4分で、needs_check のものは別に時間を取ります（第10章では2分）。

例外に対処する

上の2行が最も多くなります。 どちらも台帳の整備で減ります。AIの精度の話ではありません。

記録を残す

• 照会の原文（入力値と自由記述）、送信者と所属、受付日時
• 検索の結果（採った文書のID、@search.rerankerScore、キャプション）
• 1つ目の呼び出しのJSONと、2つ目の呼び出しの本文および引用された箇所
• そのとき参照した資料のURL・取得日・ハッシュ
• 人が直した箇所（どの文を、どう直したか）と、送った回答
• needs_check になった理由の分類と、その後どこへ確かめたか

4つ目が、後からいちばん効きます。 資料が更新されたときに、どの回答がどの版を根拠にしていたかを引けるのは、これを残している場合だけです。

最後の行は、台帳に足す列を決める材料です。 「延べ面積が分からないので絞れない」が続くなら、その列を足す。答えるたびに、次から答えられる範囲が広がります。