IBM Bobで出力した内容、Copilotへのプロンプトを含みます。
前回に続いて、Copilotを使いながら、要件定義の作成をしていきます。
Copilotで要件定義をする場合に、大体どれくらいの時間をかけて、Copilotが100％と提示する要件定義をしたのかを案内していきます。
・Copilotに 「完成系の」 要件定義書を払い出してもらう
・IBM Bobで要件定義を 「精査」 する
・粒度を比べてみる
本内容では、前回の仕様書の部分を一旦省き、Copilotに出力してもらった内容をIBM Bobで精査してもらいます。
理由は、Copilotの出力が「シンプルすぎた」からです。
Copilotでの要件定義を、チープにさせないためには？
今回Copilotで要件定義をしていきました。かなり時間をかけて質問に回答した結果、認証の項目がチープに出力されています。確かに、ID/パスワードで、と書きましたが、これは定義というより聞き取りです。
## 4. 認証
- MVP：ID / パスワード
- 拡張：SSO（Slack / LDAP 等）
Copilotにもう少し踏み込んで出力してもらうためには、さらにプロンプトを工夫する必要があり、もう少し具体性を持たせてみます。また、いっぺんにすべてを更新するのではなく、分割して指示を与える方が効果的です。
「4. 認証」の項目について、
一般的なエンタープライズ向けのセキュリティ基準（OWASP ASVS等）に基づき、
実務でそのまま使えるレベルまで具体化してください。
特に以下の項目について、標準的な数値を設定して詳細な箇条書きで出力してください：
パスワードポリシー（長さ、複雑性、禁止事項、有効期限、履歴管理）
セッション管理（有効期限、同時ログイン制御、タイムアウト設定）
パスワードリセット（リセットフロー、一時パスワードの運用）
※「MVPレベル」ではなく、商用利用に耐えうる「堅牢な仕様」として提案してください。
# 4. 認証仕様（エンタープライズレベル）
---
## 4.1 認証方式
- ID / パスワード認証（MVP）
- 将来拡張：
- SSO（SAML / OAuth2）
- MFA（多要素認証）
---
## 4.2 パスワードポリシー
### ■ 基本要件
- 最小文字数：12文字以上
- 最大文字数：128文字以下
- Unicode文字使用可（日本語・記号含む）
- 大文字・小文字・数字・記号の強制はしない
- （ただし推奨表示は行う）
---
### ■ 複雑性要件（ブラックリスト方式）
以下は禁止：
- ユーザー名・メールアドレスと一致／部分一致
- 連続文字（例：aaaa, 1234）
- 辞書攻撃に使用されるパターン
- 過去に漏洩したパスワード（HaveIBeenPwned等のリスト参照）
- よくあるパスワード
- password / 123456 / qwerty など
---
### ■ パスワード履歴
- 過去5回分のパスワードは再利用禁止
- ハッシュ化して保持（平文保存禁止）
---
### ■ 有効期限
- 期限切れポリシー：
- 原則：無期限（NIST推奨）
- ただし以下の場合は強制変更：
- 初回ログイン
- リセット後
- セキュリティインシデント発生時
---
### ■ 保存方式
- ハッシュアルゴリズム：
- bcrypt（cost 10以上）または Argon2
- ソルト：必須
- Pepper：推奨
---
## 4.3 ログイン制御
### ■ 失敗回数制限
- 5回失敗でアカウントロック
- ロック時間：
- 15分（自動解除）
- または管理者解除
---
### ■ レート制限
- 1IPあたり：
- 1分間に5回まで
- 超過時：
- 一時ブロック（HTTP 429）
---
## 4.4 セッション管理
---
### ■ セッションID
- 生成方式：
- 128bit以上の暗号学的乱数
- Cookie属性：
- HttpOnly
- Secure
- SameSite=Strict
---
### ■ セッション有効期限
- 無操作タイムアウト：
- 15分
- 最大継続時間（絶対）：
- 8時間
- ログイン直後のみ延長可能
以下略。
Copilotでの要件定義については、フィードバックループも大事ですが、より重要なのは、各項目の基準を置いてあげることでした。セキュリティではどうなのか？DBの仕様は、テーブル定義は？
より良い要件定義に落とし込むため、Copilotでの出力の方法はもっと深掘りが必要です。
再度IBM Bobに要件定義を精査してもらう
Copilotで出力した粒度の荒い要件定義を、IBM Bobで精査してもらうとどのようになるのでしょうか？プロンプトを変更する前に、実施した結果を下記で示します。
## 4. 認証・セキュリティ
### 4.1 認証方式
#### MVP
- ID / パスワード認証
- セッションベース
#### 将来拡張
- SSO（Slack / LDAP 等）
### 4.2 パスワードポリシー
- **最小長**: 8文字
- **要件**: 英大文字・小文字・数字を各1文字以上含む
- **禁止**: 辞書単語、ユーザーID含む
- **有効期限**: 90日（管理者は強制変更可）
- **履歴**: 過去3世代のパスワードは再利用不可
### 4.3 セッション管理
- **有効期限**: 8時間（アイドル時）
- **絶対期限**: 24時間
- **同時ログイン**: 1セッションのみ（新規で既存を無効化）
- **ログアウト**: 明示的ログアウトボタン
- **自動ログアウト**: 8時間無操作で自動ログアウト
### 4.4 パスワードリセット
- 管理者による強制リセット
- 初回ログイン時の変更強制
- リセット後の一時パスワード有効期限: 24時間
- 一時パスワードはランダム生成（12文字）
### 4.5 セキュリティログ
以下のイベントを記録:
- ログイン成功/失敗（IPアドレス含む）
- パスワード変更
- セッション無効化
- 権限変更
- 管理者操作
### 4.6 セキュリティ対策
- **HTTPS**: 必須（自己証明書可）
- **SQLインジェクション**: プリペアドステートメント使用
- **XSS**: 全出力をエスケープ処理
- **CSRF**: トークン検証
- **ブルートフォース**: 5回失敗でアカウントロック（15分間）
以下略
このように出力されました。結構細かく書かれています。IBM Bobで優れていると感じた点はコーディングに即した内容で、聞いている以上のことを返してくれるという点でしょう。この出力はCopilotで「出力したままのmdファイルを読ませていた」ので、プロンプト改善前の内容から出力したということです。
## 4. 認証
- MVP：ID / パスワード
- 拡張：SSO（Slack / LDAP 等）
つまりIBM Bobでは、簡易な要件定義であっても、そこからより踏み込んだ内容を出力してくれるということです。
Copilotで100％と言われた要件定義を「IBM Bob」に精査してもらう
今回2時間近くかけてCopilotの質問に答えて、得られた要件定義のmdファイルですが、このファイルをIBM Bobに再度精査してもらいました。
出てきたレポートの一部を抜粋します。
前回のMVP版から大幅に改善されています。
🔴 Critical: 1件（セキュリティ）
🟡 High: 4件（技術仕様、運用設計）
🟢 Medium: 5件（整合性、明確化）
全体的な評価:
✅ 認証・権限が明確化
✅ フェーズ遷移ルールが詳細
✅ 承認フローが具体的
✅ 通知仕様が明確
✅ エラーハンドリングが定義済み
🔴 Critical Issues（即座に対応必要）
1. パスワードポリシーとセッション管理が未定義
問題点:
「ID / パスワード」とあるが、
- パスワード要件（長さ、複雑性）
- セッション有効期限
- ログアウト処理
- パスワード変更・リセット
が未定義
リスク:
脆弱なパスワードによる不正アクセス
セッション固定攻撃
なりすまし
~~~
長いので割愛
~~~
前回からの改善点:
✅ 認証・権限が大幅に明確化
✅ フェーズ遷移ルールが詳細化
✅ 承認フローが具体化
✅ 通知仕様が明確化
✅ エラーハンドリングが追加
残存課題:
セキュリティ詳細（パスワード、セッション）
技術的詳細（ID採番、通知失敗時）
運用設計（MySQL移行、バックアップ）
推奨アクション:
上記Phase 1-2（Critical/High）を完了させてから開発着手することを推奨します。Phase 3-4は開発と並行して詰めることも可能です。
開発着手可否:
Critical/High対応後であれば、開発着手可能なレベルです。
前回より良くなった。という評価をもらいましたが、Copilotで満足いく要件定義をするためには、多くの手順が必要です。改善プロンプトを出すために、ひとつの提案として、「Copilotで出力した最終版を、IBM Bobで手直しする」というのが最速です。
できればIBM Bobにはコードを書かせたい。Copilotをどう使う
せっかく時間をかけて、Copilotを使うと決めたので、より出力の精度を上げることを諦めるわけにはいきません。ということで、提案するのはIBM Bobで出力した今回の内容と、Copilotで出力した内容を比較させて、不足を補うプロンプトを出力させることです。
「5.2 チケットID仕様」について、大規模システムでの実績がある
ID採番方式（Twitter Snowflake、UUID v7等）を参考に、以下の要件を
満たす具体的な実装仕様を提案してください：
- 一意性保証（分散環境での重複防止）
- 時系列ソート可能性
- 採番性能（秒間1000件以上）
- 月次リセットの実装方法
- デッドロック対策
※実装コード例も含めて提案してください。
## 1. 概要
本仕様では、大規模システムにおいて必要とされる以下の要件を満たすチケットID生成方式を定義する。
- 分散環境での一意性
- 時系列ソート可能性
- 高スループット（1000件/秒以上）
- 月次リセット
- デッドロック回避
---
## 2. 採用方式
**拡張Snowflake方式 + 月次論理カウンタ分離**
~~~
中略
~~~
--
## 9. 月次カウンタ実装
java
@Transactional
public long nextMonthlySequence(String ym) {
Counter c = repo.lockByYm(ym);
if (c == null) c = new Counter(ym, 1);
else c.increment();
repo.save(c);
return c.getValue();
}
---
## 10. 表示ID生成
java
public String displayId(String ym, long seq) {
return ym + "-" + String.format("%06d", seq);
}
かなり細かく出力してくれるようになりました。すでに仕様書寄りになっていますが、これくらいの粒度になると、最終的にIBM Bobが精査する時にも「使える」内容だと言えます。
トークン節約については、どう見るか？
今回Copilotで出力した結果から、IBM Bobで要件定義を出すという話で進めてきましたが、要件定義を出すためにCopilotを使って質問に回答するのは、「無駄ではない」と言えます。
9回に渡る要件の確認がありました。9回分のトークンをすべてIBM Bobで精査しながら、というのはもったいないですし、IBM Bobで出力した結果とCopilotの出力を比較することで、ある程度の精度を出力するテンプレートプロンプトを出すことができるのは先述の通りです。
結果的に、IBM Bobで消費されるトークンの多くを開発に回すことができます。要件を確定させてから、IBM Bobに渡して、Bobが理解しやすい形にした上で、開発、テストまでやってもらう。
この流れで、より良い開発ができればと思います。
次回は、実際に書いて貰ったコードが「ツールごとにどれくらい違うのか」をみていければと思います。IBM Bobをより賢く利用していただくための一助になれば幸いです。