Factory Missions とは？
Factory Missions は、Droid を使って大規模でマルチ機能の作業を構造化された方法で取り組むための仕組みです。すべてを単一のセッションで処理するのではなく、まず Droid と協力してプラン（機能、マイルストーン、各部分を達成するために必要なスキル）を構築し、その後作業を管理するオーケストレーション層に実行を委ねます。 Factory Missions には/missions コマンドでアクセスできます（/mission でも利用可能）。
共同計画
コードを書く前に、Droidと一緒に機能、マイルストーン、成功基準を定義します。
スキルを考慮した実行
既存のスキルを活用し、作業の各部分に合わせて新しい専門スキルを開発します。
構造化されたオーケストレーション
Mission Controlはエージェント全体の実行を管理し、計画に沿って進捗を追跡します。
設定は引き継がれます
MCP連携、スキル、フック、カスタムDroidはすべてFactory Missions内で動作します。
最適な成果のために
動作の仕組み
プランを正しく組み立てる方法については 計画と検証 を参照してください。承認済みのミッションを実行・操作するには CLIでの実行 または Desktop/Webでの実行 を参照してください。
Factory Missions が適している用途
私たちは様々な作業で Factory Missions を構築・テストしてきました：- フルスタック開発 — フロントエンド、バックエンド、データベース、デプロイメントを含む完全なアプリケーションの構築
- リサーチ — 複数のアプローチを探索し、発見を統合し、構造化された出力を生成する深い調査タスク
- ブラウンフィールド移行 — 既存の動作を保持しながら、既存コードベースの現代化、フレームワークの交換、大規模プロジェクトの再構築
- 野心的なプロトタイプ — 単なるスケッチではなく、機能的である必要がある製品実験
未解決の問題
Factory Missions は初期段階です。まだ取り組んでいる根本的な問題があるため、これをリサーチプレビューとして提供しています：- 並列化は必要か？ 複数のエージェントを並列実行するのは理論的には良く聞こえますが、実際に逐次実行よりも良い結果を生み出すのでしょうか？これをテストしています。
- 正確性を最大化するには？ 長期間のプランはエラーが蓄積されます。各段階でどの検証と修正戦略が最も効果的でしょうか？
- コスト vs. 品質のトレードオフ — オーケストレーターはどの程度積極的であるべきでしょうか？より多くの計画と検証は高コストを意味しますが、潜在的により良い出力をもたらします。適切なバランスはどこでしょうか？
関連項目
- 計画と検証 — 事前プランを正しく組み立て、検証頻度を調整する
- CLIでの実行 — ターミナルから監視・介入・リダイレクトする
- Desktop/Webでの実行 — 視覚的な Mission Control ダッシュボード
- トラブルシューティング — 停止したミッション、詰まったワーカー、ブロックされたマイルストーンからの復旧
- 設定とリファレンス — ヘッドレス実行、設定、組織ポリシー
- 仕様モード — 実装前の計画から恩恵を受ける適切にスコープされたタスクに対して
- 大規模機能の実装 — マルチフェーズプロジェクトのマニュアルワークフロー
- カスタムDroid — ミッションが使用できる専門的なサブエージェントを構築
- スキル — ミッションが活用できるスキルの作成と管理