AIプロバイダーに指示を逐一読み上げるのはやめて、サブエージェント、スキル、コマンドを作成しよう

プロンプト依存からインテリジェントエージェントシステムへ

多くの人はいまだにAIを“テレプロンプター”のように使っています。

プロンプトを打つ。待つ。返答を受け取る。それをどこかにコピペする。そしてまた同じことをする。何度も。同じことの繰り返し。すべてのやり取りはゼロから始まる。すべての会話は、それまでの流れを忘れてしまう。

これは協働ではありません。手間の多い口述筆記です。

2026年になっても、まだAI提供元をテレプロンプターのように扱っているなら、その足元で起きている大きな変化を取り逃しています。

テレプロンプター問題

AIをテレプロンプターとして使うというのは、本来自律的にもなり得るシステムを、単発のテキストジェネレーターとして扱っているということです。流れはこんな感じです。

詳細なプロンプトを書く
レスポンスを待つ
出力を手作業で評価する
修正して再プロンプトする
チャットを閉じると、コンテキストをすべて失う

テレプロンプター対エージェント型サブエージェントのモデル図（フローチャートとテキスト付き）。

このモデルには致命的な欠点が3つあります。

永続的な知識がない。 すべての会話が白紙の状態から始まります。同じ前提を何度も何度も説明することになります。AIはあなたのコードベースも、嗜好も、制約条件も、履歴も知りません。

委任できない。 ボトルネックは常にあなたです。あらゆる判断、検証、次のステップに、あなたの入力が必要になります。AIは、次に何をすべきかあなたの指示を待ち続けます。

専門分化がない。 コーディング、ドキュメント作成、デザイン、テスト、デプロイ——すべてを、1つの汎用インターフェースで済ませています。1種類のプロンプト。1つのコンテキストウィンドウ。1つの会話で、いくつもの役割を担わせているのです。

テレプロンプターモデルはAIをツールとして扱います。しかし、ツールは自律性をスケールさせてはくれません。スケールさせるのはエージェントです。

エージェントとして考えると何が変わるか

Claude Code におけるエージェントアーキテクチャは、3つのプリミティブから成ります。

サブエージェント：コンテキストウィンドウを分離した、専門特化した Claude インスタンス（~/.claude/agents/）
スキル：SKILL.md を持つ、自動トリガー型のナレッジモジュール（~/.claude/skills/）
コマンド：明示的なアクションのためにユーザーが起動するスラッシュコマンド（~/.claude/commands/）

従来のプロンプト利用との主な違いは次の通りです。

スキルは、コンテキストに基づいて Claude が自動的に起動する
コマンドは、あなたが明示的に/commandと入力する必要がある
サブエージェントは独立したコンテキストで、それぞれ固有のツールを使って動作する

この違いをイメージしてみましょう。

テレプロンプター的なアプローチ：

「画像、タイトル、本文テキスト、プライマリボタンを含むカードコンポーネントを、私たちのデザインシステムのパターンとアクセシビリティ標準に従って書いてください……」

Claude Code 的アプローチ：

/generate card --variant=default --with-image=true --with-button=true

最初の例は「依頼」です。2つ目は、すでに「カードとは何か」「あなたのデザインシステムの要件」「適用されるアクセシビリティ標準」「自分の出力をどう検証するか」を知っているスキルを呼び出しています。

アーキテクチャ：サブエージェント、スキル、コマンド

テレプロンプターモデルの代わりとなる構造はこうです。

Flowchart of agent architecture showing subagents, skills, and commands.

レベル1：サブエージェント

サブエージェントは、~/.claude/agents/ にあるスタンドアロンのMarkdownファイルで、並列に作業を実行します。それぞれ独自のコンテキストウィンドウを持ち、スキルを呼び出せます。

~/.claude/agents/
├── header-builder.md
├── footer-builder.md
└── dashboard-builder.md

各サブエージェントファイルにはYAMLフロントマターがあります。

name：明確な識別子
description：何をするのか、いつ呼び出されるべきか
tools：使用を許可された機能（Read, Write, Bash, Grep, Glob）

サブエージェントの例（header-builder.md）。

---
name: header-builder
description: Build complete header components with navigation
tools: Read, Write, Bash, Glob, Grep
---  You are a header component specialist...

レベル2：スキル

スキルは自動トリガーされるナレッジモジュールです。Claude に対して行った質問がスキルの目的に合致すると、そのスキルが自動的に適用されます。

~/.claude/skills/
├── card/
│   ├── SKILL.md
│   ├── workflows/
│   │   ├── generate.md
│   │   ├── validate.md
│   │   └── improve.md
│   ├── references/
│   │   └── schema.yml
│   └── scripts/
│       └── validate.py

