【4〜6人月→1.5人月に】KDDIの社内AIサービスを Claude Code + Terraformで丸ごとクラウド移行した話

はじめに

こんにちは！株式会社メンバーズ Tech Leapカンパニーの松村です。
現在私はKDDI株式会社様の社内AI推進、PoC開発のご支援を行っております。

ご支援の一環として、2026年6~7月頃に、KDDI の社内で運用しているマルチテナントSaaS（以下「本アプリ」）を、AWS（ECS Fargate / Aurora PostgreSQL / S3 / Cognito）から Google Cloud（Cloud Run / Cloud SQL / Cloud Storage / Identity Platform）へ、インフラ・アプリコード・CI/CD・認証基盤まるごと移行しました。

移行作業の大部分を Claude Code（AIコーディングエージェント）に任せ、人間は「意思決定」「危険な操作の承認」「最終確認」に集中する体制で進めた結果、人手のみで実施した場合に想定される 4〜6人月規模の作業を、実働 1.5人月程度まで圧縮できました。

本記事では、

• 何をAIに任せ、何を人間が担ったか

• その過程で実際に起きた「一筋縄ではいかない」障害と、それをどう解決したか

• リードタイムがどのように短縮されたか

を、実際の作業ログをもとに振り返ります。

移行対象のアプリについて

機能概要

本アプリは、KDDI 社員向けの AI プレゼンテーション自動生成 SaaS です。キーワードや指示文を入力するだけで、構成案の作成からスライドのデザイン、PowerPoint ファイル（PPTX）の出力までを AI が一貫して行います。

主にできることは次の通りです。

• 参考資料からテンプレートを作る: 手持ちの PDF や PPTX をアップロードすると、AI が各ページを読み取ってレイアウト・配色・フォントを解析し、スライドのテンプレートとして使えるようにします

• AI に構成案を作らせる: キーワードや指示文から、AI（LLM）が各スライドのタイトル・本文・ビジュアルのヒントを含む構成案を書き起こします。さらに、スライドごとに合うテンプレートも AI が選びます。生成後に手で直したり、指示を出して作り直させたりもできます

• スライドをデザインする: 構成案とテンプレートをもとに、画像生成 AI がスライド画像を1枚ずつ描きます。「全スライドの背景を白にして」のような指示を出せば、AI が全スライドをまとめて描き直します

• 編集できる PowerPoint として出力する: AI がスライド画像を解析し、文字や図形を編集できるオブジェクトとして組み立て直して PPTX に変換します。画像を貼っただけの PPTX ではないので、ダウンロード後に PowerPoint で自由に手直しできます

1.資料やプロンプトから、LLMが自動でスライドの構成案を作成

2.構成案をもとにAIがスライド画像を生成

3.生成された画像をAIが解析し、編集可能なpptxへ変換

4.文字や画像がそれぞれ編集可能なpptxファイルに

技術概要

• マルチテナント構成: テナントごとにデータを分離して管理

• 認証: 社内 ID プロバイダとのシングルサインオン

• 生成パイプライン: 構成案生成 → テンプレート推薦 → スライド画像生成 → PPTX 変換 の複数ステップを、複数の外部 LLM / 画像生成 API を組み合わせて実行

• 管理機能: テナント管理、お知らせ配信、アクセスログ監査など

技術スタックは Backend が FastAPI（Python）、Frontend が Next.js（TypeScript）です。コンテナベースでクラウドにデプロイされており、この「コンテナで動く二層構成のマルチテナント Web アプリ」という形自体は AWS 版・GCP 版で変わっていません。移行のスコープは、その土台となるインフラと、クラウド固有 SDK に依存したアプリコードの全面差し替えです。

移行前と移行後のアーキテクチャ

移行前（AWS）

• コンテナ実行: ECS Fargate

• DB: Aurora PostgreSQL Serverless v2

• ストレージ: S3

• 認証: Amazon Cognito + 社内 ID プロバイダとの SSO 連携

• CI/CD: GitHub Actions による自動ビルド・デプロイ

• テスト: デプロイ後に E2E テストを自動実行（Playwright で各画面のスクリーンショットを撮り、画面が正常かを LLM が判定）

移行後（GCP）

• コンテナ実行: Cloud Run（オートスケール、アイドル時ゼロスケール）

• DB: Cloud SQL for PostgreSQL

• ストレージ: Cloud Storage

• 認証: Identity Platform + 社内 ID プロバイダとの SSO 連携

• CI/CD: GitHub Actions による自動ビルド・デプロイ（長期の認証鍵を持たない方式）

• テスト: デプロイ後に E2E テストを自動実行（Playwright で撮ったスクリーンショットを LLM が判定。AWS 版から継続）

• LLM 呼び出しの一部を AWS 側のマネージド LLM サービスに切り替え（こちらも長期の秘密鍵を持たない方式で接続）

サービス対応は概ね以下の通りです。

