すべての記事へ戻る
記事

Agent Skillsとプロンプト:それぞれを使う場面

著者:

プロンプトはAIへの依頼、Agent Skillは再利用できる作業手順のパッケージです。週次報告の例から、保存プロンプトで十分な場合とSkillが役立つ場合を判断します。

ぴったり収まる手順カードを収納した、開いた書類フォルダー

毎週金曜日、仕事のメモを週次報告へまとめるようAIアシスタントに頼みます。完了済みと予定を分ける、問題点を見える状態にする、締切を作らない、という同じ規則を毎回伝えています。今週の事実は変わっても、報告規則は変わりません。

保存したプロンプトで十分かもしれません。対応エージェントで繰り返す規則を再利用できるパッケージとして管理したいなら、Agent Skillを検討する価値があります。Skillはプロンプトを不要にせず、欠けた事実を補わず、報告の正しさも保証しません。

Agent Skillsの概要は、再利用する知識と作業手順のフォルダー形式を説明しています。ここでいう「Skill」はこの技術的な意味で、訓練によってモデルが新しい能力を身につけたという一般的な主張ではありません。形式は2026年9月7日に確認しました。

固定部分と変わる部分を比べる

問い1回の依頼用プロンプトAgent Skill
繰り返す規則はどこか渡す、または再利用する文章管理された手順パッケージ
今週の事実はどこか現在の入力現在の入力またはアクセス可能な情報源として引き続き必要
例やテンプレートは使えるか依頼に含められる補助リソースとして同梱できる
アプリに必要な対応は関連する依頼と入力を受け取ることSkillを検出、使用し、必要なツールを扱うこと
結果が使える証拠は報告を確認すること同じ報告の確認

プロンプトも長く再利用でき、Skillも短い手順だけにできます。長さが違いではありません。繰り返す手順をどう保存し、利用可能にし、保守するかが実務上の違いです。

パッケージを作る前に、繰り返す依頼を試す

架空の週次メモです。

月曜日にヘルプページの下書きを完了。
Minaにレビューを依頼。まだ返信なし。
レビュー後に公開。公開日は未合意。
検索バグを再現。修正は未着手。

一度だけの報告なら、次の依頼で十分に作業を示せます。

このメモを「完了」「他者の対応待ち」「次の作業」の3節からなる
週次報告にしてください。
完了済みと予定の違いを保ってください。
担当者、日付、承認、進捗を作らないでください。
重要な事実が欠けていれば「未確認」と記してください。

[今週のメモを貼り付け]

「Minaが下書きを承認。金曜日に公開」と書いた報告は二重に失敗です。洗練された報告の依頼は、どちらの創作も許可していません。確認基準は、下書きが完了、レビューは未完、公開日は未合意、バグは再現済みだが未修正、という点です。

たまにしか報告を書かないなら、依頼を文書へ保存し、必要時に貼り付ければよいでしょう。新しいインストールや保守作業を増やさず、手順を再利用できます。

Skillは繰り返す部分を分けて保存する

対応エージェントでは、同じ報告規則をweekly-updateフォルダー内のSKILL.mdへ保存できます。形式仕様では、YAMLメタデータの名前と説明、それに続くMarkdown手順が必要です。

以下は筆者による最小構成の設計例で、インストール済みSkillでもベンチマーク結果でもありません。

---
name: weekly-update
description: Turn work notes into a factual weekly update. Use when drafting a recurring weekly status report from supplied notes.
---

# Weekly update

Read the supplied notes. If none are provided, ask for them.

Write three sections:
- Completed
- Waiting on others
- Next work

Keep planned work separate from completed work.
Do not invent owners, dates, approvals or progress.
Mark essential missing information as not confirmed.
Before returning the report, check each status against the source notes.
Return a draft; do not send it to anyone.

今週のメモをこの手順へ恒久的に入れてはいけません。「Minaから返信なし」をSkillへ埋め込むと、来週には古くなります。毎回新しい事実を渡し、繰り返す工程だけをパッケージで管理します。

現在の依頼は変動する入力へ集中できます。「weekly-update Skillを使い、このメモから今週の報告を作成してください」。エージェントはなおSkillを見つけ、従う必要があります。使用クライアントのインストール・呼び出し手順に従ってください。PCのどこかにフォルダーを作っただけでは利用可能になりません。

パッケージ化はテストの代わりにならない

形式上、必要になる前に短い説明だけを検出し、後から詳しい手順を読み込めます。長い再利用手順を無関係な作業から外せますが、どのクライアントもあらゆる依頼表現で正しいSkillを起動するとは証明しません。

同じ架空メモで、保存プロンプトとSkillを比べます。見出しだけでなく正確な事実を探してください。次にメモを完全に削除します。入力を求めるか、架空の状況報告を生成するかを見ます。最後にレビュー済みという事実を渡し、影響する状態だけが変わるか確かめます。

これは提案する合格例です。クライアント間で測定していないため、精度や速度向上は主張しません。AnthropicのSkillsに関する技術記事も、大きなパッケージがよいと考えるのではなく、代表的タスクと観察した弱点から始めるよう勧めています。

Skillにはスクリプトも含められます。他者のパッケージは、特にファイルアクセスや外部接続を求める場合、使用前に動作を確認してください。報告を書く手順と、報告を送信するコードは別物です。パッケージが存在しても、記載された全操作への許可にはなりません。

Skillを保守する価値がある場面

報告規則、テンプレート、合格例、ツールを使う手順など、複数の要素が一緒に繰り返されるならSkillを検討します。一つの管理されたパッケージが、各要素を更新し、変更後に確認を繰り返す場所になります。

作業がまれ、規則が短い、アプリが形式に対応しない場合は保存プロンプトを使います。曖昧な手順はファイルへ移しても明確になりません。まず確認できる報告を一つ作り、その後、繰り返す手順と毎週変わる事実を分けてください。

参考資料