Shiori Demo

Appearance

時計のズレ（Clock Skew）が引き起こす認証即死とインフラ時刻同期・トークン時間バッファ設計 ​

1. 概要 ​

分散システムや自律型AIエージェント（特にコンテナやVM、WSLなどの仮想環境で稼働するもの）において、時刻同期のズレ（Clock Skew / Clock Drift）は、OAuthやJWT（JSON Web Token）認証を完全に沈黙させる最も厄介な「インフラの死角」である。 Claude Code（anthropics/claude-code#6030 や #6083）等のインシデント事例は、システム時計のわずかなズレがトークン検証を失敗させ、エージェントを無限認証ループや即座のクラッシュへと陥らせる構造を示している。 本稿では、この認証崩壊のメカニズムと、dev-infra および mcp-launcher（トークン発行）が実践している時刻同期・バッファ設計の有効性について考察する。

2. インシデントの分析：時計のズレによる認証崩壊 ​

2.1. JWT（iat / exp）検証の厳密性とエラーの温床 ​

GitHub APIや各社APIゲートウェイなどのセキュアなエンドポイントでは、セキュリティ上の理由から、提示された認証トークン（JWT等）の有効期限を極めて厳密に検証する。

  • iat (Issued At: 発行時刻): トークンが生成された時刻。現在時刻より「未来」の iat を持つトークンは、改ざんや未来の不正使用を防ぐため、即座にリジェクトされる。
  • exp (Expiration Time: 有効期限): トークンの失効時刻。

ローカル環境（ホストPC、WSL、Dockerコンテナ、またはGCP VM）のシステム時計が、ネットワークの遅延やスリープ復帰時の同期ミスによって、サーバー（API側）の時計と「数分以上ズレる」現象は頻繁に発生する。

時計がズレている場合、以下のエラーが発生する。

  • 時計が進んでいる場合: 生成したトークンの iat が未来の時刻とみなされ、Invalid token signature や iat in the future エラーでリジェクトされる。
  • 時計が遅れている場合: 生成したトークンが、サーバーから見ると「すでに有効期限を過ぎている（Expired）」とみなされ、即座にリジェクトされる。

エージェント（LLM）は「自分の時計がズレている」という物理的な事実をメタ認知できないため、このエラーに遭遇すると、認証コードや暗号署名処理のバグだと誤認し、関係のないコードの書き換えとエラーを繰り返す無限デバッグループ（Token Doom Loop）に陥る。

2.2. コードレベルの妥協パッチ（CLOCK_SKEW_SECS = 300） ​

この問題に対し、プログラム側では「サーバーとクライアントの時計が最大5分ズレていても大目に見る」という、CLOCK_SKEW_SECS = 300（5分の許容バッファ） をハードコードする対症療法が取られた（claude-code#6083）。 しかし、休止状態から復帰したWSLや、NTPが未同期のGCP VMでは、時計が数時間以上平然とズレるため、コードレベルの5分バッファは根本的な解決策にはならない。

3. インフラNTP同期とJWTバッファによる堅牢な設計 ​

mcp-launcher（トークン供給）と dev-infra（GCP環境構築）の組み合わせは、この時計のズレによる認証即死を、インフラとアプリケーションの「二重のセーフティ」で防止している。

3.1. インフラ層：Chrony（NTP）によるミリ秒単位の強制同期 ​

  • dev-infra（GCP VM等のIaCテンプレート）内の startup-script.sh.tpl にて、VMのブート時および稼働中に chronyd 等の精密なNTP同期デーモンを自動セットアップ・強制実行する。
  • スリープやインスタンス再起動時に時計がドリフトするのをインフラレイヤーで未然に防ぎ、常に世界標準時（UTC）とミリ秒レベルで同期させる。

3.2. アプリケーション層：JWT iat の逆補正（時間バッファ）設計 ​

  • mcp-token がGitHub Appの鍵からJWTトークンをミント（生成）する際、生成時刻（iat）を単純な現在時刻（time.Now()）にするのではなく、意図的に 「数分前の過去の時刻（例：現在時刻 - 60秒）」 として逆補正して署名・送信する。
  • この設計により、APIサーバー側の時計がクライアントよりわずかに遅れていても、iat is in the future（未来の発行トークン）と誤認されてリジェクトされるリスクを、数学的・構造的に完全に回避する。

4. 結論 ​

AIエージェントの自律稼働において、システム時刻のズレは「AIのロジックでは解決できないインフラのトラップ」の典型例である。 dev-infra におけるNTP強制同期（Chrony）と、mcp-launcher におけるJWT発行時刻の「逆補正バッファ」という二重の防衛策は、AIエージェントに「狂いのない正確な時間軸」を提供し、認証崩壊によるゾンビ化を防ぐための、極めて実践的で美しいインフラ協調設計であるといえる。

5. 参考文献 / 一次情報 ​

Shiori pointer-RAG automation experiment.

Copyright © 2026 masuda-masuo