powerbi-modeling

Power BI モデリング

対象技術スタック／バージョン：Power BI Desktop の最新リリース、Tabular Editor、DAX Studio、および Fabric のセマンティックモデル ワークフロー。

一般的な SQL スキーマやスプレッドシートではなく、Power BI セマンティックモデル内で作業する場合に、このスキルを使用してください。

• 利用可能な場合は、ネイティブの並列サブエージェントディスパッチと 200k 以上のコンテキストウィンドウを活用してください。

有効化条件

症状 -> アクションのトリガーを使用します。一致する項目があれば、このスキルを適用し、以下のプロトコルに従って検証してください。

• スタースキーマの設計または整理
• DAX メジャーの作成またはレビュー
• リレーションシップとクロスフィルター方向の構成
• 行レベルセキュリティの実装
• モデルの健全性とパフォーマンスの監査

実践的なワークフロー

1. 変更を加える前に、現在のモデルを調査します。
2. テーブルをディメンション、ファクト、ブリッジ、またはヘルパーテーブルに分類します。
3. 暗黙的な集計より、明示的なメジャーを優先します。
4. 用途上の必要性が実証されていない限り、リレーションシップはシンプルな単方向に保ちます。
5. レポート作成者から技術フィールドを非表示にします。

MCP の実態

Power BI のモデリングツールはホスト固有です。クライアントで Power BI モデリング MCP サーバーを利用できる場合は、まず利用可能な操作を調べ、それらを必要なモデル領域（接続、テーブル、列、メジャー、リレーションシップ、DAX クエリ、セキュリティロール）に対応付けてください。

Microsoft のドキュメントを参照する場合は、Microsoft Learn MCP サーバーが有用です。次を優先してください。

• power-bi を指定した microsoft_docs_search_by_product
• 最終ページには microsoft_docs_fetch

クライアント間の移植性

このスキルは、GitHub Copilot、Claude Code、Codex で使用できるように作成されています。

• GitHub Copilot：フォルダーを Copilot から参照できるスキルパスに置くか、フォルダーの検出が利用できない場合は、ワークフローをプロジェクトの指示にまとめます。
• Claude Code：フォルダーをローカルのスキルディレクトリまたは互換性のあるプラグインソースに置きます。
• Codex：フォルダーを $CODEX_HOME/skills/powerbi-modeling にインストールまたは同期し、大幅な変更の後に Codex を再起動します。

MCP の利用可能性とフォールバック

優先 MCP サーバー：Power BI MCP

• フォールバックプロンプト：「MCP を使わずに Power BI モデリングスキルを使用してください。文書化されたローカルまたは手動のフォールバックに従い、選択したツールの範囲を示し、検証の根拠を報告してください。」
• MCP の機能が利用できない場合は、Power BI Desktop、Tabular Editor、DAX Studio、およびエクスポートしたモデルのメタデータを使用します。
• 完了前に、ローカルのモデルツールでメジャー、リレーションシップ、パフォーマンスを検証します。
• 実行中のホストで MCP 操作が利用できない場合、その操作を使用したと主張しないでください。

アンチパターン

• ソースコンテンツがすでに整っていると見なすこと：書式設定の自動化は、壊れた入力や一貫性のない入力もそのまま保持します。
• ファイルを開いて検証する工程を省くこと：ドキュメントやスプレッドシートは、スクリプトの出力ではなく、移行先のアプリで問題が発生することがよくあります。
• チェックポイントを設けずに元に戻せない編集を自動化すること：小さなマッピングミスが、ブックやドキュメント全体に影響する場合があります。

検証プロトコル

「スキルを正常に適用しました」と述べる前に、次の項目を確認してください。

1. 合格／不合格：Powerbi Modeling の実装で、対象ランタイム、フレームワークのバージョン、影響を受けるファイルが明示されています。
2. 合格／不合格：変更した範囲に対して、ビルド、リント、テスト、または同等のローカル検証を実行しています。
3. 合格／不合格：エラー、依存関係のずれ、環境の違いに関するエッジケースに対処しているか、対象外であることを明示しています。
4. 想定外ケースの検証シナリオ：正常系のテストには合格するものの、境界条件の 1 つで失敗する変更にワークフローを適用します。
5. 成功指標：未検証の成功主張がゼロであること。実装に関するすべての主張を、コマンドまたは成果物に結び付けます。

参考資料とリソース

ドキュメント

• STAR-SCHEMA - ディメンションおよびファクトのモデリングに関するガイダンス
• RELATIONSHIPS - リレーションシップのパターンとクロスフィルターのトレードオフ
• MEASURES-DAX - DAX の命名規則とメジャーの設計
• PERFORMANCE - 効果の大きい最適化のアイデア
• RLS - 行レベルセキュリティのパターン

スクリプト

• Power BI モデル監査 - 命名、ドキュメント、モデリング上の問題点をローカルで監査するヘルパー

例

• モデルの例 - モデリングパターンと DAX 構造の例

関連スキル

• documentation-authoring：ワークフローで構造化された技術文書や製品ドキュメントの作成も必要な場合に使用します。
• notion-docs：ワークフローで Notion のページやデータベースの公開も必要な場合に使用します。
• pdf：ワークフローで PDF の抽出、生成、レイアウトを考慮したレビューも必要な場合に使用します。
• word-document：ワークフローで Word 文書の作成や書式設定も必要な場合に使用します。