承認ルート設計の実務ガイド｜分岐の判断基準と、組織変更に耐えるフローの作り方

まずは結論からお伝えします。承認ルートの設計は、ベースとなる「型」を1つ選び、3つのポイントで「線引き」をするだけで明確に決まります。

 

承認ルートの型は、「直線」「並列・合議」「条件分岐」「社外接続」の4つに大別されます。まずは対象となる申請業務ごとに、ベースとなる型を1つ選びます。その上で、以下の順番で3つの線引きを行います。

 

1. 分岐の線引き：分岐を作るか、あえて「作らない」かを判断します。
2. 社外との線引き：承認者を決める前に、取引先に許可する操作範囲を定めます。
3. 変更権限の線引き：現場に変更を任せる範囲と、管理者側で統制する範囲を分けます。

 

この順序には明確な理由があります。ベースの型が決まれば、承認者の配置や分岐を入れるべきポイントはおのずと絞られます。逆に、承認者を先に並べてしまうと、型を変更するたびにルート全体を作り直す手間が発生してしまいます。

 

また、この3つの線引きを先に行うのは「後から変更すると手戻りが大きくなる項目」を固めておくためです。分岐は一度作ってしまうと後から減らすことが難しく、社外への公開範囲も一度案内した後に狭めるのは困難です。変更権限についても、一度現場に付与したものを後から制限するには、多くの説明と労力が必要になります。

承認者が増えてしまうのは、決して担当者の設計が甘いからではありません。部門をまたぐ申請業務には、無意識のうちに「人を足す」方向へと働く力が存在します。自社の承認ルートが無駄に長くなっている場合、以下の3つの力学のどれに当てはまるかを確認してみてください。

他部門の管理職を外しにくい

1つ目は、組織特有の力学です。「他部門の管理職を承認ルートから外すと角が立つのではないか」という心理が働き、本来は不要な「確認者」としてどんどん人を足してしまうケースです。

 

当社が2025年10月に情報システム部門の管理職221名へ実施した調査では、組織の「縦割り意識」や「部門最適」の考え方がDX推進の障壁になっていると感じるか尋ねました。その結果、「強く感じる（23.5％）」と「感じる（55.2％）」を合わせ、78.7％もの方が障壁を実感していることが分かりました。

 

 

出典：「レガシーシステムが存在する企業は91.9%！～情シス部門の管理職221人に"現場が直面するDX推進の障壁と課題"についてアンケート調査を実施～」
 

 

縦割り組織の課題を完全に解消してから設計を始めようとすると、いつまでもプロジェクトは進みません。承認者を足す前に、「その担当者は、申請に対して『否（差し戻し）』を出す権限と責任を持っているか」という1点のみを冷静に確認してください。

帳票ごとの違いを1本化してしまう

2つ目は、標準化を意識しすぎた結果起こる弊害です。当社のPoCにご参加いただいた、従業員約400名・全国20拠点の商社様の例が参考になります。

 

同社では、「取引先と取り交わす協力費確認書」と「社内で処理する振替伝票」の2つが検討対象でした。協力費確認書の社内承認には「上長・支店長・仕入責任者・本社仕入業務部」の4者が必要ですが、振替伝票では上長が外れて3者となります。

このように、書類の性格が異なれば関与するメンバーも変わります。すべてを無理に「1本の標準ルート」に押し込もうとすると、こうした細かな差異を吸収できず、かえって運用が複雑になります。

社外の手続きを社内延長として扱う

3つ目は、社外関係者の扱いです。取引先による「署名」や「確認」の工程を、社内承認の1ステップと同じように描いてしまう例が散見されます。

 

社内の「承認」は、権限を持つ者が可否を判断する行為です。一方、取引先への依頼は「署名」や「書類の返送」といった作業のお願いです。性質の異なる両者を同じフローに並べてしまうと、権限の設計が曖昧になります。設計時には「相手に何を見せ、何を操作させるか」を切り離して決めることが重要です。

承認ルートの型は、大きく4つに整理できます。型を選ぶ基準は、「承認者の判断が同時か順次か」「金額や部門で決裁者が変わるか」「社外の関与を含むか」の3点です。

直線型

申請者から順に、1人ずつバケツリレーのように渡していくシンプルな形です。最終決裁者が1人で、その手前に直属の上長による内容確認が入るような申請に向いています。
「上長が内容を精査し、その後に部長が金額の最終判断を下す」といった前後関係の明確な順序がある場合は直線型となります。ただし、承認の段数を1つ増やすことは、処理にかかる日数を1日分増やすことに直結するため注意が必要です。

