AI仕様決め会話例 | KCS 社内マニュアルポータル

基本方針

重要

最初から人間が整理項目を決め切らない。AIに「仕様を決めるために整理すべき項目」を提案させ、人間が漏れを判断する。

これは実装依頼ではなく、仕様決め会議であると明示する
AIにはまず整理項目と確認質問を提案させる
人間は整理項目の漏れ、過不足、業務上のリスクを判断する
決まったこと、採用しなかった案、影響範囲は必ずドキュメント化する
仕様が固まり、複数人確認が終わるまで実装させない

会話の始め方

あなた

これは実装依頼ではありません。
顧客検索画面の検索性を向上させたいので、仕様決め会議をしたいです。

まだコードは変更しないでください。
まず、このテーマで仕様を決めるために整理すべき項目を提案してください。

そのうえで、各項目について確認すべき質問も出してください。
私は、その整理項目に漏れがないかを確認します。

AIに整理項目を提案させる

AI

仕様決めのために、まず以下を整理するとよいです。

1

現状の課題

現在、何で検索できますか。何を入力しても見つけづらいですか。検索できないことが問題ですか、結果が多すぎることが問題ですか。

2

利用者と利用シーン

誰がこの検索画面を使いますか。どの業務中に検索しますか。急いで顧客を探す場面ですか、正確に絞り込む場面ですか。

3

検索対象

顧客名以外に、顧客コード、電話番号、住所、担当者名、メールアドレス、請求先名などを対象にしますか。

4

検索方式

部分一致、前方一致、完全一致、表記ゆれ対応、電話番号のハイフン有無、複数キーワード検索をどう扱いますか。

5

画面UI

検索欄は1つのままでよいですか。詳細検索欄、説明文、絞り込み条件は必要ですか。

6

検索結果

一覧に何を表示しますか。該当なしの文言、ページング、並び順は既存のままでよいですか。

7

影響範囲

UIだけの変更ですか。API検索条件、DBスキーマ、index、他画面への影響はありますか。

8

対象外

今回やらないことは何ですか。検索速度改善、表記ゆれ対応、詳細検索、検索履歴は対象外でよいですか。

9

テスト観点

検索対象ごとの正常系、該当なし、複数件ヒット、ページング維持を確認しますか。

10

ドキュメント化すべき内容

決まった仕様、実装計画、採用しなかった案と理由をどこに残しますか。

人間が漏れを判断する

あなた

整理項目はだいたい良さそうです。

追加で、以下も入れてください。

- 権限によって検索できる範囲が変わるか
- 個人情報を広く検索対象にしてよいか
- 検索ログや監査が必要か

この3つを追加したうえで、もう一度整理項目を出してください。

AI

追加観点を反映すると、整理項目は以下です。

1. 現状の課題
2. 利用者と利用シーン
3. 検索対象
4. 検索方式
5. 画面UI
6. 検索結果
7. 権限・閲覧範囲
8. 個人情報・セキュリティ
9. 検索ログ・監査
10. 影響範囲
11. 対象外
12. テスト観点
13. ドキュメント化すべき内容

次に、各項目ごとに決めるべき内容を質問形式で整理します。

一問一答で仕様を決める

あなた

OK。
ではこの13項目について、私に1つずつ質問してください。
一問一答で仕様を決めたいです。
まだ実装はしないでください。

AI

では1つ目から確認します。

## 1. 現状の課題

現在の顧客検索画面で、一番困っていることはどれですか？

1. 顧客名の一部では見つからない
2. 電話番号や顧客コードで検索できない
3. 検索結果が多すぎる
4. 表記ゆれで見つからない
5. 検索速度が遅い
6. その他

あなた

2です。
電話番号や顧客コードで検索できないのが困っています。

AI

決定事項:
- 主な課題は、顧客名以外の情報で検索できないこと
- 初期改善では、電話番号と顧客コードを優先候補にする

次の質問です。

## 2. 利用者と利用シーン

この検索画面を主に使うのは誰ですか？

例:
- 営業担当
- サポート担当
- 開発担当
- 管理者
- 全社員

あなた

