コスト計算を頼んだのに、きれいに整形された数字の一覧が返ってくる。編集できる手紙が必要なのに、届くのは地の文だけ。違いは小さく聞こえますが、その結果を使って誰かが作業を続けられるかどうかを左右します。スキルはまさにこのギャップに対応するものです。汎用AIに、特定の作業のための追加の指示とリソースを与えます。
以下の十の例は、Anthropicが公開している スキルリポジトリから取り上げたものです。これはランキングではなく、タスクマップです。紹介している利用例は私たち独自のものです。選定にあたっては元の指示内容を確認しましたが、それは私たち自身による性能テストには当たりません。
スキルは新しい知識の蓄えではなく、作業のやり方です
新しい同僚への依頼書を思い浮かべてください。彼女は目標のほかに、テンプレート、特殊なケースのためのルール、そして求める成果の説明を受け取ります。スキルはこうした情報をひとまとめにできます。ただし、スキルが存在するからといって、必要なすべてのファイルへのアクセス、適切なプログラム、十分な権限があることの証明にはなりません。こうした前提条件は、引き続き実際に作業が行われる場所の側にあります。
ですから、まず成果について考えてください。成果物は計算し続けるものですか、編集するものですか、印刷するものですか、それともブラウザで使うものですか。そのほうが、拡張機能をできるだけ多く有効にするよりも理にかなった選択につながります。
具体的な最終成果物がある四つのファイル作業
- docx: 箇条書きが、本物の見出しと編集可能なタスクリストを備えたボランティア向けの手紙になります。受け取ったら最初に、実際のファイルで変更を加えてみてください。
- pdf: 自分の文書から、具体的に名前を指定した表をページ番号付きで抽出します。欠けている値は欠けているとわかる状態のまま残り、読み取れないスキャン部分がもっともらしい数字で置き換えられることはありません。
- pptx: プロジェクトの状況が、編集可能な五枚のスライドになります。各スライドには一つの役割を持たせます。出発点、経過、問題、決定、次のステップです。
- xlsx: 資材リストに、変更可能な入力値と数式が入ります。数量を変更した人は、その計算を自分でたどることができます。
ここでは、チャットでの回答だけが重要なのではありません。想定しているアプリケーションでファイルを開き、意味のある部分を変更してみてください。表の範囲が誤って画像として出力されていると、見た目には説得力があっても、必要な後続作業ができなくなることがあります。
デザインとエンジニアリングの間にある三つのスキル
frontend-design は、明確な目的を持つインターフェースに適しています。使える依頼書では、対象者、内容、最も重要な操作を明示します。「日付がひと目でわかり、申し込み方法が明確なワークショップ登録ページ」のほうが、「モダンにして」よりも方向性をはっきり示せます。
webapp-testing は、Webアプリケーションの動作に焦点を当てます。自分で作ったローカルのフォームなら、空の入力、不正な入力、完全な入力をそれぞれ別のケースとして指定できます。スクリーンショットと、実際に最後まで操作できる流れとでは、答えている問いが異なります。
mcp-builder は、ツール向けのインターフェースの構築に関わるものです。私たち自身の例で言えば、入力が明確で、応答が限定され、結果がない場合もわかりやすい、読み取り専用の会議室照会です。こうしたサーバーを開発するためのスキルがあるからといって、任意の第三者のアカウントを使ってよいという許可になるわけではありません。
繰り返し行う三つの作業のやり方
skill-creator は、独自のスキルの下書きや改訂を支援します。まずは繰り返し発生するタスクと、エラーが目に見えるようになるいくつかのケースから始めてください。 internal-comms は、「完了」「次にやること」「停滞中」という明確なチーム向けの近況報告に適しています。確定した決定事項と提案は分けておくべきです。
canvas-design は、具体的なビジュアルのアイデアを持つイベントポスターのような、静的なデザインにつながります。後で実際に使うサイズで評価してください。優れた下書きであっても、印刷制作や完全なビジュアルアイデンティティに関するあらゆる問いに自動的に答えられるわけではありません。
コレクションではなく、一つのタスクから始めましょう
スキルを一つ選び、小さな納品条件を書きます。元データ、出力形式、関連する品質要件を一つ、そして許されない振る舞いを一つです。例：「編集可能なタスクリストを作成すること。確定した担当はそのまま引き継ぎ、名前が欠けている箇所は空欄のままにすること。」これにより、出力を具体的に評価できます。
該当するライセンスと必要なツールも確認してください。公開されていて閲覧できるからといって、自動的にオープンソースであるとは限りません。ドキュメント系スキルの場合は特にそうです。目的がはっきりしない大きなコレクションよりも、結果を理解できる扱いやすい数のスキルのほうが、日々の業務では役に立ちます。
出典および資料の確認時点：2026年十月25日。
