AIで作ったアプリ、公開して大丈夫？リリース前に確認したいこと

「動いた」けれど、公開してよいか判断できない

AIに指示して作った予約ページや業務アプリを、自分の端末で操作してみる。入力から完了まで進めれば、ひとまず形になったと感じるはずです。ただ、その確認で分かるのは、試した条件で動いたということです。別の利用者、違うデータ、途中で中断した操作まで同じように動くかは、改めて確かめる必要があります。

例えば、必須項目をすべて入力したときは保存できても、空欄のときに説明が出ないケースが考えられます。保存できたように見えても、一覧に反映されなければ利用者は判断に困ります。これは特定企業の事例ではなく、確認項目を考えるための一般的な例です。作った人が迷わず進める道筋だけでは、こうした問題を見落とします。

最初に決めたいのは、「誰が、何を、どこまでできたら完成か」です。問い合わせなら送信だけでなく担当者が内容を受け取れること、予約なら利用者と管理者が同じ日時を確認できることまで書き出します。完成の条件が言葉になると、公開日が近づいてから不安だけが増える状態を減らせます。

確認対象には、アプリ本体だけでなくメール送信、外部サービスとの接続、管理画面も含めて考えます。自分が変更した画面から、その先で何が起きるかをたどってみましょう。関係する担当者が別にいるなら、確認の分担と結果の受け渡し方法も、公開前に決めておくことが大切です。

入力の境目と、操作が変わる場面を試す

通常の操作を確認したら、次は条件の境目を探します。文字数の上限がある欄なら、上限ちょうど、その直前、その直後で説明と保存結果が一致するかを確かめます。数値なら許される最小値と最大値、日付なら選択できる期間の端を確認します。どの値が正しいかは、画面の見た目ではなく、先に決めた仕様を基準にします。

途中の操作にも注目します。入力後に前の画面へ戻る、保存中にもう一度ボタンを押す、ログインしたまま時間を置くといった場面です。例えば、戻っただけで入力がすべて消えると、長いフォームでは利用者の負担になります。二重操作で同じ申請が増えるなら、受付側の作業にも影響します。試すときはテスト用データを使い、実際の顧客への通知を避けます。

すべてを思いつきで試すより、画面ごとに「開始前」「処理中」「完了」「失敗」の状態を並べると整理しやすくなります。失敗したあとに再入力できるか、完了後に以前の画面へ戻ったらどうなるかも確認できます。処理が終わったか分からない表示は、重複操作につながるため、操作結果が伝わることまでを確認対象にします。

AIに確認項目を相談する場合も、画面や業務の条件を渡して、抜けを探す補助として使います。出てきた項目が自分のアプリに当てはまるか、期待する結果が仕様と一致するかは見直してください。項目の数が多くても、重要な予約や支払いの流れが含まれていなければ、公開判断の材料としては足りません。

端末・使いやすさ・安全面を別々に確かめる

パソコンで完成した画面も、スマートフォンではキーボードに送信ボタンが隠れたり、横長の表が読めなくなったりします。利用者が使う端末とブラウザを決め、入力から完了まで通して操作します。表示だけを眺めるのではなく、文字を拡大した場合、縦横を変えた場合、通信に時間がかかる場合の困りごとも確認します。

使いやすさの確認では、説明を読まなくても次の操作が分かるか、エラーの場所と直し方が伝わるかを見ます。W3CのWCAG 2.2は、キーボード操作や入力エラーの特定など、Webを利用しやすくするための観点を示しています。本記事で取り上げるのは基本的な確認例であり、ここを試すだけでアクセシビリティ全体への対応が完了するわけではありません。

安全面は、操作の便利さとは別に確認します。画面上で見せないことと、データを取得できないことは同じではありません。一般利用者と管理者で閲覧・変更できる情報を整理し、不要な情報が含まれていないか、テスト用の設定や接続情報が残っていないかを開発担当者と確認します。実データを使った無断の試験や、他社のシステムへの確認は行いません。

