AIに「いい感じに直して」「バグを修正して」「全部対応して」と頼めば、何らかの結果は返ってきます。問題は、返ってきたものが本当に完了なのかを判定できないことです。AIに任せる仕事を安定させたいなら、作業のお願いではなく、検収条件を渡します。
曖昧な依頼では、重要な失敗が見えない
「改善」の意味は、依頼する人とAIで一致しません。見た目が整っていても、SaaSなら別の問題が残ります。課金前に処理が走らないか、無料枠を無限に使えないか、エラー時に課金だけ発生しないかを確認しなければなりません。スマートフォンで主要CTAが見えるか、titleとmeta descriptionが重複していないか、多言語ページのリンクが正しいか、本番ビルドで壊れていないかも同じです。
これらを指定しなければ、AIは見える範囲の修正を完了として扱う可能性があります。依頼文の長さではなく、完了を判定する条件の具体性が重要です。
依頼文を小さな仕様書にする
まず「何を作業するか」ではなく「何が成立すれば終わりか」を書きます。目的には達成したい状態、対象にはページ・機能・関連ファイルを記入します。優先度はP0、P1、P2に分けます。P0は利用不能、課金・権限・データ整合性、本番公開停止に関わる問題です。P1は主要導線、利用体験、転換に大きく影響する問題。P2は軽微な表示や文言、将来改善です。
成功条件は「条件YではXが動く」「条件Zでは安全に失敗する」のように書きます。禁止事項には、既存の正常動作を壊さない、不要な大規模リファクタをしない、秘密情報を出力しない、モックの課金処理を本番扱いしない、といった境界を置きます。
そのまま使える検収条件
# 目的
Xの不具合を修正し、限定公開できる状態にする。
# 対象
- ページ:
- 機能:
- 関連ファイル:
# 優先度
P0: 利用不能、課金・権限・データ整合性、本番公開を止める問題
P1: 主要導線や利用体験に影響する問題
P2: 軽微な表示・文言、将来改善
# 成功条件
- 条件YでXが動く
- Zでは安全にエラーになる
- 認証前に有料APIを呼ばない
- スマートフォンで主要CTAが見える
- テストが通る
# 禁止事項
- 既存の正常動作を壊さない
- 秘密情報を出力しない
- 不要な大規模変更をしない
# 確認手順
1. Xを実行する
2. Yを開く
3. Zの条件を確認する
4. エラー時の表示を確認する
5. 結果を一覧化する
# 最終報告
- 変更ファイル
- 実施したテスト
- 残るリスク
- 人間が確認する項目
空欄を対象のページや条件で埋めれば、AIが作業範囲と終了地点を読み違えにくくなります。
「未確認」を完了報告と同じ重さで出させる
AIには「未確認リスクと、本番公開前に人間が確認すべき項目を列挙してください」と最後に明記します。完了という言葉だけを受け取ると、本番環境、決済、モバイル表示、異常系、多言語ページのどこまで試したのか分かりません。確認していないことを明示させれば、実装済みの範囲と人間の担当範囲を切り分けられます。
LP改善なら条件を画面と手順に落とす
たとえばLPのCTAを改善する場合は、「改善して」で終わらせません。App StoreとGoogle Playのうち存在するストアボタンだけを表示する、ファーストビューの主要CTAを1つにする、記事中盤にも自然なCTAを置く、titleとmeta descriptionを重複させない、幅375pxで表示崩れがないことを確認する、と指定します。最後に変更ファイル、確認手順、未確認リスクを報告させます。
AIは速く実装できますが、正解の境界を決めるのは人間です。検収条件があれば、AIの「完了」を、確認可能な成果へ変えられます。
