claudefableにskillを書かせる前に、先に決めておくべきこと

前回、claudefableには目の前の作業を片付けてもらうより、SonnetやOpusを動かすためのskill設計をしてもらう方がよいのでは、という話を書きました。

ただ、そのあとで少し考えました。

skillという言葉だけを見ると、どうしてもエンジニア向けの話に見えます。

Claude Code。
Sonnet。
Opus。
Fable。
ハーネス。
エージェント。

このあたりの言葉が並ぶと、「はい、専門家の話ですね」と距離を取りたくなります。

正直、私も最初はそう感じます。

でも、自分なりに整理すると、skillはコーディング専用の話ではないと思っています。

もっと広く言えば、

AIに毎回同じ品質で作業してもらうための作業手順書

に近いものだと感じています。

たとえば、AIに頼むことはコードだけではありません。

note記事の下書きを作る。
長い文章を要約する。
メール文面を整える。
議事録を整理する。
研修資料を作る。
専門用語をやさしく言い換える。
調べものの確認ポイントを出してもらう。
知らないAI用語を、初めて聞く人にも分かるように説明してもらう。

こういう作業でも、毎回なんとなくAIに頼むと、返ってくる内容がぶれます。

ある日は丁寧すぎる。
ある日は軽すぎる。
ある日は商材っぽい。
ある日は専門用語が多すぎる。
ある日は根拠のないことまで断定している。

AIは便利です。

ただ、こちらの頼み方が毎回ふわっとしていると、出力もふわっとしやすいです。

だからこそ、skillを書かせる前に、先に決めておくことがあると思っています。

まず、何の作業を安定させたいのか

最初に決めるべきなのは、何をしてもらうskillなのかです。

ここが曖昧だと、skillはただの長いプロンプトになります。

たとえば、

文章を読みやすく整えるskillなのか。
note記事の構成を作るskillなのか。
難しいAI用語をやさしく説明するskillなのか。
メール文を失礼のない表現に直すskillなのか。
議事録を要点ごとに整理するskillなのか。
調べものの確認ポイントを出すskillなのか。

ここを決めないまま「いい感じに使えるskillを作って」と頼むと、AI側も広く解釈してしまいます。

人間でも同じです。

「いい感じにやっておいて」と言われるより、

「会議メモを、決定事項・保留事項・次にやることに分けて整理して」

と言われた方が動きやすいです。

AIもそこはあまり変わらないと思っています。

次に、誰向けの出力なのか

同じ内容でも、誰に向けて書くかで言葉は変わります。

中高年向けなのか。
AI初心者向けなのか。
職場の上司向けなのか。
現場職員向けなのか。
note読者向けなのか。
Xに投稿する短文なのか。
社内文書なのか。

ここを決めておかないと、AIの文章は急にビジネス文書のようになったり、逆に軽すぎたりします。

特に、専門用語に慣れていない人へ向けて書きたい時は、ここが大事です。

AIは放っておくと、専門用語をそれっぽく並べてくることがあります。

たしかに間違ってはいない。
でも、読んだ人が分かった気になれない。

それでは意味がありません。

skillにするなら、

専門用語を使う場合は、必ず身近な例に置き換える。
初めて聞く人にも伝わる順番で説明する。
分かったふりをさせる文章ではなく、読んだ後に少し使える文章にする。

このあたりを先に決めておきたいです。

どこまでAIに任せるのか

AIを使う時に、意外と大事なのがここです。

どこまで任せるのか。

全部決めてもらうのか。
下書きまでなのか。
要点整理までなのか。
言い換えまでなのか。
比較表までなのか。
最終判断は人間がするのか。

ここを決めないまま使うと、AIの出力が強くなりすぎることがあります。

たとえば、家族への連絡文なら、AIに下書きを作ってもらうのはよいと思います。

でも、その文章をそのまま送るかどうかは別です。

相手との関係。
普段の言い方。
その時の空気。
言わない方がいい一言。

