7
3

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 Coworkのスケジュールタスクを止めない:承認ダイアログを回避してセッションディレクトリを確実にマウントする方法

7
Last updated at Posted at 2026-04-08

はじめに

「AIに日次の作業ログをまとめてもらうスケジュールタスクを仕込んだのに、翌朝確認したら止まっていた」

こんな経験はないでしょうか。セットアップは完璧なはずなのに、実行履歴を見るとタスクが途中で止まっている。原因を調べると、「承認待ち」のダイアログが出ていたことに気づく……というパターンです。

本記事では、Claude Coworkのスケジュールタスクで発生する「セッションディレクトリのマウント要求による停止」問題と、それを解決した2段階の設定方法を紹介します。

対象環境:

  • Claude Desktop(Cowork機能付き) のスケジュールタスク機能を使っている方
  • Claude Code CLI単体(cronで直接呼び出すなど)のユーザーには、userSelectedFolders に関する部分は不要ですが、マウント確認ロジックの考え方は参考になる場合があります

本記事について
本記事の内容は2026年4月時点の実機検証・実行ログ観測に基づいています。
userSelectedFoldersrequest_cowork_directory/sessions/... 配下のパス構造はいずれも公式ドキュメント未記載の内部仕様です。将来的に仕様変更・挙動変更の可能性があります。


問題の構造:なぜスケジュールタスクは止まるのか

Claude CoworkはVM内で動作している

Claude Coworkのエージェントセッションは、ホストOSから隔離された軽量VMの中で動作しています(公式ヘルプより確認済み)。VMとホスト間のファイル共有にはvirtiofsが使われており、セッションが起動するとVMが立ち上がり、作業ディレクトリは /sessions/<セッション名>/ になります。

ホストOS (Windows/Mac)
├── C:\Users\username\.claude\   ← Claude Codeのデータ
├── C:\Users\username\AppData\... ← Coworkのセッションログ
└── ...

VM内 (Coworkエージェント)
├── /sessions/keen-stoic-cray/    ← 作業ディレクトリ(観測値)
└── ~/.claude/                    ← ホストとは分離された環境

⚠️ /sessions/<セッション名>/ というパス構造は実行ログから観測されたものであり、公式に保証された仕様ではありません。

ここが罠です。VM内の ~/.claude はホストの ~/.claude とは分離された環境として扱われます。

ホストファイルへのアクセスには内部ツールの呼び出しが必要

Claude Codeのセッションログ(~/.claude/projects/)や各種設定ファイルはホスト側にあります。エージェントがこれらにアクセスするには、ログ上で request_cowork_directory として確認できる内部ツールを呼び出してホストのディレクトリをVMにマウントする必要があります。

VM内 → request_cowork_directory("C:\Users\username\.claude") →
       マウント完了: /sessions/keen-stoic-cray/mnt/.claude/

⚠️ request_cowork_directory は実行ログ上で確認された内部ツール呼び出しであり、公式APIとして公開されているものではありません。

問題は、このマウント操作がユーザーの承認を必要とするケースがあることです。

[Claude エージェント]
  ↓ request_cowork_directory を呼び出し
[承認ダイアログ表示] ← ここでブロック(発生するケースを確認)
  ↓ ユーザーが承認しないと進めない
[マウント完了]

手動でチャットしているときはすぐ承認できますが、スケジュールタスクは無人実行です。承認する人がいないため、ダイアログが出た時点でタスクは止まります(またはタイムアウト)。

Before: 止まっていたときのプロンプト

問題発生時のスケジュールタスクのプロンプトは、こんなイメージでした:

daily-ai-work-summary スキルを使って作業まとめを生成してください。

設定:
- ~/.claudeディレクトリを request_cowork_directory でマウントして使用すること
- マウント先パスを --claude-dir オプションに指定すること

シンプルに「マウントして使え」と書いているだけ。毎回 request_cowork_directory が呼ばれ、承認待ちになるケースが発生していました。


解決策:承認のタイミングを「タスク作成時」に前倒しする

