n-version-workflow

N バージョンプログラミングワークフロースキル

目的

最適なアプローチを選択するために、複数の独立した実装を生成して比較する必要がある、重要な実装で N バージョンプログラミングワークフローを実行します。

このスキルを使用するタイミング

次の用途に使用します：

• 重要なセキュリティ機能（認証、認可）
• 複数の有効なアプローチがある複雑なアルゴリズム
• コアコンポーネントのリスクの高いリファクタリング
• 長期的に大きな影響を及ぼすアーキテクチャ上の決定
• 速度よりも正確性が最優先される場合

次の用途には使用しないでください：

• 単純な CRUD 操作
• 直接的なバグ修正
• ドキュメントの更新
• 小規模な UI の調整
• 時間に制約のある緊急の修正

設定

コアパラメーター

N（バージョン数）：

• 3 - 標準的なタスクのデフォルト
• 4-6 - 高い信頼性が求められる重要な機能
• 2 - アプローチの迅速な検証

選択基準（優先順位順）：

1. 正確性 - 要件を満たし、テストに合格する
2. セキュリティ - 脆弱性やアンチパターンがない
3. シンプルさ - 徹底的にシンプルで、複雑さを最小限に抑える
4. プロジェクトの理念への準拠 - プロジェクトの原則に従っている
5. パフォーマンス - 効率性とリソース使用量

エージェントの多様性プロファイル：

• conservative - 実証済みのパターンと安全性を重視
• innovative - 斬新なアプローチと最適化を重視
• minimalist - 徹底的なシンプルさを重視
• pragmatic - 実用的なソリューションのためにトレードオフのバランスを取る
• performance-focused - 速度と効率性を最適化

実行プロセス

ステップ 1：共通コンテキストの準備

• prompt-writer エージェントを使用して、非常に明確な仕様を作成します
• すべての要件を明示的に文書化します
• 成功基準を測定可能な形で定義します
• N 個すべてのバージョンに同一のタスク仕様を用意します
• 評価指標を事前に特定します
• 重要：最適化によって削除してはならない、ユーザーの明示的な要件を把握します

出力： 唯一の正式な仕様書

ステップ 2：N 個の独立した実装を生成

• N 個の Claude サブプロセスを同時に起動します
• 各サブプロセスに同一のタスク仕様を渡します
• サブプロセス間でコンテキストを共有しません（真の独立性を確保）
• それぞれ異なるエージェント多様性プロファイルを使用します
• それぞれがテストを含む完全な実装を作成します
• それぞれが分離されたディレクトリ（version_1/、version_2/ など）で作業します

N=3 の例：

• サブプロセス 1：保守的なアプローチ（実証済みのパターン、包括的なエラー処理）
• サブプロセス 2：実用的なアプローチ（シンプルさと堅牢性のバランス）
• サブプロセス 3：ミニマリストなアプローチ（徹底的な簡素化、依存関係を最小限に抑える）

ステップ 3：実装を収集して比較

• N 個すべての実装が完了するまで待ちます
• analyzer エージェントを使用して、各実装を調査します
• tester エージェントを使用して、各バージョンのテストを実行します
• 比較マトリックスに結果を記録します

比較マトリックス：

| Version | Correctness | Security | Simplicity | Philosophy | Performance | Lines of Code |
|---------|-------------|----------|------------|------------|-------------|---------------|
| v1      | PASS        | PASS     | 7/10       | 8/10       | 150ms       | 180           |
| v2      | PASS        | PASS     | 9/10       | 9/10       | 180ms       | 95            |
| v3      | FAIL        | N/A      | 10/10      | 7/10       | N/A         | 65            |

ステップ 4：レビューと評価

• reviewer エージェントを使用して、包括的に比較します
• security エージェントを使用して、各バージョンのセキュリティを評価します
• 優先順位に従って選択基準を適用します
• 正確性テストに失敗したバージョンを除外します
• 残ったバージョンを他の基準で比較します
• 各実装の最良の部分を特定します

評価プロセス：

1. フィルタリング：正確性テストに失敗したバージョンを除外します
2. セキュリティゲート：セキュリティ上の問題があるバージョンを除外します
3. 理念の確認：シンプルさと準拠度を基準に各バージョンを評価します
4. パフォーマンス比較：ベンチマークを測定して比較します
5. 統合：ハイブリッドアプローチがより優れた解決策になり得るか特定します

ステップ 5：ソリューションを選択または統合

判断ツリー：

1. すべての基準を満たすバージョンが 1 つありますか？
   • はい → そのバージョンを選択し、理由を記録します
   • いいえ → ステップ 2 に進みます
