Framework Orchestrator

フレームワークオーケストレーター

概要

フレームワークオーケストレーターは、プロジェクトのライフサイクル全体を通じて、ほかのすべてのスキルとフレームワークを調整するメタスキルです。プロジェクトを分析し、適切なパターンを特定して、フレームワークとスキルを最適な順序で組み合わせます。

次のように考えてください： どの方法論をいつ適用すべきか把握している、AI プロジェクトマネージャーです。

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

次のような場合にフレームワークオーケストレーターを使用してください。

• 新しいプロジェクトを開始し、方法論について案内が必要な場合
• どのフレームワークやスキルを最初に適用すべきかわからない場合
• プロジェクトのオーケストレーション計画を一通り作成したい場合
• プロジェクトの複雑さのパターンを理解する必要がある場合
• プロジェクトのフェーズ間を移行する場合
• 複数の作業ストリームを並行して管理する場合

主な機能

• プロジェクトを分析し、複雑さのパターン（A、B、C）を特定します
• 最適なフレームワークの順序を推奨します
• 適切なフェーズでスキルの有効化を調整します
• フェーズゲートの検証を提供します
• プロジェクトの進行に応じてオーケストレーションを適応させます
• あらゆる側面を包括的にカバーできるようにします

ワークフロー

ステップ 1：パターンの特定

プロジェクトを分析し、次の3つのパターンのいずれかに分類します。

パターン A：シンプルな機能／拡張

特徴：

• 既存システムへの追加
• 要件が十分に理解されている
• リスクが低く、セキュリティへの影響が最小限
• 単一チームで、短期間（数日から1～2週間）

例：

• 既存の検索にフィルターを追加
• 新しいダッシュボードウィジェット
• フォームフィールドの追加
• UI のスタイル更新

期間： 1～5日

---

パターン B：新しい製品／システム

特徴：

• ゼロからの構築、または大規模なモジュールの構築
• ユーザーによる検証が必要
• セキュリティ／コンプライアンスが重要
• 複数の考慮事項（UX、アーキテクチャ、テスト）
• 中程度の期間（数週間から数か月）

例：

• 新しい SaaS 製品
• 顧客ポータル
• 社内ツール
• API プラットフォーム

期間： 4～12週間

---

パターン C：AI ネイティブ／複雑なシステム

特徴：

• パターン B のすべての特徴に加えて、次の要素があります。
• AI エージェント、RAG システム、またはナレッジグラフ
• 複雑なオーケストレーション
• 新しいテクノロジー
• 不確実性が高く、反復が必要

例：

• マルチエージェント AI システム
• RAG を活用したナレッジベース
• インテリジェントな自動化プラットフォーム
• AI 支援型の意思決定支援

期間： 8～20週間

---

ステップ 2：フレームワークの選定

パターンに基づいて、フレームワークを推奨順に提示します。

パターン A の順序（シンプルな機能）

1. simple_feature_framework - 軽量な要件定義と検証
2. code-quality-enforcer - コード標準を確保
3. testing-strategist - 単体テストのカバレッジ
4. deployment-advisor - 迅速にリリース

連携するスキル：

• quality-assurance（テスト）
• performance-optimizer（必要に応じて）

---

パターン B のシーケンス（新規プロダクト）

フェーズ 1：発見と検証

• discovery_validation_framework - ユーザー調査と問題の検証
• product_market_fit_framework - 市場分析とポジショニング
• prp-generator スキル - プロダクト要件プロンプトの作成
• user-researcher スキル - ユーザーインタビューの実施

フェーズ 2：アーキテクチャと設計

• bmad-method スキル - ビジネスモデルとアーキテクチャの整合
• design_prototyping_framework - ワイヤーフレームとプロトタイプ
• ux-designer スキル - ユーザージャーニーのマッピング
• security-architect スキル - 脅威モデリングとセキュリティ設計
• api-designer スキル（該当する場合） - API コントラクトの設計

フェーズ 3：開発

• full_stack_dev_framework - 実装のガイダンス
• frontend-builder / api-designer スキル - UI とバックエンドの構築
• quality-assurance スキル - コード品質とテスト

フェーズ 4：テストと検証

• testing_validation_framework - 包括的なテスト戦略
• quality-assurance スキル - テストピラミッドの実行
• usability-tester スキル - ユーザー受け入れテスト
• security-architect スキル - セキュリティテスト

フェーズ 5：デプロイとローンチ

• deployment_devops_framework - CI/CD とインフラストラクチャ
• deployment-advisor スキル - デプロイ戦略
• go-to-market-planner スキル - ローンチ計画

---

パターン C のシーケンス（AI ネイティブ）

パターン B の全フェーズに加えて、次を実施します：

フェーズ 2b：AI アーキテクチャ（標準アーキテクチャと並行）

