1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@daizou703

Claude Code × Microsoft Fabric (5) — CLI による Git 連携自動化：Notebook デプロイを完全自動化する

1
Posted at

想定読者

  • Microsoft Fabric を Azure DevOps（または GitHub）に Git 統合して運用しているエンジニア・データ基盤担当
  • 第 4 回で「Issue 駆動の開発フロー」を読んだ上で、ポータル UI のクリック操作を CLI 化したい方
  • データ基盤の CI/CD 化に向けて Fabric の自動化境界を見極めたい方

シリーズ過去回:

TL;DR

  • 本記事の主役は Notebook デプロイの CLI 完全自動化。fab import + fab api commitToGit の 3 ステップで、ポータル UI クリック 0 回で workspace ↔ Git 同期が完結する
  • 第 4 回でポータル UI に残っていた「すべて更新」「コミット」のクリック操作は、fab api updateFromGit / fab api commitToGit で API 化できる
  • 複数 Notebook が連鎖するような改修 も、CLI 完全自動化フローに乗せれば 1 セッション完走できる
  • 一方で .pbip Report の改修は、第 4 回で紹介した Git sync ルート 8 ステップが向くケースが多い（Desktop 編集 / PR レビュー / 視覚的差分確認が絡むため）
  • 落とし穴は CLI 自動化フロー上の 3 つ: comment 300 字制限 / 複数 workspace の打ち忘れ / LRO 伝搬遅延

1. 第 4 回からの続きと本記事で扱う範囲

1.1 第 4 回の振り返り — 残っていた「人手のクリック」

第 4 回では、Power BI レポートとデータ基盤を Git で管理する開発フローを扱いました。Issue を起票してから feature ブランチで編集し、PR レビューを通して main にマージし、Fabric ワークスペースに反映するまでの 1 周ループです。

このループには、最後まで ポータル UI のボタン操作 が 2 種類残っていました。

ボタン 動作 API
「すべて更新」 Git → workspace（差分適用） updateFromGit
「コミット」 workspace → Git commitToGit

第 4 回の章 6.4 では、ボタン操作を伴う Git sync ルートに加えて、fab CLI から workspace に直接 push するルート、ポータル UI で手動コミットするルートの 3 経路を 使い分け として整理しました。図にすると次のとおりです。

3 経路の位置付け: ① fab CLI ルート が本記事の主役、② Git sync ルート は第 4 回の主役で本記事では API 化できる範囲だけ補足、③ ポータル UI 手動ルート は GUI で 1 件だけ手動コミットするケース向け。本記事ではこの 3 経路のうち「ボタン操作を CLI に置き換えられる範囲」を一段深く掘り下げます。

1.2 ボタン操作が自動化を止める 3 つの理由

ポータル UI のクリック操作が残っていると、次の 3 点で開発フローが詰まります。

  1. 再現性: クリック操作は手順書や Issue にスクリーンショットで残しても、半年後に同じ手順を再生しにくい。CLI コマンドなら commit メッセージ・Notebook セル・スクリプトに コピペ可能な形 で残せる
  2. 速度: 1 タスクに 2〜3 回のクリックが入ると、複数 Issue を並列で進めるときに UI 操作が直列のボトルネックになる
  3. Claude Code 完結度: AI エージェントから Fabric を操作するとき、ポータル UI クリックは AI 側で代行できない。CLI に落とせれば Claude Code が裏で組み合わせて自走できる

3 番目が特に重要です。第 1〜4 回で組み上げてきた「Claude Code を中心に据えた開発スタイル」は、Claude が直接呼び出せる API 群の網羅率 で完結度が決まります。ポータル UI クリックが残るとそこだけ人手介入が必要になり、自動化フローが切れます。

1.3 本記事で扱う範囲と Report の位置付け

本記事の中心メッセージは「Notebook デプロイは fab api で完全自動化できる」です。

主役: Notebook の CLI 完全自動化

  • ポータル「すべて更新」を fab api updateFromGit で置き換える
  • ポータル「コミット」を fab api commitToGit で置き換える
  • fab import + fab api commitToGit の 3 ステップで Notebook デプロイを完結させる
  • 列名統一のような複数 Notebook が連鎖する改修を 1 セッション完走させる実例

