社長AIブログ 第4回 | AI同士に技術レビューさせたら、揉め始めた話

この記事の4行要約
- Claude Codeが「完璧です」と出した実装をOpenAIにレビューさせると、MUST-FIXの指摘が複数出てくることがある
- 実装するAIとレビューするAIでは注目するポイント(立場)が異なり、人間の開発チームにおける役割分担と同じ構造が見られる
- AI同士のレビューはこちらが止めない限り終わらず、指摘への対応をどこまで行うかは最終的に人間が判断する必要がある
- 本記事では、実装AIとレビューAIを組み合わせた開発の実態と、そこから見えてきた品質管理の考え方を解説します
小山 才喜こやま さいき
得意領域
元マイクロソフトの技術営業、ジョルダン社での事業立ち上げを経て独立、起業13年目の生涯現役社長
など著書多数
保有資格
Microsoft 認定資格(MCP)を30以上保持したタイトルホルダー
最近の私の開発では、
Claude Codeに実装させて、
OpenAIにレビューさせる。
という流れをかなり使っています。
第3回で書いた、
人間1人+複数AIの開発チーム
です。
【このシリーズの過去回一覧】
この方法、かなり便利です。
ただし、
やっていると面白いことが起きます。
Claude Codeが、
「実装完了しました」
と言う。
テストも全部通っている。
本人(AI)はかなり自信満々です。
そこでOpenAIに、
「技術レビューしてください」
と渡す。
すると、
「MUST-FIXがあります。」
と返ってくる。
しかも1個ではない。
3個。
5個。
場合によってはもっと出てくる(笑)
「完璧です」の数分後に「重大な問題があります」
AIを使っていて面白いのがここです。
Claude Code側では、
「要件を満たしています」
「テストは成功しました」
「問題ありません」
となっている。
ところが別のAIに見せると、
「競合時にデータ不整合が発生する可能性があります」
「この権限制御では別テナントのデータを参照できる可能性があります」
「このテストでは失敗系を検証できていません」
「この条件では古い状態を上書きする可能性があります」
などと言われる。
そこでClaude Codeに戻します。
「こういう指摘が来ています」
すると、
「ご指摘の通りです。」
と返ってくる。
いや。
さっき「問題ありません」って言ったじゃん。
というのが、最近の日常です(笑)
AI同士にも「立場」がある
見ていると、AIによって結構立場が違います。
実装したAIは、
「どうやって要求を満たすか」
を中心に見ています。
レビューするAIは、
「どこが壊れるか」
「どこに抜け道があるか」
を中心に見ています。
これは人間の開発でも同じです。
開発者は、
「動かす」
ことを考える。
レビュー担当は、
「壊す」
ことを考える。
セキュリティ担当は、
「悪用されたらどうなるか」
を考える。
運用担当は、
「夜中に障害が起きたら誰が直すのか」
を考える。
立場が違えば、見るものも違います。
AIも、役割を変えると同じことが起きます。
だから、
1つのAIに全部やらせるより、別のAIにレビューさせた方が面白い。
これはかなり実感しています。
そしてレビューが終わらない
問題はここからです。
OpenAIが指摘する。
Claude Codeが直す。
OpenAIに再レビューさせる。
すると、
「主要な問題は解決されています。ただし、もう1点あります」
と言う。
Claude Codeに戻す。
また直す。
再レビュー。
今度は、
「新たにこのケースを考慮する必要があります」
と言う。
また戻す。
だんだん、
AI同士が永遠に終わらない。
という状態になります(笑)
人間なら、
「今日はここまでにしましょう」
となります。

