2026.11.08 業務システム

Power BI DesktopとServiceの違い：発行から更新・ゲートウェイ設定まで

Power BI DesktopはWindowsで動く無料の作成ツールで、Power BI Service（Microsoft Learnの日本語版では「Power BI サービス」）はブラウザで使うクラウドの共有基盤です。配布・自動更新・社内データベースへの接続は、すべてService側で設定します。この記事では、両者の機能の境界、発行と再発行で置き換わる範囲、ワークスペースのロールとライセンス、スケジュール更新の上限、ゲートウェイの選び方、REST APIで更新の失敗を点検するコード例までを作業の順に示します。仕様の根拠は2026年11月時点のMicrosoft Learnの記述です。

まとめ：DesktopとServiceの違いはモデルを作る場所と配って更新する場所の分担

データの取り込み、Power Queryでの加工、DAXのメジャー、レポートの作成はDesktopで行います。完成したファイルを[発行]でServiceのワークスペースへ送ると、そこから先の共有・自動更新・権限管理はServiceが担う仕事です。Serviceでもモデルの編集はできますが、Desktopのファイルには戻らないため、正本をどちらに置くかを最初に決めておきます。

発行しただけではデータは更新されません。資格情報とゲートウェイと時刻を設定して初めて自動更新が動き、止まったときに気付く点検まで用意するのが、Serviceを業務で使うときの最低ラインです。

Power BI DesktopとPower BI Serviceの役割と機能の境界線

両者は同じ製品の2つの画面ではなく、動く場所もライセンスの扱いも違う別のソフトウェアです。

Windows専用のDesktopとブラウザで使うServiceの動作条件の違い

Power BI Desktopのダウンロードのページによると、Desktopの最小要件はWindows 10またはWindows Server 2016以降、.NET 4.7.2以降、使えるメモリ2GB以上（4GB推奨）、画面解像度1440×900以上です。毎月更新され、サポートされるのは最新版だけです。Microsoft Store版は自動で更新され、インストールに管理者特権が要りません。社内PCに配るなら、更新を利用者任せにしないStore版が扱いやすい選択です。

Serviceはブラウザで開くSaaSで、Desktop自体は無料でも、Serviceで他の人と共有するには有償ライセンスが要ります。

Desktopにしかない機能とServiceにしかない機能の比較表

作業の種類ごとに、どちらで行うかを整理すると次のようになります。

作業	Power BI Desktop	Power BI Service
データソースの列名変更に追従するスキーマ更新	可	不可（更新が失敗する）
メジャー・リレーションシップ・RLSロールの編集	可	可（Webでのモデル編集）
ダッシュボードの作成	不可	可
スケジュール更新・ゲートウェイの割り当て	不可	可
ワークスペースのロール管理・アプリ配布	不可	可
PBIPでのテキスト保存とGit管理	可	不可

実務で一番効くのは1行目です。Power BIでのデータの更新の説明では、元のデータベースで列やテーブルの名前を変えたり削除したりするとServiceの更新は失敗し、直すにはDesktopでスキーマを更新して再発行する必要があります。データの構造が変わる作業は、必ずDesktopに戻って行う必要があるのです。ダッシュボードの作り方はPower BIのダッシュボードの作り方とピン留めの手順で扱っています。

Serviceのモデル編集で直せる範囲と、自動保存で元に戻せない注意点

Serviceでセマンティックモデルを編集する機能を使うと、ブラウザ上でメジャー・計算列・計算テーブル・リレーションシップ・RLSのロールを作り、Power Queryの[データの変換]も開けます。Desktopが無いMacでも、メジャーを1本足す程度なら直せます。

変更は自動で保存され、元に戻す操作はありません。誤った変更はバージョン履歴から戻します。ライブ接続のモデルは開けず、管理ポータルで機能ごと無効にされている組織もあります。

DesktopからServiceへ発行する手順と再発行で上書きされる範囲

発行は1クリックで終わりますが、2回目以降の再発行で事故が起きやすい作業です。

[発行]でワークスペースへ送る手順とProライセンスが要る条件

