AWS Quickの企業データ接続を使い、課題発見から優先順位、仕様、試作へ進む構成です。各段階で人の承認を入れ、判断の根拠を残します。 実装の速度に加え、何を作るかの判断を支援します。参照権限、評価軸、仕様の承認者を決めることが導入の焦点になります。 実装前の判断を企業の情報につなぐ AWSは11月11日、AWS Quickで製品開発の上流を支援するAI-PDLCを紹介しました。コードの実装が速くなっても、解く課題や作る体験の選択は残るという問題を扱います。顧客の声、営業の知見、障害の記録、会議の内容は複数のツールに分かれています。Quickの接続を使い、その情報を課題の発見や仕様の根拠へつなぎます。構成は調整役と5つの専門Agentからなる計6つです。記事は発見、判断、設計、試作という前半の工程に焦点を当てています。後半の実装などはコーディングAgentへ引き継ぎます。製品開発の全工程を無人で完了するという提案ではありません。 課題から仕様までの根拠を残す Discoveryは顧客の困り事を整理し、深刻さや頻度を評価します。Prioritizeは重み付きの基準で候補を比べます。Working Backwardsは発表文とFAQの形で、顧客価値や費用、失敗の形を検討します。Spec Generatorは受け入れ条件や制約を含む仕様へまとめます。Designerは画面案や操作できるHTMLの試作を作ります。利用者はOrchestratorと会話し、各段階で確認してから次へ進みます。成果物は共有のSpaceに保存します。判断の記録は専門Agentと調整役の両方が確認する構成です。実装側にはprototype_spec.mdを渡し、要件とその理由を保ちます。開発チームにとっては、単なる作業票ではなく、何をもって完成とするかを説明する材料をそろえる方式になると見られます。 自動生成した仕様を人が選び直せる体制 導入にはQuickの環境、デスクトップクライアント、接続先の設定などが必要です。SlackやJiraなどへ接続する場合、企画の担当者が参照できる情報と共有Spaceの範囲を対応させることが論点になります。優先順位の点数が出ても、その重みや前提が自社の目的に合うかは人が確認します。元の顧客の声が偏っていれば、生成された仕様にも影響する可能性があります。原文は詳しく探索する方式と、少数の質問で進める方式を用意しています。早く試作できることと、必要な検討を終えたことは同一ではありません。仕様の承認、開発への引き継ぎ、試作の受け入れを誰が担うかが判断材料です。実行後に不要なAgentや接続を片付ける手順も示しています。生成の時間だけでなく、情報整理とレビューを含む工程全体で効果を見る必要があると見られます。試作の承認と本番公開の判断も、別の責任として整理します。