Categories と Skills：動的エージェント構成（v3.0）

学ぶと何ができるようになりますか

✅ 7 つの組み込み Categories を使用して、異なるタイプのタスクに最適なモデルを自動的に選択できるようになります
✅ 4 つの組み込み Skills を読み込んで、エージェントに専門知識と MCP ツールを注入できるようになります
✅ delegate_task を通じて Category と Skill を組み合わせ、専門化されたサブエージェントを作成できるようになります
✅ カスタム Category と Skill を作成し、特定のプロジェクト要件に対応できるようになります

現在の課題

エージェントが専門的でない？コストが高すぎる？

次のシナリオを考えてみてください：

問題	従来の方法	実際のニーズ
UI タスクに超強力なモデルを使用	Claude Opus で単純なスタイル調整を処理	コストが高く、計算リソースを浪費
複雑なロジックに軽量モデルを使用	Haiku でアーキテクチャ設計を処理	推論能力が不足し、ソリューションが誤り
Git コミットスタイルが統一されていない	手動で commit を管理し、エラーが発生しやすい	自動検出とプロジェクトルールへの準拠が必要
ブラウザテストが必要	手動でブラウザを開いて検証	Playwright MCP ツールのサポートが必要

核となる問題：

すべてのタスクを 1 つのエージェントで処理 → モデルとツールがマッチしない
ハードコードされた 10 個の固定エージェント → 柔軟な組み合わせができない
専門スキルの欠如 → エージェントが特定のドメイン知識を持たない

解決策：v3.0 の Categories と Skills システムは、ブロックのようにエージェントを組み合わせることができます：

Category（モデル抽象）：タスクタイプを定義 → 最適なモデルを自動的に選択
Skill（専門知識）：ドメイン知識と MCP ツールを注入 → エージェントをより専門的に

いつこの手法を使用するか

シナリオ	推奨される組み合わせ	効果
UI デザインと実装	`category="visual-engineering"` + `skills=["frontend-ui-ux", "playwright"]`	Gemini 3 Pro を自動的に選択 + デザイナーマインドセット + ブラウザ検証
迅速な修正とコミット	`category="quick"` + `skills=["git-master"]`	Haiku で低コスト実装 + 自動コミットスタイル検出
深いアーキテクチャ分析	`category="ultrabrain"` + `skills=[]`	GPT-5.2 Codex (xhigh) で純粋推論
ドキュメント作成	`category="writing"` + `skills=[]`	Gemini 3 Flash でドキュメントを迅速生成

🎒 開始前の準備

前提条件

このチュートリアルを始める前に、以下を確認してください：

oh-my-opencode がインストールされている（インストールチュートリアルを参照）
少なくとも 1 つの Provider が設定されている（Provider 設定を参照）
基本的な delegate_task ツールの使用方法を理解している（バックグラウンド並列タスクを参照）

重要な概念

Category は「これはどのようなタイプの仕事か」（モデル、温度、思考モードを決定）、Skill は「どのような専門知識とツールが必要か」（プロンプトと MCP サーバーを注入）を表します。delegate_task(category=..., skills=[...]) を通じて両者を組み合わせます。

コアな考え方

Categories：タスクタイプがモデルを決定

oh-my-opencode は 7 つの組み込み Categories を提供し、各カテゴリは最適なモデルと思考モードを事前設定しています：

Category	デフォルトモデル	Temperature	用途
`visual-engineering`	`google/gemini-3-pro`	0.7	フロントエンド、UI/UX、デザインタスク
`ultrabrain`	`openai/gpt-5.2-codex` (xhigh)	0.1	高度な推論タスク（複雑なアーキテクチャ意思決定）
`artistry`	`google/gemini-3-pro` (max)	0.7	創造的・芸術的タスク（斬新なアイデア）
`quick`	`anthropic/claude-haiku-4-5`	0.1	高速・低コストタスク（単一ファイルの変更）
`unspecified-low`	`anthropic/claude-sonnet-4-5`	0.1	他のカテゴリに一致しない中程度のタスク
`unspecified-high`	`anthropic/claude-opus-4-5` (max)	0.1	他のカテゴリに一致しない高品質タスク
`writing`	`google/gemini-3-flash`	0.1	ドキュメントとライティングタスク

なぜ Categories が必要なのか？

異なるタスクには異なる能力を持つモデルが必要です：

UI デザイン → 視覚的創造力が必要（Gemini 3 Pro）
アーキテクチャ意思決定 → 深い推論が必要（GPT-5.2 Codex xhigh）
単純な変更 → 高速応答が必要（Claude Haiku）

