整理整頓、こわい
結論から言います。整理しようとして全部止まりました。
Cowork（※ClaudeのデスクトップAI作業支援ツール）の作業フォルダがいつの間にか2つになっていて、「1つにまとめよう」と軽い気持ちで手を出したら、スケジュールタスクが5件まとめて「タスクファイルが見つからないか、形式が正しくありません」になり、さらにタスクを編集しようとすると「パストラバーサル検知」で全弾かれ。
部屋を掃除していたら掃除機の電源が消え、洗濯機まで止まり、なぜか玄関の鍵まで閉まる、みたいな連鎖でした。今日はその一部始終を、恥を忍んで書きます。
発端：なんで「Claude」と「Claude_blog」、2つあるんだ？
Coworkにはマウント（※選択フォルダ）という概念があって、「space」と呼ばれる作業単位の中に、作業対象フォルダを登録できます。私は「Claude_blog」というspaceを使っていたのですが、ある日spaceの設定を覗いたらフォルダが2つ登録されていました。
C:\Users\〇〇\Documents\Claude←昔のなごりC:\Users\〇〇\Documents\Claude_blog←今のメイン
同じような名前のフォルダがspaceに同居している状態で、作業ファイルが微妙にどっちにあるかバラバラ。どっちで編集しても動くけど、どっちにあるか分からない。 これは気持ち悪い。というわけで「Claude」の方を登録解除することにしました。
ちなみにCoworkのUIからはマウントの個別解除ができない場面があって（私のバージョンではそう見えた）、設定ファイルを直接編集する方法を取りました。
spaces.json を直接いじる
Coworkのマウント設定は、以下のJSONファイルに保存されています。
%APPDATA%\Claude\local-agent-mode-sessions\{セッションUUID}\{エージェントUUID}\spaces.json
中身はこんな感じ（抜粋）です。
{
"spaces": [
{
"id": "space-xxxx",
"name": "Claude_blog",
"folders": [
{ "path": "C:\\Users\\〇〇\\Documents\\Claude" },
{ "path": "C:\\Users\\〇〇\\Documents\\Claude_blog" }
]
}
]
}
folders 配列から不要な方（Claude）のエントリを削除して保存。Coworkを完全終了して再起動。ここまでは想定通り、マウントが1つに統一されて「よし、すっきりした」と思いました。
この時点ではまだ平和だったんです。嫌な予感がするときほど、なんにも起きていない。
副作用その1：スケジュールの「手順」ボタンがいっせいに死ぬ
Coworkの左サイドバーには「Scheduled（スケジュール）」という項目があって、登録済みの定期タスクが一覧表示されます。タスクごとに「手順」というボタンがあり、押すとタスクの中身（SKILL.md）が見られる仕組みです。
マウント整理後、なにげに「手順」を押したら。
タスクファイルが見つからないか、形式が正しくありません。
5件全部これ。全滅です。
原因はわりと単純で、scheduled-tasks.json（spaces.jsonと同じフォルダにある）に登録されている各タスクの filePath が、もう存在しない旧パス（Claude\Scheduled\...）を指していました。親フォルダの参照を切ったせいで、スケジューラ側からタスク本体が見えなくなったわけです。
応急処置
scheduled-tasks.json を直接開いて、5件の filePath を現行パス（Claude_blog\Scheduled\...）に書き換え。保存するとUIはすぐ復旧しました。
ここまでで「まあ、こういうこともあるよね」くらいの認識でした。この油断がこの後の首を絞めます。
副作用その2：update_scheduled_task が全滅
翌日、タスクの説明文を微調整しようとしたら、全部が以下で弾かれました。
Failed to update scheduled task: Invalid file path: path traversal detected
パストラバーサル（※本来アクセスしてはいけない場所にパスで抜けようとする攻撃手法の呼び方）。え、私、攻撃してます？してないです。説明文を直したいだけです。
不思議なのは、全部が全部ダメなわけではない点でした。
| 操作 | 結果 |
|---|---|
enabled のトグル（有効/無効切替） | ✅ 通る |
| 新規タスクの作成 | ✅ 通る |
| 一覧取得 | ✅ 通る |
description / prompt の更新 | ❌ パストラバーサル検知で拒否 |
「一覧では見えるのに、書き換えようとすると見つからないと言われる」。幽霊タスクみたいな状態で、ちょっと怖かった。
切り分け：幽霊の正体を探る
こういうときは、変数を1つずつ固定して違いを見る のが鉄則らしいので（料理の味見と同じ理屈）、4ステップで切り分けました。
enabledトグルだけ叩く → 成功（内部でSKILL.mdの書き込みが起きない操作）descriptionだけ更新 → 失敗（内部でSKILL.mdの書き込みが起きる）- 新しい場所（
Documents\Claude\Scheduled\）にダミータスクを作る → 成功 - そのダミーに対して
descriptionを更新 → 成功
結論：スケジューラが「ここに書くはず」と思っている場所（Documents\Claude\Scheduled\）と、実際にタスク本体がある場所(Documents\Claude_blog\Scheduled\)がズレていた。
一覧取得は両方を横断して見てくれるのでタスクは普通に表示される。ところが更新時にSKILL.mdを書き換えようとすると、「本来の保存先の外にあるファイルパス」として検知され、パストラバーサル扱いで拒否される。幽霊の正体は、引っ越しした本人の住民票が古い住所のままだった、みたいな話です。
そもそもスケジュールタスクのデフォルト保存先はどこ？
ここで一度立ち止まって、「正しい保存先」ってそもそもどこなの？を調べました。
結論を先に言うと、Windowsでのスケジュールタスクの既定の保存先は C:\Users\〇〇\Documents\Claude\Scheduled\{taskId}\SKILL.md です。これは create_scheduled_task（スケジュールタスク作成ツール）の仕様説明にはっきり書いてあります。
The task will be stored as a skill file ({taskId}/SKILL.md) in C:\Users\〇〇\Documents\Claude\Scheduled/
和訳すると「タスクは C:\Users\〇〇\Documents\Claude\Scheduled\ 配下に {taskId}/SKILL.md という形のスキルファイルとして保存されます」。ついでにCowork全体で見ると、プロジェクト本体も既定では Documents\Claude\ の下に作られるようになっています（こちらは公式ヘルプで確認）。つまり Documents\Claude は Cowork 全体のホームディレクトリ的な位置づけで、スケジュールタスクもその中に自分の部屋を持っている、と。
じゃあ、なんで私のタスクは別フォルダ（Claude_blog\Scheduled\）にいたのか？経緯はシンプルで、最初に Documents\Claude\ を自分で作って一通りの作業をそこに集めていたのですが、後からブログ専用に Documents\Claude_blog\ を新規作成し、Claude\ の中身をまるっと Claude_blog\ に引っ越したんです。Scheduled\ フォルダもこのときに一緒に運ばれて、結果としてタスク本体が Claude_blog\Scheduled\ に居座ることになりました。既定の家に戻してあげれば、ツールがちゃんと認識してくれる — というのが今回の話のゴールでした。
ちなみにここで地味に効いていたのが、そもそも私が手動で Claude というフォルダを先に作っていた という事実です。Claude（スケジューラ）が既定で使おうとしている Documents\Claude\ と、私が自分の意思で命名した Documents\Claude\。相談した覚えはないのに、フォルダ名がきっちり一致している。偶然、お互いに同じ名前を選んでいた——いわゆる両想いです（誰も嬉しくない両想い）。このネーミングの被りのおかげで、引っ越しの後も「両方Claudeの家に見える」状態が続き、どっちが本当の家か曖昧なまま共存できていた、とも言えます。
- 既定:
Documents\Claude\Scheduled\{taskId}\SKILL.md← スケジューラが信じている住所 - 迷子:
Documents\Claude_blog\Scheduled\{taskId}\SKILL.md← 昔の住所のまま止まっていた
対処法（2つ）
応急措置：直接ファイルを書き換える
スケジューラは実行時にSKILL.mdをそのまま読むので、ファイルを直接編集すれば内容は反映される。つまり update_scheduled_task が使えなくても、エクスプローラからSKILL.mdを開いて中身を書き換えれば、次回実行時の挙動は変わります。description（先頭のフロントマター）も同じファイル内なのでこれで足ります。
その日の仕事を止めないための一時しのぎ。病院で言う応急処置で、根治ではない。
恒久対策：フォルダごと引っ越す
本質的な解決は、実体を canonical な場所に戻すこと。つまり、
移動元: C:\Users\〇〇\Documents\Claude_blog\Scheduled\{taskId}\
移動先: C:\Users\〇〇\Documents\Claude\Scheduled\{taskId}\
の引っ越しを手でやります。Windowsエクスプローラで、該当タスクのフォルダごと（{taskId} ディレクトリ単位で）切り取り→貼り付け。{taskId} というディレクトリ名そのものが識別子なので、enabled や lastRunAt のような状態は引き継がれます。
なお、これは ユーザー自身の手作業で行う必要があります。理由は単純で、Coworkのサンドボックス側から Documents\Claude\ 配下に新規で書き込む権限がないからです。「自分で動かすしかない」系のトラブルは、珍しい。
試すなら（架空のタスクで再現する）
本番タスクでいきなり壊さないよう、ダミーのスケジュールタスクで練習するのがおすすめです。
/schedule
とチャットに打つと、スケジュールタスク作成用のスキルが起動します。中身は何でもOK。たとえばこんな感じ。
名前: folder-move-test
スケジュール: Manual only（手動実行のみ）
プロンプト: 「テスト用の無害なタスクです。実行されても何も起きません。」
作ったタスクのフォルダを別の場所にエクスプローラで動かしてみて、
一覧に出るか／「手順」ボタンで中身が見えるか／update が通るか、
この3つを順に確認すると、今回のトラブルを1/10スケールで追体験できます。
💡 ポイント： 「動くけど書き換えられない」は、一覧用と書き込み用でパスの見え方が違うときに起きがち。UIが便利に見せてくれている裏側を、たまに覗いておくと安心です。
つまずきポイント
- 整理整頓を軽く見ていた：フォルダを1つ外すだけ＝安全、ではなかった。マウント整理は、参照している別の仕組み（スケジューラ）を巻き込むことを忘れていました。次にやるときは、影響範囲を一度書き出してから手を出します。
- 一覧に出るから大丈夫、と思い込んだ：タスクが一覧に見えているのと、正しく動くのは別問題でした。「一覧表示 = 正常稼働」ではない。書き込みが絡む操作で初めて壊れるタイプのズレは、普段の使い方では気づけない。
- エラーメッセージで早合点した：「パストラバーサル検知」という物騒な言葉に引きずられて、最初は「自分のアカウントが怪しい扱いされてる？」と身構えました。実態は、こちらの保存場所と向こうの想定保存場所がズレていただけ。強そうなメッセージほど、落ち着いて切り分けるのが近道です。
まとめ：片付けは、関係者全員に言ってからやる
一連のトラブルでわかったのは、Coworkの中で「このフォルダはこの用途」という合意（canonical path）が静かに効いているということでした。spaces.json にあるマウント情報はあくまで表札で、スケジューラはスケジューラで「本当の置き場所」を別に持っている。表札だけ書き換えると、引っ越したつもりのタスクが住民票だけ残された状態になる。
整理自体はいいことだし、やって良かったと思います。ただ次からは、何を動かすと誰が困るか を先に確認してから手を出します。部屋で言えば、自分の机を片付ける前に「ルンバ、ちょっとこっちは避けてね」と声をかけておく、みたいな話。
とはいえ、壊してみて初めて見えた仕組みが多かった。「見てから動かせ」が正論だけど、「動かしてから見える」ことも多いな、と今日は思いました（負け惜しみではないです、たぶん）。
コメントを残す