BI導入で統制を強化する権限設計の進め方|ERP構想に備えるポイント

独自のデータとアプローチ、AIを高度に活用し、
伴走型のプロジェクト支援を得意とするコンサルティングファーム

経営のデータ活用が進む一方で、誰がどのデータにアクセスできるのかを把握できていない企業は少なくありません。BIの利用範囲が広がるほど、意図しない情報の閲覧や持ち出しといったリスクが経営の判断精度と信頼性を揺るがします。本記事では、Power BIを例に、ワークスペースやロール、行レベルセキュリティを組み合わせた権限設計の考え方を整理します。さらに、ERP構想の初期段階でBI権限設計を位置づけることが、全社統制と業務効率を両立させる鍵になることを解説します。ERP導入を検討されているCxOや管理職の方が、データガバナンスを事業戦略の一部として捉えるための視点を提供します。

Power BIとBI権限設計が統制強化の起点となる理由

BI導入における統制の意味と経営課題

BI導入における統制とは、データの取得、加工、共有、閲覧の各段階で誰が何にアクセスできるかを明確に定め、その状態を継続的に保つことを指します。売上高100億円以上の企業では、経営判断の根拠となる数値が複数のレポートで利用されるため、数値の正確性と管理責任の所在が経営課題になります。BI導入の成否は、ツールの機能よりも権限設計の質によって決まるといえます。統制を後付けで強化しようとすると、既に広がったレポートや共有ルールの整理に多大な工数がかかるため、導入初期からの設計が重要です。

権限設計が未整備な組織で起きやすいリスク

権限設計が未整備な組織では、閲覧だけでよい人が編集権限を持つ、退職者のアカウントが残る、機密性の高い人事や財務のデータが部門を越えて閲覧されるといった事象が起きやすくなります。特にレポートの作成者が自由にデータを共有できる状態では、誰がどのデータを持ち出したかを追跡できず、情報漏えいや誤った意思決定のリスクが高まります。こうした問題は個別の担当者の努力では解消しにくく、組織全体のルールとして仕組み化することが求められます。

ERP構想におけるBI権限設計の位置づけ

ERP構想において、BI権限設計は基幹システムのデータを活用する出口の統制を担う要素です。ERPが整備する業務データの正確性を、BIの権限設計によって適切な範囲に届けることで、全社的なデータガバナンスが成立します。ERPの投資効果を最大化するには、基幹データの整備とBI権限設計を並行して進め、両者を一体の計画として設計することが有効です。

権限設計の全体像と3階層モデル

BI権限設計の3つの階層

BI権限設計は、一般に3つの階層で整理できます。第一は環境やワークスペースといった基盤レベルの権限で、組織全体の利用範囲を定めます。第二はレポートやデータセットといったコンテンツレベルの権限で、個々の成果物への編集や閲覧を管理します。第三は行や列単位のデータレベルの権限で、閲覧できる数値の範囲を絞り込みます。各階層の権限を独立に設計し、上位から下位へ整合的に継承させることで、過不足のない統制が実現します。権限設計はセキュリティと運用効率のバランスを取ることが前提であり、過度に厳格にすると利用が停滞し、緩すぎると統制が効きません。

RBACによるロールベースの権限管理

RBACは、ユーザー個人ではなく役割(ロール)に権限を紐づけて管理する方式です。組織の職務に対応したロールを定義し、ユーザーをロールに割り当てることで、人事異動時の権限変更を最小限に抑えられます。RBACを採用することで、権限の付与理由が明確になり、監査時の説明責任も果たしやすくなります。ロールの粒度は細かすぎると管理負荷が増大するため、業務の実態に沿った数種類に絞ることが実務上のポイントです。

オブジェクト権限とデータ権限の使い分け

オブジェクト権限は、レポートやダッシュボードといった成果物そのものを閲覧、編集、共有できるかを制御します。一方、データ権限は、同じレポートを開いた場合でも閲覧者ごとに表示される数値の範囲を制御します。たとえば全社レポートを共通の成果物として共有しつつ、各拠点の責任者には自拠点の数値のみを表示させる場合に、データ権限が有効です。両者を混同すると、成果物を見せたくないのにデータだけ絞るといった設計の不整合が生じるため、目的に応じて使い分けることが重要です。

Power BIにおけるワークスペースとアクセス権の設計

ワークスペースの役割とポータルとの関係

