Claude Code v2.1.310で、Monitor toolとplugin monitorsが追加されました。
長時間動く無人タスクを放置して、いつ終わるのか分からなくなることがあります。今回の機能は、その待ち時間を監視するための入口になりそうです。
Monitor toolとは
v2.1.310のリリースノートでは、Bedrock・Vertex・FoundryでMonitor toolとplugin monitorsが追加されたと説明されています。テレメトリまたは非本質的な通信を無効にしている場合にも利用できます。
ここで大事なのは、監視機能が増えたことだけではありません。長いforeground sleepも同じ環境ではブロックされます。つまり「とりあえず長く待つ」という無人処理の設計に、明確な境界が入ったということです。
無人実行で困る長い待ち時間
たとえば、テスト環境の準備が終わるまで待つ処理を書いたとします。
while not ready():
time.sleep(300)
これでも動きますが、準備が失敗していた場合は、5分ごとに確認し続けます。処理が止まっているのか、まだ待つべきなのかも分かりにくいです。
無人タスクでは、待つこと自体を成功条件にしてはいけません。確認回数、最大待ち時間、失敗時の記録を決めておきます。
まずは停止条件を決める
私が無人ループで最初に決めるのは、次の3つです。
- 何を確認できたら成功なのか
- 何分、または何回まで待つのか
- 失敗したとき、どこへ記録して次回どう再開するのか
今回のMonitor toolは、この考え方と相性が良い機能です。監視を追加するだけでなく、監視結果をチェックポイントや実行ログに残せる形にしておくと、次の実行で続きから扱えます。
テレメトリを無効にしている場合の注意
テレメトリを無効にしても、すべての監視が同じように使えるとは限りません。v2.1.310の説明には、Monitor toolとplugin monitorsが利用できる条件が書かれています。
会社の環境やゲートウェイを通している場合は、まず実行環境で機能が有効か確認してください。公式リリースノートだけで、自分の構成でも同じ動作をすると決めつけないことが重要です。
まとめ
Claude Code v2.1.310では、Monitor toolとplugin monitorsが追加されました。長いforeground sleepがブロックされる点も含め、無人実行に「監視」と「停止条件」を持ち込む変更です。
待ち続ける処理は簡単ですが、壊れたときに原因が残りません。監視結果、最大待ち時間、再開位置を一緒に設計しましょう。簡単ですね。
コメント