AIは、指示された条件から複数の案を出し、コードを書き、テスト候補を作るのが得意です。作業の速度と選択肢の量を大きく増やしてくれます。
しかし、どの案が目的に合うか、誰にどんな影響があるか、確認結果を受け入れてよいかは、依頼文の外にあることが少なくありません。
AIが案を作り、人間が責任を持って決める。 この分担を曖昧にしないことが、Vibe Codingを安全な開発へ変える出発点です。
このレッスンの目的
このレッスンを終えると、作業を「AIへ任せる」「人間が判断する」「証拠で確認する」の三つへ分けられます。
さらに、受入条件を先に書き、AIの自己評価ではなく、画面、操作、テスト、差分から結論を出せるようになります。
判断を全部自分で抱える必要はありません。 何を任せ、どこで止め、何を見て決めるかを設計することが人間の役割です。
所要時間の目安は、読了9分 + 実習13分です。
実習13分では、操作確認条件と期待結果を定義します。画面の実装とキーボード・エラー操作の実行は、後続のUI実装駅とテスト駅で行います。
概念：生成、確認、決定を分ける
AIとの開発には、似ているようで役割の違う三段階があります。
- 生成：文章、画面案、コード、テスト候補を作る
- 確認：受入条件に照らして、実際の結果を観測する
- 決定：採用、修正、保留、停止のどれにするか選ぶ
手順
生成と決定の間に確認を置く
AIの案をそのまま採用せず、受入条件に沿った観測を挟んで人間が決める流れです。
- NODE 1目的と条件人間が先に定義
- NODE 2AIが生成案、コード、テスト候補
- NODE 3証拠で確認画面、操作、テスト、差分
- NODE 4人間が決定採用、修正、保留、停止
たとえばAIが三つのフォーム案を作り、すべてに「アクセシビリティ対応」と説明を付けたとします。人間は説明の有無ではなく、先に決めた受入条件へ案を戻します。題名が空のときに理由と修正方法が同じ場所で分かるか、キーボードだけで操作順をたどれるか、登録後の変化が伝わるかを一つずつ観測します。自動テストが通れば、繰り返し確認できる証拠として残します。実操作で迷った点は、画面と文言の改善材料として記録します。両方を見たうえで、採用、修正、保留、停止を人間が選びます。この分担なら、AIの速さを保ちながら、合格基準がAI自身の説明へ引っ張られるのを防げます。
任せる範囲が広くても、合格の根拠は人間が保持します。
AIは生成を高速化できます。確認も、テストの実行や差分の整理で支援できます。それでも、何を成功とみなすか、確認が十分か、外部へ出してよいかは人間が決めます。
人間が手放さない四つの判断
目的の判断では、誰のどんな不便を減らすかを決めます。AIは案を広げられますが、その課題へ取り組む意味までは自動で保証しません。
受入条件の判断では、何ができれば成功かを具体化します。「使いやすくする」ではなく、「キーボードだけで登録でき、エラー時に修正箇所が分かる」のように観測可能にします。
安全の判断では、入力してよいデータ、外部影響、権限、停止条件を決めます。秘密情報を貼らない、外部送信は確認を挟む、といった境界です。
公開の判断では、検証結果と未確認事項を見て、第三者へ届けるか決めます。AIの「問題ありません」は、公開判断の根拠になりません。
関係
人間が手放さない四つの判断
生成作業の周囲で、目的、受入条件、安全、公開の判断を人間が保ち続けます。
人間が責任を持つ判断
- NODE 1目的誰の何を良くするか
- NODE 2受入条件何を成功とするか
- NODE 3安全入力と外部影響の境界
- NODE 4公開証拠と未確認から決める
アクセシビリティは人間の目的から始まる
アクセシビリティのチェック項目をAIに列挙させることはできます。しかし、実際の操作順、読まれるラベル、見え方、エラーからの戻りやすさは、利用状況に沿って確認する必要があります。
規格名を含むことと、使えることは同じではありません。 自動テストが通っても、キーボード操作や読み上げの流れを人間が試す価値は残ります。
マトリクス
確認方法を性質に合わせて選ぶ
繰り返しやすさと人の解釈が必要かという二軸で、自動確認と実操作を配置します。
実習：判断分担表を作る
前のレッスンと同じ、架空の「まちの読書メモ」を使います。実在する人、書籍の記録、連絡先は使いません。
今回の依頼は「架空の本の題名と一言メモを登録するフォームを考える」です。まず、次の受入条件を書いてください。
受入条件
1. 題名が空なら、入力欄の近くに理由と修正方法が表示される
2. キーボードだけで題名、一言メモ、登録ボタンへ順に移動できる
3. 登録後に、架空の題名とメモが一覧へ一件追加される
4. 実在する情報や外部送信は使わない
分担表は、職種名を並べる表ではなく、判断がどこで行われるかを見えるようにする道具です。まず、AIには比較できる複数案や確認候補を作らせます。次に、人間は目的と受入条件を基準に、どの証拠を自動で集め、どの操作を自分で試すかを決めます。結果が条件を満たさなければ、曖昧な「もっと良くして」ではなく、観測した差を一つだけ修正依頼へ戻します。外部送信や公開が関わる行には、実行前の確認者と停止条件も書きます。未確認が残る場合は、合格へ丸めず、保留の理由としてそのまま残します。こうして生成、確認、決定を別の行にすると、速い試行錯誤の中でも責任の所在と次の行動を見失いません。
良い分担表は、未確認を隠さず次の確認へ渡します。
次に、表を三列で作ります。
比較
AI担当と人間担当を動詞で分ける
AIへ任せる生成作業と、人間が証拠を見て決める作業を同じ基準で比較します。
作業 担当 確認方法
フォーム案を三つ作る AI 案の差分を読む
入力エラーの文案を作る AI 受入条件1と照合する
採用する構成を選ぶ 人間 目的と操作順で比較する
操作確認条件を定義する 人間 Tab順と期待結果を書く
外部へ公開するか決める 人間 検証結果と未確認を読む
AIへ依頼する場合は、目的、制約、受入条件を一緒に渡します。
架空の読書メモ登録フォームを3案提案してください。
実在する情報や外部サービスは使いません。
題名が空のときは、理由と修正方法を入力欄の近くへ表示します。
キーボードだけで題名、一言メモ、登録へ移動できる案にしてください。
各案について、確認が必要な点を最後に列挙してください。
AIへ「最善の案を決めて」と任せず、比較できる材料を作らせるのがポイントです。
正常な結果
次の6項目を自己採点します。
- AIが生成する作業を動詞で書いた
- 人間が決める事項を目的、安全、受入条件、公開に分けた
- 各判断に使う画面、操作、テスト、差分を指定した
- キーボード操作とエラー修正の操作確認条件と期待結果を定義した
- 未確認事項を合格へ丸めず保留として残した
- 外部影響の前に確認者と停止条件を置いた
6項目すべてが証拠と結び付けば正常です。
よくある失敗
失敗1：AIへ実装と合格判定を同時に任せる
作った側の説明だけを読むと、見落としを拾いにくくなります。実装報告と、独立した確認結果を分けてください。
失敗2：受入条件が形容詞だけになる
「分かりやすい」「安全」「きれい」は方向として大切ですが、そのままでは合否を決められません。操作と結果へ置き換えます。
失敗3：自動テストだけで利用体験を確定する
自動テストは再現性の高い証拠です。一方で、読み順、言葉の理解、狭い画面での見え方など、実際に使って初めて分かる点があります。
失敗4：人間の担当が「全体を見る」だけになる
範囲が広すぎると確認が抜けます。目的、安全、受入条件、公開の四つへ分けます。
復旧：判断を一つ前へ戻す
AIの提案を採用したあとで不安が出たら、まず変更を増やすのを止めます。採用した理由、見た証拠、見ていない点を三行で書きます。
採用した理由: 入力欄が少なく、架空のメモ登録に必要な要素が揃っていた
見た証拠: 画面表示と、題名ありの登録を確認した
未確認: 題名なしのエラーと、キーボードだけの操作
次に、未確認のうち一つだけを試します。失敗した場合は受入条件へ戻り、修正依頼を出します。新しい機能を足して隠しません。
復旧とは、AIへ言い換えを繰り返すことではなく、判断と証拠の対応を取り戻すことです。
状態遷移
不安が出たときの判断の戻し方
採用済みの案へ変更を重ねず、理由、証拠、未確認を分けて再判断します。
- STATE案を採用理由を持って選んだ
- STATE不安を検知追加変更を止める
- STATE証拠を整理見たことと未確認
- STATE再判断修正、保留、停止
遷移
- 案を採用 → 不安を検知：受入条件との差を発見
- 不安を検知 → 証拠を整理：理由と観測を分ける
- 証拠を整理 → 再判断：一つの未確認を試す
- 再判断 → 案を採用：合格した場合だけ採用
安全メモ
AIへ入力してよい情報は、利用しているサービスの規約、組織のルール、データの性質によって変わります。この実習では、その判断を持ち込まずに済むよう、明らかなダミーデータだけを使います。
課金、送信、公開、削除、権限変更などの外部影響がある操作は、生成作業と切り離してください。AIが操作できる環境でも、実行前に対象、範囲、戻し方を人間が確認します。
AIの提案に法的、医療的、契約上の判断が含まれる場合は、この教材だけで結論を出しません。該当する専門家と正本を確認します。
成果物
このレッスンの成果物は「判断分担表」です。最低でも次の項目を含めます。
- AIへ任せる生成作業
- 人間が決める事項
- 各判断に使う証拠
- 外部影響の前に置く確認点
- 未確認を保留として残す欄
表の価値は担当者を固定することではなく、判断が消えないようにすることです。作業内容が変わったら分担も更新します。
用語集
入力の合否と、利用できる体験の合否を別の証拠で判断します。
参考・一次資料
- Web Content Accessibility Guidelines (WCAG) 2.2：アクセシビリティの受入条件を作るときのW3C勧告。規格名だけで合格にせず、対象とする達成基準と実操作を確認します。
次の駅
企画上の次駅
架空企画は引き続き「需要検証駅」に留まり、判断分担表を使って未確認の仮説を整理します。
ここで定義した操作確認の実行先は、要件を固めた後の「UI実装駅」と「テスト駅」です。導入編では、合格条件を先に作るところまでを扱います。
教材上の次レッスン
次は「ダミーデータと秘密情報」です。人間が安全線を決めても、入力するデータと設定値が混ざっていれば事故は防げません。
実在する情報を持ち込まずに機能を試し、秘密の値をコードや会話から分離する準備へ進みます。
今日のまとめ
3行で振り返ります。
- AIは生成と確認を支援できるが、目的、安全、受入条件、公開は人間が決める
- 判断分担表には担当だけでなく、合否を決める証拠と確認方法を書く
- 不安が出たら変更を増やさず、採用理由、見た証拠、未確認へ戻る