Notebook は Desktop GUI で編集することがなく、git diff のテキストで差分も読める ため、CLI 完全自動化との相性が良いアイテムです。

補足: Report は第 4 回方式が向くケースが多い

.pbip Report の改修は、API レベルでは同じく commitToGit / updateFromGit で操作できますが、実運用では第 4 回で紹介した Git sync ルート 8 ステップが向くケースが多い です。理由は次のとおりで、いずれも Notebook では発生しにくい問題です。

観点 Report で起きやすい状況
Desktop GUI 編集 .pbip を Power BI Desktop で編集して保存する作業が頻繁に発生
PR レビュー visual.json のテキスト差分は読みにくく、視覚的なレビュー確認が必要なケースが多い
Conflict 発生 Service 側の 4-space canonical 整形で「Modified」表示が出やすく、commit-back の運用が必要

ただし Report でも visual.json を Python で直接編集する改修（スキル経由の自動生成・スライサー sync の一括追加など）は、Desktop GUI を介さないため CLI 完全自動化フローで完結します。詳しくは章 5 で扱います。

Semantic Model は本記事の対象外

Semantic Model の改修は PBI Modeling MCP のライブ Deploy（第 2 回）が主軸で、fab api ルートの話とは別文脈になるため本記事の対象外です。

予告タイトルとのズレ

第 4 回の末尾で、第 5 回タイトルを 「ボタン操作なしで完全自動化」 と予告していました。執筆に入って整理した結果、Notebook デプロイは本当に完全自動化できる一方、Report 全般を「完全自動化」と呼ぶには無理があると判断し、本記事のタイトルは「CLI による Git 連携自動化：Notebook デプロイを完全自動化する」に変更しました。Notebook の完全自動化を主役に据えつつ、Report との適用範囲を正直に併記する方が、読者の運用判断に役立つと考えています。

2. API レベルの整理 — ボタンの裏で何が動いているか

2.1 ポータル UI と Fabric Public API の対応

ワークスペース上部の「ソース管理」パネルを開くと、右側に変更タブ・更新情報タブとボタン群が並びます。それぞれの裏にある Fabric Public API は次の対応関係です。

ポータル UI 要素 Fabric Public API 方向
「すべて更新」ボタン（更新情報タブ） POST /workspaces/{id}/git/updateFromGit Git → workspace
「コミット」ボタン（変更タブ） POST /workspaces/{id}/git/commitToGit workspace → Git
更新アイコン（パネル上部の矢印） GET /workspaces/{id}/git/status 状態取得のみ（sync しない）
「競合の解決」ボタン POST /workspaces/{id}/git/resolveConflicts（preview） Conflict 解決

本記事では太字 2 つ（updateFromGit / commitToGit）を中心に扱います。git/status は同期状態の確認・LRO 完了判定で頻繁に登場します。

2.2 POST /workspaces/{id}/git/updateFromGit — Git → workspace

公式 API 仕様の要点:

  • 役割: connected branch に push された commit を workspace に取り込む
  • 差分適用方式（commit で変更されたアイテムだけ更新）
  • LRO（Long Running Operation）対応 — status 202 Accepted で受理され、非同期で完了
  • 必要スコープ: Workspace.GitUpdate.All
  • Service Principal 実行は対象アイテム全部が SP 対応していれば可

fab api 経由で呼ぶときの最小形:

fab api -X post "workspaces/<workspace-id>/git/updateFromGit" \
  -i '{
    "remoteCommitHash": "<commit hash>",
    "conflictResolution": {
      "conflictResolutionType": "Workspace",
      "conflictResolutionPolicy": "PreferRemote"
    }
  }'

conflictResolution は省略すると Conflict 時にエラーになるため、無人実行を想定する場合は 「Git 側を採用」を明示 しておくのが安全です。PreferRemote は第 4 回の「受信した変更を受け入れる」と同じ意味です。

2.3 POST /workspaces/{id}/git/commitToGit — workspace → Git

updateFromGit と対称な API。workspace 側の変更を connected branch に push します。

  • 役割: workspace の変更を Git に commit して push する
  • LRO 対応・status 202 Accepted
  • 全件 commit / 選択 commit の両モード対応
