1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Claude Code 2.1.318、/schedule警告とログイン期限の変更点ガイド

1
Posted at

はじめに

対象読者は、/schedule のクラウドタスクや claude -p を使って Claude Code を無人実行・スケジュール実行している開発者です。

夜間のスケジュール実行が、エラーも出さずに何もしないまま終わっていた。翌朝ログを見て初めて気づく。無人で Claude Code を回していると、この「静かに止まる」失敗がいちばん厄介です。止まった理由が承認待ちなのか、ログイン切れなのか、ディスク不足なのかが、終了コードからも出力からも読み取れないことがあります。

Claude Code 2.1.317(2026-11-03)と 2.1.318(2026-11-04)には、この種の失敗を表に出す方向の変更がまとまって入りました。/schedule の不要コネクタ警告、claude auth status のログイン期限表示、claude -p の失敗時 exit 1 化などです。どれを手元で確かめられ、どれが changelog の記載どまりなのかを分けて整理します。

この記事で分かること

  • 2.1.317 / 2.1.318 のうち、無人実行に関係する変更点
  • claude auth status でログイン期限(loginExpiresAt)を確認する方法
  • Read ツールの「未変更スタブ」削除で、プロンプトや運用手順のどこが変わるか

前提条件

  • Claude Code 2.1.318 以降
  • 記事中の「確認した」と書いた 3 点は、2026-11-04 JST に Claude Code 2.1.318 のクラウドセッションで確認したものです。それ以外は公式 changelog の記載に基づきます

TL;DR

  1. claude --version で 2.1.318 以降か確認します
  2. claude auth status の JSON に loginExpiresAt が出るので、無人実行の前にログイン期限を見ます(環境変数の長期トークンなど、保存済み claude.ai ログインでない認証では null の場合があります)
  3. /schedule でクラウドタスクを作ったら、頼んでいないコネクタが付いていないか警告を確認します(changelog 記載・手元では未検証)
  4. claude -p は、ディスク・クォータ満杯で記録の書き込みに失敗したとき(text/json 出力)exit 1 を返すようになったので、ラッパー側で終了コードを必ず拾います
  5. Read ツールは未変更ファイルを再度読んでも内容を返すようになりました。「未変更なら再読込が省略される」前提の手順は見直します

2 つのリリースの規模

公式 changelog によると、2.1.317 は 62 件のバグ修正と 8 件の改善、2.1.318 は 47 件のバグ修正と 15 件の改善を含みます(出典: Claude Code changelog)。2 日で 100 件を超える修正が入っているため、全項目を追うより、自分の運用に関係する行だけを拾うほうが現実的です。

版 日付 バグ修正 改善
2.1.317 2026-11-03 62 8
2.1.318 2026-11-04 47 15

無人実行に関係する変更を、どのリスクを減らすものかで分類すると次のようになります。図はすべて changelog の記載を整理したもので、各変更の実際の挙動を手元で確認したものではありません。

手順

1. バージョンを確認する

まずは手元の Claude Code が対象版になっているかを確認します。

claude --version

2026-11-04 JST にクラウドセッションで実行し、次の出力を確認しました。

2.1.318 (Claude Code)

loginExpiresAt などの新しい項目は 2.1.318 で追加されたものなので、これより古い版では以降の手順の出力が一致しません。

2. claude auth status でログイン期限を確認する

2.1.318 で、保存済みの claude.ai ログインがいつ切れるかを claude auth status で確認できるようになりました。changelog の記載は次のとおりです。

Added the date a stored claude.ai sign-in ends to claude auth status (loginExpiresAt) and to claude -p JSON results (credential_expires_at)

claude auth status

一時ディレクトリをカレントにして実行し、JSON に loginExpiresAt キーが含まれることを確認しました。主要なキーだけを抜き出すと次のとおりです(他のキーは省略しています)。

{
  "authMethod": "oauth_token",
  "apiProvider": "firstParty",
  "loginExpiresAt": null
}

値が null なのは、この環境の認証方式が oauth_token(claude setup-token で発行する長期トークンなど)で、保存済み claude.ai ログインの期限として扱われないためと考えられます。ただしこの種のトークン自体にも有効期間があり(公式の認証ドキュメントでは 1 年)、null は期限が無いことを意味しません。期限付きの claude.ai ログインでどのような形式の日付が入るかは、該当する環境が無く確認できていません。

運用上の判断は次のように組むのが無難です。日付形式を確認していないため、比較ロジックは実際の出力を見てから書いてください。

claude -p の JSON 出力にも credential_expires_at が加わったと changelog に書かれていますが、手元では期限付きログインが無く、値の形式は未検証です。

3. claude -p の期限警告と失敗メッセージを把握する

