# Phase 7: 2ツール連携の統合テスト 計画書
## タスク目次
- 1. [AIエージェントワークフローシナリオの設計] - 状態: 完了 - TDD: ✅ Red / ✅ Green / ✅ Refactor
- 2. [正常実行確認シナリオのテスト実装] - 状態: 完了 - TDD: ✅ Red / ✅ Green / ✅ Refactor
- 3. [エラー調査シナリオのテスト実装] - 状態: 完了 - TDD: ✅ Red / ✅ Green / ✅ Refactor
- 4. [複数ノード取得シナリオのテスト実装] - 状態: 完了 - TDD: ✅ Red / ✅ Green / ✅ Refactor
- 5. [レスポンス時間測定とパフォーマンステスト] - 状態: 完了 - TDD: ✅ Red / ✅ Green / ✅ Refactor
**番号付けルール:**
- 全て直列実行（タスク間に依存関係あり）
**並列実行の判断基準（明示的並列宣言方式）:**
- このPhaseでは並列実行可能なタスクなし
## Phase概要
- **Phase名**: 2ツール連携の統合テスト
- **状態**: 完了
- **開始日時**: 2025-11-03
- **完了日時**: 2025-11-03
- **目標**: get_executionとget_execution_by_nodeの連携動作を検証し、AIエージェントワークフローのシナリオテストを実施
## TDD & 設計原則の適用
### TDDアプローチ
このPhaseでは以下のTDDサイクルを適用します：
1. **Red（テスト作成）**: AIエージェントの使用シナリオを想定したテストケース作成
2. **Green（最小実装）**: 両ツールの連携動作確認
3. **Refactor（リファクタリング）**: テストシナリオの最適化とエッジケース追加
### 設計原則の適用方針
- **単一責任の原則 (SRP)**: 各テストケースは単一のシナリオのみを検証
- **開放/閉鎖の原則 (OCP)**: テストフレームワークの構造は変更せず、新規シナリオを追加
- **リスコフの置換原則 (LSP)**: 各ツールのインターフェースは一貫性を保つ
- **最小限の公開**: テストユーティリティ関数のみをexportし、内部実装は隠蔽
- **依存性逆転の原則 (DIP)**: テストは実際のN8nApiClientを使用（モックではない）
⚠️ **インターフェースや抽象クラスは使用しない**: テストユーティリティは具体的な関数として実装
## 依存関係
- **前提条件**: Phase 3（get_execution統合）とPhase 6（get_execution_by_node統合）の完了
- **ブロッカー**: なし
- **後続Phaseへの影響**: Phase 8（ドキュメント更新とE2Eテスト）でCLAUDE.mdに使用例を追加
## 実装する機能
- AIエージェントワークフローシナリオの設計
- 正常実行確認シナリオのテスト
- エラー調査シナリオのテスト
- 複数ノード取得シナリオのテスト
- レスポンス時間測定とパフォーマンステスト
## タスク詳細
### タスク1: AIエージェントワークフローシナリオの設計
- **説明**:
- AIエージェントが2ツールをどのように連携して使用するかをシナリオとして設計
- シナリオ1: 正常実行確認（get_execution → 全ノード正常確認）
- シナリオ2: エラー調査（get_execution → エラーノード特定 → get_execution_by_node → エラー詳細確認）
- シナリオ3: 複数ノード詳細取得（get_execution → 複数ノードに対してget_execution_by_nodeを複数回呼び出し）
- 各シナリオのフロー図を作成
- **開始日時**: （未着手の場合は空欄）
- **TDDステップ**:
- [ ] Red: シナリオフローを検証するテストケース作成
- [ ] Green: シナリオフローの実装確認
- [ ] Refactor: シナリオの最適化（エッジケース追加）
- **依存関係**: なし
- **状態**: 未着手
### タスク2: 正常実行確認シナリオのテスト実装
- **説明**:
- テストファイル: src/tools/implementations/__tests__/two-tool-integration.test.ts
- シナリオ: AIエージェントが実行の状態を確認し、全ノードが正常であることを報告
- ステップ1: get_execution(id: "exec-123")を呼び出し
- ステップ2: ExecutionSummaryからstatistics.failedNodesが0であることを確認
- ステップ3: AIエージェントが人間ユーザーに「正常完了」を報告
- テストfixtureの準備（正常実行の実行データ）
- **開始日時**: （未着手の場合は空欄）
- **TDDステップ**:
- [ ] Red: 正常実行シナリオのテストケース作成
- [ ] Green: テストfixture準備とテスト実装
- [ ] Refactor: テストユーティリティ関数の作成
- **依存関係**: タスク1完了後
- **状態**: 未着手
### タスク3: エラー調査シナリオのテスト実装
- **説明**:
- シナリオ: AIエージェントがエラー実行を調査し、エラー原因を特定
- ステップ1: get_execution(id: "exec-456")を呼び出し
- ステップ2: ExecutionSummaryからavailableNodesのstatusが"error"のノードを特定（例: "HTTP Request"）
- ステップ3: get_execution_by_node(id: "exec-456", nodeName: "HTTP Request")を呼び出し
- ステップ4: NodeExecutionDataからerrorフィールドを確認（例: "ETIMEDOUT"）
- ステップ5: AIエージェントが人間ユーザーに「HTTP Requestノードで接続タイムアウトエラー」と報告
- テストfixtureの準備（エラー実行の実行データ）
- **開始日時**: （未着手の場合は空欄）
- **TDDステップ**:
- [ ] Red: エラー調査シナリオのテストケース作成
- [ ] Green: テストfixture準備とテスト実装
- [ ] Refactor: エラーメッセージの検証ロジック追加
- **依存関係**: タスク2完了後
- **状態**: 未着手
### タスク4: 複数ノード取得シナリオのテスト実装
- **説明**:
- シナリオ: AIエージェントが複数ノードの詳細を段階的に取得
- ステップ1: get_execution(id: "exec-789")を呼び出し
- ステップ2: ExecutionSummaryからavailableNodesを確認（例: 3ノード）
- ステップ3: get_execution_by_node(id: "exec-789", nodeName: "Node1")を呼び出し
- ステップ4: get_execution_by_node(id: "exec-789", nodeName: "Node2")を呼び出し
- ステップ5: get_execution_by_node(id: "exec-789", nodeName: "Node3")を呼び出し
- ステップ6: AIエージェントが全ノードの情報を統合して人間ユーザーに報告
- テストfixtureの準備（3ノード実行の実行データ）
- **開始日時**: （未着手の場合は空欄）
- **TDDステップ**:
- [ ] Red: 複数ノード取得シナリオのテストケース作成
- [ ] Green: テストfixture準備とテスト実装
- [ ] Refactor: ループ処理の最適化
- **依存関係**: タスク3完了後
- **状態**: 未着手
### タスク5: レスポンス時間測定とパフォーマンステスト
- **説明**:
- 各ツールのレスポンス時間を測定
- get_executionのレスポンス時間（目標: 1秒以内）
- get_execution_by_nodeのレスポンス時間（目標: 2秒以内）
- 複数ノード取得（3ノード）の合計レスポンス時間（目標: 7秒以内）
- パフォーマンス目標を超過する場合、ボトルネックを特定
- **開始日時**: （未着手の場合は空欄）
- **TDDステップ**:
- [ ] Red: レスポンス時間の上限を検証するテストケース作成
- [ ] Green: performance.now()を使用した測定実装
- [ ] Refactor: ボトルネック分析とログ出力追加
- **依存関係**: タスク4完了後
- **状態**: 未着手
## テスト戦略
- **統合テスト**:
- 2ツール連携のシナリオテスト（実際のN8nApiClientを使用）
- AIエージェントの使用パターンを想定したテストケース
- **パフォーマンステスト**:
- レスポンス時間の測定
- ボトルネック分析
- **手動テスト**:
- Claude Code等のMCPクライアントから実際に2ツールを連携して使用
## Phase完了条件
- [x] 全タスク完了
- [x] 全テスト通過（122/122テスト、E2E除く）
- [x] 品質チェックコマンドが成功（`pnpm run type-check`, `pnpm run lint`, `pnpm run test`）
- [x] 2ツール連携のシナリオテストが全て成功（6テストケース）
- [x] レスポンス時間がパフォーマンス目標以内（全て1秒未満）
## 技術的課題と解決方針
**課題1: テストfixtureの準備**
- 実際のn8n実行データを再現する必要がある
- 解決方針: 実際のn8n APIからデータを取得し、JSON fixtureとして保存
- 代替案: モックデータを手動で作成
**課題2: AIエージェントの動作を再現**
- AIエージェントの判断ロジックをテストで再現する必要がある
- 解決方針: availableNodesのstatusを確認するシンプルなロジックで再現
**課題3: レスポンス時間のばらつき**
- n8n APIのレスポンス時間がネットワーク状況に依存
- 解決方針: 複数回測定して平均値を使用
## リスク管理
**リスク1: n8n APIのレート制限**
- 影響度: 低（統合テストで頻繁にAPIを呼び出す場合）
- 対策: テストケースを最小限に抑える
- 緩和策: モックN8nApiClientを使用し、実際のAPIアクセスを削減
**リスク2: レスポンス時間がパフォーマンス目標を超過**
- 影響度: 中
- 対策: ボトルネックを特定し、最適化
- 緩和策: キャッシング機構の導入（将来的な拡張）
## 次Phaseへの引き継ぎ事項
**Phase 8で利用可能になる機能**:
- 動作確認済みの2ツール連携機能
- テストシナリオをベースにしたドキュメント例
**未解決の課題**:
- ドキュメント更新（Phase 8で実施）
- E2Eテスト（実際のn8nサーバーでの動作確認）
**技術的負債**:
- テストfixture管理（将来的にはfixture生成ツールを検討）
- パフォーマンス目標の妥当性検証（実環境での測定が必要）
