Claude Skillsはすごい、MCPよりも大きな革新かもしれない

 (simonwillison.net)
52 ポイント 投稿者 GN⁺ 2025-10-18 | 12件のコメント | WhatsAppで共有
  • Anthropicが発表した Claude Skills は、モデルが特定の作業を行う際に必要な指示、スクリプト、リソースをフォルダ形式で提供する新しいパターンで、作業ごとの専門性を動的にロードする方式
  • SkillsはMarkdownファイルとオプションのスクリプトで構成され、セッション開始時には各スキルのメタデータだけを 数十トークン で読み込み、実際に必要なときだけ全文を読み込むため、トークン効率 が非常に高い
  • Claude Codeを通じて、Skillsは単なるコーディングツールを超えて 汎用自動化エージェント へと拡張され、ファイルシステムとコマンド実行環境さえあれば多様な作業の自動化が可能
  • MCPとは異なり、Skillsはプロトコルではなく MarkdownとYAMLベースの単純な構造 で、他のモデルやツールでもすぐに活用でき、共有と普及が容易
  • このシンプルさと効率性により、Skillsは MCPよりはるかに速いペースでエコシステムが拡大 すると予想され、データジャーナリズムからブランドガイドラインまで多様な分野で専門化されたエージェントを構築可能（MCPのトークン消費問題と複雑な仕様を避けられる）

Skillsの概念と構造

  • Anthropicが2025年10月16日に Claude Skills を正式発表
    • モデルが特定の作業（例: Excel作業、組織のブランドガイドライン順守）を行う際に必要な指示、スクリプト、リソースを収めた フォルダ単位の能力拡張システム
    • Claudeは作業と関連があるときにだけそのスキルへアクセスし、専門化された作業遂行能力を高める
  • anthropic/skills のGitHubリポジトリで公式スキル例を提供
  • Skillsは概念的にきわめてシンプル
    • 中核は、モデルに作業のやり方を伝える Markdownファイル
    • オプションで追加ドキュメントや事前作成済みスクリプトを含め、作業完了を支援
  • 9月に発表されたClaudeの文書生成機能は、実際には Skillsで完全に実装 されていた

トークン効率性: Skillsの中核的な利点

  • セッション開始時、Claudeは利用可能なすべてのスキルファイルをスキャンし、各スキルの frontmatter YAMLの短い説明だけ を読む
  • 各スキルが占める初期トークンは 数十個にすぎず、きわめて効率的
  • ユーザーがスキルが役立ちそうな作業を依頼したときにだけ、全文の詳細が読み込まれる
  • これは単にディスクにファイルを保存するだけではなく、機能として成立させる中核的な差別化要因 でもある

Slack GIF生成スキルの実践例

  • slack-gif-creatorスキル のメタデータ説明
    • Slack向けに最適化されたアニメーションGIF生成ツールキット
    • サイズ制約バリデーターと、組み合わせ可能なアニメーション基本要素を含む
    • 「XがYをするSlack用GIFを作って」のような依頼に適用
  • 実際のテスト過程
    • ClaudeモバイルWebアプリでSonnet 4.5モデルにslack-gif-creatorスキルを有効化
    • Make me a gif for slack about how Skills are way cooler than MCPs というプロンプトを入力
    • Claudeが自動でGIFを生成（品質には改善の余地があるが、スキルは反復的に改良しやすい）
  • 生成されたPythonスクリプトの注目点
    • スキルディレクトリをPythonパスに追加: sys.path.insert(0, '/mnt/skills/examples/slack-gif-creator')
    • スキルの core/ ディレクトリ内にある GIFBuilder クラスを活用
    • ファイルを /mnt/user-data/outputs/ に保存
    • Slackのサイズ制限（2MB）を検証する関数 check_slack_size() を使って仕様順守を確認
    • サイズを超えた場合、モデルが自動でより小さいファイルの再生成を試みられる