並列・合議型

複数の承認者へ同時に申請を回す形です。各承認者の判断が独立しており、確認の順序に意味を持たない場合に適しています。
この型では、「全員の承認を必須とするか」それとも「一定数の承認で次へ進めるか」を分けて設定します。品質や安全性の確認では「全員承認」、情報共有（供覧）に近い確認であれば「過半数（定足数）」といった具合に使い分けると運用がスムーズです。

条件分岐型

金額や部門、勘定科目などの条件によって、承認者を自動的に切り替える形です。分岐のしきい値（基準）には、自社の「職務権限規程」に記載された決裁限度額をそのまま適用します。システムのために新しい基準を作る必要はありません。
もし、規程と実際の運用にズレがある場合（例：規程上は部長決裁だが、実務では課長が判断しているなど）は、システム化の前にどちらへ合わせるかを決定しておく必要があります。

社外接続型

取引先の署名や承認といったプロセスを挟む形です。承認者を決める前に、システム上で「社外のユーザーにどこまでの操作を許可するか（公開範囲）」を決定します。この範囲が決まらなければ、社内フローのどの段階で社外プロセスを挟むべきかも定まりません。

 

【4つの型の判定条件まとめ】

型	選ぶ基準・条件	向いている申請業務
直線型	承認者の判断に明確な前後関係がある	稟議書、購買申請
並列・合議型	承認者の判断が独立しており、順序に意味がない	品質報告、安全確認
条件分岐型	金額や部門などの条件で決裁者が変わる	支払依頼、値引き申請
社外接続型	取引先など、社外関係者の署名や承認が必要	確認書、覚書

自社で頻繁に発生する主要な申請業務を3つほど選び、上記の表に当てはめてみてください。もし、うまく割り当てられない申請がある場合、決裁者がまだ明確に特定できていない可能性があります。

また、1つの申請業務に対して2つの型を無理に組み合わせたくなる場合は、「申請そのものを2つに分けるべき」というサインです。性格の違う業務を1本にまとめると、それぞれの型のメリットが相殺されてしまいます。

条件分岐の機能は非常に便利ですが、分岐を増やすほど例外的な対応が発生しやすくなります。システム上で分岐を作り込む前に、以下の3点を確認してください。

過去1年間の「差し戻し実績」はあるか

1つ目は、差し戻しの実績確認です。分岐の先に設定しようとしている承認者が、過去1年間で一度でも申請を「差し戻し（否認）」したことがあるかを調べます。
差し戻しの有無は、その承認機能が形骸化していないかを測る指標になります。過去に一度も差し戻し実績がない承認者は、実質的に「ストッパー」としての役割を果たしていない可能性があります。その場合、承認者ではなく「確認者」や「供覧（通知のみ）」へ移行させることで、分岐そのものを不要にできるケースがあります。

「帳票の分割」でシンプルにならないか

2つ目は、帳票分割の検討です。1つの申請業務の中に分岐を2つ以上作りたくなった場合は、帳票自体を分けてしまうアプローチを検討してください。
判断の目安は、「分岐の先で、承認者だけでなく入力すべき項目内容も変わるかどうか」です。入力項目が大きく変わるのであれば、無理に同じ帳票にまとめる必要はありません。前述の商社様の例のように、書類の性格ごとに別々のルートを用意したほうが、結果的に運用がシンプルになることは多々あります。

承認ではなく「入力側の工夫」で解決できないか

3つ目は、入力画面の設計によるカバーです。もし「入力ミスや手戻りを防ぐため」に承認者を足そうとしているのであれば、まずは入力側でミスを防ぐ仕組みが作れないかを考えます。
例えば「入力値の候補をプルダウンで絞る」「前月のデータを自動転記する」「申請者の所属情報を自動入力する」といった工夫は、承認者を1人増やすよりもはるかに確実で高い効果を発揮します。誤りを見つける負担を承認者に押し付けるのではなく、最初から誤りが発生しにくい入力フォームを用意することが重要です。

 

なお、年間の申請件数や、承認者不在時の代理設定の考え方については、前掲の記事で詳しく解説しております。また、分岐を作り込んだ結果、例外対応の負担が情報システム部門に集中するような事態は避けなければなりません。当社の資料では、導入前検証で確認した具体的な設計例や分岐の判定観点をご紹介していますので、ぜひ資料請求ページよりご請求ください。

社外関係者が関与するフローでは、社内の承認ルートとは設計の順序が逆転します。社内の承認者を配置するよりも先に、「取引先にシステム上でどこまでの操作を許可するか」を決定します。

