「生成AIで書いたコード、どうレビューする？」Vibe codingと共存する開発プロセス

Posted on 5/27/2025

この記事は、社内の生成AI LT会（LT会に関するブログ）で「誰でもできるvibe-coding」と題した発表内容を基に、AIに執筆させています。

はじめに

こんにちは、プレイドのKARTE Messageチームでエンジニアをしている大内です。

KARTE Messageは、メール・アプリプッシュ・LINEなどのチャネルからエンドユーザーにパーソナライズした配信を効率化したMAツールです。

メール配信の運用について紹介した記事や、機能改善により開発スピードが向上したことを紹介した記事がありますので、そちらも併せてご覧ください。

私たちMessageチームでは、開発の生産性をさらに高めるために、エンジニア以外のメンバーもAIを活用して開発を行う取り組みを進めています。この試みは多くの可能性を秘めている一方で、「レビュワーの負担が増えすぎる」という課題も明らかになりました。

この記事では、その課題にどのように取り組み、改善を進めているかご紹介します。

AI開発の幕開けと、見えてきた課題

チームのプロダクトマネージャー（以下、PMとします）が生成AIを使い、次々と実装を始めたのがことの始まりでした。AIによってコードが効率的に生み出され、ローカル環境で動作確認ができれば、機能が形になるという事実は、開発のスピード感に大きなインパクトを与えました。

その結果、PMは多くのPRを作成。この1ヶ月だけでも、レポート機能の改善、AI連携機能の強化、リスト表示のUI刷新、多岐にわたる機能改善に関するPRがマージされました。

一方で、この新しい開発スタイルは、いくつかの運用上の課題も浮き彫りにしました。

エンジニアのレビュー負荷増大：エンジニアから見ると、「開発の意図や目的が必ずしも明確でない大量のコード」をレビューする必要が生じた。
AI生成コードの品質：AIは既存のコードベースを完全に理解しているわけではないため、「動作はするものの、品質面では改善の余地がある」コードを生成してしまうことがあった。例えば、既存コードの再利用が不十分であったり、実装方針の変更時に古いコードが残ってしまったりするケースがある。

レビュワーからは、特に以下の点が負担増の原因として挙げられました。

PRにおける差分量の増加があった。
「まず実装してみる」という進め方だったため、設計やセキュリティリスクに関する検討がコードレビュー段階に集中し、レビューの負担が増した。
AIが生成したコードの意図を読み解くのに時間がかかることがあった。

課題解決への道のり：プロセスの見直しと改善

これらの課題に対応するため、私たちは以下の改善策に取り組んでいます。

「仕様ドキュメント」の事前作成とレビュー：開発着手前に「仕様ドキュメント」を作成し、エンジニアがレビューするフローを導入。これにより、設計段階で問題点を洗い出し、セキュリティ懸念を事前に検討できるため、コードレビュー時には実装そのものに集中できるようになった。
AIによる実装意図のコメント記載：AIが生成したコードには、可能な限り実装意図をコメントとして記述。これにより、レビュワーがコードの意図を理解しやすくなることが狙い。
PRの適切な分割：AIによる大量のコード生成に対応するため、PRを機能単位や意味のある変更単位で細かく分割するルールを設けた。仕様ドキュメントで事前に粒度を決めておくことで、レビューの負荷軽減を図っている。

レビュワーから見たAI開発：評価と今後の期待

AIが生成したコードをレビューする中で、その可能性と課題の両方が見えてきました。

評価できる点

既存の複雑な実装がある中でも、動作するコードを生成できる点は注目に値する。特にテストコードの生成精度は高く、品質向上に貢献する可能性がある。
既存の制約がない新規開発の場合、AIが生成するコードは比較的標準的で読みやすい傾向にある。
コードを記述する速度は非常に速く、人間によるレビューがボトルネックになる場合もあるほどである。

今後の改善に期待する点

既存実装が複雑な場合や、多くの背景情報を理解する必要がある場合、生成されるコードの質がまだ高くないことがある。これは事前の設計ドキュメント作成である程度カバーできると考える。
PRの粒度調整や補足コメントの追加など、実装以外の部分では、まだ人間によるコントロールが必要である。
既存のコードアーキテクチャが一般的でない場合、AIの知識外となり精度が低下する可能性がある。AIを有効活用するには、既存コードも一般的なアーキテクチャに準拠している方が望ましいかもしれない。

総じて、AIに開発を完全に任せるのはまだ難しい点が多いものの、工夫次第で品質を向上させることは十分に可能だと感じています。チームとしてこの新しい取り組みに前向きに関わり、改善を続けていくことが重要だと考えています。

現在の取り組みと、そこから得られた学び

現在、私たちは以下の対策を中心に進めています。

それは、「仕様ドキュメント」を事前に作成し、エンジニアのレビューを経たうえで開発に進むフローを確立することです。

具体的なフローのイメージ

PMが仕様ドキュメントに「背景」「期待する機能」「懸念点」を記述し、「実装方針」についてはAIの支援も受けつつ草案を作成。
- この時点で、PM自身も実装の概要を把握。
エンジニアが「仕様ドキュメント」をレビュー。
- これにより、コードレビュー時に仕様の全体像が共有され、手戻りを削減。既存コードの活用など、エンジニアの知見を早期に反映する。
レビュー結果を元に「仕様ドキュメント」を修正し、関係者間で合意。
修正された「仕様ドキュメント」を設計書としてAIに入力し実装。
- より正確な仕様に基づいてAIがコードを書くことで、誤りを減らす。

AI運用の工夫

作成した仕様ドキュメントをCursorやCopilotに一時的にルールとして登録し、開発中の参照を容易にしている。
PR作成前に必須のチェックリストを作成し、レビューの負担軽減に努めている。

これらの取り組みにより、エンジニアからは「レビューの負担が軽減された」という声も聞かれるようになってきました。（もちろん、まだ改善の余地はあります。）

得られた学び

この経験から、ビジネスサイドとエンジニアが共同で仕様を定義し、開発を進めていくプロセスが、AIの登場によって大きく変わる可能性を感じています。

現在のAIの進化を見ると、いずれ「仕様書＝実装」という未来も現実のものとなるかもしれません。私たちMessageチームは、今後もこの新しい開発スタイルに積極的に取り組み、知見を深めていきたいと考えています。