変更が増えたとき、公開の仕組みをどう変えるか

変更が一日に一つなら、同じrunnerや作業ディレクトリを使い回しても問題が表面化しにくいことがあります。複数のAIが並行してブランチを作ると、前のjobのファイル、別ブランチの依存関係、古い生成物が次の検証へ混ざります。

自前で管理するrunnerでは、処理が終わったことと、環境が初期状態へ戻ったことは同じではありません。一つのjobに一つの隔離環境を割り当て、終了後に捨てる。さらにjobをまたぐ成果物にも、どの版から作られたかを持たせます。

使い捨てrunnerを名乗っていても、同じjobの途中で信頼境界の違う処理を混ぜれば影響は残ります。逆に永続runnerでも、仕事ごとの作業場所、掃除、権限、成果物を厳密に分ければリスクを減らせます。

大事なのは製品名ではなく、ある変更が別の変更へ何を持ち越せるかです。AIが増えるほど、作業場所だけでなく、キャッシュ、認証、生成物、検証結果の境界を明示します。

TerraformなどのInfrastructure as Codeには、変更計画を確認してから適用する考え方があります。問い合わせ基盤でも、どの構成をどう変えるかを先に示し、その内容と対象の版を人が確認してから実行します。

ここで人が見るのは、コマンドの細部ではありません。意図しない削除がないか、対象環境は正しいか、成果物は確認済みの版か、戻す方法があるかです。計画を作る自動化は残し、責任が変わる適用だけを止めます。

手動Applyは、担当者の待ち時間と手順ミスを残します。公開頻度が上がり、より狭い権限、独立した承認、同一成果物の保証、監査可能な復旧が整えば、再び自動化できるかもしれません。

CI/CDの目標は、人が一度も触れないことではありません。変更を速く作れる時代に、別の仕事を混ぜず、今回の版を確かめ、責任のある境界を越え、問題時に戻せることです。自動化の量は、その目的に従わせます。