🧠 Claude Skillsの「設計思想」を哲学から読み解いてみたら、ちょっと革命的だった話

📌 はじめに

Anthropicが2025年10月にローンチした Claude Skills。

表面的には「便利な機能パッケージ」に見えます。

しかし仕様を読み込むと、印象が変わりました。

人間とAIが共有する能力基盤の在り方そのもの を再定義しようとする、踏み込んだ思想設計だと気づいたのです。

🎯 この記事のゴール

この記事では、Skillsの設計思想を 3つの問い から読み解きます。

• スラッシュコマンドはなぜSkillsに統合されたのか？
• 「ユーザー起動」と「AI起動」を分ける意味はあるのか？
• そもそも、ワークフローは「知識」なのか「アクション」なのか？

結論を先に言っておきます。

Anthropicの設計は「主体で分けない、形式で分けない、能力（Skill）として束ねる」という、かなりラディカルな思想に基づいている。

👥 想定読者

• Claude Code / Claude Skills を触っていて、設計思想に興味がある方
• AIエージェント向けの社内ナレッジ基盤の構築を検討している方
• 「人間向けドキュメント」と「AI向けプロンプト」の関係に違和感を持っている方

📖 この記事の表記について

本記事では、> で始まる引用ブロックは Anthropic 公式の文言 です。

公式ドキュメントおよびエンジニアリングブログから直接引用しています。

それ以外の地の文は、その引用を踏まえた 筆者の考察・解釈 です。

「思想」「ラディカル」「境界を解消する」などの表現も、筆者の読みです。

Anthropic公式の宣言ではありません。

🛠️ 動作環境・参照ソース

• Claude Code（2025年10月リリース版以降のSkills対応）
• Anthropic公式ドキュメント: Extend Claude with skills
• Anthropic公式エンジニアリングブログ: "Equipping agents for the real world with Agent Skills"（2025年10月16日）
• 哲学的背景: Gilbert Ryle, The Concept of Mind (1949)

🎬 きっかけ：「これ、ディレクトリ分けなくていいの？」

最初に違和感を持ったのは、大規模なClaude Codeコミュニティのリポジトリを眺めていたときでした。

skills/ ディレクトリの中に、こんなものが 全部同じ階層で並んで いたのです。

skills/
├── python-patterns/         ← Pythonのイディオム集（参照する知識）
├── react-patterns/          ← Reactの書き方（参照する知識）
├── api-design/              ← API設計原則（参照する知識）
├── tdd-workflow/            ← TDDの手順（順番に実行するもの）
├── code-review-workflow/    ← コードレビュー手順（実行するもの）
├── security-review/         ← セキュリティチェックリスト
└── ...

率直に「これ、性格が違うものが混ざってない？」と思いました。

• python-patterns は、必要なときに 参照する 静的な情報
• tdd-workflow は、ステップ順に Claude が 解釈して実行する 動的なプロセス

前者は「知識」、後者は「ワークフロー」。

これだけ性質が違うのに、なぜ同じディレクトリに並べるのか。

分けたほうが管理しやすいのではないか。

そう思って公式ドキュメントと、Anthropic公式エンジニアリングブログを読みに行きました。

すると、目を引く一文がありました。

Claude is powerful, but real work requires procedural knowledge and organizational context.

「procedural knowledge」── 直訳すれば「手続き的知識」。

私が「ワークフロー」と呼んでいたものを、Anthropicは 「知識の一形態」として位置づけている のです。

動的なプロセスを「アクション」でも「コマンド」でもなく、まず「知識」と呼ぶ。

このスタンスは見落とせません。

そしてもう1つ、重要な事実があります。

Anthropicがこの機能全体に Skill（技能・能力） という名前を付けていることです。

中身の構成要素を procedural knowledge（手続き的知識）と呼びつつ、束ねた単位は Knowledge Pack でも Knowledge Module でもなく Skill と命名した。

つまり用語法として、Anthropicは2つのレイヤーを使い分けています。

• 中身 = 知識（declarative / procedural）
• 束ねた単位 = Skill（能力・技能）

「知識を、使える能力として束ねる」── この命名の二段構えに、設計思想が現れているように見えます。

さらに、/command-name で起動する旧来のスラッシュコマンドについて、公式ドキュメントはこう明記しています。

Custom commands have been merged into skills. A file at .claude/commands/deploy.md and a skill at .claude/skills/deploy/SKILL.md both create /deploy and work the same way.

カスタムコマンドは Skills に統合された。

.claude/commands/deploy.md も .claude/skills/deploy/SKILL.md も、どちらも同じ /deploy を生成して同じように動作する。

