他の自治体の条例・規則・要綱を集めた例規データから起案中の条例案に近い規定例を探し、条文の書きぶりと施行時期を比べる

処理の起点を決める

起案課から条文案が届き、担当者が検索の画面に貼ったときに動かします。 検索は審査の作業の中で行うもので、定時の一括処理にはしません。 担当者が種別と分野を選んで検索を押すと、AWS Lambda が条文案を受け取ります。

例規の写しの取り込みは、これとは別に動かします。担当者が新しく集めた例規をS3の取り込みフォルダに保存したことを起点に、条ごとの分割、ベクトルの作成、索引への登録を行います。月に1回、参考にする自治体の例規集で改正の有無を確かめ、改正されたものを取り直します。

入力データを集める

質を決めるのは、取得日と最終改正日です。 この2つが無ければ、比較表の条文がいつの時点のものかを示せません。取得日の古い例規は検索の結果に印を付けて出し、原典での確認を促します。

例規の写しは、担当者が参考にする例規を選んで保存します。 著作権法第13条は、憲法その他の法令や、地方公共団体の機関が発する告示・訓令・通達などを、権利の目的とならない著作物としています。一方で、例規集のサイトの解説や検索の仕組み、民間の事業者が作った編集物は別です。 サイトの利用条件を確かめ、機械的に一括で取得することはしません。

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

取り込みでは、例規の本文を条ごとに分けます。見出し（括弧書き）、条番号、項・号を1つの塊として持ち、附則は本則と分けて別の項目に置きます。

ベクトルは Amazon Titan Text Embeddings V2 で作ります。入力は最大8,192トークン・50,000文字で、出力は既定で1,024次元です。公式は、長い文書でも段落や節のような論理的な単位に分けることを勧めています。 条ごとに分けるのは、この勧めにも合います。日本語は多言語対応の言語の一覧に含まれています。

Sudachi の辞書には、法令用語を足します。 「管理不全空家等」「特定空家等」のような複合語が分割されると、言葉の一致の検索で当たり方が崩れます。辞書を差し替えても、すぐにはドメインに反映されません。 次の構成変更の時点か、新しいパッケージで索引を作り直して入れ替えるかのどちらかで、公式は索引の別名を使って切り替える方法を示しています。

AIへ渡す前に整形する

1. 条文案を条ごとに分ける … 「第○条」の行で区切り、見出しと項・号を1つの塊にします
2. 定義規定を別に扱う … 「この条例において、次の各号に掲げる用語の意義は」で始まる条は、定義語の一覧として取り出します
3. 自分の市に固有の言葉を外す … 市の名前、課の名前、市の計画の名前は、検索の言葉から外します
4. 例規の写しの取得日を確かめる … 取得から1年を超えたものには stale の印を付けます
5. 廃止された例規を外す … 写しを取り直したときに廃止と分かったものは、索引から外さずに repealed の印を付けます
6. 附則を分ける … 公布日と施行期日の書き方（「公布の日から施行する」「○年○月○日から施行する」「規則で定める日」）を取り出しやすいよう、附則を本則から分けて保持します

5番目で索引から消さないのには理由があります。 他の市が廃止した規定は、「なぜやめたのか」を調べる手がかりになります。 比較表では、廃止されたことが分かるように出します。

AIに処理させる

させるのは、条文案の1条と、検索で見つかった他の自治体の条を、決まった観点ごとに比べて違いを書き出すことだけです。

比べた結果には、根拠にした原文を必ず写させます。 比較表を読む担当者は、AIのまとめではなく、写された原文で違いを確かめます。 写した原文が本当に検索結果の本文にあるかは、プログラムで文字列を突き合わせて確かめます。

4行目がいちばん起きやすい失敗です。 検索の結果が3自治体しか無いときでも、AIは「他の多くの自治体でも同様の規定が見られます」と書き足しがちです。検索結果に無い例は、無いと書かせます。 見つからないこと自体が、その書きぶりが少ないという情報です。

指示内容を固定する

あなたは市の法制課の職員として、条例案の1条と、他の自治体の例規の条を比べます。
渡された【条文案】と【検索結果】だけを見て比べてください。推測で埋めないでください。

【比べる観点】
1. scope ............ 対象の範囲（誰・何が対象か）
2. obligation ....... 義務の強さ（しなければならない／努めなければならない／ものとする）
3. sanction ......... 罰則・過料・氏名の公表の有無と、その前の手続（勧告・命令）
4. delegation ....... 細目の委任先（規則で定める、市長が別に定める など）
5. effective_clause . 附則の施行期日の書き方

【厳守事項】
- 検索結果ごとに、観点ごとの違いを書いてください。
- 各観点の quote には、根拠にした原文を一字一句そのまま写してください。
  言い換え・要約・句読点の変更をしないでください。
