建築設計事務所の図面チェックをClaude Codeで効率化

設計事務所のチェック業務を Claude Code に渡してみた

正直に言うと、最初は半信半疑だった。建築設計の現場、特に確認申請前の図面チェックは「経験」「目」「現場勘」の塊で、AI に渡しても本判定はできない。建築基準法・関係法令・条例・関連告示の組み合わせは膨大で、判例的な行政運用すら絡む。本判定は有資格者がやるしかない。これは前提として動かない。

ただ、ある時に主任技術者の知人と話していて気付いた。「本判定は人がやる。でも、人がやる前の前さばきで毎回1〜2週間溶けている」と。具体的には、平面図と仕様書で建具表の品番が一致しているか、断面リストと矩計図の階高がそろっているか、構造図と意匠図の通り芯がずれていないか、設計コメントが最新版に追いついているか、過去案件の指摘事項が再発していないか。「これ全部、本判定じゃないんですよ。整合チェックなんです。でも、整合がズレてると本判定の確認申請で全部止まる」と。

この「前さばき」の領域、つまり テキストとして読み取れる部分の整合チェック を Claude Code に任せると、確認申請前の自主レビューが体感で半分以下になった、と教えてもらった事務所がある。CAD そのものを触らせない。PDF と仕様書と社内ナレッジだけを横断させる。ターミナルから「この図面PDFと仕様書PDFを並べて、品番と寸法の不整合を全部リストアップして」と投げるだけで、設計者が後で目視するための「疑い項目リスト」が出てくる。最終判断は人間がやる。けど、見落としは確実に減る。

この記事では、その運用を「実装手順としてどう組むか」という視点で書く。CAD連携前提の論点、設計者・主任技術者・確認申請担当のそれぞれの作業フローのどこに差し込めるか、社内ナレッジ蓄積の作法までを整理した。

想定シナリオ:4つの差し込みポイント

「Claude Code を図面チェックに使う」と言っても、業務全体に等しく刺さるわけではない。設計事務所の業務フローを分解すると、Claude Code が向くフェーズと向かないフェーズがはっきり分かれる。ここでは差し込みポイントを 4 つに整理する。

シナリオ1:意匠設計者の社内チェック前の自主レビュー

意匠設計者が SD(基本設計)後半〜DD(実施設計)中盤で社内チェックに出す前、自分の図面パッケージの整合を自分で確認する場面。ここが一番 Claude Code の費用対効果が高い。

具体的には、平面図・断面図・立面図・矩計図・建具表・仕上表・特記仕様書を PDF で並べて、「品番」「寸法」「階高」「通り芯」「室名」「面積」の不整合を横断的に拾わせる。これは人間がやると2〜3日溶ける作業で、しかも疲れてくると見落とす。Claude Code は疲れない。並列で横断する。社内チェックに出す前の自主レビューとして組み込むと、社内チェック担当者の負荷も減る。

想定する設計者の動き:

• PDF出力を社内サーバの一時フォルダに集約
• ターミナルから Claude Code に「整合チェックして」と投げる
• 戻ってくる「疑い項目リスト」を Excel に貼って、自分で1項目ずつ判定
• 本当の不整合は CAD で修正、Claude Code の誤検知は無視

シナリオ2:主任技術者の確認申請前自主レビュー

確認申請を出す直前、主任技術者が最終的に図面パッケージ全体を見渡す場面。ここでは法適合の本判定は当然人間がやるが、「前回の指摘事項が反映されているか」「過去の類似案件で同じ指摘を受けていないか」「社内チェックリストの全項目が形式上カバーされているか」といった振り返り型のチェックに Claude Code が刺さる。

例えば、過去 3 年分の確認申請で受けた指摘事項を社内で蓄積していれば、それを丸ごと Claude Code のコンテキストに渡して「この新規案件で類似の指摘ポイントがないか確認して」と投げられる。これは過去ナレッジへのアクセスを再現するもので、ベテラン主任技術者の頭の中にしかなかった「気をつけるポイント」を、若手主任技術者の前さばきとして提供できるようになる。

シナリオ3:確認申請担当の書類整合チェック

確認申請担当者が、図面パッケージ・計算書・仕様書・申請書類の整合を見る場面。ここはほぼ純粋にテキストの突合作業で、Claude Code が最も得意とする領域。

申請書に書かれた「建築面積」「延べ面積」「軒高」「階高」「構造種別」「用途」が、図面・計算書・仕様書のそれぞれで一致しているか。一文字違いの数字や、四捨五入の桁ずれが書類間で混ざっていないか。確認申請担当者が紙とExcelで突合していたのを、Claude Code に PDF を渡して横断テキスト抽出させると、突合作業そのものは数分で終わる。残るのは「Claude が拾った差分が本当に差分なのか」という人間の判定だけになる。

