これまで、データバックアップおよび災害復旧ベンダーのほとんどは、自社製品にAI機能を直接統合していません。技術購入者は、ツールに「AI」というラベルを安易に貼っているベンダーには警戒すべきです。なぜなら、ベンダーが「あらゆる自動化はAIの一形態である」と主張し、この用語を大雑把に用いているケースがあるからです。実際にはそうではありません。
競合他社を過度に批判していると非難されないよう、IDCの災害復旧におけるAIに関するレポートを引用しておこう。「災害復旧および事業継続ソリューションにおける包括的なAIの活用はまだ初期段階にある。ただし、厳密な定義には当てはまらない場合でも、ほとんどのベンダーが何らかの技術をAIとして位置付けている」と述べている。IDCはさらに、AI搭載機能が災害復旧ツールの主要要素となるのは少なくとも2025年以降と予測している。
つまり、クラウド災害復旧戦略にAIを統合するには、単に「AI対応」を謳うツールを購入して終わりでは不十分です。しかし企業ができるのは、汎用的なAI技術を災害復旧シナリオに応用することです。
そのための基本手順は以下の通りです。
#1. AI活用事例を特定する
まず、災害復旧の文脈でAIに何を期待するかを明確にする。過去の課題から復旧作業の精度と信頼性を高めることが目的か?予算制約からコスト削減を目指すか?それとも別の目的か?
AIソリューションに何を期待するかを把握することは、実現方法を決める上で重要。
#2. AIツールまたはプラットフォームの選択
次に、想定するユースケースをサポート可能なAIツールまたはプラットフォームを選択します。一般的に、OpenAIのGPTモデルやGoogle Geminiなどのいわゆる生成AI基盤モデルは、復旧計画の分析やプレイブック生成など、AI駆動型災害復旧に関連するタスクを実行できます。これらのソリューションの利点は、事前学習済みで使いやすいことです。
とはいえ、ソフトウェア開発リソースと専門知識があれば、独自のAIモデルを構築したり、既存のオープンソースモデルをカスタマイズしたりすることも可能です(容易ではありませんが)。
#3. モデルに関連データを学習させる
使用するAIツールやプラットフォームを選んだら、ユースケースを理解するために必要なデータをモデルに学習させます。例えば、プレイブック生成が目的なら、ファイル・ディレクトリ・データベースのマッピングをモデルに提示し、復旧手順の提案を依頼できます。あるいは、バックアップデータ構造と本番システムのマッピングを投入し、復旧成功率を高めるバックアップ改善策を求められます。
機密性の高いビジネスデータをサードパーティのAIツールやプラットフォームに公開することは、プライバシーリスクを伴う可能性があることに留意してください。これを軽減するには、ユーザーデータの管理方法について厳格な保証と制御を提供するモデルを選択します。あるいは、可能であれば、ディレクトリ自体ではなくファイルディレクトリ構造などの情報を共有することで、機密情報の公開を完全に回避します。
#4. AI駆動ワークフローの訓練と更新
バックアップと復旧の要件は頻繁に変化する可能性が高いため、運用を支えるAI駆動ワークフローの更新も必要です。例えば、新しいアプリケーションやデータベースを導入した場合、変更を確実に反映させるために、更新されたプレイブックを生成したり、復旧戦略を再評価したりすることが望ましいでしょう。



