役職名でアクセスを設計すると例外で壊れる――判定軸を「管理範囲」に移す3つの設計パターン

役職名をもとにアクセスグループを設計しているなら、例外が増えるたびに設計が崩れていく構造に入っている。
同じ「課長」でも決裁権限が違う人がいる。部門によって「支社長」と呼ぶポジションが、別部門では「部長」と呼ばれる。
この2つの問題を役職名で解こうとすると、例外グループが増え続けるか、手動判断が常態化するかのどちらかに向かう。

判定軸を役職名から「その人が管理する範囲（スコープ）」に移すことで、例外を構造の外に出せる。以下、破綻のパターンと修正設計を整理する。

役職名が「表示」である理由

アクセス設計で役職名を使う発想は自然だ。人事システムやMicrosoft 365（以下M365）のユーザー属性に役職名は入っているし、「課長以上はこのリソースへアクセス可」というルールは口頭でも伝わりやすい。

ただし、役職名は名刺の文字——つまり表示のための情報であって、アクセスを決める判定軸ではない。

アクセスを決めるべきは管轄地図の区画だ。「その人がどの範囲の業務・データを担当しているか」という情報は、役職名から計算では導けない。同じ「課長」でも、担当課が違えば見るべきデータは違う。同じ「部長」でも、特定プロジェクトの都合で一段上の権限を持つケースがある。この差は人事システムの役職コードには含まれていない。

NIST SP 800-162（Guide to Attribute Based Access Control、2014年・2023年更新）は、役職・職責を軸にするRBAC（Role-Based Access Control：役割ベースアクセス制御）が、兼務・例外・部門横断業務に対応しようとするとロール数が増加し続ける構造的問題を公式に認識している。また、Gartner IAM Summit 2024の場では「誰が何にアクセスできるか？そもそもアクセスすべきか？」という基本問を答えられないIAM（Identity and Access Management：アイデンティティとアクセスの管理）担当者が多いという指摘がなされた（Axoniusブログ経由・2次ソース）。名前軸の設計が崩れるのは運用の問題ではなく、設計の構造上の必然だ。

破綻が起きる3つのパターン

役職名ベースの設計が壊れるとき、たいていこの3パターンのどれかが起きている。

パターン1: 同じ役職名で権限が違う

「課長グループ」にアクセス権を設定した後、「A課長は経営企画も兼務しているので一段上の権限が必要」という依頼が来る。グループに例外フラグを付けるか、別グループを作るか——どちらを選んでもその場しのぎになる。次の例外が来るたびに同じ判断を繰り返す。

パターン2: 部門ごとに呼称が揃わない

営業部門では「支社長」、本社管理部門では「部長」、製造部門では「工場長」——これらが同じ権限スコープを持つとき、呼称の等級を比較して共通グループに収める作業が発生する。組織変更のたびにこの比較表が更新の対象になる。

パターン3: 異動・兼務のたびに設定変更が必要になる

役職名軸の設計では、異動や兼務が発生するたびに「旧グループから削除して新グループに追加する」という手作業が伴う。作業が常態化し、設定漏れが権限の過不足を生む。業界の実務知見として、1,000名規模の組織でもロール（グループ）定義が数千に達するケースが広く認識されている（Evolveum IAMドキュメント・2次ソース）。

設計パターン3点セット

判定軸を管理範囲に移すとき、以下の3点を設計に組み込む。

1. 名前→範囲の対応表を1枚に隔離する

役職名と管理範囲の対応関係を、権限グループとは別の1枚のテーブルに切り出す。

[ユーザー] → [名前→範囲対応表] → [スコープ定義] → [リソース権限]

権限グループ側は「スコープA担当」「スコープB管理者」という管理範囲ラベルを持ち、役職名は対応表の入力値になるだけで権限グループ側には現れない。

組織変更や呼称変更があったとき、更新するのは対応表だけでよく、権限グループ側は無改修になる。

2. 例外は「人ごとの上書き」データで吸収する

同じ役職名でも権限が違うケースをスコープ計算で解こうとすると、ルールの置き場所がなくなる。「この人だけ一段上」という例外は、計算ロジックではなく人ごとの上書きエントリで持つ。

実装上は、ユーザーに紐づく「スコープオーバーライド」テーブルを対応表の隣に用意し、上書き値がある場合はそちらを優先する構造にする。

[ユーザーID] × [上書きスコープ] × [有効期限] × [申請理由]

有効期限と申請理由を必須フィールドにしておくことで、いつ・なぜ付与された例外かを追跡できる状態を保てる。過剰権限が放置されるとセキュリティインシデントにつながる経路は実際にある（IDSA「Trends in Securing Digital Identities」2024：過去の調査データで不適切な権限管理が侵害の36%、過剰権限が21%に関与）。上書きデータは定期的にレビューし、不要になった時点で削除する運用とセットにする。

3. 部門差は「管理範囲への正準化」で合流させる

「支社長」と「部長」の等級を比較するのではなく、どちらも「担当エリア全体の管理者（スコープ：エリア全体）」という共通の管理範囲ラベルに寄せる。等級比較は組織の語彙に依存するため壊れやすいが、管理範囲への正準化（正準化＝バラつきのある表記を統一された形式に変換する操作）は組織の構造に依存するため安定する。

正準化の対応表はHR担当や事業部門リーダーと合意して定義する。この作業は初回だけ行えばよく、新しい呼称が発生したときだけ対応表に追加する。

M365 Developer Tenantで設計を検証する

M365 Developer Tenant（Microsoft 365 Developer Programで無料取得できる検証用テナント）を個人PCに持っていれば、上記の設計パターンをEntra IDのセキュリティグループとDataverseのビジネスユニット構造で実際に触りながら確認できる。

→ 関連記事：「Microsoft Power Platform 設計判断の全体像」（リンク予定）

運用責任は残る

判定軸を管理範囲に移しても、「誰がどのスコープを管理しているか」という情報を権威ソース（人事システムまたは専用台帳）に正しく持ち続ける運用責任は変わらない。設計パターンは構造の崩れ方を変えるが、データの正確性を自動保証するわけではない。

CISAのFY2023リスク・脆弱性評価（143の重要インフラ組織対象）では、侵害成功の40%が有効アカウント経由だった（2026年時点で参照できる最新のCISA年次報告書）。IPAの「情報セキュリティ10大脅威」でも、内部不正による情報漏洩が組織向け脅威の3〜4位として継続選出されており、過剰アクセス権付与が被害を拡大させると明示している（2024年・2025年版）。

これらは「アクセス設計が正しくても、権威ソースの管理が誤っていれば有効アカウントが悪用される」という構造の結果として読む。設計パターンの変更は出発点であって、継続的なアクセスレビューとセットで機能する。

まとめ

役職名は表示のための情報であって、アクセスを決める判定軸ではない。管理範囲への正準化・人ごとの上書き・対応表の隔離という3点を設計に組み込むことで、例外対応のたびに構造が崩れる状態から抜け出せる。

次の一歩：自組織のアクセス設計で「役職名」「部署名」を判定軸に使っているリソースを1つ選ぶ。そのユーザーが「実際に管理している範囲」をリストアップしてみる。そのリストが、グループ設計の出発点になる。

関連記事

• [dataverse-owner-owningbu-2axis]（リンク予定）——Dataverseのowner（誰の）とowningBusinessUnit（どこの）を2軸で分離する設計
• [normalize-at-ingestion-altkey-lookup]（リンク予定）——名前→コード変換を取り込み時に正準化する実装パターン
• [dataverse-view-filter-access-control]（リンク予定）——Dataverseのビューフィルターとセキュリティロールの役割分担