AI が構築した顧客リクエストアプリの依頼と確認方法
Leina 向けにリクエストフォーム、データベース保存、スタッフビューを指定し、公開前に永続性、バリデーション、アクセス制御を検証します。
顧客リクエストアプリはシンプルなアイデアから始まります。ユーザーが必要なことを伝え、チームがリクエストを確認する 1 つの場所を提供します。
これを有用にするには、フォームが送信内容を保存し、不足フィールドを説明し、スタッフビューを適切な人だけがアクセスできるようにする必要があります。
Leina の App Builder では、会話を通じてバックエンドロジックとデータベース保存を備えたフルスタック Web アプリケーションを作成できます。以下のサンプル依頼を使って最初のバージョンをリクエストし、実際のユーザーと共有する前にその実際の動作を確認してください。
最小限の最初のバージョンをスコープする
AI でアプリケーションを生成するときは、すべてを一度にリクエストしたくなりますが、こらえてください（例: 通知、CRM 同期、ファイル添付、優先度タグ）。まずは無駄がなく検証可能な基盤から始めます:
| コンポーネント | 必須の v1 要件 | 今は省くもの |
|---|---|---|
| 公開フォーム | 顧客名とリクエスト詳細、必須フィールドのバリデーション | ファイル添付とマルチステップウィザード |
| データベース | 自動送信タイムスタンプ付きの永続的なレコード保存 | 自動優先度スコアリングや AI 感情タグ |
| スタッフダッシュボード | 送信されたレコードを新しい順に表示する読み取り専用リスト | CRM 双方向同期、自動顧客返信メール |
| フィードバック | データベース書き込みが成功した後にのみ明示的な確認バナーを表示 | データベース確認前の推測的な成功状態 |
各ビューを誰が見られるようにするかを決めます。この例では、訪問者がリクエストを送信し、認可されたスタッフがそれを読み取ります。Leina にその分離をどのように実装できるか尋ねてください。これらは検証すべき要件であり、組み込みの制御のリストではありません。
観察可能な仕様を含む依頼を Leina に与える
Leina App Builder でこのスターター依頼をコピーして調整してください:
2 つの異なるビューを持つ顧客リクエスト Web アプリを構築してください:
- 公開リクエストフォーム:
- フィールド: 「Customer Name」と「Request Details」（両方とも必須）。
- クライアント側とサーバー側のバリデーション: 空の送信または空白のみの入力をインラインエラーメッセージで拒否する。
- レコードがデータベースで確認された後にのみ成功確認バナーを表示する。
- スタッフダッシュボード:
- 送信されたすべてのリクエストをクリーンなテーブルまたはリストで、新しい順に表示する。
- 顧客名、送信タイムスタンプ、リクエスト全文を表示する。
- アクセス制御:
- 送信フォームはすべての公開訪問者がアクセスできるようにする。
- スタッフダッシュボードは認証されたチームメンバーのみに制限する。
これら 2 つのビューで利用可能なアクセス制御を説明し、実装できない要件があれば指摘してください。開発中は架空のテストレコードを使用してください。公開前にアプリをレビューできるように準備してください。
4 つの必須受け入れテストを実行する
テストアプリでこれら 4 つのチェックを実行します。初回実行でよくある問題を検出できますが、アクセスとデータ処理は意図する用途に合わせて引き続きレビューが必要です。
1. 送信が保存されるまで追跡する
「Test: Weekly digest feature」 のような特徴的なリクエストを送信します。スタッフビューでその値を確認し、ページを再読み込みし、バックエンドストレージまたは別の認可されたブラウザセッションで同じレコードを探します。
再読み込みは最初のチェックであり、データベース書き込みの証明ではありません。localStorage のようなブラウザストレージも再読み込み後も残ります。保存されたレコードを検査して、データがどこに保存されたかを確認します。検査できない場合は、そのチェック部分を未解決として記録します。2 つ目のリクエストを追加し、1 つ目が変更されていないことを確認します。
2. 空送信テスト（バリデーション）
フィールドが空の状態、または空白のみでフォームを送信してみます。
期待される動作: フォームは不足フィールドを強調表示し、送信をブロックし、データベースに空のレコードを作成しない必要があります。
3. 複数行と特殊文字テスト（フォーマット）
改行、箇条書き、引用符、記号（&、<、#）を含むリクエストを送信します。スタッフビューを検査して、文字化けやエスケープのバグなしにフォーマットが保持されていることを確認します。
4. シークレットモードテスト（アクセス制御）
スタッフダッシュボードの URL をコピーし、ログインしていないプライベート / シークレットブラウジングウィンドウで開きます。
期待される動作: アプリケーションは認証を要求するか、アクセスを拒否する必要があります。また、スタッフアクセスを持つべきでないサインイン済みアカウントでもテストします。非表示のページやログイン画面だけでは、基盤となるデータリクエストが保護されていることを証明できません。必要な制限が利用できない場合は、それが解決されるまでアプリを架空のデータのままにしておきます。
customer request app review checklist を使用して観察結果を記録します。
一度に 1 つの動作を修正する
問題が発生した場合、ビルダーに「すべてを修正して」と依頼しないでください。具体的で単一動作の指示を与えます:
空のリクエストを送信すると、レコードが保存されていないのにフォームが成功メッセージを表示します。代わりにインラインの必須フィールドエラーを表示し、成功した送信は引き続き機能させ、既存のテストレコードを保持してください。
各修正後、修正されたエラーパスと通常の送信の両方を検証し、修正がリグレッションを引き起こしていないことを確認します。
公開とロールアウト
チェックを解決し、アプリが意図する対象者に適していることを確認したら:
- テストデータをレビュー: テスト用に作成した架空のレコードのみを特定して削除します。
- アクセスをレビュー: アプリで実際に利用可能な制御を使用して、誰がリクエストを送信でき、誰が保存されたレコードを読み取れるかを確認します。
- 公開と検証: My Apps でアプリを見つけ、利用可能な公開フローに従います。フォームリンクを共有する前に、公開されたバージョンで送信とアクセスチェックを繰り返します。
受信リクエストをレビューする担当者を選び、未解決の制限事項を記録しておきます。チームが小さいバージョンを使用し、次に何が必要かを把握したら機能を追加します。