(GROOVE X Advent Calendar 2025 2日目の記事です）
こんにちは！ふるまいチームのエンジニア、市川です！
今回はふるまいチームにおける『レビュアーとAIの間に「伝書鳩」が生まれたので、プルリクエスト（PR）のレビューをやめた』というお話です。
『レビューをやめた』と言っても、もちろん品質チェックを放棄したわけではありません。 従来のような「指摘して直してもらうのを待つ」という"待ちのレビュー"を見直したのです。
Coding Agentが産んだ悲しき「伝書鳩」問題
私たちのチームでは、家族型ロボット『LOVOT』の「ふるまい（意思決定や動き）」を作っています。 ここには、大きく分けて2つの役割を持つメンバーがいます。
かつては、エンジニアがふるまいの骨組みを作り、ビヘイビアデザイナーがその中の「アニメーション」の部分を実装する、といった分業が主流でした。 しかし、GitHub CopilotやCursor、Claude Code、DevinといったCoding Agentの登場・進化により、状況は一変しました。
今や、ビヘイビアデザイナーがガッツリとアニメーション以外の実装までも行うようになっています。 AIがコーディングをサポートしてくれるおかげで、彼らのエンジニアリング能力が底上げされたからです。これは素晴らしいことです。
とは言え、「クオリティの壁」があります。
AIが書いたコードは動きますが、プロダクトとしてリリースできる品質（保守性や堅牢性）には達していないことが多い。 そこでエンジニアがレビューをするのですが、これまでのフローはこんな感じでした。
- ビヘイビアデザイナーがCoding Agentとコードを書き、プルリクエスト（PR）を出す
- エンジニアがPR上で「ここはこう直して」とレビュー
- ビヘイビアデザイナーがそのコメントを読み解き、Coding Agentにプロンプトとして入力
- Coding Agentが修正し、ビヘイビアデザイナーがpush
- エンジニアが再確認...（以下ループ）
気づいてしまったんです。
「これ、ビヘイビアデザイナーがエンジニアとAIの間の『伝書鳩』になってないか？」と。
エンジニアは、ビヘイビアデザイナーに伝わるように噛み砕いて説明しないといけない。 ビヘイビアデザイナーは、それを正しく解釈してAIに指示しないといけない。 もどかしい。なんだこれ。
そんな時、私たちはDevinを本格導入することにしました。
GitHubのPRが「3人の共同開発会場」に変わった日
当時のDevinが他のAgentと決定的に違っていた点。それは、「GitHubのPR上のコメントを直接読んで、勝手に直してくれる」ことです1。
これを使えば、エンジニアのレビューコメントをDevinが直接読み取り、修正コミットを積んでくれるはず。 実際にやってみました。
結果は、革命的でした。
エンジニアがPRに「Devin、もっとシンプルな実装にしたい。xxxでどうですか？」と書く。 するとDevinが「了解しました、修正します」と動き出し、コードを直す。 ビヘイビアデザイナーも「ここに○○を追加してください」とコメントする。 Devinが「承知しました」と対応する。
今まで「ビヘイビアデザイナー vs AI」の1対1だった関係が、「ビヘイビアデザイナー ＋ エンジニア vs AI」の多対1になれたのです。
GitHubのPRという場所が、単なるコード置き場から、職種の違う人間とAIが膝を突き合わせて議論しながら作る「共同開発会場」に進化した瞬間でした。 それぞれが自分の得意な領域（ビヘイビアデザイナーは体験、エンジニアはコード品質）から指示を出し、AIが手を動かす。しかも指示は非同期！
「これこそが未来の開発だ！」と興奮しました。
...ただ、失敗もありました。 私達がまだDevinに慣れてなかったり、Devinがふるまい開発に慣れてなかった（知識ベースが不足している）こともあり、PR上のコメント数が100件を超えてしまいました。 「エンジニアとビヘイビアデザイナーのコメントがPRに残るから、お互いどう考えてるかが分かる」なんて事も期待していたのですが、こうなると、もう追いきれません。 しかもDevinは従量課金のため、GitHub Copilotなどの月額固定にできるツールに比べると比較的コストがかかってしまいました。
それでも、この経験から私たちは「ある真実」にたどり着きました。
大切だったのは「仕様書」
Devinでの成功と失敗を経て、私たちは開発マニュアルを作成しました。 「Devinをどう使うか」をまとめようとしたのですが、整理する内に「効率を上げるための鍵」はそこではない事に気づきました。
「ビヘイビアデザイナーの承認なしに、エンジニアがガシガシ修正を入れる」
これこそが、開発効率を爆上げする鍵だったのです。
なぜ今まで、エンジニアはビヘイビアデザイナーのコードを勝手に直さず、レビューコメントで指示出し（ビヘイビアデザイナーを伝書鳩化）していたのか？ それは、「勝手に直して、ビヘイビアデザイナーが意図した動きを壊したら申し訳ない」と遠慮していたからです。
しかし、Devinを使った時はそれが気にならなかった。 なぜか？ Devinに作業させる際、ビヘイビアデザイナーが最初に「仕様書（あるいは要件定義書）」をきっちり書いて渡していたからです。
これがあるおかげで、エンジニアは「この仕様書通りなら、コードはこうあるべきだよね」と確信を持って指摘・修正ができました2。
結果論ですが、「仕様書という正解」が真ん中にあるなら、エンジニアが直接手を下してもトラブルにならない。 むしろ、ビヘイビアデザイナーからすれば「期待した通りに動くなら、中身のコードはエンジニアが勝手に高品質にしてくれた方が嬉しい」のです。
つまり、Devinのような自律型AIがいなくても3、以下のフローさえ組めれば「伝書鳩」は消えます。
- ビヘイビアデザイナーがCoding Agentに読ませるための「仕様書」を書く
- ビヘイビアデザイナーが任意のCoding Agentを活用して実装し、動作確認してからPRを作成する（PRには仕様書も含める）
- エンジニアがCoding Agentを活用して、仕様書を軸にリファクタリングする
- ビヘイビアデザイナーが動作を最終確認する（問題があれば修正して3.に戻る）
結果、エンジニアはビヘイビアデザイナーを通さずに、仕様から外れない範囲で直接コードを修正・リファクタリングできる。
Devinは「PR上でコメントを拾う」という機能でこの体験をさせてくれましたが、本質はその機能ではなく、「共通の仕様書を軸に、エンジニアが遠慮なく介入するルール」にありました。 このような開発スタイルは業界によっては当たり前かもしれないですが、僕らには新鮮でした。
「仕様書を軸にリファクタリングする」は、以前だとエンジニアが仕様を把握するのが大変で、言うほど簡単ではなかったと思います。 Coding Agentがある今は「仕様書を要約させること」も「仕様書を軸にコード修正させること」も容易にでき、今の時代だからこそやりやすい共同開発スタイルなのかもしれないです。
まとめ
ビヘイビアデザイナーの「伝書鳩問題」を「仕様書を軸に直接介入で解決した」というお話でした。これはビヘイビアデザイナーに限った話ではないかもしれないです。 今の時代、「レビュワーとAIの間の伝書鳩になる」という問題はエンジニアにも起こりそうです。
もしレビュワーに「仕様書を軸にした直接のリファクタリング」を委託できるのであれば、そうすることで効率が上がるかもしれないです。
そんなAIでの開発スタイルを模索している僕らと、一緒にお仕事してみませんか？ 是非、下記募集をご確認ください。
