社員の出張の事前申請を Power Automate で受け、旅費規程の日当・宿泊の上限・交通の手段に照らして確認が要る点を挙げてから承認に回す

処理の起点を決める

フォームの回答が送信されたことを起点にします。 When a new response is submitted は送信ごとに動くので、出張の直前に出された申請も、その場で確認点が付いて承認に回ります。 1日1回の定時実行にはしません。翌日の出張の申請が、翌朝の処理では間に合わないからです。

出発日が近い申請は、急ぎの印を付けます。 出発日が送信の翌稼働日以内なら、承認の題名の先頭に【急ぎ】を付け、経理部の担当には Teams でも知らせます。規程の確認は省きません。 急ぎの申請ほど前泊やタクシーの理由が書かれていないことが多いからです。

同じ出張の申請が二重に出ることがあります。 申請者が日程を直して出し直したときです。台帳に、同じ申請者・同じ出張先・同じ出発日の行が直近7日以内にあれば、新しい申請を「差し替えの可能性」として扱い、経理部の担当に前の申請を取り消すかを確かめてもらいます。

入力データを集める

質を決めるのは、条文の要件のリストです。 条文だけを渡すと、「所要時間が大きく短くなる場合」の「大きく」をAIが自分の感覚で読みます。「足りる記述の例：新幹線と在来線の乗継ぎで片道5時間、航空機で2時間半」「足りない記述の例：時間短縮のため」のように、経理部が通してきた判断を例として書きます。 第3章の（b）の担当ごとのぶれは、ここで止めます。

過去の確認の記録は、同じ聞き返しを繰り返さないために渡します。 毎月同じ現場へ航空機で行く技術者に、毎回同じ理由を聞き返すのは無駄です。以前に経理が通した理由と同じ内容なら、根拠にその記録を挙げて met にできるようにします。

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

条文の要件は、当たった項目だけを渡します。 グリーン車の区間が無い申請に、グリーン車の条文を渡す必要はありません。渡す条文が少ないほど、関係の無い条文を根拠に挙げる誤りが減ります。

等級は申請の欄からではなく、社員の一覧から引きます。 申請者に等級を選ばせると、選び間違いがそのまま上限の計算に入ります。本人が書いた値と一覧の値が違えば、一覧の値で計算し、違いを確認点に載せます。

AIへ渡す前に整形する

1. 日当の計算 … 出発と帰着の日時から日帰りか宿泊かと日数を出し、等級の日当を掛けます。計算はフローの式で行い、AIに渡しません
2. 宿泊の上限の比較 … 宿泊地を地域の区分の一覧で区分に置き換え、等級×区分の上限と1泊の見込み額を比べます。区分に置き換えられない宿泊地は確認点にします
3. 条文の要件が当たる項目の洗い出し … 座席の区分がグリーン車の区間、手段が航空機・タクシーの区間、出発日の前日の宿泊（前泊）、用務の翌日の宿泊（後泊）、日程に土日・祝日をはさむもの、を拾います
4. 理由の欄の空の確認 … 当たった項目があるのに、前泊・後泊の理由とその他の理由の欄がどちらも空なら、AIに渡さずに not_stated として確認点にします
5. 金額の形の確認 … 見込み額が数字でない、0円、極端に大きい（規程の上限の3倍超など）ものは「値の確認」の印を付けます。AIに直させません
6. 個人名の扱い … 申請者の氏名と訪問先の担当者名はプロンプトに渡しません。訪問先は会社名だけを渡します

1番目と2番目をAIの外に置くのが、いちばん大事です。 金額の比較をAIにさせると、表の読み違いや桁の取り違えが起きたときに気づけません。フローの式なら、同じ入力には必ず同じ答えが出ます。

AIに処理させる

させるのは、前処理で当たった項目ごとに、申請の理由の文に条文の要件を満たす記述があるかを判定し、根拠の文と、足りないときの聞き返しの文案を書くことです。

not_stated と insufficient を分けるのが要です。 前者は理由が何も書かれていないこと、後者は書かれているが要件に届かないことです。聞き返す中身が違います。 前者には「理由を書いてください」、後者には「始発の時刻と用務の開始時刻を書いてください」と、足りない要素を名指しして聞き返せます。

最後の行が、いちばん起きやすい失敗です。 前泊の申請で用務の開始時刻が書かれていないと、AIは「訪問先が遠方のため、早朝の用務と考えられる」と補って met にします。補った瞬間、聞き返すべき点が消えます。

指示内容を固定する

あなたは商社の経理部で、出張の事前申請を旅費規程に照らして確かめる立場です。
申請に書かれていることだけを使って判定してください。推測で補わないでください。

【判定する項目】
下の「確認する項目」に挙がったものだけを判定してください。
挙がっていない項目について書かないでください。

【status の選び方】
- met .......... 条文の要件を満たす記述が申請にある
- insufficient . 理由は書かれているが、要件を満たすのに必要な要素が足りない
- not_stated ... 理由が書かれていない
- ambiguous .... 記述が要件に当たるとも当たらないとも読める
迷ったときに met を選ばないでください。

【厳守事項】
- 条文の要件と「足りる記述の例」「足りない記述の例」に照らして判定してください。
- 申請に書かれていない事情を補わないでください。
  「遠方のため早朝と考えられる」のように推し量って met にしないでください。
- 用務の開始・終了の時刻、乗車時間、距離が書かれていなければ、
  それを「書かれていない」として扱ってください。
- 過去の確認の記録に、同じ区間・同じ理由で通したものがあれば、
  その記録番号を evidence に書いて met にしてかまいません。
  理由が違う場合は使わないでください。
