購買システムの権限表の作り方——役割・操作・範囲の三つで切る

権限表は、職務分掌の結論を設定に落とすための表

購買部門から受発注のシステムを入れたいと相談されると、情報システム部門には「権限はどう設定すればよいか」という問いがほぼ必ず回ってくる。ここで、なぜ発注する人と検収する人を分けるのか、どの職責をどう分けるのかという統制の考え方から議論を始めると、話が設定の画面にたどり着かない。統制の考え方は発注する人と検収する人を分ける（職務分掌）で、承認の金額の区切り方は発注の承認ルールをどう設計するかで扱っている。この記事は、そこで決めたことを、システムに入れられる一枚の表にする作業に絞る。

表を作る責任が誰にあるかを、先に確かめておく。総務省の「クラウドサービス利用・提供における適切な設定のためのガイドライン」は、SaaS（ソフトウェアをサービスとして借りる形態）を利用する場合、アプリケーションの動作に係る設定は事業者が責任を負う一方、利用者アカウントや業務データの設定は利用者の責任になると整理している^[1]。権限の設定はまさに後者である。事業者が用意した役割の種類をどう割り当てるかは、事業者に任せられない。

三つの軸：役割・操作・データの範囲

総務省のガイドラインは、ID とアクセス管理を「誰が」「どのリソースに対し」「どのような操作ができるか」を定義してアクセス制御を実現するもの、と説明している^[1]。購買システムの権限表も、この三つの軸で作る。

一つ目の軸は役割（誰が）である。購買の流れに沿うと、購買申請を出す人、発注を作って取引先に出す人、発注を承認する人、届いた物を検収する人、取引先や品目・単価のマスタを管理する人、システムの設定と利用者を管理する人、の六つに分けられる。一人が複数の役割を持つのは構わないが、役割の定義そのものは人ではなく仕事で決める。

二つ目の軸は操作（どのような操作）である。「発注を使える」では粗すぎる。参照する、下書きを作る、確定して取引先に出す、取り消す・変更する、一覧を書き出す、設定を変える、の段階に分けて考える。とくに確定・取消・書き出しの三つは、下書きや参照とは別の権限として扱う。確定は社外へ効力を持ち、取消は記録を動かし、書き出しはデータを社外に持ち出せる操作だからである。

三つ目の軸はデータの範囲（どのリソースに対し）である。自部署の発注だけか、全社か。担当する取引先の分だけか、全取引先か。一定の金額までか。個人情報保護委員会のガイドラインは、個人データを扱う情報システムについて、技術的安全管理措置として、担当者及び取り扱う個人情報データベース等の範囲を限定するために適切なアクセス制御を行わなければならない、としている^[5]。購買システムの取引先マスタには、取引先の担当者の氏名や連絡先が入る。範囲の軸は、統制の都合だけでなく、この義務を果たす手段でもある。

権限表の例

三つの軸を一枚に重ねると、次のような表になる。行が操作、列が役割で、マスには可否と範囲を書く。あくまで出発点の例で、会社の人数や業務の分け方で中身は変わる。

この表で見てほしいのは、マスに「○」だけでなく範囲や条件が書かれていることである。「発注担当は発注を確定できる」ではなく「承認済みのものだけ確定できる」。「承認者は承認できる」ではなく「自分が出した発注は承認できない」。条件まで書いておかないと、システムの設定画面に入ったときに、どの選択肢を選べばよいかが決まらない。

表の列の数は、システムに用意された役割の数と一致しなくてよい。先に業務の側で表を作り、次の節で見るように、システムの役割と機能の切り替えにどう当てはめるかを考える。

出発点は「全員が何もできない」

権限表を作るとき、既存の業務で誰が何をしているかを書き写すところから始めると、現状の兼務がそのまま権限になる。政府機関向けの資料ではあるが、内閣官房 国家サイバー統括室の「政府機関等の対策基準策定のためのガイドライン」は、権限の管理について、アクセス権限は最小権限の付与とするため、全てにアクセスできないことを前提に、アクセスの必要がある主体に対してのみ権限を付与することを原則としている^[2]。情報に対して権限を与えるときも、知る必要のある主体にのみ付与するとしている^[2]。

