レビュー負荷への対応──変更リスクに応じて承認要件を変える
山中氏は、ソフトウェア開発ライフサイクルの各工程について、AI活用の現状評価を包み隠さず示した。
計画はPRD作成が人間主導で、NotebookLMを使ったN1分析などはあるもののAIは壁打ちと下書き支援にとどまるため「△」。設計は仕様書のAI生成がテンプレートとして運用に乗り、Spec-Driven Developmentも実施しているため「〇」。実装はClaude CodeやCodexなどのコーディングエージェントが入り「◎」。テスト・レビューはAIコードレビューが組織標準になっており「◎」。デプロイはTerraformやArgoCDによるオペレーション基盤こそ成熟しているが、AIによる自律実行はまだ限定的で「△」。メンテナンスはインシデント対応にbotやMCPを組み込み障害調査時間を短縮できているため「〇」とした。
障害対応の具体例も紹介された。DatadogのBits AIに「これ根本原因を教えて」と投げかけると、Kubernetesのistio-cniが使うTLS証明書の期限切れという根本原因の候補を、決定的な証拠や因果関係の推定、推奨アクションまで添えて返してくる。対応するメンバーの経験レベルに関わらず、障害対応の時間短縮に貢献しているという。人間は提示された内容をレビューして手を打てばよく、これまで対応者のスキルに依存していた部分がAIによって底上げされた形だ。
コード実装の速度が上がれば、レビューの負荷が上がるのは当然だと山中氏は認める。革新的な解決策があるわけではないとした上で、ABEMAが選んだのは、すべてのプルリクエストを一律に厳格レビューするのではなく、変更リスクに応じてレビュー責任者の要件を変えるという現実的な方針だ。
リファクタリングやテストコードの修正など低リスクな変更は1件の承認、機能追加やAPI改修など中リスクな変更は2件の承認、インフラ変更や認証・認可に関わる大規模な変更は1件の承認に加えてエンジニアリングマネージャーかテックリードの承認を必須にする。まだ実現はしていないが、ここにAIレビューが組み合わされば、低リスクな変更はセルフマージできるようにすることも検討中だ。
ドキュメントの分散にも同じ発想で向き合っている。これまでesa、GitHub、Notion、Google Docsに仕様書や設計文書が散らばり、どれが最新かAI自身も判別できないという課題があった。これからはGitHubにドキュメントを集約し、ドメインや機能で階層化する。継続的な運用には検索やチェンジログ作成を担うMintlifyを採用し、素のGitHubのMarkdown環境では手が届きにくい部分を補っている。
