# architect 適切に設計された (well-architected) - Full Documentation

<!-- document id=718ef814e91d80dc64791f52a474ad86f0394e9e56bbb33f79057d5a26cef61d url=/architect/next/ja-jp/well-architected/guides/engaging.md -->

> 更新スケジュールについては、[こちら](/docs/architect/ja-jp/well-architected/guide/contributors)を参照してください。

## はじめに

システムは、ユーザーがアプリケーションにアクセスして簡単に使用できるようにすることで、ユーザーがより質の高い作業ができたと感じ、システムでアプリケーションを使用したくなるようにすることで、魅力的な行動を示します。

エンゲージメント行動は、ユーザーの採用だけでなく、全体的な従業員満足度や顧客満足度にも直接関連するため、ビジネスにとって重要です。エンゲージ動作は、サポート要求を減らすのにも役立ち、ユーザーからの機能要求の品質を高めるのに役立ちます。

エンゲージ行動を作成する際の課題の 1 つは、客観的な指標のみで測定することが難しいことです。代わりに、ユーザーの主観的なエクスペリエンスによって評価されます。ユーザーは、エンゲージアプリケーションが真の価値を提供すると感じています。魅力的なアプリケーションは、[アクセス可能で](/docs/architect/ja-jp/well-architected/guide/compliant#アクセシビリティ)、邪魔にならず、わかりやすくなっています。最小限のオンボーディングとトレーニングが必要です。また、明確な方法を使用して、ユーザーエラーを積極的に防止します。

もう 1 つの課題は、エンゲージメントの目標が、システムのユーザーインタラクションの種別によって異なることが多いことです。たとえば、ケースを管理する内部ユーザーと、Web サイトのフォームから情報を送信する外部ユーザーの目標を設定できます。魅力的なシステムを設計するためには、機能とページの組み立てを開始する前に、作成しようとしているエンゲージメントの種別とユーザーがエンゲージを希望する理由を慎重に検討する必要があります。

ユーザーエクスペリエンス (UX) デザイナーと連携することで、魅力的なアプリケーションの配信に関してより効果的な意思決定を行うことができます。アーキテクチャの観点からは、ユーザーの採用と保持は健全なシステムの重要な要素です。魅力的なアーキテクチャにより、ユーザーが楽しくないシステムで時間を費やすことを避けるためにプロセスを急いだり、ステップをスキップしたりすることによって発生するデータ品質の問題の可能性を低減できます。対外システムの場合、魅力的なアーキテクチャにより、システムを扱いやすくなった顧客が組織でより多くのビジネスを行うことを選択できるため、収益と顧客維持率を高めることができます。

合理化された有益な環境を提供することに集中することで、より魅力的なアプリケーションを作成できます。

## 合理化

合理化されたアプリケーションは操作が簡単で、情報やデータ入力タスクを明確に表示でき、さまざまなフォーム要素に適応できます。合理化されたアプリケーションには、ユーザーが他の一般的なアプリケーションで使い慣れた環境パターンも含まれています。たとえば、ほとんどの Web ブラウザーでは、ユーザーがリンクを右クリックすると、最上位のオプションとして「新しいタブで開く」が表示されます。タブを含む合理化されたアプリケーションも同じパターンに従います。

非効率的なアプリケーション環境の影響は、個々のアプリケーションの範囲を超えて広がる可能性があります。アプリケーション エクスペリエンスが低いと、ユーザーの Trust が損なわれます。より多くの種類のビジネスクリティカルなアプリケーションや顧客向けアプリケーションがデジタルチャネルに移行すると、主要な関係者のロイヤルティが失われる可能性があります。

アプリケーションの複雑さ、フォーム設計、フォーム要素に意図的に取り組むことで、アプリケーションをより合理化できます。

### アプリケーションの複雑さ

アプリケーションの複雑さを最小限に抑えると、ユーザーには関連するメニュー項目、タブ、ナビゲーションコントロールのみが表示されます。ユーザーグループ、ユーザー権限、適切なアプリケーション環境間の対応付けを作成する必要があります。これらの対応付けを使用して、特定のユーザーに表示するアプリケーション環境を理解し、その環境を提供するために必要な論理的な制御をアプリケーションに提供します。

ユーザーが複雑すぎると、さまざまなエクスペリエンスが低下する可能性があります。

- ユーザーには、不要なタブや無関係なタブが表示され、空白の画面に移動し、無効またはブロックされたリンクが表示されることがよくあります。
- 「ロールが X の場合、このタブを無視...」のような不要な指示や役に立たない指示は、トレーニングやイネーブルメント資料に表示されます。
- ナビゲーションメニューが乱雑になっていると、ユーザーは作業に必要な項目を見つけるために余分な時間を費やすことになります。

これらのエクスペリエンスが低いと、採用率と満足度が低下します。

アプリケーションの適切な複雑さのレベルを判断するときは、次の点を考慮してください。

- ユーザーが実行する必要がある作業の優先度に基づいてメニュー、タブ、その他のナビゲーションコントロールを整理します。
- ユーザーがアプリケーションを使用するためだけに学習する必要がある新しい動作の導入は避けてください。
- ユーザーがユーザーインターフェースの側面をカスタマイズできるようにする機能へのアクセス権を削除しないでください。
- 権限セットを使用して、拡張または縮小されたナビゲーションオプションを提供します。
- Lightning ページの[有効化の割り当て](https://help.salesforce.com/s/articleView?id=sf.lightning_page_getting_into_salesforce1.htm)を合理化します。アプリケーションあたりのアクティブな Lightning ページ数を最小限に抑えます。動的フォーム、権限セット、条件付き表示を使用して、項目をアプリケーションの Lightning ページに追加します。これは、プロファイルによって有効化および割り当てられた複数の Lightning ページを管理する代わりに実行します。

次の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/engaging#合理化されたアプリケーションパターンとアンチパターン)のリストは、Salesforce 組織でのアプリケーションの複雑さ管理が適切 (および不適切) であることを示しています。これらを使用して、アプリケーション設計を検証または改善できます。

アプリケーションの複雑さの管理に役立つ Salesforce ツールについての詳細は、「[Tools Relevant to Engaging](/docs/architect/ja-jp/well-architected/guide/engaging#エンゲージメントに関連するツール) (エンゲージメントに関連するツール)」を参照してください。

### フォーム

合理化されたフォームでは、情報が論理シーケンスに整理され、迅速なデータ入力がサポートされ、必要なステップが最小限に抑えられます。また、[便利な](/docs/architect/ja-jp/well-architected/guide/engaging#役に立つ)クライアント側のデータ検証メッセージも使用できるため、フォームの送信サイクルを繰り返す必要がなくなります。

フォームを設計するときは、次の点を考慮してください。

- **関連フィールドをグループ化**します。プロセスまたはデータ入力タスクの同じステップに関連する項目をグループ化します。現在の ToDo に直接関連しない項目を削除します。
- **データ入力と検証を早期**に行います。ユーザーがデータを入力する必要がある項目は、フォームの早い段階で表示されます。データ書式設定やデータの欠落に関する問題を項目レベルでできるだけ早く (つまり、ユーザーが次のステップに移動したりフォームを送信したりする前に) 明らかにすることをお勧めします。また、ユーザーが項目にデータを入力する前に項目レベルのエラーを表示しないようにします。
- **データ入力タスク**を最小限に抑えます。できるだけ多くの項目を事前入力またはオートコンプリートして、データ入力エラーを最小限に抑え、効率を向上させます。必須または重要なデータの入力のみをユーザーに求めます。現在のビジネスプロセスに関連しないデータ入力を排除します。可能な場合は、自由形式のテキスト項目の代わりに選択リストを使用して、有効なオプションの選択を適用し、同じ回答のバリエーションを減らします。
- **サーバへの送信**を最小限に抑えます。複数ステップフォームでデータを複数回サーバーに送信しないでください。すべてのカスタム [LWC](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.apex_result_caching) または [Aura](https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/controllers_server_storable_actions.htm) コンポーネントでクライアント側キャッシュを使用してナビゲーションまたはページネーションアクションを処理します。(Salesforce Lightning Experience および Salesforce モバイルアプリケーションでは、デフォルトでクライアント側キャッシュが使用されます)。ユーザーがサーバーにデータを 1 回のみ送信するようにフォームを設計します。フォームを送信する前にクライアント側でユーザー入力を検証します。これにより、意図しないユーザー送信を最小限に抑え、重複またはダーティなトランザクションによってバックエンドの帯域幅が消費されることを防止し、より適切[なデータ処理](/docs/architect/ja-jp/well-architected/guide/automated#データ処理)を設計するのに役立ちます。
- **フォーム状態の管理**。クライアント側キャッシュは、ナビゲーションやページネーションなどの動作に役立つだけでなく、断続的な接続の問題によるデータ損失を最小限に抑えるのに役立ちます。また、状態を効果的に管理することで、アプリケーションはサーバーへのデータ送信を適切に調整し、トランザクションの重複を防止できます。また、サーバー側のアクションの状況に基づいて、関連性の高いメッセージをタイムリーにユーザーに表示できます。合理化されたフォームでは、データ操作は 1 回のみ送信され、ユーザーはサーバーで長時間実行されている操作が完了するまで待つ必要はありません。
- **アクセシビリティ標準に準拠**します。アプリケーションの利用者を最大化し、すべての顧客をアプリケーションの対象に含めるには、フォーム設計で[アクセシビリティ](/docs/architect/ja-jp/well-architected/guide/compliant#アクセシビリティ)の標準を適用します。

合理化されたフォームは、アプリケーションの[データの整合性](/docs/architect/ja-jp/well-architected/guide/automated#データ整合性)を高め、アプリケーションがユーザーにどれほど[役立つ](/docs/architect/ja-jp/well-architected/guide/engaging#役に立つ)かを示すのに役立ちます。また、ユーザーはエラーに対処しやすくなり、フォーム送信の状態を明確に把握できるため、サポートチケットや要求を減らすこともできます。さらに、合理化されたフォームにより、迅速かつ効率的なデータ入力が可能になり、ユーザーはより長い時間かかるプロセスが完了するまで待機することなく、さらに作業を進めることができます。

次の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/engaging#合理化されたアプリケーションパターンとアンチパターン)のリストは、Salesforce 組織での適切な (および不適切な) フォーム設計を示しています。フォームデザインの検証や改善に使用できます。

より合理化されたフォームの作成に役立つ Salesforce ツールについての詳細は、「[Tools Relevant to Engaging](/docs/architect/ja-jp/well-architected/guide/engaging#エンゲージメントに関連するツール) (エンゲージメントに関連するツール)」を参照してください。使用事例に適したフォームツールの選択に関する具体的な指針については、「[Architect’s Decision](/docs/architect/ja-jp/decision-guides/guide/build-forms#重要ポイント) Guide to Building Forms with Salesforce (Salesforce を使用したフォームの作成に関するアーキテクトの決定ガイド)」を参照してください。

### フォーム要素

エンゲージメントアプリケーションは、さまざまなデバイスやインタラクション種別、フォーム要素に適切に適応します。デバイス種別に応じて、さまざまな種類のユーザー操作が容易 (または困難) になり、フォームや項目の読みやすさも変わります。フォーム要素は、画面のサイズに加えて、ユーザーが画面を操作する方法も示します。タッチスクリーンを使用するデバイスが増加し、一部のユーザーは[アクセシビリティ](/docs/architect/ja-jp/well-architected/guide/compliant#アクセシビリティ)のために特殊なデバイスを使用することもあります。フォームを設計するときは、次の点を考慮してください。

フォーム要素のバリエーションを考慮しないと、次のようなさまざまな問題が発生する可能性があります。

- データ品質が低い
- 使用できないアプリケーションインターフェース
- サポートエージェントのトラブルシューティングまたは「代理注文」セッションの増加
- ユーザーの採用率が低い、有効ユーザー数が少ない、アプリケーションの「放棄」率が高い

Salesforce アプリケーションのフォーム要素間の相互運用性を考慮して設計するには、次の点を考慮してください。

- **すべてのアプリケーションでサポートされているフォーム要素を特定します。**
- **入力メソッドとユーザーのアクセシビリティのニーズを特定します。**詳細は、「[アクセシビリティ](/docs/architect/ja-jp/well-architected/guide/compliant#アクセシビリティ)」を参照してください。
- **可能な場合は、[標準機能](/docs/architect/ja-jp/well-architected/guide/intentional#標準機能とカスタム機能)を使用してデバイス間で適応型環境を提供します。**
  - Salesforce が提供する [Lightning ページテンプレート](https://help.salesforce.com/s/articleView?id=sf.lightning_page_templates.htm&type=5)では、デフォルトでさまざまなフォーム要素がサポートされます。Aura を使用してカスタム Lightning ページテンプレートを開発する場合、開発者はフォーム要素情報をコンポーネント設計ファイルに組み込む必要があります。
  - Salesforce が提供する[標準ページコンポーネント](https://help.salesforce.com/s/articleView?id=sf.lightning_page_components.htm&type=5)は、サポートされるフォーム要素での表示を処理します。LWC または Aura を使用してカスタムコンポーネントを作成する場合、開発者は幅認識を処理し ([Aura](https://developer.salesforce.com/docs/atlas.en-us.238.0.lightning.meta/lightning/components_config_for_app_builder_width_aware.htm?q=width) と [LWC](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/use_width_aware) では実装が異なります)、コンポーネントの設計ファイル内でフォーム要素のサポートを宣言する必要があります。
- **すべての[デバイスでフォーム](/docs/architect/ja-jp/well-architected/guide/engaging#フォーム)**の合理化に関するガイダンスに従います。
- **主要なフォーム要素のテスト計画 (および適切なテスト) を作成します。**理想的には、すべてのアプリケーションのすべてのデバイスとフォーム要素でテストします。ただし、フォーム要素テスト用に適切なデバイス (またはデバイスシミュレーター) を設定するのは、大きな投資になる可能性があります。特定のアプリケーションまたはアプリケーションセットにモバイルまたはタブレットのユーザーセットが多数含まれることがわかっている場合は、モバイルおよびタブレットフォーム要素でそれらのアプリケーションの正確なテストを優先します。

次の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/engaging#合理化されたアプリケーションパターンとアンチパターン)のリストは、Salesforce 組織でのフォーム要素の適切な (および不適切な) 認識を示しています。これらを使用して、作成前にデザインを検証したり、リファクタリングが必要なページを識別したりできます。

効果的なフォーム要素設計のための Salesforce ツールについての詳細は、「[Tools Relevant to Engaging](/docs/architect/ja-jp/well-architected/guide/engaging#エンゲージメントに関連するツール) (エンゲージメントに関連するツール)」を参照してください。

### 合理化されたアプリケーションパターンとアンチパターン

次の表に、組織で検索 (または作成) するパターンと、回避または修正の対象となるアンチパターンの選択を示します。

✨ [パターン & アンチパターンエクスプローラー](/docs/architect/ja-jp/well-architected-tools/guide/easy-streamlined)で合理化されたアプリケーションのより多くのパターンを検出します。

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">パターン</th>
            <th scope="colgroup">アンチパターン</th>
        </tr>
        <tr>
            <td rowspan="1"><b>アプリケーションの複雑</b>性</td>
            <td><b>組織内：</b>
            <br> -管理者が指定したデフォルト設定でアプリケーションのタブ数が 10 個未満である
            <br> [このアプリケーションのナビゲーション項目のエンドユーザーパーソナライズを無効化] が true に設定されているアプリケーションはありません。</td>
            <td><b>組織内：</b>
            <br> - システム管理者が指定したデフォルト設定で、アプリケーションのタブが 10 個を超えている
            <br> - 多くのアプリケーションで [このアプリケーションのナビゲーション項目のエンドユーザーパーソナライズを無効化] が true に設定されているか、ナビゲーション項目をカスタマイズする権限が組織全体で無効になっている</td>
        </tr>
        <tr>
            <td rowspan="2"><b>フォーム</b></td>
            <td><b>アプリケーション内：</b>
            <br> - 項目は論理グルーピングに従う<br> - データ入力項目が 5 個以下のグループでまとめて表示される
            <br> - データ入力エラーが明確で、ユーザーが移動したりデータを送信したりする前に項目レベルで表示される
            <br> -ページ設定コントロールでステップ間の移動が可能<br> - データ登録は 1 回のみ
            <br> - アクションとナビゲーションの表示ラベルが明確である
            <br> -ボタンクリックなどのユーザーアクションを確認するためのタイムリーで視覚的なフィードバックが提供される
            <br> -ナビゲーションボタン (「戻る」、「次へ」、「戻る」など) を UI 全体に一貫して配置</td>
            <td><b>アプリケーション内：</b>
            <br> - データ入力項目が論理的にグループ化されていないため、ユーザーがフォームに入力する際に大量のコンテキストを切り替える必要がある
            <br> - データ入力エラーには、システムの内部の仕組みを理解しているユーザーのみが解釈できる難解な情報が含まれています。
            <br> - データ入力エラーは、フォームの送信ボタンをクリックしたときにのみ表示されます。
            <br> - ステップとグルーピングが明確ではないため、ナビゲーションが困難
            <br> - データ登録はデータ入力プロセス全体で複数回行われます。
            <br> - アクションとナビゲーションの表示ラベルは、基盤となるシステム機能に精通していないユーザーに混乱を招く
            <br> - ユーザーアクションの視覚的な確認が提供されない
            <br> -ナビゲーションボタンが UI 全体の任意の場所に表示される</td>
        </tr>
        <tr>
            <td><b>フォームロジック内：</b>
            <br> - 項目は可能な限り事前入力またはオートコンプリートされる
            <br> - ユーザーは、実行時間の長いサーバー側アクションの完了を待つ必要はありません。
            <br> - カスタムコンポーネントでは、データ操作を含まないサーバーベースのアクションに <code>cacheable=true</code> を使用します。
            <br> - データ操作は 1 回のみ実行
            <br> - LWC では、<code>@wire</code> アダプターはデータ操作を含まないすべてのアクションを処理します。</td>
            <td><b>フォームロジック内：</b>
            <br> - 事前入力またはオートコンプリートが可能な項目は、手動で入力する必要があります。
            <br> -ユーザーは送信プロセス中に作業を停止して、サーバー側アクションが完了するまで待機する必要がある
            <br> - カスタムコンポーネントが <code>cacheable=false</code> に設定されている</td>
        </tr>
        <tr>
            <td rowspan="3"><b>フォーム要素</b></td>
            <td><b>組織内：</b>
            <br> -Salesforce が提供する Lightning ページテンプレートが、すべてまたはほとんどのページで使用されます。
            <br> - カスタム Lightning ページテンプレートでは、Aura コンポーネント設計ファイルで <code>design:supportedFormFactors</code> および <code>design:supportedFormFactor</code> を使用します。
            <br> - アプリケーションビルダーで使用可能なカスタム LWC または Aura コンポーネントは、それぞれの設計ファイルでサポートされるフォーム要素を宣言し、幅を認識するスタイルパターンを実装します。</td>
            <td><b>組織内：</b>
            <br> - Classic はまだ有効
            <br> - カスタム Lightning ページテンプレートでは、Aura コンポーネント設計ファイルで <code>design:supportedFormFactors</code> と <code>design:supportedFormFactor</code> が一様に使用されません。
            <br> - アプリケーションビルダーで使用可能なカスタム LWC または Aura コンポーネントでは、サポートされるフォーム要素がそれぞれの設計ファイルで一貫して宣言されない
            <br> - カスタム LWC または Aura コンポーネントでは、Salesforce が提供するインターフェースで幅を認識するスタイルは実装されません。
            <br> - カスタム LWC または Aura コンポーネントでは、さまざまなフォーム要素のスタイルは、CSS のハードコードされた <code>px</code> 値または <code>%</code> 値のみによって決まります。</td>
        </tr>
        <tr>
            <td><b>デスクトップの場合：</b>
            <br> - データ入力項目とナビゲーションコントロールが画面に表示され、意図したとおりに操作できる
            <br> -ページの有効化の割り当てルールに基づいて、レコードページとアプリケーションページが正しく表示される</td>
            <td><b>デスクトップの場合：</b>
            <br> - データ入力項目とナビゲーションコントロールが画面上の意図した場所に表示されない
            <br> - データ入力項目やナビゲーションコントロールとのやりとりが必須動作と一致しない
            <br> -ページ有効化の割り当てルールがないため、すべてのユーザーに同じレコードページとアプリケーションページが表示される</td>
        </tr>
        <tr>
            <td><b>モバイルおよびタブレットの場合:</b>
            <br> -データ入力とナビゲーションコントロールが正しく表示される
            <br> ・データ入力が簡単
            <br> 小さいフォーム要素用に最適化されたモバイルナビゲーションメニューが表示される
            <br> - コンパクトレイアウトがレコードレベルに表示される</td>
            <td><b>モバイルおよびタブレットの場合:</b>
            <br> - データ入力とナビゲーションコントロールの表示が一貫していない、または正しくない
            <br> -ユーザーが簡単にデータを入力できない
            <br> -モバイルナビゲーションメニューはデスクトップナビゲーションと区別できない
            <br> - コンパクトレイアウトがレコードレベルで設定されていない</td>
        </tr>
    </tbody>
</table>

## 役に立つ

役に立つアプリケーションを使用すると、ユーザーは集中の邪魔や中断が少なく、より強力かつ効果的に作業できます。

役に立つアプリケーションは、手動エラーを軽減し、必要なときに必要な場所でユーザーにフィードバックを提供することで、[データの整合性](/docs/architect/ja-jp/well-architected/guide/automated#データ整合性)を維持します。ユーザーが現在および次に焦点を絞る必要があるアクションを把握し、問題をより迅速に解決するための関連情報を提供します。ユーザーのアクションと有意義な影響や成果を明確に結び付けることができます。

通知とメッセージ、アプリケーション内ガイダンス、レコグニションと報奨の 3 つの主要な習慣を使用して、より便利なアプリケーションを作成できます。

### 通知とメッセージ

通知とメッセージは、ユーザーが最新情報を把握するのに役立ちます。

適切に設計された通知およびメッセージングシステムは、重要な意思決定に必要な情報をタイムリーにユーザーに提供することで、エンゲージメントと生産性を向上させることができます。不適切に設計された通知およびメッセージングシステム (関連性もタイムリー性もないメッセージを表示するシステム) は、逆の効果をもたらします。内部ユーザーは通知をすぐに無効にしたり無視したりして、重要なビジネスプロセスに影響する可能性のある正当なメッセージを見逃します。無意味な通知にうんざりした顧客やその他の外部ユーザーは、システムの使用を完全に停止する場合があります。

アプリケーションによるユーザーへの通知とメッセージの送信の処理方法を決定するときは、次の点を考慮してください。

- **エラーの場合は、最後の手段として通知とメッセージを使用します。**人間の介入なしで特定の種類のエラーを修正できるバックエンド処理を使用して、システムの[エラー処理](/docs/architect/ja-jp/well-architected/guide/automated#エラーハンドリング)を設計します。ToDo を完了できない重大なエラーに関するメッセージのみをユーザーに送信します。同様に、ビジネスユーザーが自分で実行できる (する必要がある) 是正措置がある場合のみエラーメッセージを送信します。追加のエラーメッセージや詳細は、レポートで提供したり、非同期方法を使用してテクニカルサポートスタッフに送信してフォローアップしたりできます。
- 関連性、緊急性、適時性に基づいてメッセージ種別を**選択します**。メッセージの種別によって、ブロックまたは中断動作のレベルが異なります。通知は「ブロック」メッセージの一種で、作業を続行する前にユーザーに通知の確認を求めるものです。エラーメッセージと同様に、通知は慎重に使用する必要があります。トースト通知は[ノンブロッキング](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/use_toast)で、異なる永続性動作を持つことができ、さまざまな種類のメッセージの使用事例をサポートします。最も邪魔にならないメッセージは、[アプリケーション内通知](https://help.salesforce.com/s/articleView?id=sf.notif_builder.htm&type=5)またはメールです。これらは、ユーザーが選択したタイミングと方法で処理できる情報を提供するために最適です。
- **次に何**を実行する必要があるかを検討します。通知には情報的なもの (成功メッセージなど) もあれば、ユーザーが何らかのアクションを実行する必要があるものもあります。通知を設計するときは、通知自体だけでなく、ユーザーがアクションを実行するために必要な追加情報も考慮してください。アクション可能なすべての通知に、ユーザーが追加情報を検索したり、フォローアップ手順を完了したりできる明確な手順やリンクを含めます。
- **読みやすさに重点**を置く。各通知の目的と、それに応じてユーザーが実行する必要のある次のステップを明確に伝えます。メッセージは、基盤となるシステムの内部の仕組みに精通していないビジネスユーザーが理解できるようにする必要があります。メッセージを作成するときは、[アクセシビリティ標準](/docs/architect/ja-jp/well-architected/guide/compliant#アクセシビリティ)に従って、メッセージが表示される地域のサポートユーザーにローカライズしてください。

アプリケーションビルダーが一貫した方法に従うことができるように、どのような場合に通知やさまざまな種類のエラーを使用するかを[設計標準](/docs/architect/ja-jp/well-architected/guide/intentional#設計標準)に含めます。

次の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/engaging#役に立つアプリケーションパターンとアンチパターン)のリストは、Salesforce 組織での適切な (および不適切な) 通知とメッセージングを示しています。これらを使用して、構築前に設計を検証したり、リファクタリングが必要な利用状況を特定したりできます。

通知およびメッセージング用の Salesforce ツールについての詳細は、「[Tools Relevant to Engaging](/docs/architect/ja-jp/well-architected/guide/engaging#エンゲージメントに関連するツール) (エンゲージメントに関連するツール)」を参照してください。

### アプリケーション内ガイダンス

アプリケーション内ガイダンスは、複雑なワークフローを理解しやすくしたり(必ず最初に最適[化](/docs/architect/ja-jp/well-architected/guide/automated#プロセス設計)しておく必要があります)、新しいスタッフのオンボーディングを支援したりする強力な方法です。これは、プロセスの変更の導入、新機能の強調表示、自動化されたスケーラブルなトレーニングの配布を行う優れた方法です。ただし、慎重に実装しないと、アプリケーション内ガイダンスが過度に使用される可能性があります。ポップアップやアラートを頻繁に行うと、ユーザーの騒音や中断が大きくなり、生産性が低下する可能性があります。また、アプリケーション内ガイダンスの使用頻度が低いため、リリースおよび変更管理プロセスが煩雑になる可能性があります (特にシンプルな機能)。最終的に、アプリケーション内ガイダンスの過剰使用と過少使用のどちらも、ビジネスに次のようなリスクをもたらす問題を引き起こします。

- データの整合性の低下
- ユーザーエラーの増加
- ユーザーのストレスレベルが高く、ユーザーの満足度が低い
- ユーザーの生産性の低下

アプリケーション内ガイダンスは、ユーザーの考え方によって「多すぎる」か「十分ではない」かが決まるため、シナリオごとに異なる方法で使用します。新しいシステムを初めて導入するユーザーは、使い慣れたシステムの新機能について単に学習するユーザーよりも頻繁にメッセージングが必要になります。

効果的なアプリケーション内ガイダンスを作成するための鍵を次に示します。

- **設計標準を開発**します。アプリケーション内ガイダンスが公開されすぎると、ユーザーがメッセージを頻繁に破棄したり無視したりする可能性があります。この時点で、アプリケーション内ガイダンスはリソースではなく厄介なものになります。プロンプト、ウォークスルー、項目レベルのヘルプテキスト、検証メッセージ、パス、画面フローなどを使用するタイミングを明確にするために、[設計標準](/docs/architect/ja-jp/well-architected/guide/intentional#設計標準)を定義します。
- **ガイダンス実装の優先順位付けシステムを作成します。**アプリケーション内ガイダンスのすべての使用事例を実装する必要はありません。代わりに、次の質問に優先順位を付けます。より直観的なワークフローを作成するために、より適切な項目名、ボタンの表示ラベルの明示化、より優れた[フォーム設計](/docs/architect/ja-jp/well-architected/guide/engaging#フォーム)、および[プロセスの最適化](/docs/architect/ja-jp/well-architected/guide/automated#プロセス設計)をシンプルに使用できるのはどこか?パスに役に立つテキストやリンクを追加できる場所は?アプリケーション内ガイダンスが[ビジネスコストに](/docs/architect/ja-jp/resources/guide/kpi-spreadsheet-template)与える影響は?ユーザーにメッセージを配信する頻度は?また、すべての関係者が確認できるように、実装が[ロード](/docs/architect/ja-jp/well-architected/guide/intentional#ロードマップ)マップに含まれていることを確認します。
- **ユーザーを有効な (および提案された) アプリケーション内ガイダンスに対応付けます。**ユーザーをアプリケーション内ガイダンスに対応付けると、ユーザーに表示されるアプリケーション内ガイダンスが多すぎることによる「ヘルプの過負荷」を特定して防止できます。これは多くの場合、チームが特定の使用事例について偏狭に考えすぎているため、サイロ化された開発の結果です。ユーザーが何にさらされるかの全体像を維持することは、大規模な組織では特に重要です。ロードマップにガイダンスの実装を含めることも役立ちます。
- **フィードバックを収集して改善に役立てます。**アプリケーション内ガイダンスの利用状況に関するデータを確認し、アプリケーション内ガイダンスのリリースの効果を判断するために使用します。ガイダンス作成者を支援するために、ユーザーが自由回答型のフィードバックも提供してください。

次の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/engaging#役に立つアプリケーションパターンとアンチパターン)のリストは、Salesforce 組織での適切な (および不適切な) アプリケーション内ガイダンスを示しています。これを使用して、構築前に設計を検証し、リファクタリングが必要な実装を特定できます。

アプリケーション内ガイダンス用の Salesforce ツールについての詳細は、「[Tools Relevant to Engaging](/docs/architect/ja-jp/well-architected/guide/engaging#エンゲージメントに関連するツール) (エンゲージメントに関連するツール)」を参照してください。

### レコグニションと報奨

レコグニションと報奨をアプリケーションに組み込むことで、そのアプリケーションを使用する個人は仕事の影響をより身近に感じ、貢献度、生産性、パフォーマンスの価値をよりよく理解できます。また、ロイヤルティとエンゲージメントを解放する強力な方法でもあります。

レコグニションやアプリケーションエクスペリエンスの報奨を与えるように設計していないと、次のようなさまざまな問題が発生する可能性があります。

- 進行状況や進行速度の理解に苦労しているユーザー
- 目標や未完了の作業への進行状況に関する混乱
- 自分の ToDo と「全体像」との関連性を感じていない非生産的なユーザーが多い
- 手動の低レベルの目標レポートによる管理時間の浪費

報奨を与えるアプリケーションエクスペリエンスは、会社の文化、ポリシー、標準、および個々のユーザーのコンテキストと設定によって異なるため、設計と提供が難しい場合があります。デスクトップユーザーが喜びや感謝を感じるのに役立つ機能は、モバイルのユーザーや、騒がしく忙しいホームオフィスで作業をしようとしているユーザーにとって苛立ちとなる可能性があります。アプリケーションを使用して非公開または機密性の高い情報を操作しているユーザーは、紙吹雪やバッジのような形でのマイルストーンに関するコミュニケーションに感謝しない可能性があります。一方、分散した営業チームは、このようなゲーミフィケーションを適切なアプリケーション環境として認識できます。最終的に、選択する実装パターンは、チームのユーザーエクスペリエンス (UX) デザイナーと協力して決定することをお勧めします。

アーキテクチャについては、ユーザーが評価され、報われると感じるのに役立つ機能をアプリケーションで実装する方法と場所を特定することが重要です。また、これらの機能によってアプリケーション[の再利用](/docs/architect/ja-jp/well-architected/guide/composable)性が低下したり、[実際のビジネス バリュー](/docs/architect/ja-jp/well-architected/guide/automated#ビジネス上の価値)が失われる可能性がある方法と場所を理解することも重要です。

Salesforce アプリケーションでレコグニションと報奨を評価するときには、次の点を考慮してください。

- **ユーザーが自分の進捗状況とチーム全体の統計を確認する方法と場所は?**レポートは重要ですが、多くの場合、サマリーデータが含まれており、日常業務のコンテキストを見落としてしまう可能性があります。Lightning アプリケーション・ビルダーなどのツールを使用して、アプリケーションのコンテキスト内のレコード画面にグラフやダッシュボードを埋め込むことができます。これにより、ユーザーは日常業務に取り組むときにその影響や進行状況を理解できます。
- **ユーザーはどのように認識される必要がありますか?**これは、チームまたは個人の設定によって異なる場合があります。場合によっては、スーパーバイザーはユーザーの進行状況に関するメッセージを表示して、より大きなグループと共有できます。レコグニションは、従業員の士気を高めるのに役立つ追加特典になる場合もあります。また、特定の ToDo やプロジェクトの進行状況の通知をユーザーのみにすることを希望する場合もあります。

以下の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/engaging#役に立つアプリケーションパターンとアンチパターン)のリストは、Salesforce 組織での適切な (および不適切な) 認識と報奨を示しています。これを使用して、構築前に設計を検証し、リファクタリングが必要な実装を特定できます。

評価と報奨のための Salesforce ツールについての詳細は、「[Tools Relevant to Engaging](/docs/architect/ja-jp/well-architected/guide/engaging#エンゲージメントに関連するツール) (エンゲージメントに関連するツール)」を参照してください。

### 役に立つアプリケーションパターンとアンチパターン

次の表に、組織で検索 (または作成) するパターンと、回避または修正の対象となるアンチパターンの選択を示します。

✨ [パターン & アンチパターンエクスプローラー](/docs/architect/ja-jp/well-architected-tools/guide/easy-helpful)で、役立つアプリケーションの他のパターンを見つけます。

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">パターン</th>
            <th scope="colgroup">アンチパターン</th>
        </tr>
        <tr>
            <td rowspan="3"><b>通知とメッセージ</b></td>
            <td><b>設計標準には次のものが含まれます。</b>
                <br> - 通知、トースト、通知の承認済み使用事例
                <br> -トーストのバリエーションと通知のデザインパターン
                <br> - エラーメッセージのデザインパターン</td>
            <td>設計標準がまったく定義されていない場合、エラーや通知に対処できない</td>
        </tr>
        <tr>
            <td><b>組織内：</b>
                <br> - 通知が主要なメッセージング形式
                <br> -トーストメッセージでバリエーションを使用
                <br> - <code>モード</code>が [<code>スティッキ]</code> に設定されたトーストメッセージが存在しない
                <br> - 通知はほとんど使用されない (まったく使用されていない場合)
                <br> - 生成された応答により、常に使用されるデータソースが特定されます。
                <br> -ボットはユーザーとの最初のやりとりの前に自分自身を明確に識別します。
                <br> - 生成 AI に関連するリスクの免責事項は、最初の操作の前にユーザーに表示されます。
                <br> - AI の免責事項は、ユーザーにとって明確で理解しやすい言葉で記述されている</td>
            <td><b>組織内：</b>
                <br> - メールが主要なメッセージング形式である
                <br> -メッセージ種別に一貫したアプローチがない
                <br> -トーストメッセージでバリエーションが一貫して使用されていない
                <br> - <code>モード</code>が [<code>スティッキ]</code> に設定されたトーストメッセージが存在する
                <br> - 通知はその場限りで使用される
                <br> - 生成された応答では、使用されたデータソースが特定されない
                <br> -ボットはユーザーとの最初のやりとりの前に自分自身を明確に識別しない
                <br> -生成 AI リスクに関する免責事項がユーザーに表示されない
                <br> - AI の免責事項がユーザーにとって明確でわかりやすい表現になっていない</td>
        </tr>
        <tr>
            <td><b>アプリケーション内：</b>
                <br> -人間が関与していないエンドユーザーには生成応答が直接送信されない</td>
            <td><b>アプリケーション内：</b>
                 <br> -生成応答は、人の関与なしでエンドユーザーに直接送信される</td>
        </tr>
        <tr>
            <td colspan="2">関連トピック:<a href="https://staging.architect.salesforce.com/docs/architect/ja-jp/well-architected/easy/automated#error-handling">エラーハンドリング</a></td>
        </tr>
        <tr>
            <td rowspan="2"><b>アプリケーション内ガイダンス</b></td>
            <td><b>設計標準とドキュメントには次のものが含まれます。</b>
                <br> -アプリケーション内ガイダンスの承認済み使用事例
                <br> - プロンプトとウォークスルーのデザインパターン
                <br> -ユーザー、アプリケーション、有効なアプリケーション内ガイダンスの明確なマトリックス</td>
            <td>設計標準とドキュメントが存在する場合、次のことを行います。
                <br> - アプリケーション内ガイダンスに対処しない
                <br> -ユーザー、アプリケーション、有効なアプリケーション内ガイダンスを示す明確なマトリックスを含めない</td>
        </tr>
        <tr>
            <td><b>組織内：</b>
                <br> [アプリケーション内ガイダンス間の遅延] の設定で、Salesforce によって提供されるデフォルト (24 時間) 期間より<i>長い</i>デフォルト値またはカスタム値が使用されている
                <br> - 有効なウォークスルーが複数あるアプリケーションはありません。
                <br> - 10 より大きい [表示する時間] 設定のウォークスルーはありません。
                <br> - [任意のページ、任意のアプリケーション] または [このページ、任意のアプリケーション] でプロンプトが有効になっていない</td>
            <td><b>組織内：</b>
                <br> - [アプリケーション内ガイダンス間の遅延] の設定が、Salesforce が提供するデフォルト (24 時間) よりも短い期間に設定されている。
                <br> -アプリケーションに複数の有効なウォークスルーがある
                <br> - 多くのウォークスルーの [表示する時間] 設定が 10 より大きい (最大値が 30 のウォークスルーもある)
                <br> プロンプトはアドホックに有効化され、多くは [任意のページ、任意のアプリケーション] または [このページ、任意のアプリケーション] 設定になっています。
                </td>
        </tr>
        <tr>
            <td><b>評価と報奨</b></td>
            <td><b>組織内：</b>
                <br> -アプリケーションは組み込み分析を使用して、関連する目標の進行状況と生産性の統計をユーザーに表示します。
                <br> - パスのお祝いが有効になるのはユーザーの同意がある場合のみ
                <br> - 通知とメッセージングにはユーザー認識が含まれ、通知を受けるユーザーと通知をトリガーするユーザーの設定が反映されます。
            </td>
            <td><b>組織内：</b>
                <br> -目標の進行状況と生産性統計に関連する分析は、レポートまたはマネージャーダッシュボードでのみ使用できます。
                <br> -パスのお祝いがユーザーの同意を確認せずに有効になっている
                <br> - 通知とメッセージングにユーザー認識が含まれていない、またはユーザーの好みが反映されておらず、騒がしい、仕掛けがあると感じる
            </td>
        </tr>
    </tbody>
</table>

## エンゲージメントに関連するツール

<table class="tools-table"><tbody><tr><th>ツール</th><th>説明</th><th>合理化</th><th>役に立つ</th></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.lightning_page_getting_into_salesforce1.htm&type=5">Lightning アプリケーションページの有効化</a></td><td>ページの可用性、命名、表示、および配置を管理する</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://appexchange.salesforce.com/appxListingDetail?listingId=a0N30000004gHhLEAU">Adoption Dashboards</a></td><td>ログイン履歴、機能の採用、生産性の確認</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://www.lightningdesignsystem.com/components/alert/">アラート</a></td><td>セッションでアラートを保持し、ユーザーによる開始なしでアラートを表示する</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.apex_result_caching">Apex メソッドの結果のクライアント側キャッシュ</a></td><td>キャッシュされたクライアント側データを使用してパフォーマンスを評価する</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.dynamic_forms_overview.htm&type=5">動的フォーム</a></td><td>必須項目とページセクションのみをユーザーに表示</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.networks_insights_enable.htm&type=5">エンゲージメントインサイト</a></td><td>最近のユーザー活動を監視し、必要に応じてアクションを実行する</td><td class="check-col">X</td><td class="check-col">X </td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.customhelp_lexguid.htm&type=5">アプリケーション内ガイダンス </a></td><td>トレーニングとオンボーディングにプロンプトとウォークスルーを利用する</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.customhelp_lex_learning_intro.htm&type=5">学習パス</a></td><td>ユーザーの学習エクスペリエンスのパーソナライズ</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.lightning_app_builder_overview.htm&type=5">Lightning アプリケーションビルダー</a></td><td>コードなしでカスタムモバイルおよびLightningページを作成</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.data_ui_api">Lightning Data Service</a></td><td>コンポーネント間でのデータのキャッシュと共有</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.lightningdesignsystem.com/tools/validator/">VS Code の Lightning Design System 検証</a></td><td>SLDS ガイドラインに対するマークアップの検証</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.lightning_page_templates.htm&type=5">Lightning ページテンプレート</a></td><td>さまざまなフォーム要素用の Lightning ページの作成</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.fields_lookup_filters.htm&type=5">ルックアップ検索条件</a></td><td>参照関係、主従関係、階層関係の絞り込み値</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.admin_currency.htm&type=5">マルチ通貨の管理</a></td><td>トランザクションでのマルチ通貨の使用</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=livemessage_intro.htm&language=en_US&type=5">メッセージング</a></td><td>SMS、Facebook Messenger、WhatsApp メッセージの送信</td><td class="check-col"></td><td class="check-col">X </td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=s1_branded_apps.htm&language=en_US">Mobile Publisher</a></td><td>Lightning アプリケーションと Experience Cloud サイトのモバイルバージョンを作成する</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.mobile">モバイル対応コンポーネント</a></td><td>モバイル環境で適切に動作するコンポーネントの作成</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.siteforce_languages_overview.htm&type=5">マルチ言語サイト</a></td><td>異なる言語バージョンのサイトを作成する</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.notif_builder.htm&type=5">通知ビルダー</a></td><td>情報を表示するカスタム通知を作成する</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.path_overview.htm&type=5">パス</a></td><td>ビジネスプロセスを通じてユーザーをガイドし、成功を祝う</td><td class="check-col">X</td><td class="check-col">X </td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_cache_namespace_overview.htm">プラットフォームキャッシュ</a></td><td>データのキャッシュ時のパフォーマンスと信頼性の向上</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.lightning_app_builder_mobile_guidance.htm&type=5">Lightning アプリケーションビルダーでのモバイルアプリケーションページのプレビュー</a></td><td>モバイルデバイスでのレコードおよびアプリケーションページのプレビュー</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.lightningdesignsystem.com/components/prompt/">応答画面</a></td><td>システム関連の問題と更新をユーザーに通知</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=networks_recog_badges.htm&type=5&language=en_US">レコグニションバッジ</a></td><td>ユーザーの功績を認めて称賛する</td><td class="check-col"></td><td class="check-col">X </td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.workcom_overview.htm&type=5">WDC での認識</a></td><td>スキルを支持して感謝する</td><td class="check-col"></td><td class="check-col">X </td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=customize_recordtype.htm&type=5&language=en_US">レコードタイプ</a></td><td>ビジネスプロセス、選択リスト値、ページレイアウトのパーソナライズ</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=networks_reputation_overview.htm&type=5&language=en_US">評価の概要</a></td><td>参加とKnowledge共有の認識</td><td class="check-col"></td><td class="check-col">X </td></tr>
<tr><td><a href="https://help.salesforce.com/apex/HTViewHelpDoc?id=sf.security_restriction_rule.htm&language=en_US">制限ルール</a></td><td>不要なデータが含まれる可能性があるレコードにユーザーがアクセスできないようにする</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.lightning_page_components.htm&type=5">標準ページコンポーネント</a></td><td>標準のSalesforce Lightningコンポーネントについて</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=workbench_overview.htm&type=5&language=en_US">翻訳</a></td><td>グローバルユーザーの翻訳の管理</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.fields_about_field_validation.htm&type=5">入力規則</a></td><td>保存前にデータが指定された標準を満たしていることを確認する</td><td class="check-col">X</td><td class="check-col"></td></tr>
</table>

## エンゲージメントに関連するリソース

<table class="tools-table"><tbody><tr><th>リソース</th><th>説明</th><th>合理化</th><th>役に立つ</th></tr>
<tr><td><a href="/docs/architect/ja-jp/decision-guides/guide/build-forms">Architect｀s Guide to Building Forms (フォームを作成するためのアーキテクトガイド)</a></td><td>フォーム設計の考慮事項を評価し、最適なツールを選択する</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/component-library/documentation/en/lwc/use_config_form_factors">さまざまなフォーム要素に対するコンポーネントの設定</a></td><td>デスクトップおよび携帯電話で表示するコンポーネントを設定する</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=customhelp_about.htm&type=5&language=en_US">ヘルプコンテンツのカスタマイズ</a></td><td>独自の実装に合わせたヘルプコンテンツの調整 </td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.fields_defining_default_values.htm&type=5">デフォルト項目値</a></td><td>デフォルト、動的、または静的項目値の定義</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.lightningdesignsystem.com/guidelines/overview/">設計ガイドライン</a></td><td>ベストプラクティスに沿ったユーザーインターフェースの作成</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="/docs/architect/ja-jp/resources/guide/design-standards-template">設計標準テンプレート</a></td><td>組織の設計標準を作成する</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/ux-designer-certification-prep/refresh-your-design-testing-skills">テストスキルの設計 (Trailhead)</a></td><td>設計の検証およびテスト方法の計画</td><td class="check-col">X</td><td class="check-col">X </td></tr>
<tr><td><a href="https://www.lightningdesignsystem.com/guidelines/in-app-feedback/overview/">アプリケーション内フィードバックのガイドライン</a></td><td>システム内からフィードバックを収集するためのガイドラインを確認する</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://github.com/salesforce-ux/design-system-android">Lightning Design System Android 静的ライブラリ</a></td><td>Lightning ページのデザインを使用したネイティブ Android アプリケーションの構築</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://github.com/salesforce-ux/design-system-ios">Lightning Design System iOS 静的ライブラリ</a></td><td>Lightningページのデザインを使用したネイティブiOSアプリケーションの構築</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.lightningdesignsystem.com/guidelines/messaging/overview/">メッセージングガイドライン</a></td><td>関連情報を伝え、喜びの瞬間を作り出す</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://www.lightningdesignsystem.com/guidelines/messaging/types/">メッセージング種別</a></td><td>ユーザー操作に基づいてさまざまなメッセージング種別を理解する</td><td class="check-col"></td><td class="check-col">X </td></tr>
<tr><td><a href="https://www.lightningdesignsystem.com/guidelines/navigation/">ナビゲーションガイドライン</a></td><td>ユーザーがページ間を移動し、アプリケーション内で状況把握できるようにする</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/testing-for-web-accessibility">Web アクセシビリティのテスト (Trailhead)</a></td><td>自動テストと手動テストを使用してアクセシビリティを確保</td><td class="check-col">X</td><td class="check-col">X </td></tr>
<tr><td><a href="https://www.lightningdesignsystem.com/guidelines/user-engagement/overview/">ユーザーエンゲージメントガイドライン</a></td><td>オンボーディング、採用、支援、学習に関するガイドラインを確認する</td><td class="check-col">X</td><td class="check-col">X</td></tr>
</table>

## ご意見をお聞かせください

Salesforce Well-Architected の関連性の維持にご協力ください。このコンテンツに関するフィードバックをいただくため[のアンケート](https://sfdc.co/bxNtvh)にご協力ください。また、今後の展望についてもお聞かせください。

<!-- document id=c4a9da632256bca4c0dc14f67ef539968e97036754c8e5556ae4a8b6b4782587 url=/architect/next/ja-jp/well-architected/guides/contributors.md -->

## はじめに

Salesforce Well-Architected は、Salesforce 全体およびエコシステム全体のエキスパートによるガイダンスとベストプラクティスを表します。well-archited にリソースと Knowledge を寄稿したすべてのユーザーに感謝します。

適切に設計されたドキュメントは年に 2 回更新されます。次回のメンテナンス期間中に Well-Architected への貢献方法を発表します。

Well-Architected に関するフィードバックは[ここ](https://sfdc.co/bxNtvh)からいつでも提供できます。

## ご意見をお聞かせください

Salesforce Well-Architected の関連性の維持にご協力ください。このコンテンツに関するフィードバックをいただくため[のアンケート](https://sfdc.co/bxNtvh)にご協力ください。また、今後の展望についてもお聞かせください。

<!---
## October 2025 Release

> Thank you to all our contributors who helped with the revision of the whitepaper.

<table border="0">
    <tr>
        <td>
        A A<br />
        A B<br />
        A C<br />
        A D<br />
        A E<br />
        A F<br />
        </td>
        <td>
        A A<br />
        A B<br />
        A C<br />
        A D<br />
        A E<br />
        A F<br />
        </td>
        <td>
        A A<br />
        A B<br />
        A C<br />
        A D<br />
        A E<br />
        A F<br />
        </td>
        <td>
        A A<br />
        A B<br />
        A C<br />
        A D<br />
        A E<br />
        A F<br />
        </td>
    </tr>
</table>
--->
<!---
## July 2024 Release

> Thank you to our contributors who helped with our initial release of patterns & anti-patterns for Data 360 and Einstien.

<table border="0">
    <tr>
        <td>
        Ahmed Keshk<br />
        Andres Perez<br />
        Arturo Alvarado<br />
        Arvind Raman<br />
        Bret Brizzee<br />
        CJ Buskey<br />
        </td>
        <td>
        Gina Nichols<br />
        Jim Stukas<br />
        John Kucera<br />
        Jordan Seeley<br />
        Justin Piehowski<br />
        Marc Braga<br />
        </td>
        <td>
        Marissa Chesney<br />
        Matt Dykeman<br />
        Michael DePuy<br />
        Moustafa Ishak Kamal Moustafa<br />
        Muralidhar Krishnaprasad<br />
        Patrick Hermiller<br />
        </td>
        <td>
        Scott Robbins<br />
        Shoby Abdi<br />
        Stella Hang<br />
        Susannah Plaisted<br />
        Tom Leddy<br />
        Zayne Turner<br />
        </td>
    </tr>
</table>
--->

<!-- document id=78914def4498d530d4707111e4382d23364a230548b607fbe83e5557dd21b4f2 url=/architect/next/ja-jp/well-architected/guides/intentional.md -->

> 更新スケジュールについては、[こちら](/docs/architect/ja-jp/well-architected/guide/contributors)を参照してください。

## はじめに

インテントソリューションは、ビジネス価値を即座に経時的に提供します。インテントアーキテクチャは戦略的に計画され、効果的に管理でき、人間にとって読みやすく、理解しやすいものです。

機能と修正には優先順位が付けられ、ビジネス関係者とテクノロジー関係者の両方に透過的な方法で提供されます。エンジニアリングの選択肢により、デリバリチームやメンテナンスチームが簡単に作業できる実装が作成されます。追加機能や複雑さはありません。インテントアーキテクチャは、明確で一貫した実装パターンに従うため、ビジネスに合わせて所有、維持、進化しやすくなります。ビルダーは新機能の設計を解釈して実装でき、メンテナンスチームは実装された内容をドキュメントで理解できます。

戦略、メンテナンス性、可読性の 3 つの主要な領域に焦点を当てることで、より意図的なシステムを作成できます。

## 戦略

アーキテクチャの戦略とは、システムが綿密に計画され、提供されることを意味します。つまり、配送チームとメンテナンスチームは現在および将来に行う作業を明確に把握し、全員が作業の「理由」について意思統一を図ります。つまり、緊急の要求に効果的かつ効率的に優先順位を付けることができ、関係者は要求の影響とトレードオフを明確に理解できます。

優先順位付け、ロードマップ、ガバナンスに重点を置くことで、アーキテクチャに明確な戦略を組み込むことができます。

### 優先順位付け

優先順位付けとは、提供する作業の順序と範囲を計画することです。優先度付けには、成果物がビジネスに及ぼす真の影響を把握し、他の作業要求や製品またはプログラムの全体的なロードマップに対してそれらの影響を評価します。

特定の作業項目の影響を評価する 1 つの方法は、実際のコストやビジネス上のメリットを確認することです。自動化の[KPI](/docs/architect/ja-jp/well-architected/guide/automated#kpi)を特定したら、[ビジネス インパクト計算ワークシート](/docs/architect/ja-jp/resources/guide/kpi-spreadsheet-template)を使用して実装の全体的なコストまたはメリットを評価できます。これらの計算は、どの自動化をどのような順序で作成するかについて関係者の意見をまとめるのに役立ちます。また、延期または回避する自動化を特定するのにも役立ちます。自動化の場合、効果的な作業の特定についての詳細は、「[プロセス設計](/docs/architect/ja-jp/well-architected/guide/automated#プロセス設計)」を参照してください。

また、配信の優先順位付けフレームワークを確立すると、ユーザーとメンテナンスチームがユーザーの期待を管理し、ロードマップに沿って進めることができます。

優先度付けに使用できる考慮事項を次に示します。

- 成果物のビジネスへの影響 (コスト/利益)
- 成果物に必要な新規作業量
- 成果物を維持するために必要な作業量

以下の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/intentional#戦略パターンとアンチパターン)のリストは、Salesforce 作業における適切な (および不適切な) 優先順位付けを示しています。これらを使用して実装計画を検証したり、構築する前に優先度をより適切に特定する必要がある場所を特定したりできます。

優先度付けに役立つ Salesforce のツールについての詳細は、「[Tools Relevant to Intentional](/docs/architect/ja-jp/well-architected/guide/intentional#インテンショナルに関連するツール) (インテントに関連するツール)」を参照してください。

### ロードマップ

ロードマップとは、優先順位が付けられ、検証済みで、明確に定義された、実行すべき作業のビューです。効果的なロードマップにより、今後の作業のビジネスへの影響とテクノロジーへの影響を明確に把握できます。ビジネス関係者と技術関係者とのエンゲージメントは、ロードマップの重要な部分です。ロードマップを使用すると、作業を開始する前にアプローチと結果に関するフィードバックや賛同を得ることができます。最終的に、ロードマップは、今後の作業の「理由」についてすべての関係者と一致させます。

チームがバックログを使用している場合、ロードマップはバックログの項目の要約やリストではないと理解することが重要です。リレーションはその逆です。項目は、ロードマップの成果物に明確かつ確実に関連付けることができる場合にのみバックログに入ります。関係者のエンゲージメントに基づいて作成された高品質のロードマップにより、デリバリチームとメンテナンスチームは、何に焦点を絞るべきか、どのように要請に優先度を付けるべきかを明確に把握できるため、競合する要請を整理して関係者の期待を管理しやすくなります。

ロードマップが不十分または存在しない場合、次のようになります。

- 新機能のリリース時期が明確でない
- 関係者間で優先度が競合する
- 提供されるソリューションと組織全体のビジョンの乖離
- 進行中の作業を理解しにくい
- チーム全体の作業負荷の不均衡
- 作業項目間のリレーションと連動関係が認識されていない
- 不適切な連動関係による実装の停止

多くの場合、意思決定を行うためには、各自の役割に合った情報が必要です。効果的なロードマップを作成するには、利用者と必要な情報の種類を明確に理解する必要があります。ロードマップは、ビジネス利用者と技術利用者をサポートする 2 つのスタイルに分類されます。各スタイルには、異なる種別の情報をサポートする 2 つのレベルの粒度が含まれます。

ビジネスロードマップは、関係者が組織の変更を計画し、成長機会を活用し、企業目標を常に把握するのに役立ちます。ビジネスロードマップは、IT 支出を全体的なビジネスビジョンに合わせる方法も提供します。

- ビジネス機能ロードマップを作成して、有効化される機能をエグゼクティブ関係者に表示します。このタイプのロードマップには、機能自体と、業務効率の向上や新しい製品ラインの立ち上げなど、ビジネス目標に合わせた機能の概要が含まれます。
- リソース計画、予算編成、変更管理でビジネス関係者をサポートする必要がある場合、ビジネス機能ロードマップを作成して特定の機能にドリルダウンし、そのサポート機能を示します。

テクノロジーロードマップは、予算とリソース割り当ての計画で技術関係者を支援します。また、実装チームは、プロジェクトの全体像のどこにプロジェクトが適合するかを理解し、チーム間の連動関係を特定できます。

- 実装する特定のシステムとシステムレベルの連動関係を示すテクノロジーシステムロードマップを作成します。この種類のロードマップでは、概要レベルのシステム情報と、システムとビジネス機能間の連携が示されます。
- リソース計画とイネーブルメントの要件に役立つ、リリースされるシステムの特定のコンポーネントにドリルダウンするテクノロジーコンポーネントロードマップを作成します。この種類のロードマップには、コンポーネントレベルの情報と実装要件 (宣言型開発やプロコードなど) が示されます。

ロードマップに現実的なスケジュールが含まれていることを確認します。よくある間違いは、システムの実装に要する時間のみを含め、関連活動の完了に要する時間は考慮しないことです。これにより、実装チームメンバーの過剰な割り当てや、予想以上の遅延が発生する可能性があります。ロードマップを作成するときは、次の作業にかかる時間を考慮してください。

- すべての新機能と更新された機能のドキュメント
- 新機能をサポートするために必要な既存の機能のメンテナンス
- インテグレーションをサポートするために必要な関連システムの更新
- 稼働開始直後にプロジェクトチームからサポートが向上
- テスト、トレーニング、変更管理

適切に連携したビジネスロードマップとテクノロジーロードマップでは、機能のリリース時期とその背後にあるテクノロジーに関する総合的なビューが伝達されます。次の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/intentional#戦略パターンとアンチパターン)のリストは、Salesforce 組織にとって適切な (および不適切な) ロードマップを示しています。これらを使用して、ロードマップ戦略を検証または改善できます。

ロードマップに役立つ Salesforce ツールについての詳細は、「[Tools Relevant to Intentional](/docs/architect/ja-jp/well-architected/guide/intentional#インテンショナルに関連するツール) (インテントに関連するツール)」を参照してください。

### ガバナンス

ガバナンスは、関係者との優先順位付け、意思決定、変更管理を処理するために使用される構造です。ガバナンスにより、意思決定とコミュニケーションの方法が明確になります。フィードバックや要請を意思決定プロセスに取り込み、すべての関係者がメンテナンスや開発作業の状況を把握するための一貫した方法を提供します。ガバナンスにより、リリース管理プロセスが明確で一貫性のあるものになり、すべてのチームメンバーが各自の役割と責任を理解できるようになります。

適切なガバナンスがない場合、チームは次のようなさまざまな問題を経験します。

- 重複する機能の要求がアドホックに届いた
- 実装チームは、ビジネス上の価値、トレードオフ、組織全体の目標を適切に考慮せずに、より影響力のある関係者からの「より容易な」取り組みや要求を優先する
- 一貫した承認およびレビュープロセスの欠如
- リリースケイデンスと品質の一貫性がない
- 開発作業における高い不具合率、上書き、競合、重複作業

システムに効果的なガバナンスがないことを示す最も明確な兆候は、リリースが遅く、煩雑であることかもしれません。ガバナンスシステムの規模は有効性の基準ではないことを認識しておくことが重要です。実際、(多くの大企業で採用されているような) ガバナンスのための精巧なシステムによって、リリースの速度と頻度が抑制される可能性があります。

優れたガバナンスとは、悪いカスタマイズが開発の初期段階を通り越しやすくし、良いカスタマイズを予測可能かつ一貫して本番に取り込むことです。

多くの場合、ガバナンスの取り組みは反応的です。技術的な債務超過などの問題がビジネスで問題になり始めたときに開始または二重化されます。多くの場合、企業は、開発者ツールチェーンとソース制御システム内で効果的な[設計標準](/docs/architect/ja-jp/resources/guide/design-standards-template)を作成し、その標準を適用する自動化を構築する代わりに、開発作業とリリースを「封鎖」します。

Salesforce ガバナンスシステムのフレームワークを構築するときは、次の要素を含めて、次の主要な質問に答えてください。

- **作業要求。**ユーザーが機能や特長を尋ねる方法は?バグの報告方法は?
- **優先順位付けと作業計画。**誰が重要な作業要求を決定しますか?作業の範囲設定、優先度設定、受け入れまたはサインオフは?
- **環境とリリース計画。**開発、テスト、リリースの環境パイプラインは?誰が何をプロビジョニング、更新、アクセス権を付与しますか?リリースと検証は誰が行いますか?変更のリリース方法とタイミングは?Salesforce リリースサイクル中のリリースまたは環境をどのように処理しますか?(詳細は、「[アプリケーションライフサイクル管理](/docs/architect/ja-jp/well-architected/guide/resilient#アプリケーションライフサイクル管理)」を参照してください)。
- **サービス所有権と本番サポート。**Who supports what? (誰が何をサポートするか)「ホットフィックス」本番の問題を処理するのは誰ですか?これらの項目は、どのようにテストおよびリリースされますか?組織の全体的なセキュリティ基準の責任者は誰ですか?

次の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/intentional#戦略パターンとアンチパターン)のリストは、Salesforce 組織での適切な (および不十分な) ガバナンスを示しています。これらを使用して、ガバナンス戦略を検証または改善できます。

ガバナンスに使用できる Salesforce ツールについての詳細は、「[Tools Relevant to Intentional](/docs/architect/ja-jp/well-architected/guide/intentional#インテンショナルに関連するツール) (インテントに関連するツール)」を参照してください。

### 戦略パターンとアンチパターン

次の表に、組織で検索 (または作成) するパターンと、回避または修正の対象となるアンチパターンの選択を示します。

✨ [パターン & アンチパターンエクスプローラー](/docs/architect/ja-jp/well-architected-tools/guide/easy-strategy)で、戦略のパターンをさらに確認できます。

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">パターン</th>
            <th scope="colgroup">アンチパターン</th>
        </tr>
        <tr>
            <td rowspan="2"><b>優先順位付け</b></td>
            <td><b>ドキュメント内：</b>
            <br> - すべての新しい作業項目に明確なビジネス価値評価指標がある (収益の増加、プロセスの最適化によるコスト削減など)
            <br> - ロードマップには、ビジネス価値に基づいて作業の優先度が示されます。</td>
            <td><b>ドキュメント内：</b>
            <br> - 作業に関連するビジネス価値が明確でない、または存在しない
            <br> - ロードマップが存在しない</td>
        </tr>
        <tr>
            <td><b>社内：</b>
            <br> - すべての作業項目で実装コストとメンテナンスコストが特定されている
            <br> - 機能の要求は、ビジネスへの影響、提供に必要な新しい作業の量、メンテナンスに必要な作業の量に基づいて優先順位が付けられます。</td>
            <td><b>社内：</b>
            <br> - 機能の実装および管理に関連するコストが明確でない
            <br> - 要求はアドホックまたは先入れ先出し方式で提供されます。</td>
        </tr>
        <tr>
            <td rowspan="2"><b>ロード</b>マッピング</td>
            <td><b>ロードマップ:</b>
            <br> - 利用者 (ビジネスまたは技術) に合わせて調整された情報を伝える
            <br> - 正しい詳細レベルで情報を伝える
            <br> - 開始日と終了日を表示
            <br> - 前提条件と連動関係を表示</td>
            <td><b>ロードマップ (存在する場合):</b>
            <br> - 成果物としてではなく、プロジェクトのキックオフ資料として使用される
            <br> - 関係者とデリバリチームの連携をサポートしていない
            <br> - 複数の詳細レベル (同じロードマップにシステムとコンポーネントを含めるなど)
            <br> - 利用者に合わせて調整されていない情報 (同じロードマップ内のビジネス機能やシステムなど) が含まれている</td>
        </tr>
        <tr>
            <td><b>ビジネス内：</b>
            <br> - 関係者が作業項目の「理由」を理解する
            <br> - 配送チームは、長期的な優先度に対してバックログ項目を評価する方法を知っている
            <br> -チームは誰が何をしていて、どのように連動関係を管理するかを把握する
            <br> -優先度をすぐに変更する必要がある場合でも、作業は意図的です。</td>
            <td><b>ビジネス内：</b>
            <br> -バックログにあるものから作業を取得し、明確な「理由」がない
            <br> - チームは相互に依存する作業の調整に苦労し、多くの場合、気づかないうちに作業の複製を行っている
            <br> - 作業は反応型が多い
            <br> - 関係者は、現状にストレスや困惑を感じることが多く、新しい機能がいつ提供されるかわからない</td>
        </tr>
        <tr>
            <td><b>ガバナンス</b></td>
            <td><b>ビジネス内：</b>
            <br> -ユーザーはバグの報告や機能の要求を簡単に行うことができます。
            <br> - 作業項目の優先順位付けプロセスが文書化され、すべての関係者に公開されます。
            <br> 環境戦略が明確に文書化され、開発環境がドキュメントと一致している
            <br> -リリース計画は予測可能で、すべてのデリバリチームメンバーに対して透過的
            <br> -チームメンバーは、アプリケーションライフサイクル全体で誰が何を担当するかを知っている
            <br> - リリースがユーザーと配信/メンテナンスチームにとって明確である
            <br> - 本番サポートプロセスが明確で、ホットフィックスが本番に移行するパスが明確である
            <br> - チームとプロジェクトでは、ビジネス用途で承認された AI モデルのみが使用されます。</td>
            <td><b>ビジネス内：</b>
            <br> - バグレポートと機能要求はアドホック
            <br> - 作業項目に明確な優先順位がない
            <br> - 環境はその場しのぎでプロビジョニングされ、予測どおりに更新されないことがあります。多くの場合、開発者は必要な環境とアクセス権を持っていません。
            <br> - リリースは配送チームとユーザーにとって予測できない
            <br> -チームは誰が何に責任を持っているかわからない
            <br> - ホットフィックスはアドホックに対応
            <br> -バックログが「アイデアバンク」となり、古くなり停滞している
            <br> -ガバナンス機関がサポート要請のトラブルシューティングを行うヘルプデスクとして機能する
            <br> -ドキュメントに簡単にアクセスできない
            <br> - チームがアドホックで AI モデルを選択</td>
        </tr>
    </tbody>
</table>

## メンテナンス性

メンテナンス性とは、予測可能な定期的なシステムへの新機能の追加や技術的な負債のシステム外への移動によって、システムを健全な状態に保つことができることを意味します。メンテナンス可能なシステムにより、チームは予測可能なスピードと品質でビジネスに価値を提供できます。システムの保守性は、可読性、疎結合性、テスト戦略の綿密さなど、いくつかの要素によって決まります。

最も重要なことは、システムの保守性は、その設計の単純さに左右されます。このセクションでは、より簡単なソリューション設計を作成し、メンテナンス性を高める方法について説明します。

カスタム機能よりも標準機能を使用することと、技術的な負債を処理することの 2 つの主要な点に焦点を絞ることで、メンテナンスしやすいソリューションを構築できます。

### 標準機能とカスタム機能

Salesforce には、Sales Cloud、Service Cloud、および多くの Salesforce 業種ソリューションを含むさまざまな事前作成済みソリューションと、独自のカスタムソリューションを作成する柔軟性があります。Salesforce 独自のクラウドソリューションを強化する基本サービスは、Salesforce Customer 360 Platform 上に構築されたすべてのカスタムソリューションでも使用できます。Salesforce の事前作成済みサービスとソリューションをできるだけ多くのソリューションの信頼できる基盤として使用します。

事前作成済みプラットフォームサービスには、2 つの異なる利点があります。まず、アプリケーションはリリースのたびに最新の Salesforce のイノベーションから自然にメリットを得られます。2 つ目は、開発チームが基本的なアーキテクチャの面倒な作業ではなく、Salesforce ソリューションによって提供されるビジネス機能の拡張と深化に集中できることです。

標準機能を使用するタイミングとカスタム機能を作成するタイミングを適切に選択することは、アーキテクチャの観点から困難ではありません。キーは次のとおりです。

- **プラットフォームのカスタマイズとは、コピーではなく、変更と拡張を意味します。**アーキテクチャを設計または評価するときには、次の点について質問する必要があります。これはすでに Salesforce プラットフォームのどこかに存在しますか?回答が「_Yes, but_...\[ビジネスの関係者が求める変更をここに挿入してください...]」の場合、プラットフォームで事前作成済み機能を使用します。実行するアーキテクチャ作業では、ビジネスの期待を満たすために事前作成済み Salesforce 機能を設定する最も便利な方法を特定します。
- **カスタマイズなし**。時間の経過と共に、すべての変更は結果をもたらします。カスタムソリューションを実装する必要がある場合は、可能な限りローコードテクノロジーを使用し、実装で[構成可能なユニット](/docs/architect/ja-jp/well-architected/guide/composable)を作成することで、システムに蓄積される避けられない[技術的負債](/docs/architect/ja-jp/well-architected/guide/intentional#技術的負債)を軽減できます。
- build-buy **スペクトルを考慮**します。[Salesforce AppExchange](https://appexchange.salesforce.com/)は、Salesforce を拡張するアプリケーションとソリューションのマーケットプレイスです。AppExchange アプリケーションでは、カスタムソリューションの構築と管理に伴うオーバーヘッドなしで機能を提供できます。AppExchange ソリューションを評価するときは、次の点を考慮してください。
  - ソリューションの特徴とギャップを特定します。理想的なのは、すべてのビジネス要件を満たすアプリケーションを見つけることです。実際には、完璧な適合が見つからない場合があります。ソリューションを評価するときに、潜在的なソリューションの機能をビジネス要件の優先リストに対応付けます。これにより、最も重要な要件に最も適したソリューションを見つけることができます。
  - Sandbox と無料トライアルを使用します。無料トライアル期間を使用して Sandbox 環境でアプリケーションを評価し、最適なアプリケーションを特定します。アプリケーションで既存の設定と競合する設定変更が必要かどうかを判断します。
  - 短期コストと長期コストを考慮します。サブスクリプションベースのアプリケーションの定期的なコストに対して、長期的なアプリケーションメンテナンスの節約を評価します。ビジネス関係者が決して使用しない多くの機能に対して定期的なコストを支払う必要があるシナリオを回避します。
- **Salesforce の事前作成済みデータモデルを使用します。**Salesforce では、営業、サービス、さまざまな業種向けに事前作成済みデータモデルを提供しています。Salesforce が提供するデータモデルを使用することで、システムの機能が 1 回のみ定義され (冗長性とサイロ化を排除)、システム全体にわたる一元化された情報源が確立され、分析によるアプリケーションデータの理解が容易になり、Salesforce の事前作成済み人工知能サービスが使いやすくなり、メンテナンスコストが削減され (サポートする必要があるカスタマイズが減るため)、技術的負債が軽減されます。

単純なことです次の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/intentional#メンテナンス性パターンとアンチパターン)からわかるように、アンチパターンは、カスタムソリューションで標準機能を複製するか、より複雑なテクノロジーを使用してカスタマイズを行うかに集約されます。

実際には、カスタム機能のアンチパターンがビジネス関係者から最善または唯一の実現可能な方法とみなされる場合があります。このような場合は、このパスを選択する際のトレードオフを関係者に説明し、決定、その根拠、実装を徹底的に文書化することが重要です。これは、コアバリューを早期に提供し、経時的に対応することで、関係者が最善の方法を理解するのに役立つ領域でもあります。

メンテナンス性の向上に役立つ Salesforce ツールについての詳細は、「[Tools Relevant to Intentional](/docs/architect/ja-jp/well-architected/guide/intentional#インテンショナルに関連するツール) (インテントに関連するツール)」を参照してください。

### 技術的負債

技術的負債は、どのシステムにも当然含まれます。昨日のサウンドデザインは、テクノロジーやビジネスニーズが変化するとアンチパターンになる可能性があります。Salesforce Platform 機能のギャップを埋めるために構築されたものが、Salesforce の新しいリリースや製品の発売で突然冗長になることがあります。すでに実装したテクノロジーよりも、よりパフォーマンスの高いテクノロジーや柔軟なテクノロジーの方が優先される可能性があります。技術的負債はさまざまな方法で作成できます。

Salesforce Customer 360 Platform を使用してアプリケーションを構築する主なメリットは、[下位互換性](/docs/architect/ja-jp/fundamentals/guide/architecture-basics#プラットフォーム-api)が組み込まれていることです。つまり、新しいプラットフォームの革新により、今後ソリューションで使用するパターンが変わる可能性がありますが、以前の Salesforce テクノロジーに基づいて構築したソリューションの日常業務は引き続き機能します。時間が経つにつれて、古いテクノロジーに基づくソリューションでは、アプリケーションに新機能を追加するリスクやボトルネックが発生し始め、ソリューション全体の健全性が低下します。

Salesforce ソリューションで健全でわかりやすい設計を維持するためには、技術的負債に対処するための定期的な作業を計画して実行することが不可欠です。技術的負債の計画、監査、修正を怠ることは、適切に設計されていないシステムを作成する確実な方法です。

技術的な負債を最小限に抑える 1 つの方法は、ショートカットを避け、カスタム機能よりも[標準機能](/docs/architect/ja-jp/well-architected/guide/intentional#標準機能とカスタム機能)を選択することで、できるだけ導入しないようにすることです。ハードコード値などのショートカットは、時間を節約したいと思うかもしれませんが、長期的には返済する必要のある負債を生み出します。

アーキテクチャの観点から技術的負債に対処する鍵は次のとおりです。

- アクションとアクションのないビジネスに対する実際の[コストまたは利益](/docs/architect/ja-jp/resources/guide/kpi-spreadsheet-template)の特定
- 適切[なロード](/docs/architect/ja-jp/well-architected/guide/intentional#ロードマップ)マッピング
- [構成可能なソリューション](/docs/architect/ja-jp/well-architected/guide/composable)の構築

難しいのは、関係者がアクションを実行するタイミングを合わせることです。一部の関係者は、継続的なメンテナンスを「昨日の過ち」に対処したり、予算でサポートする必要がある機能を取り除いたりしていると感じるかもしれません。

アクションとアクションなしの実際のビジネスへの影響を、明確に定義された成果物とタイムラインと共に示すことで、関係者は技術的負債に対処する価値と相対的な優先度を理解することができます。技術的な負債をビジネスへの影響に結び付ける作業を一貫して行うことは、関係者が作業内容をより深く理解することに役立つだけではありません。また、ユーザーが真にメリットを得られる方法で技術的負債を特定して対処するのに役立ちます。

次の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/intentional#メンテナンス性パターンとアンチパターン)のリストは、Salesforce 組織での適切な (および不十分な) 技術的債務管理を示しています。

技術的負債に役立つ Salesforce ツールについての詳細は、「[Tools Relevant to Intentional](/docs/architect/ja-jp/well-architected/guide/intentional#インテンショナルに関連するツール) (インテントに関連するツール)」を参照してください。

### メンテナンス性パターンとアンチパターン

次の表に、組織で検索 (または作成) するパターンと、回避または修正の対象となるアンチパターンの選択を示します。

✨ [パターン & アンチパターンエクスプローラー](/docs/architect/ja-jp/well-architected-tools/guide/easy-maintainability)で、メンテナンス性を向上するパターンを見つけます。

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">パターン</th>
            <th scope="colgroup">アンチパターン</th>
        </tr>
        <tr>
            <td rowspan="5"><b>標準とカスタム</b></td>
            <td><b>設計基準では、次のようになります。</b>
            <br> -ソリューションが不要なカスタマイズにならないようにするための明確な指針がある
            <br> - ソリューションの指針では、次の優先度が使用されます。1.組み込みプラットフォームサービスの使用、2.カスタムソリューションを構築する前に AppExchange アプリケーションを考慮する 3.コードを記述する前にローコードのカスタマイズを使用する</td>
            <td><b>設計基準では、次のようになります。</b>
            <br> - 設計標準が存在しないか、不要なカスタマイズやコードを回避するための明確な根拠がない</td>
        </tr>
        <tr>
            <td><b>ドキュメント:</b>
            <br> - ソリューションを構築するか購入するかを選択するときに、決定レコードに短期および長期コストの計算が表示される</td>
            <td><b>ドキュメント:</b>
            <br> - ソリューションの構築または購入を選択するときに、意思決定レコードで短期コストと長期コストの両方が考慮されない</td>
        </tr>
        <tr>
            <td><b>データモデルの場合:</b>
            <br> - 標準オブジェクトと重複する名前または機能を持つオブジェクトがない
            <br> - 標準オブジェクトは、その意図する範囲から遥かに逸脱した目的では使用されません。</td>
            <td><b>データモデルの場合:</b>
            <br> - オブジェクトが標準オブジェクトの名前や機能を重複する
            <br> - 標準オブジェクトが意図する範囲外の目的で使用されている</td>
        </tr>
        <tr>
            <td><b>LWC、Aura、または Visualforce の場合:</b>
            <br> - 標準ページビューメカニズムを上書きするコードが存在しない</td>
            <td><b>LWC、Aura、または Visualforce の場合:</b>
            <br> - 標準のページビューメカニズムを上書きするコードが存在する (多くの場合、単一ページアプリケーションの形式)</td>
        </tr>
        <tr>
            <td><b>LWC、Aura、または Apex の場合:</b>
            <br> - プラットフォームの実行順序を上書きまたは回避しようとするコードがない</td>
            <td><b>LWC、Aura、または Apex の場合:</b>
            <br> - プラットフォームの実行順序を上書きまたは回避するコード試行</td>
        </tr>
        <tr>
            <td rowspan="3"><b>技術的負債</b></td>
            <td><b>ロードマップ：</b>
            <br> - 技術的な負債に対処する作業が計画されている
            <br> - 成果物と開始日/終了日が明確である</td>
            <td><b>ロードマップ：</b>
            <br> -技術的な負債に対処する作業が計画されていない
            <br> - 成果物があいまいで、開始日/終了日が明確でない</td>
        </tr>
        <tr>
            <td><b>決定レコード：</b>
            <br> - テクノロジー導入前/導入後の債務修復の KPI が明確に文書化されている
            <br> - アクションとアクションのトレードオフに関するディスカッションでビジネスのコストまたは利益に焦点を絞る</td>
            <td><b>決定レコード：</b>
            <br> - テクノロジー債務の修復には測定可能な KPI がない
            <br> - 技術的な負債は、ビジネスとの関連性はなく、技術的な観点またはITに焦点を絞った観点で考慮されます。</td>
        </tr>
        <tr>
            <td><b>組織内：</b>
            <br> - 次のようなサポート対象外のテクノロジーや従来のテクノロジーは有効ではありません。
            <br> -- すべてのユーザーが Lightning Experience で作業
            <br> -- Apex で <code>@future</code> が使用されていない、またはほとんど使用されていない (Queueable が使用されている)
            <br> -- すべてのサードパーティ Apex は AppExchange パッケージに属する
            <br> -- 有効なワークフロールールなし (フローを使用)
            <br> -- 有効なプロセスビルダープロセスなし (フローを使用)
            <br> -- PushTopic イベント (変更データキャプチャを使用)
            <br> -- 一般的なイベント (プラットフォームイベントが使用されます)
            <br> -- 30.0 より前の API バージョン
            <br> -- Salesforce 組織の接続で Salesforce Connect の組織間アダプタを使用</td>
            <td><b>組織内：</b>
            <br> サポートされないテクノロジーまたは従来のテクノロジーが有効:
            <br> -- Salesforce Classic で作業するユーザー
            <br> -- Apex での <code>@future</code> の利用状況
            <br> -- AppExchange 以外のソースからのサードパーティ Apex
            <br> -- ワークフロールール
            <br> -- プロセスビルダープロセス
            <br> -- PushTopic イベント
            <br> -- 一般的なイベント
            <br> -- 30.0 より前の API バージョン
            <br> -- Salesforce から Salesforce への接続</td>
        </tr>
    </tbody>
</table>

## 読みやすさ

*可読性*の概念の中核は、ユーザーが物事の仕組みを容易に理解できるように一貫性を確保することです。読みやすいシステムを構築することで、配送チームとメンテナンスチームが連携し、システムに不慣れなユーザーでもピースがどのように組み合わされるかをすばやく理解できます。つまり、チームは、制度的または歴史的な Knowledge を持つ個人に依存しなくても、ベンダーや新しいチーム メンバーを効果的にオンボーディングできます。つまり、システムの構成とコードは人間にとって読みやすく、理解しやすいため、チームの熟練した個人は選択肢の質とトレードオフに集中できます。読みやすさにより、ガバナンスと品質保証のプロセスがスピードアップし、チームが冗長なカスタマイズを作成する可能性があるタイミングをより適切に特定できます。また、再利用可能でテスト可能な方法で動作するシステムの可能性を高めることもできます。

効果的な設計基準とドキュメントを使用して、読みやすさを高めることができます。

### 設計標準

[設計標準](/docs/architect/ja-jp/resources/guide/design-standards-template)では、開発の初期段階でも、すべてのカスタマイズの一貫性を保つための指針が提供されます。設計標準はガードレールのように機能し、システムで作業するすべてのデリバリチームとメンテナンスチームが、カスタマイズのアプローチと実装方法を常に一致させます。設計標準を定義すると、デリバリチームとメンテナンスチームの生産性が向上し、コードとアーキテクチャのレビューが容易になり、より適切な[ドキュメント](/docs/architect/ja-jp/well-architected/guide/intentional#ドキュメント)作成の基礎となります。

設計標準がない場合、チームはサイロで作業する可能性が高くなります。設計標準で提供される一貫性がなければ、企業は次の課題に苦労することになります。

- ベンダーと開発チームがソリューション全体でアドホックなパターンとアプローチを使用しているため、アンチパターンが導入され、再利用性が低下する可能性がある(「[懸念の分離](/docs/architect/ja-jp/well-architected/guide/composable#懸念事項の分離)」を参照)。
- 本番の問題を解決する時間が増え、新しいチームメンバーのオンボーディングに必要なチームをサポートし、チームがさまざまなパターンやアプローチを理解できるようになりました。
- チーム間のコラボレーションの不十分さ、チーム間の作業の重複、競合を解決する時間の無駄、インテグレーションテスト中に発見されたバグ。
- ストレスと離職率の増加。

設計標準の主な利点は、関係者が設計標準を作成するために行う必要がある会話と決定に起因します。具体的には、このプロセスにより、ビジネスとテクノロジーをリードする企業が、ビジネスにとって最適な設計がどのようになっているかを調整できるようになります。

[設計標準](/docs/architect/ja-jp/resources/guide/design-standards-template)に次のものを含めます。

- **Salesforce メタデータの命名**規則。システムのすべてのカスタマイズの命名方法に関する一連の規則を定義します。優れた命名規則は、オブジェクト、項目、コード、フロー、その他のシステム要素の名前に一貫性を持たせるだけではありません。優れた命名規則は、開発チームが構築の目的と機能に関する情報を伝える名前を使用するのにも役立ちます。その結果、他の関係者は名前を確認するだけで特定のカスタマイズをより適切に理解できます。
- **承認済みデザインパターンとその使用事例**。[パターン & アンチパターンエクスプローラー](/docs/architect/ja-jp/well-architected-tools/guide/patterns)のライブラリと、各パターンを使用するタイミング (および使用しないタイミング) に関する重要な情報を設定します。ライブラリには、必要な Apex トリガー パターン、またはシステムで必要[な構成可能](/docs/architect/ja-jp/well-architected/guide/composable)性に基づくフロー オーケストレーション パターンが含まれている場合があります。
- **開発環境とツールガイダンス**。開発チームが作業に使用するツールを明確にリストします。これには、コードを記述するすべてのユーザー向けに承認されたツールチェーンや言語、またはローコード開発向けに承認された (または承認されていない) 宣言型機能が含まれます。標準には、カスタマイズとドキュメント化のためのソース制御システムのリスト、および必要なチェックイン/チェックアウト手順が含まれている場合があります。また、さまざまな種類の開発作業に使用する環境のリストが含まれている場合もあります。

これらの標準の定義に加えて、標準を維持および保存する方法と場所を決定する必要があります。社内のチームが設計標準を見つけられない場合 (または、その存在に気づいていない場合)、有効ではありません。設計標準がドキュメントと同じシステム内に存在していることが理想的です (詳細は次のセクションを参照してください)。

次の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/intentional#読みやすさパターンとアンチパターン)のリストは、Salesforce 組織にとって適切な (および不適切な) 設計標準を示しています。これらを使用して、設計標準を検証または改善できます。

設計標準の定義に役立つ Salesforce ツールについての詳細は、「[Tools Relevant to Intentional](/docs/architect/ja-jp/well-architected/guide/intentional#インテンショナルに関連するツール) (インテントに関連するツール)」を参照してください。

### ドキュメント

ドキュメントには、システムの内容、方法、理由が記載されています。有意義で一貫性のあるドキュメントがないと、チームはシステムをそのまま理解しようとして多くの時間を浪費します (機能とカスタマイズを誤解する可能性もあります)。

優れたドキュメントは作成に時間がかかります。ほとんどのチームは、大規模なプロジェクトでは文書化が重要であることに同意していますが、設定の更新や自動化の微調整など、迅速な変更を行う場合はスキップしたくなります。システムに行った変更を文書化しないことは、常にアンチパターンです。ドキュメントをスキップすると、先行作業の時間を節約できますが、適切にドキュメント化されていない組織のトラブルシューティングに要する時間は、その時間の節約を相殺する以上のものになります。予定している更新に必要な作業のレベルに関係なく、すべての見積にドキュメントを作成するための十分な時間を常に含めます。

明確なドキュメントがない場合、次のようなさまざまな問題が発生する可能性があります。

- 既存の実装のやり直しに費やす開発サイクル
- 以前の決定を再確認したり、困惑したりする反復的なディスカッション
- 新規チームメンバーまたはベンダーのオンボーディングの長期化
- 制度的または歴史的な Knowledge を持つ個人への過剰依存
- 同じ機能または類似する機能をビジネス全体でサポートする冗長アーキテクチャ
- ソリューションの目的と価値を主要な関係者に伝えることが難しい

Salesforce ソリューションの場合、次のドキュメントを保持します。

- **ソリューションの概要**。[図](/docs/architect/ja-jp/reference-diagrams/guide/introduction)を使用すると、自分と関係者がさまざまな詳細レベルでソリューションを視覚化できます。Salesforce ダイアグラムフレームワークを使用すると、ソリューションのビジネス能力や技術的な実装の詳細を示すダイアグラムを作成できます。
- **決定レコード**。検討されたオプション、トレードオフ、最終決定、および推論の記録を、すべてのチームメンバーが将来の参照のためにアクセスできる一元的な場所に保管します。
- **コード**。コード形式自体はドキュメントの主要な部分であり、[設計標準](/docs/architect/ja-jp/well-architected/guide/intentional#設計標準)に合わせることができます (準拠させる必要があります)。また、鍵情報のログを作成し、コードを変更するたびに更新します。すべてのクラス、トリガー、およびコンポーネントについて、次のドキュメントを作成します。
  - コードの作成者
  - コードが記述されたとき
  - コードで実行される内容
  - 主要な連動関係
  - すべての変更
- **宣言型カスタマイズ**。組織でメタデータに対して実行できるあらゆる種類のカスタマイズについて、Salesforce ではメタデータの目的とインテントに関する有益な情報をチームに提供するため[の組み込み属性](/docs/architect/ja-jp/fundamentals/guide/platform-multitenant-architecture#ブラウザーベースノーコードおよびローコードアプリケーション開発)を提供しています。設計標準の一部として、チームがこれらの組み込み機能をどのように使用するか、宣言型カスタマイズをどのように命名するかを含めます。また、コードに使用する情報と同じ鍵情報のログも保持します。

現在および将来のすべてのチームメンバーが同じ方法でドキュメントを解釈できるように、一連のドキュメント標準を作成します ([設計標準](/docs/architect/ja-jp/resources/guide/design-standards-template)が役立ちます)。また、ユーザーがドキュメントを検索して関連するセクションや用語を見つける方法を考慮することも重要です。システムが老朽化し、複雑さが増すにつれて、ドキュメントも増加します。ドキュメントの情報の有用性は、ユーザーが関連項目を検索および見つける頻度、速度、および容易さに直接関連します。

以下の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/intentional#読みやすさパターンとアンチパターン)のリストは、Salesforce 組織での適切な (および不適切な) ドキュメントを示しています。これらを使用して、ドキュメント戦略を検証または改善できます。

ドキュメント用の Salesforce ツールについての詳細は、「[Tools Relevant to Intentional](/docs/architect/ja-jp/well-architected/guide/intentional#インテンショナルに関連するツール) (インテントに関連するツール)」を参照してください。

### 読みやすさパターンとアンチパターン

次の表に、組織で検索 (または作成) するパターンと、回避または修正の対象となるアンチパターンの選択を示します。

✨ [パターン & アンチパターンエクスプローラー](/docs/architect/ja-jp/well-architected-tools/guide/easy-readability)で、より多くのパターンを見やすくします。

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">パターン</th>
            <th scope="colgroup">アンチパターン</th>
        </tr>
        <tr>
            <td rowspan="2"><b>設計標準</b></td>
            <td><b>組織内：</b>
            <br> - コードおよび宣言型カスタマイズには、人間が判読可能な一貫した名前を付ける
            <br> - データモデルには、オブジェクトと項目に対して一貫した統一した名前を付ける
            <br> - 監査では、項目が一貫して入力され、レポートなどで参照されていることが示されます。</td>
            <td><b>組織内：</b>
            <br> - コードのカスタマイズと宣言型のカスタマイズの名前が統一されていない
            <br> - データモデルの名前に一貫性がなく、多くのオブジェクトと項目が冗長であるように見える
            <br> - 監査では、未使用の項目やさまざまなレベルの使用量が表示され、レポートなどへのリンクが一貫していない。</td>
        </tr>
        <tr>
            <td><b>ビジネス内：</b>
            <br> -チームは、作業を完了するために使用すべき (使用しない) ツールを把握している
            <br> -承認済みデザインパターンは、使用事例別に簡単に見つけて識別できます。
            <br> 承認済みの AI モデルが明確に識別され、目的が含まれている</td>
            <td><b>ビジネス内：</b>
            <br> -チームは多くの異なるツールを使用して同様の作業を完了
            <br> - 承認されたデザインパターンがない
            <br> -ベンダーや新入社員のオンボーディングに時間がかかる
            <br> ・承認済みのAIモデルが明確に識別されておらず、その使用目的が明確でない</td>
        </tr>
        <tr>
            <td rowspan="2"><b>ドキュメント</b></td>
            <td><b>組織内：</b>
            <br> - コードおよび宣言型カスタマイズには明確な説明がある</td>
            <td><b>組織内：</b>
            <br> - コードおよび宣言型カスタマイズに説明が含まれていない、説明がわかりづらい、またはカスタマイズが実際に行っていることと一致しないように見える</td>
        </tr>
        <tr>
            <td><b>ビジネス内：</b>
            <br> - すべてのソリューションのビジネス能力と技術的な実装の詳細を示す図が存在する
            <br> - コードおよび宣言型カスタマイズで誰が/いつ/どのような情報ログが存在するかを示す鍵
            <br> - ユーザーは関連するドキュメントを検索して見つけることができます。</td>
            <td><b>ビジネス内：</b>
            <br> - ソリューションの内容/方法/理由が見つけにくく、ほとんどのチームが使用できない可能性がある
            <br> - ソリューションと使用しているシステムを理解するのに苦労している
            <br> -ベンダーや新入社員のオンボーディングに時間がかかる</td>
        </tr>
    </tbody>
</table>

## インテンショナルに関連するツール

<table class="tools-table"><tbody><tr><th>ツール</th><th>説明</th><th>戦略</th><th>メンテナンス性</th><th>読みやすさ</th></tr>
<tr><td><a href="https://github.com/SalesforceFoundation/ApexDoc">ApexDoc</a></td><td>静的 HTML ページを使用したドキュメント Apex</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.fields_picklist_delete_inactive_values.htm&language=en_US&type=5&_ga=2.216886358.1142927923.1683068265-1808100124.1682614163">無効な選択リスト値の一括削除</a></td><td>選択リストから無効な未使用の値を削除する</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.lightningdesignsystem.com/tools/validator/">Lightning Design System 検証</a></td><td>マークアップを検証し、コードを改善する方法を確認する</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=release-notes.rn_automate_flow_mgmt_migrate_to_flow_tool.htm&type=5&release=242&_ga=2.180751207.1142927923.1683068265-1808100124.1682614163">フローへの移行</a></td><td>ワークフロールールとプロセスビルダープロセスのフローへの変換</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://appexchange.salesforce.com/appxListingDetail?listingId=a0N3u00000MRsKnEAL">Salesforce Labs によるプロジェクト管理ツール</a></td><td>Salesforce 組織内のプロジェクトを管理する</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://marketplace.visualstudio.com/items?itemName=salesforce.salesforcedx-vscode-expanded">Visual Studio Code 向け Salesforce 拡張機能 (拡張)</a></td><td>Visual Studio Code 拡張機能を使用した Salesforce コードの効率的な分析</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://sfdc.co/OrgCheck">組織チェック</a></td><td>組織とその技術的負債をすばやく分析する</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://github.com/forcedotcom/code-analyzer">Salesforce Code Analyzer</a></td><td>IDE、CLI、またはCI/CDを使用してコードをスキャンし、ベストプラクティスに準拠していることを確認する</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://architect.salesforce.com/roadmaps/roadmap-explorer">Salesforce Roadmap Explorer</a></td><td>Salesforce 製品のイノベーションの探索</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.admin_monitorsetup.htm&type=5">Setup Audit Trail</a></td><td>設定変更と監査履歴の追跡</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
</table>

## Resources Relevant to Intentional (インテントに関連するリソース)

<table class="tools-table"><tbody><tr><th>リソース</th><th>説明</th><th>戦略</th><th>メンテナンス性</th><th>読みやすさ</th></tr>
<tr><td><a href="https://www.salesforce.com/blog/documentation-strategies-to-improve-your-salesforce-org/">Salesforce 組織を改善するための 5 つのドキュメント戦略</a></td><td>Salesforce 実装ドキュメントの改善</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/success-cloud-coding-conventions/choose-naming-conventions-sc">命名規則の選択 (Trailhead)</a></td><td>命名規則の適用方法</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://medium.com/salesforce-architects/defining-identifying-and-measuring-technical-debt-5f783e2b381d">技術的負債の定義、識別、および測定</a></td><td>技術的負債の定義、特定、測定</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="/docs/architect/ja-jp/resources/guide/design-standards-template">設計標準テンプレート</a></td><td>組織の設計標準を作成する</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="/diagrams">Salesforce 図の使用開始</a></td><td>使用事例に適した図の作成方法を学ぶ</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/success-cloud-coding-conventions/get-started-with-coding-conventions-sc">コーディング規則の使用開始 (Trailhead)</a></td><td>コーディング規則の定義と準拠</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://trailhead.salesforce.com/trailblazer-community/download/file/0693A000006PskRQAS">技術的負債に対処する方法 (Trailhead)</a></td><td>Salesforce 組織での技術的負債の管理</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/success-cloud-coding-conventions/improve-your-apex-code-sc">Apex コードの改善 (Trailhead)</a></td><td>テスト駆動開発の基本原則の適用</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/manage_the_sfdc_organizational_alignment_v2mom?trailmix_creator_id=strailhead&trailmix_slug=prepare-for-your-strategy-designer-credential">組織の連携 (Trailhead)</a></td><td>アライメントのための V2MOM プロセス</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://medium.com/salesforce-architects/prioritizing-and-planning-a-way-out-of-technical-debt-6f18fbb2b007">技術的負債から抜け出すための優先順位付けと計画</a></td><td>技術的負債を削減および削除する計画を形成する</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://salesforce.quip.com/MW5cAPVwat8k#JCIACA8Q963">Salesforce 命名規則テンプレート</a></td><td>命名規則の使用開始</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://admin.salesforce.com/blog/2021/tech-debt-what-it-is-and-why-you-should-care">技術的負債:何なのか なぜ気にする必要があるのか </a></td><td>組織の技術的負債の影響を理解する</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://medium.com/salesforce-architects/using-the-business-model-canvas-in-enterprise-architecture-5c136803a99d">エンタープライズアーキテクチャでのビジネスモデルキャンバスの使用</a></td><td>ビジネスモデルの価値の創出、提供、確認</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
</table>

## ご意見をお聞かせください

Salesforce Well-Architected の関連性の維持にご協力ください。このコンテンツに関するフィードバックをいただくため[のアンケート](https://sfdc.co/bxNtvh)にご協力ください。また、今後の展望についてもお聞かせください。

<!-- document id=500916f9093b57a668028f035d19951b83f78e5785a56e9252f9a425bbe07b06 url=/architect/next/ja-jp/well-architected/guides/composable.md -->

> 更新スケジュールについては、[こちら](/docs/architect/ja-jp/well-architected/guide/contributors)を参照してください。

## はじめに

コンポーザブルなソリューションは、迅速かつ高い安定性で調整できます。構成可能なように設計されたシステムは、相互に適切に動作し、サービスの開始と終了を簡単に切り替えることができる有意義なユニット (ビルディングブロック) で構成されています。コンポーザビリティをシステムに組み込むことで、システムの個々のユニットをリファクタリングまたは再構成して、新機能を導入したり、技術的な負債を解消したりできます。コンポーザビリティにより、チームは少量の変更で有意義な機能の構築と提供に集中できるため、より迅速で予測可能な提供サイクルとリリースが可能になります。

コンポーザブルなシステムにより、刺激がビジネスの内部要因によるものか、外部要因によるものかにかかわらず、ビジネスをより迅速かつ安定的に適応させることができます。コンポーザビリティは、システムの[耐障害性](/docs/architect/ja-jp/well-architected/guide/resilient)を高め、ソリューションとアーキテクチャパターンをより[意図的](/docs/architect/ja-jp/well-architected/guide/intentional)にするのに役立ちます。

懸念事項の分離、相互運用性、パッケージ化可能性という 3 つの主要な習慣を構築することで、Salesforce ソリューションをより構成可能にできます。次の図では、これらの習慣の関係を 2 つの方法で確認できます。1 つの構成可能なシステムの 1 つの単位の場合と、構成可能なシステムの複数の単位の場合です。

<b>単一の構成可能なユニット:</b>

<a href="https://a.sfdcstatic.com/developer-website/prod/images/architect/composable-capabilities.jpeg" target="_blank">
    <img style="border:1px solid #e5e5e5;margin:2rem 0rem;width:50%;" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/composable-capabilities.jpeg" alt="次の図は、ネストされた 3 つのカードで構成可能なトピックがどのように関連するかを示しています。 一番内側のカードは機能単位、次のレイヤーは相互運用性、外側のレイヤーは梱包可能性です。">
</a>

<b>構成可能なシステム:</b>

<a href="https://a.sfdcstatic.com/developer-website/prod/images/architect/composable-multi-package-capabilities.jpeg" target="_blank">
    <img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/composable-multi-package-capabilities.jpeg" alt="次の図は、ネストされた 3 つのカードで構成可能なトピックがどのように関連するかを示しています。 一番内側のカードは機能単位、次のレイヤーは相互運用性、外側のレイヤーは梱包可能性です。">
</a>

## 懸念事項の分離

ソフトウェアエンジニアリングおよびシステムアーキテクチャの基本概念であり、*懸念の分離*では、モジュール単位に分割できる大規模なシステム内でさまざまな懸念事項を特定します。システム内で懸念事項を強固に分離するには、システム全体でアプリケーションロジックと機能の意味のあるユニットを作成する必要があります。単位を小さくすると、アプリケーション配信チームとメンテナンスチームは、大規模なシステムの中断を最小限に抑えながら、変更の方法と場所を理解しやすくなります。また、ユニットを小さくすると、[技術的負債](/docs/architect/ja-jp/well-architected/guide/intentional#技術的負債)に対処するときに作業をどのようにどこに集中させるかが明確になり、システム全体の[可読性](/docs/architect/ja-jp/well-architected/guide/intentional#読みやすさ)が向上します。

ビジネス能力を重視して状態を管理することで、Salesforce 組織に懸念をより適切に分離できます。

### 機能単位

Salesforce システムの場合、懸念事項を分離するための最良のアプローチでは、ビジネス指向の視点を適用して、システム内のモジュラーユニット (または機能) を特定して整理します。これは、技術的な機能に基づいてユニットを識別するエンジニアリング重視のビューとは異なります。関心事を切り分けるビジネス指向の観点では、ビジネスユーザーとビジネスユーザーに提供するサービスに基づいてシステムのコードとカスタマイズを整理する必要があります。このアプローチは、システム内の冗長または重複する技術的機能の可能性を無視という意味ではありません。つまり、テクニカルサービスは、ビジネスにとって最終的に透明性の高い組織原則に明確に対応付けられています。

ビジネス機能を考慮すると、ビジネス分析チームとディスカバリーチーム間の受け渡しをできるだけ簡単に行うことができます。アプリケーションビルダーが作業単位をコンポーザー可能なアーキテクチャに対応付ける場所を知らない場合、コンポーザー可能なアプリケーション環境ではなく混乱が生じます。また、ビジネスで必要とされる最終状態と組織内のモジュラーユニットの対応付けが明確でない場合、開発チームやベンダーが冗長な機能をシステムに組み込む可能性が高くなります。

ビジネス機能に合わせて機能ユニットを配置するには、次の点を考慮してください。

- **Start with jobs to be done** (実行するジョブから開始)。ユーザーとビジネス自体のやるべき仕事 (JTBD) に焦点を絞ります。Tony Ulwick が先駆者となり、商品またはサービスを使用して人々が達成しようとしている「仕事」、つまり真の目的を理解することに焦点を絞りました。これは、ユーザーのロール関連の ToDo やビジネスプロセスの個々のステップよりも高い抽象レベルです。たとえば、重複チェックや住所検証などのタスクは、「顧客の 1 つのビューの確立」という高次の機能に分類されます。これらの高次のビジネス機能を明確に把握したら、システムの一部を対応付けることができます。
- **レポート構造ではなく機能指向です。**ビジネスユニットの内部階層は、意味のある機能やジョブを実行するためのプロキシではありません。ビジネスの内部階層は、プロセスとチーム構造に重大な影響を及ぼします (予算は言うまでもありません)。これらは、物流上の重要な考慮事項です。ただし、ビジネスの機能ニーズは、物流よりも抽象化レベルで実行されます。高次の関数ではなくレポート構造を提供するモジュールを作成する場合、そのモジュールがビジネス機能にどのように関連するかを特定するために追加の手順を実行する必要がある場合があります。
- **反復型**。まず、ビジネス部門と連携して、最小限の実行可能な商品 (MVP) にどのような機能が有効かを特定します。機能を特定したら、その MVP の作成を開始します。構築するときに、作成する機能単位の中心となるプロセス、メタデータ、および[イベントやメッセージ](/docs/architect/ja-jp/well-architected/guide/composable#メッセージングとイベント)を特定します。外部連動関係のプロセス、メタデータ、イベントまたはメッセージを特定します。より多くの機能ユニットを設計するときに、(サイロ化されたユニットを構築するのではなく) [API 管理](/docs/architect/ja-jp/well-architected/guide/composable#api-管理)と[連動関係管理](/docs/architect/ja-jp/well-architected/guide/composable#連動関係管理)を実装して、相互に適切に機能するユニットを構築します。

以下の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/composable#懸念パターンとアンチパターンの分離)のリストは、Salesforce ソリューション内でのビジネス機能に対する適切な (および不適切な) 方向性を示しています。これらを使用して、構築前に設計を検証したり、システムのリファクタリングが必要な領域を特定したりできます。

ビジネス機能をより深く理解するために Salesforce から入手できるツールについての詳細は、「[Tools Relevant to Composable](/docs/architect/ja-jp/well-architected/guide/composable#コンポーザブルに関連するツール) (コンポーザブルに関連するツール)」を参照してください。

### 状態管理

状態管理では、さまざまな時点でのシステム全体の情報の移動に重点が置かれます。効果的な状態管理により、アプリケーションは複雑なデータフローやインタラクションを処理でき、予定外の結果が最小限に抑えられます。モジュール化された Salesforce 組織で状態を管理するには、ユニット内およびユニット間のロジックフローの明確なパスと、予定外の実行動作のグレースフルパスを作成します。状態管理により、モジュール化された Salesforce アプリケーションユニットから一貫したロジックストリームを形成できます。ほとんどの場合、ユニット間の情報フローを構造化するには[相互運用性](/docs/architect/ja-jp/well-architected/guide/composable#相互運用性)が必要です。

疎結合のユニット間で状態を管理することが困難な場合、Salesforce ではモノリス型のアプリケーション開発になることがよくあります。これは、1 つのフロー内で複雑なプロセスを調整するために構築された大規模な「モノフロー」で確認できます。もう 1 つの例として、大規模な Apex クラスがあります。これは、*スパゲッティ・コード*や長い一連の 1 回限りの方法を使用して複雑なプロセスを調整します。このようなアプリケーションアーキテクチャでは、リファクタリングとデバッグが難しくなり、新しいチームメンバーやベンダーのオンボーディング時間が長くなります。また、機能は再利用できないため、ビジネスに提供されるアプリケーションの価値も低下します。

モジュラー型の Salesforce 組織全体で状態を管理するには、次の点を考慮してください。

- **ステートフルパターンとステートレスパターンのどちらを使用するかを決定します。**ステートフルパターンでは実行パス全体で情報が保持されますが、ステートレスパターンでは保持されません。疎結合システムでは、ステートレスパターンにより、コンポーネントをより迅速にリファクタリングでき、副作用を減らすことができます。ただし、ステートレスパターンがすべての使用事例に適しているわけではありません。データ操作のコンポーネントを作成する場合、ステートフルパターンはシステム全体のデータの整合性と一貫性を保つのに役立ちます。コンポーネントが次のいずれかの条件を満たしている場合、ステートフルパターンを使用します。
  - より大きな実行パス内の配置を認識することはコンポーネントの動作に不可欠
  - 下流のアクションの結果に基づいてコンポーネントの動作を変更する必要がある (たとえば、下流のコンポーネントからのロールバック/エラー/成功メッセージに基づいて実行を変更する必要がある)
  - コンポーネントは、外部システムまたはダウンストリームシステムからの応答を待って作業を完了する必要があります。
- **ステートフルな情報の有意義なカテゴリを作成します。\***状態と*はあいまいな用語であり、Salesforce 組織内 (およびそれ以降) のこのような深く幅広い情報に適用でき、単独ではほとんど意味がありません。したがって、ステートフルパターンを作成するために必要な最初のステップは、システム内で最も重要なステートフル実行パス (またはステートフル動作の種類) の*有意義\*なカテゴリを作成することです。考慮すべきカテゴリ:
  - ナビゲーションとフォーム
  - データベース操作
  - 一括処理および一括処理
  - エラー
- ** [データベーストランザクション](/docs/architect/ja-jp/fundamentals/guide/architecture-basics#データベース操作)の観点からデータ関連の状態を定義し**ます。プラットフォームの組み込み動作では、Salesforce のデータに関するほとんどの状態の考慮事項が考慮されません。この動作に対して、またはこの動作を回避して管理しようとしないでください。それに合わせて設計します。分散トランザクションロジックを最小化または排除するソリューションを設計します。(詳細については、「[データ処理](/docs/architect/ja-jp/well-architected/guide/automated#データ処理)」を参照してください)。
- **機能単位内 (および機能単位全体) で発生する状態を特定します。**機能ユニットをより大きなシステムに組み立てるときは、ステートレスコンポーネントとステートフルコンポーネントの動作を混在させることに留意し、無限ループや処理のギャップが生じる可能性のある組み合わせを回避します。
- **ハンドオフを定義**します。コンポーネントが状態関連のデータをシステムの別の部分に転送するために使用する[メッセージングまたはイベント](/docs/architect/ja-jp/well-architected/guide/composable#メッセージングとイベント)パターンを検討します。トランザクション認識と[処理](/docs/architect/ja-jp/well-architected/guide/automated#データ処理)をコンポーネントに組み込んでいることを確認します。ハンドオフには分散トランザクションロジックを含めないでください。
- プロセス図と状態の**対応付けを作成**します。プロセス図には、さまざまな時点で情報をシステム内を移動する手順が詳しく説明されています。状態ダイアグラムは、情報 (状態) の実際の変化を示します。[Salesforce Diagrams](/docs/architect/ja-jp/reference-diagrams/guide/kit-of-parts) 図形のメタデータフッター部分を使用して、プロセスの各ステップで変化する情報の状態を取得します。プロセス図と状態図を分ける場合は、必ずリンクしてください。この概念は、設計および実装中にプロセスやシステムランドスケープの現在および将来の状態を取得することと混同しないでください。これは、システム内を移動する情報に関するものではないためです。

次の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/composable#懸念パターンとアンチパターンの分離)のリストは、Salesforce ソリューション内の適切な (および不適切な) 状態管理を示しています。これらを使用して、構築前に設計を検証したり、システム内でリファクタリングが必要な場所を特定したりできます。

状態を管理するための Salesforce ツールについての詳細は、「[Tools Relevant to Composable](/docs/architect/ja-jp/well-architected/guide/composable#コンポーザブルに関連するツール) (コンポーザブルに関連するツール)」を参照してください。

### 懸念パターンとアンチパターンの分離

次の表に、組織で検索 (または作成) するパターンと、回避または修正の対象となるアンチパターンの選択を示します。

✨ [パターン & アンチパターンエクスプローラー](/docs/architect/ja-jp/well-architected-tools/guide/adaptable-separation-of-concerns)で、懸念事項を分離するためのより多くのパターンを見つけます。

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">パターン</th>
            <th scope="colgroup">アンチパターン</th>
        </tr>
        <tr>
            <td rowspan="3"><b>機能単位</b></td>
            <td><b>設計基準では、次のようになります。</b>
                <br> - 命名規則では、機能単位を示す方法について説明しています。
                <br> 現在定義されているすべての機能単位 (および関連する命名規則) のリストが存在する
                <br> ・機能単位の追加や変更の提案基準が存在する</td>
            <td><b>設計基準では、次のようになります。</b>
                <br> - 設計標準が存在しないか、機能単位と使用事例を扱っていない
            </td>
        </tr>
        <tr>
            <td><b>ドキュメント:</b>
                <br> - 組織の機能単位を明確に示すシステムランドスケープダイアグラム
                <br> - すべてのドキュメントと実装図にコンポーネントの機能単位が明確に示されている
                <br> - 個々のコンポーネントのドキュメントには、コンポーネントの機能単位の対応付けが含まれます。
                <br> -機能単位内のすべてのコンポーネントが検索可能で、見つけやすい
            </td>
            <td><b>ドキュメント:</b>
                <br> - コンポーネントのドキュメントが存在しない
                <br> - コンポーネントドキュメントにはコンポーネントが属する機能単位が記述されていますが、その機能単位の定義が表示されるのはコンポーネントドキュメントのみです。
                <br> -特定の機能単位を検索できない、または検索が機能単位内のすべてのコンポーネントの識別に役立たない
            </td>
        </tr>
        <tr>
            <td><b>組織内：</b>
                <br> -特定のメタデータ(フロー、Apexクラス、Lightningページなど)の機能単位の配置をすばやく特定できます。
                <br> - 機能単位にはビジネスにわかりやすい表示ラベルを付ける
            </td>
            <td><b>組織内：</b>
                <br> -メタデータの機能単位の配置を特定できない
                <br> - 機能単位情報に一貫性がないか、不正確である
                <br> - 機能単位情報の表示ラベルが、ビジネスユーザーにとって無意味なエンジニアリング関連の用語で付けられている
            </td>
        </tr>
         <tr>
            <td rowspan="4"><b>状態管理</b></td>
            <td><b>設計基準では、次のようになります。</b>
                <br> -ステートフル設計とステートレス設計の使用事例が明確である
                <br> - ステートレス通信の承認済みパターンが存在する
                <br> - ステートフルなコミュニケーションの承認済みパターンが存在する
                <br> - 状態のカテゴリをクリア
            </td>
            <td><b>設計基準では、次のようになります。</b>
                <br> - 設計標準が存在しないか、状態/ステートレスパターンと使用事例を扱っていない
            </td>
        </tr>
        <tr>
            <td><b>ドキュメント:</b>
                <br> - ステートフルまたはステートレス通信を処理するすべてのコンポーネントは、実装されたパターンを示します。
                <br> -特定のステートフル/ステートレスパターンを実装しているすべてのコンポーネントを検索して見つけることができます。
                <br> - プロセス図とインタラクション図には、状態カテゴリと引き継ぎに関する詳細が表示されます。
            </td>
            <td><b>ドキュメント:</b>
                <br> - コンポーネントのドキュメントが存在しない
                <br> - コンポーネントのドキュメントには実装されたステートフル/ステートレスパターンが説明されていますが、定義が表示されるのはここのみです。
                <br> -特定のパターンを検索できない、または検索がそのパターンを使用するすべてのコンポーネントの識別に役立つとは限らない
            </td>
        </tr>
        <tr>
            <td><b>Apex:</b><br> - すべてのデータ操作でセーブポイントとロールバック動作が使用される</td>
            <td><b>Apex:</b><br> - セーブポイントとロールバック動作が使用されない</td>
        </tr>
        <tr>
            <td><b>フロー内:</b><br> - 障害パスがあり、レコードのロールバック要素が使用されている</td>
            <td><b>フロー内:</b><br> - [レコードをロールバック] 要素が使用されていない</td>
        </tr>
    </tbody>
</table>

## 相互運用性

相互運用性を考慮して設計されたシステムでは、コンポーネントが情報交換を行い、効果的に連携して動作します。モジュラー システムをサイロ化するのではなくコンポーザブルにするには、相互運用性が重要です。[疎結合](/docs/architect/ja-jp/well-architected/guide/composable#疎結合)システムでは相互運用性を実現することが困難な場合があります。ユニット間の独立性やシステム全体の全体的な[懸念の分離](/docs/architect/ja-jp/well-architected/guide/composable#懸念事項の分離)を損なわない一貫した統合方法の標準を確立する必要があります。

相互運用性は、ユーザーエクスペリエンスの品質にも影響します。ユーザーは 1 つの領域 (注文情報など) で作成されたデータを別の領域 (マーケティングキャンペーンなど) で使用できることを期待しています。また、ビルダーは、フローの作成や API への認証など、何らかの方法を習得すれば、次の問題に進むときに使い慣れた手法が機能することを期待しています。相互運用性を考慮した設計を怠ると、アーキテクチャの冗長化、データの複製、プロセスの非効率性、開発およびサポートコストの増加につながります。

メッセージングやイベント、および API 管理を使用して、モジュラー型システムで相互運用性を作成できます。

### メッセージングとイベント

メッセージとイベントは、システム全体のコンポーネントで情報を送受信できるようにする 2 つの方法です。伝達できるコンテンツという点では、イベントとメッセージは似ています。大きな違いは、送信者の動作です。通常、*メッセージ*を送信するコンポーネントは、データを特定の宛先に送信し、受信者からの何らかの応答を待機します。一方、コンポーネントは、何かが発生すると*イベント*を出します。特定の宛先はなく、応答も期待できません。これらの動作の違いにより、さまざまなコミュニケーションパターンがサポートされます。メッセージではステートフルな通信パターンがサポートされ、イベントではステートレスな通信パターンがサポートされます。(この区別の詳細については、「[状態管理](/docs/architect/ja-jp/well-architected/guide/composable#状態管理)」を参照してください)。

メッセージングとイベントに関するプロトコルと使用事例についてチームを調整することが重要です。基準があいまいな場合、システム全体でパターンが混在するため、次のことが発生する可能性があります。

- 特定の使用事例に誤ったパターンが適用されるパフォーマンスと拡張性の問題
- 処理の一貫性がないため、エンドユーザーにはシステムが不安定に見えます。
- トラブルシューティング時間が長くなり、メンテナンスプロセスが複雑になる

Salesforce 組織内でより疎結合の構造を作成するためにメッセージとイベントを設計するときは、次の点を考慮してください。

- 同期および非同期の**使用事例を識別**します。イベントにより、システム全体で疎結合のステートレスな非同期通信が可能になります。メッセージングでは、より厳密に制御されたステートフルで同期的なコミュニケーションパターンを使用できます。メッセージまたはイベントを使用するタイミングを決定する場合、コミュニケーションを同期 (およびブロッキングの可能性あり) にするか、非同期とノンブロッキングのどちらにするかを決定する必要があります。
- **データ構造を慎重**に定義します。コンポーネント間で渡される情報の構造は、疎結合のシステムを管理しやすく一貫性のあるものにするために重要です。(詳細については、「[API 管理](/docs/architect/ja-jp/well-architected/guide/composable#api-管理)」を参照してください)。メッセージまたはイベントを設計するときの重要な考慮事項は、情報の構造を変更する必要がある頻度です。メッセージまたはイベント構造が定義されてシステムに実装されると、特にイベントまたはメッセージがすでに外部システムへの情報の送信に使用されている場合、更新の処理が困難になる可能性があります。
- **適切なサイズ**のメッセージ。一般に、メッセージサイズは小さく抑えることをお勧めします。ただし、メッセージ*のサイズ*とメッセージ*量*の間でバランスを取る作業もあります。少量のデータをより迅速に処理できます。受信者は受信した情報を開梱し、解釈して、その処理方法を決定する必要があるため、処理には追加のオーバーヘッドが発生します。これらのステップの完了にはごくわずかな時間がかかりますが、大規模なシステムに負荷が蓄積され、発生する可能性があります。作業を完了するためにシステム内のコンポーネントで多数の小さなメッセージを連続して処理する必要がある設計は避けます。メッセージのサイズを適切に設定するには、すべてのダウンストリームコンポーネントが多数の後続メッセージを要求または処理できると想定せずに、ダウンストリームコンポーネントが送信された情報を正常に処理および処理するために必要な最小限のデータを考慮してください。
- **拡張性設計**。コンポーネントが疎結合になっていると、アーキテクチャの拡張が容易になります。コンポーネント間の連動関係を排除することで、チームは個々のコンポーネントのパフォーマンスや拡張性の向上に取り組むことができますが、他のコンポーネントへの影響を最小限に抑えることができます。ただし、疎結合コンポーネントは、アーキテクチャを大規模に(特に[状態の管理](/docs/architect/ja-jp/well-architected/guide/composable#状態管理)に関して)複雑にします。有効なユーザーエクスペリエンスやデータ整合性の理由でロジックや連動関係をより緊密に組み合わせる必要があるプロセスを特定し、それらのプロセスに非同期/イベントベースのパターンを導入しないようにします。代わりに、同期/メッセージベースのパターンと適切なエラー処理を使用してください。

次の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/composable#相互運用性パターンとアンチパターン)のリストは、Salesforce ソリューション内の適切な (および不適切な) メッセージングとイベントを示しています。これらを使用して、構築前に設計を検証したり、システム内でリファクタリングが必要な場所を特定したりできます。

Salesforce メッセージングおよびイベントツールについての詳細は、「[Tools Relevant to Composable](/docs/architect/ja-jp/well-architected/guide/composable#コンポーザブルに関連するツール) (コンポーザブルに関連するツール)」を参照してください。特定の使用事例のイベントパターンまたはツールの選択についての詳細は、『[Architect’s](/docs/architect/ja-jp/decision-guides/guide/event-driven#key-takeaways) Guide to Event-Driven Architecture with Salesforce (Salesforce を使用したイベント駆動型アーキテクチャのアーキテクトガイド)』を参照してください。

### API 管理

Salesforce ソリューション内で適切なアプリケーションプログラミングインターフェース (API) 管理を構築すると、システムの個々のコンポーネントが予測可能なコミュニケーションパターンに従うことができます。Salesforce には、Salesforce 外のシステムとの通信に使用する組み込みの安全な API が用意されています。(Salesforce Platform API についての詳細は、「[アーキテクチャの基本](/docs/architect/ja-jp/fundamentals/guide/architecture-basics#プラットフォーム-api)」を参照してください)。

Salesforce ソリューション内の効果的な API 管理は、真に構成可能なアーキテクチャを構築するための鍵です。これにより、Salesforce 組織内のコンポーネントは効率的に情報を送受信できます。また、ソリューションビルダーは、構築したコンポーネントがシステムの他のコンポーネントと通信する方法に関する明確なプロトコルに従うことができ、不適切な実装を早期に特定できます。さらに、ソリューション作成者は構築またはリファクタリングする特定のコンポーネントに絞り込むことができるため、生産性と品質が向上します。

エンタープライズレベルの API 管理は個別のトピックであり、包括的な API 管理ツールを使用することをお勧めします。このトピックに関する MuleSoft の観点についての詳細は、「[API 管理と](https://www.mulesoft.com/resources/api/what-is-api-management#:~:text=API%20management%20is%20the%20process,create%20are%20consumable%20and%20secure.)は」を参照してください。

Salesforce ソリューション内で API 管理機能を構築するには、次の点を考慮してください。

- **API は、コミュニケーションのための*予測*可能なパターンまたは契約と考えてください。**入力変数または出力変数のデータ型、変数名、特定のパターンに表示する (または表示しない) 情報など、これらは効果的な API 管理のための鍵です。これらの定義は設計標準に表示され、チームはドキュメントを使用してこれらの定義がシステムの特定の部分でどのように実装されているかを見つけることができます。新しい開発からインテグレーション環境への変更をマージすることの難しさを把握する 1 つの方法は、変更を API 通信の実装が不十分な (または API 定義がまったくない) 場所の証拠とみなすことです。
- **API に対する考え方をコードに限定しないでください。**このコンテキストで API を定義するのは、そのメッセージ内のメッセージ構造と変数の一貫性です。この一貫性が維持されている限り、API はコードだけでなく、モジュール化された自動起動 (またはプラットフォームイベントトリガー) フローやフローテンプレートなどの宣言型カスタマイズにも実装できます。API 実装ではなく、[パッケージ化](/docs/architect/ja-jp/well-architected/guide/composable#パッケージ性)可能性と[テスト可能性](/docs/architect/ja-jp/well-architected/guide/resilient#アプリケーションライフサイクル管理)に基づいて、コードで何を定義するか、フローで何を定義するかを決定します。

- ライフサイクルとバージョン管理を**シンプルにし**ます。アプリケーション開発のすべての部分と同様に、API にもライフサイクル (定義、構築、テスト、リリース、メンテナンス (廃止を含む)) があります。Salesforce Platform API では、プラットフォームのリリースサイクルが短いため、1 年のうちに複数のバージョンがリリースされます。(この動作についての詳細は、「Salesforce [アーキテクチャの基本](/docs/architect/ja-jp/fundamentals/guide/architecture-basics#プラットフォーム-api)」を参照してください)。つまり、プラットフォーム API のライフサイクルはかなり複雑です。特定の API の複数のバージョンを Salesforce のユーザーが維持して使用できるようにする必要があるためです。このレベルの複雑さは PaaS の使用事例に適していますが、プラットフォーム上のソリューションアーキテクチャでは不要な複雑さである可能性が高くなります (以下を参照)。[アクセシビリティアンチパターン](/docs/architect/ja-jp/well-architected/guide/intentional#読みやすさパターンとアンチパターン))。API の明確な目的 (エラー処理など) と明確なベースライン定義を定義することに集中します。各 API の 1 つのバージョンのみを使用するようにします。
- **API の検出、アクセス、管理を容易にします。**[API をドキュメント](/docs/architect/ja-jp/well-architected/guide/intentional#設計標準)化して、潜在的なコンシューマーが利用可能な API を簡単に見つけられるようにします。API は[、機能](/docs/architect/ja-jp/well-architected/guide/composable#機能単位)の一部としてスムーズに機能する必要があります。
- **反復型**。一度に 1 つの内部 API の定義と実装のみに集中します。これにより、API 定義を迅速に反復することに集中し、サポート対象の*1 つ*のバージョンに適した形式を見つけて、実装の経験からベスト・プラクティスを確立できます。

次の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/composable#相互運用性パターンとアンチパターン)のリストは、Salesforce ソリューション内での API 管理の適切さ (および適切でない) を示しています。これらを使用して、構築前に設計を検証したり、システムのリファクタリングが必要な領域を特定したりできます。

相互運用性の向上に役立つ Salesforce から入手できるツールについての詳細は、「[Tools Relevant to Composable](/docs/architect/ja-jp/well-architected/guide/composable#コンポーザブルに関連するツール) (コンポーザブルに関連するツール)」を参照してください。

### 相互運用性パターンとアンチパターン

次の表に、組織で検索 (または作成) するパターンと、回避または修正の対象となるアンチパターンの選択を示します。

✨ [パターン & アンチパターンエクスプローラー](/docs/architect/ja-jp/well-architected-tools/guide/adaptable-interoperability)で相互運用性に関するより多くのパターンを見つけます。

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">パターン</th>
            <th scope="colgroup">アンチパターン</th>
        </tr>
        <tr>
            <td rowspan="3"><b>メッセージングとイベント</b></td>
            <td><b>設計基準では、次のようになります。</b>
                <br> - 同期パターン (メッセージング) と非同期パターン (イベント) を使用する状況に関する明確な標準が存在する
                <br> - イベントおよびメッセージ構造には明確な標準がある
            </td>
            <td><b>設計基準では、次のようになります。</b>
                <br> - 設計標準が存在しないか、同期パターンと非同期パターンの明確な標準やメッセージまたはイベント構造の明確な標準がない
            </td>
        </tr>
        <tr>
            <td><b>組織内：</b>
                <br> - 内部システムメッセージングに使用されるプラットフォームイベントの表示ラベルが明確である
                <br> - Salesforce フローツールでシステム全体のメッセージングまたはイベントサービスを参照する
                <br> -一貫したメッセージングとイベントパターンがフローとコードに表示される
            </td>
            <td><b>組織内：</b>
                <br> - 内部システムメッセージングに使用されるプラットフォームイベントの表示ラベルが明確でない、または存在しない
                <br> - メッセージングパターンとイベントパターンのさまざまな戦略がフローとコードで表示される
            </td>
        </tr>
        <tr>
            <td><b>Apex または LWC の場合:</b>
                <br> - カスタムイベント定義の範囲が制限される (システム全体のイベントやメッセージがコードで定義されない)
                <br> - Apex のシステム全体のメッセージングサービスまたはイベントサービスは、Salesforce フローツールで使用できるようにアノテーションが付けられます。
            </td>
            <td><b>Apex または LWC の場合:</b>
                <br> -システム全体のメッセージおよび/またはイベント構造がApexまたはJavaScriptで定義されている
                <br> - Apex で定義されたシステム全体のイベント構造またはメッセージ構造をフローなどのツールで使用できない
            </td>
        </tr>
         <tr>
            <td rowspan="3"><b>API 管理</b></td>
            <td><b>設計基準では、次のようになります。</b>
                <br> - クロスコンポーネント通信用の明確なプロトコル (API) が存在する
                <br> - プロトコル/API は、ビルダーが検索および検索できる論理グループにまとめられています。
                <br> -プロトコル/API により、変数のデータ型、変数名、必須または省略可能を定義し、使用する状況を明確に説明
            </td>
            <td><b>設計基準では、次のようになります。</b>
                <br> - 設計標準が存在しないか、API と使用事例を定義していない
            </td>
        </tr>
        <tr>
            <td><b>ドキュメント:</b>
                <br> - すべてのコンポーネントのドキュメントに、実装済みの API/通信プロトコルが明記されている
                <br> -特定の API またはプロトコルを検索し、それが実装されているコンポーネントを識別できる
            </td>
            <td><b>ドキュメント:</b>
                <br> - コンポーネントのドキュメントが存在しない
                <br> - コンポーネントドキュメントにはコンポーネント内に実装された API が記載されていますが、API 定義が表示されるのはここのみです。
                <br> -特定の API またはプロトコルを検索できない、または API またはプロトコルが実装されたコンポーネントを特定できない
            </td>
        </tr>
        <tr>
            <td><b>組織内：</b>
                <br> - 内部コミュニケーション用の API メッセージ形式と変数がカスタムメタデータ型で定義されている
                <br> - 内部コミュニケーション用の API メッセージ形式と変数がプラットフォームイベントで定義されている
                <br> - コードおよび宣言型カスタマイズでは、情報を送受信するために適切なカスタムメタデータ型 (またはプラットフォームイベント) を参照します。
            </td>
            <td><b>組織内：</b>
                <br> - システムのコンポーネント間 (コードおよび宣言型カスタマイズ) の通信がアドホックである
                <br> - API は、Salesforce と外部システム間の通信専用に定義されています。
            </td>
        </tr>
    </tbody>
</table>

## パッケージ性

Salesforce 組織でパッケージ化可能性を作成するということは、組織の機能は、パッケージとして独立して信頼性高く開発およびリリースできるユニットから取得されるということです。これらの単位は、第 [2 世代](https://developer.salesforce.com/docs/atlas.en-us.218.0.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp_plan_pkg_types.htm)パッケージ (ISV のロック解除済みパッケージまたは管理パッケージ) の種別として定義するのが理想的です。注意:適切に設計されたソリューションでは、これらのパッケージ種別が排他的に使用されるため、ここでは第一世代管理パッケージについては説明しません。

[懸念事項の分離](/docs/architect/ja-jp/well-architected/guide/composable#懸念事項の分離)を定義して、Salesforce 組織で機能ユニットを作成することは別問題です。連動関係を明確に把握して管理することで、これらのユニットをパッケージアーティファクトとして正常にバージョン管理することができます。このレベルの安定性とメタデータの分離を実現するには、DevOps (およびアーキテクチャ) の成熟度を大幅に高める必要があります。また、開発時間が短縮され、アプリケーションビルダーの環境が改善され、リリースとリリース管理の予測可能性と制御が可能になります。すべての組織が効果的なパッケージの定義、管理、開発に必要なインフラストラクチャをサポートできるとは限りません。ただし、パッケージ化の達成は、ほぼすべての Salesforce 組織にとって最終的な目標です。

疎結合と連動関係の管理に重点を置くことで、Salesforce ソリューションのパッケージ化可能性を高めることができます。

### 疎結合

疎結合系では、個々のピースは強く結び付きません。合成可能なシステムの利点の多くは疎結合にあります。パッケージ化可能なシステムでは、パッケージ間の疎結合 (および組織のインストール) を実現することで、パッケージを明確に定義し、パッケージを使用するチームの開発サイクルの生産性を高めることができます。

Salesforce Platform では、特定の[組織に密結合](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_org_dependent.htm)されたパッケージを作成できます。この機能は、パッケージの成熟度が進むにつれて、機能単位を定義したり、組織で適切[な懸念事項の](/docs/architect/ja-jp/well-architected/guide/composable#懸念事項の分離)分離を試したりするのに役立ちます。ただし、この方法を選択した場合、ソース駆動開発、バージョン管理の使用、アーティファクトの安定性など、真にパッケージ化可能なメタデータの利点はほとんど実現されません。代わりに、次のような密結合システムの欠点が引き続き発生する可能性があります。

- 停止とパフォーマンスの問題を引き起こす単一障害点
- 低速で予測不能なリリース
- 困難で複雑なデバッグおよびトラブルシューティングサイクル
- [拡張性](/docs/architect/ja-jp/well-architected/guide/reliable#拡張性)と[パフォーマンス](/docs/architect/ja-jp/well-architected/guide/reliable#performance)の問題

パッケージ化可能な Salesforce システムの最終目標は、疎結合パッケージです。

Salesforce メタデータを効果的なパッケージに分割する場合は、次の点を考慮してください。

- **カスタマイズとは、データとメタデータです。**パッケージ化可能性に関しては、Salesforce Platform ではデータとメタデータの処理が大きく異なります。組織のどの機能が[メタデータまたは](/docs/architect/ja-jp/fundamentals/guide/architecture-basics#メタデータとデータ)データであるかを理解することが重要です。パッケージ化された単位にデータを含めることはできません。パッケージ化されたユニットへの機能の抽象化を開始する場所を決定するときに、チームはデータとして保存されているカスタマイズをパッケージから完全に除外するか、メタデータベースの実装にリファクタリングするかを決定する必要があります。
- **パッケージ化がチーム**に与える影響。Salesforce のパッケージ化の物流上の現実は、パッケージバージョンの作成とリリース作業の多くで、Salesforce CLI や CI/CD テクノロジーのスキルが必要であるということです。つまり、ローコードのカスタマイズもプログラムによるカスタマイズも、パッケージ関連の DevOps テクノロジーを操作できる担当者による時間と注意が必要になります。チームが機能配信を管理する方法によっては、パッケージの採用によって、組織全体のさまざまなチームに大幅な遅延や阻害要因が発生する可能性があります。チームがパッケージによる機能配信を管理できるかどうかを特定し、スキルやスタッフのギャップに対処する計画を立てる必要があります。ソリューションには、ペアプログラミングの採用や、開発環境の CI/CD ジョブの実装などがあります。
- **パッケージ化によって環境戦略がどのように変化するか。**パッケージ主導の開発ライフサイクルでは、初期の作業は[ゼロ組織](https://developer.salesforce.com/docs/atlas.en-us.238.0.sfdx_setup.meta/sfdx_setup/sfdx_setup_next_steps.htm?q=scratch%20org)で実行する必要があります。これらの一時的なソース駆動開発環境により、サイクルの反復性が高まります。また、開発チームのより詳細な環境アクセス制御と本番組織からの分離もサポートされます。Sandbox または本番環境にのみ存在するパッケージ化されていないメタデータやデータへのパッケージの連動関係が多いほど、チームがスクラッチ組織を実際に使用できる可能性が低くなります。[Sandbox でソース追跡](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_setup_enable_source_tracking_sandboxes.htm)を有効にして、スクラッチ以外の組織環境でのソース駆動型開発パターンを許可できますが、開発チームはスクラッチ組織の速度と反復速度の恩恵を受けません。
- **パッケージバージョンとリリース**の関係。開発パッケージのバージョン管理の頻度とフェーズを計画します。パッケージバージョン要求は 24 時間周期で制限されます (組織ごと)。一般的なベストプラクティスとして、パッケージのバージョン管理は、どのパッケージの内容も変更する必要がないことが確信できる場合にのみ行います。理想的には、品質保証プロセスが完了した後にパッケージバージョンをプロビジョニングします。開発チームがパッケージ作成要求の成功または失敗を、パッケージ境界をどの程度適切に定義しているかの「テスト」として使用できないようにします。これを行うには、パッケージアーティファクトのバージョン管理を試行しない方法があります。
- 理想的な最終状態で**サポートされる**もの。理想的なパッケージ戦略により、Salesforce リリースを迅速に開発して提供でき、安定的に管理できます。組織全体で定義するパッケージが多すぎると、開発チームが新しい種類の複雑さやボトルネックになる可能性があります。過度にモジュール化された組織では、リリースが遅くなり、困難になる可能性もあります。まず、1 つの意味のあるパッケージのいくつかのバージョンを作成してリリースします。後続のパッケージを段階的に取得します。ビジネスに役立つリリースケイデンスができた時点で、パッケージの導入を停止します。ビジネスニーズの変化やリリース品質の低下に応じて、パッケージを経時的にリファクタリングします。理想的なパッケージの最終状態は主観的です。

パッケージの定義方法に関係なく、疎結合パッケージのバージョン管理は、効果的な[連動関係管理](/docs/architect/ja-jp/well-architected/guide/composable#連動関係管理)によってのみ正常に行われます。

次の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/composable#パッケージ化可能性パターンとアンチパターン)のリストは、Salesforce パッケージでの適切な (および不適切な) 疎結合を示しています。これらを使用して、構築前に設計を検証したり、システムのリファクタリングが必要な領域を特定したりできます。

パッケージ性の向上に役立つ Salesforce ツールについての詳細は、「[Tools Relevant to Composable](/docs/architect/ja-jp/well-architected/guide/composable#コンポーザブルに関連するツール) (コンポーザブルに関連するツール)」を参照してください。

### 連動関係管理

Salesforce ソリューションのコンテキストでの連動関係管理とは、パッケージのメタデータと、それらのパッケージをインストールする組織のメタデータ間のリレーションを特定して構造化することです。連動関係管理は、安定したパッケージアーティファクトを開発するうえで重要です。

連動関係は、完全に分離され、[疎に結合](/docs/architect/ja-jp/well-architected/guide/composable#疎結合)された機能ユニットを作成する努力と対立する可能性があります。理想的なエンジニアリング状態では、疎結合のシステムはユニット間の連動関係がありません。ただし、実際には、すべての連動関係を削除することは現実的ではありません。

多くの場合、システムを[読みやすく](/docs/architect/ja-jp/well-architected/guide/intentional#読みやすさ)することと、ビジネスに適した[機能ユニット](/docs/architect/ja-jp/well-architected/guide/composable#機能単位)を使用することのバランスを取るには、システム内のユニットを完全に分離するというトレードオフが必要です。より現実的には、Salesforce Platform の[標準機能](/docs/architect/ja-jp/well-architected/guide/intentional#標準機能とカスタム機能)によって提供されるコア サービスによって、Salesforce ソリューションの主要なネット ポジティブ連動関係が作成されます。拡張性、パフォーマンス、およびセキュリティに関する多くの組み込みの利点は、それらがプラットフォームにどれほど深く統合されているかに起因します。パッケージ化可能な Salesforce ソリューションを設計する場合、パッケージの連動関係は本質的に悪いものではないことに注意してください。不十分な連動関係管理*は*悪いことです。

Salesforce パッケージを使用した効果的な連動関係管理により、開発チームとメンテナンスチームは次のことができます。

- 新しいプロジェクトへの迅速なオンボーディングと制限された環境アクセス
- 変更をすばやく開発してテストする
- 複雑な機能を小さく具体的なコミットメントでどのように提供すべきかを理解する
- リリース頻度を制御し、システムメンテナンス/リリース停止期間を短縮
- あらゆる環境での悪影響を予測的にロールバック

Salesforce を使用した連動関係管理の手法は非常に簡単です。

- [メッセージングとイベント](/docs/architect/ja-jp/well-architected/guide/composable#メッセージングとイベント)を使用して、コンポーネント間のステートフルまたはステートレス情報の適切な引き継ぎを処理します。
- カスタムメタデータ型を使用して、動的な実行時情報を提供し、連動関係インジェクションパターンをサポートします。
- Apex 開発者に抽象クラスまたは[仮想クラス](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_extending.htm)を使用させる。

最終的には、宣言型開発とプログラム開発の両方で組織で使用できるデザインパターンを決定する必要があります。(アーキテクチャ上の) 最も重要な考慮事項は、連動関係を減らすためにエンジニアリングの複雑さを増す箇所と、アプリケーションビルダーのワークフローを簡略化するためにより多くの連動関係を許容する必要がある箇所を定義することです。

連動関係管理戦略をパッケージに組み込む場合は、パッケージ単位に関する 2 つの主要な整理原則 (水平と垂直) を考慮してください。

- **水平境界**。水平パラダイムでは、複数のパッケージで必要とされる可能性のある機能が水平レイヤーに抽象化されます。水平レイヤーは共通の機能のソースになり、宣言された連動関係を介してアクセスします。パッケージ間で重複する機能を最小限に抑えることは、連動関係を最小限に抑えることよりも優先されます。
- **縦方向の境界**。垂直パラダイムでは、システムの部分間の分離と疎結合が最大化されます。共有機能は制限され、ユニット間で同様の作業が表示されることがあります。パッケージ単位間の分離を最大化するために、連動関係は厳密に制限されます。

これは決定事項ではないことに注意してください。必要に応じて、縦方向と横方向のパラダイムを組み合わせることができます。多くの場合、パッケージから開始する最も早い方法は、水平サービスレイヤーを作成することです。パッケージの採用の規模と複雑さが大きくなるにつれて、縦方向の単位を抽象化することで、複雑な環境設定プロセスや開発者のオンボーディングを簡略化できます。

たとえば、2 つの機能単位 (A と B) があるシステムは、縦方向、横方向、および縦-横方向のハイブリッドパラダイムで配置されたパッケージ連動関係で構造化できます。

<a href="https://a.sfdcstatic.com/developer-website/prod/images/architect/composable-vertical-horizontal-slices.jpeg" target="_blank">
    <img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/composable-vertical-horizontal-slices.jpeg" alt="次の図は、A と B の 2 つのパッケージを示しています。これらは、共有連動関係を持たないように構築され (縦のスライス)、多くの共通サービスを持ち (横のスライス)、それぞれが混在するように構築されています (ハイブリッド)。">
</a>

選択するパッケージ整理パラダイムに関係なく、次の点に留意してください。

- **パッケージ間でメタデータを複製しないでください。**複数のパッケージで必要なメタデータは、連動関係として宣言された 1 つ以上のパッケージに抽象化する必要があります。
- **Salesforce Platform メタデータの組み込み連動関係を活用します。**アプリケーションビルダーの場合、Salesforce Platform が提供する組み込みサービスでは、すばやく設定できる多くの機能が提供されます。これらのサービスの多くには組み込み連動関係があり、下位レベルの機能単位に抽象化することは困難です。特定のメタデータ型の場合、それが組み込み[連動関係](https://developer.salesforce.com/blogs/2018/06/lets-talk-deployment-and-reasons-why-they-succeed-or-fail)のどこに当てはまるかを理解し、その理解に基づいて[パッケージ連動関係チェーンを](https://developer.salesforce.com/blogs/2018/06/working-with-modular-development-and-unlocked-packages-part-2)定義する必要があります。多くの組み込み連動関係を持つ標準プラットフォーム機能に無理に疎結合を組み込むことで、パッケージの採用を開始しないでください。高次の機能に到達するにつれて (値ではなく) 複雑さが増します。また、[標準対カスタム](/docs/architect/ja-jp/well-architected/guide/intentional#標準機能とカスタム機能)[のアンチパターン](/docs/architect/ja-jp/well-architected/guide/intentional#メンテナンス性パターンとアンチパターン)に分類される別の方法もあります。メタデータを下から (連動関係が最も少ない) 上にパッケージ化し、経時的に反復します。
- **連動関係チェーン**に注意してください。開発者が一度に多くの異なるパッケージに変更を分割する必要があるパッケージ連動関係チェーンの作成は避けてください。
- **ソース制御**に何が適しているかを考えます。ソース制御でパッケージを管理する基本的な方法は 2 つあります。1 つ目は、パッケージがフォルダ内で分離されている 1 つの*独占*リポジトリです。2 つ目は、パッケージが独自のリポジトリに隔離されている複数のリポジトリです。各種ソース戦略の長期的な管理には複雑さがあります。開発者のオンボーディングの観点では、複数のリポジトリパラダイムで縦方向の境界がより効率的です。横方向の境界は、独占情報でよりわかりやすくなります。ここでも、アーキテクチャの成熟に合わせて戦略を組み合わせることができます。

次の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/composable#パッケージ化可能性パターンとアンチパターン)のリストは、Salesforce パッケージでの適切な (および不適切な) 連動関係管理を示しています。これらを使用して、構築前に設計を検証したり、システムのリファクタリングが必要な領域を特定したりできます。

連動関係管理用の Salesforce ツールについての詳細は、「[Tools Relevant to Composable](/docs/architect/ja-jp/well-architected/guide/composable#コンポーザブルに関連するツール)」を参照してください。

### パッケージ化可能性パターンとアンチパターン

次の表に、組織で検索 (または作成) するパターンと、回避または修正の対象となるアンチパターンの選択を示します。

✨ [パターン & アンチパターンエクスプローラー](/docs/architect/ja-jp/well-architected-tools/guide/adaptable-packageability)でパッケージ化可能なパターンをさらに見つけます。

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">パターン</th>
            <th scope="colgroup">アンチパターン</th>
        </tr>
        <tr>
            <td rowspan="5"><b>疎結合</b></td>
            <td><b>設計基準では、次のようになります。</b>
                <br> - 命名規則では、パッケージ単位の表記方法を指定します。
                <br> 現在定義されているすべてのパッケージ単位 (および関連する命名規則) のリストを検索して見つけることができます。
                <br> ・パッケージ単位の追加や変更の提案基準が存在する
                <br> - (省略可能) カスタム設定の承認済み使用事例がすべて明確にリストされている (ある場合)
            </td>
            <td><b>設計基準では、次のようになります。</b>
                <br> - 設計標準が存在しないか、パッケージ単位と使用事例を扱っていない
            </td>
        </tr>
        <tr>
            <td><b>組織内：</b>
                <br> - カスタムメタデータ型により、コードおよび宣言型カスタマイズの動的な実行時情報が提供されます。
                <br> - カスタム設定が存在しないか、カスタム設定がほとんど存在せず、パッケージ化された機能に関連するものがない
                <br> - コードまたは宣言型カスタマイズの動的かつ実行時情報を提供するカスタムオブジェクトが存在しない
            </td>
            <td><b>組織内：</b>
                <br> - カスタム設定が使用される
                <br> - カスタムオブジェクトは、コードまたは宣言型カスタマイズの動的な実行時情報を提供する目的で存在します。
                <br> - カスタムメタデータ型は、コードおよび宣言型カスタマイズの動的かつ実行時情報を提供するのに使用されない (または一貫して使用されない)
            </td>
        </tr>
        <tr>
            <td><b>Apex:</b>
                <br> Common Services およびボイラープレートコードは、抽象または仮想 Apex クラスを使用して定義されます。
                <br> - 動的で実行時の情報に依存するメソッドは、適切なカスタムメタデータ型を参照します。
            </td>
            <td><b>Apex:</b>
                <br> - Common Services とボイラープレートコードが他のクラスと容易に区別されない
                <br> - クラスやメソッド間の内部参照が追跡しづらく、コードベース全体で一貫性がない
                <br> - メソッドが動的で実行時の情報にアクセスするために一貫した方法を使用していないか、メソッドがカスタムオブジェクトで実行時の動作情報を照会しているか、コードがカスタム設定を参照している
            </td>
        </tr>
        <tr>
            <td><b>ソース制御および開発環境の場合:</b>
                <br> - package.xml ファイルは、初期段階または概念実証プロジェクトマニフェストにのみ表示されます。
            </td>
            <td><b>ソース制御および開発環境の場合:</b>
                <br> - package.xml ファイルはメタデータリリースの制御に使用されます。
            </td>
        </tr>
        <tr>
            <td><b>パッケージ内：</b>
                <br> -組織依存のロック解除済みパッケージは、初期段階または概念実証実験でのみ使用されます。
                <br> - 本番または Sandbox で未管理パッケージが定義されていない
            </td>
            <td><b>パッケージ内：</b>
                <br> - すべてのパッケージが組織依存のロック解除済みパッケージである
                <br> - 未管理パッケージが本番または Sandbox で定義されている
            </td>
        </tr>
         <tr>
            <td rowspan="4"><b>連動関係管理</b></td>
            <td><b>設計基準では、次のようになります。</b>
                <br> - 連動関係を宣言するための基準が存在する
                <br> - 連動関係の導入または変更に関する基準が存在する
            </td>
            <td><b>設計基準では、次のようになります。</b>
                <br> - 設計標準が存在しないか、連動関係の宣言方法を扱っていない
            </td>
        </tr>
        <tr>
            <td><b>ソース制御：</b>
                <br> - ロック解除済みパッケージのパッケージバージョンでは、別名 (<code>最新</code>) を使用して <code>sfdx-project.json</code> マニフェストで連動関係を宣言します。
                <br> -開発者はスクラッチ組織を作成し、ソース制御からパッケージメタデータを正常にリリースできます。
            </td>
            <td><b>ソース制御：</b>
                <br> - ロック解除済みパッケージのパッケージバージョンが <code>sfdx-project.json</code> マニフェストで明示的に宣言されている (<code>最新の</code>別名がない)
                <br> - 開発者がソース制御を使用してスクラッチ組織で正常に作業できない
            </td>
        </tr>
        <tr>
            <td><b>パッケージ内：</b>
                <br> -パッケージ間でメタデータが重複しない
                <br> -パッケージ開発の場合、初期段階の開発作業はすべてスクラッチ組織で行われます。
            </td>
            <td><b>パッケージ内：</b>
                <br> -異なるパッケージのメタデータを複製することで連動関係を回避
                <br> - 早期パッケージ開発は Developer Sandbox で行われるか、早期パッケージ開発はスクラッチ組織では実行できません。
            </td>
        </tr>
        <tr>
            <td colspan="2">関連トピック:<a href="/docs/architect/ja-jp/well-architected/guide/composable#疎結合">疎結合</a></td>
        </tr>
    </tbody>
</table>

## コンポーザブルに関連するツール

<table class="tools-table"><tbody><tr><th>ツール</th><th>説明</th><th>懸念事項の分離</th><th>相互運用性</th><th>パッケージ性</th></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_rest.htm">Apex REST Webサービス</a></td><td>ApexクラスおよびメソッドをREST経由で外部アプリケーションに公開</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_web_services.htm#apex_web_services">Apex SOAP Web サービス</a></td><td>Apex クラスおよびメソッドを SOAP 経由で外部アプリケーションに公開する</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">変更データキャプチャ</a></td><td>Salesforce レコードへの変更を公開</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.custommetadatatypes_overview.htm&language=en_US&r=https%3A%2F%2Fwww.google.com%2F&type=5">カスタムメタデータ型</a></td><td>再利用可能なカスタマイズ可能なパッケージ化可能な機能を定義する</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/component-library/documentation/en/lwc/reference_decorators">デコレーター</a></td><td>API として関数またはプロパティを公開</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_setup_enable_devhub.htm">Dev Hub</a></td><td>スクラッチ組織、第二世代パッケージ、Einstein機能を管理します。</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/generic_streaming_intro.htm">一般的なイベント (従来)*</a></td><td>Salesforce データの変更に関連付けられていないカスタムイベントの送信</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.data_ui_api">Lightning Data Service</a></td><td>コンポーネント間でのデータのキャッシュと共有</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_intro.htm">メタデータ API</a></td><td>Salesforce 環境間のカスタマイズのリリース</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_supported_mdapi_types.htm">メタデータカバー率レポート</a></td><td>複数のチャネルでサポートされるメタデータの対象範囲を決定する </td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://docs.mulesoft.com/composer/ms_composer_overview">MuleSoft Composer</a></td><td>コードではなくクリックを使用してデータのプロセスの自動化を構築</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging.htm">送信メッセージ</a></td><td>項目値の更新時に外部エンドポイントにメッセージを送信</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">プラットフォームイベント </a></td><td>ほぼリアルタイムのイベントデータを含む安全でスケーラブルなメッセージを送信する</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/blogs/2021/07/pub-sub-api-building-event-driven-integrations-just-got-even-easier">Pub/Sub API</a></td><td>プラットフォームイベント、変更データキャプチャ、またはリアルタイムイベント監視への登録</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/pushtopic_events_intro.htm">PushTopic イベント (従来)*</a></td><td>ユーザー定義の SOQL クエリに一致する変更通知の送受信</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/tools/sfdxcli">Salesforce CLI</a></td><td>Salesforce 組織で作業するときの自動化の開発と構築</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="/docs/architect/ja-jp/reference-diagrams/guide/introduction">Salesforce の図</a></td><td>ビジネス能力と技術的な詳細を示す図を作成する</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://marketplace.visualstudio.com/items?itemName=salesforce.salesforcedx-vscode-expanded">Visual Studio Code 向け Salesforce 拡張機能 (拡張)</a></td><td>Salesforce 開発の公式 VS Code 拡張機能</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_scratch_orgs.htm">スクラッチ組織</a></td><td>Salesforce コードとメタデータを破棄可能な組織にリリースする</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp.htm">第二世代管理パッケージ</a></td><td>AppExchange 向けアプリケーションの開発と配布</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api_tooling.meta/api_tooling/intro_tasks.htm">Tooling API</a></td><td>Lightning プラットフォームアプリケーション用のカスタム開発ツールまたはアプリケーションの作成</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_intro.htm">ロック解除済みパッケージ</a></td><td>メタデータの整理、アプリケーションのパッケージ化、AppExchange アプリケーションの拡張</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr>
<td colspan="5">*Salesforce は、現在の機能の範囲内で引き続き PushTopic および Generic Events をサポートしますが、この技術にさらに投資する予定はありません。</td>
</tr>
</table>

## コンポーザブルに関連するリソース

<table class="tools-table"><tbody><tr><th>リソース</th><th>説明</th><th>懸念事項の分離</th><th>相互運用性</th><th>パッケージ性</th></tr>
<tr><td><a href="https://blogs.mulesoft.com/api-integration/strategy/a-primitive-look-at-digital-integration/">デジタルインテグレーションのプリミティブな考察</a></td><td>接続の概念の共通言語を開発する</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://medium.com/p/cd4b7ebe926b">Salesforce を使用したドメイン駆動設計の適用</a></td><td>ビジネス機能に関するソリューション指向</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.218.0.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp_plan_best_practices.htm">第二世代パッケージのベストプラクティス</a></td><td>2GP パッケージ化のパターンと方法を理解する</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.238.0.sfdx_dev.meta/sfdx_dev/packaging_packageable_components.htm">管理パッケージで使用可能なコンポーネント</a></td><td>管理パッケージメタデータコンポーネントを理解する</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="/docs/architect/ja-jp/resources/guide/design-standards-template">設計標準テンプレート</a></td><td>組織の設計標準を作成する</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="/docs/architect/ja-jp/decision-guides/guide/event-driven">イベント駆動型アーキテクチャ決定ガイド</a></td><td>イベント駆動型アーキテクチャのパターンとツールの比較</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/events_anti_patterns.htm">イベントのアンチパターン</a></td><td>イベントを使用するときに避けるべきアンチパターンの特定</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://blogs.mulesoft.com/dev-guides/design-message-driven-and-event-driven-apis/">メッセージ駆動型およびイベント駆動型の API の設計方法</a></td><td>MuleSoft 開発者ガイドで違いを確認する</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/en/content/learn/modules/jobs-to-be-done-framework-for-designers/learn-about-the-jobs-to-be-done-framework">完了すべきジョブフレームワークについて</a></td><td>Trailhead での JTBD の探索</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/commerce/pwa-kit-managed-runtime/guide/managing-global-state.html">B2C Commerce でのグローバル状態の管理</a></td><td>コンポーネント間でデータを簡単に渡して状態を維持</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://www.lightningdesignsystem.com/guidelines/messaging/overview/">メッセージングガイドライン</a></td><td>関連情報を伝え、喜びの瞬間を作り出す</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.lightningdesignsystem.com/guidelines/messaging/types/">メッセージング種別</a></td><td>ユーザー操作の性質によるさまざまなメッセージング種別の理解</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.238.0.api_meta.meta/api_meta/meta_types_list.htm">メタデータ型</a></td><td>Salesforce 組織のさまざまなメタデータの種別を理解する</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.salesforce_app_enable_push_notifications.htm&type=5">モバイルアプリケーション通知種別</a></td><td>Salesforce モバイルアプリケーションの通知種別について</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_visualforce_best_practices.meta/salesforce_visualforce_best_practices/pages_best_practices_perf_code_view_state.htm">ビューステートの最適化</a></td><td>Visualforce ページでの状態の維持</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_intro.htm">Salesforce 開発者エクスペリエンス (DX)</a></td><td>Lightning プラットフォームでのアプリケーションの管理および開発</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_unsupported_types.htm">サポートされないメタデータ型</a></td><td>メタデータ API で使用できないコンポーネントを特定する</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
</table>

## ご意見をお聞かせください

Salesforce Well-Architected の関連性の維持にご協力ください。このコンテンツに関するフィードバックをいただくため[のアンケート](https://sfdc.co/bxNtvh)にご協力ください。また、今後の展望についてもお聞かせください。

<!-- document id=bced1428938c98d5013fc92f88f36cf52c00b54320a30e6b32571cfd9e0c7705 url=/architect/next/ja-jp/well-architected/guides/reliable.md -->

> 更新スケジュールについては、[こちら](/docs/architect/ja-jp/well-architected/guide/contributors)を参照してください。

## はじめに

信頼性の高いソリューションは、効果的かつ確実に動作します。可用性と一貫したパフォーマンスを備え、成長するビジネスをサポートする拡張性を備えています。

信頼性の高いシステムは、エラーが発生しにくく、期待どおりに動作し、タイムリーに結果を提供します。逆に、信頼性の低いシステムは動作が遅く、期待どおりに動作しないか、重要なタイミングで失敗します。信頼性の低いシステムは、不正確な情報を提供するため、関係者はビジネス上の意思決定でシステムを Trust できません。

システムの信頼性は一定ではありません。現在の信頼性が高いシステムは、成長に合わせて設計されていないと、信頼性が低下する可能性があります。信頼性の低いシステムでは、コストのかかるメンテナンス、リファクタリング、再実装が必要になり、戦略的プロジェクトから資金が回らなくなる場合があります。

[可用](/docs/architect/ja-jp/well-architected/guide/reliable#可用性)性、[パフォーマンス](/docs/architect/ja-jp/well-architected/guide/reliable#performance)、[拡張性](/docs/architect/ja-jp/well-architected/guide/reliable#拡張性)の 3 つの原則に重点を置き、Salesforce ソリューションの信頼性を向上させます。[Salesforce のスケーラビリティ製品スイート](https://www.salesforce.com/platform/application-scaling-performance-testing/)は、アーキテクトが信頼性の高い実装を運用できるようにするネイティブ機能を提供します。

## 可用性

可用性は、システムが稼働している時間の割合を表します。Salesforce Platform は、ほとんどの[インフラストラクチャレベルの](https://trust.salesforce.com/)可用性の問題に対応します。ただし、プラットフォームで構築し、顧客が経験するソリューションの可用性は、共通の責任です。Salesforce の[高可用性](https://trust.salesforce.com/en/#systemStatus)があっても、サービスが中断されるリスクがゼロになることはありません。

アーキテクトは、計画メンテナンスや予期しない状況などの Salesforce サービスの中断に備える必要があります。サービスの中断に加えて、ハイ パフォーマンスを維持し、ビジネスの成長に合わせて拡張する方法を検討します。アーキテクチャの選択肢が狭いと、長期的な可用性の問題が発生する可能性があります。

ソリューションを構築する*前*の設計フェーズで可用性を検討します。可用性に関する設計を先延ばしにするほど、長期的には可用性の問題の実際のコストは高くなります。潜在的なリスクを軽減するには、テスト環境で Salesforce スケールテストを使用します。この環境では、コードを本番にリリースする前に本番の規模でテストできます。

アーキテクトは、ビジネスの言語を使用して、ビジネスの関係者の技術的な懸念をまとめ、賛同を得て可用性作業に優先順位を付けます。潜在的なリスクを軽減するには、テスト環境で Salesforce スケールテストを使用します。この環境では、コードを本番にリリースする前に本番の規模でテストできます。

[リスク管理](/docs/architect/ja-jp/well-architected/guide/reliable#リスク管理)と[障害の軽減](/docs/architect/ja-jp/well-architected/guide/reliable#障害の軽減)を通じて、Salesforce ソリューションの可用性を高めることができます。

### リスク管理

Salesforce アーキテクチャのコンテキストでリスクを管理するには、システムの動作、ユーザー (従業員、パートナー、顧客など)、およびビジネスプロセスに対する潜在的な危険を特定します。多くの場合、リスク分析を実施する正式なプロセスは、プロジェクトマネージャーの責任になります。アーキテクトは、リスク分析が技術およびビジネスの関係者の懸念を適切に表すようにします。また、本番ピーク時のホットスポットに基づいてスケールテストする必要があるビジネスクリティカルな使用事例を特定することも、ユーザーの責任です。

リスク管理における最大の落とし穴は、十分な時間と思考を割かなかったことにあります。チームは多くの場合、リスク評価をスキップします。または、データの整合性に対するリスクを軽減する重要な部分である[バックアップとリストア](/docs/architect/ja-jp/well-architected/guide/resilient#バックアップおよび復元機能の構築)の解決と、包括的なリスク評価および軽減を混同します。

Salesforce ソリューションのリスクを評価するには、次の方法を使用します。

- **リスク評価フレーム**ワーク。一部の大企業では、関連するリスクマトリックスがすでに用意されている場合があります。その場合、それらを使用して、危険の分類方法、収集する情報の種類、修復のために配置する必要がある情報などを決定します。まだリスク評価フレームワークがない場合は、信頼できるソースから見つけて使用します。
- **顧客の視点から影響の重要度とリスクカテゴリを評価します**。Proactive Monitoring and Scale Center では、設定可能なアラートとダッシュボードが提供されます。パフォーマンスと拡張性のリスクを継続的に評価し、手動チェックリストへの依存を減らします。Customer Trust と認識は、すべてのビジネスにとって重要です。ビジネスへの影響の観点から見ると、通常、顧客にリーチした問題のリスクは、リーチしなかった問題のリスクよりも大きくなります。顧客は、内部チームと同じようにリスクについて考えたり認識したりしない可能性があります。顧客がアカウントにログインできない場合、おそらく問題の根本原因に関心はありません。彼らは自分の直近の経験に最も関心があります。
- **リスクに優先**順位を付けます。理想的なのは、すべてのリスクが確実な緩和および対応計画にリンクされていることです。実際には、時間の経過と共に解決する必要があるギャップがあります。「早期に価値を提供し、反復する」アプローチを採用することが重要です。あなたと配送およびメンテナンスチームは、一度に多くの作業のみを引き受けることができます。Salesforce では、よく「すべてが重要であれば、何も重要ではありません」と表現します。V2MOM を使用して、会社全体、チーム全体、および各個人に至るまで、作業に優先順位を付けて調整します。([V2MOM の詳細](https://trailhead.salesforce.com/content/learn/modules/manage_the_sfdc_organizational_alignment_v2mom/msfw_oav2m_writing_a_v2mom)は Trailhead で確認できます)。リスク評価を使用すると、最も重要なリスク管理作業に優先順位を付けて取り組むために関係者と連携できます。スケールテスト - テスト計画の作成を使用して、優先度を設定するリスクを特定し、スケールテストを使用してそれらのリスクを軽減します。

Proactive Monitoring を使用して、可用性リスクを早期に検出します。API リクエスト制限の急増、行ロック エラー、同時 Apex 障害などの異常を明らかにし、問題がサービスの中断にエスカレーションする前にアクション可能なインサイトを提供します。

可用性[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/reliable#対応可能状況パターンとアンチパターン)は、Salesforce ソリューション内のリスク管理が適切かどうかを示します。このパターンを使用して、構築前に設計を検証したり、システムのリファクタリング領域を特定したりします。

リスク管理に関連する Salesforce ツールについての詳細は、「[Salesforce Tools For Reliability](/docs/architect/ja-jp/well-architected/guide/reliable#信頼性のための-salesforce-ツール) (信頼性のための Salesforce ツール)」を参照してください。

### 障害の軽減

障害ポイントとは、システムが信頼性を失う脆弱性です。優れた障害軽減とは、すべての潜在的な障害ポイントを特定することではありません。メンテナンスチームとサポートチームが効果的に対応できるように、障害ポイントをすばやく分類して優先順位を付けます。「[インシデント応答」](/docs/architect/ja-jp/well-architected/guide/resilient#インシデント対応)を参照してください。

より適切な障害軽減戦略を作成する

- **人、プロセス、テクノロジーの観点から障害ポイントのトリガーを分類します。**人、プロセス、テクノロジーの観点でリスクを分類するのと同じように、優先度の高い障害ポイントがトリガーされる方法にも同じ考え方を適用します。このアプローチは、潜在的な障害トリガーを特定し、その障害トリガーへの対応策を作成して整理するのに役立ちます。トリガーの分類方法に基づいて、同様の軽減アプローチで一見不一致に見える障害トリガーを軽減できます。

<table style="border-color:white;">
    <tbody>
        <tr>
            <th scope="colgroup" colspan="1">トリガー分類/種別</th>
            <th scope="colgroup" colspan="1">軽減</th>
        </tr>
        <tr>
            <td>人</td>
            <td>ポリシー</td>
        </tr>
        <tr>
            <td>プロセス</td>
            <td>プレイブック、継続性計画</td>
        </tr>
        <tr>
            <td>テクノロジー</td>
            <td>重複</td>
        </tr>
    </tbody>
</table>

- 基本、中間、および成熟した緩和の**外観を識別**します。緩和戦略の構築には時間がかかります。軽減レベルを定義して、すぐに制御できる場所と、経時的な取り組みの焦点を自分とチームが確認できるようにします。可能な限り早い段階で、緩和アプローチで自動化を使用する機会を常に探します。このアプローチが実際にどのようなものかを説明するために、この例では、人指向のトリガーと、ポリシーベースの緩和が基本レベル、中間レベル、成熟レベルでどのようなものかを示しています。

<table style="border-color:white;overflow-x:scroll;">
    <tbody>
        <tr>
            <th scope="colgroup" colspan="1">トリガー</th>
            <th scope="colgroup" colspan="1">軽減</th>
            <th scope="colgroup" colspan="1">基本</th>
            <th scope="colgroup" colspan="1">中級</th>
            <th scope="colgroup" colspan="1">成熟</th>
        </tr>
        <tr>
            <td>新規または退職する従業員のユーザーアクセス権の変更</td>
            <td>ユーザーをプロビジョニングまたはプロビジョニング解除するためのサービスレベル契約 (SLA) と要件</td>
            <td>手動変更の SLA に従って、ユーザーを手動でプロビジョニングおよびプロビジョニング解除します。</td>
            <td>スケジュール済み変更の SLA に従って、スケジュール済みジョブでユーザーの変更を処理します。</td>
            <td>SSO/IDM ソリューションを使用して、ユーザーのプロビジョニングとプロビジョニング解除を自動化します。</td>
        </tr>
    </tbody>
</table>

アーキテクチャ プレイブックと継続性計画に加えて、Proactive Monitoring を使用します。Proactive Monitoring では、ログイン失敗、CPU タイムアウト例外、同時 API 要求エラーなどの障害トリガーに対するリアルタイム アラートを設定できます。このアラートのアプローチにより、テクニカル関係者とビジネス関係者の両方に障害の影響を軽減するタイミングを知らせることで、障害の軽減を強化します。

[可用性パターンと](/docs/architect/ja-jp/well-architected/guide/reliable#対応可能状況パターンとアンチパターン)アンチパターンは、Salesforce ソリューションでの障害軽減の適切さと劣悪さを示します。これを使用して、構築前に設計を検証したり、システム内のリファクタリングする場所を特定したりできます。

障害軽減のための Salesforce ツールについての詳細は、「[Tools Relevant to Reliable](/docs/architect/ja-jp/well-architected/guide/reliable#信頼性のための-salesforce-ツール) (信頼性に関連するツール)」を参照してください。

### 対応可能状況パターンとアンチパターン

次の表に、組織で検索または作成するパターンと、回避または修正の対象となるアンチパターンを示します。

✨ [パターン & アンチパターンエクスプローラー](/docs/architect/ja-jp/well-architected-tools/guide/trusted-availability)で、使用可能なパターンをさらに確認できます。

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">パターン</th>
            <th scope="colgroup">アンチパターン</th>
        </tr>
        <tr><td rowspan="2"><b>リスク管理</b></td>
        <td class="check-col"><b>ビジネス:</b>
        <br> 確立されたリスク評価フレームワークが使用されている。
        <br> リスクは、人、プロセス、テクノロジーの領域に分類されます。</td>
        <td class="check-col"><b>ビジネス:</b>
        <br> - Salesforce のリスク評価フレームワークはアドホックです。
        <br> リスクが明確ではない。</td></tr>
        <tr>
        <td class="check-col"><b>ドキュメント:</b>
        <br> - リスクの重要度は、顧客への影響に基づいて分類および評価されます。
        <br> - リスク軽減および対応計画に優先順位を付けます。</td>
        <td class="check-col"><b>ドキュメント:</b>
        <br> - リスクの重要度やカテゴリを評価するときに、顧客の視点は考慮されません。
        <br> - リスク軽減および対応計画は、考えられるすべてのリスクを把握しようとします。</td>
        </tr>
        <tr><td rowspan="1"><b>障害の軽減</b></td>
        <td class="check-col"><b>組織内：</b>
        <br> - 障害点トリガーとそれに対応する緩和計画は、人、プロセス、テクノロジー別に分類されます。
        <br> - 緩和コントロールがすぐに導入され、経時的に成熟し、できるだけ早く自動化が組み込まれます。
        <br> - 最適な拡張性を確保するために、変更が本番にリリースされる前に包括的なテストと最適化を完了します。
        <br> - ビジネスクリティカルなイベントの前に、SLA に従ってスケールテストと最適化が実行されます。
        </td>
        <td class="check-col"><b>組織内：</b>
        <br> - 失敗点トリガーは分類されません。緩和方法が存在しないか、その場しのぎでのみ使用されます。
        <br> - 緩和措置が再検討または改善されていない。
        <br> - 軽減措置では自動化は使用されません。
        </td></tr>
        <tr><td rowspan="1"><b>監視とオブザーバビリティ</b></td>
        <td class="check-col"><b>組織内：</b>        
        <br> -チェックと異常検出では、Proactive Monitoring が有効になっています。
        <br> -継続的な可視性のために、Proactive MonitoringアラートはScale Centerと統合されています。
        </td>
        <td class="check-col"><b>組織内：</b>
        <br> - 状態チェックは手動でのみ実行され、継続的な監視は行われません。
        </td></tr>
    </tbody>
</table>

## Performance

システムアーキテクチャのパフォーマンスは、システムの処理量 (スループット) と応答速度 (レイテンシ) の指標です。通常、本番環境でのテストと監視を通じてシステムのパフォーマンスを把握します。

パフォーマンスの高いシステムは、予測されるすべての需要レベルでタイムリーにプロセスを完了します。

パフォーマンスが低いと、レイテンシーやスループットが低下し、生産性が低下してユーザーのストレスが高まります。パフォーマンスの問題の解決は急務です。これは、顧客の Trust が失われ、財務上の損失が生じる可能性があるためです。

スループットと遅延を最適化することで、ソリューションのパフォーマンスを向上させることができます。

> 注意:スループットと遅延の最適化は、システムの処理と応答性の向上に不可欠な側面です。ただし、全体的なシステム パフォーマンスは、[拡張性](/docs/architect/ja-jp/well-architected/guide/reliable#拡張性)を考慮した設計の程度にも左右されることに注意してください。設計では両方のディメンションを考慮する必要があります。

### スループット

Salesforce アーキテクチャのコンテキストでは、スループットとは、システムが特定の時間内に完了できる同時要求の数です。スループットを考慮して設計および最適化されたお客様の Salesforce ソリューションは、Salesforce Platform に組み込まれた[LEGATO の制限](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm)内で適切に動作します。

Salesforce のスループットを最適化するには、まずシステムの作業負荷を正確に計算し、その増加を計画します。システムに対して行われる要求の正確な予測がなければ、システムのスループット機能で潜在的な問題を特定できません。

ワークロードについて考えるときは、次の 3 つのディメンションを考慮してください。

- 特定の時間内にシステムで処理する必要**のあるトランザクション数**
- システムに同時にアクセスする必要がある**ユーザーの数**
- システムの**トランザクションロジックの全体**的な複雑さ

パフォーマンスについて考える場合、チームはコンピューティングと最大 CPU 時間の制約に焦点を絞りすぎることがあります。これはプラットフォームのガバナ制限です。CPU 時間に焦点を絞ったチームは、スループットを最適化する他の方法を見落とします。対象を拡大してこれらの方法を適用すると、Salesforce アーキテクチャの全体的なスループットと効率が向上します。これらの改善により、遅延が短縮され、システム全体のパフォーマンスが向上します。ApexGuru は、ループ内の SOQL、ループ内の DML、非効率的な GGD コール、コストのかかるメソッドなど、スループット制限アンチパターンを積極的に検出します。これらのインサイトは、チームがスループットの上限となるガバナ制限のリスクを排除するのに役立ちます。

システムのスループットを最適化する

- **非同期処理**を推奨。Salesforce Platform では、トランザクションコンテキストを使用してデータの整合性を制御し、暴走コードを制限します。「アーキテクチャの基本」の「[アーキテクチャの基本](/docs/architect/ja-jp/fundamentals/guide/architecture-basics#トランザクション)」の「トランザクション」を参照してください。このため、可能な場合は非同期 (async) 処理を使用することで、同期実行コンテキストの潜在的なボトルネックを最小限に抑えることができます。「[データ処理」](/docs/architect/ja-jp/well-architected/guide/automated#データ処理)を参照してください。非同期コンピューティングの使用は、あらゆる種類のパフォーマンスの問題を解決できるわけではなく、非同期プロセスを組み込むときには遅延を考慮する必要があります。キュー可能 Apex などの特定のプラットフォーム機能では、キューでのメッセージの待機時間が長くなるため、トラフィック急増時に遅延が増加する可能性があります。使用事例によっては、スループットを維持または改善するために、応答性の低下を許容する必要がある場合があります。場合によっては、遅延の増加を許容できないと判断できます。スケールテストでは、Full Sandbox でトラフィックの急増をシミュレーションすることで、これらのトレードオフを検証できます。そこで、ジョブがスループットと遅延にどのように影響するかを測定できます。
- **常に一括**処理を使用します。一括処理の概要は、コレクションに対して操作を実行することを意味します。多くの場合、Salesforce ソリューションの一括処理について話し合うチームは、コレクションに対するデータ操作の合理化に焦点を当てています。「[運用ロジック](/docs/architect/ja-jp/well-architected/guide/automated#操作ロジック)」を参照してください。ただし、システムレベルでの一括処理には、データ操作以外にも関連があります。また、コールアウトや複雑な計算などの特定のタスクを一括処理の候補にすることを検討します。適切な一括処理により、オーバーヘッドが軽減されます。操作ごとに 1 つの要求ではなく、1 つの要求で複数の操作を実行します。ApexGuru では、[DML や SOQL](https://help.salesforce.com/s/articleView?language=en_US&id=xcloud.apexguru_antipatterns.htm&type=5) などの膨張防止パターンがループ内に表示され、本番に拡張する前に修正できます。「[Bulk Operations」](/docs/architect/ja-jp/fundamentals/guide/platform-multitenant-architecture#一括操作)を参照してください。
- **検索に SOSL を使用し、SOQL をデータ操作のように扱います。**複雑すぎる SOQL ステートメントを使用すると、システムがレコードを取得する時間が長くなることは明白に思えるかもしれません。SOQL は、[基礎となるリレーショナル データベース](/docs/architect/ja-jp/fundamentals/guide/platform-multitenant-architecture#プラットフォームデータレイヤー)にオーバーヘッドを追加し、処理速度を低下させます。テキスト条件またはワイルドカード条件を使用する場合、SOSL のパフォーマンスが高くなります。SOSL は、全文検索用インデックスとユニバーサル検索用に最適化されたプラットフォームの検索エンジンを使用します。レコード取得パターンを最適化するには、設計標準で SOSL を使用してシステム内のデータを検索するタイミングが指定されていることを確認してください。また、効率的なデータ操作のために SOQL の使用方法を指定していることを確認します。「[運用ロジック](/docs/architect/ja-jp/well-architected/guide/automated#操作ロジック)」を参照)。
- **プラットフォームキャッシュと Apexgur**。[Lightning Platform Cache](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_cache_namespace_overview.htm)レイヤーにより、Salesforce セッションおよび組織のデータをキャッシュするときのパフォーマンスと信頼性が向上します。プラットフォームキャッシュは、キャッシュスペースを分散することでパフォーマンスを向上させ、一部のアプリケーションや操作が他のアプリケーションや操作から容量を奪うことを防ぎます。ApexGuru は、繰り返されるクエリ ([Platform Cache for SOQL 結果](https://help.salesforce.com/s/articleView?id=xcloud.apexguru_antipattern_soql_without_platform_cache.htm&type=5)など) をキャッシュする機会の欠落を検出し、大規模な環境でのスループットを向上させます。

パフォーマンスの[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/reliable#パフォーマンスパターンとアンチパターン)は、Salesforce 組織でのスループットの適切と劣悪を示します。これらを使用して、構築前に設計を検証したり、さらなる最適化の機会を特定したりできます。

スループットを最適化するための Salesforce ツールについての詳細は、「[Salesforce Tools For Reliability](/docs/architect/ja-jp/well-architected/guide/reliable#信頼性のための-salesforce-ツール) (信頼性のための Salesforce ツール)」を参照してください。

### 遅延

レイテンシは、システムが実行パスを完了する速度の指標です。システムのスループットを最適化すると、遅延の改善に寄与します。レイテンシのもう 1 つのディメンションは、知覚されるパフォーマンス、つまりユーザーが感じるシステムの応答性です。

ユーザーは、ページの読み込みやプロセスの終了を待ちたくありません。リストビュー、レコードページ、レポートなどを操作するときに読み込み時間が頻繁に長くなると、システムのユーザーはストレスを感じるでしょう。この場合、顧客やパートナーは、パフォーマンスの低いシステムに対処するのではなく、他の場所にビジネスを移すことができます。内部では、従業員が設計どおりにシステムを使用しないように回避策を作成することがあります。これにより、セキュリティとデータの整合性の下流で問題が発生する可能性があります。

知覚されるパフォーマンスは診断が難しい場合があります。ユーザーからパフォーマンスの低下が報告されると、サポートチームは問題を再現できない可能性があります。遅延の増加は、多くの場合、小さな問題が積み重なって発生するため、知覚されるパフォーマンスの問題の正確な原因を診断することが困難になる可能性があります。

Salesforce システムで遅延を減らし、応答性を改善する

- **レポートを最適化**します。各レポートが 1 つの特定の目的を果たすようにします。システムのすべてのレポートの対象ユーザーと目的を明確に特定します。レポートには、利用者メンバーが意思決定を行うために必要な最小限のデータのみを含めます。レポートの目的と一致しない列を削除すると、取得および表示する必要があるデータの量が減るため、レポートのパフォーマンスが向上します。
- **フィルタを最適化**します。有効な検索条件を使用すると、データベースから取得される行数の範囲を正確に設定できるため、レポートおよびリストビューのパフォーマンスが向上します。原則として、検索条件ロジックを具体的にすればするほど、データに対する基礎となるクエリの効率が向上します。検索条件を最適化する方法は次のとおりです。
  - 「次の文字列を含む」および「次の文字列を含まない」の代わりに「次の文字列と等しい」および「次の文字列と等しくない」を使用
  - 数式項目による絞り込みの回避
- **共有モデルを**簡素化します。共有モデルが複雑すぎると、ユーザーが表示または処理するデータにアクセスできるかどうかを判断するために共有および表示モデルを確認する必要があるため、さまざまなプロセスが遅くなる可能性があります。複雑な共有の計算では、ユーザーのコンテキストで実行されるレポート、リストビュー、自動化の遅延が増加する可能性があります。「[共有と表示](/docs/architect/ja-jp/well-architected/guide/secure#共有と表示)」を参照してください。
- **カスタム UI コンポーネント**を最適化。カスタムのユーザーインターフェース (UI) コンポーネントを使用すると、遅延が増加する可能性があります。カスタム UI コンポーネントのパフォーマンスを最適化するには、次のことを検討してください。
  - **Lightning Web コンポーネント (LWC)**。LWC フレームワークは、最新の Web 標準に密接に対応しています。LWC で記述されたカスタムコンポーネントは Web ブラウザーでより効率的に表示され、開発者はよりパフォーマンスの高い JavaScript メソッドを使用できます。Aura や Visualforce などの古い UI テクノロジーではなく、LWC を使用することを常に目指してください。
  - **Lightning データ サービス**。Lightning Data Service は、コンポーネント間の安全でパフォーマンスの高い共有キャッシュの作成とメンテナンスを処理します。これを使用して、データのためにサーバーを不必要に往復することを回避し、全体的なアプリケーションの応答性を向上させます。
  - **リストデータのクライアント側の並び替えと絞り込み。**LWC (推奨) コンポーネントと Aura コンポーネント (それ以外の場合) の両方で、開発者は標準の JavaScript 配列機能を使用してクライアント側で値の並び替え、絞り込み、選択を行い、サーバーへの移動回数を減らすことができます。

[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/reliable#パフォーマンスパターンとアンチパターン)は、Salesforce 組織での適切な遅延と低い遅延を示します。これらを使用して、構築前に設計を検証したり、さらなる最適化の機会を特定したりできます。

レイテンシ最適化のための Salesforce ツールについての詳細は、「[Salesforce Tools For Reliability](/docs/architect/ja-jp/well-architected/guide/reliable#信頼性のための-salesforce-ツール)(信頼性のための Salesforce ツール)」を参照してください。

### パフォーマンスパターンとアンチパターン

次の表に、組織で検索または作成するパターンと、回避または修正の対象となるアンチパターンを示します。

✨ [パターン & アンチパターンエクスプローラー](/docs/architect/ja-jp/well-architected-tools/guide/trusted-performance)でパフォーマンスに関するより多くのパターンを検出します。

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">パターン</th>
            <th scope="colgroup">アンチパターン</th>
        </tr>
        <tr>
            <td rowspan="2"><b>スループット</b></td>
            <td><b>設計基準では、次のようになります。</b>
                <br> - プラットフォームキャッシュの使用方法に関するガイダンスは、<a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_platform_cache_best_practices.htm" target="_blank">プラットフォームキャッシュベストプラクティス</a>に準拠しています。
            </td>
            <td><b>設計基準では、次のようになります。</b>
                <br> - プラットフォームキャッシュの利用状況に関する指針がある場合、明確ではない、またはベストプラクティスに準拠していない。
            </td>
        </tr>
        <tr>
            <td><b>組織内：</b>
            <br> - 一括処理は、データとシステム操作に使用されます。
            <br> - DML またはデータベースメソッドは、常に Apex のコレクションに対して動作します。
            <br> - DML 中にデータベースで経過時間が短くなるために使用する項目が制限されます。
            <br> - SOSL ではすべてのワイルドカード条件が使用されます。
            <br> - SOQL ステートメントは選択的です。
            <br> -- LIKE 比較や部分テキスト比較は使用しません。
            <br> -- 比較演算子では、主ロジックまたは唯一のロジックとして肯定的なロジック (つまり INCLUDES または IN) が使用されます。
            <br> --= NULL と != NULL が使用されるのは、常に肯定的な比較演算子の後にある場合のみです。 
            <br> – データ負荷を最小限に抑えてパフォーマンスを最大化するために、SOQL クエリで必要な項目のみが取得されます。
            <br> -- LIMIT 1 ステートメントは使用されません。
            <br> -- ALL ROWS キーワードは使用されません。
            <br> - 可能な場合は非同期処理が優先されます。
            <br> プラットフォームキャッシュパーティションが設定されている。
            </td>
            <td><b>組織内：</b>
                <br> - DML ステートメントは一括処理されません。
                <br> - Apex の 1 つのレコードに対して DML またはデータベースメソッドが動作します。
                <br> - SOSL がワイルドカード選択条件で使用されることはほとんどありません。
                <br> - SOQL ステートメントは非選択的です。
                <br> -- LIKE およびワイルドカード検索条件が含まれます。
                <br> -- !=、NOT、または NOT IN 条件を使用した比較は、主または唯一の比較演算子として使用されます。
                <br> -- = NULL 条件と != NULL 条件を主または唯一の比較演算子として使用します。
                <br> -- LIMIT 1 ステートメントが使用されます。
                <br> -- ALL ROWS キーワードが使用されます。
                <br> - SOQL がループ内に表示されます。
                <br> - 同期プロセスが好まれます。
            </td>
        </tr>
        <tr>
            <td rowspan="1"><b>遅延</b></td>
            <td><b>組織内：</b>
            <br> - レポートは 1 つの特定の目的を果たし、意思決定に必要な最小限の行数と列数が含まれます。
            <br> -検索条件で「次の文字列と一致する」と「次の文字列と一致しない」が使用されている。
            <br> - 検索条件に数式項目が含まれていない。
            <br> ・共有モデルは可能な限り簡略化。
            <br> カスタムUIコンポーネントでは、LWC(Lightning Webコンポーネント)を使用します。
            <br> - LWC はデータ操作に Lightning Data Service を使用します。
            <br> - リストデータの並び替えと絞り込みは、JavaScript でクライアント側で処理されます。
            <br> - Salesforce Edge が有効になっている。
            </td>
            <td><b>組織内：</b>
            <br> - レポートには複数の目的がある場合や、意思決定に不要な行や列が含まれている場合があります。
            <br> -検索条件で「含む」と「含まない」が使用されている。
            <br> - 検索条件には数式項目が含まれます。
            <br> 共有モデルは複雑です。
            <br> -カスタムUIコンポーネントではフレームワークが使用されているため、LWCよりもレンダリング効率が低い場合があります(AuraやVisualforceなど)。
            <br> - LWC はデータ操作に Apex を使用します。
            <br> - リストデータの並び替えと絞り込みは、Apex を使用してサーバー側で処理されます。
            <br> - Salesforce Edge が有効になっていない。
            </td>
        </tr>
    </tbody>
</table>

## 拡張性

拡張性とは、システムが進化および成長しても一貫して実行できる機能です。拡張性の高いシステムでは、トランザクション量や同時アクセスの大幅な増加を、根本的な変更なしで処理できます。Salesforce のプラットフォームサービスは、アプリケーションの拡張性をサポートするように設計されています。「[内部プラットフォーム処理](/docs/architect/ja-jp/fundamentals/guide/platform-multitenant-architecture#内部プラットフォーム処理)」を参照してください。そうは言っても、組織が成長し、製品やサービスの需要が増加すると、効果的かつ期待どおりに機能するシステムを作成する責任があります。最初から拡張性を考慮して設計することで、新しい機能をより迅速に提供し、ユーザートラフィックが増加してもサービスの中断を減らすことができます。新機能を本番にリリースする前の設計フェーズの早い段階で、**スケールテスト**を使用して予測されるワークロードをシミュレーションし、アーキテクチャがそれらをサポートするために拡張できることを確認します。

拡張性を重視して設計されていないシステムでは、トラブルシューティング、再設計、リファクタリングに絶えずコストがかかります。拡張性の問題は時間と共に複雑になり、システム全体のパフォーマンスが低下します。ビジネスによっては、開発およびメンテナンスリソースの大半を、価値を生み出す新機能ではなく拡張性の問題への対応に費やしている場合があります。

ビジネスが臨界点に達することがあります。システムの元の設計ではビジネスの成長に対応できず、予期しないイベントによってシステムが不安定になります。**Scale Center**からのインサイトを使用して、拡張性の転換点を早期に特定します。Scale Center では、例外のホットスポット、実行時間の長いトランザクション、経時的に悪化するキューのボトルネックが表示されます。

データモデルの最適化とデータ量管理に焦点を当てることで、拡張性を備えた設計が可能になります。

_注:ここでは説明しませんが、拡張性のテストは、アプリケーションアーキテクチャの検証に不可欠です。指針については、「[テスト戦略](/docs/architect/ja-jp/well-architected/guide/resilient#テスト戦略)」を参照してください。_

### データモデリング

データモデリングでは、組織内のオブジェクトを構造化し、ユーザーと自動化プロセスが必要なデータをできるだけ早く取得できるように相互に関連付けます。[スループットを向上](/docs/architect/ja-jp/well-architected/guide/reliable#スループット)する手段を講じることで多くのパフォーマンス問題に対処できますが、最適化されたデータモデルがなければ、取り組みの効果は高まりません。

不適切に設計されたデータモデルの悪影響はすぐには現れません。データ量、プロセス、ユーザー、インテグレーションの面でシステムが大きくなるにつれて、その弱点が露呈します。適切に設計されたデータモデルを使用すると、要件の追加や拡張に応じてアプリケーションを継続的にリファクタリングしやすくなります。**ApexGuru**は、非選択的な SOQL、未使用のフィールド、スキーマの非効率性など、データモデルの拡張性に直接影響するデータアクセスのアンチパターンを明らかにします。

データモデルを最適化する

- **Salesforce の事前**作成済みデータモデル。Salesforce では、営業、サービス、さまざまな業種向けに事前作成済みデータモデルを提供しています。Salesforce が提供するデータモデルを使用することで、システムの機能が 1 回のみ定義され、冗長性とサイロ化が解消され、システム全体の情報源が一元化されます。この 1 つのソースでは Salesforce の事前作成済みデータモデルを使用していたため、分析を使用してアプリケーションデータを理解し、Salesforce の事前作成済み人工知能サービスを使用する方が簡単です。また、サポートする必要があるカスタマイズを減らすことで、メンテナンスコストと技術的負債を削減できます。
- **適切なデータ型**。Salesforce でサポートされるさまざまな項目の種別とその制限について説明します。レポートと暗号化の要件を考慮して、将来、種別間でデータを変換する必要がないようにします。
- **適切なリレーション**。Salesforce では、オブジェクト間の主従関係と参照関係の 2 種類がサポートされています。主従関係には 2 つの主な利点があります。1 つは、子レコードの詳細を数えて集計する組み込みの積み上げ集計機能です。もう 1 つは組み込みのカスケード削除機能で、親レコードを削除すると、子レコードも削除されます。ただし、主従関係の使用を決定する前に、主従関係の[共有とデータスキュー](/docs/architect/ja-jp/well-architected/guide/reliable#データ量)の影響を理解していることを確認してください。
- **スケールに合わせて非正規化します。**正規化とは、データの冗長性を減らしてデータの整合性を向上させるためにデータモデルを構造化するプロセスです。残念ながら、正規化によってスケーリングの問題が発生することがあります。非正規化されたテーブルは規模に応じてパフォーマンスが向上しますが、データの整合性と冗長性を考慮してください。

[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/reliable#拡張性パターンとアンチパターン)は、Salesforce 組織でのデータモデルの最適化の適切さと劣悪さを示します。これらを使用して、構築前に設計を検証したり、さらなる最適化の機会を特定したりできます。

データモデル最適化用の Salesforce ツールについての詳細は、「[Salesforce Tools For Reliability](/docs/architect/ja-jp/well-architected/guide/reliable#信頼性のための-salesforce-ツール) (信頼性のための Salesforce ツール)」を参照してください。

### データ量

データ量は、レコード件数とサイズに基づく、システム内に保存されているデータ量の指標です。組織に数万人のユーザー、数千万件のレコード、または合計数百ギガバイトのレコードストレージがある場合、データ量が多くなります。組織のデータ量とオブジェクト間のリレーションは拡張性に影響し、レコード数のみよりも拡張性に大きく影響する可能性があります。

データ量が多い組織の拡張性を向上させる

- **子レコードを配布**します。親に多数の子レコードが含まれないようにすることで、親子データの歪みを回避します。一般的な推奨事項は、親レコードが 10,000 件を超えないようにすることです。たとえば、取引先責任者が多数あり、取引先を使用しないリリースでは、複数の取引先レコードを設定し、関連する取引先責任者レコードをそれらの取引先責任者レコードに分散することを検討します。
- **レコードの所有**権を分配する。1 人のユーザーまたはキューが 10,000 件を超える同じオブジェクトのレコードを所有しないようにしたり、1 つのロールまたは公開グループのすべてのメンバーがそのレコードを所有しないようにしたりすることで、所有権の偏りを回避します。「ダミーユーザー」によるデータの「保留」は、所有権の偏見につながることがよくあります。この問題が発生した場合は、[共有計算](/docs/architect/ja-jp/well-architected/guide/reliable#遅延)への影響に注意してください。所有権のスキューを解消するためにレコードを再配布できない場合は、データ所有者ユーザーをロールに割り当てないようにします。組織の共有モデルでロールの割り当てが必要な場合は、データ所有者のユーザーを共有階層の最上位の個別のロールに配置します。変更を行うと、共有の再適用によってパフォーマンスに大きな影響を与えるため、そのユーザーのロールで頻繁に変更したり、予定外の変更を行ったりしないでください。共有ルールで参照される可能性のある公開グループからユーザーを除外します。
- **Salesforce の**レコードデータ量を削減します。Salesforce は、企業が顧客を 1 つのビューで表示できるように設計されています。Salesforce でデータを制限することがベストプラクティスであることは直観に反すると思われるかもしれません。ただし、単一ビューの威力は、ビジネスユーザーが顧客データをどの程度理解してアクションを実行できるかにあります。データ量が増加するにつれて、最新ではないデータや、日常的なプロセスや分析に関連しないデータによって、いくつかの問題が発生します。これらの問題には、アプリケーションのパフォーマンスの低下、データセキュリティリスクの増大、検索、レポート、分析への悪影響などがあります。この問題を回避するには、データモデルのすべてのオブジェクトのデータライフサイクルを定義し、古くなり、即座にビジネス上の価値が失われた場合のデータのタイムラインと分類を設定します。データライフサイクルに従って、次の手順を実装し、経時的なデータを管理します。
  - **データアーカイブおよび消去** \- データ量をできるだけ少なくするには、ビジネスで不要なレコードを削除してデータ量をできるだけ少なくします。Bulk API 2.0 の物理削除機能を使用して、大量のデータを削除します。
  - **データ集計 -** 主要な履歴トレンドやサマリー データをレポートと互換性のある形式で集計する集計カスタム オブジェクトを作成します。[バッチ Apex](/docs/architect/ja-jp/well-architected/guide/reliable#スループット) を使用してカスタムオブジェクトに入力します。その後、ユーザーは集計されたオブジェクトレコードに基づいてレポートを実行できます。
  - **データ階層化**。Salesforce レポートや日常業務で不要な大規模なデータセットは、別のアプリケーションで管理します。必要に応じて、マッシュアップ、コールアウト、外部オブジェクトを使用して Salesforce でデータを使用できるようにします。

実際には、問題が発生したときに拡張性の問題の根本原因にすぐに対処できるとは限りません。このため、Salesforce には当面の課題を軽減するオプションが用意されています。大量のデータを処理するには、組織でこれらの機能を有効にすることが現実的で長期的なアーキテクチャ戦略ではないことを知っておくことが重要です。これらの短期的なその場しのぎの回避策は、不十分なデータアーキテクチャに悩まされているシステムの遅延を減らすのに役立ちますが、組織に技術的な負債を追加する可能性もあります。

規模の問題の短期的な回避策は次のとおりです。

- **カスタムインデックス**インデックスは、プラットフォームのクエリオプティマイザーがデータアクセス操作を高速化するために使用する特殊な内部テーブルに保存されます。「[マルチテナントインデックス](/docs/architect/ja-jp/fundamentals/guide/platform-multitenant-architecture#インデックス)」を参照)。プラットフォームでは、デフォルトで特定の種別の項目に自動的にインデックスが付けられます。パフォーマンスの低いクエリを高速化するには、Salesforce カスタマーサポートに連絡して追加のカスタムインデックスを要求できます。クエリプランツールを使用して、カスタムインデックスによってクエリのパフォーマンスが向上するかどうかを判断します。
- **Skinny テーブル**。100 万件を超えるレコードがあるオブジェクトの一般的な項目セットのクエリをさらに最適化する必要がある場合は、スキニーテーブルが役立ちます。Skinny テーブルでは、レポートまたはオートメーションで同じオブジェクトのカスタム項目と標準項目を使用する場合に発生する[バックグラウンド結合](https://developer.salesforce.com/docs/atlas.en-us.salesforce_large_data_volumes_bp.meta/salesforce_large_data_volumes_bp/ldv_deployments_infrastructure_skinny_tables.htm)が排除されます。スキニーテーブルを使用するには、Salesforce カスタマーサポートが組織でスキニーテーブルを有効にする必要があります。

拡張性に関する[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/reliable#拡張性パターンとアンチパターン)は、Salesforce 組織でのデータボリューム管理の適切さと劣悪さを示します。これらを使用して、構築前に設計を検証したり、さらなる最適化の機会を特定したりできます。

データ量を管理するための Salesforce ツールについての詳細は、「[Salesforce Tools For Reliability](/docs/architect/ja-jp/well-architected/guide/reliable#信頼性のための-salesforce-ツール) (信頼性のための Salesforce ツール)」を参照してください。

### 拡張性パターンとアンチパターン

組織で検索または作成するパターンと、回避または修正の対象となるアンチパターンの選択内容が表示されます。

✨ [パターン & アンチパターンエクスプローラー](/docs/architect/ja-jp/well-architected-tools/guide/trusted-scalability)で拡張性に関するより多くのパターンを見つけます。

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">パターン</th>
            <th scope="colgroup">アンチパターン</th>
        </tr>
        <tr>
            <td rowspan="3"><b>データモデリング</b></td>
            <td><b>設計基準では、次のようになります。</b>
                <br> - カスタムオブジェクトが存在することをビジネス上の正当性が保証する基準と指針。
            </td>
            <td><b>設計基準では、次のようになります。</b>
                <br> - カスタムオブジェクトを作成するための標準はありません。
            </td>
        </tr>
         <tr>
            <td><b>データモデルの場合:</b>
                <br> 可能な場合は標準オブジェクトが使用されます。
                <br> - ApexGuru によるアンチパターンチェックにより、SOQL クエリが選択され、スキーマの非効率的な使用が回避されることを確認します。
                <br> - テーブルはスケールに対して非正規化されます。
            </td>
            <td><b>データモデルの場合:</b>
                <br> - 複製された標準オブジェクトがある。
                <br> - テーブルは冗長性を避けるために正規化されます。
            </td>
        </tr>
         <tr>
            <td><b>ビジネス内：</b>
                <br> - ローコードビルダーは、Salesforce でサポートされるさまざまなデータ型を理解し、レポートと暗号化の要件を評価してから、データ型を選択します。
                <br> - オブジェクト間の主従関係を確立する前に、その関係の共有とデータスキューの影響を評価します。
            </td>
            <td><b>ビジネス内：</b>
                <br> - ローコードビルダーは、下流のレポートと暗号化の要件を評価することなくデータ型を選択します。
                <br> - オブジェクト間の主従関係を確立することを決定する前に、その関係の共有とデータスキューの影響を評価しません。
            </td>
        </tr>
        <tr>
            <td rowspan="3"><b>データ量</b></td>
            <td><b>データ内：</b>
                <br> 10,000 件を超える子レコードを持つ親レコードはありません。
                <br> - 10,000 件を超える同じオブジェクト種別のレコードにユーザーが割り当てられていない。
                <br> - 同じレコードを参照する参照項目を持つ 10,000 件を超えるレコードが含まれるインスタンスはありません。
                <br> - 一括データ読み込みは、ParentId 項目値に従ってバッチに並び替えられます。
                <br> -バッチ戦略が同時実行で破綻しないように、スケールテストを使用して本番規模で一括読み込みパターンを検証します。
                <br> - 本番へのデータの一括読み込みは、ピーク営業時間中に行われません。
                <br> - 一括データ読み込みには、ビジネス上の意思決定に必要な最小限のデータのみが含まれます。
            </td>
            <td><b>データ内：</b>
                <br> 10,000 件を超える子レコードが存在する。
                <br> - ユーザーが同じ種別の 10,000 件を超えるレコードに割り当てられている。
                <br> 10,000 件を超えるレコードに同じレコードを参照する参照項目があるインスタンスが存在する。
                <br> - 一括データ読み込みは、ParentId 項目値に従ってバッチに並び替えられません。
                <br> - 本番環境へのデータの一括読み込みは、営業時間のピーク時に行われます。
                <br> - 一括データの読み込みは、ビジネス上の意思決定に必要な最小限のデータに制限されません。
            </td>
        </tr>
         <tr>
            <td><b>フローおよび Apex の場合 ―</b>
                <br> - データの歪みが問題になるシナリオで、子レコードの数を複数の親レコードに分散するロジックが存在します。
                <br> -インテグレーションを使用してレコードをインポートまたは複製すると、ロジックによって適切なユーザーに割り当てられます。
                <br> - Apex コレクション (リストやセットなど) の場合、クエリを最小限に抑えてデータ処理を最適化するために複数のレコードを処理するロジックが存在します。
                <br> - 拡張性の高いコードの標準とベスト プラクティスに準拠する効率的なApexコードが記述され、リリースされます。 
            </td>
            <td><b>フローおよび Apex の場合 ―</b>
                <br> - 子レコードは、すでに割り当てられている子レコードの数に関係なく、親レコードに任意に割り当てられます。
                <br> データ読み込みまたはインテグレーションで作成されたレコードは、一般的な「インテグレーションユーザー」に割り当てられます。
                <br> - 同じオブジェクトからの複数の再帰的な SOQL クエリが同期トランザクションにあり、ヒープ使用量が多い。
                <br> -開発者がApexコードを作成すると、非効率性とパフォーマンス<a href="https://help.salesforce.com/s/articleView?id=xcloud.apexguru_antipatterns.htm&type=5">のアンチパターン</a>が発生します。
            </td>
        </tr>
         <tr>
            <td><b>ビジネス内：</b>
                <br> - データのアーカイブおよび消去戦略を文書化して実装している
            </td>
            <td><b>ビジネス内：</b>
                <br> -データアーカイブおよび消去戦略がないか、戦略が文書化されているが実装されていない
            </td>
        </tr>
    </tbody>
</table>

## 信頼性のための Salesforce ツール

<table class="tools-table"><tbody><tr><th>ツール</th><th>説明</th><th>可用性</th><th>Performance</th><th>拡張性</th></tr>
  <tr>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.bigobjects.meta/bigobjects/big_object.htm">Big Object</a></td>
      <td>プラットフォームで大量のデータを保存および管理します。</td>
      <td class="check-col"></td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://github.com/forcedotcom/code-analyzer">コードスキャナー</a></td>
      <td>Apex コードをスキャンしてパフォーマンスの問題がないか確認します。</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col"></td>
    </tr>
    <tr>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_large_data_volumes_bp.meta/salesforce_large_data_volumes_bp/ldv_deployments_infrastructure_indexes.htm">カスタムインデックス</a></td>
      <td>カスタムインデックスを使用してクエリのパフォーマンスを向上させます。</td>
      <td class="check-col"></td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_large_data_volumes_bp.meta/salesforce_large_data_volumes_bp/ldv_deployments_techniques_deleting_data.htm">データの削除</a></td>
      <td>不要なデータを削除してパフォーマンスを向上させます。</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_large_data_volumes_bp.meta/salesforce_large_data_volumes_bp/ldv_deployments_infrastructure_divisions.htm">ディビジョン</a></td>
      <td>データをパーティション分割して、クエリとレポートのレコード数を制限します。</td>
      <td class="check-col"></td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://help.salesforce.com/s/articleView?id=xcloud.scale_test_overview.htm&type=5">スケールテスト</a><a href="https://help.salesforce.com/s/articleView?id=sf.technical_requirements_performance_assistant.htm&type=5"></a></td>
      <td>システムのパフォーマンスをテストし、結果を解釈します。本番にリリースする前に、拡張性とパフォーマンスを検証するために、Playwright または JMeter スクリプトを使用して大規模な UI および API ワークロードをシミュレーションします。</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://help.salesforce.com/s/articleView?id=xcloud.scale_center_overview.htm&type=5">Scale Center</a></td>
      <td>システムパフォーマンスに関するセルフサービスとリアルタイムのインサイトを取得します。実行時間の長いトランザクション、例外のホットスポット、スループットのボトルネックを見つけます。開発サイクルの早い段階で拡張性の問題を診断します。</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://help.salesforce.com/s/articleView?id=release-notes.rn_apexguru.htm&release=258&type=5">ApexGuru</a></td>
      <td>Scale CenterのこのGenAIベースの機能を使用して、実行時にApex、SOQL、テスト クラスのアンチパターンを検出します。ApexGuru と Salesforce Code Analyzer のインテグレーションにより、開発ワークフローで AI を駆使したおすすめとインライン修正を利用できます。これらの推奨事項と修正を使用して、ホットスポットを解決し、クエリの選択性、一括処理、キャッシュ使用量、テスト品質を向上させます。</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://github.com/forcedotcom/code-analyzer">Salesforce Code Analyzer</a></td>
      <td>IDE、CLI、または CI/CD を使用してコードをスキャンし、ベストプラクティスに準拠していることを確認します。Salesforce Code Analyzer と ApexGuru の統合により、開発者ワークフローでパフォーマンスのアンチパターンに関するインサイトを直接取得できます。</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col"></td>
    </tr>
    <tr>
      <td><a href="https://help.salesforce.com/s/articleView?id=sf.domain_name_edge_network_route_my_domain.htm&type=5">Salesforce Edge ネットワーク</a></td>
      <td>Salesforce Edgeネットワークを介して[<a href="https://help.salesforce.com/s/articleView?id=xcloud.domain_name_overview.htm&language=en_US&type=5">私のドメイン</a>]をルーティングすることで、ダウンロード時間とユーザーエクスペリエンスを改善します。</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col"></td>
    </tr>
    <tr>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_large_data_volumes_bp.meta/salesforce_large_data_volumes_bp/ldv_deployments_infrastructure_skinny_tables.htm">スキニーテーブル</a></td>
      <td>頻繁に使用する項目があるテーブルでの結合は避けてください。</td>
      <td class="check-col"></td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://help.salesforce.com/s/articleView?id=000382042&type=1">プロアクティブな監視</a></td>
      <td>レコードの増加、所有権のスキュー、パフォーマンスの低下の異常を継続的に監視します。重大になる前に、規模に関するアラートを表示します。</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
    </tr>
</table>

## 信頼性のための Salesforce リソース

<table class="tools-table"><tbody><tr><th>リソース</th><th>説明</th><th>可用性</th><th>Performance</th><th>拡張性</th></tr>
  <tr>
      <td><a href="https://www.salesforce.com/blog/scalability/">拡張性の課題 - ビジネスを将来にわたって維持する方法</a></td>
      <td>拡張性の実装が、持続可能な成長と長期的な成功にどのようにつながるかを説明します。</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://developer.salesforce.com/blogs/2023/07/salesforce-scale-center-is-generally-available">Scale Center を使用したスケーラブルなアプリケーションの構築とリリース</a></td>
      <td>Salesforce 実装のパフォーマンスの問題を積極的に評価して解決する方法について説明します。</td>
      <td class="check-col"></td>
      <td class="check-col"></td>
      <td class="check-col"></td>
    </tr>
    <tr>
      <td><a href="https://developer.salesforce.com/blogs/2022/05/analyze-performance-scale-hotspots-in-complex-salesforce-apps">複雑なSalesforceアプリケーションでのパフォーマンスの分析とホットスポットの拡張</a></td>
      <td>組織のパフォーマンスと拡張性の問題に対処します。</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://www.salesforce.com/blog/scale-testing/">ラッシュ時のトラフィックでアプリケーションがパニックになるべきではない - 準備方法</a></td>
      <td>スケールテストを成功させるための 4 つの主要なステップについて説明します。</td>
      <td class="check-col"></td>
      <td class="check-col"></td>
      <td class="check-col"></td>
    </tr>
    <tr>
      <td><a href="https://developer.salesforce.com/blogs/2025/06/the-apexguru-ai-engine-explained">ApexGuru AIエンジンの説明</a></td>
      <td>ApexGuru がカスタムトレーニングされたモデル、実際の組織のテレメトリ、インテリジェントなフィルタリングを使用して、正確でコンテキストに沿ったアクション可能なインサイトを提供する方法について説明します。</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://trailhead.salesforce.com/content/learn/modules/apexguru/optimize-apex-code-with-apexguru">ApexGuruを使用したアプリケーションおよびAgentforce向けApexの最適化</a></td>
      <td>SOQL、DML、デバッグ、非効率性のテストなど、ApexGuruが開発者のパフォーマンス アンチパターンの検出と修正にどのように役立つかについて説明します。また、ApexGuruを、アプリケーションの拡張性の高い開発とAgentforceの実装のためのAI搭載コーチとして使用します。</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://help.salesforce.com/s/articleView?id=xcloud.apexguru_antipatterns.htm&type=5">ApexGuru Antipatterns</a></td>
      <td>Salesforce のメジャーリリースのたびに更新される ApexGuru で検出されたアンチパターンの公式ライブラリについて説明します。</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_large_data_volumes_bp.meta/salesforce_large_data_volumes_bp/ldv_deployments_introduction.htm">大量のデータを使用するリリースのベストプラクティス</a></td>
      <td>大量のデータのプロセスへの影響を理解します。</td>
      <td class="check-col"></td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://help.salesforce.com/s/articleView?id=xcloud.domain_name_edge_network_considerations.htm&type=5">Salesforce Edge ネットワークに関する考慮事項</a></td>
      <td>Salesforce Edge ネットワークを使用するために組織を準備する方法を確認します。</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col"></td>
    </tr>
    <tr>
      <td><a href="/docs/architect/ja-jp/resources/guide/design-standards-template">設計標準テンプレート</a></td>
      <td>組織の設計標準を作成します。</td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://medium.com/salesforce-architects/data-model-design-considerations-when-building-salesforce-applications-part-1-4e605f504b54">データモデル設計に関する考慮事項</a></td>
      <td>拡張性とメンテナンスのためにデータモデルを最適化します。</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.draes.meta/draes/draes_preface.htm">企業の規模に応じたレコードアクセス権の作成</a></td>
      <td>設定によってアクセス制御のパフォーマンスを最適化します。</td>
      <td class="check-col"></td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_large_data_volumes_bp.meta/salesforce_large_data_volumes_bp/ldv_deployments_infrastructure_for_performance.htm">大量のデータを処理するシステムのインフラストラクチャ</a></td>
      <td>大量のデータを使用するリリースのシステムパフォーマンスをサポートする機能について説明します。</td>
      <td class="check-col"></td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://help.salesforce.com/s/articleView?id=sf.admin_rebates_additional_resources_for_batch_management.htm&type=5">一括管理の学習リソース</a></td>
      <td>一括管理について説明します。</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://trailhead.salesforce.com/content/learn/modules/lightning-experience-performance-optimization">Lightning Experience パフォーマンスの最適化</a></td>
      <td>組織のLightning Experienceを改善して、ユーザーの作業時間を短縮します。</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col"></td>
    </tr>
    <tr>
      <td><a href="https://developer.salesforce.com/blogs/engineering/2013/04/managing-lookup-skew-to-avoid-record-lock-exceptions">Salesforce でのルックアップスキューの管理によるレコードロック例外の回避</a></td>
      <td>ルックアップスキューの影響を最小限に抑える方法を理解します。</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_large_data_volumes_bp.meta/salesforce_large_data_volumes_bp/ldv_deployments_best_practices_soql_and_sosl.htm">SOQL および SOSL のベストプラクティス</a></td>
      <td>大量のデータを使用するリリースの場合は、SOQL および SOSL のベストプラクティスに従ってください。</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.draes.meta/draes/draes_tools.htm">大規模な再配置のためのツール</a></td>
      <td>再配置を効果的に計画および実行します。</td>
      <td class="check-col"></td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
    </tr>
    <tr>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_large_data_volumes_bp.meta/salesforce_large_data_volumes_bp/ldv_deployments_techniques_using_mashups.htm">マッシュアップの使用</a></td>
      <td>大きなデータセットを別のアプリケーションで管理します。</td>
      <td class="check-col"></td>
      <td class="check-col">X</td>
      <td class="check-col">X</td>
    </tr>
</table>

## ご意見をお聞かせください

Salesforce Well-Architected の関連性の維持にご協力ください。このコンテンツに関するフィードバックをいただくため[のアンケート](https://sfdc.co/bxNtvh)にご協力ください。また、今後の展望についてもお聞かせください。

<!-- document id=967bcf211b9282f330daea7c518fd9f53f09719fb46a13762e7a296f94610440 url=/architect/next/ja-jp/well-architected/guides/trusted-overview.md -->

> 更新スケジュールについては、[こちら](/docs/architect/ja-jp/well-architected/guide/contributors)を参照してください。

## はじめに

**信頼できる**Salesforce ソリューションは、ビジネスと関係者を保護します。**信頼**できるように適切に設計されたソリューションは、安全性、コンプライアンス、信頼性に優れています。

**安全な**ソリューションは、アクセスを制御してデータを保護します。<br>
**準拠**ソリューションは、法的および倫理的なガイドラインに従います。<br>
**信頼**性の高いソリューションは、効率的で信頼性の高い方法で動作します。<br>

**信頼できる**ソリューションを作成するには、慎重に計画する必要があります。ソリューションがサービスを提供するビジネスや業界のコンテキストを理解する必要があります。ビジネスの全体的なリスク許容度は?どのようなデータがシステムに出入りしますか?Salesforce は、特殊なセキュリティ、コンプライアンス、または倫理的な考慮事項があるデータの記録システムまたはストレージポイントとして機能しますか?関連する規制とコンプライアンス基準は?追加の会社固有の標準はありますか?Salesforce はビジネスに不可欠なシステムですか?考慮する必要があるトラフィックまたはシステム使用量の季節的または状況的な急増がありますか?

**信頼できる**ソリューションに到達するには、ビジネス全体の関係者と協力する必要があります。ソリューションにアクセスする必要があるユーザーとシステムの種類、および作業を実行するために必要なデータと権限を明確に把握する必要があります。法的要件、業界要件、社内ポリシー、標準を理解する必要があります。開発チームやメンテナンスチームと協力して、機能にアクセスし、ユーザーに平等にサービスを提供できるようにする必要があります。中断時や急成長時であっても、ソリューションの可用性とパフォーマンスを計画する必要があります。適切に構築されたソリューションにとって、**信頼**されることほど不可欠なものはありません。

次のセクションでは、**信頼**できるソリューション アーキテクチャの主な考慮事項について、より詳細なガイダンスを提供します。

## 信頼済み概要

<table>
<tbody>
        <tr>
            <th scope="colgroup" colspan="3" class="guide-table-roadmap"><a href="/docs/architect/ja-jp/well-architected/guide/secure">安全</a></th>
        </tr>
        <tr>
        <td colspan="3">安全なシステムは、ビジネス、関係者、データを保護します。セキュアなアーキテクチャにより、承認されたユーザーのみがアクセスでき、ユーザーのアクセスを作業に不可欠なものに制限して、システム内のデータが侵害されないようにします。</td>
        </tr>
        <tr>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/ja-jp/well-architected/guide/secure#組織のセキュリティ">組織のセキュリティ</a></th>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/ja-jp/well-architected/guide/secure#セッションセキュリティ">セッションセキュリティ</a></th>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/ja-jp/well-architected/guide/secure#データセキュリティ">データセキュリティ</a></th>
        </tr>
        <tr>
            <td>認証 <br>Authorization</td>
            <td>セッション管理<br>デバイスアクセス <br>脅威の検出と対応</td>
            <td>共有と表示 <br>暗号化の使用</td>
        </tr>
        <tr>
            <th scope="colgroup" colspan="3" class="guide-table-roadmap"><a href="/docs/architect/ja-jp/well-architected/guide/compliant">適合</a></th>
        </tr>
        <tr>
        <td colspan="3">準拠ソリューションは、法的および倫理的なガイドラインに従います。準拠アーキテクチャは、法的規制と業界標準に準拠し、倫理ポリシーに準拠し、すべてのユーザーに公平に対応します。</td>
        </tr>
        <tr>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/ja-jp/well-architected/guide/compliant#法的遵守">法的遵守</th>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/ja-jp/well-architected/guide/compliant#倫理基準">倫理基準</th>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/ja-jp/well-architected/guide/compliant#アクセシビリティ">アクセシビリティ</th>
        </tr>
        <tr>
            <td>データプライバシー <br>ローカライズ</td>
            <td>会社の方針 <br>人工知能</td>
            <td>データエントリ <br>ナビゲーション</td>
        </tr>
        <tr>
            <th scope="colgroup" colspan="3" class="guide-table-roadmap"><a href="/docs/architect/ja-jp/well-architected/guide/reliable">信頼性</a></th>
        </tr>
        <tr>
        <td colspan="3">信頼性の高いソリューションは、さまざまな条件下で効率的かつ確実に動作します。信頼性の高いアーキテクチャは、ユーザーが期待するタイミングと場所で使用でき、一貫したパフォーマンスを提供し、ビジネスに合わせて拡張できます。</td>
        </tr>
        <tr>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/ja-jp/well-architected/guide/reliable#可用性">可用性</th>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/ja-jp/well-architected/guide/reliable#performance">パフォーマンス</th>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/ja-jp/well-architected/guide/reliable#拡張性">拡張性</th>
        </tr>
        <tr>
            <td>リスク管理 <br>障害の軽減 </td>
            <td>スループット <br>遅延</td>
            <td>データモデリング <br>データ量 </td>
        </tr>
        </tbody>
</table>

<!-- document id=c6830465ab87448033de2e101955f2f2d7c635dcb0a2e320073b6410d440bfea url=/architect/next/ja-jp/well-architected/guides/secure.md -->

> 更新スケジュールについては、[こちら](/docs/architect/ja-jp/well-architected/guide/contributors)を参照してください。

## はじめに

安全なシステムは、組織の関係者とデータを保護します。セキュアなアーキテクチャでは、ユーザー ID を検証し、必要な情報のみへのデータアクセスを制限し、データ侵害を防止します。

Salesforce は、Customer Trust とデータ セキュリティを優先します。Salesforce Platform はプライバシーとセキュリティを確保します。リアルタイムのシステム パフォーマンスおよびセキュリティ情報は、[Salesforce Trust](https://trust.salesforce.com/)で入手できます。

組織と顧客データを保護することは、セキュアな Salesforce ソリューションを構築するための基礎となります。Salesforce アーキテクトは、Salesforce の組み込みセキュリティ機能を利用して組織と顧客データを保護する責任を負います。これらの決定を行うときは、地理的分布、業種、会社の業務手順、顧客のデータ型を考慮します。

組織のセキュリティ、セッションのセキュリティ、データセキュリティの 3 つの領域に焦点を絞ることで、ソリューションのセキュリティを強化できます。

## 組織のセキュリティ

組織のセキュリティでは、検証済みの承認されたユーザーのみがシステムにアクセスでき、必要な機能とデータのみにアクセスできるようにすることで、不正なアクセスからシステムを保護します。

組織のセキュリティに問題があることを示す兆候には、次のようなものがあります。

- ユーザーを有効化または無効化するアドホックプロセス
- ユーザーまたはシステムロールの変更の承認を更新する手順が明確でない
- ユーザーセキュリティを正しく割り当てるための個人の組織的な Knowledge への依存
- 確立されたセキュリティフレームワークや業界のベストプラクティスに適合できない
- 構造化データガバナンスフレームワークとサポートポリシーがない

認証と承認に焦点を絞ることで、Salesforce 組織のより適切なセキュリティ制御を構築できます。

### 認証

認証は、システムにアクセスしようとしているユーザーの ID を検証する、セキュリティとアクセス管理に不可欠です。これは、人間のユーザー (従業員、顧客) と自動化されたユーザー (外部システム、インテグレーション) の両方に適用され、各ユーザー種別に特定の認証スキームが必要です。組織内のすべての Salesforce エントリポイントで安全なアクセスを確保するには、さまざまな認証方法を設定する必要があります。

Salesforce で安全な認証フローを作成する

- **人格ではなく個人に基づいて Salesforce ユーザーを作成します。**Salesforce の組み込み監査機能は、各ユーザーアカウントがプラットフォームにアクセスする 1 人の個人に対応している場合に最も効果的です。共有ユーザーアカウントを使用すると、これらの監査の有効性が低下し、セキュリティの脆弱性がさらに発生し、アカウント侵害の潜在的な影響がエスカレーションし、効果的な認証スキームを作成する機能が複雑になります。これには、インテグレーションユーザーのユーザーアカウントも含まれます。
- **安全な UI ベースのアクセスシナリオ**。ほとんどの人間のユーザーは、Salesforce 組織にある種の UI ベースのアクセス (ログインアクセスと呼ばれることが多い) を必要とします。Salesforce では、次のログインシナリオに対していくつかの保護レイヤーが提供されます。
  - **パスワードポリシー。**サイバー犯罪者は多くの場合、ユーザー名とパスワードを狙ってアプリケーションへの不正アクセスを取得します。[パスワード ポリシー](https://help.salesforce.com/s/articleView?id=sf.admin_password.htm&type=5)の設定は、ログイン アクセスを保護するための基本的なステップですが、Salesforce ではユーザーごとにポリシーを上書きできるため、これだけでは不十分であることに注意してください。
  - **多要素認証 (MFA)**。Salesforce では、すべての UI ベースのユーザーログインに [MFA が必要](https://help.salesforce.com/s/articleView?id=000352937&type=1)です。MFA は、ユーザー名とパスワードを正常に入力した後で追加の ID 形式または要素を入力するようにユーザーに要求することで、ログイン情報の漏洩やブルートフォース攻撃に対する重要な防御策を提供します。この追加要素は通常、モバイルデバイス、セキュリティキー、生体認証マーカーなどの物理的な形式を取ります。
  - **シングルサインオン (SSO)**。SSO シナリオでは、ユーザーは組織のアプリケーション全体で 1 セットのログイン情報のみを使用します。システムへのアクセスは一元的にプロビジョニングおよび管理されるため、セキュリティが向上します。Salesforce は、[SSO シナリオ](https://help.salesforce.com/s/articleView?id=sf.sso_about.htm&type=5)でサービスプロバイダーまたは ID プロバイダーとして機能できます。SSO 実装の停止や問題に対処できるように、一部またはすべてのシステム管理者が Salesforce に直接ログインできるようにします。
  - **ログイン後のステップ。**一部の使用事例では、システムにアクセスする前にユーザーが追加の手順を実行する必要がある場合があります。カスタムログインフローを実装して、次の追加プロセスステップでユーザーをガイドできます。例として、次のようなものがあります。
    - 契約条件への同意
    - [ログイン検出とパスワードなしのログインシナリオ](https://help.salesforce.com/s/articleView?id=sf.external_identity_passwordless_login_use_cases.htm&type=5)の使用
    - ユーザーあたりの同時 Salesforce セッション数を制限して、セッションベースの攻撃の可能性を減らす (「[セッションセキュリティ](/docs/architect/ja-jp/well-architected/guide/secure#セッションセキュリティ)」を参照)。
    - ジオフェンスサービスへの接続
- **安全な API ベース アクセス シナリオ**。すべてのユーザーが Salesforce 組織の API ベースのアクセスを要求できます。Salesforce では、API ベースのシナリオに対して次のような保護レイヤーが提供されます。
  - **API アクセスコントロール**。[API アクセス制御](https://help.salesforce.com/s/articleView?id=sf.security_api_access_control_about.htm&type=5)を使用しない場合、組織に接続アプリケーションが導入されていなくても、有効なログイン情報セットを持つすべてのユーザーが任意のアプリケーションを活用して組織に接続できます。データアクセス制御は引き続き適用されますが、ユーザーは制御されていない方法で情報にアクセスできました。たとえば、システム管理者の承認なしに、アプリケーションを使用して大量のデータをダウンロードしたり、破損した情報をアップロードしたりすることができます。
  - **API Only 権限**。Salesforce で API 限定ユーザー権限を設定できます。権限セットの一部としてこれを自動化ユーザーまたは[インテグレーションユーザー](https://help.salesforce.com/s/articleView?language=en_US&id=sf.integration_user.htm)人格に割り当てて、UI ベースのアクセスを完全にブロックします。
  - **証明書とキー**。[証明書と鍵](https://help.salesforce.com/s/articleView?id=sf.security_keys_about.htm&type=5)により、Salesforce は、承認された企業または会社からの要求であることを検証できます。[Salesforce で SSO](https://help.salesforce.com/s/articleView?id=sf.sso_about.htm&type=5) を使用する場合は、証明書とキーを設定する必要があります。
  - **接続アプリケーション**。Salesforce で[接続アプリケーション](https://help.salesforce.com/s/articleView?id=sf.connected_app_overview.htm&type=5)を設定すると、必要な認証プロトコル、認証範囲、セッションの動作など、Salesforce への外部システムアクセスを 1 つの定義で制御できます。
  - **指定ログイン情報**。[指定ログイン情報](https://help.salesforce.com/s/articleView?id=sf.named_credentials_define.htm&type=5)を使用すると、Salesforce 内の 1 つの定義で外部アクセス ポイントと認証プロトコルを制御できます。Apex、外部サービス、および Salesforce Connect データソースからのコールアウトの認証を安全に定義および管理するために使用できます。
- **Agentforce Agent ユーザー認証**。Salesforce 上に構築された Agentforce エージェントは、実際のユーザーと同様に管理可能な権限を持つエージェントユーザーオブジェクトを使用します。エージェントを設定するときは、アクセスをエージェントが果たす役割に合わせて慎重に調整し、データアクセスをエンドユーザーにサービスを提供するために必要なアクセスのみに制限します。同様に、エージェントは公開アクションと非公開アクションの両方で設定できます。非公開アクションの場合、エンドユーザーを検証して認証し、エージェントコンテキストに対応付けます。これにより、エージェントはエンドユーザーのアクセス制御内で偽装および操作を行い、セキュリティと Trust を維持できます。

次の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/secure#組織のセキュリティパターンとアンチパターン)のリストは、Salesforce 組織での適切な (および劣悪な) 認証アーキテクチャを示しています。これらを使用して、構築前に設計を検証したり、さらなる改善の機会を特定したりできます。

Salesforce で使用できる認証ツールについての詳細は、「[Tools Relevant to Secure](/docs/architect/ja-jp/well-architected/guide/secure#セキュリティに関連するツール) (セキュリティに関連するツール)」を参照してください。

### Authorization

認証では、ユーザーがアクセスできる機能、機能、データ、および[認証](/docs/architect/ja-jp/well-architected/guide/secure#認証)後にこれらのリソースを使用して実行できるアクションを定義します。認証制御は人間のユーザーのみを対象とするのではなく、Agentforce Agent ユーザー (特に、認証されていないエンドユーザーにサービスを提供するエージェント) に合わせて調整する必要があります。

組織で認証できるユーザーの制限は重要な最初のステップですが、強力な認証と堅牢な認証を組み合わせることも重要です。適切な承認制御がないと、ユーザーはレコードを作成、編集、削除したり、ビジネスや関係者に有害な方法でシステム機能にアクセスしたりする可能性があります。承認管理が不十分な場合、システムが使いづらくなる可能性もあります。ユーザーがシステム内で実行できる操作を制御することで、より高いレベルの Trust を促進し、システムとユーザーの両方を保護できます。

Salesforce の安全な認証スキームを作成する

- **最小権限の原則**に従います。ユーザーに ToDo に必要な権限のみを割り当てることで、最小権限 (PoLP) の原則を受け入れます。この原則に従うには、詳細でモジュール化された権限セットを設計します。これにより、権限セットグループを使用した高度なアクセス制御が可能になり、[ミュート](https://help.salesforce.com/s/articleView?id=sf.perm_set_groups_muting.htm&type=5)や[有効期限の設定](https://help.salesforce.com/s/articleView?id=release-notes.rn_forcecom_permissions_assn_expiration.htm&type=5&release=238)などの権限を正確に管理できます。システムの[機能単位](/docs/architect/ja-jp/well-architected/guide/composable#機能単位)をビジネス機能に合わせて、詳細な権限と有効な権限セットグループを定義します。権限は、Salesforce の*メタデータ*アクセスに適用されます。Salesforce *データ*アクセスの PoLP の設定についての詳細は、「[共有と表示](/docs/architect/ja-jp/well-architected/guide/secure#共有と表示)」を参照してください。
- **ユーザーアクセスは、個人ではなく人格の観点から考えます。**個々のユーザーの観点から認証 (またはセキュリティ全般) を考慮すると、システムを拡張および進化させることはできません。代わりに、ユーザーのグループを表す人格を設計して管理します。セキュアな Salesforce ソリューションでは、認証に個人を使用し、認証に人格を使用します。個別の人格のセキュリティ設定を定義することで、セキュリティモデルのアクセス権と権限を詳細に制御できるため、長期的にリファクタリングする必要が最小限に抑えられます。定義するセキュリティ人格を[設計標準とドキュメント](/docs/architect/ja-jp/well-architected/guide/intentional#読みやすさ)に含めます。
- **権限セットと権限セットグループを使用して、メタデータへのユーザーアクセスを制御します。**権限セットと権限セットグループは、ユーザーがアクセスできるメタデータとそのメタデータで実行できる操作を制御します。Salesforce メタデータについての詳細は、「[メタデータとデータ](/docs/architect/ja-jp/fundamentals/guide/architecture-basics#メタデータとデータ)」を参照してください。権限セットと権限セットグループを使用して、アプリケーションの割り当て、機能ライセンスの有効化、管理パッケージアクセス、システム権限、[CRUD](https://developer.salesforce.com/docs/atlas.en-us.214.0.lightning.meta/lightning/apex_crud_fls.htm) アクセス、項目レベルのアクセスを設定します。このアクセス権を[設計標準とドキュメント](/docs/architect/ja-jp/well-architected/guide/intentional#読みやすさ)に含めます。
- **組織の共有設定 (OWD) と共有を使用して、ユーザーのデータアクセスを制御します。**[データとメタデータ](/docs/architect/ja-jp/fundamentals/guide/architecture-basics#メタデータとデータ)は Salesforce では別個のエンティティであり、それぞれに個別のアクセス制御が必要です。OWD と組み込み共有ツールを使用して、Salesforce データ (個々のレコード、ファイル、ドキュメント) のアクセス権を設定します。詳細は、「[データセキュリティ](/docs/architect/ja-jp/well-architected/guide/secure#データセキュリティ)」を参照してください。
- **OAuth 範囲を使用して、接続アプリケーションのアクセスを制御します。**接続アプリケーションを設定するときに、アプリケーションユーザーが Salesforce リソースに対して持つ[範囲](https://help.salesforce.com/s/articleView?id=remoteaccess_oauth_tokens_scopes.htm&type=5&language=en_US)またはアクセス権限を定義します。OAuth トークンの管理についての詳細は、「[セッション管理」](/docs/architect/ja-jp/well-architected/guide/secure#セッション管理)を参照してください。
- **インテグレーションごとに 1 人の Salesforce ユーザーを作成します。**最小権限の原則に従うには、インテグレーションごとに一意の Salesforce [インテグレーションユーザー](https://help.salesforce.com/s/articleView?id=sf.integration_user.htm)を作成します。これにより、特定のデータアクセスを割り当てて、操作の制御を改善し、トランザクションのトレーサビリティを確保し、潜在的なセキュリティ侵害の影響を最小限に抑えることができます。
- **すべてのエージェントユーザーに対して PoLP を使用して一意のアカウントを実装します。**各 Agentforce Agent ユーザーは一意であり、複数のエージェントで再利用しないでください。これらのアカウントの権限は、最小権限の原則に厳密に従う必要があります。エージェントユーザーが実行するアクションは、Salesforce 内の高度なセキュリティコンテキストで、または Salesforce のアクセス制御が適用されない外部システムに対して動作する場合があります。これにより、アクションが機密情報にアクセスしたり、ユーザーに開示したりする可能性があります。
- **プロファイルの使用を最小限に抑え、プロファイル外のアクセス制御を移行します。**プロファイルを使用すると、[ログイン IP 範囲](https://help.salesforce.com/s/articleView?id=sf.security_networkaccess.htm&type=5)、[ログイン時間](https://help.salesforce.com/s/articleView?id=sf.login_hours.htm&type=5)、従来の Salesforce Classic ユーザー インターフェイスに固有の機能(具体的には、デフォルトのレコード タイプとページ レイアウトの割り当て)へのアクセスを制限できます。現在プロファイルにあるその他の機能は、[権限セットおよび権限セットグループ](https://help.salesforce.com/s/articleView?id=sf.perm_set_groups_create_with_perm_sets.htm)の同等の機能に移行する必要があります。Salesforce Classic UI 機能に関連付けられたプロファイルの機能は、修復の対象にする必要があります。

次の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/secure#組織のセキュリティパターンとアンチパターン)のリストは、Salesforce 組織での適切な (および不適切な) 認証方法を示しています。これらを使用して、構築前に設計を検証したり、さらなる改善の機会を特定したりできます。

Salesforce から入手できる認証ツールについての詳細は、「[Tools Relevant to Secure](/docs/architect/ja-jp/well-architected/guide/secure#セキュリティに関連するツール) (セキュリティに関連するツール)」を参照してください。

### 組織のセキュリティパターンとアンチパターン

次の表に、組織で検索 (または作成) するパターンと、回避または修正の対象となるアンチパターンの選択を示します。

✨ [パターン & アンチパターンエクスプローラー](/docs/architect/ja-jp/well-architected-tools/guide/trusted-organizational-security)で、組織のセキュリティに関するより多くのパターンを検出します。

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">パターン</th>
            <th scope="colgroup">アンチパターン</th>
        </tr>
        <tr>
            <td rowspan="3"><b>認証</b></td>
            <td><b>設計標準およびドキュメント:</b>
            <br> 承認済みセキュリティ人格が明確に定義され、リストされている
            <br> - セキュリティマトリックスにセキュリティ人格と許可された認証スキーム (UI、API) の対応付けが存在する</td>
            <td><b>設計標準とドキュメントが存在する場合、次のことを行います。</b>
            <br> - セキュリティ人格を含めない
            <br> -セキュリティ人格と許可された認証スキームの明確な対応付けを含むセキュリティマトリックスを含めない</td>
        </tr>
        <tr>
            <td><b>組織内：</b>
            <br> - <a href="https://security.salesforce.com/mfa-requirement-check">Salesforce MFA Check</a> に合わせたログイン設定
            <br> -Salesforce にログインしているユーザーとエンティティのリレーションは 1 対 1 (共有ユーザーなし)
            <br> - <a href="https://help.salesforce.com/s/articleView?language=en_US&type=5&id=sf.security_api_access_control_about.htm">API アクセスコントロール</a>により、未承認の接続アプリケーションを介したユーザーの認証を防止
            <br> SSO が有効になっている場合、承認された管理者ユーザーにダイレクトログインアクセス権がある</td>
            <td><b>組織内：</b>
            <br> - ログイン設定が <a href="https://security.salesforce.com/mfa-requirement-check">Salesforce MFA Check</a> に適合していない
            <br> -Salesforce にログインしているユーザーとエンティティ間のリレーションが 1 対 1 ではない (共有ユーザーアカウントがある)
            <br> - ユーザーがファイアウォールの内側から Salesforce にアクセスする場合、ファイアウォールはハードコードされた IP アドレスを使用して Salesforce との間の通信を保護します。
            <br> - <a href="https://help.salesforce.com/s/articleView?language=en_US&type=5&id=sf.security_api_access_control_about.htm">API アクセスコントロール</a>が有効になっていない
            <br> -SSO が有効になっている場合、承認された管理者ユーザーには直接ログインアクセス権がありません。</td>
        </tr>
        <tr>
            <td><b>LWC、Apex、Aura の場合:</b>
            <br> - 認証を実行するメソッドは、指定ログイン情報を使用してユーザー名/パスワードフローを処理します。
            <br> - ユーザー名やパスワードが判読可能な形式でコードに表示されない (ハードコードされた値や文字列がない)
            <br> - カスタムログインフローが存在する場合、関連するすべてのカスタムコードで適切な <code>SessionManagement</code> メソッドが使用されます。</td>
            <td><b>LWC、Apex、Aura の場合:</b>
            <br> - 認証がアドホックで処理される
            <br> - ユーザー名とパスワードがコードに表示される</td>
        </tr>
        <tr>
            <td rowspan="4"><b>Authorization</b></td>
            <td><b>設計標準およびドキュメント:</b>
            <br> - Salesforce へのアクセス権を持つすべてのユーザーとシステムがセキュリティマトリックスの 1 つ以上の人格に対応付けられる
            <br> -セキュリティマトリックスには、メタデータ権限と割り当てられたユーザー人格が明確にリストされています。
            <br> - 権限を昇格させる使用事例が明確にリストされている。たとえば、次のようなケースがあります。
            <br> -- 「すべてのデータの編集」権限
            <br> -- 「すべてのデータの参照」権限 </td>
            <td><b>設計標準とドキュメントが存在する場合、次のことを行います。</b>
            <br> - セキュリティマトリックスを含めない
            <br> - 権限を明確にリストしない
            <br> - 権限の昇格を許可する使用事例を明確にリストしない</td>
        </tr>
        <tr>
            <td><b>組織内：</b>
            <br> 権限セットと権限セットグループは、メタデータへのアクセスを制御するために使用されます。
            <br> - 権限セットと権限セットグループはビジネス機能に合わせて調整
            <br> - ユーザーに割り当てられた権限は、セキュリティマトリックス定義に従います。
            <br> - プロファイルは、ログイン IP アドレスの制限とログイン時間を制御するためにのみ最小限使用されます。
            <br> - すべてのインテグレーションに一意の API 専用インテグレーションユーザーが設定されている</td>
            <td><b>組織内：</b>
            <br> - 権限セットグループがビジネス機能に基づいてアクセスできるように設定されていない
            <br> 権限セットがアドホックに設定されている
            <br> - 権限セットが冗長であるか、重複が激しい。明確な機能ロジックやセット間の違いを理解するのが難しい。
            <br> - ユーザーに割り当てられた権限がセキュリティマトリックス定義に従っていない
            <br> - プロファイルにはメタデータのアクセス制御が含まれます。
            <br> - API 限定ユーザーが設定されていないか、複数のインテグレーションで共有されている</td>
        </tr>
        <tr>
            <td><b>Apex:</b>
            <br> - データベース操作では、次のような項目レベルおよびオブジェクトレベルのアクセスチェックが適切に実行されます。
            <br> -- DML およびデータベース DML ステートメントは、データ操作の<a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_enforce_usermode.htm">ユーザーモード</a>またはシステムモードを宣言します。
            <br> -- DML およびデータベース DML ステートメントでは、データ操作の前に <code>stripInaccessible</code> メソッドを使用します。
            <br> -- SOQL および SOSL ステートメントは、<code>WITH USER_MODE</code> および <code>WITH SYSTEM_MODE</code> キーワードおよび/または
            <br> -- <code>stripInaccessible</code> メソッドは、クエリ結果とサブクエリ結果を絞り込むために使用されます。
            <br> -- sObject describe の結果メソッド (<code>isAccessible</code>、<code>isCreateable</code>、<code>isUpdateable</code>、<code>isDeletable</code>) は慎重に使用されます。</td>
            <td><b>Apex:</b>
            <br> - DML、データベースクラスのメソッド、SOQL および SOSL がデフォルトのシステムモードで実行
            <br> - 次のようなデータベース操作では、アクセスチェックが適切に実行されません。
            <br> -- DML またはデータベースクラスのメソッドでは、sObject および項目レベルのアクセス権に対して <code>isAccessible</code>、<code>isCreateable</code>、<code>isUpdateable</code>、<code>isDeletable</code> チェックのみが使用されます。
            <br> -- SOQL クエリは、アクセス制限に <code>WITH SECURITY_ENFORCED</code> キーワードのみを使用します。</td>
        </tr>
        <tr>
            <td><b>フロー内</b><a href="https://developer.salesforce.com/docs/atlas.en-us.secure_coding_guide.meta/secure_coding_guide/secure_coding_considerations_flow_design.htm">(フロー設計のセキュリティに関する考慮事項)</a><b>:</b>
            <br> - フローでは、可能な限り制限の厳しい実行コンテキスト (理想的にはユーザーモード) が使用されます。
            <br> -セキュリティ上の機密データや特権データへのアクセスは、実行コンテキストを最小限に抑えるためにサブフローによって実行されます。
            <br> - レコードトリガーフローで実行されるロジックの制限
            <br> フロー入力が検証され、許可されたペイロードのみが入力として渡されることを確認します。</td>
            <td><b>フロー内:</b>
            <br> - フローが実行するアクションに関係なく、フローはシステムモードまたは共有なしのシステムモードで実行されます。
            <br> - すべてのフローロジックが 1 つの大きなフロー内で実行される
            <br> - フロー入力は検証されず、検証なしでコンシューマーに渡されます。</td>
        </tr>
    </tbody>
</table>

## セッションセキュリティ

セッションとは、ユーザーに関連付けられた一定期間の一連の要求と応答です。ユーザーが Salesforce に対して正常に認証されると、セッションが開始されます。[セッションセキュリティ](https://help.salesforce.com/s/articleView?language=en_US&type=5&id=sf.security_overview_sessions.htm)とは、セッションの干渉やハイジャックを阻止して不正アクセスやデータ侵害を防止するようにシステムを設定する方法です。

システムのすべてのユーザー活動はセッションのコンテキスト内で発生するため、セッションの開始方法、セッション中に実行できること、ユーザーが使用する (および使用する) デバイス、疑わしいセッション動作や異常なセッション動作を検出して対処する方法を考慮することが重要です。

Salesforce でセッションセキュリティを構築するには、セッション管理、デバイスアクセス、脅威の検出と対応という 3 つの鍵に焦点を当てます。

### セッション管理

セッションは、ユーザーが正常に認証され、Salesforce へのアクセス権が付与されたときに開始されます。これらのセッションにより、プラットフォームは特定の要求と応答を特定のユーザーに関連付けることができます。

HTTPS プロトコルは、フロントエンドクライアントと Salesforce Platform 間の通信を容易にします。クライアントには、ブラウザー、モバイルアプリケーション、ローカルアプリケーションなどが含まれます。HTTPS はステートレスなプロトコルです。つまり、すべての通信は個別であり、以前または将来の通信とは無関係です。

このステートレスなアプローチにより、ネットワーク通信が高速化され、パケット間のリンクの切断によるエラーが排除されます。ただし、Web アプリケーションには、複数の要求と応答のやり取りで各ユーザーの ID やその他の関連情報を追跡する方法がまだ必要です。Salesforce は、ほとんどの Web アプリケーションと同様に、セッションと[トークン](https://help.salesforce.com/s/articleView?id=sf.remoteaccess_oauth_tokens_scopes.htm&type=5)を使用してこれを実現します。

- **セッション**により、Salesforce は要求と応答をユーザーに関連付けることができます。ユーザーが認証されると、プラットフォームはセッション ID をクライアントアプリケーションに送信します。この ID には、ユーザーの要求 (データの移動、検索、送信など) が含まれます。
- **トークンを使用**すると、ユーザーおよび接続アプリケーションは ID を 1 回検証するだけで、それ以降は一意のアクセストークンを使用できます。トークンの有効期限は制限され、特定のリソースへのアクセスのみが許可されます（アクセスレベルの設定についての詳細は、「[認証](/docs/architect/ja-jp/well-architected/guide/secure#authorization)」を参照してください）。トークンを使用すると、ユーザーがログインしなくても、承認されたリソースにアクセスできます。

セッションとトークンが適切に保護されていない場合、悪意のある人物がセッションとトークンを妨害し、ユーザーになりすましたり、システムで悪意のあるコードを実行したりする可能性があります。

Salesforce の安全なセッション管理を構築する

- **Salesforce でセッション種別がどのように分類されるかを理解**します。承認済み[セッション種別](https://help.salesforce.com/s/articleView?id=sf.security_session_types.htm&type=5)を特定してセキュリティユーザー人格に対応付け、ドキュメントに記録します。
- **セッションの発信方法とセッション トラフィックの送信先を制御します。**さまざまなユーザー人格が開始できるセッションの種類を特定したら、未承認のソースまたはコンテキストから発生するセッションをブロックするコントロールを設定します。Salesforce では、次のようなセッションの開始元とトラフィックを制御する方法がいくつか用意されています。
  - **組み込みセッション保護**。Salesforce では、クロスサイトスクリプティング、クロスサイト要求フォージェリ、[コンテンツ盗聴](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types#mime_sniffing)、[クリックジャック](https://owasp.org/www-community/attacks/Clickjacking)など、セッションベースの悪意のある活動に対する組織全体の保護が自動的に有効になります。これらの保護は無効にしないでください。無効にできない保護もあります。
  - **ドメインと IP 範囲**。すべての Salesforce 組織で[\[私のドメイン](https://help.salesforce.com/s/articleView?id=sf.domain_name_overview.htm&type=5)]がデフォルトで有効になっており、Salesforce アクセス用の会社固有のサブドメインが作成されます。\[私のドメイン] を使用して、組織に関連付けられた名前をカスタマイズまたは変更できます。さらに、Salesforce では Experience Cloud サイトやその他のアプリケーションページの追加[ドメイン設定](https://help.salesforce.com/s/articleView?id=sf.domain_mgmt_overview.htm&type=5)をサポートしています。注意:ユーザーが会社のファイアウォールの内側から Salesforce にアクセスする必要がある場合、[必要なドメイン](https://help.salesforce.com/s/articleView?id=sf.setup_domains.htm&type=5)をファイアウォールの許可リストに追加します。[ログイン IP アドレス](https://developer.salesforce.com/docs/atlas.en-us.securityImplGuide.meta/securityImplGuide/users_profiles_epui_login_ip_ranges_edit.htm)と[信頼済み IP アドレス](https://help.salesforce.com/s/articleView?id=sf.security_networkaccess.htm)を設定して、Salesforce への受信ログイン要求とセッション要求を制御できます。
  - **ログイン時間**。特定のユーザー 人格が勤務時間を設定している場合、定義され[たログイン時間](https://help.salesforce.com/s/articleView?id=sf.login_hours.htm&type=5)外に Salesforce にアクセスするユーザー 人格を制限できます。
- セッションレベルセキュリティの強化が必要な活動を**制御します**。デフォルトでは、セッションには標準と高保証の 2 種類の[セキュリティレベル](https://help.salesforce.com/s/articleView?id=sf.security_overview_sessions.htm&type=5)を設定できます。これらのセキュリティレベルを使用して、ユーザーがレポートやダッシュボードへのアクセス、Salesforce 組織のセキュリティ設定の管理などの活動を実行できるようにする方法と実行できないようにする方法を制御します。セッションレベルのセキュリティポリシーでは、ユーザーが操作を実行するために[高保証セッション](https://help.salesforce.com/s/articleView?id=sf.security_auth_require_ha_session.htm&type=5)の確立を要求したり、機密操作の実行をブロックしたりする場合があります。
- セッションベースの権限の追加が必要な活動を**制御します**。Salesforce では、[セッションベースの権限](https://help.salesforce.com/s/articleView?id=sf.perm_sets_session_use.htm&type=5)の有効化がサポートされ、特定のセッション中にユーザーが権限の昇格やアクセス権の付与を一時的に許可できます。セッションベースの権限は、フローまたは Salesforce API で有効化および無効化できます。
- **タイムアウト**による無効なユーザーセッションの管理。無効なセッションを終了することは、セッションセキュリティの管理の重要な部分です。これにより、たとえば、ユーザーがブラウザータブで Salesforce セッションを開いたままにして別のアプリケーションで作業している場合や、ユーザーのモバイルデバイスが Salesforce にログインしていて無人の場合にシステムを保護できます。Salesforce のデフォルトのセッション無操作タイムアウトは 2 時間です。セッションの無操作タイムアウトレベルを増減できますが、タイムアウトの増減は、説得力のある十分な根拠に基づいて行う必要があります。
- **トークン設定を使用して接続アプリケーションセッションを管理します。**接続アプリケーションを設定するときに、接続アプリケーションを使用して Salesforce にアクセスするユーザーに付与される範囲 (認証レベル) も定義します。この範囲は、接続アプリケーションのユーザーが正常に認証された後に発行される [OAuth トークン](https://help.salesforce.com/s/articleView?id=remoteaccess_oauth_tokens_scopes.htm&type=5&language=en_US)を使用してセッションレベルで適用されます。トークンの有効期間は、[トークン更新ポリシー](https://help.salesforce.com/s/articleView?id=remoteaccess_oauth_tokens_scopes.htm&type=5&language=en_US)を使用して制御できます。組織管理者は、必要に応じてユーザーごと、または組織ごとにトークンを手動で取り消すことができます。

次の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/secure#セッションセキュリティパターンとアンチパターン)のリストは、Salesforce 組織での適切な (および不適切な) セッション管理を示しています。これらを使用して、構築前に設計を検証したり、さらなる改善の機会を特定したりできます。

Salesforce から入手できるセッション管理ツールについての詳細は、「[Tools Relevant to Secure](/docs/architect/ja-jp/well-architected/guide/secure#セキュリティに関連するツール) (セキュリティに関連するツール)」を参照してください。

### デバイスアクセス

現在のコンテキストでは、*デバイス*とは、デスクトップワークステーション、ノートパソコン、タブレット、携帯電話など、個人が Salesforce にアクセスするために使用する電子機器を指します。

ポータブルデバイスを使用すると、ユーザーはどこからでも柔軟に Salesforce にアクセスできます。ただし、この利便性により、悪意のあるアクターにさらなる攻撃ベクトルがもたらされる可能性があります。これらの脅威ベクトルは、公共の場所で肩を並べてログイン情報を盗む単純な戦術から、デバイスにマルウェアをインストールしたり、偽の公衆 Wi-Fi ネットワークを作成してデータ送信を傍受したりするより高度な方法まで多岐にわたります。このため、デバイス (特にポータブルデバイス) のセキュリティ保護は、システム全体のセキュリティにとって不可欠です。

Salesforce のデバイスアクセスを保護する

- **Salesforce 提供**のモバイルアプリケーションソリューション。Salesforce にアクセスする必要があるモバイルデバイスのユーザーに、iOS および Android で使用可能な公式の [Salesforce アプリケーション](https://help.salesforce.com/s/articleView?id=sf.mobile_security.htm&type=5)を使用してもらいます。ビジネスニーズにカスタムモバイルソリューションが必要な場合は、安全な認証および承認方法を提供する [Salesforce Mobile SDK](https://developer.salesforce.com/docs/atlas.en-us.mobile_sdk.meta/mobile_sdk/intro.htm) を使用する必要があります。
- **モバイルデバイスの使用をセッション管理に組み込みます**。セッションセキュリティレベル、セッションタイムアウト、その他のセッションコンテキスト制御では、モバイルデバイスでのユーザーからの予想されるアクセスを考慮する必要があります。Salesforce へのアクセスを許可するデバイスと許可しないデバイス、およびモバイルセッションにアクセスできるユーザーの種類を検討します。セキュリティ人格ドキュメントにモバイルアクセス標準を含めます。このトピックについての詳細は、「[セッション管理」](/docs/architect/ja-jp/well-architected/guide/secure#セッション管理)を参照してください。
- **モバイルデバイス管理 (MDM) テクノロジーを使用して、デバイスレベルのセキュリティを補完します。**iOS および Android 用の Salesforce アプリケーションは、[多くの一般](https://help.salesforce.com/s/articleView?id=sf.mobile_security_mdm.htm&type=5)的な MDM スイートと互換性があります。任意の MDM ソリューションを使用して、ユーザーデバイスの Salesforce アプリケーションの追加のアクセス制御を設定できます。
- **モバイルアプリケーション管理 (MAM) テクノロジを使用してアプリケーションレベルのセキュリティを補完します。**MAM テクノロジーは、モバイルデバイスでのアプリケーションレベルの制御をサポートします。Salesforce では、Salesforce モバイルアプリケーション用の有料[MAM アドオン](https://help.salesforce.com/s/articleView?id=sf.mobile_security_mam_overview.htm&type=5)を提供しています。

次の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/secure#セッションセキュリティパターンとアンチパターン)のリストは、Salesforce 組織での適切な (および不適切な) デバイス管理を示しています。これらを使用して、構築前に設計を検証したり、さらなる改善の機会を特定したりできます。

Salesforce から入手できるデバイス管理ツールについての詳細は、「[Tools Relevant to Secure](/docs/architect/ja-jp/well-architected/guide/secure#セキュリティに関連するツール) (セキュリティに関連するツール)」を参照してください。

### 脅威の検出と対応

脅威検知は、悪意のある活動を示している可能性があるシステム内の行動パターンを特定するプロセスです。これには、ダウンロードされるデータ量が平均を超えている場合や、ユーザーが平均よりも短い期間内に複数のレコードの機密データを含む項目を変更した場合などがあります。脅威への対応には、自動セッションの有効期限、アラート、その他の通知を含めることができます。

脅威検知の目標は、潜在的な問題をできるだけ早く特定して対応することです。リアルタイムの脅威検知に基づいてアクションを実行することで、悪意のある行動を追跡から阻止できます。Salesforce は、アドオンまたは [Salesforce Shield](https://www.salesforce.com/products/platform/products/shield/) の一部として[リアルタイムイベント監視](https://help.salesforce.com/s/articleView?id=sf.real_time_event_monitoring_overview.htm&type=5)を提供します。機密性の高いアプリケーションがある場合や、堅牢なリアルタイムの脅威検知および対応機能が必要な場合、次のいずれかのソリューションを使用します。

Salesforce ソリューションの効果的な脅威検知および対応戦略を構築する

- **組み込み監査機能**。Salesforce には、組織への変更を追跡および監査するのに役立つさまざまな[組み込みツール](https://help.salesforce.com/s/articleView?id=sf.monitoring_admin.htm&type=5)が用意されています。たとえば、[監査履歴設定](https://help.salesforce.com/s/articleView?id=sf.admin_monitorsetup.htm&type=5)では、管理アクションの監査履歴を表示できます。Salesforce では、デフォルトで項目レベルの変更が一定期間追跡されますが、[項目履歴管理](https://help.salesforce.com/s/articleView?id=sf.tracking_field_history.htm&type=5)を有効化して、項目の変更を UI で最大 18 か月間、API で最大 24 か月間表示できます。また、[項目監査履歴](https://help.salesforce.com/s/articleView?id=sf.field_audit_trail.htm&type=5)を有効化して、項目レベルの変更に関する監査履歴を無期限に保持できます (データを手動で削除するまで)。
- **定期的な監査レビュー**。リアルタイムの脅威検知で見逃される可能性のある異常な変更を特定するには、監査が不可欠です。正当なアクセス権を持つユーザーが長期にわたって毎日少数のレコードを一貫して削除するシナリオを考えてみます。このユーザーは、有効なログイン情報を持ち、レコードを削除する適切な権限を持っており、大量のレコードを一度に削除していないため、活動がリアルタイムの脅威として検出される可能性はほとんどありません。ただし、ユーザー活動レポートを確認する監査チームは、1 人のユーザーが経時的に過剰にレコードを削除しているこの傾向を明確に特定できるため、簡単に対処できます。[ガバナンス ポリシー](/docs/architect/ja-jp/well-architected/guide/intentional#ガバナンス)の一環として、ログイン履歴、ユーザー セッション アクティビティ、接続アプリケーションの使用状況を監査する定期的な間隔を設定します。
- **脅威対応戦略を作成し、セキュリティポリシーに含めます。**次の内容をカバーする脅威対応戦略を作成します。
  - 脅威対応種別定義(アラートや自動化など)と[関連する](/docs/architect/ja-jp/well-architected/guide/resilient#インシデント対応)関係者グループ。メッセージまたはアラートの設計についての詳細は、「[エラーと通知](/docs/architect/ja-jp/well-architected/guide/engaging#通知とメッセージ)」を参照してください。
  - 脅威とみなされる可能性があるリアルタイムの変更または活動の特定のカテゴリと、各カテゴリに関連付けられた対応種別
  - すべての自動脅威対応 (トークンの取り消し、セッションの終了、ユーザーアカウントの無効化、リソースへのアクセスのブロックなど) と自動化トリガーの明確なリスト

イベント監視では、リアルタイムの脅威の検出と対応を有効にすることで、この原則を適用するために必要なデータが提供されます。トランザクションセキュリティでは、会社のポリシーベースのアクションが適用され、イベント種別では、経時的なユーザーおよびアプリケーションアクセスの監視がサポートされます。

Salesforce のネイティブ脅威検知サービスは、統計モデルと機械学習モデルを使用して疑わしい行動を識別します。このサービスは、サイバー攻撃や疑わしいデータアクセスから保護する特定のイベントを生成します。

トランザクションセキュリティでは、組織で発生する主要なイベントを捕捉し、会社のポリシーベースのアクションを適用するフレームワークが提供されるため、セキュリティがさらに強化されます。これにより、イベント監視がロギングツールから自動セキュリティ防御の重要なコンポーネントに変わります。

以下の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/secure#セッションセキュリティパターンとアンチパターン)のリストは、Salesforce 組織での適切な (および不適切な) 脅威の検出と対応を示しています。これらを使用して、構築前に設計を検証したり、さらなる改善の機会を特定したりできます。

Salesforce から入手できる脅威の検出、アラート、対応の自動化ツールについての詳細は、「[Tools Relevant to Secure](/docs/architect/ja-jp/well-architected/guide/secure#セキュリティに関連するツール)」を参照してください。

### セッションセキュリティパターンとアンチパターン

次の表に、組織で検索 (または作成) するパターンと、回避または修正の対象となるアンチパターンの選択を示します。

✨ [パターン & アンチパターンエクスプローラー](/docs/architect/ja-jp/well-architected-tools/guide/trusted-session-security)で、セッションセキュリティのその他のパターンを検出します。

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">パターン</th>
            <th scope="colgroup">アンチパターン</th>
        </tr>
        <tr>
            <td rowspan="3"><b>セッション管理</b></td>
            <td><b>設計標準およびドキュメント:</b>
            <br> -セキュリティ人格には、各人格の承認済みセッション種別とタイムアウト/期間設定が明確に記載されています。
            <br> - ログイン時間が指定されている (または不要として識別されている)
            <br> - 高度なセッションレベルセキュリティまたは権限を必要とする操作が明確で検出可能
            <br> - 接続アプリケーションの範囲とトークン管理ポリシーが明確で検出可能</td>
            <td><b>設計標準およびドキュメント:</b>
            <br> - セキュリティ人格が存在しないか、セッション種別とタイムアウト/期間設定に関する情報が不足しています。
            <br> - セキュリティポリシーに接続アプリケーションの範囲やトークン管理に関する情報が含まれていない</td>
        </tr>
        <tr>
            <td><b>組織内：</b>
            <br> - セッション監査では、ユーザーは予期されるセッション種別でのみ Salesforce にアクセスできます。
            <br> -「API 限定ユーザー」アクセスに対する明確な有効な権限セットがあり (「API 限定」権限が TRUE に設定されている)、すべてのインテグレーションユーザーと自動化ユーザーが割り当てられている
            <br> - ユーザーがファイアウォールの内側から Salesforce にアクセスする場合、ファイアウォールは IP アドレスではなく必須ドメインの許可リストを使用して、Salesforce との間の通信を保護します。
            <br> - 無効なセッションタイムアウト間隔がデフォルト (2 時間) を超えていない
            <br> 次の設定がすべて有効になっている。
            <br> -- [設定] ページのクリックジャック保護
            <br> -- 設定以外の Salesforce ページのクリックジャック保護
            <br> -- クロスサイトリクエストフォージェリ (CSRF) 保護
            <br> -- クロスサイトスクリプティング (XSS) 保護
            <br> -- コンテンツ盗聴保護の有効化
            <br> -- 参照元 URL の保護
            <br> -- Salesforce の外部にリダイレクトされる前にユーザーに警告する</td>
            <td><b>組織内：</b>
            <br> 定期的なセッション監査がない
            <br> - ユーザーが持つべきセッション種別の定義がない
            <br> インテグレーションユーザーと自動化ユーザーで「API のみ」権限が不明瞭または欠落している
            <br> - ユーザーがファイアウォールの内側から Salesforce にアクセスする場合、ファイアウォールはハードコードされた IP アドレスを使用して Salesforce との間の通信を保護します。
            <br> - 無効なセッションタイムアウト間隔がデフォルト (2 時間) を超えている
            <br> 次のいずれかの設定が無効になっている。
            <br> -- [設定] ページのクリックジャック保護
            <br> -- 設定以外の Salesforce ページのクリックジャック保護
            <br> -- クロスサイトリクエストフォージェリ (CSRF) 保護
            <br> -- クロスサイトスクリプティング (XSS) 保護
            <br> -- コンテンツ盗聴保護の有効化
            <br> -- 参照元 URL の保護
            <br> -- Salesforce の外部にリダイレクトされる前にユーザーに警告する</td>
        </tr>
        <tr>
            <td><b>LWC、Apex、Aura の場合:</b>
            <br> - カスタムログインフローが存在する場合、関連するすべてのカスタムコードで適切<code>な SessionManagement</code> メソッドを使用してセッションレベルセキュリティを割り当てる</td>
            <td><b>LWC、Apex、Aura の場合:</b>
            <br> - カスタムログインフローが存在する場合、セッションレベルセキュリティを割り当てるロジックはありません。</td>
        </tr>
        <tr>
            <td rowspan="2"><b>デバイスアクセス</b></td>
            <td><b>設計標準およびドキュメント:</b>
            <br> - デバイスポリシーが明確で検出可能
            <br> -セキュリティ人格が適切なデバイスの使用状況とポリシーに明確に対応付けられている</td>
            <td><b>設計標準およびドキュメント:</b>
            <br> セキュリティポリシーが存在しないか、デバイスアクセスに関する情報が含まれていない</td>
        </tr>
        <tr>
            <td><b>組織内：</b>
            <br> - Salesforce モバイル接続アプリケーションの設定で、無操作状態の後に PIN/パスコードロック解除が必要
            <br> ビジネスニーズにより、Salesforce モバイルにアクセスできるユーザーの厳格な制御が必要な場合、API アクセス制御が有効になり、Salesforce モバイルアプリケーションのすべてのユーザーに権限セットが割り当てられます。</td>
            <td><b>組織内：</b>
            <br> - Salesforce モバイル接続アプリケーションが、無操作時に PIN/パスコードロック解除を要求するように設定されていない
            <br> – ビジネスニーズにより、Salesforce モバイルにアクセスできるユーザーを厳密に制御する必要があるが、API アクセス制御が有効になっていない、または権限セットを使用して Salesforce モバイルアプリケーションへのアクセスを制御していない</td>
        </tr>
        <tr>
            <td rowspan="3"><b>脅威の検出と対応</b></td>
            <td><b>設計標準およびドキュメント:</b>
            <br> -セキュリティポリシーには、応答をトリガーする必要があるイベントのリストと適切な応答種別が含まれます。
            <br> - データモデルのすべてのオブジェクトで監査レベルが指定されている<br> - Salesforce 内で使用可能なログを確認する手順が文書化されている
            <br> - すべての自動応答が明確に文書化されている</td>
            <td><b>設計標準およびドキュメント:</b>
            <br> セキュリティポリシーが存在しないか、脅威の検出とアラートに関する情報が含まれていない
            <br> - 自動レスポンスのドキュメントが存在しないか不明瞭である</td>
        </tr>
        <tr>
            <td><b>社内：</b>
            <br> -監査データは、ビジネス関係者が理解してアクセスできるレポートで利用できます。
            <br> - 監査履歴とレポートの定期的な確認</td>
            <td><b>社内：</b>
            <br> -監査データは、アクセスと解釈に専門分野の専門知識が必要なログファイルでのみ使用できます。
            <br> - 監査情報をレビューするプロセスが存在しない</td>
        </tr>
        <tr>
            <td><b>組織内：</b>
            <br> - 異常な利用状況が検出された場合にユーザーアカウントを無効化したり、リソースへのアクセスをリアルタイムでブロックしたりすることで、脅威に対応するための自動化が実施されている
            <br> - 通知とアラートが、異常な活動について適切なユーザーに通知するように設定されている
            <br> - 非公開データまたは機密データを含むすべての項目で項目履歴管理が有効になっている</td>
            <td><b>組織内：</b>
            <br> -脅威に対応するための自動化が確立されていない
            <br> - 通知とアラートが、異常な活動について適切なユーザーに通知するように設定されていないか、異常な活動に関連する一部の通知とアラートが存在するが、それらはアドホックである
            <br> - 非公開データまたは機密データを含む項目で項目履歴管理が一貫して有効になっていない</td>
        </tr>
    </tbody>
</table>

## データセキュリティ

データセキュリティとは、不正アクセス、破損、意図しない削除からデータを保護する手段です。データセキュリティには、転送中および保存中のデータの保護が含まれます。

強力なデータセキュリティにより、システムへの不正アクセスによるリスクと潜在的な損害を最小限に抑えます。データセキュリティが不十分な場合、システムはデータ侵害に対して脆弱になり、顧客や会社に重大な影響を及ぼす可能性があります。したがって、データの保護は、安全なアーキテクチャを構築するための基本です。

データセキュリティを強化するには、まず Salesforce 内で何がデータとみなされるか、およびその分類を明確に理解します。Salesforce 組織内に保存されている個々のレコード、ファイル、ドキュメントは、そのデータです。メタデータとデータの違いについての詳細は、「[Salesforce アーキテクチャの基本](/docs/architect/ja-jp/fundamentals/guide/architecture-basics#メタデータとデータ)」を参照してください。

暗号化の使用だけでなく、共有と表示に重点を置くことで、Salesforce ソリューションでより強力なデータセキュリティを構築できます。

> 注意:データ セキュリティを設計するときは、[データ プライバシー](/docs/architect/ja-jp/well-architected/guide/compliant#データプライバシー)と[アーカイブおよびパージ](/docs/architect/ja-jp/well-architected/guide/resilient#継続性計画)を考慮してください。これらの概念はどちらもソリューション全体のデータ セキュリティに影響します。

### データ分類

機密性 (公開、内部、機密、制限付きなど) に基づいて、Salesforce Platform 内に保存されているすべてのデータを識別および分類します。各データ型の処理方法と保護方法の概要を示す明確な**データ分類ポリシー**を定義します。項目レベルセキュリティ、暗号化、データマスキングなどの適切なセキュリティ制御を実装して、ポリシーを適用し、機密データを不正アクセスや漏洩から保護します。これらの分類と統制がビジネスおよびコンプライアンス要件と一致していることを確認するために、定期的に確認および監査します。

### 共有と表示

共有と表示には、Salesforce 内のデータへのユーザーアクセスを制御するシステムの設定が含まれます。共有と表示によってユーザーがアクセスできる個々のレコードが制御されますが、これらの設定だけでは、特定のレコードでユーザーが実行できる操作や、そのレコード内のどの特定の項目が表示されるかは最終的に制御されません。データ操作を実行する権限 ([CRUD](https://developer.salesforce.com/docs/atlas.en-us.214.0.lightning.meta/lightning/apex_crud_fls.htm) など) は、メタデータアクセス制御を介してユーザーに割り当てられます。メタデータアクセス制御は、個々のオブジェクトおよびフィールドレベルでユーザーに設定できます。詳細は、「[承認](/docs/architect/ja-jp/well-architected/guide/secure#authorization)」を参照してください。

Agentforce アクションでは、通常は直接アクセスできない認証済みユーザーと匿名ユーザーの両方にデータを公開できます。Agentforce エージェントを作成するときは、エージェントに割り当てられたすべてのアクションを慎重に検討して文書化してください。アクションごとに、次のことを理解する必要があります。

- アクションでアクセスできるデータ。
- アクションが実行されるセキュリティコンテキスト。
- アクションに、エージェントセッションに機密データや制限されたデータを組み込むことができる Knowledge 取得機能やその他の機能があるかどうか。

Salesforce で効果的な共有と表示を設定する

- 有意義な職務に**関する設計アクセス**。[ユーザー人格](/docs/architect/ja-jp/well-architected/guide/secure#認証)を実行するビジネス機能に対応付けるセキュリティマトリックスを作成します。この[テンプレートを](/docs/architect/ja-jp/resources/guide/security-policy-template)基盤として使用して、共有と表示を設計します。有意義なビジネス機能の特定についての詳細は、「[機能単位](/docs/architect/ja-jp/well-architected/guide/composable#機能単位)」を参照してください。
- **最小権限の原則を適用する最もシンプルなパスを選択します。**共有および表示スキームの設計に[最小権限の原則](/docs/architect/ja-jp/well-architected/guide/secure#authorization)を適用する場合は、最もわかりやすい方法で実行します。過剰なデータ制限と共有スキームは、システムのメンテナンス性、拡張性、適応性に関するダウンストリームの問題を引き起こす可能性があります。代わりに、[Salesforce の柔軟](https://resources.docs.salesforce.com/latest/latest/en-us/sfdc/pdf/sharing_architecture.pdf)な階層化されたデータ共有を利用して、データレベルでユーザーアクセスの詳細なルールを設定します。
- **ビジネスで機密データを扱う場合を除き、*内部*組織の共有設定 (OWD) を \[公開/参照のみ] に設定し、\[非公開] を使用します。**OWD は、データレベルでユーザーに付与する「最小」権限のレベルを制御します。OWD のレベルより下のアクセスを制限することはできません。非公開 OWD は、すべての使用事例で理想的に見えますが、多くの場合、企業全体のユーザーは、複雑な共有スキームを介して、より権限の高い OWD を誤って複製してしまう可能性があります。また、非公開 OWD を使用すると、ユーザーが重複データを作成する可能性があります。データ量と親子または所有権の歪みによっては、共有の適用 (および再適用) が完了するまでに非常に時間がかかる場合があります。非公開の OWD では、これがさらに悪化します。OWD は CRUD 権限と項目レベルの表示を制御しないことに注意してください。OWD がビジネスニーズによって正当化される場合にのみ \[非公開] を選択します。多くの場合、そのような正当化は[コンプライアンス](/docs/architect/ja-jp/well-architected/guide/compliant)に関連します。
- **より大きなアクセスを許可するやむを得ないビジネス上の理由がない限り、*外部*組織の共有設定 (OWD) を \[非公開] に設定します。**[外部 OWD は](https://help.salesforce.com/s/articleView?id=sf.security_owd_external.htm&type=5)、Experience Cloud サイトやポータルなどから Salesforce データにアクセスするユーザーに適用されます。これにより、内部ユーザーと外部ユーザーに別々の OWD ベースラインを設定し、さまざまな種別の「最小」権限を許可できます。外部ユーザーの OWD は常に \[非公開] に設定します。よりオープンなレベルの例外は、ビジネスニーズによって明確に正当化する必要があります。

次の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/secure#データセキュリティパターンとアンチパターン)のリストは、Salesforce 組織での共有と表示が適切 (および不適切) であることを示しています。これらを使用して、構築前に設計を検証したり、さらなる改善の機会を特定したりできます。

Salesforce の共有および表示ツールについての詳細は、「[Tools Relevant to Secure](/docs/architect/ja-jp/well-architected/guide/secure#セキュリティに関連するツール) (セキュリティに関連するツール)」を参照してください。

### 暗号化の使用

暗号化は、読み取り可能なデータを解読不可能なエンコード形式に変換します。暗号化されたデータは、鍵を使用して復号化したり、元の形式に変換したりできます。そのため、暗号化は、保存中および転送中のデータを保護するための最も効果的な方法の 1 つであり、権限のないユーザーがデータにアクセスした場合でもデータを読み取ることができません。

Salesforce ソリューションで暗号化を適切に使用するように設計する

- **転送中のデータは常に適切に暗号化してください。**Salesforce では、[Salesforce サポートブラウザ](https://help.salesforce.com/s/articleView?id=sf.getstart_browser_overview.htm&type=5)で実行されるすべてのセッションに [TLS を採用](https://help.salesforce.com/s/articleView?id=sf.security_overview_infrastructure.htm&type=5)し、HTTPS を使用した発信通話が特定のセキュリティ標準を満たしていることを要求します。プラットフォーム API でもデフォルトで HTTPS が使用されます。また、Salesforce Experience Cloud サイトまたはポータルとその関連 Salesforce 組織間で送信されるデータは、デフォルトで転送中に暗号化され[ます](https://help.salesforce.com/s/articleView?id=xcloud.security_pe_platform_encryption_faq.htm&type=5)。Salesforce の[組み込みメールサービス](https://help.salesforce.com/s/articleView?id=sf.emailadmin_send_email_from_salesforce_overview.htm&type=5)を使用する場合、Salesforce が[メールの送信](https://help.salesforce.com/s/articleView?id=sf.emailadmin_deliverability.htm&type=5)および送信試行に使用するトランスポート層セキュリティ (TLS) にはデフォルトレベルがあります。明確なビジネス上の理由がない限り、少なくとも組織の設定がデフォルト設定より低くならないようにする必要があります。データの分類と機密性に基づいて、AWS Direct Connect または Salesforce Private Connect を介して Salesforce へのプライベートネットワーク接続を活用することを検討してください。これにより、データが公開インターネットを通過するのではなく、ユーザーアクセスとインテグレーションの両方でプライベートネットワーク接続を介して安全に転送されます。
- **ビジネスで必要な場合は、保存データを暗号化します。**Salesforce では、保存データを暗号化する方法がいくつか用意されています。
  - **Hyperforce**[Hyperforce](/docs/architect/ja-jp/fundamentals/guide/platform-multitenant-architecture#hyperforce)を使用する組織では、データは保存時に暗号化されます。暗号化は、Salesforce によって組織で管理されます。独自の暗号化鍵を作成 (または破棄) することはできません。
  - **Salesforce Shield**。[Salesforce Shield](https://www.salesforce.com/products/platform/products/shield/)では、Salesforce 組織の保存データを、アプリケーション レイヤーやデータベース レイヤーなどの追加レイヤーで暗号化できます。Shield では、堅牢な \[Bring Your Own Key (BYOK)] オプションを含め、テナントの暗号化鍵の完全な管理機能を使用できます。非構造化データ (ファイル、添付ファイル、検索インデックス、行動など) を暗号化することもできます。Hyperforce ベースのインスタンスでは、外部鍵マネージャーを使用するオプションが用意されているため、独自の AWS KMS を使用できます。この機能を使用すると、Salesforce に保存されているデータの暗号化と復号化に使用される暗号化鍵を KMS 内で完全に制御できるため、セキュリティが強化され、組織のコンプライアンス要件に対応できます。

以下の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/secure#データセキュリティパターンとアンチパターン)のリストは、Salesforce 組織での暗号化の適切な (および不適切な) 使用を示しています。これらを使用して、構築前に設計を検証したり、さらなる改善の機会を特定したりできます。

Salesforce から入手できる暗号化ツールについての詳細は、「[Tools Relevant to Secure](/docs/architect/ja-jp/well-architected/guide/secure#セキュリティに関連するツール) (セキュリティに関連するツール)」を参照してください。

### データセキュリティパターンとアンチパターン

次の表に、組織で検索 (または作成) するパターンと、回避または修正の対象となるアンチパターンの選択を示します。

✨ [パターン & アンチパターンエクスプローラー](/docs/architect/ja-jp/well-architected-tools/guide/trusted-data-security)で、データセキュリティに関するより多くのパターンを見つけます。

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">パターン</th>
            <th scope="colgroup">アンチパターン</th>
        </tr>
        <tr>
            <td rowspan="3"><b>共有と表示</b></td>
            <td><b>設計標準およびドキュメント:</b>
            <br> - 各ユーザー人格がアクセスを許可されているデータの概要がセキュリティマトリックスに記載されています。
            <br> - 外部ユーザーと内部ユーザーで異なるデータアクセス標準が使用される (該当する場合)
            </td>
            <td><b>設計標準およびドキュメント:</b>
            <br> - 設計標準とドキュメントが存在しないか、セキュリティマトリックスが含まれていない
            <br> - セキュリティマトリックスが存在する場合、ユーザー人格のデータアクセスの概要は示されません。
            </td>
        </tr>
        <tr>
            <td><b>組織内：</b>
            <br> - コンプライアンス要件により、内部ユーザーの組織の共有設定 (OWD) は [公開/参照]、内部ユーザーの OWD は [非公開]
            <br> - 外部ユーザーの OWD は非公開
            <br> -生成 AI はユーザーモードでのみ動作するか、システムアクセスの特定の使用目的に明確なビジネス上の正当性がある</td></td>
            <td><b>組織内：</b>
            <br> - 内部ユーザーの OWD がビジネス上の理由なく非公開に設定されているか、内部ユーザーの OWD が公開/参照・更新可能に設定されている
            <br> - 外部ユーザーの OWD がビジネス上の理由なく [非公開] 以外に設定されている
            <br> -生成 AI はビジネス上の正当性なしでシステムモードで動作します。</td>
        </tr>
        <tr>
            <td><b>Apex:</b>
            <br> - データにアクセスするすべてのコード (SOQL/SOSL) またはデータ操作を実行するすべてのコード (DML/データベースクラスのメソッド) <code>で共有</code>キーワードを使用</td>
            <td><b>Apex:</b>
            <br> - <code>共有</code>キーワードが一貫して使用されていない</td>
        </tr>
        <tr>
        <tr>
            <td rowspan="3"><b>暗号化の使用</b></td>
            <td><b>設計標準およびドキュメント:</b>
            <br> -転送中および(必要に応じて)保存中のデータ暗号化の使用事例が明確で検出可能
            <br> 承認済みの暗号化プロトコルが明確にリストされている
            <br> - コードドキュメントに暗号化が使用されている場所と使用されているプロトコルが明記されている</td>
            <td><b>設計標準およびドキュメント:</b>
            <br> - 承認された暗号化プロトコルが明確でない、またはリストに記載されていない
            <br> - コードが文書化されていないか、コードのどこでどのように暗号化が使用されているかに関するドキュメントが明確でない</td>
        </tr>
        <tr>
            <td><b>組織内：</b>
            <br> -保存時のデータ保護を強化する必要があるセキュリティ リスクが特定された場合、HyperforceまたはSalesforce Shieldのいずれかが保存時の暗号化を提供します。</td>
            <td><b>組織内：</b>
            <br> -ビジネス ニーズにより保存時のデータ保護を強化する必要があるが、HyperforceとSalesforce Shieldのどちらも使用されていない</td>
        </tr>
        <tr>
            <td><b>Apex:</b>
            <br> -ビジネス ニーズで転送中のデータ保護を強化する必要がある場合、統合に関連するすべてのコードは、<a href="https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_classes_restful_crypto.htm">暗号化クラス メソッド</a>を使用してロジックを実行し、送信前にデータを暗号化するか、受信時にデータを復号化します。</td>
            <td><b>Apex:</b>
            <br> - ビジネスニーズにより、転送中のデータ保護を強化する必要があるが、インテグレーションに関連するコードで、送信前または受信時にデータを暗号化せずにロジックを実行する、または暗号化クラスのメソッドをアドホックに使用する</td>
        </tr>
    </tbody>
</table>

## セキュリティに関連するツール

<table class="tools-table"><tbody><tr><th>ツール</th><th>説明</th><th>組織のセキュリティ</th><th>セッションセキュリティ</th><th>データセキュリティ</th></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_classes_restful_crypto.htm">Apex 暗号クラス</a></td><td>Apex でのデータの暗号化と復号化</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=security_api_access_control_about.htm&type=5&language=en_US">API アクセスコントロール</a></td><td>Salesforce API と接続アプリケーションへのアクセスを管理する</td><td class="check-col">X </td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/sforce_api_objects_apianomalyevent.htm">API 異常イベント</a></td><td>ユーザーが API コールを実行する方法の異常を追跡する</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=browser_security.htm&type=5&language=en_US">ブラウザのセキュリティ設定</a></td><td>機密データの保護と SSL 証明書の監視</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=security_certificate_based_auth.htm&type=5&language=en_US">証明書ベースの認証</a></td><td>一意のデジタル証明書を使用して個人を認証する</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.security_keys_about.htm&type=5">証明書と鍵</a></td><td>Salesforce からの外部 Web サイトへの要求を確認する</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://github.com/forcedotcom/code-analyzer">コードスキャナー</a></td><td>Apex コードのセキュリティ脆弱性のスキャン</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=connected_app_overview.htm&type=5&language=en_US">接続アプリケーション</a></td><td>API と標準プロトコルを使用した統合</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/sforce_api_objects_credentialstuffingevent.htm">クレデンシャルスタッフィングイベント</a></td><td>盗まれたユーザーログイン情報を使用するログイン試行を追跡する</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.configuring_remoteproxy.htm&type=5">CSP 信頼済みサイト</a></td><td>コードインジェクション攻撃 (クロスサイトスクリプティング) の防止</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.security_login_flow.htm&type=5">カスタムログインフロー</a></td><td>ユーザーのログインビジネスプロセスの制御</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=identity_about_customers_partners.htm&type=5&language=en_US">顧客 ID</a></td><td>Web サイトおよびアプリケーションのログインと検証を制御する</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.data_mask_overview.htm&type=5">Data Mask</a></td><td>Sandbox の機密データの自動マスキング</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.code_debug_log.htm&type=5">デバッグログ</a></td><td>組織で発生したイベントを追跡する</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=admin_delegate.htm&type=5&language=en_US">代理管理者</a></td><td>非管理者ユーザーへの制限付き管理者権限の割り当て</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.security_overview_identity_verification.htm&type=5">デバイスの有効化</a></td><td>信頼できないブラウザー、デバイス、IP 範囲からのログインを確認する</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.enhanced_transaction_security_policy_types.htm&type=5">拡張トランザクションセキュリティ</a></td><td>イベントを傍受し、ユーザー活動を監視および制御する</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.modifying_field_access_settings.htm&type=5">フィールドアクセス</a></td><td>項目レベルでのデータアクセスの制御</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.field_audit_trail.htm&type=5">項目監査履歴</a></td><td>アーカイブされた項目履歴データを保持するポリシーを定義する</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.tracking_field_history.htm&type=5">項目履歴管理</a></td><td>項目履歴の追跡と表示</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=security_frontdoorjsp.htm&type=5&language=en_US">Frontdoor.jsp</a></td><td>既存のセッション ID とサーバー URL を使用したアクセスを許可</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.heroku.com/connect">Heroku Connect</a></td><td>Heroku と Salesforce 間の双方向同期</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://www.heroku.com/shield">Heroku Shield</a></td><td>HIPAA または PCI 準拠アプリケーションの作成</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=security_auth_require_ha_session.htm&type=5&language=en_US">高保証セッションセキュリティ</a></td><td>機密操作のセキュリティ強化が必要</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.identityconnect_about.htm&type=5">Identity Connect</a></td><td>ユーザーレコードを Active Directory アカウントに対応付ける</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.security_verification_history.htm&type=5">ID 検証履歴</a></td><td>ユーザー ID 検証試行の監査</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?language=en_US&id=sf.integration_user.htm">インテグレーションユーザーライセンス</a></td><td>API を介してのみデータと機能へのアクセス権を付与します。</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.security_ll_overview.htm&type=5">Lightning Login</a></td><td>脆弱なパスワードやパスワードを忘れた場合、およびアカウントがロックアウトされないようにする</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.identity_login_access.htm&type=5">ログインアクセス</a></td><td>サポートユーザーが別のユーザーとしてログインできるようにする</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.event_monitoring_faq.htm&type=5">ログインフォレンジック</a></td><td>なりすましを示す可能性がある行動を特定する</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=users_login_history.htm&type=5&language=en_US">ログイン履歴</a></td><td>組織と Experience Cloud サイトのログイン試行の監視</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=security_device_management.htm&type=5&language=en_US">モバイルデバイス追跡</a></td><td>組織へのモバイルデバイスのアクセスを追跡および監視する</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.mobile_sdk.meta/mobile_sdk/intro.htm">Mobile SDK</a></td><td>スタンドアロンモバイルアプリケーション内の Salesforce Platform への接続</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=release-notes.rn_security_monitor_user_permissions.htm&type=5&release=238">ユーザー権限の監視 (Shield)</a></td><td>権限セットおよび権限セットグループの変更</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.security_overview_2fa.htm&type=5">多要素認証</a></td><td>ログインに 2 つ以上の検証方法が必要</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.security_keys_uploading_mutual_auth_cert_api.htm&type=5">相互認証</a></td><td>SSL または TLS 相互認証の適用</td><td class="check-col"></td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.domain_name_overview.htm&type=5">私のドメイン</a></td><td>ログインページとポリシー、SSO、ソーシャルログインの設定</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.named_credentials_about.htm&type=5">指定ログイン情報</a></td><td>エンドポイント URL と認証パラメーターを指定する</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.remoteaccess_authenticate.htm&type=5">OAuth 認証</a></td><td>トークン交換によるクライアントアプリケーションアクセスの承認 </td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=admin_password.htm&type=5&language=en_US">パスワードポリシー</a></td><td>パスワード履歴、長さ、複雑さの設定</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=release-notes.rn_forcecom_permissions_assn_expiration.htm&type=5&release=238">権限セットの割り当ての有効期限</a></td><td>権限セットおよび権限セットグループの割り当ての有効期限を設定する</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=release-notes.rn_security_monitor_user_permissions.htm&type=5&release=238">権限セットイベント</a></td><td>権限セットおよび権限セットグループへの変更を監視する</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=perm_set_groups.htm&type=5&language=en_US">権限セットグループ</a></td><td>複雑なアクセス要件をサポートする権限セットのバンドル</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=perm_sets_overview.htm&type=5&language=en_US">権限セット</a></td><td>ユーザーがメタデータ、機能、アプリケーションにアクセスする方法を制御する</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.private_connect_overview.htm&type=5">プライベートコネクト</a></td><td>Salesforce と Amazon Web Services 間のセキュアなインテグレーション</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.admin_userprofiles.htm&type=5">プロファイル</a></td><td>ログイン IP アドレスの制限とログイン時間の制御</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.real_time_event_monitoring_overview.htm&type=5">リアルタイムイベントモニタリング</a></td><td>Salesforce での標準イベントの監視と検出 </td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=configuring_remoteproxy.htm&type=5&language=en_US">リモートサイト設定</a></td><td>Apex または JavaScript コール用の外部サイトを登録</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/sforce_api_objects_reportanomalyevent.htm">レポート異常イベント</a></td><td>ユーザーがレポートを実行またはエクスポートする方法の異常を追跡する</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.security_restriction_rule.htm&type=5">制限ルール</a></td><td>ユーザーが不要なレコードにアクセスできないようにする</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://github.com/forcedotcom/code-analyzer">Salesforce Code Analyzer</a></td><td>IDE、CLI、またはCI/CDを使用してコードをスキャンし、ベストプラクティスに準拠していることを確認する</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.security_scoping_rule.htm&type=5">範囲設定ルール</a></td><td>ユーザーに表示されるデフォルトレコードを制御する</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.security_center.htm&type=5">セキュリティセンター</a></td><td>すべての組織のセキュリティ設定を表示し、ポスチャ変更のアラートを設定する</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.security_health_check.htm&type=5">セキュリティ状態チェック</a></td><td>セキュリティ設定の脆弱性を特定する</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/sforce_api_objects_sessionhijackingevent.htm">セッションハイジャックイベント</a></td><td>盗まれたセッション識別子を使用して不正アクセスを特定する</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.236.0.apexref.meta/apexref/apex_class_Auth_SessionManagement.htm">Session Management クラス</a></td><td>有効なセッションのセキュリティ設定のカスタマイズ</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=admin_sessions.htm&type=5&language=en_US">セッションセキュリティ設定</a></td><td>悪意のある攻撃から保護するためのセッションの設定</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.admin_monitorsetup.htm&type=5">Setup Audit Trail</a></td><td>システム管理者による最近の設定変更の追跡</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.managing_the_sharing_model.htm&type=5">共有設定</a></td><td>レコードレベルでのデータアクセスの制御</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.security_pe_overview.htm&type=5">Shield Platform Encryption</a></td><td>保存中および転送中の機密データを暗号化</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.sso_about.htm&type=5">シングルサインオン</a></td><td>1 回のログインで複数のアプリケーションにアクセスできるようにする</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.identity_scim_overview.htm&type=5">クロスドメイン ID 管理 (SCIM) システム</a></td><td>REST API を使用したシステム全体の ID の管理</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.real_time_em_threat_detection.htm&type=5">脅威検知</a></td><td>統計と機械学習を使用した脅威の検出</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=security_networkaccess.htm&type=5&language=en_US">信頼済み IP 範囲</a></td><td>追加の検証を必要としない IP アドレスを定義する</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://appexchange.salesforce.com/appxListingDetail?listingId=a0N3A00000FYkDDUA1&tab=e">ユーザーアクセスレポート</a></td><td>ユーザーのオブジェクト、レコード、権限アクセス権の統合ビューの取得</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
</table>

## Resources Relevant to Secure (セキュリティに関連するリソース)

<table class="tools-table"><tbody><tr><th>リソース</th><th>説明</th><th>組織のセキュリティ</th><th>セッションセキュリティ</th><th>データセキュリティ</th></tr>
<tr><td><a href="https://resources.docs.salesforce.com/latest/latest/en-us/sfdc/pdf/sharing_architecture.pdf">共有アーキテクチャのガイド</a></td><td>アクセスツール、共有モデル、使用事例についての詳細</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="/docs/architect/ja-jp/resources/guide/design-standards-template">設計標準テンプレート</a></td><td>組織の設計標準を作成する</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://medium.com/salesforce-architects/how-to-build-a-user-security-model-12db130b3182">ユーザーセキュリティモデルの作成方法</a></td><td>ユーザーセキュリティモデルの理解を深める</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://medium.com/salesforce-architects/how-to-implement-the-principle-of-least-privilege-in-salesforce-59d3dbab9908?source=friends_link&sk=b7650c7fca8ad47bdd876399bbb0c635">Salesforce での最小権限の原則の実装方法</a></td><td>Salesforce での PoLP データアクセス制御の適用方法</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=security_user_session_info.htm&type=5&language=en_US">ユーザーセッションの監視</a></td><td>有効なセッションを確認して疑わしいセッションを終了する</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://security.salesforce.com/mfa">多要素認証</a></td><td>Salesforce からの公式 MFA リソースへのアクセス</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/permission-set-groups/mute-permissions-in-permission-set-groups">権限セットグループ (Trailhead)</a></td><td>権限セットグループのハンズオン</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.234.0.api_rest.meta/api_rest/intro_rest_architecture.htm">REST APIアーキテクチャ</a></td><td>REST API の用語と概念の理解</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_concepts_security.htm">セキュリティと SOAP API</a></td><td>SOAP API の用語と概念について</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://medium.com/salesforce-architects/security-best-practices-for-api-access-and-internal-system-users-a6199d0cda09">API および内部システムユーザー向けのセキュリティのベストプラクティス</a></td><td>API ユーザーによる Salesforce へのアクセスの保護と内部システムユーザーの保護</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://resources.docs.salesforce.com/238/latest/en-us/sfdc/pdf/salesforce_security_impl_guide.pdf">セキュリティ実装ガイド</a></td><td>Salesforce セキュリティの包括的な確認</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="/docs/architect/ja-jp/resources/guide/security-policy-template">セキュリティポリシーテンプレート</a></td><td>組織のセキュリティポリシーの設定</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=security_session_types.htm&type=5&language=en_US">Session Types</a></td><td>組織へのアクセスに使用されるセッションの種別を特定する</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/threat-modeling-fundamentals">脅威モデリングの基礎 (Trailhead)</a></td><td>セキュリティの脅威とその防止方法について説明します。</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
</table>

## ご意見をお聞かせください

Salesforce Well-Architected の関連性の維持にご協力ください。このコンテンツに関するフィードバックをいただくため[のアンケート](https://sfdc.co/bxNtvh)にご協力ください。また、今後の展望についてもお聞かせください。

<!-- document id=39fdc2befd29975345033296064fef6f6c31590d1b8c59633a6cc0564434e073 url=/architect/next/ja-jp/well-architected/guides/overview.md -->

## はじめに

<image style="width:100%;padding-top:1rem;padding-bottom:1rem;" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/framework2023-7.png" alt="Diagram showing Salesforce Well-Architected core capabilities are Trusted, Easy, Adaptable">

Salesforce Well-Architected Framework では、健全性の状態と、Salesforce Customer 360 Platform を使用したソリューションのロードマップと設計に費やす時間が示されます。Salesforce とエコシステム全体の製品チームと実装エキスパートからの Knowledge に基づいて、ランドスケープで検索するパターンとアンチパターンの規範的なガイダンスと例が共有されます。Salesforce Well-Architected は、信頼性が高く、容易で、適応性の高いソリューションの構築を支援します。

**信頼できる**ソリューションは関係者を保護します。<br>
**簡単**なソリューションは、迅速に価値を提供します。<br>
**適応可能**なソリューションはビジネスと共に進化します。<br>

Salesforce Well-Architected は、Customer 360 プラットフォームで健全なソリューションを構築するために必要なアーキテクチャの考え方を段階的に理解できるように設計されています。

アーキテクトが Salesforce を使用してソリューションを作成する場合の独自の課題は、プラットフォームの基本的な柔軟性です。1 つのソリューションで、Salesforce が提供する事前作成済みソリューション (Sales Cloud、Service Cloud、業種の異なる Industries Cloud など) を拡張できます。別のソリューションとして、完全なカスタムアプリケーションを使用することもできます。Salesforce で実行できることは幅広く、実装に最適なテクノロジーの選択肢はビジネスニーズによって異なります。考えられるすべての Salesforce ソリューションについて、何が長期的な健康の可能性を最大限に高めるのかを知ることは非常に困難です。

Salesforce Well-Architected では、必要に応じて経験豊富なアーキテクトからのインサイトとガイダンスが提供されます。意見のあるビューとおすすめを使用して、考え方を検証 (または異議を唱える) し、検討すべき領域や初めてのテクノロジーに関するインサイトを得ることができます。

また、すべての健全なソリューションに共通のアーキテクチャベンチマークがある場合、実装が多様であるため、理解が困難になる可能性があります。Salesforce では、会社として、また人間として行うすべてのことがコアバリューによって導かれています。これはアーキテクチャにも適用できると考えています。そのため、Salesforce Well-Architected は「信頼済み」、「簡単」、「適応可能」をコアとして構築されています。複雑なアーキテクチャの詳細とトレードオフを評価するときに、これらのコア機能に戻り、意思決定の指針となるコンパスポイントとして使用できます。

以下では、Trusted (信頼済み)、Easy (簡単)、Adaptable (適応可能) フレームワークで探索する個々のトピックの詳細について説明します。

## トピックの配置方法

Salesforce Well-Architected では、2 つのレベルで情報を整理しています。最上位レベルは、適切に設計されたソリューションのあるべき姿です。信頼性、容易性、適応性。第 2 レベルは、考慮事項、構築するパターン (または避けるべきアンチパターン)、および「信頼済み、簡単、適応型」ソリューションの特定の側面に関連する指示的ガイダンスについて詳しく説明します。このフレームワーク全体で提供されるガイダンスに設計を合わせることで、Salesforce Customer 360 アプリケーションの高品質と長期にわたる健全性を向上させることができます。

💡 パターンとアンチパターンをすばやく開始したいですか?[パターン & アンチパターンエクスプローラー](/docs/architect/ja-jp/well-architected-tools/guide/patterns)にアクセスします。

以下に、トピックの配置方法の概要を示します。

<table style="border-color:white;">
    <colgroup>
       <col span="1" style="width: 33%;">
       <col span="1" style="width: 34%;">
       <col span="1" style="width: 33%;">
    </colgroup>
    <tbody>
            <tr>
                <th scope="colgroup" colspan="3" class="guide-table-roadmap"><a href="/docs/architect/ja-jp/well-architected/guide/trusted-overview">信頼済み</a></th>
            </tr>
            <tr>
                <td colspan="3"> 信頼できるソリューションは、ビジネスと関係者を保護します。</td>
            </tr>
            <tr>
                <th><a href="/docs/architect/ja-jp/well-architected/guide/secure">安全</a></th>
                <th><a href="/docs/architect/ja-jp/well-architected/guide/compliant">適合</a></th>
                <th><a href="/docs/architect/ja-jp/well-architected/guide/reliable">信頼性</a></th>
            </tr>
            <tr>
                <td>組織のセキュリティ<br>セッションセキュリティ<br>データセキュリティ</td>
                <td>法的遵守<br>倫理基準<br>アクセシビリティ</td>
                <td>可用性<br>Performance<br>拡張性</td>
            </tr>
            <tr>
                <th scope="colgroup" colspan="3" class="guide-table-roadmap"><a href="/docs/architect/ja-jp/well-architected/guide/easy-overview">簡単</a></th>
            </tr>
            <tr>
            <td colspan="3">簡単なソリューションは、ビジネス価値を迅速に提供します。</td>
            </tr>
            <tr>
                <th><a href="/docs/architect/ja-jp/well-architected/guide/intentional">意図的</a></th>
                <th><a href="/docs/architect/ja-jp/well-architected/guide/automated">自動</a></th>
                <th><a href="/docs/architect/ja-jp/well-architected/guide/engaging">エンゲージメント</a></th>
            </tr>
            <tr>
                <td>戦略<br>メンテナンス性<br>読みやすさ</td>
                <td>効率<br>データ整合性</td>
                <td>合理化<br>役に立つ</td>
            </tr>
            <tr>
                <th scope="colgroup" colspan="3" class="guide-table-roadmap"><a href="/docs/architect/ja-jp/well-architected/guide/adaptable-overview">適応可能</a></th>
            <tr>
                <td colspan="3">適応性の高いソリューションは、ビジネスに合わせて進化します。</td>
            </tr>
            <tr>
                <th colspan="2"><a href="/docs/architect/ja-jp/well-architected/guide/resilient">耐障害性</a></th>
                <th><a href="/docs/architect/ja-jp/well-architected/guide/composable">コンポーザブル</a></th>
            </tr>
            <tr>
                <td colspan="2">アプリケーションライフサイクル管理<br>インシデント対応<br>継続性計画</td>
                <td>懸念事項の分離<br>相互運用性<br>パッケージ性</td>
            </tr>
    </tbody>
 </table>

<!-- document id=0b3163bcbd1d8bdf5486230db25bdcc9787ee0814de2d5b7e38d859d222a6b03 url=/architect/next/ja-jp/well-architected/guides/easy-overview.md -->

> 更新スケジュールについては、[こちら](/docs/architect/ja-jp/well-architected/guide/contributors)を参照してください。

# はじめに

**容易**な Salesforce ソリューションは、迅速に価値を提供します。**容易**に設計されているソリューションは、意図的で自動化されており、魅力的です。

**インテンショナル**・ソリューションは、ビジネス価値を即座に経時的に提供します。<br>
**自動化さ**れたソリューションにより、企業は作業を迅速かつ大規模に完了できます。<br>
**魅力的な**ソリューションはユーザーを喜ばせ、導入を促進します。<br>

**容易**なアーキテクチャの作成は、アーキテクトにとって複雑な課題になる可能性があります。Salesforce Platform の柔軟性と使用可能なさまざまな[自動化ツール](/docs/architect/ja-jp/well-architected/guide/automated#自動化に関連するツール)を考慮すると、実装の詳細は個々の Salesforce 組織によって大きく異なる可能性があります。**簡単な**アーキテクチャでは、よりインテリジェントな(および困難な)トレードオフ分析と関係者との会話が必要になる場合があります。ソリューション設計は、プログラマにとっては耐障害性と信頼性を備えていますが、組織管理者が所有または維持するのは容易ではありません。このようなソリューションは、**簡単**に構築できるわけではありません。

**簡単な**ソリューションを実現するには、ビジネスの優先事項を深く正確に理解する必要があります。ユーザーの希望、ニーズ、日々の業務の実態など、ユーザーを理解する必要があります。また、配送チームとメンテナンスチームのスキル (およびスキルギャップ) も理解する必要があります。さまざまなツールオプションと設計パターンを反復処理して、デリバリチームとメンテナンスチームが管理しやすく、作業を迅速かつ大規模に自動化し、ユーザーと真にエンゲージできる、ビジネスに価値をもたらす意図的なソリューションに到達する必要があります。

次のセクションでは、**Easy**ソリューションアーキテクチャの主な考慮事項について、より詳細なガイダンスを提供します。

## 簡単な概要

<table>
<tbody>
        <tr>
            <th scope="colgroup" colspan="3" class="guide-table-roadmap"><a href="/docs/architect/ja-jp/well-architected/guide/intentional">意図的</a></th>
        </tr>
        <tr>
        <td colspan="3">インテントソリューションは、ビジネス価値を即座に経時的に提供します。インテントアーキテクチャは戦略的に計画され、効果的に管理でき、人間にとって読みやすく、理解しやすいものです。</td>
        </tr>
        <tr>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/ja-jp/well-architected/guide/intentional#戦略">戦略</a></th>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/ja-jp/well-architected/guide/intentional#メンテナンス性">メンテナンス性</a></th>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/ja-jp/well-architected/guide/intentional#読みやすさ">読みやすさ</a></th>
        </tr>
        <tr>
            <td>優先順位付け <br>ロードマップ <br>ガバナンス</td>
            <td>標準とカスタム <br>技術的負債</td>
            <td>設計標準 <br>ドキュメント</td>
        </tr>
        <tr>
            <th scope="colgroup" colspan="3" class="guide-table-roadmap"><a href="/docs/architect/ja-jp/well-architected/guide/automated">自動</a></th>
        </tr>
        <tr>
        <td colspan="3">自動化ソリューションにより、ビジネスはより迅速かつ大規模に作業を完了できます。健全な自動化により、反復的な手動作業や複雑なデータ入力に費やす時間が削減されます。</td>
        </tr>
        <tr>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/ja-jp/well-architected/guide/automated#効率">効率</a></th>
            <th scope="colgroup" colspan="2"><a href="/docs/architect/ja-jp/well-architected/guide/automated#データ整合性">データ整合性</a></th>
        </tr>
        <tr>
            <td>プロセス設計 <br>操作ロジック<br>KPI</td>
            <td colspan="2">データ処理 <br>エラーハンドリング</td>
        </tr>
        <tr>
            <th scope="colgroup" colspan="3" class="guide-table-roadmap"><a href="/docs/architect/ja-jp/well-architected/guide/engaging">エンゲージメント</a></th>
        </tr>
        <tr>
        <td colspan="3">魅力的なソリューションはユーザーを喜ばせ、導入を促進します。エンゲージメントのためのアーキテクチャとは、直感的で役に立つユーザーエクスペリエンスを作成することです。</td>
        </tr>
        <tr>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/ja-jp/well-architected/guide/engaging#合理化">合理化</a></th>
            <th scope="colgroup" colspan="2"><a href="/docs/architect/ja-jp/well-architected/guide/engaging#役に立つ">ヘルプ</a></th>
        </tr>
        <tr>
            <td>アプリケーションの複雑さ <br>フォーム <br>フォーム要素</td>
            <td colspan="2">通知 &amp; メッセージング <br>アプリケーション内ガイダンス<br>レコグニション &amp; 報奨</td>
        </tr>
        </tbody>
</table>

<!-- document id=3dc2407ddc19c398ee04246dadc4149528d960380dd049feff368ef1a3e6dd36 url=/architect/next/ja-jp/well-architected/guides/resilient.md -->

> 更新スケジュールについては、[こちら](/docs/architect/ja-jp/well-architected/guide/contributors)を参照してください。

## はじめに

耐障害性に優れたソリューションは、障害が発生しても高いサービス品質を維持します。パフォーマンスが低下したり、サービスが中断されたりしても、ソリューションは迅速かつ効果的に復旧します。

ソリューションの耐障害性は、次の 2 つの主要な性質に基づいています。

- **靭性**:問題が発生した場合、ソリューションは問題に耐えて耐えます。
- **弾力性**:問題が解決されると、ソリューションは理想的な状態または形状に戻ります。

耐障害性を備えたソリューションを設計するには、靭性と弾力性の両方を考慮して設計し、計画された変更や予期しない変更に直面しても耐久性と迅速な復旧の両方を確保する必要があります。

テクノロジーコンテキストでは、システムやソリューションを、共通の目標を実行するために調整する相互依存するコンポーネントのコレクションとして考えます。すべてのコンポーネントが失敗する可能性があります。これらのコンポーネント内の問題 (コードや設定の不具合からネットワークやハードウェアの問題まで) により、予期しない動作が発生する可能性があります。1 つ以上のコンポーネントに障害が発生しても、システム全体が機能し続けるか、すぐに安定した状態に戻ると、システムは回復性のある動作を示します。

Salesforce ソリューションの耐障害性を向上させるために、3 つの主要な習慣に焦点を絞ることをお勧めします。

- [**アプリケーション ライフサイクル管理(ALM)**](/docs/architect/ja-jp/well-architected/guide/resilient#アプリケーションライフサイクル管理):アイデアの創出から廃棄までのライフサイクル全体にわたって、チームがソフトウェアを管理する方法
- [**インシデント対応**](/docs/architect/ja-jp/well-architected/guide/resilient#インシデント対応):システムの可用性やセキュリティに影響する問題をチームが特定し、対処して防止する方法
- [**継続性計画**](/docs/architect/ja-jp/well-architected/guide/resilient#継続性計画):予期しないイベントによって問題が発生した場合に、チームがどのように人員とシステムを機能させ続けるかを計画します。

## アプリケーションライフサイクル管理

アプリケーションライフサイクル管理 (ALM) は、作成から廃棄までのライフサイクル全体でソフトウェアを総合的に管理する手法です。ALM は、システムの耐障害性の要であり、アプリケーションライフサイクルに関連する人、プロセス、ツール、専門分野を網羅します。これらの領域には、DevOps と配信方法、オブザーバビリティ、テスト戦略、ガバナンス、CI/CD が含まれます。

ビジネスで ALM を効果的に実践すると、チームは変化にすばやく対応し、アプリケーションは安定性や品質を損なうことなく、進化するビジネス要件に対応します。

一方、健全な ALM がない場合、チームはアプリケーションライフサイクルのすべてのフェーズで苦労します。

問題のある ALM の症状を次に示します。

- 時間がかかり、エラーが発生しやすい開発サイクル
- 負荷が高く困難な導入
- 本番環境および QA 後に発見された重大度の高い問題またはバグ
- 幻覚や一貫性のない動作を行う AI エージェント
- リリースの安定化に必要な頻繁なロールバックまたはホットフィックスの導入

ALM はソリューションのほぼすべての側面に触れるため、ソリューションの明確で効果的な ALM プラクティスを確立することは、アーキテクチャ作業の重要な部分です。

3 つの主要な領域に焦点を当てて、ALM プラクティスを改善します。

- [**リリース管理**](/docs/architect/ja-jp/well-architected/guide/resilient#リリース管理)：変更の計画、順序付け、制御、さまざまな環境への移行
- [**環境戦略**](/docs/architect/ja-jp/well-architected/guide/resilient#環境戦略) — 開発およびテスト中にターゲット環境でアプリケーションを使用および管理する方法に関する戦略
- [**シグナリング戦略**](/docs/architect/ja-jp/well-architected/guide/resilient#シグナリング戦略) — システム内の障害を検出して劣化が発生する前に修正するために使用する重要なシグナルとアプリケーション計測の定義
- [**テスト戦略**](/docs/architect/ja-jp/well-architected/guide/resilient#テスト戦略) — ALM プロセス中にアプリケーションの成功を測定するためのテストを計画および実行する方法の指針となる原則と標準

### リリース管理

リリース管理には、変更の計画、順序付け、制御、1 つ以上の環境への移行が含まれます。1 つのリリースは、チームが同時に対象環境に移行する計画済みの変更のグループです。

システムへの変更をリリースすると、そのシステムにはリスクが生じます。変更前のシステムが安定した状態の場合、新しい状態に移行し、将来の変更によるリスクに対して脆弱になります。今後何らかの変更によってシステムが制御不能で不安定な状態になると、重大なインシデントが発生する可能性があります。ソリューション アーキテクチャでは、耐障害性の高いリリースに向けた設計は、個々の[変更を効果](/docs/architect/ja-jp/well-architected/guide/resilient#テスト戦略)的にテストするだけではありません。また、システムとそのユーザーへの変更を安全に導入する方法を計画します。

チームが実行する作業は、予測可能で正確なリリース情報によって異なります。変更管理および有効化プロセスでは、どの変更をシステムに移行できるかを明確にします。リリース管理および有効化プロセスで、変更をシステムにリリースする方法と頻度を指定します。

ビジネス関係者も、特に要求する機能やバグ修正に関連するリリース情報に関心を持っています。ソリューションを Trust して関係者に価値を示すには、一貫性のある明確なリリーススケジュールを設定し、安定したリリースアーティファクトを出荷します。

Salesforce の効果的なリリース管理を確立する

- アーキテクチャおよび開発ガバナンスと**緊密に連携**します。関連するすべてのガバナンスフォーラムと統制に合わせて、リリースを事前に計画してください。開発を開始する前に、AI Council で優先度の高いすべての Agentforce 使用事例を確認して承認を受けます。法務チームと倫理的な使用チームによる高リスクの Agentforce 使用事例のレビューを取得します。リリース チェックリストとドキュメントを使用して、ガバナンス活動に対して Agentforce エージェント API 名などのリリース アーティファクトを追跡します。
- **[組織ベースの開発プロセスまたはリリースプロセス](https://developer.salesforce.com/tools/vscode/en/user-guide/development-models)**は使用しないでください。このパラダイムは、開発およびリリース用のより古い制限されたテクノロジーを反映しています。Salesforce CLI を使用すると、チームはソース主導の開発およびリリース機能を採用できるようになりました。
- **できるだけ安定したリリースメカニズムを選択**します。このアプローチでは、2 つのことを実現します。まず、リリース期間とサービスの中断を最小限に抑えます。次に、高度に制御された予測可能なリリース動作が可能になります。リリースメカニズムの安定性が高ければ高いほど、修正やロールバックを必要とする変更がリリースで発生する可能性が低くなります。予期しない問題が発生した場合、安定したリリースメカニズムにより、サポートスタッフやシステム管理者がロールバックをより簡単に実行できるようになります。

チームにとって最適なリリースメカニズムは、チームに必要なスキルを備えた最も安定したオプションです。推奨されるリリースメカニズムを安定性の順にリストします。すべては相互に互換性があるため、会社にとって最適な場合は複数を組み合わせて使用します。

- [**ロック解除済みパッケージ**](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_intro.htm) — ロック解除済みパッケージは、最も安定したリリース アーティファクトです。パッケージをインストールして変更をリリースすることが、最も迅速かつ予測可能な変更の導入方法です。パッケージではバージョン管理が使用されるため、堅牢な変更管理とシステム管理者が理解しやすいきめ細かいロールバックが可能です。また、パッケージには強力なメタデータ管理が必要なため、不適切な連動関係を早期に特定できます。また、監査可能な開発パイプラインとアーティファクトも作成します。「[パッケージ化](/docs/architect/ja-jp/well-architected/guide/composable#パッケージ性)可能性」を参照してください。
- [**DevOps センター**](https://help.salesforce.com/s/articleView?id=sf.devops_center_overview.htm&type=5):DevOps センターでは、ロー コードまたはプロコードのスキル セットを持つデリバリ チームがソース管理を使用し、変更に対して共同で作業し、共通のリリース パスを定義することができます。DevOps センターはソース制御と統合されており、ポイント アンド クリックで変更やリリースを制御できます。
- ** [Salesforce CLI](https://developer.salesforce.com/tools/sfdxcli) を使用したソース駆動開発およびメタデータのリリース** — パッケージを使用できない場合は、Salesforce CLI を使用してソース駆動開発およびメタデータのリリースを行います。古い package.xml 形式を使用してメタデータをリリースしないでください。推奨[ソース形式](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_source_file_format.htm)とは異なる構造に従います。ソース形式は、パッケージ開発、スクラッチ組織のワークフロー、Sandbox でのより詳細な変更追跡をサポートするように進化しました。この形式は読みやすく、複雑なメタデータ型と連動関係をより分離でき、リリースマニフェストをより詳細に制御できます。
- **リリースに名前**を付けます。リリースに明確な識別子を付けることで、チームと関係者が一貫性を保つことができます。Salesforce では、各メジャーリリースの名前は「Spring」、「Summer」、または「Winter」で始まり、その後にリリース年 (「Summer '25」など) が続きます。会社でリリースを定義および整理するための命名規則がまだない場合は、命名規則を作成して使用します。明確なリリース名を使用すると、チームのシステム全体の計画、開発、提供のすべてのフェーズで情報を整理できます。[ロード](/docs/architect/ja-jp/well-architected/guide/intentional#ロードマップ)マップのリリース名を使用して、どの変更がいつ行われるかを関係者に明確に伝えます。開発アーティファクトを簡単に追跡および監査できるように、ドキュメント、変更ログ、作業説明、コードコメント、ソース制御のブランチでリリース名を使用します。
- **リリースマニフェスト内で、連動関係を適切に管理します。**Salesforce メタデータには組み込み連動関係があります。Salesforce リリースが失敗する一般的な理由は、連動関係が適切に管理されていないことです。すでに説明したように、安定したリリースメカニズムを選択することで、開発サイクルの早い段階で不適切な管理連動関係が公開される可能性があります。ロック解除済みパッケージが最も安定したリリース車両である主な理由の 1 つは、パッケージの開発と作成に必要な強力なメタデータ管理にあります。自分またはリリース管理チームが Salesforce メタデータ型間の組み込み連動関係を理解していない場合、リリースマニフェストとリリースマニフェストで問題のある組み合わせを積極的に見つけることはできません。「[連動関係管理](/docs/architect/ja-jp/well-architected/guide/composable#連動関係管理)」を参照してください。

[ALM のパターンと](/docs/architect/ja-jp/well-architected/guide/resilient#alm-パターンとアンチパターン)アンチパターンは、Salesforce 組織でのリリース管理の適切さと劣悪さを示します。このパターンを使用して、構築前に設計を検証したり、システム内でリファクタリングが必要な箇所を特定したりします。

リリース管理用の Salesforce ツールについての詳細は、「[Salesforce Tools for Resiliency](/docs/architect/ja-jp/well-architected/guide/resilient#耐障害性のための-salesforce-ツール)」を参照してください。

### 環境戦略

Salesforce には、アプリケーション開発およびテストサイクルで使用するさまざまな[環境](https://help.salesforce.com/s/articleView?id=sf.create_test_instance.htm&type=5)が用意されています。Salesforce の効果的な環境戦略では、環境の使用方法と適切な管理について理解する必要があります。ALM では、開発環境またはテスト環境がどの程度役立つかは、本番環境に対する忠実度と本番環境からの分離によって異なります。

優れた環境戦略には、いくつかの利点があります。

- 本番環境に対する忠実度の向上
- 迅速な環境設定と破棄
- 開発とテストの俊敏性の向上
- パイプライン全体のセキュリティの向上
- デリバリフェーズ全体での騒音と競合の低減
- 開発チームの満足度の向上

多くの場合、チームはこれらの利点の実現に苦労します。開発環境と戦略を最大限に活用するには、いくつかの問題の原因が考えられます。原因の 1 つとして考えられるのは、チームが従う開発モデルの種別です。

以前の組織ベースの開発アプローチでは、各環境が複数の機能を果たす必要がありました。チームがさまざまな種類の作業を行う場所であるだけでなく、リリースアーティファクト (つまり、リリースでリリースするメタデータ) のソースである必要がありました。環境は設定や解体が容易でなかったため、過密状態が多く、チーム間のメタデータの競合も多く、ALM 全体の速度や柔軟性にはあまり意味がありません。

ソースベースの開発モデルを使用すると、環境とリリースおよびリリースアーティファクトの関係が根本的に変わります。このモデルでは、ソース制御はリリースするメタデータのソースです。環境は、チームが作業を実行する場所です。

ただし、ソースベースの開発モデルに従うだけでは、優れた環境戦略が保証されません。ソース管理を使用しても、チームは外部システムとのインテグレーションや、管理パッケージや[データ](/docs/architect/ja-jp/fundamentals/guide/architecture-basics#メタデータとデータ)に依存するカスタマイズなど、ソース管理下にないメタデータに依存する構成をテストする条件を設定するのに苦労する可能性があります。特定の状況では、ソースベースのモデルの課題は、組織ベースのモデルに典型的な課題と似ています。

効果的な環境戦略を作成する

- **ソース駆動型開発およびリリース モデルを採用できます。**[組織ベースの開発](https://developer.salesforce.com/tools/vscode/en/user-guide/development-models)モデルの使用を中止します。「[リリース管理](/docs/architect/ja-jp/well-architected/guide/resilient#リリース管理)」を参照)。リリースする環境とリリースの環境を切り離して、健全な環境戦略と健全なリリースを作成する必要があります。
- **各環境でサポートされる作業の種別を理解します。**Salesforce でサポートされる環境種別には、さまざまな機能と制限があります。環境戦略を設計するときに、環境で何ができるか、何ができないかを検討します。チームは、必要な機能を備えた環境で作業を実行します。指針については、Salesforce 開発環境とその機能の概要を参照してください。

<table>
<thead>
<tr>
<th></th>
<th>スクラッチ組織</th>
<th>Developer Sandbox</th>
<th>Developer Pro Sandbox</th>
<th>Partial Copy Sandbox</th>
<th>Full Sandbox</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>サポート<a href="https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_shape_create_shape.htm">組織シェイプ</a></strong></td>
<td>はい</td>
<td>いいえ</td>
<td>いいえ</td>
<td>不可</td>
<td>不可</td>
</tr>
<tr>
<td><strong><a href="https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_setup_enable_source_tracking_sandboxes.htm">ソース追跡のサポート</a></strong></td>
<td>はい</td>
<td>はい</td>
<td>はい</td>
<td>不可</td>
<td>不可</td>
</tr>
<tr>
<td><strong>寿命</strong></td>
<td>1 ～ 30 日</td>
<td>手動制御</td>
<td>手動制御</td>
<td>手動制御</td>
<td>手動制御</td>
</tr>
<tr>
<td><strong>更新間隔</strong></td>
<td>使用不可</td>
<td>1 日</td>
<td>1 日</td>
<td>5 日</td>
<td>29 日</td>
</tr>
<tr>
<td><strong>リリースプレビューのサポート</strong></td>
<td><a href="https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_scratch_orgs_version_selection.htm">開発者による制御</a></td>
<td>Sandbox インスタンスに基づく</td>
<td>Sandbox インスタンスに基づく</td>
<td>Sandbox インスタンスに基づく</td>
<td>Sandbox インスタンスに基づく</td>
</tr>
<tr>
<td><strong>プロビジョニング時間</strong></td>
<td>> 5 分</td>
<td>時間または日</td>
<td>時間または日</td>
<td>時間または日</td>
<td>時間または日</td>
</tr>
<tr>
<td><strong>Metadata Determined By</strong></td>
<td>ソース管理</td>
<td>本番</td>
<td>本番</td>
<td>本番</td>
<td>本番</td>
</tr>
<tr>
<td><strong>Data Determined By</strong></td>
<td>手動データ読み込み</td>
<td>手動データ読み込み</td>
<td>手動データ読み込み</td>
<td>Sandbox テンプレート</td>
<td>本番</td>
</tr>
<tr>
<td><strong>データ制限</strong></td>
<td>200 MB</td>
<td>200 MB</td>
<td>1 GB</td>
<td>5 GB</td>
<td>本番と同じ</td>
</tr>
</tbody>
</table>

次の表を参照して、いくつかの一般的な開発タスクで使用する機能と環境を確認してください。

<table style="overflow-x:scroll;">
<thead>
<tr>
<th>ToDo</th>
<th>組織シェイプ</th>
<th>ソース追跡</th>
<th>頻繁な更新</th>
<th>リリースプレビューのサポート</th>
<th>本番のすべてのメタデータ</th>
<th>本番の部分メタデータ</th>
<th>本番からの大規模なデータセット</th>
<th>本番の部分的なデータセット</th>
<th>互換性のある環境</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>プロトタイピング</strong></td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center"></td>
<td align="center">X</td>
<td>スクラッチ組織、開発者および開発者向け Pro Sandbox</td>
</tr>
<tr>
<td><strong>新機能の調査または概念実証開発</strong></td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center"></td>
<td align="center">X</td>
<td>スクラッチ組織、開発者および開発者向け Pro Sandbox</td>
</tr>
<tr>
<td><strong>ユーザー受け入れテスト</strong></td>
<td align="center"></td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center"></td>
<td align="center">X</td>
<td>Developer Sandbox、Developer Pro Sandbox、Partial Copy Sandbox</td>
</tr>
<tr>
<td><strong>パフォーマンスと拡張性のテスト</strong></td>
<td align="center"></td>
<td align="center"></td>
<td align="center"></td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center"></td>
<td align="center">X</td>
<td align="center"></td>
<td>Full Sandbox</td>
</tr>
<tr>
<td><strong>ユーザートレーニング</strong></td>
<td align="center"></td>
<td align="center"></td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X*</td>
<td align="center">X</td>
<td>Developer Pro、Partial Copy、*Full Sandbox</td>
</tr>
<tr>
<td colspan="10">*特定の種類の作業を完了する必要がある場合は、リソース負荷の低い環境を使用します。</td>
</tr>
</tbody>
</table>

さらに、Einstein データ ライブラリ、Knowledge 記事、非構造化データなどの機能を使用する Agentforce エージェントの場合、Data 360 Sandbox がない限り、包括的なテストが制限されます。また、正確なテスト条件を確保するには、Data 360 Sandbox も必要です。

- **環境をリリースアーティファクトから分離します。**[組織ベースの開発](https://developer.salesforce.com/tools/vscode/en/user-guide/development-models)は使用しないでください。環境を、一定の時間作業が行われる場所として扱います。環境内のメタデータの状態は、リリースアーティファクトから分離されていると考えてください。コードまたは設定が環境で「把握」された場合、ソース管理にコミットしてリリースアーティファクトにします。
  - 環境は儚いものです。プロセスをできるだけ早く作成および破棄できるようにプロセスを作成します。
  - 人工物は持ちこたえるソース制御に属します。
- **環境をリリースパスから切り離す。**特定の環境に変更をリリースする必要がある必須リリースパスは、よく見られます。多くの場合、このアプローチは、アプリケーションの成熟度やリリースの安定性を検証するためのプロキシを確立するために実装されます。また、チームはこの機能を使用して、複雑なテストインフラストラクチャを設定する必要がある環境の数を最小限に抑えることもできます。ソースベースのパラダイムでは、変更を検証およびテストする方法と場所をより柔軟に設定できます。
  - リリースフェーズは、環境ではなくリリースアーティファクトに適用されます。特定のリリースフェーズのすべての変更を「収集」するためだけに環境を作成しないでください。ソース制御 (特に分岐) の目的は、これです。ソース制御の分岐戦略を使用して、どの変更をどの環境にリリースするかを整理します。必要な作業に応じて、リリースのすべてのメタデータを環境にリリースする必要があります。分岐により、これが可能になります。一部の例外を除き、すべての開発環境は、関連する作業が終了した直後に更新または破棄する必要があります。特定の環境内で発生した (保持する) メタデータへの変更は、必ずソース制御に同期してください。
  - 環境は、本番環境への忠実度によってのみ役立ちます。環境設定ワークフローまたは自動化を最適化して、環境をできるだけ早く解体または更新できるようにします。ALM プロセスの全体的な回復力に対する重大なリスクとして、より迅速かつ頻繁に環境を更新することを妨げる設定を検討します。関連する修復作業がある場合は、計画に追加して優先度を付けます。システムでより疎結合の[モジュラーユニット](/docs/architect/ja-jp/well-architected/guide/composable)を採用する方法を確認します。これにより、チームはスクラッチ組織でより多くの種類の開発を実行でき、Sandbox の割り当てを他の作業に割り当てることができます。スクラッチ組織で提供される機能は、ライセンスを購入していない、または有効にしていないなど、本番組織にない機能をテストするためのものです。
  - ビジネスユーザーまたはエンドユーザーがアクセスできる環境では、ユーザーは重要な作業に集中できます。多くの異なるエンドユーザーやビジネス関係者が ALM 関連の作業を行おうとする、汎用的で差別化されていない環境は避けてください。特定の関係者を特定の環境に招待して有効化し、特定の作業を行います。Partial Copy Sandbox でサポートできないほど大量のデータがある環境にエンドユーザーやビジネスの関係者を置くプロセスを慎重に評価します。作業に必要なデータ量であることを確認します。ユーザー受け入れテストと初期段階の開発サイクルをできるだけ密接に連携するように計画します。すべてのテストフェーズを最適化して、開発チームとエンドユーザーのフィードバックと反復サイクルを早期化します。「[テスト戦略](/docs/architect/ja-jp/well-architected/guide/resilient#テスト戦略)」を参照してください。
- **変更**種別ごとに異なるリリースパスを作成します。すべての変更で同じ種別の ALM 作業を同じ順序で完了する必要があるわけではありません。システムのバックエンドコンポーネントの軽微な変更についてエンドユーザーに受け入れテストを実行させることは、時間の無駄遣いになる可能性があります。ただし、モバイルアプリケーションの開発の初期段階では、ユーザー受け入れテストと拡張性テストは非常に有益です。高リスク、中リスク、低リスクなど、さまざまなカテゴリの変更のリリースパスを特定します。

  - **高リスク:**変更は、顧客、パートナー、またはすべての内部ユーザーに影響します。変更は、セキュリティまたはインテグレーションに影響します。変更により、複雑な新機能が追加されます。
  - **中リスク:**変更の影響は、内部ユーザーの定義済みしきい値を超えます。変更は、データモデル、データ操作を実行する自動化、インテグレーションに影響します。
  - **低リスク:**内部ユーザーの定義されたしきい値よりも少ない数に直接影響します。セキュリティの変更、データ操作やインテグレーションを伴うデータモデルや自動化は含まれません。

- **過密な環境は許可しないでください。**作業の優先順位付け、範囲設定、順序付けの規律が欠けていると、必然的に開発環境に過負荷が発生し、作業量が多すぎたり、多すぎたり、多すぎたり、異なっていたりします。過密な環境では、開発チーム間のストレス、あいまいさ、対立が生じます。また、開発パイプライン内にノイズが発生し、品質管理活動が妨げられます。このような悪影響に加えて、開発環境の過密は環境のメンテナンスとセキュリティにとって深刻な脅威です。ALM プロセスの潜在的な問題の兆候として過密を考慮します。根本原因の問題を調査して対処します。それでも過密が解消されない場合は、[Sandbox を追加](https://help.salesforce.com/s/articleView?id=sf.data_sandbox_environments.htm&type=5)できます。

[ALM のパターン](/docs/architect/ja-jp/well-architected/guide/resilient#alm-パターンとアンチパターン)とアンチパターンのリストには、Salesforce 組織での適切な環境管理と不適切な環境管理が示されます。これを使用して、構築前に設計を検証したり、システムのリファクタリングが必要な領域を特定したりできます。

環境管理用の Salesforce ツールについての詳細は、「[Salesforce Tools for Resiliency](/docs/architect/ja-jp/well-architected/guide/resilient#耐障害性のための-salesforce-ツール)」を参照してください。

### シグナリング戦略

シグナリング戦略では、システム全体の機能低下に連鎖する前に障害を検出、診断、修正するために必要な重要なシグナルとアプリケーション計測を定義します。効果的な計装により、アプリケーションは、障害の受動的な被害者から、問題を検出し、その動作を調整し、必要に応じて正常な機能低下を調整できる独自の回復力でアクティブな関係者に変換されます。

アプリケーションが包括的な計装を実装すると、ストレス下での自己規制、オペレーターへの健康状態の伝達、調整された回復活動への参加が可能になります。これらの機能により、個々のコンポーネントに問題が発生しても、システムはサービス品質を維持できます。一方、適切な計装が行われなければ、アプリケーションはブラックボックスとなり、破滅的な症状が現れるまで黙って失敗します。チームはユーザーから問題の報告を受けて初めて対応し、トラブルシューティングは観察ではなく考古学の課題になります。

- **アプリケーション内のエラー**を検出します。高負荷時に発生する一般的な障害パターンを検出して対応するように、アプリケーション自身が計測する必要があります。キューの飽和度を考慮します。メッセージキューが処理できるよりも早くいっぱいになると、インストルメンテーションされていないアプリケーションは、メモリを使い果たすかタイムアウトのカスケードが発生するまで作業を受け入れ続けます。適切に計測されたアプリケーションは、キューの深さ、却下率、処理遅延を監視し、しきい値を超えた場合に防御的な応答をトリガーします。
- **アプリケーション外からのシグナルを効果的に処理**:オペレーティングシステムからの信号の処理は、もう 1 つの重要な計装ポイントを表します。グレースフルシャットダウンを有効にするには、アプリケーションが終了シグナル (SIGTERM、SIGINT) のハンドラーを登録する必要があります。シャットダウン中、適切に計測されたアプリケーションは新しい作業の受け入れを停止し、進行中の要求の完了、バッファのフラッシュ、接続のクリーンアップ、サービス検出からの登録解除を許可します。このオーケストレーションされたシャットダウンにより、データの損失が防止され、ロードバランサーは中断することなくトラフィックをリダイレクトできます。
- **複雑な障害シナリオに対応する手段:**これらの基本パターン以外にも、アプリケーションではより微妙な障害モードを測定する必要があります。コンポーネントが一部の観測者には正常で、別の観測者には異常がないように見えるグレーの障害を特定するには、内部信号と外部信号の両方を関連付ける必要があります。アプリケーションは、データベース接続プールを計測して正常性チェックを報告し、同時に徐々に低下していくトランザクション完了率を追跡できます。効果的な計装戦略では、複数の観測点を重ねます。

  - **ビジネス評価指標**では、注文完了率や検索結果の品質など、アプリケーション固有の成功指標を追跡します。
  - **システム評価指標**は、リソース使用率、遅延の分布、およびエラー率を監視します。
  - **合成プローブは**クリティカル パスを継続的に実行し、ユーザーがパフォーマンス低下に遭遇する前に検出します。
  - **分散トレーシング**では、サービスの境界を越えて要求レベルの表示が提供されます。

これらのシグナルは、自動化されたシステムと人間のオペレーターの両方がアプリケーションの健全性を評価できる標準化されたインターフェースを介して公開されます。計装自体がアプリケーションのレジリエンス戦略の一部となり、エラー率に基づいてサーキット ブレーカーを停止し、オートスケーラーでキューの深さに対応し、[オペレータはインシデント](/docs/architect/ja-jp/well-architected/guide/resilient#インシデント対応)中に情報に基づいた意思決定を行うことができます。

[ALM のパターンと](/docs/architect/ja-jp/well-architected/guide/resilient#alm-パターンとアンチパターン)アンチパターンは、Salesforce 組織での適切なシグナリング戦略と不適切なシグナリング戦略を示します。これを使用して、構築前に設計を検証したり、システムのリファクタリングが必要な領域を特定したりできます。

シグナリング戦略用の Salesforce ツールについての詳細は、「[Salesforce Tools for Resiliency](/docs/architect/ja-jp/well-architected/guide/resilient#耐障害性のための-salesforce-ツール)」を参照してください。

### テスト戦略

テスト戦略は、ALM プロセス中のアプリケーションの成功と失敗を測定するテストを計画および実行する方法に関する一連の指針と標準です。テスト戦略では、テストに関与するすべての関係者が、特定のテストの優先度、目的、範囲について常に把握し、その範囲に合わせて調整します。また、プロジェクトチームは効果的で周到なテスト計画を作成できます。

通常、開発者または品質保証とテストの専門家が特定のテストの作成と実行に関与します。テスト戦略は、特定のプロジェクトでどのような種類のテストを実行する必要があり、どのような順序でテストを実行する必要があるかをこれらの個人が把握するのに役立ちます。また、テスト戦略は、チームが適切な形式のテスト、テスト計画、アーティファクト (テストデータセット、デバイス、トラフィックまたはネットワークシミュレーターなど) を作成するために必要なものを確保できるようにするのに役立ちます。

効果的なテスト戦略では、単体テスト、UI テスト、回帰テストなど、さまざまなテスト種別をさまざまな組み合わせや条件でどのように、いつ、どこで、なぜ実行するかを明確に把握し、システムと進行中の変更の動作を明らかにします。効果的なテスト戦略では、1 つの種類のテストでは測定が困難な、拡張性、信頼性、使いやすさなどの非機能要件にシステムがどの程度適合しているかを示すテストが生成されます。

Salesforce の効果的なテスト戦略を作成する

- **テストは反復的かつ頻繁に、可能な限り自動化された方法で実行します。**チームがさまざまなワークロードに対してさまざまなテスト種別を実行できるようにするテスト自動化を設計および実装します。変更がソース制御に反映されるときにさまざまなテスト実行が自動的に実行されるように調整します。このアプローチにより、チームは早い段階で回帰を事前に特定して対処できます。可能な場合は、この取り組みに継続的インテグレーション/継続的デリバリ (CI/CD) を使用します。それ以外の場合は、チームがセルフサービス方式でテストの順序を早期に頻繁に実行できるように、明確なテスト計画を作成します。Agentforce エージェントのテストでは、さまざまな入力が含まれる AI エージェントの厳格なバッチ テストをテスト センターに依頼し、さまざまなシナリオで適切に機能することを確認します。
- すべての変更ですべての種類のテストが必要なわけではありません**。**効果的なリリースパイプラインが高リスク、中リスク、低リスクのアプリケーションに対応するのと同じように、効果的なテスト戦略も対応します。さまざまな種類のリスク、使用事例、または複雑さがあるアプリケーションに適したテスト体制を選択して従う方法をチームに明確に示します。「[環境戦略](/docs/architect/ja-jp/well-architected/guide/resilient#環境戦略)」を参照してください。
- **さまざまな環境種別で実行できるテストを定義します。**正確なテストでは本番環境への忠実度が重要な要素ですが、テストの種類によって意味が異なります。たとえば、回帰テストでは、メタデータとある程度のデータに関して本番環境に対して忠実である必要があります。特定のテストセットで本番に対してどのような忠実度が必要かを定義し、さまざまなテストに適した条件をサポートできる環境の種類を明確に分類します。各環境種別に適した作業種別の概要については、「[環境戦略](/docs/architect/ja-jp/well-architected/guide/resilient#環境戦略)」を参照してください。
- **耐久性、ストレス、パフォーマンス、拡張性のテストを使用して、アプリケーションの成熟度を継続的に測定します。**これらのテストは、本番レベルのニーズに対するアプリケーションのリリース準備状況を示します。主要な新機能の場合、アプリケーション開発サイクルでこれらのテストをいくつかの間隔で実行します。これらのテストを、進行中の ToDo の一部ではなく、1 つのフェーズまたは開発フェーズの一部のみとみなすのはアンチパターンです。チームがアプリケーションのパフォーマンスに関するフィードバックを早期に頻繁に取得することが最も役立ち、本番レベルの準備状況からどの程度アプリケーションに近いか遠いかをより深く理解できます。変更が本番に移行する前に問題をより適切に特定して対処する機能は、より高度なテストを頻繁に実行することで複雑さを増す価値があります。
  - **重要なテスト**。拡張性テストやパフォーマンステストを実施する時間はおそらく固定されており、システムのあらゆる側面をテストすることは現実的ではありません。すべての機能が均等に使用されるわけではなく、すべての拡張性のボトルネックがビジネスに均等に影響するわけではありません。スケールテストは、システムで最も使用頻度が高く、価値の高い部分に焦点を絞ります。組織の拡張性とパフォーマンスを確認および改善するための最も重要な機会を定義して理解します。
  - **「十分」がどのようなものかを知る。**拡張性テストとパフォーマンステストの成功条件を定義することが重要です。自分と開発チームがテストベンチマークとして成功条件を使用していることを確認します。また、開発チームが構築する機能要件も伝えます。通常、これらの条件には、合意した値未満の応答時間で特定の数の同時ユーザーをサポートすることと、[サービスレベル目標(SLO)](/docs/architect/ja-jp/well-architected/guide/resilient#time-to-recover-リカバリ時間)が含まれます。主要な目標条件を定義し、条件が満たされていることを確認する拡張性とパフォーマンスのテストを設計します。
  - **適切な環境があることを確認します。**拡張性とパフォーマンスのテストでは、特に本番環境への忠実度が求められます。本番以外の環境でのデータセット、要求のデモグラフィック、要求率、作業負荷の特性はすべて、本番で表示される内容とできる限り一致する必要があります。スケール テストでは、Full Sandbox を使用する必要があります。組織にスケール テスト用の Full Sandbox がない場合、適切なスケール テストを実行できません。
- **テスト ワークロードが機能以外の要件の測定に役立つことを確認します。**次の点を考慮してください。
  - **テストデータ** \- 本番から分離されたデータに対してあらゆる種類のテストを実行する必要があります。Apex 単体テストでは、[データファクトリパターンを](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_utility_classes.htm)実装して、環境データから分離された独自のテストデータをコードで生成します。また、さまざまな形式でテストデータセットを作成して管理し、データ読み込み動作をテストしたり、開発環境に UI ベースのテスト用のデータを入力したり、インテグレーションテストを支援したりできます。すべてのテストデータは、外部化されたデータセットとして管理されるか、データファクトリコードによってオンデマンドで作成されるかに関係なく、機密データおよび識別可能なデータで整理する必要があります。否定的な単体テスト動作と境界単体テスト動作をサポートするには、破損したデータ、不完全なデータ、および不正な形式のデータを含める必要があります。
  - **模擬サービスおよびスタブサービス** \- インテグレーションテストでは、模擬サービスとスタブサービスを使用して API 応答をシミュレーションできます。Apex では、Apex テストで使用するモック フレームワークを作成するための [Stub API](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_stub_api.htm) がサポートされています。Apex テストで使用できるモックフレームワークを作成するためのモック。モックとスタブは、複雑なデータファクトリや外部のテストデータセットへの依存度を下げて、システムのデータ処理動作を検証するのに役立ちます。本番のようなトラフィックやデータ量が関連しないテストでは、モックやスタブの方が適している場合があります。
  - **デバイスと支援技術** - [魅力的な](/docs/architect/ja-jp/well-architected/guide/engaging)アプリケーションと[アクセス](/docs/architect/ja-jp/well-architected/guide/compliant#アクセシビリティ)可能なアプリケーションを構築するうえで重要なのは、さまざまなデバイスとさまざまな種類の支援技術でユーザーの期待に応えられるようにすることです。有意義なユーザビリティテストを効果的に実施するには、より多くの投資とさまざまな種類の専門知識が必要になる可能性がありますが、リリース時にユーザー向けアプリケーションがどの程度適切に設計されているかを把握する上で、これは不可欠な要素です。
  - **シミュレーター** \- 本番同様の大量のユーザー要求、API トラフィック、またはネットワーク速度の変動を複製する必要がある場合、これらの条件をシミュレートするツールが必要になることがあります。すべてのテストにこのレベルの投資が必要なわけではありません。多くの場合、これらのツールは拡張性とパフォーマンスのテストで最も役立ちます。
  - **AI およびエージェント テスト** \- テストの主な目標は、AI の幻覚を減らすことです。AI の幻覚は、捏造された誤った回答です。AI の使用事例をテストして、顧客に対する理解が不完全であること、データが欠落していること、メタデータが不完全な項目があること、データが古いことに起因する一般的な問題を明らかにします。テストセンターを使用して、このようなテストに必要なテストデータの作成を支援します。

### ALM パターンとアンチパターン

次の表に、組織で検索または作成するパターンと、回避または修正の対象となるアンチパターンを示します。

✨ [パターン & アンチパターンエクスプローラー](/docs/architect/ja-jp/well-architected-tools/guide/adaptable-application-lifecycle-management)で ALM のその他のパターンを検出します。

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">パターン</th>
            <th scope="colgroup">アンチパターン</th>
        </tr>
        <tr>
        <td rowspan="2"><b>リリース管理</b></td>
        <td><strong>本番：</strong>
        <br> - メタデータは、次のような安定したリリースメカニズムを使用していることを示します。
        <br> -- ロック解除済みパッケージに整理されるメタデータ
        <br> -- DevOpsセンターが有効でインストール中
        <br> -- ソース形式を使用したメタデータ API を介したリリース
        <br> - リリースログには、使用可能な履歴内の失敗したリリースは表示されません。
        <br> -リリース履歴には、リリース期間内の明確なリリースケイデンスおよび非常に均一なリリースクラスターが表示されます。</td>
        <td><strong>本番：</strong>
        <br> - メタデータは、次のような組織ベースのリリースメカニズムを使用していることを示します。
        <br> -- 変更セットの積極的な使用
        <br> -- メタデータ API を使用したリリースでは package.xml 形式を使用します。
        <br> - リリースログには、使用可能な履歴内の失敗したリリースの繰り返しが表示されます。
        <br> - リリースに識別可能なケイデンスがないか、リリースのクラスターが不規則である (ホットフィックスとアドホックロールバックの兆候)。
        <br> DevOps センターが有効になっておらず、インストールされていません。</td></tr>
        <tr><td><strong>ロードマップとドキュメント:</strong>
        <br> リリース名は明確です。
        <br> - 機能が特定の指定リリースに明確に関連付けられている。
        <br> - リリース名は検索および検出可能です。
        <br> -チームは、アーティファクト、開発項目、その他の作業に正しいリリース名でタグ付けするための明確なガイドラインを見つけて従うことができます。
        <br> - リリース名別にリリースマニフェストの明確なビューをまとめることができます。
        <br> - 生成 AI アプリケーションの品質しきい値は、さまざまな開発フェーズで定義されます。</td>
        <td><strong>ロードマップとドキュメント:</strong>
        <br> - リリース名は含まれません。
        <br> -機能が特定のリリースに明確に関連付けられていない。
        <br> - リリース名がその場限りで使用されているか、存在しない。
        <br> - チームは、アーティファクト、開発項目、その他の作業を異なる方法で参照します。
        <br> - リリース名を使用して、リリースマニフェストの明確なビューをまとめることはできません。
        <br> - 生成 AI アプリケーションの品質しきい値が定義されていないか、定義されているとしても、さまざまな開発フェーズで定義されていない。</td></tr>
        <tr><td><strong>環境戦略</strong></td>
        <td><strong>組織内:</strong>
            <br> - ソース駆動型の開発およびリリースモデルを採用している。
            <br> - Developer Sandbox および Developer Pro Sandbox でソース追跡が有効になっている。
            <br> 特定の環境のメタデータはリリースアーティファクトから独立しています。
            <br> - 環境はリリースパスに直接対応していません。
            <br> - 変更のリリースパスは、変更の種別 (高リスク、中リスク、低リスク) によって異なります。
            <br> -過密環境は存在しない。
            <br> - リスクの高い設定変更が本番で直接行われることはありません。
            <br> - ピーク営業時間中にリリースは発生しません。
            <br> - Data 360 Sandboxを使用して、Einsteinデータ ライブラリ、Knowledge記事、非構造化データを必要とするエージェントの使用事例を適切にテストする </td>
            <td><strong>組織内:</strong>
                <br> 組織ベースの開発およびリリースモデルを採用している。
                <br> - Developer Sandbox および Developer Pro Sandbox でソース追跡が有効になっていない。
                <br> 特定の環境のメタデータはリリースアーティファクトです。
                <br> - 環境はリリースパスに直接対応します。
                <br> - 変更の種別に関係なく、すべての変更のリリースパスは同じです。
                <br> - 過密環境が存在する。 - リスクの高い設定変更が本番で直接行われている。
                <br> - リリースは営業時間のピーク時に行われます。
                <br> - Einsteinデータ ライブラリ、Knowledge記事、非構造化データを必要とするAgentforceエージェントは、Data 360 Sandboxを使用してテストされません。</td></tr>
        <tr><td><strong>シグナリング戦略</strong></td>
            <td><strong>組織内:</strong>
                <br> - チームは、状態チェック API と SLO の定義と標準化に関して協力します。
                <br> - シグナリング戦略の定期的なレビューと調整は、事後および運用準備状況レビューの一環です。
                <br><strong>本番：</strong>
                <br> - すべてのアプリケーションに状態チェックが実装されています。
                <br> - アプリケーションは、負荷や機能などの状態に関する明示的なシグナルを提供します。
                <br> - アプリケーションは、連動関係が正常でない場合に正常に機能しないように設計されています。
                <br> - 負荷制限は、カスケード障害を防ぐために使用されます。
                <br><strong>設計の場合:</strong>
                <br> バックプレッシャおよび負荷制限メカニズムにより、トラフィックによってサービスが過負荷になることを回避します。
                <br> - 連動関係は最終的に失敗すると想定されます。シグナルハンドラーは、失敗を改善するために構築されています。</td>
            <td><strong>組織内:</strong>
                <br> - チームがサイロで業務を行っているため、一貫性と互換性のない健康シグナリングメカニズムが構築されている。
                <br> - シグナル戦略は後付けであり、インシデントが発生したときにのみ対処されます。
                <br><strong>本番：</strong>
                <br> - コンポーネントが正常性ステータスを通知せずに警告なしで失敗する。
                <br> - アプリケーションは、正常なサービスへの要求を無期限に再試行します。
                <br> - すべての要求は、重要度に関係なく同じ優先度で処理されます。
                <br> - 問題を特定するために、オペレータはユーザーからの苦情や重要なシステム障害などの事後対応型対策のみを使用します。
                <br><strong>設計の場合:</strong>
                <br> - すべての連動関係が常に使用可能であることを前提としており、ネットワークパーティション、遅延の急増、その他の一般的な問題は考慮されていません。
                <br> - アプリケーションが過負荷の場合でもすべての受信要求を受け入れるため、遅延や障害の可能性が高まる</td>
        </tr>
        <tr><td rowspan="4"><strong>テスト戦略</strong></td>
            <td><strong>ビジネス:</strong>
                <br> - ユーザビリティテストでは、さまざまなデバイスと支援技術が使用されます。
                <br> - シミュレーターを使用して、拡張性とパフォーマンスのテストで本番同様の条件を再現します。
                <br> - 変更がソース制御に反映されると、テストが自動化されて実行されます。
                <br> - アプリケーション開発サイクルで耐久テスト、ストレステスト、パフォーマンステスト、スケールテストがいくつかの間隔で実行され、進行中のタスクとみなされます。
                <br> - B2C スケールのアプリケーション、大量のユーザー、大量のデータがある場合、QA プロセスの一部としてスケールテストを含めます。
                <br> スケールテストは、システムの優先度の高い側面に焦点を絞っています。
                <br> スケールテストには明確な条件があります。
                <br> - Full Sandbox でスケールテストを実施します。
                <br> - プロンプトエンジニアリングには人間による品質レビューが含まれます。
                <br> Agentforce テストセンターは、堅牢なエージェントテストに使用されます。</td>
            <td><strong>ビジネス:</strong>
                <br> - ユーザビリティテストは実施されないか、実施されるとしても、一部のデバイスで実施されます。
                <br> - 本番同様のユーザー要求量、API トラフィック、ネットワーク速度の変動はテストされません。
                <br> テストの自動化が行われていない。
                <br> - 耐久、ストレス、パフォーマンス、スケールテストは、開発のフェーズまたはフェーズとみなされます。
                <br> - QA プロセスの一環としてスケールテストを実施しておらず、B2C スケールのアプリケーション、大量のユーザー、大量のデータがある。
                <br> -スケールテストに優先順位が付けられていない。
                <br> スケールテストに明確な条件がない。
                <br> Partial Copy SandboxまたはDeveloper Sandboxでスケール テストを実施します。
                <br> - プロンプトエンジニアリングには人間による品質レビューは含まれません。
                <br> - Agentforce エージェントはテストされません。テストされている場合は、Agent Builder を使用してアドホックでのみテストされます。</td></tr>
        <tr><td><strong>組織内：</strong>
                <br> - すべてのテストデータは、機密データと識別データで整理されます。</td>
            <td><strong>組織内：</strong>
                <br> - テストデータは本番データと同一です。</td></tr>
        <tr><td><strong>Apex:</strong>
            <br> - データファクトリパターンが単体テストに使用される
            <br> - モックとスタブを使用して API 応答をシミュレーションします。</td>
            <td><strong>Apex:</strong>
                <br> - 単体テストは組織データに依存します。
                <br> - モックとスタブは使用されません。</td></tr>
        <tr><td><strong>設計標準およびドキュメント:</strong>
            <br> - 環境は、サポート可能なテストの種類によって分類されます。
            <br> リスク、使用事例、複雑さに応じて適切なテスト体制が指定されます。</td>
            <td><strong>設計標準およびドキュメント:</strong>
                <br> 各環境でサポートされるテストの種類が明確でない。
                <br> - テスト計画は、リスク、使用事例、複雑さで分類されません。</td>
        </tr>
    </tbody>
</table>

## インシデント対応

セキュリティおよびサイトの信頼性エンジニアリング (SRE) では、インシデント対応は、システム全体の可用性やセキュリティに影響するイベントをチームが特定して対処する方法、および根本原因に対処して将来の問題を防止する方法に焦点が当てられます。インシデント対応には、問題の発生後およびリアルタイムで問題に対処するために必要なプロセス、ツール、および組織行動が含まれます。

アーキテクトは、稼働開始後にソリューションの運用を日常的に監視する立場にはなりません。レジリエンスのための設計の一環として、サポートチームが第 1 レベルの診断を実行し、システムを安定させて、調査と根本原因の軽減を開発またはメンテナンスチームに効果的に渡すことができる復旧機能を設計します。ユーザーを日常的に直接サポートするチームは、システムのアーキテクチャに対する深い理解や専門知識を持っていない可能性があります。これらのチームには、日常業務を監視し、潜在的なインシデントを診断するときにシステムから情報にアクセスし、可用性に影響する問題の効果的な初期対応者となるために必要なツールとプロセスが不可欠です。

[リカバリ時間](/docs/architect/ja-jp/well-architected/guide/resilient#time-to-recover-リカバリ時間)、[優先順位付け](/docs/architect/ja-jp/well-architected/guide/resilient#優先順位を付ける機能)、[監視とアラート](/docs/architect/ja-jp/well-architected/guide/resilient#監視とアラート)に重点を置くことで、Salesforce ソリューションのインシデントに対するチームの対応を改善できます。

### Time to Recover (リカバリ時間)

インシデントが発生した場合、最優先事項はシステムを安定した稼働状態に復元することです。多くの場合、企業はインシデントから回復する唯一の方法は「問題を解決する」ことだと考えています。この前提は、正確な根本原因の分析と修復が、システム内の重要な問題を最終的に解決する方法であるという点で公平です。しかし、危機対応の初期段階での「問題解決」は、最も現実的なアプローチではありません。インシデントの重大度によっては、その 1 秒やその影響が収益や評価の低下につながる可能性があります。

多くの場合、根本原因を診断して対処しようとすると、システムを稼働状態に戻す作業が遅延します。論理的には、インシデント対応者に根本原因の対処を依頼するアプローチを採用すると、専門分野のエキスパート (SME) とサポートスタッフに大きな負担がかかります。インシデント*中*に根本原因を見つけて修正するには、SME がインシデントごとに待機する必要があるため、顧客対応の第一線のサポートスタッフが対応できない可能性があります。また、チームが変更をリリースし、その結果、インシデントがさらに発生する可能性もあります。最終的に、このようなアプローチではコストが増加し、チーム全体の帯域幅が消費され、危機発生時に顧客の Trust とブランドの評判が損なわれる可能性があります。

適切なインシデント管理パラダイムは、最初のステップとして復旧に優先順位を付けて集中することです。システムが安定した状態に復元されたら、責任のない事後調査、インシデント調査、根本原因の修復、および同様の活動をフォローアップできます。この業務順序により、インシデント対応スタッフは、必要に応じてのみ支援するように関連 SME にアラートを送信することで、復旧戦略の優先順位付け、診断、実行をより適切に行うことができます。また、SME はインシデントの根本原因を特定して修正できます。

インシデント対応に復旧優先の考え方を採用する

- サービスレベル目標の **SLO を確立**して達成します。SLO は、パフォーマンスやアップタイムなど、システムの特定の非機能要件 (NFR) について関係者と共に策定する標準です。これらの目標は、一定期間のサービスレベルインジケーター (SLI) によって測定されます。SLO がないと、インシデント対応や複雑な問題のトラブルシューティングに関する作業の多くが無秩序で反応的になる可能性があります。たとえば、「この特定のエラーを報告した一部のユーザーに対して、このエラーを停止する」ように迅速なアクションを促すことができます。このサイクルにより、チームは根本原因分析をインシデント対応に近づけることができます。これは、事後対応的な対応が停止される可能性があるからです。SLO と SLI を確立すると、より効果的に開始できます。SLO を確立するには、次の質問について考えます。
  - **今後 1~3 年間のシステムの NFR は?**たとえば、NFR には、システムでサポートする必要がある応答時間、ピーク要求レート、同時ユーザー数が含まれる場合があります。
  - **顧客とそのユーザーに何を体験してもらいたいですか?**「ユーザーは Salesforce でレポートをすばやく実行できます」というこの質問への回答に基づいて SLO を設定します。
  - **何を測定でき、どの期間測定する必要がありますか?**この質問への回答に基づいて SLI を作成します。前の例に一致する SLI は、「レポートの読み込みの _x_% が平均 _n_ 秒以内に行われ、30 日間にわたって測定された」とします。
- **リカバリ戦略を定義して標準化します。**変更のロールバックと回避策の実装は、システムを再び機能させ、インシデントの影響を最小限に抑えるのに役立ちます。サポートチームまたは運用チームの適切なメンバーが実行できる復旧戦略とプロトコルを文書化します。復旧戦略はインシデント種別によって異なります。次の表に、インシデント種別を復旧戦略に対応付ける一般的なフレームワークを示します。障害ポイントの特定と軽減戦略の定義についての詳細は、「[可用性」](/docs/architect/ja-jp/well-architected/guide/reliable#可用性)を参照してください。

<table>
    <tbody>
    <tr>
        <th align="center">インシデント種別</th>
        <th align="center">見かけのトリガー</th>
        <th align="center">リカバリ戦略</th>
    </tr>
    <tr><th rowspan="2"><strong>システム停止</strong></td>
    <td>ログインの破損やアカウントアクセスの問題</td>
    <td>アカウント回復ポリシー</td></tr>
    <tr><td>Service unavailability (サービス利用不可)</td>
        <td>冗長なバックアップ サービスの有効化、手動の回避策</td></tr>
    <tr><th rowspan="2"><strong>本番環境のバグ</strong></td>
    <td>最近の変更</td>
    <td>以前のバージョンのリリースのロールバックまたはリリース解除</td></tr>
    <tr><td>原因不明のバグの発生</td>
        <td>手動の回避策、重要でない機能の無効化、中小企業へのエスカレーション</td></tr>
    </tbody>
</table>

- **クリア終了条件**を定義します。SLO を使用して、システムがインシデントや影響の状況に該当しないかどうかを判断します。
- **インシデント後の確認と根本原因の修復のプロセスを定義します。**サービスが復元されたら、時間をかけてインシデントを確認します。レビュー時には、*無責任な事後*対応を行います。関係者と協力して、障害や非難を個人に割り当てるのではなく、*何*が*どのよう*に起こったかに関する明確な事実を確立することに集中します。さまざまなレビュー形式を使用して、長期的な問題に対処する方法を検討します。
  - *アクション後レビュー*では、インシデントへの対応に焦点が絞られます。これは、適切な対応プロセスと戦略が実施されているかどうかを評価するのに役立ちます。
  - *根本原因分析*では、インシデントの根本原因に焦点を絞ります。インシデントの原因となったシステムの設計と実装のバグや問題を特定するのに役立ちます。
- 合意したリカバリプロトコルを**定期的に**練習します。復旧プロトコルを実践して、全員がインシデントを適切に処理できるようにします。Sandbox とテスト環境を使用して、チームがインシデントのシミュレーションと復旧を練習できるようにします。また、インシデント後のレビューも練習します。これらすべての実践を行うことにより、復旧をエンジニアリングとサポートの文化の一部とすることができます。

[インシデント対応パターンと](/docs/architect/ja-jp/well-architected/guide/resilient#インシデントレスポンスパターンとアンチパターン)アンチパターンは、Salesforce ソリューションでリカバリに優先順位を付けるアーキテクチャを示します。これを使用して、構築前に設計を検証したり、システムのリファクタリングが必要な領域を特定したりできます。

リカバリ時間に役立つ Salesforce ツールについての詳細は、「[Salesforce Tools for Resiliency](/docs/architect/ja-jp/well-architected/guide/resilient#耐障害性のための-salesforce-ツール)」を参照してください。

### 優先順位を付ける機能

テクノロジーのコンテキストでは、トリアージには問題とサポート要請にカテゴリと重要度レベルを割り当てることが含まれます。ソリューションがどんなに綿密に計画されていても、ユーザーサポートの問題や要求が発生します。これらの問題は、十分なトレーニングや変更管理の欠如、UI/UX のギャップ、予期しないエンドユーザーの動作、[監視やアラート](/docs/architect/ja-jp/well-architected/guide/resilient#監視とアラート)で検出されない緊急のシステム問題などに起因します。

サポートチームと運用チームは、ユーザーサポートクエリを効率的に調査し、迅速に診断できる必要があります。問題の優先順位付けを行い、重大度の低い懸念を除外して重要なシステムインシデントをすばやく見つけることは、これらのチームの主要な能力です。優先順位付けが不十分だと、すべてのレベルのユーザーサポートが低下し、重要なインシデントが長期化し、顧客とビジネスがさらに中断するリスクが高まります。

日々の業務やサポートに関与していないかもしれませんが、アーキテクトは、Salesforce Platform で作成するソリューションでサポートチームや運用チームが効果的に問題の優先順位を付けられるようにする責任があります。

チームが Salesforce ソリューション内の問題を効果的にトリアージできるようにする

- **サポートチームが有益な情報にアクセスできるようにします。**
  - **システムと設計パターン**を文書化します。ソリューションの[読みやすさ](/docs/architect/ja-jp/well-architected/guide/intentional#読みやすさ)と一貫性を確保することは、サポートスタッフがサポートを担当するシステムを理解できるようにするうえで重要です。ドキュメントでは、システムのさまざまな部分で問題やインシデントに優先順位を付ける方法に関する情報をチームが見つける方法を検討します。また、チームは影響領域に基づいて復旧戦略に関する技術情報にすばやくアクセスできるようにします。トピック分類やアクションの選択など、Agentforce の一般的な問題に関連するトラブルシューティングガイドを提供します。これにより、チームは権限や設定に関連する問題をすばやく優先順位付けできます。
  - **デバッグを念頭に**置いて設計します。サポートチームと組織管理者は、さまざまな環境でユーザーの問題を正しくトリアージするために、デバッグと診断を有効にする必要があります。*デバッグに便利な*パターンの例として、システム全体の実行パスにロギングやカスタムエラーメッセージを組み込むパターンがあります。イベントログやエージェントビルダーの推論ビューなどのツールを使用して、一般的な Agentforce デバッグアプローチのサポートチームを有効にします。
  - インシデントの SME と関係者を**特定します**。インシデントからの回復をサポートする必要がある関連 SME または関係者、およびインシデント後の分析に関与する必要がある関連 SME または関係者のリストを作成します。
  - ハンドオフは**慎重に処理**してください。稼働開始の一環として、サポートチームまたは運用チームへの各ソリューションの引き渡しの品質を確認します。サポートスタッフが関連するシステムアーキテクチャや模擬インシデント対応訓練を受講するためのトレーニングを提供します。ログやケースノートで取得されない情報をチームが文書化する方法や、インシデント対応者が根本原因調査にどのように貢献できるか、または修正のユーザー受け入れテストをどのように実行するかなど、インシデント後の引き継ぎについて考えます。
- **相談を受けた場合は、すべてのユーザーがリカバリを最優先事項として意識してください。**
  - **迅速な対応。**受信したユーザーサポート要求、監視通知、アラートにすばやく対応します。
  - **症状と問題を区別します。**対処する必要がある実際のシステムインシデントがあるかどうかを判断します。実際の問題のあるコンポーネントを特定します。合意された[リカバリ戦略](/docs/architect/ja-jp/well-architected/guide/resilient#time-to-recover-リカバリ時間)に従って、システムをインシデント状況から迅速に抜け出すことができます。
- 重要な使用事例をサポートする Agentforce エージェントの場合、実行可能で関連する回避策が用意されていて、冗長性対策としてすぐに有効にできることを確認します。たとえば、手動処理に切り替えたり、関連ドキュメントにリダイレクトして手動で確認したりできます。

[インシデント対応パターンと](/docs/architect/ja-jp/well-architected/guide/resilient#インシデントレスポンスパターンとアンチパターン)アンチパターンは、効果的なトリアージのための設計が Salesforce ソリューションでどのように行われるかを示しています。これを使用して、構築前に設計を検証したり、システムのリファクタリングが必要な領域を特定したりできます。

トリアージに役立つ Salesforce ツールについての詳細は、「[Salesforce Tools for Resiliency](/docs/architect/ja-jp/well-architected/guide/resilient#耐障害性のための-salesforce-ツール)」を参照してください。

### 監視とアラート

*監視*と*アラート*は、サイトの信頼性エンジニアリングで広く使用されている用語です。システムの耐障害性のコンテキストでは、監視はシステムの現在の状態を継続的に評価し、アラートはシステムの状態に関する潜在的な懸念事項に関する関係者への通知を自動化します。効果的な監視とアラートは、サポートスタッフの規模と増加からシステムの規模と増加を切り離すための重要な要素です。

Salesforce には、システムの動作を監視するさまざまな組み込み機能があります。Salesforce では、アドオンまたは [Salesforce Shield](https://www.salesforce.com/products/platform/products/shield/) の一部として[リアルタイムイベント監視](https://developer.salesforce.com/docs/atlas.en-us.securityImplGuide.meta/securityImplGuide/real_time_event_monitoring_overview.htm)も提供しています。どの Salesforce ソリューションでも、監視とアラート用に設計された設計には次の利点があります。

- 自動インシデント対応機能
- 適切なタイミングで適切なユーザーに関連情報を提供
- 履歴ビューとトレンド分析のための明確な情報

Salesforce ソリューション内で効果的な監視とアラートを作成する

- **自動化を優先**事項にする。重要な状態の変更についてユーザーに通知することは、システムの安定性と運用を維持する上で重要ですが、理想的なアーキテクチャでは、可能な場合は問題が自動修正され、緊急で回復できない問題に関するアラートのみが送信されます。自動修正機能がなくても、自動化によってアラートとレポートがより便利になります。
  - **Salesforce がすでに提供**している機能から開始します。Salesforce Platform には、ガバナ制限に関するソリューションの運用を監視するための関連ログと API が用意されています。さらに、プラットフォームはガバナ制限違反や同様の問題についてアラートを送信します。これらのログとアラートを基礎として、システムのセルフリカバリ、インシデントレポート、アラートをより完全に自動化する方法を検討します。たとえば、ログを監視し、特定の種別のイベントが記録されたときに復旧アクションを実行する自動化を実装できます。
  - システム状態に対する**変更を分類**します。監視およびレポートする主要な状態の具体的で意味のあるカテゴリを作成します。これらのカテゴリは、[アプリケーションコンポーネント](/docs/architect/ja-jp/well-architected/guide/composable#状態管理)で状態を管理するために定義したカテゴリに揃えます。状態変更情報の処理方法に [API 指向](/docs/architect/ja-jp/well-architected/guide/composable#api-管理)の考え方を採用する。一貫したメッセージ形式と状態カテゴリにより、自動化、レポート、アラートが簡素化されます。
  - **自動化ロジックをシステムの他の部分に合わせます。**適切な自動化[エラー処理](/docs/architect/ja-jp/well-architected/guide/automated#エラーハンドリング)を構築している場合は、状態の変更を分類して自動化で応答する方法にこれらのパターンを拡張できます。復元可能とみなされる状態の変更については、再試行動作を自動化できます。重大または致命的とみなされる状態変更の場合、ユーザーへのアラートを自動化します。
- **ノイズの発生**を回避します。ユーザーが受信するアラート (特にアクションを実行する必要がないアラート) が多すぎると、すべてのアラートを無効化または無視する傾向があります。このシナリオでは、[有益な](/docs/architect/ja-jp/well-architected/guide/engaging#役に立つ)アラートを作成する努力が台無しになります。アラートを受信するユーザー、トリガーする対象、トリガーされるタイミングの範囲を広げるために、次のことを検討してください。
  - **関係者マップ**を作成します。システムが適切なアラートを適切な関係者に適切なタイミングで提供するには、まず関係者グループを特定して分類します。
  - **ユーザー権限に**基づいてメッセージを転送します。応答する能力と権限を持つ受信者にのみアラートを送信します。ビジネスユーザーは、アクセス権のあるレコードの問題を修正することで修正できる問題についてのアラートを利用できます。問題により技術的な対応が必要な場合は、サポートスタッフにアラートを送信する必要があります。
  - **予想される応答**を明確にします。アラートは、人の介入が必要なシナリオでのみ送信します。受信者に期待されるアクションを明確に示すようにメッセージを構造化します。関係者にアラートを送信して表示する場合、関係者からアクションを実行する必要がないときは、その旨を、関係者に送信されるメッセージのバージョンで明確にします。
  - **アラートをタイムリー**かつ適切にする。発生した障害に応じて配信され、まだ修正が必要なアラート) は、潜在的な障害に関するアラートほど役に立ちません。理想的には、システムで問題が発生したときにサポートスタッフにすぐにアラートが送信され、業務に悪影響が及ぶ前に問題[を優先順位](/docs/architect/ja-jp/well-architected/guide/resilient#優先順位を付ける機能)付けできるようにしてください。

[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/resilient#インシデントレスポンスパターンとアンチパターン)のリストは、効果的な監視とアラートを作成するための Salesforce ソリューションのアーキテクチャを示しています。これを使用して、構築前に設計を検証したり、システムのリファクタリングが必要な領域を特定したりできます。

監視およびアラート用の Salesforce ツールについての詳細は、「[Salesforce Tools for Resiliency](/docs/architect/ja-jp/well-architected/guide/resilient#耐障害性のための-salesforce-ツール)」を参照してください。

### インシデントレスポンスパターンとアンチパターン

次の表に、組織で検索または作成するパターンと、回避または修正の対象となるアンチパターンを示します。

✨ [パターン & アンチパターンエクスプローラー](/docs/architect/ja-jp/well-architected-tools/guide/adaptable-incident-response)でインシデント対応のより多くのパターンを検出します。

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">パターン</th>
            <th scope="colgroup">アンチパターン</th>
        </tr>
        <tr><td rowspan="4"><b>Time to Recover</b></td>
            <td><strong>ビジネス:</strong>
                <br> -回復プロトコルは定期的に実行されます。
                <br> - チームは本番のどのサービスを所有し、どのサービスに責任があるかを把握できます。
                <br> -チームは問題の診断をサポートする関連ツールを理解します。</td>
            <td><strong>ビジネス:</strong>
                <br> - リカバリプロトコルが存在しないか、定期的に実行されていない。
                <br> - 本番のさまざまなサービスを所有し、責任を持つチームが明確でない。
                <br> - チームには、問題の診断をサポートするツールに関するガイダンスや標準はありません。</td>
        </tr>
        <tr><td><strong>ドキュメント:</strong>
            <br> -リカバリー戦略はインシデント種別とトリガーで定義および分類されます。
            <br> - インシデント対応の終了条件は SLO に含まれており、明確です。
            <br> インシデント中に権限を昇格させるための有効化条件と割り当てロジックが明確である。
            <br> インシデント対応権限セットと承認が明確にリストされている。
            <br> 一般的な問題の特定と診断に役立つトラブルシューティングガイドが存在する。</td>
            <td><strong>ドキュメント:</strong>
                <br> インシデント対応がアドホックに実行される。
                <br> -インシデント応答の終了条件が存在しない。
                <br> - 昇格した権限が割り当てられていないか、割り当てられている場合はアドホックに割り当てられています。
                <br> インシデント対応権限セットと承認がリストされていない。</td>
        </tr>
        <tr><td><strong>組織内：</strong>
            <br> - インシデント対応用のセッションベースの権限セットが存在し、復旧時にサポートスタッフに割り当てることができます。
            <br> [Setup Audit Trail (設定変更履歴)] には、指定されたリカバリテスト担当者が、合意された時間にテスト環境にログインし、リカバリテストスクリプトに従ったことが示されます。</td>
            <td><strong>組織内：</strong>
                <br> - インシデント対応用のセッションベースの権限セットが存在しないか、存在する場合、サポートスタッフに権限がありません。
                <br> - [設定変更履歴] で、指定されたリカバリテスト担当者がテスト環境にログインしていないか、リカバリテストスクリプトに従っていないことが示される</td></tr>
        <tr><td><strong>テスト計画:</strong>
            <br> - リカバリテスト用のテストスクリプトが存在し、繰り返し可能である。
            <br> ・インシデントシミュレーションの環境が明確に記載されている。</td>
            <td><strong>テスト計画:</strong>
                <br> -リカバリテスト用のテストスクリプトが存在しない。
                <br> インシデントシミュレーションの環境が確立されていない。</td>
        </tr>
        <tr><td rowspan="3"><b>トリアージ機能</b></td>
            <td><strong>ビジネス:</strong>
                <br> - インシデントが発生する前に、複雑な問題をサポートするように警告する必要がある SME または関係者を特定します。
                <br> -配送チームとサポートチーム間の引き継ぎは稼働開始の一部です。
                <br> - 相談があれば、Salesforce アーキテクトが迅速に対応し、チームが復旧に集中できるようにします。</td>
            <td><strong>ビジネス:</strong>
                <br> - 警告を受ける必要がある SME または関係者は、インシデントが発生するまで特定されません。
                <br> -配送チームとサポートチーム間の引き継ぎはリリースプロセスに含まれません。
                <br> - Salesforce アーキテクトは、インシデント対応は自分の作業範囲外であると考えています。</td></tr>
        <tr><td><strong>ドキュメント:</strong>
            <br> - 特定のソリューションで使用されているシステムおよび設計パターンをサポートスタッフが検出および参照可能。</td>
            <td><strong>ドキュメント:</strong>
                <br> - 特定のソリューションで使用されているシステムおよび設計パターンをサポートスタッフがすぐに使用できない。</td>
        </tr>
        <tr><td><strong>組織内：</strong>
            <br> -ロギングとカスタムエラーメッセージがシステム全体の実行パスに組み込まれます。</td>
            <td><strong>組織の場合</strong>: - ログ記録メッセージとカスタムエラーメッセージは使用されません。</td></tr>
        <tr><td rowspan="2"><b>監視とアラート</b></td>
            <td><strong>組織内：</strong>
                <br> - アラートは、人の介入が必要なシナリオをユーザーに通知するためにのみ使用されます。その他の失敗は記録され、報告可能です。
                <br>  -アラートは、そのアラートに応答できるユーザーに送信されます。
                <br> 可能な場合は、潜在的な障害が発生する前にアラートが配信されます。</td>
            <td><strong>組織内：</strong>
                <br> - アラートは、後続のアクションが必要かどうかに関係なく、何らかの障害が発生したときに送信されます。
                <br> -技術的なソリューションが必要な問題に関するアラートがビジネスユーザーに配信されます。
                <br> - アラートは、すでに発生した失敗に対してのみ配信されます。</td></tr>
        <tr>
            <td><strong>ドキュメント:</strong>
                <br> - プロンプトチューニングアラートのエントリ条件は、直接および間接的な生成 AI フィードバック評価指標に基づいて定義されます。</td>
            <td><strong>ドキュメント:</strong>
                <br> - 生成 AI アプリケーションのプロンプトチューニングアラートをトリガーするための条件が定義されていません。</td></tr>
    </tbody>
</table>

## 継続性計画

ビジネスレジリエンスの鍵は、計画外のイベントによって発生した問題を通じて人とシステムが機能できるようにする方法に焦点を当てた継続性計画です。ビジネス継続性計画 (BCP) では、危機を乗り越えてプロセスを進める方法を人重視で考えます。継続性計画の技術的な側面は、BCP の災害復旧部分に含まれます。「[テクノロジー継続性](/docs/architect/ja-jp/well-architected/guide/resilient#テクノロジーの継続性)」を参照してください。

適切な継続性計画がなければ、危機やシステムの停止時に組織がどのように対処すべきかを把握できない可能性があります。効果的な継続性計画がない場合、顧客、関係者、ビジネスに壊滅的な影響を与える可能性があります。有害事象が発生した場合、重要なプロセスのメンテナンスや復旧が行われないまま経過すると、財務上の損害、評判の低下、従業員の安全、さらには規制へのコンプライアンスのリスクが高まります。

[Salesforce のビジネス](/docs/architect/ja-jp/well-architected/guide/resilient#ビジネス継続性)継続性の定義、[テクノロジーの継続](/docs/architect/ja-jp/well-architected/guide/resilient#テクノロジーの継続性)性の計画、バックアップおよび[リストア機能の構築](/docs/architect/ja-jp/well-architected/guide/resilient#バックアップおよび復元機能の構築)の 3 つの領域に集中することで、より適切な継続性計画をシステムに組み込むことができます。

### ビジネス継続性

すでに BCP が設定されている場合があります。含まれている場合は、Salesforce が含まれていることを確認します。会社に BCP がない場合は、関係者と協力して Salesforce 組織を対象とする BCP を作成します。

Salesforce は、多くのビジネス部門の顧客データと重要なビジネスプロセスの情報源として信頼されています。そのため、BCP で Salesforce が果たす役割は、他のシステムが果たす役割とは異なる場合があります。Salesforce は、復旧のために優先度の高い多くの領域に関与する可能性があります。

Salesforce システムに関連する事業継続計画を作成する

- **リカバリの優先**事項を明確にする。[インシデント対応](/docs/architect/ja-jp/well-architected/guide/resilient#インシデント対応)の一般的なアプローチと同様に、危機の瞬間のシステムにはリカバリが最優先される必要があります。多くのビジネスクリティカルなサービスが Salesforce で実行されます。関係者がさまざまなビジネス機能を復旧するための適切な優先度を特定できるようにする必要があります。一般的なフレームワークは次のとおりです。
  - 不可欠なビジネスインフラストラクチャの安定化。
  - カスタマーサービスの安定化。
  - 従業員とパートナーのサービスを安定させます。
- **BCP でエコシステムを考慮**します。Salesforce は、お客様の環境で唯一のシステムではありません。Salesforce と統合するシステム、AppExchange ベンダーからインストールされたソリューション、および Salesforce のデータやプロセスに接続するその他のシステムに関する BCP のギャップを特定します。提供できるかどうかがベンダーによって異なる場合は、それらのベンダーに継続性計画について問い合わせます。機能を評価し、システムの可用性を維持する方法を計画します。
- **BCP の懸念事項をテスト戦略に統合します**。BCP のテスト計画を作成して実行します。見過ごされがちなプロセスや人に関連する BCP の領域をテストすることは特に重要です。BCP の関連項目を全体的な ALM [テスト戦略](/docs/architect/ja-jp/well-architected/guide/resilient#テスト戦略)に組み込みます。メンテナンススケジュールを作成してそれに従い、テストを確認して計画を最新の状態に保ちます。

[継続性計画](/docs/architect/ja-jp/well-architected/guide/resilient#継続性計画パターンとアンチパターン)のパターンとアンチパターンは、Salesforce ソリューションでの適切な継続性計画と不適切な継続性計画を示します。これを使用して、構築前に設計を検証したり、システム内でリファクタリングが必要な箇所を特定したりできます。

ビジネス継続性を定義するための Salesforce ツールについての詳細は、「[Salesforce Tools for Resiliency](/docs/architect/ja-jp/well-architected/guide/resilient#耐障害性のための-salesforce-ツール)」を参照してください。

### テクノロジーの継続性

テクノロジーの継続性の目標は、システムのコンポーネントの問題によってビジネスに不可欠な業務が妨げられないようにすることです。Salesforce では、サービスの可用性を最高レベルに維持し、あらゆる問題に関する透明性の高い情報を提供することを優先しています。Salesforce システムのパフォーマンスと問題に関するリアルタイム情報は [Trust.salesforce.com](https://trust.salesforce.com/) で確認できます。Salesforce を基盤とするアーキテクトは、Salesforce がプラットフォーム全体で提供するサイトの信頼性、セキュリティ、およびパフォーマンス機能をソリューションで活用できます。

ただし、Salesforce ソリューションの全体的な継続性は、Salesforce が提供する組み込みサービスの範囲を超えて拡張されます。アーキテクチャの観点から見ると、Salesforce テクノロジーの継続性計画は、まず Salesforce が大企業の状況にどのように適合するかについて質問し、回答する必要があります。Salesforce と統合するシステムの種類は?外部システムは Salesforce のプロセスまたは情報にどのように依存しますか?Salesforce 組織で AppExchange ソリューションに依存しているプロセスまたは機能は何ですか?ユーザーはサードパーティ ID サービスまたは SSO を使用して Salesforce にアクセスしますか?

Salesforce システムでテクノロジーの継続性を高める

- **インフラストラクチャを評価します。**テクノロジーの停止や問題に対する最も一般的な修復戦略は、インシデント中にフォールバックできる冗長なサービスやシステムの構築です。Salesforce では、意図的に冗長化されたアーキテクチャを採用しています。つまり、顧客のシステムとサービスのコピーを異なる物理的な場所に保持しています。必要に応じてユーザートラフィックをデータセンター間で転送できるサイトの切り替えなど、いくつかのディザスタリカバリ技術を使用しています。意図的な冗長性を構築する必要がある可能性がある場所を特定するには、次の質問を自分に投げかけます。
  - \[X] サービスのサービス中断中はどうなるでしょうか?そのサービスから別のサービスに切り替えることはできますか?
  - \[X] のリカバリにはどのくらい時間がかかりますか?顧客への影響は?パートナーへの影響は?内部チームへの影響は?
  - [バックアップ](/docs/architect/ja-jp/well-architected/guide/resilient#バックアップおよび復元機能の構築)とその頻度は?バックアップによって、ビジネスをサポートするために必要なデータが提供されるか?
  - ベンダーとの依存関係があるか?顧客の BCP 計画は?
- **運用サポートを提供します。**運用サポートとは、チームができるだけ早く再開して稼働できるようにすることです。業務量要件の大幅な増加や、予期しない変化 (業界全体、地域全体、グローバルなど) による需要にシステムでどのように対処できるかを検討します。サイト信頼性エンジニアリング (SRE) またはサポートチームがインシデントに効果的に対応するために必要となる可能性のある追加のリソースやガラス破損時の手順を BCP が考慮していることを確認します。運用サポートについて尋ねる質問は次のとおりです。
  - 停止時に、技術チームは作業を継続するために必要なツールを使用できますか?計画の検証やギャップの特定のために停止をシミュレーションしましたか?
  - 災害が特定の地域で発生した場合、その地域の補償プランはありますか?
  - お客様はグローバルですか?24 時間 365 日稼働していますか?
  - 障害が発生したときに適切な個人に通知する適切な[監視とアラート](/docs/architect/ja-jp/well-architected/guide/resilient#監視とアラート)がありますか?
- **リカバリ戦略を自動化してテストします。**問題を修正したら、問題の発生場所と修正方法を特定します。可能な場合は、修復に基づいて復旧戦略を自動化し、プロセスの問題を調整します。多くの会社は、システムの耐障害性をテストするためにサービスのサブセットのインシデントシミュレーションをスケジュールします。たとえば、システム管理者アカウントのロックアウトや侵害のシミュレーション、AppExchange プロバイダーの停止や問題のシミュレーションなどです。「[インシデント対応](/docs/architect/ja-jp/well-architected/guide/resilient#インシデント対応)」を参照)。テストと自動化によってサービスを迅速に復元する方法に関する質問を次に示します。
  - インシデントシミュレーションのスケジュールと実行頻度は?
  - サービスを安定した状態に戻すのにかかる時間はわかりますか?
  - 安定した配送プロセスが確立されているか?
  - フェイルオーバーとリカバリを自動化できる場所は?

インシデント後レビューから出た項目は、他の開発項目と同様に扱います。計画システムに追加して、優先度を付けて作業できるようにします。

[継続性計画](/docs/architect/ja-jp/well-architected/guide/resilient#継続性計画パターンとアンチパターン)のパターンとアンチパターンは、Salesforce ソリューションでの適切なテクノロジー継続性計画と不適切なテクノロジー継続性計画を示します。これを使用して、構築前に設計を検証したり、システム内でリファクタリングが必要な箇所を特定したりできます。

テクノロジー継続性計画用の Salesforce ツールについての詳細は、「[Salesforce Tools for Resiliency](/docs/architect/ja-jp/well-architected/guide/resilient#耐障害性のための-salesforce-ツール)」を参照してください。

### バックアップおよび復元機能の構築

バックアップしたデータまたはメタデータのコピーを復元すると、組織が最新の既知の安定した状態に戻ることができます。また、重大なシステム障害やサービスの中断時にフェイルオーバーシステムを提供することもできます。データとメタデータを定期的にバックアップし、暗号化されたバックアップ済みコピーを安全な場所に保存すると、アーキテクチャの耐障害性が強化されます。

バックアップおよび復元戦略がないと、本番データとメタデータが悪意を持って破損した場合、不具合が誤って本番に取り込まれた場合、または大量のデータの読み込み中の障害で本番データが破損した場合に、クリーンなバージョンの本番データを復元できません。次のいずれかのシナリオでは、ビジネスクリティカルな本番データが破損したり、完全に失われたりする可能性があります。バックアップおよび復元テクノロジーの設定には、継続性計画に加えて、大量のデータを軽減する戦略の支援やコンプライアンス関連の保持ポリシーの遵守など、さまざまな利点があります。

Salesforce ソリューションでバックアップおよび復元戦略と確実に連携する

- **始めましょう。**優れたバックアップおよび復元戦略を実現するための最初のステップは、そもそも戦略を持つことです。組織のすべてのデータとメタデータを夜間にバックアップするといった単純な作業でも、災害時に重要な情報や機能が失われないようにすることができます。
- **バックアップへのアクセスを制限します。**システム管理者のみが、データのバックアップコピーにアクセスできます。このアクセス制限により、ビジネスユーザーは、組織での表示が許可されていないバックアップコピーのレコードを表示できなくなります。
- **復元プロセスを定期的にテストします。**実装するバックアップおよび復元戦略に関係なく、Full Sandbox または Partial Copy Sandbox で復元プロセスを定期的[にテストし](/docs/architect/ja-jp/well-architected/guide/resilient#テスト戦略)、必要なときに正常に機能することを確認します。
- **バックアップおよびリストア戦略をデータアーカイブ戦略と一致させます。**レコードがアーカイブまたはシステムから消去されたときにバックアップまたはアーカイブで何を実行するかを決定します。「[データ量](/docs/architect/ja-jp/well-architected/guide/reliable#データ量)」を参照)。

データ量が非常に多く、次のバックアップの実行を開始するまでにフルバックアップを完了するための時間がない場合は、より詳細なバックアップ戦略が必要になる可能性があります。また、組織のデータが頻繁に変更されるため、更新が組織にとってミッションクリティカルなものである場合は、より詳細なバックアップ戦略が必要になる場合もあります。

バックアップ戦略をより詳細にする

- バックアップの範囲を**特定のオブジェクト**に限定します。この戦略では、さまざまなオブジェクトから異なる間隔でレコードをバックアップします。データの一貫性を維持するために、子オブジェクトは親オブジェクトと同じ間隔でバックアップする必要があります。
- **タイム ボックスの\*\***部分バックアップ\*\*。この戦略では、フルバックアップ (すべてのデータとメタデータ) と部分バックアップ (メタデータと前回のバックアップ以降に追加または変更されたレコードのみ) を区別します。

**\*フル バックアップの実行は停止しないでください。**データ量が多いと実行時間が長くなる場合でも、完全なバックアップを排除しないでください。データ量が多い場合は、定期的で頻度の低いフルバックアップ (毎週のバックアップなど) を計画します。また、部分的なバックアップやオブジェクト固有のバックアップをより頻繁に計画します (夜間のバックアップや X 時間ごとのバックアップなど)。このアプローチにより、復元プロセスで使用する最も完全で正確なデータセットを柔軟に再構築できます。\*

[継続性計画](/docs/architect/ja-jp/well-architected/guide/resilient#継続性計画パターンとアンチパターン)のパターンとアンチパターンは、Salesforce ソリューションでのバックアップおよび復元機能の適切さと劣悪さを示します。これを使用して、構築前に設計を検証したり、システム内でリファクタリングが必要な箇所を特定したりできます。

### Salesforce のバックアップとリカバリ

Salesforce Backup and Recover (Salesforce バックアップおよびリカバリ) は、Own 買収からの Own Recover を含む統合 Salesforce ソリューションであり、重要なデータを損失や破損から保護します。安全性が高く、設定が容易で、いつでも使用できるソリューションにより、ビジネスの継続性とデータの復元性が確保され、コンプライアンスが簡素化されます。

Salesforce のバックアップとリカバリを使用して、データの損失を防止し、データインシデントから迅速に復旧し、全体的なデータ管理戦略を簡素化します。価値の高いデータおよび規制対象のデータのバックアップポリシーを作成し、数回クリックするだけでそのデータを復元できます。

#### 自動バックアップのリリース

日次自動バックアップにより、メタデータ、Sandbox、管理パッケージデータ、添付ファイルなど、重要な組織データがすべて保護されます。必要な頻度でバックアップを実行して、目標復旧時点 (RPO) の目標を達成し、導入を保護します。バックアップには常にアクセスでき、安全かつコンプライアンスに従って保存されます。継続的なデータ保護は、さらに機密性の高いデータやトランザクションデータにも対応しており、急速に変化する重要な情報をより迅速にリカバリできます。

#### データのプロアクティブな監視

メールに直接送信されるプロアクティブなアラートを使用して、異常なデータアクティビティ、データ損失、破損を検出します。統計的な異常値を特定したり、異常なデータアクティビティを通知するルールを作成したりするためのリアルタイムアラートを受信して、インシデントをこれまで以上に迅速に検出できるようにします。

#### 正確で迅速な復元

Salesforce のバックアップとリカバリでは、変更を詳細に可視化することで、影響を受けるデータをすばやく特定して復元できるため、リカバリが迅速化されます。ビジュアルグラフなどのツールでは不要な変更が強調表示され、使いやすいリカバリ機能では影響を受けるオブジェクト、項目、レコードが正確に復元されます。

#### バックアップの使用の拡張

このツールを使用すると、分析、監査、コンプライアンスのためにバックアップを使用できます。検索可能な履歴データ、過去のデータを表示するオープン検索機能、外部分析または倉庫のエクスポート機能を利用できます。これにより、Salesforce API を追加することなく、バックアップを再利用できます。

#### 統合バックアップデータ管理

バックアップとリカバリでは、すべてのバックアップ、管理、運用、コンプライアンスを 1 つのコンソールで統合できます。このコンソールでは、すべての本番組織と Sandbox のバックアップへのアクセス、管理、カスタマイズ、監視ができます。また、データ主体の要求を実行してバックアップデータのコンプライアンスを確保し、バックアップスケジュール、頻度、保持ポリシーを完全に制御してカスタマイズすることもできます。

#### Salesforce のバックアップとリカバリの主な使用事例

- **データインシデントの影響**を軽減します。Salesforce バックアップおよびリカバリでは、影響を受けるレコードをインシデント前の状態に戻すことで、サイバー攻撃や内部または外部の悪意のある活動などのデータインシデントを軽減できます。バックアップとリカバリのエクスポート機能では、ユーザーの重要なデータへの継続的なアクセスと使いやすさが保証されます。
- **永続的なデータ損失**を防止します。データ損失の主な原因は依然として人為的ミスです。バックアップとリカバリは、これらの間違いに対する正確かつ迅速なソリューションを提供します。
- **データコンプライアンスと法的要件への対応が容易になります。**Salesforce バックアップおよびリカバリでは、共有責任モデルがサポートされているため、バックアップデータの一括忘れやデータ修正のセルフサービス機能を使用できます。

バックアップおよびリストア用の Salesforce ツールについての詳細は、「[Salesforce Tools for Resiliency](/docs/architect/ja-jp/well-architected/guide/resilient#耐障害性のための-salesforce-ツール)」を参照してください。

### 継続性計画パターンとアンチパターン

次の表に、組織で検索または作成するパターンと、回避または修正の対象となるアンチパターンを示します。

✨ [パターン & アンチパターンエクスプローラー](/docs/architect/ja-jp/well-architected-tools/guide/adaptable-continuity-planning)で、継続性計画のためのより多くのパターンを検出します。

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">パターン</th>
            <th scope="colgroup">アンチパターン</th>
        </tr><td rowspan="3"><b>ビジネス継続性</b></td>
        <td><strong>ビジネス:</strong>
            <br> ・ 「 リカバリファースト」の考え方を採用し、最優先のビジネス機能と機能をできるだけ早く影響から除外することを重視します。
             <br> - BCP テスト計画のレビューのためのメンテナンススケジュールがある。</td>
        <td><strong>ビジネス:</strong>
             <br> インシデント管理には「問題を解決する」という精神が唯一のアプローチです。
             <br> - BCP テスト計画は定期的に更新されません。</td></tr>
    <tr><td><strong>ドキュメント:</strong>
         <br> - Salesforce が使用できなくなった場合にデータの処理を続行またはトリアージする手順、BCP の使用をトリガーするイベントのリスト、BCP テストの手順と間隔を含む BCP が存在します。
         <br> - BCP には、上流と下流のシステムおよび連動関係が含まれます。</td>
        <td><strong>ドキュメント:</strong>
             <br> BCP が存在しないか、完了していないか、Salesforce のみが含まれている。</td>
    </tr>
    <tr><td><strong>テスト計画:</strong>
         <br> プロセスと人に関連する BCP の領域が考慮されます。</td>
        <td><strong>テスト計画:</strong>
             <br> プロセスと人に関連する BCP の領域は考慮されません。</td></tr>
    <tr><td rowspan="2"><b>テクノロジーの継続性</b></td>
        <td><strong>ビジネス:</strong>
            <br> -意図的な冗長性システムやフェールオーバーシステムを構築する必要があるかどうかを評価済み
            <br> - インシデント回復戦略は可能な限り自動化されています。</td>
        <td><strong>ビジネス:</strong>
            <br> -意図的な冗長性やフェイルオーバシステムの必要性を評価していない
            <br> インシデント回復戦略はすべて手動です。</td>
    </tr>
    <tr><td><strong>ドキュメント:</strong>
        <br> - BCP は、チームがインシデントに効果的に対応するために必要となる可能性のある追加のリソースやガラス破損時の処置を考慮します。</td>
        <td><strong>ドキュメント:</strong>
            <br> - BCP に運用サポートのニーズが含まれていない。</td>
    </tr>
    <tr><td rowspan="2"><b>バックアップと復元</b></td>
        <td><strong>ドキュメント:</strong>
            <br> - データとメタデータの両方のバックアップおよびリストア戦略が存在する。</td>
        <td><strong>ドキュメント:</strong>
            <br> - バックアップおよび復元戦略が存在しないか、存在するとしても不完全であり、データのみに適用されるか、メタデータのみに適用されるかのいずれかです。</td></tr>
    <tr><td><strong>会社：</strong>
        <br> -バックアップは、承認されたユーザーのみがアクセスできる安全な場所に保存されます。
        <br> - テスト計画とテストログでは、データの復元が Full Sandbox または Partial Copy Sandbox で年に 2 回以上テストされていることが示されています。</td>
        <td><strong>会社：</strong>
            <br> -バックアップは人間が判読できません。
            <br> - バックアップは、未承認のビジネスユーザーがアクセスできる場所に保存されます。
            <br> -データ復元プロセスがないか、データ復元プロセスがテストされていません。</td>
    </tr>
    </tbody>
</table>

## 耐障害性のための Salesforce ツール

<table class="tools-table"><tbody><tr><th>ツール</th><th>説明</th><th>アプリケーションライフサイクル管理</th><th>インシデント対応</th><th>継続性計画</th></tr>

<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=sf.apex_hammer_execution_status.htm&type=5">Apex Hammer テスト</a></td>
<td>現在および新しいリリースでの Salesforce Apex テストについて説明します。</td>
<td class="check-col">X</td>
<td class="check-col"></td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_stub_api.htm">ApexスタブAPI</a></td>
<td>モックフレームワークを作成してテストを合理化します。</td>
<td class="check-col">X</td>
<td class="check-col"></td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=sf.backup_restore.htm&type=5">バックアップとリカバリ</a></td>
<td>データの損失を防ぐためにバックアップを自動的に生成します。</td>
<td class="check-col"></td>
<td class="check-col"></td>
<td class="check-col">X</td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=sf.custom_index.htm&type=5">Big Object</a></td>
<td>プラットフォームで大量のデータを保存および管理します。</td>
<td class="check-col"></td>
<td class="check-col"></td>
<td class="check-col">X</td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=tracking_field_history.htm&type=5&language=en_US">項目履歴管理</a></td>
<td>項目履歴を追跡および表示します。</td>
<td class="check-col"></td>
<td class="check-col">X</td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=adoption_security_metrics.htm&type=5&language=en_US">Get Adoption and Security Insights for Your Organization(組織の採用およびセキュリティに関するインサイトの取得)新しいウィンドウでリンクを開く</a></td>
<td>組織での Lightning Experience の採用と使用状況を監視します。</td>
<td class="check-col"></td>
<td class="check-col">X</td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=monitoring_async_api_jobs_overview.htm&type=5&language=en_US">データの一括読み込みジョブの管理</a></td>
<td>Bulk API を使用して、大量のレコードの更新または削除を行います。</td>
<td class="check-col"></td>
<td class="check-col">X</td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=event_monitoring_monitor_events_with_event_manager.htm&type=5&language=en_US">リアルタイムイベントモニタリングイベントの管理</a></td>
<td>イベント監視のストリーミングおよびストレージ設定を管理します。</td>
<td class="check-col"></td>
<td class="check-col">X</td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=admin_monitorresources.htm&type=5&language=en_US">データおよびストレージリソース</a></td>
<td>Salesforce 組織のストレージ制限と使用量を表示します。</td>
<td class="check-col"></td>
<td class="check-col">X</td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=code_monitoring_debug_logs.htm&type=5&language=en_US">デバッグログの監視</a></td>
<td>ログを監視し、ログをトリガーするフラグを設定します。</td>
<td class="check-col"></td>
<td class="check-col">X</td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=event_monitoring_faq.htm&type=5&language=en_US">ログインフォレンジックによるログイン活動の監視</a></td>
<td>なりすましを示す可能性がある行動を特定します。</td>
<td class="check-col"></td>
<td class="check-col">X</td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=admin_monitorsetup.htm&type=5&language=en_US">設定変更履歴を使用した設定変更の監視</a></td>
<td>システム管理者による最近の設定変更を追跡します。</td>
<td class="check-col"></td>
<td class="check-col">X</td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=monitoring_training_history.htm&type=5&language=en_US">トレーニング履歴の監視 (この機能は、現在日本のお客様に対してサポートしていません)</a></td>
<td>ユーザーが受講した Salesforce トレーニングクラスを表示します。</td>
<td class="check-col"></td>
<td class="check-col">X</td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=monitoring_background_jobs.htm&type=5&language=en_US">バックグラウンドジョブの監視</a></td>
<td>組織のバックグラウンドジョブを監視します。</td>
<td class="check-col"></td>
<td class="check-col">X</td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=data_monitoring_jobs.htm&type=5&language=en_US">スケジュール済みジョブの監視</a></td>
<td>レポートスナップショット、スケジュール済み Apex ジョブ、ダッシュボードの更新を表示します。</td>
<td class="check-col"></td>
<td class="check-col">X</td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=sf.technical_requirements_performance_assistant.htm&type=5">拡張性テスト</a></td>
<td>システムのパフォーマンスをテストし、結果を解釈します。</td>
<td class="check-col">X</td>
<td class="check-col"></td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://www.salesforce.com/services/professional-services/proactive-monitoring/">プロアクティブな監視</a></td>
<td>Salesforce 監視サービスを使用して中断を最小限に抑えます。</td>
<td class="check-col"></td>
<td class="check-col">X</td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=sf.data_mask_overview.htm&type=5">Salesforce Data Mask</a></td>
<td>Sandbox のデータを自動的にマスキングします。</td>
<td class="check-col">X</td>
<td class="check-col"></td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=dev_force_com_system_overview_page.htm&type=5&language=en_US">[システムの概要] ページ</a></td>
<td>組織の利用状況データと制限を表示します。</td>
<td class="check-col"></td>
<td class="check-col">X</td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/intro_framework.htm">力の使用:Lightning:糸くず</a></td>
<td>Salesforce CLIを使用してコードを分析および検証します。</td>
<td class="check-col">X</td>
<td class="check-col"></td>
<td class="check-col"></td>
</tr>
</table>

## レジリエントに関連するリソース

<table class="tools-table"><tbody><tr><th>リソース</th><th>説明</th><th>アプリケーションライフサイクル管理</th><th>インシデント対応</th><th>継続性計画</th></tr>
<tr>
<td><a href="https://medium.com/salesforce-architects/7-anti-patterns-in-performance-and-scale-testing-ba4eeda00516?source=friends_link&sk=5268a41719e7d01ba7f89f003064918f">パフォーマンスと拡張性のテストにおける7つのアンチパターン</a></td>
<td>パフォーマンスと拡張性のテストでは、一般的なアンチパターンは避けてください。</td>
<td class="check-col">X</td>
<td class="check-col"></td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://developer.salesforce.com/blogs/2022/05/analyze-performance-scale-hotspots-in-complex-salesforce-apps">複雑なSalesforceアプリケーションでのパフォーマンスの分析とホットスポットの拡張</a></td>
<td>組織のパフォーマンスと拡張性の問題に対処するためのアプローチについて説明します。</td>
<td class="check-col">X</td>
<td class="check-col"></td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://trailhead.salesforce.com/en/content/learn/modules/cybersecurity-threat-prevention-and-response/build-a-disaster-recovery-plan">災害復旧計画の作成 (Trailhead)</a></td>
<td>災害復旧計画を作成します。</td>
<td class="check-col"></td>
<td class="check-col"></td>
<td class="check-col">X</td>
</tr>
<tr>
<td><a href="https://medium.com/salesforce-architects/business-continuity-is-more-than-backup-and-restore-bebe9fb9b93d">ビジネス継続性はバックアップ/リストア以上のもの</a></td>
<td>BCP を包括的に把握します。</td>
<td class="check-col"></td>
<td class="check-col"></td>
<td class="check-col">X</td>
</tr>
<tr>
<td><a href="/docs/architect/ja-jp/resources/guide/design-standards-template">設計標準テンプレート</a></td>
<td>組織の設計標準を作成します。</td>
<td class="check-col">X</td>
<td class="check-col"></td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://medium.com/salesforce-architects/diagnostics-and-monitoring-tools-for-salesforce-part-1-bfa059f9a63e?source=search_post---------3----------------------------">Salesforce の診断および監視ツール</a></td>
<td>実装の品質とパフォーマンスを改善する方法について説明します。</td>
<td class="check-col"></td>
<td class="check-col">X</td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://medium.com/salesforce-architects/guiding-principles-for-bcps-6871d29ee947">ビジネス継続性計画の指針</a></td>
<td>効果的な BCP の基礎となる基本原則を確認します。</td>
<td class="check-col"></td>
<td class="check-col"></td>
<td class="check-col">X</td>
</tr>
<tr>
<td><a href="https://medium.com/salesforce-architects/how-to-scale-test-on-salesforce-bf933d5948b9">Salesforce でのスケールテスト方法</a></td>
<td>スケールテストライフサイクルの 5 つのフェーズについて説明します。</td>
<td class="check-col">X</td>
<td class="check-col"></td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://developer.salesforce.com/blogs/2020/09/introduction-to-performance-testing">パフォーマンステストの概要</a></td>
<td>パフォーマンステスト方法を開発する方法について説明します。</td>
<td class="check-col">X</td>
<td class="check-col"></td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://help.salesforce.com/s/articleView?id=sf.monitoring_admin.htm&type=5">組織の監視</a></td>
<td>セルフサービス監視オプションについて説明します。</td>
<td class="check-col"></td>
<td class="check-col">X</td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="/docs/architect/ja-jp/resources/guide/test-strategy-template">テスト戦略テンプレート</a></td>
<td>拡張性とパフォーマンスのテスト計画を作成してカスタマイズします。</td>
<td class="check-col">X</td>
<td class="check-col"></td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="/docs/architect/ja-jp/resources/guide/test-strategy-template">テスト戦略テンプレート</a></td>
<td>テスト戦略が完了していることを確認します。</td>
<td class="check-col">X</td>
<td class="check-col"></td>
<td class="check-col"></td>
</tr>
<tr>
<td><a href="https://trailhead.salesforce.com/en/content/learn/modules/sfdx_dev_model/sfdx_dev_model_sdd">ソース駆動開発について (Trailhead)</a></td>
<td>パッケージ開発とスクラッチ組織について説明します。</td>
<td class="check-col">X</td>
<td class="check-col"></td>
<td class="check-col"></td>
</tr>

</table>

## ご意見をお聞かせください

Salesforce Well-Architected の関連性の維持にご協力ください。このコンテンツに関するフィードバックをいただくため[のアンケート](https://sfdc.co/bxNtvh)にご協力ください。また、今後の展望についてもお聞かせください。

<!-- document id=34326fce301ac0da07f536c4eb1c4a88d47b2ad3c203bc8c44548c7f6236932b url=/architect/next/ja-jp/well-architected/guides/automated.md -->

> 更新スケジュールについては、[こちら](/docs/architect/ja-jp/well-architected/guide/contributors)を参照してください。

## はじめに

システムは、ビジネスが主要な目標と目標をより迅速かつ大規模に達成できるようにすることで、自動化された動作を示します。健全な自動化により、ユーザーは価値の高い作業に集中でき、反復的な手作業や複雑なデータ入力に費やす時間を短縮できます。

多くの場合、自動化とは、ビジネスプロセスを紙ベースのフォームからデジタルフォームへ、古いシステムから新しいシステムへ翻訳することです。ビジネスプロセスの翻訳には、必ず変革の機会が伴います。

変革とは、新しいテクノロジーを使用して、ユーザーの混乱を招くような変化をもたらすことではありません。トランスフォーメーションとは、作業をよりシンプルにする方法を作成し、円滑にビジネスを成長させ、ビジネスユーザーが関係者にとって本当に重要なことにより深く集中できるようにすることです。アーキテクチャの観点からは、完全に排除できる ToDo、または自動的に処理できる ToDo を特定する必要があります。テクノロジーの使用方法とビジネスに対する測定可能な影響を明確に関連付ける必要があります。

Salesforce での自動化に関する重要事項: プログラムによるスキルセットと宣言型のスキルセットを使用して、さまざまなツールで自動化できます。適切に設計された自動化を設計するとは、1 つの自動化ツールのみで構築することを選択することではありません。一貫性のある予測可能なアプローチを使用し、チームが設計した自動化を開発、テスト、リリース、維持できるようにすることです。自動化は、可能な限り[保守可能で読み](/docs/architect/ja-jp/well-architected/guide/intentional)やすい形式にする必要があります。

このセクションでは、企業が主要な目標をより迅速かつ大規模に達成できるように自動化を設計およびリファクタリングする方法について説明します。効率性とデータの整合性に重点を置くことで、Salesforce の自動化のアーキテクチャを改善できます。

## 効率

自動化の効率を高めるのは、Salesforce テクノロジーを使用して通常どおりビジネスを忠実に再現することではありません。これは、チームがミーティングや追跡の責任を負う主要な評価指標とビジネス上の成果を深く理解し、一歩下がって自動化している作業内および作業全体の[機能ユニット](/docs/architect/ja-jp/well-architected/guide/composable#機能単位)を確認することです。自動化を使用してパターンを作成し、ビジネスをより効果的かつ迅速に大規模に運営する方法を特定することです。

効率的な自動化ロジックにより、次のことが可能になります。

- 拡張性とビジネスにとっての価値の向上
- ユーザーにとってより役立つ
- [適応性](/docs/architect/ja-jp/well-architected/guide/adaptable-overview)と進化するビジネスニーズに対応

プロセス設計と運用ロジックを使用して、自動化の効率を向上させることができます。

### プロセス設計

プロセス設計には、作業方法の定義が含まれます。真に効率的で効果的なプロセスを構築することは、設計が現在の働き方を再現するだけではないことを意味します。効果のないステップや不明確なステップを特定して削除することが重要です。最適化されたプロセスでは、不要な手順を実行せずに測定可能なビジネス価値 ([「KPI](/docs/architect/ja-jp/well-architected/guide/automated#kpi)」を参照) を生み出す必要があります。不明確なステップや不必要なステップがあると、技術的な負債が発生し、自動化のメンテナンスができなくなる可能性があります。

多くの場合、ビジネスプロセスの検出と文書化の責任は、ビジネスアナリストやシステム管理者にも任されます。アーキテクトは、チームのこれらのメンバーと協力して、プロセス設計が技術的に健全で適切に構成されていることを確認する責任があります。Salesforce Platform に関する Knowledge をできるだけ早く適用することで、チームは自動化によって合理化するプロセスや、コストのかかるカスタマイズを回避するために変更が必要なプロセスを特定できます。

Salesforce 用に最適化されたプロセスを構築するには、次の点を考慮してください。

- **プロセスを徹底**的に定義します。目的が不明確なプロセスや定義があいまいなプロセスは、設計時に誤って解釈される可能性が高くなります。これにより、前提条件に基づく設計に欠陥が生じ、不正確または非効率的な自動化になります。自動化するビジネスプロセスが次の標準を満たしていることを確認します。

  - 1 つの特定の機能に限定 (「[機能単位](/docs/architect/ja-jp/well-architected/guide/composable#機能単位)」を参照)
  - 明確に定義された測定可能な出力がある(「[ビジネス バリュー](/docs/architect/ja-jp/well-architected/guide/automated#ビジネス上の価値)」を参照)
  - 明確に定義された入力と出力がある

- **プロセスステップを明確**にします\*。「将来役立つ可能性がある」ステップを追加することは魅力的ですが、この方法は決して適切ではありません。自動化の各ステップは、プロセス全体の結果に関連します。各プロセスステップに次の特性があることを確認します。
  - 特定の詳細なタスクを実行する (「[構成可能](/docs/architect/ja-jp/well-architected/guide/composable)」を参照)
  - プロセスで定義された出力を生成するために必要 (必須ではないすべてのステップを削除)
  - 最小限のリソースで完了できる
  - 可能な場合はユーザーの入力を求めるのではなく、既存のシステムデータを利用する(「[エンゲージメント](/docs/architect/ja-jp/well-architected/guide/engaging)」を参照)
  - ユーザーが基盤となるシステムのしくみを知らなくても理解できる入力オプションを提供します ([ヘルプを](/docs/architect/ja-jp/well-architected/guide/engaging#役に立つ)参照)。

次の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/automated#効率パターンとアンチパターン)のリストは、Salesforce 組織での最適化が適切 (および不適切) であることを示しています。これらを使用して、作成前に自動化設計を検証したり、さらに最適化する必要がある自動化を特定したりできます。

Salesforce から入手できるプロセス自動化ツールについての詳細は、「[Tools Relevant to Automated](/docs/architect/ja-jp/well-architected/guide/automated#自動化に関連するツール) (自動化に関連するツール)」を参照してください。

### 操作ロジック

運用ロジックは、プロセスを設計から実際の実装にどの程度効果的に変換するかを扱います。トランザクション量や実行中の同時インスタンス数の急増に関係なく、強力な操作ロジックを使用する自動化は引き続き適切に機能します。論理的に適切な自動化により、企業はより簡単に拡張して、より高い需要レベルで業務を行うことができます。自動化への強力な運用ロジックの組み込みは、システム全体の[信頼性](/docs/architect/ja-jp/well-architected/guide/reliable)に直接関連します。

自動化が効果的に機能しないと、ユーザー エクスペリエンスとカスタマー エクスペリエンスが低下し、収益の損失と Customer Trust の低下の両方が発生する可能性があります。また、メンテナンスコストも高くなり、ボトルネックとなって関連プロセスが遅延し、システム全体のパフォーマンスの問題が発生する可能性があります。

自動化で効果的な運用ロジックを作成するには、次の点を考慮してください。

- **自動化を作成する全員が適切な方法を確実に理解できるようにします。**どのような種類の自動化ツールでも、設計の選択肢は限られます。コードは、クリックベースのツールと同様に、エラーや不適切な実装の選択肢が発生しやすくなります。たとえば、ハードコードされた参照 ID の使用は、フローとコードの両方に現れるアンチパターンです。クリックベースのツールは、すべてのユーザーおよびすべてのユーザーがオートメーションを本番にリリースできるようにするライセンスとして捉えることはできません。オートメーションを作成するすべてのチームメンバーは、正しい方法でオートメーションを作成する方法を知っている必要があります。システム全体で有効な標準を定義して適用する方法についての詳細は、[「読みやすさ](/docs/architect/ja-jp/well-architected/guide/intentional#読みやすさ)と[設計標準](/docs/architect/ja-jp/well-architected/guide/intentional#設計標準)」を参照してください。
- **すべての実行パス**を明確に文書化します。自動化の使用が増加すると、潜在的なデータ量が増加するだけでなく、予定外のコールコンテキストも増加します。さまざまなオートメーションを呼び出す方法を理解し、複数のエントリポイントがあるすべてのオートメーションで適切なトランザクション制御 (「データ処理」を参照) が表示されることを確認する必要があります。たとえば、画面フローは一括データ読み込みでは実行されませんが、Apex トリガーおよびトリガー (および自動起動) フローはおそらく実行されます。実装時にどのような論理条件に対応する必要があるかを理解するうえで、自動化の計画済み実行パスと潜在的な実行パスを明確に文書化することは重要です。
- すべてのデータ操作 (SOQL を含む) を**「一括」**します。すべてのデータ操作 (挿入、更新など) はコレクションに対して実行する必要があります。いつも例外なくこれは、操作を「一括処理」することを意味します。プラットフォームではシングルトンデータ操作をサポートできますが、シングルトンパターンの実装を許可しないでください。
- **検索操作に SOSL** を使用します。SOSL を介して返されたレコードに対してデータ操作を実行できないという誤解があります。SOSL 結果に対して DML を直接呼び出すことはできませんが、コードは SOSL 結果を解析し、DML または Database クラスメソッドで参照できるコレクションを作成できます。SOSL と SOQL の主な違いは、それぞれの戻り値のデータ型と、汎用検索またはワイルドカード検索への応答方法です。SOSL は複数の sObject 型に対して機能でき (そのため戻り値の型が異なります)、ワイルドカード検索や一般化された文字列検索を SOQL よりも優れたパフォーマンスで処理できます。
- **SOQL をデータ操作**のように扱います。SOQL を使用してレコードを検索しないでください。SOQL を使用してデータ操作を絞り込みます。SOQL とデータ操作は、[基礎となるリレーショナルデータベース](/docs/architect/ja-jp/fundamentals/guide/platform-multitenant-architecture#プラットフォームデータレイヤー)のパフォーマンスに非常によく似た影響を与える可能性があります。SOQL では、データ操作を予期してデータベース行をロックする[明示的 DML インジケータ](https://developer.salesforce.com/docs/atlas.en-us.238.0.soql_sosl.meta/soql_sosl/sforce_api_calls_soql_select_for_update.htm?q=for%20update)を渡すこともできます。スケーラブルな自動化を作成するには、SOQL を同様の適正評価で処理してください。具体的には、特殊で適切な形式の選択基準を使用せず、無関係な項目の参照を許可せず、`WHERE`ステートメントロジックの項目と検索条件入力の間でデータ型を慎重に一致させる必要があります。また、一括処理されていないコンテキストや null または空白の検索条件に対してクエリが実行されないように、コードに適切な制御が必要です。
- **同期操作は、ユーザーをリアルタイムで支援する作業のみに焦点を絞ります。**[プロセス最適化](/docs/architect/ja-jp/well-architected/guide/automated#プロセス設計)時に、ユーザーがリアルタイムまたはほぼリアルタイムで実行する必要がある内容と、非同期 (非同期) トランザクションに延期できる内容に関連するロジックを特定します。同期/非同期操作の設計に関する考慮事項についての詳細は、「[データ処理」](/docs/architect/ja-jp/well-architected/guide/automated#データ処理)を参照してください。

次の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/automated#効率パターンとアンチパターン)のリストは、Salesforce オートメーションでの適切な (および不適切な) 操作ロジックを示しています。これらを使用して、作成前に自動化設計を検証したり、さらに最適化する必要がある自動化を特定したりできます。

拡張の計画に役立つ Salesforce から入手できるツールについての詳細は、「[Tools Relevant to Automated](/docs/architect/ja-jp/well-architected/guide/automated#自動化に関連するツール) (自動化に関連するツール)」を参照してください。

### KPI

自動化 KPI は、自動化の経時的な影響を測定します。これらがないと、自動化が本当にビジネス価値を高めているか、ユーザーの意図しない複雑さを生み出しているかを判断する方法がありません。作成するすべての自動化は、明確で測定可能な KPI セットに関連付ける必要があります。

優れた KPI は、関連付けられた期間と共に測定可能な値で定義されます。例として、次のようなものがあります。

- \[X 個の数値] 1 か月あたりの作業時間の短縮
- 手動データ入力による処理の失敗が週あたり \[Y%] 減少

明確で測定可能な KPI ができたら、Salesforce の自動化によってそれらの KPI に対するレポートに関連するデータが生成されるかどうかと、どのように生成されるかも理解する必要があります。

次の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/automated#効率パターンとアンチパターン)のリストは、Salesforce の自動化に関する適切な (および不適切な) KPI を示しています。これらを使用して既存の KPI を検証したり、構築する前に KPI をより適切に識別する必要がある場所を特定したりできます。

KPI に関するヘルプとして Salesforce から入手できるツールについての詳細は、「[Tools Relevant to Automated](/docs/architect/ja-jp/well-architected/guide/automated#自動化に関連するツール) (自動化に関連するツール)」を参照してください。

### 効率パターンとアンチパターン

次の表に、組織で検索 (または作成) するパターンと、回避または修正の対象となるアンチパターンの選択を示します。

✨ [パターン & アンチパターンエクスプローラー](/docs/architect/ja-jp/well-architected-tools/guide/easy-efficiency)でより多くのパターンを見つけて効率化します。

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">パターン</th>
            <th scope="colgroup">アンチパターン</th>
        </tr>
        <tr>
            <td rowspan="2"><b>プロセス設計</b></td>
            <td><b>組織内：</b>
            <br> - 各フローは 1 つの特定の目的を果たす
            <br> - 各ステップで特定の詳細なタスクを実行
            <br> - フローは、メインフローとサポートサブフローで構成される階層構造で編成されます。
            <br> - すべてのユーザー入力にフロー内の明確な目的がある
            <br> - 既存のシステムデータを使用できない場合にのみ、ユーザーにデータの提供が求められます。</td>
            <td><b>組織内：</b>
            <br> - フローは複数の目的を果たし、コンテキストを提供するために追加の入力が必要
            <br> - フローには、データが使用されていない入力が必要です。
            <br> - 関連ステップのグループには、他のフローのステップのグループと重複する機能が含まれています。
            <br> - フローは、保存されているデータを代わりに使用できる場合にユーザーの入力を要求</td>
        </tr>
        <tr>
            <td><b>Apex:</b>
            <br> - 各クラスは 1 つの特定の目的を果たす
            <br> - 各方法で特定の詳細なタスクを実行
            <br> - すべての入力変数には、クラス内で明確な目的があります。<br> - 最小限のリソースでコードを実行</td>
            <td><b>Apex:</b>
            <br> - クラスは複数の目的を果たす
            <br> - メソッドが複数の ToDo を実行する、またはメソッドが属するクラスの明確な目的と一致しない ToDo を実行する
            <br> - 入力変数は実際にはメソッドで使用されません。
            <br> - データベースまたは外部システムからデータを不必要に取得するメソッド</td>
        </tr>
        <tr>
            <td rowspan="3"><b>運用ロジック</b></td>
            <td><b>フロー内:</b>
            <br> - ハードコードされた値を参照する変数がない (レコードタイプ、ユーザーなど)
            <br> - すべての自動起動フローおよびプロセスでは、決定要素または一時停止要素、あるいはその両方を使用してエントリ条件を評価し、大量のデータに対する無限ループや実行を防止します。
            <br> - フロー(プロセスを含む)は、大量のデータ コンテキストでロジックをApexに渡す
            <br> - サブフローは、ビジネス全体で再利用する必要があるプロセスのセクションで使用されます。</td>
            <td><b>フロー内:</b>
            <br> - 変数の値がハードコードされている
            <br> - 一括データの読み込み前にフロー (プロセスを含む) を手動で無効化する必要がある
            <br> - フロー (プロセスを含む) で「未対応の例外」通知がトリガーされる
            <br> - 単純なフローでも、ガバナ制限に関連するエラーが発生することがよくあります。
            <br> - サブフローを使用するのではなく、フローの一部がフロー間で繰り返される</td>
        </tr>
        <tr>
            <td><b>Apex:</b>
            <br> - ハードコードされた値を参照する変数がない (レコードタイプ、ユーザーなど)
            <br> - すべてのワイルドカード条件が SOSL に表示されます。
            <br> - SOQL が <code>try-catch</code> でラップされている
            <br> - ループ内に SOQL が表示されない
            <br> - SOQL ステートメントは、次を含む選択的なステートメントです。
                <br> -- <code>類似</code>の比較や部分的なテキストの比較は使用しない
                <br> -- 比較演算子は、主ロジックまたは唯一のロジックとして正のロジック (<code>INCLUDES</code>、<code>IN</code> など) を使用します。
                <br> -- <code>= NULL</code>、<code>!= NULL</code> の使用はまれで、常に正の比較演算子の後にある
                <br> -- <code>LIMIT 1</code> ステートメントは表示されません。
                <br> -- no usage of <code>ALL ROWS</code> keyword
            <td><b>Apex:</b>
            <br> - 変数の値がハードコードされている
            <br> - SOSL がワイルドカード選択条件で使用されることはほとんどありません。
            <br> - SOQL が <code>try-catch</code> でラップされていない
            <br> - SOQL がループ内に表示される
            <br> - SOQL ステートメントは、次を含む非選択的です。
                <br> -- <code>類似</code>検索条件とワイルドカード検索条件が表示されます。
                <br> -- <code>NOT</code> 条件、<code>NOT IN</code> 条件を使用した比較は、主比較演算子または唯一の比較演算子として使用されます。
                <br> -- <code>= NULL</code>、<code>!= NULL</code> 条件は主比較演算子または唯一の比較演算子として使用されます。
                <br> -- <code>LIMIT 1</code> ステートメントが表示されます。
                <br> -- <code>ALL ROWS</code> キーワードが使用されている
        </tr>
        <tr>
            <td><b>設計標準およびドキュメント:</b>
                <br> - 自動化の計画済み実行パスと潜在的な実行パスが明確になっている
                <br> - 自動化内の同期操作と非同期操作の使用事例が設計標準の一部として明確に示されている
            </td>
            <td><b>設計標準およびドキュメント:</b>
                <br> オートメーションの呼び出しが文書化されていない
                <br> - 同期操作と非同期操作の使用事例は対応していません。
            </td>
        </tr>
        <tr>
            <td rowspan="2"><b>KPIs</b></td>
            <td><b>ドキュメント内：</b>
            <br> - すべてのオートメーションの出力は測定可能で期限付き
            <br> - KPI ごとに説明可能な関係者がリストされている</td>
            <td><b>ドキュメント内：</b>
            <br> - 自動化の KPI が存在しないか、メジャメントの期間が明確でない
            <br> - KPI には説明責任のある関係者がいない</td>
        </tr>
        <tr>
            <td><b>レポートおよびダッシュボード内：</b>
            <br> - KPI に関連するすべての総計値が 1 つ以上のレポートまたはダッシュボードに含まれている</td>
            <td><b>レポートおよびダッシュボード内：</b>
            <br> - KPI レポートが存在しないか、一部の KPI に関連する評価指標がレポートにない</td>
        </tr>
    </tbody>
</table>

## データ整合性

データの整合性とは、システムが正確で完全なデータをどの程度適切に維持するかということです。Salesforce Platform では、個々の組織のリレーショナルデータベースに保存されているデータの整合性を保護するために設計された堅牢な[組み込み処理ロジック](/docs/architect/ja-jp/fundamentals/guide/architecture-basics#データベース操作)が保持されます。健全な自動化を構築するための基本の 1 つは、Salesforce の組み込みデータ整合性動作を理解し、すべての自動化設計がこれらの動作に準拠していることを確認することです。

自動化設計の最大のアンチパターンは、[Salesforce がすでに](/docs/architect/ja-jp/fundamentals/guide/architecture-basics#データベース操作)提供している強力なデータ整合性サービスを認識できず、これらのサービスを利用する[標準機能](/docs/architect/ja-jp/well-architected/guide/intentional#標準機能とカスタム機能)を使用できないことにあります。データの整合性を保護および維持する自動化を設計するには、Salesforce の基本的な動作順序に精通している必要があります。

データの整合性をカスタム自動化に適切に拡張すると、次のことが可能になります。

- 手動操作なしで一括処理や大量データに対する操作が可能
- 必要に応じてユーザーセキュリティポリシーを適用し、必要に応じてシステムコンテキストに切り替えます。
- 実行時にエラーが発生し、予測可能な復旧パスまたは障害パスを辿る。

適切なデータ処理とエラー処理により、Salesforce オートメーションにデータの整合性を高めることができます。

### データ処理

Salesforce で適切にデータを処理できるように設計するための最初のステップは、マルチテナントプラットフォームで[トランザクション](/docs/architect/ja-jp/fundamentals/guide/architecture-basics#トランザクション)を処理する方法を理解することです。これには、レコードレベルのデータ操作中にデータの整合性を確保するために Salesforce Platform で使用される組み込み[の実行順序](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm)動作の理解も含まれます。この動作の影響についての詳細は、「Salesforce アーキテクチャの基本」の「[データベースの操作](/docs/architect/ja-jp/fundamentals/guide/architecture-basics#データベース操作)」を参照してください。

オートメーションのデータ処理が不適切である場合は、識別して完全に修正するのが最も困難なアンチパターンの 1 つになる可能性があります。プラットフォームの実行順序は再帰的で重複しているため、問題の発生場所を特定することが困難です。致命的なエラーをスローする、またはガバナ制限を超えるコードまたはフローの特定のセクションが、根本的なデータ処理問題の根本原因ではない可能性があります。

*トランザクション認識*は、Salesforce を使用して信頼性と拡張性を備えた自動化を構築するうえで重要です。つまり、自動化の各ステップは、プラットフォームで制御される[実行順序](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm)に対する相対的な位置の Knowledge に基づいて設計され、機能を正しく実行して、情報を次のステップに正しく渡すことができます。

使用している自動化ツールに関係なく、適切なトランザクション認識は同様のパターンに従い、一般的な考慮事項が必要です。

- すべての自動化は、任意の時点で大量のデータに対して予告なしに実行されることが想定されます。自動化には、一括または一括実行を可能にするパスが必要です(「[拡張性](/docs/architect/ja-jp/well-architected/guide/reliable#拡張性)」を参照)。
- 同じトランザクションでシステムコンテキストデータ操作とユーザーコンテキストデータ操作を混在させないでください。
- [*コンテキスト*前](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_context_variables.htm)の同期データ操作を予約し、コンテキスト*後*のすべてのアクションで非同期操作を使用します。
- [メッセージングと通知](/docs/architect/ja-jp/well-architected/guide/engaging#通知とメッセージ)を使用して、非同期操作の結果に基づいてユーザーがデータを待機する必要があるアプリケーション内環境を作成しないようにします。

トランザクション認識以外にも、データ処理には 2 つ目の側面があります。それは、さまざまな[実行コンテキスト](/docs/architect/ja-jp/fundamentals/guide/architecture-basics#execution-context-実行コンテキスト)でロジックを実行するタイミングを知ることです。オートメーションをさまざまな実行コンテキストに分割する一般的な理由は次のとおりです。

- **大量のデータ操作や複雑なデータ操作**
  - [一括処理](/docs/architect/ja-jp/well-architected/guide/automated#データ処理)では、自動化で大量のデータが正しく処理されるとは限りません。自動化内のデータ操作の量がトランザクションあたりの制限を超える場合、大量データに固有の機能(バッチ Apex や [Bulk 2.0 API](https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/asynch_api_intro.htm) など)を使用してデータ操作を実行する必要があります。これらは、大量のデータに適した個別のトランザクション制限があります。
  - レコード間で複雑なリレーション階層をトラバースしたり、複雑な再計算 (数式項目を含まない) を実行したりする必要があるデータ操作を一括で実行すると、トランザクションあたりの制限を簡単に超える可能性があります。システムで後続のアクションを完了するために必要な関連データ操作または SOQL の観点から、1 つのレコードの更新がどの程度「うるさい」かを検討します。
  - 自動化のチェーン全体に関与する sObject の種別では、「[混在 DML](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_dml_non_mix_sobjects.htm)」エラーを回避するために、データ操作を個別のトランザクションに分割する必要がある場合があります。
- **ユーザーまたはシステムコンテキストで実行する必要があるロジック**
  - Salesforce Platform は、ユーザーコンテキストでの[共有と表示](/docs/architect/ja-jp/well-architected/guide/secure#共有と表示)を適用します。オートメーションのユーザーの権限レベルを超える操作を実行する必要がある場合、それらの操作がシステムコンテキストで実行されることを確認する必要があります。
  - さまざまなツールは、さまざまなコンテキストで実行されるか、実行されません。
    - Apex はデフォルトでシステム コンテキストで実行されます。Apex 動作でユーザー レベルの共有ルールを適用するかどうかと適用方法を制御できます。これを行うには、Apex クラス定義で [sharing キーワード](https://developer.salesforce.com/docs/atlas.en-us.238.0.apexcode.meta/apexcode/apex_classes_keywords_sharing.htm?q=run%20as%20user)を使用します。
    - フローには 1 つのデフォルト動作はありません。フローは、フローの[起動方法に](https://help.salesforce.com/s/articleView?id=sf.flow_distribute_context.htm&type=5)基づいてユーザーコンテキストまたはシステムコンテキストで実行されます。システムコンテキストで共有を適用するオプションがあります。
    - プロセス (つまり、プロセスビルダーで作成されたオートメーション) は、共有に関する考慮事項なしでシステムコンテキストで実行されます。(注意:フローを使用してローコードの自動化を作成することをお勧めします。
- **非同期で実行する必要があるロジック**
  - 外部システム操作 - 外部データにアクセスする同期コールアウトまたはアクションは、プラットフォームのロールバック動作に含まれません。これらの動作を利用するには、外部システムを含むアクションを個別のトランザクションに配置する必要があります （非同期 [Apex](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_async_overview.htm) メソッド、[非同期パス](https://help.salesforce.com/s/articleView?id=release-notes.rn_automate_flow_builder_asynchronous_path.htm&type=5&release=234)、または[呼び出し可能アクション](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_forcecom_flow_invocable_action_callout.htm)を使用）。
  - イベントおよびメッセージング - データ操作に関連するイベントまたはメッセージのフローを制御する (およびプラットフォームのロールバック動作を利用する) には、非同期 Apex メソッドを使用して、メッセージングまたはイベントに関連するすべてのアクションを[*アフター*コンテキスト](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_context_variables.htm)に配置します。

次の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/automated#データ整合性パターンとアンチパターン)のリストは、Salesforce オートメーションでの適切な (および不適切な) データ処理を示しています。これらを使用して、作成前に自動化設計を検証したり、データ処理を改善するためにリファクタリングする必要がある自動化を特定したりできます。

自動化でのデータ処理に Salesforce から使用できるツールについての詳細は、「[Tools Relevant to Automated](/docs/architect/ja-jp/well-architected/guide/automated#自動化に関連するツール) (自動化に関連するツール)」を参照してください。

### エラーハンドリング

エラー処理は、データの整合性を保つために重要です。また、強力なエラー処理により、システムの拡張性と経年劣化[を回復力](/docs/architect/ja-jp/well-architected/guide/resilient)を高めます。

オートメーションで不適切なエラー処理が行われると、次の原因が考えられます。

- レコードの不一致やその他のデータ整合性の問題
- ユーザーや他のシステムへの不正確な通知の送信
- 手動または反復処理による時間とリソースの浪費
- システムに対する全体的な[Trust](/docs/architect/ja-jp/well-architected/guide/trusted-overview)の欠如

オートメーションのエラー処理では、実行中のプロセスに、情報のエラーを解析し、エラー情報に基づいて次のステップに関するロジックにアクセスして、正しいパスに従う機能を付与する必要があります。これらの機能は、すべての自動化で何度も構築する必要はありません([最適化アンチパターン](/docs/architect/ja-jp/well-architected/guide/automated#プロセス設計))。代わりに、システムのすべてのオートメーションは、関連するエラー処理[コンポーネント](/docs/architect/ja-jp/well-architected/guide/composable#疎結合)に接続できる必要があります。

適切なエラー処理コントロールをオートメーションに組み込むには、次の質問をします。

- 「致命的」エラーとは?
- 「回復可能な」エラーとは?
- ユーザーアクションによってトリガーされるオートメーションの場合、変更を確定する前にエラーを検出してユーザーに通知する方法は?

これらのエラーの処理方法を決定したら、効果的なエラー処理をオートメーションに組み込むことができます。次の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/automated#データ整合性パターンとアンチパターン)のリストは、Salesforce オートメーションでの適切な (および不適切な) エラー処理を示しています。これらを使用して、作成前に自動化設計を検証したり、エラー処理を改善するためにリファクタリングする必要がある自動化を特定したりできます。

エラー処理用に Salesforce から入手できるツールについての詳細は、「[Tools Relevant to Automated](/docs/architect/ja-jp/well-architected/guide/automated#自動化に関連するツール) (自動化に関連するツール)」を参照してください。

### データ整合性パターンとアンチパターン

次の表に、組織で検索 (または作成) するパターンと、回避または修正の対象となるアンチパターンの選択を示します。

✨ [パターン & アンチパターンエクスプローラー](/docs/architect/ja-jp/well-architected-tools/guide/easy-data-integrity)で、データの整合性に関するより多くのパターンを検出します。

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">パターン</th>
            <th scope="colgroup">アンチパターン</th>
        </tr>
        <tr>
            <td rowspan="4"><b>データ処理</b></td>
            <td><b>データ辞書:</b>
            <br> - すべてのデータソースとデータレークオブジェクトの項目レベルのデータと優先順位付けロジックが存在する
            <br> - データレークオブジェクトからデータモデルオブジェクトへの項目の対応付けが存在する</td>
            <td><b>データ辞書:</b>
            <br> - データソースとデータレークオブジェクトの項目レベルデータと優先度ロジックは含まれません。
            <br> - データレークオブジェクトからデータモデルオブジェクトへの項目の対応付けは含まれません。</td>
        </tr>
        <tr>
            <td><b>Apex：</b>
            <br> - すべての同期 DML ステートメントまたはデータベースクラスのメソッドがトリガー実行<i>前</i>のコンテキストで実行される
            <br> -非同期Apex呼び出しでは、キュー可能を使用してトランザクション間で複雑なDMLを「チェーニング」します。
            <br> -バッチApexは、大量のデータに対してのみ使用されます。
            <br> - <code>@future</code> Apex は、コールアウトまたはシステム オブジェクト DML で慎重に使用されていません。</td>
            <td><b>Apex：</b>
            <br> - DML ステートメントは、トリガー<i>後</i>のコンテキストで呼び出されるコードに定期的に表示されます。
            <br> - 非同期 Apex はほとんど使用されません。
            <br> - 次のような非同期 Apex 機能が任意に使用されます。
            <br> -- Future メソッドと Queueable Apex が一貫性がないか、同じ意味で使用されています。
            <br> -- データベース操作には、必要に応じて実行を一括処理 Apex に渡すための明確で一貫したロジックがない</td>
        </tr>
        <tr>
            <td><b>フロー内:</b>
            <br> - ユーザーコンテキストで起動されるすべてのフローは、すべてのシステムコンテキストトランザクションをサブフローに抽象化します。サブフローは、[一時停止] 要素の後に一貫して配置され、<a href="https://help.salesforce.com/s/articleView?id=flow_concepts_transaction.htm&type=5&language=en_US">新しいトランザクションを作成</a>します。
            <br> - (モノリスフロー内で複数のサブフローを呼び出すのではなく) Orchestrator を使用して関連データ操作の複雑なシーケンスを作成する
            <br> - すべてのレコードトリガーフローに<a href="https://help.salesforce.com/s/articleView?id=release-notes.rn_automate_flow_builder_trigger_order.htm&type=5&release=236">トリガー順序値</a>が入力されている
            <br> - 外部システムコールアウトまたは実行時間の長いプロセスが含まれるフローで非同期パスが使用されている</td>
            <td><b>フロー内:</b>
            <br> - 大規模なモノリシックフローが、関連するデータ操作の複雑なシーケンスを調整しようとする (サブフローの有無にかかわらず)
            <br> - レコードトリガーフローでトリガー順序属性がまったく使用されていない、またはトリガー順序値が一貫して使用されていない
            <br> - 非同期パスが一貫して使用されていない、またはまったく使用されていない</td>
        </tr>
        <tr>
            <td><b>組織内：</b>
            <br> - ID 解決調整ルールは、データ辞書の優先度設定ロジックに従います。</td>
            <td><b>組織内：</b>
            <br> - ID 解決調整ルールがデータ辞書の優先度ロジックに従っていない</td>
        <tr/>
        <tr>
            <td rowspan="4"><b>エラーハンドリング</b></td>
            <td><b>Apex:</b>
            <br> - コードは、すべての DML、SOQL、コールアウト、およびその他の重要なプロセスステップを <code>try-catch</code> ブロックでラップします。
            <br> -カスタム例外を使用して高度なエラーメッセージとロジックを作成<br> - 非同期コンテキストと一括コンテキストでは、DML の代わりに<a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/langCon_apex_dml_database.htm">データベースクラスメソッド</a>が使用される
            <br> - データベースクラスメソッドは、すべてのデータ操作 (DML の代わりに) で排他的に使用できます。</td>
            <td><b>Apex:</b>
            <br> - DML、SOQL、コールアウト、またはその他の重要なプロセスステップが一貫して <code>try-catch</code> ブロックでラップされていない
            <br> - 本番コードに <code>System.debug</code> ステートメントが表示される (コメントアウトされない)
            <br> - Database クラスのメソッドが使用されていない
            <br> - データ操作は DML のみで行われます。</td>
        </tr>
        <tr>
            <td><b>Lightning Web コンポーネント （LWC） の場合：</b>
            <br> - JavaScript は、すべてのデータ操作と重要なプロセスステップを <code>if ()</code>/<code>else if ()</code> ブロックでラップします。
            <br> - すべての <code>@wire</code> 関数は、API で提供され<code>たデータ</code>および<code>エラー</code>プロパティを使用します。
            <br> - すべての <code>if (error)</code>/<code>else if (error)</code> ステートメントには、エラーを処理して情報メッセージを提供するロジックが含まれます。</td>
            <td><b>LWC の場合:</b>
            <br> - JavaScript では、データ操作または重要なプロセスステップを含む <code>if ()</code>/<code>else if ()</code> ブロックを一貫して使用しません。
            <br> - <code>@wire</code> 関数は、API で提供され<code>たデータ</code>および<code>エラー</code>プロパティを使用しません (または、一貫して使用しません)。
            <br> - まったく使用していない場合、<code>if (error)</code>/<code>else if (error)</code> ステートメントには、エラーを処理して有益なエラーメッセージを提供するロジックが実際には含まれていません。</td>
        </tr>
        <tr>
            <td><b>Aura の場合:</b>
            <br> - JavaScript は、すべてのデータ操作と重要なプロセスステップを <code>try-catch</code> ブロックでラップします。
            <br> - <code>try-catch</code> ブロック内では、ネイティブの JavaScript <code>エラー</code>が throw ステートメントで使用されます (<code>$A.error()</code> は使用されません)。
            <br> - リカバリ可能なすべてのエラーロジックが <code>catch</code> ステートメント内に表示され、明確なユーザーメッセージが提供される</td>
            <td><b>Aura の場合:</b>
            <br> - JavaScript では、データ操作と重要なプロセスステップが一貫して <code>try-catch</code> ブロックでラップされない
            <br> - コンポーネントは <code>$A.error()</code> を使用します。
            <br> - リカバリ可能なエラーロジックが <code>catch</code> ステートメント内に一貫して表示されず、ユーザーへのエラーメッセージが明確でない</td>
        </tr>
        <tr>
            <td><b>フロー内:</b>
            <br> - 画面フローでは一貫して障害コネクタを使用してユーザーにエラーを表示します。
            <br> 画面に表示されるエラーに対してカスタムエラーメッセージを設定する
            <br> - データ操作、コールアウト、その他の重要な処理ロジックを含むフローには、すべての主要なアクションの障害パスがあります。</td>
            <td><b>フロー内:</b>
            <br> - フローで障害パスが一貫して使用されていない、またはまったく使用されていない
            <br> - カスタムエラーメッセージが使用されないため、ユーザーにはデフォルトの「このフローで未対応の障害が発生しました」メッセージが表示されます。</td>
        </tr>
    </tbody>
</table>

## ビジネス上の価値

自動化のコンテキストでのビジネス価値の概念は、プロセスがビジネス関係者に測定可能なプラスの影響をどの程度もたらすかということです。プロセスの自動化によって、反復的で価値の低いタスクに費やす時間を短縮できることが理想的です。また、エラーが発生する可能性のある手動処理作業を排除することで、データの整合性を高めることもできます。[プロセス設計](/docs/architect/ja-jp/well-architected/guide/automated#プロセス設計)と同様に、実際のビジネス バリューを促進する自動化を特定して提供するためには、基本的な検出やビジネス分析以上の作業が必要です。

ビジネスユーザーが要求したすべてのプロセスを、バックログ (またはチケットキュー) に表示される順序で、または組織の政治的要因に基づいて自動化することが、ビジネスに価値を提供する最善の方法と思われる場合があります。これにより、2 つの関連する問題が生じる可能性があります。つまり、最適な順序で自動化を構築することと、間違った自動化を完全に構築することです。1 つ目の問題は、優先順位付けが不十分で、価値の高いプロセスが必要なときに実装されず、成長が鈍化する可能性があります。2 つ目の問題は、間違った自動化を構築することで、価値の高い自動化のデリバリが遅延するだけでなく、時間の無駄遣いや不要なコストが発生し、デリバリチームのストレスが高まることです。

KPI と優先順位付けに重点を置くことで、より大きなビジネス価値を提供できます。

## 自動化に関連するツール

<table class="tools-table"><tbody><tr><th>ツール</th><th>説明</th><th>効率</th><th>データ整合性</th><th>ビジネス上の価値</th></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_batch.htm">Apex バッチ</a></td><td>レコードをまとめて管理可能なチャンクとして処理する</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_invoking_future_methods.htm">Apex Future メソッド</a></td><td>Apex メソッドをバックグラウンドで非同期に実行</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_queueing_jobs.htm">Apex Queueing </a></td><td>Apex ジョブをキューに追加して監視する</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_scheduler.htm">Apex Scheduler</a></td><td>Apex クラスを指定された時間に非同期で実行する</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=what_are_approvals.htm&type=5&language=en_US">承認</a></td><td>レコードを承認するために必要なステップを指定する</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_async_overview.htm">非同期 Apex</a></td><td>Apex コードを非同期で実行</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=customize_automatedactions.htm&type=5&language=en_US">自動アクション</a></td><td>項目自動更新、メール送信、その他のアクションをバックグラウンドで実行する</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=einstein_next_best_action.htm&type=5&language=en_US">Einstein Next Best Action</a></td><td>適切なおすすめを適切なタイミングで適切なユーザーに表示</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=customize_wfalerts.htm&type=5&language=en_US">メールアラート</a></td><td>自動メールの作成と送信</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.rules_escalation_actions.htm&type=5">エスカレーションアクション</a></td><td>ケースのエスカレーションで実行する自動アクションを指定する</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=workflow_managing_field_updates.htm&type=5&language=en_US">項目自動更新</a></td><td>自動化に基づいて項目値を更新する</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=release-notes.rn_forcecom_flow_fbuilder.htm&type=5&release=230">Flow Builder</a></td><td>ポイント &amp; クリックインターフェースを使用した自動化の構築</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=release-notes.rn_forcecom_flow_extend.htm&type=5&language=en_US&release=230">フロー拡張</a></td><td>保存されている変数にフローのコンポーネント入力としてアクセス</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://www.salesforce.com/products/platform/workflow-automation/workflow-library/flow-index/?#service">フローテンプレートライブラリ</a></td><td>テンプレートを使用した業種固有のフローの設計</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=creating_workflow_flow_actions.htm&type=5&language=en_US">フロートリガー</a></td><td>複雑なビジネスプロセスの自動化</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_actions_invocable.htm">呼び出し可能なアクション</a></td><td>Apex 機能をフローに追加する</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=orchestrator_flow_orchestrator.htm&type=5&language=en_US">オーケストレーター</a></td><td>複数ステップの自動化の作成と管理</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=workflow_managing_outbound_messages.htm&type=5&language=en_US">送信メッセージ</a></td><td>受信確認と再試行を使用して自動化プロセスから情報を送信する </td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_publish_flow.htm">フローを使用したプラットフォームイベントの公開</a></td><td>ユーザー操作と自動化による行動の公開</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_large_data_volumes_bp.meta/salesforce_large_data_volumes_bp/ldv_deployments_infrastructure_salesforce_query_optimizer.htm">Query Optimizer</a></td><td>選択性とインデックスを使用して、クエリ、レポート、リストビューのパフォーマンスを向上</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.flow_lightning_flow.htm&type=5">Salesforce フロー</a></td><td>Flow Builder を使用した宣言型プロセスの自動化の作成</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=livemessage_automatic_notifications_flows.htm&type=5&language=en_US">フローを使用した通知の送信</a></td><td>SMS、WhatsApp、Facebook Messenger でメッセージを送信</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=livemessage_automatic_message_notifications_process.htm&type=5&language=en_US">プロセスを使用した通知の送信</a></td><td>SMS、WhatsApp、Facebook Messenger でメッセージを送信</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.238.0.soql_sosl.meta/soql_sosl/sforce_api_calls_soql_select_for_update.htm?q=for+update">SOQL FOR UPDATE 修飾子</a></td><td>競合状態とスレッドの安全性の問題を回避するためにレコードをロックする</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=nba_strategy_builder.htm&type=5&language=en_US">Strategy Builder </a></td><td>レコードページに表示するおすすめを特定する</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_vpm_implementation_guide.meta/salesforce_vpm_implementation_guide/vpm_designer_about_subflows.htm">サブフロー</a></td><td>再利用によるフローの複雑さの軽減</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_subscribe_flow.htm">フローを使用したプラットフォームイベントの登録</a></td><td>オートメーションを介して公開されたメッセージの受信</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=customize_wftasks.htm&type=5&language=en_US">ToDo アクション</a></td><td>自動化によってユーザーに付与される割り当ての詳細を決定する</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
</table>

## 自動化に関連するリソース

<table class="tools-table"><tbody><tr><th>リソース</th><th>説明</th><th>効率</th><th>データ整合性</th><th>ビジネス上の価値</th></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm">Apex 実行ガバナおよび制限</a></td><td>Apex ランタイムエンジンによる制限の適用方法</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.admin_rebates_additional_resources_for_batch_management.htm&type=5">一括管理リソース</a></td><td>一括処理ジョブの作成、管理、スケジュール、監視</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.238.0.salesforce_large_data_volumes_bp.meta/salesforce_large_data_volumes_bp/ldv_deployments_best_practices_soql_and_sosl.htm">SOQL および SOSL のベストプラクティス</a></td><td>大量のデータを使用するアプリケーションのクエリパフォーマンスを向上</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="/docs/architect/ja-jp/resources/guide/design-standards-template">設計標準テンプレート</a></td><td>組織の設計標準を作成する</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.flow_concepts_bulkification.htm&type=5">トランザクションでのフローの一括処理</a></td><td>コレクションに対して操作するフローを設計する</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.flow_considerations_trigger_schedule.htm&type=5">フローデータに関する考慮事項</a></td><td>バッチデータのスケジュールトリガーフローについて</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=release-notes.rn_forcecom_flow_debug.htm&type=5&release=230">フローのデバッグ</a></td><td>フローのテストとトラブルシューティング</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/how_requests_are_processed.htm">要求の処理方法</a></td><td>Salesforce でジョブをすばやく処理して失敗を最小限に抑える方法</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="/docs/architect/ja-jp/resources/guide/kpi-spreadsheet-template">KPI Spreadsheet Template</a></td><td>特定の指標のビジネス価値を判断する</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_forcecom_flow_invocable_action_callout.htm">呼び出し可能なアクションからの外部システムへのコールアウト</a></td><td>Apex を使用したフローからの外部システムのコール</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_dml_non_mix_sobjects.htm">混在 DML 操作</a></td><td>同じトランザクションの DML で一緒に使用できる sObject を把握する</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm">実行順序</a></td><td>挿入、更新、更新/挿入のイベントの順序を理解する</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=000334796&type=1">クエリプランに関する FAQ</a></td><td>大量のデータが含まれるクエリを最適化する</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.flow_considerations_trigger_schedule.htm&type=5">スケジュールトリガーフローに関する考慮事項</a></td><td>スケジュールトリガーフローの特殊な動作について</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/langCon_apex_transaction_control.htm">トランザクションコントロール</a></td><td>現在のデータベースの状態を指定するセーブポイントを生成する</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.flow_build_logic_fault.htm&type=5">フローが失敗するとどうなるか</a></td><td>フローでのエラー処理について</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=000355199&type=1">ワークフローの自動化のベスト プラクティス ガイド</a></td><td>Salesforce オートメーションの使用開始</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/langCon_apex_SOQL_VLSQ.htm">Working with Very Large SOQL Queries (非常に大きい SOQL クエリの処理)</a></td><td>より効率的な SOQL クエリの作成</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
</table>

## ご意見をお聞かせください

Salesforce Well-Architected の関連性の維持にご協力ください。このコンテンツに関するフィードバックをいただくため[のアンケート](https://sfdc.co/bxNtvh)にご協力ください。また、今後の展望についてもお聞かせください。

<!-- document id=2c66c8b53875c9fe6e56cbce05e1fad697790698c432b3377df0f0b15877245d url=/architect/next/ja-jp/well-architected/guides/compliant.md -->

> 更新スケジュールについては、[こちら](/docs/architect/ja-jp/well-architected/guide/contributors)を参照してください。

免責事項:このドキュメントは情報提供のみを目的として配布され、法的なアドバイスを示すものではありません。また、このドキュメントを法律的なアドバイスとして使用しないでください。

## はじめに

準拠システムは、適用される法的および倫理ガイドラインに準拠するように設計されており、その遵守は測定可能かつ監査可能です。これは、意図する目的でデータアクセスを承認された個人に制限し、関連する法的規制を遵守し、すべての承認されたユーザーに公平なアクセスを保証することで実証されます。

プロアクティブな対策は、コンプライアンス違反を防止および検出するために不可欠です。規制と標準に対する反応型のアプローチでは、特に顧客の要求や苦情に応じてのみ変更が行われる場合、顧客の Trust が損なわれる可能性があります。このような苦情は、組織のブランドや評判を損ない、収益の損失につながる可能性があります。

Salesforce ソリューションのコンプライアンスを構築するには、法令遵守、倫理基準、アクセシビリティの 3 つの主要な習慣に焦点を当てます。

## 法的遵守

法的義務の遵守には、地域の法律と業界規制への準拠が含まれます。アーキテクトは、組織の法務チームまたはサードパーティ監査人が特定のコンプライアンス要件を決定したら、これらの要件を理解し、設計プロセスの早い段階で潜在的なコンプライアンスの問題を積極的に特定してフラグを設定し、罰金や訴訟のリスクを軽減する必要があります。

データプライバシーとローカライズにより、Salesforce ソリューションの法的遵守を改善できます。

### データプライバシー

データプライバシーは、ソリューションで個人識別情報 (PII) を収集、保存、処理する方法、関連する規制、および個人データへのアクセスを制御する個人の能力を扱います。これらの規制に準拠するには、[共有および表示モデル](/docs/architect/ja-jp/well-architected/guide/secure#共有と表示)の更新、アクセスを制限するメタデータ構成の変更、項目レベルの暗号化の実装、ログとイベントの監視、要求に応じて顧客のデータをエクスポートまたは削除する自動化の作成、自動化と AI でのデータ使用を規制するポリシーの作成が必要になる場合があります。

データプライバシー規制を遵守しないと、多額の罰金や訴訟につながる可能性があります。さらに、不十分な制御やセキュリティ侵害が原因で関係者データが公開されると、収益が失われ、Customer Trust が損なわれる可能性があります。

データプライバシー要件に準拠するには、次の点を考慮してください。

- **規制の専門家**に相談してください。法務チームまたはサードパーティ監査人と協力して、ビジネスに適用される業界固有のコンプライアンス規制を評価します。たとえば、ヘルスケア企業は医療保険の相互運用性と説明責任に関する法律 (HIPAA) に準拠する必要があります。
- **データを分類**します。データ分類により、プロジェクトチームは、組織のさまざまなデータ要素が使用される場合と使用されない場合を把握できます。また、データ管理ポリシーコンプライアンスに関する[レポート](https://help.salesforce.com/s/articleView?id=sf.data_classification_report.htm&type=5)を作成することもできます。適用される規制を[項目レベルで](https://help.salesforce.com/s/articleView?id=sf.data_classification_intro.htm&type=5)指定して組織のデータを分類し、所有者、機密レベル、その項目が現在使用されているかどうかを取得します。

分類プロセスでは、一見機密に思える項目だけでなく、データモデルのすべての項目をどのように使用するかを考慮することが重要です。場合によっては、重要でないように見える項目が、誤ったコンテキストで使用されると機密になることがあります。たとえば、米国の郵便番号は人種のプロキシになる可能性があるため、予測モードで使用した場合、意図せずにバイアスを追加したり、危害を加えたりする場合があります。人気のある名前は世代ごとに変わる傾向があるため、性別、出身国、人種、宗教、さらには年齢を予測するために名前を使用できます。すべての項目の分類と、関連付けられた AI 機能によるそれらの項目の使用方法の明確な説明を文書に含めます。

[Data Detect](https://help.salesforce.com/s/articleView?id=sf.einstein_data_detect.htm&type=5) などのツールを使用して、組織内の機密データを識別します。フィールドが機密として分類されている場合や、機密フィールドがわかっている場合は、Einstein Content Selection などのツールでも[高度な相関](https://help.salesforce.com/s/articleView?language=en_US&type=5&id=sf.mc_pb_manage_einstein_content_selection_attributes_and_bias.htm)関係があるフィールドが識別されるため、それらの機密フィールドのプロキシになる可能性があります。

- **データ ガバナンスのベスト** プラクティスを確立します。すべての関連ドキュメントが完全で最新であり、一元的に保存されていることを確認して、すべての関係者が簡単に使用できるようにします。これにより、法的責任に対する組織の保護が強化されると同時に、顧客やパートナーとの Trust も維持されます。たとえば、データ辞書にはシステムに保存されるすべてのデータ要素のオブジェクトおよび項目レベルの定義と分類が文書化され、設計ドキュメントには規制に準拠するために作成した自動化に関する詳細が含まれ、セキュリティマトリックスにはユーザーがアクセスできるデータの概要が示されます。重要なのは、この包括的なドキュメントが RAG(Retrieval-Augmented Generation)の正式なソースとなり、Agentforce などのエージェント システムを検証済みの準拠した運用コンテキストに直接グラウンディングすることで、出力の一貫性や幻覚の発生を防止することです。

次の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/compliant#法的遵守パターンとアンチパターン)のリストは、Salesforce ソリューション内の適切な (および不十分な) データプライバシー管理を示しています。これらを使用して、構築前に設計を検証したり、システムのリファクタリングが必要な領域を特定したりします。

データ プライバシーのための Salesforce ツールについての詳細は、「[準拠するツール](/docs/architect/ja-jp/well-architected/guide/compliant#準拠に関連するツール)」を参照してください。

### ローカライズ

ローカリゼーションとは、特定の言語、文化、目的の地域の美意識に合わせて製品を調整することです。これには、国や自治体によって大幅に異なる可能性があるデータレジデンシー法などの地域固有の規制への対応も含まれます。そのため、顧客の所在場所や自社の製品やサービスを市場に導入する方法によっては、システムが複数の規制フレームワークを満たす必要がある場合があります。

データプライバシー保護法の変更に加えて、多くの国ではデータレジデンシー法も制定されています。データレジデンシー法では、少なくともその国の国民に関連するすべてのデータをその国の国境内に物理的に保存することが義務付けられています。一部の法律では、さらに踏み込んで、市民がアクセスできる可能性のあるすべてのデータ (商品やサービスに関するデータを含む) をローカルストレージに保存する必要があります。場合によっては、規制により、その国または地域の他の市民のみが市民データを管理しなければならない場合があります。

違反すると、多額の罰金や訴訟につながる可能性があります。たとえば、EU のデータ保護当局は、2,000 万ユーロまたはグローバル収益の 4% のいずれか高い方の罰金を科すことができます。米国では、カリフォルニア州司法長官の事務所は、意図的な違反と意図しない違反の両方で重大な罰則を求めることができます。

ローカライズとデータレジデンシーの要件をより適切に管理するには、次の点を考慮してください。

- **規制の専門家**に相談してください。法務チームまたはサードパーティ監査人と協力して、ビジネスが展開されている地域の法律を評価し、どの法律が適用されるかを判断します。たとえば、EU の一般データ保護規則 (GDPR) や EU AI 法、カリフォルニア州消費者プライバシー法 (CCPA) などがあります。
- **データをローカル**に保存します。地域に固有のデータは、独自の個別の組織に保持します。Salesforce のパブリック クラウド基盤である[Hyperforce](https://help.salesforce.com/s/articleView?id=000356459&type=1)を使用して、特定の地域で組織をホストします。
- **データ複製を回避**します。ローカルデータストレージとは、データが国内に*保存され*ていることを意味します。もちろん、データが標準インターフェイスを介して国外に転送されると、コンプライアンスの問題が発生する可能性があります。たとえば、レコードをローカルで作成して管理し、別の国のデータウェアハウスに複製して報告することは、データレジデンシー法に違反します。地域間報告が義務付けられているグローバル企業で作業している場合、まずデータが保存されている国内でデータを集計し、それに関連する市民を識別できる可能性のある情報をすべて削除してから、集計情報のみを複製します。この方法では、より詳細なデータを国または地域レベルで利用できるように関係者に報告の制限を伝える必要がありますが、グローバルで使用できるのはサマリーデータのみです。

次の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/compliant#法的遵守パターンとアンチパターン)のリストは、Salesforce ソリューション内での適切な (および不適切な) ローカライズとデータレジデンシープロセスを示しています。これらを使用して、構築前に設計を検証したり、リファクタリングが必要な領域を特定したりします。

ローカライズ用の Salesforce ツールについての詳細は、「[Tools Relevant to Be Compliant](/docs/architect/ja-jp/well-architected/guide/compliant#準拠に関連するツール) (準拠に関連するツール)」を参照してください。

### 法的遵守パターンとアンチパターン

次の表に、組織で検索 (または作成) するパターンと、回避または修正の対象となるアンチパターンの選択を示します。

✨ [パターン & アンチパターンエクスプローラー](/docs/architect/ja-jp/well-architected-tools/guide/trusted-legal-adherence)で、法的遵守のためのより多くのパターンを検出します。

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">パターン</th>
            <th scope="colgroup">アンチパターン</th>
        </tr>
        <tr>
            <td rowspan="2"><b>データプライバシー</b></td>
            <td><b>ドキュメント:</b>
            <br> - 項目レベルの名前、説明、分類を含む最新のデータ辞書がある
            <br> -どのユーザーがどのデータにアクセスできるかを識別する最新のセキュリティマトリックスがある
            <br> - 規制要件に対応するために作成された自動化の標準と図を含む最新の設計ドキュメントがある</td>
            <td><b>ドキュメント:</b>
            <br> データ辞書が存在しないか、最新の状態に保たれていない
            <br> - 共有および表示ドキュメントが存在しないか、最新の状態に保たれていない
            <br> - 規制要件に対応する自動化の設計標準、図、ドキュメントが存在しないか、最新の状態に保たれていない</td>
        </tr>
        <tr>
            <td><b>組織内：</b>
            <br> - 機密情報が含まれるか、データプライバシー規制の対象となるすべてのオブジェクトと項目で、[コンプライアンス分類]、[データ所有者]、[データ機密性レベル]、[項目の利用状況] が設定されている</td>
            <td><b>組織内：</b>
            <br> - 機密情報が含まれるオブジェクトと項目、またはデータプライバシー規制の対象となる項目に、コンプライアンス分類、データ所有者、データ機密性レベル、項目の利用状況の設定がない。</td>
        </tr>
        <tr>
            <td rowspan="1"><b>ローカライズ</b></td>
            <td><b>ドキュメント:</b>
            <br> - 適用されるすべてのデータレジデンシー要件に準拠するためにデータを保存および管理する組織戦略がある
            <br> - 国境を越えてデータを複製するための受け入れ可能なシナリオとプロセスの概要を示す統合戦略がある
            <br> - 地域、国、グローバルレベルでレポートとダッシュボードに含めることができる粒度のレベルの概要を示す分析戦略がある</td>
            <td><b>ドキュメント:</b>
            <br> 組織戦略がないか、組織の戦略でデータのローカライズとレジデンシーの要件に対応できていない
            <br> インテグレーション戦略がないか、インテグレーション戦略でデータのローカライズとレジデンシーの要件に対応できていない
            <br> 分析戦略がないか、分析戦略がデータのローカライズとレジデンシー要件に対応していません。</td>
        </tr>
    </tbody>
</table>

## 倫理基準

ビジネスコンテキストでは、倫理基準とは、会社や個人が価値観や道徳的な観点からどのように行動するかを示すガイドラインです。Salesforce では、[コア バリュー](https://trailhead.salesforce.com/content/learn/modules/salesforce-culture-and-values/explore-salesforce-culture-and-values)が会社として、従業員として実行するすべての行動の指針となっています。また、お客様がソフトウェアを倫理的に使用できるように支援する[倫理的な使用](https://www.salesforce.com/company/intentional-innovation/ethical-use-policy/)ポリシー チームも編成しています。Dell EMC の[AUP(利用](https://sfdc.co/AUP)規定)と[AI AUP(AI](http://sfdc.co/AI-Policy)利用規定)はコア バリューの拡張であり、利用状況に関する質問が生じた場合に意思決定の指針となります。

組織によっては、単に地域の規制に準拠するだけでなく、さらに一連のポリシーが設定されている場合があります。これらのポリシーは、他の地域の規制への準拠、特定の組織や市場との取引の拒否、差別や偏った行動を防止するための従業員と顧客のやりとりの監視など、さまざまな形で使用できます。これらのポリシーに準拠するには、[法的遵守](/docs/architect/ja-jp/well-architected/guide/compliant#法的遵守)の場合と同様に設計標準またはシステム設定の更新が必要な場合があります。

Salesforce ソリューションの倫理基準への準拠を促進するには、会社のポリシーに従って、人工知能の使用を評価します。

### 会社の方針

会社のポリシーは、ビジネスのさまざまな側面 (人、プロセス、テクノロジーなど) をどのように運用すべきかを定義するガイドラインです。お客様は、Trust した組織と取引することを希望します。ほとんどの会社のポリシーは、この原則を反映するように設計されています。システムが規定のポリシーと一致しないユーザー エクスペリエンスを作成すると、Customer Trust はすぐに失われます。

効果的なポリシーは[倫理の文化](https://www.salesforce.com/blog/new-research-ethical-leadership-business/)から自然に生まれます。エンジニアリングや設計からデータサイエンス、マーケティング、営業に至るまで、すべての従業員は倫理的な使用に対する責任を教育する必要があります。このような文化では、従業員は倫理的な行動に報いる明確なインセンティブ構造と、非倫理的な行動に対する明確で一貫した結果を確認できます。

組織のポリシーが設計に反映されるようにするには、次の点を考慮してください。

- 意図しない**結果に注意**する。アーキテクトは、ソリューションの潜在的な影響とその使用方法を予測する責任があります。ハッピーパスの検討やテストだけに陥ってはいけません。代わりに、エッジケースのテストとトレードオフの評価に関する専門知識を活用して、ソリューションの倫理的な影響を徹底的に検討します。商品の影響を受けるすべての人 (特に、過少評価されている人、疎外されている人、弱い立場にある人) について考えます。誰かまたは何かがソリューションを操作し、意図しない結果を引き起こす可能性があるさまざまな方法を評価します。[Build With Intention Toolkit](http://sfdc.co/BuildwithIntention) を使用して、包含を念頭に置いて設計します。
- 会社の許容使用ポリシーに**倫理を組み込む**。法務チームまたはサードパーティと協力して、許容される使用ポリシーに倫理を含め、ソリューションの使用が会社の価値と一致するようにします。ローコードツールとプロコードツールのどちらで開発されたかに関係なく、ソリューションでサポートされる組織の価値とポリシーに関する情報をドキュメントに含める必要があります。許容される使用ポリシーを公開して、従業員および顧客との Trust 構築への取り組みを示します。
- **包括的な言葉**を使用します。ユーザーがソリューションをどのように使用しているかを理解し、ユーザー・インターフェース、コード、ドキュメントで[言葉を調整](https://www.salesforce.com/news/stories/salesforce-updates-technical-language-in-ongoing-effort-to-address-implicit-bias/)して、包括的さをより正確に反映します。まず、排他的な表現を特定して削除し、次に除外につながる可能性がある習慣や慣習の種別を理解することにコミットします。

次の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/compliant#倫理基準パターンとアンチパターン)のリストは、Salesforce ソリューション内での会社のポリシーへの適切な遵守 (および不適切な遵守) を示しています。これらを使用して、構築前に設計を検証したり、システム内でリファクタリングが必要な領域を特定したりします。

設計を会社のポリシーに合わせるための Salesforce ツールについての詳細は、「[準拠するツール](/docs/architect/ja-jp/well-architected/guide/compliant#準拠に関連するツール)」を参照してください。

### 人工知能

人工知能は、推論、知覚、意思決定など、通常は人間の知能を必要とするタスクを計算システムを使用して実行します。Salesforce Platform の AI 機能は予測、生成、エージェントの各テクノロジーにまたがり、カスタマーエクスペリエンスとビジネス運用を強化する包括的なツールスイートを提供します。

- **予測 AI は**履歴データを分析し、販売トレンドや顧客の離脱など、将来の結果を予測します。Einstein AI は、データのパターンを分析しておすすめを提供し、ビジネス上の成果を予測することで、これらのインサイトを提供します。
- **生成 AI**は、大規模な言語モデルを活用して新しいコンテンツを作成することに重点を置いています。Einstein GPT は、CRM データと連携して、メール、チャットの応答、顧客とのコミュニケーションなどのパーソナライズされたコンテンツを生成するコア コンポーネントです。
- **エージェント型 AI**は、エージェントが自律的に特定の目標を達成するための推論とアクションを実行できるようにすることで、AI をさらに進化させます。Agentforce は、これらのインテリジェントなエージェントを構築するためのプラットフォームであり、顧客のケースの解決やマーケティングキャンペーンの最適化などの複雑なビジネスプロセスを自動化できます。これらのエージェントは、Data 360 を介してリアルタイムでデータを操作でき、既存のワークフローと API を利用できます。これらの AI 機能はすべて Einstein Trust Layer によって保護され、倫理的な使用が確保されます。

Einstein AI のコア アルゴリズムのほとんどは設定できませんが、一部の機能では、ドキュメントに記載されているように、お客様が独自のデータを使用してモデルを微調整できる場合があります。さらに、拡張グラウンディング (RAG) を使用して独自の CRM、Knowledge ベースの記事、その他のドキュメントで AI モデルをグラウンディングし、組織、顧客、使用事例に合わせて出力の精度をさらに高めることができます。ただし、基礎となるデータが偏ったり歪んだりすると、出力も偏ったり不正確になったりする可能性があります。バイアスの例として、顧客ベースが多様で、特定の人種、性別、または民族のメンバーが含まれている場合でも、取引先責任者リストにそのメンバーが含まれないことがあります。詳細については、「Salesforce [Responsible Creation of AI Trailhead](https://trailhead.salesforce.com/en/content/learn/modules/responsible-creation-of-artificial-intelligence)」モジュール、「[Understanding Trusted Agentic AI Trailhead](https://trailhead.salesforce.com/content/learn/modules/trusted-agentic-ai)」、「[AI Ethics Maturity Model](https://www.salesforceairesearch.com/static/ethics/EthicalAIMaturityModel.pdf)」、「Salesforce の[信頼できる AI 原則](https://www.salesforceairesearch.com/trusted-ai)」、「[Responsible Generative AI Guidelines](https://www.salesforce.com/news/stories/generative-ai-guidelines/)」、および「[Responsible Agentic AI Guidelines](https://www.salesforce.com/news/stories/responsible-agentic-ai-guidelines/)」を参照してください。

適用される法的規制と会社の独自の倫理基準を考慮しないと、AI 内にバイアスがかかり、訴訟、収益の損失、Customer Trust の問題、会社のパブリック イメージの毀損につながる可能性があります。

AI の責任ある倫理的な使用について考慮すべき事項を次に示します。

- **データセットとドキュメント**を確認します。データセットが、AI 機能が影響するすべてのユーザーを表すようにします。これには、潜在的なバイアスを軽減するために、ユーザー調査でユーザーの正体を理解し、データがそのすべてを正確に表していることを確認することが必要になる場合があります。また、モデルの基礎となる CRM データ、Knowledge Article、その他のドキュメントを確認し、最新、正確、完全であることも重要です。大量のデータでモデルをグラウンディングしても役に立たないため、データが古い、矛盾している、不完全である場合には幻覚が生じる可能性があります。
- **[人間を指揮](https://www.salesforce.com/news/stories/human-at-the-helm/)**します。個々の AI インタラクションに人間が介入するのではなく、最も注意が必要な判断項目に従業員が集中できるようにします。AI システムがより多くの責任を負うことができると確信するまでテストし、結果が正確かつ効果的に機能し続けることを確認します。また、AI システムまたはエージェントが高リスクの使用事例や AI の信頼性レベルが低い場合に人間にエスカレーションするように指示します。
- モデルの出力と結果の安全**を優先**します。バイアス、説明可能性、堅牢性[の評価](https://www.salesforce.com/news/stories/developing-ethical-ai/)、および[倫理的なレッドチーミング](https://www.salesforce.com/blog/red-teaming-ai/)を実施する。トレーニングに使用されるデータに含まれる個人識別情報 (PII) のエージェント応答とアクションを通じてプライバシー保護に優先度を付け、追加の被害を防止するためのガードレールを作成します。テスト中に有害な結果が見つかった場合は、システムプロンプトに指示を追加して再テストします。また、Retrieval-Augmented Generation (RAG) で使用するデータの品質や代表性を向上させる必要もあります。
- **規制に備える**。AI に関する倫理的な懸念に加えて、多くの政府は、管轄区域内で業務を行う組織による AI の使用を規制する法律を制定したり、通過させたりしています。この法規制には、AI ソリューションがどのように作成され、どのように機能するかを説明するモデルカードの公開義務が含まれる場合があります。人工知能ベースのソリューションを実装する前に、システムが使用される地域で許可されるまたは許可されない AI 関連機能の種類を認識し、戦略に必要な調整を行います。地域の規制に準拠するために、一部の地域で特定の機能を無効にする必要があります。無効にした場合は、それらの機能を使用せずにシステムを引き続き稼働できることを確認してください。多くの管轄区域では、顧客やエンドユーザーが AI システムを操作するときの透明性も求められます。
- **組織の AI モデル**を監視します。影響を受けるユーザーは、AI が使用されたことを把握し、被害を簡単に報告して是正を要求する機会を得ることができます。レポートだけでは、AI 機能がユーザーに害をもたらしているかどうかを判断できない場合があります。モデルのデータドリフト、公平性/バイアススコアの変化、正確性、堅牢性を継続的に監視します。[品質アラートに対処](https://help.salesforce.com/s/articleView?id=sf.bi_edd_quality_alert.htm&type=5)し、悪影響が特定されたときに迅速に対応するための計画があることを確認します。

以下の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/compliant#倫理基準パターンとアンチパターン)のリストは、Salesforce ソリューション内の適切な(および不十分な)AI 設計を示しています。これらを使用して、構築前に設計を検証したり、システムのリファクタリングが必要な領域を特定したりします。

より倫理的な AI ポリシーを実装するための Salesforce ツールの詳細については、「[Tools Relevant to Be Compliant](/docs/architect/ja-jp/well-architected/guide/compliant#準拠に関連するツール)」を参照してください。

### 倫理基準パターンとアンチパターン

次の表に、組織で検索 (または作成) するパターンと、回避または修正の対象となるアンチパターンの選択を示します。

✨ [パターン & アンチパターンエクスプローラー](/docs/architect/ja-jp/well-architected-tools/guide/trusted-ethical-standards)で、倫理基準のパターンをさらに確認できます。

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">パターン</th>
            <th scope="colgroup">アンチパターン</th>
        </tr>
        <tr>
            <td rowspan="3"><b>会社のポリシー</b></td>
            <td><b>設計基準では、次のようになります。</b>
            <br> - 標準には、会社のポリシーの影響を受ける領域に関する明確な指針が含まれます。</td>
            <td><b>設計基準では、次のようになります。</b>
            <br> - 設計標準が存在しないか、会社のポリシーの対象となる領域に関する明確な指針を提供していない</td>
        </tr>
        <tr>
            <td><b>ドキュメント:</b>
            <br> - 設定およびカスタマイズに関するドキュメントには、サポートされている会社の値への参照が含まれます。</td>
            <td><b>ドキュメント:</b>
            <br> - 設定およびカスタマイズのドキュメントで会社の値やポリシーが参照されていない</td>
        </tr>
        <tr>
            <td><b>組織内：</b>
            <br> - 会社のポリシー関連のコンプライアンスの対象となるすべてのオブジェクトと項目で、[コンプライアンス分類]、[データ所有者]、[データ機密性レベル]、[項目の利用状況] が設定されている</td>
            <td><b>組織内：</b>
            <br> - 会社のポリシー関連のコンプライアンスの対象となるオブジェクトで、コンプライアンス分類、データ所有者、データ機密性レベル、または項目使用状況の設定がない</td>
        </tr>
        <tr>
            <td rowspan="2"><b>人工知能</b></td>
            <td><b>設計基準では、次のようになります。</b>
            <br> - AI アプリケーションのポリシーと承認済み使用事例が明確で見つけやすい
            <br> - RAGで使用するデータとドキュメントが代表的、完全、正確、最新であることを確認します。データセットやドキュメントに存在する可能性のあるバイアス、有害性、その他の有害なコンテンツを探す
            <br> -生成応答により、AI モデルで使用されるデータソースが常に特定される
            <br> - プロンプトエンジニアリングに使用できる/使用できないデータセットが文書化されている
            <br> -ボットと生成 AI 応答がユーザーに明確に識別される
            <br> ・生成 AI の免責事項を使用するタイミングと方法の基準が明確になっている
            <br> - AI ソリューション設計に人間が関与するポイントを文書化する方法に関する明確な要件が存在する
            <br> - AI ソリューション設計の直接および間接フィードバックパスを文書化するための標準が存在する
            <br> - ユーザーにとって AI を識別する必要があるポイントを明確に定義する
            <br> -特に規制や高リスクの使用事例で、ユーザーを指揮する
            </td>
            <td><b>設計基準では、次のようになります。</b>
            <br> -設計標準が存在しないか、AI アプリケーションの明確なポリシーと承認済み使用事例が含まれていない
            <br> -生成応答は、AI モデルで使用されるデータソースを識別しません。
            <br> プロンプトエンジニアリングで使用されるデータセットが文書化されていない
            <br> -ボットと生成 AI 応答がユーザーに識別されない
            <br> -生成応答に関する免責事項がない
            <br> - AI ソリューション設計における人間の関与のポイントを文書化するための要件が存在しない
            <br> -AI ソリューション設計の直接および間接フィードバックパスを文書化するための標準が存在しない
            <br> - AI を識別する必要があるポイントを設計標準で示していない
            </td>
        </tr>
        <tr>
            <td><b>ドキュメント:</b>
            <br> - AI 機能が含まれる設定およびカスタマイズのドキュメントには、すべてのプロセスロジックの詳細な説明が含まれ、法務チームまたは監査人がアクセスできる一元的な場所に保存されます。
            <br> - Salesforce で作成または取り込むモデルは、該当するデータセグメントを含めて明確に文書化されています。
            <br> -会話ロジックとエージェントの会話が徹底的に文書化されている
            <br> -データのドリフト、公平性とバイアススコアの変化、正確性、堅牢性に関する組織のAIモデルを監視するプロセスがある
            <br> - すべての AI プロセスで使用されるトレーニング、評価、テストデータの説明が保持されている
            <br> - AI 関連のデータクリーンアップの説明は、バイアステスト、関連付けられた結果、パフォーマンス/精度スコア (F1 スコアなど) と共に管理されます。</td>
            <td><b>ドキュメント:</b>
            <br> - AI 機能が含まれる設定およびカスタマイズのドキュメントが欠落しているか、不完全であるか、アクセスできない場所に保存されている
            <br> - AI モデルまたはシステムが、モデルのドキュメントを作成せずに組織に実装されている
            <br> - エージェントがメッセージと会話フローの文書化なしで組織に実装されている
            <br> - AI 監視プロセスが存在しないか文書化されていない
            <br> -すべての AI プロセスで使用されるトレーニング、評価、テストデータに関する情報が不明瞭または利用不可
            <br> - AI 関連のデータクリーンアップ、バイアステスト、結果に関する情報が不明瞭または利用不可</td>
        </tr>
    </tbody>
</table>

## アクセシビリティ

テクノロジーにおける*アクセシビリティ*とは、さまざまな能力を持つユーザーにとってのシステムやソリューションの使いやすさを指します。能力に関係なく、すべてのユーザーに対して機能するシステムを設計することが、場所や業種によっては法的に義務付けられています。法的要件だけでなく、アクセス可能なシステムを構築することで、組織は関係者との Trust を促進および強化できます。顧客向けアプリケーションの場合、アクセスしにくい代替ソリューションよりもシステムを使用することを選択する可能性があるため、収益が増加する可能性もあります。

Salesforce では、[アクセシビリティ準拠レポート (](https://www.salesforce.com/company/legal/508_accessibility/)ACR) を公開しています。これは、ソフトウェアがアクセシビリティ標準に準拠する方法の詳細を説明した業界標準のドキュメントです。Lightning Web コンポーネントや Experience Cloud テンプレートなど、UI ベースのコントロールのほとんどは、これらの標準に準拠するように設計されています。ベースラインのアクセシビリティ機能は多くのビジネスで十分かもしれませんが、プロジェクトを開始する前に ACR とリリースノートを確認することが重要です。これにより、製品またはサービスの市場投入アプローチに応じて、当社の標準を超える追加のアクセシビリティ要件を特定して文書化できます。

データ入力とナビゲーションの 2 つの主要な領域に焦点を絞ることで、システムのアクセシビリティを改善できます。

### データエントリ

データ入力活動は、ユーザーが項目、フォーム、またはユーザーインターフェースの別の部分に情報を入力する必要がある場合に実行されます。キーボードとマウスは最も一般的な入力方法ですが、一部のユーザーは音声合成やその他のデバイスを使用している可能性があります。また、ユーザーは異なる言語でコミュニケーションできます。

アクセシビリティを念頭に置いて設計されていないソリューションは、特定の障害を持つ個人をその障害を持つ個人とやりとりすることを除外する可能性があります。

アクセシビリティを設計するときは、次の点を考慮してください。

- **ユーザーの言語**。ビジネスを行う場所に応じて、システムの 1 つの標準言語を設定することも、マルチ言語機能を提供することもできます。複数の言語でテキストを表示する場合、翻訳が必要な項目の表示ラベルとその他の UI 要素 (通知やエラーメッセージなど) のリストを設計標準に含める必要があります。ネイティブスピーカーに翻訳の正確性と意味を確認してもらいます。Salesforce [の翻訳機能](https://help.salesforce.com/s/articleView?id=sf.workbench_overview.htm&type=5)を使用してリアルタイムのメタデータとデータ翻訳を行い、すべてのマルチ言語機能を徹底的にテストします。
- **使用される入力デバイスの種類。**標準キーボードおよびマウス以外のデータ入力に使用できるツールを設計標準にリストします。アクセシビリティテストをテスト計画に含め、すべての入力が複数の種別の入力デバイスでテストされるようにします。
- **フォームの使い**勝手。フォームに表示ラベルが含まれていることを確認し、役に立つエラーメッセージを提供し、完了に向けてユーザーを誘導し、進行状況をユーザーに通知して、ユーザーが入力を確認、確認、編集できるようにします。

次の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/compliant#アクセシビリティパターンとアンチパターン)のリストは、Salesforce ソリューション内のアクセシビリティが適切に (または適切に) 設計されていない場合のデータ入力を示しています。これらを使用して、構築前に設計を検証したり、システム内でリファクタリングが必要な領域を特定したりします。

よりアクセスしやすいデータ入力を作成するための Salesforce ツールについての詳細は、「[Tools Relevant to Be Compliant](/docs/architect/ja-jp/well-architected/guide/compliant#準拠に関連するツール) (準拠に関連するツール)」を参照してください。

### ナビゲーション

ナビゲーションでは、ユーザーが画面間および画面内の項目間でフォーカスを移動します。ユーザーは、視覚、聴覚、触覚を頼りにしながら、クリックやキーストロークなど、さまざまな方法でシステムのさまざまな UI 要素を操作する必要があります。サポートする予定のナビゲーションデバイスのリストが設計標準に含まれていることを確認します。実装チームは、テスト時にこのリストを参照して、すべてのナビゲーションの可能性が考慮されていることを確認する必要があります。

アクセシビリティナビゲーションを設計するときは、次の質問とその回答を考慮してください。

- **ユーザーはソリューションをどのように操作しますか?**標準のキーボードとマウス以外のナビゲーションに使用できるデバイスを設計標準にリストします。
- **ナビゲーションに一貫性がありますか?**ナビゲーションコントロールの設計標準を確立して、システム全体の一貫性を確保します。ナビゲーションパスは、システム全体で類似している必要があります。ある画面の右下に青い \[次へ] ボタンが表示され、次の画面の中央に緑の \[次へ] ボタンが表示されるなど、ナビゲーションが一貫していない場合、一部のユーザーにとってはやや迷惑ですが、障害者にとってはアプリケーションが使用できなくなる可能性があります。
- **テストはアクセシビリティを考慮していますか?**アクセシビリティテストをテスト計画に含め、すべてのナビゲーションフローが複数の種別の入力デバイスでテストされるようにします。
- **キーボードフォーカスが一貫して表示されますか?**キーボードフォーカスの現在の状態を常に視覚的に表示し、キーボードを使用しているユーザーが操作できるようにします。
- **ナビゲーションは色に依存しますか?**情報の表示やアクションの要求に色のみを使用することは避けてください。意味を伝えるための色の適切な使用と適切なレベルのコントラストの適用については、[Web Content Accessibility Guidelines (WCAG) 2.0](https://www.w3.org/TR/WCAG20/#visual-audio-contrast) に準拠します。
- **設計はレビュー済みですか?**定期的なレビューを実施し、ユーザーインターフェースの一貫性が維持され、わかりやすくなっていることを確認します。

以下の[パターンとアンチパターン](/docs/architect/ja-jp/well-architected/guide/compliant#アクセシビリティパターンとアンチパターン)のリストは、Salesforce ソリューション内のアクセシビリティを適切に (または適切に) 設計した場合のナビゲーションを示しています。これらを使用して、構築前に設計を検証したり、システムのリファクタリングが必要な領域を特定したりします。

よりアクセシビリティの高いナビゲーションを作成するための Salesforce ツールについての詳細は、「[Tools Relevant to Be Compliant](/docs/architect/ja-jp/well-architected/guide/compliant#準拠に関連するツール) (準拠に関連するツール)」を参照してください。

### アクセシビリティパターンとアンチパターン

次の表に、組織で検索 (または作成) するパターンと、回避または修正の対象となるアンチパターンの選択を示します。

✨ [パターン & アンチパターンエクスプローラー](/docs/architect/ja-jp/well-architected-tools/guide/trusted-accessibility)でアクセシビリティに関するより多くのパターンを見つけます。

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">パターン</th>
            <th scope="colgroup">アンチパターン</th>
        </tr>
        <tr>
            <td rowspan="3"><b>データエントリ</b></td>
            <td><b>設計基準では、次のようになります。</b>
            <br> - 標準キーボードおよびマウス以外のデータ入力に使用できるすべてのデバイスがリストされます。
            <br> - テキスト値とそのすべてのサポート対象言語への翻訳がリストされます。</td>
            <td><b>設計基準では、次のようになります。</b>
            <br> - 標準キーボードおよびマウス以外のデータ入力に使用できるデバイスの一部のみが表示されるか、まったく表示されないか
            <br> - サポートされる言語が翻訳対象の UI 要素と共にリストされている
            </td>
        </tr>
        <tr>
            <td><b>テスト計画:</b>
            <br> - テストステップには、複数の種別の入力デバイスを使用したデータ入力が含まれます。
            <br> - テストステップに複数言語でのデータ入力が含まれる</td>
            <td><b>テスト計画:</b>
            <br> アクセシビリティテストが含まれていない、またはアクセス可能なデータエントリのテストがアドホックである</td>
        </tr>
        <tr>
            <td><b>組織内：</b>
            <br> -サポートされる言語の翻訳はトランスレーションワークベンチに保存されます。
            </td>
            <td><b>組織内：</b>
            <br> - 翻訳はカスタム表示ラベルに保存される
            </td>
        </tr>
        <tr>
            <td rowspan="2"><b>ナビゲーション</b></td>
            <td><b>設計基準では、次のようになります。</b>
            <br> - (標準のキーボードとマウスだけでなく) ナビゲーションに使用できるすべてのデバイスが明確にリストされている
            <br> - UI/UX 標準では、すべてのナビゲーションコントロールの種別とスタイルを指定します。
            <br> - 意味や状態を伝えるために承認される視覚的な合図の種別が明確にリストされており、色は主要な合図ではない</td>
            <td><b>設計基準では、次のようになります。</b>
            <br> - 設計標準が存在しないか、ナビゲーションコントロールのアクセシビリティ要件を考慮していない
            <br> -ナビゲーションの UI/UX 標準が一貫していない
            <br> - 意味や状態の視覚的な手がかりが色に依存していたり、ビルダー用の視覚的な手がかりの明確なリストがなかったりする</td>
        </tr>
        <tr>
            <td><b>テスト計画:</b>
            <br> - テストステップには、複数の種別の入力デバイスを使用したナビゲーションが含まれます。
            <br> - テスト計画には、UI/UX テストを使用してナビゲーションパスの一貫性を確保することが含まれます。</td>
            <td><b>テスト計画:</b>
            <br> -アクセシビリティテストが含まれていないか、アクセシビリティナビゲーションのテストがアドホックに行われている</td>
        </tr>
    </tbody>
</table>

## 準拠に関連するツール

<table class="tools-table"><tbody><tr><th>ツール</th><th>説明</th><th>法的遵守</th><th>倫理基準</th><th>アクセシビリティ</th></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=ai.copilot_analytics.htm&type=5">Agentforce 分析</a></td><td>エージェントのパフォーマンスに関するインサイトを取得する</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=ai.agent_testing_center.htm&type=5">Agentforceテストセンター</a></td><td>テストごとに最大 1,000 件のテストケースを使用して最大 10 件のテストジョブを実行するため、複数のシナリオをすばやく作成して評価できます。</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=ai.generative_ai_trust_citations.htm&type=5">引用</a></td><td>引用は、生成された回答の潜在的な不正確さや幻覚を特定するのに役立ち、AI ツールの使用に対する信頼性を高めます。</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.236.0.api_rest.meta/api_rest/resources_consent.htm">同意 API</a></td><td>同意を求める顧客設定の追跡</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.consent_event_stream.htm&type=5">同意イベントストリーム</a></td><td>同意または連絡先情報の変更に関する通知を送信する</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.consent_mgmt_fields.htm&type=5">同意管理オブジェクト</a></td><td>顧客のプライバシーと同意設定を管理する</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.data_portability.htm&type=5">データアクセスと可搬性</a></td><td>要求に応じて顧客関連データをエクスポート</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.data_classification_intro.htm&type=5">データ分類</a></td><td>オブジェクト項目の主要なコンプライアンスと監査情報を記録する</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=ai.agent_instruction_adherence_monitor_dc.htm&type=5">Data 360 レポート</a></td><td>エージェントの指示遵守の監視</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.data_deletion.htm&type=5">データ削除</a></td><td>法的規制に準拠するためにデータを削除する</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.individuals_store_data_privacy.htm&type=5">データプライバシー設定</a></td><td>顧客データのプライバシー設定を保存する</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.data_translation.htm&type=5">データ翻訳</a></td><td>ユーザーに表示されるデータを翻訳する</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.einstein_data_detect.htm&type=5">Data Detect</a></td><td>カテゴリと機密レベルを実際のデータに合わせる</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=data.c360_a_data_explorer.htm&type=5">Data 360 Explorer</a></td><td>データサイエンティストのプロジェクトおよびオブジェクト権限の管理</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=ai.generative_ai_prism.htm&type=5">Einstein Data Prism</a></td><td>Salesforce 内の生成 AI アプリケーションのグラウンディングソリューションで、グラウンディング機能を使用する AI ソリューションの精度を向上</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.salesforce.com/artificial-intelligence/trusted-ai/">Einstein Trust Layer</a></td><td>Salesforce エコシステム全体でデータプライバシーを保護し、AI の精度を高め、AI の責任ある使用を促進するために設計された機能、プロセス、ポリシーのコレクション</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=ai.copilot_setup_enhanced_event_logs.htm&type=5">拡張イベントログ</a></td><td>イベントログは、エージェントセッションのイベントとユーザーメッセージを取得して、指示の遵守の確認、エージェントのテスト、トラブルシューティングを行います。</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.collab_files_connect_parent.htm&type=5">Files Connect</a></td><td>Salesforce からの外部ファイルの参照、検索、共有</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=000356459&type=1">Hyperforce</a></td><td>ローカルデータストレージ要件への準拠</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.workbench_metadata_translation.htm&type=5">メタデータ翻訳</a></td><td>言語を翻訳してアプリケーションをローカライズする</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.236.0.api_rest.meta/api_rest/resources_portability.htm">可搬性 API</a></td><td>可搬性ポリシーで識別された顧客データをまとめる</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.preference_center_about.htm&type=5">プリファレンスマネージャー</a></td><td>顧客とのコミュニケーション設定の収集</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.privacy_center.htm&type=5">プライバシーセンター</a></td><td>顧客の要求とデータプライバシー保護法への対応</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.restriction_of_processing.htm&type=5">データ処理の制限</a></td><td>個人データの処理方法の制限</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.rtbf_policies.htm&type=5">忘れられる権利</a></td><td>要求に応じて個々の顧客データを削除する</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.collab_files_overview.htm&type=5">Salesforce Files</a></td><td>ファイルを非公開で共有および保存する</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.security_center.htm&type=5">セキュリティセンター</a></td><td>複数の組織のセキュリティとプライバシーの設定を表示する</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/atlas.en-us.securityImplGuide.meta/securityImplGuide/security_pe_overview.htm">Shield Platform Encryption</a></td><td>保存中および転送中のデータを暗号化</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.workbench.htm&type=5">トランスレーションワークベンチ</a></td><td>メタデータとデータ表示ラベルの翻訳された値を維持する</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col">X</td></tr>
</table>

## 準拠すべきリソース

<table class="tools-table"><tbody><tr><th>リソース</th><th>説明</th><th>法的遵守</th><th>倫理基準</th><th>アクセシビリティ</th></tr>
<tr><td><a href="https://medium.com/p/781b5fd2427">責任あるAI設計の5つの原則</a></td><td>人工知能 (AI) 機能を倫理的に設計する</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/accessibility-basics?trailmix_creator_id=strailhead&trailmix_slug=prepare-for-your-strategy-designer-credential">アクセシビリティの基本 (Trailhead)</a></td><td>アクセシビリティが重要な理由</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://www.salesforce.com/company/legal/508_accessibility/">アクセシビリティ適合性レポート (ACR)</a></td><td>Salesforce がアクセシビリティ標準をどのように満たしているかを理解する</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://www.lightningdesignsystem.com/2e1ef8501/p/112ac5-accessibility">アクセシビリティの概要</a></td><td>Salesforce Lightning 内のアクセシビリティの理解</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://www.salesforceairesearch.com/static/ethics/EthicalAIMaturityModel.pdf">AI倫理成熟度モデル</a></td><td>倫理原則を運用するためのロードマップを作成する</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.salesforce.com/blog/red-teaming-ai/">AI Red Teaming:信頼</a>のテスト</td><td>Salesforce の「倫理的なハッカー」がレッドチーミングを使用して Responsible AI を開発する方法について説明します。</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.salesforce.com/blog/automated-framework-for-red-teaming-ai/">攻撃者の自動化：Red Teaming AI</a>のスケーラブルなフレームワークの設計</td><td>Salesforce で攻撃者のプロンプトの生成と応答の検証を自動化し、有害なコンテンツへの人間の接触を減らしながら AI インタラクションを保護する方法について説明します。</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.bots_service_best_practice.htm&type=5">会話の設計のベストプラクティス</a></td><td>チャットボットを設計するときのベストプラクティスに従う</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/best-practices-for-sustainable-design?trailmix_creator_id=strailhead&trailmix_slug=prepare-for-your-strategy-designer-credential">Best Practices for Sustainable Design (持続可能な設計のベストプラクティス) (Trailhead)</a></td><td>設計に Sustainability を組み込む</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.consent_management.htm&type=5">同意管理</a></td><td>同意およびオプトアウト要求の追跡と遵守</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.aac_manage_data_policies.htm&type=5">Einstein のデータポリシー</a></td><td>Einstein 機能全体のデータ使用の制御</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="/docs/architect/ja-jp/resources/guide/design-standards-template">設計標準テンプレート</a></td><td>組織の設計標準を作成する</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://www.salesforce.com/blog/red-teaming-ai/">信頼できるAI製品の構築に成功したことを証明する倫理的なハッキング プラクティス</a></td><td>Salesforceが<a href="https://www.salesforce.com/blog/red-teaming-ai/">レッド チーミング手法</a>を使用して、悪意のある使用、意図的な整合性攻撃、無害な誤用をテストし、AIの責任ある問題を特定することで、AI製品の安全性を向上させる方法について説明します。</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.salesforce.com/content/dam/web/en_us/www/documents/research/salesforce-research-ethical-leadership-and-business.pdf">倫理的なリーダーシップとビジネス</a></td><td>テクノロジー、平等、倫理に関するインサイト</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.salesforce.com/company/intentional-innovation/ethical-use-policy/">倫理的な使用ポリシー</a></td><td>製品およびサービスの倫理的な使用に関する Salesforce ポリシーの探索</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/ethics-by-design?trailmix_creator_id=strailhead&trailmix_slug=prepare-for-your-strategy-designer-credential">設計による倫理 (Trailhead)</a></td><td>技術開発に倫理デザインを組み込む</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/salesforce-culture-and-values">Salesforce の文化と価値の探索 (Trailhead)</a></td><td>Salesforce のコアバリューの探索</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://developer.salesforce.com/docs/component-library/documentation/en/lwc/mobile_a11y.html">アクセシビリティモバイル設計ガイドラインに従う</a></td><td>ベストプラクティスに従って設計にアクセスできるようにする</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://trailhead.salesforce.com/en/content/learn/trails/get-started-with-web-accessibility">Web アクセシビリティの使用開始 (Trailhead)</a></td><td>Web サイトとアプリケーションをアクセス可能にする方法の基本を学ぶ</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://www.salesforce.com/blog/how-salesforce-builds-reproducible-red-teaming-infrastructure/">Salesforce による再現可能な Red Teaming インフラストラクチャの構築方法</a></td><td>敵対的テストを設計、実装、実行するときに推奨される 4 つのコンポーネント</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://medium.com/salesforce-ux/how-to-run-a-consequence-scanning-workshop-4b14792ea987">結果スキャンワークショップの実行方法</a></td><td>イノベーション時に考えられるすべての結果を考慮する</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.data_protection_and_privacy.htm&type=5">データ保護とプライバシーの実装</a></td><td>データ保護とプライバシーの要件を評価する</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/inclusive-design">包括的な設計 (Trailhead)</a></td><td>包括的な設計原則によるイノベーションの促進</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="/docs/architect/ja-jp/resources/guide/kpi-spreadsheet-template">KPI Spreadsheet Template</a></td><td>組織の重要業績評価指標 (KPI) の設定</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://www.salesforce.com/company/legal/">法律情報</a></td><td>Salesforce の法務情報センターの探索</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://developer.salesforce.com/blogs/2021/09/learn-moar-in-winter-22-with-lwc-cookie-consent-module">LWC Cookie 同意モジュール</a></td><td>Experience Cloud サイトでのユーザーの Cookie アクセスの制御</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.salesforce.com/privacy/overview/">プライバシーの概要</a></td><td>地域および業種ごとのデータプライバシーについて</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/trusted-agentic-ai/promote-responsible-and-ethical-agents">責任ある倫理的なエージェントの促進</a></td><td>倫理的なレッドチーミングおよびテスト戦略を実行し、組織の指針と基準を作成する方法について説明します。</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.salesforce.com/news/stories/responsible-agentic-ai-guidelines/">担当エージェント AI のガイドライン</a></td><td></td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/en/content/learn/modules/responsible-creation-of-artificial-intelligence">「AI Trailhead モジュールの責任ある作成」</a></td><td>データとアルゴリズムからバイアスを取り除き、会社で倫理的な AI システムを構築する方法について説明します。</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.salesforceairesearch.com/trusted-ai">責任ある生成 AI ガイドライン</a></td><td><a href="https://www.salesforceairesearch.com/trusted-ai">信頼できるAI原則</a>に基づいて、生成AIの責任ある開発と実装に焦点を絞った新しいガイドラインのセットが作成されています。</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://compliance.salesforce.com/">Salesforceコンプライアンス認定</a></td><td>Saleforce のコンプライアンス認定と証明を確認する</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/sustainable-design?trailmix_creator_id=strailhead&trailmix_slug=prepare-for-your-strategy-designer-credential">持続可能な設計 (Trailhead)</a></td><td>企業と社会の関係強化</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/testing-for-web-accessibility">Web アクセシビリティのテスト (Trailhead)</a></td><td>自動テストと手動テストを使用してアクセシビリティを確保</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/trusted-agentic-ai">信頼できるエージェント型AI</a></td><td>Agentforceが保護と責任あるAIの原則を使用して倫理的なAIを作成する方法について説明します。</td><td class="check-col"></td><td class="check-col">x</td><td class="check-col"></td></tr>
</table>

## ご意見をお聞かせください

Salesforce Well-Architected の関連性の維持にご協力ください。このコンテンツに関するフィードバックをいただくため[のアンケート](https://sfdc.co/bxNtvh)にご協力ください。また、今後の展望についてもお聞かせください。

<!-- document id=983b2cbad247c3c4fe8feaf17995950da5e82de62ea7688822bd9fb48b04c950 url=/architect/next/ja-jp/well-architected/guides/adaptable-overview.md -->

> 更新スケジュールについては、[こちら](/docs/architect/ja-jp/well-architected/guide/contributors)を参照してください。

## はじめに

**適応可能**な Salesforce ソリューションは、ビジネスに合わせて進化します。**適応可能**に適切に設計されたソリューションは、復元性と構成が可能です。

**耐障害性**のあるソリューションは、変化に適切に対処します。<br>
**コンポーザブル** ソリューションは、迅速かつ高い安定性で調整できます。

ビジネス変革のニーズは、顧客の要求、市場や業界の混乱、デジタル変革のオポチュニティなど、さまざまな要因から生じる可能性があります。変更が小さい場合があります。時には、変化は深刻なものです。最も深刻なレベルでは、変化により、企業は事業を行う主な理由を再考してシフトし、顧客サービスの内容、方法、および場所を再評価する必要があります。**適応可能**なアーキテクチャは、企業の存続と中断からの復旧を支援するだけでなく、重大な変化の時期に企業のイノベーションと成功の可能性を生み出します。

**適応可能**なシステムを作成するには、深く創造的で正確なアーキテクチャ思考が必要です。まず、ビジネスの短期的および長期的な軌跡を正確に理解する必要があります。個々の実装の詳細を評価する場合、複数のディメンションと詳細レベルの影響を考慮する必要があります。人、プロセス、技術の観点から考える必要があります。また、現在の状態と将来の状態に対する影響をマクロレベルとマイクロレベルで同時に予測する必要があります。

次のセクションでは、**適応型**ソリューション アーキテクチャの各コア動作について、より詳細なガイダンスを提供します。

## 適応可能な概要

<table>
<tbody>
        <tr>
            <th scope="colgroup" colspan="3" class="guide-table-roadmap"><a href="/docs/architect/ja-jp/well-architected/guide/resilient">耐障害性</a></th>
        </tr>
        <tr>
        <td colspan="3">レジリエントなソリューションは、変化に適切に対処します。レジリエントなアーキテクチャでは、予測可能な方法で、期待される動作と運用にすばやく戻ることができます。</td>
        </tr>
        <tr>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/ja-jp/well-architected/guide/resilient#アプリケーションライフサイクル管理">アプリケーションライフサイクル管理</th>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/ja-jp/well-architected/guide/resilient#インシデント対応">インシデント対応</th>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/ja-jp/well-architected/guide/resilient#継続性計画">継続性計画</th>
        </tr>
        <tr>
            <td>リリース管理 <br>環境戦略 <br>テスト戦略</td>
            <td>Time to Recover (リカバリ時間) <br>優先順位を付ける機能 <br>監視とアラート</td>
            <td>ビジネス継続性 <br>テクノロジーの継続性</td>
        </tr>
        <tr>
            <th scope="colgroup" colspan="3" class="guide-table-roadmap"><a href="/docs/architect/ja-jp/well-architected/guide/composable">コンポーザブル</a></th>
        </tr>
        <tr>
        <td colspan="3">コンポーザブルなソリューションは、迅速かつ高い安定性で調整できます。コンポーザブルアーキテクチャは、相互に適切に動作するユニットで構築され、サービスの開始と終了を切り替えることができます。</td>
        </tr>
        <tr>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/ja-jp/well-architected/guide/composable#懸念事項の分離">懸念の分離</th>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/ja-jp/well-architected/guide/composable#相互運用性">相互運用性</th>
            <th scope="colgroup" colspan="1"><a href="/docs/architect/ja-jp/well-architected/guide/composable#パッケージ性">パッケージ性</th>
        </tr>
        <tr>
            <td>機能単位 <br>状態管理</td>
            <td>メッセージングとイベント <br>API 管理</td>
            <td>疎結合 <br>連動関係管理</td>
        </tr>
        </tbody>
</table>