不動産

【2026年最新】不動産の重要事項説明書ドラフト・点検をClaude Codeで

宅地建物取引士が行う重要事項説明書の作成・点検業務をClaude Codeで支援する実装ガイド。物件データから各項目を自動ドラフト化し、宅建業法第35条の記載必須事項の充足チェック・漏れ検出まで一気通貫で行う手順を詳解。

【2026年最新】不動産の重要事項説明書ドラフト・点検をClaude Codeで


結論:重要事項説明書(重説)のドラフト生成・記載漏れチェック・旧版との差分確認は、Claude Codeをローカル環境で使えば宅建士の業務負担を大幅に軽減できる。ただし最終責任・口頭説明は必ず宅建士(人間)が行う必要がある。

  • 要点1:物件データ(登記・調査・ハザード情報)を構造化JSONで渡すことで、第35条の各項目ドラフトを一括生成できる
  • 要点2:「必須項目の充足チェック」をプログラマティックに自動化すると、記載漏れや矛盾箇所を人間よりも素早く検出できる
  • 要点3:個人情報・物件情報を外部APIに送信しない設計(ローカルClaude Codeまたはオンプレ環境)が法的リスク管理の大前提

対象読者:不動産会社の宅地建物取引士・情シス・不動産DX担当、不動産テックエンジニア

今日やること:物件データJSONの構造定義(本記事Step 1)を自社のシステムに合わせて実装してみる

「重説、またミスがあったらどうしよう……」

不動産会社の宅建士として、あるいはDX担当として、こんな不安を抱えながら書類を確認した経験はないでしょうか。重要事項説明書(以下「重説」)は宅地建物取引業法第35条に基づく法定書類で、記載漏れや誤記は取引の無効・損害賠償・業務停止処分につながりかねない。それだけに、正直なところ「ダブルチェックを何回やっても怖い」という声を、不動産会社へのAI導入支援の現場でよく聞きます。

私自身、複数の不動産テック案件に関わる中で気づいたのは、「重説の作業負担の大半は情報収集・転記・チェックであって、宅建士の専門判断は全体の3割程度にすぎない」ということでした。逆に言えば、残り7割はClaude Codeで支援できる余地があります。

本記事では、物件データの構造化から第35条必須事項の充足チェック、ハザード・法令制限の記載漏れ検査、旧版との差分ハイライトまで、宅建士チームが実際に使える実装パターンをコード付きで解説します。

重要な前提: 本記事はClaude Codeを「ドラフト生成支援・チェック補助」として使う手法を紹介しています。重説の最終確認・記名・口頭説明は宅地建物取引士が直接行う法的義務(宅建業法第35条)があります。本ツールはあくまで補助手段であり、宅建士の判断・責任を代替するものではありません。


1. なぜ今、重説×Claude Codeなのか

宅建業法第35条では、重説に記載すべき事項が明確に列挙されています(登記記録、都市計画法・建築基準法の制限、ハザードマップ、契約解除条件など)。これらは「法定チェックリスト」であり、機械的な確認に適しています。

一方で実務では次のような問題が頻発します:

  • 登記情報・現況調査・ハザード情報が複数の異なるシステム・書類に分散している
  • 各システムからデータをコピー&ペーストする際の転記ミス
  • 過去物件の書類を流用した際に前の物件情報が残るリスク
  • 法令改正(例:水害ハザード情報の追記義務、2020年8月施行)後のフォーマット対応漏れ

Claude Codeをローカル環境で動かすと、これらの「構造的にミスが起きやすい作業」をプログラムで補助できます。

事例区分: 想定シナリオ
以下は100社以上のAI導入支援経験をもとに構成した典型的なシナリオです。特定の実在企業のデータではありません。

中堅不動産会社(宅建士5名・年間取引300件規模)の想定では、1件の重説作成に平均2〜3時間かかっていたところ、Claude Code支援の導入後には「情報収集・転記・初稿確認」フェーズで約40〜50%の時間短縮が見込めます(試算値。実際の効果は物件種別・業務フロー・システム連携状況により異なります)。