Power BI Desktopからの発行の手順は次のとおりです。

Desktopで[ファイル]＞[発行]＞[Power BI へ発行]、または[ホーム]リボンの[発行]を選ぶ
Power BIにサインインしていなければサインインする
発行先のワークスペースを検索して選び、[選択]を押す
完了画面のリンクから、Serviceでレポートを開いて表示を確かめる

発行すると、ファイルと同じ名前のセマンティックモデルとレポートができます。マイワークスペース以外へ送るには、Pro（またはPremium Per User）のライセンスが必要です。ライセンスがないまま共有のワークスペースへ発行すると「Power BI Pro ライセンスを持つユーザーのみがこのワークスペースに発行できます」というエラーで止まります。

再発行で置き換わるものと、名前の重複・ストレージモード変更の失敗

同じファイルを再発行すると、Service上のセマンティックモデルがファイルの内容で置き換わります。影響を受けるワークスペース・レポート・ダッシュボードの数が確認ダイアログに出るので、他部署のレポートがつながっていないかをここで確かめます。発行ページの注意事項のうち、運用で引っかかりやすいものは次のとおりです。

列やメジャーの名前を変えたり消したりすると、そのフィールドを使うService上のビジュアルが壊れる
同じ名前のセマンティックモデルがワークスペースに複数あると発行が失敗する
インポートで発行したものをDirectQueryやライブ接続のファイルで上書きすることはできない
更新スケジュールがあるモデルは、再発行の直後に更新が始まる
新しいデータソースを足して再発行したら、次の定時更新より前にServiceで資格情報を入れる

4つ目があるため、大きなモデルの再発行は業務時間を避けます。

Serviceで直した内容が再発行で消える事故とPBIPで正本を管理する方法

発行ページには、Serviceでレポートに加えた変更は元のDesktopファイルに保存されないと書かれています。Serviceで誰かがグラフを1枚足した後に、手元の古いファイルを再発行すると、その追加は保持されず、消えることになるのです。防ぐには、正本をDesktopのファイルに決め、Serviceでの直接編集を禁止するか、Serviceで直した場合は[PBIXファイルのダウンロード]で取り直してから作業します。ダウンロードできるのは共同作成者以上のロールです。

複数人で作るなら、Power BI Desktopプロジェクト（PBIP）として保存し、Gitで管理します。PBIPではレポートとモデルが.Reportと.SemanticModelのフォルダーにテキストファイルとして分かれ、変更の差分を追えます。Desktopが作る.gitignoreの既定値は次の2行で、ローカルのデータキャッシュは履歴に入りません。

**/.pbi/localSettings.json
**/.pbi/cache.abf

PBIPはWindowsのパス長の上限260文字に掛かることがあるため、リポジトリはドライブ直下の短いフォルダーに置きます。

ワークスペースのロールとライセンスで決まる社内の共有範囲の設計

ワークスペースに誰をどのロールで入れるかで、見られる人と直せる人が決まります。

Free・Pro・PPU・容量ワークスペースで変わる発行と閲覧の条件

ライセンスの種類別機能を、ワークスペースが共有容量にあるか、Premium容量（またはFabricのF64以上）にあるかで並べると次のようになります。

ライセンス	共有容量のワークスペース	Premium容量・F64以上で追加される範囲
Fabric（Free）	自分で作ったコンテンツのみ	Pro・PPUの人が共有したものを閲覧
Power BI Pro	発行・共有はProの人どうし	Free・PPUの人へ配布
Premium Per User	発行・共有はPPUの人どうし	Free・Proの人へ配布

判断を分けるのは閲覧者の人数です。共有容量では見る人全員にProが要るため、閲覧だけの人が多い会社ほど容量ワークスペースのほうが安く済む分岐点があります。料金の全体像はPower BIのできること・料金とExcelやTableauとの違いにまとめています。

管理者・メンバー・共同作成者・ビューアーの権限差と更新を直せる人

