前夜に走らせた定期実行のログを、翌朝いちばんに開く習慣があります。ある朝に開いたファイルは、見出しの一行だけで終わっていました。処理が落ちたのではなく、途中で待っていたのです。
原因を辿ってみますと、設定の書き間違いではありませんでした。私がその作業を置いた場所が違っていました。手元で対話しながら動かすぶんには何の問題もない手順を、誰も画面を見ていない時間帯へ、そのまま移していたのです。
Cowork と Claude Code は、どちらも同じ Claude が動きます。ですから「どちらが優れているか」という問いは、私の場合ほとんど役に立ちませんでした。役に立ったのは、その作業の途中で人の承認が挟まってよいのか、挟まっては困るのか——この一点だけでした。
承認が挟まってよい作業と、挟まると止まる作業
承認は安全装置です。人が画面を見ている面では、期待どおりに働きます。消してはいけないファイルに手が伸びたとき、いちど止めてくれるからです。
ところが同じ安全装置は、誰も見ていない時間帯には別のふるまいに変わります。止まるのではなく、待ち続けます。待っているだけですので、例外も残らず、失敗として通知もされません。翌朝のログが見出しだけで終わっている、というかたちで初めて分かるのです。
この「待ちが終端になる」現象は、私の手元に限った話ではないようです。普通の拒否ルールを一つ置いただけで、cd と相対パスの読み取りを含む複合コマンドが毎回承認を求めて止まる、という報告が上がっています（claude-code Issue #91650）。危険な動作そのものではなく、コマンドの組み立て方に判定が当たってしまう例です。定期実行を組む方には、他人事ではない挙動だと思います。
無人の面に置いて、私が引き上げた作業
個人開発で長く運用している壁紙アプリでは、配信前の素材整理に決まった手順があります。対話でその手順を組み上げたとき、私はうまくいった勢いのまま、同じ手順を定期実行へ移しました。
結果は芳しくありませんでした。ファイルの読み書きに専用の編集ツールを使っていたため、実行のたびに許可を尋ねられ、そこで終わっていたのです。対話の面では「はい」を押すだけの一手でしたが、無人の面ではそれが終端でした。
いま思えば、移したのは手順ではなく、対話を前提にした癖のほうだったのだと気づきます。そこで線を引き直しました。
無人の面には、途中で人に尋ねる手順を一つも残しません。 尋ねる必要がある作業は、尋ねる直前で切って、対話の面へ渡します。
書き換えの中身は、ファイル操作をシェルの cat と sed に寄せる、という地味なものでした。auto モードの内部指示にも、専用の編集ツールではなく sed や短いヒアドキュメントで書き換えるよう記された箇所が見つかったという報告があり（Issue #88041）、方向としては同じだと感じました。ただ私の理由は速さではなく、承認の入り口を一つ減らせることにあります。
いま使っている置き分けの基準
機能の一覧を並べて比べるのはやめました。代わりに、作業の性質を一行で言い切って、置く場所を決めています。
| 作業の性質 | 置く場所 | そう決めた理由 |
|---|---|---|
| 毎日同じ時刻に同じ形で回す（素材の書き出し、集計の更新） | Cowork の定期タスク | 承認を挟まない形に最初から書き切れる |
| 途中で人の判断が要る（公開してよいか、消してよいか） | 対話の面（Cowork か Claude Code） | 承認が安全装置として本来の働きをする |
| 手順がまだ固まっていない、試している段階 | Claude Code | 失敗を見ながらその場で直せる |
| リポジトリに手を入れる（差分を読んで直す） | Claude Code | 差分を確かめてから止める判断ができる |
| 外部サービスとの接続設定を直す | 対話の面 | 再認証や接続状態の確認に画面が要る |
| OS やアプリの更新を当てた直後 | どちらも動かさず、まず手で確かめる | 環境側の変化は自動化の外側にある |
下の二行は、あとから足したものです。接続の修復は CLI では扱えてもデスクトップの面からは届かない、という指摘があります（Issue #54136）。また Windows の累積更新を当てたところ、共有フォルダが一つもマウントされなくなったという報告もあります（Issue #92984）。私自身が踏んだわけではありませんが、いずれも「自動化の中では直せない層」の話ですので、更新の翌朝は定期タスクの結果より先に、手でフォルダを開くようにしています。
なお「見ながら頼むか、任せて離れるか」という軸そのものについては、Claude in Chrome と Cowork の使い分け — 「見ながら頼む」か「任せて離れる」かでも別の角度から書き残しています。
無人の面に残す書き方
置き分けを決めたあと、無人側のスクリプトには三つだけ約束を持たせました。承認の入り口を作らないこと、書けたことを別の手段で確かめること、そして終端で必ず一行残すことです。
#!/usr/bin/env bash
set -u
OUT="$HOME/reports/$(date +%Y-%m-%d)_summary.txt"
mkdir -p "$(dirname "$OUT")"
# 書き込みは専用ツールではなくシェルで行い、承認の入り口を作らない
cat <<'EOF' > "$OUT"
# 本日の棚卸し
status: pending
EOF
# 書けたことを、戻り値ではなく実体で確かめる
if [ -s "$OUT" ]; then
echo "OK wrote $(wc -c < "$OUT") bytes -> $OUT"
else
echo "FAILED empty output -> $OUT" >&2
exit 1
fi期待する出力は OK wrote 37 bytes -> /Users/you/reports/2026-09-18_summary.txt のような一行です。
なぜこう書くのか、三つの理由を順に補足します。ヒアドキュメントの区切りを <<'EOF' とクォートしているのは、本文中の $ やバッククォートを展開させないためです。クォートを落とすと、書き出したはずのログが空になったり、途中で切れたりします。
-s で確かめているのは、成功の戻り値と、実際に書かれたことが別だからです。書き込み系のツールが成功を返しながらファイルが存在しない、という報告も残っています（Issue #81538）。戻り値は「呼べた」ことしか教えてくれません。
終端で一行残しているのは、何も書かれていないログでは「動かなかった」と「動いて何も見つからなかった」を区別できないからです。この区別がつかないと、翌朝に読む側が毎回ゼロから調べ直すことになります。
もう一つ、小さな作法があります。複合コマンドを一行に繋げないことです。
# 承認判定が先頭の cd に当たって止まることがあるため、繋げずに分けます
cd "$WORK" || exit 1
git add content/
git commit -m "update: daily inventory"一行に繋げたほうが短くはなります。それでも分けているのは、止まったときにどの行で止まったのかがログから読めるからです。無人の面では、短さより読み返せることを取っています。定期タスクそのものの組み方はCowork スケジュールタスク運用の実際 — 朝のダイジェストと週次レポートを無人で回すまでにまとめてあります。
対話の面は、許可の粒度で軽くする
無人側を承認ゼロにすると、対話側にはむしろ承認が増えます。ここを重くしすぎると、こんどは自分の手が止まります。私は許可を広く開けるのではなく、細かく開ける方向で調整しました。
{
"permissions": {
"allow": [
"Bash(git status)",
"Bash(git diff:*)",
"Read(./content/**)"
],
"deny": [
"Read(./.env)",
"Read(./**/*.pem)"
]
}
}読み取り専用のコマンドだけを名前で許可し、秘密を含むファイルは拒否で塞ぐ、という形です。ただし拒否を足すと、その対象に触れ得る複合コマンドまで承認待ちになることがあります（先の Issue #91650）。拒否は万能の盾ではなく、日々の手数と引き換えになる設定なのです。無人実行で確認要求そのものをどう捌くかは無人実行で auto モードの確認要求を止めずに捌く — permission-prompt-tool で deny-by-default に応えるに書いてあります。
止める場所は一つに、尋ねる場所は人が見ている時間帯に。 置き分けの基準を一文に縮めると、私の場合これになります。
最初に移す作業は、一つだけ
いま対話で回している作業を見渡して、途中で一度も「はい」を押していないものを一つだけ選んでみてください。それだけを定期実行へ移し、一週間そのままにしておく——これが私のおすすめする最初の一歩です。二つ目を移すのは、一つ目のログが七日ぶん揃ってからでも遅くありません。
私自身、境界を引き直すたびに前の自分の雑さに気づかされます。同じところで手が止まっている方に、何か一つでも持ち帰っていただけましたら幸いです。お読みいただきありがとうございました。