何をAIに任せて何を人間がやったか

移行は「AI が自律的に実装まで完結させる」「人間が判断・実行する」「両者が協働する」の3パターンに分けて進めました。全工程を通じて 90 件の作業単位を記録し、都度どちらが担当したかをログに残す運用にしていました（このログ運用自体もAI主導で継続）。

AI が単独で完結させたこと

• 既存 AWS アーキテクチャドキュメントの精読と、AWS→GCP のサービス対応表・移行アーキテクチャ設計のドラフト作成

• Terraform モジュール一式（ネットワーク・IAM・KMS・DB・ストレージ・Cloud Run・ロードバランサ・CI/CD・監視、計13モジュール）の実装

• クラウド SDK 依存コードの全面書き換え（ストレージ層の SDK 差し替え、認証トークン検証ロジックの差し替え、認証フローの API 差し替えなど。呼び出し側は数十ファイル・数百箇所規模）

• 障害の根本原因調査（後述）と修正、回帰テストの追加

• CI/CD ワークフローの実装、および途中で判明した設計上の制約に応じた再設計

• 作業ログ・セットアップ手順書・要件チェックリストなど、ドキュメント一式の作成・継続更新

人間が担ったこと

• クラウド選定・DB エンジン選定・認証方式・移行戦略（並行構築→DNS カットオーバー）などの最終意思決定

• terraform apply の実行（原則すべて。破壊的操作を伴うため、AI は plan の提示までに限定するルールを最初から敷いていた）

• シークレットの実値投入（DB パスワード、APIキーなど。値を会話ログに残さないよう人間が手元で実行）

• 社内の関係部署への各種申請や、クラウドコンソール上での設定など、外部システム側の手続き

• ブラウザ操作が必要な E2E 動作確認（実際のログイン、画面遷移の確認）

• Pull Request のレビューとマージ承認

例外的にAIへ権限移譲した場面

一度だけ、明確な承認のもとで AI に「1回限りの環境構築コマンド実行」を許可した場面がありました。権限や認証まわりの初期設定のような、通常は人間が実行する類の操作です。恒常的な自律実行にはしておらず、都度「今回はAIが実行してよいか」を確認するプロセスを踏んでいます。この線引き（apply は人間、単発の構築コマンドは都度承認のうえAI可）は移行期間を通じて一貫させました。

「terraform apply と入力するだけ」だった、という感覚

今回の移行で象徴的だったのは、新しいクラウド上にリソースを1つ作るたびに、人間が「何を作るべきか」を考える必要がほぼ無くなっていたことです。

ネットワーク・IAM・KMS・DB・ストレージ・Cloud Run・ロードバランサ・CI/CD・監視という13個の構成要素を、AIが最初から Terraform コードとして書き起こしていました。人間が担ったのは、

1. 出てきた terraform plan の差分（「何が何個、追加/変更/削除されるか」）を読んで妥当性を確認する

2. 問題なければ terraform apply と打つ

という2ステップだけです。GCPコンソールを開いてリソースをポチポチ作る、公式ドキュメントを読みながら設定項目を1つずつ埋める、といった作業は発生しませんでした。IaC（Infrastructure as Code）自体は目新しい手法ではありませんが、「コードを書く」という最も時間のかかる工程まで含めてAIが担ったことで、人間の役割が「実行権限を持つ承認者」に純化された、というのが今回の実感です。

もちろん、これは無条件に安全というわけではありません。既存の環境を巻き込まないためのState分離・命名規則・「削除は必ず人手承認」といったガードレールは、着手前に明文化してAIに徹底させています。「AIが書いたコードを無条件に信頼してapplyする」のではなく、「plan差分で毎回確認できる」というTerraformの仕組みそのものが、AI生成コードを安全に運用に載せるための前提になっていました。

AI はどう障害を調べ、どう解決したか

移行はドキュメント通りには進みませんでした。ここでは、実際に起きた障害を4つ取り上げ、AI がどこを見て原因にたどり着き、どう解決したかを紹介します。

どの障害でも、AI の動き方は概ね同じでした。

1. エラーメッセージだけで判断せず、ログ・実データ・コード・設定を自分で取りに行って突き合わせる

2. 原因を特定したら、修正だけでなく「修正で別の何かが壊れないか」まで確認する（Terraform の plan 差分、回帰テストなど）

3. 直したあとに、実際の環境で直ったことを確かめる

人間が担ったのは、AI が出した解決方針の承認と、terraform apply やブラウザでの最終確認です。

1. CI/CD の標準構成が社内環境では使えなかった

起きたこと: 一般的な手順どおりに CI/CD の認証を組んだところ、ワークフローが準備段階で停止しました。

AI の調査: エラー文から、処理の中身ではなく認証に使う外部の連携モジュールを取得する段階で失敗していると読み取り、社内の CI 環境の制約で標準構成がそもそも使えないと特定しました。

