マット・ポコック / Matt Pocock · 00:53 「スキル地獄とは、 スキルが全部無料で手に入り、 ダウンロードも貢献も自力での理解もできるのに、 部品同士がどう噛み合うのか分からない状態だ。 良いスキルと悪いスキルの見分けがつかない」
問題設定はユーモアで始まる。 開発者は数年おきに 「地獄」 を見つけてきた、 と Matt は言う。 かつては tutorial hell チュートリアルを次々こなすのに、 断片がつながらず、 抜け出せない循環に陥る状態。 Matt が挙げる過去の 「地獄」 の 1 つ があり、 10 分おきに新しい JavaScript フレームワークが発表される framework hell 新しいフレームワークが次々に登場し、 常に流行りを追い続けなければならない疲弊状態 があった。 そして今あるのが skill hell 使えるスキルが無数に無料で手に入るのに、 部品同士の噛み合い方が分からず、 良いスキルと悪いスキルを見分けられないまま全部を試そうとして成果が出ない状態。 個人だけでなく組織にも起きる だ。 出口の見えない迷路を、 同じ角をぐるぐる回り続ける感覚に近い。 スキルが約束する成果が出ないまま、 「もう 1 個スキルを足せばいい」 という声だけが積み上がっていく。
Matt の処方箋は 4 段構えのチェックリストで、 スキルの (1) trigger スキルがどう起動されるか。 ユーザーが手動で呼ぶか、 エージェント自身が説明文を読んで自動で呼ぶか、 の設計判断 (どう呼び出されるか)、 (2) structure (内部がどう組み立てられているか)、 (3) steering スキルを通じてエージェントに 「こう動け」 と実際にやらせる技術。 Matt はここに 1 つの中心技法を置く (どう舵を取るか)、 (4) pruning (どこまで小さくできるか) を順に点検する。 現地にいない利点として、 このチェックリスト自体を 「writing great skills」 という新しいスキルにまとめてリポジトリに置いた、 と本人が付け加える。 チェックリストを説くスキルを、 スキルとして配布する、 という入れ子構造になっている。
structure の核は、 スキルを 2 つの単位で捉えることだ。 手順を追う steps スキルが辿るステップ・バイ・ステップの手続き と、 その手順を助ける補助情報である reference steps を進めるために必要な補助情報。 テンプレートや用語定義など。 steps だけのスキルも reference だけのスキルもありうる 。 例に挙がる 2PRD スキルは 3 steps (文脈を集める → テストの区分をユーザーと確認する human-in-the-loop チェックポイント → PRD を書く) と 2 reference (テストの区分とは何か、 PRD テンプレート) で構成される。 そのうえで Matt は 「skill.md をできるだけ小さく」 を強く求める。 削った 1 語は毎リクエストで効くトークン節約であり、 監査もしやすくなる。 1 つの分岐でしか使わない reference は、 context pointer ある資源から別のファイルへ 「必要ならこちらを見よ」 と指し示す参照。 model-invoked スキルの説明文もこれの一種で、 エージェントの文脈に置くことも、 置かずに隠すこともできる の先に切り出して skill.md 本体から追い出す — これが分岐の多いスキルを小さく保つ基本手筋になる。
着眼点
trigger — model-invoked と user-invoked は、 どちらもタダではない (03:16 - 07:25)
最初の判断は、 スキルを誰が起動するかだ。 model-invoked skill エージェント自身が起動できるスキル。 説明文が常にエージェントの文脈に入り、 エージェントが 「この説明なら呼ぶべきだ」 と判断して skill.md を読み込む。 説明文が context pointer として働く は説明文が常に文脈に入り、 エージェントが自分で呼ぶか、 ユーザーが呼ぶかを選べる。 一見こちらが柔軟で優れて見える。 だが Matt は、 model-invoked を 1 つ足すたびにエージェントへの 「context load」 が増える、 と釘を刺す。 説明文は毎リクエストでトークンを食い、 エージェントが考える対象を 1 つ増やす。 model-invoked が 100 個あれば、 相談のたびに使わないマニュアルを 100 冊、 机に積み上げてから話し始めるようなものだ。
では全部 user-invoked skill ユーザーが手動で呼ぶスキル。 model invocation を無効化 (disable) すると説明文はユーザーにしか見えず、 エージェントの文脈には載らない。 context load はかからないが、 ユーザー側が使いどころを覚えておく必要がある にすればいいかというと、 今度はユーザー側に 「cognitive load」 がかかる。 頭に入れておくスキルが増えるほど、 操縦者に求められる技量が上がる。 Matt 自身は全面的に user-invoked を好む — 「制御を握りたい、 エージェントへの context load を最小にしたい」 から。 一方で人気スキル集の superpowers は主に model-invoked で 「エージェントに超能力を与える」 設計だ。 model-invoked には不確実性のコストもある。 「文脈ポインタは、 タスクに完璧に合っていてもモデルが辿らないことがある」。 辿るかどうかを確かめるために evals スキルやモデルの挙動を検証する評価。 model-invoked スキルでは 「正しいタイミングで呼ばれているか」 を eval で確認する必要が生じる を回す羽目になる。 結論は歯切れよく、 どちらにも同じ大きさのコストがあり、 簡単に選べる二択ではない、 と本人が認める。
steering — 合言葉 (leading words) がこの講演の一番の持ち帰り (11:54 - 16:47)
Matt が 「この講演で一番持ち帰ってほしい」 と名指しするのが leading words 密度の高い意味を短い語に詰め込んだ 「合言葉」。 スキル本文に置くと、 エージェントが思考トレースや出力でその語を復唱し、 それが振る舞いを変える。 Matt は steering の中心技法として据える だ。 症状はよくある。 スキルにはっきり書いたつもりなのに、 エージェントが言った通りに動かない。 原因は、 意味を凝縮した合言葉を使っていないことにある、 と Matt は診る。 合言葉をスキルに置くと、 エージェントはそれを思考トークンにも出力にも復唱し、 その語が望む振る舞いを表しているなら、 挙動がそちらへ寄る。 コーチが選手に短い掛け声を 1 つ渡すと、 選手が試合中に自分でその言葉を唱えてフォームが直る、 あの働きに近い。
具体例が効く。 エージェントは仕事をまとめて渡されると 「層ごと」 に書く癖がある — データベース層を全部、 次にスキーマを全部、 次に API を全部、 最後にフロントを全部。 人間なら小さく動くものを先に作って早めにフィードバックを取るところを、 やらない。 そこで 「層で切るな」 と説教する代わりに、 vertical slice 機能を横 (層) ではなく縦に薄く切り出し、 端から端まで動く最小の 1 枚を先に作る開発用語。 leading words の実例として、 この 1 語がエージェントの既存知識を呼び起こす という合言葉を 1 つ渡す。 開発の世界でよく知られた語なので、 エージェントの既存知識が呼び起こされる。 うまくいったかどうかは目で確かめられる — 推論トレースに 「これは薄い vertical slice として進める」 と現れれば、 実装計画が良くなる。 「英語は呼べる関数が幅広い API のようなものだ」。 合言葉が効かないなら、 もっと一貫して、 もっと強い候補を探せばいい。
もう 1 つの梃子が 「legwork」 だ。 エージェントは特定のステップで足を使う量が足りないことがある。 典型は plan mode で、 「明確化の質問をする → 計画を作る」 の 2 段のうち、 最終目標が 「計画を作る」 だと見えているせいで、 質問を数個で切り上げて早々に計画へ走る。 Matt の解は、 スキルを分割することだった。 明確化を grill with docs Matt のスキルの 1 つ。 plan mode の 「明確化の質問」 フェーズを独立スキルに切り出したもの。 エージェントに次段の計画作成を見せず、 明確化そのものに足を使わせる という独立スキルに切り出し、 計画作成 (2PRD) を別スキルにする。 エージェントには一度に 1 ステップしか見えない。 未来の目標を隠すことで、 今のステップに使う足の量が増える。 常に分割が要るわけではないが、 特定のステップに一段の作業を上乗せしたい場面では、 これに並ぶ技法はない、 と Matt は言う。
pruning — no-ops と沈殿物を狩り、 スキルを小さく保つ (16:48 - 19:05)
最後は刈り込みで、 失敗モードの早撃ちだ。 巨大なスキルは、 それ自体が別の失敗の症状であることが多い。 第一が single source of truth スキルの各要素が 1 箇所にだけ存在する状態。 同じ reference (PRD テンプレートやテスト区分の説明など) を複数箇所で繰り返さない、 という DRY 原則 の欠如、 つまり重複だ。 PRD テンプレートのような reference を、 あちこちで繰り返さない。 第二が sediment 複数人が同じ markdown に足していく際、 誰も他人の記述を消す勇気がなく、 無関係な記述が溜まっていく現象。 沈殿物のように積もる。 対処は structure の見直しか、 陳腐化した記述の削除 (沈殿物)。 共有ドキュメントに全員が足すが誰も消さない結果、 誰も掃除しない共同の水槽の底にヘドロが溜まるように、 無関係な記述が積もる。 まず structure を見直し、 全分岐に関係する記述か確かめ、 特定分岐のものは正しい分岐へ、 陳腐化したものは消す。
三つ目が no-ops スキルの中で何かをするように見えて、 実際にはエージェントの振る舞いを変えていない記述。 エージェントにスキルを書かせた時に混入しやすい。 「削っても結果が変わるか」 の削除テストで検出する で、 エージェントにスキルを書かせた時に混入しやすい。 たとえば 「長く詳しいコミットメッセージを書け」 という段落を丸ごと消したらどうなるか。 エージェントはたぶん、 消しても十分まともなコミットメッセージを書く。 だとすればその段落は、 配線されていないエレベーターの 「閉」 ボタンと同じで、 押しても何も起きない。 Matt が 「どうやってスキルをそんなに小さく保つのか」 とよく聞かれる答えはここにある — 削除テストを回し、 記述を合言葉へ圧縮し、 無関係な沈殿物を残さない。 巡回の締めくくりとして、 trigger (正しい時に発火しているか、 context load か cognitive load か)、 structure (分岐、 steps と reference、 単一分岐の資材を skill.md の外へ)、 steering (合言葉が推論トレースに出るか、 legwork のために分割すべきか)、 pruning (沈殿物と no-ops の掃除) を一枚に並べて確認する。
動画の構成
- (00:00) 導入 — スキル地獄とは何か、 tutorial hell / framework hell の系譜、 「もう 1 個スキルを足せばいい」 の罪悪感
- (02:12) 4 項チェックリスト (trigger / structure / steering / pruning) の全体像、 「writing great skills」 スキルとして配布
- (03:16) trigger — user-invoked と model-invoked の違い、 context pointer と説明文
- (05:20) model-invoked の context load、 100 スキル = 100 説明文
- (06:10) 自作スキル (user-invoked) と superpowers (model-invoked) の対比、 不確実性のコストと eval の必要
- (07:29) structure — steps と reference の 2 単位、 2PRD スキルの 3 steps + 2 reference
- (09:00) skill.md を最小に、 分岐ごとの reference を context pointer で外出し、 domain-modeling の例
- (11:54) steering — leading words の導入、 「エージェントが言う通りに動かない」 症状
- (12:57) vertical slice の実例、 層ごとに書く癖を合言葉で直す、 推論トレースで検証
- (14:56) legwork — ステップごとの足の量、 plan mode の明確化が足りない問題
- (15:47) grill with docs としての分割、 一度に 1 ステップだけ見せる
- (16:48) pruning — 巨大スキルは症状、 DRY / single source of truth
- (17:44) sediment (沈殿物)、 共有ドキュメントに溜まる無関係な記述
- (18:27) no-ops、 コミットメッセージ段落の削除テスト
- (19:06) 4 項の総まとめ
- (19:55) 「writing great skills」 スキルの入手先、 aihero.dev ニュースレター、 AI コーディング入門コースの予告
関連リソース
- Building Great Agent Skills: The Missing Manual — AI Engineer 公式 (講演動画)
- mattpocock/skills — Matt のスキルリポジトリ (講演の題材)
- writing-great-skills SKILL.md — チェックリストを収めた実物スキル
- AI Hero (aihero.dev) — Matt の教育プラットフォーム / ニュースレター
用語集
- skill hell (スキル地獄)
- 使えるスキルが無数に無料で手に入るのに、 部品同士の噛み合い方が分からず、 良いスキルと悪いスキルを見分けられないまま全部を試そうとして成果が出ない状態。 tutorial hell / framework hell に続く、 開発者が繰り返し落ちる 「出口の見えない循環」 として Matt が命名。 個人だけでなく組織にも起きる。
- trigger (起動)
- スキルがどう呼び出されるか。 チェックリストの 1 項目め。 ユーザーが手動で呼ぶ user-invoked と、 エージェントが説明文を読んで自動で呼ぶ model-invoked の設計判断を指す。
- model-invoked skill
- エージェント自身が起動できるスキル。 説明文が常にエージェントの文脈に入り、 context pointer として skill.md を指す。 柔軟だが、 説明文が毎リクエストでトークンを食う context load と、 モデルが文脈ポインタを辿らない不確実性のコストがかかる。
- user-invoked skill
- ユーザーが手動で呼ぶスキル。 model invocation を無効化すると、 説明文はユーザーにしか見えず、 エージェントの文脈には載らない。 context load はゼロだが、 ユーザー側が使いどころを覚える cognitive load がかかる。 Matt が好む形。
- context pointer
- ある資源から別のファイルへ 「必要ならこちらを見よ」 と指し示す参照。 model-invoked スキルの説明文もこれの一種。 分岐でしか使わない reference をこの先に隠すことで、 skill.md 本体を小さく保てる。
- steps と reference
- スキルを構成する 2 つの単位。 steps は辿る手続き、 reference はそれを助ける補助情報 (テンプレート・用語定義など)。 steps だけのスキルも reference だけのスキルもありうるが、 この 2 単位で分解すると設計が整理される。
- leading words (合言葉)
- 密度の高い意味を短い語に詰め込んだ語。 スキル本文に置くと、 エージェントが思考トレースや出力で復唱し、 それが振る舞いを変える。 「vertical slice」 のように、 開発で既に知られた語を使うとエージェントの既存知識を呼び起こせる。 効いたかどうかは推論トレースに語が現れるかで確認できる。
- legwork (足を使う量)
- あるステップにエージェントが投じる作業量。 最終目標が見えていると、 途中のステップ (明確化の質問など) を早々に切り上げる傾向がある。 スキルを分割して一度に 1 ステップしか見せない (未来の目標を隠す) ことで、 今のステップに使う足の量を増やせる。
- no-ops
- スキルの中で何かをするように見えて、 実際にはエージェントの振る舞いを変えていない記述。 「削っても結果が変わるか」 の削除テストで検出する。 エージェントにスキルを書かせた時に混入しやすい失敗モード。
- sediment (沈殿物)
- 複数人が同じ markdown に書き足すうち、 誰も他人の記述を消せず、 無関係な記述が積もっていく現象。 対処は structure の見直し (全分岐に関係するか、 特定分岐へ移すか、 陳腐化を消すか)。
- single source of truth
- スキルの各要素が 1 箇所にだけ存在する状態。 同じ reference を複数箇所で繰り返さない DRY 原則。 巨大なスキルは、 重複・沈殿物・no-ops といった別の失敗の症状であることが多い。