> ## Documentation Index
> Fetch the complete documentation index at: https://factory-docs-model-update-cl-824.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 計画と検証

> 計画段階は Missions が最も価値を発揮する場面です。機能とマイルストーンのスコープ設定、検証頻度の設定、コストと期間の見積もり方法を学びます。

## 計画段階が最も重要

Factory Missions において最も価値があるのは計画段階です。事前のプランを正しく組み立てる（機能、順序、マイルストーン、関連するスキル、そして作業をどのように検証するか）ことが、実行の成功を決定します。Droid は異議を唱え、質問を投げかけ、プランが確実になるまであなたと反復作業を行います。

これは意図的なものです。明確なマイルストーンを持つ適切にスコープされたプランは、曖昧な目標でいきなり実行に飛び込むよりもはるかに良い結果を生み出します。

## 検証

マイルストーンは検証頻度を定義します。検証ワーカーは各マイルストーンの終了時に実行され、その作業を検証します。シンプルなプロジェクトでは1つのマイルストーンで十分なことが多いですが、より長期または複雑なプロジェクトでは、より頻繁なマイルストーン検証が作業の規模拡大時の基盤安定性を保つのに役立ちます。

小規模で単純なプロジェクトでは、単一のマイルストーンで十分なことが多いです。大規模または長期間のプロジェクトでは、より詳細なマイルストーンがドリフトを防ぎ、後の高コストな再作業を削減できます。

QAスタイルの検証を必要としないプロジェクトの場合は、Mission Control 内のミッション設定でこれを無効化できます。

<a id="development-scripting-for-qa" />

## QAのための開発スクリプト

ミッションは実行中のアプリケーションを動かすことで自らの作業を検証します。そのため、最も価値のある準備の一つは、Droid がアプリを立ち上げ、操作し、観察できるようにする信頼性の高いスクリプトです。私たちが見てきた良いパターンは次のとおりです。

* **アプリを起動する単一のコマンド。** Web アプリであれば、バックエンドとフロントエンド（および必要なサービス）の両方を起動する単一のスクリプトを用意し、ワーカーがスタック全体を再現可能に立ち上げられるようにします。
* **ログをファイルシステムに出力する。** アプリケーションのログをディスク上のファイルに出力し、Droid が各アクションの後に読み取って確認できるようにします。ターミナルにしか流れないログは、ワーカーにとって扱いがはるかに難しくなります。
* **リソース使用量を抑える。** アプリの実行がリソース（RAM、CPU、ディスク）を消費しすぎないようにします。ワーカーはアプリと並行して動作するため、重いローカルスタックはミッションを遅くしたり不安定にしたりします。
* **入力を送る手段を用意する。** ユーザーと同じようにアプリを操作するためのプログラム的な手段を Droid に与えます。Web アプリ、Electron アプリ、ターミナル UI アプリケーションの QA テストを可能にするため、いくつかのツール（`tuistory` と `agent-browser`）をデフォルトで提供しています。アプリがこれらのいずれにも該当しない場合は、Droid に操作用のカスタムツールチェーンを与える方法を見つけることを強くお勧めします。

<Warning>
  ディスクに書き出されたログには、シークレット（認証情報、トークン、セッション ID、PII など）が含まれることがあります。特に共有マシンや、ログが CI アーティファクトとしてアップロードされる場合は注意が必要です。機密フィールドはマスキングし、ログファイルのアクセス権限を制限し、バージョン管理（例: `.gitignore`）や CI アーティファクトの収集対象から除外してください。
</Warning>

## コストと期間の見積もり

大まかな計画のヒューリスティックとして、ミッションの期間とコストはワーカーの実行回数に比例します：

* **機能ワーカー：** 機能あたり約1回の実行
* **検証ワーカー：** 各マイルストーンあたり2回の実行（検証が最初の試行で通る前提）

つまり、初期見積もりは約：

`total runs ≈ #features + 2 * #milestones`

実際には、これは上限ではなく下限です。検証でフォローアップ作業が必要な問題が浮上する可能性があり、オーケストレーターは実行中に追加の修正機能を作成できます。

## 関連項目

* [Factory Missions 概要](/jp/features/missions/overview) -- コンセプトと動作の仕組み
* [CLIでの実行](/jp/cli/features/missions/running-cli) -- 承認済みプランの実行と操作
* [設定とリファレンス](/jp/features/missions/reference) -- ワーカーとバリデーターを制御する設定
