AIによる設計書レビューの仕組みを作る

設計書レビューでは、記載漏れや仕様の矛盾、考慮不足などを確認します。しかし、限られた時間で多くの資料を読むと、ケアレスミスや確認観点の漏れを完全に防ぐことは難しく、レビュー品質も担当者の経験や得意分野に左右されます。

見慣れない技術を使う案件や、途中から参加した案件では、前提知識を短期間で補いながら資料を読み込む必要があります。そこで現在、AIを使ってレビューを補助し、案件が変わっても共通利用できる仕組みを作成しています。まだ実案件で本格利用したものではなく、検証中の取り組みです。

案件ごとの準備を減らす共通基盤

【エンジニア募集中】フルリモート可◎、売上/従業員数9年連続UP、平均残業8時間、有給取得率90％、年休124日以上 etc.　　詳細はこちらから＞

AIに設計書を確認させるだけであれば、案件ごとに長いプロンプトを書くことでも対応できます。ただし、確認観点、判定基準、出力形式、禁止事項を毎回作り直すのは負担が大きいです。

そのため、複数案件で利用できるレビュー手順、ルール、エージェントの役割、成果物の形式を共通部分として分離しました。案件固有の業務ルールやシステム構成だけを設定として追加し、共通部分を再利用する考え方です。

あわせて、案件フォルダを作成するツールや、エージェントが出力した成果物のID、件数、関連付け、正本とサマリーの整合性などを検査するツールも用意しています。

複数の役割で確認観点を増やす

一つの視点だけでは指摘が偏る可能性があるため、現在は複数の役割を持つエージェントを通してレビューする構成にしています。

・開発リーダー、ベテランエンジニアの視点：実現性、保守性、技術的な整合性を確認

・プロジェクトマネージャーの視点：影響範囲、リスク、進行上の懸念を確認

・顧客側のシステム担当者の視点：業務との整合性や説明の分かりやすさを確認

これらは実際の担当者をAIで置き換えるものではなく、立場ごとに異なる確認観点を明確にするための設定です。AIは理想的な構成や一般的な設計パターンも提示するため、コストや納期を理由に省略した内容について、本当に省略してよいのかを見直すきっかけにもなります。ただし、どこまで採用するかは案件の制約を踏まえて人が判断します。

レビュー結果は、問題と判断できるIssue、仕様確認が必要なQuestion、任意の改善提案であるSuggestionに分けます。資料にない仕様を推測で確定しないことも強いルールとして定め、AIの誤った補完を抑制しています。

入力資料を変更せず、結果を分離する

構成上の重要なルールとして、AIに渡した入力資料は更新、削除、移動を禁止しています。AIの出力をそのまま正式な仕様にせず、原本と生成結果を明確に分け、必ず人が確認できる状態を保つためです。

入力は01_inputへ保管し、レビュー結果や要確認事項、トレーサビリティの確認結果は03_outputへ出力します。構成を単純に分けることで、どこまでが原本で、どこからがAIによる確認結果なのかを追いやすくしています。

現在地と最終的に目指す形

現在は、基本設計書、詳細設計書、ソースコードなどを対象としたレビュー部分について、共通ルール、役割、出力形式、検査ツールを一通り整えた段階です。実案件での本格利用はまだ行っておらず、適用できる案件があれば、指摘精度や運用負荷を検証したいと考えています。

最終的な目標は、要件定義書や参考資料から基本設計書を生成し、人が確認・修正した後にレビューエージェントを実行します。さらに、確認済みの基本設計書から詳細設計書を生成し、同様に人の確認とAIレビューを繰り返しながら、実装、単体テスト、結合テストまでつなげることがゴールです。

AIによって人のレビューをなくすのではなく、人が重要な判断に集中できるよう、確認観点を補う仕組みとして改善を続けていきます。

【エンジニア募集中】フルリモートも◎(リモート率85.7％)、平均残業8時間、年休124日以上、有給取得率90％ etc.　詳細はこちらから＞