【Salesforce】ToDoの期限が想定と違う時の管理者が見るべき原因

SalesforceのToDo(タスク)は、営業活動や顧客対応の進捗管理に欠かせない機能です。しかし、ToDoの期日(ActivityDate)がユーザーの意図と異なる表示になるトラブルが発生することがあります。管理者としては、なぜ期限がずれるのかを迅速に特定し、システム設定やユーザー運用を適切に調整する必要があります。本記事では、ToDoの期限が想定と異なる場合に管理者が確認すべき原因と、その解決方法を具体的に解説します。組織全体で統一的な期限管理を実現するために、ぜひ参考にしてください。

ToDoの期限が想定と違う主な原因

ToDoの期限(ActivityDate)が期待と異なる原因は、大きく以下の4つに分類されます。これらを意識しながら調査を進めると、効率的に問題を特定できます。

• 1. ユーザーのタイムゾーン設定の不一致
  Salesforceでは日付フィールドはサーバーのタイムゾーン(通常UTC)で保存され、ユーザーごとに設定されたタイムゾーンで変換されて表示されます。例えば、日本時間(JST)のユーザーがUTCのユーザーと同じToDoを見ると、日付が1日ずれて見えることがあります。
• 2. オブジェクト設定によるデフォルト値や数式の誤り
  ToDoオブジェクトのActivityDateフィールドにデフォルト値や数式が設定されている場合、その計算結果が想定と異なる可能性があります。特に、数式で他の日付フィールド(例:取引先責任者の誕生日)を参照している場合、参照元の値が変更されると連動します。
• 3. 自動化機能による上書き
  ワークフロールール、プロセスビルダー、フローなどの自動化機能がActivityDateを更新するルールを定義していると、ユーザーが手動で入力した日付が上書きされることがあります。条件や更新値の設定ミスが原因で、意図しない期限に変更されるケースが少なくありません。
• 4. データインポートやAPI連携時の変換ミス
  データローダやAPIを使って外部システムからToDoを取り込む際、日付のフォーマットやタイムゾーンの扱いが不適切だと、期限がずれます。特に、CSVファイルの日付列が文字列として扱われ、自動変換が行われない場合に問題が発生します。

原因を特定するための確認手順(管理者向け)

問題の原因を特定するには、次の手順で段階的に確認します。各手順を実施する際は、Sandbox環境でのテストを推奨します。

1. 該当ToDoレコードの詳細を確認する
   問題のToDoを開き、ActivityDateフィールドに表示されている日付と、ユーザーが期待する日付を比較します。フィールド履歴(設定 > オブジェクトマネージャ > Task > フィールド履歴)を有効にしていれば、いつ誰がどのように更新したかが分かります。
2. ユーザーのタイムゾーン設定を確認する
   ユーザーの個人設定(右上のユーザーアイコン > 設定 > マイ設定 > 個人用のカスタマイズ > ロケール)でタイムゾーンが適切か確認します。日本組織なら「(GMT+09:00) 日本標準時」が選択されているかがポイントです。組織全体のデフォルトタイムゾーンも管理設定(会社の設定 > 組織のデフォルトタイムゾーン)で確認できます。
3. オブジェクト設定でActivityDateのデフォルト値や数式を確認する
   設定 > オブジェクトマネージャ > Task > フィールドとリレーション > ActivityDate を開き、「デフォルト値」や「数式」タブを確認します。数式が設定されている場合は、その式が正しく評価されているかテストします。例えば、{!TODAY()} + 7 のような式で7日後を指定している場合、TODAY()がUTCで計算されるため、ユーザーのタイムゾーンによっては1日ずれることがあります。
4. 自動化ルール(ワークフロールール、プロセスビルダー、フロー)を確認する
   設定 > プロセス自動化 > ワークフロールール(またはプロセスビルダー、フロー)で、Taskオブジェクトに対するルールをすべてリストアップします。特にActivityDateを更新するルールがないか、条件や更新値のロジックを精査します。数式で日付を計算している場合、UTCとユーザータイムゾーンの変換を考慮する必要があります。
