社員から出る借上げ社宅の入居申請を、社宅規程の要件（距離・家賃の上限・家族構成）と物件の資料に照らして判定し、承認者向けの所見を付けて回す

処理の起点を決める

申請のリストに項目が作られたことを起点にします。 申請が出たその日に担当者の手元に下書きが届くので、異動の時期でも、申請から判定までの日数が延びません。 週に1回まとめて審査する形にはしません。物件は押さえておける期間が短く、待たせると申込が他の人に取られます。

添付が無い申請は、フローの最初で止めます。 募集図面が無いと、家賃と間取りを確かめる先がありません。申請者に Teams で「募集図面を添付してください」と返し、項目を「差戻し（添付不足）」にします。 添付が足されたら、担当者が手でフローを動かし直します。

住み替えの申請は、いまの社宅の契約とあわせて見ます。 申請の区分が「住み替え」なら、借上げの契約の台帳からいまの社宅の家賃と入居日を引き、住み替えの理由（家族の増加など）が規程の対象に当たるかを判定の対象に足します。

入力データを集める

質を決めるのは、規程の要件の表です。 Word の社宅規程をそのままAIに渡すと、附則や過去の改正の経過措置まで読んで、いまの上限と違う数字で判定することがあります。 規程を「要件・条件・上限・条文番号」の行に書き出し、いま有効な行だけを渡します。共益費を家賃に含めるか、駐車場代はどうかも、この表に1行ずつ書きます。 第3章の（b）の細部は、ここで決めます。

社員の情報は、続柄と人数だけを渡します。 扶養家族の氏名や生年月日は、判定に要りません。世帯区分を決めるのは、同居する家族の続柄と人数です。 子の年齢で間取りの目安が変わる規程なら、「未就学・小学生以上」のような区分だけを書き出します。

経路検索は、会社が指定した1つの方法にそろえてもらいます。 申請者ごとに違う地図のサービスや経路の条件で測ると、同じ物件でも距離が変わります。 指定の方法と条件（徒歩・公共交通・車）を申請の手引きに書き、その画面を添付してもらいます。

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

規程の要件の表は、地域で絞ってから渡します。 工場3か所と本社の4地域分を全部渡すと、別の地域の上限で判定することがあります。 Get items の Filter Query で、勤務先の地域と「有効」の行だけを取ります。

人事のシステムの情報は、毎晩の書き出しを SharePoint リストに置いておきます。 人事のシステムを直接つなぐ経路は作りません。判定に要る列だけを書き出すことで、AIに渡る範囲を最初から絞ります。 結婚・出産の直後で登録が追いついていない場合は、第7章の例外処理で扱います。

AIへ渡す前に整形する

1. 添付の確認 … 添付が1つ以上あるか、PDFか画像か、50ページ未満・合計25MB未満かを確かめます
2. 添付の種類の見分け … ファイル名ではなく、申請フォームの添付の欄（募集図面・経路検索）で区別します
3. 申請の数字の整え … 家賃・共益費・駐車場代・距離の欄の全角数字やカンマ、「万」「km」を、式で比べられる数値に直します
4. 世帯区分の仮決め … 同居予定の家族の人数から、単身・2人・3人以上の区分を式で決めます
5. 上限と範囲の取り出し … 世帯区分と地域で、規程の要件の表から上限と範囲の行を取ります
6. 重複の確認 … 同じ社員の申請が「審査中」で残っていないかを確かめます

3番目と4番目は AI に任せません。 申請の欄の数字はフローの式で数値に直し、世帯区分も人数から式で決めます。AIが読むのは添付の資料と文の要件で、申請の欄の数字はAIを通さずに比べます。 後で AIの読み取りと突き合わせるための、もう1本の筋です。

2番目でファイル名を使わないのは、申請者がファイル名を自由に付けるからです。

AIに処理させる

させるのは、添付の資料から物件の値を読み取り、規程の要件を1つずつ判定して、根拠を書くことです。 承認するかどうかの判断と、規程に無い事情の扱いはさせません。

右端の列の区別が、この構成でいちばん大事です。 not_met は規程の要件を満たしていないこと、needs_info は資料が足りず判定できないこと、not_in_rules は規程に書かれていない事情であることです。前者は差し戻すもの、中は資料を求めるもの、後者は担当者と課長が判断するものです。 混ぜると、介護のための親の同居のような事情を、機械的に「満たさない」として差し戻すことになります。

3行目がいちばん起きやすい失敗です。 申請に8万円、図面に8万8千円とあると、AIは申請者の記入を正として8万円で判定しがちです。判定には必ず図面の値を使い、申請との食い違いは mismatch として残させます。

指示内容を固定する

あなたは人事部で、借上げ社宅の入居申請を社宅規程に照らして確かめる担当です。
申請の内容、添付の資料（募集図面・経路検索の結果）、規程の要件の表だけを根拠に、
要件ごとに判定してください。推測で埋めないでください。

【判定する要件】規程の要件の表の行ごと（{rules}）

【status の選び方】
- met ........... 資料の値が要件を満たしている
- not_met ....... 資料の値が要件を満たしていない
- needs_info .... 資料に値が無い、または読み取れず判定できない
- not_in_rules .. 申請の事情が、規程の要件の表に書かれていない
迷ったときに met を選ばないでください。

【厳守事項】
- 家賃・共益費・駐車場代・間取り・面積・所在地は、募集図面から読み取った値で
  判定してください。申請の記入の値で判定しないでください。
