社長AIブログ 第8回 | AIにAzureへのシステム移行までやらせてみた

この記事の4行要約
- AI活用は新規開発だけでなく、既存システムのAzure移行のような「止められない」プロジェクトにも広がっています
- 現行調査・構成設計・移行チェックリスト・移行手順書・失敗パターンの洗い出しなど、移行の各フェーズでAIが実務レベルで機能します
- ただしAIは最終的な意思決定や責任を負えないため、何をAIに任せ、何を人間が判断・保証するかの線引きが重要になります
- 本記事では、Azureへのシステム移行にAIを深く関与させた実体験と、そこから見えてきたAI時代の判断のあり方を紹介します
小山 才喜こやま さいき
得意領域
元マイクロソフトの技術営業、ジョルダン社での事業立ち上げを経て独立、起業13年目の生涯現役社長
など著書多数
保有資格
Microsoft 認定資格(MCP)を30以上保持したタイトルホルダー
ここまでこのブログでは、
AIに、
設計させる。
コードを書かせる。
テストさせる。
レビューさせる。
という話を書いてきました。
【このシリーズの過去回一覧】
-
社長AIブログ 第1回 | 30年近くIT業界にいるおっさんが、AIでまた開発者に戻った話
-
社長AIブログ 第2回 | AIだけで本当に製品は作れるのか?
-
社長AIブログ 第3回 | OpenAIとClaude Codeを一緒に働かせてみた
-
社長AIブログ 第4回 | AI同士に技術レビューさせたら、揉め始めた話
-
社長AIブログ 第5回 | 禁断のAI課金。AIで開発費は本当に安くなったのか?
-
社長AIブログ 第6回 | AIで楽になるはずが、なぜ私は1日20時間働いているのか?
-
社長AIブログ 第7回 | 生成AI時代、最初に限界を迎えるのはAIではなく人間だった
-
社長AIブログ 第8回 | AIにAzureへのシステム移行までやらせてみた
では、
既に動いているシステムを、
別の環境へ移すような仕事はどうなのか。
最近、
アーティサンでも既存システムをAzureへ移行する案件があります。
そこで、
AIをシステム移行にもかなり入れてみる
ことにしました。
結論から言うと、
かなり使えます。
ただし、
新規開発より怖いです(笑)
新規開発と移行は、似ているようで全然違う
新しいシステムなら、
多少失敗しても、
直せばいい。
まだ利用者がいない。
まだ本番データもない。
作り直すこともできます。
でも、
既存システムの移行は違います。
既に利用者がいる。
データがある。
止められない。
URLが変わるかもしれない。
認証もある。
バックアップもある。
監視も必要。
移行に失敗すると、
普通に業務が止まります。
だから、
「AIでやってみよう!」
と軽いノリだけではできません。
ここはかなり慎重に進めます。
まずAIに現行システムを読ませる
最初にやるのは、
現行調査です。
どんな構成なのか。
どこにコードがあるのか。
DBは何か。
ファイルはどこにあるか。
外部サービスは何か。
環境変数は何か。
定期処理はあるか。
ログはどこに出るか。
バックアップはどうしているか。
昔なら、
設計書を探して、
ソースコードを読んで、
担当者に聞いて、
Excelに整理する。
かなり時間が掛かります。
今は、
リポジトリや既存ドキュメントをAIに読ませ、
「現行構成を整理して」
と依頼できます。
もちろん、
全部信用はしません。
でも、
たたき台を作る速度は圧倒的に速いです。
次に「Azureならどうする?」を考えさせる
現行構成が分かったら、
Azure側の構成を考えます。
ここでAIに、
「VMへそのまま載せ替えるのではなく、
できるだけPaaSで考えたい」
のような方針を渡します。
すると、
Webアプリ。
データベース。
ストレージ。
シークレット管理。
監視。
バックアップ。
ネットワーク。
デプロイ方式。
などを整理してきます。
ここで重要なのは、
単に、
「動く構成」
ではなく、
「運用できる構成」
にすることです。
Azureはサービスが多い。
何でもできます。
だから逆に、
何を使わないかも重要です。
VMに載せるだけなら簡単。でも、それでは面白くない
既存システムをクラウドへ移す場合、
一番簡単なのは、
今動いているものを、
そのままVMに載せることです。
いわゆるLift & Shiftです。
もちろん、
それが正解の場合もあります。
ただ、
せっかく移行するなら、
運用負荷を下げたい。
バックアップを楽にしたい。
監視を標準化したい。
デプロイを自動化したい。
セキュリティも改善したい。
となります。
すると、
App ServiceなどのPaaS。
マネージドDB。
ストレージ。
シークレット管理。
監視サービス。
CI/CD。
などを組み合わせることになります。
この設計を、
AIとかなり細かく詰めます。
AIは「抜け」を探すのにも使える
移行設計で怖いのは、
忘れていたもの
です。
例えば、
昔作ったバッチ。
特定IPだけ許可している設定。
手作業で更新しているファイル。
誰も覚えていない定期処理。
メール送信。
外部API。
DNS。
証明書。
バックアップ。
こういうものが、
本番切替の日に突然出てきます。
「そういえば、これあった」
一番聞きたくない言葉です(笑)
そこでAIに、
「一般的なWebシステム移行で見落としやすい項目を洗い出して」
とレビューさせます。
すると、
チェックリストをかなり出してくれます。
さらに、
現行構成と突き合わせて、
不足を探させる。
これはかなり使えます。
移行計画もAIに書かせる
次に、
実際の移行手順です。
事前準備。
Azure環境構築。
データ移行。
アプリデプロイ。
DNS切替。
疎通確認。
業務確認。
監視確認。
問題が起きた時の切り戻し。
ここを手順書にします。
そして、
「この手順で失敗するとしたら何が起きる?」
とAIに聞く。
また直す。
さらに、
「ロールバック条件を明確にして」
と頼む。
また直す。
こうやって、
移行手順そのものをレビュー対象にする。
昔も当然やっていましたが、
AIがいることで、
レビュー回数をかなり増やせます。

