Salesforce カスタムオブジェクト完全ガイド：テクニカルアーキテクトによるデータモデリング実践

日付:

背景と応用シナリオ

Salesforceは、商談 (Opportunity) 、取引先 (Account) 、取引先責任者 (Contact) といった、多くのビジネスプロセスに対応する Standard Objects (標準オブジェクト) を標準で備えています。これらは強力で、多くの企業の基本的なCRMニーズを満たすことができます。しかし、企業のビジネスプロセスは千差万別であり、これらの標準オブジェクトだけでは対応しきれない独自のデータ管理要件が存在します。例えば、製造業における機械の管理、医療機関における患者情報の管理、教育機関におけるコースの管理などです。

このような独自のビジネス要件に対応するためにSalesforceが提供する中核的な機能が Custom Objects (カスタムオブジェクト) です。Custom Objectとは、ユーザーが自社のビジネスニーズに合わせて独自に定義できるデータベーステーブルのようなものです。標準オブジェクトと同様に、項目、リレーション、ページレイアウト、セキュリティ設定などを自由に構成でき、Salesforceプラットフォームの自動化機能（FlowやApexトリガなど）やレポーティング機能とシームレスに連携させることができます。

応用シナリオの例：

  • IT資産管理: IT_Asset__c というカスタムオブジェクトを作成し、PC、サーバー、ソフトウェアライセンスなどの情報を管理します。Employee__c（従業員）オブジェクトと参照関係を結び、どの資産が誰に割り当てられているかを追跡します。
  • プロジェクト管理: Project__c オブジェクトを作成してプロジェクトの基本情報を管理し、Task__c オブジェクトを主従関係で紐づけてタスクを管理します。これにより、プロジェクト単位での進捗や工数の集計が容易になります。
  • 不動産管理: Property__c（物件）オブジェクトと Showing__c（内覧）オブジェクトを作成し、物件情報と内覧履歴を関連付けて管理します。

このように、Custom ObjectsはSalesforceを単なるCRMツールから、企業全体のビジネスプロセスを支えるカスタムアプリケーションプラットフォームへと昇華させるための根幹をなす機能です。

原理説明

Custom Objectは、SalesforceのメタデータAPIを通じて定義されるデータ構造です。技術的には、組織のデータベーススキーマに新しいテーブルとして追加されるものと考えることができます。すべてのカスタムオブジェクトは、API参照名として末尾に __c というサフィックスが付与されることで、標準オブジェクトと区別されます。例えば、「Project」という表示ラベルでオブジェクトを作成すると、API参照名は Project__c となります。

Custom Objectは、以下の主要なコンポーネントで構成されます。

1. Fields (項目)

データを格納するカラムに相当します。Custom Objectを作成すると、いくつかの標準項目が自動的に作成されます。

  • Id: 18桁の一意なレコードID。
  • Name: レコード名。テキストまたは自動採番形式を選択できます。
  • OwnerId: レコードの所有者（UserまたはQueue）。
  • CreatedDate / LastModifiedDate: レコードの作成日時と最終更新日時。

これらに加えて、ビジネス要件に応じて Custom Fields (カスタム項目) を追加します。テキスト、数値、日付、選択リスト、数式、チェックボックスなど、多様なデータ型が用意されています。

2. Relationships (リレーション)

オブジェクト間の関連性を定義する重要な機能です。主に2つの種類があります。

  • Lookup Relationship (参照関係): 2つのオブジェクトを緩やかに結合します。親レコードが削除されても、子レコードは削除されません。オブジェクト間に多対1（n:1）の関係を構築する、最も一般的なリレーションです。例えば、Task__c オブジェクトに Project__c への参照項目を作成すると、1つのプロジェクトに複数のタスクが紐づきます。
  • Master-Detail Relationship (主従関係): 2つのオブジェクトを密接に結合します。親（主）レコードが削除されると、子（従）レコードも連動して削除されます（カスケード削除）。子レコードの所有者と共有設定は、親レコードに完全に依存します。主従関係は、親子関係が必須である場合に適しており、積み上げ集計項目（Roll-Up Summary Field）を利用できるという強力なメリットがあります。