シナリオ4:社内ナレッジへの蓄積と検索

これは単発のチェックではなく、事務所の中長期的な資産形成の話。過去の確認申請指摘事項・社内チェックでの発見・行政との事前協議メモ・条例ごとの留意点を、社内に文章で蓄積し、Claude Code から横断検索できる状態にしておく。

ベテランが「あの案件のときの行政指摘、たしか軒高の取り方で…」と思い出す瞬間を、若手が Claude Code に「軒高の取り方で過去に受けた指摘はある?」と聞ける状態にする。これは図面チェックそのものではないが、結果としてチェックの質を底上げする。社内 wiki に書きためた内容を Claude Code のコンテキストに渡すだけでいい。

実装手順:CAD の外側で動かす

ここから具体的な実装手順に入る。最初に強調しておくと、Claude Code に CAD バイナリ(dwg/dxf のネイティブ形式)を直接触らせない。CAD データの解釈は CAD ベンダーのアプリの責任範囲で、汎用 LLM がやる仕事ではない。

Claude Code が触るのは テキスト面 だけ。具体的には:

• 図面 PDF からテキスト抽出したもの(寸法・室名・特記事項のテキスト部分)
• 仕様書(Word / PDF / Markdown)
• 建具表・仕上表(Excel / CSV)
• 社内ナレッジ(Markdown / Confluence エクスポート / 過去議事録)
• 確認申請書(Excel / PDF)

図面の形そのものは人間が CAD で見る。Claude Code は「図面の中に書かれている文字情報」と「周辺資料の文字情報」を突合する役割に徹する。これが安全に動かす境界線だ。

環境構築の最小セット

導入する事務所の規模・予算・セキュリティ要件にもよるが、最小構成は次の通り。

• Claude Code 本体:Anthropic 公式のターミナル版を各設計者の PC にインストール
• PDF テキスト抽出ツール:標準的な OSS で十分(pdfminer / pdftotext など)
• 社内ナレッジの置き場:社内サーバの共有フォルダか、社内 Git リポジトリ。最初は共有フォルダで十分
• Claude Code から触らせるファイルの範囲:案件フォルダ配下のみに絞る。事務所全体のファイルにアクセスさせない

権限設計が一番の論点になる。設計事務所のファイルサーバは案件ごとに機密度が違うし、施主との NDA がある案件もある。Claude Code がローカル PC で動くこと、共有フォルダのうち閲覧権限がある部分しか触れないこと、を IT 管理者と合意してから導入する。

運用フロー:意匠設計者の場合

意匠設計者がシナリオ1の自主レビューに使う場合の手順。

1. 案件フォルダ内に review/ サブフォルダを作る
2. レビュー対象の図面 PDF・仕様書 PDF・建具表 Excel を review/ に集約
3. ターミナルで案件フォルダに移動して Claude Code を起動
4. プロンプト(後述)を投げる
5. 戻ってきた「疑い項目」を確認 → CAD で修正 or 無視
6. レビュー後、review/ はそのまま残して履歴として保存

注意点として、PDF テキスト抽出はレイアウト依存で揺れる。表組みのセル順が壊れたり、寸法線の数字が行末で分断されたりする。これは Claude Code の責任ではなく PDF 抽出ツールの責任 で、設計者がプロンプト側でカバーする必要がある。「数字が分断されている場合は、近接する単位記号と合わせて解釈してください」のような指示をプロンプトに入れる。

運用フロー:確認申請担当の場合

確認申請担当(シナリオ3)の場合は、最後のクロスチェックとして使う。

1. 申請書 Excel・図面 PDF・計算書 PDF・仕様書 PDF を application_check/ に集約
2. 「主要数値の突合」プロンプト(後述)を投げる
3. 建築面積・延べ面積・軒高・最高高さ・階高・構造種別・用途・防火地域指定について、各書類間の差分を出力
4. 差分が出た項目を、申請書原本・計算書原本に当たって人間が判定
5. 確定したら主任技術者の最終チェックへ

ここで重要なのは、Claude Code が「差分あり」と言った項目を そのまま信じない こと。PDF 抽出の揺れで「3,000」が「3000」と読まれただけで「差分」になるケースが頻発する。人間が原本に当たって最終確定するという運用を崩さない。

コピペで使えるプロンプト5本

実際に設計事務所で使えるプロンプトを5本紹介する。事務所の業務フローや図面の書式に合わせて調整して使ってほしい。初回は必ず1案件分のテストデータで試してから本運用に入ること。

プロンプト1:平面図と建具表の品番突合

あなたは建築設計事務所の図面チェック補助です。
以下の制約のもとで、平面図PDFと建具表Excelの品番不整合を抽出してください。

【入力】
- 平面図PDFから抽出したテキスト(寸法・室名・建具記号を含む)
- 建具表Excel(建具記号・品番・寸法・仕様)