不動産業のDXツール選定全般については、不動産仲介業務の自動化で提案速度を3倍にした実装事例も参考にしてください。


2. 実装の全体像:4つの柱

重説×Claude Code支援は以下の4ステップで構成します:

  1. 物件データの構造化:各システムから収集した情報を統一スキーマのJSONに変換
  2. ドラフト生成:JSONを渡してClaude Codeが第35条各項目のドラフトテキストを出力
  3. 必須項目充足チェック:第35条列挙事項の記載有無・矛盾を自動検出
  4. 差分ハイライト:旧版との変更箇所を視覚化して宅建士が最終確認
重要事項説明書×Claude Code 実装フロー図:物件データJSON化→Claude Codeドラフト生成→第35条必須項目チェック→差分ハイライト→宅建士最終確認の5ステップ
重説×Claude Code の実装フロー。ドラフト生成・チェックはClaude Codeが担い、最終責任・口頭説明は宅建士が行う分業設計。

3. Step 1:物件データを構造化JSONに変換する

「どんな情報をClaude Codeに渡すか」の設計が最重要です。まず物件データのスキーマを定義します。

3-1. 物件データスキーマの定義

# property_schema.py
# 重説ドラフト生成用 物件データスキーマ

from dataclasses import dataclass, field
from typing import Optional, List

@dataclass
class RegisterInfo:
    """登記情報"""
    land_area: float          # 土地面積(㎡)
    building_area: float      # 建物面積(㎡)
    ownership_type: str       # 所有権形態(所有権/借地権等)
    encumbrances: List[str]   # 担保・仮差押等のリスト
    address: str              # 所在地

@dataclass
class ZoningInfo:
    """都市計画・用途地域情報"""
    zoning: str               # 用途地域
    building_coverage_ratio: float  # 建蔽率(%)
    floor_area_ratio: float         # 容積率(%)
    fire_prevention_area: Optional[str]  # 防火地域等
    city_planning_restrictions: List[str]  # その他都計制限リスト

@dataclass
class HazardInfo:
    """ハザード・地盤情報(2020年8月改正後の追記義務対応)"""
    flood_risk: str           # 洪水リスク区分(要説明事項)
    landslide_risk: str       # 土砂災害リスク区分
    storm_surge_risk: str     # 高潮リスク区分
    tsunami_risk: str         # 津波リスク区分(条例指定地域の場合)
    soil_contamination: Optional[str]  # 土壌汚染調査結果

@dataclass
class PropertyData:
    """重説ドラフト生成用 物件データ統合スキーマ"""
    case_id: str              # 案件ID(個人情報は含めない)
    property_type: str        # 物件種別(売買/賃貸/土地/建物)
    register: RegisterInfo
    zoning: ZoningInfo
    hazard: HazardInfo
    management_fee: Optional[float]   # 管理費(マンション等)
    repair_reserve: Optional[float]   # 修繕積立金
    asbestos_survey: Optional[str]    # アスベスト調査結果
    earthquake_resistance: Optional[str]  # 耐震診断結果
    remarks: List[str] = field(default_factory=list)  # 特記事項

3-2. データの収集と変換

# data_collector.py
# 各システムからデータを収集してPropertyDataに変換する

import json
from pathlib import Path

