Claude Code on the WebでSkillを作っても呼ばれない——cloud routineはローカルSkillファイルを読めない設計の盲点と回避策

「Skillを整備したのに、クラウドルーチンで呼ばれていない」——Claude Code on the Webで自動化を組んでいる人なら、同じ場所で詰まる可能性がある。

この記事は、content-executorにSkillを適用しようとして2026年6月23日に踏んだ設計の盲点と、adapt-specファイルへの移植で解決するまでの実装記録です。

結論

Claude Code on the Web（CCR）のクラウドルーチンは、ローカルの ~/.claude/skills/ を読まない。Skillはローカルで手動セッションを動かすときのみ有効。クラウドルーチンに仕様を渡したいなら、ルーチンが Read できるプロジェクトファイルに書き方ガイドを置く。

これが私がcontent-executorの外部配信ステップを設計しながら出した答えです。

この記事の前提

スタック: masatoman.net（Next.js + Supabase）+ Qiita/Zenn/はてな/Dev.to/note外部配信
運用: content-executorというクラウドルーチン（CCR）で記事を自動生成→各媒体にadapted→push
発見日: 2026-06-23（Skillを整備した直後、content-executorに適用しようとして判明）
「Skillが呼ばれた成功談」ではなく「クラウドで呼ばれない理由を理解してadapt-specに切り替えた設計変更の記録」です

読者のよくある詰まり（「それ俺だ」を作る）

Claude Code on the Webで自動化を組んでいると、こういう状況になりやすい。

ローカルでSkillを整備した: ~/.claude/skills/adapt-qiita/SKILL.md を作って、Qiita向け記事の書き方ガイドを書いた
ローカルでは動く: 手動でClaude Codeを起動するとSkillが呼ばれる
クラウドルーチンには効かない: CCRで動くcontent-executorが同じ作業をしても、Skillは無視される
直し場所が分からない: プロンプトを修正しても、Skillを書き直しても、クラウドの挙動が変わらない

これはSkillの記述が悪いのでも、Claude Codeのバグでもない。設計の問題です。

実際に起きたこと（2026-06-23）

content-executorのStep5——Qiita/Zenn/はてな/Dev.to/note向けにadapted記事を生成するステップ——で、各媒体の書き方ガイドをどう渡すかを設計していた。

「Skillに書けばいい」と思ってローカルに ~/.claude/skills/adapt-qiita/SKILL.md を作り、Qiita記事のfrontmatter仕様やCTA規則を記載した。ローカルでテストするとSkillが呼ばれる。問題なさそうに見えた。

しかしcontent-executorはClaude Code on the Web（CCR）で動くクラウドルーチンだ。実際にルーチンを走らせると、Skillは一切呼ばれていなかった。ルーチンはSkillを無視して、プロンプトに書かれた指示だけで記事を生成していた。

原因分析

なぜクラウドルーチンがSkillを読まないのか。構造を整理すると単純だ。

環境	Skillファイルの場所	アクセス可否
ローカルClaude Code	`~/.claude/skills/` (自分のマシン上)	✅ 読める
Claude Code on the Web（CCR）	クラウドの隔離コンテナ上で実行	❌ ローカルファイルにアクセス不可

Skillは「ローカルのファイルシステムにあるMarkdownを、Claude Codeのセッションが読む」仕組みだ。CCRはクラウドコンテナで動くため、あなたのマシンの ~/.claude/skills/ には物理的にアクセスできない。

どれだけSkillを丁寧に書いても、クラウドルーチンはそのファイルの存在を知らない。「ローカルで動く」のは、ローカルセッションがローカルファイルを読めるから——当然だが、盲点になりやすい。

解決した設計：adapt-specファイルへの移植

実は content-executor は最初から答えを持っていた。Step5のプロンプトを読むと、こう書いてあった。

各投稿先に展開する。投稿先ごとに仕様が違うので、
その投稿先の仕様ファイルを必ず Read してから生成する
（仕様はプロンプトに書かず masatoman.net/docs/adapt-spec-{媒体}.md が単一ソース）

つまり設計としては「Skillではなく、クラウドルーチンが Read コマンドで読めるプロジェクトファイルに仕様を書く」が既に採用されていた。私がSkillに書いた内容は、masatoman.net/docs/adapt-spec-qiita.md に移植すればよかった。

解決手順：

~/.claude/skills/adapt-qiita/SKILL.md に書いたQiita仕様を masatoman.net/docs/adapt-spec-qiita.md に移植する
ルーチンのプロンプトに「Step5でadapt-spec-.mdをReadしてから生成する」と明記する
ルーチンを実行——クラウドが masatoman.net/docs/adapt-spec-qiita.md を Read して仕様を取得し、Qiita向け記事を生成する

クラウドルーチンは Read コマンドでリポジトリ内のファイルを読める。「クラウドが直接触れるファイル」に仕様を置く——これがクラウドルーチンへの仕様の渡し方だ。

判断軸：いつSkillを使い、いつファイルに置くか

この発見から整理した判断基準：

使う場面	適切な仕様の置き場所
ローカルで手動セッションを動かす	`~/.claude/skills/` のSkillファイル
Claude Code on the WebのCCRで動くクラウドルーチン	リポジトリ内の仕様ファイル（Readで読めるパス）
CIやGitHub Actionsで動くスクリプト	環境変数またはリポジトリ内のconfig/スクリプト

問いは「その設定を読む主体が、ローカルのファイルシステムにアクセスできるか？」だ。

ローカルセッション → Skillが有効
クラウドで動く何か → Skillは届かない。Readできる場所に置く

SkillはClaude Codeの便利機能だが「どこからでも使える」ではない。ローカル専用だと理解してから使うと、設計の迷子が減る。

今日やること（3つ以内）

自分のSkillを確認する: 「クラウドルーチンで使いたい」と思ってSkillを書いていないか確認する。あれば、ルーチンがReadできるリポジトリ内のファイルに移植する。
クラウドルーチンのプロンプトに仕様ファイルのReadを明記する: 仕様をファイルに移植しても、ルーチンがReadするよう指示がなければ無視される。Read masatoman.net/docs/adapt-spec-{媒体}.md してから生成する の一行を追加する。
「ローカルで動く ≠ クラウドで動く」をチェックリストに追加する: 自動化を設計するとき、実行環境（ローカルかクラウドか）とその環境が参照できるファイルの場所を確認する習慣を入れる。