Power BI推奨/認定（Endorsement）で“正”のモデルを作る：全社ガバナンス入門

Power BI を組織で使い始めると、最初に伸びるのは「レポートの数」です。現場のスピード感は上がりますが、一定規模を超えると別の問題が必ず起こります。

• 同じ売上なのに、部署ごとに数字が違う

• 似たようなセマンティックモデル（データセット）が増えて、どれが正しいか分からない

• 会議のたびに「この数字の定義は？」から始まる

• 引き継ぎができず、“作った人しか分からない”資産が増える

• 間違ったレポートが共有され、意思決定に影響が出る

この状況で重要なのは、すべてを中央で縛ることではありません。現場の自走を止めずに、「これは信頼して使っていい」という目印を作り、利用者が迷わない状態を作ることです。
そこで効くのが 推奨/認定（Endorsement） です。

推奨/認定は、Power BI のコンテンツ（特にセマンティックモデル）に「公式」「信頼できる」といった“格付け”を与え、組織としての“正”を作るための機能です。この記事では、推奨/認定をどう設計し、どう運用すれば「全社ガバナンス」と「現場のスピード」を両立できるのかを、分かりやすく整理します。

1. 推奨/認定が効く場面は「検索と共有が増えた後」

個人利用や少人数チームでは、誰が何を作っているか把握しやすく、口頭で補えます。
一方、閲覧者が増えて「探して使う」フェーズに入ると、利用者はこう考えます。

“たくさんある中で、どれを使えば安全？”

この問いに答えられないと、現場は次のどちらかに流れます。

• 怖いから使わない（結局Excelに戻る）

• 自分でまた作る（乱立が加速する）

推奨/認定は、ここに対して「使って良いもの」を目立たせ、選びやすくする仕組みです。
導入効果が出やすいのは、次の兆候が見えてきたタイミングです。

• ワークスペースやレポートが増え、検索して探す人が増えた

• “売上モデル”のような基幹モデルが複数存在している

• 共有リンクが飛び交い、正しい入口が分からない

• BI運用担当（センター/情シス/データチーム）が立ち上がり始めた

2. 「推奨」と「認定」の役割を分けると、運用が壊れない

推奨/認定は、運用の作り方がすべてです。まず最初に決めたいのが、推奨（Promoted） と 認定（Certified） をどう使い分けるかです。

推奨（Promoted）：現場で広めたい“優良”コンテンツの目印

推奨は、「よくできていて再利用してほしい」「まずこれを使ってほしい」という“おすすめ”の位置付けで使うと効果的です。
運用上は、次の性格に向いています。

• 部門内の標準モデル

• チーム内で合意したKPIの基準

• 作成者が明確で、更新が安定している

• まだ全社公式ではないが、利用を促進したい

推奨は、現場のスピード感を活かしつつ、良い資産を埋もれさせないための仕組みです。

認定（Certified）：全社として“正”と宣言する公式コンテンツ

認定は、より強い意味を持たせるべきです。
「会社としてこの定義が正」「意思決定の根拠にして良い」と言い切るレベルにすると、認定の価値が上がります。

• 経営指標や全社KPIの基準モデル

• 重要会議で使う数字の“唯一の正”

• データ定義、品質、更新、権限が統制されている

• 変更管理（影響範囲の確認、リリース手順）が整っている

ポイントは、認定を乱発しないことです。
“認定が多すぎる”と、利用者は結局迷います。認定は少数精鋭にすると運用が安定します。

3. 推奨/認定で作るべきは「正しいレポート」ではなく「正しいモデル」

推奨/認定はレポートにも効きますが、ガバナンス上の本命は セマンティックモデル（データセット） の統一です。理由はシンプルです。

• レポートは見せ方が違うだけで、目的別に増えやすい

• “数字の定義”はモデル側に置いた方が一貫する

• モデルが統一されると、レポートは薄く作れて乱立しにくい

• 権限・更新・品質の管理をモデル単位で行える

つまり、推奨/認定は「このレポートが正しい」よりも、
「このモデルから作るレポートは同じ定義になる」 を実現するために使うのが強いです。

4. 全社ガバナンス入門：最初に決めるべき5つのルール

推奨/認定は“付けること”より“維持すること”が難しいです。維持できる運用にするために、最初に最低限これだけ決めると失敗しにくくなります。

① 何を認定するか（対象範囲）

• まずは「基幹モデル」だけ認定する（売上、粗利、在庫、人事など）

• レポートは推奨止まりにして、認定を増やしすぎない
  このように対象を絞ると、運用が回ります。

② 誰が決めるか（承認者・責任者）

• 認定は“責任を持てる組織”が付与する（データ/BIの中核チームなど）