このあたりは、最後に人間が見た方がいいです。

仕事の文書でも同じです。

AIに整えてもらう。
でも、最終確認は自分で行う。

この線引きをskillの中に入れておくと、AIに任せすぎる怖さが少し減ります。

やってはいけないことを決める

skillを書くなら、「何をするか」だけでなく「何をしないか」も決めておきたいです。

ここはかなり重要だと思っています。

たとえば、

根拠のないことを断定しない。
分からないことを分かったように書かない。
個人情報をそのまま出さない。
専門家判断が必要な内容を決めつけない。
読者を不安で煽りすぎない。
商材っぽい言い回しにしない。
難しい言葉を説明なしに使わない。

こういう禁止事項です。

AIは文章がうまいので、間違っていてもそれっぽく見えることがあります。

だからこそ、最初から「ここはやらない」と決めておく必要があります。

これはAIを疑うためではなく、安心して使うための線引きです。

包丁を使う時に、刃の向きを気にするのと同じです。

便利な道具ほど、扱い方を決めておいた方が安全です。

最後に、どんな形で返してほしいのか

AIに頼む時、最後の出力形式も大事です。

ここを決めないと、毎回返ってくる形が変わります。

タイトル案がほしいのか。
本文構成がほしいのか。
記事全文がほしいのか。
X投稿文がほしいのか。
要約がほしいのか。
チェックリストがほしいのか。
次にやることを出してほしいのか。

たとえばnote記事を書くためのskillなら、

タイトル案
記事の狙い
本文構成
本文全文
投稿後のX文面
ハッシュタグ
次の記事候補

この順番で返すように決めておくと、毎回の作業が楽になります。

議事録整理なら、

決定事項
未決事項
担当者
期限
次回確認すること

のように固定できます。

メール文面なら、

件名
本文
少し柔らかい版
少し事務的な版
送る前の確認点

という形でもよさそうです。

このように、最後の形を決めておくと、AIの出力を毎回整え直す手間が減ります。

skillは、AIに渡す作業手順書に近い

skillという言葉は、少し難しく見えます。

でも、私にとっては、AIに渡す作業手順書のようなものだと考えると少し分かりやすくなりました。

何をしてもらうのか。
誰向けに出すのか。
どこまで任せるのか。
何をしてはいけないのか。
どんな形で返してもらうのか。

これを先に決める。

そのうえで、claudefableのような強いAIにskillとして整理してもらう。

この順番が大事だと思っています。

いきなりFableに「良いskillを作って」と丸投げするのではなく、人間側が作業の目的と境界線を決める。

そのうえで、Fableには構造化してもらう。

この方が、あとでSonnetやOpusに渡した時にも使いやすいskillになりやすいのではないかと感じています。

AIの使い方そのものを設計する

エンジニアAI。
Claude Code。
skill。
ハーネス。
エージェント。

こういう言葉は、どうしても専門家向けに見えます。

でも、その中にある考え方の一部は、普段AIを使う人にも関係があります。

AIにどう頼むか。
どこまで任せるか。
どうすれば毎回の出力が安定するか。
分からないことを、分からないまま断定させないためにはどうするか。

これは、コードを書く人だけの話ではありません。

文書作成でも、調べものでも、メールでも、議事録でも、noteでも同じです。

AIを使う人が増えるほど、

「どのAIが強いか」

だけでなく、

「そのAIをどう動かすか」

が大事になってくると思っています。

私自身もまだ手探りです。

ただ、skillという考え方は、ただの専門用語ではなく、AIを安定して使うためのヒントになる気がしています。

このあたりは、しばらく整理していきたいです。

Claudeやskillまわりの話は、専門用語が多くて少し距離を感じます。

だからこそ、

AIをどう使うか。
どこまで任せるか。
どうすれば出力がぶれにくくなるか。

このあたりを、できるだけ分かりやすい言葉で少しずつ書いていきます。

同じあたりを追っている方は、フォローしてもらえるとうれしいです。