Skillsの環境依存性

  • Skillsの仕組みは、モデルが次のものにアクセスできてはじめて 完全に機能する
    • ファイルシステム
    • ファイルシステム探索ツール
    • 環境内でコマンドを実行する能力
  • これはLLMツーリングにおける一般的なパターン
    • ChatGPT Code Interpreterが 2023年初頭 の最初の大規模事例
    • その後、Cursor、Claude Code、Codex CLI、Gemini CLIのようなコーディングエージェントツールによってローカルマシンへまで拡大
  • この要件は、MCPやChatGPT Pluginsなど過去のLLM能力拡張の試みとの 最大の違い でもある
  • 重要な依存関係ではあるが、解放される新しい能力の規模 は驚くほど大きい
  • 安全性の問題は依然として重要
    • 安全な コーディング環境の提供が必要
    • プロンプトインジェクションのような攻撃による被害を許容可能な水準に抑えられる サンドボックス 環境の構築方法が必要

Claude Code: 汎用エージェントへの進化

  • 2025年1月、筆者は「エージェント」は失敗すると予想していたが、完全に外れた
    • 2025年は実際に「エージェント」の年となった（定義はいろいろあるが、「tools in a loop」と定義）
  • Claude Codeという名前は適切ではない
    • 純粋なコーディングツールではなく、汎用コンピュータ自動化ツール である
    • コンピュータにコマンドを入力して達成できる あらゆる作業 を自動化できる
    • 汎用エージェント（general agent） と説明するのがもっとも適切
  • Skillsはこの可能性をさらに明確かつ明示的にする
  • 応用可能性は目が回るほど広い
    • データジャーナリズムの例: 次の作業を扱うスキルフォルダを構成できる
      • 米国国勢調査データの出典と構造の理解
      • さまざまな形式のデータをPythonライブラリでSQLite/DuckDBに読み込む
      • S3上のParquetファイルやDatasette Cloudテーブルとしてデータをオンライン公開
      • 新しいデータセットから興味深いストーリーを見つける方法（経験豊富なデータ記者の指針）
      • D3を使った、整っていて読みやすいデータ可視化の構築
    • 結果: MarkdownファイルといくつかのPythonスクリプト例だけで、米国国勢調査データからストーリーを見つけて公開する 「データジャーナリズムエージェント」 を構築できる

Skills vs MCP 比較

  • Model Context Protocol（MCP） は2024年11月の公開以来、非常に大きな注目を集めた
    • あらゆる企業が「AI戦略」を必要としており、MCP実装の発表はその需要を満たす手軽な方法だった
  • MCPの限界が徐々に明らかになってきた
    • もっとも重要な問題はトークン使用量
    • GitHubの公式MCPは、それ単体で数万コンテキストトークンを消費する
    • さらにいくつか追加すると、LLMが実際に有用な作業を行う余地がほとんど残らない
  • コーディングエージェントを本格的に扱い始めて以降、筆者のMCPへの関心は低下した
    • MCPで達成できるほぼすべてのことは CLIツールで置き換え可能
    • LLMは cli-tool --help の呼び出し方を知っているため、使い方の説明に大量のトークンを費やす必要がない
    • モデルが必要なときに自分で把握できる
  • Skillsはまったく同じ利点を持ち、さらに新しいCLIツールを実装する必要すらない
    • 作業のやり方を説明するMarkdownファイルを置くだけ
    • 安定性や効率性の向上に役立つ場合にのみ追加スクリプトを含めればよい

Skillsエコシステムの爆発的成長予測

  • Skillsのもっとも興味深い点の1つは 共有のしやすさ
    • 多くのスキルは単一ファイルで実装されると予想される
    • より高度なスキルは、いくつかのファイルを含むフォルダ形式になる
  • Anthropic提供資料
  • 筆者も Datasetteプラグインのビルド方法 のようなスキル案を構想中
  • 他のモデルでも利用可能: これもSkills設計の利点
    • スキルフォルダをCodex CLIやGemini CLIに接続し、「pdf/SKILL.mdを読んで、このプロジェクトを説明するPDFを作って」と指示すれば動作する
    • そのツールやモデルにスキルシステムへの組み込み知識がなくても可能
  • 予想: 今年のMCPラッシュがかすんで見えるほどの Skillsのカンブリア爆発 が起きる

