Salesforce Platform

Salesforce Platformを選ぶ理由

Salesforce Platformの最大の特徴は、アプリケーションが「どこで」動作するかという点にあります。空のデータベースから始めて、ID管理、認証、ワークフロー、監査、API、管理レイヤーを個別に組み立てるのではなく、チームはすでにSalesforceで運用されているデータモデルと管理コントロールの上にアプリケーションを構築できます。

この利点は、取引先、連絡先、商談、ケース、サービスプロセス、パートナー関係など、確立されたSalesforceのドメインと連携するアプリケーションを構築する場合に最も顕著になります。カスタムアプリケーションは、顧客データの独自の解釈を維持するのではなく、組織の他の部分と同じ権限設定、自動化、レポート、レコード履歴を共有できます。

現在のSalesforceのウェブサイトでは、この基盤を「Headless 360」や「Agentforce 360」という位置づけで紹介することが増えています。開発者、管理者、購入者、および既存のドキュメントでは引き続き「Salesforce Platform」という名称が使われているため、検討や導入の過程で両方の名称が使われる場合があります。

このプラットフォームはメタデータ駆動型です。オブジェクト、項目、レイアウト、入力規則、自動化、権限、コンポーネント、そしてアプリケーション設定の多くが、デプロイ可能なメタデータとして表現されます。これにより、管理者がビジュアルツールでプロセスを設定し、開発者がその同じプロセスをコードで拡張してメタデータをソース管理にコミットするという、共通の運用モデルが実現します。

基本的なワークフロー

導入を成功させるには、通常、インターフェースの設計よりもドメインモデリングから開始します。要件を既存の標準オブジェクトに含めるか、カスタムオブジェクトが必要か、あるいは外部システムに置くべきかを判断します。適切な標準モデルを再利用することで、レポート、自動化、パッケージアプリ、および将来のSalesforceリリースとの互換性が一般的に向上します。

セキュリティはデータモデルと同時に設計する必要があります。オブジェクトへのアクセス、項目の可視性、レコードの共有、所有権、ロール、権限セットは、その後のほぼすべての決定に影響します。UIを構築した後にこれらのコントロールを後付けしようとすると、多大な手戻りが発生する可能性があり、レポートや統合、自動化、生成AIの回答を通じてデータが露出するリスクも生じます。

その後、宣言的（ノーコード/ローコード）なアプローチを優先して開発を進めます。単純なフォーム、承認、レコード更新、通知、ガイド付きプロセスなどは、通常、ビジュアルツールで保守する方が容易です。Apexやカスタムコンポーネントは、ロジックがトランザクション処理を伴う場合、計算が複雑な場合、複数のエントリポイントで再利用する場合、またはビジュアルな自動化では安全に表現しにくい場合に適しています。

プロフェッショナルな開発においては、標準的なソフトウェアライフサイクルに従うべきです。メタデータをプロジェクトに取り込み、Gitでレビューし、テスト環境で検証してから、管理された環境を経て本番へ反映します。ブラウザベースのビルダーは試作や管理には便利ですが、本番環境への変更は、文書化されていない個別の組織での手動編集に頼るべきではありません。

最適なユースケース

Salesforce Platformは、レコードが定義されたビジネスプロセスに従って移動する業務アプリケーションに特に適しています。例として、オンボーディング、承認ワークフロー、アカウントプランニング、パートナー管理、現場検査、顧客エスカレーション、コンプライアンスレビュー、契約の引き継ぎ、社内申請システムなどが挙げられます。

また、既存のSalesforce環境の拡張にも効果的です。サービス部門のスーパーバイザー向けの専用コンソール、商談データと連携したパートナーポータル、現場従業員向けのモバイルワークフローなどが必要な場合、これらを同じプラットフォーム上に保つことで、データの同期ロジックを削減し、既存のアクセスモデルを維持できます。

一方で、大量のトランザクションが発生する一般消費者向けサービス、メディア処理、科学計算、リアルタイムのマルチプレイヤーシステム、または制限のないバックグラウンド実行を必要とするワークロードには、あまり向いていません。一般的なアーキテクチャでは、ビジネスプロセスと管理されたレコードをSalesforceに置き、重い計算、ストリーミング、または特殊なインフラを必要とする部分は、APIやイベントで接続された外部サービスに委ねます。

この境界線は重要です。Salesforceをすべてのワークロードのランタイムとして扱うと、コードが複雑になり、マルチテナントの制限（ガバナ制限）に常に直面することになります。逆に、単なるパッシブなCRMとして扱うと、ワークフローやメタデータシステムの価値を無駄にしてしまいます。実用的な中間解は、顧客に関連するオーケストレーションをSalesforceの近くに保ち、インフラ負荷の高い作業は専用に設計されたサービスに任せることです。

実践的なAI支援開発

