AIとアプリを作っていると、「この画面では動くけれど、別の利用者が開くとどうなるんだろう」という場面が出てきます。
私は、教材やマニュアルをもとに答えるAIを作って共有するアプリを、Codexと開発しています。その中で役に立ったのが、同じ対象を、違う利用者・違う状態で開いた画面を並べることでした。
この記事では、開発中に行った確認を、別のアプリでも使える手順に整理します。スクリーンショットの差分だけで動作を保証する方法ではなく、画面比較を使って仕様の抜けを見つけ、操作確認につなぐ方法です。
1. 比べる対象を一つに固定する
まず、対象を「同じAIの会話画面」のように絞ります。片方は一覧、もう片方は編集画面、という比較では、何の条件による違いかが分かりにくくなります。
今回のアプリでは、同じAIでも作成者と受領者で必要な操作が異なります。また、一人の会員が、自分のAIでは作成者、他の人のAIでは受領者になることもあります。
したがって、単に「ユーザーAとBを比べる」のではなく、対象に対する立場を決めてから比較します。
| 固定するもの | 例 |
|---|---|
| 対象 | 同じAIの会話画面 |
| データ | 架空のAI名と確認用の会話 |
| 表示幅 | PC同士、スマホ同士でそれぞれ統一 |
| 表示位置 | 案内文・入力欄・送信ボタンを含む同じ範囲 |
2. 「使えない理由」を先に分ける
次に、画面が変わる条件を出します。今回、「使えない」という一つの言葉の中に、複数の理由が混ざっていました。
- 作成者が共有をやめて「自分だけ」にした。
- 作成者の会話用の利用枠が足りない。
- 契約プラン上、そのAIが利用対象から外れている。
この3つは、復帰する方法も、案内を読むべき相手も違います。先に区別しておくと、「エラー時の画面」のような曖昧な依頼を避けられます。
確認表は、例えばこうします。これは今回の例を、検証用に整理したものです。
| 状態 | 作成者側で確認すること | 受領者側で確認すること |
|---|---|---|
| 通常の共有中 | 会話と編集へ進めるか | 会話へ進め、編集操作は出ないか |
| 共有を「自分だけ」に変更 | 本人は引き続き使えるか | 新しい質問が止まり、理由が伝わるか |
| 会話用の利用枠が不足 | 利用できない理由と、対応先が分かるか | 自分では変更できない契約の操作へ誘導されないか |
| プラン上の利用対象外 | 復帰できる条件と案内が合っているか | 共有停止と混同した説明になっていないか |
表の各行には、期待する状態を書きます。「確認済み」という一列だけで済ませず、何が表示され、何ができればよいかを言葉にしておくのがポイントです。
3. 変更前・変更案・変更後を区別して撮る
画像を並べるときに混ざりやすいのが、まだ実装していない案と、本当に変更した後の画面です。
私は次のように区別します。
| 画像の種類 | 表記 |
|---|---|
| 現在のアプリを撮ったもの | 現在の画面 |
| 表示を変えて再現したもの | 変更案・未反映 |
| 修正したアプリを実際に操作して撮ったもの | 変更後の実画面 |
変更案を見て採用を決めることと、採用後に正しく動くと確認することは別です。作成者側だけの画像が出てきたら、受領者側もそろえてから判断します。
撮影では、見たい部品と周囲の文脈が読める大きさを確保します。画面全体を小さくした画像より、案内文・入力欄・ボタンを含む範囲を文字が読める解像度で撮った方が、違いを確認しやすくなります。
例えば、共有を「自分だけ」にしたときの比較です。
架空の確認用会員・会話を使って撮影した、開発当時の本番画面です。切り出し・配置・比較見出しを加えた加工済み画像で、画面内の文言や状態は描き換えていません。会話の空白を省略した位置も示しています。最新の画面デザインを示す画像ではありません。
左の作成者は入力でき、右の受領者には案内が出ています。同じAIでも、立場によって必要な表示が違うことを一度に確認できます。
4. Codexに渡す指示を、比較条件まで書く
「見やすくして」「おかしいところを直して」だけだと、判断する条件までAIに任せることになります。
次は、今回の進め方を別の開発でも使えるように整理した指示文です。過去の会話をそのまま引用したものではありません。
同じ対象について、利用者の立場と状態による表示を比較したいです。
1. 最初に、表示が変わる条件を表にしてください。
対象、操作する人の立場、状態、期待する表示・操作を分けてください。
まだ決まっていない仕様は、推測で埋めず「未決定」と示してください。
2. 比較には架空の確認用データを使ってください。
同じ表示幅、同じ対象、同じ位置で撮影してください。
見せたい範囲の文字が読める解像度にしてください。
3. 変更前と変更案を並べ、採用前に確認できるようにしてください。
実画面と再現した案を区別し、画像に立場と状態を明記してください。
4. 見直す箇所と、維持する箇所を分けて説明してください。
採用した案だけを反映した後、同じ条件で再確認してください。
5. 見た目の確認と動作確認を分けてください。
入力・送信・状態の復帰まで実際に操作し、結果を記録してください。
修正前に「維持する箇所」も示すと、直したい場所の周囲まで連動して変わっていないかを確認できます。どこを直すかと同じくらい、どこが残るかを見ます。
5. スクリーンショットの後に、操作と復帰を確かめる
入力欄がグレーになった画像だけでは、送信処理が止まっているかは分かりません。表示を見た後は、同じ条件で操作します。
| 確認 | 見るもの |
|---|---|
| 入力・送信 | 使えない状態で新しい質問が実行されないか |
| サーバー側の権限 | UIを経由しない要求でも、許可されない操作を拒否するか |
| 状態の復帰 | 共有や利用条件を戻した後、会話を続けられるか |
| 画面の再表示 | 再読み込みや別画面から戻った後も、正しい状態か |
| 履歴 | 他の利用者の会話と混ざらないか |
権限の確認は、自分が管理する開発・検証環境と確認用アカウントで行います。実際の顧客データを比較用に使う必要はありません。
また、個別の操作だけでは見えない問題もあります。開発中には、プラン変更の予約と取り消しなどを続けて行うと、古い結果が残るケースがありました。一回ずつの成功に加えて、前の操作が次の操作へ影響するかも見ます。
6. スマホは、入力を始めた状態も比べる
スマホ幅の静止画がきれいでも、キーボードを出した後の使い勝手は別です。
私の開発では、入力欄を見える位置へ動かす処理が別のスクロール処理を呼び、位置が落ち着かなくなることがありました。普通にページを開いただけでは分からず、入力中の画面録画が原因を整理する材料になりました。
スマホでは、次の一連の流れを追加します。
- 入力欄をタップし、キーボードを出す。
- 長い文章を入力する。
- 入力中にスクロールする。
- 編集画面を閉じ、内容が残っているかを見る。
- 次のボタンや元の操作へ戻れるかを見る。
ブラウザーの表示幅を狭くする確認と、手元の端末でキーボードを出す確認は、同じ結果としてまとめません。「自動検証では確認済み」「実機では未確認」のように、確認できた範囲を残します。
比較表を、判断の置き場所にする
この方法で便利だったのは、差分を探すことだけではありません。「この説明は誰に必要か」「この人には設定ボタンが要るのか」といった、仕様の話をしやすくなったことです。
対象を固定し、立場と状態を分け、期待する操作を書いてから画面を並べる。その後に、送信や復帰まで確かめる。文章だけでは追いにくくなった条件を、確認できる単位へ戻せます。
開発中の比較画像と経緯は、7日目の開発日記にまとめています。
この記事で使った制作例は、私が開発しているAIチャットつくーるです。教材やマニュアルをもとに答えるAIを作り、リンクで受講生やチームへ共有できます。