• multi-agent-architect スキル - エージェントシステムの設計
• rag-implementer スキル - RAG アーキテクチャ（該当する場合）
• knowledge-graph-builder スキル - ナレッジ構造（該当する場合）
• agentic-workflow-orchestration-framework - エージェントの連携

フェーズ 3b：AI 開発（標準開発と統合）

• context_engineering_framework - プロンプトとコンテキストの設計
• multi_agent_orchestration_framework - エージェントの実装

フェーズ 4b：AI テスト（追加のテストレイヤー）

• エージェントの動作とエッジケースをテストします
• RAG の検索品質を検証します
• LLM のパフォーマンスをベンチマークします

---

ステップ 3：フェーズのオーケストレーション

検証ゲートを設けてフェーズを実行します：

フェーズゲートの構成

フェーズ 2（設計）への移行条件：

• PRP ドキュメントが完成している
• 問題の記述が検証済みである
• 成功指標が定義されている
• ユーザーストーリーが文書化されている

フェーズ 3（開発）への移行条件：

• アーキテクチャが文書化されている
• データモデルが設計されている
• セキュリティ上の脅威が特定されている
• 緩和策が計画されている

フェーズ 4（テスト）への移行条件：

• 機能が完成している
• ユニットテストのカバレッジが 80% を超えている
• コードレビューに合格している
• SAST スキャンで問題がない

フェーズ 5（デプロイ）への移行条件：

• すべてのテストに合格している
• UAT が完了している
• セキュリティテストが完了している
• カバレッジが 90% を超えている

---

ステップ 4：スキルの連携

現在のフェーズに応じてスキルをオーケストレーションします：

発見フェーズのスキル：

• user-researcher
• product-strategist
• product-analyst

設計フェーズのスキル：

• ux-designer
• design-system-architect
• bmad-method
• security-architect

開発フェーズのスキル：

• frontend-builder
• api-designer
• multi-agent-architect（パターン C）
• rag-implementer（パターン C）
• mvp-builder

テストフェーズのスキル：

• quality-assurance
• usability-tester
• security-architect

デプロイフェーズのスキル：

• deployment-advisor
• go-to-market-planner
• performance-optimizer

ローンチ後のスキル：

• product-analyst
• customer-feedback-analyzer
• performance-optimizer

---

例

例1：SaaS 分析プラットフォーム（パターン B）

プロジェクト分析：

• ゼロからの新製品
• B2B SaaS モデル
• セキュリティとコンプライアンスが重要
• 8週間のスケジュール

推奨する順序：

第1週：発見

1. discovery_validation_framework
2. user-researcher skill → ユーザーインタビュー
3. product-strategist skill → 市場検証
4. prp-generator skill → PRP を作成

第2週：アーキテクチャ 5. bmad-method skill → ビジネスモデルとアーキテクチャの調整 6. design_prototyping_framework → ワイヤーフレーム 7. ux-designer skill → ユーザージャーニー 8. api-designer skill → API 設計 9. security-architect skill → 脅威モデル

第3～6週：開発 10. full_stack_dev_framework 11. frontend-builder skill → React UI の構築 12. api-designer skill → バックエンドの構築 13. quality-assurance skill → 継続的なテスト

第7週：テスト 14. testing_validation_framework 15. quality-assurance skill → テストピラミッド 16. usability-tester skill → ユーザーテスト 17. security-architect skill → セキュリティテスト

第8週：デプロイ 18. deployment_devops_framework 19. deployment-advisor skill → 本番環境へデプロイ 20. go-to-market-planner skill → ローンチ計画

---

例2：マルチエージェントのカスタマーサポートシステム（パターン C）

プロジェクト分析：

• 複数のエージェントを備えた AI ネイティブシステム
• ナレッジ検索に RAG を使用
• 複雑なオーケストレーション
• 12週間のスケジュール

推奨する順序：

第1～2週：発見（パターン B と同じ）

第3～4週：アーキテクチャ

• bmad-method skill
• security-architect skill
• multi-agent-architect skill → エージェントシステムの設計
• rag-implementer skill → RAG アーキテクチャ
• knowledge-graph-builder skill → ナレッジ構造
• agentic-workflow-orchestration-framework

第5～9週：開発

• full_stack_dev_framework
• frontend-builder skill
• multi-agent-architect skill → エージェントの実装
• rag-implementer skill → ベクトル DB と埋め込み
• context_engineering_framework → プロンプト設計
• quality-assurance skill

第10～11週：テスト

• testing_validation_framework
• quality-assurance skill
• エージェントの動作、RAG の品質、LLM のパフォーマンスをテスト
• usability-tester skill

第12週：デプロイ

• deployment_devops_framework
• deployment-advisor skill
• go-to-market-planner skill

---

例3：ユーザーエクスポート機能の追加（パターン A）

プロジェクト分析：

