AIに「予約アプリを作って」と頼むと、日時を選ぶ画面や予約ボタンを作ってくれます。自分のアイデアが画面になり、実際に操作できるのは楽しいものです。
そこから使えるアプリにしていくには、画面の裏側も作り込んでいきます。予約を保存して次に開いたときにも確認できるようにしたり、同じ時間に申し込みが重なったときの処理を決めたりする必要があるからです。「予約完了」という表示だけでは、データが保存されたかどうかまでは分かりません。
この記事では予約アプリを例に、フロントエンド、バックエンド、データベース、フレームワークの役割を整理します。
使う人が何をしたいのかも考えておく
ここでは、ホットペッパーとInstagramのDMからお客様が来るお店を考えてみます。お店を知ってもらう経路がすでにあるので、まずはそこから予約が確定するまでの流れを確認します。
DMで日時を相談してからホットペッパーへ案内するのか、DMのやり取りで予約を確定するのか。スタッフはどこで空き枠を確認し、変更やキャンセルをどこへ記録しているのか。ここが分からないまま新しい予約画面を増やすと、確認する場所や入力の手間も増えてしまいます。
調べた結果、必要なのはお客様向けの新しい画面より、スタッフがDMの対応状況を共有する仕組みかもしれません。AIへ依頼するときも、誰がどこから来て、今はどう対応しているかまで伝えると、作る機能を考えやすくなります。外部サービスと自動連携できるかは、使える機能や契約条件を別途確認します。
ここからはWebの仕組みを学ぶため、自社側に予約の入力・保存機能を作る場合を例に説明します。ホットペッパーやInstagramと自動連携する構成ではありません。
フロント・バック・DBの役割
まずは車の運転席を想像してみてください。ハンドルやペダルで操作し、メーターで速度を確認します。このように人が操作したり状態を見たりする部分が、アプリのフロントエンドに近い役割です。
アクセルの操作を受け取り、車の状態に応じて動力を調整する制御の仕組みは、バックエンドに例えられます。運転席からは見えませんが、操作に応じて実際の処理を行っています。
データベースは、カーナビの登録地点や走行履歴を保存し、後から取り出せる仕組みに例えられます。メーターに今表示されていることと、記録として残っていることは別です。アプリでも「画面に出た」と「保存された」を分けて考えます。
車とWebアプリは構造が違いますが、操作する部分、処理する部分、記録を残す部分に分けると、それぞれの役割をつかみやすくなります。予約アプリでは次のようになります。
フロントエンドは、利用者が見る画面や操作を担当します。予約日を選ぶカレンダー、入力フォーム、送信中の表示などです。HTMLはページの構造、CSSは見た目、JavaScriptは操作に応じた動きなどを扱います。
バックエンドでは、受け取った予約日時に空きがあるか、操作している人に権限があるかなどを確かめてから保存の処理へ進みます。
データベースは、予約や利用者などの情報を保存し、必要に応じて取り出す仕組みです。
典型的な構成では、画面から予約の要求を送り、バックエンドが確認し、データベースへ保存します。その結果が画面に返ってきて、利用者に完了を知らせます。この通信にはHTTPという仕組みが使われます。基本的な流れは、MDNのサーバーサイド入門でも説明されています。
これらを一つのプロジェクトで作ることもあります。フォルダやファイルを見ただけでは区別がつかない場合もあるので、どのコードが何を担当しているかを確認していきます。
APIでデータや処理をやり取りする
APIという言葉もよく出てきます。Web開発では、別の機能にデータを渡したり、処理を依頼したりするための接点として登場します。
例えば予約機能では、希望日時を送ると、予約番号や受け付けられなかった理由が返ってきます。こうしたやり取りのために、送信先やデータの形式、返す内容を決めておきます。
予約できないときも、このやり取りを調べると原因を絞れます。画面から要求が送られていない場合と、要求は届いたものの保存に失敗した場合では、直す場所が違うからです。
AIにも「直して」だけでなく、「送信先、送った内容、返ってきた結果を確認して、失敗している箇所を説明して」と頼めるようになります。確認に使う記録からは、個人情報や秘密情報を取り除きます。
フレームワークを使う理由
アプリには、URLごとに処理を切り替える、入力内容を確認するなど、繰り返し必要になる仕組みがあります。こうした開発を助ける機能と構成上の決まりを提供するのが、Webフレームワークです。備わっている機能は製品ごとに異なります。MDNのフレームワーク解説に、その役割が整理されています。
車づくりで共通の車台や部品の取り付け規格を使うように、アプリでも既存の仕組みを使うことで開発の手間を減らせます。フレームワークを使っても、予約を受け付ける条件など、自分のアプリに必要なルールは設計します。
よく名前が挙がるReactとNext.jsも、役割に違いがあります。Reactは画面を部品に分けて組み立てるためのライブラリです。Next.jsはReactを使うフレームワークで、サーバーで行う処理とブラウザーで行う処理を、一つのプロジェクトで扱えます。公式ドキュメントでも、この実行場所の違いが説明されています。
Next.jsのプロジェクトを読むときは、ブラウザーで動くコードとサーバーで動くコードを区別して見る必要があります。
AIがフレームワークを提案してきたら、今回のアプリで何に使うのか説明してもらいましょう。公開先で動かせるか、必要な機能がそろっているかも確認すると、選ぶ理由が分かってきます。
操作する権限はサーバー側で確認する
予約アプリでは、自分の予約にだけ取消ボタンを表示することがあります。ただ、他人の予約からボタンを隠すだけでは、取消処理を防げません。利用者のブラウザーから送られる要求は、画面の操作以外の方法でも作れます。送られてきた予約番号をそのまま信じると、別の人の予約を取り消せる可能性があります。
取消処理を行う側でも、操作した人がその予約を取り消せるか確認する必要があります。
この確認に関わるのが「認証」と「認可」です。認証では利用者が誰かを確かめ、認可ではその人に許す操作を判断します。ログイン機能があるだけで、すべての権限確認が済むわけではありません。OWASPの認可ガイドも、要求ごとの権限確認と、クライアント側の判定だけに依存しないことを勧めています。
AIと確認を進めるときは、別の利用者の予約番号を指定した場合に取消処理が拒否されるか、というように条件を具体的に伝えます。テスト用のアカウントと予約を用意し、想定どおり拒否されるか実際に確かめます。
正常に動く場合と失敗する場合をテストする
予約できるようになったら、再読み込みや通信の失敗なども試してみます。予約アプリなら、次のような項目を確認します。
- 再読み込みしても保存した予約を確認できる。
- 別の利用者の予約を勝手に変更できない。
- 同じ枠へ同時に申し込んでも、定員を超えて確定しない。
- 通信に失敗したとき、成功したような表示にならない。
ボタンの連打を画面で防ぐことは役立ちますが、別の端末から同時に申し込まれる可能性もあります。予約の確定条件は、保存する側も含めて設計する必要があります。
こうした確認項目は、実装前にAIと一緒に整理しておくと便利です。修正するときは変更前後の差分を見て、動作を確かめながら少しずつ進めます。一度に多くの変更を加えない方が、不具合の原因も追いやすくなります。
作りたいものに合わせて学ぶ順番を決める
最初から全部を覚えようとすると大変なので、作りたい機能に合わせて少しずつ学ぶのがおすすめです。
予約アプリなら、まずはテスト用の予約を一件保存して、再読み込み後にも確認できるところまで作ります。その過程で画面から保存先までの処理を追い、次に利用者ごとの権限やエラーへの対応を調べる、と進めると学ぶ内容を絞れます。
DiluNovaが大切にしているのは、先に「いつまでに、どこまで行くか」を決め、そこへ向けて進め方を組み立てることです。AIを使う開発でも、完成と呼べる条件を決めておくことが、指示と確認の両方に役立ちます。
手元で作っているアプリがあれば、ボタンを一つ選んで処理を追ってみるとよい練習になります。AIに関連するファイルを挙げてもらい、送信先、権限を確認する処理、データの保存先を順に見ていくと、今回紹介した役割と実際のコードを結びつけられます。
開発の進め方も知りたい方へ
実際の案件では、仕組みを理解することに加えて、使う人の困りごとを調べ、最初に作る範囲と完成の条件を依頼者と合わせておく必要があります。ヒアリングからテスト・公開までの進め方は、AIを使ったWeb開発の実務ガイドで、予約受付を改善する例とともに詳しく紹介しています。
最後まで読んでいただき、ありがとうございました。
DiluNovaは、AI導入・伴走支援、ソフトウェア・ハードウェア開発、セキュリティ診断に取り組む会社です。先に「いつまでに、どこまで行くか」を決め、使う人の仕事に合う形を一緒に考えています。DiluNovaのホームページでは、事業内容や開発・支援実績も紹介しています。