ログイン期限については、警告と失敗時のメッセージも changelog で変わっています。

Added a one-line stderr warning to claude -p text output, starting 10 days before a stored claude.ai sign-in ends

公式 changelog によると、テキスト出力の claude -p は期限の 10 日前から stderr に 1 行の警告を出します。無人実行のラッパーで stderr を捨てていると、この警告は誰にも届きません。ログへ残す設定にしておくと、期限切れの前に気づけます。手元では警告の実物を見ていないため、文言は確認できていません。

期限切れで起動に失敗したときのメッセージも変わりました。changelog の要旨は、期限に達したことを明示し、claude -p では claude auth login と claude setup-token を案内する、というものです。原因が分からないまま再試行を繰り返す状況は、これで減ると考えられます。

4. 終了コードを拾う

無人実行で最も効く変更は、2.1.317 の次の修正だと筆者は見ています。

Fixed claude -p exiting 0 when a full disk or quota lost its transcript or ~/.claude.json writes; it now prints an error and, in text and json output, exits 1.

ディスクやクォータが一杯で会話記録や ~/.claude.json の書き込みに失敗しても、以前は exit 0 で終わることがありました。changelog では、エラーを表示してテキスト・JSON 出力時に exit 1 を返すよう修正されたとしています。同じ行で「NFS のエクスポートが一杯の場合は検出できないことがある」とも注記されています。

終了コードを見ずに「コマンドが終わったら成功」とみなすラッパーは、この修正の恩恵を受けられません。cron やジョブランナーから呼んでいる場合は、非ゼロ終了を通知に繋げておきます。

2.1.318 では設定ファイルまわりも変わっています。changelog によると、非対話起動で ~/.claude.json が不正な JSON だった場合、以前は既定値で置き換えていましたが、今後は起動を失敗させ、復旧方法を表示し、ファイルには手を付けません。あわせて、claude -p や SDK アプリによる無人実行で、内容に変更が無いときは毎回 ~/.claude.json を書き直さないよう改善されています。設定が黙って初期化される経路が 1 つ減り、代わりに起動失敗として表に出るようになったので、ここでも終了コードの確認が前提になります。

5. /schedule のコネクタ警告を確認する

2.1.317 で /schedule に警告が加わりました。

Added a warning to /schedule when a new cloud scheduled task gets connectors you did not ask for, with how to remove them

新しいクラウドスケジュールタスクに、依頼していないコネクタが付いた場合に警告し、外し方も案内するという内容です。無人タスクに不要なコネクタが付いていると、意図しない外部サービスへのアクセス権を持ったまま定期実行されることになります。作成直後に警告が出ていないかを見て、出ていれば案内どおりに外すのが基本の手順になります。手元ではクラウドタスクを新規作成しておらず、警告画面は確認していません。

同じ 2.1.317 で、/schedule でタスクを作成・更新した後に、次回実行時刻とリンクが結果に含まれない不具合も修正されています。作成後に次回実行時刻が表示されるかは、登録できたかを確かめる手がかりになります。

2.1.318 では deniedMcpServers の照合範囲も広がりました。changelog によると、URL で指定した拒否エントリが、上流 URL が一致する Anthropic 提供サーバーや、クラウドセッション・セルフホストランナー上のコネクタにも効くようになりました。コネクタ自身の URL が渡されない環境ではコネクタ名で拒否するよう案内されています。URL 照合が実際にどのコネクタに効くかは、手元では検証していません。

6. Read ツールの二度読みを確認する

2.1.317 で、Read ツールの挙動が変わりました。

Removed the Read tool's "file unchanged since your last Read" stub: reading an unchanged file again returns its content

以前は、同じセッションで未変更のファイルをもう一度 Read すると「前回の Read から変更なし」というスタブが返り、内容そのものは返りませんでした。2.1.317 以降は、未変更でも内容が返ります。

2.1.318 のクラウドセッションで、3 行の未変更ファイル(probe.txt)を同一セッションで 2 回続けて Read し、2 回目も内容がそのまま返ることを確認しました。1 回目・2 回目とも、行番号付きで 1 line1、2 line2、3(空行)の形で返っています。

これで影響を受けるのは、長いセッションの途中で同じファイルを読み直す使い方です。以前は再読込してもスタブしか返らないため、前に読んだ内容が圧縮などでコンテキストから消えていると、読み直しても中身を得られない可能性がありました。今後は読み直せば内容が返ります。一方で、同じ大きなファイルを何度も読むと、そのたびに内容がコンテキストに載ります。手順書やプロンプトで「必要な範囲だけ offset と limit で読む」と決めている運用は、引き続き有効です。

7. その他、無人実行に関係する変更