Power BIのワークスペースは、Power BI Service上に設けられた共有フォルダのような単位であり、レポート、ダッシュボード、セマンティックモデルなどのコンテンツをまとめて管理する場所です。組織の権限設計は、このワークスペースを起点に組み立てることが実務上もっとも効果的です。ポータルは利用者が閲覧するレポートを集約する入口として機能し、作成と管理を担うワークスペースとは役割が異なります。両者を分けて設計することで、作成者の編集権限と閲覧者の参照権限を明確に切り分けられます。

4つのワークスペースロールと権限範囲

ワークスペースには管理者、メンバー、共同作成者、閲覧者の4つのロールがあります。管理者はワークスペースの全操作が可能であり、アクセス権の付与や削除も担えるため、任命は必要最小限に抑えるべきです。メンバーと共同作成者はコンテンツの編集や発行が可能ですが、権限の範囲は異なります。閲覧者は参照のみに限定されます。各ロールの権限範囲を業務単位で定義し、役職で一律に割り当てないことが統制強化の第一歩となります。

レポート作成者とデータソースの権限分離

レポート作成者が、データソースへの接続情報や認証設定まで変更できる状態は、統制上のリスクになります。データソースの接続権限はデータ管理者が担い、レポート作成者は承認済みのセマンティックモデルを利用してレポートを作成する形に分離することが望ましいです。これにより、作成者はデータの仕組みを意識せずに分析に集中でき、データソース側の設定変更も一元管理できます。

最小権限の原則を適用した運用設計

最小権限の原則とは、業務上必要な最小限の権限のみを付与する考え方です。Power BIでは、閲覧で足りる利用者に編集権限を与えない、共同作業が不要なユーザーに共同作成者を割り当てないといった運用で実現します。ワークスペースごとに利用目的と対象ユーザーを定義し、権限付与の申請と承認の流れを業務プロセスに組み込むことが重要です。権限を広く与えてから絞る運用ではなく、狭く付与してから必要に応じて拡張する運用が、監査にも耐えうる設計となります。

行レベルセキュリティ(RLS)によるデータ統制

RLSの仕組みとセマンティックモデルでの設定

行レベルセキュリティ(RLS)は、同一のレポートを共有しながら、ユーザーごとに閲覧できるデータの行を制限する機能です。たとえば、拠点ごとや部門ごとに異なるデータを表示させる場合に有効です。RLSはセマンティックモデル側で定義し、レポートごとに個別設定するのではなく、モデルを経由するすべてのレポートに一貫して適用されるようにすることが統制上の要点です。レポートごとの設定に頼ると、設定漏れや不整合が生じやすくなります。

RLS設定の前提となるライセンス・Premium容量の考え方

RLSはPower BI ProまたはPremiumライセンスで利用可能です。組織全体での導入規模や共有先の人数によって、必要なライセンス形態は変わります。大規模に運用する場合は、Premium容量の利用も含めて費用対効果を検討すべきです。月額費用の目安として、規模に応じて月額300万円から1000万円程度の投資を見込む企業も少なくありません。ライセンス設計をRLSの設計と同時に進めることで、後からの手戻りを防げます。

DAX式によるフィルター条件の定義と検証

RLSのフィルター条件は、DAX式によって定義します。ユーザーのメールアドレスとマッピング用のテーブルを突き合わせ、該当する行のみを返す式を組むのが一般的です。定義後は、Power BI Desktopや Power BI Service上で、特定ユーザーとして表示した際に想定どおりのデータのみが見えるかを検証する必要があります。検証は本番展開前に、担当者ごとに複数の代表ケースで実施することが重要です。条件の抜けや過剰な制限を事前に発見できれば、データ統制の信頼性は大きく高まります。

権限の運用・監査体制の構築

退職・異動時の権限移管とアカウント管理

BI権限設計は、制定して終わりではありません。組織の人員は常に入れ替わるため、退職や異動に伴う権限の扱いを運用ルールとして定めておくことが、統制を維持するうえで欠かせません。Power BIでは、コンテンツを作成または共有しているユーザーが退職や異動になった場合に、そのユーザーが保持していたコンテンツや権限をどう引き継ぐかを事前に決めておく必要があります。特に、担当者の個人アカウントに依存したレポートは、担当者が離れた途端に更新や管理ができなくなるリスクを抱えています。ユーザーアカウントが削除された後は30日間中断状態となり、その後に権限が削除されるため、この猶予期間を踏まえた引き継ぎ手順を整備することが重要です。

監査ログによるアクセス追跡と持ち出し防止

権限を適切に設定しても、誰がいつどのデータにアクセスしたかを把握できなければ、統制が効いているとはいえません。監査ログを取得し、アクセス状況を追跡できる状態にしておくことは、不正な閲覧や想定外のデータ持ち出しを早期に発見するための基盤となります。加えて、データの持ち出し管理は、エクスポートやファイル共有の可否を含めて明確に定義する必要があります。経営層にとって重要なのは、持ち出しを一律に禁止することではなく、業務上必要な範囲で統制を効かせ、その記録を経営判断に耐える形で残すことです。

