何が変わったか：Slackのスレッド、サポートチケット、営業メモ、Jiraの課題など、シグナルはさまざまな場所に散在しています。ツールをまたいで作業するうちに、背景情報が失われがちです。なぜ重要か：要望の背後にある「なぜ」を見落とすと、スプリントが無駄になります。影響を受ける人：解決すべき課題の優先順位を決めるプロダクトマネージャー、リサーチ責任者、カスタマーサクセスチーム。実践のポイント：コネクターを設定し、Discoveryエージェントに会話の記録、文書、チケットを取り込ませます。根拠に基づく課題ボードを使い、発生頻度と深刻度を評価し、代表的な顧客の声を示し、相反するシグナルを明らかにします。リスクと制約：ノイズの多い入力はスコアを歪める可能性があります。サンプリングの偏りを修正するため、人による検証を組み込みましょう。

何が変わったか：優先順位を決める際は、エージェント活用の実現可能性と事業へのインパクトの両方を評価する必要があります。なぜ重要か：コーディングが速くなるほど開発コストは下がり、何に取り組むべきかの判断がボトルネックになります。影響を受ける人：価値、リスク、実現可能性のバランスを取るPM、デザイン責任者、事業関係者。実践のポイント：2つの評価マトリクスを使います。1つはLLMやツールとの適合性、運用準備度を0～10で評価し、もう1つはインパクト、工数、規制面を評価します。Prioritizeエージェントに、根拠を追跡できる順位付き評価マトリクスを作成させ、各スコアの簡潔な理由も記録します。リスクと制約：評価の重みづけには戦略が反映されます。あらかじめ設定して文書化し、新たな根拠が得られたら再評価しましょう。

何が変わったか：設計では、コーディングエージェントとの契約としても機能する成果物を作る必要があります。なぜ重要か：受け入れ条件を明記した仕様は曖昧さを減らし、企画から提供までを加速します。影響を受ける人：仕様を受け取るUXチーム、PM、エンジニアリング責任者。実践のポイント：Working BackwardsエージェントでPR/FAQを作成し、Spec Generatorでユーザーフロー、ペルソナ、受け入れ条件、デザイン引き継ぎ概要書に落とし込みます。各要件が、その根拠となる課題と優先順位の文脈を参照していることを確認しましょう。リスクと制約：仕様を細かく定めすぎると、エンジニアの創造性を損なうおそれがあります。実装担当者が同等の代替案を提案できるよう、「制約と意図」のセクションを設けましょう。

何が変わったか：Designerエージェントは、オーケストレーターと同じワークスペース内でワイヤーフレーム、カスタマージャーニーマップ、クリック可能なHTMLプロトタイプを生成できます。なぜ重要か：素早く作ったプロトタイプを使えば、コードを書く前に関係者や顧客が仮説を検証し、誤りを見つけられます。影響を受ける人：エンジニアリングが着手する前に承認する必要があるリサーチャー、UX担当者、関係者。実践のポイント：既知の領域にはFast Track、新しい課題にはDeep Discoveryを使います。クリック可能なプロトタイプで短時間のユーザビリティテストやコンシェルジュテストを実施し、指標や顧客の声を記録して、課題ボードに反映します。リスクと制約：プロトタイプによって、実際以上に完成度が高いという誤解が生じることがあります。デザイン実験では、学習目標と合格基準を明確にしましょう。

何が変わったか：KiroやClaude Codeなどのコーディングエージェントは、Agent Client Protocol（ACP）を通じて構造化された仕様を受け取り、実用的なコードをすばやく生成できます。ただし、決定性のある明確な仕様が必要です。なぜ重要か：受け入れテストを含む開発着手可能な仕様があれば、製品の意図と実装の隔たりを埋められます。影響を受ける人：エンジニアリングマネージャー、SRE、セキュリティ審査担当者。実践のポイント：要件、データモデル、受け入れ条件、テストケースを1つのprototype_spec.mdにまとめます。引き継ぎにはACP互換のアダプターを使い、仕様を承認または却下する人のレビューを必須にします。リスクと制約：自動ビルドは望ましくない結果も加速しかねません。プライバシー、コンプライアンス、アーキテクチャとの整合性を確認する明示的なチェックポイントを設けましょう。