def build_property_data_from_sources(
    registry_data: dict,      # 登記情報APIまたはPDF抽出結果
    survey_data: dict,        # 現況調査結果
    hazard_api_data: dict,    # ハザード情報API(国土交通省等)
    case_id: str
) -> dict:
    """
    各ソースデータを統合して重説ドラフト用JSONに変換する。
    ※ 顧客個人情報(氏名・住所・電話番号)は含めないこと
    """
    return {
        "case_id": case_id,
        "property_type": registry_data.get("property_type"),
        "register": {
            "land_area": registry_data.get("land_area"),
            "building_area": registry_data.get("building_area"),
            "ownership_type": registry_data.get("ownership_type"),
            "encumbrances": registry_data.get("encumbrances", []),
            "address": registry_data.get("address")
        },
        "zoning": {
            "zoning": survey_data.get("zoning"),
            "building_coverage_ratio": survey_data.get("bcr"),
            "floor_area_ratio": survey_data.get("far"),
            "fire_prevention_area": survey_data.get("fire_prevention"),
            "city_planning_restrictions": survey_data.get("cp_restrictions", [])
        },
        "hazard": {
            "flood_risk": hazard_api_data.get("flood"),
            "landslide_risk": hazard_api_data.get("landslide"),
            "storm_surge_risk": hazard_api_data.get("storm_surge"),
            "tsunami_risk": hazard_api_data.get("tsunami", "対象外"),
            "soil_contamination": survey_data.get("soil_contamination")
        },
        "management_fee": survey_data.get("management_fee"),
        "repair_reserve": survey_data.get("repair_reserve"),
        "asbestos_survey": survey_data.get("asbestos"),
        "earthquake_resistance": survey_data.get("earthquake_resistance"),
        "remarks": survey_data.get("remarks", [])
    }

# 使用例
if __name__ == "__main__":
    # 各ソースからデータを収集(実装は各システムに依存)
    property_json = build_property_data_from_sources(
        registry_data={"property_type": "売買・マンション", ...},
        survey_data={...},
        hazard_api_data={...},
        case_id="CASE-2026-001"  # 個人を特定できないIDのみ
    )

    Path("/tmp/property_case_001.json").write_text(
        json.dumps(property_json, ensure_ascii=False, indent=2)
    )

セキュリティ設計の重要点: このJSONには買主・売主の氏名・住所・電話番号などの個人情報を含めないでください。案件IDで紐付け、個人情報は別システムで管理する設計にします。Claude Codeはローカル環境で動かすことで外部サーバーへの送信を防止できます(Claude Code公式ページでのローカル実行に関する記載も参照してください)。


4. Step 2:第35条ドラフトテキストを生成する

4-1. システムプロンプトの設計

# draft_generator.py
# 重説ドラフト生成プロンプト

SYSTEM_PROMPT = """
あなたは宅地建物取引業の実務に精通したAIアシスタントです。
提供された物件データを元に、宅地建物取引業法第35条に基づく
重要事項説明書の各項目ドラフトを作成します。

【重要な制約】
1. 提供されたデータに含まれている情報のみを使用する
2. 不明な情報や不足している情報は「要確認: [項目名]」と明示する
3. 法的な判断(例:本物件は特定の制限に該当するか否か)は行わず、
   「宅建士による確認が必要」と記載する
4. 「仮定した点は必ず"仮定"と明記してください」
5. 数字・固有名詞は提供データの値のみを使用し、推測で補完しない

出力形式: 各項目を見出し付きで、Markdownテキストとして出力する
"""

USER_PROMPT_TEMPLATE = """
以下の物件データを元に、重要事項説明書の各項目ドラフトを作成してください。

物件データ:
{property_json}

作成する項目:
1. 物件の表示(登記事項)
2. 都市計画法・建築基準法による制限
3. 私道の負担
4. 飲用水・電気・ガスの供給施設
5. 管理費・修繕積立金(マンションの場合)
6. 造成宅地防災区域・土砂災害警戒区域の指定状況
7. 水防法に基づく水害ハザードマップの対象区域
8. 石綿(アスベスト)使用調査の結果の記録の存否
9. 耐震診断の内容
10. 契約の解除

各項目に「要確認」事項がある場合は必ず明示してください。
不足している情報があれば、最初に質問リストを出してから作業を開始してください。
"""

4-2. Claude Code APIを呼び出してドラフトを生成

import anthropic
import json

