行政書士事務所で、許認可の申請ごとの過去の補正の指示と対応の記録を探し、同じ窓口・同じ手続きで指摘されやすい点を根拠付きで返す

処理の起点を決める

取り込みと検索で、起点が2つあります。

取り込みは毎晩です。 補正のメモは、補正を受けた日か、対応を終えた日に担当が書きます。翌日の点検に載れば足ります。 案件の管理表の補正の有無の欄が「あり」になった案件を読み、メモのファイルが無ければ担当に書くよう知らせます。

区分の確かめは、週に1回です。 毎晩の取り込みでAIが付けた区分のうち、新しく作られた区分と、自信が低いと書かれたものを一覧にし、総務の担当がまとめて直します。

検索は、担当が案件の画面で「補正の傾向を見る」を押したときに動きます。 申請書類を作り終え、手引きのチェックリストで確かめた後に押します。作り始める前に押すと、まだ決まっていない要件の満たし方で検索することになります。

入力データを集める

質を決めるのは、案件の特徴の欄です。 「建設業の新規の許可」というだけでは、過去の補正のどれが今回に当てはまるかが分かりません。要件をどう満たすかで、求められる資料が違うからです。 管理表に、手続きごとに決めた数個の選択肢の欄を足します。

手引きの版は、古い補正を見分けるために持ちます。 窓口の手引きが改訂されると、それより前の補正は今の運用と違うことがあります。補正の日が、今の手引きの改訂の日より前かどうかを、点検表に出します。

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

補正のメモは、Lambda が案件のフォルダから読みます。メモの書き方は担当ごとに違うので、Claude で指摘ごとに分けます。 1つの補正で3つの指摘を受けていれば、3件の記録になります。

索引の項目は、次のように持たせます。

category は keyword で持たせます。 公式のドキュメントでは、significant_terms はkeyword や数値のような決まった値の項目で最もよく働き、細かく分けた文章の項目ではメモリを多く使うとされています。指摘の内容の文章そのものではなく、区分で集計します。

近い案件の検索は、集計とは別の要求で行います。 同じ窓口・同じ手続きで絞ったうえで、案件の特徴が重なるものを上に並べます。

GET /corrections/_search
{
  "size": 8,
  "query": { "bool": {
    "filter": [ { "term": { "procedure": "建設業の許可" } },
                { "term": { "office": "A県B土木事務所" } } ],
    "should": [
      { "terms": { "features": ["経管_他社役員経験", "専技_実務経験10年"] } },
      { "match": { "finding": "役員 経験 期間 裏付け" } }
    ],
    "minimum_should_match": 1
  } },
  "sort": [ "_score", { "corrected_on": "desc" } ]
}

minimum_should_match を1にしているのは、特徴が1つも重ならない補正を外すためです。 同じ窓口でも、要件の満たし方がまったく違う案件の補正は、今回の点検の根拠になりません。点数が同じなら新しい補正を上にします。

AIへ渡す前に整形する

1. 指摘ごとに分ける … 1つのメモに複数の指摘があれば、指摘ごとに1件にします
2. 区分を付ける … 事務所で決めた区分の一覧（記載の誤り、添付の不足、常勤の確認、経験の期間の裏付け、資格の確認、営業所の実態、財産の確認、様式の版 など）から選びます
3. 依頼者の名前を外す … 指摘の内容に書かれた依頼者の会社名や人名は、「依頼者」「役員A」に置き換えます
4. 案件の特徴を付ける … 案件の管理表の欄から写します
5. 手引きの改訂の日と比べる … 補正の日が、その窓口の今の手引きより前なら印を付けます
6. 取下げ・再申請を分ける … 補正で済まなかった案件は、結果の項目で分けます

2番目で、区分を事務所の一覧から選ばせるのが要です。 AIに自由に区分を作らせると、「常勤性の確認」「常勤の疎明」「常勤確認資料」が別の区分になり、集計では3つに散って、どれも目立たなくなります。 一覧に無いときだけ「新しい区分の候補」として出させ、週1回の確かめで一覧に足すかを決めます。

3番目の置き換えは、AIに任せきりにしません。 依頼者の会社名は案件の管理表にあるので、取り込みの処理が管理表の名前で機械的に置き換え、AIはその後のメモを読みます。役員の個人名のように管理表に無い名前だけ、AIに「人名らしい語」を挙げさせて置き換えます。

AIに処理させる

AIの仕事は2か所です。 取り込みでメモを指摘ごとに分けて区分を付けることと、検索と集計の結果から点検表を書くことです。集計と検索は検索基盤が行います。

最後の行が、いちばん外せない線です。 点検表に「通る見込み」が書かれると、担当はそれを依頼者に伝えたくなります。過去の補正が無いことは、今回補正が無いことを意味しません。

2行目も大事です。 補正のメモには「〇〇さんは細かい」のような書き方が残っていることがあります。点検表に個人への評価が載ると、事務所の外に出たときに問題になります。

指示内容を固定する

あなたは行政書士法人で、許認可の申請前の点検表を作る係です。
渡された集計と検索結果だけを根拠にしてください。一般的な許認可の知識で補わないでください。

【今回の案件】手続き：{procedure}　種類：{app_type}　窓口：{office}　特徴：{features}
【集計】
common：この窓口・手続きで件数の多い指摘の区分と件数
distinctive：同じ手続きの他の窓口に比べ、この窓口で目立つ区分と件数
【検索結果】similar：今回の案件の特徴に近い過去の補正（案件番号、補正の日、指摘、対応、結果）
【手引きの改訂の日】{guide_revised_on}

