スマホで初回の保存まで通し、操作の詰まりと試験の誤判定を確かめる

確かめたかったのは、初めて来た人が保存まで進めるか

検索から案内ページに来た人が、初回で迷わずに最初の保存まで進めるか。2026年10月13日、英語学習アプリ Words Admin の「AI-Recall」で、この流れを実際のブラウザから確かめました。AI-Recall は、話した内容から言えなかった英語を抜き出し、覚え直すための機能です。

検証のきっかけは、検索から来た人向けの入口ページを2本作ったことでした。入口を用意した後、その案内に沿って操作すれば、覚え直し用のメモである AI-Memo に最初の1件を保存できるところまで進めるのかを確認しました。

画面幅は390pxに設定しました。ログインしていない状態で /ai-recall?utm_source=guide を開き、ログイン、最初の抜き出し、AI-Memo への保存までを自動で通す手順です。試験用のアカウントは @example.invalid のアドレスで作成し、実行後に削除しました。実際の利用者数が変わっていないことも確認しています。

修正範囲は、検証前に「文言と導線だけ・最大3つ」と決めました。初めて操作する人が最初の保存まで進めるかを確かめ、見つかった詰まりに対して、案内の文言と画面送りを直しました。

サインインの必要性と、処理後の結果が伝わっていなかった

本番での最初の実行では、詰まりが3つ見つかりました。

最も問題だったのは、未ログインの状態で「この話から抜き出す」を押したときの案内です。サーバはログインが必要であることを示す401を返していましたが、画面に出た文言は次のとおりでした。

抜き出せませんでした。もう一度お試しください。

この状態では、同じボタンを何度押しても、サインインが必要という条件は変わりません。画面の指示に従ってやり直すほど、同じ失敗を繰り返すことになります。入口ページは「見本で試す」まで案内していたため、その案内から進んだ人が最初に踏む失敗でもありました。

押す前の説明にも不足がありました。ページ上部には「保存・同期するにはサインイン」という全ページ共通の案内があるものの、抜き出し自体にサインインが必要とは書かれていませんでした。操作前にも、失敗した後にも、先へ進むための条件が伝わっていなかったわけです。

もう1つは、抜き出し直後の表示位置でした。390px幅で確認すると、結果の先頭は上から860pxの位置にあり、画面の高さは844pxでした。結果は画面の外に出ており、5秒待っても見えている画面がほぼ変わりません。処理後の結果があっても、その位置では何も起きなかったように見えていました。

修正は、断り方・事前の説明・画面送りの3つ

修正では、まず未ログインと分かっている場合にサーバを呼ばず、その場でサインインを案内するようにしました。サーバから401または403が返った場合も同じ理由として扱います。返ってきた本文が読めない形でも、状態の番号を読むようにしました。

表示する文言は「サインインすると抜き出せます（無料）。」とし、「サインインへ」のボタンを添えました。これで、断られた理由と、次に進むための操作を同じ場所で案内します。

次に、抜き出しボタンの真下へ「抜き出すにはサインインが要ります（無料）。」という1行を追加しました。操作した後だけでなく、押す前にも条件を確認できる位置に置いています。ページ上部の「保存・同期するにはサインイン」という共通の案内だけでは伝わっていなかった、抜き出しに必要な条件を示しました。

最後に、結果が返ったら結果の位置まで、操作を断ったらその説明の位置まで、自動で画面を送るようにしました。抜き出しができた場合と、サインインが必要な場合の両方で、その時点で読むべき内容まで画面を送ります。

画面下に浮かぶ通知も一度実装しましたが、採用しませんでした。この画面では通知が1秒で消える設定で、実際に消えることを確認したためです。サインインが必要という大事な説明の置き場所には使わない、と判断しました。

試験の「失敗」と「成功」も、そのまま受け取らない

確認中には、製品の詰まりに見えて、調べると試験側の誤りだったものも3つありました。これらは製品の欠陥としての報告には含めていません。

下段のタブを押せなかった件では、試験が要素の役割を使って対象を探していました。しかし、実際の要素は <button> ではなく <p> で、役割（role）も名前もありませんでした。役割で探す書き方では見つからなかったため、試験では文字を使って押すように修正しました。ただし、キーボードで操作できない問題は、別の課題として残しています。

保存確認にも誤りがありました。メモの実体は別の保存先にあり、試験では違う場所を見て「入っていない」と判定していたのです。この判定は、メモが保存されなかったことを示すものではありませんでした。保存の有無を調べる際には、確認対象の保存先が合っているかも点検する必要がありました。

さらに、試験終了時の後片付けの処理が、途中の失敗を飲み込んでいました。途中で落ちた実行にも、次の表示が出ていました。

3/3 passed

この表示では、途中で失敗したにもかかわらず、全部通ったように見えます。そこで、途中の失敗を必ず記録する形に直しました。操作ができなかったという判定にも、全部通ったという判定にも、試験の書き方による誤りが含まれていました。

今回の確認では、画面上で起きた詰まりと、測る道具の側で起きた誤りを分けています。タブの探し方、メモの保存先、後片付け時の失敗の扱いは、それぞれ試験の判定を確かめ直すきっかけになりました。

修正後は、本番でも保存先と画面表示まで確認した

修正後の結果は、次のとおりです。2026年10月13日の今回の記録にある値を、そのまま示します。

最初の抜き出しでは、5秒でメモに6件が入り、メモの画面でも「登録数 6」を確認しました。抜き出しの操作だけで終えず、メモに入った件数と、メモの画面に表示された件数まで確かめています。

本番と同じ作り方で組んだローカル環境、本番環境のどちらも、結果は15/15で詰まり0でした。主要な導線の定期検査と単体テストの結果も、初回の操作を通した記録と併せて確認しました。

業務に置き換えると

社内ツールを作ったのに使われないとき、今回の確認手順を当てはめるなら、点検する項目は次の4つです。

• 初めての人の1回目を最後まで通す。 スマホ幅で入口から操作し、ログイン、処理、保存まで確認します。機能が動くかを確かめるとともに、初回の操作が最後までつながっているかを見ます。
• 失敗の文言に、次の操作が書かれているかを見る。 原因が変わらないまま「もう一度」と案内していないかを確かめます。今回なら、必要だったのはサインインであり、その条件と移動先を示す文言とボタンを用意しました。
• 結果が見える位置に出ているかを確かめる。 処理後の画面で、結果や断りの説明が画面外に隠れていないかを確認します。今回の390px幅では、結果が画面の外にあり、5秒待っても何も起きなかったように見えていました。
• 試験の判定と実際の操作を照らし合わせる。 要素の探し方、保存先、途中の失敗の記録を点検し、試験側の誤りと製品の問題を分けます。「通った」という表示があっても、途中の失敗が記録から抜けていないかを確かめます。

この記事は、TechAthletes が自社のサービスを作る中で記録した実測をもとに書いています。業務への導入のご相談は 仕事の窓口 で受け付けています。