Salesforce無料トライアルとDeveloper Editionの違いと設定手順

Salesforce 無料トライアルと Developer Edition の概要と使い分け

Salesforce 無料トライアル 設定方法 ステップバイステップを求める導入担当者向けに、申込から初期設定、検証ポイントまで実務的に整理します。
Salesforce 無料トライアル 設定方法 ステップバイステップで実行できる手順と注意点を具体的に示します。

公式トライアルの特徴

公式トライアルは短期間で製品の機能や操作感を確認するための評価環境です。地域や製品により試用条件が異なるため、申込ページで条件を必ず確認してください。

• 目的：Sales Cloud（営業支援）、Service Cloud（カスタマーサポート）、Salesforce Platform（プラットフォーム）などの主要機能を短期で評価すること。
• 入手性：製品ページの「今すぐ無料で試す」「無料トライアルを開始（Start free trial）」等のCTAから申込します。クレジットカードの要否は地域・プロモーションにより異なるため、申込ページの注意書きを確認してください。
• 利用期間・機能：試用期間や利用できる機能は製品やキャンペーンで変わります。正式な条件は各製品ページで確認してください（下記リンク参照）。
• 参考リンク（製品別トライアル例）：
• Sales Cloud（営業支援）: https://www.salesforce.com/jp/products/sales-cloud/free-trial/
• Service Cloud（サービス）: https://www.salesforce.com/jp/products/service-cloud/free-trial/
• Salesforce Platform（プラットフォーム）: https://www.salesforce.com/jp/products/platform/free-trial/

Developer Edition の目的と特徴

Developer Edition（開発者用エディション）は、個人やチームの開発・学習・PoC に適した永続的な無料 org です。プロダクションの代替ではなく検証用として使います。

• 目的：Apex、Lightning コンポーネント、API連携の開発やトライアル、Trailhead演習用。組織のクローンではないため本番データは含まれません。
• 制限：ストレージ、API コール、同時接続などの制限があります。最新の制限値は公式ドキュメントで確認してください（例: App Limits Cheat Sheet）。
• 参照（制限確認）: https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform.htm
• 入手先：Developer Edition 登録ページ https://developer.salesforce.com/signup

申込前の前提条件：必要な権限、推奨ブラウザ、準備すべき組織情報

申込前に整えておくと初期検証がスムーズです。ここでは管理者目線で最低限準備すべき項目を挙げます。

必要な権限とアカウント設計

初期運用に備えて管理体制を決めます。管理者アカウントの運用方針が後の作業効率に影響します。

• 管理者：System Administrator 権限を持つアカウントを最低1名は確保します。可能ならバックアップ管理者を1名用意します。
• 登録メール：トライアル申込や Developer 登録には有効なメールアドレスが必要です。Developer のユーザー名はメール形式で Salesforce 全体でユニークである必要があります（例: [メールアドレス削除] のように工夫）。
• 権限設計：最小権限の原則を意識してプロファイルと権限セットの設計方針をあらかじめ決めます。

推奨ブラウザとネットワーク設定

ブラウザやネットワーク制限で動作しないことがあります。事前確認で手戻りを減らします。

• 推奨ブラウザ：最新の Google Chrome、Microsoft Edge、Safari を推奨します。Internet Explorer はサポート外です。
• ネットワーク：アウトバウンドで *.salesforce.com への HTTPS(443) が許可されていることを確認します。プロキシやファイアウォールで API やコールバックが遮断されないよう設定します。
• SSO/IdP：シングルサインオンを試す場合は SAML 設定情報（Entity ID、ACS URL、証明書）を事前に用意します。

事前に準備すべき組織情報

初期設定で入力する組織情報を揃えておくと速度が上がります。

• 会社名、業務メールのドメイン、タイムゾーン、ロケール、デフォルト通貨
• 会計年度（Fiscal Year）と営業時間（Business Hours）
• ユーザー数の想定、主要業務フロー（商談・ケースなど）の概要
• 連携予定の外部システムと API 要件、メール送信ドメイン（SPF/DKIM）設定の有無

Sandbox と Developer Edition の違いと実務での使い分け

検証環境は目的によって最適な選択が異なります。Sandbox と Developer Edition の性質を理解して使い分けます。

Sandbox とは

Sandbox は本番組織のコピーを作れる環境で、下記のような用途に向きます。

• 特徴：本番のメタデータや（種類によっては）データを複製してテストできます。種類によりリフレッシュ間隔やデータ容量が変わります（Developer Sandbox、Partial Copy、Full Sandbox など）。
• 用途：UAT（ユーザー受入試験）、本番に近い統合テスト、大規模な変更検証。
• 注意：Sandbox は本番ライセンスに依存するため、すべてのエディションで利用できるわけではありません。Sandbox の詳細は公式ドキュメントを参照してください。
• 参照（Sandbox概要）: https://help.salesforce.com/s/articleView?id=sf.sandbox_overview.htm&type=5