社外に許可する操作をリストアップする

前述の商社様における「協力費確認書」を例に見てみましょう。このケースでは、取引先側が行う操作を以下の4つに限定しました。

 

1. 帳票のダウンロード
2. 署名
3. 署名済み帳票のアップロード
4. アップロード時の「社内担当者」の選択

 

ここまでが社外に許可する操作の全容です。さらに重要な要件として、「社内での承認進捗状況は取引先側から見えないようにする」という条件が加わっています。価格交渉などを伴う書類において、社内検討がどこまで進んでいるかは、相手に開示すべきではない機密情報だからです。

決定した公開範囲を「要件」として明文化する

社外への操作範囲は、口頭での取り決めだけで終わらせてはいけません。「誰が」「どの画面で」「何を行えるか」を権限の一覧表として要件定義書に明確に書き残す必要があります。
要件定義書の項目構成や、未決事項の扱い方については「要件定義書の必要項目と書き方｜実案件のサンプルと未決事項の管理法（テンプレート付）」にまとめておりますので、ご参照ください。

授受した書類の保存には「別のルール」が適用される

社外とやり取りする電子書類には、社内の承認ルールとは別の法的な保存要件が課せられます。
国税庁の「電子帳簿保存法一問一答【電子取引関係】（令和7年6月版）」によると、電子取引とは「取引情報の授受を電磁的方式により行う取引」と定義されています。

 

出典：国税庁「電子帳簿保存法一問一答【電子取引関係】」（令和7年6月）

 

また、所得税（源泉徴収に係るものを除く）および法人税の保存義務者に対しては、電子取引を行った場合、その取引情報を電磁的記録により保存する義務が定められています。つまり、社内でどれほど完璧な承認ルートを設計しても、電子帳簿保存法などの要件を満たす保管ルールを別途定めておかなければ、コンプライアンス上の課題が残る点には注意が必要です。

ルートの型と分岐が決まったら、最後に「運用時の設計」を行います。承認ルートは一度作って終わりではなく、人事異動や組織改編のたびにメンテナンスが必要になります。ここでの設計を誤ると、毎年4月になるたびに膨大なシステム修正作業に追われることになります。

承認者は「個人名」ではなく「役職と組織」で指定する

異動のたびにルートが機能しなくなる最大の原因は、承認者を「個人名（A部長、B課長など）」で指定していることです。個人ではなく「〇〇部の部長」といったように「役職と組織」の組み合わせで設定しておけば、基幹システム等の人事情報が更新されるだけでルートも自動的に追随します。
異動時にも業務を止めないための考え方については、「異動・組織変更でも業務を止めない｜引き継ぎを最小化するプロセスの仕組み化」が参考になります。

現場に変更を任せる範囲を「事前に」定義する

現場部門（ユーザー）側でルートの一部を変更できるシステムの場合、「どこまで現場の裁量に任せるか」が重要な論点となります。

 

令和5年4月7日に企業会計審議会が公表した意見書では、統制活動について次のように説明されています。

 

統制活動とは、経営者の命令及び指示が適切に実行されることを確保するために定める方針及び手続をいう。（中略）これには、権限及び職責の付与、職務の分掌等が含まれる。

出典：企業会計審議会「財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の改訂について（意見書）」

 

ここから読み取れるのは、「誰に何の権限を与えるか」を明確に定めること自体が、重要な内部統制活動であるという事実です。「現場に設定変更を許可すること」自体が問題なのではなく、「許可する範囲が曖昧なまま放置されている状態」が問題となります。

現場に任せる範囲と管理側で統制する範囲は、以下のように明確に線引きすることをおすすめします。

 

変更の種類	現場部門に任せる（許可する）	管理部門で握る（統制する）
代理承認者の設定	◯
申請項目の追加・微修正	◯
決裁段数の増減		◯
金額しきい値の変更		◯
社外への公開範囲の変更		◯

なお、電子化（脱ハンコ）に伴う社内規程の見直しについては「脱ハンコで内部統制を強化する実践ガイド｜管理職が知るべき規程見直しと承認プロセスのDX化」にて詳しく解説しています。

当社が2026年に実施したPoC案件の中から、ルート設計に対するアプローチが分かれた3社の実例をご紹介します。いずれも要件定義から検証段階の事例であり、具体的な費用対効果（処理日数の短縮効果など）は計測前のため、「何を基準にプロジェクトを推進したか」に焦点を当てています。（※企業名非公開のため、業種と規模のみ記載）

正社員約520名の食品製造業