根本的な発想の転換は、「実行時に承認を求めず、タスク設定時にまとめて承認しておく」です。

これを実現する手順は2つあります。

Step 1: userSelectedFolders でディレクトリを事前マウント登録する

Claude Coworkのスケジュールタスク設定ファイル(scheduled-tasks.json)には userSelectedFolders というフィールドが存在します。ここに追加したディレクトリは、タスク実行時に自動でマウントされるような挙動を確認しています

⚠️ userSelectedFolders は公式ドキュメント未記載のフィールドです。実環境ではこの設定によりフォルダアクセスが事前許可される挙動を確認していますが(2026年4月時点)、将来的に仕様変更の可能性があります。

// Before: userSelectedFolders なし  承認ダイアログが出るケースがある
{
  "scheduledTasks": [
    {
      "id": "daily-ai-work-summary",
      "cronExpression": "0 9 * * *",
      "enabled": true,
      "filePath": "C:\\Users\\username\\Scheduled\\daily-ai-work-summary\\SKILL.md"
    }
  ]
}
// After: 必要なフォルダを事前登録  自動マウント、承認不要(実機確認済み)
{
  "scheduledTasks": [
    {
      "id": "daily-ai-work-summary",
      "cronExpression": "0 9 * * *",
      "enabled": true,
      "filePath": "C:\\Users\\username\\Scheduled\\daily-ai-work-summary\\SKILL.md",
      "userSelectedFolders": [
        "C:\\Users\\username\\.claude",
        "C:\\Users\\username\\Documents\\github\\my-project"
      ]
    }
  ]
}

userSelectedFolders に登録したパスは、タスク実行時にVMの /sessions/<セッション名>/mnt/ 以下に自動でマウントされる挙動を確認しています。

scheduled-tasks.json の場所について
OSや環境によって異なります。Windowsの場合は %APPDATA%\Claude\ 配下に存在することが多いですが、Claude Desktopのデータディレクトリを直接確認してください。

Step 2: プロンプトに「マウント済み確認ロジック」を埋め込む

userSelectedFolders だけでは不十分です。エージェントは「既にマウントされているパス」を知らないため、素直にプロンプト通り request_cowork_directory を呼び出そうとしてしまいます。

ここで、プロンプトにシェルによる事前チェックのロジックを直接書き込みます:

// Before: 常に request_cowork_directory を呼ぶ(承認が必要になるケースがある)
- ~/.claudeディレクトリを request_cowork_directory でマウントして使用すること
// After: まずlsで確認し、マウント済みならそのパスを使う
- .claudeディレクトリのマウント: まず
  `ls -d /sessions/*/mnt/.claude/projects 2>/dev/null | head -1`
  でマウント済みか確認し、存在すればそのパスを使用する。
  存在しない場合のみ request_cowork_directory で
  C:\Users\username\.claude をマウントする。
  --claude-dir オプションに取得したVMパスを指定すること

ポイントが2つあります:

👉 /sessions/*/mnt/ のグロブパターン + head -1
セッション名(keen-stoic-cray のような自動生成名)は毎回変わります。ワイルドカードを使うことで、セッション名に依存せずマウント済みパスを発見できます。また -d オプションでディレクトリのみを対象とし、| head -1 で古いセッションディレクトリが残存していた場合の複数マッチによる引数過多エラーを防いでいます。

👉 2>/dev/null でエラーを捨てる
マウントされていない場合に ls がエラーを出しても、それがエージェントの誤動作を引き起こさないようにします。

判定フローのイメージ

エージェント起動
  ↓
ls /sessions/*/mnt/.claude/projects 2>/dev/null
  ↓
┌── 出力あり(userSelectedFolders で事前マウント済み)
│     → /sessions/keen-stoic-cray/mnt/.claude を使用
│     → request_cowork_directory を呼ばない → 承認ダイアログなし
│
└── 出力なし(手動実行 or 未登録ディレクトリ)
      → request_cowork_directory を呼んでマウント
      → (手動実行なら承認して進む)

スケジュール実行時は userSelectedFolders で事前マウントされているため、常に上のルートを通ります。


