一般的にデータベースの変更はアプリケーションの変更に比べると影響が大きく、慎重な対応が求められます。またcreatedAtのデフォルト値など、実行タイミングにより値が変動する設定をし忘れた場合、元の値を復元することは困難です。そのためできる限りプロダクションでの変更を少ない回数にするために、リリース前の慎重なレビューによる地道な改善活動が重要になります。
一方で手動によるレビューは属人性が高くなりやすく、データベースという専門性が求められるコンポーネントへの変更レビューはボトルネックになりがちです。
これまでは、レビュー依頼のフォーマット整備やレビュアー教育によって個々の処理能力を向上させるか、あるいは担当者を増やすといった解決策しかありませんでした。
しかし近年の生成AIの発達により、第三の選択肢としてレビューを自動化する選択肢を容易に選ぶことができるようになりました。
このブログではGoogle Cloudが提供するGemini Code Assist for GitHubを利用して、より安全なPrisma ORMのデータモデリングとレビュープロセスを実現する方法を紹介します。
はじめに
このブログで紹介するGemini Code Assist for GitHubは2025年6月時点ではPreviewステータスとなっています。Google Cloudによる生成AIプレビュー製品向け追加規約により、出力結果を画像や文章などの形式で直接共有することができません。そのためこのブログではGitHubのプルリクエストURLを記載するにとどめます。
またこのブログ内で紹介しているコードやスタイルガイドはあくまでサンプルとなります。実際に利用する場合はご注意ください。
Gemini Code Assist for GitHubとは？
Gemini Code Assist for GitHubはGoogle Cloudが提供する生成AIモデルであるGeminiシリーズをバックエンドモデルとしたコーディングエージェントのうち、GitHubでの利用に特化した製品です。Gemini Code Assist for GitHubを利用することで、GitHubのプルリクエストを自動的にレビューしバグやスタイルの問題、コードの修正を提案します。
Gemini Code Assist for GitHubは.gemini/ ディレクトリにあるconfig.yaml とstyleguide.md を利用して、リポジトリレベルまたはディレクトリレベルでの設定を適用することができます。
config.yamlによる設定のカスタマイズ
config.yamlはGemini Code Assist for GitHubの動作を制御するための設定ファイルです。
ディレクトリ内のサブディレクトリやファイルに対してレビューを行うかといった設定や、レビューに含めないファイルパターンの指定などを行うことができます。
設定項目一覧
have_fun: レビューコメントの非技術的な部分にポエムのような冗談を含めるかどうか。Default: trueignore_patterns: globパターンでレビュー対象から除外するPATHパターンを指定する。Default: []code_review: コードレビューの設定を行う。disable: Pull Requestでの自動的なレビューを無効にするかどうか。Default: falsecomment_severity_threshold: レビューコメントで指摘する内容のレベル。Default: MEDIUMmax_review_comments: レビューコメントの最大数を指定する。Default: -1(制限なし)pull_request_opened: Pull Request時に表示・実行する内容を指定する。help: ヘルプメッセージを表示するかどうか。Default: falsesummary: Pull Requestのサマリを表示するかどうか。Default: truecode_review: Pull Requestに対して自動でコードレビューをするかどうか。Default: true
明示的な設定を行わない場合、下記のconfig.yamlが適用されます。
have_fun: true
code_review:
disable: false
comment_severity_threshold: MEDIUM
max_review_comments: -1
pull_request_opened:
help: false
summary: true
code_review: true
ignore_patterns: []またGoogle Cloudが管理するリポジトリの一つであるgoogle-gemini/gemini-cliでは下記のconfig.yamlを利用しています。
have_fun: false
code_review:
disable: false
comment_severity_threshold: HIGH
max_review_comments: -1
pull_request_opened:
help: false
summary: true
code_review: true
ignore_patterns: []styleguide.mdによるスタイルガイドの提供
styleguide.mdはマークダウン形式のファイルで、コードレビュー時に参考にしてほしい情報やレビュールールを記述します。つまりコーディング規約や設計規則といった、プロジェクトのドキュメントを記述することになります。
このブログでは主にstyleguide.mdを利用したコーディング規約と設計規則の定義によるGemini Code Assist for GitHubのレビュー結果の違いを紹介することがメインとなります。
Gemini Code Assist for GitHubを利用したPrisma ORMのレビュー
前述の章でstyleguide.mdを設定することで、レビューの挙動をカスタマイズできることを紹介しました。この章ではstyleguide.mdを設定することで、Prisma ORMのデータモデリングをレビューする方法を紹介します。
今回は特別なstyleguide.mdを設定しないパターンと、Prisma ORM用ディレクトリにコーディング規約のみ定義するパターン、そしてコーディング規約に加えてデータモデリングのルールを定義したより高度なレビューを試します。
レビュー対象とするprisma.schemaファイル
それぞれのパターンの前提として、下記のprisma.schemaファイルを利用します。
// This is your Prisma schema file,
// learn more about it in the docs: https://pris.ly/d/prisma-schema
// Looking for ways to speed up your queries, or scale easily with your serverless or edge functions?
// Try Prisma Accelerate: https://pris.ly/cli/accelerate-init
generator client {
provider = "prisma-client-js"
}
datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
}
model User {
id Int @id @default(autoincrement())
email String @unique
name String?
posts Post[]
profile Profile?
createdAt DateTime
updatedAt DateTime
deletedAt DateTime?
}
model Profile {
id Int @id @default(autoincrement())
bio String?
userId Int @unique
user User @relation(fields: [userId], references: [id])
}
model Post {
id Int @id @default(autoincrement())
title String
content String?
published Boolean @default(false)
authorId Int
author User @relation(fields: [authorId], references: [id])
categories Category[]
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
}
model Category {
id Int @id @default(autoincrement())
name String @unique
posts Post[]
}デフォルトでGemini Code Assistを利用する
まず初めにstyleguide.mdを設定しない場合、どのようなレビューを生成するかを紹介します。
レビューによる指摘の概要
この状態でprisma.schemaに対して出力されたレビューの主なポイントとしては下記の通りです。
UserモデルcreatedAt/updatedAtカラムについて、デフォルト値と自動アップデートの設定を入れること- アプリケーションでも設定していないことからエラーが発生することから提案しているようです。
ポイント
ここでは、すべてのテーブルにcreatedAtとupdatedAtが存在することや、userIdに基づくRLS（Row-Level Security）を適用するといった暗黙の前提をコンテキストとして与えていないため、それらに関するレビューコメントは出力されていません。
styleguide.mdを利用したレビューの高度化
次にstyleguide.mdにコーディング規約を設定することによる挙動の変化を確認します。
styleguide.md の概要
実際に適用したstyleguide.mdのうち今回のレビュー結果に関係するポイントは下記の通りです。
- モデル名・カラム名の命名規則
- PKの方針とIDカラムのデータ型
- 暗黙的なMany-to-Manyモデルの宣言によるテーブルの生成抑止
- すべてのテーブルで
createdAt/updatedAtカラムを追加し、自動アップデートを設定すること - 子テーブルは親テーブルの更新時の動作を記述すること
- Boolean型は
is/has/canをprefixにつけること - モデルのフィールド順序のルール
全文はリンクを確認ください。
レビューによる指摘の概要
この状態でprisma.schemaに対して出力されたレビューの主なポイントとしては下記の通りです。
Userモデルidカラムにuuidを利用することcreatedAt/updatedAtカラムにデフォルト値と自動アップデートの設定を入れること- モデルのフィールド順序を
styleguide.mdに従って整列すること
Profileモデルidカラムにuuidを利用すること- RLSのために
userId/idカラムでPKを作成すること createdAt/updatedAtカラムを持つことUserモデルのDELETE/UPDATEアクションに対する挙動を設定すること- モデルのフィールド順序を
styleguide.mdに従って整列すること
Postモデルidカラムにuuidを利用すること- RLSのために
userId/idカラムでPKを作成すること Categoryモデルとの間に暗黙的なmany-to-manyのリレーションが作成されるのを避けることboolean型のフィールド名をpublishedからisPublishedに変更することUserモデルのDELETE/UPDATEアクションに対する挙動を設定すること- モデルのフィールド順序を
styleguide.mdに従って整列すること
Categoryモデルidカラムにuuidを利用することcreatedAt/updatedAtカラムにデフォルト値と自動アップデートの設定を入れることPostモデルとの間に暗黙的なmany-to-manyのリレーションが作成されるのを避けること
ポイント
styleguide.mdの定義により、デフォルト状態では出力されなかったコーディング規約に則った様々な指摘が出力されます。特に、単純なsed/grepのようなスクリプトベースでは検出が難しい暗黙的なmany-to-manyの宣言を検知できることにも注目です。
styleguide.mdにコード修正よりも高度なレビュー項目を試す
最後に単純なルールを超えた、データモデリングにかかわるガイドを追記します。
styleguide.md の概要
## 8. Deletion Strategy
### 8.1. Deleted Tables
Instead of soft deletion with a `deletedAt` field, we use separate deleted tables with database triggers to maintain a complete audit trail of deleted records.
For each main table that requires deletion tracking, create a corresponding deleted table with:
- The same structure as the original table
- An additional `deletedAt` timestamp field
- An additional `deletedBy` field to track who deleted the record
※モデルのサンプル略
### 8.2. Deletion Triggers
Database triggers MUST be created to automatically copy records to the deleted table before deletion. These triggers are managed in version-controlled .sql files as they are not part of the Prisma schema.
Example trigger structure:
※トリガーのサンプル略
### 8.3. Naming Convention for Deleted Tables
- Deleted table names MUST follow the pattern: `Deleted{OriginalModelName}`
- Example: `User` → `DeletedUser`, `Post` → `DeletedPost`
### 8.4. Gemini Code Assist Implementation Notes
When implementing deletion functionality, Gemini Code Assist should suggest the following changes:
※どのように修正すべきかの手法のため略該当箇所はリンクを確認ください。
レビューによる指摘の概要
ほとんどの指摘は「styleguide.mdを利用したレビューの高度化」に含まれる内容です。
一方で大きな違いとしては下記がありました。
UserモデルdeletedAtによるソフトデリートではなく、DELETE時にトリガーでDeletedUserモデルにアーカイブするよう提案
ポイント
deletedAtによる削除フラグではなく、アーカイブテーブルの利用を促すガイドを提供することで、deletedAtの不使用と代替案を自動で提案させることができます。
一方でガイドには十分具体的な代替案を例示しているにも関わらずサンプルを提供することはありませんでした。再実行することで出力するのか、または現時点での限界の一つかは議論の余地があります。
まとめ
このブログでは生成AIツールの一つであるGemini Code Assist for GitHubを利用したデータベースに関わるレビューの一部自動化の手法を紹介しました。
コーディング規約を与える前と後ではレビューの精度が大きく変わり、またデータモデリングのルールに踏み込んだ規約についても変更の提案を出力することが可能になりました。これはSQLアンチパターンやデータモデリングのアンチパターンをstyleguide.mdとして保存することで、データモデリングのレビューを大きく簡略化できる可能性を示しています。
これにより、データベースエンジニアがいない組織でもより安全なデータベース変更が可能になり、データベースエンジニアがいる組織では、エンジニアがレビューの負担を軽減し、より高度で本質的な業務に集中できるようになるでしょう。
一方で、組織特有の一般化しにくいアンチパターンやルールについては、都度データベースエンジニアがコンテキストを整理し、styleguide.mdを育てていく必要があると言えるでしょう。