Anthropic Agent Skillsを活用して自分だけの再利用可能なワークフローを作る方法 参考: anthropics/skillsリポジトリ · Agent Skills標準


1. Skillとは何か?

Skillは、Claudeが特定の作業を再利用可能な方式でより上手く実行できるように教える指示・スクリプト・リソースが入ったフォルダです。Claudeは作業状況に応じてSkillを動的にロードします。

一言でまとめると、よく使う機能をまとめたコレクションを作ったものです。

核心的なアイデアは単純です。

  • プロンプトを毎回書き直さない。 よく練られたワークフローを1つのフォルダに収めておけば、Claudeは関連する作業に出会うたびにその指示に従う。
  • 段階的ローディング(Progressive Disclosure)。 Skillの名前と説明(description)だけが常にコンテキストに常駐し、本文とバンドルされたリソースは必要な時だけロードされる。コンテキストを節約しながらも深い専門性を持たせられる。
  • LLMはエクセルであってオラクル(神託)ではない。 Skillはこの原則の実務的な実装である — モデルに「うまくやって」を期待する代わりに、検証済みの手順とチェックリストを明示的に注入する。

2. リポジトリ構造

anthropics/skillsリポジトリの構成

ディレクトリ 説明
./skills 実際のSkill例(Creative & Design、Development & Technical、Enterprise & Communication、Document Skills)
./spec Agent Skills標準の仕様
./template 新しいSkillを作成する際に使うテンプレート

特にskills/docxskills/pdfskills/pptxskills/xlsxは、Claudeの実際の文書生成機能を動かしているプロダクションSkillであり、複雑なSkillを設計する際の良い参考資料になります(ソース公開、オープンソースではない)。


3. Skillの解剖学

skill-name/
├── SKILL.md            (必須)
│   ├── YAMLフロントマター  (name, descriptionが必須)
│   └── Markdown指示
└── バンドルリソース          (任意)
    ├── scripts/        - 決定的/繰り返し作業用の実行コード
    ├── references/     - 必要な時だけコンテキストにロードされるドキュメント
    └── assets/         - 出力に使用されるファイル(テンプレート、アイコン、フォント)

フロントマターの必須項目

項目 説明
name 一意の識別子(小文字、スペースはハイフンに)
description トリガーメカニズムの核心。 何をするか + いつ使うべきかの両方をここに記す

設計原則

  1. descriptionはやや「積極的に」 — Claudeは Skillをあまり使わない(undertrigger)傾向があるため、「ユーザーがX、Y、Zに言及したら明示的に要求されなくてもこのSkillを使え」のようにトリガー条件を具体的に列挙する。
  2. SKILL.mdの本文は500行以下 — 超える場合はreferences/に階層を分離し、いつ読むべきかを明確に案内する。
  3. 決定的な作業はスクリプトで — 計算、パース、API呼び出しのように毎回同じ結果になるべき作業は、LLMの自由生成に任せずscripts/にコードとして固定する。
  4. ドメインが複数ある場合はvariantごとに分離 — 例: references/krx.mdreferences/us-market.mdのように市場別の参照ファイルを分けると、Claudeは必要なものだけを読む。

4. 使用方法

Claude Code

/plugin marketplace add anthropics/skills
/plugin install example-skills@anthropic-agent-skills

インストール後は自然言語で言及するだけです:

「クオンツ市況スキルで今日の相場を要約して」

個人用Skillは~/.claude/skills/にフォルダごと入れればよいです。

Claude.ai (Web/アプリ)

有料プランではSettings → CapabilitiesからSkillのアップロードが可能です。.skillパッケージまたはSKILL.mdが入ったzipをアップロードすればよいです。(公式ガイド)

Claude API

事前構築されたSkillの使用、またはカスタムSkillのアップロードが可能です。(Skills API Quickstart)


5. 例①: クオンツ視点のデイリー市況サマリースキル

毎朝「今日の市況を要約して」の一言で、単なるニュースの列挙ではなくファクター・需給・ボラティリティの観点から構造化されたブリーフィングを受け取るスキルです。

フォルダ構造

quant-market-brief/
├── SKILL.md
└── references/
    ├── factor-checklist.md    # チェックすべきファクターのリストと解釈基準
    └── output-template.md     # ブリーフィング出力テンプレート

SKILL.md

---
name: quant-market-brief
description: >
  今日の株式市況をクオンツの観点から要約するスキル。ユーザーが「市況」、「今日の相場」、
  「マーケットブリーフィング」、「相場まとめ」、「今日のKOSPI/ナスダックどう」などに言及したら、
  明示的に「クオンツ」という単語がなくても必ずこのスキルを使うこと。
  単純なニュースの列挙ではなく、ファクター・ボラティリティ・需給フレームで構造化されたブリーフィングを生成する。
---

# Quant Market Brief

## 目的
個別ニュースではなく市場構造(レジーム)を読む。「何が起きたか」ではなく
「ファクター・ボラティリティ・需給の観点で市場がどのレジームにあり、何が変わったか」に答える。

## ワークフロー

### ステップ1: データ収集(Web検索必須)
以下を必ず検索で確認する。学習データの記憶で答えない:
- 主要指数の終値/変動率: KOSPI、KOSDAQ、S&P 500、NASDAQ、フィラデルフィア半導体
- ボラティリティ: VIXレベルと前日比の変化、VKOSPI
- 金利/為替: 米国10年債、ウォン/ドル、ドルインデックス(DXY)
- 需給: 外国人/機関投資家の純買越(KRX)、主要セクターETFの資金フロー
- 暗号資産(任意): BTC、キムチプレミアム — リスク選好度プロキシとしてのみ使用

### ステップ2: ファクターレンズの適用
references/factor-checklist.mdを読み、以下を判定する:
- モメンタム vs リバーサル: 最近の主導株が続くか、失速するか
- グロース vs バリュー: 金利方向とスタイルローテーションの整合性
- 大型 vs 小型: リスク選好度の拡散の有無
- クオリティ/低ボラ: 防御ファクターへの資金移動の有無

### ステップ3: レジーム判定
以下のいずれかに明示的に分類し、根拠を1行で付ける:
Risk-On / Risk-Off / Rotation(ローテーション) / Chop(方向感なし)

### ステップ4: 出力
references/output-template.mdのテンプレートに従う。必ず含める内容:
1. 一言レジーム判定(最上部)
2. 数値テーブル(指数/ボラティリティ/金利/為替/需給)
3. ファクタースコアカード(各ファクター: 強気/中立/弱気 + 根拠1行)
4. 「昨日と変わったこと」セクション — デルタに焦点
5. 反証条件 — 今日の判定が間違っていた場合、何が観測されるか

## ガイドライン
- 予測しない。観測された事実 → ファクター解釈 → 条件付きシナリオの順序を守る。
- すべての数値に出典と基準時刻を明記する。
- 確信度を上/中/下で表記する。データが矛盾する場合は「矛盾」と書く。
- 投資勧誘の表現(「買え/売れ」)を使わない。判断材料のみを提供する。

references/factor-checklist.md (抜粋)

# ファクターチェックリスト

## モメンタム
- 信号: 直近1ヶ月の上位リターンセクターが当日も相対的に強いか
- 強気判定: 主導セクターの相対リターン > 市場 && 出来高維持
- 崩壊信号: 主導株の急落 + 出来高急増(分散売り)

## ボラティリティレジーム
- VIX < 15: 低ボラティリティ(キャリー/モメンタムに有利)
- VIX 15–25: 中立
- VIX > 25: 高ボラティリティ(低ボラ/クオリティ、ポジション縮小検討区間)
- 注意: VIXの「レベル」より「変化率」が短期信号として有効

6. 例②: ポートフォリオデイリーモニタリング & 評価スキル

自分のポートフォリオを登録しておき、1日1回変動が発生した際にクオンツの観点+市場ニュース+SNSセンチメントを総合して「投資判断に反映できる形」で評価するスキルです。

核心的な設計ポイント:

  • ポートフォリオはassets/portfolio.jsonに状態として保存 — 毎回入力し直さない
  • 変動トリガールールをコード/仕様として固定 — 「変動があった」の定義をLLMの裁量に任せない
  • 3つの情報源(クオンツ/ニュース/SNS)を分離収集後に相互検証 — 1つのソースが結論を支配しないようにする(マルチソース委員会方式)

フォルダ構造

portfolio-daily-review/
├── SKILL.md
├── assets/
│   └── portfolio.json         # 保有銘柄・数量・平均取得単価・リスク限度
├── references/
│   ├── trigger-rules.md       # 「変動」の定量的定義
│   ├── sentiment-guide.md     # SNSセンチメント解釈時の注意事項
│   └── action-framework.md    # 評価 → アクション候補のマッピング基準
└── scripts/
    └── check_triggers.py      # 価格変動/限度違反判定スクリプト(任意)

assets/portfolio.json

{
  "base_currency": "KRW",
  "last_review": "2026-07-04",
  "risk_limits": {
    "single_position_max_pct": 20,
    "daily_drawdown_alert_pct": -3.0,
    "portfolio_drawdown_alert_pct": -5.0
  },
  "positions": [
    { "ticker": "005930.KS", "name": "삼성전자", "qty": 100, "avg_price": 72000, "thesis": "HBMサイクル" },
    { "ticker": "NVDA",      "name": "엔비디아", "qty": 10,  "avg_price": 118.5, "thesis": "AIインフラcapex" },
    { "ticker": "BTC",       "name": "비트코인", "qty": 0.5, "avg_price": 61000000, "thesis": "マクロヘッジ" }
  ]
}

SKILL.md

---
name: portfolio-daily-review
description: >
  ユーザーの投資ポートフォリオを1日1回チェックし、事前定義された変動トリガーが
  作動した場合にクオンツ分析・市場ニュース・SNSセンチメントを総合して投資判断材料を生成する
  スキル。ユーザーが「ポートフォリオチェック」、「自分のアカウント」、「今日のレビュー」、「保有銘柄どう」、
  「リバランス」などに言及したり、デイリーチェックを要求したら必ずこのスキルを使うこと。
  ポートフォリオの状態はassets/portfolio.jsonから読み込む。
---

# Portfolio Daily Review

## 目的
感情ではなくルールでポートフォリオをチェックする。トリガー未発動なら「異常なし」
の一言で終わり、発動時のみ3ソース総合評価を行う。

## ワークフロー

### ステップ0: 状態のロード
assets/portfolio.jsonを読む。last_reviewが今日なら
「今日のレビューは既に完了済み」と伝え、再実行するか確認する(1日1回の原則)。

### ステップ1: 相場の更新とトリガー判定
各ポジションの現在価格をWeb検索で確認し、references/trigger-rules.mdの
ルールで判定する。要約:
- 個別銘柄の日次変動 ±3%以上
- ポートフォリオ全体の評価額の日次変動 ±2%以上
- risk_limits違反(単一銘柄比重超過、損失限度到達)
- 保有銘柄関連の重大ニュース(業績、規制、ハッキング/セキュリティ事故、上場廃止関連)

トリガー未発動時: 現在価格テーブル + 「トリガーなし、アクション不要」で終了。
不必要な分析を生成しない。

### ステップ2: 3ソース収集(トリガー発動銘柄のみ)
各ソースを独立して収集し、互いに混在させない:

[A] クオンツの観点
- 該当銘柄のファクター状態: モメンタム(1M/3M)、セクター相対強度、ボラティリティ変化
- 市場レジームとの整合性(quant-market-briefスキルがあればその結果を再利用)

[B] 市場ニュース
- Web検索でトリガー原因のニュースを特定する。一次情報源(開示、業績発表、
  規制機関発表)を優先する。推測性の記事とファクトを区別して表記する。

[C] SNSセンチメント
- X(旧Twitter)、Reddit、国内コミュニティの反応の方向性と強度をWeb検索で把握。
- references/sentiment-guide.mdを必ず先に読む。核心:
  SNSは逆指標になりうる。極端な偏り(恐怖/興奮)はそれ自体が信号であり、
  方向性の信号としてそのまま使わない。

### ステップ3: 相互検証と総合評価
3つのソースの方向性が一致するかをマトリクスで整理する:

| ソース | 方向 | 強度 | 核心根拠 |
|---|---|---|---|
| クオンツ | ネガティブ | 中 | モメンタム失速 + セクター相対弱さ |
| ニュース | ネガティブ | 強 | 業績ガイダンス下方修正(一次情報源) |
| SNS  | 極端な恐怖 | 強 | 逆指標の可能性を表記 |

- 3つ一致 → 信頼度高い
- 2:1に分裂 → 少数意見の根拠を必ず本文に残す
- ニュース(ファクト)とクオンツ(価格アクション)が衝突する場合、その事実自体を強調する

### ステップ4: アクション候補の提示
references/action-framework.mdの基準で以下の形式を守る:
- アクション候補: 維持 / 比重縮小 / 比重拡大 / 損切り検討 / 追加観察のうち1~2つ選択
- 各候補の根拠と反対論拠の両方を明示
- 反証条件: 「Xが観測されればこの評価は無効」を必ず含める
- 最終決定はユーザーの判断であることを明示する。買い/売りの指示語は使わない。

### ステップ5: 状態の更新
portfolio.jsonのlast_reviewを今日の日付に更新し、
レビューの要約をログとして残す(次回レビュー時の「昨日とのデルタ」計算に使用)。

## ガイドライン
- トリガーがなければ沈黙する。毎日長文の分析を吐き出すのはノイズである。
- 3つのソースの重み付けを任意に決めない。不一致は不一致として報告する。
- SNSを引用する際は個別アカウントを特定せず、集計された方向性/強度のみを扱う。
- すべての数値に照会時刻を明記する。

references/trigger-rules.md (抜粋)

# 変動トリガー定義

「変動があった」とは、以下の定量条件のうち1つ以上を満たすことを意味する。
LLMの主観的判断(「かなり下がった気がする」)をトリガーとして使わない。

| トリガー | 条件 | 優先度 |
|---|---|---|
| T1 個別急変動 | 銘柄の日次変動 |±3%| 以上 | 中 |
| T2 ポートフォリオ変動 | 全体評価額の日次変動 |±2%| 以上 | 高 |
| T3 リスク限度 | risk_limits項目違反 | 最高 |
| T4 イベント | 業績/規制/セキュリティ事故/上場廃止関連の一次情報源ニュース | 高 |
| T5 ボラティリティジャンプ | 銘柄のインプライド/ヒストリカルボラティリティが前日比+50% | 中 |

複数トリガーが同時に発動した場合、優先度の高いものから報告する。

実行例 (Claude Code)

> 今日のポートフォリオをレビューして

[portfolio-daily-review スキル発動]
1. portfolio.jsonロード → 3ポジション
2. 相場検索 → NVDA -4.2%(T1発動)、残りはトリガーなし
3. NVDAについてクオンツ/ニュース/SNSの3ソース収集
4. 相互検証マトリクス + アクション候補 + 反証条件を出力
5. last_review更新

7. 2つのスキルを連携する

2つのスキルは独立して動作しますが、一緒にインストールするとシナジーが生まれます:

朝のルーティン:
1. quant-market-brief  → 市場レジーム判定 (Risk-On / Off / Rotation / Chop)
2. portfolio-daily-review → そのレジームをコンテキストとして個別ポジションを評価
   (SKILL.mdステップ2 [A]で「quant-market-brief結果を再利用」と明示)

こうしたスキル間の参照が、Skillsシステムの実践的な活用パターンです — 各スキルは小さく単一責任を持ちながら、ワークフローレベルで組み合わされます。


8. 作成時によくある間違い

間違い 修正
descriptionに機能だけ書いてトリガー条件を書かない 「ユーザーがX、Yに言及したら使うこと」を明示する(undertrigger防止)
判断基準をLLMの裁量に任せる 定量ルールをreferences/に固定する(例: トリガー定義)
毎回ポートフォリオを対話形式で入力 assets/に状態ファイルとして保存する
SKILL.md1つにすべてを詰め込む 500行を超えたらreferences/に分離し、読むタイミングを案内する
予測/売買指示の出力 観測 → 解釈 → 条件付きシナリオ + 反証条件の構造を強制する
テストせずに配布 実際のプロンプト3~5個で発動有無と出力品質を検証する

9. 関連リンク

注意: リポジトリのSkillsはデモ/教育目的です。実際のClaudeの動作と異なる場合があるため、重要な作業の前には必ず自分の環境でテストしてください。本ガイドの投資関連スキルは判断材料を構造化するツールであり、投資アドバイスではありません。