14:59 - 15:54
自己修復するCIと、証拠を伴うコードレビュー
前の章では、静的解析や画面の比較、フロントエンドとバックエンドの接続確認を、共有CI（継続的インテグレーション）の前に実行する流れを見ました。これは開発の内側のループです。問題を早く見つけて、作成した環境の中ですぐ直せるようにします。
この章では、その後の外側のループを扱います。外側には共有CI、より深いコードレビュー、そして人による確認があります。Uberの説明では、エージェント型SDLCは「コードを生成して終わり」ではありません。検証の結果を使って修正し、確認できる証拠を残しながら、変更を次の段階へ進めます。
CIの自己修復は、限定された修理ループです
CIは、プルリクエスト（PR）に対してビルドやテストを行う共有の自動化です。複数のチームが同じCIを使うため、CIに送る変更が増えると、失敗への対応も共有の負担になります。そこで、外側のCIの一部に自己修復（self-healing）を組み込みます。
ただし、自己修復は「どんな失敗でもAIが直す」という意味ではありません。対応できる失敗の種類をあらかじめ決め、その種類だけを分類し、修理し、もう一度実行する、範囲の限られたループです。原因が対応対象でなければ、人や通常の調査に戻します。
例：古くなったベースを直す
ここでいうベース（base）は、PRが変更を適用する対象ブランチの現在の状態です。下書きPRを作った後で対象ブランチが進むと、元の変更をそのまま適用できないことがあります。これを古いベースによる競合（stale-base conflict）と呼びます。
この場合の流れは、次のようになります。
- CIが失敗の種類を分類します。
- 失敗が古いベースによるものだと判断できれば、変更を現在のベースに合わせて再適用します。画面の例では、変更をリベースしています。
- CIをもう一度実行します。
- 通過すれば、修理後の結果を次の確認へ渡します。
図1：失敗の分類、修理、再実行、通過という、限定された自己修復の経路です。
この図が示すのは、自己修復が動く一つの経路です。すべてのCI失敗が自動的に解決されることを示しているわけではありません。特に、分類を間違えたまま修理を続けると、問題を隠したり、別の変更を加えたりする危険があります。したがって、修理の対象と停止条件を管理する必要があります。
検証をどのモデルで行うかを分ける
Uberの説明では、レビューや検証を一種類のモデルだけに任せません。開発の内側のループでは、小さくて速いモデルを使いやすい場合があります。編集のたびに簡単な検査を行うなら、待ち時間と費用を抑えることが重要だからです。
一方、外側のループでは、より強力なモデルを使って、深いレビューを行えます。たとえば、複数のリポジトリにまたがるPRでは、変更のつながりや設計上の問題を広く調べる必要があります。この仕事には、単純な形式チェックより深い推論が必要です。
これは、強いモデルを常に使うか、安いモデルだけを使うかという二択ではありません。確認する場所に応じて、モデルの深さを分ける設計です。
例：レビューのモデルを段階化する
すべての編集に対しては、速いモデルが、文法や決められたルールなどの基本的な問題を確認します。問題がなければ、開発者やエージェントは次の作業へ進めます。
その後、複数リポジトリのPRが外側のレビューに来たとします。ここでは、より強力なモデルが、関連する変更の整合性や、要件に対する実装の妥当性を詳しく調べます。
この段階化には、四つのトレードオフがあります。速さ、実行回数、費用、そして推論の深さです。頻繁な検査には速さを優先し、回数が少なく影響の大きいレビューには深さを使います。具体的なモデル名や、各モデルの正確な性能は、この説明だけからは決められません。
自律的なPRには、読める証拠を付ける
自律モードでは、エージェントが人から細かく指示されなくても、目的に向かって作業を進めます。しかし、自律的に作られたことは、正しさの証明ではありません。人が確認する必要がなくなるのではなく、人が確認しやすい形で情報を残す必要があります。
そのため、Minionが作った自律的なPRには、これまでに行った検査の一覧や、画面のスクリーンショットなどを添付します。レビュー担当者は、変更の差分（diff）だけでなく、どの検証を通ったか、その結果を示す資料も見られます。これは、成果物の来歴（provenance）を見えるようにする設計です。来歴とは、成果物がどのように作られ、どの検査を受けたかを示す情報です。
例：証拠を伴う自律的なPRを読む
レビュー担当者が、Minionによる複数リポジトリの差分を開いたとします。PRには、実行済みのチェックの表と、画面の確認結果が添付されています。担当者は、次のように確認できます。
- 要件に対応する変更がどのリポジトリにあるか。
- どの静的解析、テスト、統合確認が実行されたか。
- 画面が設計どおりかを確認する資料があるか。
- 失敗した検査を、どのように修正して再実行したか。
図2：チェックリストと添付レポートが、自律的な変更の検証結果を人に見せています。
この図は、レビュー前に検証の証拠が添付されていることを示します。ただし、添付があるだけで変更が正しいと決まるわけではありません。証拠は、人が判断するための材料です。最終的な受け入れや却下の権限を人が持つことが、信頼の重要な部分です。
この段階の意味
この仕組みでは、生成、検証、修正、レビューが一つの流れになります。内側のループでは速いモデルと早い検査を使い、外側のCIでは対応可能な失敗を限定的に修理し、必要なら深いレビューに進みます。その各段階で、検査結果を記録しておけば、変更がどのように確認されたかを人が追跡できます。
大切なのは、自律性をレビューの代わりにしないことです。自動化が増えるほど、何をしたか、何を確認したか、どこに不確実性が残っているかを見えるようにする必要があります。自己修復とモデルの段階化は人を消す仕組みではなく、人が重要な判断に集中できるように、反復的な確認と証拠の収集を整理する仕組みです。