はじめに
「AIに株を売買させたら儲かるのか？」
シンプルな疑問から始めて、Claude APIを使った自律型トレーディングエージェント Hermes Agent を個人開発し、実際にVPS上で24時間稼働させています。
この記事は5回シリーズの第1回です。今回はプロジェクトの全体像と設計思想を紹介します。
このシリーズで作るもの
- 株・暗号資産・FX を対象にした自動売買システム
- TypeScript（Node.js） で書かれたエージェント本体
- Claude API（claude-opus-4系） が最終的な売買判断を下す
- Alpaca（株・暗号資産）と OANDA（FX）に実際に注文を入れる
- Streamlit ダッシュボードでリアルタイム監視
- Discord にトレード通知が届く
なぜ作ったのか
既成のアルゴリズムトレードツールは多いですが、「ルールが固定されている」という根本的な限界があります。RSIが30以下になったら買う、など。市場は常に変化するので、単純なルールはすぐに陳腐化します。
一方でClaude（Anthropic社のLLM）は、チャートのコンテキストや過去のトレード記録を読んで「なぜその形は買いなのか」を自然言語で判断できます。
ルールエンジン（高速・安価）× LLM（文脈判断・高精度） の2段構成にすれば、両方の良いところを取れるのでは？というのがアイデアの出発点です。
システム全体像
毎サイクル（デフォルト5分）
│
├─ Stage 1: ルールエンジン（TypeScript、無料）
│ └─ 過去100本のローソク足 → SMA/RSI/ATR → BUY/SELL/HOLD
│ シグナルが変化した（HOLD→BUY など）ときだけ Stage 2 へ
│
└─ Stage 2: Claude判断（APIコール、有料）
└─ チャート文脈・直近ローソク足・過去トレード記録を渡す
→ EXECUTE（注文） または WAIT（様子見）
↓
EXECUTE → Alpaca/OANDA に注文を入れる
WAIT → ファントムトレード記録（仮想トレース）
ポイントは 「Claudeをシグナル変化時だけ呼ぶ」 こと。BUY→BUY（変化なし）はゼロコスト。これで月のAPIコストを現実的な範囲に抑えられます。
アーキテクチャ
auto-trade/
├── src/
│ ├── agent/ # Hermes Agent本体（Claude API + MCP Client）
│ │ ├── hermes.ts # メインエージェント（2ステージパイプライン）
│ │ ├── strategy/ # 7種類のルールエンジン
│ │ ├── memory.ts # トレード記録・勝率追跡
│ │ └── discord.ts # Discord通知
│ └── mcp/ # MCP Server（Alpaca/OANDA API）
│ └── tools/ # 価格取得・注文・口座情報
├── python/
│ ├── dashboard/ # Streamlitダッシュボード
│ └── backtest/ # バックテスト・パラメータ最適化
└── data/
└── strategy-params.json # シンボルごとの戦略設定
MCP（Model Context Protocol）を使う理由
Alpaca や OANDA との通信は MCP Server として独立したプロセスで動かしています。
- エージェントとブローカーAPIを疎結合にする
-
get_historical_bars・place_order・get_account_infoなどをツールとして定義することで、将来別のエージェントからも使える
実装は @modelcontextprotocol/sdk を使っています。
対応アセットと注文方式
| アセット | ブローカー | 注文方式 | セッション |
|---|---|---|---|
| 株（AAPL, NVDA, META…） | Alpaca | ブラケット注文（SL/TP同時設定） | 平日 9:30–16:00 ET |
| 暗号資産（BTC/USD…） | Alpaca | 成行注文（SL/TPはソフトウェア管理） | 24/7 |
| FX（USD_JPY, EUR_USD…） | OANDA | 成行+ネイティブSL/TP | 平日24h |
シンボルの形式（/含む→暗号資産、_含む→FX、それ以外→株）でルーティングを自動判定しています。
7種類のルールエンジン
Stage 1 のルールエンジンは銘柄ごとにバックテストで最適なものを選んでいます。
| エンジン | 特徴 |
|---|---|
structural |
SMAクロス + RSIでエントリー、スウィングSL |
trend |
structural と同じ条件だが SL = ATR×2（強トレンド向き） |
rebound |
ボリンジャーバンド端 + RSI極値でのリバウンド |
breakout |
N本高値/安値ブレイクアウト |
pullback |
トレンド方向への押し目買い/戻り売り |
range_breakout |
ボラティリティ圧縮後のブレイク |
momentum_reversal |
RSI+BB極値でのカウンタートレンド |
例えば META は「structural（SMA20/50）」と「structural（SMA50/100）」の2エンジンを並走させ、どちらかがシグナルを出したときに Claude が判断します。
ファントムトレード（WAIT回顧）
Claudeが WAIT（見送り）を選んだとき、仮想的にエントリーしたとして記録します。その後 SL/TP に達したら WIN/LOSS を判定。
これにより：
- 「Claudeが見送ったトレードは本当に危なかったのか」を定量評価
- キャリブレーションデータとして次の判断に活かす（「最近 WAIT しすぎている」警告）
実際のDiscord通知：
👻 Phantom recorded — META SHORT
Entry: 608.51 | SL: 609.375 | TP: 606.78 | R:R 1:2.0
"Structural engine fired SELL on RSI 64 overbought, but the last bar
is a strong bullish marubozu..."
✅ Phantom WIN — META SHORT
Entry: 608.51 → Exit: 606.78 | P&L: +0.28%
WAITが多いときは「見逃しコスト」が見えるので、Claudeの過剰保守を検知できます。
技術スタック
| レイヤー | 技術 |
|---|---|
| エージェント・MCP | Node.js 20 / TypeScript 5 |
| LLM | Claude API（@anthropic-ai/sdk） |
| ブローカー | Alpaca Markets / OANDA REST |
| バックテスト・UI | Python 3.12 / Streamlit / Plotly |
| 通知 | Discord Webhook |
| 常駐・cron | PM2（VPS上） |
次回予告
次回（第2回）は 2ステージパイプラインの技術詳解 です。
- Stage 1 のシグナル生成ロジック（RSI/SMA/BB計算）
- Stage 2 の Claude へ渡すコンテキストの設計
-
lastActionによるシグナル変化検出の仕組み - 実際に発生したバグ（同じシグナルが毎5分 Claude を呼び続けた問題）とその修正
シリーズ一覧
- 第1回（本記事）: 全体像・設計思想
- 第2回: 2ステージパイプライン技術詳解
- 第3回: バックテスト & パラメータ最適化
- 第4回: リスク管理の実装
- 第5回: 本番運用 & バグ修正の実録