建築設計事務所が過去の確認申請の質疑・指摘の記録を OpenSearch に入れ、新しい計画で指摘されやすい点を申請の前に探す

処理の起点を決める

トリガーは2つあります。 1つは毎晩の取り込みで、確認済証が交付されて閉じた案件の質疑・指摘を索引に入れます。もう1つは事前確認の依頼のフォームの送信で、ここで検索を動かします。

取り込みは、審査が終わった案件だけにします。 審査の途中の案件は、回答書が書きかけで、指摘に対する事務所の答えが決まっていません。答えの決まっていない指摘を引くと、担当者が未確定の回答をまねるおそれがあります。

依頼は、計画の概要が固まった時点で1回、図書をまとめる直前にもう1回出せるようにします。 2回目は計画の変更を反映した条件で探し直し、1回目の一覧から増えた指摘と消えた指摘を分けて出します。

計画変更の確認申請も、同じ依頼で扱います。 変更の内容をフォームに書けば、変更に関わる条項の指摘を探します。

入力データを集める

質を決めるのは、案件の属性が指摘に付いているかです。 指摘の文だけを索引に入れると、共同住宅の指摘と戸建て住宅の指摘が混ざって引けます。属性は案件の台帳から引いて、指摘の1件ずつに写します。

条項の一覧は、事務所の言い方をそろえるために作ります。 審査機関の様式では「法第35条」「令第126条の2」と書くところもあれば、「排煙」「避難」と見出しで書くところもあります。一覧に条項の番号と見出しを並べ、取り込みのときに番号へそろえます。

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

質疑書・指摘事項は、案件のフォルダから PDF と Word を取り出し、指摘の番号ごとに1件に分けます。 審査機関の様式は数種類なので、様式ごとに「指摘の番号」「指摘の文」「回答の文」の位置を決めて取り出します。 様式の決まらない古い記録は、取り込みの対象から外して一覧に残します。

取り出した指摘には、次の項目を付けて索引に入れます。

article は1件に複数入ることがあります。 「排煙と内装制限の両方」のような指摘は、両方の条項を付けます。集計では両方の条項に1件ずつ数えられるので、その旨を一覧に書きます。

case_id と finding_no を文書の識別子にして上書きで入れます。 同じ案件の取り込みをやり直しても、同じ指摘が二重に入りません。

AIへ渡す前に整形する

1. 様式ごとに指摘を分ける … 指摘の番号の行を見つけ、次の番号までを1件にします
2. 条項の番号をそろえる … 「法35条」「建基法第35条」「法第三十五条」を 法35 にそろえ、見出しだけの指摘には条項の一覧から候補を付けます。候補が2つ以上なら article_unsure の印を付けます
3. 用途の区分をそろえる … 「共同住宅」「マンション」「賃貸住宅」を事務所の区分にそろえます
4. 固有名詞を記号に置き換える … 建築主の氏名、所在の地番、審査の担当者の氏名を記号に置き換えます
5. 制度の区分を付ける … 指摘を受けた年月が2025年4月より前か後かで regime を付けます
6. 辞書を整える … 「避難上有効なバルコニー」「竪穴区画」のような語を、Sudachi のユーザー辞書に入れます

2番目の article_unsure は、集計から外して別に数えます。 条項の候補を推測で決めて集計に入れると、件数の多い条項が実際より多く見えます。

6番目のユーザー辞書は、更新がすぐには効きません。 Amazon OpenSearch Service の公式ページは、Sudachi の辞書のファイルを関連付け直しても、次のブルー／グリーンのデプロイまでドメインに反映されないとしています。急ぐなら、新しいパッケージで新しい索引を作って入れ直し、索引の別名（エイリアス）を付け替えて切り替えます。

AIに処理させる

生成AIにさせることは2つです。 1つは、計画の概要から検索の手がかりを取り出すこと、もう1つは、引けた指摘を条項ごとの一覧にまとめることです。

3行目がいちばん起きやすい失敗です。 生成AIは建築基準法の一般的な知識を持っているので、引けた指摘に無い条項まで「よくある指摘」として足します。足された項目は事務所の記録ではなく、根拠を開けません。 照合で記録の番号の無い項目を捨てます。

4行目の「一般化しない」も同じ理由です。 1件の指摘から「この窓口はこの点に厳しい」と書くと、担当者は件数を見ずに決まりとして覚えます。 件数と年月を並べ、判断は担当者に任せます。

指示内容を固定する

あなたは建築設計事務所の設計監理部で、確認申請の前に過去の指摘を
確かめる立場です。下の【検索で引けた指摘】と【条項ごとの件数】だけを
使って、今回の計画で確かめる項目の一覧を作ってください。

【作るもの】
- 条項ごとに、引けた指摘の要点と、当時の回答の要点をまとめる
- 各項目に、根拠にした指摘の case_id と finding_no を必ず付ける
- 引けた指摘の案件と今回の計画の違い（用途・規模・構造・申請先）を書く

【厳守事項】
- 【検索で引けた指摘】に無い指摘や条項を足さないでください。
  一般的に指摘されやすいと思う点があっても書かないでください。
- 件数は【条項ごとの件数】の値を写してください。数え直さないでください。
- 計画が法に適合しているか、指摘を受けるかどうかを書かないでください。
- 「この窓口は必ず」「いつも」のような言い方をしないでください。
- regime が before_2025_04 の指摘には、制度の改正前の記録であることを
  note に書いてください。
