Lovable、「毎回同じ指示をする問題」にようやく答えを出した — Skills機能の使い方

Lovableでアプリを作っていると、同じ指示を何度も打っている自分に気づく。「Tailwindを使って」「日本語で」「ボタンの角は丸くして」「shadcn/uiのコンポーネントを使って」——プロジェクトを新しく作るたびに、同じことを書く。

Claude CodeにはCLAUDE.md、Cursorには.cursorrules、WindsurfにもRulesがある。プロジェクト固有のルールをファイルに書いておけばAIが従う、という仕組みだ。Lovableにはそれがなかった。800万人が使うバイブコーディングツールとしては、わりと致命的な不在だったと思う。

5月18日、ようやくその穴が埋まった。

Skillsとは何か

Skillsは、繰り返し使う指示をMarkdownファイルとして保存し、関連するタスクが発生したときにLovableが自動で読み込む仕組みだ。

ここがポイントで、「常にロードされるコンテキスト」ではない。Lovableには既にWorkspace KnowledgeやProject Knowledgeという「常時参照される情報」の仕組みがある。Skillsはそれらとはレイヤーが違い、特定のタスクに該当する場合のみ起動する。

たとえば「SEOチェック」というSkillを作っておくと、ページを作るときだけそのSkillがロードされる。ロゴの色を変えるときには呼ばれない。この選択的な適用が、トークンの無駄遣いを防ぎ、指示の精度を保つ。

SKILL.mdのフォーマット

Skillの実体は、フォルダ内の SKILL.md ファイルだ。構造はシンプルで、名前、説明文（「Use when...」で始まるトリガー条件）、そして本文の指示をMarkdownで書く。オプションでスクリプトや参照ファイルを同梱できる。

Markdownベースなので、中身は完全に透明だ。Lovableが何を指示されているか、ユーザーがいつでも確認・編集できる。チームメイトと共有するのも、GitHubからインポートするのも、ZIPでエクスポートするのも自由。

作り方は3通り

1. ワークスペース設定から手動で作成 — Settings画面からSkillを新規作成し、Markdownを書く
2. ZIPやGitHubからインポート — 他の人が作ったSkillをそのまま取り込める
3. Lovableに「これをSkillにして」と頼む — 何度も同じ指示をしていると、Lovableに「この指示をSkillとして保存して」と言えば自動でSkillファイルを生成してくれる

3番目が地味にいい。指示の定型化を意識していなくても、日常的に繰り返しているパターンをLovable側が吸い上げてくれる。

具体的にどう使えるか

たとえばこんなSkillが考えられる。

デザインシステム: プロジェクト横断で使うカラーパレット、タイポグラフィ、コンポーネントのルールをSkillにまとめる。新しいプロジェクトでも、デザインの一貫性が自動で保たれる。

QAチェックリスト: 「ページ作成後にアクセシビリティチェック」「フォーム送信後のエラーハンドリング確認」などの品質チェックをSkillにしておけば、ビルドのたびに自動で適用される。

ローンチ準備: OGP設定、favicon、404ページ、Google Analytics埋め込みなど、公開前にやるべきことリストをSkillにしておけば、デプロイ前の確認漏れが減る。

非エンジニアがメインのLovableユーザーにとって、こうした「プロがやっている当たり前のチェック」をSkillとして配布できるのは大きい。

CursorやClaude Codeとの違い

Cursorの.cursorrules やClaude CodeのCLAUDE.mdは「プロジェクト単位で常にロードされるコンテキスト」だ。対してLovableのSkillsは「タスク単位で選択的にロードされる」。

どちらが優れているという話ではなく、ユーザー層が違う。CursorやClaude Codeのユーザーはエンジニアなので、プロジェクトルートに設定ファイルを置く行為に抵抗がない。Lovableのユーザーは非エンジニアが多い。「ファイルを置く」よりも「UIから設定する」「AIに頼んで保存してもらう」ほうがハードルが低い。Skillsの設計はその層に合っている。

もう一つ、SkillsはWorkspace単位で管理される。つまり同じワークスペース内の全プロジェクトに横断的に適用できる。Cursorの.cursorrulesはリポジトリ単位なので、プロジェクトを跨いだルール共有には別の工夫が必要だ。

期待したいこと

Skillsの仕組みが本当に面白くなるのは、Skillsのマーケットプレイスやコミュニティ共有が実現したときだろう。「EC向けSEO最適化Skill」「SaaSダッシュボード設計Skill」「日本語ローカライゼーションSkill」のように、特定の用途に特化したSkillを誰かが作り、他のユーザーが1クリックでインポートする。LobeHubのSkills Marketplaceのような動きは既にある。

もしLovableがそのエコシステムを公式に整備すれば、プロンプトエンジニアリングの知識がなくてもプロ品質のアプリを作れる——というLovableの本来の約束がさらに近づく。

気になる点

Skillsの「自動適用」がどれくらい正確かは未知数だ。「Use when...」のトリガー条件をうまく書かないと、期待したタイミングで発動しない、あるいは不要なタイミングで発動する可能性がある。ここはユーザーの試行錯誤が必要になるだろう。

また、Skillsが増えすぎたときの管理も課題になりそうだ。10個、20個とSkillが溜まったとき、どれが有効でどれが古いのか、整理する仕組みが今のところ見当たらない。

それでも、800万人のユーザーが「毎回同じ指示を繰り返す」苦痛から解放されるインパクトは小さくない。Lovableを日常的に使っているなら、まずは自分が繰り返している指示を1つSkillにしてみるといい。