この記事は、機能したのに定着しなかった自動化の記録である。DMM のプラットフォーム開発本部のユーザーレビューグループに所属する著者は、2025 年 7 月に Claude Code Action を使ってプルリクエスト自動承認の仕組みを構築したことを述べている。エージェントが各プルリクエストをスコアリングし、スコアがしきい値を超えれば自動で承認するというものである。記事によれば、精度は悪くなく、プロンプトの調整によって安定した運用も実現できた。しかし、その仕組みはチームに定着しなかった。記事が主題とするのは、精度の問題ではなく、この乖離である。
記事がたどり着く説明は、コードレビューは品質チェックであるだけでなく意図を共有する対話でもあり、チームが感じた違和感はその対話を自動化によって取り除いてしまったことから生じた、というものである。記事はこれを、同じグループが以前に成功させた別の自動化――ユーザーが投稿したレビューを対象とする AI コンテンツモデレーションの仕組み――と対比し、違いはツールではなくタスクの側にあるとする。モデレーションには背景や意図の共有が必要なく、その点でコードレビューは決定的に異なっていた、と記事は述べる。
結論は、記事が 2 層の表として示す役割分担である。第 1 層のコード品質は AI が得意とする領域であり、第 2 層の意図と判断は人が得意とする領域である。著者の締めくくりの立場は、AI による自動化だけを追求するとチームは短期的には速くなるが変化に弱くなり、意図の共有を積み重ねることは遅くとも変化に強いチームを生む、というものであり、このバランスを設計することこそが AI 時代の開発の要だとしている。
要点
- チームは 2025 年 7 月に Claude Code Action で PR 自動承認を構築し、AI レビュアーに各プルリクエストを 4 つの軸――
pr_clarity_score（AI の判断の明確さ）、code_quality_score、test_quality_score、security_quality_score――でスコアリングさせ、スコアが基準を満たした場合にのみauto_approvalを"Y"にした。記事では、これら 4 つのスコアに PR の要約と理由を添えた出力オブジェクトの例が示されている。 - 精度は許容できる水準で、プロンプトの調整によって安定した運用が得られたが、この仕組みはチームに定着しなかった。記事はこれを中心的な謎として提示する。失敗したのはモデルではなく定着のほうだった。
- コードレビューは品質チェックであるだけでなく、意図を共有する対話として説明される。記事は例示として 2 つのやり取りを挙げる。1 つは、レビュアーがなぜその実装を選んだのかを尋ね、リリースを急いでいたため作成者が安全な選択肢を取ったという答えが返ってくるもの。もう 1 つは、プルリクエストを読むことで、次のエンジニアが今回追加されたものを拡張または継承すれば後続の機能を作れるとわかるものである。前者は判断の背景の共有であり、チームの信頼を築くものと位置づけられ、後者はコードレベルでの意図共有であり、次の設計への橋渡しと位置づけられている。
- 同じグループは、別のタスクをすでに完全に自動化していた。投稿されたユーザーレビューを分析し、禁止用語やルール違反を判定する AI コンテンツモデレーションの仕組みであり、全レビューの 60% 超を自動承認し、承認までの時間を 1〜3 日から約 10 分に短縮したと報告されている。記事の議論はこの対比を軸にしている。モデレーションには背景や意図の共有が必要なく、それがコードレビューとの決定的な違いだと述べられている。
- AI が生成したコードは、整っていてテストも通るが、なぜそうしたのかが伝わらないものとして描かれる。記事は、AI も理由を生成することはできると認めつつ、判断における迷いや比較、揺らぎを表現することはできないと述べる。そのため AI が作成したプルリクエストは、正しく動作しても信頼できるとは限らず、この「信頼の層」こそ人が担うべき部分だとされる。
- 記事のまとめのモデルは、レビューを 2 つに分ける。第 1 層のコード品質は AI の得意分野として AI に割り当て、第 2 層の意図と判断は人に割り当てる。純粋なコード品質のチェックは AI に委ねられるとされ、意図を共有し理解を深める時間は人が担うべき部分とされる。
- 以上はすべて 1 つのチームによる自らの経験の記述であり、記事が述べる定着の失敗について測定は示されていない。
背景
記事は、DMM のプラットフォーム開発本部で進められている AX（AI Transformation）戦略の中に自らを位置づけ、同グループが週次の AI 分析会や Findy Team+ の活用といった取り組みを通じて、AI による生産性向上を推進していると述べている。そうした背景のもとで、チームは独自の壁を感じたと報告し、コードレビューの自動化を通じてその原因を見つめ直すことにしたという。
著者は、自動化のコストを、チームが得るものではなく失うものの観点から捉えている。コードが大量に生成され、なぜそう書いたのかという議論が省かれれば、コードベースは生きた知識として育たなくなり、チームは変化に弱くなる。記事は具体的な構成を処方するのではなく、設計の問いを読者に投げ返して締めくくられている。