【AWS Summit Japan 2026】レガシー構成のリニューアルとこれからのデータ基盤。AWSサミットで得てきた学びを共有！

こんにちは、プロダクト開発本部の近藤です。
私は現在、AUTO-REXの開発を専任で担当するエンジニアとして、企画・設計・開発などに一貫して携わっています。
そんな私が、プロダクト開発本部が抱える課題の解決策を探るべく、今年も「AWS Summit Japan 2026」に参加してきました。

現在、プロダクト開発本部では以下の3つのプロジェクトに取り組んでいます。

一つ目は、レガシー構成のリニューアルです。社内には長年運用してきたサイトがいくつもあります。これらのサービスを止めずに、どう安全に作り直すかを模索しています。symphony販売管理やAUTO-REXは、その代表例です。

二つ目は、AIを開発プロセスにどう組み込むかの最適な形を見つけることです。プロダクト開発本部では、CursorやDevinの2軸で活用を進めていますが、各チーム手探りの状態です。

三つ目は、全社的なデータ基盤の構築です。増え続ける自動車関連データをどうまとめ、将来のAI活用まで見据えたアーキテクチャにするかの検討を行なっています。

これらの課題感を持ってセッションやブースに参加し、それぞれで得た学びを共有します。

1. 『AWS Transform custom』で見た、AIエージェントによるコード解析

1つ目のプロジェクト「レガシー構成のリニューアル」で一番のネックは、長年動いてきたシステムのなかで、コード・処理・データ参照がきれいに分かれていないことです。レガシーなサービスは依存関係が追いづらく、ある画面の変更がどこまで影響するか、どこから手を付けるか、全部を人手で読み解くのは現実的ではありません。
この悩みを解決するべく、AIエージェントによるコードモダナイゼーションのセッション（『AWS Transform custom : AI エージェントによる 大規模コードモダナイゼーションの自動化』）に参加しました。

デモを見ながら、「ここまでコードの書き換えや依存関係の解析を任せていい段階に来たのか」と思いました。これまで、ひとつの大きなシステムを新しいフレームワークへ移すときは、コードを読んで、直して、手でテストする作業がどうしても必要でした。

AWS Transform customは、静的解析から変換、テストケースの補完までをエージェントに連携させるやり方です。人が移行の方針を決めて結果を評価し、実際の書き換えはエージェントに任せます。
symphony販売管理やAUTO-REXのようなレガシーシステムでも、依存関係の整理やロジックの切り出しに使えそうです。工数を減らしつつ、移行時の漏れも抑えられるはずです。

まずはチームに共有して、比較的独立した機能を1つ選び、「どこまで解析・変換できるか」を小さく試したいと思います。

2. 『キーノート』で聞いた、AI-DLCという開発の進め方

2つ目のプロジェクト「AIを開発プロセスにどう組み込むか」は、多くの組織でも同様に試行錯誤されている部分かと思います。プロダクト開発本部ではCursorとDevinの2軸で活用を進めていますが、現在は各チーム手探りの状態です。

少し前までは、チャットで質問し答えをもらう使い方が主流でしたが、今年のSummitでは、「エージェント」が中心テーマとして語られていました。目的を渡すだけで調査から実装まで自動で進めようとする動きは、CursorやDevinを導入した現場のリアルな感覚とも重なります。

キーノートや複数のセッションで登場したのが、「AI-Driven Development Lifecycle（AI-DLC）」という考え方です。当初私たちは、「要件や設計の意図をAIに伝え、実装からテストまでを任せた上で、人間は最後のレビューと品質担保に注力する」ようなプロセスをイメージしていました。しかし、今回のセッションを通じて、そうした「AIに任せきりにする（AI管理型）」アプローチでは、結果として人間が生成物の理解や修正に多大な時間を費やすことになり、品質向上に繋がりにくいということに気付かされました。

実際のAI-DLCが提唱しているのは、工程の中に人が常時入り込み、AIと密に協調する進め方です。例えば、AIが作業計画や設計案を提示しつつ、曖昧な点があればAI側から人に問い返し、重要な判断は人が行います。こうしたやり取りを、各工程においてチーム全体で繰り返しながら進めていくというスタイルです。

