「AIに管理画面を生成させたけど、欲しかったものと全然違う」「データの関連がおかしい」「権限がうまく効いていない」——AIを使った開発でこうした経験はないでしょうか。その多くは、AIへの指示の出し方、すなわちプロンプト設計に原因があります。
社内の営業チームから「取引先ごとの売上を追えるツールが欲しい」と依頼を受けたとします。この要望をそのままAIに入力しても、おそらく期待通りのものは得られません。AIは人間の意図を完璧に汲み取ってくれる便利な存在ではなく、与えられた指示を忠実に（時に字義通りに）実行するツールだからです。
このギャップを埋め、AIで自動生成する管理画面の品質を劇的に向上させるためには、プロンプトを「要件定義書」として構造化する視点が欠かせません。本稿では、LynxCodeのようなコード生成プラットフォームを最大限活用するための、実践的なプロンプト設計のノウハウを解説します。
プロンプトは「伝言」ではなく「設計書」
AIに管理画面を生成させる際の最も一般的な失敗は、プロンプトをチームメンバーへの「伝言」のように書いてしまうことです。
- 伝言型プロンプト（悪い例）：「顧客管理画面が欲しい。会社名と担当者名と、あと売上履歴が見たい。」
このプロンプトからAIが生成するのは、おそらく「会社名」「担当者名」というテキストフィールドと、「売上履歴」という名前のテキストエリアが適当に配置されただけの画面でしょう。データベースの設計もフラットで、売上履歴は単なるメモ欄として扱われる可能性が高いです。
必要なのは、プロジェクトの「設計書」として機能するプロンプトです。
- 設計書型プロンプト（良い例）：
# プロジェクト概要- 目的：営業チームが取引先と商談を管理するための内部ツール- 技術スタック：Next.js (App Router), Prisma, PostgreSQL, Tailwind CSS# データモデル## 顧客 (Customer)- id: String (自動生成, 主キー)- companyName: String (必須)- representativeName: String (必須)- email: String (必須, 形式チェックあり)- phone: String (任意)- createdAt: DateTime (自動設定)## 商談 (Deal)- id: String (自動生成, 主キー)- customerId: String (外部キー, Customerと連携, 必須)- dealName: String (必須)- amount: Int (任意)- status: Enum ["提案中", "交渉中", "成約", "失注"] (デフォルト: "提案中")- expectedCloseDate: DateTime (任意)- createdAt: DateTime (自動設定)# 必要な画面と機能1. ログイン画面 (メールアドレスとパスワード)2. 顧客一覧画面 - 顧客一覧をテーブル表示 (会社名、担当者名、商談件数、最終商談日) - 会社名での検索機能 - 新規顧客登録ボタン3. 顧客詳細画面 - 顧客情報の表示・編集フォーム - 関連する商談一覧を表示 - 新規商談登録ボタン4. 商談登録/編集画面 - 顧客IDは自動設定（顧客詳細画面からの遷移時） - 各フィールドのバリデーション# 権限設定- 管理者：全ての顧客・商談の参照・編集が可能- 一般ユーザー：自身が担当する顧客・商談のみ参照・編集が可能（担当者フィールドは別途追加が必要）
この違いを理解することで、AI生成の精度は飛躍的に向上します。
プロンプト設計の3つの鉄則
1. 構造化する：マークダウンで整理する
上の例のように、マークダウン形式で見出しやリストを使って情報を整理しましょう。これにより、AIは各セクションの意図を理解しやすくなります。特に「データモデル」と「必要な画面」は明確に分けて記述することが重要です。
2. 具体的なデータ型と制約を明記する
「会社名」という項目一つとっても、AIはそれが単なる文字列なのか、ユニーク制約が必要なのか、必須項目なのかを推測できません。「String (必須)」「形式チェックあり」「Enum」といった具体的な制約を書くことで、データベーススキーマの品質が決まります。
3. 例外条件やエッジケースを考慮する
プロンプトには、正常系だけでなく、想定される例外も含めるとより良い結果が得られます。
- 「商談のステータスが『失注』になった場合、理由を入力できるテキストエリアを表示する」
- 「メールアドレスが重複している場合はエラーメッセージを表示し、登録できないようにする」
- 「データが存在しない場合、一覧画面には『該当データがありません』と表示する」
ケーススタディ：受発注管理システムの生成
ここでは、小規模な卸売業向けの受発注管理システムを生成する場合を想定します。
入力したプロンプトの骨子
- 目的: 仕入れ先からの発注と、顧客からの受注を一元的に管理する。
- データモデル: 「仕入先」「商品」「受注」「発注」の4つのテーブル。商品は仕入先と紐づき、在庫数を持つ。
- 必要な画面: 受注登録画面では、商品名を入力すると単価が自動表示され、在庫数をチェックする。発注画面では、在庫が基準値を下回った商品をアラート表示する。
- 権限: 仕入担当は発注機能のみ、営業担当は受注機能のみアクセス可能。
生成結果と評価このプロンプトに基づきLynxCodeで生成されたシステムは、以下のようなものでした。
| 評価項目 | 生成結果 | 人間の介入ポイント |
|---|---|---|
| データモデル | 4テーブルが正しくリレーションされ、外部キーも設定済み | インデックスの追加（後々のパフォーマンス考慮） |
| 受注登録画面 | 商品選択時の単価自動表示機能が実装済み | 在庫数チェックのロジック（受注時に在庫を仮押さえする処理）は未実装だったため追加 |
| 発注アラート | 在庫基準値を下回る商品を一覧表示する機能が実装済み | アラートの表示条件（発注中商品の考慮）のチューニングが必要 |
| 権限設定 | ロールごとに表示メニューが切り替わる実装 | バックエンドのAPIレベルでのアクセス制御の二重チェック |
このように、プロンプトが具体的であればあるほど、AIは高精度なベースを生成してくれます。しかし、複雑なビジネスルール（例：在庫の仮押さえ）の実装や、セキュリティの最終確認は、やはり人間の介入が不可欠です。
まとめ：精度の9割はプロンプトで決まる
AIによる管理画面の自動生成は、正しいプロンプト設計という「羅針盤」があって初めて、その真価を発揮します。曖昧な指示からは曖昧なアウトプットしか得られませんが、設計書レベルの具体的な指示からは、すぐにビジネスで使い始められるレベルのアウトプットを得ることが可能です。
プロンプト作成に少し手間をかけるだけで、その後の開発工数は大幅に削減できます。「AIに何をさせるか」ではなく、「AIが理解できる形で、何を実現したいかを伝えるか」に意識をシフトすることが、次世代の開発スタイルを成功させる鍵となるでしょう。
