リテインは、クラウド移行の対象をすぐに移さず、現行環境に残しておく判断や移行戦略です。移行効果が小さい場合や技術的・法的な制約がある場合は、今移す合理性が低いこともあるため、要件や費用が変わるまで保留します。なお、手法名を決める前に、誰のどの意思決定を支援するかを定めておきます。
AI駆動開発の基本や工程ごとの活用方法、費用・期間への影響については、無料ホワイトペーパー「【2026年最新版】AI駆動開発の完全ガイドブック」で詳しく解説しています。
▼開発を相談する前に読みたい無料ホワイトペーパー
・【2026年最新版】AI駆動開発の完全ガイドブック
リテインの定義と役割
リテインでは、クラウド移行をいったん保留し、対象を現行環境で維持します。要件や費用が変わった段階で、移行を検討します。
定義を実務に落とすときは、入力、処理、出力、仮定を分けて記録します。あわせて、対象範囲と前提を明確にすると、評価の条件をそろえられます。
入力に将来の情報が混ざったり、対象範囲が変わったりすると、検証時だけ有利な結果になることがあります。
データの発生時点と評価時点をそろえ、除外条件と欠測の扱いも事前に決めておきます。
結果が良く見えても、これらの前提が異なると適切な評価にならない場合があります。
リテインの仕組み｜計算と判断の流れ
1. 目的とデータ単位の定義
目的とデータ単位を先に定めておくと、後から条件を変えずに評価を再現できます。この段階では、業務上の判断材料や保留理由、対象外の扱いも決めておきます。
- 目的とデータ単位：意思決定の狙いと評価値の意味を定めます。観測単位、対象期間、利用できる変数も決めます。
- 業務上の判断材料：業務の重要度や依存、規制を押さえます。改修費や残存期間、運用リスクも確認します。移行優先度と再評価時期も定義します。
- 保留理由：判断の根拠を書き残し、先送りのまま放置されるのを防ぎます。
- 対象外の処理：結果を見てから都合よく除外することを避け、除外した件数と理由をログに残します。
2. 候補設定の学習と推定
候補となる設定やモデルを複数用意し、訓練、検証、最終評価の役割を分けます。そのうえで、前処理や変数選択は全データへ先に適用するのを避け、再現できるパイプラインとして保存します。
乱数やライブラリのバージョン、設定値、入力データのスナップショットを記録しておけば、同じ条件で再実行できます。
3. 結果を判断に使える形への変換
判断する人には、スコアのほかにも情報が必要なため、結果と根拠の見せ方を整えておきます。
- 業務で判断できる出力：スコアや係数を、残存システム数や維持費などの、現場で意味が分かる単位に結びつけます。
- 確認する指標：障害や技術負債、再評価日を見ます。移行候補化や運用工数、リスクも含めます。
- 不確実性と対象範囲：点推定の値だけでなく、ばらつきや対象外の条件も併記します。
- 反証と限界：判断を覆す反証も含め、利用者がどこまで使えるかを確認できるようにします。
リテインの使い方｜実務での適用場面
小さな検証の進め方
リテインを選ぶ前に、対象の条件と、検証結果を採否につなげる観点をそろえておきます。
- 保留を検討する状況：移行効果が小さい、または技術的・法的制約がある場合は、今移す合理性が低いことがあります。
- 廃止予定：近く使われなくなるシステムも対象になり得ます。
- 小さな検証：代表的なデータと明確な成功条件に絞って、基準手法との差分を測ります。
- 採用判断：短期の指標だけで決めず、運用負荷、説明可能性、更新頻度、例外処理も含めて見極めます。
- 再評価：定期的に採用の可否を見直します。
評価期間と利用者のそろえ方
未来の情報を使えない業務では、時系列でデータを分割します。
同じ顧客や案件が繰り返し現れる場合は、グループ単位で分割します。
読む人が結果の意味を誤解しないよう、レポートには指標の単位と分母を書きます。対象範囲と信頼区間も併記します。
本番運用への移行
本番では、入力の欠損率や分布を監視します。あわせて、結果の品質や処理時間、エラー率も見ます。
悪化時の再学習・再推定の条件、承認者、ロールバック先を、あらかじめ決めておきます。
検証時と同じ集計ができるログも残しておきます。
リテインと関連手法の違い
クラウド移行で検討する手法は、対象を維持するか、廃止するか、移設・再設計するかで区別できます。リテインは、このうち対象を現行環境に残す手法です。
- リテイン：現行環境での維持
- リタイア：対象の廃止
- リホスト：対象の移設
- リファクタリング：対象の再設計
保留と先送りは区別する必要があります。
発注側は、リテインの理由と再評価の条件を定め、ただ放置しないようにします。
比較するときは、データ分割、目的、評価期間をそろえ、前処理や計算予算も同じにします。
手法ごとに答えられる問いが違う場合は、単純な順位付けを避けます。
精度や安定性、費用を並べた判断表を作ります。説明や保守性も、同じ表に入れます。そのうえで、各手法の違いを踏まえて選べます。
リテインの評価方法｜数字以外も含めた判断
主要指標と不確実性
評価では、残存システム数や維持費を確認します。あわせて、障害や技術負債、再評価日も見ます。
移行候補化、運用工数、リスクも判断材料になります。
診断と再現性
集計方法によって見え方が変わるため、結果は平均値だけでなく、期間別やグループ別、極端なケースでも確認します。
設定を変えた感度分析、別データでの確認、複数シードでの再実験を行います。
結論が一つの偶然に依存していないかを、実験の結果から点検します。
リテインで起きやすい失敗と対策
データと前処理の問題
評価が楽観的になりやすい操作を把握し、前処理や対象の選定に注意します。
- 全データでの前処理：集計・標準化・補完を済ませてから分割すると、性能や推定が楽観的な値になります。
- 未来の情報：将来の値を入力に含めると、性能や推定が実際より良く見えます。
- 評価対象の選定：結果を見てから対象を選ぶと、評価が楽観的になります。
前処理は学習側に限定し、処理の前後で件数と値域を監査します。
指標と問いの混同
運用上の管理不足は、指標の読み違いと並んで判断を誤らせる原因になります。理由と再評価から問いと前提まで、取り違えやすい点を順に見ていきます。
- 理由と再評価：判断の根拠を残し、見直しを行います。
- 環境と契約：古い基盤の脆弱性や、契約期限の見落としに注意します。
- 担当者への依存：特定の担当者しか分からない状態を避けます。
- 指標の解釈：数値が改善しても、業務成果や因果効果を示すとは限りません。
- 問いと前提：分析の目的と意思決定者の知りたいことを並べ、不足する仮定やデータを示して、結果だけで決められるという誤解を防ぎます。
運用条件の変化の見落とし
制度や価格、顧客構成は変わります。季節性や計測方法も変わります。そのため、運用時にも当初の条件が続くとは限りません。
入力の分布や欠測を監視します。結果の品質や主要グループの差も見ておきます。
再評価のきっかけも事前に決めておきます。
リテインを採用する判断基準
リテインを採用するのは、現時点で移行の費用対効果が合わない明確な理由があり、維持と再評価を管理できる場合です。
一方、採用しない場合は、基準手法、見送った理由、次に必要なデータを記録しておきます。記録が残っていれば、将来の再検討に役立ちます。
説明資料には、数式やアルゴリズムに加えて、仮定と分からない範囲を示します。
成功例と合わせて、失敗例も残します。
結果を利用する人が反証条件や適用範囲を確認できるようにします。そのため、判断の前提を共有できます。
リテインまとめ｜目的・前提・評価のそろえ方
リテインを選ぶと、対象システムは現行環境に残ります。そのうえで、要件や費用の変化を待ち、移行を再検討します。
価値を出すには、まず対象と時間を定めます。入力、出力、仮定も定義します。
また、基準手法と同じ条件で評価することも欠かせません。
小さく検証してから適用範囲を広げ、設定、データ、評価結果を再現できる形で保存します。
判断では、精度や有意性だけでなく、誤りのコストや説明可能性も含めます。運用負荷や公平性も判断材料にします。
よくある質問（FAQ）
Q. リテインとは何ですか？
リテインは、クラウド移行の対象をすぐには移さず、現行環境に残す判断や移行戦略です。要件や費用が変わるまで保留します。
Q. リテインはどのような場面で使いますか？
移行効果や制約を踏まえて、当面は既存環境を維持すると判断したときに使います。
Q. リテインを使うときの評価指標は何ですか？
残存システム数や維持費、障害を確認します。技術負債や再評価日、移行候補化も見ます。また、運用工数やリスクも判断に含めます。
Q. リテインで起きやすい失敗は何ですか？
理由や再評価の不足に注意します。
脆弱性の放置や、担当者への依存、契約期限の見落としにも気をつけます。
Q. リテインと似た手法はどう使い分けますか？
リテインは現行維持、リタイアは廃止、リホストは移設、リファクタリングは再設計です。
参考資料
本記事の定義と実務上の注意は、次の公式資料を参照しています。
https://aws.amazon.com/cloud-migration/、https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/migrate/prepare。仕様や前提は更新されるため、実装時は利用するバージョンの公式ドキュメントも確認してください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。