その変更は、どう本番に届く？——AI開発の更新と公開を引き継げる工程にする

月曜の朝、「回答画面の文言を直してほしい」と連絡が入る。担当者はAIに修正を頼み、昼前には自分の環境で動かした。ところが、いざ公開しようとすると誰も答えられない。いま本番で動いている版はどれか。設定はどこにあるか。誰が確認し、問題があれば何へ戻すのか。

変更を作れたことと、会社の仕組みに安全に届けられることの間には、いくつかの受渡しがある。変更理由、確認結果、公開した版、戻す手順が一本につながって初めて、その変更は組織の仕事になる。

必要なのは分厚い規程ではない。小さな変更を、作った本人が休んでも同じ判断で流せる工程である。

最初の記録は、変更内容より変更理由

「ボタンを足す」「回答文を直す」だけでは、どこまで確認すれば終わりか決まらない。変更の入口では、困っている利用者、変えたい業務結果、影響し得るデータや操作、受入れ条件を短く書く。たとえば「担当者が未処理だけを一覧できる。処理済みの案件は更新できない」と置けば、表示だけでなく権限と状態も確認対象になる。

変更履歴は、採用した変更を、理由と時点に結び付けて残した記録である。AIとの会話をすべて保存することではない。「なぜ変えたか」「どの版へ変えたか」「何を確認したか」「誰が本番利用を認めたか」を同じ識別子で追えればよい。

履歴の入口を持つと、口頭依頼が届くたびに本番を直接直す流れを避けられる。見送った案も、理由を一言残せば、次の担当者が同じ議論を繰り返さずに済む。変更理由は、後で戻すかどうかを決める基準にもなる。

レビューは、変更の影響に合わせて人を選ぶ

レビューは、変更した箇所と確認結果を別の人が見て、受入れ条件に合うかを確かめる工程である。すべての変更に同じ人数を集める必要はない。文言の修正なら業務担当の確認で足りる場合がある。権限、個人情報、外部送信、金額計算に触れるなら、それぞれを判断できる担当を加える。

「問題なし」という記録だけでは、次回に使えない。どの版を、どの環境で、どの利用者権限と入力で試し、期待した結果と実際の結果がどうだったかを残す。失敗した試験も消さない。担当外の利用者には更新できなかった、外部送信を止めた状態では画面だけ確認した、といった境界が次のレビューを助ける。

レビューと承認も分けて考えたい。レビューは条件を確かめた結果を示す。承認は、その結果と残る不確実性を見て、本番へ進める判断である。作成者、確認者、承認者を常に三人に分けるという一律の決まりではない。影響の大きい変更ほど、一人の見落としがそのまま公開判断にならない組み合わせを選ぶ。

デプロイは、確認済みの版を本番へ渡す仕事

デプロイは、確認した版と設定を、利用者が使う本番環境へ反映する工程である。単に「公開ボタンを押す」ことではない。何を、どの環境へ、どの設定で、誰の権限を使って届けたかをそろえる受渡しだ。

開発環境で動いた版でも、本番では接続先、送信先、秘密情報、利用者権限が異なることがある。そこで公開前に、承認された版と実際に反映する版が同じか、環境ごとの設定差は管理されているか、公開権限を誰が持つか、公開直後に何を確認するかを読む。担当者の手元だけにある設定は、この時点で引継ぎを止める。

たとえば、レビュー後に「文言だけ」とAIへ追加修正を頼んだなら、そこでできた版は、先ほど確認した版とは別である。差分を読み、必要な試験をやり直してから公開対象にする。公開後も、本番に届いた版の識別情報を記録すれば、「確認したはずの変更」がどこで食い違ったかを追える。

OWASPのCI/CD Security Cheat Sheet は、変更を本番へ届けるパイプラインについて、権限、秘密情報、依存関係、実行環境などを管理対象として整理している。これは特定の公開サービスや自社の手順が安全だという証明ではない。公開工程そのものも点検対象である、と考える根拠に使える。

自分の環境で動いた版ではなく、レビューした版が、承認した設定で本番へ届いたことを確かめる。

ロールバックは「前の画面へ戻す」だけではない

ロールバックは、公開後に問題が見つかったとき、利用可能だった前の状態へ戻す判断と操作である。画面やプログラムを前の版へ戻せば終わる場合もある。一方で、新しい版で入力されたデータ、すでに送った通知、変更した権限は、別に確認が必要なことがある。

だから公開前に、戻す版、戻す判断をする人、操作する人、利用者への連絡先、公開後に生じたデータの確認方法を決める。戻す操作が実行できることも、影響の小さい環境で確かめておきたい。手順書の存在と、実際に戻せることは別だからだ。

緊急変更では、会社で決めた緊急時の手順に従う。担当者が独断で確認を省くという意味ではない。ただし、対象範囲、公開者、戻す条件、通常のレビューを補う期限と担当は残す。急いだ理由があるほど、事後確認を誰の記憶にも預けない。

自分が残す変更記録と、公開・切戻しの担当をつなぐ

自分が残せる変更理由と候補版、確認結果を一つの記録にする。その記録を誰が確認し、誰が公開や切戻しを判断するかも確かめる。工程全体を一人で担う必要はない。変更には、次の五つの受渡しがある。

所有者は、すべてを自分で操作する人ではない。その場所で必要な判断を引き受け、担当不在でも次の人が記録へたどり着けるようにする人だ。一人が複数を担う小さな組織でも、役割を欄で分ければ、どの判断が抜けたか分かる。

まず一つの変更をこの五つに通す。記録が続かないなら、判断に使われない項目を削る。版、確認結果、公開者、戻す条件のどれかが追えなければ、そこは減らしてはいけない。工程の完成度は書類の厚さではなく、次の担当者が同じ変更を追い、止め、戻せるかで測る。

次の変更で、履歴・確認・公開・切戻しの担当をつなぐ

AIで修正を作る速度が上がるほど、変更を本番へ届ける工程は頻繁に使われる。変更履歴が理由と版を結び、レビューが条件と結果を残し、デプロイが承認版を本番へ渡し、ロールバックが戻す判断を支える。それぞれの所有者が分かれば、更新は個人技から日常業務へ変わる。

次にAIへ修正を頼むときは、困っていることと、変えない条件を先に書きたい。できた版と確認結果を結び、公開・切戻しの担当へ渡す。自分の権限で埋められない欄は、勝手に決めず、公開前に確かめる仕事として残す。

参考資料

• OWASP CI/CD Security Cheat Sheet