2. 上位基準で同点のバージョンが 2 つ以上ありますか？
   • はい → ステップ 3 に進みます
   • いいえ → 最も高いスコアのバージョンを選択します
3. 各バージョンに相互補完的な強みがありますか？
   • はい → 最良の部分を組み合わせたハイブリッドを統合します
   • いいえ → 重み付けされた基準の優先順位に基づいて選択します

統合の例：

Selected: Hybrid of v1 and v2
- Core logic from v2 (ruthless simplicity)
- Error handling from v1 (comprehensive coverage)
- Testing approach from v2 (focused, minimal)
- Documentation style from v1 (thorough)

Rationale: v2's minimalist core paired with v1's robust
error handling provides optimal balance of simplicity
and production-readiness.

ステップ 6：選択したソリューションを実装する

• ビルダーエージェントを使用して最終版を実装します
• 単一のバージョンを選択した場合：それをそのまま使用します
• 統合する場合：最良の部分を組み合わせたハイブリッド版を実装します
• ステップ 1で明示されたユーザー要件をすべて維持します
• テストスイート全体を実行します
• 選択理由をコードコメントに記録します

ドキュメントのテンプレート：

"""
N-Version Implementation Selection

Generated Versions: 3
Selection: Hybrid of v1 (conservative) and v2 (pragmatic)

Rationale:
- v1 had superior error handling and edge case coverage
- v2 had cleaner architecture and better testability
- v3 failed correctness tests (edge case handling)

This implementation combines v2's core logic with v1's
defensive programming approach for production robustness.

Selection Criteria Applied:
1. Correctness: v1=PASS, v2=PASS, v3=FAIL
2. Security: All passed
3. Simplicity: v2 ranked highest
4. Philosophy: v1 and v2 tied
5. Performance: Negligible difference

ステップ 7：得られた知見を記録する

• 分析ドキュメント n_version_analysis.md を作成します
• 生成したN個すべての実装について記録します
• 選択理由を詳しく説明します
• 却下したバージョンから得られた知見を記録します
• amplihack.memory.discoveries の store_discovery() を使用して、学んだパターンをメモリーに保存します
• 今後の参考として比較表を含めます

トレードオフ

コスト： 計算リソースと時間がN倍になります
メリット： 致命的なエラーのリスクを大幅に低減できます
最適な用途： バグが高くつく機能（セキュリティ、データ整合性）

例

例 1：認証システム

タスク： JWTベースの認証を実装する
構成： N=4（重要なセキュリティ機能）
プロファイル： 保守的、セキュリティ重視、実用重視、最小限

結果：

• v1（保守的）：最も包括的ですが、過剰に設計されています
• v2（セキュリティ重視）：セキュリティ面は優れていますが、複雑です
• v3（実用重視）：バランスは良好ですが、エッジケースが不足しています
• v4（最小限）：単純すぎて、セキュリティ上の不備があります

選択： v2とv3のハイブリッド

• v2のセキュリティ実装
• v3のAPI設計とシンプルさ

理由： セキュリティは妥協できませんが、v3のより明快なAPI設計によって、セキュリティを損なうことなく使いやすさが向上しました。

例 2：データ処理パイプライン

タスク： 大容量のCSVファイルを効率的に処理する
構成： N=3（パフォーマンスが重要）
プロファイル： 実用重視、パフォーマンス重視、最小限

結果：

• v1（実用重視）：Pandasベースで、使い慣れた方法ですが処理が遅いです
• v2（パフォーマンス重視）：独自のストリーミング処理で、10倍高速です
• v3（最小限）：PythonのCSVモジュールを使い、シンプルですが処理が遅いです

選択： v2（パフォーマンス重視）

理由： パフォーマンス要件を満たすには複雑さが必要でした。v2のストリーミング方式はスループット要件を満たしましたが、v1とv3ではスケールできませんでした。

哲学との整合性

このワークフローでは、次のことを徹底します。

• リスクの低減： 複数の実装によって、単一のアプローチでは見落とす可能性のあるエラーを検出します
• 探索： 異なるアプローチを通じて、設計上のトレードオフを明らかにします
• 根拠に基づく選択： 勘ではなく、体系的な比較に基づいて選択します
• 学習： 却下したバージョンからも、貴重な知見が得られます
• 並列実行： 効率化のため、N個の実装を同時に実行します

デフォルトワークフローとの統合

このワークフローを有効にすると、DEFAULT_WORKFLOWのステップ4～5（調査／設計と実装）が置き換わります。それ以外のすべてのステップ（要件、テスト、CI/CD）は変わりません。