コーディングエージェント向け修正指示に変換する

まず確認する症状

• 所見はあるが、開発者がどこから直すべきか分からない。
• 修正後の確認条件がなく、直ったか判断できない。
• レビュー所見は理解できるが、開発者やコーディングエージェントが触る範囲と完了条件を判断できない。
• 修正、検証、再スキャン、残課題化の流れが分かれておらず、1つの大きな依頼になっている。

なぜ問題か

• 自動開発では、曖昧な指摘よりも受け入れ条件つきの小さな作業単位が重要です。
• ツール名に依存しないMarkdown/JSONにすると、顧客の開発環境を選びません。
• AI実装では、曖昧な改善案よりも、対象、制約、受け入れ条件、検証コマンドが揃った小さなタスクが成功しやすくなります。
• 成果物をMarkdownやJSONで残すと、別の人や別のエージェントが途中から再開しやすくなります。

診断で見る指標

修正方法

受け入れ条件

1. 01PCとスマホの両方で目視確認し、主なCTAまたは操作対象が迷わず見つかる。
2. 02キーボード操作、読み上げ補助、または自動検査で再発しやすい項目を確認する。
3. 03修正後にui.designで再スキャンし、同じ所見が残る場合は原因を分解する。
4. 04各タスクに、目的、対象、変更内容、非目標、受け入れ条件、確認コマンドまたは確認手順がある。
5. 05修正後に、解消した所見、残った所見、新しく出た所見、確認不能な所見を分けて記録している。
6. 06AIに渡す指示は、目的、対象、制約、修正方針、受け入れ条件、確認方法を含む。
7. 07複数レーンの課題は、CV、UX、アクセシビリティ、SEO、計測のどれを先に直すか分かれている。

参考資料

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

よくある失敗

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

関連ページ