CRM日時項目のタイムゾーン管理｜日付ずれを防ぐ保存・表示・連携ルール

CRMの日時項目は、画面上では同じ「2026年8月16日 10:00」に見えても、保存時の基準、利用者のタイムゾーン、CSVやAPIの形式、レポートの日付境界によって別の瞬間として扱われます。国内だけで運用しているつもりでも、SaaS側の保存値はUTC、利用者表示は日本時間、連携バッチはUTC日付という組み合わせになり、商談予定、対応期限、契約日、日次集計が前日や翌日にずれることがあります。

結論から言うと、CRMでは「世界で一つの瞬間」「カレンダー上の日付」「タイムゾーンに依存しない時刻」を別の型として設計します。瞬間はUTCを基準に保存し、APIではZまたは数値オフセットを明示します。誕生日や契約日のような日付はDate Onlyで保持し、午前0時のDateTimeで代用しません。CSV・API・レポートでは、入力時のゾーン、変換責任、集計基準ゾーンを仕様として固定し、境界時刻とサマータイムを含むテストで確認します。

---

本記事のポイント

1. 日時項目は、瞬間・日付・地域に依存しない時刻のどれを表すかを先に決め、保存型と表示変換を分けます。
2. CSV・API連携ではZまたは数値オフセットを必須にし、変換前の値、基準ゾーン、変換後UTCを追跡できるようにします。
3. 既存項目の挙動変更は値を自動補正しない製品があるため、依存調査、影響試算、並行検証、切り戻しを先に用意します。

---

CRMの日時を3種類に分けて設計する

最初に決めるのは「UTCか日本時間か」ではなく、その値が何を表しているかです。商談開始、メール送信、問い合わせ受信、レコード作成は、世界のどこで見ても同じ一つの瞬間です。一方、誕生日、契約開始日、請求対象日、休業日はカレンダー上の日付であり、見る人の地域によって前日へ変わってはいけません。店舗の開店時刻やホテルのチェックイン時刻のように、地域の壁時計上の時刻自体が意味を持つ値もあります。

意味	業務例	推奨する保持	避ける設計
世界で一つの瞬間	商談開始、問い合わせ受信、更新時刻、送信時刻	UTCのtimestampを正本にし、表示時に利用者ゾーンへ変換	オフセットのない文字列や日本時間の固定文字列
カレンダー上の日付	誕生日、契約日、請求日、休日、満了日	Date Onlyとして年月日だけを保持	午前0時のDateTimeで代用し、表示変換を受ける
地域に依存しない壁時計時刻	施設の開店時刻、毎日の締切時刻、定刻の受付	時刻と必要な地域タイムゾーンIDを目的別に保持	現在のUTCオフセットだけを永久に保存

SalesforceはDate/Timeを内部でUTCとして扱い、画面では利用者に設定されたタイムゾーンへ変換します。そのため、同じレコードでも東京とニューヨークの利用者には異なる現地時刻で表示されます。これは不整合ではなく、同じ瞬間を地域ごとに表している結果です。問題は、その変換を想定していないCSV、数式、外部連携が混ざることです。

Microsoft Dataverseでは、日時列の挙動としてUserLocal、DateOnly、TimeZoneIndependentを選べます。UserLocalはUTCを基準に利用者表示へ変換し、DateOnlyは時刻を持たない日付、TimeZoneIndependentは利用者ゾーンによる変換をしない日時です。表示形式をDate Onlyにしただけでは、時刻部分を持つUserLocalの挙動が残る場合があります。Microsoftも、UserLocalのままDate Only表示にすると、別タイムゾーンの利用者に異なる日付が見える可能性があると注意しています。

項目台帳には、項目名だけでなく、業務上の意味、保存型、基準ゾーン、入力元、表示変換、日付境界、連携形式、所有者を記録します。一般的な項目追加・統合・廃止の進め方はCRM選択リストの管理方法でも扱っていますが、日時では「型が同じでも意味が違う」点を追加して管理する必要があります。

