Claude Code × Microsoft Fabric (3) － Power BI レポートを AI に作らせる：.pbip を使ったビジュアルページの自動生成

Posted at 2026-05-19

想定読者

Power BI Desktop で日々ビジュアル作成しているデータエンジニア・BI エンジニア

AI エージェント（Claude Code 等）に Power BI レポート作成を任せられないか模索している方

.pbip（Power BI Project）形式を実用ベースで活用したい方

TL;DR

Power BI レポートは .pbip（Power BI Project）形式で保存すると、レポート定義が JSON テキストに分解されます。中でも 1 ビジュアル 1 ファイルの visual.json はシンプルな JSON 構造で、Claude Code が直接書けるレベルのテキストです。

.pbix（バイナリ・1 ファイル）             AI が中を編集できない
.pbip（テキスト・数百ファイル JSON）       AI が直接生成・編集できる

Semantic Model 側に列名・メジャー名が整っていれば、visual.json で Entity / Property を 2 つ指定するだけでデータバインディングが完了します。

筆者の環境では、この方式で 4 つの Semantic Model にまたがる 30+ ページ・90+ ビジュアルを AI 駆動で生成しました。Power BI Desktop の GUI でドラッグ&ドロップでビジュアルを置く工程が、自然言語のページ仕様 → JSON 自動生成 → Desktop で開いて微調整、というフローに置き換わりました。

しかも、この一連の流れは /pbip-visual という Claude Code Skill にパッケージング済みで、既存レポートへのページ追加だけでなく、ゼロから新規 .pbip プロジェクトを立ち上げるところも AI 駆動で完結します。Semantic Model さえ整備されていれば、Power BI Desktop を一度も開かずにレポートプロジェクトを初期セットアップできます。

本記事では、.pbip 形式の最小解剖から、visual.json の核心構造、実証ケース 2 つ（PoC + 量産パターン）、そして /pbip-visual という Claude Code Skill 化まで、約 1 か月の実運用ベースで共有します。

1. 前回までのおさらい

第 1 回（土台編）では、Power BI モノリスから Microsoft Fabric への移行を進めている 開発スタック全体 を紹介しました。

第 2 回（カバー拡大）では、Claude Code から Fabric を動かす 2 つの MCP Server の使い分け・配布形態の違い・実践ケースとして「Semantic Model 側の列名を AI に日本語化させる」例を扱いました。

今回（第 3 回）は、その先 — レポートページ自体を AI に組ませる アプローチです。第 2 回が「AI に列を選ばせるために Semantic Model を整える」話だったのに対し、第 3 回は 整えた Semantic Model を前提に、その上に乗るレポートページを AI に書かせる 話になります。第 2 回と本記事はゆるく直列関係にあります。

2. `.pbip` 形式の最小解剖

.pbip は .pbix の テキストベース版です。レポート定義が JSON ファイルに分解されて、Git でのバージョン管理・diff・マージ・そして AI による直接生成 が可能になります。

2.1 `.pbix` vs `.pbip` の違い

項目	`.pbix` / `.pbit`	`.pbip`
ファイル形式	バイナリ（ZIP 圧縮）	テキスト（JSON）
Git diff	不可能	可能（ビジュアル単位）
マージコンフリクト	解決不能	JSON レベルで解決可能
AI による直接編集	不可能	可能（本記事の主題）
ファイル数	1 ファイル	数百ファイル（ビジュアル数に比例）
Fabric Git 統合	—	同等の構造が自動管理される

2.2 `.pbip` としての保存方法（意外と知られていない）

.pbip 保存は Power BI Desktop の プレビュー機能で、デフォルトでは無効になっています。次の手順で有効化が必要です。

Power BI Desktop で [ファイル] → [オプションと設定] → [オプション] を開く
左メニューから [プレビュー機能] を選択
[Power BI プロジェクト (.pbip) 保存オプション] にチェックを入れる
Power BI Desktop を再起動

有効化後、[ファイル] → [名前を付けて保存] でファイル形式に .pbip が選択肢として現れます。既存の .pbix を開いて .pbip で保存すれば、テキストベース形式に変換されます。

逆方向（.pbip → .pbix）も [名前を付けて保存] でいつでも戻せます。試しに保存形式を変えても元に戻せるので、まず手元のレポートで .pbip 化して中身を覗いてみる、というのが入口としておすすめです。

注: .pbip 保存は執筆時点で プレビュー段階です。プロダクション運用前に最新の制限事項を公式ドキュメントで確認してください。

