スケジュールタスクが SUCCEEDED のまま成果を出さなくなったら、最初の1分で外への通信を疑います

GitHub の Issue #93562 を読んだ夜、自分の定期タスクの実行一覧を開き直しました。どの行も SUCCEEDED で、赤い行は一つもありません。

それでも胸のあたりが落ち着きませんでした。報告されていた症状は——実行は成功と記録されるのに、成果物が何も生まれない——というものだったからです。

最初にお伝えしたいのは、実行一覧の色は、成果が出たことの証拠にならないという点です。外への通信が止まっていないかを最初の1分で見分けるプローブと、成果物の鮮度を別の目で見る小さなチェックを、以下に書き残します。

報告されていた症状

Issue の報告者は、毎日走らせていた定期タスク18本が、2026年9月11日からすべて成果を出さなくなったと書いています。スケジュールは発火し、記録は SUCCEEDED のまま。ただし各回の最初の外向き通信が、プロキシの CONNECT で 403 になっていたそうです。

設定は「ネットワーク通信を許可」かつ「ドメイン許可リスト: すべてのドメイン」でした。それでも許可リストの外のホストは通らず、デスクトップ側のローカル VM から試しても同じだった、と報告されています。同じスレッドには、同じ症状を確認したという声が複数並んでおります。

私が確認できたのは、ここまでです。原因が何か、いつ直るのかは、Issue の記述からは分かりません。取得した時点で、この Issue は open のままでした。

大事なのは原因の特定よりも、自分のタスクが同じ状態になったとき、何分で気づけるかのほうだと考えています。

最初の1分で見る、疎通プローブ

壁紙アプリの運用を定期タスクに任せるなら、最初の手順はたいてい外部の API やサイトへ出ていくことです。そこが塞がれると、後ろの手順はすべて空振りになります。ですから、タスクの冒頭で「出られるか」だけを先に確かめ、結果を必ず1行残すようにしました。

#!/usr/bin/env bash
# egress_probe.sh — 外部ホストへ出られるかを 1 行ずつ記録し、1 つでも塞がれていれば exit 1
# 使い方: ./egress_probe.sh https://api.github.com https://example.com
set -u
LOG="${PROBE_LOG:-./egress_probe.log}"
blocked=0
 
probe() {
  local url="$1" out code connect rc
  # %{http_connect} はプロキシが返した CONNECT の応答コード（直結なら 000）
  out=$(curl -sS -m 15 -o /dev/null -w '%{http_code} %{http_connect}' "$url" 2>&1)
  rc=$?
  code=${out%% *}; connect=${out##* }
  if [ "$rc" -eq 56 ] || [ "$connect" = "403" ]; then
    echo "BLOCKED(proxy) rc=$rc connect=$connect $url"; return 1
  elif [ "$rc" -eq 6 ]; then
    echo "NO-DNS rc=$rc $url"; return 1
  elif [ "$rc" -ne 0 ]; then
    echo "FAIL rc=$rc $url"; return 1
  fi
  echo "OK http=$code connect=$connect $url"
}
 
echo "== $(date -u +%FT%TZ) start (${#@} hosts)" >> "$LOG"
for u in "$@"; do
  line=$(probe "$u") || blocked=$((blocked+1))
  echo "$line" | tee -a "$LOG"
done
echo "== end blocked=$blocked" >> "$LOG"
[ "$blocked" -eq 0 ]

なぜこう書いたのかを3点だけ補います。

• local の宣言と代入を別の行に分けているのは、rc=$? に curl の終了コードを残すためです。local out=$(curl ...) と一行で書きますと、$? には local 自身の結果（常に 0）が入り、56 も 6 も見えなくなります。
• curl -w '%{http_connect}' を使うと、プロキシが返した CONNECT の応答コードが取れます。報告にあった CONNECT tunnel failed, response 403 は curl の終了コード 56 と対応しますから、この二つのどちらかを見れば「プロキシが止めた」と言い切れます。
• 最後の [ "$blocked" -eq 0 ] で、一つでも塞がれていれば exit 1 を返します。タスクの指示文には「プローブが失敗したら、BLOCKED と書いて終わる。成果物を作ったふりをしない」と一文入れておきます。

結果の読み分け

プローブが返す行は、次の三つに分けて読んでいます。

報告者は IMAP（ポート 993）が名前解決すらできなかったとも書いています。許可リストが効くのは CONNECT を使う HTTP(S) だけで、メールのポートや SSH は別の話になります。ここを取り違えますと、設定を「すべてのドメイン」に直したのに IMAP だけ動かない——という場面で、長く迷ってしまいます。

成果物の鮮度を、実行記録とは別に見る

プローブは「今日出られるか」しか教えてくれません。夜のうちに起きた失敗に朝気づくには、成果物の更新時刻を直接見るのが確実です。

#!/usr/bin/env bash
# check_fresh.sh — 成果物の更新時刻が古すぎないかを見る（実行記録の色は見ない）
# 使い方: ./check_fresh.sh <ファイル> [許容時間(時間)]   例: ./check_fresh.sh daily_report.md 26
f="${1:?file required}"; max_h="${2:-26}"
[ -e "$f" ] || { echo "MISSING $f"; exit 2; }
now=$(date +%s)
# GNU stat と BSD stat の両対応
mtime=$(stat -c %Y "$f" 2>/dev/null || stat -f %m "$f")
age_h=$(( (now - mtime) / 3600 ))
if [ "$age_h" -gt "$max_h" ]; then echo "STALE ${age_h}h > ${max_h}h $f"; exit 1; fi
echo "FRESH ${age_h}h $f"

許容時間を24時間ではなく26時間にしているのは、実行時刻が少しずれた日に誤報を出さないためです。手元で更新時刻を作り分けて動かしたところ、更新直後は FRESH 0h、40時間前のファイルは STALE 40h > 26h で終了コード 1、存在しないファイルは MISSING で終了コード 2 になりました。

終了コードを三通りに分けておくと、朝の確認が「赤い行があるか」から「どの種類の赤か」に変わります。

手元で測れたことと、測れなかったこと

2026年10月17日の午後、Cowork のローカル VM から7つのホストへプローブ相当の curl を打ちました。結果は次のとおりです。

つまり私の環境では、報告にあるような 403 は再現しませんでした。connect の欄も 000 のままで、プロキシを経由した形跡は見えていません。存在しないホスト名には終了コード 6 が返り、NO-DNS の行が出ることだけを確かめられました。

ですから BLOCKED の行が実際にどう表示されるかは、Issue に載っているログ（curl: (56) CONNECT tunnel failed, response 403）に頼っております。ここは私の手元で見た光景ではない、と正直に書き添えておきます。

今日から置く1つ

定期タスクの冒頭に、プローブを1回だけ置いてみてください。ホストは、そのタスクがいちばん最初に呼ぶ1つか2つで十分です。

連携フォルダの扱いで詰まった経験は 連携フォルダに置いたロックが、二度目の無人実行を締め出すまで に、検査が落ちない形になっていた経験は 毒入りサンプルを置くまで、無人の検査は一度も落ちていませんでした に書き残しております。どちらも、緑の記録を疑い直す話です。

記録の色は参考に、朝いちばんに見るのは成果物の更新時刻。 この線引きだけは、外の仕組みがどう変わっても手放さないでおこうと、いまも感じています。