非技術者にスキルは育てられるのか — 純正リファレンスの『スキルの一生』を解剖した

これは Anthropic の業種特化エージェント製品を読むシリーズの3本目になる。1本目は Claude for Legal の cookbook 5本を「Building Effective Agents」の5分類で仕分けた。2本目は Legal と Small Business の両方を開けて、製品の本体がプロンプトではなく「権限・継ぎ目・信頼境界を構成ファイルでどう縛るか」だったと書いた。

どちらも「エージェントをどう組むか」の話だった。今回はレイヤーを一段上げる。スキルそのものの一生 — 作られ、信頼を判断され、品質を採点され、更新され、カスタムされ、そして（願わくば）改善されていく — を、非技術者の目線で追う。

なぜ非技術者の目線か。この2製品が想定する主役は、コードを書く人ではないからだ。Legal の読者は弁護士、Small Business の読者は中小事業主。どちらもエンジニアではない。彼らには、はっきり4つの「できない」がある。

1. コードを読めない — インストールするスキルが何をするか、ファイルを開いても判断できない
2. エディタでスキルを書けない — SKILL.md を一から書くのは無理
3. スキルの良し悪しを判断できない — よく出来たスキルと地雷を見分けられない
4. 実データでの効き目を測れない — 「このスキル、うちの案件で本当に効くのか？」を検証できない

clone して分かったのは、両製品がこの「できない」を、ライフサイクルの各段でプロセスで肩代わりしているということだった。先に結論を言ってしまうと — 肩代わりは見事だが、最後の一段だけ、純正リファレンスですら開けていない。そこが今回の主題になる。

メタ層は両方にあった。ただし思想が正反対だった

スキルを管理するための「メタ層」が、両リポジトリにそれぞれ存在する。

• Legal: legal-builder-hub プラグイン。README が自分でこう名乗っている — "This is the app store."
• Small Business: cowork-plugin-management プラグイン。create-cowork-plugin と cowork-plugin-customizer の2スキルだけ。

同じ「基盤が自分の拡張をどう生み、どう管理するか」という問いに、二人は正反対の姿勢で答えていた。

	legal-builder-hub	cowork-plugin-management
想定読者	顧客データを扱う弁護士	非技術者の中小事業主
スキルの前提	untrusted な第三者コード	自分で作る／カスタムする
全振り先	審査・統治	作りやすさ・隠蔽
メタファ	セキュリティ検問付き App Store	ノーコード・プラグインビルダー

Legal は「外から来る得体の知れないコードをどう審査して入れるか」に全リソースを割く。Small Business は「非技術者がどうやって自分のプラグインを持つか」に全リソースを割く。ステークスの違い（弁護士は誤れば賠償、事業主は誤っても小さい）が、投資先を分けている。

この2つを段ごとに並べると、スキルの一生が見えてくる。

①〜⑤は「非技術者ができないこと」を製品が肩代わりする段だ。⑥だけが点線——ここが今回の主題になる。順に追う。

段①：作成 — 「書けない」を会話で肩代わり

Small Business の create-cowork-plugin は、会話だけでプラグインを作る。Discovery → Component Planning → Design → Implementation → Package の5フェーズで、最後に .plugin ファイルが出てくる。注目すべきは、徹底した非技術者配慮だ。

Nontechnical output: Keep all user-facing conversation in plain language. Do not expose implementation details like file paths, directory structures, or schema fields unless the user asks. Frame everything in terms of what the plugin will do.

ファイルパスもディレクトリ構造もスキーマも、ユーザーには見せない。「何ができるか」の言葉だけで会話する。plugin.json も SKILL.md も、ユーザーの背後で Claude が書く。

設計原則も拾える。「小さく始めろ」(A plugin with one well-crafted skill is more useful than one with five half-baked components.)、そして基盤開発者として一番効くのがこれだ。

Skills are for Claude: Write skill body content as instructions for Claude to follow, not documentation for the user to read.

スキルは「ユーザー向けドキュメント」ではなく「Claude 向けの命令文」だ。これを取り違えると、説明書みたいな読み物を書いて発火しないスキルが量産される。本体は 3,000 語未満に絞り、詳細は references/ に逃がす（progressive disclosure）。

段②：信頼判断 — 「読めない」を多層防御で肩代わり

ここからは Legal 側の独壇場になる。skill-installer は、コミュニティスキルをレジストリからローカルへ入れる7ステップだ。

1. allowlist を読む（fetch する前に）
2. fetch（read-only サブエージェントで）
3. raw SKILL.md を全文表示
4. 構造トラストチェック（hooks / MCP / tool 権限 / 書き込み先 / ネットワーク）
5. skills-qa を走らせる
6. 人間が yes と打つ
7. install