2.3 骨格 3 ファイル

数百ファイルといっても、AI に書かせる観点で 重要なのは 3 つだけです。

ファイル	役割	AI に書かせる頻度
`.pbip`	エントリポイント。`{"artifacts": [{"report": {"path": "..."}}]}` のみ	初回のみ
`definition.pbir`	どの Semantic Model に接続するかの参照	初回のみ
`visual.json`	ビジュアル 1 つ分の定義（type / position / queries / objects）	毎回

つまり、新規ページ追加は page.json（1 つ）+ visual.json（複数）を生成する作業 に集約されます。

2.4 ディレクトリ構造の実物

{name}.pbip                          ← エントリ JSON
{name}.Report/
├── definition.pbir                  ← Semantic Model 接続
├── definition/
│   ├── report.json                  ← テーマ・全体設定
│   ├── pages/
│   │   └── pages.json               ← ページ一覧 + activePageName
│   │   └── {hash}/                  ← ページ 1 つ
│   │       ├── page.json
│   │       └── visuals/
│   │           └── {hash}/
│   │               └── visual.json  ← ★ ビジュアル 1 つ
│   └── ...
└── StaticResources/
    └── ...                          ← テーマ JSON 等

{hash} 部分は ランダム生成で OK（後述）です。

3. visual.json の核心構造 — なぜ AI に書かせやすいか

ここが本記事の核心です。

visual.json の構造は 想像よりずっとシンプルで、Semantic Model が整備されていれば、Entity と Property の 2 つを指定するだけでデータバインディングが完了します。

3.1 visual.json の最小例（KPI カード）

{
  "name": "{ハッシュ}",
  "position": { "x": 40, "y": 80, "z": 1000, "width": 280, "height": 110 },
  "visual": {
    "visualType": "cardVisual",
    "query": {
      "queryState": {
        "Data": {
          "projections": [
            {
              "field": {
                "Measure": {
                  "Expression": { "SourceRef": { "Entity": "fact_sales" } },
                  "Property": "実績_利益率"
                }
              },
              "queryRef": "fact_sales.実績_利益率",
              "nativeQueryRef": "実績_利益率"
            }
          ]
        }
      }
    },
    "objects": { /* 書式設定（後述） */ }
  }
}

注目してほしいのは 2 行だけ:

"Expression": { "SourceRef": { "Entity": "fact_sales" } },
"Property": "実績_利益率"

これだけで、fact_sales テーブルの 実績_利益率 メジャーが KPI カードにバインドされます。

3.2 Entity / Property が AI に書かせやすい理由

Entity と Property は Semantic Model の表示名そのもの。日本語列名・日本語メジャー名で整えてあれば、AI は 自然言語のままバインディング名を書けるわけです。

第 2 回で扱った「Semantic Model の日本語化」が、ここで効いてきます。 SM が英語のままだと、AI は内部 mapping を都度引かないと正しい Property 名を書けません。日本語化しておくと「自然言語の指示 → visual.json」の経路が直線的になります。

3.3 ハッシュ名はランダム生成で OK

ディレクトリ名・visual.json の name フィールドに使われる 20 文字 hex のハッシュは、Python の secrets.token_hex(10) で生成した値で問題なく動作します。Power BI Desktop で開いてもエラーは出ません。

import secrets
visual_hash = secrets.token_hex(10)  # 例: "9c6afc8f95811cae030f"

ただし 1 つだけ制約があり、visual.json 内の name フィールドの値は ディレクトリ名と完全一致 させる必要があります。一致していないと Desktop でエラーになります。

3.4 Column の場合は "Column" に変わるだけ

メジャーではなく列（dim テーブルの組織名など）をバインドする場合は、"Measure" のキーが "Column" に変わるだけです。

"field": {
  "Column": {
    "Expression": { "SourceRef": { "Entity": "dim_organization" } },
    "Property": "部門名"
  }
}

スライサーや棒グラフの X 軸はこちらを使います。

4. 実証ケース 1: 単一ページ生成 PoC

2026 年 4 月 14 日、既存 BI レポート .pbip に Claude Code が visual.json を直接書いて新ページを追加してみました。

4.1 生成内容

6 ビジュアルからなる「売上分析（Claude Code 自動生成）」ページ:

visualType	用途	データバインディング	結果
`shape`	ヘッダー帯(装飾)	—	✅ デジタル庁テーマの書式適用
`textbox`	ページタイトル	—	✅
`cardVisual`	KPI(売上)	`fact_sales.実績_売上`	✅ 実値表示
`cardVisual`	KPI(利益率)	`fact_sales.実績_利益率`	✅ 実値表示
`clusteredColumnChart`	月別売上	`dim_date.年月 × fact_sales.実績_売上`	✅ 月次推移表示
`slicer`	部門名フィルタ	`dim_organization.部門名`	✅ クロスフィルタ動作

4.2 やったこと

4.3 PoC から得た 4 つの発見

ハッシュはランダム生成で OK — secrets.token_hex(10) で生成。Desktop が受け入れる
テンプレート複製 + Entity/Property 差し替えが実用的 — 既存ページの visual.json をコピー → Entity / Property を書き換えるだけで新ビジュアル化できる
Semantic Model の日本語表示名がそのまま使える — Entity = テーブル名・Property = 列/メジャー名
dim テーブルから X 軸を取ればクロスフィルタが正常動作 — fact 単独ではなく dim 経由で繋ぐ

この時点では PoC 1 ページですが、ここから「手動で 30+ ページ作る代わりに、AI に生成させる」という運用フェーズに移れる確信が持てました。

5. 実証ケース 2: 量産パターン（既存ページ流用）

PoC 後、4 つの異なる用途の Semantic Model にまたがる 30+ ページ・90+ ビジュアル を生成しました。ここで効くのが 既存ページ流用パターン です。

5.1 全ページを 1 から書くと冗長

ページが増えてくると、同じ構造のページ（行 = 費目・列 = 月階層・値 = 3 メジャー）を Semantic Model やフィルタ条件だけ変えて量産することが多くなります。

PoC のときのように 1 ビジュアルずつ JSON を書き起こすのは、6 ページ目以降は冗長です。代わりに、既存ページを shutil.copytree で複製 → メジャー名・タイトル文字列だけ Python で置換 する半機械的フローに移行しました。

5.2 流用フローの全体像

5.3 実例: 指標推移分析ページの量産

旧 BI の「指標推移(単価)」ページを新 Semantic Model 用に再構築したときの実例です。

項目	値
流用元	同 SM の「指標推移(数量)」ページ(lineChart×4 + slicer×3 + textbox + shape の 9 ビジュアル)
流用ビジュアル	7 ビジュアル(上段 lineChart×2 + slicer×3 + 装飾 2 つ)
不要ビジュアル	下段 lineChart×2(関連指標 2 つ)を流用対象から除外
書き換え対象	メジャー名(旧 → 新の 1:1 文字列置換)+ タイトル `title.text`
所要時間	Python スクリプト記述 + 実行で短時間(ゼロから書く場合と比べ大幅短縮)

Python スクリプトの骨子は次のような形になります(雰囲気だけ):

import shutil, uuid
from pathlib import Path

src_page = Path("...trends_analysis.Report/.../pages/{源ハッシュ}")
new_hash = uuid.uuid4().hex[:20]
dst_page = src_page.parent / new_hash

shutil.copytree(src_page, dst_page)

measure_map = {
    "数量": "単価",
    "数量_実績": "単価_実績",
    # ...
}

title_map = {
    "指標推移(数量)": "指標推移(単価)",
}

for visual_json in dst_page.rglob("visual.json"):
    content = visual_json.read_text(encoding="utf-8")
    # 自身ハッシュ参照を新ハッシュに置換
    content = content.replace(src_page.name, new_hash)
    # メジャー名置換
    for old, new in measure_map.items():
        content = content.replace(old, new)
    # タイトル置換
    for old, new in title_map.items():
        content = content.replace(old, new)
    visual_json.write_text(content, encoding="utf-8")

5.4 「半機械的」が成立する 3 条件

このパターンは どんなページでも使える銀の弾丸ではないことに注意してください。次の 3 条件が揃ったときに有効です。

条件	説明
構造類似ページが既に存在	lineChart 数・slicer 数・レイアウトが概ね一致するページがある
メジャー差し替えが 1:1 置換で済む	旧 → 新の対応が、文字列置換で曖昧さなく完結する
書式設定が流用元に揃っている	後述する「仕上げ 2 点セット」が流用元で既に適用済み

3 条件が崩れる場合（新 visualType・複雑なレイアウト変更が必要等）は、素直に visual.json を新規記述する標準フローに戻ります。

5.5 量産時の落とし穴: タイトル文字列の置換漏れ

