AIコーディングエージェントを使えば、顧客管理画面を短時間で作れるようになりました。
しかし、Excelにある会社名、担当者名、電話番号をWeb画面へ移しただけでは、仕事が便利になるとは限りません。利用者が1人で、現在のExcelに困っていないなら、システムを作らないほうがよい場合もあります。
大切なのは「顧客台帳をWeb化すること」ではなく、現在の業務で起きている問題を解決することです。
この記事では、少人数の営業チームで利用する顧客管理システムを例に、次の流れを具体的に説明します。
現在の困り事を整理する
↓
AIに機能候補を出させる
↓
人間が作る機能を選ぶ
↓
画面一覧とモックを作る
↓
実際の業務を想定して確認する
↓
画面外の処理と非機能要件を補う
↓
本実装する単位へ分ける
ここで扱うAI駆動開発は、AIを顧客管理システムへ組み込むことではありません。AIコーディングエージェントを開発者として利用し、人間が目的と判断を担当しながらシステムを作る方法です。
今回想定する会社
次のような小規模企業を例にします。
- 営業担当者は5人
- 顧客情報を共有Excelで管理している
- 電話やメールで受けた問い合わせもExcelへ記録する
- 営業担当者と管理者が利用する
- 社外の顧客はシステムを利用しない
現在、次の問題が起きています。
- 同じ顧客が重複して登録される
- 誰が最後に対応したのか分からない
- 対応期限を過ぎても気づかない
- 担当者が休むと、ほかの人が経緯を確認できない
- ファイルのコピーが作られ、どれが最新か分からない
- 顧客情報を全員が自由に削除できる
この例では、顧客情報を表示することより、問い合わせを誰が担当し、いつまでに対応し、何を行ったかを共有することが中心になります。
1. まず「作る必要があるか」を確認する
AIで作り始める前に、既存の道具で解決できないかを確認します。
例えば、次の条件ならExcelや共有スプレッドシートを継続する選択もあります。
- 利用者が1人
- 顧客数が少ない
- 同時に編集しない
- 対応履歴や期限を管理しない
- 利用者ごとの権限が不要
- 現在の運用で問題が起きていない
一方、今回の例では、複数人での利用、対応履歴、期限管理、権限制御が必要です。単一の台帳ではなく、業務の流れを管理したいため、Webアプリを検討する理由があります。
顧客を登録する
↓
問い合わせを記録する
↓
担当者と期限を決める
↓
対応内容を追記する
↓
対応済みにする
この流れのどこで問題が起きているかを確認してから、機能を考えます。
Webアプリ化すると、社内LANや共有フォルダへ直接接続させる代わりに、IDを中心としたゼロトラスト型のアクセス制御を通じて、許可した利用者や端末からモバイルアクセスできる構成も選べます。営業担当者が外出先から顧客情報や対応状況を確認できれば、帰社してExcelへ転記する作業も減らせます。
また、顧客台帳と対応履歴がDBへ整理されていれば、将来は次のような処理へつなげられます。
- 対応期限や次回連絡日のリマインド
- 見積書・請求書作成システムとの連携
- 入金状況や契約状況の表示
- メールやカレンダーとの連携
- 顧客ごとの問い合わせ件数や対応状況の集計
ただし、Web化やDB化だけで自動的に実現するわけではありません。アクセス制御、連携先、データ項目、失敗時の再実行などを設計し、必要になった機能から追加します。
2. AIに機能候補を出させる
必要な機能を人間がゼロから列挙するのではなく、AIにたたき台を作らせます。
営業担当者5人と管理者が利用する、社内向け顧客管理システムを検討しています。
現在は共有Excelを使っていますが、次の問題があります。
- 顧客の重複登録
- 問い合わせの対応漏れ
- 対応履歴を共有できない
- 担当者と期限が分からない
- 全員が顧客情報を削除できる
この問題を解決するために必要になりそうな機能を提案してください。
各機能について、次を示してください。
- 機能名
- 解決する問題
- 利用する人
- 初期版で必要か
まだ技術選定や実装は行わないでください。
AIからは、例えば次のような候補が出てきます。
- ログイン
- 顧客の登録・編集
- 重複候補の表示
- 顧客の検索
- 問い合わせの登録
- 担当者の割り当て
- 対応期限の設定
- 対応履歴の記録
- 未対応一覧
- メール通知
- CSV入出力
- 集計ダッシュボード
- 顧客の削除
- 利用者管理
- 監査ログ
この時点では、機能を実装させません。
3. 「やる・後で・やらない」を決める
AIの提案を、初期版へ入れるもの、後回しにするもの、今回作らないものへ分けます。
| 機能 | 判断 | 理由 |
|---|---|---|
| ログイン | やる | 社内データを保護するため |
| 顧客の登録・編集 | やる | 基本となる機能のため |
| 顧客の検索 | やる | 必要な顧客を探すため |
| 問い合わせの登録 | やる | 対応状況を共有するため |
| 担当者と期限の設定 | やる | 対応漏れを防ぐため |
| 対応履歴 | やる | 引き継ぎを可能にするため |
| 未対応一覧 | やる | 期限超過に気づくため |
| 利用者管理 | やる | 退職・異動へ対応するため |
| 顧客の削除 | 管理者のみ | 誤削除を防ぐため |
| 重複候補の表示 | 後で | 初期版はメールアドレスの重複を拒否するため |
| メール通知 | 後で | まず画面上の未対応一覧で運用を試すため |
| 請求システム連携 | 後で | 顧客管理の運用を固めてから連携項目を決めるため |
| CSV取り込み | 後で | 初期データの移行時だけ別途対応するため |
| 集計ダッシュボード | 後で | データが蓄積してから必要性を判断するため |
| AIによる顧客評価 | やらない | 今回の問題解決に不要なため |
ここで重要なのは、AIが提案した機能を全部作らないことです。
例えばメール通知は便利ですが、通知先、送信失敗、再送、配信停止など、画面以外の仕様も必要になります。初期版では未対応一覧だけで業務が回るかを試し、不足したら追加します。
4. 利用者と権限を決める
画面を作る前に、利用者の種類だけは決めておきます。今回の例では、営業担当者と管理者の2種類とします。
| 操作 | 営業担当者 | 管理者 |
|---|---|---|
| 顧客を閲覧する | 可 | 可 |
| 顧客を登録・編集する | 可 | 可 |
| 問い合わせを登録する | 可 | 可 |
| 対応履歴を追加する | 可 | 可 |
| 顧客を削除する | 不可 | 可 |
| 利用者を追加・停止する | 不可 | 可 |
| 監査ログを確認する | 不可 | 可 |
画面上でボタンを隠すだけでは権限制御になりません。本実装では、APIやサーバー処理でも権限を確認します。
5. 画面一覧を作る
「やる」と決めた機能から、AIに画面一覧を作らせます。
決定した機能と権限表を基に、初期版の画面一覧と画面遷移を作成してください。
各画面について、次を示してください。
- 画面名
- 利用者
- 表示項目
- 入力項目
- 主な操作
- 遷移元と遷移先
- 営業担当者と管理者の違い
「後で」「やらない」にした機能は含めないでください。
今回の画面構成は、次のようになります。
ログイン
↓
未対応一覧
├──→ 顧客一覧 ──→ 顧客詳細 ──→ 顧客編集
│ ├──→ 問い合わせ登録
│ └──→ 対応履歴追加
├──→ 顧客新規登録
└──→ 利用者管理（管理者のみ）
ログイン後の最初の画面は、顧客一覧ではなく未対応一覧としました。今回解決したい問題が、顧客情報の保管ではなく対応漏れだからです。
6. 仮データでモックを作る
画面構成が決まったら、AIコーディングエージェントに操作確認用のモックを作らせます。
決定した画面一覧と権限表を基に、顧客管理システムのモックを作成してください。
- 固定のサンプルデータを使用する
- DBや外部APIへ接続しない
- 本物のログイン処理は作らない
- 営業担当者と管理者の表示を切り替えられるようにする
- 一覧、詳細、登録、編集の画面遷移を確認できるようにする
- 登録や編集の内容は再読み込みすると元へ戻ってよい
- 「後で」「やらない」にした機能は追加しない
- 画面上に「仕様確認用モック」と表示する
- PCとスマートフォンの幅で確認できるようにする
モックの目的は、デザインを完成させることではありません。必要な情報と業務の流れを、人間が具体的に確認できる状態にすることです。
7. 実際の業務をモックで試す
営業担当者と管理者に、実際の業務を想定して操作してもらいます。
営業担当者に試してもらう操作
- 今日が期限の問い合わせを探す
- 顧客の過去の対応履歴を確認する
- 電話で受けた問い合わせを登録する
- 自分を担当者に設定する
- 対応内容を記録して完了にする
管理者に試してもらう操作
- 期限を過ぎた問い合わせを確認する
- 担当者が不在の問い合わせを別の人へ割り当てる
- 重複して登録された顧客を確認する
- 退職者のアカウントを停止する
操作してもらうと、例えば次のような意見が出るかもしれません。
- 顧客一覧より、未対応一覧を最初に表示したい
- 会社名だけでなく電話番号でも検索したい
- 対応履歴に次回連絡日が必要
- 期限超過を色だけでなく文字でも表示したい
- 完了した問い合わせを再度開けるようにしたい
- 顧客の削除ではなく利用停止にしたい
これらを反映して、もう一度操作してもらいます。
8. モックから仕様を起こす
モックが固まったら、AIに本実装の仕様を整理させます。
確定した顧客管理システムのモックと権限表を調査してください。
次を作成してください。
- 機能一覧
- 画面遷移
- 各画面の表示項目と入力項目
- 入力値の検証ルール
- API一覧
- DBテーブル案
- 認証と権限の確認箇所
- 正常系と異常系のテスト項目
- 画面だけでは判断できない未決定事項
不明な仕様を推測で確定せず、「要確認」としてください。
まだ本実装は行わないでください。
今回の例では、少なくとも次のデータが必要になりそうです。
利用者
└─ 営業担当者／管理者
顧客
├─ 会社名
├─ 担当者名
├─ メールアドレス
├─ 電話番号
└─ 利用状態
問い合わせ
├─ 顧客
├─ 件名
├─ 内容
├─ 担当者
├─ 対応期限
└─ ステータス
対応履歴
├─ 問い合わせ
├─ 対応者
├─ 対応日時
└─ 対応内容
これはまだDB設計のたたき台です。同じ顧客に複数の連絡先があるか、担当者を変更した履歴を残すかなど、業務に合わせて決めます。
9. 画面に現れない処理を確認する
モックからは見つけにくい処理を、別に確認します。
| 処理 | 初期版での判断 |
|---|---|
| 期限超過の判定 | 必要。画面表示時に判定する |
| 期限前のメール通知 | 後で追加を検討する |
| 次回連絡日のリマインド | 日付の運用を固めてから追加する |
| 請求システム連携 | 連携するデータと責任範囲を決めてから追加する |
| 日次集計 | 不要 |
| CSV取り込み | 初回移行だけ別途実施する |
| 監査ログ | 顧客削除と利用者変更は記録する |
| 自動バックアップ | 必要 |
| 失敗ジョブの再実行 | 初期版では対象ジョブなし |
| 古いデータの削除 | 保存期間を確認してから決める |
メール通知を追加する場合は、定期バッチやジョブキューが必要になる可能性があります。画面へ通知ボタンを足すだけでは終わりません。
10. セキュリティ・性能・運用を確認する
セキュリティ
- 社内の利用者だけがアクセスできるか
- モバイルアクセス時も利用者、端末、接続条件を確認できるか
- ゼロトラスト型のアクセス制御をどこへ適用するか
- 退職者のアカウントを停止できるか
- 顧客情報を閲覧できる範囲は適切か
- 営業担当者が顧客を削除できないか
- URLのIDを変更して別の顧客を閲覧できないか
- DBや管理画面をインターネットへ直接公開していないか
- 個人情報をログへ出力していないか
- 操作履歴をどこまで残すか
具体的な確認項目は、AIで作ったアプリのセキュリティ｜事前準備と本番公開チェックリストにもまとめています。
パフォーマンス
今回のような5人向けシステムで、最初から大規模構成を作る必要はありません。ただし、確認できる基準は決めます。
- 初期の顧客数と年間の増加数
- 対応履歴の件数
- 同時に利用する人数
- 通常の一覧や検索を何秒以内に表示するか
- 一度に表示する最大件数
- CSVを扱う場合の最大行数
運用
- 誰が利用者を追加・停止するか
- 誰がバックアップの成功を確認するか
- 障害通知を誰が受け取るか
- どこまでデータを戻せればよいか
- OSやライブラリを誰が更新するか
- 問い合わせを誰が受け付けるか
アプリが動くことと、安全に使い続けられることは別です。開発後の運用については、AIで業務効率化する方法｜開発後の運用とセキュリティ対策でも説明しています。
11. 本実装を小さな単位へ分ける
仕様が固まっても、システム全体を一度に実装させません。確認できる単位へ分けます。
1. プロジェクトとテスト環境を準備する
2. 利用者と認証を実装する
3. 顧客テーブルとマイグレーションを作る
4. 顧客の登録・一覧・詳細を実装する
5. 顧客検索を実装する
6. 問い合わせの登録を実装する
7. 担当者・期限・ステータスを実装する
8. 対応履歴を実装する
9. 管理者の利用者管理を実装する
10. 監査ログ、バックアップ、監視を確認する
各工程で、差分、テスト結果、認証、権限、DBマイグレーションを確認し、Gitへコミットしてから次へ進みます。
この例で作らなかったもの
初期版では、次の機能を作りませんでした。
- 売上予測
- 営業成績ランキング
- 高度な集計ダッシュボード
- AIによる顧客評価
- メールの一斉配信
- 外部の顧客が利用するポータル
- 複数部署にまたがる承認フロー
将来必要になる可能性はありますが、現在の問題を解決するためには不要です。使われるか分からない機能を先に作るより、初期版を実際に使い、不足したものを追加します。
まとめ
顧客管理システムを作る目的は、ExcelをWeb画面へ置き換えることではありません。
今回の例では、顧客情報そのものより、問い合わせ、担当者、期限、対応履歴を共有し、対応漏れを防ぐことに価値がありました。
AIには、機能候補、画面一覧、モック、APIやDBのたたき台を作らせられます。しかし、何に困っているか、どの機能を作るか、誰に何を許可するかを決めるのは人間です。
AIに案を出させる
→ 人間が選ぶ
→ モックを触って修正する
→ 画面外の処理を補う
→ 安全性と運用を確認する
→ 小さく実装する
AIで作れるようになったからこそ、「作れるか」ではなく、何を解決するために作るのかを最初に確認することが重要です。
技術選定については、次の記事で初心者向けの構成例を紹介しています。
本番公開前の確認事項については、次の記事にまとめています。