つまり旧来のコマンドと skill は、機能としてシームレスに同じものとして扱われています。

ここで気づきました。

これは単なる実装の整理ではなく、思想的な統合 だと。

「分けなくていいのか」という私の問いに対して、Anthropicは「分けないことに意味があるんだ」と答えているように見えたのです。

そこから掘り下げていったのが、この記事の出発点です。

📜 Anthropic公式仕様の整理

統合後のSkillには、起動制御のための2つのフィールドが用意されています。

frontmatter	効果
（指定なし）	デフォルト：ユーザーもClaudeも両方起動可能
disable-model-invocation: true	ユーザーのみ起動可能（副作用持ち操作向け）
user-invocable: false	Claudeのみ起動可能（背景知識向け）

公式ドキュメントの該当部分はこう書かれています。

By default, both you and Claude can invoke any skill. You can type /skill-name to invoke it directly, and Claude can load it automatically when relevant to your conversation. Two frontmatter fields let you restrict this.

ここで重要なのは動詞です。

"restrict"（制限する）。

つまり公式仕様の設計思想は、こう読めます。

• デフォルト = 両方有効（最大の自由度）
• フィールド指定 = あえて制限をかける（restriction）

これは、よく読むと結構踏み込んだ宣言です。

💡 第一の洞察：「主体」で分けるのはもう古い

旧来のメンタルモデルでは、こういう分離がありました。

• Commands = 人間が起動するもの（人間専用UI）
• Knowledge Base / Prompts = AIが参照するもの（AI専用データ）

つまり「誰のためのものか」で分けていた。

ところが統合後のSkillでは、デフォルトで両方が呼び出せる。

これは何を意味するか。

「能力（Skill）というものは、人間だけのためのものではない。AIだけのためのものでもない。どの主体が呼び出すかは、Skillごとに後から決められる。」

呼び出す主体（人間かAIか）は、能力（Skill）自体の性質を変えるものではない。

これに気づいたとき、ちょっと鳥肌が立ちました。

🔍 制限フィールドの「存在意義」が思想の根拠

ここで重要なのは、制限フィールドが 存在すること自体 が思想の根拠になっている点です。

disable-model-invocation と user-invocable の2つを指します。

もしAnthropicが「Skillは誰のものでもない」と一辺倒に考えているなら、これらのフィールドは不要なはずです。

でも実際には、次のようなケースがあります。

• デプロイ操作 は人間だけが起動すべき（AIの判断に委ねたくない）
• レガシーシステムの背景知識 はAIだけが参照すれば良い（メニューに出ても人間は使わない）

このように、「能力（Skill）そのものは中立だが、特定のSkillは特定の主体だけが扱うべきケースがある」 ことを明確に認めています。

つまり設計思想は、2つのレイヤーから成り立っています。

レイヤー1：能力の本質（中立）

• 同じMarkdownを人間もAIも読む
• 同じskillを人間もAIも呼び出せる
• 「人間用ドキュメント」と「AI用プロンプト」を分けない

レイヤー2：能力のアクセス制御（設計可能）

• デフォルトは両方アクセス可能
• 必要に応じて制限できる

🧠 第二の洞察：「形式」で分けるのも本質的ではない

ここで冒頭の問いに戻ります。

そもそも私が違和感を持ったのは、性質の違う2つが同じディレクトリに並んでいたことでした。

python-patterns（静的な参照情報）と tdd-workflow（順序的なプロセス）です。

前者は「知識」と呼ぶのが自然です。

一方、後者は「ワークフロー」と呼びたくなる。

これは別物ではないのか？

ここで一度、哲学に立ち寄ってみます。

📚 知識の古典的二分類

人間の知識を扱う学問領域では、伝統的に知識は2種類に分類されてきました。

哲学者 Gilbert Ryle が1949年に提示した古典的な議論です。

① 宣言的知識（Declarative Knowledge）= "Knowing That"

• 「何がそうであるか」を記述する知識
• 例：「水は100℃で沸騰する」「Reactは仮想DOMを使う」
• 静的・命題的・参照可能

② 手続き的知識（Procedural Knowledge）= "Knowing How"

• 「どうやってそれを行うか」を記述する知識
• 例：「自転車の乗り方」「TDDの実践方法」
• 動的・順序的・実行可能

Ryleの核心的な主張はこうです。

"Knowing how is not reducible to knowing that."

「やり方を知る」ことは「何かを知る」ことに還元できない。

けれども、両方とも知識である。

🧩 Skillの全体像に当てはめると

「ワークフロー」は知識から外れた特別なものではなく、「手続き的知識」という形態の知識である。そして Skill は、宣言的知識と手続き的知識を束ねて「使える能力」にしたパッケージである。