5. データインポートのログを確認する
   データローダやData Import Wizardを使ってインポートした場合、インポートファイルの日付列が文字列として扱われていないか確認します。CSVの日付が「2025/03/01」ではなく「2025-03-01 00:00:00」のような形式になっている場合、Salesforceが正しく日付と認識しないことがあります。また、API連携では、REST APIのDateフィールドはISO 8601形式(yyyy-MM-dd)で送る必要があります。

ユーザー側の設定による影響

ユーザー個人の設定ミスが原因で期限がずれるケースは頻繁に発生します。管理者が確認すべきユーザー設定は以下の通りです。

タイムゾーンの誤設定

ユーザーが自分のタイムゾーンを正しく設定していないと、ToDoの期限が意図しない日付で表示されます。例えば、日本在住のユーザーが「(GMT) グリニッジ標準時」を選択している場合、表示される日付は実際の期限より9時間前の日付になります(午前0時に作成したToDoなら前日の日付)。

手動入力ミス

ユーザーがToDo作成時にカレンダーUIで日付を選択する際、誤って別の日付をクリックしてしまうことがあります。特に、月をまたぐ操作でうっかりミスが発生しやすいです。管理者はフィールド履歴で更新者と日時を確認し、手動変更かどうかを判断します。

ブラウザのタイムゾーンとの連動

SalesforceのUIはブラウザのタイムゾーンを使用して日付を表示するわけではありません。ユーザー設定のタイムゾーンが優先されるため、ブラウザのタイムゾーンと異なる設定をしていると混乱を招きます。ユーザーには個人設定のタイムゾーンを勤務地に合わせるよう周知することが重要です。

自動化機能(ワークフロールール、プロセスビルダー、フロー)による変更

自動化機能によるActivityDateの更新は、意図しない期限変更の主要原因の一つです。それぞれの機能の特徴と確認ポイントを比較します。

自動化機能	特徴	確認すべき項目
ワークフロールール	即時アクションまたは時間依存アクションで日付を更新できる。条件は数式やレコード項目で指定。	数式で日付を設定する場合、TODAY()とNOW()の違い(TODAY()は日付のみ、NOW()は日時)に注意。UTCでの計算となる。
プロセスビルダー	トリガー条件とアクションを視覚的に設定。即時アクションでフィールド更新が可能。	アクションの「更新する値」に数式を使用する場合、数式の結果が想定通りかテスト。プロセスビルダーは時間依存アクションを持たないため、ワークフロールールと混在しないよう注意。
フロー	複雑なロジックが組める。リソース要素(数式、変数)を使って柔軟に日付を計算できる。	フローの数式リソースで使用されているタイムゾーン関数(例:DATEVALUE())が正しいか。また、フローの開始条件と更新タイミングを確認。

特に、時間依存のワークフロールールで「レコード作成時からN日後」のような設定をしている場合、作成時刻とトリガー時刻のずれに注意してください。例えば、金曜日の17時に作成されたToDoが、月曜日の17時に期限が更新されるという動作が想定外であれば、ルールの設計を見直す必要があります。

データインポートやAPI連携時の注意点

外部システムからのデータ取り込みは、日付の形式やタイムゾーンの扱いを間違えると期限がずれる原因になります。以下の点を確認してください。

データローダでインポートする場合

データローダでは、ActivityDateフィールドにCSVの日付値をそのまま渡します。CSVの日付が「2025/03/01」のような形式の場合、Salesforceが正しく日付と認識しないことがあるため、ISO形式「2025-03-01」に統一することを推奨します。また、時刻を含む「2025-03-01 00:00:00」の場合、Salesforceは日付型として読み込む際に時刻を無視しますが、タイムゾーンによる影響は受けません。

APIでインポートする場合