ワークスペースのロールは4段階です。コンテンツの編集、ゲートウェイ経由の更新スケジュール設定、PBIXのダウンロードは共同作成者以上、アプリの発行はメンバー以上、ユーザーの削除は管理者だけです。ゲートウェイ経由の更新には、ゲートウェイ側の利用許可も別に要ります。

レポートを見るだけの人はビューアーに入れます。行レベルセキュリティ（RLS）が効くのはビューアーだけで、共同作成者以上には絞り込みが掛からないからです。RLSの仕組み自体はRLSの仕組みとDB別の設定例で解説しています。メンバーは既存ユーザーのロールを変えられないため、ビューアーを共同作成者に上げる作業は管理者が行います。

Power BI Serviceでスケジュール更新を設定する手順と回数の上限

Desktopでは[更新]ボタンを押せばデータが新しくなりますが、Serviceでは更新の設定をしない限り、発行した時点のデータのまま止まっています。

インポート・DirectQuery・ライブ接続で変わるスケジュール更新の要否

スケジュール更新が必要なのは、データをモデルに取り込むインポートモードだけです。DirectQueryとライブ接続はレポートを操作するたびに元のデータソースへ問い合わせるため、データの更新は要りません。ただしダッシュボードにピン留めしたタイルの更新は約1時間ごとなので、DirectQueryでもタイルの数字にはレポートとの時間差が出ます。

モードはDesktopで決め、再発行では切り替えられないため、発行前に鮮度の要件から選びます。

定時更新の資格情報・ゲートウェイ・時刻・失敗通知を設定する手順

更新スケジュールの構成では、次の順に設定します。

ワークスペースの一覧でセマンティックモデルを選び、[更新]＞[更新のスケジュール]を開く
[ゲートウェイとクラウド接続]で、社内のデータソースに使うゲートウェイを選ぶ（クラウドだけなら不要）
[データソースの資格情報]でデータベースのユーザーとパスワードを入れる
[更新スケジュールの構成]を[オン]にし、タイムゾーンを日本時間（UTC+09:00）にして曜日と時刻を足す
失敗時のメール通知先に、所有者以外の担当者かチームのアドレスを足して[適用]を押す

時刻は目安で、15分以内の開始を目標としつつ最大1時間遅れることがあります。月に1回だけ更新する選択肢はないため、月次の更新はPower Automateから起動します。

1日8回と48回の上限、2時間の制限、非アクティブと失敗で止まる条件

Learnの更新ページから、運用設計に効く数値を拾うと次のとおりです。

定時更新は、共有容量（Pro）で1日8回、PPU・Premium容量・Fabric容量で1日48回まで
共有容量の8回にはREST API経由の更新も含まれ、画面の[今すぐ更新]は含まれない
1回の更新は共有容量で2時間以内、Premiumで5時間以内に終わる必要がある
2か月間、そのモデルのレポートやダッシュボードを誰も開かないと定時更新が一時停止する
4回続けて失敗するか、資格情報の期限切れなど直さないと回復しない誤りで定時更新が無効になる

最後の2つは所有者にメールが届くだけなので、所有者が異動すると誰も気付きません。資格情報もモデルの所有者1人に紐づくため、担当が変わったら設定画面の[引き継ぎ]で所有者を移します。

オンプレミスのデータに届くゲートウェイの選び方と発行後の接続設定

社内のSQL Serverやファイルサーバーのデータを定時更新するには、社内ネットワークにゲートウェイを置きます。オンプレミスデータゲートウェイは送信方向の通信だけで動き、受信ポートを開ける必要はありません。

標準モードと個人用モードの違いと、検証段階で個人用で済ませてよい条件

ゲートウェイには標準モードと個人用モードがあります。個人用ゲートウェイのページの比較から、選定に効く行を抜き出します。

項目	標準モード	個人用モード
使える人	許可された複数のユーザー	インストールした本人だけ
対応する接続	インポート・DirectQuery・ライブ接続	インポートのみ
動き方	Windowsサービス・クラスター構成可	サインインしたままの対話型アプリ
データソースと資格情報の管理	ゲートウェイ管理者が一元管理	モデルごとに本人が設定