社員が私有車を業務使用した際の「燃料費申請フロー」が対象でした。同社は「この業務では差し戻しがほとんど発生しないため、まずは申請を受け付けるワークフローが存在すれば十分である」という仮説を立てました。そのため、複雑な分岐や合議は組まず、シンプルな「直線型」で要件を満たすと判断しています。
現場から挙がった3つの要望も、すべて「入力側の工夫（自動計算や入力補助）」に関するものであり、承認ルートを複雑化させるのではなく、入力段階でミスを減らす方向で設計が進められました。

従業員約400名の化学メーカー

IT部門が主導し、7つの社内課題についてシステム化の可否を検討していた企業です。その中で「請求書や見積書を取引先へ渡すフロー」も候補に挙がりました。
同社ですでに導入済みのkintoneを活用する案も出ましたが、「取引先までシステムに巻き込むと、アカウント費用などでコストが膨らみすぎる」という指摘がなされました。社外関係者を含むルート設計では、利用者数の増加を見越した慎重な費用対見積もりが不可欠です。

従業員約150名のソフトウェア開発業

これまで見積りや受注の管理をExcelで行っていた総務部（担当2名）の業務が対象です。ここで検討されたのは、「決裁」を目的としないユニークなルート設計でした。

営業担当からの依頼をワークフローで受け付け、それに基づき総務が見積書を起票するという流れです。目的は「依頼窓口の一本化」「対応漏れの防止」、そして「依頼履歴の確実な保存」でした。このように、申請フローは単なる決裁ツールとしてだけでなく、業務の「受付システム」としても有効に機能します。

 

これら3社に共通しているのは、ルートの「型」を選ぶ前に、システム化の「目的」を明確にしている点です。業務をシンプルに保ちたいのか、コストを最小限に抑えたいのか、それとも窓口を一本化したいのか。目的が定まれば、選ぶべきルートの形は自然と決まってきます。

最後に、設計の過程で特によく寄せられる4つの疑問にお答えします。

1つの申請業務に、複数の型を組み合わせて設定してもよいですか？

システム上の設定は可能ですが、まずは「申請業務自体を分割できないか」を再検討してください。例えば「前半が並列・合議型で、後半が直線型」といった複雑なルートは、現場への運用ルールの説明や浸透が非常に難しくなります。

取引先へシステムのアカウントを渡すことにセキュリティ上の不安があります。

アカウントを発行する前に、「社外ユーザーに許可する操作」を明確にリストアップしてください。前述のPoC事例のように「ダウンロード・署名・アップロードの3操作のみに限定し、社内の進捗ステータスは一切見せない」といった厳格な権限設定を行えばリスクは最小化できます。操作範囲を定めてから権限を付与する順序を守ることが安全への近道です。

現場部門にルート変更の権限を任せると、内部統制が緩みませんか？

「現場が変更できる範囲」を事前に明確に定義していれば、統制が緩むことはありません。現実的な運用としては、代理承認者の設定や細かな入力項目の追加は現場に任せつつ、「決裁段数の増減」や「金額のしきい値変更」といった重要項目は管理部門側で権限を握る形が推奨されます。また、システム上に変更履歴（監査ログ）が残るかどうかも併せて確認してください。

すでに電子決裁を導入しているのに、承認スピードが遅いのはなぜですか？

システムルートの形そのものではなく、「承認の宛先設定」や「承認完了の定義」に根本的な原因があるケースが多く見られます。原因の切り分け方については、前掲の電子決裁の記事をご参照ください。また、システム自体の機能不足が疑われる場合は、「ワークフローシステム比較の3つの軸 選び方と料金、無料版の限界を検証データから見極める」の記事が参考になります。

承認ルートの設計は、業務ごとにベースとなる「型」を1つ選ぶことからスタートします。自社の申請業務が「直線」「並列・合議」「条件分岐」「社外接続」のどれに該当するかを見極め、割り当てを行ってください。

 

条件分岐については、過去の差し戻し実績や、帳票を分割できるかといった観点から要否を判断します。「あえて分岐を作らない」という選択も、立派な設計のひとつです。
取引先を含むフローの場合は、社内の承認者を配置する前に「社外に許可する操作範囲」を決定します。また、将来の組織変更や人事異動に備え、承認者は個人名ではなく必ず「役職と組織」の組み合わせで指定するようにしてください。

 

承認ルートの詳細な設計方針は、システム製品を選定する「前」に自社内で固めておくべき要素が多く存在します。当社の資料では、取引先を含むフローの権限設定の具体例や、組織変更に耐えうるルート指定の実践的な方法をご紹介しております。ぜひ資料請求ページよりお気軽にご請求ください。