Salesforce 項目レベルセキュリティの徹底解説：管理者向け完全ガイド

概要とビジネスシーン

Field-Level Security (FLS)（項目レベルセキュリティ）は、Salesforceプラットフォームにおいて、特定のユーザーがオブジェクトの個々のフィールドにアクセスできるかどうかを制御する重要な機能です。これは機密データの保護、コンプライアンスの維持、そしてユーザーが必要な情報にのみアクセスできるようにするために不可欠なセキュリティ層を提供します。レコードへのアクセスが許可された後、さらに詳細な粒度でフィールドの参照や編集権限を制御することができます。

実際のビジネスシーン

FLSは、様々な業界で機密情報の管理とコンプライアンス遵守において中心的な役割を果たします。

シーンA - 金融業界（個人情報保護）：

ビジネス課題：ある銀行では、顧客の社会保障番号や口座番号といった機密性の高い個人情報をSalesforceで管理しています。営業担当者には顧客の連絡先や取引履歴へのアクセスを許可する一方、これらの機密情報へのアクセスは特定のコンプライアンスチームやサポート担当者のみに限定する必要があります。
ソリューション：FLSを使用して、営業担当者のプロファイルや権限セットに対して、社会保障番号および口座番号フィールドの「参照アクセス」と「編集アクセス」を無効化します。これにより、営業担当者はこれらの機密情報をUIやAPI経由で参照・編集できなくなります。
定量的効果：個人情報保護法（例：GDPR、CCPA）への準拠を強化し、データ漏洩リスクを50%低減。コンプライアンス違反による潜在的な罰金を回避し、顧客の信頼を維持。

シーンB - 医療業界（患者のプライバシー）：

ビジネス課題：医療機関では、患者の病歴、診断、投薬情報などの医療記録をSalesforceで管理しています。医師、看護師、医療事務員といった異なる職種のスタッフが患者情報にアクセスしますが、職務に応じてアクセスレベルを厳密に制御する必要があります。例えば、事務員は請求情報にアクセスできますが、診断結果や投薬履歴にはアクセスできません。
ソリューション：FLSを適用し、医師のプロファイルにはすべての医療記録フィールドへの参照・編集アクセスを許可します。一方、医療事務員のプロファイルでは、診断結果や投薬履歴フィールドのアクセスを無効にし、請求関連フィールドのみを許可します。
定量的効果：HIPAA（医療保険の携行性と説明責任に関する法律）を含む医療情報プライバシー規制への準拠を達成し、患者のプライバシー侵害リスクを大幅に削減。内部監査の効率が20%向上。

シーンC - 人事部門（給与情報の管理）：

ビジネス課題：企業の人事部門では、従業員の給与、評価、健康情報といった非常に機密性の高いデータをSalesforceで管理しています。通常の人事担当者には従業員情報へのアクセスを許可する一方で、給与担当者のみが給与フィールドを参照・編集できるようにする必要があります。
ソリューション：従業員オブジェクトの給与フィールドに対し、FLSを使用して特定の「給与担当者」権限セットにのみ参照・編集アクセスを付与し、他の全ての人事プロファイルからはアクセスを無効にします。
定量的効果：内部統制を強化し、給与情報への不正アクセスリスクを90%削減。情報管理の厳格化により、従業員の信頼度が向上し、内部監査での指摘事項が減少。

技術原理とアーキテクチャ

Field-Level Security (FLS) は、Salesforceのセキュリティモデルの中核をなす要素の一つです。その動作メカニズムとアーキテクチャはシンプルでありながら強力です。

基礎的な動作メカニズム

FLSは、ユーザーが特定のレコードにアクセスする許可（オブジェクトレベルセキュリティ）を得た後に適用されます。つまり、まずユーザーがオブジェクト自体へのアクセス権を持っているかを評価し、次にそのオブジェクト内の個々のフィールドへのアクセス権を評価する二段階のプロセスを踏みます。ユーザーがSalesforce UIでレコードを表示しようとする、レポートを実行する、またはAPIを通じてデータを取得しようとする際、Salesforceプラットフォームは以下の要素を考慮して、どのフィールドが表示され、編集可能であるかを動的に決定します。

