Sabitlenmiş Tweet
Claude 公式のブログがめちゃ参考になったので、分かりやすくまとめる。
「Claude は本来めちゃ賢い。でも Skill の書き方を間違えると、実力を自分で潰してる」という話
Claude は基本、かなり賢い前提で設計されている
だから人間向けの丁寧すぎる説明とか、背景知識の講義みたいなのを書くと、無駄なトークンが増えて判断精度が落ちるらしい
ここがまず重要な前提
Skill って「知識を教える場所」じゃなくて「行動を成功させるための設計図」なんよね。で、よくある失敗がこれ
Claude に不安になって、「念のため説明しとこ」「一応ここも書いとこ」ってやると、Skill が太って、コンテキストを圧迫して、結果として性能が下がる
公式が言ってるのはかなりドライで、
- Claude はもう十分賢い
- 本当に知らないことだけ書け
- 1 トークンごとに価値を疑え
という思想。次に出てくるのが「自由度」の話。タスクには性質があって、
- 壊れやすい処理
- 順序や正確さが命の処理
こういうのは、自由度を極限まで下げて「これを、そのまま、絶対にこの順でやれ」と書くべき
逆に、
- レビュー
- 分析
- 方針決め
みたいなやつは、ガチガチに縛ると逆に弱くなる。このへんは「判断の余地」をちゃんと残す。この自由度設計が、Skill の出来をほぼ決める
公式のたとえが面白くて、Claude を「道を進むロボット」に例えてる。崖だらけの細い橋なら、ガードレール必須。何もない草原なら、方向だけ示して放置でいい
Skill はこのガードレール設計の話
あと、めちゃ大事なのが name と description
Claude は起動時に、全 Skill の「名前と説明」だけをまとめて読み込む。つまり、
- ここで選ばれなかった Skill は
- SKILL .md がどれだけ良くても
- 一生読まれない
description には『何をするか』だけじゃなく『どんなときに使うか』まで書け、と強調している。ここが弱いと、そもそも Skill 候補に上がらない
で、SKILL .md 本体について
全部を書こうとするな、が原則。
SKILL .md は README じゃない。
目次であり、ナビゲーション。
必要になったら、
- reference .md
- examples .md
- forms .md
みたいな別ファイルを読ませる。これが Progressive Disclosure という考え方
ファイルは読まれない限りコンテキストを消費しない、という前提があるからこそ、目次に徹して、必要になった瞬間だけ別ファイルを読ませる設計が効く
全部最初から読ませるのは最悪。必要なときに、必要な分だけ。ただし注意点があって、「参照の参照」はやるな。
SKILL .md → A .md → B .md みたいな構造にすると、Claude が部分読みして事故る
SKILL .md から直接リンクする 1 段構造が安全。
次にワークフロー。複雑な作業は、文章で説明するな。チェックリストにしろ。
Claude 自身が「今どこまで終わったか」「次に何をやるか」を自己管理できる形がベスト。
さらに重要なのが、一発成功を前提にするな、という思想
実行 → 検証 → 修正 このループを最初から Skill に組み込む
特に Skill に含める処理については、Claude にコードを生成させるより、あらかじめ用意したスクリプトを実行させる方がいい、と言い切っている
理由は単純で、
- 再現性が高い
- 速い
- トークンを食わない
から。Skill に含めるスクリプトは「生成させるため」じゃなく「実行させるため」に置く
あと地味だけど重要なのが、時間依存の情報を書くな。「◯ 年 ◯ 月以降は〜」みたいなのは Skill を腐らせる。古い情報は Old patterns として隔離しろ、という設計
最後に一番思想的なところ
Skill は、評価から作れ。
まず Claude が失敗した実例を集める
それをテストケースにする
それを通すために、最小限の Skill を書く
想像で書いた Skill は、だいたい使われないってことらしい
まとめると、このページが言ってるのはこれ
- Claude を「何も分かってない新人」として扱うな
- 「めちゃ優秀だけど、事故るときは事故る同僚」として扱え
- Skill は知識集じゃない。判断ミスしやすい場所にだけ置くガードレール
日本語
