はじめに
最近Microsoftが開発しているAutogenを利用したPOCをしているのですが、その中でSequential Chatsを利用して要件定義を作成するサンプルを作成したので、ここで紹介します。
必要なもの
- Streamlit (Webアプリケーションフレームワーク)
- Autogen (pip intstall pyautogen でインストールしてください)
- LLM (今回の例ではLM Studioを使用していますが、OllamaやOpenAIでも利用可能です)
- Model: mistral-nemo-instruct-2407(LM Studio)
コード例
Streamlitで以下のような感じでコードを作成しています。
import autogen
from autogen import AssistantAgent, UserProxyAgent
import streamlit as st
class TrackableAssistantAgent(AssistantAgent):
def _process_received_message(self, message, sender, silent):
return super()._process_received_message(message, sender, silent)
class TrackableUserProxyAgent(UserProxyAgent):
def _process_received_message(self, message, sender, silent):
with st.chat_message(sender.name):
st.markdown(message)
return super()._process_received_message(message, sender, silent)
config_list = autogen.config_list_from_json(
env_or_file="pages/LLM_CONFIG_LIST.json",
)
filter_mistral = {"model": ["mistral-nemo-instruct-2407"]}
writer_task1 ="""
ある書店チェーンのシステム開発を考えています。
売上、受発注、棚卸、入金に関するシステムを実装したいです。
そのための要件定義を提案してください。
"""
reviewer_task1 = """
設計者(Writer)が提出した内容が要件に適合しているか、品質が高いかを確認することが求められます。
ユーザーやクライアントから提出された内容に要件が適合しているか、品質が高いかを確認し、設計者(Writer)にフィードバックを提供してください。
また文章の体裁、誤字脱字、表現の統一にも注意してフィードバックを提供してください。
特に、以下の点についてレビューを行ってください。
- 内容の明確性, 説明の適切さ
- 要件の過不足の確認, 不足している場合は追加要件の提案
- ドキュメントの体裁, 誤字脱字の確認
- フロー図の正確性, 説明の明確さ
- ドキュメントの一貫性, 表現の統一
- その他の改善点
必ず日本語で会話は行ってください
"""
writer_task2 = """
Reviewerからのフィードバックを受けて、要件定義書を再作成してください。
要件定義書は日本語で記述し、Markdown形式で提出してください。
フロー図や図式に関しては必ずMermaid形式で記述し、他のWebサイト等やリンクを利用しないでください。
"""
writer_task_last = """
Reviewerからのフィードバックを受けて、要件定義書を再作成して[最終案]という文言を付与して提出してください。
要件定義書は日本語で記述し、Markdown形式で提出してください。
フロー図や図式に関しては必ずMermaid形式で記述し、他のWebサイト等やリンクを利用しないでください。
"""
reviewer_task2 = """
設計者(Writer)が提出した内容が要件に適合しているか、品質が高いかを確認することが求められます。
ユーザーやクライアントから提出された内容に要件が適合しているか、品質が高いかを確認し、設計者(Writer)にフィードバックを提供してください。
また文章の体裁、誤字脱字、表現の統一にも注意してフィードバックを提供してください。
特に、以下の点についてレビューを行ってください。
- 内容の明確性, 説明の適切さ
- 要件の過不足の確認, 不足している場合は追加要件の提案
- ドキュメントの体裁, 誤字脱字の確認
- フロー図の正確性, 説明の明確さ
- ドキュメントの一貫性, 表現の統一
- その他の改善点
必ず日本語で会話は行ってください
"""
with st.container():
user_input = st.chat_input("Give some goal for the agent ...")
if user_input:
with st.chat_message("User"):
st.markdown(user_input)
llm_config = {
"timeout": 600,
"config_list": autogen.filter_config(config_list, filter_mistral),
"cache_seed": None,
"temperature": 0,
"price": [0, 0],
}
writer = TrackableAssistantAgent(
name="Writer",
llm_config=llm_config,
max_consecutive_auto_reply=2,
system_message="""
あなたは、アプリケーション開発における設計の専門家です。
クライアントからの要望や要求定義から、要件定義書を作成してください。
作成する成果物としては基本的な要件定義の項目の他に以下のものを考慮して必要に応じて追加してください。
ただしユーザーから指定があった場合はそれに合わせてください。
- 機能用件
- ユースケース図
- 業務フロー図
- システム設計書
- アーキテクチャ図
- データモデル(テーブル形式で記述してください)
- ユーザーインターフェース
- エラー処理
- バックアップ
- セキュリティ
- パフォーマンス
- ログ管理
- 非機能要件
ドキュメントはMarkdown形式で記述してください。
フロー図やクラス図、モデル、その他の図に関しては必ずMarkdownもしくはMermaid形式で記述し、他のWebサイト等やリンクを利用しないでください。
テーブル形式のものはMarkdownのテーブル形式で記述してください。
画像生成は行わないでください。
修正や指摘が与えられた場合は全文を修正して再提出してください。
""",
)
Reviewer = TrackableAssistantAgent(
name="Reviewer",
llm_config=llm_config,
max_consecutive_auto_reply=2,
system_message="""
あなたは、設計の品質を向上させるためのフィードバックを提供するレビュアーです。
設計者(Writer)が提出した内容が要件に適合しているか、品質が高いかを確認することが求められます。
ユーザーやクライアントから提出された内容に要件が適合しているか、品質が高いかを確認し、設計者(Writer)にフィードバックを提供してください。
また文章の体裁、誤字脱字、表現の統一にも注意してフィードバックを提供してください。
特に、以下の点についてレビューを行ってください。
- 内容の明確性, 説明の適切さ
- 要件の過不足の確認, 不足している場合は追加要件の提案
- ドキュメントの体裁, 誤字脱字の確認
- フロー図の正確性, 説明の明確さ
- ドキュメントの一貫性, 表現の統一
- その他の改善点
""",
)
user_proxy = TrackableUserProxyAgent(
name="User",
human_input_mode="NEVER",
is_termination_msg=lambda x: x.get("content", "").find("TERMINATE") >= 0,
code_execution_config=False
)
user_proxy.initiate_chats(
[
{
"chat_id": 0,
"recipient": writer,
"message": user_input,
"clear_history": True,
"silent": False,
"max_turns": 1,
"summary_method": "last_msg"
},
{
"chat_id": 1,
"recipient": Reviewer,
"message": reviewer_task1,
"clear_history": False,
"silent": False,
"max_turns": 1,
"summary_method": "last_msg"
},
{
"chat_id": 2,
"recipient": writer,
"message": writer_task2,
"clear_history": False,
"silent": False,
"max_turns": 1,
"summary_method": "last_msg"
},
{
"chat_id": 3,
"recipient": Reviewer,
"message": reviewer_task2,
"clear_history": False,
"silent": False,
"max_turns": 1,
"summary_method": "last_msg"
},
{
"chat_id": 4,
"recipient": writer,
"message": writer_task_last,
"clear_history": False,
"silent": False,
"max_turns": 1,
"summary_method": "last_msg"
}
],
)
コード解説
class TrackableAssistantAgent(AssistantAgent):
def _process_received_message(self, message, sender, silent):
return super()._process_received_message(message, sender, silent)
class TrackableUserProxyAgent(UserProxyAgent):
def _process_received_message(self, message, sender, silent):
with st.chat_message(sender.name):
st.markdown(message)
return super()._process_received_message(message, sender, silent)
AutogenのAssistantAgent, UserProxyAgentのラッパークラスです。
Streamlitで会話を表示する場合、このようにコードを実装するとうまくいきます。
UserProxyAgentではst.chat_message...を書いていますが、AssistantAgentでは特に何もしていません。
AIの回答のみを出す場合はこれでOKですが、もしUserからの指示も表示させたい場合はAssistantAgentにもst.char_message...を実装すればいいです。
writer_task1 を書いていますが、これをStreamlitで最初の質問として記入してください。
config_list = autogen.config_list_from_json(
env_or_file="pages/LLM_CONFIG_LIST.json",
)
filter_mistral = {"model": ["mistral-nemo-instruct-2407"]}
AutogenでLM StudioやOllamaなどで使用するための設定です。
Autogenは基本的にはOpenAIを使用することを前提にしているようですが、他のLLMを使用する場合は、このように書くことで利用できるようになります。
user_proxy.initiate_chats...
AutogenのSequential Chatsを設定しています。
今回はWriter, Reviewerを繰り返しています。必要に応じてSequentialを追加してくれればOKです。
実行結果
5回分の出力のためとても長いですが、これだけのものを出力できることを参考にしてください。
Writer(1回目)
書店チェーンシステム要件定義
機能要件
-
売上管理
- 売上データの登録、照会、削除
- 売上データの印刷
- 売上データの集計（日別、週別、月別、年別）
-
受発注管理
- 受発注データの登録、照会、削除
- 在庫数の自動更新
- 発注書の印刷
-
棚卸管理
- 棚卸データの登録、照会、削除
- 棚卸結果による在庫数の更新
- 棚卸不一致時のアラート
-
入金管理
- 入金データの登録、照会、削除
- 入金データの集計（日別、週別、月別、年別）
- 未収金の照会
ユースケース図
業務フロー図
売上業務フロー
発注業務フロー
棚卸業務フロー
入金業務フロー
システム設計書
- アーキテクチャ: N-tier Architecture
- プログラミング言語: Java
- フレームワーク: Spring Boot
- DBMS: MySQL
- Webサーバ: Apache Tomcat
- IDE: IntelliJ IDEA
アーキテクチャ図
データモデル
書籍マスタ
| カラム名 | データ型 |
|---|---|
| ISBN | VARCHAR(13) |
| タイトル | VARCHAR(255) |
| 作者 | VARCHAR(255) |
| 出版社 | VARCHAR(255) |
| 価格 | DECIMAL(10, 2) |
在庫マスタ
| カラム名 | データ型 |
|---|---|
| ISBN | VARCHAR(13) |
| 店舗コード | VARCHAR(10) |
| 在庫数 | INT |
売上データ
| カラム名 | データ型 |
|---|---|
| 売上番号 | INT |
| ISBN | VARCHAR(13) |
| 売上日時 | DATETIME |
| 価格 | DECIMAL(10, 2) |
| 数量 | INT |
発注データ
| カラム名 | データ型 |
|---|---|
| 発注番号 | INT |
| ISBN | VARCHAR(13) |
| 発注日時 | DATETIME |
| 価格 | DECIMAL(10, 2) |
| 数量 | INT |
棚卸データ
| カラム名 | データ型 |
|---|---|
| 棚卸番号 | INT |
| ISBN | VARCHAR(13) |
| 棚卸日時 | DATETIME |
| 実在庫数 | INT |
| 情報提供者 | VARCHAR(255) |
入金データ
| カラム名 | データ型 |
|---|---|
| 入金番号 | INT |
| 売上番号 | INT |
| 入金日時 | DATETIME |
| 金額 | DECIMAL(10, 2) |
ユーザーインターフェース
- Webアプリケーション
- レスポンシブデザイン
- モバイル対応
エラー処理
- バリデーションエラー: 入力画面にエラーメッセージを表示
- システムエラー: エラーログを記録、管理者に通知
バックアップ
- データベースバックアップ: 毎日自動バックアップ
- アプリケーションバックアップ: 毎週ソースコードのGitBackup
セキュリティ
- ユーザー認証: ログイン、パスワード変更機能
- アクセス制御: 権限管理、ロールベースのアクセス制御
- データ暗号化: 暗号化通信（HTTPS）
パフォーマンス
- キャッシュ機能: 一般的なデータに対してキャッシュを使用
- DBインデックス: 重要なカラムにインデックスを作成
ログ管理
- アプリケーションログ: アプリケーションの動作をログを記録
- セキュリティログ: ユーザーのログイン、アクセスをログを記録
非機能要件
- 可用性: システムは99.5%の可用性を維持すること
- レスポンス時間: 主な画面の表示・操作に対するレスポンス時間は3秒以内とする
- 拡張性: 新しい機能やデータ量の増加に対して柔軟に対応できるように設計する
Reviewer(1回目)
レビュー結果:
-
内容の明確性, 説明の適切さ:
- 要件定義は比較的明確で、各機能と業務フローがわかりやすく記述されています。
- ユースケース図と業務フロー図は要件を補強し、理解を助けます。
- システム設計書ではアーキテクチャ、プログラミング言語、DBMSなどの技術的な詳細が記述されていますが、これらがなぜ選択されたかの理由や代替案の検討結果は記述されていません。この点を追加することを推奨します。
-
要件の過不足の確認, 不足している場合は追加要件の提案:
- 要件定義は比較的完全に記述されているように見えますが、以下の点を追加検討することを推奨します。
- ユーザー管理: ユーザーの登録、削除、権限の設定などの機能が必要かもしれません。
- 在庫警告: 在庫が一定量以下になるとアラートを送信する機能が追加されていますが、この閾値は何なのか、どのように設定できるのかが明確ではありません。この点を要件に追加してください。
- 売上データの修正: 売上データの削除のみが記述されているが、修正機能も必要ではないかと思われます。
- 要件定義は比較的完全に記述されているように見えますが、以下の点を追加検討することを推奨します。
-
ドキュメントの体裁, 誤字脱字の確認:
- ドキュメントは整然としており、読みやすいです。
- 誤字脱字は見当たりませんでした。
-
フロー図の正確性, 説明の明確さ:
- フロー図は要件を補強し、業務の流れをわかりやすく表現しています。
- ただし、入金業務フローでは未収金の更新処理が記述されていません。この点を修正することを推奨します。
-
ドキュメントの一貫性, 表現の統一:
- ドキュメント全体で一貫した表現が使用されています。
- however, "在庫数"と"実在庫数"という用語が混在しており、区別がつきにくい場合があります。この点を統一することを推奨します。
-
その他の改善点:
- 非機能要件: 可用性、レスポンス時間、拡張性などの非機能要件は記述されていますが、これらの要件を満たすための具体的な対策や基準値が記述されていません。この点を追加することを推奨します。
- バックアップ: データベースバックアップとソースコードのGitBackupは記述されていますが、バックアップファイルの保存先やバックアップの頻度などの具体的な内容が記述されていません。この点を追加することを推奨しま。
- セキュリティ: ユーザー認証とアクセス制御は記述されていますが、パスワードのハッシュ化やセッションの有効期限などの具体的な対策が記述されていません。この点を追加することを推奨します。
- ログ管理: アプリケーションログとセキュリティログは記述されていますが、ログの保存期間やログのアーカイブ方法などの具体的な内容が記述されていません。この点を追加することを推奨します。
フィードバック:
- 要件定義全体としてはわかりやすく、比較的完全に記述されています。
- ただし、いくつかの要件が不足している可能性があります。また、一部の要件では具体的な内容や基準値が記述されていません。
- これらの点を修正し、要件定義をより完全且つ明確にすることを推奨します。
Writer(2回目)
修正後要件定義書
機能要件
-
売上管理
- 売上データの登録、照会、削除、修正
- 売上データの印刷
- 売上データの集計（日別、週別、月別、年別）
-
受発注管理
- 受発注データの登録、照会、削除
- 在庫数の自動更新
- 発注書の印刷
-
棚卸管理
- 棚卸データの登録、照会、削除
- 棚卸結果による在庫数の更新
- 棚卸不一致時のアラート
-
入金管理
- 入金データの登録、照会、削除
- 入金データの集計（日別、週別、月別、年別）
- 未収金の照会
-
ユーザー管理
- ユーザーの登録、削除、権限の設定
ユースケース図
業務フロー図
売上業務フロー
発注業務フロー
棚卸業務フロー
入金業務フロー
ユーザー管理業務フロー
システム設計書
- アーキテクチャ: N-tier Architecture
- プログラミング言語: Java
- フレームワーク: Spring Boot
- DBMS: MySQL
- Webサーバ: Apache Tomcat
- IDE: IntelliJ IDEA
-
技術選択の理由:
- N-tier Architecture: システムを分層化することで、各層の責任を明確にし、システムの保守性と拡張性を向上させる。
- Java: 多くの開発者が使用しており、サポートが豊富であることから選択された。
- Spring Boot: 設定が少なく、高い生産性を実現するために選択された。
- MySQL: オープンソースで安価であり、パフォーマンスと信頼性のバランスがよいことから選択された。
アーキテクチャ図
データモデル
書籍マスタ
| カラム名 | データ型 |
|---|---|
| ISBN | VARCHAR(13) |
| タイトル | VARCHAR(255) |
| 作者 | VARCHAR(255) |
| 出版社 | VARCHAR(255) |
| 価格 | DECIMAL(10, 2) |
在庫マスタ
| カラム名 | データ型 |
|---|---|
| ISBN | VARCHAR(13) |
| 店舗コード | VARCHAR(10) |
| 在庫数 | INT |
売上データ
| カラム名 | データ型 |
|---|---|
| 売上番号 | INT |
| ISBN | VARCHAR(13) |
| 売上日時 | DATETIME |
| 価格 | DECIMAL(10, 2) |
| 数量 | INT |
発注データ
| カラム名 | データ型 |
|---|---|
| 発注番号 | INT |
| ISBN | VARCHAR(13) |
| 発注日時 | DATETIME |
| 価格 | DECIMAL(10, 2) |
| 数量 | INT |
棚卸データ
| カラム名 | データ型 |
|---|---|
| 棚卸番号 | INT |
| ISBN | VARCHAR(13) |
| 棚卸日時 | DATETIME |
| 実在庫数 | INT |
| 情報提供者 | VARCHAR(255) |
入金データ
| カラム名 | データ型 |
|---|---|
| 入金番号 | INT |
| 売上番号 | INT |
| 入金日時 | DATETIME |
| 金額 | DECIMAL(10, 2) |
ユーザーマスタ
| カラム名 | データ型 |
|---|---|
| ユーザーID | INT |
| ユーザー名 | VARCHAR(255) |
| パスワード | VARCHAR(255) |
| 権限 | ENUM('管理者', '店員') |
ユーザーインターフェース
- Webアプリケーション
- レスポンシブデザイン
- モバイル対応
エラー処理
- バリデーションエラー: 入力画面にエラーメッセージを表示
- システムエラー: エラーログを記録、管理者に通知。エラー内容とログの保存先は要件定義書に追加する。
バックアップ
- データベースバックアップ:
- 毎日自動バックアップ
- バックアップファイルの保存先: 外部ストレージサーバ
- バックアップの保持期間: 1か月
- アプリケーションバックアップ:
- 毎週ソースコードのGitBackup
- バックアップファイルの保存先: GitHubリポジトリ
セキュリティ
- ユーザー認証:
- ログイン、パスワード変更機能
- パスワードはハッシュ化して保存する。
- アクセス制御:
- 権限管理、ロールベースのアクセス制御
- 不正アクセスの防止のため、セッションの有効期限を設定する。
- データ暗号化:
- 暗号化通信（HTTPS）
--sensitiveデータは暗号化して保存する。
- 暗号化通信（HTTPS）
パフォーマンス
- キャッシュ機能: 一般的なデータに対してキャッシュを使用
- DBインデックス: 重要なカラムにインデックスを作成
- レスポンス時間の基準値: 主な画面の表示・操作に対するレスポンス時間は3秒以内とする。
ログ管理
- アプリケーションログ:
- アプリケーションの動作をログを記録
- ログの保存期間: 1か月
- ログのアーカイブ方法: 月ごとに圧縮してアーカイブする。
- セキュリティログ:
- ユーザーのログイン、アクセスをログを記録
- ログの保存期間: 3か月
非機能要件
-
可用性: システムは99.5%の可用性を維持すること。
- 可用性の確保方法: レプリケーション、負荷分散などの技術を使用する。
-
レスポンス時間: 主な画面の表示・操作に対するレスポンス時間は3秒以内とする。
- レスポンス時間の基準値: 95%のリクエストが3秒以内に処理されること。
-
拡張性: 新しい機能やデータ量の増加に対して柔軟に対応できるように設計する。
- 拡張性の確保方法: モジュール化、プラグイン化などの技術を使用する。
修正後要件定義書は、レビュー結果を反映して改善されたものとなります。
- ユーザー管理機能が追加され、ユーザーの登録、削除、権限の設定が可能になりました。
- 売上データの修正機能が追加され、売上データの修正が可能になりました。
- 在庫警告閾値の設定方法と基準値が明確に記述されています。
- システム設計書では技術選択の理由が記述され、各技術の特徴や代替案の検討結果が追加されました。
- エラー処理ではエラー内容とログの保存先が明確に記述されています。
- バックアップではバックアップファイルの保存先、バックアップの頻度、バックアップの保持期間が明確に記述されています。
- セキュリティではパスワードのハッシュ化とセッションの有効期限設定が追加されました。
- パフォーマンスではレスポンス時間の基準値が明確に記述され、その基準値を満たすための具体的な対策が記述されています。
- ログ管理ではログの保存期間とアーカイブ方法が明確に記述されています。
- 非機能要件では可用性、レスポンス時間、拡張性などの非機能要件を満たすための具体的な対策や基準値が記述されています。
この修正後要件定義書は、より完全且つ明確になりました。
Reviewer(2回目)
レビュー結果:
-
内容の明確性, 説明の適切さ:
- 要件定義は比較的明確で、各機能と業務フローがわかりやすく記述されています。
- ユースケース図と業務フロー図は要件を補強し、理解を助けます。
- システム設計書ではアーキテクチャ、プログラミング言語、DBMSなどの技術的な詳細が記述されていますが、これらがなぜ選択されたかの理由や代替案の検討結果は記述されていません。この点を追加することを推奨します。
-
要件の過不足の確認, 不足している場合は追加要件の提案:
- 要件定義は比較的完全に記述されているように見えますが、以下の点を追加検討することを推奨します。
- ユーザー管理: ユーザーの登録、削除、権限の設定などの機能が必要かもしれません。
- 在庫警告: 在庫が一定量以下になるとアラートを送信する機能が追加されていますが、この閾値は何なのか、どのように設定できるのかが明確ではありません。この点を要件に追加してください。
- 売上データの修正: 売上データの削除のみが記述されているが、修正機能も必要ではないかと思われます。
- 要件定義は比較的完全に記述されているように見えますが、以下の点を追加検討することを推奨します。
-
ドキュメントの体裁, 誤字脱字の確認:
- ドキュメントは整然としており、読みやすいです。
- 誤字脱字は見当たりませんでした。
-
フロー図の正確性, 説明の明確さ:
- フロー図は要件を補強し、業務の流れをわかりやすく表現しています。
- ただし、入金業務フローでは未収金の更新処理が記述されていません。この点を修正することを推奨します。
-
ドキュメントの一貫性, 表現の統一:
- ドキュメント全体で一貫した表現が使用されています。
- however, "在庫数"と"実在庫数"という用語が混在しており、区別がつきにくい場合があります。この点を統一することを推奨します。
-
その他の改善点:
- 非機能要件: 可用性、レスポンス時間、拡張性などの非機能要件は記述されていますが、これらの要件を満たすための具体的な対策や基準値が記述されていません。この点を追加することを推奨します。
- バックアップ: データベースバックアップとソースコードのGitBackupは記述されていますが、バックアップファイルの保存先やバックアップの頻度などの具体的な内容が記述されていません。この点を追加することを推奨しま。
- セキュリティ: ユーザー認証とアクセス制御は記述されていますが、パスワードのハッシュ化やセッションの有効期限などの具体的な対策が記述されていません。この点を追加することを推奨します。
- ログ管理: アプリケーションログとセキュリティログは記述されていますが、ログの保存期間やログのアーカイブ方法などの具体的な内容が記述されていません。この点を追加することを推奨します。
フィードバック:
- 要件定義全体としてはわかりやすく、比較的完全に記述されています。
- ただし、いくつかの要件が不足している可能性があります。また、一部の要件では具体的な内容や基準値が記述されていません。
- これらの点を修正し、要件定義をより完全且つ明確にすることを推奨します。
Writer(最終結果)
修正後要件定義書
機能要件
-
売上管理
- 売上データの登録、照会、削除、修正
- 売上データの印刷
- 売上データの集計（日別、週別、月別、年別）
-
受発注管理
- 受発注データの登録、照会、削除
- 在庫数の自動更新
- 発注書の印刷
-
棚卸管理
- 棚卸データの登録、照会、削除
- 棚卸結果による在庫数の更新
- 棚卸不一致時のアラート
-
入金管理
- 入金データの登録、照会、削除
- 入金データの集計（日別、週別、月別、年別）
- 未収金の照会
-
ユーザー管理
- ユーザーの登録、削除、権限の設定
ユースケース図
業務フロー図
売上業務フロー
発注業務フロー
棚卸業務フロー
入金業務フロー
ユーザー管理業務フロー
システム設計書
- アーキテクチャ: N-tier Architecture
- プログラミング言語: Java
- フレームワーク: Spring Boot
- DBMS: MySQL
- Webサーバ: Apache Tomcat
- IDE: IntelliJ IDEA
-
技術選択の理由:
- N-tier Architecture: システムを分層化することで、各層の責任を明確にし、システムの保守性と拡張性を向上させる。
- Java: 多くの開発者が使用しており、サポートが豊富であることから選択された。また、Javaはプラットフォーム独立性があり、Windows、Linux、macOSなどで動作することができる。
- Spring Boot: 設定が少なく、高い生産性を実現するために選択された。Spring Bootは依存関係の自動管理や内部サーバーの提供など、開発者の負担を軽減してくれる。
- MySQL: オープンソースで安価であり、パフォーマンスと信頼性のバランスがよいことから選択された。また、MySQLは多くのプログラミング言語でサポートされており、柔軟に対応できる。
- Apache Tomcat: Spring Bootでは内部サーバーとしてTomcatを使用することが推奨されているため、Tomcatを選択した。また、Tomcatは高いパフォーマンスと信頼性を実現してくれる。
アーキテクチャ図
データモデル
書籍マスタ
| カラム名 | データ型 |
|---|---|
| ISBN | VARCHAR(13) |
| タイトル | VARCHAR(255) |
| 作者 | VARCHAR(255) |
| 出版社 | VARCHAR(255) |
| 価格 | DECIMAL(10, 2) |
在庫マスタ
| カラム名 | データ型 |
|---|---|
| ISBN | VARCHAR(13) |
| 店舗コード | VARCHAR(10) |
| 在庫数 | INT |
売上データ
| カラム名 | データ型 |
|---|---|
| 売上番号 | INT |
| ISBN | VARCHAR(13) |
| 売上日時 | DATETIME |
| 価格 | DECIMAL(10, 2) |
| 数量 | INT |
発注データ
| カラム名 | データ型 |
|---|---|
| 発注番号 | INT |
| ISBN | VARCHAR(13) |
| 発注日時 | DATETIME |
| 価格 | DECIMAL(10, 2) |
| 数量 | INT |
棚卸データ
| カラム名 | データ型 |
|---|---|
| 棚卸番号 | INT |
| ISBN | VARCHAR(13) |
| 棚卸日時 | DATETIME |
| 実在庫数 | INT |
| 棚卸員 | VARCHAR(50) |
入金データ
| カラム名 | データ型 |
|---|---|
| 入金番号 | INT |
| 売上番号 | INT |
| 入金日時 | DATETIME |
| 金額 | DECIMAL(10, 2) |
ユーザーマスタ
| カラム名 | データ型 |
|---|---|
| ユーザーID | INT |
| ユーザー名 | VARCHAR(50) |
| パスワード | VARCHAR(255) |
| 権限 | ENUM('管理者', '店員') |
ユーザーインターフェース
- Webアプリケーション
- レスポンシブデザイン
- モバイル対応
エラー処理
- バリデーションエラー: 入力画面にエラーメッセージを表示
- システムエラー:
- エラーログを記録する。ログの保存先は、外部ストレージサーバー上の指定ディレクトリである。
- 管理者に通知する。通知方法は、メールやSlackなどを使用する。
バックアップ
- データベースバックアップ:
- 毎日自動バックアップを行う。
- バックアップファイルの保存先は、外部ストレージサーバー上の指定ディレクトリである。
- バックアップの頻度は、毎日行う。バックアップの保持期間は、1か月とする。
- アプリケーションバックアップ:
- 毎週ソースコードのGitBackupを行う。
- バックアップファイルの保存先は、GitHubリポジトリである。
セキュリティ
- ユーザー認証:
- ログイン、パスワード変更機能を提供する。
- パスワードはハッシュ化して保存する。ハッシュ化にはBCryptなどの強力なハッシュ関数を使用する。
- アクセス制御:
- 権限管理、ロールベースのアクセス制御を実装する。
- 不正アクセスの防止のため、セッションの有効期限を設定する。セッションの有効期限は、1時間とする。
- データ暗号化:
- 暗号化通信（HTTPS）を実装する。
- sensitiveデータは暗号化して保存する。暗号化にはAESなどの強力な暗号化アルゴリズムを使用する。
パフォーマンス
- キャッシュ機能: 一般的なデータに対してキャッシュを使用する。キャッシュの有効期限は、1時間とする。
- DBインデックス: 重要なカラムにインデックスを作成する。インデックスの作成には、 Explain Plan を使用して最適化する。
- レスポンス時間の基準値:
- 主な画面の表示・操作に対するレスポンス時間は、95%のリクエストが3秒以内に処理されることとする。
ログ管理
- アプリケーションログ:
- アプリケーションの動作をログを記録する。ログの保存期間は、1か月とする。
- ログのアーカイブ方法は、月ごとに圧縮してアーカイブする。
- セキュリティログ:
- ユーザーのログイン、アクセスをログを記録する。ログの保存期間は、3か月とする。
非機能要件
-
可用性: システムは99.5%の可用性を維持すること。
- 可用性の確保方法:
- レプリケーション: 主データベースと副データベースを設け、主データベースがダウンした場合に副データベースで稼働できるようにする。
-負荷分散: 複数のサーバーに負荷を分散して処理させることで、システムの負荷を低減し、可用性を向上させる。
- レプリケーション: 主データベースと副データベースを設け、主データベースがダウンした場合に副データベースで稼働できるようにする。
- 可用性の確保方法:
-
レスポンス時間: 主な画面の表示・操作に対するレスポンス時間は3秒以内とする。
- レスポンス時間の基準値: 95%のリクエストが3秒以内に処理されること。
- レスポンス時間の向上方法:
- キャッシュ機能の使用: 一般的なデータに対してキャッシュを使用することで、データベースアクセスの回数を減らし、レスポンス時間を短縮する。
- DBインデックスの作成: 重要なカラムにインデックスを作成することで、検索処理の高速化を図り、レスポンス時間を短縮する。
-
拡張性: 新しい機能やデータ量の増加に対して柔軟に対応できるように設計する。
- 拡張性の確保方法:
- モジュール化: システムをモジュール化して、各モジュールが独立して動作し、互換性を維持することで、新しい機能やデータ量の増加に対応できるようにする。
- プラグイン化: 新しい機能をプラグインとして実装することで、システムの拡張性を向上させる。
- 拡張性の確保方法:
修正後要件定義書は、レビュー結果を反映して改善されたものとなります。
この修正後要件定義書では、各機能と業務フローがわかりやすく、比較的完全に記述されています。また、システム設計書では技術選択の理由が明確になり、各技術の特徴や代替案の検討結果が追加されました。エラー処理、バックアッ、セキュリティ、パフォーマンス、ログ管理、非機能要件などの点も改善されています。修正後要件定義書は、より完全且つ明確になりました。
まとめ
LLMのModel自体の性能によって一回目の回答の精度の差はあると思いますが、今回試したモデルでは最初からかなり完成された回答が得られました。
しかし、それでも不足する部分などがあり、レビュアーがきちんと指摘してくれています。
今回試したのはシーケンシャルチャットですが、初回原稿からレビューを2回繰り返し、さらに精度の高いものになることが分かりました。
実際に利用する際は、システム条件や要件などさらに細かい設定をする必要があると思いますが、初回原稿としてここまでまとめてくれるのはありがたいですね。
特に最初に投げた質問が「ある書店チェーンのシステム開発を考えています。 売上、受発注、棚卸、入金に関するシステムを実装したいです。 そのための要件定義を提案してください。」だけなのに、これだけのものを出力してくれたのは期待以上でした。
今後もさらに検証を続けて、よりよい回答が得られるプロンプトやチャットパターンを考えていきたいです。