FLSは、参照アクセス（readable）と編集アクセス（editable）の2つのレベルでフィールドの可視性を制御します。フィールドが「参照不可」に設定されている場合、UI、レポート、およびAPIのいずれからもそのフィールドの値は見えなくなります。同様に、「編集不可」に設定されている場合、そのフィールドの値を変更することはできません。

主要コンポーネントと依存関係

FLSの主要なコンポーネントは以下の通りです。

プロファイル (Profile)：ユーザーのタイプ（例：営業、サポート、システム管理者）に基づいて、オブジェクトやフィールドへの基本的なアクセス権を定義します。FLS設定の主要なコンポーネントの一つです。
権限セット (Permission Set)：プロファイルで定義されたアクセス権を拡張するために使用されます。プロファイルで設定されたFLSを上書きし、よりきめ細かなアクセス権をユーザーに付与できます。
オブジェクト (Object)：FLSが適用されるレコードの論理的なコンテナです（例：Account、Opportunity、カスタムオブジェクト）。
フィールド (Field)：FLSが制御する個々のデータ要素です（例：Account.AnnualRevenue、Contact.Email）。
設定 UI (Setup UI)：Salesforce管理者がFLSを視覚的に設定するためのグラフィカルインターフェースです。
Metadata API：FLS設定をプログラム的に取得、デプロイ、管理するためのAPIです。CI/CDパイプラインや大規模な設定管理に利用されます。

データフロー

ユーザーがSalesforceでフィールドデータにアクセスしようとする際のFLSの評価フローは以下の通りです。

ステップ	説明	評価対象
1. ユーザーアクション	ユーザーがレコード（例: Account）の参照、編集、またはAPI経由での取得を試みます。	Salesforce UI / APIリクエスト
2. オブジェクトレベルセキュリティ (OLS) 評価	Salesforceは、ユーザーがAccountオブジェクト自体にアクセスできるか（参照、作成、編集、削除）を評価します。	ユーザーのプロファイル、割り当てられた権限セット
3. レコードレベルセキュリティ評価	OLSが許可された場合、ユーザーが特定のレコード（例: 特定のAccountレコード）にアクセスできるか（共有設定など）を評価します。	組織の共有設定（OWD）、共有ルール、ロール階層、手動共有、Apex共有
4. FLS 評価	レコードへのアクセスが許可された場合、Salesforceは対象ユーザーのプロファイルと権限セットに基づいて、特定のフィールド（例: Account.AnnualRevenue）の参照および編集が許可されているかを評価します。最も緩い権限（例: プロファイルで不可、権限セットで可の場合、可となる）が適用されます。	ユーザーのプロファイル、割り当てられた権限セットのFLS設定
5. データ表示/編集	参照および編集が許可されたフィールドのみがSalesforce UIに表示され、編集可能になります。API経由のクエリでは、許可されたフィールドのみが結果として返されます。	Salesforce UI / API応答

ソリューション比較と選定

Salesforceには、ユーザーに表示される情報を制御するための複数のメカニズムが存在します。FLSはその中で最も厳格で包括的なセキュリティ層を提供しますが、他のソリューションとの違いを理解し、適切に使い分けることが重要です。

ソリューション	適用シーン	パフォーマンス	Governor Limits	複雑度
field-level security	データモデルレベルでの厳格なアクセス制御。APIアクセス、レポート、リストビューにも適用され、機密データ保護の基盤となる。	非常に高速（プラットフォームネイティブで効率的に評価）	該当なし（直接的なGovernor Limitなし）	低〜中（プロファイル・権限セットが多いと管理が複雑化しやすい）
ページレイアウト (Page Layout)	UI上でのフィールドの表示/非表示、表示順序、セクション、必須設定を制御。特定のプロファイル/レコードタイプに対して異なるUIを提供。APIアクセスには影響しない。	高速（プラットフォームネイティブ）	該当なし	低
Apex トリガー/クラス	カスタムロジックによるデータ操作時の動的なバリデーション、計算、関連オブジェクトの更新。プログラムによる柔軟なアクセス制御が可能だが、開発が必要。	中〜高（コードの複雑さやクエリ数による）	高（CPU時間、SOQLクエリ、DML操作など多数）	高
LWC/Visualforce コンポーネントの条件付きレンダリング	カスタムUIコンポーネント内で、特定の条件に基づいてフィールドやコンポーネントの表示/非表示を制御。UIレベルの制御であり、APIアクセスには影響しない。	中（クライアント側レンダリング、Apex呼び出し時はサーバー負荷）	該当なし（Apex呼び出し時は関連制限）	中〜高

