代理承認の設計｜承認者不在で止めない、証跡を壊さない

承認者が休暇に入る。出張で反応がない。異動したばかりで誰が承認者なのか決まっていない。こうした場面で申請が止まるのを避けるために、多くの企業が代理承認の仕組みを入れます。

ところが導入から1年ほど経つと、別の問題が出てきます。「この申請、誰が承認したことになっているのか」が説明できなくなるのです。代理設定が残ったまま退職者のアカウントが承認者に居座っていたり、本来は一時的だったはずの代理者が実質の承認者になっていたり。止めないための仕組みが、統制を静かに壊していくという構図です。

本記事は、代理承認を「どう設定するか」ではなく「誰の権限で押されたことになるか」から設計する視点で整理します。Power Automateでの具体的な実装パターンはPower Automateで稟議フローは作れる？内製の限界、承認が止まっているときの切り分け手順はPower Automateの承認フローが止まる原因10選にまとめているので、実装側はそちらをご覧ください。

この記事の要点

• 代理承認には委譲・代行・移管の3つの型があり、証跡にどう残るかがそれぞれ違う。最初に決めるべきはここ。
• 事故の大半は設定ミスではなく、期間と範囲を区切らなかったことで起きる（退職者の代理設定、代理の恒常化）。
• 承認者・代理者をフローやアプリの設定本体に直書きすると、組織改編のたびに触れる人が1人に固定されていく。
• 監査で問われるのは承認の事実だけでなく、その人が承認してよい根拠（権限委譲の記録）まで含む。
• 代理承認を増やす前に、承認回数そのものを減らせないかを先に検討したほうが効果が大きい場面がある。

代理承認とは、何を委ねる行為か

代理承認は「承認ボタンを押す作業」の肩代わりではありません。承認という意思決定の権限を、一時的に他者へ委ねる行為です。ここを曖昧にしたまま仕組みだけ入れると、後から証跡の説明がつかなくなります。

実務で使われている形は、大きく3つに分かれます。

型1：委譲（代理者が自分の名前で承認する）

承認権限を代理者に与え、代理者が自分のアカウントで承認します。記録に残るのは代理者の名前です。「部長不在のため課長が代理承認した」という事実がそのまま残るため、証跡としては最も素直です。

型2：代行（承認者のアカウントで代理者が操作する）

承認者のIDを共有する、あるいは承認者宛のメールリンクを秘書や担当者が開いて処理する形です。記録上は承認者本人が承認したことになります。運用としては手軽ですが、記録と実態が食い違うため、内部統制上は避けるべき形です。監査で「本当にご本人が承認しましたか」と問われたときに、否定も肯定もできません。

型3：移管（上位者・別の承認者へ振り直す）

一定時間応答がなければ上位者へ自動でエスカレーションする、あるいは管理者が承認者を差し替える形です。記録に残るのは新しい承認者の名前で、誰に回ったかの履歴も残ります。

3つの型の違いは「証跡の残り方」に出る

型	承認者として記録される人	監査で説明できるか	向く場面
委譲	代理者本人	◎ 委譲の根拠を示せば成立する	計画された不在（休暇・出張）
代行	承認者本人（実態と不一致）	✕ 実際に誰が判断したか示せない	推奨しない
移管	新しい承認者	◎ 振り直しの履歴が残る	突発的な不在、長期の滞留

型2（代行）は、仕組みを入れていない企業で自然発生します。 「部長のメールを秘書が開いて処理している」「承認用アカウントを共有している」という運用に心当たりがあれば、それは代理承認の設計をしていない状態です。

ツールごとに「設定できる範囲」は違う

型が決まったら、使っているツールで実現できるかを確認します。ここは各クラスタの記事で詳しく扱っているため、要点だけ整理します。

• kintone：プロセス管理の作業者指定は、ユーザー・組織・グループ・フィールドの値から選べます。組織やグループで指定しておけば、メンバーの入れ替えに設定変更なしで追随できます。設計パターンはkintoneのプロセス管理とは？仕組みと設計パターンにまとめています
• Power Automate：承認アクションの割り当て先を動的に決める実装と、タイムアウトで上位者へ回す実装の2通りがあります。実装パターンはPower Automateで稟議フローは作れる？内製の限界を参照してください
• GAS：ステータスと承認者列を持つスプレッドシートに対して、条件で通知先を切り替える形になります。自作の範囲と限界はGASで承認フローを自動化する方法と限界で整理しています

