データベースを変更・移行する前に決めること

データベースを変更する作業は、AIへ「移行して」と頼んだだけでは始められません。既存データの意味、守るべき情報、停止できる時間、契約上の条件、失敗時の判断者は、コードやテーブル定義だけからは確定できないためです。

本稿でいう「データベース変更・移行」には、データベースの列や、値や関係の規則を表す制約などの構造を変える作業、既存データの値を変換する作業、別のデータベースや事業者へ移す作業を含めます。構造を表す定義はスキーマ、既存データを新しい状態へ移す一連の処理はマイグレーションとも呼ばれます。

最初に、次の三つから状態を選びます。

進めない：目的に対して移行が不要、またはデータ消失や停止などの影響を受け入れられない
準備を続ける（本番は保留）：未確認事項があり、確認する人と再開条件を決める。調査や準備は続けても、本番作業は始めない
進める：対象、合格条件、停止・復旧方法、実行する人と承認する人が確定している

これは外部規格の正式な承認状態ではなく、この記事で使う記録方法です。重要な欄が空白なら、空白を同意とみなさず「未確認」と記録し、「準備を続ける（本番は保留）」にします。判断票を埋めたこと自体も、本番作業の許可にはなりません。

変更・移行が必要かを最初に分ける

データベースを後回しにして機能を作ると、後から列の追加や型の変更、データの分割・統合、保存先の切替えが必要になることがあります。ただし、要望が出たからといって、必ず既存データを変える必要があるわけではありません。

次の五問に答えます。

何を実現したいのか。現在のどの不具合や制約を解消するのか
アプリ側の表示や計算だけを変え、既存データを変えずに済ませられないか
既存の値を変換しないと、新しい機能や保存先で正しく扱えないか
正式な保存先を別のデータベースへ切り替えるのか。一時的な複製を作るだけなのか
変更をしない場合と、変更に失敗した場合では、どちらの影響を受け入れられるか

変更の種類も分けます。複数に該当する場合は、一つの「移行」という作業名へまとめず、段階と担当を分けます。

変更の種類	確認する中心
スキーマだけを変える	列・型・制約・索引（検索を速くする仕組み）、ロック（処理中にほかの操作を待たせる仕組み）、既存アプリとの互換性（旧版と新版を同じ期間に使えるか）
既存データを変換する	変換規則、欠損・重複、再実行、変換前後の照合
別データベース・別事業者へ移す	コピー、同期、切替え、接続先、契約、容量、費用
アプリとデータベースを同時に変える	旧版・新版が読める形、公開順序、切替え後の書込み

現行の論理データモデルを整理する段階なら、先にデータベース設計のためのER図を使います。候補のデータベースや事業者を比較する段階は技術選定の進め方の範囲です。この記事は、変更対象が具体化した後の実行判定を扱います。

起こり得る問題を確認項目へ変える

「危険そう」で止めず、何を観測し、どの状態なら作業を止めるかへ変換します。

起こり得る問題	事前に決める確認
データの消失・破損・重複・誤った相手への対応付け	対象件数だけでなく、主キー（各行を区別する識別子）、対応関係、重要な値、変換前後の差分をどう比べるか
親データのない子データなど参照関係の破損	どの参照が必ず成立すべきか、孤立データをどう検出するか
文字化け、時刻のずれ、数値の桁あふれ、丸め	文字コード、照合順序（文字の比較・並べ方の規則）、タイムゾーン、型、最大・最小値、NULL（値が入っていない状態）をどのデータで試すか
個人・顧客・秘密データの露出	AIへの入力（プロンプト）、ログ、一時領域、書き出しファイル（エクスポート）、バックアップの保存先、閲覧者、保持、削除をどう制限するか
移行用アカウントの権限過大	読取り、作成、更新、削除、権限変更を分け、今回必要な操作だけにしたか
テーブルのロック、長時間処理、サービス停止	対象版の公式資料、実行計画、長時間トランザクション（複数のデータベース操作を一まとまりに扱う処理）、所要時間、負荷、停止できる時間帯をどう確認するか
一部だけ移行された状態	完了単位、再開位置、二重実行時の扱い、途中状態を旧版・新版が読めるか
旧版と新版の非互換	どの期間にどちらが読取り・書込みできるか、古い列をいつ消せるか
二重書込みや再実行による重複	同じ処理を繰り返しても重複しない条件、片方だけ成功した場合の検出・修復
一時保存（キャッシュ）、検索用索引、処理を伝える通知（イベント）、外部連携の不一致	再構築・再送・照合の対象、順序、完了確認、担当
ロールバック不能、復元未確認	アプリを前版へ戻す手順（ロールバック）とデータを復元する手順、失われる書込み、壊れた部分を直して新しい状態へ進める方法（ロールフォワード）
容量不足や想定外の費用	元データ、複製、索引、一時領域、ログ、バックアップ、転送の最大見込みと警告条件

