公平性

公平性

Salesforce アーキテクチャでは、公平性とは、アクセス可能なインターフェース、バイアスの検出と緩和、透明性の高い意思決定、倫理的なガバナンスを通じて、ユーザーに平等なサービスを提供するソリューションを構築することを意味します。Einsteinの予測は、顧客と従業員に影響する結果に影響します。つまり、アーキテクトは、デモグラフィック グループ全体で公平な結果を生成すると同時に、障害のあるユーザーが引き続きアクセスできるシステムを設計する必要があります。

Salesforce は、公平性のために特別に設計されたプラットフォーム機能を提供しており、WCAG 2.2 AA に準拠するよう努めています。Salesforce Lightning Design System (SLDS) を正しく使用すると、この目標をサポートするように設計されたコンポーネントが提供されます。各コンポーネントを詳しく見てみましょう。

  • Shield Platform Encryptionはデモグラフィック データなどの機密属性を保護し、イベント監視は透過的なデータ処理をサポートする監査履歴を提供します。
  • Einstein Trust Layer(ETL)は、監視とコンプライアンスの目的で生成AIプロンプトと応答の安全な監査履歴を取得します。
  • Experience Cloud にはアクセシビリティコントロールが含まれています。
  • 項目監査履歴では、項目レベルのデータ変更履歴を長期間保持できます。これにより、AI 判断データが追跡項目に保存されるときのアルゴリズムによる説明責任がサポートされます。

これらの機能は、Salesforce の公正性プラクティスの運用コストを削減するのに役立ちます。

Salesforce では、公正さは 3 つのディメンションにまたがって機能し、ソリューションを提供します。包括的な設計により、シームレスなキーボード ナビゲーション、スクリーン リーダーの互換性、コグニティブ デザインへの対応など、LWC(Lightning Webコンポーネント)、Visualforceページ、Experience Cloudサイトに完全にアクセスできるようになります。AIの公平性プラクティスは、バイアス検出、多様なトレーニング データ、継続的な監視を使用して、Einstein予測を公平な結果に導きます。ガバナンスは、モデルの進化と使用事例の拡大に合わせて公正性を維持するためのプロセスと制御を提供します。

公平性を怠ると、リスクがますます高まります。アクセスできない Experience Cloud サイトでは、組織が ADA (Americans with Disabilities Act) 訴訟や、連邦機関とそのコントラクターのセクション 508 コンプライアンス違反にさらされる可能性があります。システムのリスク分類と新しいアルゴリズムの説明責任に関する法律によっては、Einstein予測のバイアスがEU AI法の要件に違反する可能性があります。意思決定ロジックに関する有意義な情報が欠落している法的または同様の重大な影響を持つ完全に自動化されたAI主導の意思決定は、GDPR第22条および第15条(1)の情報の権利に違反する可能性があります。

公平性を考慮して設計する組織は、システムの影響を受ける顧客、従業員、コミュニティに対する予見可能な被害を軽減する傾向にあります。公平性の欠如は、経済的損害、機会の拒否、精神的苦痛、制度的差別の強化など、影響を受ける個人に具体的で重大な損害を与える可能性があります。規制の調整は、影響を受ける個人に適切に対応することから続く傾向にあります。

次の原則を使用して、プラットフォームを公平にするためのアーキテクチャ上の意思決定を導きます。

  • **Lightning アクセシビリティパターンの設計。**を構築するときは、可能な限り Lightning Design System と、WCAG 2.2 AA アクセシビリティをサポートするように設計された標準 Lightning Web コンポーネントを使用します。SLDS を使用して構築する場合、アクセシビリティを設計のコア原則とするライブラリを活用します。SLDSコンポーネントは、キーボードのアクセシビリティと支援技術との互換性が検証されており、多くのコンポーネントには開発者向けのヒントを含むアクセシビリティセクションが含まれています。カスタムコンポーネントが必要な場合、明示的な Accessible Rich Internet Applications (WAI-ARIA) 実装、セマンティック HTML、およびキーボードナビゲーションパターンを支援技術テストで検証する必要があります。
  • **各モデル種別に適したツールを使用して、バイアスを軽減および監視します。**リリース前および本番で継続的に、デモグラフィックグループ全体で公平な結果を得るために AI 出力を検証します。予測モデルの場合は、Einstein Discoveryとカスタム インスツルメンテーションを使用して決定データを取得し、CRM Analyticsで分析して公正性評価指標を測定します。生成AIとAgentforceの機能の場合は、ETL(Einstein Trust Layer)のプロンプトと応答の監査履歴を使用します。規制の透明性要件を満たすための決定を文書化します。
  • **Shield Platform Encryptionを活用してデータ保護を制御できます。**Shield Platform Encryptionは、個人データを保護しながら完全一致クエリを必要とする機密属性に対して確定的スキームで使用します。イベント監視ログを外部のセキュリティ情報およびイベント管理 (SIEM) システムに転送して、改ざんが明らかな監査履歴をサポートします。SIEM で、必要な規制に対して Salesforce ネイティブの保持期間を超えるライトワンスストレージとアクセスの分離を適用する場合です。
  • **リスクの高い予測のレビューワークフローを設計します。**Salesforceフローの承認プロセスとレビュー メカニズムを設定して、最終的な意思決定に影響するEinstein予測が適切な手動レビューを受けられるようにします。信頼性しきい値とビジネスルールを使用して、アクションを実行する前に予測の検証が必要なタイミングを決定します。
  • **差別のない組織全体のデフォルト (OWD) と項目レベルセキュリティ (FLS) を適用します。**OWD と FLS を使用してデータアクセスパターンを作成し、デフォルトでアクセスを制限し、共有ルールを使用して各ロールに必要な追加アクセス権のみを付与します。プロファイルに過剰なアクセス権を付与すると、機密属性が公開され、差別的な意思決定が可能になる可能性があります。
  • **プラットフォームの同意を介してユーザーエージェンシーを有効にします。**項目監査履歴で Data 360 の同意管理機能またはカスタム同意オブジェクトを使用して、使用事例ごとの詳細な AI 同意を追跡します。ユーザーが AI 駆動機能を除外し、人間による代替手段を提供できるようにします (可能な場合)。

データアーキテクチャの決定によって、Salesforce システムに表示される母集団と非表示の母集団が決まります。データ品質の低下は技術的な問題だけではありません。データギャップが特定のデモグラフィックグループに組織的に不利な場合、公平性の問題になります。

  • **データの可用性に関する必須項目を確認します。**必須項目で、デモグラフィックごとに異なる情報の可用性が想定されている場合、データの完全性が差別的になります。不完全なレコードを却下するシステムでは、必要な情報を提供できないユーザーは表示されません。
    • メールアドレスを必須にすると、信頼できるインターネットアクセスや個人のメールアドレスがないユーザーは除外されます。
    • 米国の社会保障番号 (SSN) を要求すると、SSN がまだ発行されていない海外の顧客と最近の移民は除外されます。
    • 町名・番地の必須化では、ホームレス人口と従来の住所以外のユーザーは除外されます。
  • **必須項目のビジネス上の正当性を監査します。**すべての必須項目で、省略可能ではなく必須である理由を文書化することが重要です。代替アプローチでプロセスが特定のデータなしで機能できる場合、それらの項目を省略可能にして、欠損値を適切に処理するシステムを設計します。これにより、そのようなデータを提供できないユーザーが除外されないようにできます。

欧米の命名規則 ([名]、[姓]) に従う名前項目では、命名方法が異なるカルチャーを除外できます。

多くの文化では次のものが使用されます。

  • 姓のない単一名 (または単義語)
  • 「姓」が世代によって変化する慣用姓
  • 複数の指定名または姓
  • ライフイベントや社会的状況に基づいて変化する名前
  • 「名」と「姓」が文化的に無意味な区別である名前

1 つの氏名項目を使用するか、一般的な命名規則に対応する柔軟な複数部分構造を使用して、名前アーキテクチャを設計します。名前の順序、継承パターン、文化的な規範に関する仮定は避けてください。