UTC保存と利用者表示の責任を分ける

瞬間を表す日時は、保存・交換の正本をUTCへ寄せると比較と並び替えが安定します。ただし、UTCだけを保存すれば十分とは限りません。顧客が入力した現地時刻を再現する必要があるなら、元のタイムゾーンIDや入力オフセット、入力元も別に保持します。数値オフセットの「+09:00」はその瞬間のUTCとの差を示しますが、地域の将来のサマータイム規則までは表しません。定期予定を扱う場合は、`Asia/Tokyo`や`America/Los_Angeles`のような地域タイムゾーンを業務仕様として持つ方が安全です。

処理層	責任	確認する値	代表的な事故
入力画面	利用者がどの地域時刻を入力しているか明示	利用者ゾーン、項目挙動、入力例	ブラウザとCRMが二重に変換する
保存	瞬間・日付・壁時計時刻を型どおり保持	raw値、UTC、ゾーンID、変換時刻	日付を午前0時UTCで保存して前日表示
API・CSV	形式とオフセットの解釈を固定	RFC 3339形式、Z、数値オフセット	ゾーンなし値をUTCと現地時刻で別解釈
画面・通知	誰のゾーンで見せるか決める	利用者設定、組織設定、通知受信者	画面とメールの時刻が一致しない
レポート	日次・月次の境界ゾーンを固定	集計開始・終了のUTC換算	UTC日付で切って日本時間の早朝分が前日へ入る

画面上で正しく見えることと、保存値が正しいことは別です。SalesforceのUIは利用者ゾーンへ変換しますが、Data LoaderやAPIの入出力はUTCとして扱われるため、画面値とCSV値が数時間違って見えることがあります。DataverseのUserLocalも、UI入力では現地時刻からUTCへの計算が行われますが、OData APIへオフセットなしの値を送ると同じ計算が行われず、表示時に差が出る例が公式資料で示されています。

日付だけが必要な項目をDateTimeにしないことも重要です。SalesforceではDateとDate/Timeが別の型で、数式でDate/TimeからDateへ変換するときのタイムゾーン処理に注意が必要です。DataverseでもDate Only挙動は時刻を保存しません。契約日や誕生日のように全利用者が同じ年月日を見るべき値は、最初から日付型にすると変換経路を減らせます。

CSV・API連携で日付ずれを防ぐ

システム間連携では、オフセットなしの`2026-08-16T10:00:00`を禁止し、UTCなら末尾に`Z`、現地時刻なら`+09:00`のような数値オフセットを含めます。RFC 3339はインターネット上のtimestampについてUTCとの関係をオフセットで示す形式を定義しています。`JST`、`CST`のような略称は地域によって意味が重なるため、交換形式に使いません。

たとえば、日本時間2026年8月16日10時の瞬間は、`2026-08-16T10:00:00+09:00`または同じ瞬間の`2026-08-16T01:00:00Z`で表せます。どちらを受け付けるか、受信側がどこでUTCへ正規化するかをAPI仕様に書きます。SalesforceのAPIへDateTimeを送る場合はUTC形式を使い、DataverseのUserLocal列へWeb APIで送る場合は、利用者のオフセットを含めるか、事前にUTCへ変換してZ付きで送る方法が公式に案内されています。製品ごとの仕様差を共通処理で隠さず、connector単位の変換テストを持ちます。

1. 項目対応表を作る：送信元の型、意味、基準ゾーン、送信形式と、CRM側の型・挙動を1行ずつ対応させます。
2. 曖昧な入力を拒否する：オフセットなし日時、2桁年、月日順が不明な文字列、空欄とゼロ日付の混在を受け付けません。
3. raw値を検証用に残す：一時領域に原文、取込時刻、入力元、変換後UTC、エラー理由を残し、秘密情報や不要な個人情報は増やしません。
4. 境界データで試す：日付が変わる前後、月末・年末、うるう日、サマータイム開始・終了、異なる利用者ゾーンを含む固定データを用意します。
5. 小さい件数で照合する：取込前値、API応答、東京利用者表示、海外利用者表示、レポート日付を同じrecord IDで比較します。
6. 再実行を安全にする：変換済み値を二重にオフセットしないよう、取込ID、version、処理済み状態を持たせます。
7. 本番後も差分を監視する：前日・翌日への移動件数、時刻欠損、将来日、想定外ゾーン、連携エラーを日次で確認します。