すべてを同じ重さで扱う必要はありません。対象外と判断した項目にも、理由と判断者を残します。

対象と守る条件を固定する

AIは、見えているスキーマや一部のサンプルから、全データの実態と業務上の意味を確定できません。まず人が、読取り中心の調査で現在地を固定します。本番データの値を一覧へ転記するのではなく、正式な管理画面やアクセス制限された調査結果への参照を残します。

対象と責任を分ける

同じ人が複数を担っても構いませんが、役割は分けて記録します。

データの責任者：データの意味、利用目的、正しさ、保持・削除条件を判断する
サービスの責任者：停止の業務影響、利用者への連絡、再開を判断する
移行の実行者：承認済み手順を実行し、証拠を記録する
セキュリティ・法務・契約の確認先：個人情報、顧客情報、委託、越境、保持、報告等を確認する
最終承認者：残るリスクを確認し、「進める」または「準備を続ける（本番は保留）」を決める

誰がどこまで書くかを分ける

判断票を一人で完成させる必要はありません。最初の担当者は、目的、影響、分かっている対象、未確認事項、確認先を記録します。技術的な値や契約条件を推測で埋めず、決められる人へ欄ごと渡します。

記録・確認する人	担当する内容
最初の担当者	目的、困っていること、利用者への影響、分かっている対象、未確認事項
データの責任者	データの意味、守る条件、保持・削除条件、合格条件
サービスの責任者	停止の業務影響、停止できる時間、利用者への連絡、再開条件
移行の実行者	承認済み手順の実行、監視、証拠の記録
セキュリティ・法務・契約の確認先	機微性、利用目的、委託・越境、保持・削除、契約条件
データベース担当者または事業者	対象版のロック、所要時間、互換性、容量、実行・復元方法と技術的な証拠
最終承認者	未確認事項と残るリスク、本番開始の可否

必要な責任者や最終承認者がいない、機微性や契約条件を確認できない、復元試験の証拠がない、停止の許容範囲や停止条件を決められない場合は、「準備を続ける（本番は保留）」を選びます。確認する人と期限、再開条件を記録し、組織内の権限者、契約先の事業者、または組織が依頼した専門家へ渡します。確認できるまで本番作業は始めません。

現在の状態を記録する

少なくとも次を、確認日と確認元つきで記録します。

データベース製品、事業者、データベースの種類（エンジン）とバージョン、本番・検証などの環境
データの正式な保存先、対象スキーマ・テーブル・列、主キーと参照関係
行数、データ量、増加量、最大値・最小値・NULL・重複・古い形式の分布
文字コード、照合順序（文字の比較・並べ方の規則）、タイムゾーン、数値・日時の型
索引（検索を速くする仕組み）、制約（不正な値や関係を防ぐ規則）、トリガー（特定操作に応じてデータベースが実行する処理）、データベース内に保存した処理（ストアド処理）、拡張機能など変更へ関係する仕組み
接続するアプリの版、定期処理、帳票、分析、キャッシュ、検索、イベント、外部連携
通常時と繁忙時の負荷、長時間トランザクション、空き容量、費用の確認元
バックアップの対象、取得時点、暗号化、アクセス、保持、復元手順の参照先

移行ツールに事前評価機能があれば、既知の非対応を探す補助にできます。たとえばAWS DMSの事前評価は、対応オブジェクト、索引設定、データ型、主キー形式などを確認します。この確認範囲はAWS DMSに限られ、合格表示だけではデータの業務上の意味や最終承認は確定できません。

機微性と保管場所を確認する

個人情報、顧客データ、認証情報、契約上の秘密、社内限定情報を分類します。生の値を判断票へ書かず、分類、管理元、閲覧できる役割、利用目的、保持・削除条件、確認先を書きます。

