直ったって言ったじゃん！ なんで動かないの？ | アカバネ・レッドの開発日誌17

AIもコーディングも初めてのスナックガールズが、実際に試して、つまずいたところを一つずつ学んでいく開発日誌です。今回は、AIの修正結果をどう確認するか、小さなボタンの練習と実際のWordPressサイトの作業を一緒に見ていきます。

先にボタンを押してみる？ ↓

直ったって返事は来たのに、ボタンはそのまま

こんにちは、レッドだよ。AIが長い説明の最後に「修正完了」って書いてくれると、ひとまずうれしいよね。難しい説明は全部わからなくても、これで動くんだろうなって思うし。

でも、その返事だけ読んで画面を閉じると、見落とすものがあるの。ファイルを直したことと、使いたかった機能がちゃんと動くことは、別々に確認しないといけない。今日は開始ボタンを押しながら、その違いを見てみよう。

まず「壊れた例」で開始を押してみて。そのままでしょ？ 今度は「修正した例」でも同じボタンを押してみよう。画面が変わったら、戻るも押してみて。最初の画面がきれいに表示されるのを見ただけでは、この違いはわからないよ。

キラリ

ちゃんと押したんだけど。シロちゃんもやってみて。

ネア

私もそのままです。どこで押したか、書いておきますね。

サイトの作業記録にも、まだ確認することがあった

小さなボタンの練習だけだと、ちょっと実感が湧かないよね？ 実際にWordPressサイトを手直しした記録も持ってきたよ。9月14日に、開発日誌の下に「前の回・次の回・全一覧」へ読み進める欄を付けたの。韓国語の記事からは韓国語の回へ、英語と日本語の記事からは同じ言語の回へ移動できるようにする作業だったんだ。

コードの検査と公開APIの確認は通ったよ。APIは、サイトにデータを頼んで受け取るための窓口。ここでは、続きを読む欄にどの記事が入るかを確認できたの。でも、通常の公開URLで記事を開くと、英語の第1回・第6回と日本語の第6回には古い画面が残っていた。この記録を読むと、データを受け取れると確認しただけで、読者の画面も変わったと思っちゃいけないんだなって感じたよ。

当時の記録で確認された原因は、キャッシュだった。キャッシュは、ページを素早く表示するために一時的に保管しておくコピーだよ。新しいコードを入れても、保管された古いページが出てくると、読者には前の画面が見えるの。このときはキャッシュを手動で消さず、自然に更新されたあと、同じ公開URLをもう一度確認したよ。9月14日午後9時46分（韓国標準時）の再確認記録には、三つの記事すべてに続きを読む欄と自動更新スクリプトがあると残っているんだ。

配置も別に直したよ。最初は続きを読む欄が共有・いいねのあとにあったんだけど、ハッシュタグのすぐあとに移して、実際のページで順番をもう一度確認したの。「欄がある」と「読者が読んでいる途中で見つけやすい場所にある」も、別の確認なんだね。元の本文と予約時刻が変わっていないかも、一緒に検査したよ。

レッド

コードはできてても、私が見てる画面は前のままってこともあったんだね。

ネア

そういうこともあります。同じURLをもう一度開いて、どこまで変わったか確認する必要がありますね。

この記録を読んだので、今回のボタンの練習でも「ボタンができた」で終わりにしないつもり。押すとどこへ行くか、戻れるか、もう一度やっても同じか、別々に見てみよう。それから、画面がそのままだからって、すぐキャッシュのせいにしないこと。今回のサイト作業ではキャッシュだったけど、別の問題なら原因を改めて調べないといけないからね。

「動かない」のあとに、何を伝えればいい？

壊れたボタンの例に戻ってきたよ。私はすぐ直してもらおうとしたけど、その前にキラリが押した場所をもう一度見たの。開始ボタンで、何も変わらなかった。そこまでは確認できた。でも、なぜ動かないのかはまだわからない。見た現象と、推測した原因を混ぜないことが先だよ。

AIにも「ボタンのコードが間違ってる」と原因を決めて伝えるより、同じ状況をもう一度見られるように説明しよう。こうして問題をもう一度起こすことを、再現というよ。