タスクごとにモデルを手動で選択するのは面倒です。Categories を使用すると、タスクタイプを宣言するだけで、システムが最適なモデルを自動的に選択します。

Skills：専門知識の注入

Skill は SKILL.md ファイルで定義されるドメインエキスパートであり、次のものを注入できます：

専門知識（プロンプト拡張）
MCP サーバー（自動読み込み）
ワークフローガイド（具体的な操作手順）

組み込みの 4 つの Skills：

Skill	機能	MCP	用途
`playwright`	ブラウザ自動化	`@playwright/mcp`	UI 検証、スクリーンショット、スクレイピング
`agent-browser`	ブラウザ自動化（Vercel）	手動インストール	同上、代替案
`frontend-ui-ux`	デザイナーマインドセット	なし	美しい UI を構築
`git-master`	Git エキスパート	なし	自動コミット、履歴検索、rebase

Skill の動作原理：

Skill を読み込むと、システムは：

SKILL.md ファイルのプロンプト内容を読み込む
MCP が定義されている場合、対応するサーバーを自動的に起動
Skill プロンプトをエージェントのシステムプロンプトに追加

例えば、git-master Skill には以下が含まれています：

コミットスタイル検出（プロジェクトの commit フォーマットを自動認識）
アトミックコミットルール（3 ファイル → 最低 2 つのコミット）
Rebase ワークフロー（squash、fixup、競合処理）
履歴検索（blame、bisect、log -S）

Sisyphus Junior：タスク実行者

Category を使用すると、特別なサブエージェント——Sisyphus Junior が生成されます。

重要な特徴：

✅ Category のモデル設定を継承
✅ 読み込まれた Skills のプロンプトを継承
❌ 再委任できない（task と delegate_task ツールの使用は禁止）

なぜ再委任を禁止しているのか？

無限ループとタスクの発散を防ぐためです：

Sisyphus (メインエージェント)
  ↓ delegate_task(category="quick")
Sisyphus Junior
  ↓ delegate_task を試行（許可された場合）
Sisyphus Junior 2
  ↓ delegate_task
...無限ループ...

再委任を禁止することで、Sisyphus Junior は割り当てられたタスクの完了に集中し、目標の明確化と効率的な実行を確保します。

一緒にやってみましょう

ステップ 1：迅速な修正（Quick + Git Master）

実際のシナリオを使ってみましょう：いくつかのファイルを変更し、自動的にコミットしてプロジェクトスタイルに従う必要があります。

なぜquick Category の Haiku モデルはコストが低く、git-master Skill と組み合わせることで自動的にコミットスタイルを検出し、完璧なコミットを実現します。

OpenCode で次のように入力します：

delegate_task を使用して現在の変更をコミット
- category: quick
- load_skills: ["git-master"]
- prompt: "現在のすべての変更をコミットしてください。プロジェクトのコミットスタイルに従ってください（git log で検出）。アトミックコミットを確保し、1 つの commit は最大 3 ファイルまでです。"
- run_in_background: false

次のような結果が表示されます：

Sisyphus Junior が起動し、claude-haiku-4-5 モデルを使用
git-master Skill が読み込まれ、プロンプトに Git エキスパートの知識が含まれる

エージェントが以下の操作を実行：

bash

# 並列でコンテキストを収集
git status
git diff --stat
git log -30 --oneline

コミットスタイルを検出（Semantic vs Plain vs Short）
アトミックコミットを計画（3 ファイル → 最低 2 つのコミット）
検出されたスタイルに従ってコミットを実行

チェックポイント ✅：

コミットが成功したかを検証します：

bash

git log --oneline -5

複数のアトミックコミットが表示され、それぞれに明確なメッセージスタイルがあるはずです。

ステップ 2：UI 実装と検証（Visual + Playwright + UI/UX）

シナリオ：ページにレスポンシブなチャートコンポーネントを追加し、ブラウザで検証する必要があります。

なぜ

visual-engineering Category は Gemini 3 Pro を選択（視覚デザインに強み）
playwright Skill はブラウザテスト用の MCP ツールを提供
frontend-ui-ux Skill はデザイナーマインドセットを注入（配色、タイポグラフィ、アニメーション）

OpenCode で次のように入力します：

