00:04
昨日、「ここは直して。」と言ったのに、 次の文章でまた同じことが起こる。
AIに仕事を頼んでいると、この繰り返しが一番疲れることがあります。 会話が長く残っていることと、次の作業で必要な判断を取り出せることは違うんです。
今日は、Claude CodeのSkillsを使って、 投稿文の確認を一つの手順にする方法です。
すごいプロンプトを一回書いて終わり、ではなく、 使った結果を次の仕事へ戻すところまで扱います。
例えば、元の資料には、「相談を受け付けています。」としかないのに、 AIが、「残り3名です。」と足してしまった。
単に、「もらないで。」と言うだけでなく、 何を根拠に消すのかまで手順にします。
この例で、短いスキルの中身を見ていきます。
Claude Codeでは、スキルは専用フォルダに置いた skill.md というファイルで定義します。
個人で使う場所と、そのプロジェクトだけ使う場所があります。
公式の手順に沿って、名前とどんな時に使うか、 具体的な進め方を書きます。
ここで大事なのは、 全ての会話を巨大な手順書へコピーしないことです。
今回の投稿文チェックなら、対象の原文を読む、 追加された事実を探す、直す理由を示す、という一つの仕事に絞れます。
手順書があるだけで、どんなモデルでも 毎回同じ品質になるとは言えません。
だから、手順に加えて、 どういう出力なら困るかも見本にします。
今日は作れるファイルを資料に入れているので、 形をゼロから考える必要はありません。
自分の仕事に当たるところを変えて使えます。
AIへ仕事の型を渡すとき、良い完成例だけを置くと、 表面の言い回しだけに見せることがあります。
良い例と直す必要がある例を一組にしてください。
例えば原文は、初回相談を受け付けています。
悪い例は、根拠のない今だけ残り3名を加えた文。
直した例は、追加を消した初回相談を 受け付けていますという文です。
相談内容を補う案は、事実ではなく、 提案として別に返します。
この3つを並べると、禁止したいのは、 強い言葉すべてではなく、
原文にない事実を作ることだとわかります。
短くするために、大事な条件まで消した文も、 別の悪い例として置けます。
好みだけの指示より、 どこを見て判断したのかまで残すのがポイントです。
今回の手順は4つです。
まず、元の資料と依頼の目的を読む。
次に、文章の中の事実と提案を分ける。
3つ目に、資料で確かめられない数字や条件を探す。
最後に、直した文と直した理由を一緒に返します。
これを実行するときは、対象の文章だけでなく、 称号する原資料も渡します。
文章だけ見て、正しいかどうかを AIに当てさせないためです。
元資料が足りないときは、 確かめられる部分だけを直して、
不要な項目を別に返します。
ファイルと良い例、悪い例は、 LINEの育つ手順で受け取れます。
03:02
長いルール集を増やすための資料ではありません。
自分の一つの仕事で、次に同じミスを 見つけられるかを試すためのセットです。
ここから、作った後にどう直すのかを話します。
スキルを直すときは、今うまくいかなかった 一文だけで確認しないでください。
その一文は直っても、前に正しくできていた 文章を壊すことがあるからです。
例えば、数字を削るとだけルールを足すと、 根拠のない残跡は消えても、
資料にある料金や日付まで消えてしまいます。
そこで、根拠のない数字は止める例と、 根拠がある料金は残す例の両方で試します。
変更したルール、試した入力、前と変わった結果を残す。
うまくいったかどうかは、手順書の文字数ではなく、 次の実際の仕事で判断します。
直したつもりで終わらせず、守りたかった良さが 残っているかも一緒に見てください。
クロードコードのスキルを初めて作るなら、
置く場所、ファイル、呼び出し方の3つを押さえてください。
自分の複数の仕事で使うなら、個人用のスキルフォルダー。
今のプロジェクトだけで使うなら、 そのプロジェクト内のスキルフォルダーへ置きます。
正確な保存先は、画面に出しています。
今回のフォルダ名は、PostFactCheck。
その中に、大文字のスキル.mdというファイルを置きます。
冒頭に名前と投稿文を原資料と 称号する時に使う、という説明。
その下に、資料を読む、数字と条件を称号する、 修正文と理由を返す、という手順を書きます。
保存したら、スラッシュに続けてスキル名を入力し、 投稿文と原資料を渡します。
返ってほしいのは、直した文、 直した理由、確認が必要な点。
まず1つ実行して、根拠のある料金まで 消してないかも確かめる。
ここまでが、手順を書いて終わりにしない 最初の1回です。
