フォームから列を外しても、その列は API・エクスポート・レポートから普通に読める。
列の機密を守るのはフィールドセキュリティプロファイル（列ごとに「許可した身分だけ可視」と設定するプロファイル）の仕事であり、フォーム編集とは別のレイヤーで動く。
「行は読めるのに、その列だけ null が返る」という状態を設定後に API で確認するまでが、設計の完了だ。
「フォームから外す」と「列を隠す」は別の操作
フォームから列を外すのは、画面（UI）からその欄を取り除く操作だ。モデル駆動アプリやキャンバスアプリのフォームデザイナーで列を削除すれば、その画面には表示されなくなる。
しかしそれは、Dataverse テーブルの列そのものが隠れたわけではない。別のビュー・別のフォーム・Web API・Excel エクスポート・Power BI レポート——どの経路からも当該列は依然として読める。
| 操作 | 対象 | 別の画面・API からの読み取り |
|---|---|---|
| フォームから列を外す | 特定のフォーム画面のみ | 読める |
| フィールドセキュリティプロファイルで保護 | テーブルの列単位・全入口 | 許可がなければ null が返る |
Microsoft Learn（2025年6月更新）には「列セキュリティの適用範囲は組織横断であり、クライアントアプリ・Web サービス呼び出し・フィルタービューを使ったレポートを含む全データアクセス要求に適用される」と明記されている。フォームを触っただけではこのレイヤーには一切届かない。
行の鍵と列の鍵は独立した 2 軸
Dataverse のアクセス制御には、独立した 2 つの軸がある。
- 行の軸：どのレコードが見えるか（セキュリティロール、行レベルアクセス制御で制御）
- 列の軸：見えるレコードの中でどの欄を読ませるか（フィールドセキュリティプロファイルで制御）
2 軸は直交する。行を読める権限を持つユーザーでも、列セキュリティが設定されていればその列の値は返ってこない。与信スコア・年収帯・人事評価コメントなど、同じテーブルの中に機密度の異なる列が混在する業態では、この 2 軸を意識した設計が必要になる。
フィールドセキュリティプロファイルの設定手順（4 ステップ）
設定は Power Apps と Power Platform 管理センターの 2 箇所を行き来する。
ステップ 1：列のセキュリティを有効にする
Power Apps > Dataverse > テーブル > 対象の列 > 詳細オプション > 「列のセキュリティを有効にする」をオン。この設定をした時点で、プロファイルが割り当たっていないユーザーはシステム管理者ロールでなければ当該列にアクセスできなくなる（既定は不可視）。
ステップ 2：列セキュリティプロファイルを作成
Power Platform 管理センター > 設定 > ユーザー + アクセス許可 > 列のセキュリティ プロファイル > 新規作成。プロファイルには任意の名前をつける（例：「与信閲覧者」「本部専用」）。
ステップ 3：プロファイルに列の権限を設定
プロファイルを開き、保護した列に対して Read / Create / Update の許可・不許可を設定する。読み取りだけ許可して更新は禁止、という細かい設定も可能だ。
ステップ 4：プロファイルをユーザーまたはチームに割り当て
プロファイルをユーザー個人またはチームに紐付ける。チームへの割り当てを使うと、組織変更時にプロファイルの再配布コストが下がる。
設定が本物かどうか——破壊検証の手順
設定後に確認せずに「閉じた」と思い込むのが最も危険な状態だ。許可を持たないユーザーの権限で Web API を叩き、null が返ることを実際に確かめる。
前提：許可のないユーザー（または検証用テストアカウント）で以下のリクエストを発行する。
GET https://<org>.api.crm.dynamics.com/api/data/v9.2/<テーブル複数形>?$select=<保護した列の論理名>
Microsoft Learn（2026年2月更新）には次の 2 点が明記されている。
- 「セキュリティ保護された列の値を返す際のデフォルト API の動作は、データを返さないことである」
- 「呼び出し元アプリケーションは、セキュリティによる null と実際の null を区別できない」
403 エラーが返るわけではない。列プロパティはレスポンスに含まれるが、値は null になっている。エラーが出ないからといって設定が効いていないとは判断できないし、null が返っているからといって設定漏れとも限らない。$select で明示指定して null が返ることを確認するのが破壊検証の正確な手順だ。
フォームやビュー上では、保護された列は空白や非表示ではなく「****」と鍵アイコンで表示される。これは「ここに値があるが、あなたには見せない」という設計上の意図的な表現で、フォームから列を外した際の「欄がない」とは視覚的にも意味が異なる。
全入口に適用される、ということの意味
フィールドセキュリティプロファイルの制御が適用されるコンポーネントは公式ドキュメント（2025年6月更新）で次のように列挙されている。
- Dataverse Web サービス（Web API）
- レポート
- 検索（Search）
- オフライン
- フィルタービュー
- 監査（Auditing）
- 重複データ検出
「全入口に適用」とは、これらのどの経路を使っても同じ制御が機能するということだ。許可のないユーザーが Excel にエクスポートしても、Power BI レポートを作っても、保護列は null として扱われる。設定を一箇所で管理すれば、すべての出口が揃う。
データマスキング機能（2025 年 GA）——null の代わりに部分マスクを返す
2025 年に GA となったデータマスキング機能を使うと、null 返却の代わりに部分マスク済みの文字列を返せるようになった。正規表現でマスキングルールを定義し、たとえば「電話番号の末尾 4 桁だけ表示」「メールアドレスの @ 前を非表示」といった表示が可能になる。
対応する列タイプは数値列・単一行テキスト・複数行テキスト。適用はサーバーサイドで行われるため、フォーム・ビュー・API・エクスポートのどの経路でも一貫したマスク表示になる。
null を返すことで「列の存在自体を知らせない」設計をするか、部分マスクを返すことで「値はあるが読ませない」設計をするかは、業務要件に応じて選択する。
誠実な限界の開示
フィールドセキュリティプロファイルで「完全セキュア」とは言えない。主な限界は 2 点ある。
許可名簿の運用依存：誰にプロファイルを割り当てるかの判断と管理は運用側の責任だ。プロファイルを付けすぎれば制御が崩れ、付け忘れが重なれば意図した境界を保てない。技術的な設定と並行して「誰に、いつ、どのプロセスで付与・剥奪するか」の運用設計が必要になる。
全権管理者の扱い：セキュリティプロファイルが設定されていない場合、システム管理者ロールのみが当該列にアクセスできる、と公式ドキュメントに記載されている。管理者権限の扱いは組織のガバナンスポリシーで別途設計する。
列の機密境界を「構造に置く」ことはフィールドセキュリティプロファイルで実現できる。そこから先の「誰に開けるか」の運用設計は、設定者の責任範囲として引き受ける形になる。
まとめ
フォームから列を外すのは画面の話であり、列の機密を守る設定ではない。フィールドセキュリティプロファイルで「既定は不可視・許可した身分だけ可視」と設定し、破壊検証で null 返却を確認するまでが列の機密境界を引く作業だ。
次の一歩：Power Apps で対象列の「列のセキュリティを有効にする」をオンにし、Power Platform 管理センターでプロファイルを 1 つ作成する。設定後に許可のないアカウントで $select を使って Web API を叩き、null が返ることを確認する。
関連記事：行レベルのアクセス制御（どのレコードを見せるか）については「Dataverse のビューフィルターとアクセス制御——行レベルで見せる範囲を構造的に絞る」を参照。