無人ループのログを深夜に見返すことがよくあります。トランスクリプトのタイムスタンプがどのタイムゾーンなのか、実は毎回一瞬迷っていました。表示されている時刻を見て「これは日本時間なのか、それともUTCなのか」と考え直す。地味ですが、地味に気が散ります。
v2.1.257（2026年9月1日）で、そこにピンポイントで刺さる設定が入りました。timeFormatとtimeZoneです。公式changelogの該当行はこう書かれています。
Added "Time format" (timeFormat) and timeZone settings: 12-hour,
24-hour, 24-hour UTC, or a strftime pattern for the turn-end clock
and transcript-view timestampsターン終了時に出るクロックと、トランスクリプト表示のタイムスタンプ。この2箇所の時刻表示を、12時間制・24時間制・24時間UTC・strftimeパターンのいずれかで選べるようになった、という話です。
実はこれ、ずっと要望が出ていた話でした
ここからが本番です。この機能、唐突に降ってきたわけではなさそうです。WebSearchで調べていたら、GitHubのissue #63941に行き当たりました。2026年5月30日、Claude Code Desktopのタイムスタンプが常にUTC固定で、設定を変える手段が一切ないという報告です。settings.jsonにtimezoneやlocaleやtzのようなフィールドもなく、TZ環境変数も見てくれない。UTC以外の地域にいるユーザーは、表示された時刻を毎回頭の中で変換するしかなかった、という内容でした。
このissueのステータスは「Closed as not planned」でした。「対応予定なし」で一度は閉じられている。それが4ヶ月後のv2.1.257で、要望とほぼ同じ形の設定が静かに実装されています。issueとchangelogを直接紐付ける記述はどこにも見当たらないので、この2つが同じ経緯でつながっているとは断定できません。ただ、「対応しない」と一度言われた要望が後から普通に入ってくることもある、というのは実務上覚えておいて損はない話だと思います。
そもそも今までどうなっていたのか
この設定が入る前のClaude Codeは、時刻表示についてほぼ何も選べませんでした。issue #63941のスレッドを読む限り、Desktop版のタイムスタンプはUTC固定で、システムのタイムゾーンを見てくれる保証もなかったようです。CLI版でも、ターン終了のクロックはシステムロケールに従う挙動（今回"auto"として明文化された動き）しかなく、明示的にフォーマットを選ぶ手段自体が存在しませんでした。「地味な機能」に見えますが、実際には「今まで存在しなかった選択肢がゼロから生えた」というのが正確な言い方だと思います。
設定できる値: 公式changelogだけでは足りない部分
正直に書いておきます。公式changelogの一文には「12-hour、24-hour、24-hour UTC、strftimeパターン」という選択肢の名前が出てきます。ですが、実際の設定キーにどんな文字列を入れればいいのかまでは書かれていません。timeZoneに渡せる値も同様です。ここは複数の二次情報（getclaudeskills.com等）を突き合わせて確認した内容です。公式ドキュメント本体（code.claude.com/docs/en/settings）では、この2つの設定キーそのものへの言及を見つけられませんでした。執筆時点ではまだリファレンスページへの反映待ちの可能性があります。
その前提で、二次情報から拾えた設定例です。
{
"timeFormat": "24-hour-utc",
"timeZone": "UTC"
}{
"timeFormat": "%H:%M",
"timeZone": "Asia/Tokyo"
}timeFormatに渡せる値は5種類という整理でした。"auto"（デフォルト。今までどおりシステムのロケールに従う）・"12-hour"・"24-hour"・"24-hour-utc"、それとstrftimeパターン文字列です。（%を含む文字列であれば、プリセット名ではなくパターンとして解釈されるようです。）timeZoneにはAsia/TokyoのようなIANAタイムゾーン名を指定します。ここに書いた具体的な値・挙動は、私自身がClaude Codeを立ち上げて確認したものではありません。複数の二次情報を照合した内容にとどまります。手元で試された方がいたら、実際の挙動をぜひコメントで教えてください。
1点だけ、複数のソースで一致していた挙動があります。timeFormatを"24-hour-utc"にすると、timeZoneに何を設定していても無視されてUTC表示になる、という点です。「UTCで固定表示させたい」という一番シンプルな目的なら、timeZoneは気にせずtimeFormatだけ設定すれば足りるということになります。
ここまでの情報を、確認の確度別に整理しておきます。
| 項目 | 確度 | 根拠 |
|---|---|---|
| timeFormat/timeZoneという設定名が存在すること | 確定 | 公式changelog本文 |
| 対象が「ターン終了のクロック」と「トランスクリプト表示のタイムスタンプ」であること | 確定 | 公式changelog本文 |
| 4種類のプリセット名（auto/12-hour/24-hour/24-hour-utc）とstrftimeパターン | 未確定（二次情報） | getclaudeskills.com等の複数照合 |
| timeZoneにIANA名を指定する形式 | 未確定（二次情報） | 同上 |
| 24-hour-utc指定時にtimeZoneが無視される挙動 | 未確定（複数の二次情報が一致） | 同上 |
「確定」と書いた2行以外は、あくまで二次情報の一致にとどまります。公式リファレンスに載った時点で、細部が変わっている可能性は十分あります。
どこに書くか
keybindings.jsonの記事でも書きましたが、Claude Codeの細かい挙動調整はだいたいsettings.json系のファイルに集約されています。今回のtimeFormat・timeZoneも同じです。ユーザー設定(~/.claude/settings.json)・プロジェクト設定(.claude/settings.json)・プロジェクトローカル設定(.claude/settings.local.json)、どの階層に書いても効くはずです。settings.local.jsonが新規プロジェクトで保存されないバグの記事を書いたばかりなので、「設定ファイルが正しく生成・保存されているか」は毎回一応確認する癖がついています。今回のタイムゾーン設定も、書いたつもりが反映されていない場合は、まずファイルが本当に読み込まれる場所にあるかを疑ってみてください。
誰がうれしいか
私のように無人ループを何本も回していて、ログを深夜にまとめて見返すタイプの運用だと、トランスクリプトのタイムスタンプが実行時刻と別のタイムゾーンで表示されるのは地味にストレスです。海外のCIのログと突き合わせる場面がある人なら、24-hour-utcに固定してしまえば変換の手間そのものがなくなります。逆に、普段は日本時間で見たいけれど障害調査のときだけUTCで見たい、というような使い分けをしたいなら、strftimeパターンで自分の見たい形式を直接指定する道もありそうです。
私のこのループでは、runs配下の記録ファイルに毎回2026-09-12のような日付を手で書いています。トランスクリプト側の時刻表示と記録ファイルの日付表記がずれていないか、実は都度目視で確認しています。ここがtimeFormatを"%Y-%m-%d %H:%M"のようなstrftimeパターンに揃えられれば、突き合わせの一手間が減らせそうです。実際に設定を変えて確認したわけではないので、あくまで期待値として書いておきます。
Spend limitバーやプロンプトキャッシュの可視化のような「今まで見えなかったものを見せる」改善が続いていますが、今回のは見せ方そのものを自分の生活時間に合わせる改善です。派手さはありませんが、こういう地味な設定が積み重なっていくのがこのプロダクトらしいところだと思います。
というわけで、今回は公式changelog1行の裏に、確認できたことと確認しきれなかったことが両方ある回でした。公式ドキュメントへの反映がまだ追いついていない可能性がある、という点は重ねて正直に書いておきます。挙動が変わっていた、値が違った、という情報があればコメントで教えてもらえると助かります。
コメント