• 推奨は部門責任者やワークスペース管理者が付けられるようにする
  意思決定のルートを分けると、スピードと統制が両立します。

③ 何を満たしたら認定か（認定基準）

認定基準は難しくしすぎると止まります。最初は次のような現実的な項目で十分です。

• 指標定義（KPIの算出ロジック）が文書化されている

• 更新が安定している（更新頻度・失敗時対応が決まっている）

• データ品質のチェック（欠損、異常値）が最低限ある

• オーナーが明確（問い合わせ先、改修担当）

• 権限（閲覧範囲）が適切

④ 変更管理をどうするか（壊さない仕組み）

認定モデルは、変更すると下流のレポートが壊れる可能性があります。
そのため、少なくとも次を運用ルールに入れるのが安全です。

• 変更前に影響範囲を確認する

• 重要変更は検証→本番の順で反映する

• 定義変更は周知する（いつから数字が変わるか明確化）

⑤ 期限と棚卸し（“認定しっぱなし”を防ぐ）

認定は「付けた瞬間」より「付け続けられるか」が重要です。
棚卸しを決めないと、古い基準の認定が残り、逆に混乱を招きます。

• 四半期に1回：認定モデルの棚卸し

• 半期に1回：推奨モデルの整理（重複の統合）
  このくらいの頻度でも十分効果があります。

5. 推奨/認定を“活用度”につなげる設計（ここが差になる）

推奨/認定を付けても、利用者がそれに気づかなければ意味がありません。
活用につなげるには、「目印」＋「入口」＋「使い方」をセットにするのがコツです。

5-1. 入口を一本化する（迷子を防ぐ）

• 全社向けのアプリ配信で「公式モデル」「公式レ पोート」をまとめる

• 部門向けも同様に、推奨コンテンツはアプリに集約する
  入口が散らばると、認定しても発見されにくくなります。

5-2. “何が正か”を言語化する（利用者の不安を消す）

モデルやレポートの説明欄などに、短くても良いので以下を書きます。

• 対象範囲（どの部門/どの期間/どの粒度か）

• 主な指標の定義（例：売上は税抜、返品は控除…など）

• 更新頻度（毎日○時、月次○営業日…）

• 問い合わせ先（モデルオーナー）

これだけで「安心して使える」状態に近づきます。

5-3. “推奨→認定”の昇格ルートを作る

いきなり認定基準を満たすのは難しいことが多いです。
そこで、推奨を「育成枠」として使い、一定条件を満たしたら認定へ昇格する流れを作ると運用が回ります。

• 推奨：部門内の標準として運用開始

• 運用が安定：問い合わせが減る、更新が安定する

• 認定：全社展開し、唯一の正として宣言する

6. よくある失敗と、避けるための現実解

最後に、推奨/認定でありがちな失敗と対策をまとめます。ここを押さえると、一気に実務向けになります。

失敗①：認定を増やしすぎて、結局迷う

対策： 認定は少数精鋭。まずは「全社KPIの中核モデル」に限定する。推奨は多めでもよい。

失敗②：認定したのに、古くなって信用が落ちる

対策： 棚卸し（定期点検）を仕組みに入れる。更新失敗・データ欠損が起きたら、認定維持の条件を満たしているか再確認する。

失敗③：認定モデルを誰でも変更できて、下流が壊れる

対策： 認定モデルの変更は責任者を限定し、変更前の影響確認と検証の手順を必須にする。

失敗④：推奨/認定が形骸化して、誰も気にしない

対策： 入口（アプリ配信）に集約し、「まずこれを使う」を明示する。会議や業務プロセスで“認定モデルの数字”を参照する運用に寄せる。

失敗⑤：現場の自走を止めて反発が出る

対策： 認定は“全社の正”だけに絞り、現場の自由領域は推奨で支援する。「全部を中央で統制」ではなく「正の基準を提供し、現場は再利用して速く作れる」形が理想。

まとめ：推奨/認定は“正の道しるべ”。少数精鋭の認定と、育つ推奨で回す

推奨/認定（Endorsement）は、Power BI を全社で使うための“道しるべ”です。
乱立を完全に止める魔法ではありませんが、利用者が迷う原因を減らし、「このモデルを使えば安心」という基準を作れます。

• 認定は全社の“正”として少数精鋭で運用する

• 推奨は現場で育つ標準として広く使い、良い資産を埋もれさせない

• 本命はレポートではなく、セマンティックモデルの統一

• 入口の一本化、説明の整備、変更管理、棚卸しで“維持”する

この設計に寄せると、Power BI は「作りっぱなし」ではなく「育つ資産」になります。
まずは、最重要な基幹モデルを1つだけ選び、推奨→認定の流れを作るところから始めるのが、いちばん失敗しにくい一歩です。