まず製品を形にする
AIとの協働方法を理解し、画面構成、操作状態、フォーム、ミニプログラムの基礎を作ります。
成果物：操作できる予約画面未経験から始めるAIプロダクト実践講座
AIで画面を作るだけでなく、
一つの製品を公開まで仕上げる。
27章を通して、同じ生活サービス予約ミニプログラムを作ります。画面とフォームから始め、API、データベース、認証・権限、決済、ファイル、サーバー、監視まで進みます。各章に具体的な課題、成果物、確認項目があります。
一つのプロジェクトを27章で完成
画面からバックエンドまで
公開と継続保守まで
現行27章のカリキュラムをもとにした内容
学習中：予約フローをバックエンドにつなぐ
第7章 / 全27章
CHAPTER 07
画面から実際のAPIを呼ぶ
固定データのサービス一覧をAPIデータに置き換える
CHAPTER 08
予約をデータベースに保存
データ設計を行い、実際の注文を保存する
CHAPTER 09
ログインとユーザー識別
自分の予約だけを見られるようにする
CHAPTER 10
管理画面で予約を処理
受付、日時変更、完了、取消の状態を管理
CHAPTER 11
エラーと例外処理
通信失敗、二重送信、空き時間なしに対応
CHAPTER 12
一連の受入確認
実際の利用経路で画面からサーバーまで確認
AIにコードを書かせることと、製品を作れることは同じではありません。何を解決し、どこを変え、どう動作確認するかを判断できることが本当の力です。
先にプログラミング知識をすべて暗記する必要はありません。必要な知識を、その知識が必要になる製品課題の中で学びます。AIで実装を速めながら、要件、境界、受入確認は自分で担い、開発の判断力を身につけます。
01 · 一つの実践プロジェクトを画面から本番まで
一件のサービス予約には、
一件のサービス予約には、
画面、データ、管理画面の連携が必要です。
講座では生活サービス予約ミニプログラムを作ります。利用者がサービスと時間を選んで予約し、サーバーが空きを確認して保存し、管理者が受付、日時変更、完了、取消を処理します。
実践プロジェクト
画面を増やすたびに、利用するAPIと保存するデータを理解します。
画面は製品の表面にすぎません。API仕様、データテーブル、ユーザー識別、業務状態、エラー経路まで扱い、予約が利用者側から管理側へ本当に流れるようにします。
今週予約可能
必要なサービスを選ぶ
家電クリーニング
約90分
約90分
訪問修理
約60分
約60分
ハウスクリーニング
約120分
約120分
その他
すべて見る
すべて見る
予約時間
土曜 14:00
残り2枠
予約を確定
ミニプログラム画面
サービス一覧、日時、予約フォーム、自分の注文
ユーザー操作
業務API
空き確認、予約送信、取消、日時変更
ルール確認
データベース
ユーザー、サービス、時間枠、予約、状態履歴
実データ保存
管理画面
受付、予定管理、完了、返金、例外処理
業務の完結
02 · 27個のばらばらな例ではなく、一つの27章
前の段階で作った製品に、
前の段階で作った製品に、
実用に必要な能力を一つずつ加えます。
最初の6章で操作できる画面とミニプログラムを作り、次にAPI、データベース、ログインを接続します。その後、権限、同時処理、決済、ファイルを扱い、最後にドメイン、サーバー、監視、公開、改善まで進みます。
実データにつなぐ
API、バックエンド、データベース、ログイン、一連の動作確認。
成果物：保存できる予約フロー業務上の境界を扱う
役割、権限、セキュリティ、同時処理、決済、返金、ファイルアップロード。
成果物：取引できる業務システム公開して運用する
データ分析、ドメイン、サーバー、配備、監視、公開、バージョン改善。
成果物：公開された製品今後も変更できるようにする
Git、プロジェクト文書、文脈管理で判断を残し、将来も安全に変更できるようにします。
成果物：保守できるプロジェクト資産
各章で製品を変える
「説明を聞いた」で終わらず、各章で確認できる製品変更を残します。
第7章ではAPIの定義を理解するだけでなく、ローカルの仮データを実際のAPIに置き換え、読み込み中、空、エラー、再試行の状態を確認します。
TASK
サービス一覧をバックエンドにつなぐ
学ぶ概念：HTTPリクエスト、JSON、非同期状態、API仕様、エラー処理。
成果物：データベースのサービスを表示し、読込失敗を処理する。
受入確認リスト
1
実際のAPIを呼ぶ
画面スクリプトの固定サービス配列を使わない。
2
三つの状態を扱う
読み込み中、成功、失敗をそれぞれ明確に表示する。
3
APIデータと照合する
名称、価格、所要時間がサーバーの返却値と一致する。
4
回帰確認を行う
サービス選択と次の画面への遷移が引き続き動く。
03 · AIは実装を速め、人が方向と受入確認を担う
文脈と境界を伝えてから、
文脈と境界を伝えてから、
一つの明確な変更をAIに依頼します。
現在の製品状態、目標、変更可能な範囲、受入条件を説明し、AIにコードを理解させてから実装し、実行結果を根拠に修正する。この協働サイクルを繰り返し練習します。
AIに渡す情報
現在の状態
サービス一覧はまだ画面内の固定配列を使っている。
今回の目標
GET /api/servicesを呼び、予約可能なサービスを表示する。
変更範囲
サービス一覧画面と対応する通信モジュールだけを変更する。
受入条件
読込中、成功、空、失敗、再試行をすべて確認できる。
AIの仕事は「コードを生成した」で終わりません
01既存画面、通信処理、レスポンス構造を先に読む
02変更するファイルと状態処理を説明する
03最小限の変更を実装し、対象を絞って確認する
04推測ではなく、実際のエラーから原因を特定する
05業務ルールと最終体験を人が確認する
AIとの協働方法
AIは速く書けますが、「何をもって完了か」を推測させてはいけません。
利用経路、業務ルール、データ境界に合う変更かを確認します。エラー時はログと実際の状態を先に見て、当てずっぽうで指示を変えるのではなく、AIに根拠を追加します。
一つの製品を完成させながら、AIと開発する方法を身につけます。
27章で、要件、画面、バックエンド、データ、セキュリティ、決済、公開を一つの実践ルートにまとめます。