毎週の集計資料を同じ手順で整えるなら、依頼文を何度も作る負担を減らせます。
CodexのSkillsは、再利用する指示や手順をまとめるために使えます。
ただし、長い指示文を保存しただけでは、入力の不足や検証漏れが残ります。
このレッスンでは、架空の問い合わせ集計を題材に、役割、手順、例外、合格条件を持つSkillを設計します。
この記事で学ぶこと
- 安定した工程を再利用する
- 入力不足の扱いを決める
- 数字と意味を別々に検証する
再利用に向く仕事を選ぶ
Skillにする仕事は、入力と出力が繰り返し似ているものを選びます。
例えば週ごとの問い合わせ記録から、件数、分類、未対応項目をまとめる仕事です。
資料の場所と完成形式が毎回同じなら、手順を共有する価値があります。
頻度だけでなく、説明し直す負担と確認の手間も見ます。
一方、初めての事業判断や、必要資料が毎回大きく違う企画は、すぐに固定しない方がよい場合があります。
数回試し、どの工程が安定しているかを見てからまとめます。
まだ判断基準が曖昧な仕事をSkillへ入れると、迷いも一緒に繰り返します。
再利用する前に、手順の妥当性を確かめます。
OpenAIの公式資料では、SKILL.mdに説明と指示をまとめる構成が案内されています。
保存場所や利用方法は環境の最新資料で確認します。
本教材では、機能を設定する前に、仕事の設計を完成させます。
人が読んでも何をするか分からない内容は、ファイルにしただけで明確にはなりません。
仕事の選定では、失敗したときに正解を確認できるかも見ます。
集計なら元の記録と件数を照合できますが、根拠のない将来予測は同じように評価できません。
確認可能な工程から標準化すると、Skillの改善が実際の品質へつながったかを測れます。
難しい判断を無理に固定する必要はありません。
入力条件を明文化する
最初に必要な入力を定義します。
問い合わせ集計なら、対象期間、記録の形式、分類基準、重複の扱いが必要です。
「今週の問い合わせをまとめる」だけでは、今週がどの日時までか、同じ人の追加連絡を別件と数えるかが分かりません。
集計の前提を決めることが結果の比較につながります。
入力に個人情報が含まれる場合は、報告で必要な項目と不要な項目を分けます。
件数と傾向をまとめるだけなら、氏名やメールアドレスを出力する必要はないかもしれません。
元資料へのアクセス権と、報告の配布範囲を区別します。
便利だから全項目を転記する、という手順にはしません。
不足した入力の扱いも定義します。
対象期間がない場合は確認する、分類できない内容は「その他」へ入れて理由を残す、といった分岐です。
空の記録と取得失敗は別に扱います。
データが読めないのに「問い合わせ0件」と報告しないことが、繰り返し業務では特に重要です。
重複の基準は、件名が同じなら同一といった単純な規則だけでは足りない場合があります。
同じ人からの追加質問を1件へまとめるか、別の対応として数えるかを業務で決めます。
見本には、この判断が分かれる記録を含めてください。
数える単位の違いが、前週との比較を変えるためです。
手順を成果物へつなぐ
手順は、入力確認、重複整理、分類、集計、照合の順など、処理の流れで書きます。
それぞれに何を残すかを添えます。
問い合わせの原文を短く整理する際も、意味を変えない条件が必要です。
例えば要望と不具合を混同しないよう、判断が難しいものは確認欄へ残します。
出力には、対象期間、総件数、分類別件数、未対応項目、確認が必要な記録を含めます。
件数だけでは、担当者が次に行動できません。
一方、すべての原文を貼ると読みづらくなります。
利用者が判断するために必要な情報へ絞り、詳しい記録へ戻れる識別情報を添えます。
完成例は、形式を理解するために短く示します。
架空の例なら「操作方法3件、請求2件、その他1件。未対応は請求の1件」です。
例の数字を次回の出力へ引き継がないよう、見本であることを明記します。
固定するのは項目と判断の基準であり、結果の内容ではありません。
分類の根拠を残す必要がある場合は、短い理由と記録の識別情報を添えます。
請求についての質問なのか、操作の不具合なのかが曖昧な例で役立ちます。
ただし、原文の全情報を複製する必要はありません。
担当者が必要な記録へ戻れることと、報告の読みやすさを両立する形を選びます。
検証と停止を組み込む
検証は最後に付け足すのではなく、手順の中へ入れます。
分類別件数の合計が総件数と一致するか、対象期間外の記録が混ざっていないかを確認します。
要約が原文の意味を変えていないかは、重要な項目を原記録へ戻って見ます。
数の整合と意味の整合を分けて確かめます。
停止条件は、結果の信頼性に影響するものを選びます。
ファイルが読めない、列の意味が変わった、重複の基準が不明といった場合です。
軽微な表現の違いなら暫定案で進められますが、件数の定義が曖昧なら比較できません。
どの不足なら止めるかを具体的に書きます。
外部共有を含む場合は、Skillの存在だけで送信を許可されたとは扱いません。
共有先と内容が依頼の範囲に含まれるかを確かめます。
練習ではローカルの報告下書きまでとし、配布は別の工程にします。
手順の再利用と外部操作の権限を分けることで、用途を広げる際にも判断しやすくなります。
途中で入力形式が変わった場合の扱いも決めます。
列名が変わっただけなのか、列の意味が変わったのかで対応は違います。
推測で以前の列へ当てはめる前に、必要な項目を照合します。
自動化された手順ほど、形式変更を正常なデータとして通してしまわない条件が必要です。
異なる見本で品質を測る
試す入力は、正常な記録だけにしません。
重複、分類不能、空欄、対象期間外を含めた見本を用意します。
結果がそれぞれの条件を正しく扱うかを確認します。
きれいに整った見本だけで成功しても、実務のばらつきへ対応できるとは限りません。
採点は、件数の正しさ、原文との一致、未対応の見つけやすさなどで行います。
同じ文章が毎回出ることは目的ではありません。
内容が変われば要約や優先事項も変わるべきです。
必要な項目が揃い、担当者が次の対応へ進めるかを評価します。
失敗したら、原因に対応する箇所を修正します。
重複が多重計上されたなら定義、分類がぶれたなら基準、合計が合わないなら検証を直します。
すべてを説明欄へ詰め込まず、発動条件、手順、確認を分けます。
AGENTS.mdにある共通ルールと重複しすぎないようにし、仕事固有の手順をSkillへ集めます。
Skillの採用判断には、人が直した内容も含めます。
最初の出力が高得点でも、毎回同じ分類を手で直しているなら基準が不足しています。
修正箇所を記録し、分類例へ加えるなどの対応を選びます。
説明を増やした後は、別の見本でも使えるかを確認し、特定の例だけへの対処にならないようにします。
実践課題
実践課題：週次集計のSkill案を書く
つくるものは、問い合わせ集計用のSKILL.md草案です。
用意するのは、架空の記録6件と、重複や不明項目を含む追加の見本です。
実際の顧客情報は使いません。
発動条件から検証まで、人が追って実行できる内容にします。
- 対象期間と数え方を含む必須入力を書く
- 対象の仕事と対象外を明記する
- 集計までの手順と出力項目を決める
- 異常な見本で停止条件と照合を試す
架空の完成例：「週次の問い合わせ集計に使う。対象期間と重複基準が必須。分類別件数、未対応、確認事項を出す。合計を原記録と照合する。ファイル取得に失敗した場合は0件と報告せず、取得失敗を残す。」
自己確認
- 数える単位が決まっている
- 手順に検証が含まれる
- 空データと取得失敗を区別できる
まとめ
Skillsでは、繰り返す仕事の入力条件と完成条件を揃えます。
正常な見本だけでなく、重複や不足を含む入力で試してください。
次は1つの週次業務について、どこで判断がぶれるかを調べ、その条件を手順へ反映します。
- 安定した工程を再利用する
- 入力不足の扱いを決める
- 数字と意味を別々に検証する
