「AIに頼めば、予約アプリも作れる？」
そう考えたとき、最初に入力したくなるのは「予約できるアプリを作って」という依頼かもしれません。
ただ、その一文には、まだ決まっていないことがいくつもあります。
誰が予約するのか。何を保存するのか。送信した時点で予約が確定するのか、それとも担当者の確認を待つのか。
AIがコードを書き始める前に、このあたりを短い文章にしておくと、生成されたものを確かめる基準ができます。
今回は、小さな教室の予約アプリを設計例に、非技術者でも先に決められることを整理します。GrokのWeb版で作った試作の操作結果も紹介しますが、確認したのは未入力・満席・受付後の画面表示です。予約アプリ自体にAI機能を組み込む話や、Grok Build CLIの実測レビューではありません。
予約アプリを作るなら、まず四文を書く
最初から長い仕様書を用意する必要はありません。
まずは、利用者が申し込んでから結果を確認するまでを、四文で書いてみます。
① 訪問者は、希望する教室の日時と名前、連絡先を送信する。 ② アプリは申し込み内容を保存し、「確認待ち」として担当者に表示する。 ③ 担当者が定員と内容を確認して予約を確定し、申込者へ結果を知らせる。 ④ 申込者には他人の情報を見せず、満席や送信失敗のときは、状況と次の操作を案内する。
今回は「申し込みを受け付けたあと、担当者が確認する方式」にしました。
空席があれば自動で確定する方式もありますが、必要な処理は変わります。どちらにするかは、教室の運営に合わせて選びます。
この四文だけで完成ではありません。それでも、「予約アプリを作って」より、確認すべきことが見えやすくなります。
誰が入力し、誰が確認するか
利用者全員に、同じ画面が必要でしょうか。
今回の例では、申し込む人と担当者で、することが違います。
申し込む人は、日時を選んで必要事項を送ります。担当者は、届いた申し込みを確認し、受け付けられるか判断します。
今回はGrokのWeb版で、架空の教室の申込フォームを試作しました。受付可能な日時を選び、テスト用の名前とメールアドレスを入力して送信すると、「確認待ち」と表示されました。画面上でも、申し込みの受付と予約の確定を分けています。
ここで決めておきたいのが、送信後に表示する言葉です。
担当者の確認が必要なのに「予約が完了しました」と表示すると、申込者は席を確保できたと受け取るかもしれません。
今回なら、送信直後は次のような案内にします。
お申し込みを受け付けました。現在は確認待ちです。予約の確定後、ご入力の連絡先へご案内します。
ただし、この文章を表示するなら、実際に連絡する方法も必要です。
担当者がメールを送るのか、アプリから自動送信するのか。誰が、どのタイミングで対応するのかまで決めます。画面に案内を書くだけでは、連絡は届きません。
保存する情報も、入力欄と一緒に整理します。
今回なら、教室の日時、名前、連絡先に加えて、予約番号と「確認待ち・確定・受付不可」などの状態が必要になります。住所や生年月日などは、運営上の必要がなければ最初から集めない設計にできます。
申込者のアカウントは必要でしょうか。
これも、使い方によります。メールで結果を受け取るだけなら、申込者用のアカウントを設けない方法も考えられます。一方、あとから自分の予約を一覧で見たり変更したりするなら、本人を確認する仕組みが必要です。
「とりあえずログイン画面を付ける」前に、戻ってきた人が何をするのかを決めておきます。
他人の情報と、満席の日時をどう扱うか
予約一覧ができたら、そのまま公開してよいでしょうか。
名前や連絡先を含む一覧は、誰でも見られる画面には置けません。
担当者は必要な予約を確認できる。申込者が予約詳細を見る仕組みを設けるなら、本人の情報だけを確認できる。この範囲を先に決めます。
また、画面から他人の予約を隠すだけでは不十分です。予約番号やURLを変えてアクセスした場合にも、許可されていない情報を取得できないようにする必要があります。
非技術者でも、AIに伝える条件として、次のように書けます。
予約者の名前と連絡先は、権限のある担当者だけが閲覧できるようにしてください。申込者向けの確認機能を作る場合は、本人の予約以外を閲覧・変更できない設計にしてください。
次に、満席の場合です。
日時を選んだときには空きがあっても、送信するまでの間に別の人の予約が確定することがあります。今回の確認方式なら、担当者が確定するときに定員を超えない仕組みが必要です。
満席と通信失敗も、同じ案内にはしません。
試作では、何も入力せずに送信する操作も試しました。日時・名前・メールアドレスの不足が一つずつ表示され、該当する入力欄も赤枠になりました。「入力エラー」だけで終わらず、どこを直せばよいかが分かる案内です。
次に、満席に設定した日時を選び、名前とメールアドレスを入力して送信しました。すると「選択された日時は満席です。別の日時を選んでください」と表示されました。ただし、入力欄の下には「満席の日時は選択できません」とあり、実際には選択できる画面と説明が一致していません。この文言は「満席の日時には申し込めません」に直す必要があります。
今回確認したのは、未入力・満席・受付後の画面表示です。データの永続保存、ログイン、他人の情報へのアクセス制限、実際の通知は、この試作では検証していません。
ここからは、今回の試作では検証していない通信失敗についても考えます。通信が途切れたからといって、必ず保存されていないとは限りません。。
受付結果が分からないまま「もう一度送信してください」とだけ案内すると、同じ申し込みが重複する可能性があります。受付状況を確認する方法や、繰り返し送信しても重複しない処理も検討します。
こうした条件を決めておくと、AIへの依頼も「エラーを直して」から、「受付結果が不明な場合は、再送信の前に確認方法を表示して」へ具体化できます。
コード生成の速さと、公開の準備は別に考える
ここまで決めれば、あとはAIに任せられるでしょうか。
コード生成ツールには、画面や保存処理の実装、修正案の作成などを支援してもらえます。一方、何を予約確定とするか、誰に情報を見せるか、トラブル時に誰が対応するかは、作り手が運営に合わせて決め、結果を確認する必要があります。
Grokのようなコード生成を使う場合も、公開後の運用まで一度に任せられるわけではありません。Grok Buildの英語解説は、生成から公開までの作業を考える材料になります。
Grok Build公式紹介でも、計画を確認・修正し、承認してから実行する流れが示されています。先ほどの四文は、その計画を読むときの基準として使えます。
AIから返ってきた計画に、自動で予約を確定する処理が入っていたら、今回決めた運営方法とは違います。「担当者が確認する」という条件に戻して、実装前に修正できます。
探索用の試作なら、架空の名前と日時を入れて、申し込みの流れや画面の分かりやすさを確かめるところから始められます。
保存や通知がまだ動かない場合は、その範囲を明示して触ってもらいます。試作品で分かったことをもとに、四文を書き直しても構いません。
実際の予約を受け付ける段階では、画面の確認に加えて、次の流れを通して試します。
- 申し込みが保存され、担当者が確認できる。
- 担当者が更新した予約状態と、申込者への案内が一致する。
- 権限のない人が、予約情報を閲覧・変更できない。
- 満席や送信失敗のとき、利用者が次の行動を選べる。
- 困った人が連絡でき、担当者が状況を調べられる。
コードが生成されたあとにも、公開先の設定や、連絡方法、更新・復旧の準備が残ります。すべてを最初から詳しく決める必要はありませんが、人に使ってもらう前には、未決定のままにしている箇所を確認したいところです。
最初に書いた四文へ戻ってみてください。
「担当者が確認する」と書いたなら、誰が確認するのか。「結果を知らせる」と書いたなら、どう届けるのか。「失敗を案内する」と書いたなら、利用者はそこから何ができるのか。
答えられない箇所があれば、そこが次に埋める決定です。
その決定を実装と確認項目に反映してから、公開へ進めます。
출처: note 원문
번역: Gemma 3(.44) 초벌 + 교정 검수
원문 보기 | 출처: note.com