Tsuzura

サービス公開前の確認

公開候補と証拠、設定、データ変更、停止条件、復旧方法をそろえ、GO・HOLD・NO-GOを判断する公開判定票の作り方を解説します。

公開日
更新日

テストが終わっても、そのまま公開へ進めるとは限りません。テストした版と実際に公開する版が違う、本番用の設定が足りない、問題を検知する方法や戻し方が決まっていない、といった状態が残ることがあります。

公開前の確認では、実際に公開する候補を特定し、その候補に対応する証拠、環境、公開中に見る情報、停止条件、復旧方法を一つにまとめます。社内だけで使うサービスも、顧客向けのサービスも対象です。

この記事は、要件と受入条件を決め、テストの計画と結果を記録した人を対象にしています。読み終えると、一回の公開について、GO（進める）、HOLD（保留）、NO-GO（見送る）を判断するための公開判定票を作れます。特定のクラウドや、自動ビルド・配信の仕組み（CI/CD）の操作方法は扱いません。

公開前の確認が必要な理由

公開前の確認で決めるのは、「何を出すか」「何を根拠に進めるか」「異常をどう判断するか」「問題時にどう戻すか」です。チェック項目を多く埋めること自体が目的ではありません。

公開・デプロイ・ロールアウトの違い

この記事では、用語を次の意味で使います。製品や組織によって呼び方が異なるため、実際の開発ではその環境の用語も確認してください。

用語 この記事での意味
公開 変更後のサービスを、意図した利用者や業務が使える状態にすること
デプロイ コード、設定、基盤構成などの変更を対象環境へ反映する操作
ロールアウト 変更を反映する範囲を広げる過程。段階的に広げる場合を段階公開と呼ぶ
公開候補 今回反映するコード、成果物、設定、データ変更を特定したまとまり
本番環境 実際の利用者と業務で使う環境

デプロイが成功しても、利用者が正常に使えるとは限りません。反対に、配置済みでも利用者にはまだ有効にしていない場合があります。反映する操作、利用可能にする判断、利用範囲を広げる過程を分けると、どこで確認するかが明確になります。

公開判定票が保証しないこと

英国政府のデジタルサービス向けの一例として、GOV.UKのLive段階の解説は、運用段階（Live）へ移る前に、情報保護、成功指標、可用性、監視、性能や脆弱性の継続的な確認などを準備するよう示しています。つまり、テスト結果は公開判断の材料の一つであり、それだけで公開準備の全体を表すものではありません。

Google SREの公開手順の解説は、公開手順に軽量さと重要事項の再現可能な確認の両方を求め、公開の種類と複雑さに合わせて調整する考え方を示しています。本記事の公開判定票も、安全を保証する固定基準ではありません。今回の変更に必要な項目を選び、該当しない項目には理由を残します。

公開対象を特定する

最初に、公開候補を一つに固定します。「最新版」「さっきテストしたもの」「mainブランチ」といった表現だけでは、後から同じ対象を特定できません。

Google SREの公開工程の解説は、ソースの版、ビルド（コードから配布できる成果物を作る処理）の識別子、実際の公開内容、テストの記録を対応づけています。

一回の公開に公開IDを付け、その下に今回該当する識別子を組み合わせます。すべての識別子が必要なわけではありません。証拠から実際の公開対象まで追える組み合わせにします。

  • コミットSHAまたはタグ：コードの版を特定する
  • ビルド番号または成果物のダイジェスト（内容から計算した識別値）：作成された成果物を特定する
  • 設定の版または変更ID：コードとは別に変わる設定を特定する
  • デプロイID：どの対象環境へ何を反映したかを特定する

公開対象には、コードの版だけでなく、コードとは別に変更される設定も含めます。