OWASPのログ指針は、アクセストークン、パスワード、データベース接続文字列、暗号鍵、機微な個人データなどを通常はログへ直接残さないよう示しています。必要に応じて、削除、一部を隠す処理（マスク）、元の値を推測しにくい値への変換（ハッシュ化）、暗号化等で保護します。この説明はログに限られます。一時ファイル、エクスポート、バックアップにも同じ値が複製される可能性を調べ、それぞれの保存先と削除確認を別に記録します。

業務上壊してはいけない条件を決める

合格条件は「変更用の命令（SQL）が成功した」「行数が同じ」だけにしません。変更後も必ず成り立つ業務上の条件を、確認方法と許容差つきで定めます。ここでは、業務上壊してはいけない条件をビジネス不変条件と呼びます。

対象業務について、次の観点から空欄を埋めます。

存在：必ず残るべき顧客、注文、権利、残高、履歴は何か
対応：どの利用者と契約、注文と明細、親と子が結び付くべきか
一意性と順序：重複してはいけない識別子、前後関係を守る日時は何か
計算結果：件数、合計、状態別内訳など、移行前後で一致または説明可能であるべき値は何か
外部の状態：検索結果、キャッシュ、通知、イベント、会計・決済・分析等で一致すべきものは何か

各条件に、確認用の読取り処理、期待値、許容差、失敗時の停止条件、判断者を付けます。要件を観測可能な条件へ変える方法は要件と受入条件を参照します。

方式、互換期間、停止を決める

方式は「止めないこと」から逆算せず、データを守り、失敗を検出し、サービスを復旧できることから選びます。

方式	向く状況	追加で確認すること
書込みを止めて一度に変更する	変更中の書込みを安全に取り込めず、業務上、停止を受け入れられる	停止できる時間帯、開始時点、再開条件、超過時の連絡
旧形式と新形式を一定期間共存させる	アプリとデータを段階的に切り替える	旧版・新版の読取りと書込み、変換の順序、古い形式を消す条件
コピーと変更同期後に接続先を切り替える	別データベース・別事業者へ移し、同期手段を使える	同期遅延、切替え時の書込み、再接続、元データベースへ戻る条件
小さな単位に分けて変換する	一括処理が長く、再開位置を管理できる	完了単位、再実行、部分完了を読める版、全体照合

旧形式と新形式を共存させる場合は、新しい列や保存先を追加し、既存データを変換し、読取り先を切り替え、十分に確認してから古いものを削除します。追加、変換、切替え、削除を一回の不可分な作業だと仮定しません。二重書込みを使う場合は、片方だけ成功した状態と再実行時の重複をどう検出・修復するかが決まるまで採用しません。

製品名の「オンライン」も無停止の保証ではありません。MySQL 8.4 InnoDBのOnline DDL（データベースを使いながら構造を変える機能の名称）でも、定義の確定時に排他的なメタデータロック（テーブル定義の確定中、ほかの操作を待たせる仕組み）が必要です。そのため、長時間トランザクションを待ったり、待機中の要求が後続処理を止めたりする場合があります。

MySQL 8.4の暗黙的コミットでは、ALTER TABLEなど、資料に列挙された構造定義命令（DDL）が、明示的な指示がなくても実行前にそれまでの変更を確定します。確認した範囲はMySQL 8.4です。

PostgreSQL 18のALTER TABLEも、操作ごとにロック、既存データの走査、テーブルの書換え、索引再構築の有無が異なります。大きなテーブルや索引の再構築は長時間化し、一時的な追加ディスク領域が必要になり得ます。ここで挙げた挙動はPostgreSQL 18で確認したものなので、別製品や別操作は対象の公式資料で確認します。

別データベースへ移す方式もツールごとに異なります。Google Cloud Database Migration Serviceの概要では、継続移行は停止を最小化する方式として説明される一方、1回だけ実行する移行では移行中に元データベースへの新規書込みができず、依存アプリが停止を経験し得ます。同サービスは元データベースと移行先への二重書込みを支援しません。これはGoogle Cloud DMSでの挙動です。継続移行を選んでも停止がゼロになるとは限りません。