REST APIでActivityDateを指定する際は、必ず「yyyy-MM-dd」形式の文字列を送信します。日時型(DateTime)ではないため、タイムゾーン変換はSalesforce側で行われません。しかし、APIリクエストを送信するシステムのタイムゾーンとSalesforceの解釈にずれがあると、意図しない日付になるケースがあります。例えば、日本時間の午前0時にAPIを叩いて「2025-03-01」を送信しても、それはそのまま保存されるため、問題は起きません。ただし、システムが自動的に時刻を付加する場合(例:2025-03-01T00:00:00Z)、Salesforceは日付部分だけを抽出するので、通常は問題ありません。しかし、システムによってはタイムゾーン変換が行われて日付が変わることがあるため、テストが必要です。

失敗パターンとその対策

実際に発生した失敗パターンをいくつか紹介します。これらの事例を参考に、自組織の状況をチェックしてください。

• パターン1:グローバル組織でのタイムゾーン混乱
  日本とアメリカのメンバーが同じToDoを見て、それぞれが異なる日付を認識するケース。対策としては、ToDoオブジェクトに「基準日付(UTC)」の項目を追加し、常にUTCで確認できるようにするか、組織のデフォルトタイムゾーンを統一することを検討します。
• パターン2:ワークフロールールでTODAY() + 1が翌日にならない
  日本時間の深夜に作成したToDoで、TODAY() + 1が前日になってしまう現象。これはTODAY()がUTCの日付を返すためです。対策として、数式でDATEVALUE(NOW()) + 1のように現在日時から日付を計算するか、ワークフロールールの条件を見直します。
• パターン3:データローダでCSVの日付列が空文字の場合
  CSVの日付列が空(null)の場合、Salesforceではデフォルト値が設定され、想定外の日付が入ります。対策として、データローダのマッピングでデフォルト値を設定しない、またはCSV側で空欄を明示的にnullにする必要があります。

よくある質問(Q&A)

• Q1. 特定のユーザーだけToDoの期限が1日ずれて表示されます。原因は何ですか?
  A1. そのユーザーのタイムゾーン設定が他のユーザーと異なる可能性が高いです。個人設定でタイムゾーンを確認してください。特に、海外出張などで一時的に変更したまま元に戻していないケースがよくあります。
• Q2. ワークフロールールでActivityDateを更新するようにしたのに、なぜか更新されません。
  A2. ワークフロールールの評価条件が正しいか確認してください。「レコードが作成され、次に編集されるたび」などの条件になっていると、ToDo作成時のみ評価されません。また、ルールの適用順序や、他の自動化ルールとの競合がないかも調べてください。
• Q3. データローダでインポートしたToDoの期限がすべて同じ日付になっています。なぜですか?
  A3. CSVの日付列が空欄、またはすべて同じ値になっている可能性があります。CSVファイルを開いて確認してください。また、マッピングでデフォルト値が設定されている場合もその値が適用されます。
• Q4. 組織全体のタイムゾーンを変更したら、既存のToDoの期限が変わってしまいました。
  A4. 組織のデフォルトタイムゾーンを変更しても、既存のレコードのActivityDateに保存されている値(UTC)は変わりません。しかし、表示がユーザーのタイムゾーンに依存するため、ユーザーごとに異なる見え方になることがあります。既存データはそのままですが、ユーザー設定のタイムゾーンを統一すれば解消できます。

まとめ

SalesforceのToDo期限が想定と異なる場合、まずはユーザーのタイムゾーン設定とオブジェクト設定のデフォルト値を確認しましょう。次に、ワークフロールールやフローなどの自動化機能がActivityDateを更新していないかを精査します。データインポートやAPI連携の場合も、日付の形式とタイムゾーンの扱いに注意が必要です。これらの原因を一つずつ切り分けることで、多くの問題は解決できます。また、ユーザーに対しては、ToDoの期限が自分のタイムゾーン設定に依存することを周知し、定期的に設定を見直すように促すと、トラブルを未然に防げます。管理者として、システム設定とユーザー教育の両面から対策を進めてください。