Skillsで繰り返す仕事を標準化する

この記事で学ぶこと

• 安定した仕事から標準化する
• 発動条件と例外を具体化する
• 結果の品質で手順を直す

繰り返す仕事を選ぶ

Skillは、特定の仕事で使う指示や手順を再利用するためのまとまりです。

Claude Codeの公式資料では、SKILL.mdに名前や説明、指示を書く仕組みが案内されています。

実際の配置方法や起動方法は利用環境の公式資料で確認します。

本教材では、設定操作より先に、何を標準化する価値があるかを考えます。

対象には、入力と出力が似ていて、繰り返し発生する仕事が向いています。

架空の例では、週2回、資料から記事の構成案を作ります。

毎回、読者、目的、根拠を確認し、見出しと不足情報を出します。

この共通手順をまとめれば、依頼のたびに条件を思い出す負担を減らせます。

頻度だけでなく、確認の手間も選ぶ基準です。

一度きりの企画や、毎回前提が大きく変わる判断は、すぐSkillにする必要はありません。

先に数回手作業で試し、安定している工程を見つけます。

まだ方法が定まらないのに固定すると、悪い手順を繰り返すことになります。

再利用するのは、過去の出力そのものではなく、良い結果へ進むための手順です。

型にする候補は、過去の依頼を比べて探します。

毎回同じ資料確認と見出し整理をしているなら、その部分が候補です。

一方、対象読者の決定まで案件ごとに異なるなら、入力として渡す項目にします。

変えない手順と毎回変える条件を先に分けておきましょう。

再利用の候補を探すには、前回と今回で変わった材料と、同じだった手順を分けてみます。

資料の内容は毎回変わっても、根拠の抽出と構成の照合は共通かもしれません。

変わる部分を入力として明示すると、特定の記事だけで通用する手順を汎用の仕事と取り違えずに済みます。

発動条件を具体的にする

説明欄には、何を頼まれたときに使うのかを書きます。

「文章を良くする」では対象が広すぎます。

「提供された資料から、初学者向け解説記事の構成案を作る依頼で使う」なら役割が明確です。

完成原稿の執筆や、資料にない事実の調査も担当するのかを区別します。

発動条件には対象外も必要に応じて書きます。

この例では、個別メールの返信や広告コピーは別の仕事です。

同じ文章でも、読者の状況と合格条件が異なります。

役割を広げすぎると、記事構成の手順をメールへ適用するようなずれが起きます。

最初は用途を狭くし、実績から共通化できる範囲を見極めます。

入力が足りない場合の扱いも決めます。

読者が不明なら確認する、資料がないなら構成を断定せず必要資料を示す、という分岐です。

単に「不足なら質問」と書くだけでは、細かな不足まで毎回止まる場合があります。

作業を始められない重要条件と、仮定を明記して進められる条件を分けておくと使いやすくなります。

発動しない例も書いてみます。

構成案を作る用途なら、完成原稿の事実確認やSNSへの投稿は別の仕事です。

似た単語が含まれるだけで使う範囲を広げないよう、対象と対象外を一組にすると、他の手順との重なりを見つけやすくなります。

似たSkillが複数ある場合は、使い分けを説明欄で確認できるようにします。

構成案作成と完成原稿の修正が同じ説明では、適切な手順を選びにくくなります。

入力と成果物の違いを短く示すことが有効です。

名前のかっこよさより、依頼した人が用途を選べることを優先してください。

入力から出力までをつなぐ

手順は、実際の成果物が次の工程に渡る順番で書きます。

記事構成なら、読者と目的を整理し、資料から使える事実を抜き出し、見出しを並べ、各節の答えと具体例を置きます。

最後に不足する根拠を一覧にします。

「よく考える」「質を上げる」では、何をするかも確認方法も分かりません。

出力形式は、利用する人が次の仕事へ進める形にします。

見出しだけでなく、節ごとの主張、使用資料、具体例の予定を添えると、執筆時に使えます。

架空の完成例なら「第2節：資料不足の見分け方。根拠は配布資料3ページ。例は数値の出典がない場合」です。

形式の美しさより、判断材料が欠けていないかを優先します。

参考文書を追加する場合は、本文へすべて埋め込まず、何のときに読むかを示します。