【出力フォーマット】
| 建具記号 | 平面図側の記載 | 建具表側の記載 | 不整合の種類 | 信頼度 |
|---------|--------------|--------------|------------|-------|
| AD-01   | (内容)        | (内容)        | (品番違い等) | 高/中/低 |

【ルール】
- 「不整合の種類」は「品番違い」「寸法違い」「平面図に記号があるが建具表にない」「建具表にあるが平面図に記号なし」のいずれかに分類
- PDF抽出の揺れ(全角半角・スペース・カンマの有無)は不整合扱いにしない
- 信頼度「高」は明確な品番/寸法の食い違い、「中」は記号の表記揺れ、「低」はPDF抽出に起因しそうなもの
- 最終的な判断は設計者がやるため、判定理由を1行で添える
- わからない場合は無理に判定せず「要確認」と書く

プロンプト2:階高と寸法の通し確認

あなたは建築設計事務所の図面チェック補助です。
矩計図・断面図・立面図の階高と主要寸法が通っているか確認してください。

【入力】
- 矩計図PDFから抽出したテキスト(階高・天井高・床高など)
- 断面図PDFから抽出したテキスト(同上)
- 立面図PDFから抽出したテキスト(階高・軒高・最高高さ)

【出力フォーマット】
1. 各図面ごとに、抽出できた寸法を表で整理
2. 階ごとに「矩計図 / 断面図 / 立面図」の3列で並べた比較表
3. 不一致がある行をハイライトし、想定される原因を1行で添える

【ルール】
- 寸法の単位は mm を基本とする。図面側の表記が「m」「FL」混在の場合はそのまま記載して、不一致判定の前に「単位揺れあり」と注記
- 階の表記揺れ(1F/1階/GL/FL)は同一階として扱う
- 軒高・最高高さの定義は図面側の表記をそのまま採用し、解釈を加えない
- わからない/抽出できなかった項目は空欄ではなく「(抽出不可)」と書く

プロンプト3:確認申請書類の主要数値突合

あなたは建築確認申請の書類整合チェック補助です。
確認申請書・図面パッケージ・構造計算書・仕様書のあいだで、主要数値の整合を取ってください。

【主要数値】
- 敷地面積
- 建築面積
- 延べ面積
- 各階床面積
- 階数(地上/地下)
- 軒高
- 最高高さ
- 構造種別
- 主要用途
- 防火地域指定

【出力フォーマット】
| 項目 | 確認申請書 | 図面 | 構造計算書 | 仕様書 | 一致 | 備考 |

【ルール】
- 一致/不一致は「○」「✕」「要確認」の3段階
- 「要確認」は、書類のどれかで未記載・抽出不可だった場合
- 単位の揺れ(m / mm / ㎡)は備考に書き、自動で換算しない(換算ミスを避けるため、人間が判断)
- 防火地域指定など文字情報の表記揺れ(「準防火地域」と「準防火」)は備考に書く
- 最終判断は確認申請担当・主任技術者が原本に当たって行う前提なので、断定的に「不適合」とは書かない

プロンプト4:過去案件指摘事項との照合

あなたは建築設計事務所のナレッジ補助です。
新規案件のチェックリストと、過去の確認申請指摘事項データベースを突き合わせ、
新規案件で再発しそうな指摘ポイントをピックアップしてください。

【入力】
- 新規案件の概要(用途・規模・構造・敷地条件・主要設計コンセプト)
- 社内ナレッジ:過去3年分の確認申請指摘事項リスト(用途・規模・指摘内容・対応方法)

【出力フォーマット】
1. 新規案件と類似性が高い過去案件Top5(類似理由を一行ずつ)
2. 過去案件で受けた指摘のうち、新規案件で再発する可能性が高いもの(理由付き)
3. 注意して確認すべきポイントのチェックリスト(箇条書き、5〜10項目)

【ルール】
- 「再発する可能性が高い」は、用途・規模・構造のどれかが類似する場合に限定
- 法令の解釈や行政運用に踏み込む断定はしない。「過去にこういう指摘があった」事実の提示にとどめる
- 主任技術者がこれを元に最終的に確認すべきリストを作る前提
- 案件固有の事情(行政庁の運用差)があるため、断定的な「適合/不適合」は書かない

プロンプト5:仕様書とコメントの整合チェック

あなたは建築設計の社内レビュー補助です。
特記仕様書・図面コメント・最新の設計変更メモのあいだで、矛盾や古い記述の残置を抽出してください。

【入力】
- 特記仕様書(最新版)
- 図面に付いているコメント(設計者注記)
- 設計変更メモ(日付付き)

【出力フォーマット】
| 該当箇所 | 特記仕様書の記載 | 図面コメントの記載 | 設計変更メモ | 矛盾の種類 | 推奨アクション |

【ルール】
- 「矛盾の種類」は「古い記述の残置」「仕様変更が片側に反映されていない」「相互に矛盾」のいずれか
- 設計変更メモの日付が最新の場合、それを基準とする(ただし最終判断は設計者)
- 「推奨アクション」は「仕様書を変更メモに合わせて更新」「図面コメントを最新化」「両方確認のうえ判断」のような形で書く
- 仕様の正解を断定せず、あくまで「整合が取れていない箇所の列挙」にとどめる

CAD連携前提で押さえるべき論点

「CAD と Claude Code を連携させたい」という要望は当然出てくる。ここで論点を整理しておく。

論点1:CAD バイナリは触らない

前述のとおり、dwg / rvt / ifc などの CAD ネイティブバイナリは Claude Code から触らない。これは技術的にできないという話ではなく、業務上の責任分界点を曖昧にしないため。CAD データの解釈は CAD ベンダーの責任、Claude Code が触るのはテキスト面のみ、という線を引いておく。

もし CAD のデータを使いたい場合は、CAD 側でテキスト面(寸法リスト・部材リスト・属性データ)を CSV や DXF テキスト形式でエクスポートして、それを Claude Code に渡す。これなら CAD 側のエクスポート機能の挙動を信用すればよく、Claude Code が CAD バイナリを誤読するリスクを切り離せる。

論点2:BIM とのデータ橋渡し

BIM(Revit / Archicad など)を使っている事務所では、モデルから属性情報をテキスト出力して Claude Code に渡せる。例えば部屋面積一覧・建具リスト・部材リストを CSV にエクスポートし、仕様書 PDF と突合させる、といった使い方ができる。

ただし、BIM のモデル品質に依存するため、「BIM が信用できる事務所」と「BIM が現場では使われていない事務所」で運用が大きく違う。BIM が運用されていない事務所では、まず PDF / Excel / 仕様書だけで運用を回し、BIM 化が進んでから連携を考えるのが現実的だ。

論点3:座標・図形情報の限界

Claude Code はテキスト推論モデルなので、図形の幾何学的な整合(平面と立面で柱位置が一致しているか、構造図と意匠図で梁の通り芯がそろっているか)は 図形そのものとしては判定できない。座標値・通り芯記号・寸法のテキスト面で「数値として通っているか」までは見られるが、「図形として描けているか」は CAD で人間が見るしかない。

この境界を理解せずに「全部 Claude Code でチェックできる」と期待すると、現場でハマる。Claude Code は テキスト整合のチェッカー であって 図形チェッカーではない、と最初から線を引く。

論点4:確認申請の最終責任

これは技術論点というより法的・倫理的論点。確認申請の最終責任は建築士・主任技術者にある。Claude Code がいくら整合チェックをやっても、その出力をそのまま申請書に転記してはいけない。必ず人間が原本に当たって最終確定する。これは事務所の運用ルールとして明文化する。

「Claude Code が大丈夫と言ったから提出した」という運用は絶対にしない。Claude Code は 人間の判定を補助する第二の目 であり、責任を負える立場にはない。

役割別の差し込み方をもう少し細かく

シナリオ1〜4を提示したが、現場で実際に運用するときは「誰が・どの時間に・どのフォルダで・どこまで判定するか」までセットで決めないと、便利ツールが「面倒な追加作業」に化ける。役割ごとに落とし込む。

意匠設計者の差し込み

意匠設計者は「自分の図面パッケージを社内チェックに出す前」に Claude Code を回す。これは深夜の追加作業ではなく、自主レビューの一部として標準工程に組み込む。図面 PDF をエクスポートしたあと、5〜10分で結果が返ってくる程度の量(平面・建具表・仕様書のテキスト面)に絞る。設計の手戻りが出やすいタイミングは「DD 後半の整合チェック」と「実施設計直前の最終確認」の2回で、ここに Claude Code を使うと費用対効果が高い。逆に SD 序盤やコンセプト検討では Claude Code はあまり役立たない。設計案の確定度が低いと「不整合」が出るのが当たり前なので、ノイズに埋もれる。

主任技術者の差し込み

主任技術者は「全図面の整合を俯瞰する立場」「過去案件の指摘事項を踏まえて若手を指導する立場」の二刀流。Claude Code は前者の俯瞰整合と、後者のナレッジ参照で使い分ける。具体的には、社内チェック後の図面パッケージを Claude Code に渡して「過去類似案件で指摘されやすい論点が見落とされていないか」を最後にチェックする。ここはベテラン主任技術者の暗黙知に依存していた部分で、Claude Code に過去ナレッジを渡せば、暗黙知の一部が形式知化される。若手主任技術者が同じ視点でレビューできる足場になる。

確認申請担当の差し込み

確認申請担当はテキスト突合作業がほぼすべてなので、Claude Code との相性は最も良い。ただし、書類間の差分が「PDF 抽出の揺れ」か「本当に違う数字」かは人間が原本に当たって判定する。確認申請担当が「Claude Code の出力 → 原本確認 → 差分確定 → 主任技術者に申告」というフローを徹底すると、見落としは大きく減る。逆に「Claude Code が一致と言ったから一致」で済ませると、文字化けの一致を見逃して、後で行政から戻される。

CAD オペレーターの差し込み

CAD オペレーターは Claude Code の直接ユーザーではないことが多いが、「Claude Code に渡すための PDF を、抽出しやすい形式でエクスポートする」という重要な役割を担う。図面の文字情報(寸法・室名・建具記号・特記事項)をテキストレイヤーで埋め込んだ PDF をエクスポートするか、ラスタライズして OCR が必要な PDF をエクスポートするか、で Claude Code の精度が大きく変わる。社内で「Claude Code 用 PDF エクスポート設定」を1つ決めて全員が使うと、運用が安定する。

効果指標:何をどう測るか

導入後の効果を測るのは、設計事務所にとっては難しい。図面チェックは「成果物が単一の数字に落ちる業務」ではないからだ。それでも、最低限こういう指標は取れる。

定量指標

• 自主レビューにかかる時間:Claude Code 導入前と導入後で、設計者が自主レビューに使う時間を1案件あたりで比較。最低でも 1〜2 案件ぶんは記録を取る
• 社内チェックで発見される不整合の件数:導入前/後で、社内チェック担当者が拾う不整合件数を記録。理想は「件数が増える(=自主レビューの精度が上がり、より細かい指摘になる)」ではなく「件数が減る(=自主レビューでつぶせている)」
• 確認申請の差し戻し回数:長期で見る指標。導入前後で確認申請の差し戻し回数の傾向を見る。ただしこれは案件の難易度や行政庁の運用差にも影響されるため、短期では判定しない
• 確認申請担当の書類突合工数:申請書・図面・計算書の数値突合にかかる時間。ここは比較的測りやすい

定性指標

• 主任技術者の心理的負荷:確認申請前の自主レビューで「見落としていないか」という心理的負荷が減ったかどうか。これは設計者・主任技術者へのヒアリングで定性的に拾う
• 若手の学習効果:若手設計者が Claude Code の出力を見ることで、「ベテランが何をチェックしているか」を学べているか。これは1on1や OJT のなかで拾う
• ナレッジ蓄積の進み具合:過去の指摘事項・社内チェック発見・行政との事前協議メモが、Claude Code から検索できる形で蓄積されているか

測り方の注意

「Claude Code 導入で工数が30%減った」のような断定的な数字を最初から目標にすると、現場が数字合わせに走ってしまう。むしろ「自主レビューの質を上げて、社内チェック担当の見落としを減らす」「ベテランの暗黙知を若手がアクセスできる状態にする」といった質の改善を最初の3〜6ヶ月のゴールにして、定量数字は後追いで取る、が現実的だ。

定量指標を出す場合も「導入前 vs 導入後」の比較だけでなく、「導入後の Claude Code 出力のうち、設計者が採用した割合(=真陽性率)」と「Claude Code が出した指摘のうち、誤検知として無視された割合(=偽陽性率)」を記録すると、運用の改善ポイントが見えてくる。

【要注意】よくある失敗パターン4つ

導入支援の現場で繰り返し見てきた失敗パターン。事前に潰してから運用に入ってほしい。

失敗1:Claude Code の出力を「最終判定」として扱ってしまう

❌ NG例:「Claude Code が “不整合なし” と言ったので、自主レビューはこれで終わり。社内チェックに出す」

⭕ OK例:「Claude Code が “不整合なし” と言ったが、PDF 抽出の揺れで見落としがあるかもしれないので、最低限の目視チェックは必ず通す」

Claude Code は「テキスト面で見える不整合の指摘」までしかできない。図形の整合、寸法線の引き方、納まりの妥当性は人間が見る。Claude Code の出力を「最終判定」として運用すると、PDF 抽出が崩れた瞬間に重大な見落としが起こる。必ず人間の目を残す。

失敗2:法令解釈を Claude Code に断定させてしまう

❌ NG例:「この建物の用途は集会場なので、特定の防火区画が必要、で合ってますか?」→ Claude Code に YES/NO を返させる

⭕ OK例:「過去の確認申請で集会場用途のとき、どんな指摘を受けたか教えてください」→ Claude Code には過去ナレッジへのアクセスだけ任せて、解釈は主任技術者がやる

建築基準法・関係法令・告示・条例・特定行政庁の運用は、Claude Code が網羅できる範囲を超える。法令解釈の本判定を Claude Code に求めるのは設計事務所の本来業務の放棄だし、なにより責任の所在が曖昧になる。Claude Code は 過去の事実の参照 までで止めて、解釈は人間がやる。

失敗3:CAD バイナリを直接 Claude Code に渡そうとする

❌ NG例:「dwg ファイルを Claude Code に渡して、図面の整合を全部見てもらおう」

⭕ OK例:「CAD から PDF を出力し、寸法リストを CSV でエクスポートしてから、Claude Code に渡す」

CAD バイナリは Claude Code から読めない。仮に読めたとしても、CAD ベンダーが意図したデータ構造を Claude Code が再現できる保証はない。CAD 側で意図したテキスト出力を経由するのが安全。これは技術的な話というより、責任分界点を明確にするための運用ルールだ。

失敗4:社内ナレッジを蓄積せずに使い続ける

❌ NG例:「Claude Code でチェックしている。社内ナレッジへの蓄積は後回しでいい」

⭕ OK例:「Claude Code でチェックした結果と、人間の判定結果(採用 or 無視 or 修正)をセットで保存し、月次で振り返って Claude Code の使い方を改善する」

Claude Code を入れただけで、社内ナレッジが自然に貯まることはない。「Claude が指摘した内容」「人間がそれをどう判定したか」「結果として正解だったか」をセットで残しておくと、半年後・1年後に運用品質を測り、プロンプトを改善できる。運用ログは資産になる。逆に取らなければ、何を学んだか・何が外れたかが残らず、組織として成長しない。

社内ナレッジ蓄積:中長期で効く投資

図面チェックそのものより、実は 社内ナレッジへの蓄積 のほうが事務所の中長期競争力を左右する。Claude Code を入れる本当の理由は、ベテランの暗黙知を組織の形式知に変える基盤を作ることにある。

蓄積すべき情報

• 過去の確認申請指摘事項:案件単位ではなく「用途×規模×指摘内容」で索引化
• 社内チェックで発見された不整合と修正履歴:発見者・修正者・所要時間付き
• 行政との事前協議メモ:特定行政庁の運用差を明文化(ただし機密扱い)
• 過去案件の納まり判断と理由:なぜその仕様にしたかの判断理由
• Claude Code の指摘ログ:採用 / 無視 / 修正の3分類で記録

蓄積の進め方

最初から完璧な体系を作ろうとすると失敗する。Markdown でフラットに書きためるのが現実的だ。1案件 = 1Markdown ファイル、項目は決め打ちでテンプレ化、社内サーバの共有フォルダで管理。これだけで Claude Code から横断検索できる状態になる。

3ヶ月運用したら、たまった Markdown を Claude Code に読ませて「どのカテゴリで指摘が多いか」を分析させる。そこで初めて「このカテゴリの指摘は社内チェックリストに反映しよう」「このパターンは Claude Code のプロンプトに事前に入れておこう」という改善が回り始める。

属人化の解消

「あのベテランしか知らない」という状態は、設計事務所の中長期リスク。ベテランが定年で抜けたり、転職したりすると、組織のチェック品質が一気に落ちる。Claude Code は ベテランの暗黙知を組織が共有できる形に変える媒介 として機能する。これは図面チェックの効率化以上に大きい価値を生む。

セキュリティと情報管理

設計事務所が扱う情報は、施主との NDA、住所・所有者情報、構造の詳細、施工単価など機密度が高い。Claude Code 導入時には次の項目を必ず IT 管理者と協議する。

協議すべき項目

• Claude Code の通信先と暗号化:Anthropic 公式のクライアントを使い、通信が TLS で暗号化されていることを確認
• 送信されるデータの範囲:プロンプトと添付ファイルとして送信される情報の機密度を整理
• ローカルキャッシュの扱い:Claude Code のローカル一時ファイルがどこに保存されるか、業務終了後に消すか
• 案件ごとのアクセス権限:Claude Code から触れるフォルダを、設計者の権限と一致させる
• NDA 対象案件の運用ルール:NDA 対象案件で Claude Code を使うかどうか、施主に開示するかどうかの社内ポリシー
• 監査ログ:いつ・誰が・どの案件で・どんなプロンプトを投げたか、最低限のログを社内サーバに残す

個人情報の取り扱い

図面パッケージの中には、施主の住所・氏名・連絡先が含まれることがある。Claude Code に渡す前に マスキング するか、そもそも個人情報を含まない部分だけ渡すか、運用を決めておく。「便利だから全部渡す」という運用は、施主との信頼関係を壊す。

導入の進め方:3ヶ月ロードマップ

10〜30名規模の設計事務所での標準的な導入ロードマップを示す。

1ヶ月目:小さく試す

