申込フォームや予約フォームを公開する「その瞬間」は、何度経験しても少し手が止まります。見た目のチェックはひと通りできても、実際に入力して送信するところまで、人の目だけで全部確認するのは案外難しいものです。動画制作の現場でも、問い合わせフォームや日程調整の仕組みを作って公開する機会が増えてきました。見た目が整っていても、裏側の送信処理まで本当に正しく動くとは限りません。最近は、公開前にClaude Codeへテストコードを書いてもらい、画面の裏側の動きまで確認する手順を取り入れました。今回はその工程で何を確認しているか、現場の視点でまとめておきます。
見た目のチェックだけでは足りない理由
フォームの不具合は、見た目にはほとんど出ません。入力欄がずれたりボタンの色がおかしかったりすれば目で見て気づきますが、「必須項目が空のまま送信できてしまう」「ある条件のときは送信をブロックするはずなのに、実際はブロックされない」といった不具合は、ブラウザで一通り触っただけでは見逃しやすいのです。公開してから気づいた場合、相手にも迷惑をかけてしまいます。だからこそ、公開前に動きそのものを検証する工程が必要だと感じています。
Claude Codeにテストコードを書いてもらう
具体的には、ブラウザを自動操作するテストコード(Playwrightというツールを使っています)をClaude Codeに書いてもらい、フォームに実際の入力パターンを流し込んで、送信ボタンを押した後の動きまで一つずつ確認します。自分で手入力して試すより速く、しかも何度でも同じ条件で再現できるのが利点です。確認する観点はおおよそ次の3つです。
- 必須項目が入っているときだけ、正しい内容で送信処理が始まるか
- 送信してはいけない条件(たとえば特定の状態や注意書きがある場合)のときに、本当に送信がブロックされるか
- 入力欄に想定外の値が入り込んでいないか、同意のチェックなどが勝手にオンになっていないか
特に2つ目の「送信してはいけない条件で、本当に止まっているか」は、コードを目で読むだけでは安心できない部分です。自分では「こう書いたから大丈夫」と思っていても、実際に動かして確認するまでは、本当にそうなっているかは分からないのです。
手を動かして初めて見える「ヒヤリ」
テストコードを書いて実際に動かしてみると、思っていた通りに動く部分と、想定より条件分岐が複雑になっている部分が、はっきり分かれて見えてきます。「送信をブロックするはずの条件」が別の条件と重なったときにどう振る舞うかは、頭の中で考えているだけでは案外あやふやなままです。実際にブラウザを動かして、画面の裏側で送信処理が本当に呼ばれていないかまで確認して、ようやく「公開しても大丈夫」と言える状態になります。この一手間を飛ばしていたら、と考えるとヒヤリとします。
公開前のひと手間が、後の安心につながる
テストコードを書く時間は、フォーム自体を作る時間に比べれば決して長くありません。それでも、公開した後に「あの時確認しておけば」と思うよりは、公開前に数十分かけて確認しておく方が、結果的には早く済みます。AIに任せられる部分は任せて、自分は「何を確認すべきか」を考える方に時間を使う。この分担が、今のところ一番現場に合っていると感じています。
これは特別な開発環境がなくてもできる工程です。Claude Codeのようなツールに「このフォームの、こういう条件での動きを確認するテストを書いて」と伝えるだけで、確認したい観点を言葉にする力さえあれば十分に始められます。難しいのはコードを書くことではなく、「何がヒヤリとするポイントか」を事前に洗い出すことだと感じています。
申込・予約フォームや業務システムの公開前チェックで同じような不安を感じている方は、一度試してみる価値があると思います。ご相談はお問い合わせからお気軽にどうぞ。