安全な確認と復旧のために保守時間帯を設ける方が妥当な場合があります。停止時間、復旧時間、失ってよいデータ時点、保持期間は、サービスの影響、契約、法令、運用能力から決めます。すべてのサービスに共通する値は置きません。平常時のバックアップや、復旧までに許容する時間・失ってよいデータ時点（RTO・RPO）はWebサービスの最低限の運用設計へ分けます。

リハーサルと復元試験を行う

本番前に、本番と同じ手順を安全な環境で通します。実在する人や顧客の生データはAIへ渡さず、組織の担当者が安全性を確認した生成データを優先します。実際に起こり得る境界値や例外も含めます。

個人情報保護委員会の仮名加工情報・匿名加工情報ガイドラインでは、氏名を削除・置換しても、住所や生年月日等との組合せから個人を識別できる場合があると示しています。日本の個人情報取扱事業者等を対象とするガイドラインです。「名前を消した」だけで安全と判断せず、個別データが法令上の仮名加工情報・匿名加工情報に当たるかは担当者へ確認します。

代表性は平均的な値だけでは足りません。次を対象に応じて含めます。

NULL、空文字、最大長、古い形式、重複候補
最大・最小の数値、丸め境界、桁あふれ候補
日付境界、夏時間やタイムゾーンの違い、過去・未来日時
多言語文字、絵文字、結合文字、異なる文字コード由来の値
親子関係、複数段の参照、削除済み・休止中の状態
処理途中で停止した状態と、同じ手順を再実行した状態

AWSの移行前カットオーバー指針は、切替え前のリハーサルと不測事態への備えを勧めています。計画には、必要な停止と超過時の業務影響、ロールフォワード・ロールバック、依存先、機能・性能・連携試験、作業時間・順序・担当を含めます。これはAWSワークロードの移行指針なので、停止時間や文書形式は対象サービスに合わせて決めます。

リハーサルでは、成功・失敗だけでなく次を記録します。

固定した手順・コード・設定・データベースバージョン
開始・終了時刻、段階ごとの実測時間、行数とデータ量
ロック待ち、遅い処理、CPU・メモリ・ディスク・ネットワークの変化
元データ、複製、索引、一時領域、ログ、バックアップを含む最大使用容量
再実行したときの重複、欠損、再開位置
合格条件と停止条件を確認した読取り結果
本番との差と、その差が結果へ与える影響

バックアップを実際に復元する

バックアップの成功表示と、必要な状態へ戻せることは別です。NIST CSF 2.0は、バックアップの保護・保守・試験と、復元前後のデータ完全性確認を成果として示しています。NIST CSF 2.0は米国の任意フレームワークです。取得頻度や保持世代は、対象サービスの条件から別に決めます。

今回の移行では、次を対応付けます。

バックアップが対象にするアプリ版、データベース版、スキーマ版
バックアップが表すデータ時点と、その後の書込みをどう扱うか
暗号化、アクセスできる人、保管場所、保持・削除条件
空の安全な環境へ復元する手順と必要な権限
復元後にスキーマ、件数、参照、重要値、アプリ動作を確認する方法
実測した復元・検証時間と、サービス側が許容する時間・データ損失との比較

本番変更前のバックアップだけでなく、どの時点の状態を復旧目標にするかを固定します。復元試験を行っていない場合は「復元可能」と書きません。

停止条件と復旧方法を決める

停止条件は「問題があれば止める」では実行できません。観測対象、閾値、判断者、停止操作、停止後の安全な状態を一組にします。

項目	決めること
観測	エラー率、未処理件数、同期遅延、ロック待ち、処理時間、容量、重要な照合値
停止条件	どの状態・継続時間・件数で、新たな処理の開始を止めるか、実行中処理を止めるか
判断者	自動停止できる範囲、人が判断する範囲、連絡不能時の扱い
停止操作	接続、書込み、移行処理、公開処理をどの順で止めるか
復旧	ロールバックかロールフォワードか、対象版、対象データ時点、失われ得る書込み
再開	どの照合と承認が終われば利用を再開できるか
連絡	利用者、業務責任者、運用、セキュリティ、事業者へ誰が何を伝えるか

アプリを前の版へ戻しても、新しい形式へ変換済みのデータが旧版で読めるとは限りません。逆に、切替え後の新規書込みがある状態で古いバックアップへ戻すと、その書込みを失う可能性があります。