権限棚卸しの頻度と定例化の進め方

権限は時間の経過とともに、本来の役割から乖離していく性質があります。異動時に付与された権限が削除されずに残る、プロジェクト終了後も共有が続くといった状況は、多くの組織で見られる典型的な課題です。これを防ぐためには、権限の棚卸しを定期的に実施し、誰が何の権限を持っているかを確認する仕組みが欠かせません。頻度については、年に数回の定例化を基本としつつ、組織再編や大きな人事異動のタイミングでは臨時に実施するなど、運用負荷と統制水準のバランスを取ることが現実的です。棚卸しの結果は、情報システム部門と業務部門が共通の基準で評価できるよう、記録として残しておくことが求められます。

ERP構想・導入を検討されている方へ

ERP構想とBI権限設計を一体で進める意義

ERP構想を描く際、基幹システムの機能要件やデータ統合の設計に議論が集中しがちです。しかし、ERPで蓄積された経営データをBIで活用する段階になってから権限設計を検討すると、既存の業務プロセスや組織の権限体系との整合が取れず、大幅な手戻りが生じやすくなります。ERPの導入とBI権限設計を一体で進めることで、データの定義、アクセス権限、監査要件を最初から設計に組み込むことができ、統制と運用効率の両立を実現しやすくなります。経営層が求める統制の強化は、こうした上流段階での設計判断によって初めて実効性を持つといえます。

コネクタブルーのERPコンサルティングサービスについて

コネクタブルーでは、ERP構想の策定から導入、BI権限設計を含む運用体制の構築までを一貫して支援しています。成果報酬型のAIOサービスとして提供しており、その特長は以下のとおりです。

  • 成果に連動した料金体系により、投資判断の透明性を確保できる
  • ERP、BI、データ統制を横断的に捉え、経営課題に直結した設計を行える
  • 費用相場は月額300万円から1000万円であり、規模や範囲に応じて最適な体制を組める

統制強化と業務効率化を同時に実現したい経営層にとって、構想段階から伴走できるパートナーの存在は大きな意味を持ちます。

  • Enterprise Resource Planning

Enterprise Resource Planning

Fit to Standard導入とAIベースの業務改革(BPR)
両輪の改革へ

Get In Touch

ERPプロジェクトを成功させるために

基幹システムの刷新は、お客様の社内に知識や経験を有したメンバーが少ない場合が多い一方、ERPの製品選定の難易度は高まっており、長期・大規模案件となることから、お客様にとっては非常に難易度の高いプロジェクトになるケースがほとんどです。
一般的にERP導入プロジェクトはセオリー/方法論通りに進めることが重要と言われており、確かにこのセオリーに精通していることは必要ですが、それをなぞるだけではプロジェクトを成功させるには不十分です。

私たちは、幅広いERP製品知識と、導入方法論への習熟に加え、お客様の業界・業務プロセス、企業文化への理解に基づき、セオリー/方法論の先に求められる「お客様にとって固有の創意工夫」に踏み込み、お客様と一緒にその答えを導き出すスタイルを採用しております。結果として、この部分において、これまでご支援させて頂いたクライアント企業様から最もご評価いただいております。

これからプロジェクトを立ち上げるが何から着手すべきか分からない、実行中プロジェクトの先行きが不透明化してきているなどの課題感をお持ちの場合には、まずはお気軽にお声がけ下さい。
Fit to Standardアプローチを軸として、業種・業務の複雑性によってはスクラッチ開発とのハイブリッド構成などお客様にとって最適なToBe像を幅広に、中立的な立場で示唆・提言させて頂き、プロジェクトの成功に貢献します。
基幹システムの刷新は、お客様の社内に知識や経験を有したメンバーが少ない場合が多い一方、ERPの製品選定の難易度は高まっており、長期・大規模案件となることから、お客様にとっては非常に難易度の高いプロジェクトになるケースがほとんどです。
一般的にERP導入プロジェクトはセオリー/方法論通りに進めることが重要と言われており、確かにこのセオリーに精通していることは必要ですが、それをなぞるだけではプロジェクトを成功させるには不十分です。

私たちは、幅広いERP製品知識と、導入方法論への習熟に加え、お客様の業界・業務プロセス、企業文化への理解に基づき、セオリー/方法論の先に求められる「お客様にとって固有の創意工夫」に踏み込み、お客様と一緒にその答えを導き出すスタイルを採用しております。結果として、この部分において、これまでご支援させて頂いたクライアント企業様から最もご評価いただいております。