シンプルさこそが中核的な強み

  • 一部では、Skillsは単純すぎて機能と呼べないという反発もある
    • 多くの人が、Markdownファイルに追加指示を書いてコーディングエージェントに読ませるトリックをすでに試している
    • AGENTS.md は確立されたパターンであり、「PDF生成前にPDF.mdを読め」という指示も含められる
  • Skills設計の中核にあるシンプルさこそ、筆者が興奮している理由
  • MCPは完全な プロトコル仕様 を持つ
    • ホスト、クライアント、サーバー、リソース、プロンプト、ツール、サンプリング、ルート、elicitation
    • 3つの転送方式（stdio、streamable HTTP、もともとはSSE）も含む
  • SkillsはMarkdown + 少量のYAMLメタデータ + オプションの実行スクリプト
    • LLMの精神にずっと近い: テキストを渡し、あとはモデルに処理させる
  • Skillsは難しい部分を LLMハーネスと関連するコンピュータ環境にアウトソース している
    • 過去数年間にLLMのツール実行能力について学んだすべてを踏まえると、非常に賢明な戦略といえる

関連記事

12件のコメント

 
shakespeares 2025-10-19

コーディングで Claude Code を使うときにも応用できる部分なのかなと思います。
今も Claude.md にガイドを入れておいて、詳細ガイドはそれぞれ分けて進めています。
 
labeldock 2025-10-19

少ないトークンで多くの作業を行うには、プロンプト最適化よりもマルチエージェントや要約を活用する方法で、もっと簡単に解決できそうに思います。問題点には同感ですが、解決方法には限界があるように感じます。
 
savvykang 2025-10-18

Skillsもトークンを使うのではありませんか？ もしそうなら、トークン使用量の問題がまた発生しそうですが、そのときどう対応するのかよく分かりませんね
 
dnjstmxhs 2025-10-19

コンテキストにはSKILLS.md全体ではなく、ひとまず冒頭の以下のような名前と説明の部分だけが常に入るように見えました。

name: skill-creator
description: 効果的なskillsを作成するためのガイド。このskillは、専門知識、ワークフロー、またはツール統合によってClaudeの機能を拡張する新しいskillを作成したい（または既存のskillを更新したい）場合に使用する必要があります。
license: Complete terms in LICENSE.txt
 
ds2ilz 2025-10-18

Claude Codeで作業していると、指示や規則をコンテキストに繰り返し食わせることになって、結局はトークン使用量とコンテキストの間で悩むことになるんですよね。そこで思いついたのが、フォルダを作って詳細はそこに機能別のmdとして詳しく書き込み、claude.mdには何をするには何を見ればいいかというポインタだけを大量に入れておく方式だったのですが、かなり安くうまく動きました。skillsは結局こういうものをまとめたものなので、かなり使い勝手がよさそうですね
 
laeyoung 2025-10-19

発表どおりにSkills Marketplaceも出てくれば、必要なskillだけ受け取って必要なときにenableしておけるので、それなりに良さそうだと思いました
 
shakespeares 2025-10-19

おお、重要な説明ありがとうございます。
 
2025-10-18
[このコメントは非表示になっています。]
 
dnjstmxhs 2025-10-19

コンテキスト処理とClaude Skillsにはどんな関連があるのでしょうか？ 私はすでに、以前からあったClaude Codeのカスタムコマンドと何が違うのだろう？ と思っていたのですが、ドキュメントを読んでいくうちに、最大の違いはやはり1つのスキルの中にPythonやJavaScriptのようなスクリプトコードを含めて実行できる点だと感じました
 
2025-10-18
[このコメントは非表示になっています。]
 