これはAtomic Design メソドロジー（アトム、分子、オーガニズム）に従っています。各スキルは、1つのことにだけ精通したエキスパートです。カードが必要になれば、カードのスキルが自動的に起動します。

各スキルは次のことを理解しています。

コンポーネントのスキーマ（props、slots、variants）
あなたのデザインシステムの規約
フレームワーク固有のパターン
WCAG のアクセシビリティ要件
参照できる関連スキル

レベル3：コマンド

コマンドはユーザーが起動するショートカットです。/commandと入力することで呼び出します。スキルのワークフロー内、もしくはグローバルに配置されます。

Slash commands workflow graphic with six colorful boxes.

~/.claude/skills/card/workflows/
├── generate.md    # /generate card
├── validate.md    # /validate card
├── improve.md     # /improve card
├── document.md    # /document card
├── test.md        # /test card
└── a11y.md        # /a11y card

コマンドは、まず計画のためにサブエージェントを呼び出し、その後の実行はメインの Claude が担当する、といったこともできます。これによって、ツールへの完全なアクセスを備えた、構造化されたワークフローが実現します。

完全な例：カードスキル

実際のスキルを使って、これがどのように機能するかを具体的に見ていきます。

Code snippet with highlighted components and card design preview.

スキルの構造

~/.claude/skills/card/
├── SKILL.md           # Core prompt and instructions
├── workflows/         # Slash commands
│   ├── generate.md
│   ├── validate.md
│   ├── improve.md
│   ├── document.md
│   ├── test.md
│   └── a11y.md
├── references/        # Documentation loaded into context
│   └── schema.yml
└── scripts/           # Executable Python/Bash scripts
    └── validate.py

SKILL.md ファイル

---
name: card
description: Generate and validate card components 
  for any design system with accessibility checks
---  # Card Skill  When user requests card components, this skill 
auto-triggers based on context.
 ## Schema  props:
  title: string
  body: string
  image: { src, alt, width }
  variant: default | horizontal | overlay
 slots:
  header: Custom header content
  footer: Buttons, links
 ## Related Skills  This skill can reference:
- image
- heading
- button
- link
- text

スラッシュコマンドの使い方

新しいカードを生成：

/generate card \   --variant="default" \   --title="Welcome" \   --with-image=true \   --with-button=true

既存のカードを検証：

/validate card \   --file="components/card.jsx"

アクセシビリティ準拠をチェック：

/a11y card --level="AA"

特定のコンテキスト向けにUXを改善：

/improve card \   --context="e-commerce product listing" \   --focus="conversion"

水面下で起きていること

/generate cardを実行すると、Claude は次のように動きます。

カードスキルをトリガー： SKILL.md をコンテキストに読み込む
スキーマを読む： 渡されたパラメータが許可された props に合致しているか検証する
他のスキルを参照： image、heading、button などのスキルから専門知識を取り込む
ワークフローを実行： workflows/generate.md を実行する
自己検証： 自身の出力に対して validate ワークフローを走らせる
結果を返す： コンポーネントと、必要に応じて警告を返す

カードスキルは単にマークアップを生成するだけではありません。複数の専門家（スキル）がそれぞれのドメイン知識を持ち寄るような、オーケストレーションを行っています。

なぜ重要か：ビルダーからシステム思考へ

テレプロンプターモデルでは、あなたは常にオペレーターのままです。スキルモデルでは、あなたはアーキテクトになります。

プロンプトを書くことからスキルを設計することへと発想を切り替えたとき、いくつかの変化が起きました。

コンテキストの繰り返しがなくなった。 各スキルはすでに自分の領域を理解しています。カードが必要なときに、毎回「カードとは何か」を説明する必要がなくなりました。

コンポジションで考えるようになった。 1ページは1つのプロンプトではありません。オーガニズムの調整であり、そのオーガニズムは分子の調整であり、その分子はアトムの調整です。各レイヤーが、それ専用のスキルを持ちます。

検証を委任できるようになった。 すべての出力を逐一目視確認する代わりに、/validate コマンドで構造をチェックし、/a11y コマンドでWCAG準拠を確認し、/test コマンドで自動テストを実行します。私はすべてではなく、例外だけをレビューします。

組織的な知識を構築できた。 スキルの SKILL.md を改善すれば、その改善は永続します。システムは、単発の会話中だけでなく、時間とともに賢くなっていきます。

これは、AIを「使う」ことと、AIと一緒に「構築する」ことの違いです。

デザインこそがコードである

デザインシステムに取り組む中で、私は1つの原則に行き着きました。デザインこそがコードである、ということです。

デザイントークン、コンポーネントスキーマ、エージェント設定が整合していれば、デザイナーが指定する内容と、デベロッパーが実装する内容との間に「翻訳レイヤー」は存在しません。仕様そのものが、すなわち実装なのです。

エージェントはこれを次のように現実のものにします。

