delegateAccessTokenCreate がexpiresIn を返すようになった委任トークン（delegate token）を作る際、レスポンスに「あと何秒で失効するか」が含まれるように。特に有効期限を指定せず親トークンの TTL を継承させたときの、これまで知る術がなかった失効時刻が判明する。
delegateAccessTokenCreate mutation が返す DelegateAccessToken 型に expiresIn フィールドが追加された。トークンは作れるが、レスポンスに有効期限の情報が無い。特に有効期限を指定しなかった場合、いつ切れるか把握する手段が無かった。
レスポンスの expiresIn に「あと何秒で失効するか」が入る。これで更新タイミングの設計や監視が可能に。
expiresIn 入力で TTL（有効期間）を指定できる。今回追加されたのはレスポンス側の expiresIn で、これは「失効までの残り秒数」を表す。（上記コードのフィールド以外の具体的なスキーマ詳細は記事に記載なし）
記事が「特に有益（particularly beneficial）」と名指ししているのが、入力の expiresIn を指定しなかったケース。このとき委任トークンは 親トークンの TTL（Time to Live）を継承する。
expiresIn がその空白を埋めるのが、この更新の核心。| 項目 | 従来 | 今回（2026-04〜） |
|---|---|---|
| expiresIn 指定時の失効把握 | 手計算 入力値から自分で推定 | 確定 レスポンスの値で把握 |
| expiresIn 省略時（親 TTL 継承） | 不可 失効時刻を知る術が無い | 判明 残り秒数が返る |
| REST delegate endpoint との整合 | REST 側にのみ有効期限データあり | 整合 GraphQL でも同等のデータ |
| 値の形式 | — | 失効までの残り秒数（seconds remaining） |
| 対象 API バージョン | — | 2026-04 以降 |
この expiresIn フィールドは GraphQL Admin API version 2026-04 以降で利用可能。古いバージョンを呼んでいるアプリは API バージョンの更新が必要。
委任トークンを発行するアプリが対象。発行時のレスポンスに新フィールドが含まれる。対象プラン等の追加条件は記事に記載なし。
expiresIn は失効までの秒数。失効時刻として保持したいなら、取得時刻 + expiresIn で自分でタイムスタンプ化する。タイムゾーン非依存で扱える反面、受信時刻の基準を決めておく必要がある。
入力 expiresIn を省くと子は親 TTL を継承する。この場合の失効把握が今回の最大の利得。明示指定運用なら恩恵は限定的だが、継承運用なら更新ロジックを組み直せる。
REST Admin API の delegate エンドポイントで取れていた有効期限データと整合する。REST → GraphQL 移行時に、失効情報の欠落という非互換が解消される。
失効を「使ってから 401 で気づく」のではなく、残り秒数を見て事前にリフレッシュする設計が可能に。トークン失効起因の断続的な失敗を予防できる。
expiresIn は 2026-04 以降のバージョンでないと返らない。古い API バージョン固定のアプリは、まず呼び出しバージョンを上げる必要がある。クエリに expiresIn を追記しただけでは旧バージョンでは効かない点に注意。既存トークンへの遡及や他フィールド仕様は記事に記載が無いため、実スキーマで検証すること。
expiresIn を保存し、残り秒数が閾値を切る前にトークンを再発行するジョブを組む。expiresIn で失効時刻を算出してキャッシュ。残り秒数を直接保持すると経過で陳腐化するため、絶対時刻に正規化して持つ。delegateAccessTokenCreate を使い、レスポンスの expiresIn で REST と同等の失効情報を取得。expiresIn をログ・メトリクスに記録し、残り秒数が短いトークンをダッシュボード／アラートで可視化。delegateAccessTokenCreate のレスポンスに 失効までの残り秒数 expiresIn が追加（2026-04 以降）。