CSVは利用者が表計算ソフトで開くだけでも表示形式が変わります。列を文字列として固定し、timezone列やsource system列を分け、取込テンプレートに具体例を載せます。SalesforceはData LoaderでDate/Timeを取込・出力するときUTCとして扱い、UIでは利用者ゾーンへ変換するため、両方を同じ値として目視比較しないことが重要です。大量移行の全体設計はCRM乗り換え前のチェックリストと合わせて確認すると、日時以外の参照関係や重複も整理できます。

レポート境界とサマータイムを検証する

日次レポートの「8月16日」は、どのタイムゾーンの0時から24時までかを決めなければ再現できません。日本営業チームの日報なら、Asia/Tokyoの8月16日0時以上・8月17日0時未満をUTCへ換算し、その範囲でtimestampを検索します。UTC日付へ単純に変換して`2026-08-16`だけを比較すると、日本時間16日0時から8時59分のデータがUTCでは15日に入り、件数がずれます。

組織全体を一つのゾーンで集計するのか、担当者の現地日付で集計するのか、顧客拠点の日付で集計するのかも固定します。営業活動件数は担当者ゾーン、請求締めは契約上の基準ゾーン、SLAは受付拠点ゾーンというように、指標ごとに基準が異なる場合があります。同じtimestampを使っていても、集計目的が違えば日付バケットは変わります。

サマータイムを採用する地域では、1日が常に24時間とは限りません。春には存在しない現地時刻があり、秋には同じ現地時刻が2回現れます。固定の`-08:00`を年間通じて使わず、地域タイムゾーンと対象日からオフセットを求めます。通知予約、次回活動、月次締め、SLAの期限計算は、切替日の前後をテストデータに含めます。

検証ケース	入力	期待する確認	失敗時に疑う層
日本時間の日付境界	23:59、00:00、00:01	日次集計が意図した日に入る	レポートのUTC検索範囲
海外利用者表示	同じUTC timestamp	瞬間は同じで現地表示だけが変わる	利用者タイムゾーン設定
Date Only	誕生日・契約日	全地域で同じ年月日	DateTime代用、表示変換
DST開始・終了	切替前後の現地時刻	欠落・重複を仕様どおり扱う	固定オフセット、地域ID欠落
CSV/API再取込	同じ取込IDとtimestamp	二重変換・重複更新がない	冪等性、raw値の扱い

レポートや自動化で日時項目を参照していると、項目の挙動変更が集計、通知、承認、予測へ波及します。変更前に利用箇所を特定し、過去値と新規値を同じ計算へ混在させない設計が必要です。廃止・置換時の依存調査はCRM項目を安全に廃止する手順を参照してください。

既存の日時項目を安全に移行する

既存項目の型や挙動を直接変更すると、保存済みデータが期待どおりに変換されない場合があります。Dataverseは、UserLocalからDateOnlyまたはTimeZoneIndependentへ挙動を変えても、既存値は自動変換されずUTCのまま残ると明記しています。新しく入力・更新された値だけが新挙動になるため、同じ列に旧ルールと新ルールの値が混在する可能性があります。

安全な移行では、まず現在値の意味を特定します。過去のCSV、連携コード、利用者設定、数式、ワークフロー、レポート、通知テンプレートを調べ、「この値はUTC」「日本時間をUTCと誤認して保存」「日付を午前0時で代用」のように母集団を分類します。一律に9時間足すと、正しく保存されていた行まで壊します。