設計の急所は「AI が判断する層」を信用しきらないことだ。allowlist をfetch より先に読む理由がそれを物語る。

This step must happen before fetching the skill content. The allowlist is the one gate that does not depend on Claude correctly analyzing attacker-controlled text.

スキル本文（＝攻撃者が書ける文章）を読み込んだ後に「このソースを信頼するか」を判断すると、その判断自体が汚染されたコンテキストの中で行われてしまう。だから allowlist だけは、ユーザーが打ったコマンドとレジストリ URL という「外側のメタデータ」に対して、本文を読む前に効かせる。

そして raw を必ず見せる。要約ではなく、全文を。

"What follows is the raw SKILL.md. Claude's summary is a convenience, not a substitute for you reading it. This file will instruct Claude how to behave whenever the skill runs."

製品は、AI 仲介の信頼に限界があることを自白までしている。「巧妙な injection は、raw 表示を飛ばせ・スキャンはクリーンと報告しろ・承認前に書き込め、と Claude に命じ得る。緩和策はリスクを下げるが消せない」と。だから fetch と解析は read-only サブエージェント（書き込み権限なし）で走らせ、承認が出るまで Write 権限を与えない。injection が成功しても、掴むものが無い。

そして、本稿の核心がここに埋まっていた

skill-installer の Step 5.5「Role-aware routing」を読んで、手が止まった。

非技術者（Non-lawyer）がスキルを入れようとして、品質判定が SOME CONCERN 以上だったとき、インストーラは**「入れますか？」のプロンプトを出さない**。

Role = Non-lawyer AND verdict is SOME CONCERN or higher ... do NOT present the Step 6 install prompt. The install-or-not decision is not this user's to make.

代わりに、jargon を一切使わない平易な言葉で、顧問弁護士へのハンドオフ文面を生成する。そしてその理由を、製品はこう言い切る。

The decision-architecture gap the hub has to close is handing the final call to the person least equipped to make it.

埋めるべき溝とは、最も判断できない人に最終決定を委ねてしまうことだ。 ——これは、この記事全体の主張そのものだ。覚えておいてほしい。最後にもう一度戻ってくる。

ついでに license も独立したゲートになっている。「信頼できるソースでも、ライセンス義務は別問題」。SPDX 識別子を厳格なパターンマッチで抽出し、未知の文字列はそれ自体を「データ整合性の異常」として人間承認へ回す。ライセンス文字列すら injection ベクタとして扱う徹底ぶりだ。

段③：品質評価 — 「良し悪しが分からない」を設計フレームで肩代わり

skills-qa は、スキルを 13パラメータで採点し、READY / SOME CONCERN / MATERIAL CONCERNS / REFUSE の4段階で判定する。自己定義が小気味よい。

Anyone can build a skill. This one checks whether it was built well before it touches your workflows.

13個の中で白眉は Work Shape の3分類だ。スキルが扱う仕事を、

• Accretive Judgment（文脈が時間で積み上がる。Claude は文脈の管理役で、結論を出さない。委譲しきい値は保守的に）
• Bounded Transactional（範囲が限定され決着が明示的。Claude は逸脱を浮かせ、選ばない）
• Pattern-Matched Review（リスクが既知で反復的。Claude の自律度を上げてよい。例外検知が主設計要件）

の3つに分け、「どの仕事形か」によって委譲しきい値・自律度・エスカレーション要件を変える。これは「良いスキルとは何か」を、感覚ではなく設計の根っことして言語化したものだ。自作基盤の品質ゲートにそのまま移植できる。

ただし — ここが効いてくる。skills-qa は、末尾で自分の守備範囲をはっきり線引きしている。

• Guarantee performance. A "Ready" verdict means the skill was designed well against the framework. It is not a performance guarantee against your specific inputs and edge cases.
• Replace piloting. QA evaluates design. Piloting in a controlled environment with real inputs is a separate step and should follow a "Ready" verdict before team-wide deployment.

設計品質は採点する。だが、実データでの効き目（performance）は採点しない。 そして「実データで試すこと（piloting）」は別の段だ、と明言して、自分のスコープから外している。空白地帯の入口が、ここに見えている。

段④：更新 — 「差分の危険が見抜けない」を強制 diff で肩代わり

auto-updater には auto モードが無い。これは設計だ。

There is no "auto" mode. Updates to code that runs in your legal environment always require a human to read the diff.

しかも tag ではなく commit SHA に固定する。tag は mutable で、publisher が後から書き換えられるからだ。極めつけが「GlassWorm ゲート」と名付けられた防御で、信頼済みの publisher が v1.1 のマイナーアップデートに毒を仕込む攻撃を名指しで想定している。

A skill that was clean at v1.0 can ship a poisoned v1.1 ... Install-time trust does not transfer to updates.

