自治体の補助金の担当が交付申請を確かめるときに、事業の内容が近い過去の交付事業の審査メモと実績報告を探し、対象経費の判断と当時の照会を根拠付きで返す

処理の起点を決める

担当者が審査の画面で「前例を探す」を押したことを起点にします。 経費の内訳の中で判断に迷う行がある申請に使います。すべての申請で自動に前例を出すと、要綱を読む前に前例を読む癖が付くので、担当者が必要と思ったときに押す形にします。

索引の更新は、決裁のたびに行います。 交付決定の決裁を経た審査メモ、額の確定の決裁を経た実績報告の審査の記録を、決まったフォルダに置くと、その文書だけを読み取って索引に入れます。

改正の表の更新は、交付要綱の改正のたびに担当課が行います。 改正された補助金・条項・対象経費の扱いと施行の日を表に書き足します。この表が古いと、第5章の4番目の印が付かなくなります。

入力データを集める

質を決めるのは、審査メモと実績報告が同じ事業の番号で結べるかです。 補助金の台帳の事業の番号を、審査メモと実績報告の両方に必ず持たせます。 番号の無い古い記録は、台帳の申請者と年度で番号を割り当て、割り当てたことを印で残します。

定型の文言の一覧は、more_like_this の精度を決めます。 申請書の様式に必ず出る言葉は、どの申請にも同じように出るので、事業の中身ではなく様式の近さで文書が並びます。 一覧の言葉を stop_words に入れて、特徴づける言葉の候補から外します。

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

審査メモ・実績報告の審査の記録を、それぞれ索引の1件にします。 項目は、事業の番号（キーワード）、補助金の種類（キーワード）、年度（数値）、記録の種類（審査メモ・実績報告）、事業計画の要約と経費の文章（Sudachi で分ける文章）、経費の行の一覧に分けます。

検索の要求は、おおよそ次の形です。

{
  "size": 8,
  "query": {
    "bool": {
      "filter": [
        { "term": { "program": "shop-renovation" } },
        { "range": { "fiscal_year": { "gte": 2021 } } }
      ],
      "must": {
        "more_like_this": {
          "fields": ["plan_text", "expense_text"],
          "like": "{今回の事業計画と経費の内訳の文章}",
          "min_term_freq": 1,
          "min_doc_freq": 2,
          "max_query_terms": 40,
          "stop_words": ["本事業", "補助対象経費", "事業計画"]
        }
      }
    }
  },
  "collapse": {
    "field": "project_id",
    "inner_hits": { "name": "records", "size": 4, "sort": [{ "record_type": "asc" }] }
  }
}

min_term_freq を1にしているのは、既定の2のままだと短い文章で何も引けないからです。 公式のドキュメントでは、min_term_freq は入力の中でこの回数より少なく出る言葉を無視するもので、既定は2です。経費の内訳の「エアコン」「看板」は1回しか出ないことが多く、既定のままだと、いちばん大事な経費の言葉が候補から落ちます。 min_doc_freq（既定5）、max_query_terms（既定25）、minimum_should_match（既定30%）も、件数を見ながら決めます。

前の年度にも申請のあった事業者の継続の申請では、like に文章と文書を並べます。 公式のドキュメントでは、like には自由な文章と、索引にある文書を組み合わせて渡せるとされています。前年度の同じ事業の審査メモを like に足すと、その事業と内容の近い他の事業も一緒に引けます。反対に、unlike に渡した文章や文書の言葉は、近さの判断に使われないとされています。様式の説明の文章を unlike に入れる方法もありますが、まずは stop_words で足ります。

collapse の項目は、キーワードの型にします。 公式のドキュメントでは、collapse はキーワードか数値の項目に使えるとされています。また、返る総件数はまとめる前の件数で、まとまりの数ではないとされているので、画面に出す件数は返ってきた事業の数から数えます。

AIへ渡す前に整形する

