社員の住所変更届・通勤経路の申請を、申請された経路と運賃・規程の上限と照らして確認し、通勤手当の変更が要るものと確認が要る点を人事へ返す

処理の起点を決める

Forms に申請が送信されたことを起点にします。 Microsoft Forms コネクタのトリガー「新しい応答が送信されたとき」で受け、「応答の詳細を取得する」で回答の中身を取ります。公式ドキュメントでは、このコネクタは組織のアカウントでのみ機能するとされています。

グループで作ったフォームは、トリガーのドロップダウンに出ません。 公式ドキュメントでは、グループ フォームをトリガーするには、フォームを編集するときのアドレス バーの「FormId=」の後の部分を、フォーム ID に手で貼る必要があるとされています。人事部のチームで管理しているフォームなら、最初にここでつまずきます。

月末に申請をまとめて確かめる形にはしません。 変更の日が月の途中の申請は、給与の締めまでに承認が終わっている必要があります。届いた時点で確かめ、確認が要るものを早く本人に返すほうが、往復の時間が取れます。

入力データを集める

質を決めるのは、3行目の規程の条件です。 規程の文のままでは、フローの規則に使えません。「最安との差が月3,000円以内なら、所要時間が15分以上短い経路を認める」「乗換が2回以上少ない場合は認める」のように、数字で書けるものは数字にします。 数字にできない例外（育児・介護・障がいなどの事情）は、文のまま持ち、生成AIへ渡します。

Forms の作りも、入力の質を左右します。 経路を1つの自由記述の欄で受けると、「JR で◯◯まで、そこから地下鉄」のような書き方が混ざります。乗る駅、乗換の駅（3つまで）、降りる駅を別々の欄にし、交通手段は選択肢にします。 それでも自由記述の書き方は残るので、生成AIでそろえる処理は外しません。

1行目の住所は、市区町村までしか持ちません。 経路を探すのに要るのは最寄りの駅で、番地は要りません。番地まで含んだ住所は、給与システムの住所の届出として別に扱い、このフローには流しません。

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

申請はトリガーと「応答の詳細を取得する」で受け、勤務地の駅と規程の条件は SharePoint のリストから引きます。探索の結果は、駅すぱあと API を HTTP のアクションで呼んで取ります。 API キーは、フローの中に直接書かず、管理された場所に置きます。

申請の経路の探索では、乗換の駅を viaList の経由地に入れます。 経由地を入れずに出発地と目的地だけで探すと、申請とは別の経路の運賃が返り、比べる意味がなくなります。 経由地を入れても申請の経路と違う路線で返ることがあるので、返ってきた経路の駅の並びが申請と一致するかを、フローで確かめます。

探索の日付（date）は、変更の日にします。 運賃の改定をまたぐ申請で、今日の運賃と変更の日の運賃が違うことがあるからです。

IC カードの運賃で比べるかどうかも、探索の条件で決めておきます。 公式ドキュメントでは、conditionDetail で IC の運賃や交通の種類、座席の区分などの細かな探索の条件を指定できるとされています。社員が経路探索のサイトで調べた条件と、フローの探索の条件が違えば、金額はずれて当然です。 Forms の入力の説明に、どの条件で調べてほしいかを書いておきます。

AIへ渡す前に整形する

1. 必須の欄の確認 … 最寄りの駅、経路、定期代、変更の日が空でないかを確かめます。空なら本人へすぐ差し戻します
2. 経路の書き方をそろえる … 「JR → 地下鉄 → バス」のような書き方を、駅の並びにそろえます（次の小見出し）
3. 駅名の照合 … そろえた駅名が探索で見つかるかを確かめます。見つからない駅名は「駅名の確認が要る」とします
4. 交通手段の分け方 … マイカー・自転車を併用する申請は、電車・バスの区間だけを探索にかけ、マイカーの区間は人の確認に回します
5. 変更の日の確認 … 給与の締めの日と比べ、締めを過ぎた変更の日なら、さかのぼっての支給になることを記録に付けます

4番目でマイカーの区間を人に回すのは、課税されない上限の計算が違うからです。 国税庁のタックスアンサーでは、交通機関とマイカー・自転車を併せて使う場合は、交通機関の定期代などと、マイカー・自転車の片道の距離などに応じた額を合計した金額（1か月15万円が限度）とされ、後者は別のコードで説明されています。この構成では、電車・バスの区間だけを確かめます。

AIに処理させる

生成AIの仕事は2つです。 申請の経路の書き方を駅の並びにそろえることと、最安でない経路の理由が規程の例外に当たりそうかを読むことです。運賃の比較と上限の判定は、フローの規則で行います。

規則の判定は、次の順で行います。

理由の判定に渡す例外の条件は、次のような文で持ちます。 コードを付けておくと、生成AIの candidate と担当の判断を後から突き合わせられます。

月100円の差は、本記事のモデル条件です。 IC カードの運賃ときっぷの運賃の違いや、端数の扱いで小さな差が出ます。差の許し幅は、最初の1か月の結果を見て決めます。

指示内容を固定する

プロンプト1（経路の整形）は、次の指示です。

あなたは人事部で、社員が書いた通勤経路を、経路探索に入れる駅の並びにそろえる立場です。
渡された申請の経路の文だけを読み、乗る駅、乗換の駅、降りる駅を順に並べてください。

【厳守事項】
- 書かれていない乗換の駅を補わないでください。
- 駅名は書かれたとおりに写し、正式名に直せる場合だけ official_name に書いてください。
  直せるか分からない場合は空にしてください。
