Contents
フェーズ別ロードマップ：Salesforce Lightning 移行の6段階
移行は評価→設計→準備→パイロット→本番切替→安定化の6段階で管理すると効果的です。各フェーズで成果物とゲートを明確にし、担当と検証基準を定めることを推奨します。
評価（Assess）
ここでは影響範囲の可視化と優先度決定を行います。
- Readiness Checkの実行とCSV出力
- 主要コンポーネント（VF、Apex、カスタムボタン、統合）の棚卸
- 影響マトリクス作成（業務インパクト、工数見積）
- 高リスク項目をチケット化し優先度付け
設計（Design）
UI/UXと自動化をLightning設計に合わせて調整します。
- レコードページの標準化設計（ダイナミックフォーム等）
- フロー設計書と例外フローの定義
- 統合インターフェースの契約（API仕様、タイムアウト）
- 業務オーナーによる設計承認の取得
準備（Prepare）
Sandboxで再現とテストを行い、デプロイ準備を整えます。
- Full Copyで主要シナリオを再現（可能なら本番と同構成）
- メタデータのバージョン管理（Git）とデプロイ手順確定
- 自動化（Flow/Apex）の単体・負荷テスト実施
パイロット（Pilot）
限定ユーザーで実運用を検証し課題を収束します。
- 対象ユーザーの選定とスケジュール調整
- UATシナリオ実行とフィードバック回収
- 運用ドキュメント・FAQ整備
本番切替（Cutover）
ダウンタイムを最小化し安全に切り替えます。
- 変更フリーズ開始と最終バックアップ取得
- メタデプロイ、旧自動化の段階的無効化と新Flowの有効化
- スモークテストと主要統合の確認
安定化（Stabilize）
運用を監視し継続的改善を実施します。
- 日次モニタリングで初期問題を早期検出
- パフォーマンス最適化と残件の優先度化
- 利用促進施策とユーザー教育の継続
役割とRACI（例）
役割と責任を明確にした上で進めると意思決定が速くなります。
下は簡易サンプルで、プロジェクト規模に応じて拡張してください。
| 役割 | 評価 | 設計 | 準備 | パイロット | 本番 | 安定化 |
|---|---|---|---|---|---|---|
| プロジェクトマネージャー (A) | A | A | A | A | A | A |
| 業務オーナー (A/R) | C | C | C | R | C | C |
| Salesforce 管理者 (R) | R | R | R | R | R | R |
| 開発者 (R) | C | R | R | C | C | C |
| QA / テスター (C/R) | C | C | R | R | C | R |
| 統合担当 (C/R) | C | C | R | C | R | C |
| サポートリード (I) | I | I | C | R | R | R |
R：実行責任者、A：最終責任者（承認）、C：相談先、I：通知先。
推奨追加ステークホルダー：セキュリティ／コンプライアンス担当、データチーム、Change Manager、ベンダー担当。
Readiness Check と移行準備状況の実務的な活用
Transition AssistantのReadiness Checkは有用な出発点ですが、検出範囲に限界があります。自動レポートをCSVで取り出し、Metadata APIやSFDXで取得したデータと突合して業務側と合意する運用を作ることを推奨します。
実行前準備
実行前に本番とSandboxの準備や権限を整えます。
- 実行は読み取り専用だが、結果は業務確認が必要になる点を共有する
- Full Copy Sandboxを用意し、再現検証の計画を立てる
- Readiness Check結果のCSVエクスポート保存先を決める
Readiness Check の実行手順（実務）
UIでの実行に加えSFDXでメタデータを取得して検証します。
- Setup → Transition Assistant → Check Readiness を実行し、CSVをダウンロードする。
- CSVを影響チーム別にインポートしタグ付けする。
- SFDX/Metadata APIでメタ情報を取得し、自動検出と突合する。
SFDXを併用したメタデータ取得の例（要認証設定）:
|
1 2 3 4 5 6 7 |
# package.xml を用いて Metadata API から取得 sfdx force:mdapi:retrieve -k ./package.xml -r ./mdapi_output -u PROD_ALIAS -w 10 unzip ./mdapi_output/unpackaged.zip -d ./mdapi_output # mdapi 形式をソース形式に変換 sfdx force:mdapi:convert -r ./mdapi_output -d ./force-app/main/default |
または manifest を使って直接ソースを取得する方法:
|
1 2 |
sfdx force:source:retrieve -x manifest/package.xml -u PROD_ALIAS -r ./backup |
Readiness Check CSV テンプレート（サンプル）
以下は影響マトリクス用のCSVテンプレート例です。チームで共有して編集します。
|
1 2 3 4 5 6 |
MetadataType,FullName,Label,Location,OwnerTeam,Priority,EstimatedHours,RecommendedAction,Notes CustomButton,Account.MyJSButton,My Button,Account Page,Sales,High,8,Convert to Screen Flow,JS依存を確認 ApexClass,OrderProcessor,Order Processor,Apex,Integration,High,16,Review for API version,外部連携の確認必要 Visualforce,OpportunityVF,Oppty VF,Opportunity Page,Sales,Medium,24,Rebuild as LWC,DOM操作あり Flow,AccountAutoAssign,Auto Assign Flow,Flow,Sales Ops,High,12,Review bulk behavior,バルク対応要 |
Readiness Check の限界と手作業検証項目
自動検出で見落としがちな点を事前に列挙します。
- Visualforce内のDOM操作や外部スクリプトの依存関係は検出されにくい
- JavaScriptボタンのロジック（画面遷移＋一括処理）
- 管理パッケージのLightning対応状況はベンダー確認が必要
- 特定の統合（OAuthリフレッシュ、IP制限）の挙動変化
公式ドキュメント（参考）
- Move to Lightning Experience（Transition Assistant） — https://help.salesforce.com/s/articleView?id=move_to_lightning_experience.htm&type=5 （確認日: 2026-05-20）
- SFDX CLI リファレンス — https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli.meta/sfdx_cli/ （確認日: 2026-05-20）
- Metadata API ガイド — https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/ （確認日: 2026-05-20）
影響範囲の棚卸と移行パターン（CSVテンプレート付き）
正確な棚卸が移行計画の核になります。自動検出結果とメタデータを突合し、業務オーナーと合意した影響マトリクスを最終成果物とします。
チェック対象一覧
代表的な棚卸対象項目を示します。
- UI: レコードページ、コンパクトレイアウト、Lightning Record Pages
- ボタン/リンク: カスタムボタン（JavaScript、URL）
- Visualforce / Apex: APIバージョン、DOM依存、標準コントローラの使用
- 自動化: Workflow、Process Builder、既存Flow、Apexバッチ
- レポート/ダッシュボード: フォルダ共有、改修必要性
- パッケージ/AppExchange: ベンダー対応状況
- 統合: 外部API、ミドルウェア、コネクタ
- 権限・共有: プロファイル、権限セット、FLS、共有ルール
影響マトリクス CSV テンプレート（実例）
チーム間でやり取りしやすいCSV例を再掲します。上流でこれを埋めてチケット化します。
|
1 2 3 4 5 |
MetadataType,FullName,Label,Location,OwnerTeam,Priority,EstimatedHours,DeploymentPath,ReplacementPattern,Notes CustomButton,Account.EditAndAssign,Edit & Assign,Account Page,Sales,High,12,SFDX,Screen Flow + Invocable Apex,複数レコード対応要 ApexClass,InvoiceBatchProcess,Invoice Batch,Apex,Finance,High,40,Git/CI,Refactor to Queueable,バッチ時間監視 Visualforce,CaseQuickEntry,Case Quick Entry,Case Page,Support,Medium,20,LWC,Rebuild as LWC,外部JS参照 |
Classic固有要素別の移行パターン
要素ごとに移行方針と注意点を示します。
JavaScriptボタン（置換方針）
画面操作＋ロジックはScreen FlowやLWC＋Invocable Apexで代替することを推奨します。
- 単純URL遷移：URLボタンまたは標準アクションで代替
- フォーム処理や検証：Screen Flowで画面化し必要に応じてApexを呼び出す
- 大量更新：Batch/Queueable Apexで非同期処理に切替
Visualforceの扱い
表示のみであればLightningに埋め込めますが、DOM操作が多い場合はLWC/Auraでの再実装を推奨します。互換性検証は手作業で行ってください。
AppExchange / マネージドパッケージ
ベンダーにLightning対応版の有無を確認します。未対応の場合は代替機能またはカスタム開発の見積もりを行います。
自動化移行（Workflow/Process Builder→Flow）とレコードページ設計
自動化は業務に直結するため段階的かつ検証重視で移行することが重要です。変換ツールは補助的に使い、変換後は必ず手作業でレビューしてください。
移行の優先順位付けと標準手順
移行は影響度と停止リスクで優先順位付けします。
- 全自動化の棚卸（条件・例外・トリガー頻度）
- クリティカルな自動化を優先して設計・テスト（例: 支払通知）
- SandboxでFlowを再現しバルクデータで負荷検証
- 旧Processを無効化→新Flowを有効化の段階切替を実施
Flow設計の注意点（バルク／エラーハンドリング）
Flowは柔軟ですがガバナ制限を意識して設計します。
- before-save Flowで簡易な値セットを使いDMLを削減する
- 大量処理はバッチ化や分割処理で対応する
- Fault経路を必ず実装し、ログオブジェクトへ記録する
- 再試行・ロールバック方針を定義する
Invocable Apex サンプル
Flowから呼び出す簡易的なInvocableクラスの例です。実運用では例外処理やリトライを追加してください。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
public with sharing class FlowAccountUpdater { public class Request { @InvocableVariable(required=true) public Id accountId; @InvocableVariable public String newValue; } public class Result { @InvocableVariable public Boolean success; public Result(Boolean s) { success = s; } } @InvocableMethod(label='Update Accounts' description='Update account field from Flow') public static List<Result> updateAccounts(List<Request> requests) { List<Account> toUpdate = new List<Account>(); for(Request r : requests) { Account a = new Account(Id = r.accountId); a.Custom_Field__c = r.newValue; toUpdate.add(a); } if (!toUpdate.isEmpty()) { update toUpdate; // バルク考慮: 呼び出し側でサイズ管理を行うこと } List<Result> results = new List<Result>(); for(Integer i=0;i<requests.size();i++) results.add(new Result(true)); return results; } } |
注意：Invocableメソッドはバルクで呼ばれるため、処理量とガバナを考慮することが必要です。
Process Builder 変換ツールの取り扱いに関する注意
Salesforceの変換ツールでProcessをFlowに変換できますが、動作やパフォーマンスの差が出る場合があります。変換後は必ず手動レビューとバルクテストを行ってください。公式ドキュメントでツールの挙動を確認することを推奨します（確認日付きリンクは参考資料参照）。
テスト計画、KPIとCI/CDの自動化例
テスト計画は合格基準を数値で定義し、自動化を導入して再現性を確保します。テストデータの保護は法令に配慮して行ってください。
テスト種別と合格基準（数値例）
代表的な合格基準と目安を示します。組織により調整してください。
- UAT合格率：95%以上を目標とすることを推奨
- 許容エラー件数（スモーク期間）：重大エラーは0、主要処理は1件以内/時間が目安
- ページ応答：主要レコードページの95パーセンタイル <= 2.5秒
- バッチ処理：想定実行時間の変動幅 < 10%
- APIエラー率：1%未満が目安（負荷試験で確認）
テストデータ作成とマスキング方針
Full Copy Sandboxの利用時は個人情報保護が必要です。以下の方針を参考にしてください。
- PIIフィールドの特定とドキュメント化
- Salesforce Data Mask等の専用ツール導入を検討する（公式参照）
- マスキング要件：ユニーク性の保持、参照整合性の担保、再識別キーの別保管
- マッピング表は暗号化して限定保管する（再現性が必要なテスト用）
参考ドキュメント：Salesforce Data Mask — https://help.salesforce.com/s/articleView?id=data_mask_overview.htm&type=5 （確認日: 2026-05-20）
CI/CD と自動デプロイの実務例（SFDX / GitHub Actions）
デプロイを自動化してレビューとテストを組み合わせます。概略ワークフロー：Pull Request → CIで静的チェック／ユニットテスト実行 → ステージングへデプロイ → 承認後本番デプロイ。
代表的なコマンド例:
|
1 2 3 4 5 6 7 8 9 10 |
# JWT認証でCIからOrgへログイン（事前に設定） sfdx auth:jwt:grant -i $SF_CLIENT_ID -u $SF_USERNAME -f assets/server.key -r https://login.salesforce.com # ソースをメタAPI形式に変換してデプロイ sfdx force:source:convert -r force-app -d mdapi_output sfdx force:mdapi:deploy -d mdapi_output -u $SF_USERNAME -w 60 # Apexテストを実行 sfdx force:apex:test:run -u $SF_USERNAME -r human -c |
GitHub Actionsの簡易スニペット（概念）:
|
1 2 3 4 5 6 7 8 9 10 11 |
jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - run: npm install sfdx-cli --global - run: sfdx auth:jwt:grant -i $SF_CLIENT_ID -u $SF_USERNAME -f assets/server.key - run: sfdx force:source:convert -r force-app -d mdapi_output - run: sfdx force:mdapi:deploy -d mdapi_output -u $SF_USERNAME -w 60 - run: sfdx force:apex:test:run -u $SF_USERNAME -r human -c |
認証情報や鍵の管理はセキュアな方法（GitHub SecretsやVault）を利用してください。
カットオーバー／ロールバックおよび安定化の実務チェックリスト
カットオーバーは事前準備とロールバック手順の検証が鍵です。ロールバックは本番での即時無条件実行が難しい場面もあるため、事前にSandboxで検証した手順を用意します。
詳細カットオーバーチェックリスト
以下は実務で使える詳細手順です。実環境に合わせて順序や対象を調整してください。
- 切替ウィンドウと影響範囲をステークホルダーへ最終周知
- 変更フリーズ開始時刻の設定と周知
- メタデータの最終スナップショット取得（SFDX/MDAPI）
- 重要データのエクスポート（SOQL→CSV、Data Export）
- インテグレーションの一時停止またはポーリング停止指示
- 本番デプロイ実行（CI/CDまたはSFDX）
- 自動化の段階的切替（旧Process無効化→Flow有効化）
- スモークテスト（ログイン、主要レコード作成、統合確認）
- 監視ログとエラージャーナルの初期チェック（Apex例外、Flowエラー）
- 問題収束後、切替完了連絡と運用サポート開始
印刷用短縮チェックリスト
短時間で確認するための最小項目です。切替直前のチェックに使ってください。
- 変更フリーズ有効か
- メタデータ/データのスナップショット取得済みか
- 主要統合が停止/待機状態か
- デプロイ成功、スモークテスト合格か
- サポート連絡先とエスカレーション経路が機能するか
ロールバック基準とメタデータ／データのスナップショット手順
ロールバック基準は事前に定義し、関係者が合意しておきます。例：
- 主要業務が完全に停止し手動回避が不可能な場合
- 重要データの欠損が短時間で復旧不可能な場合
- 統合に致命的なエラーが発生し業務継続が不可と判断された場合
メタデータのスナップショット取得例:
|
1 2 3 4 |
# package.xml を用いてメタデータを取得 sfdx force:mdapi:retrieve -k ./package.xml -r ./backup -u PROD_ALIAS -w 10 unzip ./backup/unpackaged.zip -d ./backup/unpackaged |
メタデータ復旧（リストア）例:
|
1 2 3 |
# mdapi 形式でデプロイ sfdx force:mdapi:deploy -d ./backup/unpackaged -u PROD_ALIAS -w 60 |
データのスナップショットと復元（例）:
|
1 2 3 4 5 6 |
# データエクスポート（CSV） sfdx force:data:soql:query -q "SELECT Id, Name, Email FROM Contact" -u PROD_ALIAS -r csv > contacts_backup.csv # 復元（bulk upsert / upsert には Id を使用） sfdx force:data:bulk:upsert -s Contact -f contacts_backup.csv -u PROD_ALIAS -i Id |
注意点：Full Copyの差し戻しは通常即時実行できないため、必要なデータのみを抽出してリストアする手順を事前に検証してください。Lightning無効化はメタデータ差分や権限差異が残る可能性があるため、単純なロールバック方法としては万能ではありません。
移行後のモニタリングと改善
初期は日次、それ以降は週次で主要指標を確認します。
- モニタリング指標：ページロード時間、Flowエラー数、Apex例外、APIエラー、未解決チケット数
- レポート頻度：初期 7日間は日次、8〜30日は週次、その後は運用方針に応じて調整
- ユーザーフィードバックの記録と優先度付けを行い、継続リリースを計画
まとめ
段階化した評価・設計・準備・パイロット・本番切替・安定化の流れで進めると移行リスクが低減します。Readiness Checkは出発点として有効ですが、SFDXやMetadata APIでの突合、影響マトリクスCSV、Flow/Apexの実装サンプルによる実務検証を併用すると安全性が向上します。テスト基準やデータマスキング、メタデータ/データのスナップショット手順を事前に合意し、ロールバック手順をSandboxで検証してください。
参考資料（公式ドキュメント）
- Move to Lightning Experience（Transition Assistant / Readiness Check） — https://help.salesforce.com/s/articleView?id=move_to_lightning_experience.htm&type=5 （確認日: 2026-05-20）
- Migrate Process Builder to Flow（変換ツール） — https://help.salesforce.com/s/articleView?id=sf.flow_migrate_from_process_builder.htm&type=5 （確認日: 2026-05-20）
- Salesforce Flow ベストプラクティス（開発者向け） — https://developer.salesforce.com/docs/atlas.en-us.flow.meta/flow/flow_best_practices.htm （確認日: 2026-05-20）
- SFDX CLI リファレンス — https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli.meta/sfdx_cli/ （確認日: 2026-05-20）
- Metadata API ガイド — https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/ （確認日: 2026-05-20）
- Salesforce Data Mask（Sandbox のデータ保護） — https://help.salesforce.com/s/articleView?id=data_mask_overview.htm&type=5 （確認日: 2026-05-20）
（注）Salesforce のツールや制限はリリースで変更されることがあります。主要な操作前に上記公式ドキュメントを再確認することを推奨します。