これからプロジェクトを立ち上げるが何から着手すべきか分からない、実行中プロジェクトの先行きが不透明化してきているなどの課題感をお持ちの場合には、まずはお気軽にお声がけ下さい。
Fit to Standardアプローチを軸として、業種・業務の複雑性によってはスクラッチ開発とのハイブリッド構成などお客様にとって最適なToBe像を幅広に、中立的な立場で示唆・提言させて頂き、プロジェクトの成功に貢献します。

Contact

よくある質問(FAQ)

BI導入で統制を強化するとはどういう意味ですか?

BI導入で統制を強化するとは、社内のデータを誰がどこまで閲覧・編集・共有できるかを明確に定め、データの利用を組織のルールに沿って管理することを指します。BIツールは多くの社員がデータに触れる仕組みであるため、権限の設計が不十分だと情報漏えいや誤った意思決定につながるおそれがあります。そのため、権限設計を軸にアクセス制御、監査、運用ルールを整えることが統制強化の中核になります。部長や役員、CxOの立場では、全社のデータ活用を進めながらもガバナンスを効かせるための基盤として捉えることが重要です。

BI Access Control(BIアクセスコントロール)の考え方を取り入れ、役割ごとに必要最小限の権限を付与することで、利便性とセキュリティの両立を図ることができます。

権限設計はセキュリティと運用効率のバランスを取る必要があります。過度に厳しく設定すると現場の分析業務が停滞し、逆に緩すぎると統制が効かなくなります。自社の業務実態に合わせて、統制の強度を段階的に設計することが求められます。

BIツールの権限設計とは何ですか?

BIツールの権限設計とは、BIツール上でユーザーごとに利用できる機能やデータの範囲を定義する仕組みづくりのことです。BIツールの権限設計はデータ管理において重要であり、誰がデータソースに接続でき、誰がレポートを作成・公開でき、誰が閲覧のみ可能かを体系的に整理する必要があります。

権限設計は、組織の職務やデータの機密度に応じて設計します。たとえば、経営層向けの全社指標と、現場担当者向けの部門データでは、閲覧できる範囲が異なります。このように役割と情報の重要度を結び付けて設計することで、統制と活用の両立が可能になります。

権限設計の初期段階で役割の定義を曖昧にすると、後から例外対応が増え、管理コストが膨らみます。そのため、導入前に業務フローとデータの流れを整理しておくことが大切です。

Power BIのワークスペースの権限はどのように設定しますか?

Power BIのワークスペースの権限は、Power BI Service上でワークスペースに対してユーザーやグループを追加し、それぞれにロールを割り当てることで設定します。ワークスペースはPower BI Service上の共有フォルダであり、レポートやデータセット、ダッシュボードなどのコンテンツをまとめて管理する単位です。

設定の際は、個人単位ではなくAzure ADのセキュリティグループなどを用いてチーム単位で付与すると、人事異動時の管理負荷を抑えられます。チームの役割に応じてロールを割り当てることで、アクセス権の管理が統一されます。

また、マイワークスペースは個人専用の領域であり、共有を前提とするコンテンツはワークスペースで管理することが推奨されます。アプリを発行する際には、アプリの利用者に対して閲覧権限を付与する形で、コンテンツの公開範囲を制御できます。

Power BIのワークスペースにはどのようなロールがありますか?

Power BIのワークスペースには、管理者、メンバー、共同作成者、閲覧者の4つのロールがあります。ワークスペースには管理者・メンバー・共同作成者・閲覧者の4ロールがあり、それぞれ操作できる範囲が異なります。

管理者はワークスペースの全操作が可能であり、メンバーの追加や削除、ワークスペース設定の変更まで行えます。メンバーはコンテンツの作成・編集・発行が可能で、共同作成者はレポートの編集やデータセットの利用などを担当します。閲覧者はコンテンツを見ることのみが可能で、編集や削除は行えません。

役割に応じて適切なロールを割り当てることで、誤操作や意図しない変更を防ぐことができます。特に管理者の人数は必要最小限に絞ることが、統制強化の観点から重要です。

行レベルセキュリティ(RLS)とは何ですか?

行レベルセキュリティ(RLS)とは、同じレポートやデータセットを利用しても、ユーザーごとに閲覧できるデータの行を制限する機能です。Power BIの行レベルセキュリティ(RLS)機能は、ダッシュボードやレポートを作成して共有する際に、その対象ユーザーごとに異なるレベルのアクセス権限を設定できる仕組みです。行レベルセキュリティはユーザーごとに異なるデータを表示するため、部門や担当地域ごとにデータを分けて提供したい場合に効果を発揮します。