GN⁺ 2025-10-18
Hacker News の意見

  • 私には Claude Skills は、RAG をユーザー体験の面で不必要に難しくしている証拠に見える。技術的に複雑なのではなく、UX が問題だ。この部分さえうまく解決できれば、Claude Skills 自体が不要になる気がする。Claude Skills が MCP より優れている点は、作るのが簡単なことだ。ただ書くだけで作れるので、誰でも使える。ただし、環境への依存が大きい。例えば、動作に必要な特定のツールがあるとき、それを自動化するためのサンドボックス設定はどうするのか？ しかも、正しいバージョンかどうかすら確信しにくい

  • うちの会社でも社内で似たようなことを試している。うちの monorepo のコンテキストファイルが大きくなりすぎたので、作業ごとに段階的にロードされる fragment ツリーを構築した。こうしたコンテキスト文書は既存の開発者向け文書と非常によく似て見えるが、実際にははるかに役に立ち、タスク志向だ。以前はなぜこういう文書を作れなかったのか不思議に思う。

    1. フィードバックループが長すぎた。文書を書いても、それが効果的かどうか一生わからないこともあるし、わかったとしても数年後かもしれない。変更しても A/B テストのようなことは不可能だった。今は簡単にコンテキスト Markdown を書いて Claude に試させ、すぐに改善できる
    2. ツールによって文書作成そのものも簡単になった。良い文書を作るのは昔から常に難しく、例やリンク、有用な補足情報を入れるには膨大な時間がかかっていたが、今はツールのおかげでコストが下がった
    3. 開発者の中には利己的な人も多い。他人のために書く文書にはなかなかやる気が出ないが、AI をもっと上手く使えるようにする文書なら自発的な動機が生まれる ほかに何か理論があるのか気になる

    • これは実質的に principal-agent 問題に marshmallow test 的な性質が混ざったものだ。開発者が AI ではなく他人のために文書を書く場合、その相手が誰なのか、何を必要としているのか、そもそもそれを見るのかすらわからない。もちろん後で自分の役にも立つかもしれないが、それを理解したり、そのための時間や規律を持つのは難しい。しかし AI が文書を活用して自分を直接助けてくれる状況なら、必要な情報を記録する非常に強い即時的な動機が生まれる。さらにフィードバックループも短くなる。ちなみに、LLM の特性上コードコメントは消されやすいので、最近は文書をより多く残し、コメントは大幅に減った

    • 新規開発者は文書がひどくても、自分が間抜けに見えるのを嫌ってあまり不満を言わない。書いた本人はすでに頭の中にモデルがあるので問題を感じにくく、文書をきちんと書くことは自分の仕事を危うくする行為でもあった。だが、間抜けなロボットにひどい文書を渡して、それがうまくいかなければ、自分を責めるしかない。結局 #2 + #3 だと思う。大きな変化があるとすれば、「代替可能性」がネガティブからポジティブに変わったことだ（安価なエージェントに自分の席を奪われる前に、自分で自分をエージェントに置き換える）

    • 技術的負債が存在する理由と似ている。ビジネス上の圧力、悪い設計、リソース不足。コードを変えるたびに良い文書を維持し続けるのは、以前は本当にコストが高かった

  • フォルダの中に複数の skills があると想像してほしいと言われたとき、米国国勢調査データの場所や構造の解釈方法のようなタスクをカバーする状況が思い浮かぶ。この話を聞いた瞬間、Wolfram Alpha を初めて使ったときのことを思い出した。一般的な検索エンジンとは違い、本当に構造化されたツールで問題を解くことに圧倒された。今もう一度使ってみてもやはりすごい: Wolfram Alpha で米国人口をクエリする。私の頭の中の Skills モデルは、Wolfram Alpha にカスタム拡張を追加したものに近い

    • あなたが貼ったリンクをクリックしてみたら、Wolfram Alpha でクエリが what%27s the total population of the United States%3F として開いた。結果が面白くて、6.1% mod 3 °F (2015-2019 American Community Survey 5-year estimates) と出てくる。どうやってこれを計算したのか気になる

    • 正直、昔の Wolfram Alpha は本当に狂気じみた成果だった。どうやって当時 AI なしで複雑な数学の問題まで扱うシステムを実装したのか、今でも不思議だ

  • Skills と既存ツールの違いが少しわかりにくい。多くの skills は単なるツールとも言えるし、あるいは複数ツールの束に説明を足したもののようにも感じる。ところが、ツール定義と skill 定義は別の場所にあるのではないか？ 両者の dependency をどう表現するのか気になる。skills が「コマンドライン利用可、python、tool A、tool B が必要」と明記していたら、skill のロード時にそうしたツール群も一緒に有効化されるという意味なのか？

  • 実際に注目すべき点は、みんなが MCP に過剰にのめり込み、経路依存的に行動していたことだ。本当に面白いのは、実は単なる「tool call」そのものだ。tool call は本当に便利で面白い。MCP はそのための数ある手段の一つにすぎない。しかも、それほど優れたやり方でもない

    • MCP がものすごく広まったのはタイミングがすべてだったと思う。MCP 以前にもツール呼び出しは存在していたが、モデルはそれをうまく扱えなかった。MCP の登場時期が、ちょうどモデルがツール呼び出しを得意にし始めた時期と重なった。だから結局、LLM が他のシステムとやり取りする目的でツールを呼べるという事実を人々が知ったことこそが、MCP ブームの本質だ

    • MCP サーバーは実質的に tool call を登録するレジストリだ。では通常の tool call と比べて何が悪いのか？

    • MCP に意味があるのは、LLM に oauth の概念を教える点だ。だからサーバーベースのツール呼び出しが可能になった。以前は使う CLI ごとに別々にインストールし、その中で認証も個別に処理する必要があった。tool calling が LLM 最大の強みであることは確かだが、「ツール認証を気にする必要がある」というメッセージが明確になったのもかなり大きな価値だと思う

    • ちなみに、MCP も Anthropic が革新した機能であることは伝えておく

    • Skills を抜きにしても、MCP より良い方法があるなら何なのか気になる

  • MCP の影響力はターミナルを超えてはるかに広い。ChatGPT、Claude Web、n8n、LibreChat でも使えるし、認証、リソース、さらには UI（apps-sdk など）まで考慮されている。コーディングワークフローや CLI ベースのエージェント（Claude Code など）中心なら CLI ツールにも非常に大きな価値があるが、CRM、営業、サポート、運用、財務のような領域では MCP ベースのツールの方が適した形だ。Skills と MCP は競合関係ではなく、相互補完的な目的を持つ。特に Skills の Python コードが interpreter から直接 MCP を呼べるときこそ本当の飛躍だ（うちでも試したが非常にうまくいった）

    • MCP がターミナルベースのツールに比べて持つ大きな利点の一つは、完全に分離された Linux 環境のようなサンドボックスなしでも動かせることだ。そして、はるかに単純なモデルでも使える。ノート PC や、場合によってはスマホで動くモデルでも、MCP を 2〜3 個くらいなら十分扱える。正直、そういうモデルにファイル読み込みや curl まで信頼性高くやらせるのは無理がある

    • LLM を外部ソフトウェアや物理世界と統合するのは、最近本当にすごく魅力的に感じる。しかもそのすべてが自然言語で可能だ。さらに LLM は MCP サーバーのコードまで生成できるので、まったく新しい機能を簡単に作り出せる

  • 正直、MCP は過大評価されていて、限界も明確だと思う。現状の MCP サーバーの 95% は役に立たず、単純な tool call で十分置き換えられる

    • 当然だが、よくできた MCP サーバーは本当に素晴らしい。一方で、ひどい MCP サーバーはむしろさらに深刻な問題を生む。たいてい、すべてのプロダクトチームが「MCP が熱いから」という理由だけで、必ず MCP サーバーを作らなければならない圧力を受ける。顧客側にも AI 活用の目標が無条件にあるため、こうしたものを求めてくる。だが実際には何が欲しいのかわかっておらず、ただ「AI が入っている」と言えればいい。だからプロダクトチームも、AI 導入に明確な効果がなくても、MCP のおかげで素早く「うちは AI プロダクトです」と宣伝できる。AI の本質とはあまり関係のない現象だ

    • MCP はサーバー提供者を信頼しなければ使えない。実質的にサーバーの誠実さに依存している。実際、Uber のような会社は、あらゆる prompt engineering を使って、LLM が自社サービスを最良の選択肢だと思うよう絶えず誘導するはずだ。結局、MCP publisher と consumer のあいだではインセンティブが完全にずれている

    • 結局 tool call が核心だという点には同意する。ただ、MCP には CLI に対して少なくとも 2 つの利点がある。1 つは、tool call を使う LLM が構造化出力を要求しつつ複雑な相互作用を実装する際、MCP の方が CLI より簡単だということ。もう 1 つは、tool call 間の state を MCP サーバーでは自然に維持できることだ。最初は自分も hype に安易に乗せられたのではないかと思ったが、最近 MCP を学ぶために作った小さなデモ（https://github.com/cournape/text2synth）は CLI で作るより簡単で、こういう例が MCP の面白い可能性をよく示していると思う

    • MCP サーバーはハッカーにかなり人気がある感じだ。設定が甘く、雑にデプロイされたインスタンスが多すぎる。企業が既存のあらゆるデプロイ防御線を取り払ってしまった状態だ

    • うちのフロントエンドチームは figma MCP からものすごい価値を引き出している。3 週間かかる仕事を 1 日で終わらせられた

  • 私も Markdown ファイルをいくつか使って skills に匹敵するものを作った。セッションごとに 1 回くらいエージェントに skill を思い出させれば十分だ。Claude がこれをやっているからといって、何が特別なのかよくわからない

    • ある種のパターンに名前を付けること自体が重要な部分だ。すでに多くの人が自然に発見して使っていた有用なパターンだが、名前が付いたことで、より高いレベルの議論が可能になった。Anthropic は特に、このパターンがコーディングエージェントの慢性的な問題だった「context 汚染」の解決に役立つことも見抜いていた。以前の AGENTS.md や MCP は文脈に多すぎる情報が入り込み、非実用的だったが、skills パターンははるかに効率的だ

    • すでに解決されていた問題を公式に構造化し、自動化を少し足したような感じだ。以前使っていた MCP の中には、単に凝った文書検索機能だったものが多く、こういう skills がそれを置き換えてくれることを期待している

    • 私も同じ疑問がある。Aider や CC でこれを 1 年以上使ってきた

  • これは少し否定的かもしれないが、同じように感じている人がいるか知りたい。こうしたサービスを平均的なユーザーに自分で設定させようとしたら、彼らは「正気か？」と思うのが当然だ。大半の人は、ただログインして、何かを頼めばシステムが残りを勝手に処理してくれることを望んでいる。MCP、Apps、Skills、Gems などはすべて、問題設定を間違えている。これは、YouTube で 6 か月ごとに「新しいプログラミング言語やフレームワークが最高だ」と言いながら todo アプリを作り、同じ動画を最大 6 回も繰り返すチャンネルに似ている。本当に反復的で表面的な改善しかなく、根本的な問題は解けていない。技術というジャンルのどこかで何かが間違っていて、資金が集まるとこういう発表ばかりが量産され、次のリリースを出して昇進や転職をするだけで、本質的な価値は残らないように思える

    • 根本問題が解決されていないという主張について言えば、最近はソリューションがまったく新しい問題までパッケージにして持ち込んでくる。箱を開けると問題とソリューションが同時に飛び出して、互いを追いかけて逃げ回る。そして自分が技術的により進化した人間になった気分になる

    • MCP、Apps、Skills、Gems などがすべて間違った問題を考えているという話に対して、私の悲観的な見方では、私たちは AI のためにより多くの文書と API を作っているが、実際には人間向けの文書として作っても結果は似たようなものだったはずだ。私の時間の半分は、文書のない複雑なシステムのデバッグに引きずり回されていた

    • 「根本問題」とは何で、2023 年に ChatGPT が大衆化する以前は、こうした「根本問題」を解決するサイクルはどれくらいだったのか気になる

    • 「todo アプリを同じ内容で 6 回作って忘れる」という例について言えば、これが何の問題なのかよくわからない。技術はもともと漸進的かつ反復的に進歩するものだ。誰かは明日また最高のフロントエンドフレームワークだという動画を上げるだろうし、以前は Nextjs、その前は React、Angular、JQuery、PHP、HTML でも同じことをしていた。もし AI に資金が集中していなければ、いまだに GPT-3 や Claude 2 で止まっていたはずだ。ツール面で粗悪なものが出ることはあっても（私は Skills はかなり良いと思っている）、それを見て業界全体が腐っているとは言えないと思う

    • まあ、まだすべてが始まったばかりで、本当に何がうまく機能するのか誰にもわからない。表面的な試みに見えるが、実際には最先端そのものだ

  • これは完全に別の概念だ。MCP は外部サービス接続や oauth のような認証処理まで含む。Skills は実質的に CLI ツール + プロンプトの組み合わせだ。活用領域が違うので簡単には比較できない。ちなみに、MCP 登場以前にうちでも Skillset というシステムを作って使っていたが、今振り返ると MCP と Skills の長所を混ぜた最高のハイブリッドだったと思う
 
github88 2025-10-18

大げさなのは本当だ