表記ルール、過去の良い例、採点表は役割が異なります。

過去例を唯一の正解にすると、題材が変わっても同じ構成になります。

例は参考であり、今回の目的と資料に合わせて変える条件を明記します。

出力の見本は、表の形だけでなく根拠の位置まで示します。

各見出しの下へ主張、使う資料、足りない情報を置けば、次に本文を書く人が迷いにくくなります。

見本の題材をそのままコピーするのではなく、今回の資料から各欄を埋める手順にしてください。

保存先は、次の執筆担当が見つけられる場所を指定します。

会話だけに構成が残ると、別の作業者が参照しづらくなります。

資料の一覧と構成案が対応していれば、どの根拠で書くかを再調査する負担も減ります。

成果物の使われ方まで含めて出力形式を設計します。

失敗時の分岐を入れる

再利用する仕事ほど、通常の入力だけでなく例外を考えます。

資料同士で数字が違う、古い版しかない、読者と内容が合わないといった場合です。

記事構成では、根拠が食い違えば勝手に一方を採用せず、出典と差を一覧にします。

資料の不足を滑らかな文章で埋めない条件が必要です。

停止条件は、成果の信頼性や権限に影響するものへ絞ります。

必要な資料が読めない、公開権限がない、入力に秘密情報が含まれるなどです。

一方、見出しの順番が複数考えられる程度なら、案と採用理由を示して進められます。

すべての判断を停止条件にすると、手順の再利用が確認の増加につながります。

外部への保存や送信を含める場合は、Skillを使ったことだけで許可が得られたとは考えません。

仕事の依頼と環境の権限に従います。

本教材の練習では、構成案を指定の練習フォルダへ保存するところまでとします。

操作の範囲が明確な状態で手順を試し、必要が出てから連携を増やします。

途中で条件が変わる例も試します。

想定読者が変わった場合、見出しだけを調整すればよいのか、資料の選び直しが必要かを確かめます。

以前の入力を使い続けてはいけない条件を明示すると、形式は整っていても目的に合わない成果物を減らせます。

例外分岐には、再開するために必要な入力も書きます。

引用元が不明なら、資料名と該当部分が必要です。

読者が未定なら、誰が何を判断する記事かを確認します。

停止の宣言だけで終わらず、何が届けば続けられるかを示すと、担当者が必要な情報を返しやすくなります。

見本と例外で評価する

Skillを書いたら、過去の成功例だけで試すのではなく、通常の資料と不足のある資料を用意します。

通常例では使える構成案が出るか、不足例では不明点を正しく残すかを見ます。

どちらも同じ出力になるなら、条件分岐が働いていない可能性があります。

採点は、根拠との対応、読者への適合、出力項目の充足など、実務に必要な軸で行います。

毎回同じ見出しが出ることは合格条件ではありません。

今回の資料に応じた構成であり、事実を作っていないことを確かめます。

出力が短くなった、実行が速かったという理由だけで採用しないようにします。

修正は、失敗した条件に対応する箇所へ加えます。

説明が長すぎて発動範囲が曖昧なら説明欄、出典が抜けたなら出力形式、資料不足を埋めたなら例外分岐を直します。

SkillとCLAUDE.mdに同じルールを重複させすぎず、プロジェクト共通の条件と仕事固有の手順を分担させて保守します。

使った結果の記録には、修正した箇所と理由を残します。

毎回同じ出典欄を直しているなら、出力例か確認手順を改善する候補です。

単に成功したかを数えるより、手作業がどこへ残ったかを見ると、次に整える部分と、その効果を判断できます。

変更したSkillの評価結果には、どの条件を直したかを記録します。

根拠不足の見本で改善したとしても、通常の構成が長くなりすぎることがあります。

修正した例と以前成功した例の両方を見てください。

用途に必要な範囲で比較すれば、手順の改善が別の品質を損なっていないか確認できます。

まとめ

Skillは、繰り返す仕事の入力、手順、出力、検証を揃える仕組みです。

用途を狭くし、通常例と例外で試すと、実務で使えるか判断できます。

次は週に繰り返している仕事を1つ選び、設定より先に手順の草案を作ってください。

• 安定した仕事から標準化する
• 発動条件と例外を具体化する
• 結果の品質で手順を直す