承認者マスタの設計｜組織改編で壊れない承認ルート

承認フローの設計記事を読むと、ほぼ必ず「承認者はフローに直書きせず、マスタから引きましょう」と書かれています。当サイトの記事でも、Power Automateの実装、kintoneのプロセス管理、代理承認の設計と、5本が同じことを勧めています。

ところが「では、そのマスタをどう作るのか」はどこにも書かれていません。列は何を持つのか、人事システムと同期すべきか、組織改編のときに過去の承認をどう説明するのか——実際に作る段になると、この辺りで手が止まります。

本記事はその部分を埋めます。扱うのはマスタ側の設計で、承認フローそのものの実装はPower Automateで稟議フローは作れる？内製の限界、代理承認の扱いは代理承認の設計｜承認者不在で止めない、証跡を壊さないにあります。

この記事の要点

• 承認者マスタの目的は「承認ルートの定義をフロー本体から切り離すこと」。狙いは保守を情シス以外に開くことと、変更履歴を残すこと。
• 承認者の指定方法は個人・役職・組織・申請者の上長の4つ。それぞれ壊れ方が違うので、組織の変わりやすさで選ぶ。
• マスタに持たせる列は、キー（部門・金額帯・申請種別）と値（承認者・代理者・有効期間）に分けて考える。
• 人事システムとの同期は、手動・CSV・APIの3段階。同期を入れる前に「兼務と役職者不在をどう表現するか」を決めないと破綻する。
• 監査で問われるのは「その時点のルート」。現在の値だけを持つマスタでは、過去の承認の妥当性を説明できない。

承認者マスタは何のために作るのか

承認者マスタとは、誰がどの申請を承認するのかという対応関係を、承認フローの外側に切り出したテーブルです。Microsoft 365であればSharePointリスト、kintoneであれば別アプリ、Google Workspaceであればスプレッドシートが実体になります。

目的は2つあります。

目的1：設定本体を触らずに承認ルートを変えられるようにする

承認者をフローやアプリの設定に直接書き込むと、異動・昇格・組織改編のたびに設定本体を開いて編集することになります。編集できるのは作った人だけなので、そのフローに触れる人が1人に固定されていきます。担当者が異動した時点で、誰も直せないフローが残ります。

マスタから引く構成にしておけば、以降の変更は行の書き換えだけです。総務や人事の担当者に権限を渡せるようになり、情シスが毎回呼ばれる状態から抜けられます。

目的2：承認ルートの変更履歴を残す

もうひとつは監査対応です。フローの設定を直接書き換えると、「いつ・誰が・何を変えたか」はシステムのログに残るとしても、当時の承認ルートを再現する手段がありません。マスタとして持ち、変更履歴を残す設計にしておけば、過去の承認について問われたときにその時点のルートを示せます。

この論点は代理承認の設計｜承認者不在で止めない、証跡を壊さないで扱った「その人が承認してよい根拠」と同じ話です。承認の記録だけでは、その人が承認者だったことを証明できません。

承認者の指定方法は4つある

マスタの設計に入る前に、そもそも承認者をどう特定するかを決めます。ここを決めないまま列を作ると、後から作り直しになります。

指定方法	例	組織変更時の壊れ方	向く組織
個人	田中太郎	異動・退職のたびに全行を探して修正	承認者がほぼ固定の小規模組織
役職	営業部 部長	役職が空席になると承認者不在で止まる	役職と決裁権限が対応している組織
組織	営業部 課長職グループ	グループのメンバー管理側に依存する	複数名のうち誰でも承認可な運用
申請者の上長	申請者の上司属性を参照	上長属性が未設定の社員で止まる	人事データが整備されている組織

実務でよく採られるのは、役職指定と申請者の上長指定の併用です。 通常は上長へ、金額が一定額を超えたら役職指定で部門長へ、という組み方になります。

個人指定は避けるのが原則ですが、少人数で兼務が多い組織では役職指定のほうが破綻することもあります。「役職が空席のまま数ヶ月」という状態が起こりうるなら、個人指定＋期間管理のほうが現実的です。

