あと2日。claudefableには、SonnetやOpusを動かすためのskill設計をしてもらう

あと2日。

claudefableが使えるうちに、やっておきたいことがあります。

それは、目の前の作業を片付けてもらうことではありません。

SonnetやOpusを今後使っていくための、skill設計をしてもらうことです。

ここで言うskillは、単なる便利メモではありません。

「この作業ではこう答えてください」という表面的な指示でもありません。

どの情報を読ませるか。

どの順番で判断させるか。

どこで検証させるか。

どこから先は推測させないか。

どの出力形式で返させるか。

失敗した時に、何を見直させるか。

つまり、モデルの外側にある実行環境をどう設計するか。

最近よく言われる、ハーネスエンジニアリングに近い話です。

モデル単体の性能だけを見る段階ではなくなってきた

少し前までは、AIを使う時に見ていたのは、ほとんどモデル単体の性能でした。

どのモデルが賢いか。

どのモデルが長文に強いか。

どのモデルがコードに強いか。

どのモデルが推論に強いか。

もちろん、それは今でも大事です。

ただ、最近はそれだけでは足りないと感じています。

同じモデルでも、渡す文脈、使える道具、作業手順、検証方法、停止条件が違えば、出力はかなり変わります。

モデルそのものを変えなくても、外側の設計で出力の質が変わる。

この外側の設計が、かなり重要になってきていると思います。

claudefableを作業者として消費するのはもったいない

claudefableが強いなら、難しい作業をそのまま投げたくなります。

複雑な判断をさせる。

長い文脈を読ませる。

曖昧な要件を整理させる。

修正方針を考えさせる。

それは当然便利です。

ただ、あと2日という制限があるなら、使い方を少し変えた方がいいと思っています。

Fableを、作業者として使い切るのではなく、設計者として使う。

SonnetやOpusが今後うまく動くための、ハーネスを設計してもらう。

この方が、あとに残るものが大きいです。

一回分の答えを作ってもらうのではなく、次のAIが答えを作る時の環境を整えてもらう。

今回やりたいのは、そこです。

skillは、モデルへの追加説明ではなく、実行時の設計図になる

skillを雑に作ると、ただの長いプロンプトになります。

それだと弱いです。

本当に作りたいのは、モデルに読ませる説明文ではなく、実行時の設計図です。

たとえば、skillの中で決めるべきなのは、こういうことです。

・このskillは、どんな依頼で発火するのか
・最初に何を確認するのか
・どの情報を必ず読むのか
・どの情報は読まなくてよいのか
・判断する前に、何を分解するのか
・作業中に迷ったら、どの基準へ戻るのか
・結果を出す前に、何を検証するのか
・失敗した時に、どこから見直すのか
・最終出力は、どの形にそろえるのか

ここまで決めておくと、skillは単なる「お願い文」ではなくなります。

SonnetやOpusが作業する時の、足場になります。

Fableに作らせるべきなのは、答えではなくハーネス

Fableが使えるうちにやるべきことは、個別の答えを大量に作らせることではないと思っています。

むしろ、Fableにはこう聞くべきです。

この作業をSonnetに任せるなら、どんなskillが必要か。

この作業をOpusに任せるなら、どこまで自由度を持たせるべきか。

この作業で失敗しやすい判断はどこか。

モデルが推測で進みやすい箇所はどこか。

検証工程をskillに組み込むなら、どの順番がよいか。

出力形式を固定するなら、どこまで固定し、どこは余白として残すべきか。

つまり、Fableに「答えてもらう」のではなく、SonnetやOpusが答えるための環境を設計してもらう。

ここが大事だと思います。

ハーネスが弱いと、強いモデルでもブレる

どれだけ強いモデルを使っても、ハーネスが弱いと出力はブレます。

文脈の渡し方が雑なら、読み違えます。

判断順序が曖昧なら、途中を飛ばします。

検証工程がなければ、それっぽい結論で止まります。

出力形式が決まっていなければ、毎回違う形で返ってきます。

失敗時の戻り先がなければ、同じ場所で空回りします。

これは、モデルが弱いというより、作業環境の設計が弱い状態です。

だから、今後は「どのモデルを使うか」だけでなく、「どんなハーネスで動かすか」が重要になります。

skillは、そのハーネスを持ち運びやすくする一つの形だと思っています。

Fableが使えなくなった後に残るもの

claudefableがサブスクで使えなくなった後、Fableそのものは使えなくなるかもしれません。

でも、Fableに設計させたskillは残せます。

Sonnetに渡せる。

Opusに渡せる。

別の環境に移せる。

必要に応じて修正できる。

育て直すこともできる。

これは大きいです。

強いAIをその場限りで使うのではなく、次のAIの品質を底上げするために使う。

Fableの出力を、そのまま成果物として消費するのではなく、今後のAI運用の土台として残す。

この発想が必要だと思っています。

skill作成で大事なのは、細かく書きすぎないこと

ただし、skillに何でも詰め込めばいいわけではありません。

長ければ強いわけではない。

細かければ安定するわけでもない。

むしろ、余計な説明が多いskillは、モデルの判断を鈍らせることがあります。

大事なのは、どこを固定し、どこを自由にするかです。

手順が崩れると危ない部分は固定する。

判断に幅が必要な部分は余白を残す。

検証が必要な部分は明示する。

モデルが自分で判断してよい部分は、あえて縛りすぎない。

この設計も、Fableに考えさせたいところです。

skillを書くというより、skillの粒度を設計する。

ここを雑にすると、ただ長いだけの指示書になります。

日本語圏でも、この話はもっと出てきていい

海外では、モデル単体の性能だけでなく、エージェントをどう動かすか、どんな実行環境を与えるか、どのように検証させるかという話が増えています。

日本語圏では、まだ「どのAIが強いか」「どのモデルが賢いか」という話が中心になりがちです。

もちろん、それも大事です。

でも、同じくらい大事なのは、強いAIをどう動かすかです。

強いAIを、毎回その場の作業者として使うのか。

それとも、次のAIがうまく動くためのハーネス設計者として使うのか。

この差は、あとから大きくなると思います。

claudefableが使えるうちに、Fableの力をその場の回答で終わらせない。

SonnetやOpusを動かすためのskill設計に回す。

これは、かなり現実的な使い方だと思っています。

まとめ

あと2日。

claudefableには、目の前の作業を大量に処理させるのではなく、今後SonnetやOpusを動かすためのskillを設計してもらいます。

作るべきなのは、便利プロンプトではありません。

モデルの外側にある、実行時のハーネスです。

どの文脈を読むか。

どう判断するか。

どこで検証するか。

どの形式で返すか。

失敗した時にどこへ戻るか。

そこまで含めてskillにする。

Fableが使えなくなった後も、SonnetやOpusの出力品質を底上げするための足場を残す。

今やるべきことは、AIに答えを作らせることではなく、次のAIが良い答えを出すための環境を作ることだと思っています。