例えば、営業部門の担当者には自分の担当エリアの売上のみを表示し、責任者には全社の数値を表示するといった運用が可能です。レポートを個別に作成し直す必要がなくなるため、同じレポートを共有しながら情報を適切に分離できます。

RLSの設定はDAX式でフィルター条件を定義して行います。Power BI Desktopとサービスの両方で設定できるため、開発段階から運用段階まで一貫して管理できます。

RLSを使うにはどのライセンスが必要ですか?

RLSはPower BI ProまたはPremiumライセンスで利用可能です。Power BIの行レベルセキュリティはProライセンス以上で利用可能であり、Pro以上のライセンスを保有していることが前提となります。

RLSを組織で運用する際には、ユーザー数やコンテンツの共有範囲に応じてライセンス体系を検討する必要があります。Premium容量を利用すると、閲覧者を含む多くのユーザーに対してコンテンツを配布しやすくなります。

ライセンス選定は初期コストだけでなく、将来のユーザー拡大や運用体制も踏まえて判断することが重要です。大規模な全社展開を想定する場合は、Premium容量を含めた総コストを試算しておくとよいでしょう。

最小権限の原則とは何ですか? BIではどのように適用しますか?

最小権限の原則とは、ユーザーに業務遂行に必要な最小限の権限のみを付与するという考え方です。最小権限の原則を適用すべきであり、BIにおいても必要以上のデータや機能へのアクセスを与えないことが基本となります。

BIでの適用方法としては、RBAC(ロールベースアクセス制御)を用いて、職務ごとにロールを定義し、そのロールに権限を紐づける方法が一般的です。RBACを用いてロールベースで権限を管理することで、個別対応の増加を抑えながら一貫した統制を実現できます。

また、オブジェクト権限とデータ権限に基づくアクセス制御を組み合わせることで、レポートそのものへのアクセスと、その中に含まれるデータの範囲を分けて管理できます。さらに、権限設計には3つの階層があるとされ、組織、ワークスペース、コンテンツの各レベルで権限を整理することが効果的です。

退職や異動したユーザーの権限はどのように扱うべきですか?

退職や異動したユーザーの権限は、速やかに見直しや削除を行うことが望ましいです。Power BIでコンテンツを作成または共有しているユーザーが退職や異動になった場合、そのユーザーが保持していたコンテンツや権限の扱いを事前に定めておく必要があります。退職したユーザーの権限は30日後に削除され、ユーザーアカウント削除後は30日間中断状態になります。ただし、この期間に依存すると不要な権限が残るおそれがあるため、人事情報と連動した運用ルールを整えることが重要です。

具体的には、異動時にワークスペースのロールを見直し、退職時にはコンテンツの所有権を別の担当者へ引き継ぐ手順を標準化します。アクセス権はロールやセキュリティグループで管理しておくと、個人単位の変更漏れを防ぎやすくなります。

BIのデータ持ち出しを防ぐにはどうすればよいですか?

BIのデータ持ち出しを防ぐには、データの持ち出し管理を厳格に行い、エクスポートや共有の範囲を制御することが重要です。データの持ち出し管理が重要であり、機密データを扱うレポートについては、ダウンロードや外部共有の可否を権限で制限する必要があります。

また、監査ログによってアクセス状況を追跡可能にすることで、誰がいつどのデータにアクセスし、どのような操作を行ったかを把握できます。監査ログを定期的に確認する体制を整えることで、不正な持ち出しの兆候を早期に検知しやすくなります。

さらに、機密データを含むレポートは専用のワークスペースに配置し、閲覧者を必要最小限に限定することが有効です。アプリ単位で公開範囲を絞り込むことも、持ち出しリスクの抑制につながります。

権限の棚卸しはどのくらいの頻度で行えばよいですか?

権限の棚卸しは定期的に行うことが望ましく、一般的には四半期ごとや半期ごとに実施する方法が考えられます。権限の棚卸しを定期的に行うべきであり、組織の人事異動の頻度やデータの機密度に応じて頻度を決めることが大切です。

棚卸しでは、ワークスペースのメンバー、ロールの割り当て状況、RLSの設定内容、共有されているアプリの利用者などを確認します。不要になった権限は速やかに削除し、必要な権限が適切に付与されているかを検証します。

また、システム的な変更がある場合や大きな組織改編の後には、通常の周期を待たずに臨時で棚卸しを実施することも有効です。定期的な見直しを仕組み化することで、統制の実効性を維持できます。