民間の会社にこの基準を守る義務はないが、表の作り方としてはそのまま使える。空の表を置き、役割ごとに「この操作が無いと仕事が止まるか」を一つずつ問い、止まるものだけに印を付ける。参照の権限も同じで、「見えたほうが便利」は理由にしない。単価や見積の内訳は、社内でも見せる範囲を絞りたい情報である。

情報処理推進機構（IPA）の情報セキュリティ関連規程のサンプルも、利用者の業務・職務に応じた必要最低限のアクセス権を付与すること、特定の情報資産へのアクセス権が同一人物に集中することで起きうる不正を考えて複数名に分散して付与すること、アクセス権の発行・変更・削除を申請・許可制とし申請書または台帳を作って保管することを、アクセス制御方針の例として示している^[4]。権限表は、この台帳の中身そのものになる。

システム管理者の権限は、業務の権限と分ける

権限表の右端の列、システム管理は性質が違う。他の列は購買の仕事をする権限だが、この列は他の列を書き換えられる権限である。総務省のガイドラインは、管理者はクラウド全体のセキュリティに関与するため、管理者アカウントとユーザアカウントを分離し、管理者アカウントには多要素認証を必須にする等の設定を確実に行うよう求めている^[1]。管理者や特権アカウントについては、多要素認証と複数人でのチェック体制をとること、認証やアクセスログ、設定変更等のログを監視すること、特権アカウントの利用者や特権に昇格できるアカウントは最小限とすることが望ましいとしている^[1]。

政府機関向けのガイドラインは、管理者権限を付与するときの措置の例として、業務上必要な場合に限定すること、必要最小限の権限のみ付与すること、同一の者が権限の付与と権限の執行を兼ねないようにすること、管理者権限を行使できる端末を専用の端末とすることを挙げている^[2]。そのうえで、管理者権限を持つ識別コードの利用は権限を必要とする業務に限り、一般の業務として使わせないこととしている^[2]。

購買の現場に置き換えると、次の三つになる。システム管理者の役割を持つ人には、日々の発注や承認に使うアカウントとは別のアカウントを用意する（一つのアカウントで両方をこなさない）。設定を変えたら、変えた人とは別の人が確かめる。そして、システム管理者が自分に業務の権限を足す操作が記録に残り、別の人の目に触れるようにする。総務省のガイドラインは、設定を直接行う人を「設定者」、最終的な設定の確認と正常な設定の維持に責任を持つ人を「設定管理者」と呼び、SaaS ではこの二つの役割を利用者の側が持つとしている^[1]。人数が足りなければ、設定者と設定管理者を別の部署から出すだけでも効果がある。

人がいないからといって、管理者権限を常に持たせておく必要もない。政府機関向けのガイドラインは、アカウント管理者や権限管理者のような特に強い権限は常時付与せず、執行が必要になったときに申請と承認を経て有効化することが望ましいとしている^[2]。システムに一時的な付与の機能が無い場合でも、運用で同じことはできる。普段使う管理者アカウントは一つにしておき、変更が必要なときだけ申請書を出してもらい、作業が終わったら別の人が記録を確認する。管理者の権限がなぜ業務の権限から離れていなければならないかという統制上の理由は、職務分掌の記事で扱った「権限の設計は二階建て」の話につながっている。

システムの役割の数が少ないときの当てはめ方

クラウドの購買システムには、用意された役割が「管理者」「一般」のように数種類しかないものが多い。業務で作った六つの列を、そのまま役割として作れないことのほうが普通である。そのときは、次の順で当てはめる。

1. 役割と機能の切り替えを組み合わせる。役割の種類が少なくても、利用者ごとに「購買の機能を使えるか」「承認者として指定されているか」のような設定があれば、組み合わせで列を作れる。承認者を役割ではなく個人で指定できるシステムなら、承認の列は役割にしなくてもよい。