• 意匠設計者1〜2名で、進行中案件のうち比較的シンプルなものを選んで試す
• プロンプト1(平面図と建具表の品番突合)だけ運用
• Claude Code の出力を CSV / Excel に貼って、設計者が1件ずつ判定
• 「真陽性率」「偽陽性率」「処理時間」を記録
• セキュリティ・権限・通信の項目を IT 管理者と協議し、社内ポリシーを決める

2ヶ月目:プロンプトを増やす

• 1ヶ月目の結果を踏まえてプロンプトを調整(誤検知が多かった項目を制約条件で潰す)
• プロンプト2〜3も運用に追加
• 確認申請担当も巻き込み、書類突合を試す
• 社内ナレッジの蓄積を開始(Markdown テンプレを決める)

3ヶ月目:全体に広げる

• 意匠設計者の大半が使う状態にする
• 主任技術者の自主レビューにも導入
• 過去案件指摘事項データベース(プロンプト4)の運用開始
• 3ヶ月の運用ログを Claude Code に読ませて分析、プロンプト・運用フローを再設計
• 定量指標(時間・回数)の初回まとめを出す

避けるべき進め方

「全社一斉導入」「いきなり大型案件に投入」「効果が見えないからすぐ撤退」のいずれもうまくいかない。小さく試し、ログを取り、運用を改善するサイクルが基本。3ヶ月で結果が見えなくても、社内ナレッジの蓄積が始まっていれば成功と考えていい。

業界特有の落とし穴をもう一段深く

失敗パターン4つに加え、建築設計事務所ならではの細かい落とし穴をいくつか共有する。導入支援で実際に遭遇したものをベースに整理した。

落とし穴1:PDF 抽出の文字化け対応

建築図面の PDF はラスタライズされているケースが少なくない。スキャンされた紙図面や、CAD から「印刷」フォーマットで出力された PDF だと、テキストレイヤーが入っていない。この場合 Claude Code は文字を読み取れないので、OCR を一段挟む必要がある。OCR の精度は和文の数字・記号で揺れるため、最初に「自社で使う CAD のエクスポート設定」を統一して、テキストレイヤー付き PDF が標準で出る状態を作る。これだけで Claude Code の精度が一段上がる。

落とし穴2:特記仕様書の構造の揺れ

特記仕様書は事務所ごと、案件ごとに章立て・項目順が違う。Claude Code に渡すときに「ルール:章番号が異なっていても同じ内容を扱う」と明示しないと、章番号違いを「内容違い」と誤検知する。特記仕様書のテンプレートを社内で標準化すると、運用が安定する。これは Claude Code 導入を口実に、社内仕様書テンプレの統一を進める良い機会でもある。

落とし穴3:寸法の単位ゆれ

建築図面は基本 mm 表記だが、高さや距離が m / mm 混在することがある。階段段数・敷地境界線・道路斜線の検討では m が出てきがちで、Claude Code が単位を勝手に換算して比較すると、四捨五入の桁ずれを「不一致」と誤検知する。プロンプトに「単位を勝手に換算せず、揺れがある場合は備考に書く」と明示しておくこと。これは前述のプロンプト2・プロンプト3にも組み込んである。

落とし穴4:行政庁の運用差

同じ建築基準法の条文でも、特定行政庁ごとに運用が違うケースがある(用途分類の解釈、軒高の取り方、防火設備の認定など)。Claude Code に法令解釈を求めないという原則は前述のとおりだが、「過去にこの行政庁で同じ用途の案件を扱ったときの指摘」を Claude Code に検索させるのは有効。社内ナレッジに「行政庁名 × 用途 × 指摘内容」のメタ情報を残しておくと、Claude Code の参照効率が高まる。

落とし穴5:設計変更の連鎖反映漏れ

意匠設計の変更が、構造設計・設備設計・仕様書・建具表のどこに反映漏れがあるか。これは設計事務所の永遠の課題で、Claude Code を入れたからといってゼロにはならない。ただ、Claude Code の出力履歴を残しておくと「変更前の整合状態」と「変更後の整合状態」を比較しやすくなる。長期では設計品質の改善ループになる。

落とし穴6:外注先との情報共有

構造設計・設備設計を外注している事務所では、外注先との情報共有のタイミングがチェックの精度に直結する。Claude Code を外注先には渡さず、自社内で整合チェックの結果だけを共有するか、Claude Code 自体を外注先にも導入してもらうか、運用設計を分けて考える。後者は契約・セキュリティ・コストの整理が必要で、最初は前者から始めるのが現実的だ。

落とし穴7:プロンプトの「育て方」を社内に残さない

導入初期は、設計者ごとに自分のプロンプトを書き換えて使う。これは悪いことではないが、各人が自己流で育てたプロンプトが共有されないと、組織としての学習が起きない。月次で「うまく動いたプロンプト」「誤検知が減ったルール追加」を社内 Markdown に集めて、Claude Code から横断検索できる状態にしておく。プロンプト自体が、社内ナレッジの一部になる。これを最初から組み込んでおくと、3年後にプロンプト資産が組織の競争力になる。設計事務所の差別化は、最終的にこういう地味な積み上げに帰着する。

