データベース設計の自動レビュー機能を生成AIで独自開発
講演者の廣瀬氏は、KINTOテクノロジーズのプラットフォーム開発部 DBREグループに所属している。
KINTOテクノロジーズは、モビリティ・カンパニー化を目指すトヨタグループのITサービスを支える内製開発部隊で、東京・大阪・名古屋にまたがって350名超のソフトウェアエンジニアを擁している。その中でDBREグループは、データベース領域にSRE（Site Reliability Engineering：サイト信頼性エンジニアリング）の考え方を取り入れて、プラットフォームやツール開発、運用、トラブルシューティングなどに携わっている。
今回紹介した社内アプリでは、データベースのテーブル設計を生成AIで自動レビューする機能を備えている。プルリクエストをオープンすると、GitHub Actionsがトリガされて、AWS上に構築した自動レビューの仕組みをキックする。そして、GitHub上のコメントとして修正案がフィードバックされる流れになっている。
今回開発したアプリケーションはシステム開発を支援する機能であるため、デプロイ可否の判断や運用時の品質を何らかの基準で評価する必要がある。
「生成AIアプリケーション開発ではこの評価が重要と考えています。生成AIからの応答を100%コントロールできないからです。私は特に機械学習のバックグラウンドがあるわけではないので、開発時に最も苦労した箇所の1つになりました」
では、この自動レビュー機能をどのような方針で開発したのだろうか。廣瀬氏は、従来の構文解析と生成AIの2つの方式があると説明した。構文解析であれば、オブジェクト名がオーバースネークケースで定義されているかはチェックできる。一方で、「格納データが推測できるようにオブジェクト名を命名する」というガイドラインに対して、オブジェクト名が「text」「data1」では意味が曖昧なのでNGになるが、こういう例は構文解析では検出が難しく生成AIの方が得意だ。
自動レビュー機能の開発方針に対して廣瀬氏は「理想は、レビュー観点に応じて構文解析と生成AIのどちらかを使い分けることですが、今回は生成AIのみでMVP（Minimum Viable Product）を実装することにしました」と語った。
では、このような機能をなぜ自前で作ったのだろうか。
すでに、GitHub Copilot／PR-Agent／CodeRabbitなどコードレビューを支援するサービスやOSSが登場しているが、多数のガイドラインの高精度なチェックは現状では困難と判断したという。また、フィードバックの方法を柔軟に調整したいという考えもあった。例えば、意味が曖昧な「data1」というカラムがあったとしても、修正案の提示は難しいためコメントのみにしたいといった具合だ。さらに、将来的に構文解析とのハイブリッド構成で精度向上を目指す意向もあった。
それでは、生成AIアプリケーションはどのように評価すればいいのだろか。
ここで廣瀬氏は、マイクロソフトが公開している「生成AIアプリケーションの評価」というドキュメントを紹介した。ここに、“GenAIOps”ライフサイクルにおける3つの評価プロセスが示されている。「この3つのプロセスで、それぞれ適切に評価することが重要とされており、私たちもこれに従ってアプリケーション開発を実施しました」と廣瀬氏は言う。
廣瀬氏は、この3つのフェーズに沿って、テーブル設計の自動レビュー機能について説明を続けた。