fab api -X post "workspaces/<workspace-id>/git/commitToGit" \
  -i '{"mode":"All","comment":"基本給列名統一: Bronze/Silver/Gold/Semantic Model/データ辞書 一括更新"}'

mode パラメータの選択:

値 動作
All 全 uncommitted 変更を一括 commit
Selective items フィールドで指定したアイテムのみ commit

一括 commit でよいケースが大半なので、運用では mode: "All" がデフォルトです。

2.4 LRO（status 202 Accepted）の扱い

両 API とも 非同期実行 で、即座に完了しません。レスポンスは次の形:

{"status_code": 202, "text": null}

LRO の完了は git/status を叩いて remoteCommitHash の更新と changes: [] を確認する のが確実です（Operation ID ベースのポーリング API も別途ありますが、git/status で 1 回確認する方がシンプル）。

fab api "workspaces/<workspace-id>/git/status"
# → "remoteCommitHash" が更新済 + "changes": [] なら commit / update 完了

LRO は通常数秒で完了しますが、7 章で扱うように 数十秒の伝搬遅延 が起きるケースがあります。

3. Notebook の CLI 完全自動化が成立する理由

3.1 結論 — Notebook デプロイは 3 ステップで完全自動化できる

Notebook デプロイは fab import → commitToGit → git pull の 3 ステップ で workspace ↔ Git の双方向同期が完結します。ポータル UI のクリックは 0 回。これが本記事の主役です。

具体的なコマンド例は章 4 で、複数 Notebook の連鎖改修例は章 5 で扱います。

3.2 なぜ Notebook は CLI 完全自動化と相性が良いか

Notebook の性質が CLI 完全自動化と噛み合う理由は 3 点あります。

観点 Notebook の性質 CLI 自動化への影響
編集場所 VS Code 等のテキストエディタ・GUI 不要 ローカルでテキスト編集 → そのまま fab import できる
差分の視認性 コードの git diff でレビュー可能 PR レビューも CLI 経由のテキスト差分で完結
Service 側 canonical 整形 影響なし commitToGit 後の「Modified」表示が出ず、commit-back ループが不要

「テキスト編集 + テキスト差分 + canonical 整形の影響なし」の 3 条件が揃うため、ローカル編集から workspace 反映・Git push までを 1 直線の CLI フローに乗せられます。

3.3 対比: Report は第 4 回方式が向くケースが多い

同じ Fabric Git API（commitToGit / updateFromGit）を .pbip Report に適用することもできますが、Report は 3.2 の 3 観点がほぼ逆向き になります。

観点 Report の性質 結果
編集場所 Power BI Desktop の GUI 編集が一般的 Desktop 編集自体は CLI 化対象外
差分の視認性 visual.json の差分は視覚的確認が必要なケースあり PR レビュー時の視覚確認が必要
Service 側 canonical 整形 あり（4-space drift で「Modified」表示） commit-back の運用が必要

このため Report の標準ルートは Git sync ルート 8 ステップ（第 4 回 6.3 参照）が向きます。Step 6「すべて更新」と Step 7「commit-back」だけは updateFromGit / commitToGit API で代替できますが、Desktop 編集（Step 1-3）・PR レビュー（Step 5）・GUI 視覚確認は人間作業として残ります。

ただし Report でも visual.json を Python で直接編集する改修（スキル経由のページ自動生成・スライサー sync の一括追加など）は、Desktop GUI を介さないため Notebook と同じ CLI 完全自動化フローで完結します。この例外パターンは章 5.2 で扱います。

4. Notebook デプロイの CLI 完全自動化フロー

4.1 fab import → commitToGit の 3 ステップ完結フロー

Notebook を 1 本 workspace に反映し、Git にも commit するまでの最短フローは次の 3 ステップです（章 3.1 の図を再掲）。

実コマンド:

# 1. fab import で workspace に反映
fab import "<workspace-name>.Workspace/NB_xxx.Notebook" \
  -i "<local-staging-path>/NB_xxx.Notebook" -f