項目 記録する内容
公開ID 一回の公開判断と実行をまとめるID
コードの版 コミットSHAまたはタグ
ビルド成果物の版 ビルド番号または成果物のダイジェスト
設定の版 設定の版または変更ID。秘密値は書かない
デプロイID 配信先が発行する場合に記録する
現在の正常版 問題が起きる前に動いていた版と設定。初回公開なら該当なしと理由を書く
対象環境 本番、顧客別環境など実際の配信先
利用者へ反映する範囲 全利用者、特定部門、特定顧客など
変更内容 今回有効になるコード、設定、データ変更
対象外 今回は変えず、確認対象にも含めない範囲
開始日時または開始条件 いつ、何が揃ったら始めるか
実行者と承認者 操作する人と、進める判断をする人

コード、ビルド成果物、設定のいずれかが変わったら、その前の候補に対するビルドやテスト結果を自動的に流用しません。変更後の組み合わせへ必要な確認をもう一度結び付けます。

同じ候補版の証拠を確認する

公開前に確認する証拠は、実際に公開する候補と同じ版に対応している必要があります。結果に「成功」とだけ書かれていても、対象版、実行日時、記録先が分からなければ公開候補の根拠にはできません。

証拠 確認すること
要件・受入 今回の変更が満たす条件と、受入結果が記録されている
ビルド 公開候補の成果物を作成した結果があり、成果物の版と記録先を対応づけられる
テスト 計画した確認が同じ候補版で実行され、結果と未実行項目が分かる
必要なレビュー セキュリティ、プライバシー、法務、アクセシビリティなど、変更に応じた確認が完了している
未確認事項 実行できなかった確認、仮定、残るリスク、判断する人が分かる

証拠の参照先には、自動ビルドの実行URL、記録ID、承認記録、課題、保存場所など、確認者が実物へ到達できる場所を書きます。画面の文言を転記するだけでなく、対象版と結果を一緒に確認できる記録を優先します。

テストの種類や組み合わせは、テストの種類と選び方で決めます。公開前の確認ではテストを選び直すのではなく、必要と決めたテストが、今回の公開候補で実行されたかを確認します。AIが生成・変更したコードを公開候補に含める場合は、同じ候補版のAI生成コードのレビュー記録も確認します。

本記事の判定票では、次の状態を合格として扱いません。

  • テストが未実行だが、実行予定として記録されているだけ
  • 以前の版では成功したが、公開候補では実行されていない
  • 実行対象や環境が分からない
  • 失敗した確認が除外または無効化され、理由がない
  • 未確認事項を誰が受け入れたか分からない

不足があればHOLDにし、必要な証拠と担当者を明記します。情報不足を「たぶん問題ない」で埋めないことが、公開判定票の役割です。

条件に該当する変更を確認する

設定値や外部サービス自体を変えなくても、今回の変更で既存の秘密情報を新しく読む、権限の使い方が変わる、外部APIの利用が増える場合は確認対象です。今回の変更で追加・変更するものに加え、使い方、読み書き、影響範囲が変わるものを確認します。すべての欄を無理に埋めるのではなく、完了、未完了、該当なしを区別します。該当なしには理由を書き、未確認を隠すために使いません。

設定

本番で変わる設定を、コードとは別に特定します。対象環境、設定名、変更内容、適用順、以前の正常な設定を記録します。秘密値そのものは記録しません。

Google SREの本番サービス運用ガイドは、設定の構文だけでなく、可能な範囲で意味も検証し、不正な新しい値をそのまま適用しない考え方を示しています。値が存在することだけで正しさを判断せず、許可された形式、値域、参照先、組み合わせを確認します。

以前の設定を維持することが安全でない変更もあります。その場合は、既存設定を使い続けるのではなく、公開をHOLDにする条件や別の復旧方法を決めます。

秘密情報と権限

APIキー、データベース接続情報、トークンなどの秘密情報について確認するのは、値ではなく安全に供給・更新・失効できる状態です。

OWASPのSecrets Management Cheat Sheetは、秘密情報を必要な主体だけに見せ、更新・失効可能にし、平文ログへ残さず、アクセス主体、更新方法、依存関係、漏えいなどのインシデント時の連絡先を記録するよう案内しています。