そして、冒頭で引用したAnthropic公式エンジニアリングブログの一文を、もう一度読み直してください。

Claude is powerful, but real work requires procedural knowledge and organizational context.

Anthropicが選んでいる用語は、まさに procedural knowledge（手続き的知識） です。

「ワークフロー」でも「アクション」でも「コマンド」でもない。

「知識」というカテゴリで包摂する用語法 を公式に採用しています。

しかも、その知識を束ねた単位を Skill（能力） と命名した。

これは、宣言的知識も手続き的知識も「能力の素材」として等しく扱う、というスタンスの表明と読めます。

ここに、冒頭の私の違和感への答えがあります。

python-patterns と tdd-workflow が同じディレクトリに並んでいたのは、設計の雑さではありませんでした。

「どちらも Skill（能力）を構成する知識である」という認識 が、ディレクトリ構造に素直に表れていただけだったのです。

🎨 ここまでの設計思想を統合する

ここまでの2つの洞察を統合すると、Anthropicが Commands → Skills 統合で実現した世界観が見えてきます。

過去の二分法	フラットな答え
skillはユーザー用？AI用？	両方用（主体で分けない）
skillは宣言的？手続き的？	両方ある（形式で分けない）

ここから導かれる答えはこうです。

Skillとは「主体や形式に依存せず、宣言的知識と手続き的知識を束ねた『使える能力』のパッケージ」である。

つまりSkillという統一概念は、2つの境界を超える装置として読めます。

人間とAIの境界、宣言的と手続き的の境界、その両方を超えて「能力」として束ねる のです。

🔧 実践への落とし込み

哲学的な議論を、現場で使える指針に落とし込みます。

基本方針：90%以上のskillは「制限なし」で作る

frontmatterは最小限にして、デフォルト動作（両方有効）を使う。

これが Anthropic公式推奨の標準形 です。

---
name: tdd-workflow
description: Use this skill when writing new features, fixing bugs, or refactoring code.
---

これで何の問題もありません。

「中途半端」ではなく、「制限なしの完全な状態」です。

例外：制限が必要なケース

ケース	フィールド	例
本番デプロイ	disable-model-invocation: true	/deploy-production
Slack通知送信	disable-model-invocation: true	/notify-team
課金関連操作	disable-model-invocation: true	/charge-customer
内部コンテキスト供給専用	user-invocable: false	legacy-auth-system-context

判別基準は明確です。

disable-model-invocation: true を足すべきなのは：

• 取り消せない外部副作用がある
• Claudeが文脈で誤判断したら困る
• 必ず人間が明示的にトリガーを引くべき

user-invocable: false を足すべきなのは：

• skill名がスラッシュコマンドとして意味をなさない
• メニューに並んでいてもユーザーが混乱する

コンテンツの性質と起動制御は別物

ここで強調したいことがあります。

「ワークフロー型だから人間専用」「知識参照型だから制限なし」みたいな対応関係は存在しない ということです。

以下の4通りはどれも普通にあり得る組み合わせです。

skill例	コンテンツの性質	起動制御
python-patterns	知識参照型	制限なし（両方起動可）
legacy-auth-context	知識参照型	AI専用
tdd-workflow	ワークフロー型	制限なし（両方起動可）
/deploy-production	ワークフロー型	人間専用

「コンテンツが何か」と「誰が起動できるか」は 別々に決める設計判断 です。

「ワークフローっぽいから人間専用にしないと」と連動させて考える必要はありません。

🌟 「全てを Skill として束ねる」設計の強さ

この設計の本当の強さは、合成と進化の容易さに表れます。

🤝 自然な合成ができる

ユーザー: "新機能を実装したい"
  ↓
Claude が複数のskillを同時参照:
  - tdd-workflow（手続き的）→ 進め方
  - typescript-patterns（宣言的）→ 書き方
  - security-review（宣言的）→ 守るべきこと
  - api-design（宣言的）→ 設計原則

全部「Skill」という同じ抽象（=使える能力）で扱える。

だから 自然に組み合わさる。

🌱 自然な進化ができる

「次回からはこうすべき」という手続き的知識も、「これは知っておくべき」という宣言的知識も、同じ Skill レイヤーで蓄積されていきます。

「やり方の蓄積」と「知識の蓄積」が、同じ「使える能力」の基盤の上で起こる。

これは知識基盤としても、能力基盤としても、非常に強力な性質です。

📎 補足：公式が語る「Skillの構成要素」について

ここまで Skill の中身を「宣言的知識 / 手続き的知識」という Ryle 的な観点で語ってきました。