他業界の Claude Code 活用事例も参考になる

建築設計と直接の業界は違うが、Claude Code を業務に組み込むパターンとして参考になる事例を紹介する。

• 建設業の日報作成業務を Claude Code で効率化 — 同じ建設業界の現場系業務。日報・施工写真・職人配置の整合チェックに Claude Code を使う実装。
• 不動産業の AI 査定業務を Claude Code で自動化する5ステップ — 物件情報と査定根拠のテキスト突合という意味で、書類整合チェックの考え方が近い。
• 製造業の品質検査レポート作成を Claude Code で自動化 — 検査記録と仕様書の整合チェックは、図面と仕様書の整合チェックとほぼ同じ構造。プロンプト設計の参考になる。

業界が違っても、「ベテランがやっていた前さばきを Claude Code に渡し、人間は本判定に集中する」という構造はほぼ共通している。建築設計事務所での Claude Code 運用も、根本構造はこれらの事例と同じだ。

次の一歩:何から始めるか

この記事をここまで読んだ意匠設計者・主任技術者・確認申請担当の方が、明日からできる最初の一歩を3つ示す。

アクション1:1案件分のテストデータを作る

過去の案件で完了したもの(つまり「正解」が分かっているもの)を1つ選び、図面PDF・仕様書PDF・建具表Excelをまとめておく。Claude Code に投げて、過去に社内チェックで指摘された内容が再現できるかを試す。再現できれば、現在進行中の案件に試す価値がある。

アクション2:プロンプトを社内ルールに合わせる

この記事のプロンプトはあくまで雛形。事務所ごとに、建具記号の命名規則・寸法表記のルール・特記仕様書の構成は違う。プロンプトの「ルール」セクションを自社の書式に書き換える。これだけで誤検知が大きく減る。

アクション3:社内ナレッジの Markdown テンプレを決める

過去案件の指摘事項を Markdown に書きためるテンプレを決め、空の Markdown ファイルを共有フォルダに1つ置く。完璧な体系を作ろうとせず、まず1案件ぶん書いてみる。これが社内ナレッジ蓄積の出発点になる。

主任技術者向け:ガバナンス側で先に決めること

主任技術者・経営層は、運用を始める前に次の3点を社内ルールとして明文化してほしい。

• Claude Code は予備チェック・整合チェックの補助であり、確認申請の最終責任は有資格者にある
• NDA 対象案件・施主開示要件のある案件での Claude Code 使用範囲
• 運用ログ・指摘ログ・社内ナレッジの保管期間とアクセス権限

このルールを先に決めておくと、現場の設計者は安心して試せる。逆にルールが曖昧なまま現場に投げると、設計者は責任を負いたくないので使わなくなる。

参考出典

• 国土交通省「建築確認手続等の運用改善について」 — 建築確認申請の手続き・運用に関する国の公式情報。本記事は法令解釈に踏み込まないが、確認申請業務の制度的位置づけを把握する一次資料として参照。
• 国土交通省「建築基準法等の改正情報」 — 建築基準法および関連法令の改正履歴。Claude Code は最新法令を網羅していないため、適用判断は必ず一次情報に当たる。
• Anthropic「Claude Code 公式」 — Claude Code 本体の仕様・対応ユースケース・セキュリティ情報。本記事の実装手順は Claude Code 公式の前提仕様に従う。
• 日本建築学会 — 建築設計の技術・運用に関するアカデミックリソース。社内ナレッジの体系化を進める際の参考。
• 建築技術教育普及センター — 建築士・主任技術者の資格制度に関する公式情報。Claude Code 運用ルールを「有資格者の責任範囲」で線引きする際の参照。

著者プロフィール

Claude Code 導入を本格検討するなら

次回予告:次の記事では、建設業の施工管理(工程表・工事日報・労務管理)に Claude Code を組み込む実装手順を扱う予定。設計と施工の両側で Claude Code を運用すると、現場と設計のあいだの情報受け渡しが大きく軽くなる事例を紹介する。

※本記事の内容は執筆時点(2026年5月)の情報に基づきます。建築基準法・関係法令・行政運用は随時改正・更新されます。実際の確認申請業務にあたっては、必ず最新の法令・告示・特定行政庁の運用と、有資格の建築士・主任技術者・確認検査機関の判断に従ってください。Claude Code は予備チェックの補助であり、最終的な法適合判断・確認申請書類の責任は有資格者にあります。

関連記事（自動）

• ▸ 【2026年最新】建設業の積算・見積書作成をClaude Codeで半自動化
• ▸ 建設現場の日報をClaude Codeで整理｜写真メモと安全確認の自動レポート