メインコンテンツへスキップ
VEGA開発からの知見
移行と継続運用

大きなシステムを移すとき、守るのは既存の振る舞い

新しいコアを作るとき、見落としやすいのが既存の設定と途中の処理です。正常な入力で一度動くことは確かめても、前回の状態を引き継げるか、定期処理が同じ版を使うかまでは分かりません。

VEGAのアーキテクチャ移行では、既存の戦略を新しいコアへ接続する作業と、運用経路を切り替える作業を分けて扱ってきました。新旧の比較、ソースの統合、配備、実際の起動について、それぞれの完了条件を定めています。

設計で決めておくこと

新旧の結果の一致に加え、配備先と実際の定期実行で使われた版を確認する。

01

既存の処理と同じ入力・設定で比べる

似た入力で同じ結果が出ても、既存の振る舞いを保った証拠としては弱い場合があります。対象時点、設定、保有や在庫、前回の状態をそろえ、既存の処理と新しい処理を比較します。

既存設定がないところを、都合のよい初期値で埋めると、動く比較を作れても移行対象を再現できません。欠けている入力は欠けたまま記録し、何をそろえれば比較できるかを明確にします。

02

一つの一致で、全体の互換性を判断しない

正常な一例が一致していても、上限付近、設定の期限切れ、対象外、取得失敗、同時処理では異なる結果になることがあります。規則をまたぐ境界と、異なる状態の組み合わせを確認します。

新旧比較に含める条件

  • 正常な入力と、候補がない入力
  • 上限の手前、上限と同じ値、上限を超える値
  • 欠損、矛盾、古い入力
  • 前回の状態がある場合と、初回の場合
  • 同じイベントの再受信と、途中での再起動
  • 利用者や口座、設定の版が異なる場合

03

コードが入った後、実際の経路を確かめる

ソースが統合されたこと、対象環境へ配備されたこと、設定が読み込まれたこと、登録された定期処理が実際に起動したことは別の出来事です。手動で成功した処理が、定期実行でも同じ環境を使うとは限りません。

表は横にスクロールして確認できます。

移行を確認する段階
段階確認すること
実装・統合対象の版が、必要な契約とローカル検証を満たす
配備対象環境に、確認した版と設定が存在する
実際の起動登録された経路が、その版と設定で動いた
業務の結果入力から記録・レポートまで、その実行に対応している
継続・復旧停止、再起動、次の実行でも制約が保たれる

04

移行の完了条件と、利用の許可を分ける

互換性が確認できても、新しい顧客や本番の外部操作を許可したことにはなりません。移行した対象、確認した環境、残る制約、運用の権限を記録します。

引き継ぎには、現在の版、完了した段階、未完了の確認、次に開始する場所を残します。例えば「配備済み、定期起動は未確認」なら、次の担当者が確認すべき箇所を特定できます。「対応済み」だけでは、その区別がつきません。

マルチユーザー設計

AIの共通基盤で、顧客ごとの状態をどう分けるか

同じAIを使う顧客でも、許可された操作や処理中の記録はそれぞれ異なります。設定、再試行、キャッシュ、日次レポートに他の顧客の情報が混ざらないかを確かめます。

読む →
AI開発と独立レビュー

AI同士のレビューを、根拠のある改善につなげる

Claude CodeとCodexに実装とレビューを分担させるとき、何を確かめるか。再現できる失敗、対象のコミット、修正後の確認をそろえ、指摘を採用する基準を定めます。

読む →
復旧と信頼性

タイムアウトの後、再送する前に確かめること

応答がなくても、相手側では処理が完了しているかもしれません。送り直してよいかを判断するために、送信前の記録と相手側の照会を使い、再起動後にも照合できるようにします。

読む →

自社の業務でAIを使うには

対象の業務と使えるデータを確認し、AIに任せる処理、人が判断する場面、停止後の対応を決めます。設計から実装、検証までご相談ください。