field-level security を使用すべき場合

✅ 機密データへのアクセスを厳格に制御したい場合。例えば、社会保障番号、給与、健康情報などのフィールドを特定のユーザーグループ以外には見せないようにしたい場合。
✅ UIだけでなく、API、レポート、リストビュー、データローダーなど、あらゆるインターフェースからのフィールドへの参照・編集を制限したい場合。
✅ 複数のユーザープロファイルや権限セット間で、特定のフィールドへのアクセス権限に明確な違いがある場合。
✅ 企業のコンプライアンス要件（例：GDPR、HIPAA、SOX）を満たすために、データプライバシーとセキュリティをデータモデルレベルで確保する必要がある場合。

field-level security を不適用とするシナリオ

❌ 単に UI 上でフィールドの表示順序を変更したい、または特定のフィールドをグループ化したいだけの場合（ページレイアウトで十分）。
❌ 特定の条件（例: レコードのステータスが「完了」の場合）に基づいて動的にフィールドを読み取り専用にしたい場合（ページレイアウトの割り当てやLWC/Visualforceの条件付きレンダリング、Apexによる制御がより柔軟）。

実装例

Salesforce管理者として、Field-Level Security (FLS) を設定する最も一般的な方法は、Salesforceの「設定」UIを使用することです。しかし、大規模な組織やDevOpsプロセスを導入している組織では、Metadata API (メタデータAPI) を使用してプロファイルや権限セットのXML定義を管理し、デプロイすることが一般的です。ここでは、AccountオブジェクトのAnnualRevenueフィールドを、特定のプロファイル（例：「Standard User」）から非表示にする設定を例に、UIからの手順とMetadata APIでの表現を示します。

1. UIからのFLS設定手順

Salesforceにシステム管理者としてログインします。
「設定 (Setup)」を開き、「オブジェクトマネージャ (Object Manager)」に移動します。
対象オブジェクトである「Account (取引先)」を選択します。
左側のナビゲーションから「項目とリレーション (Fields & Relationships)」をクリックします。
対象フィールドである「年間売上 (Annual Revenue)」を選択します。
「項目レベルセキュリティの設定 (Set Field-Level Security)」ボタンをクリックします。
表示されるプロファイルと権限セットのリストから、「Standard User」プロファイルを探します。
「Standard User」プロファイルの行にある「参照アクセス (Read Access)」と「編集アクセス (Edit Access)」のチェックボックスの両方をオフにします。
「保存 (Save)」をクリックして変更を適用します。

これで、「Standard User」プロファイルを持つユーザーは、UI、レポート、APIのいずれからも取引先の「年間売上」フィールドを参照・編集できなくなります。

2. Metadata APIでのFLS表現（XMLコード例）

UIで設定した内容は、内部的にはMetadata APIを通じてXML形式で管理されます。以下は、上記の設定がプロファイルファイル（Profile.profile-meta.xml）でどのように表現されるかを示すXMLスニペットです。

<?xml version="1.0" encoding="UTF-8"?>
<Profile xmlns="http://soap.sforce.com/2006/04/metadata">
    <fullName>Standard User</fullName> <!-- 対象のプロファイル名 -->
    <!-- 他のプロファイル設定が続く -->

    <fieldPermissions>
        <editable>false</editable> <!-- このフィールドは編集不可 -->
        <field>Account.AnnualRevenue</field> <!-- 対象のフィールドAPI名 -->
        <readable>false</readable> <!-- このフィールドは参照不可 -->
    </fieldPermissions>

    <!-- 必要に応じて他の fieldPermissions や設定が続く -->
