ログファイルや API レスポンスでよく見かける「1718198400」のような10桁ほどの数字。これは Unix タイムスタンプ と呼ばれる時刻の表現方法です。
人間にとっては「いつのこと？」と一目で分からない形式ですが、コンピューターにとっては最も扱いやすい時刻表現で、世界中のサーバー・データベース・API で標準的に使われています。この記事では、Unixタイムスタンプの仕組みと、実務での扱い方を一気にまとめます。
Unixタイムスタンプとは何か
Unixタイムスタンプは、1970年1月1日 00:00:00 UTC（協定世界時）からの経過秒数 として時刻を表す方式です。エポック秒、POSIX時間、Unix時間とも呼ばれます。
例：
0→ 1970年1月1日 00:00:00 UTC（起点）1000000000→ 2001年9月9日（10億秒記念日）1718198400→ 2024年6月12日 12:00:00 UTC
本サイトの タイムスタンプ変換ツール で、数値と日時を相互変換できます。
なぜ「1970年1月1日」が起点なのか
この日付は、Unix オペレーティングシステム（現在の macOS や Linux のルーツ）が開発された時期に近いことから選ばれました。1971年に Unix 第1版が登場し、その内部で時刻を扱う基準として「キリのいい日付」が必要だったため、1970年1月1日 00:00:00 UTC がエポック（起点）として定められました。
これにより、すべての時刻は「起点からの秒数」という単一の整数で表現できるようになりました。タイムゾーン、夏時間、月の長さの違いといった面倒な計算を、システムレベルで一切無視できる強力な設計です。
Unixタイムスタンプを使う利点
- 計算が単純：差を取れば経過秒数、加算すれば未来時刻、というシンプルな算術で時刻計算ができる。
- タイムゾーン非依存：すべてUTCを基準にしているため、サーバーが世界中のどこにあっても同じ値を共有できる。
- 並び替えが容易：数値として扱えるので、データベースのインデックス・ソートで効率的。
- 容量が小さい：32bitまたは64bit整数1つで時刻を表現できる。
単位の違い — 秒・ミリ秒・マイクロ秒
Unixタイムスタンプには、精度の異なる複数の単位があります。同じ瞬間を表していても、桁数で見分けられます。
- 秒：10桁前後（例：
1718198400）。古典的なUnix時間。Linux・PHP・MySQLなどで主流。 - ミリ秒：13桁前後（例：
1718198400000）。JavaScript・Java・MongoDB などで使われる。1秒を1000分割。 - マイクロ秒：16桁前後。一部の高精度ログで使用。
- ナノ秒：19桁前後。Go言語の
time.Time、Kubernetes ログなどで使用。
変換時のコツ：桁数を見れば一発で単位が分かります。13桁ならミリ秒、10桁なら秒。本サイトのツールもこれを自動判別します。
各プログラミング言語での扱い方
JavaScript
- 現在時刻（ミリ秒）：
Date.now() - 現在時刻（秒）：
Math.floor(Date.now() / 1000) - 秒 → 日時：
new Date(秒 * 1000)（秒を入力する時は1000倍が必要） - ISO形式に変換：
new Date(...).toISOString()
Python
- 現在時刻（秒、浮動小数点）：
time.time() - 整数の秒：
int(time.time()) - 秒 → datetime：
datetime.fromtimestamp(秒) - UTC で扱う：
datetime.fromtimestamp(秒, tz=timezone.utc)
PHP
- 現在時刻（秒）：
time() - 秒 → 文字列：
date("Y-m-d H:i:s", 秒) - 文字列 → 秒：
strtotime("2026-06-13")
SQL（MySQL）
- 現在のUnix時間：
UNIX_TIMESTAMP() - Unix時間 → 日時：
FROM_UNIXTIME(秒) - 日時 → Unix時間：
UNIX_TIMESTAMP('2026-06-13')
UTC とローカルタイムの違い
Unixタイムスタンプ自体は UTC（協定世界時）を基準 にした単一の値で、タイムゾーンの情報を含みません。しかし、人間が見る日時はローカルタイムで表示したいことが多いです。
ここで重要なのが 「保存はUTC、表示はローカルタイム」 という原則です。
- データベースには Unix時間 or UTC で保存：地域に依存しないため、グローバルサービスでも一貫した管理ができる。
- 表示時にユーザーのタイムゾーンに変換：ブラウザのJavaScriptなら自動的にローカルタイムで表示される。
- API のレスポンスは UTC で統一：「
2026-06-13T12:00:00Z」のように末尾のZでUTCを明示するのが安全。
日本時間（JST）はUTCより9時間進んでいるため、Unixタイムスタンプを日本時間に変換する場合は、UTC時刻に9時間（32400秒）を加算する形になります。
2038年問題 — まだ覚えておく価値のある話
Unixタイムスタンプを 32bit符号付き整数 で扱うシステムでは、表現できる最大値が 2147483647 までです。これは 2038年1月19日 03:14:07 UTC に到達します。
この時刻を超えると、32bitシステムは内部で数値オーバーフローを起こし、時刻が 1901年12月13日 に戻ってしまうという深刻なバグが発生します。「2038年問題（Year 2038 Problem）」と呼ばれる課題です。
対策：
- 64bit システムへの移行：64bit整数なら約2920億年先まで表現でき、実質的に永遠に問題なし。現在の主流のサーバー・スマホはほぼ64bit。
- 古い組込み機器の確認：センサー、決済端末、医療機器など、長期運用される組込み機器は要注意。2038年までに更新計画を立てる。
- 古いデータベースの設計確認：MySQL の
TIMESTAMP型は内部で32bit整数を使っており、影響を受ける。DATETIME型に変えるか、64bit化対応が必要。
実務での使いどころ
ログ解析
サーバーログには各イベントのタイムスタンプが記録されています。grep や awk でログを絞り込む時、Unixタイムスタンプの範囲指定を使うと正確です。
API のキャッシュ制御
HTTPヘッダーの Last-Modified や Expires は、Unixタイムスタンプベースで実装されています。クライアント側で「N秒前以降のデータか」を簡単に判定できます。
セッション管理
ユーザーのログインセッションの有効期限を「Unix時間で何秒後まで」と保存しておくと、現在時刻との比較で簡単に有効性を判定できます。
JWT (JSON Web Token)
JWTの中身には iat（発行時刻）、exp（有効期限）が Unixタイムスタンプ（秒） で埋め込まれます。これにより各言語のサーバーが互換性を保てます。
変換時のよくある落とし穴
- 秒とミリ秒を取り違える：13桁を10桁の前提で変換すると、はるか未来の日付になる。逆もまた然り。
- タイムゾーンの考慮漏れ：UTCで保存された値をローカルタイムだと思って読み解くと、9時間ずれた解釈になる。
- うるう秒：地球の自転速度の微調整で稀に挿入される「うるう秒」は、Unixタイムスタンプではほとんどの実装で扱われない（POSIX定義により無視）。1秒未満の精度が必要なシステムでは別途検討が必要。
- 古い API の負の値：1970年以前を表す負の値が含まれる古いデータは、一部の言語・DBで正しく扱えないことがある。
関連ツール
- タイムスタンプ変換ツール：Unix時間⇔日時を双方向で変換。秒・ミリ秒の自動判別。
- ハッシュ生成ツール：データの一意性チェック、APIキーの生成等で活用。
- UUID生成ツール：時刻ベースのID生成や、タイムスタンプと組み合わせた識別子作成に。
まとめ — 「数字に見えても、ただの秒数」
Unixタイムスタンプは一見すると「謎の数字の羅列」ですが、「1970年1月1日からの秒数」 という1行さえ覚えていれば、ログ・API・データベースのどんな場面でも対応できます。
ミリ秒との見分けは桁数で。タイムゾーンは「保存はUTC、表示はローカル」。それさえ意識すれば、現代のサーバー開発で時刻関連のトラブルに遭うことはほとんどなくなります。