司法書士事務所で、登記の先例・通達・所内の過去の照会記録を質問で引き、申請書の記載や添付情報の扱いを根拠つきで確かめる

処理の起点を決める

起点は、補助者か司法書士が事務所の中の検索画面で質問を送ったことです。 画面は事務所の5名だけが使います。登記の種類、申請先の登記所、申請予定日を入れないと送信できない作りにします。登記の種類は「所有権移転（相続）」「所有権移転（売買）」「抵当権抹消」「役員変更」などの一覧から選びます。

質問の文には、依頼者の氏名・住所・地番・家屋番号を入れさせません。 「被相続人の登記上の住所と、住民票の除票の最後の住所が違い、間に転居が2回ある」のように、事情を抽象化して書くよう画面に例を出します。中継プログラムは、送信の前に地番らしい数字の並びや氏名らしい語を見つけたら、送信を止めて書き直しを求めます。

1つの事件の調べものは、同じセッションで聞き足します。別の事件は、新しいセッションで始めます。 前の事件の事情が、次の事件の答えに混ざらないようにするためです。

入力データを集める

質を決めるのは、先例の要約を1つの先例ごとに分けることです。 1つの大きなファイルのままでは、先例ごとの日付や扱いの変更の印を持てません。 先例ごとに1ファイルにし、先例の日付と番号を必ず書きます。

先例集や実務書の本文は、検索の対象に入れません。 入れるのは、事務所が作った要約と、先例の日付・番号・出典の書名と頁です。原文は司法書士が書籍で確かめます。 出版物の本文を丸ごと取り込むと、著作物の扱いの問題が生じうるためです。

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

資料は Cloud Storage に種類ごとのフォルダで置き、メタデータとあわせてデータストアへ取り込みます。 法令の抜粋は法令APIから、通達は法務省のサイトから取得し、改正や新しい通達があったときに足します。 先例の要約と照会記録は、登録や更新があった日の夜に取り込みます。

絞り込みの式は、登記の種類と申請予定日で書きます。 項目を索引可能にしておけば、registration_type: ANY("transfer_inheritance", "all") AND valid_from <= "2026-10-20" AND valid_to >= "2026-10-20" のように、相続の登記に関わり、10月20日に効いている根拠だけを引けます。日付は ISO 8601 の文字列で比べられます。

扱いが変わった先例は、絞り込みで除かずに残します。 valid_to を閉じた先例は申請予定日の絞り込みから外れますが、扱いの一部だけが変わった先例は、効いている期間のまま superseded を真にして残します。どこが変わったかを superseded_note に書き、 画面で目立たせます。完全に除くと、「昔はこうだった」という所長の記憶との照らし合わせができなくなります。

AIへ渡す前に整形する

1. 先例の要約を分ける … 1つの先例ごとに、日付と番号、出典の書名と頁、要旨、事務所での使い方を同じ見出しで書いたファイルにします
2. 扱いの変更を書き込む … 法務省の通達の一覧を見ながら、先例ごとに後の通達や改正で扱いが変わったかを司法書士が確かめ、superseded と superseded_note を付けます
3. 照会記録をそろえる … 照会した日、登記所、事件の事情の要約、照会の内容、回答を同じ見出しで書きます。依頼者の氏名や地番は消します
4. 古い照会記録を OCR の解析で読む … スキャンした PDF は、データストアの作成時に OCR の解析を選び、文字の入った PDF と混ざるものは useNativeText を有効にします
5. 法令は条ごとに分ける … 法令APIから取得した条文を、法令名と条の番号を見出しにして、条ごとのファイルにします
6. 見出しを断片に含める … データストアの作成時に分割を有効にし、includeAncestorHeadings を有効にします

2番目が、この構成でいちばん重い作業です。 所長の要約の数百件について、後の通達で扱いが変わっていないかを1件ずつ確かめます。最初から全部はできないので、使う回数の多い先例から確かめ、確かめていない先例には「未確認」の印を付けます。

6番目は、データストアを作る前に決めます。 分割はデータストアの作成後に有効にも無効にもできず、見出しを含める設定は既定では無効です。分割の大きさは100〜500トークンで、既定は500です。「この場合は、上申書で足りる」とだけ書かれた断片は、見出しが無いと、どの先例のどの事情の話か分かりません。

AIに処理させる

させるのは、質問の事情に当たりうる根拠を探し、根拠ごとに何が書かれているかを、種類と日付を添えて並べることです。 記載してよいかを言うこと、根拠どうしのどちらを採るかを決めること、登記所の判断を予測することはさせません。

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

4行目がいちばん起きやすい失敗です。 照会記録は事情が具体的で、質問の事情とよく似ていると根拠のスコアが高く出ます。モデルは「上申書で足ります」と一般の扱いのように書き、 通達や先例より前に出します。照会記録は必ず「〇〇法務局の、〇年〇月の照会での回答」と書かせます。

指示内容を固定する

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

あなたは司法書士事務所で、補助者と司法書士が登記の申請書を作る前の
調べものを手伝う立場です。検索結果に出た、法令・通達と準則・事務所の
先例の要約・照会記録・事務所の手引きだけを根拠に答えます。
読むのは補助者と司法書士です。

【答え方】
1. 根拠ごとに、種類（法令／通達・準則／先例／照会記録／手引き）、
   日付と番号、何が書かれているかを書いてください。