delegate_task を使用してチャートコンポーネントを実装
- category: visual-engineering
- load_skills: ["frontend-ui-ux", "playwright"]
- prompt: "dashboard ページにレスポンシブなチャートコンポーネントを追加してください。要件：
  - Tailwind CSS を使用
  - モバイルとデスクトップに対応
  - 鮮明な配色スキームを使用（紫のグラデーションを避ける）
  - スタガードアニメーション効果を追加
  - 完了後、playwright でスクリーンショットを撮って検証"
- run_in_background: false

次のような結果が表示されます：

Sisyphus Junior が起動し、google/gemini-3-pro モデルを使用
2 つの Skills のプロンプトを読み込み：
- frontend-ui-ux：デザイナーマインドセットガイド
- playwright：ブラウザ自動化指示
@playwright/mcp サーバーが自動的に起動
エージェントが実行：
- チャートコンポーネントを設計（デザイナーマインドセットを適用）
- レスポンシブレイアウトを実装
- アニメーション効果を追加
- Playwright ツールを使用：
```
playwright_navigate: http://localhost:3000/dashboard
playwright_take_screenshot: output=dashboard-chart.png
```

チェックポイント ✅：

コンポーネントが正しくレンダリングされているかを検証します：

bash

# 新しいファイルを確認
git diff --name-only
git diff --stat

# スクリーンショットを表示
ls screenshots/

次のような結果が表示されます：

新しいチャートコンポーネントファイル
レスポンシブスタイルコード
スクリーンショットファイル（検証成功）

ステップ 3：深いアーキテクチャ分析（Ultrabrain 純粋推論）

シナリオ：マイクロサービスアーキテクチャ用に複雑な通信パターンを設計する必要があります。

なぜ

ultrabrain Category は GPT-5.2 Codex (xhigh) を選択し、最強の推論能力を提供
Skills を読み込まない → 純粋推論、専門知識による干渉を回避

OpenCode で次のように入力します：

delegate_task を使用してアーキテクチャを分析
- category: ultrabrain
- load_skills: []
- prompt: "私たちのマイクロサービスアーキテクチャ用に効率的な通信パターンを設計してください。要件：
  - サービスディスカバリをサポート
  - ネットワークパーティションを処理
  - レイテンシを最小化
  - 代替戦略を提供

  現在のアーキテクチャ：[簡易説明]
  技術スタック：gRPC、Kubernetes、Consul"
- run_in_background: false

次のような結果が表示されます：

Sisyphus Junior が起動し、openai/gpt-5.2-codex モデルを使用（xhigh 変異）
Skills を読み込まない
エージェントが深い推論を実行：
- 既存のアーキテクチャを分析
- 通信パターンを比較（CQRS、Event Sourcing、Saga など）
- 利点と欠点を比較検討
- 階層的な提案を提供（Bottom Line → Action Plan → Risks）

出力構造：

Bottom Line: ハイブリッドモード（gRPC + Event Bus）の使用を推奨

Action Plan:
1. サービス間で gRPC を使用して同期通信を実装
2. 重要なイベントを Event Bus 経由で非同期に公開
3. メッセージ重複のべき等処理を実装

Risks and Mitigations:
- Risk: ネットワークパーティションによるメッセージ損失
  Mitigation: メッセージリトライとデッドレターキューを実装

チェックポイント ✅：

ソリューションが包括的かどうかを検証します：

サービスディスカバリを考慮していますか？
ネットワークパーティションを処理していますか？
代替戦略を提供していますか？

ステップ 4：カスタム Category（オプション）

組み込み Categories がニーズを満たさない場合、oh-my-opencode.json でカスタマイズできます。

なぜ一部のプロジェクトには特定のモデル設定（Korean Writer、Deep Reasoning など）が必要です。

~/.config/opencode/oh-my-opencode.json を編集します：

jsonc

{
  "categories": {
    "korean-writer": {
      "model": "google/gemini-3-flash",
      "temperature": 0.5,
      "prompt_append": "You are a Korean technical writer. Maintain a friendly and clear tone."
    },
    
    "deep-reasoning": {
      "model": "anthropic/claude-opus-4-5",
      "thinking": {
        "type": "enabled",
        "budgetTokens": 32000
      },
      "tools": {
        "websearch_web_search_exa": false
      }
    }
  }
}

フィールドの説明：

フィールド	タイプ	説明
`model`	string	Category で使用するモデルを上書き
`temperature`	number	創造性レベル（0-2）
`prompt_append`	string	システムプロンプトに追加する内容
`thinking`	object	Thinking 設定（`{ type, budgetTokens }`）
`tools`	object	ツール権限の無効化（`{ toolName: false }`）

チェックポイント ✅：