# 2. commitToGit で Git に push
fab api -X post "workspaces/<workspace-id>/git/commitToGit" \
  -i '{"mode":"All","comment":"NB_xxx 追加"}'

# 3. ローカルクローンを同期
git -C <local-clone-path> pull --rebase origin main

ポータル UI クリックは 0 回です。Notebook の修正であれば、ローカルの作業フォルダで編集してから上記 3 コマンドを順に実行するだけで、workspace ↔ Git ↔ ローカルクローンの 3 拠点が同期します。

💡 <local-staging-path> は Notebook の編集中ファイルを置いておくローカルフォルダのことです。fab export で workspace から取得した Notebook フォルダを編集してから fab import で push するのが標準パターンです。

4.2 同期確認パターン — remoteCommitHash 確認 → git pull

commitToGit 直後に git pull --rebase すると、たまに 「Already up to date」になる ことがあります（後続 7.3 で詳しく扱います）。これは LRO の伝搬遅延が原因で、commit 自体は成功しているのに git fetch が古い HEAD を見ているケースです。

確実に同期するパターン:

# 1. commitToGit を打つ
fab api -X post "workspaces/<workspace-id>/git/commitToGit" \
  -i '{"mode":"All","comment":"..."}'
# → status_code: 202

# 2. git/status で remoteCommitHash 更新 + changes: [] を確認
fab api "workspaces/<workspace-id>/git/status"

# 3. git fetch + pull
git -C <local-clone-path> fetch origin main
git -C <local-clone-path> pull --rebase origin main

git/status が「commit が完了したか」の判定に使えるのが重要なポイントです。LRO 完了の判定をシンプルに済ませられます。

4.3 セッション末尾の git/status チェック（全 workspace 横断）

複数 workspace を扱うセッションでは、各 workspace ごとに別々に commitToGit を打つ必要 があります（7.2 で詳しく扱います）。セッション末尾に全 workspace の git/status を一括チェックするスクリプトを習慣化しておくと、commit 打ち忘れを構造的に防げます。

for ws in \
    <workspace-id-1> \
    <workspace-id-2> ; do
  echo "=== $ws ==="
  fab api "workspaces/$ws/git/status"
done

changes: [] が全 workspace で並んだら、その日の workspace ↔ Git は完全同期されたと判断できます。

5. 補足: Report は Git sync ルートが向く（部分的 API 化のみ）

章 3.3 で触れたとおり、.pbip Report の改修は 第 4 回で紹介した Git sync ルート 8 ステップが向くケースが多い です。本記事では章 4 の Notebook 完全自動化を主役にし、Report は補足として要点だけ整理します。

5.1 Report 標準ルートのうち API 化できる部分

第 4 回 6.3 の 8 ステップを要約すると次の流れです。

Semantic Model 改修 → fab export → Report 修正 → git commit / push → ポータル「すべて更新」 → 再 Uncommitted の commit-back → ローカルクローン pull --rebase

このうち、本記事の API で代替できるのは ポータル UI クリックが残る 2 ステップ だけです。

Step 内容 代替 API
Step 6 「すべて更新」 fab api updateFromGit
Step 7 再 Uncommitted の commit-back fab api commitToGit

残りの Step 1-3（編集）・Step 5（PR レビュー）・Step 8（ローカルクローン pull）は 人間作業 or 通常の git 操作として残ります。Report 全体を CLI で完全自動化はできません。

Step 6 の API 化は、PR マージ直後に自動で updateFromGit を打つフックを組めば「PR がマージされたら workspace が自動で最新になる」という CI 風の挙動になります。Step 7 の commitToGit は Service 側 4-space canonical 整形によって発生する Modified 表示の clean up に使えます（詳細は 7.4 で扱います）。

具体的なコマンド例は本記事では省略します。updateFromGit の最小形は章 2.2 を参照してください。

5.2 例外: Report でも CLI 完全自動化が成立するケース

Report でも visual.json を Python で直接編集する改修 は、Desktop GUI を介さないため章 4 の CLI 完全自動化フローで完結します。例:

  • スキル経由でページを自動生成する
  • 全 visual の visualHeader を一括補正する
  • 階層スライサーの sync 設定を全ページに追加する

