申請と承認のフローにAIを入れるなら、最初に手を付けるべきは「承認の自動化」ではなく差し戻し理由の整理です。誰が何を理由に差し戻したかを揃った形で蓄積し、分類できる状態にする。ここが先にできていれば、申請画面での事前チェックも、承認者の負担軽減も後から積み上がります。逆にここを飛ばして判定の自動化から入ると、精度の議論だけが長引き、現場の手戻りは何も変わりません。
この記事では、中小企業の経営者・システム担当者に向けて、申請承認フローにAIを組み込むときの範囲の決め方、差し戻し理由の分類の作り方、実装で詰まりやすい箇所を順に整理します。
差し戻しはなぜ減らないのか？
経費精算、稟議、休暇申請、発注依頼。どの申請でも差し戻しは起きますが、多くの会社でそれが減らない理由ははっきりしています。差し戻しの理由がデータとして残っていないからです。
典型的なのは次のような状態です。ワークフローシステムのコメント欄に「添付が足りません」「金額の内訳をお願いします」と自由文で書かれ、それ以上の構造を持たない。集計しようにも表記がばらばらで、「どの申請種別で、どの原因が、月に何件起きているか」が誰にも答えられない。結果として対策は「注意喚起のメール」に落ち着き、翌月も同じ差し戻しが繰り返されます。
AIが効くのはまさにここです。自由文のコメントを読み、あらかじめ決めた区分に当てはめ、集計可能な形に変える。これは生成AIが比較的得意とする分類の仕事で、しかも間違えても直接の損害が出にくい。間違えたときのコストが小さい領域から入るという点で、最初の一歩に向いています。
AIに任せるのはどこまでにするべき？
申請承認フローでAIが関われる場所は、大きく4つに分かれます。承認そのものの判断を任せるかどうかで、必要な検討の重さがまったく違います。
| 関わり方 | AIの役割 | 最終判断 | 着手のしやすさ |
|---|---|---|---|
| 差し戻し理由の分類 | 自由文コメントを区分に振り分ける | 人（集計の確認のみ） | 高い |
| 申請時の事前チェック | 不備の可能性を申請者に提示する | 申請者 | 中くらい |
| 承認者への要約提示 | 長文の稟議を論点ごとに要約する | 承認者 | 中くらい |
| 承認可否の自動判定 | 条件に合う申請を自動承認する | AI（例外のみ人） | 低い |
中小企業が最初に取り組むなら、上の2段です。承認可否の自動判定は、金額基準や職務権限規程との整合、内部統制上の説明責任が絡むため、設計の負荷が一段上がります。やるとしても「10万円未満かつ過去6か月に差し戻しのない申請者」のように、ルールで書ける範囲はルールで処理し、AIには判断させないのが安全です。
どこまで自動化し、どこから人に戻すかという線引きの考え方は、問い合わせAIの振り分けは「人に戻す条件」から決めるで扱った考え方がそのまま使えます。先に「人に戻す条件」を決めてから、残りを自動化の対象にする順序です。
差し戻し理由はどう分類する？
分類の区分は、AIに考えさせるのではなく人が先に決めます。区分が毎回変わると集計が成立しないためです。過去3か月分の差し戻しコメントを200件ほど目視で読み、出てきた理由を束ねていくと、たいていは次のような粒度に落ち着きます。
- 記入不備 — 必須項目の未入力、日付や取引先名の誤り
- 添付不足 — 領収書、見積書、仕様書の不足
- 金額・区分の誤り — 勘定科目の選択ミス、税区分、按分の誤り
- 社内ルール不適合 — 事前申請の漏れ、上限額の超過、職務権限の範囲外
- 内容への異議 — 必要性や時期そのものに承認者が同意しない
- その他・判別不能 — 上記に当てはまらない、または情報不足
重要なのは最後の「その他・判別不能」を必ず置くことです。無理にどれかへ押し込ませると、分類結果が実態からずれます。AIには迷ったら「判別不能」に入れてよいと明示し、その件数を定期的に人が見る運用にします。判別不能が全体の2割を超え続けるなら、区分の設計か、コメントの書かれ方のどちらかに問題があります。
分類指示そのものも、一度書いて終わりにせず版を管理してください。区分を1つ足しただけで既存の分類結果が変わることがあります。この扱い方はプロンプトは設定ではなく資産 — 「壊れたら戻せる」AI業務システムの作り方で整理した通りです。
実装で詰まるのはどこ？
受注開発の現場で、この種の仕組みが止まりやすい箇所は3つあります。
1つ目は、差し戻しコメントが構造化されていないこと。既存のワークフロー製品では、差し戻し操作とコメントが別テーブルだったり、コメントが承認履歴全体に混在していたりします。「どのコメントがどの差し戻しに対応するか」を特定できないと、分類する対象そのものが作れません。着手前にデータの持ち方を確認してください。
2つ目は、コメントが短すぎること。「NG」「再提出」としか書かれていない差し戻しは、AIでも人でも分類できません。この場合は、差し戻し画面に区分の選択肢を置き、人が1クリックで選ぶ形に変えるほうが早い。AIの出番は、選択肢に収まらない自由文が一定量あるときです。AIを入れる前に、入力の形を変えるだけで解決する場合があるという点は、見落とされがちです。
3つ目は、個人情報と取引先情報の扱い。申請の本文には、氏名、口座情報、取引先との交渉内容が含まれます。外部のAIサービスに送る場合、何を送って何を送らないかを先に決める必要があります。個人情報保護法に基づく社内の取扱規程と、委託先の管理の考え方は確認しておくべき点です。また経費精算まわりでは電子帳簿保存法の対象となる書類の保存要件があり、AIが要約や分類を行っても元の証憑そのものは所定の形で保存し続ける必要があります。
効果はどう測る？
「差し戻しが減った気がする」で終わらせないために、導入前に指標を決めておきます。最低限、次の3つです。
- 申請種別ごとの差し戻し率 — 月次。母数は提出件数
- 理由区分ごとの件数構成 — 月次。どの原因が主要かを見る
- 申請から最終承認までの日数 — 中央値で見る。平均は長期滞留に引きずられる
効果の出方は、申請の種類、現在の差し戻し率、申請者の人数によって大きく変わります。導入すれば何割削減できるといった一般的な数字は、自社の前提に当てはまるとは限りません。自社の3か月分の実測を基準線として先に取り、そこからの変化で判断するほうが確実です。
AIの分類精度そのものを測りたい場合は、人が分類した正解データを100件程度用意し、定期的に照合します。この進め方はAI の「良くなった気がする」を卒業する — 評価データセットの作り方と運用で詳しく扱っています。
まとめ
申請承認フローへのAI導入は、承認の自動化から入ると検討が重くなり、現場の実感も出にくくなります。先に差し戻し理由を分類可能な形にし、どの原因が多いかを数字で見える状態にする。そこまで進めば、申請画面での事前チェックの追加、様式の見直し、規程の説明の改善といった打ち手が、推測ではなく実データから選べるようになります。
検討を始めるなら、過去3か月の差し戻しコメントを抽出できるか、1件ごとに申請種別と紐づけられるかの2点を確認するところからです。ここが確認できれば、設計の議論は具体的に進みます。