1. 記録を文字にする … PDF の審査メモと実績報告から文字を取り出し、取り出せないものは読み取りをかけます。経費の行の表は、表の形を保って取り出します
2. 事業の番号を結ぶ … 補助金の台帳を引き、審査メモと実績報告に同じ事業の番号を付けます
3. 当時の要綱の版を割り当てる … 交付決定の日から版を割り当てます
4. 経費の行を分ける … 経費の行ごとに、名前・内容・判断・理由を分け、Citations で引けるようにブロックに分けて保管します
5. 申請者を特定する項目を外す … 事業者名・代表者名・住所・口座は索引の文章から外し、事業の番号から台帳をたどれるだけにします
6. 今回の入力から定型の文言を除く … 担当者が貼り付けた文章から、定型の文言の一覧の言葉を除いてから検索します

2番目を軽く見ないでください。 審査メモと実績報告が結べないと、collapse で事業ごとにまとめても、交付決定のときの判断と確定のときの結果が別の事業として並びます。 この構成の中心が崩れます。

AIに処理させる

探すのとまとめるのは検索基盤、改正の印は改正の表から規則で付けます。生成AIには、事業ごとの記録を読ませ、今回の経費の行と比べやすい形に並べさせます。

させないことの1行目が、この構成でいちばん大事な線引きです。 近い事業でエアコンの更新費を対象にしていれば、生成AIは「今回も対象となる可能性があります」と書きたくなります。 それを読めば、要綱を読む前に結論が決まります。

させることの4行目は、第3章の（b）への手当てです。 交付決定のときは対象、確定のときに減額、という前例は、今回の申請者に、実績報告で何を出してもらうかを先に伝える材料になります。

させることの1行目で、経費の名前の違いを越えます。 今回の「空調設備の更新」と過去の「エアコン入替工事」は、言葉が違っても同じ経費です。検索で事業を引いたあと、経費の行どうしの対応を付けるのは生成AIに任せます。 ただし、対応を付けた根拠として、過去の経費の行の原文を必ず引用させます。名前だけで対応を付けた行は、担当者が原文で内容を確かめます。

指示内容を固定する

あなたは市の補助金の担当課で、交付申請を審査する担当者に
過去の交付事業の記録を示す立場です。
渡した文書（過去の事業の審査メモと実績報告の審査の記録）だけを
根拠にしてください。

【今回の申請】補助金の種類 {program}
【今回の経費の内訳】{expense_lines}
【過去の事業】事業ごとに文書として渡します。各文書のタイトルには
  事業の番号、交付決定の年度、要綱の版、改正の印が付いています。
  本文は経費の行ごとのブロックに分かれています。

【やること】
1. 今回の経費の行ごとに、過去の事業の近い経費の行を挙げる
2. その経費の当時の判断（対象・対象外・一部対象）と理由を書く
3. 照会した内容と回答があれば書く
4. 実績報告の審査で減額・対象外とした経費があれば、理由を書く

【厳守事項】
- 今回の経費が対象になるか、ならないかを書かないでください。
  「可能性があります」「同様に」とも書かないでください。
- 過去の判断は、その事業の判断としてだけ書いてください。
- 改正の印が付いた事業は、最初に「交付決定の後に要綱の改正あり」と
  書いてください。
- 記録に書かれていない理由を推測で補わないでください。
  無いものは「記載なし」と書いてください。
- 事業者名や個人の名前を書かないでください。

「可能性があります」を禁じないと、ほぼ必ず書きます。 断定を禁じるだけでは、言い方を和らげて同じ結論を書きます。結論の方向そのものを書かせないように、言い回しまで塞ぎます。

事業の文書は、Citations を有効にしたカスタムの内容の文書として渡します。 公式のドキュメントでは、カスタムの内容の文書は渡したブロックがそのまま引用の単位になり、ブロックの番号で引用の箇所が返り、引用の箇所は渡した文書を必ず指すとされています。経費の行を1ブロックにして渡し、どの経費の行を根拠にしたかを番号で受け取ります。 また、Citations は1回の要求の中のすべての文書で有効にするか、すべてで無効にするかのどちらかとされているので、事業の文書はすべて有効にして渡します。