実際に動いたときの実行ログ(2026-03-30)

実際の自動実行(2026-03-30 09:06 JST)のセッションログを確認すると、以下の順序で処理が進んでいました:

# Step 1: マウント済み確認
$ ls /sessions/*/mnt/.claude/projects 2>/dev/null && echo "EXISTS" || echo "NOT_FOUND"
EXISTS

# → グロブが /sessions/keen-stoic-cray/mnt/.claude/projects にマッチ
# → 事前マウント済みと判断、request_cowork_directory は呼ばない

# Step 2: マウント先の具体パスを特定して使用
$ ls /sessions/keen-stoic-cray/mnt/.claude/projects
# → Claude Code のプロジェクトディレクトリ一覧が表示

# Step 3: スキルスクリプトを実行
$ python3 /sessions/keen-stoic-cray/mnt/.claude/skills/daily-ai-work-summary/scripts/extract_sessions.py \
    --date 2026-03-30 \
    --claude-dir /sessions/keen-stoic-cray/mnt/.claude \
    --format text

# → セッションログ抽出成功
# → YAML生成 → ワークフォルダへ保存 → 完走

request_cowork_directory の呼び出しはゼロ。承認ダイアログもゼロ。完全無人実行が達成されました。


なぜこれで動くのか:承認の「前払い」という考え方

この手法のポイントを一言で表すなら「承認の前払い」です。

タイミング 従来のアプローチ 今回のアプローチ
タスク設定時 特に何もしない userSelectedFolders でアクセス先を承認
タスク実行時 request_cowork_directory → 承認待ちになるケースがある ls チェック → 既にマウント済み → スキップ
承認が必要なケース 毎回(= 自動化不可) タスク設定変更時のみ

実行時の承認を完全に排除するわけではなく、承認が必要なタイミングを「タスク作成・設定変更時」に限定しているのがポイントです。

また、プロンプトにシェルのチェックロジックを書くことで、「手動実行の場合は従来通り request_cowork_directory でマウントする」というフォールバックも維持できています。スケジュール専用の特殊実装にならず、手動実行との共存が可能です。


汎用パターンとして整理する

この手法は「特定のディレクトリへの自動アクセス」全般に応用できます。

汎用プロンプトテンプレート

## ディレクトリアクセスのガイドライン

アクセスが必要なディレクトリは以下の順序で確認すること:

1. まず `ls /sessions/*/mnt/<ディレクトリ名> 2>/dev/null` でマウント済みか確認する
2. 出力があればそのパス(`/sessions/<セッション名>/mnt/<ディレクトリ名>`)を使用する
3. 出力がなければ `request_cowork_directory` でマウントしてから使用する

対象ディレクトリ:
- ホストパス: C:\Users\username\<対象フォルダ>
- VMマウント後パス: /sessions/*/mnt/<フォルダ名>

userSelectedFolders に登録すべきディレクトリの選び方

  • スケジュールタスクが確実にアクセスする必要があるディレクトリ
  • 機密性が高すぎないディレクトリ(広範なフォルダを登録しすぎない)
  • タスクが複数のフォルダを必要とするなら、必要な分だけ列挙する

まとめ:自動化完走のためのチェックリスト

Claude Coworkのスケジュールタスクを完全自動化するために確認すべき点です。

  • scheduled-tasks.json の該当タスクに userSelectedFolders を追加した
  • 必要なディレクトリをすべて userSelectedFolders に列挙した
  • スケジュールタスクのプロンプトに ls /sessions/*/mnt/... 2>/dev/null の確認ロジックを書いた
  • マウント済みの場合のパス使用と、未マウントの場合の request_cowork_directory フォールバックを両方書いた
  • 手動でテスト実行し(= スケジュール実行と同等の条件で)、人間不在でも完走するか確認した

この設定により、「朝起きたら止まっていた」問題から解放されます。スケジュールタスクは静かに、確実に、毎日動き続けます。

⚠️ 本手法は内部挙動に依存しているため、Claudeのアップデートにより動作しなくなる可能性があります。


シリーズ記事

7
3
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
7
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?