2. 種類の順は、法令、通達・準則、先例、照会記録、手引きの順にしてください。
3. 先例に「扱いの変更あり」と書かれている場合は、その旨と、
   何が変わったかの記載をそのまま書いてください。
4. 照会記録は、必ず「〇〇（登記所）の、〇年〇月の照会での回答」と書き、
   一般の扱いと分けてください。
5. 根拠どうしで扱いが違う場合は、どちらかを選ばず、両方を並べてください。

【厳守事項】
- 申請書に記載してよい、添付情報が足りる、といった結論を書かないでください。
- 登記所が受け付けるかどうかを予測しないでください。
- 照会記録の回答を、他の登記所や他の事情でも通る扱いとして書かないでください。
- 根拠に無い先例・通達を、一般的な知識で挙げないでください。
  先例の番号や日付を推測で書かないでください。
- 根拠が見つからない場合は「根拠が見つからない」と書き、
  登記所への照会の要否は書かないでください。

「先例の番号や日付を推測で書かない」を書くのは、もっともらしい番号ほど確かめにくいからです。 「昭和〇年〇月〇日民事甲第〇号」の形の番号を、モデルは根拠が無くても作れます。番号は引用された資料のメタデータからだけ出すように、中継プログラムでも引用の無い番号を表に載せません。

「どちらかを選ばず、両方を並べる」は、格と日付で決めるのが司法書士の仕事だからです。 古い先例と新しい通達が並べば、たいていは通達が優先されますが、通達が先例のどこまでを変えたかは、読んで決めることです。

出力形式を固定する

answer メソッドの応答を、中継プログラムが根拠の表に並べ直し、画面と記録に渡します。

{
  "query_id": "",
  "session_id": "",
  "user_id": "",
  "registration_type": "transfer_inheritance",
  "registry_office": "",
  "planned_filing_date": "2026-10-20",
  "question": "",
  "answer_text": "",
  "evidence": [
    { "source_type": "statute | circular | precedent | inquiry | manual",
      "title": "", "issued_at": "", "ref_no": "",
      "superseded": false, "superseded_note": "",
      "registry_office": "", "same_office": true,
      "uri": "", "grounding_score": 0.0 }
  ],
  "unverified_precedents": [""],
  "status": "answered | no_source | conflict",
  "decision": { "by": "", "result": "", "note": "", "inquiry_needed": false }
}

1つ目の理由は、evidence を種類の順に並べられることです。 中継プログラムは source_type で並べ直し、法令と通達が先、照会記録が後に来るようにします。根拠のスコアの順に並べると、事情の似た照会記録が先頭に来ます。

2つ目は、superseded と same_office を印として持てることです。 扱いの変わった先例と、申請先と違う登記所の照会記録は、画面で色を変えて出します。印の値はメタデータから入れ、モデルの文からは取りません。

3つ目は、unverified_precedents で確かめの残りを示せることです。 扱いの変更をまだ確かめていない先例が根拠に入ったら、ここに並べます。司法書士は、その先例だけは後の通達を自分で確かめます。

decision は司法書士が埋めます。 どの根拠を採り、どう判断したか、登記所に照会するかを書き、次の調べもので同じ判断を引けるようにします。

システムへ連携する

事件の管理の仕組みには、つなぎません。 事件の資料には依頼者の情報が詰まっており、検索の仕組みに渡す理由がありません。 調べた結果は、補助者が根拠の表を見て事件の記録に書きます。

法令と通達の取り込みは、月に1回の定時と、新しい通達が出たときに行います。 法務省のページの更新を見て、新しい通達が出たら、関わる先例の扱いの変更を確かめるところまでを1つの作業にします。

人が確認する

人が確かめるのは、根拠の原文と、扱いの変更と、判断です。

1. 補助者が根拠の原文を開く … 法令と通達はリンク先で、先例は書籍の頁で、原文を確かめます
2. 扱いの変わった先例と未確認の先例を司法書士が読む … superseded と unverified_precedents のものは、後の通達を読んで扱いを確かめます
3. 申請先と違う登記所の照会記録は参考に留める … 必要なら、申請先の登記所に照会します
4. 司法書士が判断し、decision に書く … 記載と添付情報を決めます
5. 月に1回、判断の記録から10件を抜いて読む … 根拠の並びと判断が合っているかを見ます

2番目を省かないでください。 扱いの変わった先例を読まずに使うと、改正前の扱いで申請書を作ることになります。補正で済まなければ、却下です。

目標は、150件をならして1件8分です。 資料を探す時間を減らし、原文の確かめと司法書士の判断の時間を残す想定です。

例外に対処する

4行目と8行目が、この構成の要です。 扱いの変更の確かめは、通達が出るたびに発生する終わりの無い作業です。確かめていないことを隠さずに印で示すことで、確かめの残りが事務所の誰にでも見えるようにします。

記録を残す

• 質問の文、利用者の ID、登記の種類、登記所、申請予定日、日時、セッションの ID
• 絞り込みの式と、answer メソッドの応答の全文（出典と根拠のスコアを含む）
• 並べ直した根拠の表と、扱いの変更・登記所の印
• 司法書士の判断と、登記所への照会の有無と結果
• 先例の要約の扱いの変更の更新の履歴（誰が、いつ、どの通達を見て）
• 記録の閲覧の履歴

5つ目を残すのは、印そのものが判断の材料だからです。 誰がいつ確かめたかが残っていれば、後の補正や却下のときに、どの時点の確かめにもとづいたかを示せます。