【Dify】稟議書チェックを自動化する方法|決裁権限表とAIで差戻し削減

この記事は約11分で読めます。

稟議書が回ってくるたびに、金額と決裁区分が合っているか、見積書は添付されているか、予算内かを目で確認していませんか。年末は来期予算の策定と並行して駆け込みの稟議が増え、管理部門の確認作業が滞りがちです。記載漏れによる差戻しが何往復も続くと、起票者の不満も高まります。

この記事では、ノーコードのAIアプリ開発基盤「Dify」を使い、稟議書の形式チェックと決裁ルートの判定をAIに一次対応させるワークフローの作り方を解説します。ノード構成、設定手順、コピペで使えるプロンプト、内部統制上の注意点までをまとめました。対象読者は、稟議の事前確認を担う経理・総務・経営企画の担当者と管理職です。

この記事の要点

  • Difyの稟議チェックは、記載漏れ・添付漏れ・決裁区分の誤りをAIと条件分岐で一次判定し、人の承認前に差戻し案を作る仕組みです。
  • 決裁者の判定は金額と区分による機械的なルールなので、LLMではなくDifyのコード実行ノードで決め打ちにするのが安全です。
  • Difyではv1.13.0でHuman Inputノードが追加され、AIの判定結果を管理部門がメールで確認してから差戻しを送る運用が組めます。
  • AIの判定はあくまで事前確認であり、決裁そのものは職務権限規程に定めた承認者が行うことを社内ルールに明記する必要があります。
スポンサーリンク

Difyで稟議書チェックを自動化するとは?

Difyで稟議書チェックを自動化するとは、起票された稟議の内容をLLMと条件分岐で事前点検し、不備があれば差戻し文案を、問題がなければ決裁ルート案を管理部門に提示する仕組みを作ることです。Difyとは、プロンプト・ナレッジ検索・条件分岐などのノードをつなげて、AIを使った業務アプリをノーコードで構築できるオープンソースの基盤です。

稟議書チェックの作業は、大きく「形式面の確認」と「判断を伴う確認」に分かれます。形式面とは、必須項目の記入、見積書の添付、金額と税区分の整合、決裁区分の選択といった、ルールに照らせば正誤が決まる項目です。判断を伴う確認とは、投資の妥当性や相見積もりの要否など、規程の解釈や事業判断が必要な項目です。

Difyのワークフローで自動化しやすいのは前者の形式面です。後者についても、社内規程をナレッジとして登録すれば「規程上この点の確認が必要です」という論点の提示まではAIに任せられます。最終判断を人に残したまま、確認の抜け漏れと往復の回数を減らすのが現実的なゴールです。

稟議チェックでAIに任せる範囲と人が判断する範囲

稟議チェックでAIに任せるべき範囲は「規程に照らして機械的に判定できる項目」と「規程の該当箇所の提示」までで、承認可否の判断は人が担うべきです。役割分担を先に決めておくと、プロンプト設計と社内説明の両方がぶれにくくなります。

確認項目 担当 Difyでの実装
必須項目の記入漏れ AI(自動) 開始ノードの必須設定とLLMの抽出
見積書・契約書案の添付有無 AI(自動) ファイル入力の有無をIF/ELSEで判定
金額に応じた決裁者の判定 ルール(自動) コード実行ノードで閾値判定
税抜・税込の記載ゆれ、見積書との金額差 AI(自動) LLMで見積書の金額を読み取り照合
相見積もり・随意契約理由の要否 AI(論点提示)+人 ナレッジ検索で購買規程を参照
予算残高との整合 人(またはAPI連携) 予算管理表をHTTPリクエストで取得
投資の妥当性・承認可否 人 Human Inputノードで管理部門が確認

公認会計士・管理部門責任者の視点で特に重要なのは、決裁者の判定をLLMに推論させないことです。職務権限規程の金額基準は内部統制上の統制活動そのものであり、同じ入力に対して毎回同じ結果が出る仕組みでなければ監査で説明できません。LLMは文章の読み取りや論点整理に使い、閾値判定はコードで固定するという切り分けが、J-SOX(財務報告に係る内部統制報告制度)対応の観点からも説明しやすい設計です。

また、会社法第362条第4項では、重要な財産の処分や多額の借財などは取締役会で決定すべき事項とされています。社内の決裁権限表で「取締役会付議」となる区分がある場合は、AIの判定結果に関わらず必ず付議の要否を人が確認するフローにしておきます。

Difyの稟議チェックワークフローの構成(ノード一覧)

