Agent Skills - ワークフローに合わせてAIをカスタマイズする

 (anthropic.com)
17 ポイント 投稿者 GN⁺ 2025-10-17 | 4件のコメント | WhatsAppで共有
  • AnthropicのAgent Skillsは、ユーザーの業務フローに合わせてAIの専門性を拡張できるようにする
  • Skillは命令、スクリプト、リソースを含むフォルダ単位の構成要素で、Claudeが作業時に必要な瞬間にだけ読み込む
  • Excel・PowerPointの生成、ブランドガイド順守など、特定業務領域に特化した実行能力を付与する
  • ユーザーや開発者が直接Skillを作成し、Claudeアプリ、Claude Code、API全体で活用可能
  • 企業単位での配布と管理機能にも対応予定で、カスタムAIワークフロー構築の基盤となる見込み

Skillsの概要と動作原理

  • Agent Skills機能を通じて、Claudeが特定の作業をよりうまくこなせるよう、カスタマイズされたスキルを利用できる
  • スキルは指示、スクリプト、リソースを含むフォルダ形式で提供され、Claudeは関連する作業が必要なときにだけそのスキルへアクセスする
  • この機能により、Excel文書管理、組織のブランドガイドライン順守など、さまざまな専門業務でClaudeをより強力に活用できる
  • ユーザーはカスタムスキルを作成し、Claudeアプリ、Claude Code、APIなどで横断的に利用できる

Skillsの動作方式

  • Claudeは作業実行中に利用可能なすべてのスキルをスキャンし、最も関連性の高いスキルを見つけるアルゴリズムを持つ
  • 一致するスキルがある場合、必要最小限の情報とファイルだけを読み込み、速度を維持しながら専門的な作業遂行能力を確保する
  • スキルの特徴
    • 組み合わせ性: 複数のスキルをスタックのように併用でき、Claudeが自動で必要なスキルを調整する
    • 移植性: 同一フォーマットで記述されており、Claude製品群のどこでも利用可能
    • 効率性: 必要な時点で必要な機能だけを呼び出す
    • 強力さ: 実行可能なコード（e.g. Python, Shell）なども含められるため、従来のプログラミング効率を活用できる
  • スキルは組織の専門知識をパッケージ化してClaudeに渡すカスタムオンボーディング資料という概念であり、専門性をパッケージ化してClaudeが特定領域の専門家役を担えるよう設計されている

Claude製品との統合

Claude Apps

  • Pro、Max、Team、Enterpriseユーザーはすべてスキル機能を利用可能
  • デフォルトで文書作成など一般的な業務向けのさまざまなサンプルスキルが提供され、独自にカスタマイズも可能
  • ユーザーが作業内容を入力すると、Claudeが自動で適切なスキルを呼び出す方式で、チェーン・オブ・ソートでもスキル動作を確認できる
  • skill-creatorスキルにより、対話型ガイドのもとでワークフローへの質問、フォルダ構造の生成、SKILL.mdの自動フォーマット、リソースのバンドルなど、簡単なスキル作成を支援
  • Team/Enterpriseでは管理者が組織単位で機能を有効化する必要がある
  • 設定ページで利用可能

Claude Developer Platform (API)

  • Messages APIリクエストと新しい/v1/skillsエンドポイントを通じて、カスタムスキルのバージョン管理と運用制御が可能
  • スキル利用には、安全なコード実行環境を提供するCode Execution Toolベータ機能が必要
  • Anthropic提供のスキルにより、Excel、PowerPoint、Word、PDFなどの専門家レベルの文書生成と編集が可能
  • 開発者は特定ワークフロー向けのカスタムスキルを作り、Claudeの活用範囲を自由に拡張できる
  • Claude Consoleで簡単なスキルバージョンの作成、参照、アップグレードをサポート
  • ドキュメントおよびAnthropic Academyで追加学習が可能

パートナー活用事例

  • Box: 保存済みコンテンツを自動変換してPowerPoint・Excel・Word文書を生成し、組織標準に合わせた自動文書化を支援
  • Notion: 複雑な質問をすぐ実行可能な作業へ変換し、プロンプト調整の負担を軽減
  • Canva: Skillを通じてエージェントをカスタマイズし、デザイン自動化とチーム単位の高品質コンテンツ制作を支援
  • Rakuten: Skillベースで財務・会計を自動化し、複数のスプレッドシートを統合処理してレポート作成時間を1日 → 1時間に短縮

Claude Codeとの連携

  • Claude Codeでチームの専門性とワークフローを拡張できるよう、スキルのインストールをサポート
    • anthropics/skillsマーケットプレイスのプラグイン方式、および~/.claude/skillsへ直接フォルダを追加する方法に対応
  • バージョン管理システム連携による、チーム間でのスキル共有と協業機能を提供
  • Claude Agent SDKを通じてカスタムエージェント開発も支援

