企業年金基金の事務局に届く給付・手続の問い合わせに、規約と手続の案内を根拠にして回答の下書きを作る

処理の起点を決める

受付台帳への新規登録を起点にします。 メールとWebフォームは受付担当が台帳に登録した時点、書面はスキャンを添付して登録した時点です。メールの受信そのものを起点にしません。 基金の代表アドレスには、受託機関からの連絡、母体企業の人事からの照会、広告も届きます。加入者からの問い合わせかどうかを判断して台帳に載せるのは、受付担当の仕事として残します。

処理は1件ずつ、登録の直後に動かします。 夕方にまとめて動かすと、翌朝の担当職員は前日分の下書きが一度に並んだ状態から始めることになり、急ぎの問い合わせ（受給者の死亡の連絡など）が埋もれます。台帳に「急ぎ」の列を設け、受付担当が付けた印を下書きの一覧の並び順に使います。

同じ人から続けて届いたものは、前の問い合わせと関連付けます。 加入者番号が同じで、前の問い合わせが未回答のまま14日以内なら、新しい下書きを作らず、前の問い合わせへの追記として扱います。 2通に別々の回答を送ると、内容が食い違ったときに説明がつきません。

入力データを集める

質を決めるのは、規約の版と施行日です。 索引の各条に「施行日」と「失効日」の2つの日付を持たせ、改正のたびに旧い版を消さずに失効日を入れます。旧い版を消すと、中途脱退者への回答の根拠が無くなります。

附則の経過措置は、本文とは別の条として索引に入れ、どの条に効くかを書き添えます。 「第○条の規定にかかわらず、平成○年○月○日前に加入者の資格を取得した者については」という形の附則は、本文の条と一緒に引かれないと意味を持ちません。

確定済みの回答例は、多くても200件ほどに絞ります。 過去の回答を全部入れると、誤っていた回答も根拠として拾われます。係長が「この書き方でよい」と確かめたものだけを入れます。

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

検索は質問ごとに行います。 1通に「住所が変わった」「年金はいつから受け取れるか」の2つが含まれていれば、まずAzure OpenAI に質問を分けさせ、質問ごとに検索をかけてから下書きを作らせます。 1通まとめて検索すると、どちらか一方の根拠しか上位に来ません。

絞り込みの条件は、施行日が基準日以前で、失効日が基準日より後（または空）の条だけです。 基準日は、在職中の加入者と受給者は今日、中途脱退者は資格の喪失日とします。中途脱退者が「今から受け取る手続」を聞いているときは、手続の案内だけ今日の版を使い、給付の要件は喪失日の版を使います。この使い分けを、質問の種類ごとの表として持っておきます。

AIへ渡す前に整形する

1. 書面の読み取り … 書面で届いたものは、スキャンを Azure AI Document Intelligence の読み取りにかけて文字にします
2. 加入者番号の照合 … 本文と台帳の加入者番号を名簿で引き、氏名の一致を確かめます。一致しなければ処理を止めて受付担当へ戻します
3. 個人情報の伏せ字 … 氏名・住所・電話番号・口座番号・基礎年金番号を、[氏名] [口座] のような印に置き換えます。回答の下書きに個人情報は要りません
4. 基準日の決定 … 区分と資格の喪失日から、上に書いた規則で決めます
5. 本人確認の状態の付与 … 登録済みの住所・メールアドレスから届いたものか、Webフォームのログインを経たものかを印にします
6. 長文の分割 … 書面で何ページにもわたる不服の申し出は、要約の対象にせず、人へ回す印を付けます

3番目は、下書きの質のためではなく、外へ出す範囲を絞るためです。 回答の下書きを作るのに、加入者の氏名も口座番号も要りません。要らないものは最初から渡しません。

5番目は、答えてよい範囲を決めるのに使います。 本人確認が取れていない経路から「私の年金額を教えて」と届いたら、一般的な説明と照会の手順だけを答え、個人の記録には触れません。 この判断は AI ではなく、印を見た規則で行います。

AIに処理させる

