【生成AI活用検討】Bedrockで設計書のレビューをしてもらう

はじめに

お疲れ様です。yuki_inkです。
生成AI、使ってますか？

最近、生成AIを使ったらこういうことができるよ！という夢のあるお話はよく耳にするようになりました。
が、じゃあそれどうやってやんの？というところの理解が、私はまだまだ追いついていません。

あんなこといいな、できたらいいな！やり方は知らんけど！助けてド●えもん〜！
そんな状況です。
それは良くない。
ということで、生成AIを使って何ができそうか、どうやったらできそうか、それに伴う課題は何かといったことを、自分の手を動かしながら学びたいと思い、色々試していこうと思います。

設計書のレビューやってくれないかな

社内に設計書の品質評価チェックリストがあります（あったとします）。
先人が「この内容は設計書に書いておけ」というものをまとめてくれた血と汗と涙の結晶です。
自分が設計書を新規作成した時に、その品質評価チェックリストと照らし合わせて「この内容書けてないですよ」みたいに指摘してくれると嬉しい！！

前準備

チェックリストと設計書のサンプルが必要です。

まずはチェックリストを作ります。
ChatGPTに書いてもらいました。

システム設計書をレビューする際の確認観点を以下のようにまとめます：

1.要件の適合性：

• 設計が要求された機能や性能に適合しているかどうかを確認する。
• ユーザーのニーズやビジネス目標を満たしているかを検証する。

2.セキュリティ：

• システムが適切なセキュリティ対策を備えているかどうかを評価する。
• データ保護、アクセス制御、脆弱性対策などの観点からセキュリティが確保されているかを確認する。

3.拡張性と柔軟性：

• システムが将来の拡張や変更に対応できる設計になっているかを確認する。
• 新しい機能の追加や技術の変化に対応できる柔軟性があるかを検証する。

4.パフォーマンス：

• システムが要求されたパフォーマンス目標を達成できるかどうかを評価する。
• 負荷テストや性能測定などを通じて、性能の問題やボトルネックを特定する。

5.ユーザビリティ：

• システムが使いやすく、直感的であるかどうかを評価する。
• ユーザビリティテストやユーザフィードバックを通じて、ユーザーの体験を向上させるための改善点を特定する。

6.耐障害性：

• システムが障害や災害に対して耐性を持っているかどうかを検証する。
• バックアップ、災害復旧、障害回復などの対策が適切に実装されているかを確認する。

7.ドキュメンテーション：

• 設計書が十分な詳細を提供しており、システムの理解やメンテナンスを容易にするかどうかを確認する。
• 適切な図表、説明、および関連する文書が含まれているかを検証する。

8.コード品質：

• システムの実装に関連するコード品質が高いかどうかを評価する。
• コードレビューや静的解析などを通じて、エラーやバグ、セキュリティ上の問題を特定する。

9.規制要件の遵守：

• システムが適用される法規制や業界の規制要件を遵守しているかどうかを確認する。
• 法的コンプライアンスやデータプライバシー規制などの要件が満たされているかを検証する。

10.費用とスケジュール：

• システムの設計が予算内であり、計画されたスケジュール内に収まるかどうかを確認する。
• 適切なリソースの割り当てとプロジェクトの進行状況を検証する。

確認すべき観点はもうちょっと色々ある気がしますが、今回は検証用のサンプルということでそのまま採用します。

続いて設計書ですが、こちらもChatGPTに書いてもらいました。

[セキュリティ強化システム設計書]

1.概要
このセキュリティ強化システムは、金融業界の企業向けに設計されています。このシステムは、顧客データや機密情報を保護し、不正アクセスやデータ漏洩から企業を守ることを目的としています。

2.システム構成

• アプリケーション層:

  • 顧客ポータル
  • 取引処理システム
  • アカウント管理システム

• データベース層:

  • 顧客情報データベース
  • 取引ログデータベース
  • 認証およびアクセス制御データベース