3. その他コンポーネント

  • Page Layouts (ページレイアウト): レコード詳細ページの項目の配置や表示/非表示を制御します。
  • Record Types (レコードタイプ): 同じオブジェクトで異なるビジネスプロセスやページレイアウト、選択リスト値を管理するために使用します。
  • Validation Rules (入力規則): レコードが保存される前に、特定のデータ品質基準を満たしているか検証するためのルールを定義します。

これらのコンポーネントを組み合わせることで、柔軟かつ堅牢なデータモデルを構築することが可能になります。

示例コード

ここでは、Project__c というカスタムオブジェクト（項目：Project_Name__c (Text), Status__c (Picklist), Budget__c (Currency)）を操作するApexコードの例を示します。

Apex DMLによるカスタムオブジェクトレコードの作成

以下のコードは、新しいプロジェクトレコードを作成し、データベースに挿入する基本的な例です。DML (Data Manipulation Language) 操作である insert を使用します。

// Project__c というAPI参照名のカスタムオブジェクトの新しいインスタンスを生成
// Apexでは、変数を宣言してメモリ内にオブジェクトの器を用意します。
Project__c newProject = new Project__c();

// 各カスタム項目に値を設定
// API参照名（__cで終わる名前）を使用して項目にアクセスします。
newProject.Project_Name__c = 'Global Website Renewal';
newProject.Status__c = 'Planning'; // 選択リストの値
newProject.Budget__c = 150000;

// try-catchブロックでDML操作を囲むことで、エラーハンドリングを実装
// 例えば、必須項目が空の場合や入力規則違反の場合にDmlExceptionが発生します。
try {
    // DMLステートメント 'insert' を使用して、メモリ上のレコードをデータベースに保存
    insert newProject;
    
    // 成功した場合の処理（例：ログ出力）
    // newProject.Id には、挿入後にSalesforceによって採番された一意のレコードIDが格納されます。
    System.debug('プロジェクトが正常に作成されました。ID: ' + newProject.Id);

} catch (DmlException e) {
    // DML操作でエラーが発生した場合の処理
    System.debug('プロジェクトの作成に失敗しました。エラー: ' + e.getMessage());
}

このコードは、Salesforceの公式ドキュメントにあるDML操作の基本原則に準拠しています。

SOQLによるカスタムオブジェクトレコードの照会

以下のコードは、SOQL (Salesforce Object Query Language) を使用して、特定の条件に一致する Project__c レコードをデータベースから取得する例です。

// SOQLクエリを実行して、特定の条件に一致するプロジェクトレコードのリストを取得
// `Budget__c` が50000より大きいプロジェクトを対象とします。
// SOQLは角括弧 `[]` で囲んでApexコード内に直接記述できます。
try {
    List<Project__c> highBudgetProjects = [
        SELECT Id, Project_Name__c, Status__c, Budget__c, CreatedDate 
        FROM Project__c 
        WHERE Budget__c > 50000 
        ORDER BY CreatedDate DESC
        LIMIT 10
    ];

    // クエリ結果が空でないかチェック
    if (!highBudgetProjects.isEmpty()) {
        // 取得したレコードをループ処理
        for (Project__c proj : highBudgetProjects) {
            System.debug('プロジェクト名: ' + proj.Project_Name__c + ', 予算: ' + proj.Budget__c);
        }
    } else {
        System.debug('条件に一致するプロジェクトは見つかりませんでした。');
    }

} catch (QueryException e) {
    // SOQLクエリでエラーが発生した場合の処理
    // （例：存在しない項目をSELECTしようとした場合など）
    System.debug('プロジェクトの照会に失敗しました。エラー: ' + e.getMessage());
}

このクエリは、カスタムオブジェクト Project__c から、予算が50,000を超えるレコードを最大10件、作成日の降順で取得します。SOQLの構文は、Salesforce Developerドキュメントで定義されている標準的な形式です。

注意事項

カスタムオブジェクトを設計・運用する際には、以下の点に注意する必要があります。

1. 権限と共有設定 (Permissions and Sharing)