- 回答の文が無い指摘は、answer_summary を空にし status を no_answer に
  してください。回答を推測で書かないでください。
- 建築主の氏名や所在の地番が記号に置き換わっている箇所を、元に戻そうと
  しないでください。

【今回の計画の概要】{plan}
【検索で引けた指摘】{hits}
【条項ごとの件数】{article_counts}
【条項の一覧】{articles}

「一般的に指摘されやすいと思う点があっても書かない」を明記しないと、項目が増えます。 増えた項目はもっともらしく、担当者は根拠を開かずに読み流します。この一覧の価値は事務所の記録であることなので、記録に無いものは1行も入れません。

「数え直さない」も同じ理由です。 生成AIに引けた10件から数えさせると、集計の値と食い違います。件数は集計の側にだけ置きます。

出力形式を固定する

{
  "request_id": "PC-2026-1102",
  "plan": { "use_group": "共同住宅", "structure": "RC", "stories": 5,
            "floor_area": 1850, "authority": "A市", "reviewer": "B機関" },
  "items": [
    {
      "article": "令126の2",
      "title": "排煙設備",
      "count_same_reviewer": 7,
      "count_all": 23,
      "findings": [
        { "case_id": "K-2023-114", "finding_no": "12",
          "finding_summary": "", "answer_summary": "",
          "regime": "after_2025_04", "status": "ok" }
      ],
      "differences": "",
      "note": ""
    }
  ]
}

JSON にする1つ目の理由は、照合を機械にできることです。 case_id と finding_no の組が検索の結果に無ければ、その指摘を捨てます。count_same_reviewer と count_all は集計の値と比べ、違えば集計の値で上書きして記録に残します。

2つ目は、根拠に1回で戻れることです。 一覧の画面では case_id から案件のフォルダの質疑書を開けるようにします。

スキーマは Bedrock の決まりに合わせます。 すべての object に additionalProperties: false を付けます。数値の minimum・maximum は使えないので、件数の範囲はプログラムで確かめます。任意の項目は全体で12個までなので、項目はすべて required にし、空の場合は空の文字列で返させます。

集計は、検索とは別のリクエストで、次の形で取ります。

{
  "size": 0,
  "query": { "bool": { "filter": [
    { "term": { "use_group": "共同住宅" } },
    { "term": { "structure": "RC" } },
    { "range": { "floor_area": { "gte": 1000, "lte": 3000 } } }
  ] } },
  "aggs": {
    "by_article": { "terms": { "field": "article", "size": 20 } },
    "same_reviewer": { "filter": { "term": { "reviewer": "B機関" } },
      "aggs": { "by_article": { "terms": { "field": "article", "size": 20 } } } }
  }
}

size を20にしているのは、既定の10では件数の多い条項が切れることがあるからです。 terms の集計は、各シャードが上位の候補を返して合わせる仕組みで、doc_count_error_upper_bound が除かれた値の最大の件数を示します。 この値が大きいときは、一覧に「件数は概数」と出します。

システムへ連携する

過去の案件のフォルダには書き込みません。 取り込みは読むだけで、記号に置き換えた後の写しを S3 に置きます。 元の質疑書と回答書は、案件のフォルダにあるものが正です。

確認申請の図書にも書き込みません。 一覧は担当者が図書を確かめるための材料で、図書を直すのは担当者です。

人が確認する

1. 件数の多い条項から見る … 同じ申請先の件数と全体の件数を並べて見ます
2. 根拠の質疑書と回答書を開く … 当時の計画と今回の計画のどこが同じかを確かめます
3. 改正前の記録を分けて見る … regime が改正前の指摘は、改正後の審査の範囲で当てはまるかを考え直します
4. 当てはまるものを図書で確かめる … 直す点を決め、図書の確認の記録に書きます
5. 当てはまらなかったものを記録する … 一覧のどの項目を外したかと、理由を残します

3番目を省かないでください。 改正の後、都市計画区域などの内では、平家かつ延べ面積200㎡以下の建築物以外は、構造によらず構造規定などの審査が必要になりました。 改正前の木造の2階建ての住宅の記録には、構造の指摘がそもそも無いことがあります。指摘が無いことを、問題が無いことと読まないでください。

目標は、1件30分で一覧を見終えることです。 一覧の項目が15を超えるときは、件数の少ない条項を後回しにし、同じ申請先で2件以上ある条項から確かめます。

例外に対処する

1行目は、思ったより多く起きます。 用途・構造・規模・申請先を全部かけると、10年分でも当てはまる案件が数件になる計画があります。外す順を「規模 → 申請先 → 構造」と決めておき、用途は外しません。用途が違う指摘を並べても、担当者には使えないからです。

記録を残す

• 依頼のフォームの入力（計画の概要）と、生成AIが取り出した検索の手がかり
• OpenSearch に送ったクエリと集計のリクエスト、返ってきた結果
• 生成AIの入力と出力の全文
• 照合で捨てた項目と、件数を上書きした項目
• 担当者が当てはまると判断した項目と、外した項目と理由
• 実際の審査で受けた指摘（審査が終わった後に、今回の一覧と並べる）

最後の行が、この構成を育てる材料になります。 審査で受けた指摘が一覧に出ていたか、出ていなかったかを数えると、探し方の弱いところ（条項のそろえ方、辞書の不足、絞り込みの強さ）が分かります。

記録は、案件の保存の期間に合わせて残します。 後から「この指摘は事前に分かっていたか」を問われたとき、どの記録を見せ、担当者がどう判断したかを示せるようにします。