AI の解決策: CI の実行環境がすでに持っている認証の仕組みを活かし、追加の鍵を持たない別の方式に切り替えました。途中、plan にCI 実行環境の作り直しが紛れ込んでいることに AI が気づき、原因の変更を取り消してから apply を依頼しています。

2. スライド画像が壊れる：移行前から潜んでいたバグ

起きたこと: 動作確認中、あるプロジェクトでスライドの一部だけが表示されませんでした。

AI の調査: ストレージ → ログ → コードの順に絞り込みました。

1. ファイルはあるが中身が壊れている → 「欠落」ではなく「書き込み中の破損」

2. ログに同じプロジェクトへの生成リクエストがほぼ同時に2回 → 同じファイルへの同時書き込み

3. 二重起動チェックとフラグのセットが別処理 → TOCTOU 競合（AWS 版から潜在）

AI の解決策: チェックとフラグのセットを1つのロック内にまとめ、20スレッドの同時実行テストを追加しました。デプロイ後、生成し直した画像が全枚数正常であることまで確認しました。

3. 本番の CI 実行環境の「静かな失敗」

起きたこと: apply はエラーなく完了したのに、CI 用の VM に必要なツールが入っていませんでした。

AI の調査: VM を調べ、起動スクリプトが終了コード 127 で失敗していたことを発見。原因は改行コードが CRLFで、shebang が解釈できていなかったことでした（Windows 端末で編集したファイルがそのまま渡っていた）。

AI の解決策: LF に直したスクリプトを実行し、VM に登録されている起動スクリプトも修正して再発を防ぎました。

4. SSL 証明書の「入れ替えデッドロック」

起きたこと: ドメイン変更の apply で、SSL 証明書の作り直しが resourceInUseByAnotherResource というエラーで失敗しました。

AI の調査: Terraform は「旧証明書を消す → 新証明書を作る」順に動くが、ロードバランサがまだ旧証明書を参照しているので消せない、という循環依存だと特定しました。

AI の解決策: 証明書名にドメイン由来のサフィックスを付けて新旧を共存可能にし、create_before_destroy で「新規作成 → 参照切り替え → 旧削除」の順にしました。

リードタイムがAIによってどれだけ縮まったか

実績

移行は 2026年6月上旬に着手し、開発環境の稼働開始・本番環境の構築・CI/CD 自動化・認証基盤の分離、そして本番データ移行の準備まで、実働ベースでおおよそ1.5人月の人間側の作業量（意思決定・承認・apply・申請・確認）で到達しました。

比較: 人手のみで行った場合の推定

作業ログに残る 90件の作業単位を AI の支援なしに人間だけで行った場合の工数を、内容の難易度から逆算し、4〜6人月規模と見積もっています。根拠は主に次の4点です。

特に大きいのは「調査」と「障害調査」です。移行では、CI/CD の標準構成が社内環境では使えないと判明する、証明書の入れ替えでデッドロックする、といった事前のドキュメントには書かれていない実行時の落とし穴に何度も遭遇しました。この種の問題は人間だけで対応すると「ログを読む→検索する→試す→失敗する→別の仮説を立てる」のサイクルに時間がかかりますが、AI がコード・設定・エラーメッセージを横断的に即座に突き合わせることで、サイクル自体を大幅に短縮できました。

なお、上記はあくまで作業ログの内容から逆算した見積もりであり、厳密なタイムトラッキングによる比較ではありません。実際の短縮効果はチームのクラウド経験や規模によって変動する点にご留意ください。

まとめ

• KDDI 社内のコンテナベースのマルチテナント SaaS を、AWS から GCP へインフラ・アプリコード・認証基盤・CI/CD まで含めて移行した

• 「意思決定・危険操作の承認・最終確認は人間、調査・実装・デバッグ・記録は AI」という役割分担で進めた結果、人手のみなら 4〜6人月規模と見積もる作業を、実働 1.5人月程度に圧縮できた

• インフラ構築はAIがTerraformコードをほぼ100%書き切ったため、人間がリソース作成のために手を動かす場面は実質「planの差分確認」と「applyと入力する」の2ステップに縮小された

• 短縮効果が最も大きかったのは、事前ドキュメントに書かれていない「実行して初めて分かる」類の障害調査。AI がログとコードを横断的に突き合わせて仮説検証を高速に繰り返せたことが効いた

• 一方で、terraform apply のような不可逆・広範囲影響の操作は最後まで人間が実行する運用を徹底した。AIに任せる範囲と人間が握る範囲の線引きを最初に決めておくことが、スピードと安全性を両立させる鍵だった

クラウド移行のような「正解が事前に分からず、実行して初めて障害に気づく」タイプのプロジェクトは、AI コーディングエージェントの得意領域と相性が良いと感じています。
また、改めて本記事を読み返してみると、数年前には考えられなかったようなスピード感と規模感の内容になっており、エンジニアリング分野におけるAIの影響力の大きさを実感しました。