「成功手順」より「失敗した時」を考えさせる
AIに設計させる時、
私は最近、
「どうすれば成功する?」
だけでなく、
「どう失敗する?」
をかなり聞くようになりました。
移行では特に重要です。
データが途中で壊れたら。
DNSが反映されなかったら。
証明書がおかしかったら。
接続先を間違えたら。
本番DBに接続できなかったら。
デプロイ後に性能が出なかったら。
こういうケースを先に出させます。
AIは、
成功パターンだけでなく、
失敗パターンを大量に考えさせると結構便利です。
GitHubが移行プロジェクトの記録になる
移行でもGitHubは重要です。
設計書。
移行計画。
IaC。
設定変更。
Issue。
Pull Request。
検証結果。
全部残します。
AIとの会話だけで進めると、
「なぜこの設定にしたのか」
が消えます。
移行後、
半年経ってから、
「この設定、何のため?」
となる。
そこで、
設計判断をドキュメントとして残す。
変更履歴を残す。
AIにも、
「ドキュメントを更新してから完了にして」
と指示します。
これは後で効きます。
AIに任せても、本番切替だけは緊張する
どれだけAIにレビューさせても、
本番切替の日は普通に緊張します。
これは変わりません(笑)
AIが、
「問題ありません」
と言っていても、
本当に動くまでは信用できない。
DNSを切り替える。
新環境へアクセスする。
ログインする。
データを見る。
実際の業務を確認する。
監視を見る。
エラーが出ていないか確認する。
この瞬間は、
20年前とあまり変わりません。
結局、
本番は本番です。
AIは「責任」を取らない
ここも大事です。
AIが、
「この構成で問題ありません」
と言った。
でも、
障害が起きた。
お客様に、
「AIがそう言ったので」
とは言えません。
会社として提供する以上、
最後の責任は会社にあります。
だから、
AIを使えば使うほど、
人間側は、
どこをAIに任せて、
どこを自分たちが保証するのか。
この線引きが必要になります。
AIは、
非常に優秀なメンバーです。
でも、
責任者ではありません。
それでも移行プロジェクトはかなり変わる
それでも、
AIを入れることで、
システム移行の進め方はかなり変わると思っています。
現行調査。
構成設計。
移行チェックリスト。
手順書。
ロールバック計画。
IaC。
レビュー。
ドキュメント。
こういう作業の速度が上がる。
特に、
今まで、
「時間がないから後で書こう」
となっていたドキュメントを、
AIに作らせられるのは大きい。
移行そのものより、
移行に伴う周辺作業がかなり軽くなる。
これは実感しています。
AIはプログラマーからITプロジェクトメンバーへ
最初、
生成AIは、
コードを書いてくれるもの、
くらいに考えていました。
今は違います。
要件整理。
設計。
レビュー。
テスト。
ドキュメント。
移行。
運用設計。
障害解析。
かなり広い範囲に入ってきています。
つまり、
AIは、
「プログラマー」
というより、
普通のITプロジェクトメンバー
になりつつあります。
そして、
複数のAIに役割を分けると、
開発チームまで作れる。
ここまで来ると、
会社のITの作り方そのものが変わってくると思います。
最後に決めるのは、やっぱり人間
今回も結論は同じです。
AIはかなり使える。
でも、
最後に、
「この構成で行く」
「この日に切り替える」
「ここまで確認したらOK」
「問題が起きたら戻す」
と決めるのは人間です。
AI時代になって、
コードを書く仕事は減るかもしれません。
でも、
判断する仕事はむしろ増える。
Azure移行までやってみて、
また同じところに戻ってきました。
AIに仕事を任せるほど、人間の判断が重要になる。
たぶん、
これがこのブログで何度も出てくるテーマになると思います。
そして次は、
AIで何でも作れるようになったからこそ、
「作らない」を決める仕事
について書いてみたいと思います。
できるから作る。
ではなく、
作れるけど作らない。
これもAI時代の経営では、かなり重要になりそうです。
Artisan(アーティサン)とは
Artisan(アーティサン)とは、腕の良い職人を意味する言葉です。
アーティサン株式会社では、技術をつくること自体を目的とせず、使われ続ける価値として社会に届けることを使命としています。
モビリティ事業は公共交通事業者や自治体向けに、バスロケーションシステム「バス予報」、予約配車システム「オンデマンドバス予報」、GTFS作成支援「まかせてGTFS」、お知らせ配信「かんたんAlert」などを提供しています。
MSクラウド事業はMicrosoft 365、SharePoint、Power Apps、Power Automate、Copilot Studioなどを中心に、コンサルティング、設計、構築、開発、研修、内製化、運用支援を提供しています。
2つの事業を通じて、企業と社会が自らの力で最適解を導き出すための支援を行っています。
気になることがあれば、お気軽にご相談ください。
また、技術を追い求めながら会社と一緒に成長していける仲間も、積極的に募集しています。
バス予報・オンデマンド交通など、モビリティ事業のサービス一覧はこちら
モビリティ事業ページへSharePoint・Power Platformなど、Microsoftクラウド事業のサービス一覧はこちら
Microsoftクラウド事業ページへアーティサンの採用情報はこちら
採用情報ページへ