Agentforce Vibesは、Salesforce開発にAIネイティブなパスを導入します。変更の計画や生成時に、組織のスキーマ、メタデータ、コードパターン、プロジェクトの指示をコンテキストとして利用できます。これは、Apexの構文は知っていても、ターゲット組織に存在しない項目やオブジェクト、権限を勝手に作り出してしまう汎用的なコード生成AIよりも有用です。

最も信頼できるワークフローは、すぐにプロジェクトの修正を依頼するのではなく、計画から始めることです。その計画で、影響を受けるメタデータ、セキュリティの変更、データアクセスパス、サーバーサイドロジック、インターフェースコンポーネント、テスト、およびデプロイの依存関係を特定します。開発者はエージェントにコードを生成させる前に、提案された構成を確認できます。

生成されたApexは、人間が書いたコードと同様のレビューが必要です。テストでは、大量レコードの一括処理、エラー時の挙動、共有ルール、項目レベルセキュリティ、コールアウト、非同期実行、およびガバナ制限の消費をカバーする必要があります。生成されたコンポーネントについては、アクセシビリティ、安全なデータアクセス、読み込み状態、および現実的なレコード量での挙動を確認してください。

AI支援は、繰り返しの多いメタデータ作成、初期テストの雛形作成、コンポーネント構造、ドキュメント作成、および大規模な組織内でのナビゲーションに特に価値があります。ただし、トランザクションの境界、セキュリティの適用、デプロイ順序、または共有された自動化を変更することの影響を理解する必要性がなくなるわけではありません。

また、SalesforceはBYOLLM（自前LLMの持ち込み）接続を通じて、外部でホストされた言語モデルをサポートしています。これにより、モデルプロバイダーや商用契約の選択肢が増えますが、ローカルでのオフライン推論とは異なる点に注意してください。接続されたモデルには、引き続きアクセス可能なホストされたエンドポイント、適切な認証情報、監視、および承認されたデータ処理設計が必要です。

競合ツールとの比較

Microsoft Power Appsは、Microsoft 365、Dataverse、Dynamics 365、Azure、Teamsを中心とする組織にとって最も近い比較対象です。ID、ドキュメント、コラボレーション、ビジネスデータがすでにMicrosoftのエコシステムにある場合、Power Appsが組織的な優位性を持つことが多いです。対して、顧客レコード、サービスプロセス、収益ワークフロー、パートナー業務がすでにSalesforceにある場合は、Salesforce Platformが同様の優位性を持ちます。

ServiceNow App Engineは、ITサービス管理、運用、従業員サービス、およびServiceNowの構成データベース（CMDB）を中心としたエンタープライズワークフローに適しています。顧客向けや収益に関連するプロセスにはSalesforceが、ITや社内サービスの提供にはServiceNowがより強力な運用の中心となるのが一般的です。

MendixやOutSystemsは、特定のCRMデータモデルに密接に縛られない、より広範なローコードアプリケーションプラットフォームです。多様なアプリケーションポートフォリオやカスタムなユーザー体験に対して、より高い柔軟性を提供する場合があります。Salesforceは、自社のビジネスデータ、セキュリティ、自動化、およびアプリケーションマーケットプレイス（AppExchange）へのより深いネイティブアクセスを提供します。

Appianは、プロセスのオーケストレーション、ケース管理、およびドキュメント中心のワークフローで頻繁に比較されます。選択の決め手は、主要な要件が多くのシステムにまたがるプロセスプラットフォームなのか、それともSalesforceの顧客・権限モデル内で直接動作すべきアプリケーションなのかという点にあります。

Oracle APEXは、Oracle Databaseの深い専門知識を持ち、SQL中心のアプリケーションを構築するチームにとって魅力的です。Salesforceのメタデータ、イベント、オブジェクト、Apexアーキテクチャとは異なる開発モデルを提供します。この選択においては、機能の比較よりも、既存のデータの所有場所がどこであるかの方が重要になることが多いです。

推奨される構成

カスタマイズが大規模になる前に、ソース管理を確立する必要があります。管理者が実装の多くを行う場合でも、重要なメタデータはリポジトリと反復可能な検証プロセスを経るべきです。これにより、変更履歴が提供され、環境間の差異が可視化され、唯一のシステム記録として特定の本番組織に依存するリスクが軽減されます。

大規模な導入では、ドメイン境界を設けることが有益です。すべてのチームが区別のない一つのメタデータセットを修正するのではなく、ビジネス機能ごとにコンポーネント、自動化、権限、コードをグループ化します。パッケージベースの開発を導入することで、所有権とデプロイを明確にできますが、高度にカスタマイズされた組織に後からパッケージを導入するには慎重な計画が必要です。

権限セットに主要な機能アクセス権を持たせ、プロファイルは実用的な最小限のベースラインとして維持すべきです。これにより、アクセス権の構成が柔軟になり、監査も容易になります。また、大規模な組織では数千の項目、フロー、クラス、コンポーネント、権限アーティファクトが蓄積されるため、命名規則の策定も同様に重要です。