• セキュリティ層:

  • ファイアウォール
  • インターネットセキュリティゲートウェイ
  • インターネットバンキングセキュリティソフトウェア
  • アクセス制御システム

3.セキュリティ機能

• アクセス制御:

  • ユーザー認証：ユーザー名とパスワードによる認証、および多要素認証の導入。
  • アクセス制限：役割ベースのアクセス制御により、権限のないユーザーがシステムにアクセスできないようにする。

• データ保護:

  • 暗号化：データの転送と保存に暗号化を使用し、データ漏洩を防止する。
  • データマスキング：機密性の高いデータを表示する前にマスキングすることで、機密情報の保護を強化する。

• 監視と検知:

  • 不正アクティビティの監視：異常なアクセスや操作を検知し、即座に対処するための監視システムを導入。
  • セキュリティイベントログの記録：すべてのセキュリティ関連のイベントをログに記録し、監査と調査のための証拠を提供する。

4.セキュリティポリシー

• パスワードポリシー：強力なパスワードの使用を要求し、定期的なパスワード変更を奨励する。
• データアクセスポリシー：最小限の必要性に基づいてデータへのアクセスを制限し、機密情報に対するアクセスを厳格に制御する。

5.災害復旧およびバックアップ

• バックアップ戦略：定期的なデータバックアップを実施し、災害時のデータ復旧を可能にする。
• 災害復旧プラン：災害時の事業継続を確保するための復旧プランを策定し、適切なテストと更新を定期的に実施する。

以上が、金融業界の企業向けセキュリティ強化システムの設計書のサンプルです。

DRについてちゃんと触れているところは個人的にポイント高いですね。
こちらもそのまま採用します。

検証

では上記のチェックリストと設計書の内容を生成AIに渡して、設計書レビューをしてもらいましょう。

・環境：Bedrockのテキストプレイグラウンド
・利用したモデル：Claude 3 Sonnet

プロンプトは以下の通り。

Human:
あなたはシステム開発の責任者です。
新規開発するシステムの設計書をレビューする役割があります。
<checkpoint></checkpoint>に記載されているレビューの各観点について、<document></document>に記載されている設計書の内容をレビューし、結果を記述してください。
結果は各観点ごとに記述するものとし、最後に総評を記述してください。

<checkpoint>
システム設計書をレビューする際の確認観点を以下のようにまとめます：

1. **要件の適合性**：
   - 設計が要求された機能や性能に適合しているかどうかを確認する。
   - ユーザーのニーズやビジネス目標を満たしているかを検証する。

2. **セキュリティ**：
   - システムが適切なセキュリティ対策を備えているかどうかを評価する。
   - データ保護、アクセス制御、脆弱性対策などの観点からセキュリティが確保されているかを確認する。

3. **拡張性と柔軟性**：
   - システムが将来の拡張や変更に対応できる設計になっているかを確認する。
   - 新しい機能の追加や技術の変化に対応できる柔軟性があるかを検証する。

4. **パフォーマンス**：
   - システムが要求されたパフォーマンス目標を達成できるかどうかを評価する。
   - 負荷テストや性能測定などを通じて、性能の問題やボトルネックを特定する。

5. **ユーザビリティ**：
   - システムが使いやすく、直感的であるかどうかを評価する。
   - ユーザビリティテストやユーザフィードバックを通じて、ユーザーの体験を向上させるための改善点を特定する。

6. **耐障害性**：
   - システムが障害や災害に対して耐性を持っているかどうかを検証する。
   - バックアップ、災害復旧、障害回復などの対策が適切に実装されているかを確認する。

7. **ドキュメンテーション**：
   - 設計書が十分な詳細を提供しており、システムの理解やメンテナンスを容易にするかどうかを確認する。
   - 適切な図表、説明、および関連する文書が含まれているかを検証する。

8. **コード品質**：
   - システムの実装に関連するコード品質が高いかどうかを評価する。
   - コードレビューや静的解析などを通じて、エラーやバグ、セキュリティ上の問題を特定する。

