おはようございます！株式会社ファストコーディングの働くおかんです。
例えば、家族に「子どもの水筒を洗っておいて」と頼むとします。こちらは、本体だけでなく、ふたやパッキンも洗って、また使える状態になるところまで思い浮かべています。でも、その全部を毎回言葉にしているわけではないんですよね。
Webの修正依頼にも、そんな省略があります。「スマホのメニューがはみ出すので直してください」。この一言に、私たちは「項目を選べることも、閉じられることも、そのままで」という期待を込めています。
AIに修正を任せるときも、その期待まで渡せているでしょうか。今回は、メニューの表示崩れを例に、直したい箇所と一緒に伝えたい、周辺の機能と確認範囲を考えてみます。
「ここを直して」に含めている、言葉にしていない期待
人間の制作担当者なら、メニューを直した後に、リンクを選んだり、開閉を試したりすることを期待しますよね。依頼された箇所の見た目だけでなく、その画面が使える状態かまで見て返してほしいからです。
もちろん、人間でも確認が抜けることはありますし、AIが関連する機能を自分で調べる場合もあります。ただ、どこまで調べて確かめるかを伝えずに、「周りも見てくれるはず」と任せると、こちらの期待と完了の判断がずれる余地が残ります。
私が依頼に加えたいのは、修正方法の細かな指定よりも、「何ができる状態を保ってほしいか」です。見た目の修正だけを頼んだつもりはなくても、依頼文には見た目のことしか書いていない。そんな食い違いを、次の例で見てみます。
メニューのはみ出しを隠しても、閉じるボタンは戻らない
比較のために、スマホ幅でメニューがはみ出すデモを作りました。実案件や、AIが実際に誤った修正をした記録ではありません。依頼する範囲によって、何を見落とし得るかを示す検証例です。
幅390pxでページを開いた時点では、表示は収まっています。ところが、メニューを開くとパネルが右へはみ出し、右側にある「閉じる」ボタンも画面外へ出ます。直したいのは、このメニューを画面内に収め、項目を選んだり、ボタンで閉じたりできる状態にすることです。
ここで「横にはみ出すのを直して」という依頼を考えます。ページの横方向にはみ出した部分を隠すと、横スクロールは見えなくなります。でも、メニュー自体の幅は変わりません。今回のデモでは、閉じるボタンは画面外のままでした。
一方、メニューの幅を画面内に収めた案では、閉じるボタンも見えるようになりました。同じ「はみ出しを直す」でも、利用者が操作できる状態に戻ったかどうかは違うんです。
隠す案でも、キーボードのEscでは閉じられます。「一切閉じられない」という結果ではありません。ただ、スマホの画面上で閉じるボタンを押せる、という目的は満たしていません。
はみ出しを隠す方法が、いつも悪いわけではありません。この例で見てほしいのは、「横スクロールが消えた」という確認だけでは、メニューの機能まで直ったと判断できないことです。
AIには、修正箇所と周辺の機能をセットで渡す
この違いを依頼に反映するなら、最初に何を渡し、AIの返答を見て何を追加するかまで考えたいです。私なら、次の順番で進めます。以下は今回の検証例をもとに整理した依頼例で、実際の会話ログではありません。
1. 画面とコードを渡し、まず原因と影響範囲を聞く
対象ページ、開く前と後の画像、再現手順を渡します。併せて、AIが調べられる場所に対象のHTML・CSS・JavaScriptを用意します。URLだけでソースや検証環境にアクセスできるとは限らないので、読める資料と使える環境も伝えます。
添付の画面とコードを確認してください。幅390pxでメニューを開くと、右側と閉じるボタンが画面外へ出ます。開く前は収まっています。まだ変更せず、再現できるか、原因は何か、修正が開閉処理やリンクに影響しそうかを整理してください。再現できなければ、不足する情報を教えてください。
返答では、実際に確認した結果と推測が分かれているかを見ます。足りないファイルや操作条件が挙がったら、それを追加します。原因を確かめずに「右側を隠す」と決めるところから始めないためです。
2. 調査結果に、維持したい動作を足して修正を頼む
次に、前の調査結果を踏まえ、期待する状態を渡します。別の会話やAIへ引き継ぐなら、対象コードの版と調査結果も一緒に渡します。
調査結果を踏まえて修正してください。メニュー項目と閉じるボタンを画面内に収め、項目を選び、ボタンで閉じ、再び開ける状態にしてください。本文、商品一覧・お知らせのリンク先、Escで閉じる動作は維持してください。ほかに影響する機能が見つかった場合も確認対象へ含め、仕様の判断が必要なら勝手に変えず知らせてください。
ここで渡すのは、近くにある要素だけではありません。同じ開閉処理やリンク先など、動作がつながっているものも含みます。すべての影響先を私たちが先に知る必要はなく、分かっている期待を渡し、残りはAIに調べてもらいます。
3. 変更内容を受け取り、同じ条件で確認を頼む
修正されたコードと変更箇所の説明を受け取ったら、最初の再現条件を確認にも使います。自分の画面でまだ崩れる場合は、その画像と操作手順を追加し、同じ修正版を対象に調べてもらいます。
修正版を、指定した検証環境で確認してください。幅320px・390px・768px・1280pxで、開く、項目を選ぶ、閉じる、再び開く操作と、リンク先・Escの動作を確かめてください。確認した環境、操作ごとの結果、未確認の範囲を分けて報告してください。実行できない項目は、確認済みにしないでください。
「調べてもらう→期待する動作を渡す→修正版の確認結果を受け取る」という流れです。プロンプトの文言をコピーするだけでなく、その時点の資料と、前の返答で分かったことをつないで渡すと、周辺の確認も依頼の中に残せます。
「直しました」の報告も、周辺の動作まで見る
依頼に確認範囲を足しても、返ってきたスクリーンショットだけで終えたら、また見た目だけの判断に戻ってしまいます。AIからの報告にも、何を試し、どこまで確かめたかを含めてもらいます。
今回のデモでは、幅を直した版を320px・390px・768px・1280pxで確認しました。メニューを開閉し、もう一度開き、商品一覧とお知らせのリンク先も確かめています。閉じた後に、開くボタンへフォーカスが戻ることも確認しました。
こうした結果があれば、「見た目が収まった」だけでなく、「そのメニューを引き続き使えるか」まで判断できます。なお、今回はデスクトップのブラウザで表示幅を変えた検証です。実際のiPhoneやAndroid端末での確認はしていません。確認済みと未確認を分けることも、報告に含めたいところです。
AIへの「ここを直して」には、直したい箇所に加えて、関連する機能、維持したい動作、修正後の確認を添える。人に任せるときに期待している範囲を、AIへの依頼では言葉にして渡しておきたいと思います。
次の修正依頼では、「この変更の後も、何ができる必要がある？」と一度考えてみてください。メニューなら、開けて、選べて、閉じられる。その一連の操作まで依頼に入れると、AIと共有する完了の基準が具体的になります。
当社のAI駆動HTMLコーディング代行でも、表示だけでなく動作や修正後の確認を含めて制作を進めています。AIによる改修や、その確認範囲に迷ったときは、直したい画面と維持したい動作を添えて、ファストコーディングへご相談ください。
参考情報
比較例の表示制御と、検証方法の範囲については、次の資料も参照しました。
本文の動作結果は、今回作った検証用デモで確かめた範囲です。特定のAIが同じ修正や確認をすることを示す実験ではありません。