Developer Edition とは

Developer Edition は独立した無料 org で、個人やチームの開発用に最適です。

• 特徴：永続的に利用可能ですがリソース制限があります。プロダクションのクローンではなく、サンプルデータや小規模の検証に向きます。
• 用途：Apex 開発、Lightning コンポーネント作成、Trailhead 学習、個別機能の PoC。

使い分けの具体例

検証の目的別に選択例を示します。

• 案件例1（短期機能評価）：Sales Cloud の操作感確認は公式トライアルで十分。
• 案件例2（API・開発検証）：Apex や API の挙動確認は Developer Edition を用意して継続的に使う。
• 案件例3（本番に近い統合テスト）：本番と同様のデータ量・外部連携を検証する場合は Partial Copy / Full Sandbox を使用する。

公式トライアルと Developer Edition の申し込み手順（具体的なステップと所要時間目安）

実務で即着手できるよう、申込から初回ログインまでの手順を明示します。各手順は想定所要時間の目安を記載します。

製品別トライアルの申込手順（Sales Cloud / Service Cloud / Platform 等）

ここでは一般的な公式トライアルの流れを示します。想定所要時間は 5〜15 分です。

1. 製品のトライアルページにアクセスする（例）:
2. Sales Cloud: https://www.salesforce.com/jp/products/sales-cloud/free-trial/
3. Service Cloud: https://www.salesforce.com/jp/products/service-cloud/free-trial/
4. Platform: https://www.salesforce.com/jp/products/platform/free-trial/
5. ページ上の CTA（例: 「今すぐ無料で試す」「無料トライアルを開始」「Start free trial」）をクリックする。
6. 申込フォームに必要事項を入力する。典型的な入力項目は次の通りです。
7. 会社名（Company）、業務メール（Work Email）、氏名（First/Last）、役職（Job Title）、電話（Phone）、従業員数（Employees）
8. 送信後、登録メールが届くか確認する。メール内のリンクからアカウントを有効化して初回ログインする。
9. 初回ログイン時にパスワード設定、プロフィール設定、トレーニング案内やサンプルデータのインストール選択が表示されることがあります。

注意点：

• クレジットカードの要否は地域や製品で異なります。申込ページの条件を確認してください。
• トライアルの有効期間や利用可能機能は製品ページで確認してください。

Developer Edition の登録手順（想定所要時間 5〜10 分）

Developer Edition は個別登録が必要です。ユーザー名は Salesforce 全体でユニークなメール形式である必要があります。

1. 開始ページにアクセスする: https://developer.salesforce.com/signup
2. 必要事項を入力する。主な項目は氏名、メール、ユーザー名（例: [メールアドレス削除]）、会社名、国、職種などです。
3. 登録後、確認メールが届きます。メール内のリンクをクリックして初回ログインし、パスワードを設定します。
4. 初回ログイン後、Setup（歯車アイコン）から環境を確認します。

実務Tips：

• ユーザー名が既に使われている場合は「+dev」や日付を付与してユニークにします。
• Developer Edition は永続的に使えますが、リソース制限を確認しておきます（リンク参照）。

申込後に確認すべき事項と想定所要時間

初回ログイン後、以下を確認します。想定所要時間は初期チェックで合計 30〜90 分見積もりです。

• 組織情報（Company Information）: Setup > Company Settings > Company Information
• ライセンス数と種類の確認: Setup > Company Settings > Company Information（User Licenses）
• 管理者アカウントの存在と連絡手段の確認
• Deliverability 設定や Org-Wide Email 設定の初期確認

初回ログイン後の管理者向け初期設定（セキュリティ／ユーザー／組織情報）

初回ログイン直後に優先すべき設定を手順で示します。セキュリティ変更は段階的に展開してください。

組織情報と基本設定

最初に組織の基礎値を確定します。操作は Setup 画面の検索で該当項目を探すと早いです。

• 組織情報の確認：Setup > Company Settings > Company Information で会社名、デフォルト通貨、ロケール、タイムゾーンを設定します。
• 会計年度と営業時間：Setup で「Fiscal Year」「Business Hours」を検索して設定します。レポート等に影響します。
• ユーザー作成：Setup > Users > Users > New User で管理者や代表ユーザーを追加します。必要項目は氏名、メール、ユーザー名、プロファイル、ライセンスです。
• プロファイルと権限セット：プロファイルで基本権限を与え、追加権限は権限セットで付与する方針を推奨します。