2. 範囲で絞れないものは、運用と記録で補う。「担当取引先の分だけ見せる」がシステムで設定できないなら、全員に見えることを前提に、書き出しの権限を絞る、書き出した記録を見る、という形で補う。操作の記録を何のために何を残すかは購買システムの操作の記録で扱う。

3. 当てはめられなかったマスを表に残す。表の上で「本来は不可だが、システムの都合で可になっている」マスに印を付け、代わりに何で補っているかを書いておく。これが、後で監査や点検を受けたときの説明になる。人数の都合で分けられない場合の代替統制の置き方は、職務分掌の記事に三つ挙げてある。

個人情報保護委員会のガイドラインは、中小規模事業者の手法の例として、個人データを取り扱うことのできる機器と、その機器を取り扱う従業者を明確化し、個人データへの不要なアクセスを防止することを挙げている^[5]。システムで細かく絞れないときでも、「誰が取引先マスタを見られるか」を明確にして一覧にしておくことはできる。

取引先（社外）に見せる範囲は、社内の誰よりも狭く

購買システムが販売管理や会計のシステムと違うのは、社外の人が画面に入ってくる場合があることである。取引先が見積に回答する、納期を回答する、発注を確認する。総務省のガイドラインは、ゲストユーザーについては、不要な情報公開を避けるため必要最小限の権限とすることを求めている^[1]。IPA の規程のサンプルも、従業員以外の者にアカウントを発行する場合は、責任者の承認を得たうえで秘密保持契約を締結することとしている^[4]。

取引先に見せてよいのは、原則として「その取引先宛ての依頼と発注」だけである。権限表に取引先の列を足すと、次のようになる。

他社の見積を取引先に見せることの扱いは相見積を他社に見せるのは違法かで取り上げている。権限の設計の側で気をつけたいのは、意図して見せる場合ではなく、設定の誤りで見えてしまう場合である。総務省のガイドラインは、アクセス管理に不慣れな利用者が不注意で情報を公開してしまうことを、ID とアクセス管理の設定不備のリスクとして挙げている^[1]。取引先向けの画面は、本番で使う前に、実際の取引先の立場のアカウント（または回答用のリンク）で開いて、見えてはいけないものが見えないかを確かめる。

そもそも取引先にアカウントを持たせるか、メールのリンクから回答してもらうかで、管理する対象が変わる。アカウントを持たせれば、取引先の担当者の異動や退職のたびに止める作業が発注側に生じる。方式の選び方はサプライヤーポータルは要るかで扱っている。

表を作った後に、壊れていく道筋を塞ぐ

権限表は、作った日がいちばん正しい。その後は、異動、退職、一時的な代行、システムの機能追加によって、少しずつ表と実際の設定がずれていく。IPA の中小企業向けガイドラインは、従業員の異動や退職等に伴う権限の変更・削除漏れ、特定の役職員等への権限集中による不正利用や権限濫用を防ぐために、アクセス権限を見直すルールを定め、権限の付与状況を管理すること、運用や利用状況を監視する仕組みを整えることを求めている^[3]。

政府機関向けのガイドラインも、不要なアクセス権限が付与されていないかを定期的に確認することとし、保守などのために一時的に付与した権限は作業が終わったら確実に削除する必要があるとしている^[2]。休暇中の承認の代行を「とりあえず承認者の権限を足しておく」で済ませると、戻し忘れた権限がそのまま残る。代行は期限つきで付け、期限の日に表と設定を突き合わせる。

システム側の変化にも気をつける。総務省のガイドラインは、IaaS や PaaS の仕様変更や機能追加などで、デフォルトで権限が広がるなどの変更が含まれる場合があると注意している^[1]。購買の SaaS でも事情は変わらない。新しい機能が加わったと案内が来たら、その機能が既存の役割の誰に開かれているかを確かめ、表に行を足す。入社・異動・退職に合わせたアカウントの発行と停止の回し方は購買システムのアカウントの発行・変更・削除で扱う。

よくある質問

購買部門が三人しかいません。六つの役割をどう割り当てればよいですか