させるのは、質問を分けること、質問ごとに区分を付けること、根拠の条文を引いて回答の下書きを書くこと、個人の記録が要る箇所に空欄の印を置くことです。

1行目がいちばん起きやすい失敗です。 規約の別表に給付の算定式があり、問い合わせに「勤続20年」と書いてあれば、AIは計算して金額を書きます。算定式は正しくても、その人の給与の記録や経過措置で値は変わります。 書かせない理由は、計算が難しいからではなく、記録のほうが正しいからです。

2行目も同じくらい重要です。 確定給付企業年金法第30条では、給付を受ける権利は受給権者の請求に基づいて事業主等が裁定するとされています。「支給されます」と書くと、裁定の前に結論を伝えたことになります。 「請求をいただいたうえで、基金が支給の要件を確かめます」という書き方に統一します。

3行目は、選択肢の説明と助言の境目の話です。 法第41条の脱退一時金と、法第81条の2の他の確定給付企業年金への移換は、どちらも中途脱退者が選べる手続です。それぞれの手続と期限を並べて書くまでがこの構成の役目で、どちらを選ぶべきかは書きません。

指示内容を固定する

あなたは企業年金基金の事務局で、加入者・受給者・中途脱退者からの
問い合わせに回答の下書きを作る担当です。
下書きは事務局の職員が確かめてから送ります。

【使ってよい根拠】
- 【根拠の条文】として渡した規約・給付規程の条と、手続の案内の箇所だけ
- 根拠の条文はすべて【基準日】に施行されていた版です
- 渡されていない条文や、一般的な知識で補わないでください

【やること】
1. 問い合わせに含まれる質問を1つずつに分ける
2. 質問ごとに category を1つ選ぶ
   procedure / benefit_rule / personal_record / decision_or_appeal / out_of_scope
3. 質問ごとに回答の下書きを書き、根拠にした条を basis に入れる
   basis.quote には根拠の文書から写した一文をそのまま入れる

【厳守事項】
- 給付の金額、加入者期間、受給開始の年月など、その人の記録で決まる値は
  書かないでください。その位置に {{要照会:項目名}} と書き、
  record_fields に項目名を入れてください。
- 規約の別表に算定式があっても、計算しないでください。
- 「支給されます」「受け取れます」と書かないでください。
  「ご請求をいただいたうえで、基金が支給の要件を確認いたします」と書いてください。
- 脱退一時金と移換のどちらが有利かを書かないでください。
  両方の手続を並べて説明するまでにしてください。
- 公的年金（老齢基礎年金・老齢厚生年金）と税金の質問には答えず、
  category を out_of_scope にしてください。
- 根拠の条文で答えられない質問は、answer を空にし、
  escalate_reason に「根拠なし」と書いてください。
- 附則に経過措置がある条は、本文と附則の両方を basis に入れてください。
- 問い合わせの文面に書かれていない事情（勤続年数、退職の理由など）を
  推測で補わないでください。不明なら {{要照会:項目名}} にしてください。

【送り主の区分】{member_type}
【基準日】{reference_date}
【本人確認の状態】{identity_status}
【問い合わせ（個人情報は伏せ字済み）】{inquiry_text}
【根拠の条文】{retrieved_articles}
【確定済みの回答例】{approved_examples}

「計算しないでください」を、金額を書かない指示とは別に書いているのには理由があります。 金額を書くなとだけ言うと、「月額の目安は加入者期間×○円です」と式の形で答えを書くことがあります。読む側にとっては金額を書いたのと同じです。

「推測で補わない」も明記が要ります。 「定年で辞めました」と書いてあれば、AIは勤続年数を規約の定年から逆算します。逆算した勤続年数で支給要件を満たすと書けば、それは記録を見ずに出した結論です。

出力形式を固定する

次の形の JSON で受け取ります。

{
  "inquiry_id": "",
  "questions": [
    {
      "question": "",
      "category": "procedure | benefit_rule | personal_record | decision_or_appeal | out_of_scope",
      "answer": "",
      "basis": [
        { "doc": "", "version": "", "article": "", "quote": "" }
      ],
      "record_fields": [""],
      "escalate_reason": ""
    }
  ],
  "overall_note": ""
}

1つ目の理由は、category を列挙型で縛れることです。 構造化出力では列挙型が使えます。受付台帳の集計がこの区分で行われるので、表に無い値が入ると集計が崩れます。

2つ目は、basis の quote を後段で照合できることです。 下書きを台帳に書き戻す前に、quote の文字列が索引の該当の条に本当にあるかをプログラムで確かめます。無ければ、条番号ごと作られた根拠です。 その質問の下書きを空にし、人へ回す印を付けます。

3つ目は、record_fields で職員の作業が決まることです。 「加入者期間」「年金の見込額」と並んでいれば、職員は記録管理のシステムでその項目だけを照会します。本文の {{要照会:項目名}} と record_fields の数が合わなければ、下書きを差し戻します。

スキーマの書き方には制約があります。 公式ページでは、すべてのフィールドを必須にし、オブジェクトに additionalProperties: false を設定すること、文字列の minLength や pattern、配列の minItems などがサポートされないことが書かれています。最大100個のプロパティと5段の入れ子という上限もあります。「basis が1件以上あること」はスキーマで強制できないので、後段の検査で見ます。

システムへ連携する

記録管理のシステムとつながないのは、意図してのことです。 つなげば空欄を自動で埋められますが、照会の権限を持つのは職員で、照会の記録も職員の名前で残るべきものです。また、受託機関のシステムに基金側から自動で問い合わせる経路を作ると、委託の契約と監査の範囲が変わります。

下書きは受付台帳の別の列に書き、送る文面の列には書きません。 職員が下書きを写して直したものだけが、送る文面の列に入ります。

人が確認する

全件、担当職員と係長の2段階で確かめます。 AIの下書きをそのまま送る経路は作りません。

1. 区分を確かめる … decision_or_appeal と out_of_scope は、下書きを読む前に係長へ回します
2. 根拠を開く … basis の条を索引で開き、版と施行日が基準日に合っているかを見ます
3. 空欄を埋める … record_fields の項目を記録管理のシステムで照会し、値を書き入れます
4. 言い回しを確かめる … 支給の約束になっていないか、選択の助言になっていないかを読みます
5. 係長が確認して送る … 直した箇所は受付台帳に記録します

2番目を省かないでください。 施行日の絞り込みは、索引の日付が正しく入っていることが前提です。改正のときに失効日の入れ忘れがあると、旧い条と新しい条が両方引かれます。 職員が版を目で確かめる工程は、索引の誤りに気づく唯一の場所です。

目標は、1件あたりの職員の手を12分にすることです。 30分のうち、条文を探す12分と回答文の骨組みを書く時間が減ります。空欄の照会と言い回しの確認は残ります。

例外に対処する

6行目の「数字の検査」は、正規表現で足ります。 下書きの中の数字（年数、月数、金額、年齢）を拾い、basis の quote の中に同じ数字があるかを見ます。規約に「60歳」とあって下書きに「60歳」とあれば通し、規約に無い「月額3万2千円」があれば止めます。

7行目は、AIの出来とは関係なく人へ回します。 受給者が亡くなった知らせに、規約の条文を引いた定型の文面を返すのは、内容が正しくても失礼になります。

記録を残す

• 問い合わせの原文（伏せ字前）と、伏せ字後に AI へ渡した文
• 基準日と、そのときの検索の条件（施行日の絞り込み）、引かれた条の一覧
• Azure OpenAI の出力の JSON 全文と、数字・quote の検査の結果
• 職員が直した箇所の差分と、空欄に入れた値の照会日時
• 係長の確認の記録と、送った文面
• 区分ごとの件数と、人へ回した理由の件数

4つ目の差分がいちばん役に立ちます。 職員が毎回同じ書き換えをしている箇所は、プロンプトか確定済みの回答例を直すべき箇所です。月に一度、差分の多い区分を見て、回答例を足すか入れ替えます。

3つ目の検査の結果は、索引の傷みの指標にもなります。 quote が見つからない件数が増えたら、規約の改正が索引に反映されていないことを疑います。