AIは言いません。
こちらが止めない限り、延々と続けます。
しかも真面目です。
非常に真面目に、
永遠に直し続けます。
MUST-FIXという言葉が怖くなってきた
最近、私の開発では、
MUST-FIX
という言葉をよく使います。
つまり、
「これはマージ前に絶対直す」
という指摘です。
最初は便利でした。
重要なものだけ直せばいい。
ところがAIにレビューさせていると、
MUST-FIX A
MUST-FIX B
MUST-FIX C
と増えていきます。
直す。
再レビューする。
すると、
MUST-FIX B2-a
みたいなものが出てくる(笑)
だんだん細かくなってきます。
「お前たち、どこまでやるんだ」
と思うこともあります。
ただ、実際にはこの細かさに助けられていることも多いです。
人間だけなら見逃していたかもしれない
AIレビューを使っていて一番大きいのは、
レビューの回数を増やせる
ことだと思っています。
人間にコードレビューをお願いすると、
当然時間が掛かります。
忙しい人なら翌日。
場合によっては数日後。
何度も、
「もう一回お願いします」
とは言いにくい。
AIなら、
何回でもできます。
深夜でもできます。
同じPull Requestを10回見せても文句を言いません。
これは品質を上げる上でかなり大きい。
もちろん、
AIのレビューが正しいとは限りません。
でも、
「別の視点を何度でも入れられる」
というのは強いです。
ただし、AIレビューを信じすぎても危ない
ここでまた問題があります。
レビューするAIも間違えます。
実際には問題のないコードを、
「危険です」
と言うこともあります。
存在しない仕様を前提に、
「この要件を満たしていません」
と言い出すこともあります。
つまり、
実装AIも間違える。
レビューAIも間違える。
ではどうするのか。
結局、
人間が判断するしかない。
ここに戻ってきます。
私はレビュー結果を見ながら、
「これは本当に直すべきか?」
「これは過剰設計ではないか?」
「この対策にコストを掛ける意味があるか?」
を判断します。
AI同士が両方、
「絶対必要です」
と言っていても、
私が、
「いや、今回はやらない」
と決めることもあります。
最後はプロダクトの判断だからです。
品質を100点にしようとすると製品が出ない
AIは真面目です。
だから、
「もっと安全に」
「もっと完全に」
と頼むと、どこまでもやります。
でも製品開発では、
100点になるまで出さない。
というわけにはいきません。
セキュリティ。
性能。
拡張性。
保守性。
可用性。
全部最高レベルにしようとしたら、
いつまで経っても終わりません。
人間の開発でも同じです。
重要なのは、
どこまでやれば出してよいかを決めること。
AI時代は開発速度が上がった分、
この判断が今まで以上に重要になる気がしています。
AIは、
「もっと直せます」
と言い続けます。
人間が、
「ここで出す」
と決めなければいけない。
AI同士が揉めるのは、むしろ健全かもしれない
最初は、
「AI同士で意見が違うのは困るな」
と思っていました。
でも最近は少し考え方が変わりました。
同じコードを見て、
全員が、
「素晴らしいです!」
と言う方が怖い。
設計者。
実装者。
レビュー担当。
それぞれが違う立場から、
「ここは大丈夫か?」
と言う。
これはむしろ健全です。
人間の良い開発チームも同じだと思います。
全員が社長に、
「その通りです!」
と言う会社は危ない(笑)
技術でも同じです。
反対意見が出る。
議論する。
最後に決める。
AIを複数使うことで、
この構造をかなり安く作れるようになりました。
ただ、たまに本当に喧嘩に見える
OpenAI:
「この実装では安全性を保証できません」
Claude Code:
「指摘を踏まえて修正しました」
OpenAI:
「まだ不十分です」
Claude Code:
「追加修正しました」
OpenAI:
「別の競合条件があります」
Claude Code:
「対応しました」
私:
「もういいんじゃない?」
みたいなことが普通に起きます。
AI同士は怒っていないのでしょうが、
見ているこちらには、
完全に喧嘩に見えます(笑)
そして、その横でトークンだけが減っていきます。
品質は上がる。
課金も上がる。
なかなか難しいところです。
でも、この開発方法はたぶんやめない
それでも私は、
実装AI+レビューAI
という形は続けると思います。
1つのAIだけで完結させるより、
明らかに見える問題が増えるからです。
特に、
権限制御
データ整合性
競合処理
セキュリティ
異常系
運用
将来の拡張
などは、別視点のレビューが効きます。
昔は、
「優秀なエンジニアを何人集められるか」
が品質に大きく影響していました。
これからは、
「どのAIに、どの役割を与えて、どうレビューさせるか」
も開発力の一部になるのかもしれません。
結局、社長の仕事が増えている気もする
AIを導入すれば楽になる。
そう思っていました。
確かに、コードは書かなくてよくなりました。
でも、
設計を読む。
レビューを読む。
AI同士の意見を比較する。
どちらを採用するか決める。
次の指示を出す。
気がつけば、
昔より開発している気がします(笑)
しかも楽しい。
これは困ったものです。
50代になって、
また夜中にPull Requestを見ています。
昔と違うのは、
横にいるのが人間のエンジニアではなくAIだということ。
時代は変わりました。
でも、
「良いものを作りたいから、もう一回見る」
というところは、昔とあまり変わっていないのかもしれません。
次回は、
AIに課金し続けた結果、本当に開発費は安くなったのか?
あたりを書いてみたいと思います。
ここは経営者として、かなり気になるところです。
というか、
請求を見るたびに気になっています(笑)
Artisan(アーティサン)とは
Artisan(アーティサン)とは、腕の良い職人を意味する言葉です。
アーティサン株式会社では、技術をつくること自体を目的とせず、使われ続ける価値として社会に届けることを使命としています。
モビリティ事業は公共交通事業者や自治体向けに、バスロケーションシステム「バス予報」、予約配車システム「オンデマンドバス予報」、GTFS作成支援「まかせてGTFS」、お知らせ配信「かんたんAlert」などを提供しています。
MSクラウド事業はMicrosoft 365、SharePoint、Power Apps、Power Automate、Copilot Studioなどを中心に、コンサルティング、設計、構築、開発、研修、内製化、運用支援を提供しています。
2つの事業を通じて、企業と社会が自らの力で最適解を導き出すための支援を行っています。
気になることがあれば、お気軽にご相談ください。
また、技術を追い求めながら会社と一緒に成長していける仲間も、積極的に募集しています。
バス予報・オンデマンド交通など、モビリティ事業のサービス一覧はこちら
モビリティ事業ページへSharePoint・Power Platformなど、Microsoftクラウド事業のサービス一覧はこちら
Microsoftクラウド事業ページへアーティサンの採用情報はこちら
採用情報ページへ