マンション管理会社のフロント担当から出る「この工事・この使い方は規約上できるか」の質問に、物件ごとの管理規約・使用細則・総会の決議を根拠にチャットで答える

処理の起点を決める

起点は、フロント担当が社内のチャット画面で物件を選び、質問を送ったことです。 画面は社内の ID でログインした管理事業部の社員だけが使い、区分所有者は使いません。 物件を選ばないと送信できない作りにします。

物件の選択は、自由入力にしません。 担当している組合の一覧から選ばせ、物件の番号を画面の側で確定させます。 質問の文に「○○レジデンス」と書かせて物件を推定させると、似た名前の物件を引く余地が残ります。

1件の問い合わせは、1つのセッションで続けます。 「張り替えるのは洋室2部屋だけ」と聞き足すと、同じセッションで答えを絞り直します。別の物件・別の問い合わせは、新しいセッションで始めます。 セッションをまたぐと、前の物件の文脈が残るからです。

入力データを集める

質を決めるのは、文書ごとのメタデータです。 文書ごとに、物件の番号、文書の種類（規約／細則／総会の決議／理事会の決議）、適用開始日、適用終了日、決議した会議の日付を付けます。物件の番号は文書を混ぜないために、適用期間は古い版を引かないために使います。

議事録は、決議の部分だけを取り込みます。 総会の議事録には、出席した区分所有者の名前や、滞納・漏水の個別の事情が書かれています。規約上の扱いを答えるのに、個人の事情は要りません。 決議の議案名と決議の内容だけを切り出して入れます。

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

文書は Cloud Storage に置き、メタデータの JSONL と一緒にデータストアへ取り込みます。 JSONL の1行に、文書の ID、structData のメタデータ、content の mimeType と Cloud Storage の uri を書きます。1回の取り込みで扱える非構造化の文書は100,000ファイルまで、1ファイルは200MBまでです。

絞り込みの式は、物件と日付で書きます。 項目を索引可能にしておけば、property_id: ANY("P0412") AND valid_from <= "2026-10-08" AND valid_to >= "2026-10-08" のように、その物件の、今日効いている版だけを引けます。改正の予定が無い文書には valid_to に 9999-12-31 を入れます。日付は ISO 8601 の文字列で比べられます。

物件の番号は、画面で選んだ値を中継プログラムが式に入れます。 モデルにもフロント担当にも書かせません。この1行が、物件を混ぜない仕組みのすべてです。

AIへ渡す前に整形する

1. 物件ごとに文書を集める … 規約、細則、議事録のPDFを、物件の番号の付いた場所に置きます
2. 改正後の全文を用意する … 新旧対照表しか無い改正は、業務課が改正後の全文を作ってから入れます
3. 版に期間を付ける … 古い版には、新しい版の適用開始日の前日を終了日として書きます
4. 議事録から決議を切り出す … 議案名・決議の内容・会議の日付だけを1件ずつの文書にします
5. 個人の名前を消す … 決議の文に部屋番号や名前が出るものは「当該住戸」に置き換えます
6. 見出しを断片に含める … データストアの作成時に分割を有効にし、includeAncestorHeadings を有効にします
7. 紙の綴りを取り込む … 紙しか無い古い細則は、スキャンして OCR の取り込み方式で入れます

2番目を省くと、答えが崩れます。 新旧対照表は、同じ条の旧い文と新しい文が左右に並ぶ表です。そのまま取り込むと、旧い文が根拠として引かれます。 改正後の全文を1本作り、新旧対照表は取り込みません。

6番目は、データストアを作る前に決めます。 分割はデータストアの作成後に有効にも無効にもできず、見出しを含める設定は既定では無効です。 「２ 前項の場合において、設計図、仕様書及び工程表を添付した申請書を…」の断片は、見出しが無いと何の申請の条か分かりません。 分割の大きさは100〜500トークンで、既定は500です。

AIに処理させる

させるのは、その物件の文書から質問に当たる条と決議を見つけ、規約上の扱いを4つの区分のどれかに当てはめ、必要な手続きと書類を根拠付きで並べることです。 承認するか、工事を始めてよいかは決めさせません。

標準管理規約の第17条は、この区分の手本になります。 専有部分の修繕・模様替え・建物に定着する物件の取付けや取替えで、共用部分や他の専有部分に影響を与えるおそれのあるものは、理事長に申請して承認を受け、申請には設計図・仕様書・工程表を添え、理事長は理事会の決議で承認・不承認を決めるとされています。承認の要らない工事でも、業者の立入りや資機材の搬入、騒音・振動・臭気について管理組合が事前に把握する必要があるものは、理事長に届け出るとされています。

answer メソッドの設定は次のようにします。

3行目がいちばん起きやすい失敗です。 規約に当たる条が無いと、モデルは「規約に定めがないため、自由に行えます」と書きます。定めが無いことは、許されているという意味ではありません。 区分所有法第6条は、建物の管理又は使用に関し区分所有者の共同の利益に反する行為をしてはならないとしています。定めが見つからないものは「定めが見つからない」と書いて止め、業務課へ回します。

指示内容を固定する

answer メソッドの preamble に、次の指示を入れます。

あなたはマンション管理会社のフロント担当を手伝う立場で、
選ばれた1つの物件の管理規約・使用細則・総会と理事会の決議から、
質問された工事や使い方の規約上の扱いを探します。
読むのはフロント担当です。区分所有者ではありません。

【答え方】
1. 規約上の扱いを、次の4つから1つ選んで最初に書いてください。
   「承認の申請が要る」「届出が要る」「禁止の定めがある」「定めが見つからない」
2. 根拠にした文書の種類（規約／細則／総会の決議／理事会の決議）、
   条の番号、決議の日付を書いてください。
3. 申請や届出が要る場合は、文書に書かれている添付書類と提出先を書いてください。
4. 数字の基準（遮音の等級、頭数、大きさ、期間）は、文書の文のまま写してください。

【厳守事項】
- 検索結果の文書に書かれていることだけで答えてください。
  他のマンションの規約や、一般的な規約の例で補わないでください。
- 「できます」「問題ありません」「許可されます」と書かないでください。
  承認するかどうかは理事会が決めます。
- 当たる条や決議が無いときは「定めが見つからない」とし、
  「自由に行える」「制限はない」と書かないでください。
- 規約と細則と決議で食い違うときは、どれが優先するかを決めず、
  食い違う箇所を並べて「業務課の確認が要る」と書いてください。
- 法律の条文の解釈や、規約が法律に合っているかの判断を書かないでください。
- 数字の基準を推定したり、書かれていない数字を補ったりしないでください。

「できます、と書かない」が、この指示の要です。 規約上は承認の申請が要る工事でも、承認の基準を満たしていそうに見えると、モデルは「承認されると考えられます」と書きます。フロント担当がそれを伝えれば、区分所有者には管理組合の約束に聞こえます。 書き方そのものを禁じ、区分と根拠で止めます。

検索の文は、中継プログラムが組み立てます。 例えば「質問：専有部分の洋室2部屋の床をカーペットからフローリングに張り替えたい。工事は11月中旬から。規約上の扱い、必要な書類、遮音の基準は何か」のように、場所と工事の種類を先に書きます。 区分所有者の名前と部屋番号は入れません。

出力形式を固定する

answer メソッドの応答を、中継プログラムが次の形に整えて、画面と記録に渡します。

{
  "query_id": "",
  "session_id": "",
  "staff_id": "",
  "property_id": "P0412",
  "asked_on": "2026-10-08",
  "question": "",
  "category": "approval_required | notice_required | prohibited | not_found",
  "requirements": [
    { "item": "", "detail": "", "basis": "" }
  ],
  "refs": [
    { "doc_type": "bylaw | rule | general_meeting | board", "article": "",
      "resolved_on": "", "valid_from": "", "valid_to": "", "uri": "",
      "grounding_score": 0 }
  ],
  "conflicts": [ { "summary": "", "refs": [""] } ],
  "status": "answered | routed | skipped",
  "staff_feedback": { "used": true, "corrected_category": "", "note": "" }
}

1つ目の理由は、category を決まった値で持てることです。 画面は区分ごとに色を変え、not_found と conflicts のあるものは区分所有者に返事をする前に業務課へ回すボタンだけを出します。区分の文言をモデルの自由な文から読み取らずに済みます。

2つ目は、refs の valid_from・valid_to を検査に使えることです。 根拠の文書の適用期間に今日が入っていなければ、その答えを画面に出さずに業務課の待ち行列へ回します。 絞り込みの式をすり抜けた古い版を、二重に止めます。

3つ目は、staff_feedback で誤りを集められることです。 フロント担当が区分を直した答えは、メタデータの付け間違いか、決議の切り出し漏れです。 業務課が毎月見て、文書の側を直します。

システムへ連携する

画面に出す物件は、ログインした担当者の担当物件だけにします。 他の担当の物件を選べないようにしておくと、担当外の物件の規約を参照した答えが返事に混ざることがありません。代わりに対応するときは、業務課が一時的に担当を足します。

問い合わせの記録の表と、区分所有者への返事の送信には、つなぎません。 返事を書いて送るのはフロント担当です。

人が確認する

フロント担当は、毎回、根拠の条項を開いて確かめてから返事を書きます。 画面の答えだけを写して返事にしない運用にします。

1. 区分と根拠の条を突き合わせる … 「承認の申請が要る」の根拠が、本当に申請と承認を定めた条かを読みます
2. 決議の日付を見る … 細則より新しい総会の決議が根拠に出ていれば、決議の文を優先して読む
3. 数字の基準を写す … 遮音の等級や頭数は、画面の文ではなく根拠の文書から写します
4. not_found と conflicts は回す … 業務課の担当が文書を確かめ、必要なら理事長に相談します

4番目を、フロント担当の判断で済ませないでください。 定めが見つからない工事は、理事会で基準を決めるきっかけになる質問です。業務課が月ごとにまとめ、理事会の議題の候補として組合に出します。

目標は、300件をならして1件6分です。 区分と根拠を確かめて返事を書くまでで、業務課へ回るものは1割前後という想定です。

例外に対処する

5行目は、この先1〜2年で増えます。 標準管理規約の改正のページは、規約の改正を決議する総会の招集の手続きを2026年3月31日までに行うか、4月1日以降に行うかで手続きの方法が変わるとしています。総会の定足数や決議の要件を問う質問は、規約の文だけでは答えられません。 この区分の質問は、最初から業務課へ回します。

記録を残す

• 質問の文、物件の番号、担当者、日時、セッションの ID
• 絞り込みの式と、answer メソッドの応答の全文（出典と根拠のスコアを含む）
• 整えた答え（category、requirements、refs、conflicts）
• そのとき参照した文書の版（文書の ID と valid_from・valid_to）
• フロント担当の評価と、区分を直した記録
• 業務課へ回した質問と、業務課の回答、理事会にかけた結果

4つ目で「そのときの版」を残すのは、規約が後から改正されるためです。 「去年の秋にこう案内された」という申し出が来たとき、当時効いていた版で答えたのかを確かめられます。

最後の行は、文書の側を育てる材料になります。 理事会が基準を決めたら、その決議を切り出して取り込み、同じ質問が次から not_found にならないようにします。