def generate_draft(property_data: dict) -> str:
    """
    物件データからClaude Codeで重説ドラフトを生成する。
    ローカルMac上で実行。外部サーバーへの物件情報送信に注意。
    """
    client = anthropic.Anthropic()  # ANTHROPIC_API_KEY環境変数から読み込み

    property_json_str = json.dumps(property_data, ensure_ascii=False, indent=2)

    message = client.messages.create(
        model="claude-opus-4-5",  # 2026年5月時点。最新モデルはanthropicの公式を確認
        max_tokens=4000,
        system=SYSTEM_PROMPT,
        messages=[
            {
                "role": "user",
                "content": USER_PROMPT_TEMPLATE.format(property_json=property_json_str)
            }
        ]
    )

    return message.content[0].text

# 使用例
if __name__ == "__main__":
    import pathlib

    property_data = json.loads(
        pathlib.Path("/tmp/property_case_001.json").read_text()
    )

    draft_text = generate_draft(property_data)
    pathlib.Path("/tmp/draft_case_001.md").write_text(draft_text, encoding="utf-8")
    print("ドラフト生成完了:", len(draft_text), "文字")

このコードはAnthropic公式SDK(Python)を使用しています。実際の運用では、物件情報の外部送信に関して所属組織のセキュリティポリシーに従ってください。


5. Step 3:第35条の必須項目充足チェック

ドラフト生成後、宅建業法第35条の記載必須事項がすべて充足されているかを自動チェックします。

5-1. チェックリスト定義

# compliance_checker.py
# 宅建業法第35条 必須記載事項チェッカー
# 参考: 国土交通省「重要事項説明書の書き方」
# https://laws.e-gov.go.jp/law/327AC1000000176

REQUIRED_ITEMS_35 = {
    # 物件に関する事項
    "property_display": {
        "label": "物件の表示",
        "required_keywords": ["登記", "所在", "地番", "地目", "地積", "構造", "床面積"],
        "severity": "critical"
    },
    "registered_rights": {
        "label": "登記記録に記録された事項",
        "required_keywords": ["所有権", "担保"],
        "severity": "critical"
    },
    "city_planning": {
        "label": "都市計画法・建築基準法による制限",
        "required_keywords": ["用途地域", "建蔽率", "容積率"],
        "severity": "critical"
    },
    "private_road": {
        "label": "私道の負担",
        "required_keywords": ["私道"],
        "severity": "critical"
    },
    "utilities": {
        "label": "飲用水・電気・ガスの供給施設",
        "required_keywords": ["水道", "電気", "ガス"],
        "severity": "critical"
    },
    "hazard_map": {
        "label": "水防法に基づく水害ハザードマップの指定状況",
        "required_keywords": ["洪水", "ハザード", "浸水", "高潮"],
        "severity": "critical"
    },
    "landslide": {
        "label": "土砂災害警戒区域の指定状況",
        "required_keywords": ["土砂災害", "地すべり", "急傾斜"],
        "severity": "critical"
    },
    "asbestos": {
        "label": "石綿使用調査の記録の存否",
        "required_keywords": ["アスベスト", "石綿"],
        "severity": "high"
    },
    "earthquake": {
        "label": "耐震診断の内容(昭和56年以前の建物)",
        "required_keywords": ["耐震", "診断"],
        "severity": "high"
    },
    "contract_cancellation": {
        "label": "契約解除に関する事項",
        "required_keywords": ["解除", "クーリング", "手付"],
        "severity": "critical"
    }
}

def check_compliance(draft_text: str) -> dict:
    """
    生成されたドラフトテキストが第35条必須項目を含んでいるか確認する。
    Returns: {item_id: {"label": str, "status": "ok"|"warning"|"missing", "reason": str}}
    """
    results = {}

    for item_id, config in REQUIRED_ITEMS_35.items():
        found_keywords = [
            kw for kw in config["required_keywords"]
            if kw in draft_text
        ]

        if len(found_keywords) == len(config["required_keywords"]):
            status = "ok"
            reason = f"全キーワード確認済み: {found_keywords}"
        elif len(found_keywords) > 0:
            status = "warning"
            reason = f"一部キーワード未確認: {set(config['required_keywords']) - set(found_keywords)}"
        else:
            status = "missing"
            reason = f"記載が見当たりません。要確認: {config['required_keywords']}"

        results[item_id] = {
            "label": config["label"],
            "status": status,
            "severity": config["severity"],
            "reason": reason
        }

    return results