セキュリティの初期設定（MFA・パスワード・IP制限）

セキュリティは早めに整備しますが、全社一斉適用はリスクがあるため段階的に実施します。

• MFA の段階的導入：
• 手順例：まず管理者で検証用ユーザーに適用し、次にパイロットユーザーに権限セットで付与、最終的に全社へ展開します。
• 権限セットで MFA を要求する方法や、Identity Center / Authentication Configurationを使った設定があります。小規模なテストを必ず実施してください。
• 予備措置：ブレークグラス用の緊急管理者アカウントを最小限で用意し、資格情報は安全なパスワードマネージャーで管理します。ブレークグラスアカウントの運用はログ管理と監査を必ず行ってください。
• パスワードポリシー：Setup > Security > Password Policies で有効期限や複雑性を設定します。段階的に強化してください。
• IP 制限・ログイン時間：重要アカウントは Profiles > Login IP Ranges や Login Hours を設定して制限します。
• 監査ログ：Setup > Monitoring > Login History、Setup Audit Trail でログ確認方法を理解します。Event Monitoring は追加ライセンスが必要です。

運用上の注意：

• 本番組織での設定変更は、まず Sandbox や Developer Edition で検証します。
• MFA や IP 制限はユーザーのロックアウトを招く恐れがあるため、テストユーザーとリカバリ手順を確立してから適用します。

バックアップとリカバリ手順

データ運用の安全策を決めておきます。

• 定期バックアップ：初期段階でデータエクスポート（Setup > Data > Data Export）や定期ジョブによるバックアップ方針を決めます。
• リカバリ手順：管理者がパスワードリセットやユーザーロック解除を行う手順書を作成します。ブレークグラス使用時の監査も必須です。

データ移行・自動化・レポートと試用中の評価チェックリスト

ここではデータ取り込み、Flow による自動化、レポート作成の実務手順と検証ポイントを示します。各ツールの使い分けとデバッグ方法を明確にします。

データ移行の準備とツールの使い分け

CSV の準備と適切なツール選択が成功の鍵です。下準備とサンプルを示します。

• CSV 準備の基本：
• 文字コード：UTF-8（BOMなし）を推奨します。日本語を含む場合は必ず UTF-8 で保存します。
• 日付形式：ISO 形式（YYYY-MM-DD）を推奨します。日時はタイムゾーンに注意してください。
• 区切り：カンマ区切り（,）。数値は小数点にドット（.）を使用します。
• 外部ID の設定例：
• 例：Account オブジェクトに External_Id__c（Text, External ID）を作成する。
• CSV 例：ParentExternalId, Name, Industry
  • 例行:
  • 12345, 株式会社A, Technology
  • 67890, 株式会社B, Manufacturing

CSV サンプル（最小例）:

• Data Import Wizard の使いどころ：
• 用途：少量〜中量のデータ取り込みに適します。関係が単純なオブジェクトや Upsert（外部ID を使った更新）に便利です。
• 実行方法：Setup > Data > Data Import Wizard（クイック検索で「Data Import Wizard」）から対象オブジェクトを選択し、CSV をアップロードしてマッピングします。
• 注意：大量データや複雑な参照関係は処理が困難な場合があります。
• Data Loader の使いどころ：
• 用途：大量データ（数万レコード以上）、複雑な参照、添付ファイルの取り込み、コマンドライン自動化に向きます。
• ダウンロードと接続：Data Loader はデスクトップアプリです。Setup 内の Data Loader ダウンロードページまたは公式ヘルプから取得します（https://help.salesforce.com で「Data Loader」を検索）。
• 接続方法：標準はユーザー名＋パスワード＋セキュリティトークン、または OAuth 接続を使用します。
• エラー対応：
• エラーファイルを必ず確認し、必須項目不足、ピックリスト不一致、重複ルール、検証ルールによる拒否を修正します。

参考ドキュメント：

• Data Import Wizard: https://help.salesforce.com/s/articleView?id=sf.importing_using_the_dataimportwizard.htm&type=5
• Data Loader: https://help.salesforce.com/s/articleView?id=sf.data_loader.htm&type=5

Flow（Record-Triggered Flow）の設計・デバッグ・移行

自動化には Flow（フロー）を推奨します。設計と検証の手順を明確にします。