どのツールでも「できなくはない」というのが実際のところです。問題は作れるかどうかではなく、作ったあと誰が保守するかにあります。

代理承認が事故になる4つのパターン

導入後に問題として表面化するのは、次の4つです。いずれも設定ミスではなく、設計段階で条件を決めなかったことが原因です。

パターン1：退職者・異動者の代理設定が残り続ける

代理設定は入れるときには意識されますが、外すときに誰も思い出しません。退職したアカウントが代理者のまま残っていると、承認依頼が誰も見ないメールボックスへ届き続けます。設定を入れた日から棚卸しの対象にしておくか、後述のように期間を区切るのが対策です。

パターン2：組織改編に承認ルートが追随しない

承認者を個人のアカウントで直接指定していると、部署の統廃合や昇格のたびに設定本体を編集することになります。編集できる人は限られているため、そのフローに触れる人が1人に固定されていきます。担当者の異動でブラックボックス化する典型です。

パターン3：代理が恒常化し、実質の承認者になる

「部長は忙しいので、実質的に課長が全部見ている」という状態は珍しくありません。これは職務分掌の観点では、承認権限が事実上移っているのに規程上は移っていない状態です。金額基準の意味も失われます。職務分掌の考え方は消耗品購買の内部統制｜リスクと承認フロー設計で整理しています。

パターン4：代理の範囲が無制限

「不在時は代理者へ」とだけ決めていると、通常は部長決裁が必要な金額の申請まで代理者が通せてしまいます。委譲したのは全権限なのか、一定額までなのかを決めていないと、代理承認が統制の抜け道になります。

設計の指針5つ

4つのパターンの裏返しが、そのまま設計の指針になります。

指針1：どの型を使うか先に決める

委譲（代理者の名前で承認）か、移管（別の承認者へ振り直す）か。計画された不在は委譲、突発的な不在は移管、という使い分けが実務的です。代行は選ばない、と明示的に決めておいてください。

指針2：期間を必ず区切る

代理設定には開始日と終了日を入れ、無期限の設定を作らないことです。期間が切れたら自動で元に戻る仕組みにしておけば、パターン1と3は構造的に起きません。期間指定ができないツールなら、月次で代理設定の一覧を確認する運用を先に決めてください。

指針3：範囲を限定する

委譲する権限に上限を付けます。「代理者が承認できるのは1件50万円まで、それ以上は上位者へ移管」といった形です。範囲を決めると、代理の恒常化が起きても被害が限定されます。

指針4：承認者をマスタで持つ

承認者・代理者をフローやアプリの設定本体に書き込まず、別のマスタから引く構成にします。部門コードや役職をキーに引く形にしておけば、以降の変更はマスタの更新だけで済み、設定本体を触れる人が1人に固定される問題も避けられます。

あわせて、マスタの変更履歴が残るようにしておいてください。監査で過去の承認の妥当性を問われた際に、その時点のルートを示せます。

指針5：委譲した事実そのものを記録する

見落とされがちなのがこれです。「誰が・誰に・いつからいつまで・どの範囲を」委譲したかの記録を残します。承認の記録だけでは、その人が承認してよい立場だったことを証明できません。

監査で問われるのは4点

内部監査・外部監査で確認されるのは、おおむね次の4点です。代理承認が絡むと3番目が増えます。

1. 申請内容（誰が、いつ、何のために、いくらで）
2. 承認の事実（誰が、いつ承認したか。ルートは基準どおりか）
3. その人が承認してよい根拠（権限規程、または権限委譲の記録）
4. 実行の記録（実際に手配・支払われた内容と金額）と、申請との差異

3を説明できない状態は、承認プロセスそのものの実効性を問われます。Teams上での承認について、どこまで証跡が残せるかはTeams承認の履歴・監査証跡はどこまで残せるかで整理しています。

代理承認を増やす前に、承認の回数を減らせないか