Difyの稟議チェックワークフローは、入力受付、情報抽出、規程参照、決裁者判定、AI判定、人の確認、通知の7段階で構成できます。以下は「ワークフロー」型アプリで組む場合のノード構成例です。

  1. 開始ノード:件名、申請部署、取引先名、金額(税抜)、支出区分(購買・業務委託・広告・設備投資など)、目的、予算科目を入力項目にし、見積書をファイル入力で受け付ける
  2. ドキュメント抽出ノード:添付された見積書PDFからテキストを取り出す
  3. 知識検索ノード:職務権限規程・購買規程・稟議規程を登録したナレッジから、支出区分に関係する条文を検索する
  4. コード実行ノード:金額と支出区分から決裁者と必要書類を決定する
  5. LLMノード:申請内容・見積書テキスト・規程の条文・決裁者判定結果を渡し、不備の有無と差戻し文案をJSON形式で出力させる
  6. IF/ELSEノード:不備ありなら差戻しルート、不備なしなら承認申請ルートに分岐する
  7. Human Inputノード:管理部門の担当者にメールで判定結果を送り、「差戻し送信」「修正して送信」「承認ルートへ」のいずれかを選んでもらう
  8. 終了ノード・通知:選択結果に応じて起票者へ差戻し文、または承認者への回付案を出力する

Human Inputノードとは、ワークフローを一時停止して人に確認や修正を求め、押されたボタンによって次の経路を分けられるDifyのノードです。Dify公式ドキュメントによると、配信方法はWebアプリとメールがあり、メールの受信者はDifyのアカウントを持っていなくても回答できます。応答がない場合の既定のタイムアウトは3日で、タイムアウト用の分岐をつなげば催促通知も組めます。

Difyで稟議チェックを設定する手順

Difyで稟議チェックを設定する手順は、規程のナレッジ登録、決裁権限表のコード化、ワークフロー構築、テスト、本番公開の順に進めるのが効率的です。最初から全支出区分を対象にせず、件数の多い「購買」区分だけで試すと検証が楽になります。

  1. 規程類をナレッジに登録する:職務権限規程、稟議規程、購買規程をテキストまたはPDFでアップロードします。条文単位で検索されるよう、条ごとに見出しを付けたテキストに整形してから登録すると精度が上がります。
  2. 決裁権限表を一覧化する:支出区分ごとの金額帯と決裁者、必要書類を表にまとめます。この表がコード実行ノードの元データになります。
  3. ワークフローアプリを新規作成する:Difyのスタジオで「ワークフロー」を選び、開始ノードに入力項目を設定します。金額は数値型、支出区分は選択式にして表記ゆれを防ぎます。
  4. ノードを上記の順に配置して変数をつなぐ:LLMノードの出力はJSON形式に固定し、後続のIF/ELSEノードで「不備あり」フラグを判定できるようにします。
  5. Human Inputノードの受信者を設定する:管理部門の担当者のメールアドレスを登録し、ボタンと差戻し文の編集欄を用意します。
  6. 過去の稟議でテストする:実際に差戻しになった稟議と、問題なく通った稟議を10件ずつ程度用意し、判定結果が人の判断と一致するかを確認します。
  7. 試行運用から本番へ移行する:最初の1〜2か月は従来の目視確認と並行して運用し、見逃しや誤検知の傾向を記録してから切り替えます。

決裁者判定のコード例(コード実行ノード)

決裁者判定は、Difyのコード実行ノード(Python)で次のように固定します。金額基準は架空の例なので、自社の職務権限規程に合わせて書き換えてください。

def main(amount: int, category: str) -> dict:
    # 金額は税抜。基準は自社の職務権限規程に合わせて変更する
    if category == "設備投資" and amount >= 50000000:
        approver = "取締役会(付議要否を確認)"
    elif amount >= 10000000:
        approver = "社長"
    elif amount >= 3000000:
        approver = "担当役員"
    elif amount >= 500000:
        approver = "部長"
    else:
        approver = "課長"
    need_quotes = 2 if amount >= 1000000 else 1
    return {"approver": approver, "need_quotes": need_quotes}

稟議チェック用プロンプト例(LLMノード)

LLMノードには、判定基準と出力形式を明示したシステムプロンプトを設定します。そのままコピーして、項目名を自社の稟議書様式に合わせて調整してください。

あなたは管理部門の稟議事前チェック担当です。
以下の申請内容・見積書テキスト・社内規程の条文をもとに、
形式面の不備だけを判定してください。承認可否の判断はしないでください。