機械置換漏れが起きやすいのは lineChart のタイトル文字列 です。visualContainerObjects.title[].properties.text.expr.Literal.Value という深い階層にあり、メジャー名置換だけだと取り逃しがちです。

"visualContainerObjects": {
  "title": [{
    "properties": {
      "text": {
        "expr": {
          "Literal": {
            "Value": "'指標推移(単価)'"
          }
        }
      }
    }
  }]
}

→ スクリプト末尾で「旧 BI 由来のタイトル文字列が残っていないか」grep する検証ステップ を必ず入れます。実際、最初の指標推移分析ページ生成では右上 lineChart のタイトルが旧名のまま残り、後処理で修正しました。

6. `/pbip-visual` スキル化 — 量産フローを Claude Code Skill に閉じ込める

ここまでの「visual.json を生成する」「既存ページを流用する」「仕上げを適用する」という一連のフローを、Claude Code の Skill（スキル）として再利用可能な形にパッケージングしたのが /pbip-visual です。

6.1 7 ステップのワークフロー

/pbip-visual を起動すると、次の 7 ステップで処理が進みます。

Step	内容	アウトプット
1	`.pbip` プロジェクトの特定 — 既存追加（A）か新規作成（B）を判別	プロジェクトのパス（または新規骨格一式）
2	既存構造の読み込み — `report.json` / `pages.json` / Semantic Model のテーブル・メジャー情報	命名規則・既存ページ構造の把握
3	ページ仕様のヒアリング — 「KPI カード 3 つ + 月次推移グラフ」等の自然言語仕様	生成対象のビジュアルリスト
4	レイアウト設計 — ヘッダー帯 + KPI 行 + メインビジュアルの座標を決定	各ビジュアルの x / y / width / height
5	JSON 生成 — `page.json` + 各 `visual.json` + `pages.json` 更新	新ページのファイル群
6	仕上げ（必須）— 階層スライサー active 補正 + visualHeader 一括付与	後述の 2 スクリプト適用済みファイル
7	デプロイと確認 — `fab import` でワークスペース反映 + 品質チェックリスト提示	Fabric Service 上のレポート

各 Step は references/ の参照ドキュメント（ビジュアルパターン集 / スタイルプリセット / デザインガイドライン）を参照しながら自律的に実行されます。

6.2 新規 `.pbip` プロジェクトもゼロから作成できる

Step 1 で重要なのは、既存追加（A）と新規作成（B）の両方をサポートしていることです。「既存レポートにページを足す」だけがスキルの出番ではありません。

Step 1B（新規作成） では、Skill 同梱の templates/pbip-skeleton/ から骨格一式をコピーし、接続先 Semantic Model の情報（ワークスペース名・SM 名・SM ID）に差し替えるだけで、ゼロから新規 .pbip プロジェクトが立ち上がります。生成されるファイル:

.pbip（エントリ JSON）
definition.pbir（SM への接続）
definition/report.json（テーマ設定）
definition/pages/pages.json（空のページ一覧）
StaticResources/（デジタル庁テーマ等のテーマファイル）

つまり、Semantic Model さえ整備されていれば、既存レポートへのページ追加だけでなく「新規レポート 1 本まるごと」を AI 駆動で立ち上げられるということです。Power BI Desktop を一度も開かずに、レポートプロジェクトの初期セットアップから完結します。

「Semantic Model 整備 → Skill で新規 .pbip 作成 → Step 3 でページ仕様を伝える → Desktop で開いて微調整」というフローが、Power BI レポート開発の新しい起点になります。

6.3 Skill 化の判断軸

Claude Code には Skill（スラッシュコマンド）と Memory（メモリ）の 2 つの永続化機構があります。.pbip ビジュアル生成を Skill 化した判断軸は次の 3 点でした。

判断軸	評価
references（参照ドキュメント）が必要か	✅ ビジュアルタイプ別の JSON テンプレート集が必須
再利用が頻繁か	✅ 月数回〜十数回ペースで新ページ生成
手順が定型化できるか	✅ Step 1〜7 で固まる

3 つすべて YES なら Skill 化、どれか NO なら Memory 止まり、というのが筆者の判断軸です。

6.4 ディレクトリ構造

