こちらは TVer Advent Calendar 2025 の3日目の記事です。 2日目の記事は@irotorisさんの「New Relic MCP Server を試す〜システムパフォーマンス定点観測とインシデント調査を AI に任せる〜」でした。

2025年はお仕事で本格的に生成AIを活用し始めた年でした。
TVerでは現在GitHub Copilot, Google Gemini, Claude Codeが正式に導入されており普段から利用して開発をしています。

今回の記事では、AIのすごい活用方法は置いておいて
現場で発生する作業のうち、AIにやらせることで捗った作業の具体例を紹介してみようと思います。

スキーマを渡して、アプリケーションコードの修正
社内問い合わせ対応の初動調査
MySQLのEXPLAIN結果の分析
PlantUMLを使ったER図の生成
SpecKitを使った仕様書作成
まとめ

スキーマを渡して、アプリケーションコードの修正

TVerではOpenAPIを使ったAPIのスキーマ管理とコードジェネレート、sqlboilerを使ったDBスキーマからのコードジェネレートを採用しています。
新機能の開発に伴って新API・新テーブルが必要になるケースで、開発途中に「やはりこのフィールドはrequired/not null制約を外したい」みたいなことがありました。

当時はDevinを導入して使っていたので、APIスキーマとDBスキーマ修正、コードジェネレートまで済ませた状態の差分を含むPull Requestを用意して
Devinに指示を出すことで精度高く作業を完遂してくれていました。

@Devin このPRに追加でcommitする形で、goのビルドを通して欲しい
${Pull RequestのURL}
修正内容: OpenAPI定義とDBスキーマ上の、${オブジェクト名.フィールド名} をnull許可した
作業して欲しい内容: goの実装上では ${オブジェクト名.フィールド名}  に nil が入るようになるので、型の修正をしてポインタとして扱えるようにしてほしい

最近のAIの精度なら、スキーマ修正含めて任せても完遂してくれそうですね。

社内問い合わせ対応の初動調査

Webサービスを長く運用してると、社内からサービスの挙動や仕様に関する問い合わせが来ることもよくあるはずです。
自分もまだ知らない機能について調査依頼が来ると気が重かったのですが、AIに尋ねることで初動が楽になりました。

仕様の問い合わせが来ています。実装を読んで回答してください。

> ${問い合わせメッセージをそのままコピペ}

弊社ではSlackのグループメンションを拾ってGitHub issue化する仕組みが動いているため
問い合わせに対して、初動の対応をAIに任せる自動化はできそうな気がします。

MySQLのEXPLAIN結果の分析

直近10億レコード超えのテーブルに対する、遅いSELECTクエリの改善をやっていました。
EXPLAIN結果を見たところ、当該テーブルに対するクエリは Index lookup で数百~数千行まで絞り込めているにもかかわらず、actual timeとしてデータ取得までに5000ms近い時間がかかっていました。
またこのクエリは1回目は遅いが、2回目以降は数10ms程度に高速化することもあり、どうやらデータがメモリに乗ると速くなるようだというところまでは当たりがついていたのですが、根本原因までたどり着けていませんでした。

# こんな感じ
-> Nested loop inner join  (cost=4926 rows=112) (actual time=428..7575 rows=540 loops=1)
    -> Index lookup on テーブル名 using index名 (絞り込みカラム1='xxx', 絞り込みカラム2=1)  (cost=2463 rows=2239) (actual time=418..4977 rows=2239 loops=1)

ClaudeにExplain結果を貼って尋ねたところ「ディスクへのランダムI/Oによる遅延」の可能性を提示してくれました。
そこで SELECT * していたクエリをindexに乗っているカラムに絞ったところ（カバリングindex化）クエリが劇的に高速化しました。

${テーブル名}に対する絞り込みはindexが効いてるのに遅いのが気になります。どんな可能性がありますか？

> ${explain結果をコピペ}

今回はexplain結果にI/O遅延を指摘する内容は出力されておらず、調査に時間がかかっていましたが
Claudeに尋ねることでその背景にある可能性を提示してくれたので解決につながりました。

PlantUMLを使ったER図の生成

これまでER図の生成はDBクライアントツールなどで行っていましたが、いくつか問題がありました

たいていのツールでは全テーブルを描画したER図しか生成してしまい、図を見る人が大変
テーブル同士の関連は外部キー制約からしか読み取れないケースが多く、アプリケーション上で指定されてる関連を図に反映することが難しい

Claudeに対して以下のように指示をすることで、特定のテーブルを中心として近い距離にあるテーブルのみER図に反映することができました。 AIに図を作らせる際、画像などの形式で直接出力させるとうまくいかないことが多いですが、PlantUMLなどテキストから図に変換可能な形式で出力させると結果が安定します。

また先述の通りsqlboilerを採用しているため、DBの外部キー制約で表現できないテーブル同士の関連もsqlboilerの設定ファイル上で表現が可能です。
今回は外部キー制約 + sqlboilerで設定した関連を含むER図を生成してみました。

xxテーブルを中心としたER図を作りたいです。以下の2ファイルを参考に関連が辿れる範囲のテーブルを対象にしたER図をPlantUML形式で出力してください。

- スキーマ.sql
- sqlboiler.toml

出力された結果はVSCodeなどのエディタに貼り付け、プラグインの機能でプレビューして確認していました。
このプロンプトでは1発でほしいER図が手に入ることが少なかったので、追加で指示を出したり自分でPlantUMLを修正することで最終的なER図を作る必要がありました。

SpecKitを使った仕様書作成

弊社は新機能の要件をConfluenceにまとめています。
SpecKitは仕様駆動開発ツールなので、以下のようにMCPサーバー経由で認証したConfluenceのURLを渡すことで詳細な仕様書を作って、その後の開発まである程度AIに任せていました。

/speckit.specify ${ConfluenceのURL}に新機能「xxx」の要件をまとめているので仕様書を作ってください

# 後続のスラッシュコマンドへ進めていきます
/speckit.plan
/speckit.tasks

SpecKitを使ってうれしいのは「エッジケースや仕様の考慮漏れを指摘してくれる点」です。
簡単に例を上げると、とあるリソースの一覧をソートして返却する機能を検討している際に「ソートキーが同じ値の場合どうしますか？次の1,2,3の選択肢から選んで」のような提案をくれます。
人間が考える仕様はエッジケースについて考慮が漏れがちなので、実装開始前にこういうポイントを指摘してくれることで手戻りが減る印象がありました。
また実装時に仕様を変更しながら実装した箇所は「実装を正としてSpecKitが生成した仕様書に反映して」と指示することで、仕様書の鮮度を保てる点もよかったです。

対して悩ましいのが、人間に読ませるにはドキュメント量が多くてノイズになるところ。
大きく分けて6種類のドキュメント（仕様書、調査書、データモデル、実装計画書、作業手順書、作業一覧）が生成されるのですが、正直言って人間にとって必要な情報は仕様書くらいで、のこりのドキュメントはAIの実装に必要な情報なのでこれをどこまでgit管理すべきかはかなり悩ましいです。

自分はドキュメントを置くディレクトリに全部閉じ込めてgit管理していますが、それをマージするためにはチームメンバーによるPull Request上のレビューが必要なルールなのでAI用の文字数を人間にレビューさせることに抵抗があります。
PullRequestで「xxx.mdの仕様の内容だけレビューして」と注意書きはしてますが、それでも文章量が多いケースがあるのでテンプレートを修正するなどして人間に対するインプット量を減らさないとこの運用は続けられないだろうなという感覚です。