【点検表に書くこと】
1. 区分ごとに、確かめる項目を1行。「この窓口で特に多い」か「どの窓口でも多い」かを書く
2. 各行に根拠の案件番号と補正の日。補正の日が手引きの改訂の日より前なら「運用が変わっている可能性」
3. similar の対応のうち、補正で受理されたときに出した資料

【厳守事項】
- 許可の要件を満たすかどうかを書かないでください。
- 補正なしで通る見込みを書かないでください。
- 窓口の担当者個人について書かないでください。
- 検索結果に無い項目を足さないでください。根拠の案件番号の無い行は書かないでください。
- 依頼者の名前を書かないでください。

「根拠の案件番号の無い行は書かない」を明記しないと、AIは一般的な点検の項目を足します。 「役員の欠格要件を確かめる」のような正しい項目ですが、手引きのチェックリストと重なり、点検表がこの窓口の傾向を示すものでなくなります。

検索結果は、Claude の検索結果ブロックで渡します。 補正1件を1つの search_result にし、source に案件番号を入れます。引用を有効にすると、答えの文に、渡した source と title の引用が付きます。 引用は既定で無効で、1つのリクエストの検索結果はすべて同じ設定にします。

出力形式を固定する

集計は、次のように組みます。

GET /corrections/_search
{
  "size": 0,
  "query": { "bool": { "filter": [
    { "term": { "procedure": "建設業の許可" } },
    { "term": { "office": "A県B土木事務所" } },
    { "range": { "corrected_on": { "gte": "now-3y/d" } } }
  ] } },
  "aggs": {
    "common": { "terms": { "field": "category", "size": 5 } },
    "distinctive": { "significant_terms": {
        "field": "category",
        "background_filter": { "bool": { "filter": [
          { "term": { "procedure": "建設業の許可" } },
          { "range": { "corrected_on": { "gte": "now-3y/d" } } } ] } } } }
  }
}

common と distinctive を同じ要求で取ります。 significant_terms の結果は、区分ごとに前景の件数（doc_count）と背景の件数（bg_count）と目立ち方の点数（score）を返します。公式のドキュメントでは、この点数には単位が無く、同じ要求の中で比べるためだけのものとされています。点検表には点数を出さず、件数を出します。

背景を狭めると、計算が遅くなることがあります。 公式のドキュメントでは、background_filter を使うと背景の件数を絞り込みのたびに数えるため、索引全体の件数を使う既定より遅くなりうるとされています。2,800件の規模では問題になりませんが、件数が増えたら手続きごとに索引を分けることを考えます。

案件の管理表に返す形は、次のJSONです。

{
  "case_id": "K-2026-1007-14",
  "office": "A県B土木事務所", "procedure": "建設業の許可", "app_type": "新規",
  "checklist": [
    { "category": "常勤の確認", "kind": "distinctive",
      "item": "常勤を示す資料として、健康保険の資格の資料を求められた例がある",
      "count": 6, "bg_count": 9,
      "evidence": [{ "case_id": "K-2025-0311-02", "corrected_on": "2025-03-18" }],
      "possibly_outdated": false },
    { "category": "添付の不足", "kind": "common",
      "item": "", "count": 11,
      "evidence": [], "possibly_outdated": true }
  ],
  "similar_cases": [
    { "case_id": "K-2024-0902-07", "finding": "", "response": "", "outcome": "補正で受理" }
  ]
}

1つ目の理由は、kind で「特有」と「よくある」を分けて表示できることです。 担当が先に見るべきは distinctive の行です。

2つ目は、count と bg_count で目立ち方の理由を数字で見せられることです。 この窓口で6件、同じ手続きの全体で9件なら、その指摘の多くがこの窓口で起きていると分かります。

3つ目は、possibly_outdated で古い根拠を区別できることです。

システムへ連携する

人が確認する

この構成の確認は、必須です。 申請の書類は、依頼者の許可の取得に直結します。

1. 区分を週に1回確かめる … 総務の担当が、新しい区分の候補と自信の低いものを直します
2. 点検表で書類を確かめる … 担当が、distinctive の行から順に書類を見ます
3. 古い根拠を手引きで確かめる … possibly_outdated の行は、今の手引きで確かめます
4. 行政書士が出す前に見る … 点検表と書類を見て、出すかを決めます

3番目を省かないでください。 手引きが改訂されて要らなくなった資料を、過去の補正を根拠に依頼者へ求めると、依頼者に余計な手間をかけさせます。

1件あたり8分を目安にします。 点検表を読んで書類の該当箇所を確かめる時間です。

週1回の区分の確かめは、30分程度で終わる量に保ちます。 毎晩の取り込みで新しい区分の候補が多すぎるなら、区分の一覧が今の補正の実態に合っていない合図です。一覧そのものを見直します。

例外に対処する

1行目で集計を出さないのは、少ない件数の significant_terms が偶然の偏りを拾うためです。 3件のうち2件が同じ区分なら、それだけで目立つと出ます。

記録を残す

• 取り込みの件数、止めたメモとその理由
• AIが付けた区分と、総務の担当が直した区分
• 案件ごとの集計の結果、近い案件、点検表の版
• 点検表を見た担当と、行政書士が確かめた日時
• 申請の後に補正があったか、それが点検表に載っていたか

最後の行が、この構成の効き目を測る材料です。 点検表に載っていたのに補正を受けたなら、点検の仕方の問題です。載っていなかった補正は、次の取り込みで新しい傾向として入ります。

点検表の版を残すのは、依頼者への説明のためです。 補正を受けたときに、出す前に何を確かめていたかを示せます。どの補正を根拠に何を確かめたかが、案件ごとに後から辿れます。