9. **規制要件の遵守**：
   - システムが適用される法規制や業界の規制要件を遵守しているかどうかを確認する。
   - 法的コンプライアンスやデータプライバシー規制などの要件が満たされているかを検証する。

10. **費用とスケジュール**：
    - システムの設計が予算内であり、計画されたスケジュール内に収まるかどうかを確認する。
    - 適切なリソースの割り当てとプロジェクトの進行状況を検証する。
</checkpoint>


<document>
[セキュリティ強化システム設計書]

1. **概要**
   このセキュリティ強化システムは、金融業界の企業向けに設計されています。このシステムは、顧客データや機密情報を保護し、不正アクセスやデータ漏洩から企業を守ることを目的としています。

2. **システム構成**
   - **アプリケーション層**:
     - 顧客ポータル
     - 取引処理システム
     - アカウント管理システム

   - **データベース層**:
     - 顧客情報データベース
     - 取引ログデータベース
     - 認証およびアクセス制御データベース

   - **セキュリティ層**:
     - ファイアウォール
     - インターネットセキュリティゲートウェイ
     - インターネットバンキングセキュリティソフトウェア
     - アクセス制御システム

3. **セキュリティ機能**
   - **アクセス制御**:
     - ユーザー認証：ユーザー名とパスワードによる認証、および多要素認証の導入。
     - アクセス制限：役割ベースのアクセス制御により、権限のないユーザーがシステムにアクセスできないようにする。

   - **データ保護**:
     - 暗号化：データの転送と保存に暗号化を使用し、データ漏洩を防止する。
     - データマスキング：機密性の高いデータを表示する前にマスキングすることで、機密情報の保護を強化する。

   - **監視と検知**:
     - 不正アクティビティの監視：異常なアクセスや操作を検知し、即座に対処するための監視システムを導入。
     - セキュリティイベントログの記録：すべてのセキュリティ関連のイベントをログに記録し、監査と調査のための証拠を提供する。

4. **セキュリティポリシー**
   - パスワードポリシー：強力なパスワードの使用を要求し、定期的なパスワード変更を奨励する。
   - データアクセスポリシー：最小限の必要性に基づいてデータへのアクセスを制限し、機密情報に対するアクセスを厳格に制御する。

5. **災害復旧およびバックアップ**
   - バックアップ戦略：定期的なデータバックアップを実施し、災害時のデータ復旧を可能にする。
   - 災害復旧プラン：災害時の事業継続を確保するための復旧プランを策定し、適切なテストと更新を定期的に実施する。

以上
</document>

Assistant:

結果

Assistant:の後に、生成された文章が表示されます。

以下、結果をそのまま添付します。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

1.要件の適合性:

この設計書では、金融業界の企業向けにセキュリティを強化することを目的として、顧客データや機密情報を不正アクセスやデータ漏洩から保護する機能が含まれています。ユーザーのニーズとビジネス目標を満たすために、アクセス制御、データ保護、監視と検知の機能が盛り込まれています。したがって、要件に適合した設計となっていると評価できます。

2.セキュリティ:

設計書には、ファイアウォール、インターネットセキュリティゲートウェイ、インターネットバンキングセキュリティソフトウェア、アクセス制御システムなどの適切なセキュリティ対策が含まれています。また、ユーザー認証、アクセス制限、暗号化、データマスキング、監視と検知などの機能によってセキュリティが強化されています。したがって、十分なセキュリティ対策が講じられていると判断できます。

3.拡張性と柔軟性:

設計書には、将来の拡張性や変更への対応について具体的な言及がありません。ただし、セキュリティ層がモジュール化されていることから、将来の拡張やセキュリティテクノロジーの変更に対応できる可能性があります。柔軟性の観点では、もう少し詳細な記述が必要かもしれません。

4.パフォーマンス:

設計書にはパフォーマンスに関する具体的な目標や要求事項が記載されていません。金融業界のシステムとしては、高いパフォーマンスが求められると想定されますが、この点について検証が必要です。