これらは Notebook と同じく「テキスト編集 + テキスト差分 + canonical 整形の影響なし」が成立するため CLI ルートに乗ります。実例は第 3 回（.pbip 自動生成）が詳しいです。

6. ミニ実例 — Notebook 中心の連鎖改修が CLI ルートで完走する

ここまでの API 単体の話を、実際の改修タスクに当てはめてみます。題材は 列名の揺らぎを上流で統一するタスク です。

データ基盤の Bronze / Silver レイヤーには、複数のデータ取得元からテーブルが入ってきます。このとき同じ意味の列が テーブルによって違う名前 で入ってくることがあります。たとえば「基本給」を意味する列が、あるテーブルでは basic_salary、別のテーブルでは base_salary という具合です。

このまま放置すると、Gold レイヤーや Semantic Model 側で 都度名前を補正する必要があり、改修や横展開のたびにコストが増えていきます。下流で吸収するより、Bronze / Silver の段階で base_salary に揃えてしまった方が結果的に楽です。

これがいわゆる 「列名統一タスク」 で、Notebook 中心の改修なので fab CLI ルートが自然 な代表例になります。

6.1 列名統一の波及範囲

データ基盤で列名を 1 つ変えると、影響範囲が複数の Notebook 群に連鎖します。

1 列の改名で、Bronze / Silver / Gold の各層の Notebook と最終的に Semantic Model の sourceColumn まで一通り改修する必要があります。Report 側はメジャー名で抽象化されているので通常は影響を受けません。

このように複数 Notebook が連鎖する改修でも、Notebook 改修である限り fab CLI ルートで完走できる のがポイントです。

6.2 Phase A-E に分けて順次進める

連鎖改修は、ワンショット Notebook を作りながら 5 つの Phase に分けると効率的です。

Phase 内容 使う Fabric 機能
A. 影響範囲調査 旧列名・新列名で grep + sourceColumn 確認 + 取込済データの粒度確認 grep / PBI Modeling MCP
B. メタデータ更新 列マッピング情報を SQL で UPDATE ワンショット Notebook
C. Bronze / Silver 再構築 既存テーブルを DROP + 取込済記録を DELETE + 本番取込 Notebook を新列名で再実行 ワンショット Notebook + fab import + fab job run
D. Gold 一括再実行 影響を受ける Gold Notebook を 並列 import + 順次 job run fab import（並列）+ fab job run（順次）
E. Semantic Model 更新 + commit Semantic Model の sourceColumn を MCP で更新 → Direct Lake Full Refresh → commitToGit + git pull PBI Modeling MCP + fab api commitToGit

Phase B-D はすべて Notebook の作成・更新・実行で完結します。.pbip Report の visual.json は触らないため Git sync ルート 8 ステップは登場しません。

6.3 Phase D のポイント — 並列 import + 順次 job run

連鎖改修の中で特に効くのが Phase D の 「並列 import + 順次 job run」 パターンです。

  • fab import は並列: 各 Notebook の import は依存関係がないので 3 本同時に流せる（1 本あたり数秒で完了）
  • fab job run は順次: 同一 Spark セッションでの競合を避けるため、1 本の完了を待ってから次を起動

Claude Code から実行する場合、fab job run を background 実行 + 完了通知 に組めば、通知を受けてから次の Notebook を起動するチェーンが自動で組めます。複数 Notebook の連鎖改修を 1 セッションで流すのに最適です。

6.4 規模感と所要時間

実際の規模感を 2 例で示します。

タスク 改修対象の概数 所要時間
給与系の列名統一（予実分離 2 系列） Bronze 10 本 / Silver 5 本 / Gold 0 本 / Semantic Model 3 本 半日
売上系の列名統一（予実分離 1 系列） Bronze 3 本 / Silver 1 本 / Gold 3 本 / Semantic Model 1 本 半日

予実分離型（実績 / 見込 / 予算）のデータでは 3 系列で 1 セット になるため、列名統一でも改修対象数が膨らみます。それでも Phase A-E に分けてワンショット Notebook を活用すれば、半日仕事の典型的規模 で 1 セッション完走できます。

6.5 なぜこの実例が fab CLI ルートで成立するか

