LASSIC Media らしくメディア
Salesforce保守で頼む4つの作業と保守会社の選び方
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- Salesforceの保守は、設定変更、年3回のリリースへの対応、ユーザーと権限の管理、連携の監視の4つに分けられます。
- リリースへの対応は、本番の4〜6週間前に先に更新されるSandboxで、自社の設定が動くかを確かめる作業が中心です。
- 頼み先は社内の管理者・導入した会社・保守専門の会社の3つで、費用は作業の量と払い方、対応の時間帯で決まります。
※ 本記事は2026年10月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
導入したSalesforceの設定を、いつのまにか誰も触れなくなっている。新しいリリースのたびに画面が変わり、利用者から聞かれても答えられない——。Salesforceを入れて数年たった会社では、こうした困りごとが起こりがちです。Salesforceの保守とは、稼働したあとの環境を、業務の変化と年3回のリリースに合わせて手入れし続ける作業のことです。
保守は社内の管理者だけで回せる場合もあれば、導入した会社や保守を専門に受ける会社に頼む場合もあります。ただし、どの頼み先にも向く場面と向かない場面があります。本記事では、Salesforceの保守を任された情報システムの担当者に向けて、保守で頼む4つの作業、年3回のリリースへの対応、頼み先の違いと費用の決まり方、そして外部に頼むときに確認したい点を整理します。
目次
Salesforceの保守とは
Salesforceはクラウドのサービスで、年に3回、Spring・Summer・Winterのリリースで新しい機能を出し、各社の環境を自動でアップグレードしています。*1 そのため保守は、自社が作り込んだ設定とデータの手入れが中心です。保守の対象になるのは、主に次のものです。
- 項目・画面・入力規則など、自社の業務に合わせて作り込んだ設定
- フロー（画面の操作で作る自動処理）や、Apex（Salesforce上で動くプログラム）
- 利用者のアカウントと、誰がどのデータを見られるかを決める権限
- 基幹システムや会計システムなど、外部のシステムとのデータ連携
導入の段階の作業（要件の整理・初期設定・データ移行）は、Salesforce導入支援の範囲と支援会社の選び方で扱っています。本記事は稼働したあとの保守運用に絞ります。
保守で頼む4つの作業
保守で頼む作業は会社ごとに違いますが、次の4つに分けて考えると、社内に残す作業と頼む作業を決めやすくなります。
| 作業 | 主な中身 | 発生する時期 |
|---|---|---|
| 設定変更 | 項目や画面の追加、入力規則・フロー・レポートの修正 | 業務や組織の変更があったとき |
| リリースへの対応 | リリースノートの確認、テスト用の環境での事前確認、利用者への案内 | 年3回 |
| ユーザーと権限の管理 | 入社・異動・退職に合わせたアカウントの追加・凍結・無効化と権限の見直し | 人の出入りがあるたび |
| 連携の監視 | 外部システムとのデータ連携の失敗と、APIの使用量の確認 | 日々の運用の中で継続して |
見落としやすいのは、ユーザーと権限の管理です。Salesforceのユーザーは削除できないため、退職した人は無効化します。不正なアクセスが疑われるときや、無効化の前に後片づけが要るときは、先に凍結してログインを止めます。*4 権限は、最小限のプロファイル（利用者の基本設定）を割り当て、権限セット（仕事に必要な権限をまとめた設定）で追加するやり方が勧められています。*4
連携の監視では、API（システム同士をつなぐ窓口）の使用量に気を配ります。Salesforceは直近24時間に実行できるAPIの呼び出しの数に上限を設けており、残りの数は設定の［システムの概要］で確かめられます。*5 指定した数を超えたら知らせる通知も設定できます。*5 通知を誰が受けて動くかまで決めておきます。
年3回のリリースへの対応
Salesforceの更新は自動で行われ、すべての利用者が同じ版を使います。*1 アップグレードの日付はSalesforce TrustのWebサイトで前もって発表され、本番環境の4〜6週間前に、Sandbox（本番とは別のテスト用の環境）が先にアップグレードされます。*1 この期間に自社の設定が動くかを確かめます。1回の対応は、次の4つの段階で進めます。
ステップ2では、リリースノートの絞り込みを使い、リリースと同時に自動で有効になる機能と、管理者が有効にしないと使えない機能を分けて確かめます。*2 ステップ3でつまずきやすいのは、Sandboxを作り直す時期です。プレビューの期間中に作り直したSandboxは、新しい版が後から当たる側へ移ってしまいます。*3
公式の学習サイトは、この準備を3か月ごとに繰り返すよう勧め、利用者が50人未満の組織なら上の手順で足りるとしています。*2 プログラムや複雑な設定が多い組織では確かめる項目が増えるため、リリースのたびの作業時間を保守の契約に含めておきます。
頼み先の違いと費用の決まり方
Salesforceの保守の頼み先は、社内の管理者、導入した会社、保守を専門に受ける会社の3つです。どれが合うかは、作り込みの量と社内の体制で変わります。
| 頼み先 | 費用の払い方 | 引き継ぎ | 向いている場面 |
|---|---|---|---|
| 社内の管理者 | 担当者の人件費。学ぶ時間とリリースのたびの確認の時間も含む | 要らない。担当者が辞めると中身を知る人がいなくなる | 利用者が少なく、作業の中心が設定変更とユーザー管理のとき |
| 導入した会社 | 導入の契約に続けて保守の契約を結ぶ。月ごとの枠か依頼ごと | ほとんど要らない。作った人が影響を見られる | 導入時の体制が続いていて、作り込みや連携が多いとき |
| 保守を専門に受ける会社 | 現状の調査と引き継ぎの費用に、毎月の保守の費用が加わる | 現状の調査と引き継ぎの期間が要る | 導入した会社が保守を受けないとき。社内の担当者が辞めたとき |
Salesforceに払うライセンスの料金と、保守を頼む会社に払う費用は別の契約です。保守の費用は、公的な調査で相場が示されているものではなく、作業の量と条件で見積もりが変わります。
- 組織の大きさ：利用者の数、作り込んだ項目・画面・フローの量、Apexの有無
- 連携先の数：つないでいる外部システムの数と、監視の頻度
- 払い方：毎月の作業時間の枠を決める形か、依頼ごとに見積もる形か
- 対応する時間帯：平日の日中だけか、夜間や休日の連絡も受けるか
- リリースへの対応：年3回の確認を毎月の費用に含めるか、別に見積もるか
見積もりは、同じ作業の一覧を各社に渡し、月ごとの作業時間と枠を超えたときの扱いをそろえて出してもらいます。
外部に頼むときに確認しておきたい点
Salesforceの保守を外部に頼む前に、次の点を自社で書き出しておくと、相談の場でそのまま使えます。
- 範囲：4つの作業のうち、どれを頼み、どれを社内に残すか
- 期間：契約の期間と見直しの時期。次のリリースへの対応をどの回から受け持つか
- 体制：窓口の担当者、問い合わせの受け方、連携が止まったときの連絡先
- 費用の決まり方：月の作業時間の枠、枠を超えたときの扱い、リリースへの対応を含むか
- 引き継ぎ：設定の変更の記録、Sandboxの一覧、連携先の一覧、管理者の権限をどう渡すか
引き継ぎの資料は、あとで保守会社を替えるときにも要ります。設定を変えたら記録を残し、自社が受け取れることを契約の最初に決めておきます。保守会社を選ぶときの一般的な確認点はシステム保守会社の選び方で扱っています。
まとめ：Salesforce保守で確かめておきたい3つの点
Salesforceの保守を頼むうえで、確かめておきたい点は3つです。第一に、4つの作業のうち、どれを頼みどれを社内に残すかを決めること。第二に、年3回のリリースのたびに、Sandboxで確かめる作業を誰が受け持つかを決めること。第三に、作業時間の枠など費用の決まり方をそろえて見積もりを比べることです。この3点を踏まえておけば、「リリースのあとで画面が変わり、誰にも聞けない」という事態を避けやすくなります。保守の分担や頼み先に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
社内の管理者と保守会社で作業を分けられますか
分けられます。たとえば、ユーザーの追加やパスワードのリセットは社内で行い、リリースの確認と連携の監視は保守会社に頼む、という分け方です。分ける場合は、権限の変更のように両方にかかわる作業をどちらが行うかを決めておきます。
リリースへの対応を頼まないとどうなりますか
自動で有効になる機能は、本番環境にリリースされるとすぐにすべての利用者に表示されます。*3 事前に確かめていないと、画面の変化について利用者からの問い合わせが増えます。また、管理者が有効にすれば使える機能が使われないままになることもあります。*2
保守会社を替えるときは何を渡せばよいですか
設定の変更の記録、Sandboxの一覧、連携先の一覧と接続の方法、管理者の権限を持つユーザーの一覧が基本です。前の会社の担当者が管理者の権限を持ったままなら、引き継ぎが終わった時点で凍結か無効化をして、権限を止めます。
Salesforceの保守運用のご相談
Salesforceの設定変更から年3回のリリースへの対応、ユーザーと権限の管理、連携の監視まで、元請（プライムベンダー）としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：Salesforce Trailhead「Salesforce リリース準備状況戦略」単元「Salesforce のリリースプロセスを理解する」（https://trailhead.salesforce.com/ja/content/learn/modules/sf_releases/sf_releases_start）。出典：年3回（Spring・Summer・Winter）のリリース、自動アップグレード、Salesforce Trustでの日付の発表、本番の4〜6週間前のSandboxのアップグレードの記述を参照（2026年10月確認）
- *2 参考：Salesforce Trailhead「Salesforce リリース準備状況戦略」単元「新機能の検索、有効化、コミュニケーション」（https://trailhead.salesforce.com/ja/content/learn/modules/sf_releases/sf_releases_strategy）。出典：リリースノートの［機能の影響］の絞り込み（自動有効機能・簡易有効機能）、3か月ごとの繰り返し、ユーザー50人未満の組織についての記述を参照（2026年10月確認）
- *3 参考：Salesforce Trailhead「Salesforce リリース準備状況戦略」単元「Sandbox プレビューで早期アクセスを利用する」（https://trailhead.salesforce.com/ja/content/learn/modules/sf_releases/sf-releases-sandbox-preview）。出典：自動で有効になる機能の表示、Sandboxプレビューの期間中に更新したSandboxが非プレビューインスタンスに移る点を参照（2026年10月確認）
- *4 参考：Salesforce Trailhead「ユーザー管理」単元「新規ユーザーの追加」（https://trailhead.salesforce.com/ja/content/learn/modules/lex_implementation_user_setup_mgmt/lex_implementation_user_setup_mgmt_adding_users-hoc）。出典：ユーザーの凍結と無効化、ユーザーは削除できない点、最小アクセスのプロファイルと権限セットの推奨を参照（2026年10月確認）
- *5 参考：Salesforce Trailhead「API の基本」単元「Salesforce プラットフォーム API について知る」（https://trailhead.salesforce.com/ja/content/learn/modules/api_basics/api_basics_overview）。出典：直近24時間のAPIコール数の制限、［システムの概要］のAPI使用状況、API使用状況通知の記述を参照（2026年10月確認）