Microsoft Azure Well-Architectedの安全なデプロイ指針も、データベース、スキーマ、状態を変える公開では、アプリを前版へ戻す手順とデータ復旧を分けています。変更に応じ、ロールバックまたはロールフォワードを用意します。これはAzure向けの運用指針です。逆向きの移行を一律に求めるのではなく、変更に応じた復旧方法を選びます。

ロールバックすると切替え後データを失う、または逆変換が安全でない場合は、壊れた部分を直して新しい状態へ進めるロールフォワードを選ぶことがあります。どちらが安全かは、リハーサルの証拠、切替え後の書込み、停止影響、復元時間から人が決めます。

移行後に照合して片づける

移行処理が終了しても、完了ではありません。移行前に固定したデータ時点と対象版に対して、次を照合します。

対象テーブル・区分ごとの件数、欠損、余分な行、重複
元の識別子と移行先の識別子の対応、誤った相手への結付け
主キー、一意性、親子参照、必須値、状態遷移
文字、日時、数値、NULL、丸め、最大・最小値
業務上重要な合計・内訳と、差がある場合の説明
アプリの読取り・書込み、定期処理、帳票、権限
キャッシュ、検索索引、イベント、通知、分析、外部連携
エラー、未処理、同期遅延、容量、費用、性能の変化

AWS DMSのデータ検証は、元と移行先の対応する行・値を比較して不一致を報告できます。一方で、追加の時間と元・移行先・ネットワークの負荷がかかり、主キー、データ型、同時更新等に制約があります。これはAWS DMSでの検証です。ツールの「検証済み」表示だけでは、業務上の意味やキャッシュ、検索、イベント、外部連携の整合まで証明できません。

照合が終わったら、互換期間を終了できるかを別に判断します。古い列やテーブル、元データベース、同期処理、二重書込み、移行用アカウント、権限、一時ファイル、エクスポート、ログ、バックアップを、保持・監査・契約条件に従って削除または無効化します。削除前に必要な証拠と承認を残し、削除した事実も確認します。

AIに任せることと人が行うこと

AIは判断材料の整理を助けられますが、データの責任者や本番の承認者にはなりません。

AIへ依頼できる範囲	人が確認・実行する範囲
読取り専用の棚卸し項目案	読取り権限の付与、対象範囲、出力に機微データがないこと
スキーマ、SQL、変換処理、手順の下書き	対象版の公式資料、全差分、実行計画、合格・停止条件
リスクやチェックリストの不足確認	業務上の意味、データ分類、契約・保持、停止許容、責任者
安全なテストデータの条件案	実データを使わないこと、代表性と安全性の確認
読取り用の照合SQL案	本番接続、書込み、削除、権限変更、実行結果の採用

OWASPのAIコーディング指針は、AIツールが開いているファイル、プロジェクト構造、端末出力等を提供者へ送る場合があると説明しています。そのため、送信範囲を確認し、機微なファイルを除外します。AI生成変更には、人の責任者、レビュー、明示的な承認、監査記録も必要です。OWASPのコミュニティ指針であり、製品ごとの送信・保持条件や法的責任を確定するものではありません。

日本の個人情報取扱事業者について、個人情報保護委員会の注意喚起は、生成AIへの個人情報の入力が特定した利用目的の達成に必要な範囲かを確認するよう示しています。本人同意なく個人データを入力する場合は、提供者が応答生成以外へ利用するか、機械学習へ使うかも確認対象です。個別案件の適法性は、利用目的、契約、設定、データの流れを確認して判断します。

IPAの中小企業向け情報セキュリティ対策ガイドラインは、漏えいすると問題になる機密性の高い情報や個人情報を生成AIへ入力しないよう求めています。保守的な安全指針であり、すべての法人向けAI環境で全情報の入力を法的に一律禁止するという意味ではありません。

この記事では、実データと、接続文字列、パスワード、トークン、暗号鍵等の資格情報・秘密値をAIへ渡さないことを安全境界にします。これはPPCやIPAが、あらゆる本番データのAI入力を法的に一律禁止するという意味ではありません。

移行用アカウントとAIのツール接続は、NIST CSF 2.0が示す最小権限の考え方を使い、今回必要な読取りと下書きに限定します。削除、本番書込み、権限拡張、機微データ送信、最終承認は、権限のある人が明示的に承認し、承認済みの手順と制御されたツールで実行します。