営業担当とサポート担当です。
問い合わせ対応中に使います。

AI

決定事項:
- 主な利用者は営業担当とサポート担当
- 利用シーンは問い合わせ対応中
- 素早く顧客を特定できることを重視する

次の質問です。

## 3. 検索対象

初回リリースで検索対象にしたい項目を選んでください。

候補:
- 顧客名
- 顧客コード
- 電話番号
- 住所
- 担当者名
- メールアドレス
- 請求先名

あなた

初回は顧客名、顧客コード、電話番号でいいです。
住所や担当者名は後回し。

AI

決定事項:
- 初回リリースの検索対象は、顧客名、顧客コード、電話番号
- 住所、担当者名、メールアドレス、請求先名は対象外

ここまでの決定事項は、後で実装計画書に必ず残します。

次の質問です。

## 4. 検索方式

検索方式はどれがよいですか？

候補:
1. 部分一致
2. 前方一致
3. 完全一致
4. 複数キーワード検索
5. 電話番号のハイフン有無を吸収

あなた

顧客名は部分一致。
顧客コードは完全一致でもいい。
電話番号はハイフン有無を吸収したい。

AI

決定事項:
- 顧客名は部分一致
- 顧客コードは完全一致
- 電話番号はハイフン有無を吸収する
- 複数キーワード検索は今回対象外

ここで影響範囲が出ます。

影響範囲:
- UI: 検索欄の説明文変更
- API: 検索条件の分岐追加
- DB: スキーマ変更なしの想定
- テスト: 顧客名、顧客コード、電話番号それぞれの検索テストが必要

次の質問へ進めますか？

UI仕様を決める例

あなた

進めて。

AI

次の質問です。

## 5. 画面UI

検索欄はどうしますか？

候補:
1. 既存の検索欄をそのまま使う
2. プレースホルダーだけ変更する
3. 検索対象の説明文を追加する
4. 詳細検索欄を追加する

あなた

既存の検索欄をそのまま使って、プレースホルダーだけ変更。
説明文は不要。

AI

決定事項:
- 既存の検索欄を流用する
- プレースホルダーを「顧客名・顧客コード・電話番号で検索」に変更する
- 説明文や詳細検索欄は追加しない

対象外:
- 詳細検索
- 絞り込み条件
- 検索対象の説明文追加

最後に仕様メモへ落とす

AI

ここまでの仕様決定をまとめます。

# 顧客検索画面 検索性改善 仕様メモ

## 目的
問い合わせ対応中に、営業担当・サポート担当が顧客を素早く特定できるようにする。

## 解決したい課題
現在は顧客名以外で検索しづらく、電話番号や顧客コードから顧客を見つけられない。

## 初回リリースの検索対象
- 顧客名
- 顧客コード
- 電話番号

## 検索方式
- 顧客名: 部分一致
- 顧客コード: 完全一致
- 電話番号: ハイフン有無を吸収

## UI仕様
- 既存の検索欄を流用
- プレースホルダーを「顧客名・顧客コード・電話番号で検索」に変更
- 詳細検索欄は追加しない

## 対象外
- 住所検索
- 担当者名検索
- メールアドレス検索
- 詳細検索
- 検索履歴
- 複数キーワード検索
- 検索速度改善
- DBスキーマ変更

## 影響範囲
- UI: プレースホルダー変更
- API: 検索対象追加
- DB: スキーマ変更なし。ただし既存カラム確認が必要
- テスト: 顧客名、顧客コード、電話番号検索

## 実装前に確認すること
- 顧客コードの保存カラム
- 電話番号の保存形式
- 既存検索APIの利用箇所
- 権限によって検索範囲が変わるか
- 個人情報検索として問題ないか

## ドキュメント化すること
- この仕様メモを docs/specs/ に残す
- 実装作業範囲は docs/ai-work/ に残す
- 採用しなかった案と理由は docs/decisions/ に残す

この会話例の狙い
AIが整理項目を提案し、人間が漏れを判断する。仕様が固まったら、決定事項をドキュメント化してから Codex に調査だけ依頼する。

ドキュメント化ルールを見る