公開判定票には次を記録します。

  • 秘密情報の参照名と用途。値は書かない
  • どのサービスまたは担当者が利用するか
  • どこから安全に供給されるか
  • 漏えいまたは失効時に、誰が更新・失効するか
  • 更新で影響する依存先

権限は利用者だけでなく、デプロイ、データベース、監視に使うサービス用IDも対象です。NIST Cybersecurity Framework 2.0は、アクセス権限を方針に沿って管理し、最小権限と職務分離（承認と実行などの権限を一人に集中させない考え方）を取り入れ、見直すことを示しています。公開操作に必要な権限だけを付け、不要な管理権限を公開作業のために追加しません。

外部依存

外部API、認証サービス、決済、メール、ストレージなど、今回の変更が利用する外部依存を確認します。本記事では、次の情報を記録します。

  • 対象のサービスと利用する機能
  • 本番環境から接続できることを確認した記録
  • 接続確認に使った、実データを変えない承認済みの方法またはテスト専用の接続先
  • 利用上限、費用上限、タイムアウト等、公開を止める条件
  • 依存先が利用できない場合の挙動
  • 問題時の稼働状況ページ、問い合わせ先、連絡先

外部依存の正常性を自分のビルド結果だけで保証することはできません。公開中に確認する監視指標と、依存先が失敗したときの停止、一部機能を制限した継続、復旧の判断へつなげます。

データとスキーマ

スキーマは、テーブルや項目、関係などデータの構造です。データベースのスキーマ変更、データ変換、削除、初期投入がある場合は、アプリケーションの公開手順とデータの変更手順を分けます。

変更対象、停止条件、バックアップ、復旧、移行後の照合を一枚にする手順は、データベースを変更・移行する前に決めることで扱います。

NIST Cybersecurity Framework 2.0は、バックアップを作成するだけでなく保護、保守、テストし、復元前後の完全性を確認することを示しています。バックアップの存在と、実際に復元できることは別の確認です。

Microsoftの安全なデプロイの解説は、データベース、スキーマ、その他の状態を持つ対象では前の版へ戻す処理が複雑になり得るため、データ変更に応じた復旧手順が必要だと説明しています。

データを変える場合は、少なくとも次を決めます。

  • 移行の対象版、順序、実行者
  • 旧版と新版が同時に動く場合の互換性
  • 適用後にデータを確認する方法
  • 中止または失敗と判断する条件
  • バックアップの時点、対象、保存先と復元確認の記録
  • アプリケーションを前版へ戻した後にデータへ残る変更
  • データを戻せない場合の修正版へ進める方法

アプリケーションを前版へ戻すことと、データを元へ戻すことを同じ意味にしません。復旧方法を説明できなければ、データ変更を含む公開はHOLDにします。

監視する指標、停止、復旧を決める

監視する指標と停止条件

公開を始める前に、何を見て正常と判断し、どの状態で拡大を止めるかを決めます。公開後に都合のよい監視指標を探すのではなく、変更による利用者影響と失敗を判断できる情報を先に選びます。

項目 記録する内容
監視指標 エラー、処理結果、応答時間、重要な業務件数など、今回の判断に使う情報
閲覧先 ダッシュボード、ログ検索、レポート等の場所
正常条件 続行できる状態。利用実績が少ない時間帯も考慮する
停止条件 ロールアウトを止め、調査または復旧へ移る状態
判断者 停止するか、前の版へ戻すか、修正版へ進めるかを決められる人
実行者 停止と復旧の操作を行う人

固定のエラー率や観測時間を、すべてのサービスへ適用することはできません。通常時の値、受入条件、利用傾向、失敗した場合の影響から決めます。判断に必要な指標の閲覧先がない、または通常時の値が分からない場合は、本記事の判定票ではHOLDにします。足りない情報、確認する担当者、再判断する条件を記録します。

段階公開を使う場合

Google SREとMicrosoftの安全なデプロイの解説は、可能な場合に変更を限定範囲から段階的に反映し、各段階を監視し、想定外の挙動があれば拡大を止めて復旧へ移る方法を示しています。

