n8n ワークフローアーキテクト

インテリジェントオートメーションアーキテクト (IAA) - 本番環境で機能するオートメーションシステムを構築するための戦略的ガイダンス。

このスキルを使う場面

以下のような場合にこのスキルを実行してください:

オートメーションプロジェクトを計画したい - 「営業パイプラインを自動化する必要がある」
複数のサービスを統合する必要がある - 「Shopify、Klaviyo、Notion を使っている」
アーキテクチャの決定が必要 - 「これに n8n を使うべき、それとも Python?」
実現可能性を評価したい - 「現在のスタックで X を自動化できる?」
本番環境対応のガイダンスが必要 - 「これを信頼性の高いものにするには?」

コアフィロソフィー

可能性より実現可能性

技術的に可能なことと、実際に本番環境で実行可能なことのギャップは非常に大きいです。このスキルは、以下の特性を持つシステムを構築するのを支援します:

土曜日の午前 3 時に故障しない
メンテナンスに博士号を必要としない
データセキュリティ、スケーラビリティ、状態管理に対応している
単なる技術的な巧妙さではなく、実際のビジネス価値を提供する

アーキテクチャ決定フレームワーク

ステップ 1: スタック分析

ユーザーがツールについて言及する場合、各ツールを以下の観点で評価します:

ツールカテゴリ	一般的な例	n8n ネイティブサポート	認証の複雑性
e コマース	Shopify、WooCommerce、BigCommerce	はい	OAuth
CRM	HubSpot、Salesforce、Zoho CRM	はい	OAuth
マーケティング	Klaviyo、Mailchimp、ActiveCampaign	はい	API キー/OAuth
生産性	Notion、Airtable、Google Sheets	はい	OAuth
コミュニケーション	Slack、Discord、Teams	はい	OAuth
決済	Stripe、PayPal、Square	はい	API キー
サポート	Zendesk、Intercom、Freshdesk	はい	API キー/OAuth

アクション: n8n MCP の search_nodes を使用して、ノードの利用可能性を確認します。

ステップ 2: ツール選択マトリックス

以下の決定ルールを適用します:

n8n を使う場合:

条件	理由
OAuth 認証が必要	n8n がトークンライフサイクルを自動的に管理
非技術者がメンテナンス	ビジュアルワークフローは自己説明的
待機を含む複数日のプロセス	組み込みの Wait ノードが一時中断を処理
標準的な SaaS 統合	事前構築されたノードが定型的なコードを排除
実行あたり 5,000 レコード未満	メモリ制限内
ビジネスロジックが 20 ノード未満	ビジュアル明確性を維持

Python/Claude Code を使う場合:

条件	理由
5,000 レコード以上を処理	ストリーム処理、メモリ管理
20MB 以上のファイル	チャンク処理機能
複雑なアルゴリズム	50 以上のノードより保守性が高い
最新の AI ライブラリ	最新パッケージへのアクセス
大量のデータ変換	Pandas、NumPy の最適化
カスタム ML モデル	Python エコシステムへのフルアクセス

ハイブリッドを使う (複雑なシステムに推奨):

n8n (オーケストレーション レイヤー)
├── Webhook とトリガー
├── OAuth 認証
├── ユーザー向け統合
├── フロー調整
│
└── Python サービスを呼び出す (処理レイヤー)
    ├── 重い計算
    ├── 複雑なロジック
    ├── AI/ML 操作
    └── n8n に結果を返す

ビジネススタッククイック評価

ユーザーがスタックを説明する場合、この分析で対応します:

テンプレートレスポンス:

## スタック分析: [ユーザーのビジネスタイプ]

### 識別されたサービス:
1. **[サービス 1]** - [カテゴリ] - n8n サポート: [はい/部分的/いいえ]
2. **[サービス 2]** - [カテゴリ] - n8n サポート: [はい/部分的/いいえ]
...

### 推奨アプローチ: [n8n / Python / ハイブリッド]

**根拠:**
- [主要な決定要因 1]
- [主要な決定要因 2]
- [主要な決定要因 3]

### 統合の複雑性: [低/中/高]
- 認証の複雑性: [シンプルな API キー / OAuth が必要]
- データ量: [ユースケースに基づいた推定]
- 処理ニーズ: [シンプルな変換 / 複雑なロジック]

### 次のステップ:
1. [他の n8n スキルを使用した具体的なアクション]
2. [n8n-workflow-patterns に従うパターン]
3. [n8n-validation-expert による検証アプローチ]

一般的なビジネスシナリオ

シナリオ 1: e コマースオートメーション

スタック: Shopify + Klaviyo + Slack + Google Sheets

判定: 純粋な n8n

すべてのサービスがネイティブノードを持つ
OAuth は自動的に処理
標準的な Webhook パターン
使用: n8n-workflow-patterns → webhook_processing