個人用は1人1台までで、別のPCに入れると前のPCの分は置き換わります。対話型アプリなので、そのPCの電源が落ちていたりサインアウトしていたりすると更新は失敗します。個人用で済ませてよいのは、作る人も見る人も実質1人の検証段階だけです。部署で使うレポートは、常時稼働のサーバーに標準モードを入れます。サポートされるのは毎月出る最新6リリースなので、半年に1回は更新します。

発行後に手動で割り当てるゲートウェイ接続と1モデル1接続の制約

見落としやすいのは、Desktopから発行したモデルにはゲートウェイ接続が自動では設定されない点です。Serviceのモデル編集のページにも、発行後にセマンティックモデル設定の[ゲートウェイ接続]で手動で設定する必要があると書かれています。初回の発行後は、前の章の手順2で必ずゲートウェイを選びます。

もう1つの制約は、1つのセマンティックモデルが使えるゲートウェイ接続は1つだけという点です。社内のSQL Serverとクラウドのデータベースを1つのクエリで結合する場合は、クラウド側の接続も同じゲートウェイ経由になります。Desktopで設定したプライバシーレベルも発行されないため、発行後に再設定が必要です。Accessファイル（.accdb）を定時更新する場合の64ビットACEや匿名認証、パスの一致といった具体的な設定はPower BIとAccessの連携：接続手順・ACEエラー・ゲートウェイ更新とDB移行で手順を追って解説しています。データソースが部署ごとに散らばっているなら、先にデータを1か所に集めるほうが運用は軽くなります。その考え方はDWHの仕組みとDBとの違いで整理しています。

REST APIでワークスペースの更新スケジュールと失敗を点検する手順

モデルが10本を超えると、設定画面を1つずつ開く点検は続きません。REST APIで一覧を取り、止まったモデルだけを洗い出します。

モデル一覧・更新スケジュール・直近の更新結果を取るPythonのコード例

Azure CLIでPower BIのアクセストークンを取り、点検したいワークスペースのIDと一緒に環境変数へ入れます。ワークスペースIDは、ServiceでワークスペースのURLのgroups/の後ろにある文字列です。

