AIでアプリを作る前に決めること｜少ないトークンでイメージどおりに仕上げる進め方
AIに「アプリを作って」と頼めば、短時間で画面やプログラムを作れるようになりました。
しかし、完成したものを見て「思っていたものと違う」と感じたり、何度も修正を繰り返してトークンを多く使ったりすることもあります。
原因は、AIの性能だけではありません。作り始める前に決めることと、AIへ任せることが整理されていないケースが多いのです。
今回は問い合わせ受付アプリを例に、次の順番で進める方法を紹介します。
要件を決める
基本機能と概要図を作る
各機能の設定を決める
機能単位で作る
動作を確認する
AIと自分の役割を分ける
すべてを一度にAIへ依頼するのではなく、最初に全体像を固めてから小さく作ることが、トークンを抑えながら自分のイメージへ近づけるポイントです。
最初から「全部作って」と頼むと何が起きるのか
たとえば、AIへ次のように依頼したとします。
「問い合わせを受け付けるWebアプリを作ってください」
これだけでも、AIはそれらしいアプリを作れます。ただし、AIには次の内容が分かりません。
誰が使うのか
どの情報を入力するのか
入力した情報をどこへ保存するのか
誰へ通知するのか
管理画面は必要なのか
ログインは必要なのか
どこへ公開するのか
何をもって完成とするのか
情報が足りない部分はAIが推測します。その推測と自分のイメージが違えば、作った後に大きな修正が必要になります。
そのため、最初の仕事はプログラムを作ることではなく、AIが推測しなくてよい状態を作ることです。
ステップ1：要件は自分が決め、AIに整理させる
要件とは、「何のために、誰が、何をできるアプリにするか」という土台です。
問い合わせ受付アプリなら、最初に自分で次の内容を決めます。
目的：Webサイトから問い合わせを受け付ける
利用者：商品やサービスに興味がある人
管理者：問い合わせへ対応する担当者
必須機能：入力、送信、保存、通知、管理画面
完了条件：利用者が送信でき、管理者が内容を確認できる
ここで大切なのは、技術名まで自分で決めなくてもよいことです。「データベースは何を使えばよいか」が分からなくても、保存したい情報と利用方法は決められます。
自分が目的と希望を伝え、AIには不足している要件の整理や選択肢の提示を任せます。
要件整理をAIへ頼む例
AIへの依頼内容：
問い合わせ受付アプリを作りたい
利用者は名前、メールアドレス、問い合わせ種別、本文を入力する
送信内容を保存し、担当者へメール通知する
担当者はログイン後の管理画面で内容を確認する
まだ実装は行わない
不足している要件と、決める必要がある項目だけを一覧にする
この段階ではコードを書かせません。まず認識のずれを見つけることにトークンを使います。
ステップ2：基本機能と概要図を先に作る
要件が整理できたら、アプリを機能に分けます。
問い合わせ受付アプリの基本構成は次のようになります。
利用者 → 問い合わせ画面 → 送信処理 → データベース保存
データベース保存 → 担当者へメール通知
担当者 → ログイン → 管理画面 → 問い合わせ確認
このような簡単な概要図でも、どこに画面があり、どこでデータを保存し、誰へ通知するかが見えるようになります。
AIには、文章から概要図と機能一覧を作らせます。自分は、その流れが実際の使い方と合っているかを確認します。
自分が確認すること
利用者の操作順がイメージと合っているか
必要な画面が不足していないか
不要な機能が追加されていないか
入力した情報が正しい相手へ届くか
管理者だけが見られる情報が守られているか
概要図の段階なら、変更しても大きな手戻りになりません。先に画面やDBを作ってしまうより、少ないトークンで修正できます。
ステップ3：各機能で必要な設定を決める
全体の流れが決まったら、機能ごとの設定を整理します。
問い合わせ画面の設定
表示する入力項目
必須項目と任意項目
入力できる文字数
メールアドレスの形式確認
送信前の確認画面の有無
送信完了時に表示するメッセージ
見た目や入力しやすさは、自分が実際の画面を見て判断します。AIには、指定した項目や入力チェックの実装を任せます。
データベースの設定
保存する項目
問い合わせ番号の付け方
受付日時
対応状況
誰が閲覧できるか
保存期間と削除方法
バックアップ方法
AIにはデータ構造の案を作らせられますが、個人情報を何のために保存し、いつまで保管するかは自分で決める必要があります。
メール通知の設定
通知先のメールアドレス
件名
本文へ載せる情報
送信に失敗した場合の記録
再送の有無
メール本文へ個人情報をすべて載せる必要があるかも確認します。「届けばよい」だけでなく、安全性も含めて決めます。
ログインと権限の設定
管理画面へログインできる人
管理者と一般担当者の権限差
パスワードの管理方法
多要素認証の有無
退職者や担当変更時のアカウント停止方法
ログイン機能をAIが作れても、誰へどの権限を与えるかは運用する側の判断です。
公開と運用の設定
公開先
独自ドメイン
HTTPS
環境変数と秘密情報
エラーログ
ヘルスチェック
バックアップ
障害通知先
公開後は「画面が開く」だけでは正常とは言えません。送信、DB保存、メール通知までを確認できるようにします。これは前回紹介した監視やエラーログにもつながります。
ステップ4：アプリ全体ではなく、機能単位でAIへ依頼する
設定が決まったら、実装を小さく分けます。
おすすめの順番は次のとおりです。
問い合わせ画面を作る
入力チェックを追加する
DBへ保存する
メール通知を追加する
ログイン画面を作る
管理画面を作る
ログと監視を追加する
1つの機能を作るたびに確認すれば、問題があった場所を特定しやすくなります。
「全部作った後で動かない」という状態では、AIも多くのファイルやログを読み直す必要があります。機能単位なら、確認対象が小さいため、回答や修正に使うトークンも抑えられます。
実装を依頼するときの型
毎回の依頼には、次の5点だけを入れます。
今回の目的
変更してよい範囲
参照する仕様書
完了条件
行ってはいけない操作
たとえば問い合わせ画面なら、次のように依頼します。
AIへの依頼内容：
要件書と概要図を先に読む
今回は問い合わせ入力画面だけを作る
名前、メールアドレス、問い合わせ種別、本文を表示する
必須項目が未入力なら送信できないようにする
DB保存、メール送信、公開はまだ行わない
実装後に変更ファイルと確認方法を報告する
この依頼なら、AIが勝手に作業範囲を広げることを防ぎやすくなります。
ステップ5：機能確認はAIと自分の両方で行う
AIが「完成しました」と報告しても、それだけで完了にはしません。
機能確認には、機械的に確認できる部分と、人が使って判断する部分があります。
AIへ任せやすい確認
必須項目が未入力のときにエラーになるか
正しい入力でDBへ1件保存されるか
メール送信処理が実行されるか
一般利用者が管理画面へ入れないか
エラー時にログが記録されるか
既存機能が壊れていないか
自分が確認すること
画面の見た目がイメージと合っているか
項目名が利用者に分かりやすいか
スマートフォンで操作しやすいか
完了メッセージが自然か
実際の業務で無理なく使えるか
個人情報の扱いに問題がないか
AIは仕様との一致を確認するのが得意です。一方、「この画面なら利用者が迷わないか」「業務で本当に使えるか」という最終判断は人が行います。
機能確認をAIへ頼む例
AIへの依頼内容：
実装は変更せず、問い合わせ送信機能を確認する
正常な入力、必須項目の未入力、長すぎる本文、不正なメール形式を試す
画面表示、DB保存件数、通知処理、エラーログを確認する
確認できた事実と未確認項目を分ける
問題があっても、修正や再実行は勝手に行わない
実装と確認を一度に頼まず、確認だけの依頼を分けると、AIがどこまで実施したか分かりやすくなります。
AIと自分の役割をどう分けるか
基本的な考え方は、「目的と最終判断は自分、整理と作業はAI」です。
自分が担当すること
アプリを作る目的
誰に使ってほしいか
必要な機能と優先順位
見た目や操作感
保存する情報と利用目的
許容できる費用やリスク
公開してよいかの最終判断
AIへ任せること
要件の不足確認
概要図と機能一覧の作成
技術やサービスの候補整理
プログラムの実装
テスト項目の作成と実行
エラー原因の調査
仕様書や変更履歴の更新
重要な設定をAIへ提案させることはできます。しかし、その提案を採用するかどうかは、自分の目的、予算、安全性に合わせて決めます。
トークンを少なくする7つの工夫
1．最初に要件をMarkdownへ保存する
毎回同じ説明を入力せず、要件書を正本としてAIに読ませます。
2．決定事項と未決定事項を分ける
決まった内容をAIに何度も考え直させないようにします。
3．1回の依頼を1つの目的に絞る
画面作成、DB保存、通知、テストを分けて依頼します。
4．変更してよい範囲を指定する
関係のないファイルを読んだり修正したりする量を減らします。
5．完了条件を先に書く
どこまでできれば終了なのかを明確にし、不要な追加作業を防ぎます。
6．エラー時はログの必要部分だけ渡す
ログ全体ではなく、発生時刻、エラーレベル、対象機能、前後の行へ絞ります。認証情報や個人情報は渡しません。
7．作業後に資料を更新する
変更した設定と確認結果をMarkdownへ残し、次回はその続きから始めます。
毎回使える短いプロンプト
共通資料を用意した後は、次の形式を使えます。
AIへの依頼内容：
作業前に要件書、概要図、設定一覧、前回の確認結果を読む
今回の目的は「〇〇機能の作成」
変更対象は「〇〇フォルダ」のみ
完了条件は「〇〇が成功し、確認結果を記録できること」
公開、削除、課金、外部送信は行わない
不明点は推測で実装せず、未確認として報告する
完了後に変更ファイル、確認結果、残課題をMarkdownへ追記する
長い背景説明を毎回書く代わりに、共通資料を読ませ、今回の差分だけを伝えるのがポイントです。
まとめ
AIでアプリを作るときは、最初から完成品を一度に作らせる必要はありません。
まず自分が目的と完成イメージを決め、AIに要件、基本機能、概要図、設定項目を整理させます。その後、機能ごとに実装と確認を繰り返します。
自分は、目的、優先順位、見た目、業務上の使いやすさ、公開判断を担当します。AIには、整理、実装、テスト、エラー調査、資料更新を任せます。
このすみ分けができると、AIの推測による手戻りが減り、使うトークンを抑えながら、自分のイメージに近いアプリを作りやすくなります。
次回以降は、要件書や概要図をどのようなMarkdownで管理すればよいか、ローカル環境でAIへ依頼するときに何を読ませるかについても、具体的なテンプレートとともに紹介していきます。
ITty Plus（イッティプラス） 現役インフラSE／個人事業主
#AI #IT #アプリ開発 #生成AI #個人開発 #業務改善
