自治体の情報公開の担当が、新しい開示請求を受けたときに、過去の開示決定・不開示の理由・審査会の答申から似た請求を探し、当時の判断と理由を根拠付きで返す

処理の起点を決める

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

取り込みは毎晩です。 決定は所管課が行い、決定通知書の写しが総務課に届きます。翌日以降の請求の判断に載れば足ります。 決定簿で決定日が付いた請求の文書を読み、不開示の理由の文書が無ければ担当に知らせます。

答申は、届いた日に担当が決定簿に結びつけます。 答申の数は年に十数件なので、対象の決定番号を担当が入れ、取り込みで結論を付けます。 答申の結論をAIに推測させると、「一部取消し」と「取消し」の取り違えが起きます。

検索は、担当が決定簿の画面で「過去の判断を見る」を押したときに動きます。 請求の内容を決定簿に入れた後に押します。請求者と話して請求の内容を特定し直したときは、もう一度押します。

入力データを集める

質を決めるのは、いちばん下の部分の種類の一覧です。 理由の説明は所管課ごとに書き方が違い、「職員以外の個人の氏名」「関係者の氏名」「個人名」が別の言葉で書かれます。 種類の一覧にそろえないと、部分の組み合わせで検索できません。

決定の種類に「不存在」を含めるのは、文書が無いという判断も前例になるためです。 同じ種類の文書を前回は「作成していない」と答えたのに、今回は開示すると、前回の判断の正しさが問われます。

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

決定通知書と不開示の理由の文書は、Lambda が共有フォルダから読みます。理由の文書の書き方は所管課ごとに違うので、Claude で部分ごとに分けます。

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

withheld を nested にするのは、部分の組み合わせを崩さないためです。 公式のドキュメントでは、オブジェクトの配列は既定で平らにされ、各項目の値が配列ごとにまとめて保存されるとされています。平らにすると、「氏名を個人の情報の号で」と「単価を法人の情報の号で」が混ざり、「単価を個人の情報の号で」不開示にした決定のように誤って当たります。

検索は、次のように組みます。

GET /foi_decisions/_search
{
  "size": 8,
  "query": { "bool": {
    "must": [ { "more_like_this": {
        "fields": ["request_text", "doc_titles"],
        "like": ["〇〇線道路改良工事の設計書と積算の資料一式"],
        "min_term_freq": 1, "min_doc_freq": 2, "max_query_terms": 20 } } ],
    "should": [ { "nested": { "path": "withheld",
        "query": { "term": { "withheld.part_type": "法人の単価" } },
        "inner_hits": { "size": 3 } } } ],
    "filter": [ { "range": { "decided_on": { "gte": "now-8y/d" } } } ]
  } },
  "aggs": { "parts": { "nested": { "path": "withheld" },
    "aggs": { "by_clause": { "terms": { "field": "withheld.clause" } } } } }
}

must に more_like_this、should に nested を置くのは、似た請求であることを条件にし、部分の種類が重なる決定を上に寄せるためです。 部分の種類を must にすると、今回は何を不開示にするかがまだ決まっていない段階で、決め打ちの検索になります。 担当が画面で部分の種類を選ばないときは、should を外して引きます。

min_term_freq を1にしているのは、請求の文が短いためです。 公式のドキュメントでは、入力の中の出現が min_term_freq より少ない語は無視され、既定は2です。1行の請求の文では、ほとんどの語が1回しか出ないので、既定のままでは語が選ばれません。min_doc_freq は既定で5で、扱いの少ない種類の文書の請求を拾えるよう2に下げます。

AIへ渡す前に整形する

1. 部分ごとに分ける … 1つの決定に複数の不開示の部分があれば、部分ごとに1要素にします
2. 部分の種類を付ける … 総務課の部分の種類の一覧から選びます
3. 号をそろえる … 「第7条第2号」「7条2号」「法人等情報」を、条例の号の表記に機械的にそろえます
4. 不開示とした中身を入れない … 索引に入れるのは、部分の種類と理由の説明だけです。不開示とした情報そのものは入れません
5. 個人名を置き換える … 請求の内容や理由の説明に出てくる個人名は、記号に置き換えます。請求者の氏名は索引に入れません
6. 答申の結論を付ける … 担当が結びつけた答申の結論を appeal_outcome に入れます

4番目が、この構成でいちばん外せない線です。 理由の説明に「〇〇の住所が記載されているため」と書かれていれば、その住所は索引に入れません。索引から不開示にした情報が読めたら、決定そのものを無にします。 取り込みで理由の説明を読み、具体的な値が書かれていれば置き換えます。

5番目で請求者の氏名を入れないのは、助言のメモで請求者が分かると、請求者ごとに判断を変えたように見えるからです。 開示の判断は、誰が請求したかによりません。

AIに処理させる

AIの仕事は2か所です。 取り込みで不開示の理由を部分ごとに分けることと、検索の結果から助言のメモを書くことです。探すことと数えることは検索基盤が行います。

最初の2行が、いちばん外せない線です。 助言のメモに「今回も法人の単価を不開示にする」と書かれると、所管課はそのまま決定の案にしたくなります。過去に不開示にしたことは、今回の文書を不開示にする理由になりません。

指示内容を固定する

あなたは市の総務課で、開示請求を所管課に回すときに添える助言のメモを作る係です。
渡された検索結果だけを根拠にしてください。一般的な情報公開の知識で補わないでください。

【今回の請求】{request_text}
【検索結果】似た過去の決定ごとに、決定番号、決定日、所管課、決定の種類、対象の文書、
  不開示とした部分（部分の種類・号・理由の説明）、答申の結論
【集計】似た決定で使われた号の内訳

【助言のメモに書くこと】
1. 似た決定ごとに1行。対象の文書、決定の種類、不開示とした部分の種類と号
2. 各行に根拠の決定番号と決定日
3. 答申で取り消された決定（一部取消しを含む）は「取り消された判断」の欄に分け、
   答申で開示すべきとされた部分を写す
4. 似た決定の間で、同じ部分の種類の扱いが分かれていれば、その旨を書く

【厳守事項】
- 今回の請求で開示するか、どこを不開示にすべきかを書かないでください。
- 号の当てはめが正しいかを評価しないでください。
- 取り消された決定を、前例として示さないでください。
- 検索結果に無い決定を足さないでください。根拠の決定番号の無い行は書かないでください。
- 請求者について書かないでください。個人名を書かないでください。

「取り消された決定を前例として示さない」を明記しないと、AIは似ている順に並べます。 取り消された決定が一番似ていることは珍しくありません。同じ種類の文書だからこそ、審査請求を受けたのです。

4番目の「扱いが分かれていれば書く」は、所管課ごとのぶれを見つけるためです。 同じ部分の種類を、ある課は開示し、別の課は不開示にしていれば、今回の判断の前に総務課で整理すべき論点です。

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

出力形式を固定する

nested の検索で inner_hits を付けると、決定ごとに、条件に当たった部分だけが添えて返ります。 公式のドキュメントでは、inner_hits の _nested がどの要素から来たかと、その位置を示します。決定通知書のどの部分かを、担当がすぐ見つけられます。

決定簿に返す形は、次のJSONです。

{
  "request_id": "R-2026-1008-03",
  "similar": [
    { "decision_id": "D-2024-0412", "decided_on": "2024-06-20",
      "section": "道路課", "decision_type": "部分開示",
      "withheld": [ { "part_type": "法人の単価", "clause": "第7条第3号" },
                    { "part_type": "個人の印影", "clause": "第7条第2号" } ],
      "appeal_outcome": "なし" }
  ],
  "overturned": [
    { "decision_id": "D-2021-0877", "appeal_outcome": "一部取消し",
      "to_be_disclosed": "工事の総額と工種ごとの金額" }
  ],
  "clause_counts": { "第7条第2号": 9, "第7条第3号": 5 },
  "divergence": ["法人の単価：道路課は不開示、公園課は開示（D-2023-0215）"]
}

1つ目の理由は、overturned を similar と別の配列にできることです。 画面でも別の枠に出し、取り消された判断が前例の一覧に紛れません。

2つ目は、clause_counts で号の内訳を数字で見せられることです。 公式のドキュメントでは、nested の集計は nested の各要素を別の隠れた文書として集計し、要素の中の項目の関係を保つとされています。似た決定で、どの号がどれだけ使われたかが分かります。

3つ目は、divergence で所管課ごとのぶれを示せることです。 総務課で整理する論点の一覧として、そのまま使えます。

システムへ連携する

人が確認する

この構成の確認は、必須です。 開示の決定は、住民の知る権利と、文書に書かれた個人や法人の利益の両方に関わります。

1. 部分の種類を週に1回確かめる … 担当が、新しい種類の候補と自信の低いものを直します
2. 助言のメモを決定通知書で確かめる … 根拠の決定番号から通知書を開き、部分と号が合っているかを見ます
3. 取り消された判断を答申で確かめる … overturned の決定は、答申の本文で開示すべきとされた範囲を読みます
4. 所管課に回す … 助言のメモを添えて回し、判断は所管課が今回の文書を見て行います

1件あたり12分を目安にします。 似た決定が数件で、取り消された判断が無ければ数分で終わり、取り消された判断や所管課ごとのぶれがある請求は20分を超えます。

3番目を省かないでください。 「一部取消し」の答申は、決定のどの部分を開示すべきとしたかが本文にしか書かれていません。to_be_disclosed はAIが答申から写したもので、写し漏れがあると、取り消されなかった部分まで前例のように読めてしまいます。 答申の本文と1度は突き合わせます。

助言のメモを所管課に回すときは、決定番号を残したまま渡します。 所管課が自分で決定通知書を開けるようにするためで、メモの要約だけで判断させないための工夫です。

例外に対処する

5行目は、見つかった時点で必ず止めます。 不開示にした情報が索引から読める状態は、その決定を出した意味を失わせます。

8行目も同じ理由です。 文書があるかどうかを答えること自体が不開示の情報を明かす場合に、存否を答えずに拒否しています。過去の決定の一覧に文書名が出れば、その文書があったことが庁内に広まります。

記録を残す

• 取り込みの件数、止めた決定とその理由、置き換えの結果
• AIが付けた部分の種類と、担当が直した種類
• 請求ごとの検索の条件、返ってきた決定番号、助言のメモの版
• 助言のメモを確かめた担当と日時、所管課に回した日
• その後の決定が、助言のメモの前例と同じ範囲だったか

助言のメモの版を残すのは、審査請求に備えるためです。 審査請求を受けたとき、決定の前に総務課がどの前例を示していたかを、弁明書を書く担当が確かめられます。

最後の行は、所管課ごとのぶれが減ったかを見る材料です。 前例と違う範囲で決定したときは、その理由を決定簿に残しておくと、次に同じ種類の請求が来たとき、違いの理由ごと前例になります。