5.ユーザビリティ:

設計書には、ユーザーインターフェースやユーザー体験に関する記載がありません。ただし、顧客ポータルがアプリケーション層に含まれていることから、ユーザビリティについても検討されていると推測できます。具体的なユーザビリティ対策については、さらなる詳細が必要です。

6.耐障害性:

設計書には、バックアップ戦略と災害復旧プランが含まれています。これらの対策により、システムの耐障害性が確保されていると評価できます。

7.ドキュメンテーション:

設計書は概要、システム構成、セキュリティ機能、セキュリティポリシー、災害復旧およびバックアップなどの項目が含まれており、システムの理解を容易にするための適切な構成となっています。ただし、詳細な説明や図表がもう少し充実していると良いでしょう。

8.コード品質:

設計書にはコード品質に関する言及がありません。コードレビューや静的解析の実施など、コード品質を確保するための具体的な対策が必要です。

9.規制要件の遵守:

設計書には、金融業界の規制要件への言及がありません。データプライバシーや法的コンプライアンスなどの規制要件を満たしているかについて、確認が必要です。

10.費用とスケジュール:

設計書には、プロジェクトの費用やスケジュールに関する情報がありません。予算内で計画されたスケジュール内に収まるかを評価するためには、この情報が必要不可欠です。

総評:

この設計書は、金融業界のセキュリティ強化システムとしては適切な内容となっています。ただし、将来の拡張性や変更への対応、パフォーマンス、ユーザビリティ、コード品質、規制要件の遵守、費用とスケジュールなどの点で、さらなる詳細な検討が必要です。全体としては、セキュリティ機能が中心となっており、その他の観点が不足している傾向にあります。設計書をより完全なものにするためには、これらの点を補強することが望ましいでしょう。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

設計書に全く言及のない内容については、ちゃんと指摘をしてくれました！
また、改善点もかなり高い精度で指摘してくれています。
生成AIでの設計書レビューを一通りクリアして、その後に上司に最終確認をお願いすれば、上司側のレビュー負荷が軽くなるかもしれません。

今後の展望と課題

実際の業務で使おうと思えば、まだまだプロンプトに改善は必要かと思いますが、検証としては非常にいい結果が出たと思います。
レビュー観点はプロンプトにベタ貼りするのではなく、RAGを使ってもいいかなと思いました。

課題としてまず頭に浮かぶのは、 設計書って大体WordファイルかExcelファイルなんだよなあ... ということです。
たとえそれをPDFで固めたとしても、です。
その設計書ファイル本体をアップロードして、その内容を読み込んでレビューする、という一連の流れを実装するのは難しそうだなと思いました。

• 「設計書ファイル本体をアップロード」
  当然、フロントエンドを含めたアプリ開発が必要。
  S3に置くとして、S3バケットそのものの設計や、どんなルートでS3にアクセスしに行くか、アクセス制御をどうするかといった検討も必要。

• 「その内容を読み込んでレビュー」
  OCRの外部サービス使う？
  あるいはここもRAGで頑張る？ チェック項目用のインデックスと別でインデックス作ったり、データ削除のタイミングどうするかとかも難しそう。

ただ、難しいとはいえ、やろうと思えばできるやつ、、！

あとはコストの問題でしょうか。
設計書なんて、内容てんこ盛りで、長文が当たり前です。
また、チェックリストもきっと（絶対）長いでしょう。
それを全部生成AIに渡すとなると、プロンプトが膨れてしまい、その分コストが高くつきます。
そもそもレビュー観点と設計書の全文をプロンプトに含めることができるのか、という話もありますが、そこも含めて仕組み全体の検討が必要です。

終わりに

思いつきで検証を進めてみましたが、思った以上に勉強になりました。
あんなこといいな、できたらいいなを、ド●えもんに頼らずとも実現するために、今後も色々なテーマで検証を重ねていきたいと思います。
最後までお目通しいただき、ありがとうございました。