繰り返し業務をSkillにする方法：手順・例外・確認を一枚にまとめる

「毎回同じ部分」がある仕事を選ぶ

週報、会議メモ、原稿のチェックなどには、毎回変わる情報と、毎回守る手順があります。前者を入力、後者をSkillの候補として分けます。毎回違う経営判断まで一つのSkillに押し込むより、決まった確認作業を先に取り出しましょう。

最初の対象には、短い匿名サンプルで評価でき、失敗してもやり直せる作業を選びます。たとえば「週報を送る」全体ではなく、「週報の下書きに必要な情報が揃っているか確認する」までに絞ります。送信は別の操作として残せます。

5つの欄で、手順を設計する

この段階では、ファイル保存や外部接続の技術を選ぶ必要はありません。まず別の人が読んでも同じ確認をできるかを見ます。「分かりやすくする」「いい感じにする」という表現が残ったら、良い例と悪い例を一つずつ足して意味を具体化します。

Skillの名前を広くしすぎると、関係の薄い依頼でも選ばれやすくなります。「業務改善」より「週報の提出前チェック」のように、使用する場面が分かる名前と説明が実用的です。

指示・参考資料・コードの役割を分ける

Agent Skillsの仕様ではSKILL.mdを中心にし、参考資料、スクリプト、素材を添付できます。最初は指示と小さな評価例から始め、決定的な処理が必要になった部分へコードを足すと構成を理解しやすくなります。

Codeを付ければ自動的に品質が上がるわけではありません。環境依存、エラー時の処理、依存ツールの更新も考える必要があります。すでに安定したCLIやコネクタがあるなら、それを使う手順を説明する方法もあります。

APIキーや個人情報をSkillへ埋め込まないことも設計の一部です。配布する素材には、架空例と差し替えるべき項目を使い、必要な認証は利用者の環境で管理する前提を明示します。

根拠：Agent Skills — Specification

成功例だけで評価しない

• 通常例：見出しと内容が揃った短い週報。不要な指摘を大量に出さないか。
• 不足例：担当者や期限の欠落。推測せず不足を指摘できるか。
• 矛盾例：本文では未完了、まとめでは完了。矛盾の両方を示せるか。
• 対象外：会議日程の変更依頼。週報チェックを無理に当てはめないか。

合格条件は表現の一致ではなく、必要な事実と不明点の扱いで定めます。修正前と修正後へ同じ入力を渡し、改善した項目と悪化した項目を記録してください。

たとえば不足の指摘が増えても、正しい内容まで誤って修正し始めたなら改善とは言い切れません。「見逃し」と「余計な指摘」を両方見ることで、現場での確認負担を評価できます。

共有する前に、他の人が始められる説明を付ける

自分の端末で一度動いたことと、他の人が使えることは別です。作業を始める場所、必要なアプリ、入力サンプル、期待する出力、失敗時の戻し方を付けます。環境要件は具体的な版と確認日を残すと後から再確認しやすくなります。

配布には、ローカルSkill、リポジトリ、プラグインなどの方法があります。OpenAIの現在の案内は、手順をSkillとして作り、他の人にインストールしてもらう場合のプラグイン化を説明しています。配布先の最新形式に従い、古いカタログの案内をそのままコピーしないようにします。

販売する場合は、手順の品質に加え、利用許諾や支援の範囲を説明します。「どんな入力でも成功」「すべてのエージェントで動く」といった表現を避け、実際に確認できた条件を示しましょう。

根拠：OpenAI — Build skills

改善する場所は、失敗の記録から一つ選ぶ

使うたびに指示を付け足すと、後から全体が読みにくくなります。まず失敗を、入力不足、判断基準の曖昧さ、環境の問題、外部サービスの問題に分けます。原因が違えば、直す場所も変わります。

一度に大きく変えず、たとえば「期限がない場合の扱い」だけを修正して評価例を再実行します。良くなった理由を説明できる変更を積み重ねる方が、手順を引き継ぐときにも役立ちます。