</Profile>

実装ロジックの解析：

<Profile>タグ：このXMLファイルがSalesforceのプロファイル定義であることを示します。fullName属性でプロファイルのAPI名（例：Standard User）を指定します。
<fieldPermissions>タグ：特定のフィールドに対する権限設定を定義します。プロファイルまたは権限セット内で、フィールドごとにこの要素を複数記述できます。
<editable>false</editable>：この要素は、対象のフィールドが現在のプロファイルを持つユーザーによって編集可能であるかどうかを定義します。falseに設定することで、編集が禁止されます。
<field>Account.AnnualRevenue</field>：対象となるフィールドのAPI名を指定します。この例では、AccountオブジェクトのAnnualRevenueフィールドが対象です。
<readable>false</readable>：この要素は、対象のフィールドが現在のプロファイルを持つユーザーによって参照可能であるかどうかを定義します。falseに設定することで、参照が禁止されます。

このXMLスニペットをSFDX CLIやWorkbenchなどのツールを使用してSalesforce組織にデプロイすることで、UIで設定した場合と同様にFLSが適用されます。権限セット（Permission Set）の場合も、PermissionSet.permissionset-meta.xmlファイル内に同様の<fieldPermissions>エントリが記述されます。

注意事項とベストプラクティス

Field-Level Security (FLS) は強力な機能ですが、効果的に管理し、潜在的な問題を回避するためには、いくつかの注意事項とベストプラクティスを理解しておく必要があります。

権限要件

FLS設定の変更に必要な権限：システム管理者プロファイルを持つユーザー、または「プロファイルの管理」および「権限セットの管理」権限が付与されたカスタムプロファイルのユーザーのみがFLSを変更できます。カスタムオブジェクトやカスタムフィールドのFLSを設定する場合、「オブジェクトの管理」権限も関連することがあります。
最小権限の原則 (Principle of Least Privilege)：ユーザーには、業務遂行に必要な最低限のアクセス権限のみを付与するべきです。不要なフィールドアクセスはデータ漏洩のリスクを高めます。

Governor Limits

FLS自体には直接的なGovernor Limits（ガバナ制限）は存在しません。これはSalesforceプラットフォームのセキュリティモデルにネイティブに組み込まれており、非常に効率的に処理されます。しかし、大量のプロファイルや権限セットの管理、複雑な権限モデルは、以下の点で間接的に影響を与える可能性があります。

設定管理の複雑度：多数のプロファイルや権限セットにFLSを散在させると、設定のオーバーヘッドが増大し、変更時の影響範囲分析やデプロイに時間がかかります。
Apexの考慮事項：ApexコードからFLSを強制しない場合、ユーザーがUIから見えないフィールドでもApex経由でデータにアクセスできてしまう可能性があります。Apex開発者は、セキュリティを考慮してWITH USER_MODE句やSchema.SObjectField.isAccessible()などのメソッドを使用してFLSをチェックする必要があります。

エラー処理

「Insufficient Privileges (権限が不足しています)」エラー：ユーザーがレコードにアクセスできるにもかかわらず、特定のフィールドが非表示になったり、編集できない場合にこのエラーが発生することがあります。これはFLSにより参照または編集がブロックされている可能性が高いです。対象ユーザーのプロファイルと権限セットのFLS設定を再確認してください。
API経由でのデータ取得時のフィールド欠落：SOQLクエリなどで特定のフィールドをリクエストしても結果に含まれない場合、FLSによりそのフィールドへの参照アクセスが許可されていない可能性があります。

パフォーマンス最適化と管理のベストプラクティス