def print_compliance_report(results: dict):
    """チェック結果をコンソールに出力"""
    print("\n=== 重要事項説明書 第35条 充足チェック結果 ===\n")

    critical_issues = []
    warnings = []

    for item_id, result in results.items():
        icon = {"ok": "✅", "warning": "⚠️", "missing": "❌"}[result["status"]]
        print(f"{icon} [{result['severity'].upper()}] {result['label']}")
        if result["status"] != "ok":
            print(f"   → {result['reason']}")
            if result["severity"] == "critical":
                critical_issues.append(result["label"])
            else:
                warnings.append(result["label"])

    print(f"\n--- サマリー ---")
    print(f"❌ 要対応(critical): {len(critical_issues)}件")
    print(f"⚠️ 要確認(high): {len(warnings)}件")

    if critical_issues:
        print("\n⚠️ 宅建士による確認が必要な重大項目:")
        for item in critical_issues:
            print(f"  - {item}")

6. Step 4:ハザード・法令制限の記載漏れを検査する

近年の法改正により、重説に追加すべき内容が増えています。特に2020年8月の「水害ハザードマップの説明義務化」(宅建業法施行規則の改正)は見落としがちです。

6-1. ハザード情報の自動クエリ(国土交通省APIの活用)

# hazard_api.py
# 国土交通省「ハザードマップポータルサイト」のデータを参照する例
# 実際のAPI利用はhttps://disaportal.gsi.go.jp/ の利用規約に従うこと

import requests

def query_hazard_info(latitude: float, longitude: float) -> dict:
    """
    緯度経度からハザード情報を取得する(概念実装)。
    実際の本番実装では国土地理院のAPIやハザードマップポータルサイトの
    データを利用する。利用条件は下記URLを参照のこと:
    https://disaportal.gsi.go.jp/

    Returns: ハザード情報の辞書
    """
    # 注意:以下は概念コードです。実際のAPIエンドポイントは
    # 国土地理院・各自治体のAPIドキュメントを参照してください。

    # 例:国土地理院のハザードマップ情報取得API(仮)
    # endpoint = f"https://api.gsi.go.jp/hazard?lat={latitude}&lon={longitude}"
    # response = requests.get(endpoint)
    # data = response.json()

    # 実装の骨子(各APIレスポンスに合わせて変換する)
    return {
        "flood": "要確認: 対象自治体のハザードマップで確認",
        "landslide": "要確認: 土砂災害ハザードマップで確認",
        "storm_surge": "要確認: 高潮ハザードマップで確認(沿岸部の場合)",
        "tsunami": "要確認: 津波ハザードマップで確認(沿岸部・条例指定地域)"
    }

def check_hazard_description_completeness(
    draft_text: str,
    hazard_info: dict
) -> list:
    """
    ドラフト内のハザード記述が物件のハザード情報と矛盾していないかチェック。
    Returns: 不整合・要確認事項のリスト
    """
    issues = []

    # 洪水リスクの記載確認
    if hazard_info.get("flood") and "要確認" not in hazard_info["flood"]:
        flood_level = hazard_info["flood"]
        if flood_level not in draft_text:
            issues.append(
                f"⚠️ 洪水リスク「{flood_level}」がドラフトに明記されていない可能性があります"
            )

    # 土砂災害の記載確認
    if "区域外" not in hazard_info.get("landslide", "") and "土砂" not in draft_text:
        issues.append("⚠️ 土砂災害警戒区域の記載を確認してください")

    return issues

7. Step 5:旧版との差分ハイライト

物件情報が更新された際、どの箇所が変わったかを宅建士が素早く確認できる仕組みを作ります。

# diff_highlighter.py
# 旧版との差分を検出してHTMLでハイライト表示する