カスタム Category が有効かどうかを検証します：

bash

# カスタム Category を使用
delegate_task(category="korean-writer", load_skills=[], prompt="...")

システムが設定したモデルとプロンプトを使用していることが確認できます。

落とし穴の警告

落とし穴 1：Quick Category のプロンプトが不明確

問題：quick Category は Haiku モデルを使用し、推論能力が限られています。プロンプトが曖昧すぎると、結果が悪くなります。

悪い例：

delegate_task(category="quick", load_skills=["git-master"], prompt="変更をコミット")

良い方法：

TASK: 現在のすべてのコード変更をコミットしてください

MUST DO:
1. プロジェクトのコミットスタイルを検出（git log -30 を通じて）
2. 8 ファイルをディレクトリ別に 3 つ以上のアトミックコミットに分割
3. 各コミットは最大 3 ファイルまで
4. 検出されたスタイルに従う（Semantic/Plain/Short）

MUST NOT DO:
- 異なるディレクトリのファイルを同じコミットにマージ
- コミット計画をスキップして直接実行

EXPECTED OUTPUT:
- 複数のアトミックコミット
- 各コミットメッセージがプロジェクトスタイルに一致
- 依存順序に従う（タイプ定義 → 実装 → テスト）

落とし穴 2：`load_skills` の指定を忘れる

問題：load_skills は必須パラメータで、指定しないとエラーになります。

エラー：

delegate_task(category="quick", prompt="...")

エラー出力：

Error: Invalid arguments: 'load_skills' parameter is REQUIRED.
Pass [] if no skills needed, but IT IS HIGHLY RECOMMENDED to pass proper skills.

良い方法：

# Skill が不要な場合、空の配列を明示的に渡す
delegate_task(category="unspecified-low", load_skills=[], prompt="...")

落とし穴 3：Category と subagent_type を同時に指定

問題：これら 2 つのパラメータは排他的で、同時に指定できません。

エラー：

delegate_task(
  category="quick",
  subagent_type="oracle",  # ❌ 競合
  ...
)

良い方法：

# Category を使用（推奨）
delegate_task(category="quick", load_skills=[], prompt="...")

# またはエージェントを直接指定
delegate_task(subagent_type="oracle", load_skills=[], prompt="...")

落とし穴 4：Git Master のマルチコミットルール

問題：git-master Skill はマルチコミットを強制し、1 つのコミットで 3 ファイル以上は失敗します。

エラー：

# 1 つのコミットで 8 ファイルを試行
git commit -m "Update landing page"  # ❌ git-master が拒否

良い方法：

# ディレクトリ別に複数のコミットに分割
git add app/page.tsx app/layout.tsx
git commit -m "Add app layer"  # ✅ Commit 1