この実例の改修対象は Notebook（Phase B-D） + Semantic Model の sourceColumn（Phase E） で、.pbip Report の visual.json は触りません。3.2 で整理した「アイテム種別ごとの自然なルート」に当てはめると:

  • Phase B-D = Notebook 改修 → fab CLI ルートが標準
  • Phase E の Semantic Model = MCP ライブ Deploy（fab api 経由ではなく MCP 経由）
  • .pbip Report 改修なし → Git sync ルート 8 ステップは不要

このため fab CLI ルートだけで 1 セッション完走できます。逆に同じ列名統一でも visual.json まで変える必要があるなら、Report 側だけ Git sync ルート 8 ステップに乗せる必要が出てきます。改修対象のアイテム種別の組み合わせ次第で、使うルートが決まる わけです。

7. 落とし穴

落とし穴は fab CLI ルート共通の 3 つ と、Report の Git sync ルート特有の 1 つ に分けて整理します。

7.1 [共通] comment メッセージは 300 字制限

commitToGit の comment フィールドは 最大 300 文字 です。ローカル git の commit と違って subject + body の詳細形式は使えません。

errorCode: InvalidParameter
message: "The field Comment must be a string or array type with a maximum length of '300'."

300 字制限の運用 tips:

  • subject 行のみで簡潔に記述
  • 詳細経緯は Issue の Discussion / 議事録 notes に書く
  • 「ローカル git の 72 字 subject + body 形式」は commitToGit 経由では使えない（ローカルクローン直編集ケース限定）
# OK: 簡潔な 1 行
fab api -X post "workspaces/<workspace-id>/git/commitToGit" \
  -i '{"mode":"All","comment":"派遣単価ページ追加: Semantic Model に 6 メジャー + Page 10"}'

# NG: 詳細を改行で展開すると 300 字超

7.2 [共通] ワークスペースを跨ぐ作業は workspace ごとに commitToGit を打つ

同じセッション内で 複数 workspace を扱った場合、各 workspace ごとに別々に commitToGit を打つ必要があります。1 つの workspace で打っても、他の workspace の uncommitted は残ります。

ハマりやすいシナリオ:

  • タスク A で workspace A を改修 → commitToGit 打つ
  • 同セッションでタスク B も進めて workspace B を改修
  • workspace A 側は commit 済の感覚で「commit 済んだ」と認識
  • workspace B 側の commit を打ち忘れて Uncommitted が残置

commitToGit API は 引数に workspace-id を取る ので、workspace を意識せずに「commit したつもり」になりがちです。

予防策として、4.3 で書いた 「セッション末尾の全 workspace git/status チェック」 を習慣化します。

for ws in <全 workspace-id>; do
  echo "=== $ws ==="
  fab api "workspaces/$ws/git/status"
done

changes: [] が全 workspace で並ぶまで commit 漏れを潰します。

7.3 [共通] LRO 伝搬遅延と「Already up to date」

commitToGit 直後に git pull --rebase すると、たまに 「Already up to date」 と表示されることがあります。実際は commit は成功しているのに、Git リモートへの反映が伝搬していないケースです。

このとき次の流れで対処します:

# 1. commitToGit 直後
fab api -X post "workspaces/<workspace-id>/git/commitToGit" \
  -i '{"mode":"All","comment":"..."}'
# status_code: 202

# 2. 早すぎる pull は "Already up to date" になることがある
git -C <local-clone-path> pull --rebase origin main
# → "Already up to date" 表示（commit 自体は成功している）

# 3. git/status で remoteCommitHash 更新を確認
fab api "workspaces/<workspace-id>/git/status"
# → "remoteCommitHash" が更新済 + "changes": [] なら commit 完了

# 4. fetch + pull 再試行
git -C <local-clone-path> fetch origin main
git -C <local-clone-path> pull --rebase origin main
# → fast-forward 成功

ポイントは 「git/status で remoteCommitHash の更新を確認してから fetch + pull する」。LRO の完了判定を git/status 側で取るのが確実です。

7.4 [Report 特有] 4-space whitespace drift と「Modified」表示

