AI時代でも性能試験はつらかった

1. AI時代でも 性能試験はつらかった Aug 5, 2026 X:@negimaboy_1293 @Re+ LT会 #6 Negima
2. 皆さんが管理しているDB 3年後に何件積まれていますか︖
3. そのDBには3年後どのように データが積まれていますか︖
4. $ whoami Negima(根本 銀河) 2023卒 • NTTデータフィナンシャルテクノロジー 決済イノベーション事業部 • クレジットカード会社向けサービスのSRE・性能改善・AI導⼊⽀援など • Javaとソフトウェアアーキテクチャの話が好き • JJUGとか地域の技術コミュニティでちょこちょこ登壇している
5. 現在の案件の性能試験事情 現在の案件の特徴 • 2025年にリリースされたクレジットカード会社向けの業務代⾏サービス • 決済中継のようなリアルタイム処理ではなくバッチ処理がメインのシステム、 ユーザが触るWebもあるにはある • DBはMySQLを使⽤し、テーブル数は300弱 • 開発チームは⼯数的に単性能試験を実施する余裕がなく、 性能担保はSRE(⾃チーム)に依存する
6. 現在の案件の性能試験事情
7. どこが⼀番ネックか 試験計画 試験データ 積み込み 試験実施 結果解析 資材改修 積み込み件数が多い 設計難易度が⾼い • 数千万~数⼗億件ほどの データのため取り扱いづらい • 他テーブルとの整合性担保が必要 • 積み込みに時間がかかり、 気軽に再投⼊できない • 各カラムのカーディナリティを ⾼精度で設計しなければ パフォーマンスに影響が出る
8. どこが⼀番ネックか AIで⾃動化する 要件情報 テーブル別設計情報 カラム別に カーディナリティや ⼊りうる値を定義したもの SQL⽣成スクリプト 本番⽤SQL (数千万~数⼗億件) RV後 踏み台サーバ上で ⼿動実⾏ テスト⽤SQL (100件) スクリプトを テストモードで実⾏し、 テスト⽤SQLを実⾏ テスト⽤DBコンテナ
9. どこが⼀番ネックか AIで⾃動化する 要件情報 テーブル別設計情報 本番⽤SQL (数千万~数⼗億件) SQL⽣成スクリプト 破綻した カラム別に カーディナリティや ⼊りうる値を定義したもの RV後 踏み台サーバ上で ⼿動実⾏ テスト⽤SQL (100件) スクリプトを テストモードで実⾏し、 テスト⽤SQLを実⾏ テスト⽤DBコンテナ
10. なぜ破綻したか AIで⾃動化する 要件情報 テーブル別設計情報 カラム別に カーディナリティや ⼊りうる値を定義したもの SQL⽣成スクリプト 本番⽤SQL (数千万~数⼗億件) RV後 踏み台サーバ上で ⼿動実⾏ テスト⽤SQL (100件) スクリプトを テストモードで実⾏し、 テスト⽤SQLを実⾏ テスト⽤DBコンテナ
11. なぜ破綻したか 要件情報︖
12. なぜ破綻したか 具体的にどういうことか • ビジネス層が考えていた事業戦略(お客様の移⾏計画)が データ件数レベルまで落とせていなかった →各テーブルがどのような状態になるかの「to be」がない • 商⽤環境を⾒ようにも稼働初期であるためデータが極少・偏った分布であった • デッドロックの発⽣を考慮し、ほとんどのテーブルに外部キーが付与されていない →DDL上から参照関係が⾒えず、整合性担保が難しい 性能試験の⼀次情報が致命的に不⾜していた
13. なぜ破綻したか 改善活動 • 試験計画段階でPJに直近確定している移⾏計画の提供と、シナリオの確約を要請する →確定していること、推測で決めなければいけないことを明確にする • 性能関連資料の成果物化 →⾃チームが所掌するテーブルの件数とカーディナリティを要件定義時に算出させる • 各機能の依存関係・仕様をJSONで⼀元管理する「統合スキーマ」の作成 現在はある程度⾃動化によって効率化できている
14. まとめ • ⾮機能やデータに関するto beはないことが多い • 性能試験効率化の⼀番の壁は⼀次情報の⽋落 • あるべきチームに、あるべき情報を出してもらうのもコンテキストエンジニアリング なのかもしれない
15. 皆さんが管理しているDB 3年後に何件積まれていますか︖
16. そのDBには3年後どのように データが積まれていますか︖
17. Enjoy your hacking︕