マスタに持たせる列

列は「引くためのキー」と「引いた結果の値」に分けて考えると整理しやすくなります。

キー側（この条件のときに、という部分）

• 部門コード：部署名ではなくコードで持ちます。部署名は改称されますが、コードは維持されることが多いためです
• 金額帯：下限と上限を別列で持ちます。「10万円以上」のような文字列で持つと、判定側で解釈が必要になります
• 申請種別：購買・経費・出張・アカウント申請など。同じ金額でも種別で承認者が変わる組織は多いので、最初から列にしておきます

値側（誰が承認するか、という部分）

• 承認者：上記4つの指定方法のどれかを入れます。指定方法を混在させる場合は、その行が個人指定なのか役職指定なのかを示す列も必要です
• 代理者：不在時に回す先。代理承認の設計は前掲の記事を参照してください
• 有効期間：開始日と終了日。組織改編を先に登録しておけるようにするための列で、後述の監査対応にも効きます

最初から入れておくと後で楽になる列

• 更新者・更新日時：誰がこの行を変えたかを残します
• 備考：「2026年4月の組織改編で追加」のような背景を書ける欄。運用が引き継がれるときに効きます

逆に、最初から持たなくてよいのは承認の段数です。段数をマスタに持たせると設計が複雑になりすぎるため、多段階が必要な場合は「1次承認」「2次承認」を別の行として持つほうが単純に保てます。

人事システムとの同期をどこまでやるか

マスタを作ると必ず出てくるのが「人事システムと同期できないか」という話です。3段階で考えます。

段階1：手動更新

行の追加・修正を人が行います。月に数件の変更であればこれで十分で、変更のたびに誰かが内容を確認するという意味では統制上もむしろ健全です。

段階2：CSVの定期取り込み

人事側から出力した組織・役職のデータを、週次や月次で取り込みます。同期の頻度が落ちる代わりに、取り込み前に差分を確認できるのが利点です。異動が集中する4月・10月だけ手動で先行登録する、という運用も取れます。

段階3：API連携による自動同期

人事システムのAPIから随時取得します。運用は軽くなりますが、人事側の変更がそのまま承認ルートに反映されるため、人事データの不備が承認の停止に直結します。

同期を入れる前に決めておくこと

どの段階を採る場合でも、次の2点を先に決めてください。ここを曖昧にしたまま同期を組むと、例外処理が延々と増えます。

1. 兼務をどう表現するか：1人が複数部署の承認者になる場合、マスタ上で行を分けるのか、1行に複数部署を持たせるのか
2. 役職者不在をどう扱うか：部長が空席のとき、上位者へ上げるのか、次席が代行するのか。代理承認の設計で整理した委譲・移管のどちらを既定にするかという話です

監査で問われるのは「その時点のルート」

見落とされやすいのがここです。承認者マスタを現在の値だけで持つと、過去の承認について妥当性を説明できません。

たとえば2年前の購買申請について「この金額を課長決裁で通したのは適切か」と問われたとき、現在のマスタが示すのは今のルートです。当時は課長決裁の上限が50万円で、その後30万円に下げられていたとしたら、現在のマスタを見ても当時の判断は説明できません。

対応は2通りあります。

• 履歴を持つ：行の変更をすべて履歴テーブルに残し、日付を指定してその時点の値を引けるようにする。正確ですが、マスタの構造と実装が重くなります
• 申請側にスナップショットを残す：申請レコードに、そのとき適用されたルート（承認者・上限額・適用したマスタの版）を書き込んでおく。マスタは単純に保てて、過去の説明は申請データ側で完結します

実務では後者が現実的です。 監査で問われるのは常に個別の申請についてなので、申請レコードを見れば当時のルートが分かる状態になっていれば足ります。Teams上での承認について、どこまで証跡が残せるかはTeams承認の履歴・監査証跡はどこまで残せるかで整理しています。

マスタが無いまま運用すると、どう詰まるか