スクリーンショットはどこを押したかを見せるのに便利で、短い画面録画は押したあとに何が起きたかを見せるのに便利だよ。エラーメッセージは勝手に短くせず、コピーしてね。ただし、パスワードやログイントークンなどの秘密の値は隠してから送ろう。エラーメッセージが出なかったなら、そのことだけ書けば大丈夫。

レッド

「何も反応しない」も説明になるんだね。原因がわからなくても。

AIKO

はい。同じ手順で確認できれば、原因を探す助けになります。

一度に直すのは、一つから

ボタンを直すついでに、色も変えたいし、音楽も入れたいし、メニューも増やしたくなった。でも今回は我慢することにしたよ。一度に変えると、また動かなくなったときに、どの変更から見ればいいか私も迷いそうだから。

修正する前には、戻れるコピーを残しておこう。ファイルが少なければ作業フォルダーをコピーできるし、Gitを使っていれば、今の変更を確認してから保存する時点を残せるよ。どのバージョンだったか、何ができて何ができなかったかも一緒に書いておくと、戻したあとに比べやすいよ。

関連ファイル：[実際のファイルパス]
実行方法：[コマンドまたは開く手順]
使用環境：[端末 / ブラウザーまたはアプリのバージョン]

最初の画面で「開始」を一回押すと
練習画面が開くはずなのに、最初の画面がそのまま残っています。
添付した画面とエラーメッセージを参考にして。

まず同じ手順で問題を再現して、原因を確認して。
開始ボタンと画面の切り替えに必要なところだけ修正して。
ボタンの文言、色、位置、ほかのメニューの動作は維持して。

修正後は、開始 → 練習画面 → 戻るを確認して。
最初の画面に戻ったあと、もう一度開始しても動くか確認して。
確認した環境、実際の結果、変更したファイルを教えて。
実行していない確認項目は、未確認のまま残して。

すでにほかの人が同じファイルを直していたら、そのことも伝えてね。AIが修正前の状態に戻そうとして、ほかの作業まで消してしまうと困るから。今回の問題と関係のない変更が混ざっていたら、適用する前に別に見てみよう。

テスト合格？ 何を試したの？

修正した例では画面が変わるよ。それで終わりかな？ 私は戻るを押して、もう一度開始してみた。今回の目標には戻ることも入っていたからね。キラリは、ウィンドウを狭くしてボタンが隠れないかも見ようと言ったよ。

AIが「テスト合格」と教えてくれたら、何を、どこで、どう確認したか聞いてみよう。コードの一部を検査した結果だけでは、実際にボタンをクリックしたところまで確認したとはいえないよ。

ボタンがあるかだけを検査すると、押しても何も反応しないボタンが合格することもあるよ。「開始を押すと練習画面が表示される」のように、ユーザーが期待する結果を確認しないといけない。Playwrightのテスト指針でも、ユーザーに見える動作を検査することを勧めているよ。Playwrightのテスト作成ガイド

PCで動いたからといって、スマホでも確認したわけではないよ。ウィンドウを狭くすることと、実際のスマホでタップすることも違うからね。使う予定の端末で大事な動作から確認して、試せなかった環境は書き残そう。MDNのブラウザー・端末別テストガイド

キラリ

シロちゃん、スマホでも押してみる？ 私、外でも見るつもりなんだ。

ネア

いいですね。それはまだ試していませんから。

今回は私が先に押してみた

これからは「修正完了」って返事が来ても、すぐ終わりにはしないつもり。もともと動かなかった手順でもう一度試して、維持してほしいと頼んだところも一緒に見るよ。問題が残っていたら、どこまで動くか書いて、続きを進めればいいんだよね。

自分で確認したなら、練習の記録はこう残せるよ。「PCで開始 → 練習画面 → 戻る → もう一度開始を確認。実際のスマホでは未確認。」まだ押していないなら、確認したと書かないこと。試していないことも残しておけば、次の人もどこから見ればいいかわかるよね。

私はキラリのほうにノートPCを向けた。今回は自信があったよ。キラリがマウスを握ると、ネアも椅子を少し寄せたの。説明しかけていた私は、ただ隣で見ることにした。二人がどこで止まるのか、気になったんだ。

#バイブコーディング #開発日記 #AIコーディング #AI自動化 #ブログ自動化 #AI初心者 #スナックガールズ #AI修正 #ソフトウェアテスト