多様な国際名を使用して名前のアーキテクチャをテストし、名前項目で次の項目が受け入れられることを確認します。

  • 1 語の名前 (例: Sukarno、Cher、Teller)
  • 一般的な項目の長さ制限を超えるロングネーム
  • 発音符号、アポストロフィー、ハイフン、スペースを含む名前
  • 非ラテン文字 (アラビア文字、中国語、キリル文字、デーヴァナーガリー文字など) を使用した名前

名前検証でユーザーの正当な名前が却下されると、文化的なアイデンティティに基づいてシステムが却下されます。

住所検証サービスは多くの場合、米国および西ヨーロッパの形式に合わせて最適化されており、次の項目が認識されないことがよくあります。

  • 項目の順序が異なる国際住所形式
  • 町名のない田舎の住所
  • 軍の住所 (APO や FPO など)
  • 私書箱と代替配送場所
  • 固有の住所システムを持つ部族の土地
  • 住所コンポーネントの非ラテン文字が使用されている国

住所検証で従来の住所形式以外の住所形式が却下されると、住所が検証データベースの期待と一致しないユーザーの取引先の作成、配送、サービス提供が妨げられます。

アクセシビリティを念頭に置いて住所検証を設計する方法をいくつか紹介します。

  • 許可住所検証を実装します。
  • 構造化された検証に失敗した場合は、自由形式の住所入力を受け入れます。
  • 無効な修正をユーザーに強制するのではなく、ユーザーが入力した住所を保存します。
  • 住所の検証は、住所の形式の検証ではなく、データ強化と重複の検出に使用します。

データキャプチャを事前にブロックする代わりに、住所の精度が業務上重要な履行プロセスに住所検証を組み込みます。

特定のコミュニケーションチャネルのユニバーサルアクセスの前提条件では、異なるテクノロジーアクセスまたは設定を持つ母集団は除外されます。

メールのみのコミュニケーションには次のものは含まれません。

  • 信頼できるインターネットアクセスがないユーザー
  • メールの使用に抵抗がある高齢者
  • SMS またはメッセージングアプリケーションが主要なコミュニケーション方法である地域のユーザー

電話のみのコミュニケーションには次のものは含まれません。

  • 耳が聞こえないユーザー
  • 電話にアクセスできないユーザーまたは共有電話を使用しているユーザー

ユーザーがチャネル設定を制御できるオムニチャネルコミュニケーションアーキテクチャを設計します。希望するコミュニケーション方法を取引先責任者レコードに保存し、すべてのアウトバウンドコミュニケーションシステムで一貫して設定を尊重します。シングルチャネル方法が普遍的に機能することを仮定するのではなく、さまざまなコミュニケーションの代替手段を提供します。

公平性の監視のためにデモグラフィックデータを収集するには、誤用を防ぐために慎重なアーキテクチャが必要です。

デモグラフィック データの収集と処理は管轄区域に依存し、法的に制限されています(EUでは、GDPR第9条で特定の法的根拠を必要とする特殊なカテゴリ データとして処理され、米国ではバイアス モニタリングは通常、自主的なEEO自己識別に依存します)。法的根拠が存在する場合、組織はデモグラフィックデータを使用して次のことを行います。

  • 保護されたグループで階層化された公平性評価指標を監視する
  • 自動化と AI システムのバイアスの検出
  • 差別防止要件への規制コンプライアンスの実証

デモグラフィックデータを収集すると、次のようなリスクが発生します。

  • アクセス制御に失敗した場合、差別的な目的でデータが使用される可能性がある
  • ユーザーが収集方法を信用せず、不正確なデータを提供する可能性がある
  • 収集は侵略的または差別的と感じる可能性がある

次のような情報を使用して、自発的な自己識別を設計し、デモグラフィックデータ収集を設計します。

  • 明確な目的 (公正性の監視やコンプライアンス報告など) で明確に説明
  • 任意であり、常に使用できる [回答しない] オプションが含まれる
  • 厳格なFLSで運用データから分離し、不正アクセスを防止
  • レポートと分析のために集計され、個々の意思決定にはリンクされない
  • Shield Event Monitoring によるアクセスパターン監査の監視

デモグラフィックデータがどのように使用され、どのように使用されないかをプライバシーポリシーで文書化することが重要です。開示されていないデータの使用によってUser Trustに違反すると、信頼性が大幅に低下し、復旧が困難になる可能性があります。

Salesforce レコードにデモグラフィックデータ、企業統計データ、または行動データを追加するサードパーティのデータ強化では、次の点でバイアスが発生する可能性があります。

  • ステレオタイプに基づく不正確な推測
  • 人口統計に関連するギャップがある不完全なカバー率
  • 不明な公正性プロパティを使用する独自のアルゴリズム
  • バイアスのかかった履歴レコードから取得されるデータ

データ強化サービスを実装する前に、次の監査を行うことが重要です。

  • ベンダーの公正性テストとバイアス緩和方法
  • デモグラフィックグループ全体のデータカバー率と精度
  • 予測の作成に使用される推測方法と特徴
  • 契約上のデータ使用制限と保持ポリシー

サードパーティデータが Salesforce 組織に入力されると、意思決定に影響し、ベンダー導入バイアスが発生して組織のバイアスとしても反映される可能性があります。

Salesforce コンテキストでは、アクセシビリティとは、障害のあるユーザー向けに機能する Lightning Web コンポーネント、Visualforce ページ、および Experience Cloud サイトを構築することを指します。標準 Lightning コンポーネントは、適切に使用すればベースライン アクセシビリティを提供しますが、カスタム開発および Experience Cloud 設定では、明示的なアクセシビリティの実装が必要です。

Lightning Design System コンポーネントは、WCAG 2.2 AA への準拠を設計どおりに使用するように設計されています。Salesforce は完全準拠に努めていますが、認定はしていません。SLDS パターンから逸脱したり、アクセシビリティを考慮しないでカスタムコンポーネントを構築したりすると、障害のあるユーザーにとって障壁になります。