ここまで設計の話をしてきましたが、根本的な問いも置いておきます。そもそも、その承認は必要かという問いです。

代理承認が必要になるのは、承認者に承認依頼が集中しているからです。件数が多ければ多いほど不在の影響が大きくなり、代理の仕組みも複雑になります。承認件数を減らす方向の打ち手は2つあります。

• 金額帯で承認の重さを変える：少額は事後承認と月次モニタリングに切り替え、事前承認は一定額以上に限定する
• 枠を先に渡す：条件付きの事前承認（カテゴリと上限を決めて渡す）にして、枠内は都度の承認を不要にする。この考え方は現場の勝手購買はなぜ止まらないのか｜緊急購買の設計で詳しく扱っています

承認の総数が減れば、代理承認の設計も単純になります。複雑な代理承認の仕組みが必要になっている時点で、承認設計そのものを見直す合図と捉えてください。

1Approvalでの実現方法

1Approval for Microsoft 365では、承認ルートと代理承認を管理画面のマスタとして持ちます。組織改編や担当者の変更があっても、フロー本体を編集せずに設定画面で完結するため、指針4の「触れる人が1人に固定される」問題が起きません。変更の履歴も残るため、過去の承認について問われた際に当時のルートを示せます。

加えて、承認が完了した時点で購買や手配の実行までつながる仕組みのため、承認待ちが長引くこと自体が減ります。不在による滞留を代理承認で吸収するより、承認から実行までの時間を短くするほうが、結果として代理の出番を減らせます。購買・出張データは実行された時点で経費データとして自動生成されるため、監査で問われる4点が突合作業なしで揃う状態になります。

機能の詳細は1Approval for Microsoft 365のページをご覧ください。ワークフローシステムを3タイプに分けて比較したワークフローシステム比較｜3タイプの違いと選び方も、選定の際の参考になります。

よくある質問（FAQ）

代理承認と代理決裁は同じものですか？

ほぼ同義で使われますが、「代理決裁」は決裁権限そのものの委譲を指すことが多く、規程上の裏付けを伴う言葉として使われる傾向があります。本記事の型でいえば委譲にあたります。社内規程で用語を定義している場合は、そちらの定義に合わせてください。

承認者のアカウントを共有して代理承認させるのは問題ありますか？

推奨しません。記録上は承認者本人が承認したことになり、実際に誰が判断したかを示せなくなります。監査で指摘を受けるだけでなく、不正があった際に責任の所在を特定できません。代理者自身のアカウントで承認する形（委譲）に切り替えてください。

代理承認の設定は誰が行うべきですか？

承認者本人が設定する運用と、管理者が一括で設定する運用があります。本人設定は機動的ですが棚卸しが効きにくく、管理者設定は確実な代わりに手間がかかります。実務では「本人が申請し、管理者が承認して有効化する」形にすると、記録も残り機動性も保てます。

代理承認を認めると内部統制上問題になりませんか？

代理承認そのものが問題なのではなく、範囲と期間が決まっていないこと、記録が残らないことが問題になります。委譲の根拠と期間、上限額が定義され、その記録が残っていれば、統制上は成立します。自動で承認者を差し替える実装を入れる場合は、事前に監査部門と扱いを合意しておいてください。

承認者が退職した場合、過去の承認はどう扱われますか？

過去の承認記録は有効なまま残ります。問題になるのは、そのアカウントが承認者として設定されたままになっているケースです。退職・異動時のアカウント処理の手順に、承認者・代理者設定の棚卸しを組み込んでおいてください。

まとめ｜「止めない」と「証跡を壊さない」は両立できる

代理承認は、承認者不在で業務が止まるのを防ぐ仕組みです。ただし入れ方を誤ると、誰が判断したのか説明できない状態を作ります。

分かれ目は、設定の巧拙ではなく次の3点です。どの型を使うか（委譲か移管か、代行は選ばない）、期間と範囲を区切ったか、委譲した事実そのものを記録しているか。この3つが決まっていれば、代理承認は統制を緩めずに滞留を防ぐ仕組みとして機能します。

まずは自社で現在有効になっている代理設定を一覧で出してみてください。終了日が入っていないものが何件あるかが、最初に手を付けるべき場所を教えてくれます。