はじめに

今後の計画と注意事項

  • 今後はSkill作成プロセスの簡素化と組織単位での配布機能強化を予定
  • SkillはClaudeがコードを実行できるようにするため、信頼できる提供元のSkillのみを使うべき
  • データ保護とセキュリティ維持に注意し、詳細は案内ドキュメントを参照

関連記事

4件のコメント

 
ahwjdekf 2025-10-21

ジャガイモ1個を焼いて食べ、茹でて食べ、炒めて食べ、煮込んで食べ、すりつぶして食べて…
 
ahwjdekf 2025-10-21

そのたびにいろいろもっともらしい名前を付けるけど、結局は全部ポテト味だ。
 
GN⁺ 2025-10-17
Hacker Newsのコメント

  • 今後はフロントエンド開発で経験したように、ChatGPTやClaudeなどを取り巻く概念的な混乱がかなり起きそうだと思う。いまはツール、関数、スキル、エージェント、サブエージェント、コマンド、アプリなどさまざまな概念があふれていて、この混乱の上に各種の「vibe」フレームワークが増え続けている

    • mcp関連の機能も忘れてはいけない。そう、確かに混乱ではあるが、その土台には学びやすい基本概念がある。新機能が追加されてもメンタルモデルに簡単にはめ込めるし、あるいは完全に無視して自分でツールを作って使うのもよい方法だ。この基本的なメンタルモデルは、LLMをループで呼び出し、セッションで何をしたかの履歴（=コンテキスト）を継続的に保存しながら、ファイルの読み取り、書き込み、bash呼び出しなどのツール呼び出しをできるようにする構造だ。「エージェントループ」とも呼ばれ、100行のPythonコードでも実装できる。LLMに関心のある開発者なら、ぜひ一度自分で作ってみることを勧める。実際にやってみると本当に目が開かれる経験になる。自分で単純なエージェントを作ってみれば、新しいツールが出てきても、それがどう動くのかを実装の観点から自然に説明できるようになる。たとえばClaude Skillsは、1) LLMに対する命令が書かれた複数のファイル、2) 起動時に利用可能なスキルだけをざっと確認して、LLMのコンテキストには短い説明だけを集めておく、3) LLMにスキルの使い方を教え、Claudeでは bash ツールを使う、4) 実際にスキルを使うときは「call bash」でファイルを読み込んで作業を実行する。もちろん、細部では重要な権限管理などはここでは省略しているが、核心の構造はこういうものだ
    • エコシステムはいまや複雑になりすぎて、自壊する可能性すらあるように感じる。あらゆるシステムやプラットフォームには、人々が日常的に記憶に留めておける限界のような総複雑性予算があり、それをどこに使うかがとりわけ重要だ。プラットフォーム提供者が新たな複雑性を追加すれば、それはプラットフォーム上に積み上げられる価値から差し引かれる。最近は提供者が差別化のために複雑性をどんどん追加しているが、結局は必要な顧客がプラットフォームに入ってこられない障壁を高くし、プラットフォーム上に本当に積み上げられる価値を削っている。いまも重複する似たようなコンセプトが新たな複雑性予算を食いつぶしている一方で、実際の追加機能は大してないように見える。内部では「こういう機能を入れれば学びやすくなる」と錯覚しがちだが、実際には引き込んだ人数と同じくらい押し出しているだけで、得るものはあまりないかもしれない
    • まったく新しい技術なので、まだ未知の領域が多すぎる。クラウドツールやPythonライブラリ選びも似た問題だった。だから誰もがアーリーアダプターではない理由でもある。これらすべてを追いかける精神的コストはかなり大きい
    • コアループは単純だが、この種の命令型の概念を自由に試せる最小限のフレームワークは本当に貴重だ。私は Beads をすぐフレームワークに組み込めて、良ければ使い続け、いまいちなら外せるのがよかった。toolkami も参考になる
    • 「Metastasizing」はこの現象を本当にうまく表している。既存の概念の上に際限なく積み重なっていく

  • さっきスキルについて記事を書いたが、「Claude Skillsは本当にすごい。MCPより大きな変化かもしれない」 記事リンク

    • SkillsとAGENTS.mdは重なる部分があると思う？ VSCodeでも最近、nested AGENTS.md機能を実験的に導入したし、形式はより緩いが、概念としては重なるかもしれない VSCodeアップデートリンク
    • スキルというのは、厳密な仕様に入れるべき機能というより、デザインパターンやプロンプトエンジニアリングの小技に近い感じがする。実際、MCPの中でも実装できていた。私は「何かを始める前にskills MCPで検索して関連ガイドを読む」という形で使ってきた
    • skillが必要な瞬間と、プロジェクトとして作るべき瞬間を、いつどう見分けるべきか気になる

  • 私は、こうしたシステムが問題をうまく解けるかどうかは、主にスキルに書かれた要約文にかかっていると見ている。人間は経験を積むにつれて、いつどのスキルを使うべきか把握できるようになるが、Claudeは毎回ゼロから、説明をざっと読んで始めるだけだ

    • 人間が経験を通じて熟練したスキル利用者になるのとは違って、LLMは単に模倣しかできない。だからRichard Suttonは、LLMはAGIへ進化できないと見ている。Suttonによれば、AGIは強化学習から生まれ、LLM（ニューラルネットワーク）は模倣しかできない。LLMは目標と行動の結果という認知的土台を持っていないので、LLMにおける「skill」は単なるリファレンスマニュアルに近い。作業・楽器・解決策の開発に反復的に応用できる「スキル」とは性質が異なる Sutton動画
    • 結局これはコンテキストウィンドウの問題だ。人間は非常に広い文脈を不正確ながら記憶できるが、特定の分野に1万時間以上注いで習熟すると、その「技術」はよく覚え、そうでないものは忘れる。LLMはプログラム的コンテキストとして一定に保存し、完全に想起できるが、全体の文脈をすべて見渡すには時間もコストもかかりすぎる。だからSkills（正確にはcontext insertion）は、出力の優先順位を手動調整する方法だ。LLMの思考モードも結局はコンテキストの再調整だ。「毎回ゼロから」とは限らない。このように捉えるとツール活用はずっと簡単になる
    • LLMが毎回新しい出発点を強いられるのは、マルチテナントなインフラのせいではないかと思う。OpenAIやAnthropicが複数ユーザー向けにサーバーやメモリを再利用したいのも自然だ。もしかすると、過去の会話をすべてLLMが記憶するような「個人用」のシングルテナント設定が可能なのか気になる
    • LLMで知識やツールを豊富に積み上げるうえでの核心は、何をいつ使うべきかをLLM自身が気づけるようにすることだが、これは今のところほぼ不可能な領域だ
    • 経験の大半は、プロジェクトや会話に関係ない一般情報だ。LLMはこうした知識を土台として持ち、その次にプロジェクト専用の情報だけを別に記憶・検索できるべきだ。人間の情報検索速度は非常に速いが、LLMも多少遅くてもほぼリアルタイムで参照は可能だ

  • Claudeの「skills」は、開発者がきちんとした文書を作成し管理してはじめてまともに機能する仕組みなので、かなり皮肉だ。実際のコード文書すら管理できない開発者が多いのに、LLM向け文書はさらに難しいだろう。非常に整理されたファイルシステムと高いリスク受容性まで備えた少数の開発者には意味があるかもしれないが、そもそもそういう人なら、こうした雑務をLLMに任せるより、教育も兼ねてジュニアにやらせたほうがよいのではないかと思う。どうせ最終的には成果物を全部レビューしなければならないし、コンテキストウィンドウにも限界があるので、本当に「人のように」スキルが体得される感じを実装するのは難しい。専用LLMの訓練までやるなら、結局そのLLMに一生縛られる構造になる。いろいろな意味で、こうした「理想的に組織内ですべての星が揃う」という前提自体が面白く感じられる

    • LLMがうまく回るには、開発者文書と、この記事で整理されている さまざまなプロ開発者向けインフラが必要だという点は、本当に役立つ動機づけになる。むしろ経営陣を説得するのにも役立つ
    • LLMは文章を書くのがうまい開発者ほど報酬が大きい。だから開発者がLLMを嫌がる理由の一つかもしれない
    • 私もコメントを探しに来たが、この視点を指摘したのはあなただけのようだ。「Skills」は結局のところ詳細な文書化であり、実際にはプロジェクトごとにそんな文書を書いたことはほとんどない。もしLLM skillsのおかげで、すべての開発者が本当に詳細な文書を書くようになるならよいが、そうなる可能性はあまり高くなさそうだ

  • Sub agents、mcp、skillsなどがどう相互作用していくのか気になる。重複がかなり多いように感じる。仕様を拡張してClaudeに追加機能を与える方向性自体は悪くないが、実際にはどんな方法でもエージェント機能の実装は似たレベルまで可能になる。今まではmcpではjsonが必要だったが、Claudeではファイルやフォルダにmarkdownを入れるだけでよく、マルチモーダル入力も可能なのでUXはかなり改善したようだ

    • Claude SkillsはただのMCPプロンプトと同じに見える MCPプロンプト仕様。わざわざ新しい概念を作った理由がわからない。チャットUIならマーケティング的には理解できるが、Claude Codeでは？ CLAUDE.mdもあるのに、少し疑問だ
    • 私はこの3つはかなりうまく相互補完すると見ている。MCPはAPIをLLM agentが使えるように包む役割、Skillsは必要なときだけ追加の指示をコンテキスト効率よくエージェントに渡す役割で、一部の命令ではMCPの使い方も案内できる。Sub-agentsはまた別のコンテキスト管理パターンで、上位エージェントが下位エージェントにミッションを送り、必要に応じてskillsとMCPを併用してトークンを節約できる

  • こういう機能が追加されるのはかなり新鮮だ。私のプロジェクトでは bin/claude のサブフォルダを別に作って、Claudeが作ったスクリプトなどを入れるようにし、claude.mdにその場所をきちんと記録してツール検索に活用している。実用上の性能もかなりよかった。実際に本当に必要なのはコンテキスト管理ヘルパー、つまり「このMCPセットでclaudeを起動して、次はあのMCPセットに切り替える」といったものだが、いまはプロジェクトごとにサブディレクトリ（プロファイル）を別管理して、そこから毎回 claude を起動している。この構造ではbin/claudeが役立っていて、Claudeは特定のBigQueryデータセットの分析方法や認証ファイルの場所などをすぐ把握できる。自分がファイルシステムをプロファイル管理に使うとは思っていなかったが、結局そうなっている

    • 「コンテキスト管理ヘルパー」という話を聞くと、それこそsub agentsなのではという気もする

  • なぜこういうデモでは、犬の画像を反転したり切り抜いたりするような、あまりに単純な例を使ったのかわからない。もっと説得力のあるスキル活用例はいくらでもあるだろうに

    • 開発者ページには、もっとずっと良いPDF処理の例がある PDFスキル文書。実際、私もclaude codeでは使い方ガイドを含むMarkdownファイルを@タグ付けして使っていたが、いまはそれが自動化されてさらによくなった
    • ウィキペディアの "The purpose of a system is what it does" を読むと一度考えさせられる
    • 今日の朝、Claudeで.xlsxファイル生成に関して遭遇した2つの問題も、この文書に解決法が載っていた Excelスキルの例
    • 犬の写真の例は、結局のところ消費者向けに伝えるためのわかりやすいリファレンスという趣旨だ

  • Claude-skillsの導入はものすごく速く広がっている感じがする。私は火曜日に「Superpowers」の 紹介記事 に強く惹かれ、それまで作っておいたツールもきれいに整理して、エージェントに任せて使えるスキルとして包んだ。deli-gatorオープンソース へのフィードバックも歓迎する

    • エージェントへの委任（delegation）機能は本当に魅力的だ。Linear issueのコンテキストが過剰に入ってくることが多く、たとえばissueの説明と最後のコメントだけ欲しいのに、Linear MCPは全コメントを取ってきてコンテキストが汚染される

  • 先週金曜日、私は誤ってClaude Skillsの存在を先に明かしてしまったが、いまは公式に出てよかった 関連ブログ記事

    • 「Claudeインスタンスを新しく立ち上げて、/mnt/skillsフォルダ全体をzipファイルにしてくれとプロンプトすると本当に動く」という、この手のハックが現実になったのは面白くもあり怖くもある。どうかファイルシステム全体やバイナリアクセス権まではないことを祈る。もしSSHまで可能なら……
    • Jesseのブログが最近本当に活発でありがたい

  • skills、plugins、マーケットプレイス、コネクタ、アドオンなど種類が多すぎて追いきれない

    • 私の考えでは、無理に追う必要はない。プロンプトエンジニアリングにおける「ベストプラクティス」と似ていて、こうしたものは一時的な制約を回避するためのその場しのぎにすぎないので、本当に必要な性能が既存モデルに標準搭載されるまでは、あえて時間を投じる必要はない。数か月もすれば消えるものばかりなので、性能が急ぎで必要なときだけ関心を向ければよい
    • こうなっている理由は少し理解する必要がある。会社としては何かを作って見せなければならないが、主力プロダクトはいまだ「大量失業の時代」という約束を実現できていない。これはユーザー向けというより投資家向けのシグナルで、「研究者に給料を払うだけで何もしていないのではなく、こうして多様な製品も作り、データも回している」と示しているのだ。巨大なABテスト基盤もあるわけだし
    • ユーザーの立場では、提供会社ごとの専用機能が増えるほど、学ぶことも設定することも増え、ベンダーロックインも強まるので、むしろ損だ。しかしモデル提供者にとっては、こうした機能を出し続けることが製品差別化を維持する手段だ。それすらなければ、自分たちの作るものは単なるコモディティになってしまう
    • 機能追加はチームの士気が上がる限り続きそうだ
    • 実際にはそれほど複雑ではないと思う。Pluginsにはcommands、MCPs、Subagents、そして今ではSkillsが含まれる。マーケットプレイスは、こうしたプラグインを集めた場所だ