経費精算の申請内容を社内規程と照合してチェックする

処理の起点を決める

申請が作成されたときを起点にします。経費精算システムがWebhookを提供していればそれを使い、なければ5分おきに新規申請をポーリングします。

上長承認の後ではなく、申請直後に動かすことが重要です。承認後にすると、申請者へのフィードバックが遅れ、この構成の主な効果（差し戻しの往復の削減）が失われます。

入力データを集める

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

社内規程の扱いが、この構成でもっとも重要な設計判断です。

規程のPDFをそのままAIに渡す方法（RAG）と、規程を構造化データに書き起こす方法があります。この用途では、書き起こしを推奨します。

書き起こしの例：

{
  "rule_id": "R-012",
  "category": "接待交際費",
  "condition": "社外の取引先を伴う飲食",
  "limit_per_person": 5000,
  "limit_unit": "1人1回",
  "required_fields": ["参加者氏名", "参加者の所属", "目的"],
  "required_attachment": ["領収書（但し書きに飲食の記載があるもの）"],
  "source_clause": "経費規程 第12条第2項",
  "exception": "役員が同席する場合は1人10,000円まで（第12条第3項）"
}

上限額の判定は、AIにさせずにプログラムで計算します。 「8,000円 > 5,000円」の判定にAIを使う理由はなく、確実性も落ちます。AIに任せるのは、「この目的の記載から、接待交際費と会議費のどちらが妥当か」といった、規則で書けない判断です。

領収書のOCR： Azure AI Document Intelligence には領収書向けのモデルがあり、店名、日付、合計金額、明細を抽出できます。適格請求書発行事業者の登録番号の抽出可否は、自社の領収書で実測してください。

AIへ渡す前に整形する

1. 領収書の向き補正 … スマートフォンで撮影した画像は傾いていることが多いため、補正します
2. 金額の突合 … 申請額とOCRで読んだ金額が一致するかを、AIを呼ぶ前にプログラムで判定します。ここが不一致なら、それだけで指摘対象です
3. 上限額の判定 … 構造化した規程データと照らして、金額上限をプログラムで判定します
4. 重複の検出 … 同一日・同一金額・同一店名の申請が既にないかを照合します
5. AIを呼ぶ対象の絞り込み … 上記1〜4で問題が見つからなかった申請のうち、判断が必要なもの（接待交際費、会議費、その他）だけをAIに回します。 交通費のようにルールで判定し切れる費目は、AIを呼びません

5が費用対効果に直結します。 月2,000件のうち、AIに渡すのは500件程度に絞れます。

AIに処理させる

規則で書けない判断だけを任せます。

指示内容を固定する

あなたは経費精算の内容を確認する担当者です。
以下の申請内容と社内規程を照らし、規程に反する可能性がある箇所を指摘してください。

【厳守事項】
- 指摘には必ず、根拠となる規程の条項番号を記載してください。
  条項を示せない指摘はしないでください。
- 承認・却下の判断はしないでください。指摘するだけです。
- 金額の上限判定は既に行われています。重複して指摘しないでください。
- 規程に定めのない事柄を、慣行や一般常識をもとに指摘しないでください。
- 申請者の意図を推測して、不正の疑いを断定しないでください。
  事実として観測できることだけを書いてください。
  （例：「私的利用と思われる」ではなく「参加者が社内のみで、
    日付が休日である」と事実を書く）
- 指摘がない場合は findings を空の配列で返してください。
  無理に指摘を作らないでください。

【社内規程（該当する費目の条項）】
{applicable_rules}

【申請内容】
費目: {category} / 金額: {amount} / 日付: {date} / 曜日: {weekday}
目的: {purpose} / 参加者: {participants}
申請者: {applicant_department} {applicant_title}

【領収書のOCR結果】
店名: {shop_name} / 日付: {receipt_date} / 金額: {receipt_amount}
但し書き: {description}

【当月の同費目の累計】
{monthly_total}

「申請者の意図を推測して、不正の疑いを断定しない」の1行が重要です。 これがないと、AIは「私的な飲食の可能性が高い」といった書き方をします。それが経理担当の目に触れ、従業員への疑念として伝わることは、労務上の問題になります。観測できる事実だけを書かせ、解釈は人がします。

出力形式を固定する

{
  "findings": [
    {
      "severity": "high | medium | low",
      "clause": "経費規程 第12条第2項",
      "observed": "",
      "issue": "",
      "suggested_action": ""
    }
  ],
  "category_suggestion": {
    "current": "",
    "suggested": "",
    "reason": ""
  },
  "needs_human_review": false
}

• observed … 観測した事実（「参加者3名のうち社外は0名」）
• issue … 規程に照らした問題（「第12条第2項の接待交際費は社外の取引先を伴う場合に限られる」）
• suggested_action … 申請者が取るべき行動（「費目を会議費に変更してください」）

suggested_action を返すことで、申請者は何を直せばよいかが分かります。「規程違反です」とだけ表示する構成にすると、申請者は結局経理に問い合わせるので、経理の工数が減りません。

システムへ連携する

申請者向け： 申請直後に、指摘内容をTeamsまたは申請画面に表示します。severity が high のものだけを出し、low は経理向けにのみ回します。申請者に細かい指摘を大量に見せると、読まれなくなります。

経理向け： 日次で、指摘のあった申請の一覧を生成します。severity 順に並べ、条項と観測事実を表示します。

経費精算システムへの書き戻し： システムがAPIを提供していれば、指摘内容をコメント欄に登録します。提供していない場合は、別途一覧を見る運用にします。この部分は利用環境に応じた個別確認が必要です。

人が確認する

「指摘なしを自動で通す」判断が、この構成の効果の大半を生みます。 ここを「念のため全件見る」運用にすると、削減効果はほぼゼロになります。

ただし、いきなり全面的に自動化しないでください。導入初月は全件を人が確認し、AIが「指摘なし」とした申請の中に、人が問題と判断するものが何件あるかを測ります。見逃し率が1%を下回ることを確認してから、自動通過に切り替えます。

また、金額が一定額（たとえば5万円）を超える申請は、指摘の有無にかかわらず人が確認する設計にします。

例外に対処する

記録を残す

この業務では、ログが監査対応の資料になります。

• 申請内容と領収書（経費精算システム側で保存）
• AIの指摘内容（条項、観測事実）
• 経理担当の判断（承認・差し戻し）と、AIの指摘と一致したか
• 「指摘なし」で自動通過した申請の一覧

最後の項目は、内部監査で「チェックを省略した根拠」を示す資料になります。自動通過の判定基準と、その適用件数を記録してください。