シナリオ 2: AI を活用したリード認定

スタック: Typeform + HubSpot + OpenAI + カスタムスコアリング

判定: ハイブリッド

n8n: Typeform Webhook、HubSpot 同期、通知
Python/Code ノード: 複雑なスコアリングアルゴリズム、AI プロンプト
使用: n8n-workflow-patterns → ai_agent_workflow

シナリオ 3: データパイプライン / ETL

スタック: PostgreSQL + BigQuery + 1 日あたり 50k 以上のレコード

判定: Python と n8n トリガー

n8n: スケジュールトリガー、成功/失敗の通知
Python: バッチ処理、ストリーミング、変換
理由: 大規模データセットに対する n8n のメモリ制限

シナリオ 4: マルチステップ承認ワークフロー

スタック: Slack + Notion + メール + 3 日間の待機期間

判定: 純粋な n8n

遅延対応の組み込み Wait ノード
Slack/Notion のネイティブ統合
人間による承認パターンが組み込まれている
使用: n8n-workflow-patterns → scheduled_tasks

本番環境対応チェックリスト

オートメーションがライブになる前に、以下を確認します:

可視性

エラー通知ワークフローが存在する
実行ログがデータベースに記録される
クリティカルパスのヘルスチェックワークフロー
重大度別の構造化アラート

べき等性

重複した Webhook の処理
作成前チェックパターン
決済用のべき等性キー
安全な再実行機能

コスト認識

AI API コストの計算と承認
レート制限が文書化されている
繰り返される呼び出しのキャッシング戦略
モデルの適切なサイジング (Haiku vs Sonnet vs Opus)

運用制御

非技術スタッフがアクセスできるキルスイッチ
高リスクアクションの承認キュー
すべてのアクションの監査証跡
構成が外部化されている

デプロイ前にワークフローを検証するには、n8n-validation-expert スキルを使用します。

他の n8n スキルとの統合

このスキルは、他のスキルを調整する 計画レイヤー として機能します:

┌─────────────────────────────────────────────────────────────┐
│                  n8n-workflow-architect                      │
│            (戦略的な決定と計画)                              │
└─────────────────────────────────────────────────────────────┘
                              │
         ┌────────────────────┼────────────────────┐
         ▼                    ▼                    ▼
┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐
│ n8n-workflow-   │  │ n8n-node-       │  │ n8n-validation- │
│ patterns        │  │ configuration   │  │ expert          │
│ (アーキテクチャ) │  │ (ノード設定)    │  │ (品質)          │
└─────────────────┘  └─────────────────┘  └─────────────────┘
         │                    │                    │
         └────────────────────┼────────────────────┘
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                     n8n MCP ツール                           │
│    (search_nodes、validate_workflow、create_workflow など) │
└─────────────────────────────────────────────────────────────┘

スキルハンドオフガイド:

アーキテクトが決定した後...	ハンドオフ先
パターンタイプが特定された	`n8n-workflow-patterns` で詳細な構造
特定のノードが必要	`n8n-node-configuration` でセットアップ
Code ノードが必要	`n8n-code-javascript` または `n8n-code-python`
式が必要	`n8n-expression-syntax` で正しい構文
検証準備ができた	`n8n-validation-expert` でデプロイ前チェック
ノード情報が必要	n8n MCP → `get_node_essentials`、`search_nodes`

プランモードの有効化

複雑なアーキテクチャ決定については、プランモードに入って以下を実行します:

ビジネスコンテキスト全体を分析
すべての統合ポイントを評価
データフローアーキテクチャを設計
障害モードと軽減策を特定
実装ロードマップを作成

プランモードのトリガー条件:

ユーザーが 3 つ以上のサービスを統合する
n8n と Python のどちらが適切か不明瞭
高リスクオートメーション (決済、顧客データ)
複雑なマルチステッププロセス
AI/ML コンポーネントが関与している

プランモード出力構造:

## オートメーション アーキテクチャ計画

### 1. ビジネス コンテキスト
[どの問題を解決するのか?]

### 2. スタック分析
[各サービス、その役割、統合の複雑性]

### 3. 推奨アーキテクチャ
[n8n / Python / ハイブリッド と根拠]

### 4. データ フロー設計
[フローのビジュアル表現]

### 5. 実装フェーズ
フェーズ 1: [コア ワークフロー]
フェーズ 2: [エラー処理と可視性]
フェーズ 3: [最適化とスケーリング]

### 6. リスク評価
[何が問題となる可能性があるか、どのように防ぐか]

### 7. メンテナンス計画
[誰がメンテナンスするか、必要なスキル]

クイック決定ツリー

