AI駆動開発の開発フロー｜レビュー・テスト・CIで人の判断を残す

AI駆動開発では、仕様の整理、調査、実装、テスト追加、リファクタリングまでをAIに依頼できます。Codex CLIの公式情報でも、リポジトリ内でコードを調べ、変更し、ローカルの開発ツールを動かし、差分レビューまで支援する流れが説明されています。便利な一方で、変更量が増えるほど、誰が何を確認したのかは見えにくくなります。

従来の開発でも、重要ブランチへ直接pushすれば事故は起きます。AIが入ると、差分は速く大きくなり、説明文も自然に見えます。レビューする人が「動きそうだ」と受け流す余地が広がるため、開発フローの中心にはmainへ入る条件を置きます。

GitHub Docsは、保護ブランチでプルリクエストレビュー、必須ステータスチェック、会話の解決、署名付きコミット、リニア履歴、デプロイ成功などを設定できると説明しています。AI生成か手書きかを分けず、重要ブランチに入る変更は同じ条件へ通す。AI駆動開発の考え方を整理するときも、この入口と出口の分離が土台になります。

AIに大きな依頼を渡すほど、一度に出てくる差分は広がります。新機能、既存修正、テスト追加、命名整理、不要コード削除が一つのプルリクエストへ混ざると、レビューは急に難しくなります。人が読んでいるつもりでも、実際にはAIの出力を追認するだけになりやすい状態です。

作業は、公開判断できる単位で切ります。「決済画面を改善する」よりも、「入力値バリデーションの不足を補う」「エラー表示の条件を直す」「既存テストの抜けを埋める」のほうが、仕様と差分とテストの対応を見やすくなります。AIへの指示を細かくする目的は、プロンプトを飾ることではありません。後から人が検証できる形にするためです。

チケットやプルリクエストに残すべき情報も変わります。AIへ投げた文章の長さより、完了条件、対象外にした範囲、確認方法、懸念点が効きます。公開時には差分、テスト結果、CI結果、レビューコメントを読み、プロンプト履歴は補助情報として扱います。

AIによるコードレビューは、自己点検として役に立ちます。Codexの公式情報では、未コミットの変更、コミット、ベースブランチとの差分に対して専用レビューを実行し、作業ツリーを変更せずに優先度付きの指摘を返す流れが示されています。プルリクエストを出す前に、影響範囲や見落としを洗い出す用途には向いています。

ただし、AIレビューの結果を人間レビューの代わりに置くと、公開判断の主体が薄くなります。人が見るべきなのは、差分の目的、仕様との一致、失敗時の戻し方、ユーザー影響です。AIレビューは読む観点を増やす補助にとどめ、承認は人が行います。

GitHubの保護ブランチでは、マージ前に一定数の承認レビューを求めたり、コードオーナーの承認を必須にしたりできます。変更後のpushで古い承認を無効にする設定もあります。AIへ強く任せるほど、承認者と責任範囲を曖昧にしない設計が必要です。Claude CodeとCodexの違いを見るときも、出力の好みだけでなく、レビューと承認をどの運用に置けるかを確認します。

AIが実装したコードは、もっともらしく見えることがあります。型が通り、命名が整い、説明も自然であれば、レビュー側の警戒は下がります。そこでテストとCIをマージ前の必須条件へ置き、気づいたときだけ走らせる運用を避けます。

GitHub Actionsの公式ドキュメントでは、リポジトリ内でワークフローを作成し、ビルドやテストを実行する継続的インテグレーションの流れが説明されています。AI駆動開発の開発フローでは、まず型検査、lint、単体テスト、主要な統合テストをpull_requestで動かす構成が現実的です。セキュリティチェックやE2Eテストを足す場合も、失敗したときに誰が直し、どの結果を公開判断へ使うのかを決めてから広げます。

CIを増やすほど安全になる、という話でもありません。必須チェックの名前が重複したり、path filterやskip条件で期待したジョブが動かなかったりすると、通ったように見えるだけの確認になります。保護ブランチの必須ステータスチェックに置くものは、安定して実行され、失敗時の意味をチームが説明できるものに絞ります。

AI駆動開発の議論では、モデル性能やプロンプトに目が向きがちです。実務で同じくらい効くのは、AIエージェントがどのファイルを読めるか、どこへ書けるか、ネットワークを使えるか、コマンド実行前に承認を求めるかです。これはセキュリティ設定であり、開発フローの設計項目でもあります。

Codexの承認とセキュリティに関する公式情報では、サンドボックスができる範囲を決め、承認ポリシーが範囲外の行動前に確認を求める構造が説明されています。workspace-writeではワークスペース内の読み書きとコマンド実行を許し、ワークスペース外の編集やネットワークアクセスには承認を求める構成が例示されています。

通常の実装では、ワークスペース内の編集とテスト実行までを許可する。外部ネットワーク、ワークスペース外の編集、依存関係の追加、マイグレーション、デプロイ関連ファイルの変更は承認制にする。境界を先に決めておくと、AIの便利さを残しながら、危険な変更を人の判断へ戻せます。

CIが成功した後にも、人が決める条件は残ります。レビューが承認され、テストが通り、必須チェックがそろっても、公開による業務影響、ユーザーに見える変化、告知の必要性、障害時の戻し方までは自動で判断されません。ここを曖昧にすると、AI駆動開発のフローは形だけになります。

公開前の確認項目は短く固定します。差分の目的はチケットと一致しているか。ユーザーに見える変更を説明できるか。失敗時に戻せるか。監視やログで異常を検知できるか。必要な関係者が承認しているか。これをプルリクエストテンプレートやリリースチェックリストに置けば、判断が個人の記憶に閉じません。

AI駆動開発の導入では、生産性や品質の向上を保証する発想より、判断条件を運用に落とす発想が重要です。研修、導入支援、技術顧問を使う場合も、Claude CodeやCodexの公式パートナー・認定のように誤解させず、自社の開発体制に合わせてレビュー、テスト、CI、公開判断を設計します。Cotomuの公開LPでは、AI駆動開発の研修は30万円、導入パッケージは50万円から、技術顧問は15万円/月、初回60分相談は無料と案内しています。