Claude Code × n8n × autoclaw — 三位一体スタックの全体像と実装パターン

なぜ「3 つ」なのか

「Claude Code だけじゃダメなのか」と聞かれることがある。

ダメではない。でも、1 つのツールだけでは「自律的に動き続ける」システムにはならない。

Claude Code は賢い。でも Claude Code は「俺が呼んだ時しか動かない」。

n8n は自動化ができる。でも n8n だけでは複雑な AI 処理を安く回し続けることができない。

autoclaw は安く速い。でも autoclaw は「仕事を渡す仕組み」がなければタダの LLM プロキシだ。

3 つが組み合わさったときに初めて、「誰も操作しなくても AI が働き続ける」システムが成立する。

この記事では、この三位一体スタックのアーキテクチャを解説する。コード例・設定例・コスト感も全部出す。

各ツールの役割

Claude Code — 設計者・コード生成エンジン

Claude Code はセッションベースの AI コーディングアシスタントだ。俺は主に「WF の設計」と「コードの生成・デバッグ」に使っている。

ポイントは Claude Code は「作る側」に徹することだ。実行は n8n と autoclaw に任せる。

俺の使い方:

• n8n の WF JSON を設計させる
• Code ノードの JavaScript を書かせる
• エラーログを渡して原因を推測させる
• CLAUDE.md に n8n 環境の仕様を書いておき、毎回読み込ませる

Claude Code が最も力を発揮するのは「何をどう作るか」の設計フェーズだ。「作ったものを実行する」フェーズは他のツールが担う。

n8n — オーケストレーター

n8n はワークフロー実行エンジンだ。「いつ・何を・どこに」を定義する。

重要な特性:

• Cron・Webhook・イベントトリガー に対応。「毎朝 6 時に動かす」「Slack でメッセージを受け取ったら動かす」が GUI で設定できる
• HTTP Request ノード で任意の API を叩ける。autoclaw も Claude API も Supabase も全部ここ経由
• Code ノード で JavaScript が実行できる。複雑なデータ変換はここに書く
• Error Workflow が設定できる。エラーが出たら別の WF を起動してDLQ（デッドレターキュー）に入れられる

n8n がオーケストレーターである理由は「トリガー管理と再実行ロジックを一箇所に集約できる」からだ。

autoclaw — LLM プロキシ・コスト最適化レイヤー

autoclaw は俺が自前で構築している LLM プロキシサーバーだ。

外部からは POST http://autoclaw:3101/task にリクエストを投げるだけで LLM の応答が返ってくる。内部では ollama（ローカル LLM）と Claude API を切り替えて使っている。

なぜ Claude API に直接繋がないのか。コストが爆発するからだ。

WF が 55 本動くとき、1 日の LLM 呼び出し回数は軽く 200 〜 300 回を超える。全部 Claude Haiku を使っても月数千円かかる。

autoclaw が挟まることで:

• 単純なタスクは ollama（ゼロコスト） で処理
• 品質が必要なタスクだけ Claude API にルーティング
• レート制限・リトライ を一箇所で管理

という切り分けができる。

アーキテクチャ全体図（テキスト版）

[外部トリガー]
Cron / Webhook / Slack / GitHub Webhook
         |
         v
[n8n — オーケストレーター]
 ┌─────────────────────────────────────┐
 │  Trigger → 前処理 → HTTP Request    │
 │                    ↓               │
 │             [autoclaw API]          │
 │             ┌────────────┐         │
 │             │ ルーティング │         │
 │             ├────────────┤         │
 │             │ ollama     │ (単純)   │
 │             │ Claude API │ (高品質) │
 │             └────────────┘         │
 │                    ↓               │
 │             [LLM Response]          │
 │  後処理 → 出力先ノード              │
 └─────────────────────────────────────┘
         |
         v
[出力先]
Obsidian / Supabase / Slack / X / Vercel Deploy
         |
         v
[監視・フィードバック]
DLQ / AUTOAGENT-OPTIMIZER → Slack レポート

データは常に「トリガー → n8n → autoclaw → 出力先」の方向に流れる。逆方向（出力先から n8n への通知）はフック WF が担う。

実装例 1: ブログ記事の自動生成パイプライン

俺が毎日使っている記事生成の流れだ。

ステップ 1: トリガー（WF-AUTOCLAW-INGEST）

Schedule Trigger (毎朝 06:00 JST)
  → HTTP Request (RSS 取得: Hacker News / TechCrunch / Zenn)
  → Code ノード (記事リスト整形)
  → HTTP Request → autoclaw API

autoclaw へのリクエスト:

{
  "task": "summarize",
  "model_preference": "fast",
  "prompt": "以下のAI関連記事から、個人開発者・副業エンジニアに有益なものを3つ選んで1行要約してください。\n\n{{ $json.articles }}"
}

model_preference: "fast" が渡されると autoclaw は ollama（コストゼロ）にルーティングする。

ステップ 2: 記事構成生成（WF-AFFILIATE-CONTENT-GEN）

