レビュー所見を修正仕様に落とす

まず確認する症状

• 『CTAを強くする』だけで、どのCTAをどう変えるか決まっていない。
• デザイン変更と文言変更と計測変更が1つの大きな作業に混ざっている。
• レビュー所見は理解できるが、開発者やコーディングエージェントが触る範囲と完了条件を判断できない。
• 修正、検証、再スキャン、残課題化の流れが分かれておらず、1つの大きな依頼になっている。

なぜ問題か

• 自動コーディングでは、曖昧な目的語や広すぎるタスクが失敗の原因になります。
• 非目標を明記すると、余計なリファクタリングやデザイン崩れを防げます。
• AI実装では、曖昧な改善案よりも、対象、制約、受け入れ条件、検証コマンドが揃った小さなタスクが成功しやすくなります。
• 成果物をMarkdownやJSONで残すと、別の人や別のエージェントが途中から再開しやすくなります。

診断で見る指標

修正方法

受け入れ条件

1. 01PCとスマホの両方で目視確認し、主なCTAまたは操作対象が迷わず見つかる。
2. 02キーボード操作、読み上げ補助、または自動検査で再発しやすい項目を確認する。
3. 03修正後にui.designで再スキャンし、同じ所見が残る場合は原因を分解する。
4. 04各タスクに、目的、対象、変更内容、非目標、受け入れ条件、確認コマンドまたは確認手順がある。
5. 05修正後に、解消した所見、残った所見、新しく出た所見、確認不能な所見を分けて記録している。
6. 06修正仕様には、何を変えるかだけでなく、何を変えないか、どう確認するかが書かれている。
7. 07広いUI改修は、文言、構造、スタイル、計測、データ契約に分けて扱われている。

参考資料

• llms.txt proposal
• Chrome Lighthouse: llms.txt
• W3C WCAG 2.2 Techniques

よくある失敗

• 『いい感じに改善』のような曖昧な指示を残す。
• 見た目だけを整え、見出し、リンク、フォームラベルなどの意味構造を直さない。
• 1つの指摘だけを直し、同じ原因から出た別画面の再発を確認しない。
• 広すぎる一括依頼をAIへ渡し、関係ないリファクタリングやUI変更を混ぜる。
• 結果JSON、report.md、tasks.json、証跡画像のどれを正として見るか決めない。

関連ページ