- バスの区間は、乗るバス停と降りるバス停を書き、mode を bus にしてください。
- 徒歩・自転車・マイカーの区間は mode に書き、駅の並びに入れないでください。
- 経路が読み取れない場合は、stops を空にして unreadable を true にしてください。
- 回答に JSON マークダウンを含めないでください。

【申請の経路】{route_text}
【最寄りの駅・バス停】{home_station}
【勤務地の駅】{work_station}

プロンプト2（理由の判定）は、次の指示です。

あなたは人事部で、通勤手当の申請のうち、最も安い経路ではない経路を申請したものについて、
理由が規程の例外の条件に当たりそうかを確かめる立場です。

【渡す情報】
- 規程の例外の条件の一覧（コードと文）
- 申請の経路と、最も安い経路の定期代・所要時間・乗換の回数（探索の結果）
- 申請の理由の欄の文

【させること】
1. 理由の文が、例外の条件のどれに当たりそうかを candidate に書いてください。
   当たりそうなものが無ければ none にしてください。
2. その判断の根拠にした文を、理由の欄からそのまま写してください。
3. 人事が本人に確かめるべき点を、質問の形で1〜3個書いてください。

【厳守事項】
- 例外を認めるかどうかを書かないでください。「当たりそう」までにしてください。
- 支給額を書かないでください。
- 理由の欄に書かれていない事情を推測しないでください。
- 育児・介護・健康の事情が書かれていても、その内容を詳しく書き写さないでください。
  「事情の記載あり（育児）」のように区分だけを書いてください。
- 回答に JSON マークダウンを含めないでください。

「事情の内容を書き写さない」を明記するのは、承認の依頼が人事の複数の担当に回るからです。 健康や家族の事情は、申請した本人と、例外を判断する担当者だけが知っていればよい情報です。承認の依頼の一覧には区分だけを出し、詳細は申請の原文で見ます。

「当たりそう」で止めさせるのは、例外の判断が規程の運用だからです。 生成AIに「認める」と書かせると、担当者がその言葉に引っ張られて承認することが起きます。

出力形式を固定する

プロンプトの出力は、JSON のカスタム形式で固定します。 公式ドキュメントでは、JSON の例を更新すると形式がカスタムになり、プロンプトを保存すると形式がロックされるとされています。フローの最後に、規則の結果と合わせて次の形の記録を作ります。

{
  "request_id": "F-20261007-0118",
  "employee_no": "S048213",
  "effective_date": "2026-11-01",
  "route": {
    "stops": [ { "name": "◯◯", "mode": "rail" }, { "name": "△△", "mode": "rail" } ],
    "unreadable": false
  },
  "fare": { "requested": 12340, "searched": 12340, "cheapest": 10980, "fastest_min": 38 },
  "checks": [
    { "rule": "fare_mismatch", "result": "ok" },
    { "rule": "cheapest_gap", "result": "reason_review" },
    { "rule": "company_limit", "result": "ok" },
    { "rule": "tax_free_limit", "result": "ok" }
  ],
  "reason_review": { "candidate": "E02", "evidence": [ { "text": "" } ], "questions": [ { "q": "" } ] },
  "verdict": "needs_check"
}

1つ目の理由は、規則の結果と生成AIの結果を別の欄に置けることです。 checks はフローの規則が埋め、reason_review だけを生成AIが埋めます。規程の条件が変わっても、直すのは規則だけです。

2つ目は、evidence と questions を、フィールド キーの付いたオブジェクトの配列にすることです。 公式ドキュメントでは、フィールド キーの無い配列（["abc", "def"]）はサポートされないとされています。

verdict は、approve（変更が要り、そのまま承認できる）、needs_check（確認が要る）、no_change（変更が要らない）の3つです。verdict は規則で決め、生成AIには書かせません。

システムへ連携する

承認の依頼には、verdict と確認の点だけを出します。 公式ドキュメントでは、プロンプトの出力のあとに承認のアクションを置き、レビュー担当者が生成されたテキストを確かめて必要に応じて編集できるとされています。本人への問い合わせ文は、確認の点をもとに担当が書き、送るのも担当です。

人が確認する

人が見るのは、needs_check の申請の確認の点だけです。 approve と no_change は、一覧で社員番号と金額を見て承認します。

1. fare_mismatch を先に見る … 申請の金額と探索の金額が違うもの。多くは IC とキップの違いか、経路の書き方の違いです
2. reason_review を読む … 生成AIの candidate と questions を参考に、例外を認めるかを担当が決めます
3. 上限を超えるものは、規程の運用の担当者に回す … 月5万円を超える申請、15万円を超える申請は、課税の扱いも含めて責任者が決めます
4. 判断を記録する … 例外を認めたか、認めなかったか、その理由を残します

4番目の記録が、第3章の（c）への答えです。 例外を認めた理由がたまると、同じ理由の申請に同じ判断をしているかを後から確かめられます。

例外に対処する

2行目の「近い駅名に置き換えない」が、いちばん守るべき線です。 同じ名前の駅が別の路線や別の地方にあることがあります。置き換えた駅で探索すると、もっともらしい運賃が返り、誰も気づきません。

記録を残す

• 申請の原文と、整形した駅の並び
• 駅すぱあと API に渡した条件（viaList・date・sort）と、返ってきた定期代・所要時間
• 規則の判定の結果と、そのときの規程の条件の版
• 生成AIの reason_review と、担当が例外を認めたか・その理由
• 承認した人と日時、給与システムに入れた日

規程の条件の版を残すのは、規程が改定されると過去の判定の意味が変わるためです。 月の上限を変えた月の前後で、同じ金額の申請の結果が違っても、版が残っていれば説明がつきます。