六つの役割は仕事の区切りであって、六人を求めるものではない。三人なら、職務分掌の記事で挙げた「取引の承認・取引の記録・資産の管理」を一人ずつに分けるのが基本になる。たとえば、承認と取引先・単価マスタの変更を一人に、申請の受付と発注の作成を別の一人に、現品の受入と検収の登録をもう一人に持たせる。発注する人にマスタを直させないのは、上の権限表と同じ考え方である。システム管理は購買の外（総務や情報システムの担当）に置ければ、それがいちばん効く。どうしても一人に集まるマスは、表に印を付けて、事後の確認で補う。

システム管理者が一人しかいないと、その人が休んだときに困ります

管理者を常時二人にするより、二人目の管理者アカウントを用意して普段は使わない形にするほうが、権限が広がりにくい。使ったときは記録を残し、使った理由を後で確かめる。管理者を一人だけにした状態で、その人が辞めて誰も設定を変えられなくなる、という事態は避ける。管理者が最後の一人になったときに降格や無効化ができないようになっているかも、システムを選ぶときに確かめておくとよい。

承認者は役割で指定するのと、個人で指定するのとどちらがよいですか

役割で指定すると、異動のときに権限表の付け替えだけで済むが、その役割の人なら誰でも承認できてしまう。個人で指定すると、誰が承認したかが明確になるが、異動のたびにルールを直す必要がある。金額の大きい段は個人で、日常の段は役割で、のように混ぜるのが現実的である。承認の段数をいくつにするかは承認の段は何段にするかで扱っている。

一覧の書き出しを禁止すると、仕事が回りません

禁止しなくてよい。範囲を絞ればよい。担当している取引先の分は書き出せるが、全取引先・全期間の一括書き出しは別の権限にする、という分け方である。書き出しは、データを社外に持ち出せる操作でもある。個人情報保護委員会のガイドラインは、アクセス制御の手法の例として、情報システムによってアクセスできる個人情報データベース等を限定することを挙げている^[5]。取引先の担当者情報を含む一覧は、とくに範囲を意識する。

まとめ

購買システムの権限表は、役割（誰が）・操作（どのような操作）・データの範囲（どのリソースに対し）の三つの軸で作る^[1]。操作は参照・作成・確定・取消・書き出し・設定変更に分け、マスには可否だけでなく範囲と条件を書く。出発点は「全員が何もできない」状態で、仕事が止まる操作だけを足す^[2]。申請と許可で権限を付け、台帳として残す^[4]。システム管理の権限は業務の権限と別のアカウントにし、変更は別の人が確かめる^[1]。取引先に見せる範囲は、その取引先宛ての依頼と発注に限り、設定の誤りで余計なものが見えないかを試す^[1]。取引先の担当者情報を含むデータは、個人情報の安全管理の面からも範囲を限定する^[5]。そして、異動・代行・機能追加のたびに表と設定を突き合わせる^[3]。

出典・参考資料

1. クラウドサービス利用・提供における適切な設定のためのガイドライン（総務省／2022 年 10 月）
2. 政府機関等の対策基準策定のためのガイドライン（令和７年度版） 第３部～付録（内閣官房 国家サイバー統括室／令和 7 年 7 月 1 日・令和 8 年 10 月 1 日一部改定）
3. 中小企業の情報セキュリティ対策ガイドライン 第 4.0 版（独立行政法人情報処理推進機構（IPA）／2026 年 3 月）
4. 情報セキュリティ関連規程（サンプル）（中小企業の情報セキュリティ対策ガイドライン 付録 5）（独立行政法人情報処理推進機構（IPA））
5. 個人情報の保護に関する法律についてのガイドライン（通則編）（個人情報保護委員会／平成 28 年 11 月・令和 8 年 6 月一部改正）

WHITE PAPER

この記事の理解を深める
無料ホワイトペーパーをプレゼント

製造業の現場で使える実務資料（PDF）を無料でお届けします。"こんな資料が届きます" ↓ 下のボタンからどうぞ。

🔒 全文は無料ダウンロードで