- 申請の記入と図面の値が違うときは、両方を書き、mismatch を true にしてください。
- 家賃の合計は、規程の要件の表に書かれた扱い（共益費・駐車場代を含めるか）に
  従ってください。表に扱いが無い費目は合計に入れず、notes に書いてください。
- 距離は経路検索の結果の画面に書かれた値を写してください。地図から推し量らないでください。
- 規程の表に無い事由・続柄は not_in_rules にしてください。
  認めるべきかどうかを書かないでください。
- evidence には、根拠にした資料の文字列と、規程の条文番号を書いてください。
- 承認すべきかどうか、給与課税の扱いを書かないでください。
- 家族の健康や事情について、申請に書かれていないことを書かないでください。
- JSON のマークダウンを答えに含めないでください。

【申請】{application}
【世帯区分（フローで決めたもの）】{household_type}
【勤務先の地域】{region}
【添付】募集図面、経路検索の結果（文書の入力）

「迷ったときに met を選ばない」を明記しないと、資料が足りない要件が「満たす」になります。 図面に駐車場代の記載が無いとき、AIは「駐車場代は無い」と読んで合計を出しがちです。記載が無いことと、ゼロであることは違います。

「申請の記入で判定しない」を独立した行にしているのも同じ理由です。 申請と図面が違うとき、どちらを使うかを決めておかないと、AIは都合のよいほうを選び、食い違いが記録に残りません。 最後の一文は、JSON が作れないときの対処として公式の説明が挙げている一文です。

出力形式を固定する

次の形のJSONで受け取ります。 プロンプトの JSON の形式を Custom にして保存し、毎回この形で返るようにします。

{
  "application_id": "",
  "property": {
    "rent": 0, "common_fee": 0, "parking_fee": null,
    "layout": "", "area_m2": 0, "address": "",
    "distance_km": null
  },
  "mismatch": { "flag": false, "items": [ { "item": "", "application": "", "document": "" } ] },
  "checks": [
    { "rule_id": "", "status": "met | not_met | needs_info | not_in_rules",
      "value": "", "limit": "", "evidence": "" }
  ],
  "notes": "",
  "memo_draft": ""
}

1つ目の理由は、AIの値を式でもう一度比べられることです。 property の家賃・共益費・距離を、フローの式で規程の上限・範囲と比べ、checks の判定と食い違えば、その要件を needs_info に落として担当者に出します。 AIの判定と式の計算が両方「満たす」のときだけ、met として扱います。

2つ目は、null と 0 を分けられることです。 駐車場代が図面に書かれていなければ null、駐車場代なしと書かれていれば 0 です。null が残る要件は、担当者が申請者に確かめます。

3つ目は、所見を要件の表から組み立てられることです。 Approvals の詳細の欄に、checks をマークダウンの表にして出し、memo_draft を承認の文章の下書きにします。課長は表の色分けで、どの要件に人の判断が入ったかを読めます。

システムへ連携する

借上げの契約の台帳には書き込みません。 承認された申請をもとに、担当者が貸主との契約を進めてから台帳に載せます。 承認から契約までのあいだに物件が埋まることもあるので、承認と契約は別の工程にしておきます。

人事のシステムにも書き込みません。 社宅の入居が給与の控除に関わる場合も、給与の担当が別の手順で登録します。 この構成が出すのは、判定と所見までです。

人が確認する

人が見るのは、すべての申請です。 担当者が判定と所見の下書きを確かめ、課長が承認します。

1. 突き合わせ不一致と mismatch を先に見る … AIの判定と式の計算が合わない要件、申請と図面が食い違う項目を、図面で確かめます
2. needs_info を申請者に確かめる … 図面に駐車場代が無い、経路検索の画面から距離が読めない、などを申請者に聞きます
3. not_in_rules を判断する … 規程に無い事由・続柄を認めるかを、担当者が課長と相談します。認めた理由を所見に書きます
4. met の要件を図面で流し見る … 家賃と間取りの値が図面どおりかを確かめます
5. 所見を直して承認する … Approvals の画面で文章を直し、承認して課長に回します

3番目は、AIが関わらない判断です。 介護のための親の同居、障害のある家族のための広い間取り。規程に書かれていない事情を認めるかは、会社の方針で決めることです。 所見に理由を書いて残せば、次に同じ事情の申請が来たときの判断の材料になります。

目標は、60件をならして1件6分です。 すべての要件が met で食い違いの無い申請は数分で確かめられ、not_in_rules を含む申請は相談の時間がかかります。

例外に対処する

6行目は、給与課税の扱いに関わります。 国税庁のタックスアンサーでは、入居者が直接契約している場合の家賃負担は社宅の貸与とは認められず、給与として課税されるとされています。借上げ社宅として扱えるかどうかは、承認の前に担当者が確かめます。

記録を残す

• 申請の項目と添付（募集図面、経路検索の結果）
• AIが返した JSON と、そのときのプロンプトの版
• 判定に使った規程の要件の表の版（上限と範囲の値）
• 式の計算の結果と、AIの判定との突き合わせの結果
• 担当者が直した所見の最終版と、not_in_rules を認めた・認めなかった理由
• 課長の承認・却下と、その日時・コメント

3つ目で規程の表の版を残すのは、上限が改定されるからです。 家賃の上限は地域の相場に合わせて見直されます。改定前に承認した社宅が、改定後の上限を超えていても、当時の表が残っていれば問題がないと示せます。

5つ目の「認めた理由」は、規程の改定の材料にもなります。