作りたいシステムのイメージはあっても、最初から仕様書を書ける人は多くありません。
特に開発経験がない人へ「必要な機能をすべて挙げてください」「入力項目と権限を決めてください」と依頼しても、完成した画面を想像しながら文章だけで決めるのは困難です。
一方、画面があれば「この項目はいらない」「ここから検索したい」「この操作は管理者だけにしたい」と具体的に判断できます。
そこでAI駆動開発では、最初から完成した仕様書を作ろうとせず、次の順番で仕様を固める方法が分かりやすいと考えています。
AIが機能一覧のたたき台を作る
↓
人間が「やる・後で・やらない」を決める
↓
仮データで操作できるモックを作る
↓
人間が操作して修正・追加する
↓
画面から仕様を起こす
↓
バッチなど画面に現れない機能を確認する
↓
セキュリティ・性能・運用を確認する
↓
本実装へ進む
この記事では、小規模な社内向け顧客管理システムを例に、この進め方を説明します。
1. 最初に目的と利用者だけを決める
最初から詳細な仕様を考える必要はありません。まず「誰が、何のために使うのか」を一文にします。
営業担当者が、顧客からの問い合わせと対応状況を共有するための
社内向け顧客管理システムを作る。
この段階で最低限確認するのは、次の項目です。
- 主に利用する人
- 解決したい業務上の問題
- 社内限定か、外部の顧客も利用するか
- PCとスマートフォンのどちらで使うか
- 既存のExcelやシステムから移すデータがあるか
目的が曖昧なまま「CRMを作って」と依頼すると、AIは一般的なCRMの機能を大量に提案します。まず対象を狭くすることが重要です。
2. AIに機能一覧のたたき台を出させる
利用者がゼロから機能を考えるのではなく、AIに候補を出させます。
営業担当者が、顧客からの問い合わせと対応状況を共有するための
社内向け顧客管理システムを検討しています。
必要になりそうな機能を、次の形式で整理してください。
- 機能名
- 何のために必要か
- 主に利用する人
- 初期版で必要か
まだ技術選定や実装は行わないでください。
一般的な機能を無制限に追加せず、小規模な初期版を想定してください。
例えば、次のような候補が出てきます。
- ログイン
- 顧客の登録・編集
- 顧客一覧と検索
- 問い合わせの登録
- 対応履歴
- 担当者の割り当て
- ステータス管理
- メール通知
- CSV入出力
- 集計ダッシュボード
- 利用者管理
AIの一覧は、あくまで会話を始めるためのたたき台です。提案されたからといって、すべて作る必要はありません。
3. 人間が「やる・後で・やらない」を決める
各機能を次の3種類に分けます。
| 分類 | 意味 |
|---|---|
| やる | 最初の公開までに必要 |
| 後で | 必要になりそうだが、初期版には含めない |
| やらない | 今回の目的には不要 |
顧客管理システムなら、例えば次のようになります。
| 機能 | 判断 | 理由 |
|---|---|---|
| ログイン | やる | 社内データを扱うため |
| 顧客の登録・編集 | やる | 中心となる業務のため |
| 顧客一覧と検索 | やる | 登録した情報を探すため |
| 対応履歴 | やる | 問い合わせ状況を共有するため |
| CSV取り込み | 後で | 初期データは少ないため |
| 集計ダッシュボード | 後で | まずデータを蓄積するため |
| メール一斉配信 | やらない | 今回の目的ではないため |
「後で」を設けると、アイデアを捨てずに初期版の範囲を小さくできます。
AIは便利そうな機能を追加することは得意ですが、費用や納期を考えて何を作らないかを決めるのは人間の役割です。
4. 画面一覧と遷移を作る
「やる」と決めた機能から、必要な画面をAIに整理させます。
「やる」と決めた機能だけを使い、必要な画面一覧を作成してください。
各画面について、次を示してください。
- 画面名
- 利用する人
- 表示する情報
- 入力する情報
- 主な操作
- 遷移元と遷移先
- 権限による違い
「後で」「やらない」に分類した機能は含めないでください。
顧客管理システムなら、最初は次の程度で十分かもしれません。
ログイン
↓
顧客一覧 ──→ 顧客詳細 ──→ 顧客編集
│ └──→ 対応履歴の登録
└──→ 顧客新規登録
画面一覧と遷移を先に確認すると、同じ機能を複数の場所へ作ったり、操作後の行き先が決まっていなかったりする問題を見つけやすくなります。
5. 仮データで操作できるモックを作る
次に、画面を眺めるだけでなく、ボタンや画面遷移を試せるモックを作ります。
この段階では、本物のDBや外部APIへ接続する必要はありません。認証も、ログイン後の画面を確認するための仮実装に留めます。
合意した画面一覧を基に、操作確認用のモックを作成してください。
- データは固定のサンプルを使用する
- DBや外部APIへ接続しない
- 本物の認証処理は実装しない
- 一覧、詳細、登録、編集の画面遷移を確認できるようにする
- 「後で」「やらない」の機能は追加しない
- モックであり、入力内容が保存されないことを画面に表示する
- スマートフォン幅でも表示を確認できるようにする
モックに本物のDBや認証を組み込み始めると、画面を捨てにくくなります。目的は実装を進めることではなく、早い段階で認識の違いを見つけることです。
6. 人間がモックを操作して確認する
画像を見せるだけでなく、実際の業務を想定して操作してもらいます。
例えば、次の作業を順番に試します。
- 顧客を探す
- 顧客の詳細を確認する
- 新しい問い合わせを登録する
- 担当者と対応状況を変更する
- 過去の対応履歴を確認する
操作しながら、次の点を確認します。
- 一覧で最初に見たい項目は何か
- 検索条件が足りているか
- 不要な入力項目がないか
- よく使う操作に何回クリックが必要か
- 登録後にどの画面へ移動したいか
- 誰にどのボタンを見せるか
- エラー時にどう案内するか
- PCとスマートフォンのどちらを優先するか
ここで出た修正をモックへ反映し、再び操作してもらいます。文章だけで仕様を決めるより、この往復のほうが具体的な意見を得やすくなります。
7. 確定したモックから仕様を起こす
画面と操作の流れが固まったら、AIに仕様のたたき台を作らせます。
確定した画面モックと画面遷移を調査し、次を整理してください。
- 機能一覧
- 各画面の表示項目と入力項目
- 入力値の検証ルール
- 画面遷移
- API一覧
- DBテーブル案
- 利用者と権限の一覧
- 正常系と異常系のテスト項目
- 画面だけでは判断できない未決定事項
不明な仕様を推測で確定せず、「要確認」としてください。
まだ本実装は行わないでください。
画面上の要素は、次のように裏側の仕様へつながります。
| 画面で確認できるもの | 仕様として決めるもの |
|---|---|
| 入力項目 | DB項目、必須条件、文字数、形式 |
| ボタン | 機能、API、実行条件 |
| 表示内容 | データの取得条件、権限 |
| 画面遷移 | 業務フロー、成功・失敗時の動作 |
| 検索・並べ替え | 検索条件、件数、性能 |
| 利用者ごとの表示差 | 認証・認可 |
ただし、画面からすべての仕様が分かるわけではありません。
8. 画面に現れない機能を洗い出す
画面中心で仕様を決めると、定期実行される処理やシステム同士の連携が抜けやすくなります。
バッチ処理
- 日次・月次の集計
- 請求データの作成
- 期限切れデータの削除
- 古いデータのアーカイブ
- 外部システムからの定期同期
非同期処理
- メールや通知の送信
- CSVの取り込み
- 帳票やPDFの作成
- 画像や動画の変換
- 大量データの処理
外部連携
- 会計、決済、在庫システムとの連携
- Webhookの受信と送信
- ファイルの自動取り込み
- 外部APIとの同期
運用のための機能
- 監査ログ
- エラー通知
- 失敗したジョブの再実行
- バックアップと復旧
- データ修復
AIには画面仕様とは別に洗い出しを依頼します。
このシステムについて、画面には現れないが必要になる可能性がある処理を洗い出してください。
次の観点を確認してください。
- 定期バッチ
- 非同期処理
- メールや通知
- 外部システム連携
- CSVの入出力
- データの保存期限と削除
- 監査ログ
- バックアップと復旧
- エラー通知と再実行
- 集計と帳票
必要性を勝手に決定せず、「必要」「後で」「不要」「要確認」の候補として提示してください。
この一覧も人間が確認し、初期版へ入れるものを決めます。
9. 非機能要件を確認する
機能が決まったら、「何ができるか」だけでなく、安全に、十分な速さで、継続して使えるかを確認します。
セキュリティ
- 社内限定か、インターネットへ公開するか
- 管理者、一般利用者、閲覧者の権限
- 多要素認証が必要か
- 個人情報や機密情報を保存するか
- データをいつまで保存するか
- 操作履歴や監査ログが必要か
- ファイルアップロードを許可するか
- 外部APIへどの情報を送るか
- 脆弱性への対応を誰が行うか
セキュリティは本実装の最後に追加する機能ではありません。認証、権限、保存するデータなどはモックの段階から確認し、ここでシステム全体を横断して漏れがないか見直します。
具体的な確認項目は、AIで作ったアプリのセキュリティ｜事前準備と本番公開チェックリストにもまとめています。
パフォーマンス
- 利用者数と同時利用者数
- 1日あたりのアクセス数
- データ件数と増加量
- 許容できる画面表示時間
- 一覧に表示する最大件数
- CSVの最大行数とファイルサイズ
- バッチを完了させる時間
- 将来どの程度まで利用が増えるか
「高速に動作する」のような表現では、完成したか判断できません。「通常の検索結果を3秒以内に表示する」など、確認できる基準へ置き換えます。
可用性と運用
- 利用する曜日と時間帯
- どの程度の停止を許容できるか
- バックアップの頻度
- どの時点までデータを戻せればよいか
- 障害を誰へ通知するか
- 誰が復旧作業を行うか
- ログをどのくらい保存するか
- メンテナンスの時間を確保できるか
開発後に必要になるアクセス制御、アップデート、監視、バックアップ、障害対応については、AIで業務効率化する方法｜開発後の運用とセキュリティ対策で詳しく説明しています。
初心者向けには、非機能要件を次の3つで考えると分かりやすくなります。
安全に使えるか
十分な速さで動くか
壊れたときに気づき、戻せるか
10. 仕様を確認してから本実装へ進む
本実装を始める前に、少なくとも次が揃っているか確認します。
- システムの目的と利用者
- 「やる・後で・やらない」に分けた機能一覧
- 合意した画面一覧と画面遷移
- 操作確認済みのモック
- 入力項目と検証ルール
- 利用者と権限の一覧
- DBテーブル案とAPI一覧
- バッチ、通知、外部連携など画面外の機能
- セキュリティ要件
- パフォーマンス要件
- バックアップ、監視、障害対応の方針
- まだ決まっていない項目
すべてを完璧に決める必要はありません。未決定事項が見える状態にし、誰がいつ決めるかを残すことが重要です。
モックと完成品を混同しない
操作できる画面ができると、完成に近いように見えます。しかし、モックには通常、次のものがありません。
- 本物の認証と権限確認
- DBへの安全な保存
- 同時更新への対応
- 入力値の厳密な検証
- エラー処理
- バックアップと復旧
- 監視と障害通知
- セキュリティ対策
- 負荷への対応
モックには、次のように明示しておくと誤解を減らせます。
この画面は仕様確認用です。入力内容は保存されず、認証・権限・セキュリティ処理は実装されていません。
モック作成に時間をかけすぎる必要もありません。見た目の細部より、必要な情報と操作の流れを確認できることを優先します。
まとめ
AI駆動開発では、利用者へ最初から完成した仕様書を求める必要はありません。
AIに機能一覧のたたき台を出させ、人間が「やる・後で・やらない」を決めます。次に、仮データで操作できるモックを作り、実際の業務を想定して確認・修正します。
画面が固まったら、API、DB、権限、テスト項目を起こします。その後、バッチや外部連携など画面に現れない機能を補い、セキュリティ、パフォーマンス、運用を横断的に確認してから本実装へ進みます。
重要なのは、AIに最初から正解を作らせることではありません。AIにたたき台を作らせ、利用者が見て、触って、選びながら仕様を具体化することです。
技術選定と実装の進め方については、次の記事で紹介しています。
- AI駆動開発で初心者が迷いにくい技術スタック――GitからCloud Runまで
- AI駆動開発の始め方――初心者がコーディングエージェントと安全に開発する手順（公開後にリンクを追加）
本番公開前の確認事項については、次の記事にまとめています。