段階公開ができない変更もあります。段階公開を使う場合も、固定の割合や時間をそのまま採用せず、誰へ、どの順番で、何を確認してから広げるかを書きます。

復旧方法を分ける

復旧は三つに分けます。

方法 決めること
アプリを前の版へ戻す 前の正常版へ戻す条件、手順、戻した後の確認
データを復旧する バックアップから戻すか、変換を取り消すか、残るデータをどう扱うか
修正版へ進める 問題を修正した新しい版へ進める条件、手順、確認

問題時に必ず前の版へ戻すとは決めません。とくにデータ変更では、前の版へ戻すことが適切でない場合があります。変更内容ごとに、停止後に調査する、アプリを前の版へ戻す、データを復旧する、修正版へ進める、のうちどれを選ぶか、判断者と実行者を決めます。

初回公開で前の正常版がない場合は、前の版へ戻す欄を「該当なし」とし、その理由を書きます。代わりに、サービスの利用を止める、機能を無効にする、修正して再公開する、のどれを行うか決めます。

公開判定票を書く

公開前の判断は、次の三つに分けます。これは外部規格ではなく、不足を曖昧にしないための本記事の記録形式です。

判断 意味
GO（進める） 対象、必要な証拠、環境、停止、復旧、判断者が特定され、残るリスクを承認者が把握している
HOLD（保留） 必要な証拠、環境、担当、復旧方法等が不足し、解消後に再判断する
NO-GO（見送る） 既知の阻害条件があり、今回の候補または計画では公開しない

GOは、未知の欠陥がないことや、安全であることの保証ではありません。今回決めた条件で公開へ進める、という判断です。

次の空欄を、一回の公開について埋めます。「公開対象」「候補版に対応する証拠」「公開、停止、復旧」「公開前の判断」は常に書きます。「条件に該当するとき書く項目」は、今回の変更で追加・変更するもの、または使い方、読み書き、影響範囲が変わるものを追加します。分からない項目は推測せずHOLDにし、足りない情報と担当者を書きます。

# 公開判定票

## 公開対象
- 公開ID:
- コードの版（ある場合。なければ該当なしと理由）:
- ビルド成果物の版（ある場合。なければ該当なしと理由）:
- 設定の版・変更ID（ある場合。なければ該当なしと理由。秘密値は書かない）:
- デプロイID（ある場合）:
- 現在の正常版（初回公開なら該当なしと理由）:
- 対象環境:
- 利用者へ反映する範囲:
- 開始日時または開始条件:
- 変更内容:
- 今回変えない範囲:
- 実行者:
- 承認者:

## 候補版に対応する証拠
- 要件・受入結果（証拠の参照先）:
- ビルド結果（対象の版・日時・証拠の参照先）:
- テスト結果（対象の版・日時・証拠の参照先）:
- 必要なレビュー（状態・証拠の参照先）:
- 未実行・未確認の項目と理由:
- 残るリスク:

## 条件に該当するとき書く項目
各項目を「完了・未完了・該当なし」で記録する。
該当なしの場合は理由を、完了の場合は証拠の参照先を書く。

- 設定変更（状態・理由・証拠の参照先）:
- 秘密情報と権限（状態・理由・証拠の参照先。秘密値は書かない）:
- 外部依存（状態・理由・証拠の参照先）:
- データ・スキーマ変更（状態・理由・証拠の参照先）:
- バックアップと復元確認（状態・理由・証拠の参照先）:

## 公開、停止、復旧
- 公開手順または手順書:
- 公開中に見る監視指標:
- 監視指標の閲覧先:
- 正常と判断する条件:
- 停止する条件:
- 停止を判断する人:
- 前の正常版の有無:
- アプリを前の版へ戻す条件・手順・確認:
- 前版がない場合の停止・機能無効化・再公開方法:
- データを復旧する条件・手順・確認:
- 修正版へ進める条件・手順・確認:
- 復旧後に残るデータ・設定:

## 公開前の判断
- 判断（GO・HOLD・NO-GO）:
- 判断理由と証拠:
- 未解決事項:
- 次に再判断する条件:
- 判断者:
- 判断日時:

