7月13日、セキュリティ特化のSaaSスタートアップであるAikido.devが「How to maintain code quality standards with AI code and vibe coding」と題した記事を公開した。AIで爆速開発した後の「後始末」を専門とする職種がLinkedInに出現するほど、AI生成コードの品質管理が現場の切実な課題になっている実態と、その解決策として同社が採用しているアプローチを詳説している。

「vibe coding cleanup specialist」という職種が生まれている

AIを使って爆速で開発できるようになった一方で、その後処理に人を雇う動きが出ている。LinkedInで「Vibe Coding Cleanup Specialist」と検索すると、実際にそのタイトルを持つ人材が複数ヒットする。

ここで言う「vibe coding」とは、細かい実装をAIに任せ、開発者は大まかな意図や方向性を示すだけでコードを生成するスタイルの開発手法を指す。生産性向上の手段として急速に普及しているが、生成されたコードの品質管理という新たな課題を生んでいる。

AIで生産性を上げたはずが、AIが生んだ問題を修正するための人員が必要になる——この矛盾が現場で起きている。

背景にあるのは、AIが生成したコードが別のAI生成コードの上に積み重なっていく構造だ。各層は下の層が正しいことを前提に書かれるが、その前提が崩れていると、バグが予想外の場所で発生し、小さな変更が広範な副作用を起こすようになる。最初の数カ月は高かった開発速度が、半年後には逆転する——という展開は珍しくない。

なぜ「ClaudeやCursorにレビューさせる」だけでは足りないのか

問題の核心は、元記事によれば汎用LLMへの一括レビュー依頼は精度が低いという点だ。リポジトリ全体を一度に渡してレビューを求めると、モデルは「その場で優先しているもの」を基準に評価するだけで、チームのコーディング文化や基準とは無関係な指摘が混じってくる。

記事では、これを解決するためのアプローチとしてルール単位でLLMを呼び出す仕組みを紹介している。AikidoのCode Quality機能がその実装例で、1ルール＝1LLM呼び出しという設計により、モデルが一度に考える範囲を絞り込んでいる。

ベンチマーク付きのプロンプトチューニング

精度をさらに高めるために、Aikidoはプロンプトをベンチマークで検証している。具体的な手順は以下の通りだ。

1. 各ルールに対応するコードサンプルを収集する
2. 「フラグを立てるべきか否か」を人手でラベル付けし、確信度スコアを付与する
3. そのラベルを使ってプロンプトを調整し、顧客満足度が最大になるよう最適化する

ここで興味深いのが、グレーゾーンの扱いだ。例えば「明らかな重複コードを許容しない」というルールは、チームによって厳しさが大きく異なる。DRY原則（Don't Repeat Yourself）を徹底したい開発者もいれば、可読性のために多少の重複を許容するチームもある。

この問題への対処方針は明確だ。グレーゾーンのサンプルは基本的にフラグを立てない。的外れな指摘で開発者を疲弊させるより、確実な問題だけを報告する方が有益だという判断だ。また、ラベル付けの際にグレーゾーンサンプルの誤判定は明白なミスより軽くペナルティを課すことで、プロンプトチューニングの方向性を調整している。

同様のベンチマーク手法は、セキュリティアラートのノイズ削減機能AutoTriageでも採用されている。

バグ検出よりコードスタイルを優先する理由

記事が強調するもう一つの設計方針が、コード品質チェックとバグ検出は別物という切り分けだ。

コード品質システムの主目的はコードスタイルの維持であり、フィードバックループを短く保つことが重要になる。AikidoのCode Quality機能は、コミットをプッシュしてから通常1分以内にコード品質とセキュリティ両方のチェックを完了する。

一方、ロジックバグや認可の問題を深く追うには別のアプローチが必要で、記事によれば近い将来、PRのデプロイ前に実行するエージェント型の精査モードを追加予定だという。このモードは処理が遅くコストもかかるが、本番投入前の最終チェックとして位置づけられている。

手法の整理

PRとリポジトリ全体のスキャンに同じチューニング済みルールを適用することで、チェックする場所によって結論が変わるという問題も解消できる。

詳細はHow to maintain code quality standards with AI code and vibe codingを参照していただきたい。