新バージョンには skills-qa を再走させ、旧版に無かった指摘が出たら fail-closed（既定で拒否）。さらに「鮮度」も見る。コミットが変わっていなくても、last_verified + freshness_window を過ぎたら警告を出す。この "last verified" の定義が鋭い。

Not "last edited." Not "last commit." The last time you, the author, opened the URLs in verified_against and confirmed the bundled references still reflect what those sources say.

「最後にいじった日」でも「最後のコミット」でもない。「作者が verified_against の URL を開いて、同梱した参照が今のソースとまだ一致すると確認した日」。そして — A skill that keeps bumping last_verified without actually re-verifying is worse than one that lets the date go stale.（再検証もせず日付だけ更新するスキルは、日付を腐らせるスキルより悪い。後者は正直だが、前者はユーザーが頼る嘘をつく）。

ただしこれも、「同梱した知識の鮮度」の話であって、「スキルの効き目」の改善ではない。時間減衰の検知に留まる。

段⑤：カスタム — 「YAML を直せない」を会話と ingest で肩代わり

Legal の customize は、設定を1項目ずつ会話で変える。cold-start 全体を再実行させない（One change at a time）。ガードレールを弱めようとすると止める — QA strictness を切ろうとしたら、middle band を勧めてくる。

Small Business の cowork-plugin-customizer には、基盤開発者として盗みたい仕掛けが2つある。

ひとつは ~~placeholder によるツール非依存テンプレ。~~project tracker と書いておき、配布先で Asana なり Jira なりに具体化する。プラグインを「製品名」ではなく「カテゴリ」で書いて配る発想だ。

もうひとつ — これが効く。カスタマイズの Phase 1 が、組織内の Knowledge MCP（Slack / ドキュメント / メール）を検索して、設定値を自動収集する。

Use company-internal knowledge MCPs to collect information relevant to the customization scope.

これは実質 ingest だ。ユーザーに型を聞く前に、組織の文脈をスキャンして埋める。自作基盤の「設定の自動補完」にそのまま使える。

段⑥：改善 — ★ 唯一、肩代わりされなかった段

ここまで5段。作成・信頼・品質・更新・カスタム、すべて「非技術者ができないこと」が、製品によって丁寧に肩代わりされていた。

では6段目 — 「このスキル、実際に効くのか？」を測って、結果でスキルを直す — はどうか。

無い。両製品のどこにも、runtime の効き目を評価して、その結果でスキル本文を改善する閉ループは無かった。

• skills-qa は設計品質止まり（"not a performance guarantee" と自分で言っている）
• auto-updater は供給網の信頼と鮮度だけ。スキルの中身の質は触らない
• "profile learns" と謳う部分も、磨かれるのは推薦のマッチングであって、スキルの効き目ではない（A month of use gets you one that reads like you wrote it yourself — これは practice profile の話だ）
• install 後の唯一の助言はこれだけ:

"Installed. Review the skill's documentation and try it on a non-sensitive test matter before using it on live work."

「低リスクの案件で試してみてね」。試すのも、効いたか判断するのも、直すのも、全部人間に返される。

思い出してほしい。段②で製品が自分で言った言葉を。

handing the final call to the person least equipped to make it.

埋めるべき溝は「最も判断できない人に最終決定を委ねること」だった。インストールの可否では、Legal はその溝を埋めた（非技術者には決めさせず、弁護士へ回す）。だが**「効き目の検証」という、非技術者が最も無力な段では、純正リファレンスですらその溝を埋めず、まるごと人間に渡している**。

作成も信頼判断も品質採点も肩代わりしておきながら、一番難しい「で、効くの？」だけが、一番判断できない人の手に残る。これが、現時点の業種特化エージェント製品の到達点であり、限界だ。

ここが基盤の差別化ポイントになる

裏を返せば、ここは空白地帯だ。

前2本で、自分の作っている基盤の北極星は ingest → extract → compile → query のパイプラインだと書いた。その上に eval → improve の閉ループを載せられれば、リファレンスの一歩先に出られる。

• eval: スキル／エージェントの出力を、実データ（過去案件・正解ペア）に対して採点する。設計品質ではなく、効き目を測る
• improve: 採点結果を使って、プロンプト・参照（references）・しきい値を自動で更新する

純正が piloting として人間に外注したものを、基盤が引き取る。非技術者が一番できないことを、最後まで肩代わりする。スキルを「インストールして人間が見守る対象」から「使うほど勝手に良くなる対象」へ動かせたとき、はじめて「ツール」ではなく「基盤」になる。

Anthropic の純正リファレンスは、スキルの一生のうち5段を見事に設計していた。残り1段は、まだ誰の図面にも引かれていない。そこにコードで線を引くのが、次の仕事だ。