カスタムオブジェクトを作成しただけでは、どのユーザーもそのオブジェクトにアクセスできません。アクセスを許可するには、Profile (プロファイル) または Permission Set (権限セット) を通じて、オブジェクトレベルの権限（作成、参照、編集、削除 - CRUD）と、項目レベルのセキュリティ（FLS - Field-Level Security）を明示的に設定する必要があります。セキュリティを無視した設計は、情報漏洩のリスクに直結するため、最も重要な考慮事項の一つです。

2. ガバナ制限 (Governor Limits)

Salesforceはマルチテナント環境であるため、リソースの公平な利用を担保するためのガバナ制限が存在します。カスタムオブジェクトに関連する主な制限は以下の通りです。

  • 組織あたりのカスタムオブジェクト総数: 組織のエディションによって上限が異なります（例: Enterprise Editionでは200個、Unlimited Editionでは2000個）。無計画にオブジェクトを作成すると、将来的な拡張性を損なう可能性があります。
  • トランザクションあたりのDML/SOQL制限: 1つのApexトランザクション内で実行できるSOQLクエリは100回、DML操作は150回までです。ループ内でクエリやDMLを発行すると、容易にこの制限に抵触するため、一括処理（バルク化）を徹底する必要があります。

3. 命名規則 (Naming Conventions)

一貫性のある命名規則を定めることは、開発とメンテナンスの効率を大幅に向上させます。オブジェクト名、項目名、API参照名は、その役割が明確にわかるように命名すべきです。例えば、オブジェクト名は単数形（Project__c）、関連オブジェクトへの参照項目はオブジェクト名（ProjectId__c）とするなど、チーム内でルールを統一することが推奨されます。

4. データモデルの選択 (Lookup vs. Master-Detail)

参照関係と主従関係の選択は、データモデルの根幹を揺るがす重要な決定です。オブジェクト間の関係が永続的で、親なしでは子が意味をなさない場合は主従関係を、それ以外の場合は参照関係を選択するのが一般的です。一度主従関係として作成した項目は、後から参照関係に変更できません（子レコードが存在する場合）。慎重な設計が求められます。

まとめとベストプラクティス

Custom Objectは、Salesforceを企業の固有のニーズに適合させるための最も強力なツールです。その柔軟性により、CRMの枠を超えたあらゆる業務アプリケーションをプラットフォーム上に構築できます。しかし、その力を最大限に引き出すためには、計画的かつ戦略的なアプローチが不可欠です。

以下に、カスタムオブジェクトを活用するためのベストプラクティスをまとめます。

  1. 標準ファーストのアプローチ: 新しいオブジェクトを作成する前に、必ず標準オブジェクトで要件を満たせないか検討してください。標準オブジェクトのカスタム項目やレコードタイプで対応できる場合も多く、その方がSalesforceの標準機能との親和性が高くなります。
  2. データモデルを計画する: いきなりオブジェクトを作成し始めるのではなく、まずER図（エンティティ関連図）などを利用してオブジェクト間の関係性を可視化し、データモデル全体を設計します。どのオブジェクトが主で、どのオブジェクトが従かを明確に定義してください。
  3. 説明を記述する: オブジェクトと項目を作成する際には、必ず「説明 (Description)」欄にその目的や用途を記述してください。このドキュメントは、将来の管理者や開発者にとって非常に価値のある情報となります。
  4. スケーラビリティを考慮する: 将来的に数百万件のレコードが格納される可能性を考慮して設計してください。特に、主従関係や多くの自動化ロジックが絡むオブジェクトでは、大量データ（LDV - Large Data Volumes）によるパフォーマンスへの影響を念頭に置く必要があります。
  5. 再利用性を意識する: 特定の部署やプロセスに特化しすぎたオブジェクトではなく、可能な限り汎用性を持たせた設計を心がけることで、将来的に他の部署でも利用できる資産となります。

結論として、優れたデータモデルの設計こそが、スケーラブルで保守性の高いSalesforceアプリケーションを構築するための鍵です。カスタムオブジェクトを正しく理解し、これらのベストプラクティスを遵守することで、Salesforceプラットフォームの真価を最大限に引き出すことができるでしょう。

コメント

コメントを投稿