手元のターミナルで動かすと一発で成功する。これでスケジュール実行でも同じように動くはずだと思いきや、同じ指示を登録した瞬間だけ「該当のスキルが見つかりません」と言われる。ローカルではまったく再現しない。設定ファイルも合っている（三度見した）。なのに、決まって朝になって結果を見ると同じエラーで止まっている——という経験をしたことはないだろうか。
これはバグではなく仕様だ。Claude Codeには、~/.claude/skills/にスキルを置いてカスタマイズする方法と、スケジュール実行（cloud routine）やCoworkのようなクラウドセッションで動かす方法の両方がある。ところがこの2つ、実は参照している設定の置き場所が違う。手元の環境をどれだけ整えても、クラウド側のセッションはそこを見に行かない。この記事では、その仕組みと、3つの回避策のどれを選ぶべきかを整理する。
この記事で学べること
- cloud routineやCoworkのセッションが、手元の
~/.claude/skills/を読まない理由 - 3つの回避策（アカウント側でskillを有効化 / repoにcommit / repoでpluginを宣言）の効き方と制約
- 永続スケジューラが欲しいだけなら、cloud routineでなくDesktop scheduled taskで足りるケースの見分け方
前提条件
- Claude Code（Pro $20/月、Max $100〜$200/月）でスケジュール実行やCoworkセッションを使っている、または使おうとしている
~/.claude/skills/に自作のスキルを置いてローカルではカスタマイズ済み
なぜクラウド側だけスキルが見つからないのか
まず起きている現象を正確に言葉にしておきたい。ローカルのターミナルでClaude Codeを起動したときは、~/.claude/skills/に置いた自作スキルが問題なく呼び出せる。ところが同じスキルを呼ぶ指示を、スケジュール実行やCoworkのセッションに渡すと、そのスキルは「無い」ものとして扱われる。設定ミスを疑って何度もパスを見直すが（もちろん合っている）、原因はそこにはない。
理由は、cloud routine・Coworkのセッションがそもそも別の場所から起動しているからだ。ローカルのセッションは自分のマシンのファイルシステムをそのまま見ているのに対して、cloud routineの実行は毎回そのタイミングで用意される新しいリモートセッションとして始まる。つまり、そのセッションの中には手元のホームディレクトリという概念自体が存在しない。~/.claude/skills/に何を置いていようと、クラウド側のセッションにとってはそもそも存在しないディレクトリを探しに行っているのと同じ状態になる。
この構造を、他の自動化の文脈に置き換えるとわかりやすい。CI環境で「ローカルにインストール済みのツールだから」という理由でスクリプトが動くことを前提にすると、フレッシュな実行環境では決まって失敗する。cloud routineのスキル探索も同じ話で、そのセッションの中に持ち込まれていないものは存在しないという前提に立って設計しないと、毎回同じところで詰まる。
では、クラウド側のセッションは実際は何を見ているのか。種明かしをすると、拍子抜けするほど少なく、参照するのは次の2種類だけだ。
- claude.aiアカウント側で有効化されているスキル（セッション開始時に同期される）
- clone対象のrepoに
.claude/skills/としてcommitされているスキル
このどちらにも入っていないスキルは、ローカルにどれだけ整備してあっても、cloud routineやCoworkからは「存在しないもの」として扱われる。
3つの回避策
原因がわかれば、打てる手は3つに絞られる。それぞれ効き方と制約が違うので、順に見ていく。
1. アカウント側でskillを有効化する
一番手軽なのは、claude.aiのskills設定（またはDesktop版のCustomize）でスキルを有効化しておく方法だ。ここで有効化したスキルは、Cowork・cloud routineの両方でセッション開始時に同期される。特定のrepoに依存しないので、複数のプロジェクトをまたいで使う汎用スキルに向いている。
2. repoの.claude/skills/にcommitする
repo側の.claude/skills/にスキル本体をcommitしておく方法。cloud routineがそのrepoをcloneした瞬間に、スキルもセッションの中に持ち込まれる。効果はそのrepoに閉じるが、確実に効く。あるプロジェクト固有の作業手順をスキル化していて、他のプロジェクトでは使わない、というケースならこちらのほうが筋がいい。
この方式で運用しているスキルほど、「毎回フレッシュな実行環境で動く」ことを前提にした作り込みが求められる。依存パッケージが入っていない前提でセットアップ手順を明示する、参照先のブランチが存在しない可能性を考慮してエラーを明示的に出す、実行環境の制約で一部の手段が使えない場合の代替策を用意しておく——といった具合に、「ローカルで動いた実績」を信用せず、「そのセッションに何が持ち込まれるか」だけを頼りに設計するという一点に尽きる。
3. repoの.claude/settings.jsonでpluginを宣言する
3つ目は、pluginとして宣言する方法だ。.claude-plugin/marketplace.jsonと{"source":"github","repo":"owner/repo"}形式の宣言を.claude/settings.jsonに置いておくと、セッション開始時にそのpluginがインストールされる。
ここで踏みやすい落とし穴がある。user settingsだけでpluginを有効化していても、それはcloud routineには転送されない。pluginをrepo側の.claude/settings.jsonに明示的に宣言していない限り、cloud routine側では「そんなpluginは無い」ものとして扱われる。ローカルで動作確認したときにplugin機能が動いていたとしても、それがuser settings側の設定だった場合、cloud routineに持っていくと同じようには動かない。
3つの回避策の比較
| 回避策 | 効く範囲 | 制約 | 向いているケース |
|---|---|---|---|
| アカウントでskillを有効化 | Cowork / cloud routineの両方、全repo共通 | claude.ai側の設定操作が必要。repoに依存しない分、repo固有の細かい調整はしにくい | プロジェクトをまたいで使う汎用スキル |
repoの.claude/skills/にcommit | そのrepoをcloneするcloud routineのみ | 効果がrepo単位に閉じる | プロジェクト固有の作業手順・ワークフロー |
repoの.claude/settings.jsonでplugin宣言 | そのrepoをcloneするcloud routineのみ | user settingsだけの有効化は転送されない | 複数スキルをまとめて配布したいとき |
判断の流れを図にすると、次のようになる。
そもそもcloud routineを選ぶべきかという判断
ここまでは「cloud routineでスキルを動かす方法」を前提に書いてきたが、そもそもの前提を疑う価値もある。単に「決まった時刻に自動実行したい」だけなら、Desktop版のscheduled taskのほうが素直な選択肢になることが多い。ローカルで実行されるので手元のスキル・専用CLI・OAuth設定をそのまま使え、セッションという単位を意識する必要もない。制約は「実行時にマシンが起動していること」だけだ。
一方でcloud routineを選ぶと、「ローカルファイルへアクセスできない（毎回フレッシュなclone）」という制約が自動的についてくる。その代わりに得られるのは「マシンが落ちていても走る」という性質だ。現実はいつも、便利さと引き換えに何かを差し出す仕組みになっている。この2つはトレードオフの関係にあり、どちらが必要かで選ぶべきスケジューラが決まる。マシンの電源やネットワークに依存せず動かしたいのが本当の要件なら、その制約を受け入れてcloud routineを選ぶ。そうでなければ、Desktop scheduled taskのほうがシンプルに済む場面のほうが多いはずだ。
まとめ
Claude Codeのcloud routineやCoworkのセッションが手元の~/.claude/skills/を読まないのは、バグではなく「フレッシュなリモートセッションとして起動する」という仕様の帰結だ。回避策は、アカウント側での有効化・repoへのskill commit・repoでのplugin宣言の3つで、どれを選ぶかは「複数プロジェクト共通か、特定repo専用か」「単体か、まとめて配布したいか」で決まる。plugin宣言を使うときは、user settingsだけの有効化がcloud routineには転送されない点に特に注意したい。
そして、そもそも「決まった時刻に走らせたい」だけならDesktop scheduled taskのほうがシンプルという判断軸も、選定の最初に置いておく価値がある。マシンが落ちていても走らせる必要があるかどうかが、その分かれ目になる。スケジュール実行に限らず、AIエージェントに複数タスクを同時に振って開発を進める比重が増えている場合、こうしたセッション設計まわりの型を作るところから相談したいならAI実装支援も選択肢の一つになる。