OWASPのWeb Security Testing Guideは、Webアプリケーションのセキュリティ試験を整理するための資料です。専門的な確認が必要な箇所は、開発担当者や診断担当者へ引き継ぎます。自分で触れる範囲の動作確認と、内部の実装を含む安全面の確認を混同しないことが、確認漏れや過大な安心を避ける助けになります。

確認結果を、修正と公開判断に使える形で残す

不具合を見つけても、「変だった」というメモだけでは、直す人が再現できません。操作した画面、事前の条件、入力、期待した結果、実際の結果をそろえ、必要なら画像を添えます。発生した端末やブラウザ、確認日も記録すれば、別の環境でだけ起きる問題を調べやすくなります。個人情報が写る画像は、そのまま共有しないよう配慮します。

確認結果は、不具合だけでなく、問題がなかった項目と、まだ確認できていない項目も残します。未確認の理由が「管理者アカウントがない」のか「確認対象外」なのかで、次に必要な作業は変わります。公開判断では、重要な業務を止める問題と、後日調整できる表示の問題を分け、対応する人と期限を決めます。

Custosの公開前診断では、点検の考え方を次のように示しています。国際的なテスト技術者の資格団体 ISTQB® が定めるテスト設計技法（境界値分析・状態遷移など）に沿って、テストケースを作っています

ソフトウェア品質の国際規格 ISO/IEC 25010 が定める品質の観点（機能の正しさ・性能・端末の違い・使いやすさ・アクセシビリティなど）に沿って確かめ、結果を報告書に残します

どのプランで何を確認するか、利用条件や対象範囲は申し込み前に確認してください。

Custosの公開前診断はWebアプリを対象とし、スマートフォンにインストールするネイティブアプリは対象外です。表示や操作の待ち時間など基本的な性能の確認と、多数のアクセスを同時に発生させる負荷試験は異なります。長期間の安定性評価、ソースコードのレビュー、修正の代行、WCAGへの適合判定を含むものではありません。安全面も入口の確認であり、詳しい脆弱性診断は別に考える必要があります。

最初に問題の一覧と件数を確認し、詳細では問題の内容や直し方、AIへの修正依頼文を確認する流れがあります。さらに初めて触る人の視点での点検も用意されています。自分に必要なのが全体の把握なのか、修正へ進むための詳しい情報なのかを整理して選びましょう。具体的な申し込み条件はサービスページで確認してください。

公開前の確認を外部へ相談する場合は、公開前診断で届く報告書の見本で、指摘の伝え方や成果物の構成を確認できます。価格や所要時間だけでなく、自分の確認したい操作と対象範囲が合うかを見ることが大切です。

まとめ：公開前の確認と、公開後の点検をつなげる

AIで開発したアプリも、完成の条件を決め、正常な操作、入力の境目、操作の中断、端末の違いを順に確かめれば、公開判断の材料を増やせます。重要なのは、すべて試したつもりになることではなく、何を確認し、何が残っているかを説明できる状態にすることです。修正した箇所は、同じ手順でもう一度確かめます。

公開の直前に変更を入れた場合は、その変更がどの画面や通知へ影響するかを確認します。確認済みの版と公開する版が違えば、以前の結果をそのまま利用できないことがあります。確認対象の版、設定、テスト用アカウントを記録し、公開担当者に受け渡すと、何を根拠に公開するのかが明確になります。

公開後は利用者も設定も変わり、外部サービスやライブラリの更新も続きます。公開前に動いたという記録を、将来までの安全の保証として扱わないようにしましょう。変更のたびに確認する機能を決め、問い合わせや障害の兆候を受け取る担当者も置くと、次の改善につなげやすくなります。

公開前の不具合確認に加え、公開後はCustosのURL診断を通じてWebサイトの脆弱性、つまり攻撃に利用される弱点を点検する流れを用意しましょう。URLから確かめられる範囲と、ログイン後の業務など別途確認が必要な範囲を整理し、必要に応じて専門的な診断を組み合わせます。

ISTQB® は International Software Testing Qualifications Board の登録商標です。Custos は ISTQB® の認定を受けた事業者ではなく、ISTQB® で定められたテスト設計技法に沿って点検を行っています。