標準の Lightning Web コンポーネントには、組み込みのアクセシビリティが用意されています。Lightning-input、Lightning-combobox、Lightning-datatable、Lightning-cardなどのコンポーネントには、適切なARIA属性、表示ラベルの関連づけ、キーボード・ナビゲーション、フォーカス管理が自動的に含まれます。可能な場合は、外観は似ているが適切なアクセシビリティインフラストラクチャが欠けている可能性があるカスタムの代替コンポーネントを作成するのではなく、標準コンポーネントを使用します。

  • **カスタム Lightning Web コンポーネントでセマンティック HTML を使用します。**カスタムコンポーネントを作成するときは、紛らわしいネストされた
    コンポーネントではなく、セマンティック HTML 要素 (
    、
  • **ARIA をカスタムコンポーネントに実装します。**セマンティック HTML でインターフェースの動作を説明できない場合、ARIA ランドマーク、ロール、プロパティを適用します。動的コンテンツ更新では、スクリーンリーダーへの変更を発表する aria-live リージョンが必要です。カスタムインタラクティブコンポーネントには、その動作に一致する明示的なロール定義が必要です。Lightning ベース コンポーネントでは ARIA が自動的に処理されますが、カスタム コンポーネントでは、スクリーン リーダーでのテストによる手動の ARIA 検証が必要です。
  • 支援技術でテスト:実際のスクリーン リーダーを使用してLightningコンポーネントを検証します(Windowsの場合はJAWSとNVDA、macOSとiOSの場合はVoiceOver、Androidの場合はTalkBackなど)。Deque の大規模な調査によれば、Axel-core などの自動化ツールはアクセシビリティの問題の約 57% を量で把握しています。残りの問題は、スクリーンリーダーのナビゲーションパターンを理解しているユーザーによる支援技術を使用した手動テストが必要です。
  • **Lightning フローでフォーカス管理を使用します。**モーダルを開いたり、動的コンテンツを読み込んだり、ユーザーが複数ステップのフローを完了したりする場合、プログラムでフォーカスを管理してキーボードユーザーを新しいコンテンツに誘導する必要があります。Lightningモーダルおよびポップ・オーバー・コンポーネントは基本的なフォーカス管理を提供しますが、コンテンツの変更に応じてフォーカスを適切に移動するには、複雑なフローに明示的なフォーカス・ロジックが必要です。

Experience Cloudサイトは、ADA、セクション508、欧州アクセシビリティ法の要件(管轄区域、利用者、組織種別によって異なる)を満たす必要があるアクセシビリティ設計を必要とする外部ユーザー(顧客、パートナー、一般利用者など)にサービスを提供します。

  • **アクセス可能なテンプレートを使用します。**LWR(Lightning Web Runtime)を使用して構築されたExperience Cloudテンプレートには、ベースライン アクセシビリティが含まれます。カスタマー取引先ポータルやヘルプセンターなどの標準テンプレートは、正しく設定されていれば WCAG 2.2 AA 基盤を提供します。カスタムテンプレートには、セマンティックマークアップ、キーボードナビゲーション、スクリーンリーダーの互換性など、明示的なアクセシビリティの実装が必要です。
  • **テーマ設定の WCAG 準拠を確認します。**カスタムテーマとブランド設定されたサイトでは、色のコントラストの検証が必要です。エクスペリエンスビルダーの [テーマ] 設定では、色、タイポグラフィ、間隔を制御します。すべてのテキストは、通常のテキストでは 4.5:1 のコントラスト (通常のテキストでは 18 pt 未満、太字では 14 pt 未満)、大きなテキスト (通常のテキストでは 18 pt 以上、太字では 14 pt 以上) および UI コンポーネントでは 3:1 を満たしていることを確認します。ブラウザー開発者ツールまたはオンラインコントラストチェッカーを使用して、コンプライアンスを検証します。ブラウザーを 200% にズームしてテストし、コンテンツや機能を損なうことなくテキストが拡大縮小されることを確認します。
  • **ナビゲーションメニューでキーボードナビゲーションを使用します。**Experience Cloud ナビゲーションコンポーネントでは、マウスに依存しないキーボードのみの操作がサポートされている必要があります。ユーザーは、フォーカストラップを使用せずに、Tab、Enter、Esc、矢印キーを使用してドロップダウンメニュー、メガメニュー、およびフライアウトナビゲーションに移動したり、そこから移動したりする必要があります。キーボードのみを使用してすべてのナビゲーションパスをテストし、アクセシビリティを検証します。
  • **Experience Cloud でフォームアクセシビリティを有効にします。**適切な表示ラベル要素または aria-labelledby を使用して、表示ラベルをすべてのフォーム入力に明示的に関連付けます。プレースホルダーテキストは、単独ではアクセシビリティ要件を満たしません。これは、テキストがデータ入力の開始直後に表示され、スクリーンリーダーユーザーに十分な永続的なコンテキストが残らないためです。Lightning 入力コンポーネントでは、必要な表示ラベル属性を使用して設定する場合、組み込みの表示ラベルの関連付けが提供されます。カスタム Visualforce フォームでは、表示ラベルと入力の明示的な関連付けが必要です。
  • **支援技術を使用して Experience Cloud サイトをテストします。**公開 Experience Cloud サイトを起動する前に、スクリーンリーダー、キーボードのみのナビゲーション、ブラウザーズームを使用して包括的なアクセシビリティテストを実施する必要があります。ユーザビリティテストに障害者ユーザーを含めることは、専門家のレビューで見落としがちな実用的で実践的な障壁を明らかにするために重要です。外部 Experience Cloud のアクセシビリティを検証しずに内部 Lightning ページのみをテストした場合、公開サイトはアクセシビリティに関する苦情や訴訟に対して脆弱になります。
  • **画像とアイコンには代替テキストを使用します。**Experience Cloud のすべての有益な画像、アイコン、グラフィックコンテンツには代替テキストが必要です。装飾画像では、空の代替テキスト (alt="") が使用されるため、スクリーンリーダーでスキップできます。有益な画像では、コンテンツと機能を説明する意味のある代替テキストが提供されます。アイコンの代替テキストを記述する場合、アイコンの外観ではなくアクションや目的に焦点を絞ります (たとえば、虫眼鏡アイコンを「虫眼鏡」と説明するのではなく、代替テキストに「サイトを検索」など、その機能的な実用性を示す必要があります)。画像を管理する場合、CMS はコンテンツの著者に代替テキストを入力するか、画像を装飾として明示的にマーク (alt="" を設定) する必要があります。これにより、美的画像の代替テキストの欠落や強制的な説明を防止してアクセシビリティを確保できます。

完全なキーボードアクセシビリティとは、マウスやタッチ操作を必要とせずにキーボードを使用してすべての機能にアクセスできることを意味します。

  • **Lightning ページでの論理的なフォーカス順序の使用。**フォーカス順序がビジュアルレイアウトとインタラクションフローに従っていることを確認します。ユーザーが Tab キーを押すと、ビジュアルデザインに基づいてユーザーが期待する順序でビジュアルフォーカスがインタラクティブ要素間を移動します。Lightning アプリケーションビルダーとエクスペリエンスビルダーでは、コンポーネントの配置に基づいてフォーカス順序が確立されます。カスタムコンポーネントでは、論理的なフォーカスの進行を確保するために明示的なタブインデックス管理が必要です。
  • **コントラスト要件を満たすために、可視フォーカスインジケーターを使用します。**Lightning Design System には、ほとんどのコンポーネントの WCAG 要件を満たすためのフォーカススタイルが用意されています。カスタムコンポーネントでは、周囲のコンテンツに対する 3:1 のコントラスト要件を満たすために、強化されたフォーカスインジケーターが必要になる場合があります。弱視のユーザーがキーボードで操作できるようにするには、フォーカスインジケーターを明確に表示する必要があります。CSS を使用してフォーカスインジケータを削除しないでください (アウトライン: なし)。代わりに可視フォーカスのスタイルを指定します。
  • **モーダルおよびオーバーレイでキーボードトラップの軽減を使用します。**モーダルダイアログは、開いている間、モーダル内でフォーカスをトラップする必要があります。これにより、キーボードユーザーが非表示の背景コンテンツにアクセスできなくなります。モーダルクローズ時にフォーカストラップが解除され、フォーカスがトリガー要素に返されます。埋め込みコンテンツ (iframe やサードパーティウィジェットを含む) では、エスケープメカニズムなしでキーボードフォーカスを完全に取得することはできません。
  • **ショートカットキーは競合せずに使用します。**Lightning には、Salesforce ヘルプに記載されている標準のキーボードショートカットが用意されています。カスタムキーボードショートカットは、標準のブラウザーコントロールやスクリーンリーダーのナビゲーションコマンドとの競合を回避するために設計する必要があります。WCAG の成功基準に従って、1 文字のショートカット (1 文字や句読点を押した場合など) でグローバルアクションをトリガーすることはできません。特定のコンポーネントにフォーカスがある場合に有効化を制限するか、ショートカットを完全に無効化または再マッピングする方法をユーザーに提供する必要があります。

アクセシビリティ検証を CI/CD パイプラインに組み込んで、アクセシビリティを定期的な手動監査として扱うのではなく、すべてのリリースで構造的な問題を自動的に検出します。

  • **Lightning Web コンポーネントのアクセシビリティテストには sa11y を使用します。**Salesforce の sa11y ライブラリ (@sa11y/jest パッケージ) は、AXE コアアクセシビリティエンジンをラップして、Jest 単体テスト用の toBeAccessible() マッチャーを追加します。単体テストの一環として、ARIA の適切な使用方法、表示ラベルの関連付け、コントラスト比、セマンティックマークアップを検証するアクセシビリティテストを自動的に作成します。アクセシビリティの重大な問題が検出されたときにビルドが失敗するように設定します。
  • **Experience Cloud で Lighthouse CI を使用します。**Google Lighthouse は、Experience Cloud サイトを含む Web ページのアクセシビリティを監査します。Lighthouse CI をリリースパイプラインに統合し、公開ページをスキャンしてアクセシビリティの問題を見つけます。リリース承認前に最小アクセシビリティスコアを要求するようにスコアしきい値を設定します。
  • **Salesforce DX MCPパッケージから入手できるアクセシビリティエージェントを使用します。**MCP互換の環境またはAgentforce Vibes内では、WCAG標準に対してコードを確認し、対象を絞った修正を明らかにし、エンジニアがレビュー、検証、マージを行うための取り込み要求を生成できます。

バイアスは、AI が導入されるずっと前から Salesforce の確定的自動化に存在します。割り当てルール、フローの決定、入力規則、テリトリー設計では、差別を永続させる可能性のある人間の判断がエンコードされます。アーキテクトが幅広く精査する AI バイアスとは異なり、自動化バイアスは多くの場合、確定的ロジックが客観的に感じられるため、未検証のまま通過します。

  • **リードとケースの割り当てルールに従います。**営業チームとサービスチームに作業を分散します。割り当てロジックで保護された特性と相関する条件が使用されている場合、自動化によってサービス品質と商談アクセスに体系的な格差が生じます。
  • テリトリー、郵便番号、または取引先の特性を使用する割り当てルールでは、価値の高い商談が特定のチームに偏って転送され、価値の低い作業が別の場所に転送される可能性があります。テリトリー境界が、テリトリーごとに異なる顧客の人口統計や報酬構造と相関している場合、割り当ての自動化によって経済的な差別が生じます。
  • **割り当てルールの結果を定期的に監査します。**顧客の人口統計で階層化されたテリトリーとチーム間の割り当て分布を計算します。エンタープライズ取引先が特定のテリトリーに集中し、SMB 取引先が他のテリトリーに分散している場合、エンタープライズテリトリーの報酬やリソースが適切であれば、割り当てルールによって公平性審査を必要とする公平な結果が得られない可能性があります。
  • **オムニチャネルのスキルベースのルーティングを確認します。**これは、顧客母集団全体のサービス品質に影響する可能性があります。ルーティングロジックで特定のスキルが顧客の価値や問題の複雑さと相関することを暗黙的に想定している場合、顧客はデモグラフィックプロキシに基づいて異なるサービス結果を受け取る可能性があります。

ルーティングパス全体の平均処理時間、初回連絡時の解決、顧客満足度を監視することが重要です。不均衡は、特定の顧客セグメントが経験の浅いエージェントを組織的に受け入れているか、ルーティングオプションが少ないかを示します。

  • **Salesforce フローの自動化を確認します。**承認の決定、対象資格の判断、またはアクセス権の付与を行うと、一見無害なビジネスルールによって差別ロジックがエンコードされる場合があります。条件が保護された特性と相関している場合、特定のフローによって間接的な差別が発生します。
  • **公平性を考慮してフローの決定を確認します。**ユーザーに影響する最終的な意思決定を行うフローごとに、次の点を確認することが重要です。
  • 一般的な顧客プロファイルに適合しないユーザーはどうなりますか?
  • 決定条件はデモグラフィック特性と相関しますか?
  • 例外とエッジケースは公平に処理されますか? または、特定のグループに組織的に不利益を与えますか?

フローの決定ロジックと公平性に関する考慮事項をアーキテクチャの決定レコードに文書化し、リスクの高いフローを AI システムと同じ倫理審査ポリシーの対象にすることが重要です。

  • **入力規則を確認します。**データ入力を防止すると、情報がシステムの前提条件と一致しないユーザーから有効なデータが除外される場合があります。正当なデータを拒否する入力規則では、目に見えない母集団が作成されます。データが入力規則パターンに適合しないユーザーは、特定のシステムとエンゲージできません。多くの場合、ユーザーは技術的なエラーを報告するのではなく要求を破棄するため、検証の失敗は報告されません。一般的な検証バイアスパターンを次に示します。
  • ラテン文字が必要な名前検証では、発音符号を含む名前とラテン文字以外のスクリプトが除外される場合があります。
  • 電話番号検証では、多くの場合、国際電話番号と代替通信方法を除外した米国/欧米の形式が使用されます。
  • 住所検証では、非標準住所 (私書箱、田舎道、部族の土地、国際形式など) を認識できません。
  • 個人のメールアドレスを必要とするメール検証では、個人のメールアクセス権がないユーザーに不利益が生じる可能性があります。
  • **多様なデータを使用して入力規則をテストします。**検証テストには、国際住所、欧米以外の名前、代替電話形式を含めます。検証で正当なデータが拒否された場合、有効なユーザーが除外されないように検証ロジックを拡張する必要があります。
  • **販売テリトリー設計を確認します。**顧客セグメンテーション戦略と販売テリトリー設計によって、顧客母集団全体のリソース割り当てが決まります。テリトリー境界またはセグメンテーション条件が、リソースの割り当てが不平等になる人口統計と相関している場合、その割り当てによって差別的な結果が生成される可能性があります。地理的境界を使用するテリトリー設計は、居住の分離パターンにより、人種、民族、経済の人口統計と相関することがよくあります。テリトリー間で報酬、スタッフレベル、リソース投資が異なる場合、地域が差別的なリソース割り当てのメカニズムになる可能性があります。
  • **設計を確定する前にテリトリーの人口統計を分析します。**提案されたテリトリー境界全体で顧客人口統計をマッピングします。人口統計学的に集中するようになったら、人口統計学的構成に関係なく、すべてのテリトリーでリソース割り当てが均等であるかどうかを評価します。ビジネスの正当性のためにテリトリー間で異なるリソースレベル (市場の成熟度、競争力、成長の可能性など) が必要な場合、その正当性を明示的に文書化し、その結果を監視して、不十分なテリトリーに十分な投資機会を提供して格差の定着を防ぎます。
  • **自動化ロジックの透明性を維持します。**ビジネスルール、割り当て条件、フロー決定ロジックを Salesforce Knowledge またはアーキテクチャ決定レコードに文書化します。透過的な自動化により、非表示のロジックによって回避される方法で公平性を確認できます。
  • **結果を定期的に監査する。**四半期ごとの監査をスケジュールして、顧客の人口統計によって階層化される可能性のある自動化の結果を分析します。格差は調査と改善の可能性をトリガーします。
  • 以下を追跡することが重要です。
  • チームおよびテリトリー間の割り当ての分布
  • 対象資格を決定するフローの承認率
  • データパターン別の入力規則却下率
  • テリトリーパフォーマンスとリソース割り当て
  • **倫理的な観点で重要度の高い自動化を確認します。**AI システムと同じ倫理審査プロセスでの雇用、クレジット、サービスアクセス、またはその他の結果に影響する件名フローと割り当てルール。自動化バイアスには、アルゴリズムバイアスと同じレベルの精査が必要です。

Salesforceでは、AIの公平性では、Einsteinを使用して、予測がすべてのデモグラフィック グループで公平な結果をもたらすことを確認することに重点を置いています。Einstein Discoveryとカスタム計測では、バイアス検出を可能にする予測モデルの決定データが取得されます。CRM Analytics ダッシュボードは公正性評価指標を追跡します。項目監査履歴とイベント監視では、アルゴリズムによる説明責任のために決定データが取得されます。

最終的な意思決定に影響するEinstein予測(リード スコアリング、商談予測、顧客セグメンテーションなど)では、必須の同等のステップとして機能する(セキュリティ レビューと同様の)リリース前の公平性評価が必要です。

統計手法を使用して、すべての予測モデルの特徴を分析し、保護された特性との相関関係を確認します。プロキシ機能を削除または変換するには、プロキシ効果にもかかわらず、その予測値が包含を妥当なものかどうかを評価します。

  • **トレーニングの前に Salesforce CRM データを監査します。**Salesforce 組織には、過去の慣習に基づく何十年もにわたる人間の意思決定が含まれています。過去のセールス チームが特定のデモグラフィックに優先度を付けている場合、Einsteinリード スコアリングはそれらのパターンを学習して永続化します。履歴データに関する予測モデルのトレーニングを行う前に、そのデータを監査して、顧客セグメント全体のデモグラフィック表現のギャップやメジャメントの不一致がないかどうかを確認することが重要です。
  • **デモグラフィックグループ全体の公平性評価指標を計算します。**予測モデルをリリースする前に、必要な人口統計データを収集および処理するための法的根拠がある場合、保護対象グループ全体の人口統計学的同等性、均等な機会、異種影響率を計算することが重要です。Einsteinリード スコアリングでセグメントAに50%の確率で高スコアが割り当てられ、セグメントBに30%の確率で高スコアが割り当てられている場合、60%の比率は5分の4ルール(80%)に違反し、調査と軽減が必要になります。80% という数字はスクリーニングトリガーであり、法的な合否ラインではありません。5 分の 4 ルールは雇用選択に関する米国連邦の経験則であり、これをクリアすることは安全港ではありません。統計的に有意な格差がある場合、より高い比率で精査される可能性があります。また、他の制度では悪影響の測定方法が異なります (たとえば、EU の間接差別法では、慣行が「特定の不利益」を生み出すかどうかが判断され、一定のしきい値はありません)。業務を行う管轄区域と使用事例に合わせて調査しきい値を調整します。
  • **バイアス検出用の予測モデル決定データをキャプチャします。**リード スコアリングや商談スコアリングなどの予測モデルのバイアスを検出するには、Einstein Discoveryとカスタム計測を使用して決定データを取得します。つまり、予測の入力、出力、モデル バージョンを追跡対象項目に保存し、項目監査履歴を有効にします。CRM Analytics でそのデータを分析し、デモグラフィックグループ全体の決定パターンを経時的に追跡し、デモグラフィックの同等性または商談の同等性の指標が許容しきい値を超えた場合にアラートを表示するダッシュボードを作成します。
  • **予測モデルでプロキシ機能を検出します。**保護された特性と相関する特性により、保護された特性がモデルから除外されている場合でも間接的な差別が可能になります。
    • Salesforce データには通常、次のプロキシ機能が含まれます。
  • テリトリーまたは郵便番号 (人種、民族、収入のプロキシ)
  • 取引先名のパターン (組織の規模と業種の統計のプロキシ)
  • コミュニケーション活動のタイミング (タイムゾーン、宗教、介護責任のプロキシ)
  • 活動データのデバイス種別またはブラウザー (収入レベルのプロキシ)

Einstein予測でバイアスが検出された場合、(根本原因と技術的な制約に基づいて)適切なパイプライン フェーズで軽減を適用する必要があります。

  • **モデルのトレーニングの前にデータのバランスを取ります。**予測モデルのトレーニングを行う前に、過小評価されている顧客セグメントのオーバーサンプリングまたは過小評価されているセグメントのアンダーサンプリングを使用して、Salesforce CRM データを再バランシングします。Data 360 を使用して複数の組織のデータを集計し、多様なトレーニングセットを確保します。合成データ生成では、差分プライバシー技術を使用してプライバシーを維持しながら、スパースセグメントを補完できます。
  • **機能エンジニアリングでプロキシを削除します。**プロキシ機能が識別されたら、デモグラフィックの相関関係のない予測機能を提供する代替機能に置き換えます。テリトリーがデモグラフィックプロキシとして機能する場合、代替として業種分類または会社規模を考慮します。取引先名のパターンが人口統計と相関している場合は、代わりに会社統計属性を使用します。
  • **後処理中にしきい値を調整します。**デモグラフィックセグメントごとに決定しきい値を調整して、トレーニングモデル後の結果率を均等にします。雇用関連の決定については、これを全面的に禁止します。Title VII(1991年公民権法)では、保護対象階層ごとにスコアを調整したり、異なるカットオフスコアを使用したりしており、文書化されている正当性によって慣行が合法化されているわけではありません。禁止されていない場合、予測によって自動決定が通知されたときに、差別化処理のビジネス上の理由でしきい値の調整を文書化します。
  • **更新されたデータを使用して、モデルを定期的に再トレーニングします。**モデルの再トレーニングを四半期ごとにスケジュールします (または、重大なデータ配信シフトが発生したとき)。新しいデータで再トレーニングを行うと、新しいバイアスパターンが捕捉され、元の公正性ベースラインからのドリフトが修正されます。本番リリース前にすべてのモデルバージョンの公正性評価指標を再検証し、再トレーニングによって新しいバイアスが発生していないことを確認します。

Einstein Trust Layerは、生成AIとAgentforce機能のプロンプト、応答、Trustシグナルをキャプチャし、生成AIの透明性と規制コンプライアンスをサポートします。予測モデルの場合、透明性と意思決定系統はEinstein Discoveryとモデル マネージャーから取得されます。これらのモデルでは、監査データを保持するためにカスタム計測が必要です。

導入後に不透明なシステムに説明を改良するのではなく、初期アーキテクチャからEinsteinソリューションに説明可能性を構築します。

  • **決定ポイントで Einstein Discovery の説明を表示します。**Einstein Discoveryでは、方向性の影響を受ける特定の予測に最も影響した変数を示す予測要素の説明が提供されます。個別のCRM Analyticsダッシュボードへのナビゲーションを要求するのではなく、決定時点でユーザーにこれらの説明を表示するLightningコンポーネントを設計します。意思決定がユーザーに影響する場合、抽象的なモデルパフォーマンス評価指標ではなく、透明性が必要です。
  • **さまざまな利用者向けの階層的な説明。**各利用者に適した説明の深さを入力します。
  • ビジネスユーザー: 「年間売上が 100 万ドルを超え、エンゲージメントスコアが上位 10% に入っているため、このリードは高スコアを獲得しました。」
  • **テクニカル ユーザー:**機能の加重、トレーニング データの特性、検証指標が記載されたEinstein Discoveryモデル カードを提供します。
  • 顧客: 「このおすすめは、最近の購入内容と同様の設定を持つ顧客に基づいています。」
  • 監査人: Einstein Discoveryとモデル マネージャーから取得した決定系統(モデルのバージョン、入力値、予測を促進した要素)をカスタム計測で提供します。
  • **信頼性を適切に伝える。**予測の信頼性をユーザーに適した言葉で表示し、ユーザーが誤って解釈する可能性のある未加工の確率スコアを回避します。「73% の信頼性」を表示する代わりに、カテゴリ (「High Confidence (高信頼性)」、「Moderate Confidence (中程度の信頼性)」、「Needs Review (要レビュー)」など) を使用して、意思決定の信頼性に対する各信頼性レベルの意味や、追加のレビューについての説明と共に伝えます。

ユーザーに影響するすべての AI 主導の意思決定の説明責任、デバッグ、規制へのコンプライアンスをサポートする、包括的で不変の監査履歴を維持します。

  • **適切なツールを使用して予測監査データを取得します。**項目監査履歴を有効にして、予測モデルの監査データ (予測の入力、出力、モデルバージョン) を追跡項目に保存します。業界や管轄区域によって異なる規制要件を満たすようにデータ保持ポリシーを作成します。
    • 金融サービス ルールでは、規制ごとに保存期間を設定します（たとえば、FINRAルール4511（b）では、FINRAルールまたはSEAルール17a-4で保存期間が指定されていないレコードに対してデフォルトの6年間の保存期間を設定します）。
    • また、医療記録の保持も、無期限保持を包括的に規定するのではなく、特定のルール(HIPAAではコンプライアンス ドキュメントに6年以上を義務付け、医療記録の保持は個々の州法で設定)によって管理されます。
  • **CRM Analytics を使用して予測モデルの決定データを分析します。**取得した予測モデル決定データ (追跡項目の予測入力、予測出力、モデルバージョン) に基づいて CRM Analytics ダッシュボードを作成し、経時的な決定パターン、公正性評価指標、モデルパフォーマンスを分析します。信頼性レベル、人口統計区分、結果種別別に予測分布を表示するレンズを作成します。追加の調査が必要な異常パターンを特定する Einstein Discovery ストーリーを設定します。
  • **長期保存には、項目監査履歴を使用します。**標準項目履歴では、UI で 18 か月間、API で最大 24 か月間の変更を追跡します。項目監査履歴では、AI 決定データを保存するカスタムオブジェクトの項目履歴を無期限に保持できます。デフォルトでは、最大 18 か月後に履歴がアーカイブされ、アーカイブデータは削除されるまで保持されます。同意レコードが含まれるオブジェクトで項目監査履歴を有効にし、決定を上書きして、規制保持要件を満たすようにレポートをバイアスします。
  • **Agentforce インタラクションにはイベント監視を使用します。**イベント監視では、アクションやフローの実行時など、Agentforce の呼び出しレベルのイベントが取得されます。Salesforce ネイティブ保持期間を超えるストレージ用に、イベントモニタリングデータを外部 SIEM (API を介した標準イベントログファイルデータと、プラットフォームイベントを介したイベントのリアルタイムイベントモニタリングサブセット) にエクスポートします。改ざんの証拠は、ライトワンスストレージとアクセスの分離を適用する特定の SIEM の動作によって異なります。大量の Agentforce インタラクションにまたがるバイアス パターンを検出するように SIEM クエリを設定します。
  • **Einstein Trust Layer との Agentforce の会話を監査します。**Einstein Trust Layerは、Data 360に保存されているAgentforceの会話プロンプトと応答の監査履歴を取得し、トランスクリプト・レベルの記録を提供して透明性と規制コンプライアンスを実現します。

複数の管轄区域の現在の AI 規制と新しい AI 規制に準拠するために位置付けられているアーキテクトの透明性機能を詳しく見てみましょう。

  • EU AI法の透明性要件。EU AI法に基づく高リスクのAIシステムには、透明性ドキュメント、技術ドキュメント、人の監視機能、正確性/公正性評価指標が必要です。Einstein Trust Layer監査証跡とEinstein Discoveryモデル・カードは、これらの要件の基盤となります。モデルトレーニングデータのデモグラフィック、検証方法、アーキテクチャ決定レコードの既知の制限事項を文書化します。
  • **GDPRの説明を受ける権利。**GDPR では、決定が自動化された処理のみに基づいており、法的または同等の効果をもたらす場合、EU のデータ主体は決定のロジックに関する有益な情報を受け取る権利が与えられます。この権利は、リサイタル71で読み上げられた第15条(1)(h)と第22条(3)に由来し、CJEUによってDun & Bradstreet(2025)で明確にされました。15 ～ 45 日の間で (管轄区域に応じて) 変化するデータ主体アクセス要求期間内の過去の決定に対して、必要に応じて一貫した説明を生成するシステムを設計します。取得した予測モデルの決定データ(予測の入力、出力、モデルのバージョン、Einstein Discoveryの説明要素)により、十分な保存期間で保存されている説明を再構築できます。
  • **アルゴリズムの説明責任の法則。**米国の州レベルのアルゴリズムによる説明責任に関する法律では、自動決定システムの影響評価と透明性レポートがますます要求されています。取得する予測モデル決定データと CRM Analytics 公正性監視ダッシュボードにより、これらのレポートのデータ基盤が提供されます。結果の AI を規制に関する問い合わせに事後的に対応するのではなく、プロアクティブなコンプライアンスとしてリリースする前にアルゴリズムによる影響評価を実施します。

OWD、共有ルール、項目レベルセキュリティ (FLS) によって、ユーザーが確認して判断に使用できる情報を決定するデータアクセスパターンが形成されます。適切に設定することで、機密属性への差別的なアクセスを防止しながら、サービスを公平に提供できます。

デフォルトでアクセスを制限するように OWD と項目レベルセキュリティを設計します。共有ルールでは、最小権限の原則 (PoLP) を使用して、各ロールが正当に必要な追加アクセス権のみを付与します。これにより、保護された特性に基づく差別的な意思決定が回避されます。

  • **制限付き OWD をデフォルトとして有効にします。**非公開 OWD は、機密の顧客データが含まれるオブジェクトに使用し、ロール階層と共有ルールでアクセス権を付与します。公開/参照・更新可能 OWD では、後からアクセスを制限すると、アクセスが中断されます。つまり、デフォルトを厳格化すると、共有の再適用が実行され、共有が完了した後にのみ有効になります。明示的な共有許可がある非公開 OWD では、差別のないコンプライアンスをサポートする監査可能なアクセスパターンが作成されます。
  • **機密属性に項目レベルセキュリティを適用します。**正当なビジネス目的でアクセスを必要としないユーザーから、保護された特性 (民族、宗教、障害状況など) を含む機密項目を非表示にします。ほとんどのプロファイルで機密項目の参照アクセス権を削除するように FLS を設定します。特定の目的 (ダイバーシティレポートや合理的な配慮など) でこれらの項目が必要な場合、ビジネス上の正当性が文書化された権限セットを使用して最小限のアクセス権を付与します。
  • **公平な結果を得るための割り当ておよび共有ルールを設計します。**割り当てルール、キュー、オムニチャネルルーティングを使用して、作業をテリトリー、チーム、サービスエージェントに均等に配分します。ビジネス上の正当性を文書化せずに、価値の高い商談や顧客を特定のユーザーグループに集中させる共有は手動で行わないでください。マネージャーの主観的な判断ではなく、客観的な条件 (業種、地域、商品ラインなど) に基づいて自動共有ルールを設定すると、バイアスが発生する可能性があります。
  • **一時的なアクセス用の権限セットを提供します。**プロファイルを変更するのではなく、権限セットを使用して機密データへの一時的なアクセス権を付与します。これはすべてのユーザーに永続的に影響します。ユーザーが特定のプロジェクトのデモグラフィックデータにアクセスする必要がある場合 (ダイバーシティ分析や宿泊要請など)、有効期限が文書化された権限セットを割り当てます。スケジュール済みフローでは、定義された期間後に権限セットを自動的に取り消すことができます。

Shield Event Monitoring とレポートを使用して、データ使用上の潜在的な差別やバイアスを示すデータアクセスパターンを検出します。

  • **Shield Event Monitoring を使用して、機密データへのアクセスを監査します。**イベント監視を使用して、保護された特性または機密属性が含まれるオブジェクトのオブジェクトレベルのアクセスイベント (レポートエクスポート、API クエリ、ページビュー) を取得します。これらのイベントに関するクエリを設定して、誰が、いつ、どのようなコンテキストでオブジェクトにアクセスしたかを明らかにし、異常なパターン (突然の急増や予期しないユーザーによるアクセスなど) を調査のトリガーとして扱います。
  • **共有ルールの配布に関するレポート。**レコードがユーザー、チーム、テリトリーにどのように分布しているかを分析するレポートを作成します。顧客人口統計別に分布統計を計算して、価値の高い取引先と商談が均等に配分されるようにします。ビジネス上の正当性を文書化することなく、特定のユーザーグループが貴重なレコードに偏ったアクセス権を持っている集中を特定します。
  • **CRUD および FLS 違反の監査。**OWD 設定、共有ルール、FLS 設定、権限セットへの変更については、「設定変更履歴」を参照してください。データアクセスコントロールを不正に変更すると、機密データに不適切にアクセスしようとする可能性があります。トランザクションセキュリティポリシーを使用して、リスクの高いリアルタイムイベント監視イベント (異常な API 活動、疑わしいログイン、機密データの大規模なレポートまたはリストビューのエクスポートなど) に対応します。トランザクションセキュリティは、レコードレベルの DML または FLS の変更ではなく、これらのランタイムイベントに対してのみ実行されるため、FLS および共有の変更については、設定監査履歴と文書化されている変更管理承認を使用する必要があります。

Salesforce では、ユーザーエージェンシーとは、顧客と従業員が AI によるエクスペリエンスへの影響を有意義に制御できることを意味します。Salesforce 同意管理機能、Data 360 同意、カスタム同意オブジェクトにより、AI インタラクションを詳細に制御できます。

AI 固有の同意要件の項目監査履歴を使用する Data 360 同意管理、Marketing Cloud 同意、またはカスタム同意オブジェクトを使用して同意追跡を設計します。

  • **AIの使用事例ごとの詳細な同意を有効にします。**包括的な AI 同意を使用する代わりに、AI 使用事例ごとに同意を有効にします。お客様はEinstein製品の推奨事項に同意しても、AI主導のクレジット決定を拒否できます。長期保存と規制要件の順守のために、同意オブジェクトの項目監査履歴を有効にします。次の項目を追跡するカスタム同意オブジェクトを設計します。
  • 同意の目的(Einstein リードスコアリング、Einstein 返信レコメンデーション、Einstein レコメンデーションビルダーなど)
  • 同意付与日と付与方法 (Web フォーム、API、電話、メールなど)
  • 同意取り消し日 (該当する場合)
  • 関連ユーザーまたは取引先責任者 ID
  • **パーソナライズには Data 360 の同意を使用します。**Einstein Personalization機能には Data 360 同意管理を使用します。Data 360 は、プライバシーデータモデルに対応付けられたコネクタを介して上流システムから同意設定を取り込み、保存します。これにより、セグメンテーションと有効化でこれらの同意属性を検索条件として使用できます。同意属性を特定の AI 使用事例に対応付けて、ユーザーがコアサービスを維持しながらパーソナライズをオプトアウトできるようにする
  • **Marketing Cloud 同意インテグレーションを有効にします。**Marketing Cloudの同意をEinsteinメッセージング インサイトおよびAI駆動型マーケティング機能と統合します。すべての AI 駆動型コミュニケーションで Marketing Cloud の登録状況と同意を尊重します。

同等の品質の人間による代替方法を使用して、ユーザー設定を尊重するアクセス可能な制御を使用して、AI 駆動機能から有意義なオプトアウトを提供します。

  • **プロファイル設定でアクセス可能なオプトアウトを指定します。**Experience Cloud プロファイル設定または内部アプリケーションの [私の設定] のアクセス可能な設定コントロールを使用して、ユーザーが AI 駆動のインタラクションをオプトアウトできるようにします。各オプトアウトの意味と、オプトアウト時にユーザーが受け取る代替環境を明確に説明します。ユーザーレコードまたは取引先責任者レコードに設定を保存します。
  • **チャネル間で永続的なプリファレンスオプションを提供します。**AI 設定をユーザーレコードまたは取引先責任者レコードに保存することで、チャネル (Web、モバイル、電話、メールなど) 間で一貫性を確保します。すべてのインタラクションフローで一貫して設定を照会し、ユーザーがさまざまなチャネルで設定を繰り返し再アサートする必要がなくなります。

倫理的な AI ガバナンスでは、モデルの進化、データシフト、使用事例の拡大に応じて公平性が維持されるように組織構造が提供されます。ガバナンスがない場合、最初の公正さの取り組みは、組織の注意が移ると悪化します。

Einstein リリース前に必須ドキュメントを作成し、チェックポイントを確認します。これは、セキュリティレビューと同じくらい重要なゲートと考えてください。

  • **モデルのドキュメントを提供します。**カスタムモデルオブジェクトを使用するか、プロジェクトに添付された Salesforce Files を使用してモデルのドキュメントを Salesforce に保存することで、検索性とバージョン管理を可能にします。以下を使用して、すべての本番予測モデルを文書化します。
  • トレーニング データのデモグラフィックと既知の表現のギャップ(Einstein Discoveryや予測ビルダーなど、お客様がトレーニングした予測モデルの場合)
  • デモグラフィックグループ別に計算されるリリース前の公平性評価指標
  • 意図された使用事例と既知の不適切な使用事例
  • 開発中に適用されるバイアス緩和戦略
  • 公平性監視のアプローチとアラートしきい値
  • 人の監視要件と承認ワークフロー
  • スケジュールと担当者の確認
  • 規制の考慮事項とコンプライアンスの位置付け
  • **リリース前公平性ゲートを有効にします。**どのゲートテストにも失敗したモデルは、本番に移行できません。公正性ゲートはセキュリティゲートと同じ厳格さで扱います。つまり、リリースをブロックする権限を持っています。Einstein 予測を本番にリリースする前に、次の作業を行う必要があります。
  • **トレーニングデータ監査を確認します。**すべての表現のギャップを分析して文書化する必要があります。
  • 公平性評価指標を確認します(たとえば、人口統計学的同等性、機会均等性、異種影響を計算して、しきい値を満たしていることを確認する必要があります)。
  • **影響評価を確認します。**影響を受ける集団全体の潜在的な被害を評価します。
  • **人の監視による設計。**すべてのエスカレーションパターン、承認ワークフロー、上書きメカニズムを適切に設計してテストする必要があります。
  • **透明性レビューを完了します。**説明機能は、すべての決定種別で検証する必要があります。
  • **完全なドキュメント。**すべての必須モデルドキュメントアーティファクトが承認されている必要があります。

部門横断的な監督を提供し、適用権限を持つ、リスクの高い AI アプリケーションのレビュープロセスを確立します。

  • **ボード構成を確認します。**テクニカルエキスパート (アーキテクトやデータサイエンティストなど)、ビジネス関係者 (商品所有者や業務担当者など)、弁護士、プライバシースペシャリスト、影響を受けるコミュニティの代表者 (可能な場合) を含めます。多様な視点から、同種グループが見逃しがちな公平性の問題を明らかにします。
  • **倫理委員会の承認が必要なすべてのトリガーを確認します。**リリース前に倫理審査が必要な AI 使用事例を定義します。
  • 雇用、信用、住宅、ヘルスケア、法的権利に影響する決定
  • 年間 10,000 人以上のユーザーまたはトランザクションに影響する自動化システム
  • 健康、財務、人口統計などの機密個人データを使用する AI アプリケーション
  • 確立された組織の先例がない新しい使用事例
  • 潜在的なバイアスによって個人またはグループに重大な損害が及ぶ可能性があるシステム
  • **リリースをブロックする権限を持つユーザーを確認して判断します。**倫理審査委員会は、変更を要求したり、監視条件を課したり、倫理基準に準拠しないリリースをブロックしたりする権限を持つ必要があります。アドバイザリのみのレビュー (執行権限なし) では、ガバナンスプロセスの有効性が制限される場合があります。申請名、審査日、提起された懸念、緩和要件、承認条件を追跡する Salesforce カスタムオブジェクトですべての審査を文書化します。

公平性の監視は、データ分布の変化やユーザー母集団の変化に応じてバイアスドリフトを検出するために継続的な注意が必要なプロセスです。

  • **CRM Analytics 公正性ダッシュボードを作成します。**取得した予測モデル決定データを使用して、公平性評価指標を追跡するダッシュボードを作成します。顧客セグメント別の人口統計学的同等性、等しい商談、異種影響率、予測品質総計値を監視します。公正性評価指標が定義済みのしきい値に違反して調査が必要になった場合にトリガーされる CRM Analytics アラートを設定します。
  • **公正性シグナルのカスタム監視を有効にします。**シグナル (デモグラフィックグループ別の決定分布の急激な変化、バイアス関連のケースレコードの急増、特定の母集団のモデルパフォーマンスの低下など) を検出するカスタム公正性監視を構築します。
  • **公平性監査をスケジュールします。**高リスクの AI システム (クレジット、雇用、ヘルスケアなど) については四半期ごとの包括的な公平性監査を実施し、低リスクのシステム (おすすめやパーソナライズなど) については半年ごとの監査を実施します。監査では、現在の公正性評価指標を検証し、承認履歴の上書きパターンを確認し、ユーザーフィードバックとバイアスレポートを分析して、ガバナンス統制が有効であることを確認する必要があります。
  • **公正性障害のインシデント対応を実装します。**バイアスが検出された場合の対応方法を詳細に記述したSalesforce Knowledgeの明確なプロセスを確立します。
  • Immediate: CRM Analytics で予測モデルの決定データを照会して、重要度と範囲を評価します。インシデントが重大である場合は、調査待機中のすべての自動意思決定を一時停止します。
  • 短期: 一時的な緩和戦略を実施します (たとえば、調整された信頼性しきい値による人の監視の強化、機能の無効化、エージェントの完全な一時停止など)。
  • 調査: 根本原因分析 (RCA) を完了して、バイアスがどのようにシステムに導入されたか、またはどのように進化したかを特定します。RCA 中は、項目監査履歴を使用してトレーニングデータ、モデルバージョン、設定変更を分析します。
  • 修正: データ修正、モデルの再トレーニング、またはプロセスの変更によって永続的な修正を実装します。
  • コミュニケーション: 影響を受けるユーザーにケース、メール、または Experience Cloud のお知らせで通知します。
  • 防止: 再発を防止するための変更を処理し、防止方法を runbooks に文書化します。

このチェックリストは、アーキテクチャのレビュー時、本番リリース前、および継続的な評価のために定期的に使用します。

データ品質と表示の公平性

  • データなしでプロセスが機能できる項目を省略可能にし、情報 (メール、SSN、町名・番地) を提供できないユーザーが除外されないように、欠損値を処理するように下流プロセスを設計します。
  • [アーキテクト名] 項目は、単数形、非ラテン文字、発音符号、ロングネームを使用できる、欧米の最初/最後の順序ではなく、単一の氏名項目または柔軟な複数部分構造として表示されます。
  • 形式が一致しない場合にレコードの作成をブロックするのではなく、自由形式と国際形式を受け入れる許可住所検証を実装して、入力された住所を保存します。
  • コミュニケーションチャネルの設定を取引先責任者レコードに保存し、1 つのチャネルがすべてのユーザーに到達すると仮定するのではなく、オムニチャネルの代替手段 (メール、SMS、電話、郵便、チャット、音声) をサポートします。
  • [回答しない] オプションを使用して任意の自己識別でデモグラフィックデータを収集し、[FLS を使用する非公開 OWD] に個別に保存し、レポート用に集計して、Shield Event Monitoring で監視します。
  • デモグラフィックデータや行動データをレコードに追加する前に、公正性テスト、デモグラフィックカバー率、推測方法に関するサードパーティ強化ベンダーを監査します。

アクセシビリティと包括的な設計

  • WCAG 2.2 AA アクセシビリティをサポートするように設計された Lightning Design System コンポーネントを使用します。Salesforce は準拠に努めていますが、コンポーネントには正しい使用方法が必要です。
  • スクリーンリーダーテストを使用してカスタム Lightning Web コンポーネントを検証します(JAWS、NVDA、VoiceOver など)。
  • LightningページとExperience Cloudサイトでマウスに依存しない完全なキーボード ナビゲーションを使用していることを確認します。
  • ブラウザー開発ツールまたはコントラストチェッカーを使用して、通常のテキストのコントラスト比が 4.5:1 であることを確認します。
  • 重要な問題に関するビルドに失敗した CI/CD パイプラインに sa11y または Lighthouse アクセシビリティスキャンを統合します。
  • 正式リリース前に支援技術を使用して Experience Cloud サイトをテストします。
  • すべての動的な変更 (エラー状態、スピナーの読み込み、メニューの展開など) が明確にアナウンスされ、音声コンテンツが UI の視覚的なインテントと一致していることを確認して、聴覚フィードバックを確認します。

Salesforce Automationの公平性

  • 特定のデモグラフィックグループに好ましい結果や望ましくない結果が集中する可能性がある保護された特性との相関関係について、割り当てルールとルーティングルールを確認します。
  • バイアスに関するフローとプロセスの自動化の決定ロジックを監査し、ビジネスルールと条件をSalesforce Knowledgeまたはアーキテクチャの決定レコードに文書化します。
  • 特定のデータパターンまたは母集団に偏りのある却下率の入力規則を評価します。
  • テリトリーとセグメンテーションの設計を分析して人口統計学的相関関係を把握し、明示的なビジネスの正当性を文書化し、十分なリソースが割り当てられていないテリトリーを監視します。
  • リスクの高いフローと割り当てルール (雇用、クレジット、サービスアクセス) を AI システムと同じ倫理審査プロセスの対象とし、人口統計で分類された自動化結果の四半期ごとの監査をスケジュールします。

AI の公平性とバイアスの検出

  • 予測モデルのトレーニングの前に、Salesforce CRM データでデモグラフィック表現のギャップを監査します。
  • リリース前に、デモグラフィックグループごとのデモグラフィックの同等性、均等な商談、異種影響率を計算します。
  • 公正性評価を必須リリースゲートとして実装します (これはセキュリティレビューと同等と考えてください)。
  • 項目監査履歴で取得された予測モデル決定データを使用して、公正性評価指標を追跡する CRM Analytics ダッシュボードを作成します。
  • 予測モデルの特徴を分析して、保護された特性 (テリトリーや取引先名のパターンなど) とプロキシの相関関係を確認します。
  • すべての重要 AI システムの包括的な公平性監査を四半期ごとにスケジュールします。

透明性と監査可能性

  • Lightningコンポーネントの決定ポイントでEinstein Discovery予測の説明を表示します。
  • 規制要件を満たす保存方法を使用して、Einstein Trust Layer監査キャプチャを構成します。
  • 長期保存のために AI 決定データを保存するすべてのカスタムオブジェクトで項目監査履歴を有効にします。
  • 改ざん証拠の SIEM 側のライトワンス制御を使用して、イベント監視データを外部 SIEM (API を介したイベントログファイルデータとプラットフォームイベントを介したリアルタイムイベント監視イベント) にエクスポートし、ネイティブ保持を超えるストレージに保存します。
  • 生の確度ではなく、ユーザーに適した信頼性コミュニケーション (高、中、低など) を提供します。

Salesforce Automationによる人の監視

  • フローで信頼性ベースのエスカレーションしきい値を設定し、信頼性の低い予測を人によるレビューに転送します。
  • 複数フェーズのレビューチェーンを必要とする重要な意思決定には、Salesforce 承認プロセスを使用します。
  • Agentforceとオムニチャネルのルーティングを統合し、人間のエージェントへのシームレスなエスカレーションを可能にします。
  • Agentforce インターフェイスで永続的な ［Connect to Human Agent］ オプションを提供して、ユーザ代理店に配慮します。
  • カスタム フィールドで取得される Agentforce 上書きのドキュメント化された根拠と承認履歴の追跡が必要です。

データアクセス制御による差別なし

  • [非公開 OWD] を有効にし、ロール階層と共有ルールを使用して追加のアクセス権を付与します。
  • 項目レベルセキュリティを設定して、アクセスが不要なユーザーに機密のデモグラフィック項目を非表示にします。
  • Shield Event Monitoring を使用して機密データのオブジェクトレベルのアクセスイベント (レポートエクスポートおよび API クエリ) を監視し、異常なアクセスパターンを分析します。
  • 共有ルールの分布を分析して、テリトリー全体で公平なレコード割り当てを確保するレポートを作成します。
  • 未承認の OWD、共有ルール、または FLS 設定の変更がないか [設定変更履歴] を確認します。

ユーザーエージェンシーと同意

  • 項目監査履歴を使用してカスタム同意オブジェクトを設計し、使用事例ごとの詳細な AI 同意を追跡します。
  • Data 360またはMarketing Cloudの同意をEinstein PersonalizationおよびAgentforce機能と統合します。
  • AI 設定をユーザーレコードまたは取引先責任者レコードに保存することで、チャネル (Web、モバイル、電話など) 間で一貫性を確保します。
  • オムニチャネルルーティングを使用して、プロファイル設定とユーザーによる代替設定でアクセス可能なオプトアウトを提供します。
  • Einstein 予測または Agentforce エンゲージメントがユーザーに影響する前にフローで同意レコードを照会します。

倫理的なAIガバナンス

  • 公正性評価指標や軽減戦略を含むすべての本番予測モデルを文書化します。お客様がトレーニングした予測モデル(Einstein Discoveryや予測ビルダーなど)の場合は、トレーニング データのデモグラフィックも文書化します。
  • すべての公平性が満たされるまでリリースをブロックする必須のリリース前公平性ゲートを設定します。
  • すべての高リスク AI アプリケーションの執行機関として AI 倫理審査委員会を作成します。
  • CRM Analytics アラートを使用して、スケジュールされたケイデンスで公正性評価指標を監視する CRM Analytics ダッシュボードを作成します。
  • 公平性障害のインシデント対応手順を定義し、そのプロセスをSalesforce Knowledgeに文書化します。
  • すべての重要システムの上書きパターンとユーザーフィードバックを分析する四半期ごとの公平性監査をスケジュールします。

適切に構築されたフレームワークに関するフィードバックを共有する。