権限セットの積極的な活用：プロファイルはできるだけ汎用的なベースラインのアクセス権を定義するために使用し、特定の役割やタスクに必要な追加のフィールドアクセス権は権限セットで付与します。これにより、プロファイルの数を減らし、FLSの管理を簡素化できます。
権限セットグループ (Permission Set Groups) の利用：複数の権限セットをまとめてユーザーに割り当てることで、権限管理のオーバーヘッドを削減し、一貫性を保ちます。大規模な組織や複雑なロールを持つ場合に特に有効です。
セキュリティ監査と定期的な見直し：FLS設定は、組織のニーズや規制要件の変化に合わせて定期的に見直し、最新の状態に保つべきです。Salesforce ShieldのEvent Monitoring (イベント監視) やField Audit Trail (項目履歴管理) を活用して、機密データへのアクセス状況を監視することも推奨されます。
テストの実施：FLS設定を変更した際は、必ず影響を受けるすべてのユーザープロファイルや権限セットで、意図した通りにフィールドの表示・編集が制御されているかをテストします。特にAPI連携やカスタムコードがフィールドを参照・更新するシナリオでは、入念なテストが必要です。

よくある質問 FAQ

Q1：FLSとページレイアウトの違いは何ですか？

A1：ページレイアウトはUI上のフィールドの表示（順番、セクション、必須設定）を制御しますが、APIアクセスには影響しません。つまり、ページレイアウトで非表示にしても、API経由ではフィールド値にアクセスできてしまいます。一方、FLSはUI、API、レポートなど、あらゆるインターフェースにおけるフィールドレベルのデータアクセスを厳密に制御します。FLSで非表示にされたフィールドは、ページレイアウトで表示設定されていてもユーザーには見えません。

Q2：FLSが意図した通りに機能しない場合、どのようにデバッグすればよいですか？

A2：まず、問題のユーザーに割り当てられているプロファイルとすべての権限セットを確認し、対象フィールドの「参照アクセス」および「編集アクセス」が正しく設定されているかを確認してください。Salesforceの「拡張プロファイルユーザーインターフェース」または「権限セットの詳細ページ」には、特定のユーザーのフィールドアクセス権限を視覚的に確認できるツールがあります。また、開発者がApexコード内でFLSをチェックする場合は、Schema.SObjectField.isAccessible()やisUpdateable()メソッドの結果を確認することがデバッグに役立ちます。

Q3：FLS設定が多すぎるとパフォーマンスに影響しますか？

A3：FLSはSalesforceプラットフォームのネイティブ機能であり、その評価は非常に効率的です。個々のFLS設定自体が直接パフォーマンスボトルネックになることは稀です。しかし、非常に多くのプロファイルや権限セットがあり、それぞれに多数のFLSが定義されている場合、全体的な管理の複雑さやユーザープロビジョニングのオーバーヘッドが増加する可能性があります。このため、一貫性のある権限モデルを設計し、権限セットグループなどを活用して管理効率を高めることが重要です。

まとめと参考資料

Field-Level Security (FLS) は、Salesforceにおけるデータセキュリティの最も基本的ながらも重要な側面です。Salesforce管理者としてFLSを適切に設計・実装・管理することは、組織のデータプライバシーを保護し、規制遵守を確実にする上で不可欠な役割を果たします。

重要ポイント：

FLSはSalesforceプラットフォームのあらゆるインターフェース（UI、API、レポートなど）において、個々のフィールドへのアクセスを厳密に制御します。
機密データ保護とコンプライアンス（GDPR、HIPAAなど）の要件を満たす上で中心的な役割を担います。
プロファイルと権限セットを通じて設定され、権限セットはプロファイルのアクセス権を拡張するために利用されます。
ページレイアウトとは異なり、FLSはフィールドの表示だけでなく、データアクセス自体を制限します。
最小権限の原則に従い、権限セットや権限セットグループを活用することで、FLSの管理を簡素化し、セキュリティを最適化できます。

公式リソース：

📖 公式ドキュメント：Field-Level Security（項目レベルセキュリティ）
📖 公式ドキュメント：項目レベルセキュリティに関する考慮事項
📖 公式ドキュメント：Metadata API Developer Guide: Profile
🎓 Trailhead モジュール：Data Security (データセキュリティ) - 特に「Control Access to Fields」セクション

にゃんこのSalesforce日記

このブログを検索