データベース変更・移行判断票

空欄を推測で埋めません。未確認なら、確認する人、期限、再開条件を添えて本番作業を保留します。

1. 変更の識別

項目	記入欄
変更名・管理番号
目的と解消する問題
変更しない場合の影響
データを変えない代替案と採否理由
変更の種類（スキーマ／変換／データベース・事業者移行／複合）
対象環境・アプリ版・データベース製品／事業者／エンジン／版
データベース情報の確認日・確認元
対象スキーマ・テーブル・データ時点

2. 責任とデータ保護

項目	記入欄
データの責任者と判断範囲
サービス停止・再開の判断者
実行者・監視者・最終承認者
セキュリティ・法務・契約の確認先
個人・顧客・秘密データの分類
利用目的、契約、保持・削除、保管場所
移行用アカウントと必要最小限の権限
AIへ渡す情報・渡さない情報・利用条件

3. 現状と合格条件

項目	記入欄	確認日・確認元
行数・容量・増加量・負荷・空き容量
主キー・参照・索引・制約・トリガー等
文字コード・照合順序・時刻・数値型
接続アプリ・定期処理・外部依存
ビジネス不変条件
照合方法、期待値、許容差
対象外とした項目・理由・判断者

合格条件の記録

条件ごとに行を追加し、確認方法との対応を崩さないようにします。

ビジネス不変条件	確認方法	期待値・許容差	停止条件	判断者	証拠の参照先

4. 方式とリハーサル

項目	記入欄
移行方式と選定理由
旧版・新版の読取り／書込み互換期間
二重書込み・再実行・部分完了の扱い
停止の要否、保守時間帯、超過時の影響
リハーサル用データの安全性と代表性
実測時間・ロック・負荷・最大容量・費用見込み
リハーサル結果と本番との差

5. バックアップ、停止、復旧

項目	記入欄
バックアップの対象版・データ時点・保管条件
復元試験の環境・結果・実測時間・証拠
観測項目と停止条件
停止を判断する人と停止操作
ロールバックまたはロールフォワードの理由
復旧先のアプリ版・データベース版・データ時点
切替え後の書込みと失われ得るデータ
連絡先・連絡内容・再開条件

6. 移行後と承認

項目	記入欄
件数・欠損・重複・対応・参照・重要値の照合
キャッシュ・検索・イベント・外部連携の照合
監視期間と終了条件
旧データベース・旧列・同期・権限・一時物の片づけ
未確認事項、確認者、期限、再開条件
最終判断（進めない／準備を続ける（本番は保留）／進める）
判断者・判断日時・根拠となる証拠

7. 未確認事項の追跡

同じ種類の未確認事項が複数あれば、行を追加します。

未確認事項	確認先	期限	本番を再開できる条件	証拠の参照先

完了チェックリスト

各項目には証拠の参照先を残します。チェックした行の末尾か直後へ「証拠の参照先：＿＿／確認者：＿＿／確認日時：＿＿」を追記します。対象外なら、チェックを付ける代わりに理由と判断者を判断票へ記録します。

本番開始前

実行中

承認済みの対象版・手順・順序から外れていない
エラー、未処理、同期遅延、ロック、時間、容量、判断票で定めた合格条件の確認値を監視している
部分完了と再開位置を記録している
停止条件に達した場合、新規処理を増やさず承認済みの停止手順へ移った
判断と連絡の時刻、実行者、結果、変更した範囲を記録した

移行後

件数だけでなく欠損、重複、対応、参照、文字・時刻・数値、重要値を照合した
アプリ、定期処理、権限、キャッシュ、検索、イベント、外部連携を照合した
エラー、性能、容量、費用、同期遅延を決めた期間にわたって監視した
未一致を修復し、再照合の証拠を残した
互換期間を終了してよいか、人が判断した
保持条件に従い、旧データベース・旧列・同期処理・過大権限・一時ファイル・エクスポートを片づけた
バックアップ、ログ、証拠の保護・保持・削除条件を確認した
利用再開と移行完了を、権限のある人が承認した

1回のリリース全体の判定はサービス公開前の確認へ渡します。判断票とチェックリストが完成しても、データ消失や停止が起きないこと、決めた時間内に必ず完了することは保証しません。対象版の証拠と未確認事項を更新し、条件が変われば再度、本番作業を保留します。