【要約】AIに設計を任せるときに気をつけたい。「正しく動く」と「増えても耐えられる」は別だった [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者が生成AIを用いてPush通知機能の設計を進めた際、対象人数が増えるほどDB負荷が線形に増大する構造に直面した。個別の処理は正しく動作するものの、大規模トラフィック時にシステムが破綻するリスクがある。具体的には以下の問題が挙げられる。
- ・1人あたりの処理につき、最大約11回のDB問い合わせが発生する設計。
- ・対象者が1,000人の場合、合計11,000回のDB通信が必要となる。
- ・DB通信や検索、接続待ちの増大により、他のAPI処理まで遅延する恐れがある。
// Approach
開発者は、対象者ごとに個別のDBアクセスを繰り返すのではなく、データを一括で扱う設計への変更を検討した。通信回数を抑え、スケーラビリティを確保するために以下の手法を採用する。
- ・必要な情報をDBから一括（Bulk）で取得する。
- ・取得したデータに基づき、対象者ごとにPush通知を実行する。
- ・処理結果をまとめてDBへ保存する。
- ・対象人数が増えても、問い合わせ回数が比例して増えない構造を目指す。
// Result
設計段階で問題に気づいたことで、本番稼働後のパフォーマンス障害を未然に防ぐことができた。AIを活用する開発における、新たな品質管理の視点が示されている。
- ・「正しく動く」ことと「増えても耐えられる」ことを分離して評価した。
- ・AIには実装だけでなく、性能面のみを監査させるレビュー手法を提示した。
- ・「対象が100倍になったらどうなるか」という検証の重要性を再定義した。
Senior Engineer Insight
> AIによる開発は実装速度を劇的に向上させるが、非機能要件の検証を疎かにする危険を孕んでいる。特にループ内でのDBアクセスは、AIが最も見落としやすい典型的な罠である。実戦においては、AIの生成物を「機能の正しさ」だけで判断してはならない。「負荷が100倍になった場合」という極端なシナリオをレビューの標準プロセスに組み込むべきだ。AIを「実装者」としてだけでなく、「性能監査役」として使い分ける高度なプロンプトエンジニアリングが、これからの設計者には求められる。