項目を追加する場合は、変更内容または失敗影響との関係を書きます。項目を該当なしにする場合も理由を残します。チェックリストを長くすることではなく、今回の公開で判断に必要な情報を追えることが目的です。

公開直後の結果を別に記録する

公開前の計画と、公開後の実績を同じ欄へ混ぜません。計画を実績で上書きすると、何を予定し、どこで差が生じたか分からなくなります。

公開直後は、実際に反映された版、環境、利用者範囲を最初に確認します。公開操作が成功したという表示だけで終わらず、計画した監視指標と利用経路の確認結果を記録します。

# 公開後の記録

## 実際の公開
- 公開ID:
- 実際の版:
- 実際の環境・利用者範囲:
- 実行日時:
- 実行者:
- 計画との差:

## 公開直後の確認
- 実行した確認:
- 実際の結果:
- 監視指標の実結果:
- ログ・証拠の場所:
- 想定外の変化:

## 公開後の判断
- 判断（続行・停止・前の版へ戻す・修正版へ進める）:
- 判断理由:
- 判断者と日時:
- 残るリスク:
- 運用へ渡す事項:

実際の版が候補と違う、判断に必要な監視指標が見えない、停止条件へ達した、想定外のデータ変更がある場合は、拡大を止めます。止めた後にどの復旧方法を選ぶかは、公開前に決めた条件と実際の状態を照合して判断します。

AIと運用への引き渡し

AIに任せる範囲

コードを保管するリポジトリ、自動ビルドの記録、課題管理、監視結果を読めるコーディングAIは、公開候補の識別子、変更差分、ビルド・テストの記録、未記入欄を集め、公開判定票の下書きを作れます。ただし、各製品で接続先、参照できる情報、操作権限は異なります。AIに渡す実装タスクの切り方と同じく、証拠収集も一件ずつ目的と対象を限定します。

監視資料や課題管理に個人情報、顧客情報、社外秘が含まれる場合は、利用が承認されたAIと接続先だけを使い、許可されていない情報を除外またはマスキングします。読み取れる権限があることと、外部AIへ提供してよいことは同じではありません。

AIには、読み取ってよい対象と禁止操作を明示します。

# 公開判定票の下書き作成

## 目的
指定した公開候補について、公開判定票の下書きを作る。

## 読み取ってよい対象
- リポジトリと指定したソースの版:
- ビルド・テスト記録:
- 要件・受入記録:
- 指定した設定名と監視資料:

## 返答に含める内容
- 各記入内容の証拠の参照先:
- 公開候補版と証拠版の一致:
- 未確認、取得不能、矛盾する情報:
- 追加で人が判断する項目:

## 行ってはいけないこと
- 本番環境の変更、デプロイ、前の版へ戻す:
- 秘密値の取得または表示:
- 権限の追加・変更:
- 未確認項目の推測による補完:
- GO・HOLD・NO-GOの最終承認:

OpenAIのCodex権限管理ガイドでは、サンドボックスがAIエージェントに技術的に可能な操作範囲を、承認方針が承認判断を必要とする地点を制御します。これはCodex固有の仕組みですが、重要なのは、指示文に「本番操作をしない」と書くことと、ツール側で操作を制限することを分ける点です。利用するAIツールが持つ権限制御を確認し、証拠収集には読み取りだけで足りる権限を使います。

人は、公開候補と証拠の一致、秘密情報の扱い、未確認事項、停止・復旧方法、承認権限を確認します。本番操作や例外承認をAIへ自動的に委ねません。

運用へ渡す情報

公開後は、次の運用へ少なくとも以下を渡します。

  • 現在動いている版と設定
  • 見る監視指標、閲覧先、正常条件、通知の担当
  • 停止・復旧手順と判断者
  • バックアップ、復元、データ復旧の記録
  • 未解決事項と残るリスク

長期の監視、バックアップの頻度、障害時の役割と連絡方法は、次のWebサービスの最低限の運用設計で詳しく決めます。

出典