.claude/skills/pbip-visual/
├── README.md                     ← セットアップ手順・前提条件
├── SKILL.md                      ← 7 ステップのワークフロー
├── references/
│   ├── visual-patterns.md        ← ビジュアルタイプ別 JSON テンプレート集
│   ├── style-presets.md          ← デジタル庁テーマ書式・カラーパレット
│   └── design-guidelines.md      ← デザイン原則・チェックリスト
├── scripts/
│   ├── fix_hierarchy_slicers.py  ← 仕上げ (1): スライサー active 補正
│   └── add_visual_header.py      ← 仕上げ (2): visualHeader 一括付与
└── templates/pbip-skeleton/      ← 骨格テンプレート (.pbip / .pbir / report.json 等)

特に templates/pbip-skeleton/ を同梱したことで、「既存プロジェクトからコピー」の手順が消え、/pbip-visual を初めて使うリポジトリでも一発で新規 .pbip を立ち上げられるようになっています（6.2 の新規作成フローで使用）。

6.5 仕上げ 2 点セット

ページ生成直後に 必ず適用する仕上げが 2 つ あり、これらを scripts/ 内に独立スクリプトとして同梱しています。

なぜこの 2 つが「必須」なのか:

仕上げ	適用しないと起きる症状
階層スライサーの折り畳み制御	スライサーの全階層が初期展開されて画面が埋まる。最上位以外を `active: false` にして折り畳む
visualHeader 付与	Power BI Service（Web）でドリルメニュー（↑↓）が非表示になる。Desktop と Web の挙動差を埋めるための必須設定

Skill 化の効用は、「うっかり仕上げを忘れる」がゼロになることです。SKILL.md に Step 6 として明示してあり、Claude Code が必ず実行します。これは Memory に書いておくだけでは抜けがちな運用知でした。

6.6 スキル化のもう一歩先

Skill のもう一歩先は 「既存類似ページの自動検出」 だと考えています。今は人間が「このページとあのページが構造類似だから流用元にしよう」と選定していますが、ここを SKILL.md の Step 1.5 として自動化する余地があります（lineChart 数・slicer 数・visualType セットの類似度で順位付け）。

ただし、自動検出を組み込むと汎用性が下がる可能性もあり、Skill のスコープをどこで線引きするかは別途検討中です。/pbip-visual 自体の深掘り（references の中身・テンプレートの設計判断・他環境への移植性）は、別記事化を視野に入れています。

7. ハマったところ・落とし穴まとめ

実運用で踏んだ落とし穴を一覧化します。

7.1 visual.json 構造系

症状	原因	対処
`pages.json` のスキーマで「Can't resolve schema」エラー	スキーマ URL に `pages/1.0.0` と書いていた	正しくは `pagesMetadata/1.0.0`
警告「ActivePageName が見つかりません」	`pages.json` に `activePageName` 未設定	既定で表示したいページのハッシュを設定
`visualType: stackedColumnChart` でレンダリングされない	visualType 名が無効	積み上げ縦棒は `columnChart` + `Series` ロール
visual がページに表示されない	`visual.json` の `name` フィールドとディレクトリ名が不一致	両者を完全一致させる
`visual.filters` プロパティで Desktop エラー	スキーマ未定義（執筆時点）	ビジュアルレベルのフィルタは Desktop GUI で手動設定
`Property 'X' has not been defined and the schema does not allow additional properties` エラーで Desktop が開けない	`objects` 配列の各要素直下に `labelDisplayUnits` / `show` / `fontSize` 等を並列配置していた	`objects` 配列の各要素直下に置けるのは `properties` と `selector` のみ。書式キーはすべて `properties` の中にネストする
列ヘッダー・凡例の `displayName` オーバーライドが無視される	`$schema` が `.../2.7.0/schema.json` のまま	`displayName` を使う `visual.json` だけ `$schema` を `2.8.0` にバンプ（使わないビジュアルは 2.7.0 のままで OK）

7.2 書式・配色系

症状	原因	対処
棒グラフの色が真っ黒・グレーになる	`ThemeDataColor` で色を指定していた	Literal hex で直接指定（例: `"Value": "'#CE0000'"`）
Y 軸の金額に意図しない `M` サフィックスが付く	Power BI が Auto スケールで百万単位に自動丸める	`labelDisplayUnits: "1L"`（= None）を `valueAxis` と `labels` 両方に設定
カードビジュアルが真っ白	`dataLabels` / `categoryLabels` プロパティを使っていた	正しくは `value` / `label` + `selector.id="default"`
pivotTable のフォーマット指定で `formatStringExpression` のトレイリングカンマ（百万・十億スケール）が効かない	Power BI 側の pivotTable 描画エンジンの仕様	スケールなしの raw 表示で運用（執筆時点）

7.3 レイアウト・操作系