# 確認項目
1. 必須項目(件名・目的・取引先・金額・予算科目)の記入漏れ
2. 申請金額と見積書金額の一致(税抜・税込の取り違えを含む)
3. 必要な見積書の枚数(必要数:{{need_quotes}})を満たしているか
4. 規程の条文に照らして追加で必要な書類や理由の記載
5. 目的欄が第三者に伝わる具体性を持っているか

# ルール
- 根拠とした規程は条番号を必ず示す
- 規程に記載がない事項は「規程に記載なし」と書き、推測で補わない
- 差戻し文は起票者向けに丁寧語で200字以内

# 出力形式(JSONのみ)
{"has_issue": true/false,
 "issues": [{"item": "", "reason": "", "rule": ""}],
 "return_message": "",
 "approver": "{{approver}}"}

Difyで稟議チェックを導入するときの注意点・リスク

Difyで稟議チェックを導入するときは、情報漏えい、AIの誤判定、権限設計、規程との整合の4点を事前に整理しておく必要があります。稟議書には取引条件や人事情報など機密性の高い内容が含まれるため、一般的なチャット利用よりも厳格な管理が求められます。

  • データの保存先:Difyのクラウド版を使う場合、入力内容と添付ファイルがDifyと利用するLLM事業者のサーバーで処理されます。M&Aや人事異動を含む稟議は対象外にするか、セルフホスト版での運用を検討します。
  • ハルシネーション(AIがもっともらしい誤りを出力する現象):AIが規程にない条件を作り出す可能性があります。プロンプトで条番号の明示を義務付け、根拠のない指摘はHuman Inputノードの段階で担当者が削除します。
  • アクセス権限:ワークフローの編集権限は管理部門の限られたメンバーに絞ります。決裁基準のコードを誰でも変更できる状態は、統制の無効化につながります。
  • 規程改定との同期:職務権限規程を改定したら、ナレッジとコード実行ノードの両方を更新します。更新日と更新者を変更履歴として残すと、監査対応で説明しやすくなります。
  • 責任の所在:「AIがOKを出したので回付した」という運用にならないよう、社内ガイドラインに「AIの判定は事前確認であり、決裁責任は承認者にある」と明記します。

DifyのHuman Inputノードはv1.13.0で追加された比較的新しい機能です。セルフホスト版ではバージョンや設定によって動作条件が異なる場合があるため、導入前に公式ドキュメントで最新の要件を確認してください。

よくある質問(FAQ)

Difyの稟議チェックは既存のワークフローシステムと併用できますか?

はい、併用できます。最も手軽なのは、既存の稟議システムに申請する前の「事前チェック」としてDifyのWebアプリを使う方法です。稟議システム側にAPIがあれば、DifyのHTTPリクエストノードで申請データを受け取り、判定結果をコメントとして書き戻す構成も検討できます。

無料プランやセルフホスト版でも構築できますか?

構築自体は可能です。DifyはオープンソースのためDockerでセルフホストでき、クラウド版にも無料のプランがあります。ただし、利用できるメッセージ数やメンバー数、メール配信の可否はプランによって異なります。2026年11月時点の条件はDify公式サイトの料金ページでご確認ください。

AIの判定精度はどのくらい期待できますか?

形式面の確認は高い精度を期待しやすい一方、規程の解釈を伴う項目は誤りが出る前提で設計すべきです。精度は規程の書き方やナレッジの整形状態に大きく左右されます。過去の稟議で人の判断との一致率を測ってから、AIに任せる範囲を決めるのが確実です。

決裁者の判定もAIに任せてよいですか?

いいえ、決裁者の判定はコードによるルール判定にすることをおすすめします。LLMは同じ入力でも出力がぶれる可能性があり、職務権限規程の運用としては説明が難しくなります。金額と支出区分による判定はコード実行ノードで固定し、AIには文章の確認と論点整理を担当させます。

まとめ:Difyの稟議チェックで差戻しの往復を減らす

Difyで稟議書チェックを自動化すると、記載漏れや添付漏れ、決裁区分の誤りを人が確認する前に洗い出せます。ポイントは、決裁者の判定をコードで固定し、LLMには見積書の読み取りと規程の論点提示を任せ、最終確認をHuman Inputノードで管理部門が行う三層構造にすることです。この設計であれば、差戻しの往復を減らしつつ、内部統制上の説明責任も保てます。

次のアクションとして、まず自社の決裁権限表を支出区分×金額帯の一覧に整理し、件数の多い購買稟議で過去10件を使った試験運用から始めてみてください。

関連記事

参考リンク

タイトルとURLをコピーしました