Access から Salesforce Platform への移行 2026：CRM/SFA連携で営業×バックオフィスを統合する戦略
目次 クリックで開く
本記事の親ピラー（包括ガイド）
本記事は Aurant Technologies の Access移行 親ピラーガイドを支えるクラスター記事です。
Salesforce が Access の移行先候補として浮上するのは、業務領域が顧客管理・営業管理・案件管理に集中しているケース。Salesforce Platform（Force.com 後継）を使うことで、CRM/SFA の標準機能と業務カスタムの両方を統合できる。本稿は、Access から Salesforce Platform への移行で押さえるべき設計判断を整理する。
1. Salesforce Platform とは何か
Salesforce は CRM/SFA から始まったが、Salesforce Platform はその基盤レイヤーをカスタムアプリ開発プラットフォームとして提供している。Access のような独立 DB アプリを Salesforce 上で構築できる。
- カスタムオブジェクト：Access のテーブル相当。標準オブジェクト（Account・Contact・Opportunity 等）と並べて自由に作成。
- カスタム項目：Access のフィールド相当。テキスト・数値・日付・選択リスト等。
- リレーション：Access の外部キー相当。Master-Detail / Lookup の 2 種類。
- Lightning App Builder：Access のフォーム相当。ドラッグ&ドロップで UI 構築。
- Flow Builder：Access のマクロ相当。ノーコードでワークフロー実装。
- Apex：Access の VBA 相当。Java ライクなプログラミング言語で複雑なロジック実装。
2. Access から Salesforce へ振り切れるかは業務の性質で決まる
Salesforce が Access の代替として現実的に勝負になるのは、業務の中心が顧客・営業・案件の周辺にあって、なおかつ営業活動の可視化と分析を本気で強化したい場合です。既存の Access が顧客カルテ・商談記録・問合せ管理のような CRM/SFA 的な業務を抱えているなら、データモデルそのものが Salesforce の標準オブジェクト（Account・Contact・Opportunity・Case）に寄せやすく、移行で得られる効果も大きくなります。さらに Marketing Cloud・Service Cloud・Pardot などのエコシステムと将来的に統合することを視野に入れているなら、Platform レベルで先に基盤を作っておく意味も出てきます。業務プロセスを Salesforce のベストプラクティス（リード→商談→契約→更新の流れ）に乗せ替えられるかも判断材料です。
逆に、Salesforce を選ぶと割高・遠回りになりやすいのが、業務が顧客と無関係な領域に集中している場合です。社内資産管理・社内タスク管理・施設予約のような業務は、kintone や Microsoft Lists、Power Apps のほうがライセンスコストとUIの両面で合理的です。Salesforce のライセンス単価は kintone・Power Apps と比べて高く、特に Platform Plus 以上を選ぶ場合は年間予算の見積もりが事業判断に直結します。また、Access 固有の複雑な VBA ロジックをそのまま Apex に書き換えようとすると、機能的には可能でも実装工数が想定を大きく超える場合があり、ノーコード（Flow）で再設計したほうが結果的に保守も楽になることが多いです。業務部門が既に Salesforce の UI に慣れていない場合は、定着のための教育投資も含めて意思決定する必要があります。
3. Salesforce Platform のライセンス体系
| ライセンス | 月額（参考） | 用途 |
|---|---|---|
| Sales Cloud Enterprise | $165 / ユーザ | 営業 CRM/SFA 中核 |
| Service Cloud Enterprise | $165 / ユーザ | カスタマーサービス・サポート |
| Platform Starter | $25 / ユーザ | シンプルなカスタムアプリ（限定機能） |
| Platform Plus | $100 / ユーザ | 本格的なカスタムアプリ開発 |
| Salesforce Inbox / Einstein 等のアドオン | 個別 | 機能拡張 |
Salesforce のライセンス費用は kintone・Power Apps と比べて高い。年間予算の見積もりは慎重に。中小企業では Platform Starter（$25）から始めて、機能要件に応じてアップグレードする段階的アプローチが現実的。
4. Access の機能と Salesforce の対応
| Access | Salesforce |
|---|---|
| テーブル | カスタムオブジェクト |
| フィールド | カスタム項目 |
| リレーション | Master-Detail / Lookup |
| クエリ | SOQL（Salesforce Object Query Language） |
| フォーム | Lightning Page（App Builder） |
| レポート | Salesforce Reports / Tableau CRM |
| マクロ・ワークフロー | Flow Builder |
| VBA | Apex |
| 権限 | プロファイル + ロール + ペルミッションセット |
表4の対応関係は概念マップで、実装では「1:1に写せない箇所」が必ず出る。Accessから持ち込んだとき詰まりやすい構成要素を、Salesforce側の具体的な実装手段と注意点で整理する。
| Access側で使っている構成要素 | Salesforceでの実装手段 | 1:1で写せない箇所と実装メモ |
|---|---|---|
| オートナンバー型主キー | 自動採番項目＋外部ID項目の二段持ち | Salesforceの自動採番は文字列で、レコード作成時に新規採番される。旧主キー値を関連テーブルの結合に使っていた場合、別途 Text(Unique, External ID) 項目を作り旧採番をそこに保持。Data Loaderの upsert キーは新採番ではなくこの外部IDを指定する。 |
| 参照整合性・連鎖削除／連鎖更新 | Master-Detail または Lookup（削除挙動を選択） | 連鎖削除を再現したいなら Master-Detail。子を残したい場合は Lookup にして「親削除時に Lookup 項目をクリア」か「親の削除を制限」を選ぶ。連鎖更新は SF にないため、結合キーは元から不変の外部ID参照に置き換える設計が前提。 |
| 選択クエリ・パラメータクエリ（JOIN込み） | レポートタイプ／リストビュー／SOQL | 2階層程度の親子JOINはカスタムレポートタイプで再現でき、パラメータ部分はレポートのフィルタ「実行時編集可」に変換。3階層以上の結合や FULL OUTER JOIN はSOQL/レポート単体では再現できず、Apex の集約クエリか BI ツール側へ寄せる。 |
| 更新クエリ・追加クエリ・削除クエリ | スケジュールFlow または Apex バッチ | 件数が数千件以下で条件が静的ならスケジュールFlowで十分。10,000 件超のバッチ更新やトランザクション制御が要る処理は Apex Batch（governor limit 回避のためチャンク処理）。Access の UPDATE 文をそのまま貼れないので、対象オブジェクトと条件を Flow の分岐で再設計する。 |
| マクロ（AutoExec／OnOpen 等） | ログインフロー／スケジュールFlow／レコードトリガFlow | AutoExec の前処理はログインフローまたはスケジュールFlow へ。フォームのOnOpen/OnCurrentで動かしていた表示制御は、Lightningレコードページの動的フォーム（表示ルール）に分離する。VBAを呼んでいたマクロは VBA 側の判断（下記）に従う。 |
| VBAモジュール（業務ロジック） | Flow／Apex／Lightning Web Component を機能で切り分け | 条件分岐＋単一オブジェクトのレコード操作のみなら Flow。複数オブジェクトのトランザクション制御・例外処理・1万件超のループは Apex。画面側で動的なUI（連動ピックリスト・段階入力ウィザード等）が要るものは LWC。DAO/ADO の SQL 呼び出しは SOQL/DML に翻訳する。 |
| 添付ファイル型フィールド（Attachment） | Salesforce Files（ContentDocument ＋ ContentDocumentLink） | 1レコードに複数ファイル添付がある場合、SF では Files を別オブジェクトとして移行し ContentDocumentLink で親レコードに関連付ける。旧 Notes & Attachments ではなく現行 Files を使う。Data Loader での投入は ContentVersion → ContentDocumentLink の二段挿入。 |
| メモ型／リッチテキストフィールド | ロングテキストエリア／リッチテキストエリア | ロングテキストエリアは1項目あたり最大 131,072 文字、リッチテキストも同上で許可されるHTMLタグが限定的。Access側で Word から書式付き貼り付けが蓄積しているケースは、事前にプレーンテキスト化＆文字数で超過行を抽出して個別対応する。 |
| 複合主キー（複数列での一意制約） | 数式項目で連結 → 外部ID＋Unique | SF は単一フィールドの Unique 制約のみ。数式項目で「項目A & ‘-‘ & 項目B」を作り、外部ID＋Unique を付けて upsert キーに使う。空欄混入で重複が発生しないよう、空欄不可のバリデーションルールも併設する。 |
| ハイパーリンク型／OLEオブジェクト型 | URL項目／Files（OLE は移行非推奨） | ハイパーリンク型は URL 項目に。OLE オブジェクト型（埋め込みExcel・画像等）は SF に対応する型がなく、抽出して個別ファイル化したうえで Files として再添付する。バイナリのまま移行は不可。 |
5. データ移行の実務
- Salesforce 環境のセットアップ：Sandbox 環境を作成。本番環境への直接インポートは厳禁。
- カスタムオブジェクト・項目の設計：Access のテーブル構造を Salesforce のオブジェクト構造に変換。命名規則・項目型の対応。
- マスタデータの移行：Account（取引先）・Contact（取引先責任者）・カスタムオブジェクトのデータを Data Loader / DataLoader.io 経由でインポート。
- トランザクションデータの移行：Opportunity（商談）・Activity（活動）・カスタムオブジェクトのトランザクション。リレーション ID の事前マッピングが必須。
- Sandbox での検証：データ整合性・リレーション正確性の確認。本番環境への移行リハーサル。
- 本番カットオーバー：本番データ移行・ユーザ受入テスト・運用開始。
6. Salesforce 移行プロジェクトで実際に時間がかかる場面
Access から Salesforce への移行は、Sandbox を作って Data Loader でデータを流せば動くこと自体は数週間で可能ですが、本番運用に乗せるまでに本当に時間がかかるのは別の3つの工程です。最初に詰まりやすいのが、要件定義とライセンス選定の判断です。Salesforce は Sales Cloud Enterprise・Service Cloud・Platform Plus などライセンスごとに使える機能と単価が大きく違い、自社の業務に対して Platform Plus で十分なのか、Sales Cloud まで必要なのかの判断を、業務領域とユーザー単価の両面で詰めていく作業が、技術選定よりも先に走ります。
次に時間を要するのが、カスタムオブジェクト・項目設計とデータ移行設計です。Access のテーブル構造をそのまま写すのではなく、Salesforce の標準オブジェクトと組み合わせた新しいデータモデルに再設計します。前章で扱った旧主キーの外部ID化、リレーション挙動の選定、複合主キーの数式項目化、添付ファイルの Files 移行などは、それぞれ個別に検証と Sandbox での試行が必要で、ここを甘く見積もるとカットオーバー直前にデータ整合性の問題が顕在化します。
最後に、本番カットオーバーとユーザートレーニングが実は最も注意の必要な工程です。Access のフォームに慣れた現場ユーザーが、Lightning Experience の画面と Flow の動きに切り替わることに慣れるための教育、本番データ移行のリハーサルとリスク管理、運用開始後の問い合わせ対応体制の整備が、ここでまとめて走ります。本番運用が安定してから、ようやく Sales Cloud・Service Cloud との統合や Marketing Cloud・MA との連携といった拡張に踏み込む段階に入ります。技術的な構築よりも、運用の定着と段階拡張のほうがプロジェクトの実時間を消費するため、ライセンス選定の段階で「いきなりフル機能を狙わない」判断ができると、プロジェクト全体の見通しが立てやすくなります。
Access移行の進め方に迷ったら ― 無料の「移行診断・セカンドオピニオン」
現行 Access の棚卸しから、kintone・Power Apps・Salesforce など移行先の選定、VBA資産の引き継ぎ、IT導入補助金の活用可否までを実装視点で無料診断します。すでにベンダーから提案を受けている場合のセカンドオピニオン（その見積り・移行方式が妥当か）にも対応します。診断のみのご利用も歓迎です。
関連ピラー
Access から Salesforce Platform へ移行して CRM/SFA 基盤が整った後、Claude を Apex や Flow に組み込んで商談支援や顧客分析を自動化する段階では、Account・Opportunity・Case のどのオブジェクト・項目を AI に参照させるかのプロファイルとパーミッションセットの設計が Salesforce ガバナンスの核心になります。Salesforce 環境への Claude 統合の PoC の進め方は Claude Code 導入支援 で設計からご支援します。
Salesforce活用・営業DXとデータ連携のご相談
Salesforceの定着支援や営業プロセスの可視化、基幹・会計システムとのデータ連携までをまとめて支援します。現在の設定や連携方式が最適かを確認したい、という導入前後のセカンドオピニオンにも対応しています。
CRM・営業支援
Salesforce・HubSpot・kintoneの選定から導入・カスタマイズ・定着まで一貫対応。営業生産性を高め、商談化率を改善します。