• 既存システムの機能強化
• 要件が明確
• 複雑さは低い
• 3日間のスケジュール

推奨する順序：

1日目：

1. simple_feature_framework → 要件を定義
2. api-designer skill → エクスポートエンドポイントを設計

2日目： 3. バックエンドとフロントエンドを構築 4. quality-assurance skill → 単体テスト

3日目： 5. testing-strategist skill → 統合テスト 6. deployment-advisor skill → ステージング環境にデプロイ後、本番環境にデプロイ

---

ベストプラクティス

1. まずパターンの特定から始める

いきなりフレームワークに飛びつかないでください。まず、次の点を把握します。

• スコープ（シンプルな機能、新製品、AI システム）
• スケジュール（日、週、月）
• リスク（低、中、高）

2. フェーズゲートを守る

検証チェックポイントを飛ばさないでください。各ゲートで次の点を確認します。

• 前の作業が完了している
• 次のフェーズの適切な基盤が整っている
• リスクが特定され、軽減されている

3. 可能な場合は並行して進める

次の作業は並行して進められます。

• UX 設計とアーキテクチャ設計（フェーズ 2）
• フロントエンド開発とバックエンド開発（フェーズ 3）
• テストの作成と機能開発（フェーズ 3）

4. 実情に応じてオーケストレーションを調整する

プロジェクトが変化した場合：

• パターン A → パターン B：発見と設計のフェーズを追加
• パターン B → パターン C：AI アーキテクチャとテストを追加
• スコープを縮小：オーケストレーションを簡素化

5. スキルを調整し、詰め込みすぎない

すべてのスキルを一度に有効にしないでください。順序を決めて進めます。

• フェーズごとに最大1～3個のスキル
• スキル間の明確な引き継ぎ
• 各スキルに固有の成果物を設定

---

よくある落とし穴

1. パターンの誤認

アンチパターン： パターン B（新製品）をパターン A（単純な機能）として扱う 結果： 発見フェーズを省略し、誤ったものを構築する

対策： 少しでも不確実な点があれば、パターン B を選びます

2. フェーズの省略

アンチパターン： 設計を行わず、すぐに開発に着手する 結果： 手戻り、要件の見落とし、セキュリティ上の不備

対策： 手順を守り、フェーズゲートを検証します

3. 単純な機能の過剰なオーケストレーション

アンチパターン： ボタンの色を変えるだけなのに、パターン B のオーケストレーション全体を使う 結果： 不要なプロセスに時間を浪費する

対策： 本当に単純な作業には、パターン A が有効です

4. 複雑なプロジェクトのオーケストレーション不足

アンチパターン： 適切なアーキテクチャフェーズを設けずに AI システムを構築する 結果： 技術的負債、パフォーマンスの低下、作り直し

対策： パターン C では包括的なオーケストレーションが必要です

5. フェーズゲートの無視

アンチパターン： アーキテクチャが未完成のまま開発に進む 結果： 不安定な基盤の上に構築し、開発途中で阻害要因が発生する

対策： フェーズゲートを徹底し、準備状況を文書化します

---

関連スキル

• prp-generator - 要件を作成します（フェーズ 1 でオーケストレーターが呼び出します）
• bmad-method - ビジネスとアーキテクチャの整合性を確保します（フェーズ 2）
• security-architect - セキュリティを設計します（フェーズ 2 と 4）
• quality-assurance - テスト戦略を策定します（フェーズ 3 と 4）
• deployment-advisor - インフラストラクチャを担当します（フェーズ 5）
• その他すべてのスキル - 適切なフェーズでオーケストレーターが有効化します

---

成果物

Framework Orchestrator を使用する場合は、次のものを作成します。

1. パターンの特定

   • パターン：A、B、または C
   • 分類の根拠
   • 推定スケジュール

2. オーケストレーション計画

   • フェーズの内訳
   • フレームワークの適用順序
   • スキルの有効化ポイント
   • フェーズゲートの基準

3. 現在のフェーズの状況

   • 現在のフェーズ
   • 完了率
   • ゲート基準への準備状況
   • 次のステップ

4. リスクと適応計画

   • 特定したリスク
   • 緊急時対応計画
   • オーケストレーションを適応させるタイミング

---

成功指標

オーケストレーションが成功したといえるのは、次の条件を満たす場合です。

• 適切なパターンを特定できている（誤分類がない）
• フレームワークが最適な順序で適用されている
• フェーズゲートが徹底され、通過している
• 適切なタイミングでスキルが有効化されている
• フェーズの省略による大規模な手戻りがない
• チームが現在のフェーズと次のステップを把握している
• パターンに応じた適切な品質でプロジェクトが納品されている

---

覚えておいてください： オーケストレーターは、適切な方法論を適切なタイミングで適用できるようにします。それが、整理された開発と混乱した迷走を分ける違いです。