Slack に「今日の記事候補」が届く。番号を返信すると:

Slack Webhook (番号受信)
  → Switch ノード (番号に対応するテーマを選択)
  → HTTP Request → autoclaw API (構成生成)

autoclaw へのリクエスト（品質重視）:

{
  "task": "generate",
  "model_preference": "quality",
  "prompt": "以下のテーマで2500字のブログ記事構成を作ってください。対象読者はエンジニア副業志向。\n\nテーマ: {{ $json.theme }}"
}

model_preference: "quality" で Claude Sonnet にルーティングされる。

ステップ 3: Obsidian 保存

生成された構成は HTTP Request ノードから Obsidian REST API に送られ、drafts/ フォルダに mdx 形式で保存される。

俺はそれを見て、肉付けして、draft: false に変えるだけだ。

実装例 2: エラー自動検知と DLQ 処理

n8n の Error Workflow 機能を使った監視設計だ。

[WF-ERROR-HANDLER] ← 全 WF の Error Workflow に設定
  Webhook受信 (エラー情報)
  → Set ノード (エラー分類: Network / API / Logic)
  → Supabase Insert (dlq テーブルに記録)
  → Slack 通知 (エラー概要 + WF 名 + 実行 URL)

これで「WF が静かに死んでいる」状態を防げる。

Supabase の DLQ テーブル構造:

CREATE TABLE n8n_dlq (
  id uuid DEFAULT gen_random_uuid(),
  wf_name text NOT NULL,
  error_type text,
  error_message text,
  payload jsonb,
  created_at timestamptz DEFAULT now(),
  resolved_at timestamptz
);

月次の AUTOAGENT-OPTIMIZER がこのテーブルを集計し、「エラー率 TOP3 WF」を Slack に報告する。

autoclaw の設定詳細

autoclaw の核心は「タスクタイプ別のモデルルーティング」だ。

config.json の抜粋:

{
  "routing": {
    "summarize": { "provider": "ollama", "model": "qwen2.5:14b" },
    "translate": { "provider": "ollama", "model": "qwen2.5:14b" },
    "generate": { "provider": "claude", "model": "claude-sonnet-4-5" },
    "review":   { "provider": "claude", "model": "claude-opus-4-5" }
  },
  "fallback": {
    "provider": "ollama",
    "model": "qwen2.5:14b"
  }
}

n8n から task: "summarize" を投げれば ollama、task: "generate" を投げれば Claude Sonnet、という切り分けが自動で行われる。

n8n の Code ノードから autoclaw を叩くシンプルな例:

const payload = {
  task: "summarize",
  prompt: $json.content,
  max_tokens: 512
};
 
// HTTP Request ノードに渡す
return [{ json: payload }];

この後 HTTP Request ノードで http://autoclaw:3101/task に POST するだけだ。

コスト感（月額実績）

実際の月額コストを公開する。

| 項目 | 月額 | 用途 | |---|---|---| | VPS（n8n + autoclaw） | ¥700 | Docker 2 コンテナ | | ollama モデル | ¥0 | VPS 内で動作 | | Claude API | ¥300〜¥800 | generate / review タスクのみ | | Supabase | ¥0 | Free Tier | | Vercel | ¥0 | Hobby |

月合計: ¥1,000〜¥1,500

全タスクを Claude API に流していたら月 ¥5,000〜¥10,000 になっていた試算がある。autoclaw のルーティングで約 70〜80% のコストを削減している。

よくある失敗パターンと対処

失敗 1: n8n の Code ノードで fetch を使う

n8n の Code ノード（task runner モード）は Node.js の fetch が使えない環境がある。

対処: HTTP Request ノードを別途立てて処理を分ける。または require('https') を使う。

失敗 2: autoclaw が落ちているのに気づかない

autoclaw が静かに死んでいると、全 WF の LLM 処理が詰まるかエラーになる。

対処: WF-AUTOCLAW-CRON で毎時ヘルスチェックを走らせ、200 以外のレスポンスが来たら即 Slack 通知する。

失敗 3: Claude Code で作ったコードをそのまま n8n に貼る

Claude Code が生成するコードは Node.js 標準環境を前提にしていることが多い。n8n の Code ノードは制約がある。

対処: CLAUDE.md に「n8n Code ノードの制約」を明示する。child_process 禁止・fetch 代わりに HTTP Request ノード使用・template literal 必須、この 3 点を書くだけで品質が激変する。

まとめ

• Claude Code = 設計・コード生成。「何を作るか」を決めるフェーズ
• n8n = 実行・オーケストレーション。「いつ・何を・どこに」を管理する
• autoclaw = コスト最適化。LLM 呼び出しをタスクタイプ別に振り分ける
• 3 つが連携することで「自律的に動き続けるシステム」が成立する
• 月のランニングコストは ¥1,000〜¥1,500

個別のツールを学ぶことよりも、この 3 つがどう連携するかの設計思想を理解することの方が、圧倒的に重要だ。