開始: ユーザーが何かを自動化したい
  │
  ├─► OAuth が関係している? ──────────────────► n8n を使用
  │
  ├─► 非開発者がメンテナンスするか? ─────────► n8n を使用
  │
  ├─► 数日/数週間の待機が必要か? ────────────► n8n を使用
  │
  ├─► 5,000 レコード以上を処理? ───────────► Python を使用
  │
  ├─► ファイルが 20MB 以上? ────────────────► Python を使用
  │
  ├─► 最新の AI/ML? ───────────────────────► Python を使用
  │
  ├─► 複雑なアルゴリズム (20 ノード以上必要)? ► Python を使用
  │
  └─► 上記の組み合わせ? ─────────────────────► ハイブリッドを使用

MCP ツール統合

アーキテクチャ計画中にこれらの n8n MCP ツールを使用します:

計画フェーズ	使用する MCP ツール
スタック分析	`search_nodes` - ノード利用可能性を確認
パターン選択	`list_node_templates` - 類似のワークフローを検索
実現可能性チェック	`get_node_essentials` - 機能を理解
複雑性の推定	`get_node_documentation` - 認証と構成のニーズ
テンプレート参照	`get_template` - 既存のパターンを学習

注意すべき危険信号

これらのパターンを見かけた場合、ユーザーに警告します:

危険信号	リスク	推奨事項
「AI にすべてをやらせたい」	コスト爆発、予測不可能性	AI を特定のタスクに限定、結果をキャッシュ
「数百万行を処理する必要がある」	メモリクラッシュ	Python でのストリーミング、n8n ループではなく
「ワークフローに 50 ノードがある」	メンテナンス不可能	コードブロックに統合するか、ワークフローを分割
「エラー処理は後で追加する」	サイレントフェイル	最初からエラー処理を構築
「あらゆる入力で機能する必要がある」	脆弱なシステム	想定される入力を定義して検証
「インターンがメンテナンスする」	単一障害点	ビジュアル明確性のため n8n を使用、十分に文書化

まとめ

このスキルが答える問題: 「ビジネススタックと要件を踏まえて、このオートメーションを構築するための最適な方法は?」

主要な出力:

スタック互換性分析
n8n vs Python vs ハイブリッドの推奨
パターンとスキルハンドオフ
本番環境対応ガイダンス
プランモードによる実装ロードマップ

連携先:

実装の詳細のための全 n8n-* スキル
ノード検出とワークフロー作成のための n8n MCP ツール
複雑なアーキテクチャ決定のためのプランモード

n8n-workflow-architect

SKILL.md 本文

n8n ワークフローアーキテクト

このスキルを使う場面

コアフィロソフィー

アーキテクチャ決定フレームワーク

ステップ 1: スタック分析

ステップ 2: ツール選択マトリックス

n8n を使う場合:

Python/Claude Code を使う場合:

ハイブリッドを使う (複雑なシステムに推奨):

ビジネススタッククイック評価

テンプレートレスポンス:

一般的なビジネスシナリオ

シナリオ 1: e コマースオートメーション

シナリオ 2: AI を活用したリード認定

シナリオ 3: データパイプライン / ETL

シナリオ 4: マルチステップ承認ワークフロー

本番環境対応チェックリスト

可視性

べき等性

コスト認識

運用制御

他の n8n スキルとの統合

スキルハンドオフガイド:

プランモードの有効化

プランモードのトリガー条件:

プランモード出力構造:

クイック決定ツリー

MCP ツール統合

注意すべき危険信号

まとめ

関連ファイル

詳細情報

SKILL.md 本文

n8n ワークフロー アーキテクト

このスキルを使う場面

コア フィロソフィー

アーキテクチャ決定フレームワーク

ステップ 1: スタック分析

ステップ 2: ツール選択マトリックス

n8n を使う場合:

Python/Claude Code を使う場合:

ハイブリッドを使う (複雑なシステムに推奨):

ビジネス スタック クイック評価

テンプレート レスポンス:

一般的なビジネス シナリオ

シナリオ 1: e コマース オートメーション

シナリオ 2: AI を活用したリード認定

シナリオ 3: データ パイプライン / ETL

シナリオ 4: マルチステップ 承認ワークフロー

本番環境対応チェックリスト

可視性

べき等性

コスト認識

運用制御

他の n8n スキルとの統合

スキル ハンドオフ ガイド:

プラン モードの有効化

プラン モードのトリガー条件:

プラン モード出力構造:

クイック決定ツリー

MCP ツール統合

注意すべき危険信号

まとめ

関連ファイル

詳細情報

n8n ワークフローアーキテクト

コアフィロソフィー

ビジネススタッククイック評価

テンプレートレスポンス:

一般的なビジネスシナリオ

シナリオ 1: e コマースオートメーション

シナリオ 3: データパイプライン / ETL

シナリオ 4: マルチステップ承認ワークフロー

スキルハンドオフガイド:

プランモードの有効化

プランモードのトリガー条件:

プランモード出力構造: