Microsoft Fabric Architecture Podcast (日本語)

Fabricのドメインはガバナンスの境界に見えますが、ドキュメントには別のことが書かれています。ドメインが実際に提供するもの、テナントで今も動き続けている既定ドメインの仕組み、そしてラベルと鍵の違いを整理します。

Show Notes

ドメインに鍵はない

Episode 38 • 2026-10-09 Duration: 10:26

Fabricのドメインはガバナンスの境界に見えますが、ドキュメントには別のことが書かれています。ドメインが実際に提供するもの、テナントで今も動き続けている既定ドメインの仕組み、そしてラベルと鍵の違いを整理します。

What we discuss

  • How it actually works underneath the abstraction
  • The pattern we keep seeing in the field
  • A real Reddit/Microsoft Q&A question unpacked
  • Where the obvious answer breaks
  • F-SKU realism — what this actually costs
  • When the rejected approach is actually right
  • Risks of the recommended path
  • The architectural principle to take home

Watch the episode

The Fabric Friday video on this topic: https://youtu.be/8wRSvnF_CtQ

From the video

  • 7:46 Demo: The Contributor Who Cannot Contribute
  • 3:15 Demo: The Filter That Is Not a Fence
  • 12:51 Demo: An Assignment Nobody Made
  • 14:42 The Sensitivity Label Override Ladder

Resources

About the show

AI-generated voices. Matthias — cloned voice. Fabia — designed AI co-host. See Matthias live on YouTube (Fabric Friday), at his meetups, and at conferences like FabCon.

Hosted by Matthias Falland — Microsoft Data Platform MVP and community architect behind the Fabric Periodic Table. New episodes every Friday.

Submit your case

Have an architecture decision you are wrestling with? DM Matthias on LinkedIn — find him as Matthias Falland. Three to five sentences about the decision, your team size, and your current stack. We anonymize before airing.


このポッドキャストは AI によって生成されています。どちらの音声も合成です。Matthias はクローン音声、Fabia は設計された AI 共同ホストです。

Brand design based on fabricperiodictable.com.

What is Microsoft Fabric Architecture Podcast (日本語)?

Microsoft Fabric のア���キテクチャ意思決定。匿名化された実際の顧客シナリオ、コストのリアリズム、反論を含む。Fabric Friday の録画に合わせた週刊エピソード。AIにより生成。

ドメインに鍵はない
Episode 38 | 2026-10-09
Fabric Architecture Podcast | Hosted by Matthias Falland with AI co-host Fabia

---

[00:08] Fabia: 「ドメインの割り当ては、テナントユーザーにとってアイテムの可視性やアクセスに影響しません」。Microsoft Learnの原文です。たった一文。

[00:12] Matthias: なのに、ドメインをセキュリティ境界として構築しているテナントに何度も出くわすんですよね。

[00:15] Fabia: 「ドメイン」という言葉が、そう思わせてしまうんです。

[00:17] Matthias: じゃあ、実際には何をしているんですか?

[00:18] Fabia: それを今日、紐解いていきます。ドメインが何を与えてくれるのか、何をひそかに持っていくのか。そして今この瞬間もテナントで動き続けている仕組みについて。

[00:23] Matthias: 管理ポータルから全員が立ち去った後もね。

[00:25] Fabia: ワークスペースをドメインに割り当てると、そのワークスペース内のすべてのアイテムのメタデータにドメイン属性が付きます。この属性が、OneLakeカタログのドメインフィルターを支えています。

[00:31] Matthias: それと、テナント設定をドメインレベルに委任できますよね。たとえば認定。ドメイン管理者が有効にして、認定者を指名する。

[00:35] Fabia: どれも持つ価値があります。カタログのフィルターだけでも、大規模テナントの使い勝手がまるで変わります。

[00:38] Matthias: ここまで聞くと……普通に便利ですね。

[00:39] Fabia: 便利です。ただ、同じドキュメントにこうも書いてあります。テナント内のすべてのユーザーが、ロールに関係なくすべてのドメインを見ることができると。

[00:44] Matthias: ドメイン名が全員に公開されている?

[00:45] Fabia: 全員にです。財務というドメインにロールを持たない人でも、カタログのドメインフィルターにそれが表示されます。

[00:49] Matthias: つまり、機密の買収案件にちなんだドメイン名をつけたら、買収の存在を公表していることになる。

[00:52] Fabia: もうひとつ、厳密な制約があります。ワークスペースが所属できるドメインは1つだけです。2つの事業部門にまたがるなら、どちらかを選ぶか、ワークスペースを分割するしかありません。

[00:58] Matthias: ワークスペースの分割は分割で、別の問題を生みますけどね。

[00:59] Fabia: ロールは3つ。真ん中のロールが名前ほど強くありません。ドメイン管理者は、ワークスペースの割り当て、共同作成者の定義、委任された設定の上書きができます。ただし、ドメインの名前変更や削除、管理者リストの編集はできません。それができるのはFabric管理者だけです。

[01:08] Matthias: 共同作成者はどうですか?

[01:09] Fabia: ここがチームのつまずくところです。ワークスペースをドメインに割り当てるには、共同作成者がすでにワークスペース管理者である必要があります。

[01:13] Matthias: つまり、すでに持っている権限を使う許可であって——

[01:15] Fabia: ——そこです。ワークスペース管理者ロールなしで共同作成者だけ渡しても、文字通り何もできません。

[01:18] Matthias: そのチケット、見たことがあります。スチュワードに共同作成者を付与して、何も変わらなくて……だいたい1週間後に混乱が始まるんですよね。

[01:23] Fabia: ただ、設計としては正しいんです。ワークスペースの割り当てはメタデータを変更し、アイテムのラベル付けにも影響し得ます。管理権限のないワークスペースに対してそれを許すわけにはいかない。

[01:29] Matthias: 動画では、デモ用のIDがdemo-operationsの共同作成者を受け取りました。ドメインのタブすら表示されなかった。

[01:33] Fabia: 共同作成者にはタブが出ません。そのIDがワークスペース管理者になって初めて、ドメインフィールドが現れました。

[01:36] Matthias: サブドメインはどうですか?管理構造をもっと深くできますか?

[01:38] Fabia: 全般設定のみです。名前と説明だけ。独自の管理者は持てず、親ドメインから引き継ぎます。階層は2段まで。管理は1段だけです。

[01:42] Matthias: 浅いほうの数字で設計すべきですね。

[01:43] Fabia: 「機密性の高いワークスペースを専用ドメインに入れました。これで保護されていますか?」

[01:47] Matthias: この質問が繰り返し出てくるのは、画面の見た目が「はい」と答えたくなるようにできているからです。

[01:50] Fabia: 答えはいいえです。ドメインは属性を付与するだけ。属性は記述するもの、アクセス許可が判断するものです。割り当てのプロセスで、誰がアクセスしようとしているかは一切評価しません。

[01:56] Matthias: しかもドメイン名は全員に見えます。つまり、機密データの場所にラベルを貼っただけで、何も保護していない。

[01:59] Fabia: ワークスペースのロールとアイテムのアクセス許可が本当の境界です。それはドメインの下のレイヤーにあります。

[02:02] Matthias: 動画のデモで具体的に見せました。同じID、2つのLakehouse、異なるドメイン。ワークスペースのロールがあったほうは開けました。なかったほうは開けなかった。ドメインはどちらの結果にも関与していません。

[02:09] Fabia: ドメインが決めたのは、カタログに何が表示されるかです。開けるかどうかを決めたのは、ワークスペースのロールです。

[02:13] Matthias: 正直に答えるなら、整理しただけです。それだけ。

[02:14] Fabia: チームが一度設定して、そのまま忘れてしまう割り当ての仕組みがあります。既定のドメインです。

[02:17] Matthias: 通常の割り当てと何が違うんですか?

[02:19] Fabia: ユーザーまたはセキュリティ グループを指定します。Fabricが既存のワークスペースをスキャンして、リスト上のユーザーがワークスペース管理者で、かつドメインが未設定なら、割り当てます。すでにドメインがあれば、そのまま。既定のドメインが上書きすることはありません。

[02:27] Matthias: そこまでは慎重ですね。

[02:28] Fabia: 慎重です。ただ、そのスキャンの後が問題です。リスト上のユーザーがワークスペースを新規作成するたびに、既定のドメインに入ります。来月も。来年も。誰も見ていなくても。

[02:33] Matthias: 常設のルールじゃないですか。

[02:34] Fabia: しかも副作用があります。この方法で割り当てられたワークスペースについて、対象ユーザーは通常、共同作成者になります。利便性を設定したつもりが、ロールまで配っていた。

[02:40] Matthias: セキュリティ グループがそのリストに入っていたら、グループのメンバーシップがドメインの構成に組み込まれますよね。誰かがグループに参加すれば、次に作るワークスペースが既定のドメインに入る。Fabricには誰も触れていないのに。

[02:47] Fabia: 動画では、デモ用のIDがドメイン未選択でワークスペースを作成しました。設定を閉じて、開き直したら、demo-salesと表示されていた。誰も選んでいないのに。

[02:53] Matthias: 見ていなくても動き続ける、唯一の割り当て方法です。意図してやったなら、強力です。

[02:55] Matthias: 秘密度ラベルの委任はどうですか?ドメインが実際にガバナンスを発揮する唯一の場所ですよね。

[02:58] Fabia: ドメイン管理者が既定の秘密度ラベルを設定できます。まだプレビュー中の機能で、先に有効化が必要です。Fabricがラベルを適用するタイミングは2つ。新しいアイテムが作成・保存されたとき。そしてラベルのない既存アイテムが更新・保存されたときです。

[03:06] Matthias: すでにラベルが付いているアイテムはどうなりますか?

[03:08] Fabia: 手動で適用されたラベルは上書きされません。優先度に関係なく。それ以外は、Purviewのラベル順序との比較になります。

[03:12] Matthias: 人の判断が常に優先される。すっきりしていますね。

[03:14] Fabia: ただし、デプロイ パイプラインとGit統合は現在サポートされていません。ドメインが持つ唯一のガバナンス機能が、CI/CDを通じてコンテンツに追従しない。コストの本質は、チームが構築したと思い込んでいるものと、実際に構築されたものとのギャップにあります。

[03:22] Matthias: こちらで作って、あちらにデプロイして、ラベルは置き去り。コスト圧力のかかる8人のチームで、誰が気づきますか?

[03:26] Matthias: でも、ここで反論したいんです。このエピソードではドメインが何でないかばかり話してきました。では、いつドメインが正解なんですか?

[03:30] Fabia: ワークスペースが何百もあって、誰も何も見つけられないテナント。一貫した命名規則を伴うドメイン構造があれば、実際に使われるカタログになります。事業部門ごとに独自の認定ポリシーが必要な場合も、委任された設定で対応できます。毎回Fabric管理者を会議に呼ぶ必要はありません。

[03:39] Matthias: つまり条件は……ワークスペースのロールとアイテムのアクセス許可で、すでに本来のセキュリティを構築してあること。ドメインはその上に載せるものです。組織化のレイヤー。下のレイヤーを飛ばしたら、見せかけの床になります。

[03:46] Fabia: 事業部門の存在自体が機密でなければ、ドメイン名は自由に使える整理手段です。看板に出しても問題ない名前にしておけばいい。

[03:50] Matthias: 私が本当に心配するリスクは、既定ドメインの設定ミスではありません。それは午後で直せます。心配なのは命名のほうです。買収案件の存在を、知るべきでない相手に漏らすドメイン名。それは情報開示の問題であって、Fabricでは直せません。

[03:58] Fabia: しかも取り消せません。保存した瞬間から、全員に見えていました。

[04:00] Matthias: もうひとつ注意すべきは、既定ドメインがひそかに共同作成者ロールを配っている点です。ロールの棚卸しが想定と違う。特にセキュリティ グループがトリガーになっている場合は。

[04:05] Fabia: メンバーシップの変更がFabricの外で起きるからです。

[04:07] Matthias: では、まとめます。ドメインは「このデータは誰のものか」に答えるものです。検索と委任に使ってください。本当の境界はワークスペースのロールとアイテムのアクセス許可で構築する。そして既定ドメインのリストは四半期ごとに監査してください。まだ動いていますから。

[04:16] Fabia: パターンが構成を決める。パターンが「整理して見つける」なら、ドメインは正しいツールです。「制限して守る」なら、レイヤーが違います。

[04:20] Matthias: どのオフィスにもファイルキャビネットがあって、引き出しにラベルが貼ってあります。建物にいる全員がそれを読めます。でも誰も、ラベルを鍵と間違えたりしない。

[04:25] Fabia: Fabricでは別みたいですけどね。

[04:27] Matthias: テナントの見方が変わったら、LinkedInでご連絡ください。Matthias Fallandです。

[04:30] Fabia: また来週お会いしましょう。

---

End of episode. ~04:31 estimated.