ここまでの手順に含めなかった項目を、changelog の記載から挙げます。いずれも手元では未検証です。

版 変更 無人実行への関係
2.1.317 Web・シェルツールがアカウントのメールアドレスをネットワークに送る前に確認を求める 無人実行では確認が承認待ちになる可能性があり、該当する処理があるか事前に把握が必要
2.1.317 Agent SDK のフックコールバックに onFailure: "block" を追加 コールバックが失敗したときに処理を通さず止められる
2.1.317 メイン会話と別モデルのサブエージェントが、セッションの effort ではなくそのモデルの保存済み effort か既定値を使う サブエージェントのコストや出力の傾向が変わる可能性がある
2.1.317 self-paced な /loop の起床が、リクエストの項目欠落でスケジュールされないことがある不具合を修正 ループ実行が途中で止まる経路の 1 つが塞がれた
2.1.318 バックグラウンドのサブエージェントが、シェルコマンドを 3 分後にバックグラウンドへ移す(全プロバイダ) 長いコマンドの実行中にプロンプトキャッシュが切れにくくなる

メールアドレス送信前の確認は、対話セッションでは安全側の変更です。ただ無人実行では、確認を求められた時点で応答する人がいません。実際にどの操作で確認が出るのかは手元で確かめていないため、無人タスクで外部への送信を伴う処理を組んでいる場合は、更新後の初回実行を見ておくことをおすすめします。

無人運用の視点から見た変更点

筆者は、このブログの執筆と公開を Claude Code のスケジュール実行で無人運用しています。その中で、承認ダイアログで止まったセッションが何も残さずに終わり、スロットが空振りする事故が 2 回ありました。どちらもエラーとしては記録されず、後から「何も起きていない」ことに気づいて判明しています。

この経験から、無人運用で優先して潰すべきなのは、派手なエラーよりも静かな失敗だと考えています。その観点で今回の 2 リリースを見ると、次の 3 つは方向が一致しています。

  • ディスク・クォータ満杯で記録の書き込みに失敗した claude -p が、exit 0 から exit 1(text/json 出力)になった
  • ログイン期限が claude auth status と JSON 出力、stderr 警告で見えるようになった(期限切れを事前に知れる)
  • /schedule が頼んでいないコネクタを警告する(権限の広がりが作成時に見える)

どれも、ラッパーやスケジューラ側が終了コードと stderr を拾っている前提で効く変更です。逆に言えば、出力を捨てている構成のままでは、今回の改善は何も届きません。更新のついでに、無人実行のラッパーが「非ゼロ終了で通知する」「stderr をログに残す」の 2 点を満たしているかを確認するのが、最も手間に対して効果の大きい作業だと筆者は見ています。

一方で、メールアドレス送信前の確認のように、対話では安全側でも無人では承認待ちを生みうる変更も同じリリースに入っています。安全側の変更がすべて無人運用にとっても安全とは限らない点は、更新のたびに意識しておく必要があります。

トラブルシューティング

Q1: claude auth status に loginExpiresAt が出てこない

A: 2.1.318 で追加された項目です。claude --version で版を確認し、2.1.318 より古ければ更新してください。

Q2: loginExpiresAt が null になる

A: この環境(authMethod が oauth_token)では null を確認しました。保存済み claude.ai ログインの期限として扱われないためと考えられますが、長期トークン自体にも有効期間があるため、null を期限なしと読まないでください。期限付きの claude.ai ログインでの表示は未検証です。

Q3: 更新後に非対話起動が失敗するようになった

A: changelog によると、2.1.318 から ~/.claude.json が不正な JSON の場合、既定値で置き換えずに起動を失敗させ、復旧方法を表示します。エラー出力の案内に従ってファイルを復元してください。

検証できなかった範囲

以下は公式 changelog の記載に基づくもので、手元では確認していません。

  • /schedule の不要コネクタ警告の実際の表示(クラウドタスクを新規作成していないため)
  • Web・シェルツールがメールアドレスを送る前の確認の実際の挙動
  • Agent SDK の onFailure: "block" の挙動
  • claude -p の期限 10 日前の stderr 警告と、JSON 出力の credential_expires_at(期限付きログインの環境が無いため)
  • deniedMcpServers の URL 照合がどのコネクタに効くか
  • バックグラウンドのサブエージェントがシェルコマンドを 3 分でバックグラウンドへ移す挙動

確認できたのは、claude --version が 2.1.318 を返すこと、claude auth status の JSON に loginExpiresAt(値は null・authMethod は oauth_token)が含まれること、未変更ファイルを同一セッションで 2 回 Read して 2 回目も内容が返ることの 3 点です。

参考

関連記事

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?