export PBI_TOKEN=$(az account get-access-token --resource https://analysis.windows.net/powerbi/api --query accessToken -o tsv)
export WS_ID=点検するワークスペースID
python3 audit_refresh.py

次のPythonは標準ライブラリだけで動きます。ワークスペース内のセマンティックモデルごとに、所有者・ゲートウェイの要否・定時更新の有効無効・直近の更新結果を1行ずつ出します。

import json, os, urllib.request, urllib.error

BASE = "https://api.powerbi.com/v1.0/myorg/groups/" + os.environ["WS_ID"]
HDR = {"Authorization": "Bearer " + os.environ["PBI_TOKEN"]}


def get(path):
    req = urllib.request.Request(BASE + path, headers=HDR)
    with urllib.request.urlopen(req, timeout=60) as r:
        return json.load(r)


for ds in get("/datasets")["value"]:          # Get Datasets In Group
    name, ds_id = ds["name"], ds["id"]
    owner = ds.get("configuredBy", "不明")
    gw = "要" if ds.get("isOnPremGatewayRequired") else "不要"
    try:
        sch = get(f"/datasets/{ds_id}/refreshSchedule")          # Get Refresh Schedule In Group
        plan = ("有効 " if sch["enabled"] else "無効 ") + ",".join(sch["times"])
    except urllib.error.HTTPError as e:
        plan = f"取得不可(HTTP {e.code})"   # DirectQuery などスケジュールを持たないモデル
    hist = get(f"/datasets/{ds_id}/refreshes?$top=1")["value"]  # Get Refresh History In Group
    if hist:
        last = hist[0]
        code = json.loads(last.get("serviceExceptionJson") or "{}").get("errorCode", "")
        result = f'{last["status"]} {last.get("refreshType", "")} {code}'.strip()
    else:
        result = "履歴なし"
    print(f"{name}\t所有者={owner}\tゲートウェイ={gw}\t定時更新={plan}\t直近={result}")

呼んでいるのはGet Datasets In Group、Get Refresh Schedule In Group、Get Refresh History In Groupの3つで、スコープはDataset.Read.All以上です。読み取りの権限しかないと一覧の応答が名前とIDだけに絞られ、更新履歴も取れないため、実行するアカウントはそのワークスペースの共同作成者以上にします。

点検結果で拾う無効化・失敗コードと手動更新を足すときの回数制限

最初に見るのは「定時更新=無効」の行で、設定した覚えがあれば非アクティブか連続失敗で止められています。次に「直近=Failed」の行のエラーコードを見ます。リファレンスの例にあるModelRefreshFailed_CredentialsNotSpecifiedは資格情報の未設定で、データソースを足して再発行した後に起きやすい失敗です。所有者の欄に異動者がいれば[引き継ぎ]の対象です。

見つけたモデルをAPIで更新し直すときは回数に注意します。Refresh Dataset In Groupは、共有容量では定時更新と合わせて1日8要求までです。一斉に更新し直すスクリプトを毎朝回すと、定時更新の枠を食い潰します。更新の起動を待ち合わせるコードやPBIXの発行の自動化はPower BIのAPI連携：Web APIの取り込みとREST APIで更新・発行を自動化する手順で解説しています。

Desktopだけで済ませるか、Serviceの共有と自動更新まで組むかの判断基準

Serviceの設定は手間がかかるぶん、組まなくてよい場面もはっきりしています。

Desktopとファイル共有で済ませてよい条件と、PBIX配布を見送る場面

Desktopだけで済ませてよいのは、作る人と見る人が同じで、更新が月数回の手作業で足りる場合です。経理担当が月次の締め後にCSVを差し替えて自分で見る使い方なら、ライセンスもゲートウェイも要りません。

反対に、PBIXファイルをメールや共有フォルダーで配る運用は採りません。インポートモードのPBIXには取り込んだデータがそのまま入っているため、受け取った人は全データを見られ、RLSで絞り込めません。どのファイルが最新かも分からなくなります。2人以上で見るレポートは、Serviceへ発行してビューアーとして見せます。

ゲートウェイやワークスペース設計まで外部の支援に任せる範囲と判断基準

レポート作成と発行は社内で十分にこなせます。詰まるのはその後ろで、ゲートウェイの置き場所が決まらない、ワークスペースが乱立してモデルの所有者が分からない、という状態では更新の失敗を追えません。部署ごとの使われ方の例はPower BIの導入例と単体で足りる範囲で紹介しています。

ゲートウェイの構成やワークスペースとロールの設計、データの持ち方から見直す段階になったら、BIツール導入支援で現在のレポートと更新の流れを確認したうえで、社内で運用する範囲と任せる範囲を切り分けられます。

Power BI DesktopとServiceの違いについてよくある質問

DesktopとServiceの使い分けで寄せられやすい質問に、Microsoft Learnの記述を根拠に答えます。

Power BI ServiceとPower BI サービスは同じものですか？

同じものです。英語の製品名がPower BI Serviceで、Microsoft Learnの日本語版では「Power BI サービス」と訳されています。ブラウザでapp.powerbi.comを開いて使うクラウドの側を指し、Windowsにインストールして使うPower BI Desktopと対になる名前です。

Power BI Desktopとは何ですか？無料で使えますか？

データの取り込み・加工・モデル作成・レポート作成を行うWindows用のアプリで、無料でダウンロードできます。Microsoft Store版とダウンロードセンターの実行ファイル版があり、Store版は自動で更新されます。作ったレポートを他の人とServiceで共有する段階になると、ProかPremium Per Userのライセンスが必要です。

MacでPower BI Desktopは使えますか？

Desktopの最小要件はWindows 10またはWindows Server 2016以降で、macOSは含まれていません。Macではブラウザで開くServiceでの閲覧と、Webでのモデル編集・レポート編集が使えます。Desktopの機能が必要なら、Microsoftが完全サポートとしているAzure Virtual DesktopかWindows 365で動かします。