Flow（フロー）かApexかを選択するための明確なポリシーを定めてください。ビジュアルな自動化が常に単純であると決めつけず、トランザクションの複雑さ、再利用性、テスト、エラーハンドリング、レコード量、および所有権を考慮します。十分にテストされた少量のコードの方が、重なり合った複数のフローよりも安全な場合もありますが、管理者による日常的な変更であれば、カスタムApexを作成するまでもないかもしれません。

本番データを不用意に開発環境にコピーしないでください。実装の機密性に応じて、代表的なテストデータ、マスキング、または管理されたシーディングプロセスを使用します。AI開発ツールを利用する場合は、どのデータやメタデータがコンテキストとして使用されるかを文書化する新たな理由となります。

AIによって生成された変更も、他の変更と同様にプルリクエスト、静的解析、自動テスト、セキュリティレビュー、およびデプロイ管理を通すべきです。実験段階では自動承認設定も便利ですが、エージェントがメタデータの修正、コマンドの実行、または接続された組織との対話を行う場合は、保守的な設定にするべきです。

ガバナンスの対象はユーザーライセンスだけではありません。APIの消費量、自動化の実行量、ストレージ、外部ログイン、Data 360の利用状況、Agentforceのアクション、接続されたモデルのコストを監視してください。プロトタイプ段階では安価に見えても、本番のトラフィックを処理し始めるとコスト構造が変わる可能性があります。

移行に関する注意点

スプレッドシート、レガシーCRM、またはカスタムデータベースからの移行は、データの所有権の整理とプロセスの合理化から始まります。すべての過去の項目をインポートし、古いワークフローをすべて再現しようとすると、保守性の高いSalesforceアプリではなく、単に高価になった旧システムのコピーが出来上がるだけです。

データ移行には明確な読み込み順序が必要です。親レコード、参照データ、ユーザー、所有権、多対多のリレーション、活動、ファイル、および依存するトランザクションには、それぞれ異なる要件がある場合があります。安定した外部IDを使用することでプロセスを反復可能にし、テスト移行中のSalesforce生成レコードIDへの依存を減らします。

初期データロード中は、通常、自動化を無効にするか慎重に制御する必要があります。そうしないと、インポートによって通知が送信されたり、重複レコードが作成されたり、予期せずデータが再計算されたり、外部システムが呼び出されたりする可能性があります。移行計画では、どの検証や自動化を過去データに適用し、どれを稼働後のみに適用するかを定義する必要があります。

既存のSalesforceユーザーは、Classicインターフェース、レガシーなVisualforce、ワークリール、プロセスビルダー、または管理されていない本番環境での変更から、Lightningコンポーネント、Flow、ソース駆動型開発、および最新のパッケージングへの移行という、異なる課題に直面するかもしれません。これは一度にすべてを書き換えるのではなく、ビジネスドメインごとに段階的に進めるべきです。

アプリケーションのポータビリティ（移植性）には制限があります。レコードやメタデータはエクスポート可能ですが、Apex、Flowの定義、Lightningコンポーネント、権限モデル、およびパッケージ化された依存関係は、他のプラットフォームで直接実行することはできません。無関係なワークロードや代替不可能なビジネスロジックをSalesforce内だけに配置する前に、このアーキテクチャ上のコミットメントを認識しておく必要があります。

運用上のトレードオフ

Salesforceのマルチテナントランタイムは、実行制限（ガバナ制限）を適用することで共有インフラを保護しています。開発者は、大量データに対応した安全なトランザクションを設計し、繰り返しのデータベース操作を避け、非同期処理を制御し、一つのトランザクション内で複数の自動化がどのように組み合わさるかを理解する必要があります。これらの制約は規律を高めることにもつながりますが、従来のサーバー環境出身の開発者が学習すべき概念が増えることにもなります。

多くのチームが重複する変更を行うことを許可すると、管理上の柔軟性がガバナンスの問題を引き起こす可能性があります。ある部門にとっては局所的な項目やフローに見えても、実際には統合、レポート、エージェント、パッケージアプリに影響を与えている場合があります。組織が成長するにつれて、明確な所有権、依存関係分析、リリース調整、および廃止手順がますます重要になります。

プラットフォームのリリースサイクルにも継続的なメンテナンスが必要です。Salesforceは一般的に互換性を維持しますが、季節ごとのリリース、APIの廃止スケジュール、ブラウザの変更、管理パッケージの更新には依然としてテストが必要です。プレビュー用のサンドボックスや自動化された回帰テストを活用することで、本番環境が新リリースに移行した後に不具合を発見するリスクを軽減できます。

したがって、Salesforce Platformは単なるアプリ構築ツールとしてではなく、運用モデルとして評価されるべきです。このテクノロジーが最も効果を発揮するのは、組織がメタデータ、アクセス権、リリース、データ品質、ライセンス、およびビジネス上の所有権を、長期的なエンタープライズシステムとして管理する準備ができている場合です。