import difflib
from pathlib import Path

def highlight_diff(old_text: str, new_text: str) -> str:
    """
    旧版・新版の重説テキストの差分をHTMLで出力する。
    追加箇所は緑、削除箇所は赤でハイライト。

    宅建士がdiff確認して最終チェックするためのビュー用途。
    """
    differ = difflib.HtmlDiff(wrapcolumn=80)
    diff_html = differ.make_file(
        old_text.splitlines(),
        new_text.splitlines(),
        fromdesc="旧版",
        todesc="新版(更新後)",
        context=True,
        numlines=3
    )
    return diff_html

def generate_change_summary(old_text: str, new_text: str) -> list:
    """
    変更点のサマリーリストを生成する(宅建士向け確認用)。
    """
    changes = []

    # 行単位での差分を取得
    diff = list(difflib.unified_diff(
        old_text.splitlines(),
        new_text.splitlines(),
        lineterm=""
    ))

    added_lines = [line[1:] for line in diff if line.startswith("+") and not line.startswith("+++")]
    removed_lines = [line[1:] for line in diff if line.startswith("-") and not line.startswith("---")]

    if added_lines:
        changes.append(f"追記・変更された行数: {len(added_lines)}")
    if removed_lines:
        changes.append(f"削除・変更された行数: {len(removed_lines)}")

    # 重要キーワードの変更を検出
    important_keywords = ["面積", "用途地域", "建蔽率", "容積率", "洪水", "担保", "管理費"]
    for kw in important_keywords:
        old_matches = [l for l in old_text.splitlines() if kw in l]
        new_matches = [l for l in new_text.splitlines() if kw in l]
        if old_matches != new_matches:
            changes.append(f"⚠️ 「{kw}」に関連する記述が変更されています → 宅建士による確認を推奨")

    return changes

# 使用例
if __name__ == "__main__":
    old_draft = Path("/tmp/draft_case_001_v1.md").read_text()
    new_draft = Path("/tmp/draft_case_001_v2.md").read_text()

    # 差分HTMLを生成
    diff_output = highlight_diff(old_draft, new_draft)
    Path("/tmp/diff_case_001.html").write_text(diff_output)

    # 変更サマリーを出力
    changes = generate_change_summary(old_draft, new_draft)
    for change in changes:
        print(change)

8. 失敗パターン:よくある実装ミスと回避策

実際の現場では、次のような実装ミスがよく見られます。

❌ 失敗1:個人情報をJSONに含めてAIへ送信してしまう

# ❌ NG: 個人情報込みのJSONをAPI送信
property_data = {
    "buyer_name": "田中太郎",   # 危険:個人情報をAIに送っている
    "buyer_address": "東京都〇〇区...",
    "phone": "090-XXXX-XXXX",
    ...
}
# ⭕ OK: 個人情報を除外し、案件IDのみで参照
property_data = {
    "case_id": "CASE-2026-001",  # 個人を特定しない内部IDのみ
    "property_type": "売買・マンション",
    "register": { ... },  # 物件情報のみ
    ...
}

理由: 個人情報保護法および各社のプライバシーポリシーに従い、個人情報は外部のAIサービスに送信しない設計にする。ローカルで動作するClaude Codeでも、ログや一時ファイルへの書き込みに注意が必要です。

❌ 失敗2:AIの生成物を宅建士が確認せずに直接使用する

# ❌ NG: 宅建士の確認なしに自動で書類として使う
def auto_finalize_and_send(case_id: str):
    draft = generate_draft(...)
    send_to_client(draft)  # 危険:宅建士の確認なし
# ⭕ OK: 必ず宅建士の承認ステップを挟む
def prepare_for_review(case_id: str):
    draft = generate_draft(...)
    compliance_result = check_compliance(draft)

    # 宅建士の確認ポータルに「要確認」ステータスで保存
    save_as_pending_review(case_id, draft, compliance_result)
    notify_licensed_agent(case_id)  # 宅建士に通知
    # → 宅建士が確認・修正・承認してから次へ