これは単に開発の一部でAIを使うのではなく、プロセス全体をAI前提で再構築するという発想です。エンジニアに求められる役割も変化しており、単にコードを書く力だけでなく、AIからの問いかけに対して的確な判断を下し、対話を通じてシステムを共に作り上げていく力が求められるようになっています。
数年前までは「AIを導入するかどうか」が論点でしたが、現在は「AIが存在する前提で、どう開発し、どう業務を回すか」へとフェーズが移行しています。弊社でCursorとDevinを並行運用していく上でも、「最後にどこでレビューを挟むか」ではなく、「各開発工程のどこに人が入り、AIとどう協調していくか」という視点で開発プロセスの改善を行なっていきます。

3. 『Apache Iceberg on AWS』で得た、データ基盤の候補

3つ目のプロジェクト「全社的なデータ基盤の構築」で一番のネックは、Summit参加を決めた時点で、どのようなアーキテクチャにするかがまだ固まっていなかったことです。そこで検討を具体化させるために参加したのが、Apache Icebergの実践セッション（『Apache Iceberg on AWS 実践ガイド -設計・取り込み・活用のベストプラクティス』）です。

本セッションは概要説明で終わらず、取り込み、パーティション設計、コンパクション（小ファイルの統合）といった運用まで、AWS上での具体的な話が多くありました。

紹介されていたのは、S3上のデータをIcebergでテーブル化し、ACIDを保ちながらAthenaやRedshiftから直接クエリする構成です。なかでも、既存のDBからCDCでデータを吸い上げてIcebergに溜める既存のDBからCDCでデータを吸い上げてIcebergに溜めるアプローチは魅力的でした。

ただし、これは「本番DBに負荷をかけない」だけで済む話ではありません。CDCの同期頻度を上げればIceberg側に小ファイルが大量に発生してクエリ性能が落ちますし、逆に頻度を下げれば本番DB側のトランザクションログ（binlog/WAL）が圧迫される懸念があります。この運用上のトレードオフをどうコントロールするかが鍵になります。

弊社の各サービスには、車両・掲載データや画像、更新履歴などが蓄積されています。車両データや更新履歴などのレコード情報はCDCで吸い上げ、画像などのメディアファイルは別経路でS3へ集約する。この形を取れれば、「掲載価格の推計」や「市場動向の分析」といった活用を進めやすくなります。

進め方として大事にしたいのは、最初から独自のETLを作り込みすぎないことです。独自の処理を凝ると、一見うまくいっても、人が変わったときに追えなくなります。AWSの標準構成をベースにすれば、後から入るエンジニアも追いやすくなります。とはいえ、CDCの頻度調整やコンパクションは標準構成のうえでも残る運用です。ここだけは初期の設計に組み込みます。

これらを踏まえ、現在は次の構成を軸にデータレイクハウスの検証を進めています。

• S3 + Apache Iceberg：ACIDトランザクションと小ファイルの最適化による効率的なデータ管理
• CDC + メダリオン構造：本番DBへの負荷を抑えながらデータを取り込み、段階的に標準化
• AIネイティブ設計：BIによる分析だけでなく、AI AgentやRAGからのデータアクセスも初期段階から考慮

この構成と運用上の論点はチームにも共有し、検証を重ねていきます。

おわりに

今回のSummitで強く残ったのは、モダナイゼーションとデータ基盤は別々の話ではなく、つながっている、ということです。レガシーをどう作り直すか、AIをどう開発に組み込むか、データをどう溜めるか。この三つがセットで動いている、と感じました。

いまのファブリカは、完成したきれいな構成を守るだけのフェーズではありません。課題を持ったまま検証し、答えを自分たちで作っていく段階です。

• symphony販売管理やAUTO-REXなど、レガシーなサービスをCursorやDevinなどのAIも使いながらモダナイゼーションする
• S3 + Apache Icebergなどを候補に、データ基盤の技術選定と検証を進める
• 溜まったデータを使い、分析やAI機能の実装につなげる
• AIを工程の一部ではなく、開発プロセス全体の前提（AI-DLC）として扱う

どれも「これから検証して、自分たちの手で形にする」段階です。大変ですが、エンジニアとしては面白いタイミングだと思います。

「仕様どおりに組むだけの仕事から出たい」
「レガシー刷新やデータ基盤の立ち上げに、最初から関わりたい」

そう思う人には、いまのファブリカは手を動かせる場所があるはずです。課題は多いですが、仕組みを自分たちで作っていく余地があります。

少しでも興味があれば、カジュアルに話しましょう。ご応募をお待ちしています。