• Before-save と After-save の使い分け：
• Before-save（レコード保存前）: 単純なフィールド更新に最適で高速です。
• After-save（保存後）: 関連レコード作成や外部呼び出し、メール送信に使います。
• Record-Triggered Flow の作成手順（概略）：
• Setup > Process Automation > Flows（または Setup の検索で「Flows」）を開く。
• [New Flow] → [Record-Triggered Flow] を選択。
• オブジェクトとトリガー条件（作成・更新・削除、条件）を指定し、Before/After を選ぶ。
• 要素（Assignment、Create Records、Update Records、Action）を配置してロジックを組む。
• デバッグとテスト：
• Flow Builder の [Debug] 機能で実行パスを確認します。レコードID を入力して既存レコードでデバッグできます。
• Fault 経路を設定してエラー発生時のログ出力や通知を作成します。
• テストケースを用意し、複数のデータパターンで動作を確認します（特にバルク処理時の動作）。
• バージョン管理と移行：
• Flow はバージョン管理が可能です。変更は新バージョンとして公開し、既存バージョンとの切替を管理します。
• 既存の Process Builder／Workflow からの移行は段階的に行います。公式の移行ガイドや「Migrate to Flow」ツールを参照し、並行稼働期間を設けて検証してください。
• トラブル回避：
• 無限ループや再帰を避けるため、条件チェックや処理フラグを設けます。
• 大量レコード更新ではバルク対応を意識し、可能なら Before-save を検討します。

参考（Flow の概要）: https://help.salesforce.com/s/articleView?id=sf.flow_overview.htm&type=5

レポート・ダッシュボード作成と試用評価チェックリスト

レポートとダッシュボードで主要 KPI を可視化し、導入可否を判断します。評価チェックリストも示します。

• 営業パイプラインレポートの作成手順（概略）：
• App Launcher から「Reports」へ移動し [New Report]（新規レポート）を選択。
• Report Type で「Opportunities（商談）」を選ぶ。
• Group Rows に Stage を設定し、金額で集計する。Close Date や Owner でフィルターを設定して保存します。
• ダッシュボード作成のポイント：
• コンポーネントは目的に応じて選択（Gauge、Line Chart、Metric、Table）。
• ダッシュボードフォルダの共有設定とスケジュール実行を確認します。
• 試用評価のチェックリスト（代表項目）：
• 機能適合性：主要業務フローが再現可能か。
• 運用性：管理者や現場での操作性はどうか。
• データ移行性：既存データの取り込み、クレンジング要否。
• セキュリティ：MFA、アクセス制御、監査ログの要件達成度。
• 拡張性／連携：API、AppExchange、SaaS 連携の可否。

• コスト：ライセンス費用、導入工数、運用コストを概算する。

• よくあるトラブルと解決の糸口：

• ログイン・MFA 関連：管理者によるユーザーのロック解除、パスワードリセット、ログイン履歴確認。
• 権限エラー：プロフィール、権限セット、フィールドレベルセキュリティを確認。
• インポート失敗：エラーファイルを解析し必須項目・ピックリスト・検証ルールを見直す。

参照先（公式ページと確認項目）

以下は申込や制限確認で優先的に参照する公式ページと、各リンク先で確認すべき項目です。

• Sales Cloud 無料トライアル: https://www.salesforce.com/jp/products/sales-cloud/free-trial/
• 確認項目：試用期間、機能制限、CTA ボタン名、クレジットカード要否
• Service Cloud 無料トライアル: https://www.salesforce.com/jp/products/service-cloud/free-trial/
• 確認項目：ケース管理機能、Service Console の利用可否、サンプルデータの有無
• Platform 無料トライアル: https://www.salesforce.com/jp/products/platform/free-trial/
• 確認項目：API 利用可否、Apex 実行環境、外部連携の制限
• Developer Edition 登録ページ: https://developer.salesforce.com/signup
• 確認項目：メールの受信、ユーザー名のユニーク要件、初期ログイン手順
• Org リソース制限（App Limits Cheat Sheet）: https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform.htm
• 確認項目：ストレージ、API コール、同時実行やレート制限の最新値

まとめ（要点）

• 目的に応じて公式トライアル（短期評価）と Developer Edition（開発・継続検証）を使い分ける。
• 申込前に権限、推奨ブラウザ、組織情報を準備しておくと初期検証が早く進む。
• Sandbox は本番クローン検証、Developer Edition は個別の開発・学習向け。用途で選ぶ。
• 初回は組織情報、管理者確保、MFA の段階的導入、パスワードポリシーを優先設定する。
• データ移行は CSV の文字コード・日付形式・外部ID を整備し、Data Import Wizard と Data Loader を使い分ける。
• Flow のデバッグ、バージョン管理、Process Builder からの移行は段階的に実施し、Fault ハンドリングを組み込む。
• 試用評価は機能適合性、運用性、データ移行性、セキュリティ、拡張性、コストで判断する。