AIにUIを実装させ、受入条件で検証する

今日の問い

AIが「実装完了」と答えたあと、あなたは何を見て受け入れますか。

30秒でつかむ

AIへのUI実装指示は、感想ではなく目的、制約、参照、受入条件で渡します。返答ではなく、コード差分、実行したテスト、実画面の操作を根拠に受け入れます。

自動テストは有力ですが、アクセシビリティや使いやすさの一部しか検出できません。キーボード、拡大、支援技術、利用者の行動は、手動確認と利用者テストを組み合わせます。

原則

目的には、利用者が終えたい行動を書きます。「きれいな予約画面」ではなく、「既存予約を確認し、別の日へ変更し、結果を理解できる」です。

制約には、守る境界を置きます。既存のデザイントークン、DOM順、個人情報を使わないこと、対象外の機能、変更してよいファイルを明示します。AIが勝手に範囲を広げにくくなります。

参照には、これまで作った成果物を渡します。primary-flow.mdだけでなく、状態表、画面、コンポーネント状態、アクセシビリティ監査、観察結果をつなぎます。矛盾があれば、実装前に報告させます。

受入条件は、操作して判定できる文にします。「アクセシブルにする」ではなく、「キーボードだけで入口から完了まで進め、各入力欄のラベルとエラーを確認できる」と書きます。正常時だけでなく、入力不備、結果なし、処理失敗も含めます。

実装後は、まず差分を読みます。対象外の変更、既存テストの削除、チェックの無効化がないか確認します。次に型、lint、テスト、ビルドを実行し、最後に指定した画面幅と入力方法で触ります。

Playwrightは、ブラウザー操作の自動化に加え、axeを組み込んだアクセシビリティ検査にも使えます。ただし公式文書も、自動検査で見つかるのは一部であり、手動評価と利用者テストを組み合わせるよう案内しています。自動検査が通ったことを、WCAG適合の証明にしません。

良い例と惜しい例

AIへの指示例

目的: 既存予約を別の日へ変更し、成功または失敗の結果を利用者が理解できるUIを実装する
制約: implementation/以外を変更しない。既存トークンとネイティブHTMLを優先する。テストを削除、無効化しない。実在する個人情報を使わない
参照: primary-flow.md、ui-states.md、screens/、component-states.md、tokens.json、accessibility-audit.md、observations.md
受入条件: 正常、入力不備、空きなし、通信失敗を操作できる。320と1280 CSSピクセルで横方向にはみ出さない。キーボードだけで完了できる。型、lint、テスト、ビルドの結果と未確認範囲を報告する

確認問題

最終制作へ反映する

今日のまとめ

• AIへは目的、制約、参照、観察可能な受入条件を渡す
• 受け入れは完了報告ではなく、差分、自動検査、実操作で判断する
• 次は、公開後に追うイベントとファネルを設計する

次のレッスン

イベントとファネルを設計する