設計図書の概要から、建築基準法と条例で確かめる項目の一覧をClaudeで作り、確認申請の前の自主点検に使う

処理の起点を決める

設計概要シートの「点検の一覧を作る」に印が付いたことを起点にします。 基本設計が固まり、用途・規模・構造・敷地の条件がそろった時点です。それより前に動かすと、空欄だらけの概要から needs_info だらけの一覧ができ、誰も読まなくなります。

Google Apps Script のインストール型トリガーでシートの編集を受け、印の列が変わったときだけ処理します。同じ計画でもう一度印を付けたら、前回の一覧を残したまま新しい版を作ります。 実施設計で面積や階数が変わることは珍しくなく、変わる前と後で、どの項目が増えたかを比べられることに意味があります。

定時の一括実行にはしません。申請の日程は計画ごとにばらばらで、担当者が「概要がそろった」と判断したときが、点検を始めるときです。

入力データを集める

質を決めるのは、確認項目マスタの「当てはまる条件」の列です。 ここが「該当する場合」のように曖昧だと、Claude は自分の知識で条件を補います。「用途に共同住宅を含む」「階数が3以上」「準防火地域」のように、概要シートの欄の値で書ける形にします。

条例リストは、市ごとに担当を決めて育てます。 一度調べた市の条例は、次の計画から探さなくて済みます。第3章の（c）が解消するのは、AIのおかげではなく、このリストのおかげです。

過去の指摘は、マスタを直す材料として持ちます。 判定の入力には入れません。指摘を入れると、Claude が「前に言われたから」という理由で項目を拾い、理由がマスタに残らないまま一覧が膨らみます。

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

概要シートと2つのリストは、Google Apps Script から読むだけです。敷地の条件は、担当者が自治体の都市計画情報で調べて書きます。 自動で取りに行く方法は市ごとに違い、提供していない市もあるため、この構成では取りに行きません。

マスタは毎回まるごと渡し、プロンプトキャッシュを使います。 確認項目マスタは計画が変わっても同じ内容なので、指示とマスタを前に置き、計画の概要を後ろに置きます。公式の説明では、キャッシュの既定の有効期間は5分で、読まれるたびに更新され、"ttl": "1h" で1時間にもできます。tools → system → messages の順で、前の段が変わると後ろはすべて作り直しになります。 マスタを system の側に置き、計画ごとに変わるものは messages に置く並びにします。

市の条例リストは、その市の分だけを渡します。 全市分を渡すと、別の市の条例を拾う誤りが起きます。

AIへ渡す前に整形する

1. 必須欄の確認 … 用途、延べ面積、階数、高さ、構造、所在の市、用途地域、防火の指定、前面道路の幅員。空欄が1つでもあれば Claude を呼ばずに担当者へ返します
2. 単位と表記の統一 … 面積は㎡、高さはm、幅員はmにそろえます。「約」「程度」の付いた値は担当者へ返します
3. 区分の判定 … 構造・階数・延べ面積から新2号・新3号などの区分を出します。この判定はプログラムで行い、結果を値として Claude に渡します
4. 数値の境目の判定 … マスタにある「延べ面積300㎡超」「高さ16m以下」のような境目を、概要の値と比べて真偽で出します
5. 複数の用途地域の確認 … 敷地が2つの用途地域にまたがるときは、両方を列に入れ、「またがる」という印を付けます
6. 施主の情報を外す … 施主の氏名、住所、敷地の地番は渡しません。所在は市の名前までにします
7. 前回の版の取得 … 同じ計画の前回の一覧があれば、差分を出すために読み込みます

3番目と4番目を軽く見ないでください。 「200㎡超」と「200㎡以上」の違い、「階数が2以上」と「2階建て」の違いは、AIに任せると、境目の計画で判定が揺れます。 境目の比較は、すべてプログラムで済ませてから渡します。

AIに処理させる

させるのは、確認項目マスタの1項目ずつについて、概要の値と区分の判定結果を条件に当て、3つのどれかを付けることです。

右端の列の「否定されている」が、この構成でいちばん大事な言葉です。 not_applicable は、値があってその値が条件を満たさないときだけです。値が無いときは needs_info です。 前者は確かめなくてよい項目、後者は確かめるかどうかがまだ分からない項目で、扱いがまったく違います。

4行目がいちばん起きやすい失敗です。 マスタの条件が短いと、Claude は自分の知っている法令の知識で条件を広げたり狭めたりします。広げるのは手間が増えるだけですが、狭めると拾い漏れになります。 条件に足りないところがあれば、判定を変えずに note に書かせ、マスタを直す材料にします。

指示内容を固定する

あなたは建築設計事務所で、確認申請の前に確かめる項目を選ぶ担当です。
法令に適合しているかは判断しません。この計画で確かめる必要があるかだけを判定します。

【判定のしかた】
確認項目マスタの各項目について、「当てはまる条件」を計画の概要に当て、
次の3つのどれかを applicability に入れてください。
- applies ........ 当てはまる条件のすべてが、概要の値で満たされている
- not_applicable . 当てはまる条件のどれかが、概要の値で否定されている
- needs_info ..... 条件の判定に要る値が概要に無い、または「未定」と書かれている
迷ったときに not_applicable を選ばないでください。

【厳守事項】
- 値が無いことを、条件を満たさないこととして扱わないでください。
  値が無ければ needs_info です。
- 当てはまる条件は、マスタに書かれたとおりに使ってください。
  ご自身の法令の知識で条件を広げたり、狭めたりしないでください。
  条件に疑問があれば、判定はそのままにして note に書いてください。
- マスタに無い項目を追加しないでください。
- 面積・高さ・階数などの境目の判定は、【区分と境目の判定結果】の値を使ってください。
  自分で数値を比べ直さないでください。
- reason には、判定の根拠にした概要の欄の名前と値を書いてください。
- check_where には、マスタの「見る図面」の欄をそのまま写してください。
- 用途が複数あるときは、どの用途の部分にかかる項目かを applies_to_use に書いてください。
- 条例リストの項目も、同じ規則で判定してください。
- 法令に適合している・していないという表現を使わないでください。

【計画の概要】{plan_summary}
【区分と境目の判定結果】{computed_flags}
【この市の条例リスト】{local_rules}

確認項目マスタは、この指示の前に system として置き、キャッシュの対象にします。

「値が無いことを、条件を満たさないこととして扱わない」を明記しないと not_applicable になります。 準防火地域の欄が空の計画で、何も言わなければ「準防火地域ではない」と読みます。拾い漏れの多くは、この読み方から生まれます。

「自分で数値を比べ直さない」と書くのも同じ理由です。 境目の判定結果を渡していても、概要に面積があると Claude は自分で比べ、結果が食い違ったときにどちらを使ったか分からなくなります。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "plan_id": "",
  "master_version": "",
  "building_class": "",
  "items": [
    {
      "item_id": "",
      "source": "master | local_rule",
      "applicability": "applies | not_applicable | needs_info",
      "reason": "",
      "applies_to_use": "",
      "check_where": "",
      "missing_inputs": [],
      "note": ""
    }
  ],
  "missing_fields_summary": []
}

building_class には、前処理でプログラムが出した区分をそのまま入れます。Claude には書き換えさせません。

1つ目の理由は、applicability を3つに固定できることです。 自由文で「おそらく不要」「念のため確認」と書かれると、一覧で並べ替えも集計もできません。3つに固定すれば、not_applicable だけを抜き出して管理建築士に回せます。

2つ目は、reason を後段で照合できることです。 Google Apps Script が reason に書かれた欄の名前と値を取り出し、概要シートに本当にその値があるかを確かめます。 概要に無い値を根拠にした判定は、needs_info に戻して担当者に回します。

3つ目は、版を比べられることです。 master_version と items が同じ形で残るので、実施設計で面積が変わったときに、前回と今回で applicability が変わった項目だけを抜き出せます。

システムへ連携する

点検の一覧には、担当者と管理建築士の確認欄を付けます。 担当者は applies の項目に「図面で確かめた」と、どの図面の何ページかを書きます。管理建築士は not_applicable の項目に「外してよい」か「確かめる」を付けます。

概要シートとマスタには書き込みません。 マスタの直しが要りそうな項目は、note を集めた一覧として別に出し、直すかどうかは管理建築士が決めます。 AIの指摘でマスタが勝手に変わると、どの版で点検したかが分からなくなります。

人が確認する

人が見るのは、3つの判定のそれぞれで、別の観点です。

1. needs_info を先に埋める … 担当者が足りない値を概要シートに書き、もう一度印を付けます。ここが残っている一覧は、点検に入りません
2. applies を図面で確かめる … 担当者が図面と計算書で確かめ、確認欄に書きます。ここは従来の点検と同じ作業です
3. not_applicable の理由を確かめる … 管理建築士が理由を読み、外してよいかを決めます。1項目あたり数秒で読めるよう、理由は欄の名前と値だけにしてあります
4. 判定を覆したら記録する … どの項目を、どちらに変えたか、なぜかを残します

3番目を省かないでください。 拾い漏れが起きるのは、ここだけです。applies の誤りは担当者が図面を見ると気づきますが、not_applicable の誤りは誰も図面を見ないので、気づく機会がありません。

目標は、管理建築士の確認を1件10分程度にすることです。 以前は一覧と図面の両方を見ていましたが、この構成では外した項目の理由を読むことに絞れます。 図面を見るのは、理由に疑問があった項目だけです。

例外に対処する

3行目と4行目の扱いが、この構成の限界を決めています。 増築や既存不適格の計画は、既存部分の状態という概要に書けない条件で項目が変わります。無理に判定させるより、対象外として最初から人に回すほうが安全です。

5行目は、運用を始めた直後に多く出ます。 条例リストは市ごとに育てるものなので、最初の数か月は「未整備」の市が多くあります。 未整備と書かれた一覧を受け取った担当者が、その市の条例を調べてリストに足す、という流れにします。

記録を残す

• 計画ごとの点検の一覧（版ごと）と、作ったときの概要シートの値
• Claude に渡した入力の全文と、返ってきたJSONの全文
• そのとき使った確認項目マスタと条例リストの版
• 照合で needs_info に戻した項目と、その理由
• 人が判定を覆した記録 … どの項目を、どちらに変えたか、なぜか
• 審査機関から受けた指摘と、その項目の点検時の判定

3つ目で版を残すのは、マスタが改正のたびに変わるからです。 同じ計画でも、マスタの版が違えば一覧が変わります。どの版で点検したかが残っていないと、指摘を受けたときに「マスタの抜け」か「判定の誤り」かを切り分けられません。

最後の行が、マスタを育てる材料になります。 審査機関から指摘を受けた項目が、点検時に not_applicable だったなら判定かマスタの誤り、一覧に無かったならマスタの抜けです。 月に一度この突き合わせをして、マスタの条件を直します。