- evidence には、判定の根拠にした申請の文か記録番号をそのまま写してください。
- insufficient と not_stated のときは、申請者への聞き返しの文案を
  question に書いてください。足りない要素を名指しし、1〜2文にしてください。
- 金額、日当、宿泊の上限について書かないでください。
- 出張を認めるべきか、規程の例外にすべきかを書かないでください。
- Don't include JSON markdown in your answer.

【確認する項目】{target_items}
【条文の要件】{rule_clauses}
【申請】出張先：{destination}／用務：{purpose}／訪問先：{visit_company}
　　　　出発：{depart_at}／帰着：{return_at}
　　　　区間：{segments}
　　　　宿泊：{lodging}
　　　　前泊・後泊の理由：{stay_reason}
　　　　その他の理由：{other_reason}
【過去の確認の記録】{past_approvals}

「挙がっていない項目について書かない」を最初に置きます。 何も言わないと、申請の全体を見て「宿泊費がやや高い」のような所見を足してきます。金額の比較はフローが済ませているので、AIの所見と食い違うと承認者が迷います。

「推し量って met にしない」を例文付きで書くのは、それがいちばん自然に出る誤りだからです。 禁止の言葉だけだと「推測ではなく一般的な事情として」と言い換えて補います。具体的な言い回しを挙げて禁じます。

最後の英文の1行は、公式の案内に合わせたものです。 JSON が作れないというエラーが出るとき、この一文を足すよう案内されています。

出力形式を固定する

次の形のJSONで受け取ります。 AI Builder のプロンプトの出力を JSON にし、例を書き換えて Custom の形に固定します。

{
  "checks": [
    {
      "item": "green_car | airplane | taxi | pre_stay | post_stay | holiday_schedule",
      "segment_no": "",
      "status": "met | insufficient | not_stated | ambiguous",
      "clause_no": "",
      "evidence": "",
      "question": ""
    }
  ]
}

キーの付いた要素の配列にしているのは、公式の制約に合わせたものです。 JSON の形は、キーの無い配列（["abc", "def"] のような形）を定義できないとされています。項目ごとに item を持たせた要素の配列にします。

JSON にする理由の1つ目は、clear と check を規則で決められることです。

2つ目は、承認の詳細欄に並べ替えて載せられることです。 check の申請は、経理部の担当への承認の詳細欄に、上限の比較の表と、checks を status の重い順に並べた箇条書きを Markdown で載せます。question は「申請者へ聞き返す」を選んだときのメールの下書きに使います。

3つ目は、項目ごとの結果を後から数えられることです。 どの項目が insufficient になりやすいかを月ごとに数えると、申請フォームのどこに入力欄を足せばよいかが分かります。前泊が多ければ「用務の開始時刻」の欄を足します。

システムへ連携する

承認は2段にします。 check の申請は、まず経理部の担当に「通す／申請者へ聞き返す」を選んでもらい、通したものだけを上長へ回します。上長の承認の詳細欄には、計算の結果と「確認点なし」または「経理部確認済み：確認点と結論」の要約を載せます。 上長は規程の照合をやり直さず、出張の要否だけを判断します。

承認の通知の送り元に注意します。 公式の説明では、承認のメールは標準のメールアカウントから送られ、自分で送ったリンク付きのメールからは承認できないとされています。また、承認者の詳細にはフローの作成者が常に表示されるので、経理部の共用アカウントでフローを作ります。担当者個人のアカウントで作ると、その人の名前が全社の承認に出続けます。

経費精算システムには書き込みません。 事前申請の結果は台帳に残し、精算の段で経理部が参照します。精算システムとつなぐのは、この構成が安定してからの別の話です。

人が確認する

人が見るのは、次の3つの場面です。

1. 経理部の担当が check の申請を開いたとき … 確認点と根拠の文を読み、通すか、申請者へ聞き返すかを決めます。 聞き返すときは question の下書きを直して送ります
2. 上限を超える見込み額がある申請 … 例外として認めるかを経理部長が決めます。AIの判定とは別に、金額の表だけで判断します
3. 上長の承認 … 出張の要否を判断します。規程の照合は経理部の結論を信じます

clear の申請は経理部が開きません。 その代わり、毎週20件を無作為に選んで経理部の担当が読み直し、 met の判定が経理部の判断と合っているかを確かめます。合わない項目は、条文の要件のリストの「足りない記述の例」に戻します。

目標は、480件をならして1件2.5分です。 clear の申請は上長に回るだけで経理部の手は動かず、check の申請は確認点を読んで判断するので数分かかります。check が全体の3〜4割という想定でならすと2.5分です。 抜き取りの読み直しもここに含みます。

例外に対処する

上の4行が大半を占めます。 どれもAIの問題ではなく、申請フォームの入力欄と社員の一覧の整い方の問題です。理由の欄が空の申請が多ければ、フォームの側で当たる項目があるときに理由を必須にするほうが効きます。

記録を残す

• フォームの回答ID、申請の原文、受け取った時刻
• 日当と宿泊の上限の計算に使った等級・地域の区分・規程の表の版、計算の結果
• 前処理で当たった項目と、AIに渡した条文の要件の版
• AIが返したJSONの全文と、clear ／ check の判定
• 経理部の担当の選択（通す／聞き返す）と、聞き返しの内容と返事
• 上長の承認の結果、承認者、日時
• 抜き取りで読み直した申請と、判定が合わなかった項目

2つ目と3つ目で版を残すのは、規程が改定されるからです。 日当や宿泊の上限は数年ごとに見直され、改定の前後をまたぐ申請を後から見たとき、どちらの表で計算したかが残っていないと、精算の段の照合ができません。

5つ目は、条文の要件のリストを育てる材料です。 経理部の担当が「通す」とした insufficient は、例が厳しすぎる印です。「聞き返す」とした met は、例が甘すぎる印です。