- 原文に書かれていない観点は "not_stated"、罰則や委任が無ければ "none" としてください。
- どの書きぶりを採るべきか、どれが望ましいかを書かないでください。
- 条例案が法令に適合するかを書かないでください。
- 公布から施行までの期間を計算しないでください。附則の文言を写すだけにしてください。
- 検索結果に無い自治体について書かないでください。
  「多くの自治体では」「一般的には」のような表現を使わないでください。
- 検索結果に stale または repealed の印があれば、note にそのことを書いてください。

【条文案】{draft_article}
【検索結果】{search_results}

「言い換えをしない」と「句読点を変えない」を分けて書いているのには理由があります。 言い換えだけを禁じると、読点の位置や「及び」「並びに」を整えて写します。法令の文では、その違いが意味の違いです。 写しの正しさは、プログラムが文字列の一致で確かめます。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力（output_config.format に type: "json_schema" とスキーマを指定）を使い、形の崩れた応答を比較表に流さないようにします。

{
  "draft_article_no": "第5条",
  "comparisons": [
    {
      "municipality": "",
      "reiki_title": "",
      "article_no": "",
      "flags": ["stale", "repealed"],
      "scope": { "summary": "", "quote": "" },
      "obligation": { "value": "must | effort | shall | not_stated", "quote": "" },
      "sanction": { "value": "penalty | fine | publication | none", "procedure": "", "quote": "" },
      "delegation": { "value": "", "quote": "" },
      "effective_clause": { "quote": "" },
      "note": ""
    }
  ]
}

1つ目の理由は、観点がそろった表にできることです。 obligation を must・effort・shall の3つに分けておけば、「義務とした市」「努力義務とした市」を数えて並べられます。 担当者の手で表を作り直す必要がありません。

2つ目は、quote を検証できることです。 プログラムが quote を検索結果の本文と突き合わせ、一致しないものは比較表に出す前に赤の印を付けます。

施行時期の比較は、プログラムが次の形で付け足します。

システムへ連携する

文書管理の仕組みへは自動で書き込みません。 比較表は審査の途中の資料で、担当者が原典を確かめて選んだものだけを審査意見に添えます。

検索の絞り込みは、hybrid クエリの filter で行います。filter はすべての検索に同じように効くため、種別・分野・規模の区分の条件は1つの bool クエリにまとめて渡します。点数の正規化は normalization-processor を使い、既定の min_max と arithmetic_mean から始めます。言葉の一致と意味の近さの重み（weights）は、合計が1.0になるように決め、試しの検索の結果を見て調整します。

検索の形は、おおむね次のとおりです（値は例）。

{
  "query": {
    "hybrid": {
      "queries": [
        { "match": { "text": "条文案の本文" } },
        { "knn": { "embedding": { "vector": [0.012, -0.034], "k": 50 } } }
      ],
      "filter": {
        "bool": {
          "filter": [
            { "term": { "kind": "条例" } },
            { "term": { "field": "空き家" } }
          ]
        }
      }
    }
  },
  "size": 30
}

重みは、最初は言葉の一致を重くします。 条文は決まった言い回しが多く、言葉の一致で当たる例が多いためです。試しの検索で、別の言葉で書かれた例が落ちていると分かったら、意味の近さの重みを少しずつ上げます。 重みを変えた日と値は、検索の記録に残します。

人が確認する

担当者は、比較表のすべての行を読みます。 検索の結果は1つの条文案につき10〜20条ほどで、件数が少ないので全件を見ます。

1. 赤の印（quote の不一致）を先に見る … 原文と写しが違う行は、検索結果の本文で読み直します
2. stale と repealed の印を見る … 古い写し、廃止された例規は、それと分かったうえで読みます
3. 参考にする規定例を選ぶ … 観点ごとの違いを見て、審査意見に挙げる例を決めます
4. 選んだ例を原典で確かめる … その自治体の公開の例規集で、現在の版と一致するかを見ます。一致しなければ写しを取り直します
5. 見つからなかった観点を記録する … 「罰則を置いた例は検索の範囲に無かった」ことも審査意見の材料にします

4番目を省かないでください。 写しを取った後に改正されていれば、審査意見に古い条文を挙げることになります。 起案課がそれをもとに条文を直すと、誤りが条例案にまで届きます。

例外に対処する

上から2行目が、この構成の価値の出るところです。 「例が見つからない」は、その書きぶりを採る自治体が少ないという情報です。 0件を隠さず、検索の条件とあわせて審査意見の材料にします。

記録を残す

• 検索に使った条文案と、選んだ種別・分野・絞り込みの条件
• hybrid クエリの結果（条ごとの点数と順位）と、そのときの重み
• 生成AIの比較の結果（comparisons）と、quote の検証の結果
• 担当者が選んだ規定例と、原典で確かめた日
• 例規の写しの取得日と、取り直しの履歴
• 「例が見つからない」と返った検索の記録

4つ目で原典を確かめた日を残すのは、審査意見の根拠の時点を示すためです。 後から「この市の条文と違う」と指摘されたとき、いつの版を見たのかを答えられるようにします。