バイブコーディングの前に、設計を考える
現在、株式会社オプアでは、技術開発AI（ChatGPT）を中心に、Claude CodeとCodexを組み合わせた開発方法を試しています。
今回はプログラムの実装そのものよりも、その前段階となる設計方針やドキュメント管理方法について、AIによるレビューと修正を繰り返してみました。
役割は、技術開発AIが全体方針や判断事項を整理し、Claude Codeが設計書などを作成・修正、Codexが独立した立場からレビューするというものです。
AIが作る前に、人が考える時間
最近は「バイブコーディング」という言葉をよく耳にします。
AIに要望を伝えると、短時間でプログラムができあがる。これは大きな進歩だと思います。
一方で、開発の目的や設計方針について、プロジェクト関係者の認識がずれたまま実装を進めると、後から大きな手戻りが発生する可能性があります。
人が介在する設計の認識合わせには、どうしても時間がかかります。
しかし、何を作るのか、なぜその設計にするのか、どこまでを対象とするのか。
こうした議論には、必要な時間を確保して取り組みたいと考えています。
「2日後にレビュー」が「数分後」に
従来の開発では、設計書を作成してレビューを依頼すると、
「次はいつレビューできますか？」
「2日後にお願いします」
というやり取りも珍しくありません。
ところが、AI同士では数分後にレビュー結果が返ってきます。
指摘を修正して再レビューする。このサイクルを短時間で何度も繰り返せることには、大きな可能性を感じました。
ただし、速さには別の問題もありました。
レビューは、いったいいつ終わるのか？
今回の取り組みでは、Codexによるレビューを合計27回実施し、そのうち26回で修正対応を行ってみました。
レビューを重ねることで、設計の曖昧さやドキュメント間の不整合が見つかり、品質が向上していく実感はありました。
しかし、修正すると別の指摘が出てくる。
その指摘を修正すると、また新たな指摘が出てくる。
途中から「これは、いったいいつ終わるのだろう？」と感じるようになりました。
AIは疲れずにレビューしてくれますが、指摘を受け取る人間の時間は有限です（笑）。
ここで気づいたのが、レビューの品質だけでなく、レビューを終える基準も設計する必要があるということです。
レビュー結果をどう記録するか
もう一つ重要だったのが、レビュー記録の管理方法です。
指摘を修正したという結果だけでは、後から判断の経緯を追いかけることが難しくなります。
そこで、レビューごとに識別番号を付け、指摘内容、重要度、対応方針、修正結果、再レビュー結果を関連付けて記録する方法を検討してみました。
さらに、レビュー原文と要約を区別して残すことや、対応を保留する場合の理由も明確にする方針です。
単なる修正履歴ではなく、なぜその判断をしたのかを後から確認できる記録を目指しています。
AIレビューにも終了基準が必要
今回の経験から、レビュー運用に次の基準を設けることを考えています。
- Critical・High： 重大な問題が残っている場合は、原則として次工程へ進まない。
- Medium・Low： 影響やリスクを評価し、理由と対応時期を明確にしたうえで保留を判断できる。
- 修正の影響範囲： 指摘箇所だけでなく、関連する設計への影響を確認する。
- レビューの収束： 指摘件数をゼロにすることだけを目的とせず、品質・リスク・検証状況から判断する。
- 最終判断： 次工程への移行や重要な変更は、人が承認する。
特に、レビューを何回繰り返すかではなく、どの状態になれば次へ進めるのかを明確にすることがポイントだと感じています。
3つのAIを連携させた、その先へ
現在は、技術開発AI、Claude Code、Codexの間で情報を受け渡しながら進めています。
今後は、レビューの重要度判定、修正範囲、再レビュー条件、終了基準などを明確にし、3つのAIを自動連携させることで、管理作業の時間を短縮できるのではないかと考えています。
もちろん、AIが生成したものをそのまま採用するのではなく、人が確認・判断する仕組みは必要だと思います。
「AIで簡単に作れた」という話を耳にする機会が増えました。
では、その品質は大丈夫なのでしょうか？
これから求められるエンジニアは、AIを使って速く作れる人だけではないと思います。
AIを活用しながら、設計の妥当性を判断し、品質を確保し、利用者にとって価値のあるものを提供できる人。
そんなエンジニアの役割について、今回の取り組みを通じて改めて考えてみました。
最適な融合が、可能性を増幅する。
株式会社オプアでは、これからもAIと人が協働する開発方法を探っていきます。