# The schema IS the source of truth schema:   props:     variant:       type: string
      enum: [primary, secondary, success, danger, warning, info]       default: primary
    size:       type: string
      enum: [sm, md, lg]       default: md
 tokens:   colors:     - --btn-bg
    - --btn-color
    - --btn-border-color

このスキーマは単なるドキュメントではありません。唯一の正となるソースです。エージェントはここからコンポーネントを生成します。バリデーターはこれに照らしてチェックします。デザイントークンもこれを参照します。1つのファイルが、数多くの用途を担うのです。

デザイナーが Figma 上でトークン値を更新すると、エージェントの設定が更新されます。エージェントの設定が更新されると、生成されるコンポーネントも更新されます。デザインとコードが同じスキーマから導かれているからこそ、「デザインこそがコード」なのです。

Claude Code で“ビルドする”側に回るには

テレプロンプターモデルから抜け出したいなら、次のような実践的なステップがあります。

ステップ1：自分のドメインを特定する

あなたの仕事の中で、「反復的で、ルールベースで、コンテキスト依存な領域」はどこでしょうか。そこがスキル候補です。

コード生成
ドキュメンテーション
テスト
レビューとバリデーション
デザインシステム運用
デプロイとDevOps

ステップ2：最初のスキルを作る

シンプルな SKILL.md から始めましょう。

---
name: my-component
description: Generate and validate my-component
---  # My Component Skill  When user asks about my-component, apply these rules...

ステップ3：ワークフロー（コマンド）を追加する

workflows/ に6つのコアコマンドを作ります。

Command	Purpose
`/generate`	新しい成果物を作成する
`/validate`	既存の成果物をチェックする
`/improve`	改善案を提案する
`/document`	説明と記録を行う
`/test`	自動テストを作成する
`/a11y`	WCAG準拠を確認する

各コマンドは、指示を書いたMarkdownファイルです。

ステップ4：スキル間の参照関係を定義する

スキル同士は参照し合うことができます。

## Related Skills  This skill uses:
- image (for card images)
- button (for CTAs)
- heading (for titles)

こうした依存関係をマッピングしましょう。階層構造は、あなたのドメインの自然な構造に対応しているべきです。

ステップ5：複雑なタスクにはサブエージェントを作る

コンテキストを分離したい、あるいは並列実行したい場合は、~/.claude/agents/ にサブエージェントファイルを作成します。

---
name: header-builder
description: Build complete header components with navigation, logo, and search
tools: Read, Write, Bash, Glob, Grep
---  You are a header component specialist. When building headers:
1. Check existing header patterns in the codebase
2. Use the nav, button, logo skills for sub-components
3. Ensure responsive design and accessibility

スキルライブラリを構築する

スキルは Atomic Design に従って構造化します。

Type	Role	Examples
Atoms	基本的なビルディングブロック	button, input, checkbox, avatar, badge, icon, link, image
Molecules	アトムの組み合わせ	card, modal, tabs, accordion, alert, dropdown, toast
Organisms	複雑なコンポーネント	header, footer, dashboard, login-form, hero, sidebar

各スキルは次のものを備えます。

自前の SKILL.md 設定
スラッシュコマンドを置く workflows/
ドキュメント類を置く references/
自動化のための scripts/
参照している他スキルの一覧

これにより、Claude はコンテキストに応じて適切なスキルを自動トリガーできる、一貫性とスケーラビリティを備えたシステムが構築されます。

未来はエージェントが担う

Atomic Design の提唱者である Brad Frost は、すでにこの変化について語っています。デザインシステムは機械が読めるインフラにならなければならない、と。なぜなら、AIエージェントがいまや、人間のチームと同じコンポーネントを使ってUIを組み上げ始めているからです。

これは「2030年の予測」ではありません。すでに起きていることです。

あなたのデザインシステムがエージェントにとってパース不能であるなら、それはレガシー化しつつあります。開発フローのあらゆるステップに人間のプロンプトが必要なら、そのワークフローはスケールしません。AIとのやり取りが毎回ゼロから始まるなら、蓄積されてきた知識を無駄にしていることになります。

AI が単なる物珍しさだった時代には、テレプロンプターモデルでもよかったかもしれません。しかし、AI がインフラになった今、それでは不十分です。

プロンプトを書くのをやめて、設計を始めましょう。

エージェントを作り、スキルを与え、彼らに連携させるのです。

スクリプトを書く人ではなく、システムを設計する人にこそ、未来は開かれています。

ウェブ開発の未来に向けて、エージェント駆動のデザインシステムを構築する。

さらなる読み物

The Design Is the Code デザインシステムにおけるセル・オートマトン的思考の探求
Atomic Design by Brad Frost コンポーネント階層の背後にあるメソドロジー
Designing Systems That Build Themselves ビルダーからシステム思考者への転換