理由: 宅地建物取引業法第35条は宅建士が重説を行う義務を定めています。AIが生成したドラフトは「素材」に過ぎず、法定の責任は宅建士にあります。実装段階でこの承認フローを省略しないことが最重要です。

❌ 失敗3:チェックリストの法令バージョンが古い

宅建業法施行規則は改正されます。たとえば2020年8月に「水害リスク情報の説明義務」が追加されました(国土交通省 土地・建設産業局)。チェックリストを一度実装したら終わりではなく、法改正の都度アップデートする運用フローを組み込む必要があります。

# ⭕ OK: チェックリストのバージョン管理
CHECKLIST_VERSION = "2026-05"  # 最終更新日を記録
CHECKLIST_REFERENCE = "https://laws.e-gov.go.jp/law/327AC1000000176"

# 定期的なチェック(例: 四半期に1回)
# 国土交通省の告示・施行規則改正を確認して REQUIRED_ITEMS_35 を更新する

❌ 失敗4:ハザード情報APIの座標精度に依存しすぎる

国土地理院APIやハザードマップポータルサイトは公的な情報源ですが、座標精度や更新タイミングによって実際のリスク評価と乖離する場合があります。APIの結果は参考情報として使い、最終的には対象自治体のハザードマップ(PDF)を宅建士が直接確認する手順を省略しないでください。


9. セキュリティ・コンプライアンス設計

不動産取引における情報管理は特に慎重さが求められます。

9-1. ローカル実行環境の構築

物件情報・顧客情報が含まれる可能性がある処理は、可能な限りローカル環境で完結させます:

  • Claude CodeをローカルMacまたはオンプレ環境で実行(Claude Code公式参照)
  • 物件データJSONの一時ファイルは処理完了後に削除
  • ログファイルに物件情報が残らないよう設計(case_idのみをログに出力)
  • APIキーの環境変数管理(.envファイルをGitにコミットしない)

9-2. アクセス制御とロール設計

# access_control.py
# シンプルなロールベースアクセス制御の例

from enum import Enum

class UserRole(Enum):
    LICENSED_AGENT = "licensed_agent"   # 宅建士:全操作可能
    DX_STAFF = "dx_staff"               # 情シス:設定・保守のみ
    SALES_STAFF = "sales_staff"         # 営業:ドラフト閲覧のみ

ROLE_PERMISSIONS = {
    UserRole.LICENSED_AGENT: ["generate_draft", "check_compliance", "approve", "finalize"],
    UserRole.DX_STAFF: ["configure", "view_logs", "update_checklist"],
    UserRole.SALES_STAFF: ["view_draft"]  # 最終承認権限なし
}

def check_permission(user_role: UserRole, action: str) -> bool:
    """ロールベースでアクションの可否を判断"""
    allowed = ROLE_PERMISSIONS.get(user_role, [])
    return action in allowed

賃貸・売買の管理業務全般のClaude Code活用については、賃貸入居者管理をClaude Codeで自動化した実装事例も参考になります。


10. 段階的な導入ロードマップ

一度に全機能を導入しようとすると失敗しやすいです。3つのフェーズで段階的に進める方法を推奨します。

Phase 1(1〜2ヶ月):チェック機能から始める

ドラフト生成は後回しにして、まず「既存の重説テキストを読み込んで記載漏れを検出する」機能だけを実装します。現行フローを変えずにAIをQAツールとして導入できるため、宅建士チームからの抵抗が少ないです。

  • 実装内容:compliance_checker.pyのみ
  • 入力:既存の重説Word/PDFをテキスト抽出して渡す
  • 評価軸:ミス検出率(「人間が見逃したが機械が検出した件数」)

Phase 2(2〜4ヶ月):ドラフト生成の部分適用

標準的な物件種別(例:区分マンション売買)に絞ってドラフト生成を導入します。全物件種別への適用は避け、まず最も件数が多い種別で精度を検証します。

  • 実装内容:draft_generator.py + data_collector.py
  • 評価軸:宅建士の修正コメント数(ドラフト品質の指標)

