この記事は playpark Blog からの転載です。
この記事で分かること
- cloud routineやCoworkのセッションが、手元の
~/.claude/skills/を読まない理由 - スキルをクラウド側に持ち込む3つの方法と、それぞれの効く範囲・制約
- そもそもcloud routineを選ぶべきかという判断軸
背景: こういう課題があった
Claude Codeでは~/.claude/skills/にスキルを置いてローカルをカスタマイズできる。ところが同じスキルを呼ぶ指示を、スケジュール実行（cloud routine）やCoworkのセッションに渡すと、そのスキルは「無い」ものとして扱われる。設定ミスを疑って何度もパスを見直しても原因は見つからない。手元ではまったく再現しないので余計に厄介だ。
選択肢の検討
原因は、cloud routine・Coworkのセッションがローカルとは別の場所から起動していることにある。ローカルのセッションは自分のマシンのファイルシステムをそのまま見ているが、cloud routineの実行は毎回そのタイミングで用意される新しいリモートセッションとして始まる。そのセッションの中には、手元のホームディレクトリという概念自体が存在しない。
クラウド側のセッションが実際に参照するのは、次の2種類だけだ。
| アプローチ | 効く範囲 | 制約 |
|---|---|---|
| claude.aiアカウントでskillを有効化 | Cowork/cloud routine全体、全repo共通 | claude.ai側の設定操作が必要 |
repoの.claude/skills/にcommit |
そのrepoをcloneするcloud routineのみ | 効果がrepo単位に閉じる |
repoの.claude/settings.jsonでplugin宣言 |
同上 | user settingsだけの有効化は転送されない |
なぜこのアプローチを選んだか
複数プロジェクトをまたいで使う汎用スキルなら、アカウント側での有効化が一番手軽だ。特定プロジェクト専用の作業手順をスキル化しているなら、repoの.claude/skills/にcommitするほうが筋がいい。効果はそのrepoに閉じるが、確実に効く。
複数スキルをまとめて配布したい場合はpluginとして宣言する手もある。
実装例
// .claude/settings.json
{
"plugins": {
"marketplaces": {
"my-marketplace": { "source": "github", "repo": "owner/repo" }
}
}
}
ここで踏みやすい落とし穴がある。user settingsだけでpluginを有効化していても、それはcloud routineには転送されない。 repo側の.claude/settings.jsonに明示的に宣言していない限り、cloud routine側では「そんなpluginは無い」ものとして扱われる。ローカルで動作確認できていたとしても、それがuser settings側の設定だった場合、cloud routineに持っていくと同じようには動かない。
まとめ: どういう場面で使うべきか
- 複数プロジェクトで共通して使う汎用スキル → アカウント側で有効化
- 特定repo専用のワークフロー → repoの
.claude/skills/にcommit - 複数スキルをまとめて配布したい → repoの
.claude/settings.jsonでplugin宣言（user settingsだけでは転送されない点に注意） - 単に「決まった時刻に自動実行したい」だけなら、Desktop scheduled taskのほうがシンプルに済むケースも多い
さらに深掘りしたい方へ
この記事ではcloud routineがローカルスキルを読まない理由と、3つの回避策の選定理由を解説しました。
毎日決まった時刻の自動実行だけスキルが動かない理由 — Claude Codeのcloud session事情 ではさらに：
- 3つの回避策の比較表と、選び方の判断フローをmermaid図で整理した解説
- cloud routineのスキル探索を「フレッシュなCI環境で失敗するスクリプト」になぞらえた構造的な説明
- そもそもcloud routineとDesktop scheduled taskのどちらを選ぶべきかというトレードオフの判断軸
を扱っています。
playpark について
playpark LLC - 業務自動化・AI活用・Web開発
