Instant を一言でいうと
Instant は
「世界共通の“ある一瞬”を、UTC 基準で表したもの」
です。
人間が「2025年1月18日 10時（日本時間）」と考えるのに対して、Instant は「1970-01-01T00:00:00Z から何秒（何ナノ秒）経ったか」という、機械寄りの時刻の表現です。
「タイムゾーンに左右されない絶対的な時刻」を扱いたいときの、土台になるクラスだと思ってください。
Instant が表しているものと、そのイメージ
「1970-01-01T00:00:00Z からの経過時間」
Instant は内部的には「エポック（1970-01-01T00:00:00Z）からの経過秒＋ナノ秒」で表現されています。
コードで見ると、まずはこうです。
Instant now = Instant.now();
System.out.println(now); // 例: 2025-01-18T01:23:45.123456789Z
末尾の Z は「UTC（+00:00）」を意味します。
つまりこれは、「世界共通の基準時刻（UTC）で見たときの、ある一瞬」です。
ここには「日本時間」や「ニューヨーク時間」といった概念は一切ありません。
ただ「世界のどこから見ても同じ瞬間」を表しているだけです。
「場所に依存しない」というのが最大の特徴
Instant はタイムゾーンを持たないので、
サーバーのタイムゾーン設定
ユーザーの居住地
夏時間の有無
といったものに影響されません。
だからこそ、
DB に保存する
システム間でやり取りする
ログに残す
といった「機械同士の約束事」には、Instant がとても向いています。
Instant と人間向けの日時（LocalDateTime / ZonedDateTime）の関係
Instant → 各地のローカル時刻に変換する
Instant は「絶対的な瞬間」なので、それを「日本時間で見ると何時か？」に変換する必要があります。
Instant now = Instant.now();
ZonedDateTime tokyoTime = now.atZone(ZoneId.of("Asia/Tokyo"));
ZonedDateTime newYorkTime = now.atZone(ZoneId.of("America/New_York"));
System.out.println(tokyoTime); // 2025-01-18T10:23:45+09:00[Asia/Tokyo]
System.out.println(newYorkTime); // 2025-01-17T20:23:45-05:00[America/New_York] など
同じ Instant を、
「東京のローカル時刻」として見るか、
「ニューヨークのローカル時刻」として見るか、
という違いだけです。
ここで大事なのは、
Instant は 1 つZonedDateTime は「その瞬間を、あるタイムゾーンで見た姿」
という関係になっていることです。
ローカル時刻 → Instant に変換する
逆に、「東京の 2025-01-18 10:00」を Instant にしたい場合は、まずタイムゾーン付きの日時にしてから変換します。
ZonedDateTime tokyo =
ZonedDateTime.of(2025, 1, 18, 10, 0, 0, 0, ZoneId.of("Asia/Tokyo"));
Instant instant = tokyo.toInstant();
System.out.println(instant); // 2025-01-18T01:00:00Z など
「東京の 10:00」は「UTC の 1:00」として表現される、という対応です。
Instant の典型的な使いどころ
DB に保存するタイムスタンプとして
DB に「作成日時」「更新日時」を保存するとき、Instant を使うと設計がきれいになります。
Instant createdAt = Instant.now();
long epochMilli = createdAt.toEpochMilli(); // long で保存しやすい
DB には BIGINT などで epochMilli を保存しておき、
取り出すときに Instant.ofEpochMilli(...) で復元します。
こうしておけば、
サーバーのタイムゾーンが変わっても
別の国のサーバーに移っても
「同じ瞬間」として扱い続けることができます。
表示するときは、ユーザーのタイムゾーンに変換してからフォーマットします。
ZoneId userZone = ZoneId.of("Asia/Tokyo");
ZonedDateTime viewTime = createdAt.atZone(userZone);
String text = viewTime.toString(); // あるいは DateTimeFormatter で整形
処理時間の計測
「この処理にどれくらい時間がかかったか」を測るときにも、Instant は便利です。
Instant start = Instant.now();
// 何か重い処理
doSomething();
Instant end = Instant.now();
Duration duration = Duration.between(start, end);
System.out.println("処理時間: " + duration.toMillis() + " ms");
Instant 同士の差分は Duration で表現でき、
ミリ秒・秒・分などに簡単に変換できます。
Instant と Date / System.currentTimeMillis の違い
Date は「中途半端な存在」
古い java.util.Date も、内部的には「エポックからのミリ秒」を持っていますが、
ミュータブルである
タイムゾーンの扱いが曖昧
API が古くて分かりにくい
といった問題があります。
Instant は、
不変（immutable）
タイムゾーンを持たない（常に UTC）Duration や ZonedDateTime などと連携しやすい
という点で、Date の「ちゃんとした後継」として設計されています。
System.currentTimeMillis との関係
System.currentTimeMillis() も「エポックからのミリ秒」を返しますが、
ただの long なので、「これは時刻だ」という情報が型にありません。
Instant を使うと、
Instant now = Instant.now(); // 型で「時刻」と分かる
long millis = now.toEpochMilli(); // 必要なら long に変換
Instant again = Instant.ofEpochMilli(millis); // 復元も簡単
というように、「時刻であること」が型で表現され、
他の日時 API とも自然につながります。
設計としての一番大事なポイント：「内部は Instant、外側で変換」
内部表現を Instant にそろえるメリット
アプリケーションの内部で扱う「瞬間」は、できるだけ Instant にそろえておくと設計がシンプルになります。
例えば、
DB：Instant（または epoch milli）
メッセージ：Instant を ISO 文字列にして送る
ドメインモデル：Instant createdAt
という形にしておき、
画面表示やユーザー入力のところでだけ、ZonedDateTime / LocalDateTime / OffsetDateTime に変換する、という方針です。
こうすると、
「内部ロジックはタイムゾーンに振り回されない」
「ユーザーごとのタイムゾーンは“外側”でだけ意識すればよい」
という構造になり、バグの入りどころが減ります。
「どこで Instant を終わらせるか」を決める
もちろん、どこかのレイヤーでは Instant を「人間向けの日時」に変換する必要があります。
コントローラ層で Instant → ZonedDateTime に変換して DTO に詰める
ビュー層で Instant をフォーマットして文字列にする
など、「どこで変換するか」を決めておくと、Instant と ZonedDateTime がアプリ全体に散らばる、というカオスを避けられます。
まとめ：Instant を自分の言葉で説明するなら
あなたの言葉で Instant を説明するなら、こうです。
「Instant は、“世界共通の絶対的な一瞬”を UTC 基準で表すクラス。
タイムゾーンやローカル時刻の概念を一切持たず、
DB 保存・システム間通信・処理時間計測など、“機械同士の約束事”の土台として使うのに向いている。
人間向けの日時（LocalDateTime / ZonedDateTime / OffsetDateTime）は、
必要なときに Instant から変換して使う、という役割分担を意識すると設計がきれいになる。」