スキルが重要な理由
Agentと構築するたびに、有用なコンテキストが生まれます:問題の解決策、設計上の決定、フレームワークの好み。しかし、そのコンテキストはチャットが終わると消えてしまいます。スキルはそれを保持します。 GSAPアニメーションスキルはAgentに特定のライブラリの正しい使い方を教えます。デザインシステムスキルは正確な色とスペースのルールを適用するよう保証します。バグ修正スキルは解決策をキャプチャして、Agentが同じ間違いを繰り返さないようにします。以前は一貫性のなかったタスクが信頼できるものになります。 スキルはオープンスタンダードでもあります。Replit Agentを含むあらゆるエージェントで動作するため、ツール間で持ち運ぶことができます。積極的 vs 反応的スキル
スキルをいつ・どのように作成するかを考えるフレームワーク。両方のパターンを理解することで、より効果的になれます。積極的スキル
積極的スキルは、構築を始める前に追加するものです。使いたいライブラリやパターンを調査し、それらのスキルを見つけるか作成してから、プロンプトを開始します。 例: 手書き風SVGアニメーションを使ったポートフォリオサイトを構築する前に、アニメーションライブラリを調査してGSAPを見つけます。GSAP Reactスキルをインストールしてから、Agentにアニメーションの構築をプロンプトします。Agentは最初から必要な専門知識を持っています—ライブラリのAPI、ベストプラクティス、一般的なパターンを理解しています。スキルなしでは、汎用的または不正確なものを生成するかもしれません。 このパターンが効果的な場合:- 人気のあるライブラリだが、Agentが単独では上手くいかない細かいパターンがある場合
- プロジェクト全体で一貫したデザインの選択をしたい場合(タイポグラフィ、スペース、アニメーションスタイル)
- プロジェクトを開始していて、すでに技術的な方向性が分かっている場合
反応的スキル
反応的スキルは、問題を解決した後に作成するものです。問題に遭遇し、Agentと一緒にデバッグし、修正し、その解決策を再発しないようにキャプチャします。 例: モバイルアプリのキャンバスを構築中に、ズームインするにつれて悪化する画像のギザギザエッジに気づきます。Agentとのデバッグで、これがミニフィケーションエイリアシング—逆説的に、画像が縮小されるほど悪化するレンダリング問題—であることが判明します。修正を実装した後、Agentにスキルを作成するよう依頼します: Agentは会話履歴を使ってプロジェクト固有のスキルを書きます。次に問題が発生したとき、スキルをAgentに示すだけで、最初からデバッグする必要がありません。 このパターンが効果的な場合:- 非明白なバグを修正し、再発を防ぎたい場合
- デバッグセッション中にアプリのアーキテクチャについて何かを学んだ場合
- 発見に大きな労力がかかった解決策をエンコードしたい場合
スキルを選択的に使う
スキルは、友人にアパートへの道順を教えるのと似ています。ターゲットを絞った指示リストは機能します。ドキュメントのバインダーは機能しません—誰もそれを読む時間がなく、重要な詳細が失われます。 同じことがAgentにも当てはまります。スキルを追加しすぎると、Agentが混乱する可能性があります。特定のプロジェクトに対してどのスキルを有効にするかを慎重に選び、不要になったものは削除しましょう。スキルは一般的なガイダンスよりも、具体的で繰り返し可能なパターンをキャプチャするときに最も効果的です。具体的なワークフロー、確立された規約、実証済みの解決策に焦点を当てましょう。
スキルを上手に作成する
スキルは複雑で精巧なものになりえます。効果を保つためのいくつかの原則:- ハッピーパスを説明する。 Agentに正しいやり方を伝えてください。してはいけないことのリストを書いていると気づいたら、それはアプローチ全体を再考すべきサインです。
- できる限りスクリプトを使う。 決定論的なスクリプトはAgentの思考負担を減らし、毎回同じステップを考えさせるよりも信頼性が高まります。
- リンクアウトする。 スキルを他のMarkdownファイルへのポインタとして構成し、Agentが目の前のタスクに必要なものだけを取り込めるようにします。
- 定期的にベンチマークする。 スキルが実際に機能しているか確認するのはこれが唯一の方法です。
- 自分で書く。 目標は簡潔で意図的なコンテキストであり、スキルを一括生成するのではなく手書きすることで達成できます。Agentにドラフト作成を手伝ってもらうことはできますが、すべての行が存在意義を持つよう自分で磨いてください。
- ベスポーク(特注)に保つ。 コードのクリーンさやセキュリティのための汎用スキルを作らないでください—それらはすでにAgentに組み込まれています。スキルはあなたやあなたの組織に特有のものをキャプチャすべきです。
- スキルが発動すべきでないときに発動する。 説明が広すぎます。絞り込み、使用しない場合を明記してください—「ブログ投稿やヘルプドキュメントには使用しない」という否定的な指示は、肯定的な指示よりも有用なことが多いです。
- スキルが発動するが出力がおかしい。 指示が汎用的すぎます。「プロフェッショナルにする」のような曖昧なガイダンスを、具体的なルール(正確な名前、具体的な要件、避けるべき明示的な事項)に置き換えてください。
- 2つのスキルが競合する。 両方が同じタスクで発動しないよう説明を修正してください。競合はほぼ常に指示の問題ではなく、スコープの問題です。
スキルをワークスペース全体に適用する
これまでの内容はすべて単一プロジェクトのスキルに適用されます。チームでは、ワークスペース全体でAgentをカスタマイズして、全員が同じ規約から始められるようにすることもできます。ワークスペースのカスタマイズには2つの部分があります:- カスタム指示 — すべてのプロジェクトとすべてのメッセージで、誰かがプロンプトを入力する前にAgentのコンテキストに注入される常時オンのルール。「認証情報を平文で保存しない」など、本当に普遍的なルールのために予約してください。毎ターン読み込まれるため、すべての単語がAgentのコンテキスト予算の一部を使います—短く保ってください。
- ワークスペーススキル — 上記で説明したのと同じスキルで、ワークスペース内の全員が利用でき、一元管理されます。関連するタスクが呼び出すまでほぼコストがかからないため、出力を劣化させることなく多くを提供できます。
セキュリティについて
ReplitのSkillsパネルのスキルは安全性が審査されています。しかし、スキルはどこからでもインストールできます—スキルは誰でも貢献できるオープンソースリポジトリから来ます。 スキルはAgentが従う指示なので、悪意のあるスキルがAgentにプロジェクトから機密データを持ち出すよう指示する可能性があります。外部ソースからスキルをインストールする前に:- ファイルを開く。 スキルはただのMarkdownです。使用する前に
/.agents/skills/の内容を読んでください。 - ソースを確認する。 スキルが信頼できるリポジトリや作者から来ていることを確認してください。
- 指示内容を確認する。 スキルが疑わしい外部URLを参照したり、機密情報を要求したりしていないことを確認してください。
スキル vs MCPサーバー
スキルとMCPサーバーはエージェントを拡張する2つの主な方法で、それぞれ異なる目的を持ちます。 スキルはコンテキスト効率的です。スキルが呼び出されるまでは、簡単な説明だけが読み込まれます。スキルの使用場面:- ワークフローと規約(「デプロイの方法」、「コードレビューチェックリスト」)
- リファレンス資料(APIパターン、スタイルガイド、デザインシステム)
- 再利用可能なプロンプトと専門知識(アニメーションライブラリ、フレームワークパターン)
- 外部サービスへの接続(Notion、Linear、Figma)
- APIアクセスが必要なアクション
- 指示するのではなく、実際に何かをするツール
次のステップ
Agentカスタマイズ
チーム全体のワークスペース共通のカスタム指示とスキルを設定する。
スキルを使う
メッセージにスキルを添付したり、プロジェクトにインストールしたり、スキルから新しいプロジェクトを開始したりする。
Agentスキルリファレンス
スキルの構造と仕組みに関する技術的な詳細。
ReplitのMCPサーバー
モデルコンテキストプロトコルを通じてAgentを外部サービスやツールに接続する。
効果的なプロンプト
より明確な指示を書いて、Agentが最初の試みでより近い結果を出せるようにする。