第 4 回 6.1 で触れた「Uncommitted/Modified」現象は、Service が JSON を内部で 4-space indent に自動整形する ことによる whitespace の差分が正体です。これは .pbip Report で起きやすく、Notebook では発生しません。

commitToGit でこの whitespace 差分を commit すると、Git に書き戻されるのは論理差分のみ で、whitespace-only 差分は破棄されます。

観察項目 結果
Desktop 編集 → push → updateFromGit ポータルで Report が「Modified」表示
fab export で Service 内部取得 → clone と diff 多数ファイルで差分検出
差分ファイルを JSON parse して == 比較 全件 logically equal（whitespace のみ）
commitToGit で git に反映された差分 論理差分のみ（whitespace 差分は破棄）

実害ゼロですが、ポータル UI 上で「変更あり」表示が残るのが気持ち悪いケースがあります。commitToGit をその日のうちに打って同期をクリーンに保つのが運用安全です。これは 5.3 で書いた 「Step 7 の commit-back」を CLI 化 することで対処できます。

8. まとめ + 連載の到達点

8.1 第 1〜5 回の到達点

連載 5 回を通じて、Microsoft Fabric を Claude Code から運用するスタックがどう組み上がったかを整理します。

回 テーマ 到達点
第 1 回 土台編 Claude Code + 2 つの MCP Server + Fabric CLI / Azure CLI / git CLI による 1 人開発スタックの確立
第 2 回 2 つの MCP Server Fabric MCP（データ基盤）+ PBI Modeling MCP（Semantic Model）の補完関係
第 3 回 .pbip 自動生成 Power BI レポートのページを visual.json 経由で AI に作らせる
第 4 回 Git 管理・Issue 駆動 Power BI レポートとデータ基盤を Git ベースのワークフローに乗せる
第 5 回 CLI 自動化 Notebook デプロイを fab api で完全自動化し、Power BI レポートとの適用範囲を整理

8.2 第 5 回で得たもの — Notebook デプロイの CLI 完全自動化

本記事の主役は Notebook デプロイの CLI 完全自動化 でした。

  • Notebook: fab import + fab api commitToGit + git pull の 3 ステップで、ポータル UI クリック 0 回の完全自動化フローが組める。「テキスト編集 + テキスト差分 + Service 側 canonical 整形の影響なし」の 3 条件が揃うため、ローカル編集から workspace 反映・Git push までを 1 直線の CLI で完結できる
  • 複数 Notebook の連鎖改修 も、章 6 で扱った Phase A-E のパターンに乗せれば 1 セッション完走できる

.pbip Report については、Notebook と同じ API（commitToGit / updateFromGit）が使えますが、実運用では第 4 回で紹介した Git sync ルート 8 ステップが向くケースが多い ことを章 3.3 / 章 5 で整理しました。Desktop GUI 編集・PR レビュー・GUI 視覚的差分確認といった工程は CLI 化対象外として残ります。

つまり Fabric の自動化境界は、「Notebook デプロイは CLI で完全自動化できる / Report は第 4 回方式の Git sync ルートが向く」 というシンプルな対比に整理できました。

8.3 連載完結時点での未踏領域

正直に書くと、連載 5 回で完結する話ではなく、まだ未踏の領域が複数あります。

  • Conflict 解決 API の実用検証: ポータル UI のダイアログを resolveConflicts API で置換できるかは未検証
  • PR レビューに AI を絡める実験: LLM をコードレビューに使う試み
  • updateFromGit の auto-trigger: PR マージ → workspace 反映を webhook / pipeline で自動化する
  • 複数 workspace の atomic commit: 複数 workspace を同時に commit するトランザクション的な保証は現状なし

8.4 関連リンク

公式ドキュメント:

連載過去回:

第 4 回で「Issue 駆動の開発フロー」の手動工程を整理し、第 5 回で Notebook デプロイの CLI 完全自動化 を確立しました。Power BI レポートまで含めて単一の完全自動化フローに押し込むのではなく、「Notebook は CLI で完全自動化 / Report は第 4 回方式の Git sync ルート」 と用途で割り切るのが、現実的なデプロイフロー自動化の形だと考えています。

質問・コメント・気付き、歓迎します。

1
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?