1. 依存関係を固定する：画面、API、CSV、数式、ワークフロー、rollup、レポート、BI、通知、外部連携を項目単位で洗い出します。
2. 値の母集団を分類する：作成期間、入力元、作成者ゾーン、値の分布から、どの変換ルールで保存されたかを推定します。
3. 新項目を用意する：上書きが避けられる場合は、正しい型・挙動の新項目を作り、変換元と変換規則を残します。
4. サンドボックスで変換する：境界日、海外利用者、DST、過去データを含む標本で、保存値・表示・集計・連携を照合します。
5. 並行書込みと差分監視を行う：限定期間だけ旧新項目へ書き、差分理由が説明できるか確認します。
6. 読み取り先を段階切替する：レポート、通知、API、画面を小さい範囲から新項目へ切り替え、異常時に旧参照へ戻せるようにします。
7. 旧項目を凍結して証跡を残す：移行完了後は旧項目の更新を止め、変換件数、除外、承認、切替時刻、監視結果を保存します。

本番データを検証環境へコピーする場合は、タイムゾーン以外に顧客情報の保護も必要です。標本の作り方と権限制御はCRMサンドボックス更新時のデータマスキングを確認してください。全件をそのまま複製せず、境界値を人工データで補うと、個人情報を増やさずに変換ロジックを検証できます。

よくある質問

CRMの日時はUTCと現地時刻のどちらで保存しますか？

商談開始や問い合わせ受信のように一つの瞬間を表す値はUTCを正本にし、表示時に利用者のタイムゾーンへ変換します。現地時刻を再現する必要があるなら、元の地域タイムゾーンIDや入力オフセットも別に保持します。誕生日や契約日のような日付はDate Onlyにします。

日付のみの項目で前日・翌日にずれるのはなぜですか？

日付を午前0時のDateTimeとして保存し、別タイムゾーンへ変換すると、時差によって前日または翌日になるためです。表示形式だけをDate Onlyにしても、保存型や挙動がUserLocalのままなら変換は残ります。時刻を必要としない値はDate Only挙動で保持します。

CSV・API連携ではタイムゾーンをどう指定しますか？

UTCなら`Z`、現地時刻なら`+09:00`のような数値オフセットを含むRFC 3339形式を使い、オフセットなし日時を受け付けません。製品によってAPI入力の変換責任が異なるため、Salesforce、Dataverseなどconnectorごとに送信形式と変換前後の期待値をテストします。

既存の日時項目を直す前に何を検証しますか？

入力元、保存挙動、利用者ゾーン、CSV・API、数式、ワークフロー、レポート、通知、外部連携を調べます。過去値がどのルールで保存されたかを母集団別に分類し、新項目またはサンドボックスで変換、表示、集計、切り戻しを確認してから本番へ進みます。

日本国内だけならタイムゾーン設計は不要ですか？

必要です。CRMやクラウドの保存値、API、バッチ、BIがUTCを使うことがあり、日本の利用者しかいなくても日付境界でずれます。組織設定と利用者設定の不一致、海外サービスの既定値、将来の拠点追加にも備え、基準ゾーンと交換形式を明示します。

サマータイムがない日本時間は固定で9時間足せばよいですか？

日本時間だけの一時的な変換では9時間差を使えますが、式を全連携へ埋め込むと再利用や海外展開で破綻します。UTC変換は標準ライブラリと地域タイムゾーンを使い、指標の日付境界を設定として管理します。海外拠点や顧客時刻を扱う処理では固定オフセットを使いません。

日時項目を直す合図は、画面の表示が合った時ではなく、保存値・API応答・利用者表示・日次集計が同じ設計で説明できた時です。値の意味、保存型、オフセット付き交換、表示責任、集計境界、既存値の移行を一つの仕様として固定すれば、CRMの日時は「ずれた後に補正する項目」ではなく、連携と分析を支える信頼できる基盤になります。