既に各記事で症状として現れているものを、原因側から並べ直すと次のようになります。

• 承認が誰も操作できない状態で止まる：退職・異動でアカウントが無効になった人が承認者に残っている。実行履歴での切り分け手順はPower Automateの承認フローが止まる原因10選にあります
• フローを誰も直せなくなる：条件分岐の中に承認者が直書きされ、作成者以外が構造を読めない
• 代理設定が残り続ける：有効期間の列がないため、いつ外すべきか分からない
• 監査で過去のルートを示せない：前章のとおり

いずれもマスタ側の設計で防げるもので、フローを作り込んで解決する問題ではありません。ワークフローシステムを比較する際も、承認ルートを設定画面で管理できるかは判断軸のひとつになります（ワークフローシステム比較｜3タイプの違いと選び方）。

1Approvalでの実現方法

1Approval for Microsoft 365では、承認ルートと代理承認を管理画面のマスタとして持ちます。部門・金額帯・申請種別による分岐も設定画面で完結するため、組織改編のたびにフロー本体を編集する必要がありません。変更の履歴も残るため、過去の承認について問われた際に当時のルートを示せます。

加えて、承認が完了した時点で購買や手配の実行までつながる仕組みのため、承認ルートの設計が「承認まで」で終わりません。購買・出張データは実行された時点で経費データとして自動生成され、申請・承認・実行が同じ記録として残ります。監査で問われる4点（申請内容・承認の事実・承認してよい根拠・実行の記録）が、突合作業なしで揃う状態になります。

機能の詳細は1Approval for Microsoft 365のページでご確認ください。

よくある質問（FAQ）

承認者マスタはどのツールで持つのが良いですか？

承認フローを動かしている基盤に合わせるのが原則です。Power Automateで組んでいるならSharePointリスト、kintoneならマスタ用のアプリ、GASならスプレッドシートになります。別のツールに置くと、参照のたびに接続とライセンスの問題が出るためです。

人事システムのデータをそのまま承認ルートに使えますか？

そのままでは使えないことが多いです。人事システムが持つのは組織と役職の情報で、決裁権限（いくらまで承認できるか）は持っていないためです。実務では、人事データから組織・役職・上長を取り込み、金額帯と申請種別の条件は承認者マスタ側で管理する形になります。

組織改編の前にマスタを更新しておけますか？

有効期間の列を持たせておけば可能です。開始日を改編日に設定した行を事前に登録しておき、当日から自動で切り替わる形にできます。改編当日に一斉更新する運用は、漏れが出やすいため避けたいところです。

承認者マスタを更新できる人は誰にすべきですか？

承認ルートの変更は統制そのものの変更なので、申請者が自分で書き換えられる状態は避けてください。実務では、総務や人事が変更を申請し、管理者が承認して反映する形にすると、機動性と統制を両立できます。マスタ自体の変更にも承認を挟む、という考え方です。

小規模な組織でも承認者マスタは必要ですか？

承認者が数名で固定されているなら、フローに直書きでも回ります。分かれ目は、承認者が年に何回変わるかです。年に数回変わるなら、その都度フローを開いて編集するほうが早い場合もあります。毎月変わる、部署が増えている、という状況ならマスタに切り出す効果が出ます。

まとめ｜マスタは「引くためのキー」から設計する

承認者マスタの設計で迷うのは、たいてい列を先に考えてしまうからです。順序としては、まずどの条件で承認者を引きたいか（部門・金額・申請種別）を決め、次にその条件で誰を引くか（個人・役職・組織・上長）を決め、最後に有効期間と履歴の持ち方を決める、という流れになります。

そして、監査で問われるのは常に過去の個別の申請です。マスタに履歴を持たせるより、申請レコードに当時のルートを書き込んでおくほうが、実装も説明も単純になります。

まずは現在動いている承認フローを開いて、承認者がフローの中に直書きされている箇所を数えてみてください。その数が、組織改編のときに誰かが手で直すことになる箇所の数です。