これは Skill の中身（content）をどう類型化するか という、筆者の分析的観点です。

これとは別に、Anthropic公式は Skill の物理的な構成要素（components） を、次の3つで説明しています。

Skills are folders of instructions, scripts, and resources that Claude loads dynamically...

つまり1つのSkillは、こう構成されます。

• instructions: SKILL.md 本体や reference.md など、Claudeが読むテキスト
• scripts: Claudeが裁量で実行する実行コード（Python等）
• resources: 画像・データファイル・テンプレート等の参照素材

特に scripts（実行コード） については、公式エンジニアリングブログに 「Skills and code execution」 という独立したセクションが設けられており、こう明記されています。

Skills can also include code for Claude to execute as tools at its discretion.

ここで間違えないでほしいのは、これらは Skill の分類（型）ではなく、1つの Skill の中に並存する構成要素 だという点です。

例えば PDF 操作の Skill には、テキストの指示・Pythonスクリプト・参照素材が 同居 しています。

instructions / scripts / resources は「Skillの内部パーツ」の話であり、「宣言的知識 / 手続き的知識」という Ryle 的な「知識の型」の話とは粒度が違う。

本記事の「宣言的 / 手続き的」という議論は、このうち主に instructions の中身を対象にした分析だとお考えください。

scripts（実行コード）は、Ryle と並ぶ「知識の型」ではなく、Skill を構成する一要素として位置づけられます。

⚠️ フラットに見ると、限界もある

絶賛だけだと公平でないので、批判的視点も入れておきます。

「全てを Skill として束ねる」設計の弱点

1. 副作用持ち操作との相性
   • 「デプロイ手順」は手続き的知識です。
   • しかし、それを実行することは副作用を伴うアクションです。
   • 知識と実行の境界が曖昧になりやすいのです。
2. 検証可能性
   • 宣言的知識は真偽が問えます。
   • しかし手続き的知識は「正しく実行できるか」しか問えません。
3. 粒度の問題
   • 「ワークフロー全体」を1つのSkillにするか、ステップごとに分解するか。
   • この判断が難しいのです。

哲学的には統合できても、運用上は区別したほうが扱いやすいケースもあります。

このあたりはまだ実践知が成熟していない領域だと感じます。

🎯 まとめ

Anthropicの Skills 統合に込められた思想

「Skillとは、宣言的知識と手続き的知識を束ねた『使える能力』である。人間でもAIでも、必要とする主体が必要なときに引き出せる。ただし、どの主体が引き出すべきかは、Skillごとに設計者が決められる。」

この思想は、2つの境界を解消します。

1. 主体の境界: 人間用ドキュメントとAI用プロンプトの分離を解消
2. 形式の境界: 宣言的知識と手続き的知識の分離を解消し、両者を「能力」として束ねる

なお、Anthropic自身がエンジニアリングブログで明示的に語っている動機は別にあります。

Progressive Disclosure（段階的開示） という工学的設計原則です。

"Progressive disclosure is the core design principle that makes Agent Skills flexible and scalable."

つまり Anthropic 自身の説明では、「必要なときに必要な分だけロードする」という話が前面に出ています。

コンテキストウィンドウ効率化の議論です。

本記事の「主体・形式の境界を超えて Skill として束ねる」という読みは、その工学的設計の 結果として浮かび上がる思想 を筆者なりに言語化したものです。

両者は別レイヤーの議論として両立します。

私たちが意識すべきこと

skillを書くということは、単に「Claude用のプロンプトを書く」ことではありません。

人間とAIが共有する「使える能力（Skill）」の基盤を構築する ことです。

そう考えると、SKILL.mdを書く態度も変わってきます。

• 人間が読んでも、AIが読んでも、同じように「能力」として行使できるか
• 宣言的な情報と手続き的な情報を、適切に分離・統合できているか
• 主体ベースではなく、能力の性質ベースで設計できているか

これらは、AI時代の新しい技術文書作成の基本リテラシーになっていくはずです。

🙏 おわりに

「能力は誰のものか」「ワークフローは知識か、それとも能力か」。

これらの問いに、皆さんはどう答えますか？

普段skillを書いている方、これから書いてみようと思っている方、社内のAIナレッジ基盤を整備しようとしている方。

設計判断の足がかりになれば嬉しいです。

「ここはこう考えるべきでは」「実際の運用ではこう困った」など、コメントや引用RPでぜひ議論させてください。

📚 参考リンク

• Anthropic公式: Extend Claude with skills
• Anthropic公式エンジニアリングブログ: Equipping agents for the real world with Agent Skills
• Gilbert Ryle, The Concept of Mind (1949) - "Knowing How vs Knowing That"