15:54 - 17:16
管理された保守とフィードバックループ
生成の後にも、ソフトウェアの仕事は続きます
この章では、AIエージェントで機能を作った後の保守（maintenance）を扱います。自動化は新しいコードを速く作るだけではありません。実験が終わった後に不要なコードを片づけたり、障害から次の改善を作ったりする仕事も、自動化の対象になります。
話者の説明では、機能やサービスを保守用のスキルに登録できます。ここでいうスキルは、エージェントが作業を進める手順と判断の案内を再利用できる形にしたものです。したがって、保守は誰かが思い出したときに一度だけ行う作業ではありません。対象を登録し、決めた手順で繰り返し実行する、管理されたワークロードになります。
例：実験用の機能フラグを片づける
スタジアムでの乗車場所を試す実験を考えます。実験では、利用者に見せる選択肢を機能フラグ（feature flag）で切り替えます。たとえば、Variant Bという選択肢を一部の利用者に見せます。
実験が終わった後も、Variant Bの分岐や設定がコードに残ると、将来の変更を難しくします。開発者は、もう使わない分岐を読みながら作業しなければなりません。テストや設定も増えます。このため、実験の終了は「新しい機能を作る仕事」の終了ではなく、「一時的なコードを安全に削除する仕事」の開始でもあります。
この作業を保守スキルにすると、エージェントは対象の機能フラグを確認し、不要になったVariant Bを削除する変更を作り、レビューに回せます。これは、エージェントに自由に本番コードを消させるという意味ではありません。対象、実行時期、変更量、レビューの境界を先に決めた手順として管理する、という意味です。
実行時期と変更量を管理する
保守ジョブが一つだけなら、実行する時刻は大きな問題にならないかもしれません。しかし、サービスや実験が増えると、多数の削除候補が同時に準備されます。そのとき、CI（継続的インテグレーション）やレビュー担当者の容量は無限ではありません。すべてのジョブをすぐに実行すると、共有のCIが混雑し、月曜日に人が確認する変更も多くなります。
そのため、スケジュールと割り当て量（quota）はガバナンスの仕組みになります。たとえば、Uberの説明では、保守ループを日曜日のような負荷の低い時間に計画します。さらに、一度にレビューへ送る差分の量を制限します。こうすると、エージェントの処理能力だけでなく、CIと人間のレビュー能力も含めて、全体の流れを調整できます。
これは単に「一番速いジョブから実行する」という最適化ではありません。安全に確認できる量を守りながら、限られた計算資源と人の時間を使う設計です。自動化を増やすほど、実行の許可だけでなく、いつ実行するか、いくつまで実行するかも決める必要があります。
図：管理された保守ループと、日曜日のオフピーク実行。
図では、保守を繰り返す流れと、日曜日の負荷が低い時間に実行する考え方が示されています。図から、定期的な実行と容量を考えた時刻設定を確認できます。一方、月曜日にレビュー担当者が見る差分の制限は、図に示された事実ではなく、話者の説明に基づく内容です。出典動画の該当時点（16:36）
結果をラベルにして、手順を改善する
保守スキルを実行するだけでは、まだ学習する仕組みになりません。作られた保守PR（pull request）に、レビュー担当者がコメントを付けます。そのPRが最終的にランディング（land、変更をマージすること）する場合もあれば、拒否されてマージされない場合もあります。これらのコメントと結果は、ラベルデータとして扱えます。つまり、「どの変更が受け入れられ、どの変更に問題があったか」を、後の評価や手順の改善に使える情報にします。
例として、Variant Bの削除PRが何度もレビューで止まるとします。コメントから、エージェントが設定ファイルを確認していなかった、または関連サービスのテストを実行していなかったと分かるかもしれません。その結果を保守スキルに反映すれば、次の実行では確認手順やテストが追加されます。逆に、繰り返し問題なくランディングされた手順は、再利用できる手順として維持できます。
ここで重要なのは、自律的に作られたPRでも、人間の判断を消さないことです。レビューのコメントと、ランディングしたかどうかという結果が残るからこそ、保守スキルは現場の証拠を受け取れます。自動実行の回数だけを増やしても、結果を記録して改善しなければ、同じ誤りを速く繰り返すだけです。
インシデントから新しい保守スキルへ
フィードバックは、通常の保守PRだけから来るとは限りません。インシデント（incident、障害や運用上の問題）やバグも、手順を見直すきっかけになります。ある障害の調査で、特定の設定や古いコードが原因になりやすいと分かった場合、その知識を新しい保守スキルにまとめられます。
話者が示す月次ループでは、インシデントやバグから学んだ内容が、新しいスキルになります。そのスキルはカタログに加えられ、別のサービスや次の保守作業で再利用できます。個別の障害対応を一回限りの知識にせず、組織全体で使える手順に変える流れです。
図：インシデントとバグが、月次の改善ループで再利用できるスキルにつながる。
この図は、運用中に見つかったインシデントやバグを、再利用可能な保守スキルへ変える流れを直接示しています。つまり、運用の経験が次のエージェント作業の手順になります。図が示すのはこの学習の流れであり、個別の障害の原因や効果の大きさではありません。出典動画の該当時点（16:59）
まとめ
この章の中心は、ソフトウェア工場を「生成する場所」だけにしないことです。実験の後には不要なコードの削除が必要です。多数の保守ジョブを安全に動かすには、実行時期と変更量を管理する必要があります。そして、レビューコメント、ランディング、拒否、インシデント、バグを次のスキルに反映させます。
このループができると、保守は自動化された孤立作業ではなくなります。運用の結果が手順を変え、変わった手順が次の保守を改善します。自動化の価値はコードの量だけではなく、作ってから学び、直し続けられる仕組みにあります。