Phase 3(4〜8ヶ月):差分管理・ハザードAPI連携

物件情報更新時の差分ハイライトや、ハザード情報APIとの連携を実装します。また、チェックリストの自動アップデートフローも整備します。

  • 実装内容:diff_highlighter.py + hazard_api.py
  • 評価軸:宅建士の確認所要時間、ヒューマンエラー発生率

11. よくある質問(FAQ)

Q. Claude Codeが生成した重説ドラフトに法的効力はありますか?
ありません。重要事項説明書は宅地建物取引業法第35条に基づく法定書類であり、宅地建物取引士が内容を確認・署名し、口頭で説明する法的義務があります。Claude Codeが生成するのはあくまでドラフト(素案)であり、最終的な法的責任は宅建士にあります。
Q. 顧客(買主・売主)の個人情報をClaude Codeに渡しても大丈夫ですか?
推奨しません。物件データのみを渡し、氏名・住所・電話番号などの個人情報は除外した設計にしてください。Claude Codeをローカル環境で実行することで外部送信を防ぐことができますが、個人情報の取り扱いは個人情報保護法および所属組織のプライバシーポリシーに従ってください。
Q. 宅建業法の改正があった場合、チェックリストはどう更新すればよいですか?
国土交通省の公式サイトで宅建業法施行規則の改正情報を定期的に確認し、REQUIRED_ITEMS_35の辞書を手動で更新する運用を推奨します。年1〜2回の法令確認フローをカレンダーに登録しておくとよいでしょう。
Q. ハザード情報の取得に使える公式APIはありますか?
国土地理院の「地理院地図API」や国土交通省のハザードマップポータルサイトのデータを参照できます。利用条件は各サービスの利用規約を確認してください。API結果は参考情報とし、対象自治体のPDF版ハザードマップも宅建士が最終確認することを推奨します。
Q. このシステムを導入するのに、どの程度の技術力が必要ですか?
Pythonの基礎知識があれば実装できます。本記事のコードを動かすには、Python 3.10以上・anthropic SDKのインストール・Anthropic APIキーの取得が必要です。社内で専任エンジニアが不在の場合は、外部エンジニアやAI導入支援会社への相談も検討してください。

12. まとめ:今日から始める3つのアクション

重要事項説明書×Claude Codeの実装、整理するとこうなります:

  • Claude Codeの役割は「補助ツール」: ドラフト生成・記載漏れチェック・差分ハイライトはClaude Codeが担い、最終責任・口頭説明は宅建士(人間)が行う分業設計が前提
  • 個人情報の設計が最重要: 物件データJSONに個人情報を含めない設計にする。ローカル実行で外部送信をゼロにする
  • 法令チェックリストは生き物: 宅建業法施行規則は改正される。チェックリストのバージョン管理と定期更新フローを最初から組み込む

今日やること

  1. 今日:property_schema.pyのデータ構造を自社のシステムに合わせて定義してみる(物件データのJSONスキーマ設計から着手)
  2. 今週中:compliance_checker.pyで既存の重説テキストを1件だけテストしてみる(ドラフト生成より先にチェック機能から試す)
  3. 今月中:Phase 1(チェック機能のみ)を宅建士チームと一緒に検証し、現行フローとの統合方法を合意する

参考・出典


著者プロフィール

佐藤傑(さとう・すぐる)
株式会社Uravation代表取締役。早稲田大学法学部在学中に生成AIの可能性に魅了され、X(旧Twitter)で活用法を発信(@SuguruKun_ai、フォロワー約10万人)。100社以上の企業向けAI研修・導入支援を展開。著書『AIエージェント仕事術』(SBクリエイティブ)。SoftBank IT連載7回執筆。

ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。


Next Step

この事例を、自社の業務に置き換える。

対象業務、利用データ、評価基準、社内展開の順番まで整理すると、Claude Code導入の失敗を減らせます。

導入を相談する