git add components/demo/*
git commit -m "Add demo components"  # ✅ Commit 2

git add e2e/*
git commit -m "Add tests"  # ✅ Commit 3

落とし穴 5：Playwright Skill の MCP が未インストール

問題：playwright Skill を使用する前に、MCP サーバーが利用可能であることを確認する必要があります。

エラー：

delegate_task(category="visual-engineering", load_skills=["playwright"], prompt="スクリーンショット...")

良い方法：

MCP 設定を確認します（~/.config/opencode/mcp.json または .claude/.mcp.json）：

jsonc

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}

Playwright MCP が設定されていない場合、playwright Skill は自動的に起動します。

このレッスンのまとめ

Categories と Skills システムは、エージェントを柔軟に組み合わせることができます：

コンポーネント	役割	設定方法
Category	モデルと思考モードを決定	`delegate_task(category="...")` または設定ファイル
Skill	専門知識と MCP を注入	`delegate_task(load_skills=["..."])` または SKILL.md ファイル
Sisyphus Junior	タスクを実行、再委任不可	自動生成、手動指定不要

組み合わせ戦略：

UI タスク：visual-engineering + frontend-ui-ux + playwright
迅速な修正：quick + git-master
深い推論：ultrabrain（Skill なし）
ドキュメント作成：writing（Skill なし）

ベストプラクティス：

✅ 常に load_skills を指定する（空の配列でも）
✅ quick Category のプロンプトは明確である必要がある（Haiku の推論能力は限られているため）
✅ Git タスクは常に git-master Skill を使用する（自動スタイル検出のため）
✅ UI タスクは常に playwright Skill を使用する（ブラウザ検証のため）
✅ タスクタイプに応じて適切な Category を選択する（デフォルトでメインエージェントを使用しない）

次のレッスンの予告

次のレッスンでは、組み込み Skills：ブラウザ自動化、Git エキスパート、UI デザイナー を学びます。
学べること：
playwright Skill の詳細なワークフロー
git-master Skill の 3 つのモード（Commit/Rebase/History Search）
frontend-ui-ux Skill のデザイン理念
カスタム Skill の作成方法

付録：ソースコード参照

クリックしてソースコードの場所を表示

更新日時：2026-01-26

機能	ファイルパス	行番号
delegate_task ツール実装	`src/tools/delegate-task/tools.ts`	全文（1070 行）
resolveCategoryConfig 関数	`src/tools/delegate-task/tools.ts`	113-152
buildSystemContent 関数	`src/tools/delegate-task/tools.ts`	176-188
デフォルト Categories 設定	`src/tools/delegate-task/constants.ts`	158-166
Categories プロンプト追加	`src/tools/delegate-task/constants.ts`	168-176
Categories 説明	`src/tools/delegate-task/constants.ts`	178-186
Category 設定 Schema	`src/config/schema.ts`	154-172
組み込み Skills 定義	`src/features/builtin-skills/`	ディレクトリ構造
git-master Skill プロンプト	`src/features/builtin-skills/git-master/SKILL.md`	全文（1106 行）

重要な定数：

SISYPHUS_JUNIOR_AGENT = "sisyphus-junior"：Category 委任の実行エージェント
DEFAULT_CATEGORIES：7 つの組み込み Category のモデル設定
CATEGORY_PROMPT_APPENDS：各 Category のプロンプト追加内容
CATEGORY_DESCRIPTIONS：各 Category の説明（delegate_task プロンプトに表示）

重要な関数：

resolveCategoryConfig()：Category 設定を解析し、ユーザーオーバーライドとデフォルト値をマージ
buildSystemContent()：Skill と Category のプロンプト内容をマージ
createDelegateTask()：delegate_task ツール定義を作成

組み込み Skills ファイル：

src/features/builtin-skills/frontend-ui-ux/SKILL.md：デザイナーマインドセットプロンプト
src/features/builtin-skills/git-master/SKILL.md：Git エキスパートの完全なワークフロー
src/features/builtin-skills/agent-browser/SKILL.md：Vercel agent-browser 設定
src/features/builtin-skills/dev-browser/SKILL.md：ブラウザ自動化リファレンスドキュメント

Categories と Skills：動的エージェント構成（v3.0） ​

学ぶと何ができるようになりますか ​

現在の課題 ​

いつこの手法を使用するか ​

🎒 開始前の準備 ​

コアな考え方 ​

Categories：タスクタイプがモデルを決定 ​

Skills：専門知識の注入 ​

Sisyphus Junior：タスク実行者 ​

一緒にやってみましょう ​

ステップ 1：迅速な修正（Quick + Git Master） ​

ステップ 2：UI 実装と検証（Visual + Playwright + UI/UX） ​

ステップ 3：深いアーキテクチャ分析（Ultrabrain 純粋推論） ​

ステップ 4：カスタム Category（オプション） ​

落とし穴の警告 ​

落とし穴 1：Quick Category のプロンプトが不明確 ​

落とし穴 2：load_skills の指定を忘れる ​

落とし穴 3：Category と subagent_type を同時に指定 ​

落とし穴 4：Git Master のマルチコミットルール ​

落とし穴 5：Playwright Skill の MCP が未インストール ​

このレッスンのまとめ ​

次のレッスンの予告 ​

付録：ソースコード参照 ​

Categories と Skills：動的エージェント構成（v3.0）

学ぶと何ができるようになりますか

現在の課題

いつこの手法を使用するか

🎒 開始前の準備

コアな考え方

Categories：タスクタイプがモデルを決定

Skills：専門知識の注入

Sisyphus Junior：タスク実行者

一緒にやってみましょう

ステップ 1：迅速な修正（Quick + Git Master）

ステップ 2：UI 実装と検証（Visual + Playwright + UI/UX）

ステップ 3：深いアーキテクチャ分析（Ultrabrain 純粋推論）

ステップ 4：カスタム Category（オプション）

落とし穴の警告

落とし穴 1：Quick Category のプロンプトが不明確

落とし穴 2：`load_skills` の指定を忘れる

落とし穴 3：Category と subagent_type を同時に指定

落とし穴 4：Git Master のマルチコミットルール

落とし穴 5：Playwright Skill の MCP が未インストール

このレッスンのまとめ

次のレッスンの予告

付録：ソースコード参照