データ基盤構築スキル（Fabric / Databricks / Foundry IQ）
architecture の §6.6 で決めたデータ基盤を、すべて API で構築・検証する。
Foundry IQ はデータストアではなく、文書やオントロジーを根拠付きでエージェントに渡す knowledge layer として扱う。
| 原則 | 内容 |
|---|
| 役割ごとに選ぶ | system of record / analytics / semantic / knowledge を別々に決める（選定ガイド） |
| 1 基盤 = 1 リソースグループ | Databricks の managed RG は Databricks が作るので事前作成しない |
| 変更は hash 承認 | plan → planHash を提示 → apply --approve-hash。削除はスキルに含めない |
| 実測で判定 | HTTP 200・リソース存在・MCP の initialize だけで成功にしない。業務の正解まで確認する |
| キーレス | Entra トークン（standard の auth_helper）とロールで認可する。API キー・PAT を使わない |
| コストを止める | 検証後は必ず manage_compute.py stop を実行し、常時課金されるリソースを報告する |
サブリファレンス
ワークフロー（正常系）
スクリプトはすべて .github/skills/data-platform/scripts/ にある。以下では $dp と略す。
$dp = ".github/skills/data-platform/scripts"
Step 1: 選定契約を確定する
spec/data-platform.json が無ければ、architecture のヒアリング結果から作る。
python $dp/recommend_platform.py --requirements spec/data-requirements.json --out spec/data-platform.json
終了コード 3（needsDecision あり）なら、候補と理由を AskUserQuestion で提示して確定する。
decision.systemOfRecord が dataverse の部分は dataverse スキル に渡す。
Step 2: 事前確認をまとめて行う
standard の共通事前確認契約に加え、1 回の AskUserQuestion で確認する。
| # | 確認事項 | 合格条件 |
|---|
| 1 | subscription・region・名前 prefix | .env の AZURE_SUBSCRIPTION_ID / DP_LOCATION / DP_NAME_PREFIX が確定 |
| 2 | 課金の承認 | Fabric capacity・Databricks warehouse・AI Search・モデルの概算と停止方法に合意 |
| 3 | 権限 | 対象 subscription の Contributor + User Access Administrator 相当、Fabric capacity 管理者 UPN |
| 4 | テナント設定 | Fabric IQ Ontology（preview）が有効、Databricks の serverless SQL が利用可能 |
| 5 | データ分類 | 投入データに個人情報・機密情報が含まれるか、公開先（Copilot Studio / Cowork / Foundry）の利用者範囲 |
続けて読み取り専用の preflight を実行する。blocked があれば解消するまで次へ進まない。
python $dp/preflight_platform.py --platform fabric --platform databricks --platform foundry --out .data-platform/preflight.json
Step 3: デプロイ計画を作り、承認を得る
基盤ごとに計画を作る。既存 RG がある場合は --validate で ARM validate まで行う。
python $dp/deploy_platform.py plan --platform databricks --validate
出力の planHash・リソースグループ・パラメータを利用者に提示し、明示承認を得る。
Step 4: デプロイし、read-back で確定する
python $dp/deploy_platform.py apply --plan .data-platform/plan-databricks.json --approve-hash <planHash>
出力の ID（Fabric workspace / Lakehouse / Ontology、Databricks host / warehouse、Search endpoint）を .env に転記する。
status が verified でなければ troubleshooting を参照する。
Step 5: データを投入する
スキーマ変換・投入・照合は data-migration スキル で行う。
Databricks は DATABRICKS_CATALOG のスキーマ、Fabric は Lakehouse、Dataverse は dataverse スキルで作ったテーブルが投入先になる。
Step 6: セマンティック層を構成する
仕様ファイル（例: cold-chain-semantics.json）から計画を作り、承認後に適用する。
python $dp/configure_semantics.py plan --target databricks-genie --spec spec/semantics.json
python $dp/configure_semantics.py apply --plan .data-platform/plan-databricks-genie.json --approve-hash <planHash>
python $dp/configure_semantics.py plan --target foundry-kb --spec spec/semantics.json --with-fabric-ontology
Fabric IQ Ontology の entity / relationship / binding は公開オーサリング API が無いため、
ブラウザ自動化方針に従い、Edge プロファイルを確認してから統合ブラウザで構成する（手順は fabric.md）。
Step 7: runtime を検証する
業務の正解（期待値）まで実測し、合格した MCP だけを接続情報として書き出す。
python $dp/verify_platform.py --check all --spec spec/semantics.json --emit-mcp spec/mcp-endpoints.json --out .data-platform/verify.json
blocked / failed / not-tested は理由付きで報告する。空の Ontology への質問は blocked になる（正常）。
Step 8: MCP を公開先スキルへ引き渡す
spec/mcp-endpoints.json を公開先スキルへ渡す。対応は mcp-exposure.md。
公開後は、公開先の実利用者 ID で テスト計画 §6 を実行する。
Step 9: 計算を停止し、残る課金を報告する
python $dp/manage_compute.py stop --target all
Fabric Paused、warehouse STOPPED を確認し、停止できない課金（AI Search の時間課金、Databricks managed RG の NAT Gateway・Public IP、モデルのトークン従量）を利用者に報告する。