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

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

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

最初に試す業務には、個人情報を含まない短いサンプルで検証でき、失敗してもすぐにやり直せる作業を選びます。たとえば「週報を送る」一連の流れ全体ではなく、「週報の下書きに必要な情報が揃っているかの確認」だけに絞り込みます。送信自体は手作業として残しておけば安心です。

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

この設計段階では、ファイル保存や外部ツール接続などの技術選定を急ぐ必要はありません。まずは自分以外の担当者が読んでも同じ手順でチェックできるかを見直しましょう。「分かりやすく」「適切に」といった曖昧な表現があれば、OKな例とNGな例を1つずつ書き添えて基準を具体化します。

Skillの名前や用途説明を大まかにしすぎると、意図しない質問や無関係な依頼のときにもAIが誤ってそのSkillを選んでしまいます。「業務改善」のような抽象的な名前ではなく、「週報の提出前チェック」のように、どんな場面で呼び出すのかが一目で分かる具体的な名称を付けましょう。

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

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

スクリプトを添付したからといって、自動的にSkillの品質が上がるわけではありません。パソコン環境による動作の違いやエラー時の対応、外部ツールの更新管理といった保守の手間も生じます。すでに安定して動いている既存ツールがあるなら、新しくコードを書く代わりにそのツールの操作手順を記述するだけでも十分です。

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

根拠：Agent Skills — Specification

04成功例だけで評価しない

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

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

たとえば、入力不足をしっかり指摘できるようになったとしても、問題のない箇所まで誤って修正し始めたなら改善とは言えません。「見逃しの少なさ」と「誤った指摘の少なさ」の両面を確認することで、現場での手直し負担が本当に減っているかを正しく評価できます。

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

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

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

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

根拠：OpenAI — Build skills

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

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

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