症状	原因	対処
スライサーのドロップダウンが切れる	`position.height` が 72 だと隠れる	スライサーは `height: 104` 以上、ヘッダー帯は `120` 推奨
階層スライサーが初期表示で全階層展開される	最上位以外の Level に `active` 指定がない	最上位以外を `active: false` にする（`scripts/fix_hierarchy_slicers.py` で一括補正）
Power BI Service（Web）でドリルメニュー（↑↓）が出ない	ビジュアル個別の `visualContainerObjects.visualHeader.show` が未設定	各ビジュアルに `visualHeader.show=true` を明示（`scripts/add_visual_header.py` で一括付与）。`report.json` のトップレベル設定はスキーマエラー
pivotTable で「実績のみ」表示になっている	1 メジャーだけで生成していた	最初から実績 / 見込 / 予算の 3 メジャーセットを `Values.projections` に含める

応用: 階層スライサーの 3 つの配置パターン

階層構造の列（例: dim_organization.組織名 - 階層）を持つスライサーは、用途ごとに JSON の配置場所が違います。一見同じ「フィルタ」に見える 3 機能が、別々のプロパティに割り当てられています:

機能	配置場所	用途
items 制限（dropdown に表示する値を絞る）	`visual.filterConfig`（visual top-level）	「特定の事業部のメンバーだけ表示」のような表示候補制限
default 選択（起動時に選択された状態にする）	`visual.objects.general[0].properties.filter`	「ページを開いた瞬間に当年度が選択済」のような初期値
sync slicer（複数ページのスライサー連動）	`visual.syncGroup`（`groupName` で同期キー指定）	「全ページの組織スライサーが連動」のようなページ間連動

3 つは併用可能（同じ slicer に items 制限 + default 選択を共存させる、など）。混同しやすいので、Power BI Desktop で 1 ページ手動設定 → visual.json を読んで構造を確認 → 他ページにコピーするのが安全です。「Desktop に書かせて学ぶ」が階層スライサー JSON の正解アプローチでした。

7.4 Semantic Model 連動系

症状	原因	対処
Semantic Model 側で列名を Rename したのに `.pbip` レポートが追随しない	Rename の自動追随は Semantic Model 内 DAX のみ	`visual.json` 内の `queryRef` / `nativeQueryRef` / `Property` / `metadata` の 4 箇所を Python で一括置換
カラム名 / メジャー名置換後にビジュアルタイトルが旧名のまま	`title.text` の `Literal.Value` が深い階層にある	スクリプト末尾で「旧名 grep」を必ず実行

8. まとめ + 連載次回予告

8.1 振り返り

.pbip は .pbix のテキスト版で、レポート定義が 数百の JSON ファイルに分解される。中でも visual.json が AI に書かせる対象
visual.json のデータバインディングは Entity と Property の 2 つを指定するだけ。Semantic Model が日本語化されていれば、自然言語のままバインディング名を書ける
2026 年 4 月の PoC で 6 ビジュアルの単一ページが Desktop で実データ表示 + クロスフィルタ動作することを確認
そこから 既存ページ流用パターンで 30+ ページ・90+ ビジュアルを生成。「半機械的」が成立する 3 条件を満たす範囲では工数削減が大きい
/pbip-visual Skill として 7 ステップのワークフローにパッケージング済み。Semantic Model さえ整っていれば、**既存レポートへのページ追加だけでなく「新規 .pbip プロジェクトをゼロから立ち上げる」**ところまで Skill 内で完結
Skill 化により、仕上げ 2 点セット（階層スライサー active 補正・visualHeader 付与）の忘れがゼロになり、運用が安定
落とし穴は visual.json 構造系・書式系・レイアウト系・Semantic Model 連動系 の 4 系統。本記事の表を参考にすればほぼ事前回避可能

8.2 連載次回予告

次回（第 4 回）は 「Power BI レポートとデータ基盤を Git で管理する — Fabric ワークスペースの履歴管理・コードレビュー実践」 を予定しています。今回扱った .pbip も含めて、Fabric ワークスペース上の Notebook・Semantic Model・Report が Azure DevOps Git にどう同期されるか（updateFromGit / Git → workspace 方向）の検証・運用ルールを共有します。

第 5 回は 「Fabric の Git 連携をボタン操作なしで完全自動化する — CLI からのデプロイフロー」（workspace → Git 方向の commitToGit を含む CI/CD ライクな自動化）の予定です。第 4 回・第 5 回で Fabric の Git 統合周辺を 2 本立てで扱います。