出力形式を固定する

Citations は構造化出力と併用できません。 公式のドキュメントでは、文書で Citations を有効にしたまま output_config.format を指定すると、400のエラーになるとされています。そのため、生成AIからは引用付きの文章で受け取り、Lambda が次の形のJSONに組み直して画面に流し込みます。

{
  "application_id": "",
  "expense_lines": [
    {
      "this_line": "店舗の空調設備の更新",
      "precedents": [
        {
          "project_id": "R05-SR-0142",
          "program_version": "2023",
          "amended_after": false,
          "decision": "一部対象",
          "reason_quote": "",
          "inquiry_quote": "",
          "settlement": "確定時に一部減額",
          "settlement_quote": "",
          "citation": { "document_index": 0, "start_block_index": 3, "end_block_index": 4 }
        }
      ]
    }
  ],
  "no_precedent_lines": [""]
}

1つ目の理由は、経費の行ごとに前例を並べられることです。 担当者が迷っているのは事業全体ではなく経費の行なので、今回の行の右に、過去の近い行の判断と理由が並ぶ形にします。

2つ目は、settlement を交付決定の判断と並べられることです。 交付決定で対象、確定で減額という前例は、画面で色を変えて出します。

3つ目は、no_precedent_lines で前例の無い経費を一覧にできることです。 前例が無い経費は、係長や前任者に確かめる経費として先に分かります。

システムへ連携する

審査メモと補助金の台帳には書き込みません。 今回の審査メモは、これまでどおり担当者が書き、決裁を経て保存します。前例の画面から審査メモを作れる作りにすると、過去の理由をそのまま写した審査メモが増えます。

人が確認する

担当者が前例を読み、今回の判断は交付要綱に照らして担当者が行い、決裁を受けます。

1. 改正の印を見る … 改正の後の事業を先に読み、改正の前の事業は今の要綱での扱いを確かめる前提で読みます
2. 確定のときの結果を見る … 交付決定で対象、確定で減額の前例があれば、その理由を読みます
3. 前例の無い経費を確かめる … no_precedent_lines の経費は、係長に確かめます
4. 今回の判断を審査メモに書く … 参照した前例の事業の番号を書きます
5. 照会が要れば申請者に照会する … 前例の照会の内容を参考に、担当者が文面を書きます

2番目を省かないでください。 確定のときの減額は、交付決定の判断より後の、証拠書類を見たうえでの結論です。前例の判断を読むときは、交付決定と確定の両方を見て初めて、その経費がどう扱われたかが分かります。

4番目の「参照した前例の番号」を必ず残してください。 次の担当がこの審査メモを前例として読んだとき、どの前例を見て判断したかをたどれます。 異動で経緯が失われるのを防ぐ、いちばん安い手当てです。

目標は、1件9分です。 前例を読み、改正の印と確定の結果を確かめ、今回の経費との違いを書き出すまでの時間です。

例外に対処する

2行目の見分けが大事です。 確定の記録が無いのが、事業がまだ終わっていないからか、記録が結べていないからかで、前例としての重さが変わります。 台帳の確定額の欄を見て、どちらかを表示に添えます。

記録を残す

• 今回の申請の補助金の種類と、検索に使った文章（定型の文言を除いた後）
• 返した事業の番号、要綱の版、改正の印
• 生成AIに渡した文書と、返ってきた文章と引用の全文
• 担当者が開いた記録と、審査メモに書いた参照した前例の番号
• 改正の表を参照したときの表の最終更新日
• 検索の設定（min_term_freq などの値）と定型の文言の一覧の版

4行目は、判断の経緯を後から追うためです。 申請者から「去年は対象だったのに」と問われたとき、どの前例を見て、どの改正を踏まえて判断したかを説明できます。

最後の行は、検索の設定を直したときに、前と後で出る前例がどう変わったかを比べるためです。 設定を変えた日が分からないと、同じ申請で前例が変わった理由を説明できません。