こんにちは、LIFULL HOME'Sのネイティブアプリ開発チームでエンジニアリングマネージャーをしている佐々木です。 「この画面、何が表示されてるか教えてもらえますか？」 目の前のタスクに集中しているときにSlackに飛んでくるこの一文で、エンジニアの手は止まります。悪気はない。でもチームのリードタイムは確実に伸びていく。 この問題を、AIに業務知識を構造化して渡すことで解消した話をします。 背景：人間が"コンテキストの運び屋"になっていた 試行錯誤：最初からこの形だったわけではない 何を作ったか：業務知識をパッケージ化する なぜ効いたか：3つの設計判断 ① 定義の集約：誰がいつ聞いても同じ答えが返る ② スキル化：「やりたいこと」を伝えるだけで手順が走る ③ ツール統合：分析もチケット起票も1箇所で完結 成果：「聞く側」も「聞かれる側」も変わった 余談：世界では「コンテキストレイヤー」と呼ばれているらしい まとめ 背景：人間が"コンテキストの運び屋"になっていた 私たちのチームでは、メイン施策を進めている最中に、次の施策のための質問・相談が頻繁に飛んできていました。 PdMから：「この画面の表示ロジックってどうなってる？」 デザイナーから：「この機能、実装上の制約ある？」「この表現はコード的に可能？」 マーケから：「この数値、どのイベントで計測されてる？」 エンジニアは手を止めてコードを読み、回答する。1往復30分〜数時間。これが毎日何回も発生していました。 問題はそれだけではありません。質問する側も「エンジニアの手を止めてしまう」という心理的ハードルを感じていて、遠慮して質問を溜め込む → まとめて聞く → 大量の回答待ちが発生する、という悪循環もありました。 本質は明確でした。 チームの業務知識が人の頭にしかなく、AIが参照できる形になっていなかった 。 試行錯誤：最初からこの形だったわけではない 前提として、利用者は非エンジニアです。GitHubアカウントを持っていない人がほとんどで、 git clone もターミナルも使えない。この制約の中で、どうやってコードベースの知識をAIに渡すか。 最初に試したのはGoogle GeminiのGem（カスタムAI）+ GitHub連携でした。でも連携した本人しか使えず、チームには共有できない。NotebookLMも同じ問題。 Repomix （コードを1ファイルに圧縮するツール）も試しましたが、ディレクトリ構造やファイル間の関係性が失われ、調査精度が出ませんでした。 結局たどり着いたのは「コードをそのまま同梱してzipで配る」という原始的な方法でした。全員が同じ環境を使えて、コードの構造もそのまま残る。「Googleドライブからダウンロード→解凍→フォルダを開く」だけで始められる。これが一番確実だった。 何を作ったか：業務知識をパッケージ化する 作ったのは、チームの業務知識を構造化してAIエージェントに渡す「パッケージ」です。zipを解凍して Kiro IDE （AIエージェント機能を内蔵したエディタ）で開き、日本語で質問するだけで使えます。 パッケージの中身は3層で構成されています。 steering（ルール・定義） : KPI定義、データソースの所在、業務上の制約 skills（手順・ナレッジ） : 分析の手順、レポート作成の方法、調査の進め方 agents（専門家） : コード調査担当、データ分析担当など、役割に特化したサブエージェント 3層構造の概念図 このしくみを、現在4チームに展開しています。 対象チーム 当初の課題 利用者 状態 ネイティブアプリ開発チーム 仕様調査でエンジニアの手が止まる PdM・企画・デザイナー ✅ 稼働中 デジタルマーケティングチーム 数値管理・レポートが手作業で属人的 マーケター ✅ 稼働中 アプリ広告運用（ASA/ASO）チーム 運用判断に専門知識が必要 企画・マーケター 🔶 一部利用 賃貸・流通領域チーム 仕様調査の横展開 PdM・企画・デザイナー 🔶 検証中 このほかにも試作段階のものがあり、少しずつ適用範囲を広げています。 このしくみの展開により、従来のコミュニケーションフローが大きく変わりました。 Before/Afterフロー比較 なぜ効いたか：3つの設計判断 ① 定義の集約：誰がいつ聞いても同じ答えが返る 「この指標の定義は？」「この計算式の出どころは？」。これまで人の頭にしかなかった情報を、Markdownファイルに一元管理しました。誰がいつ聞いても、AIが同じ定義に基づいて同じ答えを返します。属人化が構造的に解消されるしくみです。 ② スキル化：「やりたいこと」を伝えるだけで手順が走る 「着地見込を出して」と伝えるだけで、AIがデータ取得→計算→フォーマット整形まで実行します。利用者は「やりたいこと」を伝えるだけでよく、手順を知っている必要がありません。業務手順の暗黙知がスキルとして構造化されているからです。 ③ ツール統合：分析もチケット起票も1箇所で完結 BigQueryでの数値分析も、Jiraへのチケット起票も、Confluenceへの報告書投稿も、全部同じKiro IDEの中で完結します。「あの作業はスプレッドシート、この分析はGemini、あれはGoogle Apps Script」というツール跨ぎが消え、非エンジニアにとっての認知負荷が劇的に下がりました。 成果：「聞く側」も「聞かれる側」も変わった 利用者の一人である企画メンバーは、公式noteで以下のように書いてくれています。 以前は、「この仕様はどうなっていますか？」とエンジニアに確認を依頼し、その回答を待つまでに数時間〜1日ほどのリードタイムが発生していました。エンジニア側の作業を止めてしまうという心理的ハードルもありました。 しかし現在では、企画担当である私自らが調査パッケージを使い、5分〜10分程度でコードベースの一次調査を完結させています。コミュニケーションの往復が消えたことで、調査工数は約80〜90％削減され、施策検討のサイクルは圧倒的に加速しました。 — エンジニアから企画へ。LIFULL HOME'S アプリ部署で目撃した、AIシフトがもたらす「職種を越えた共創」 単に工数が減っただけではありません。「ここまで調べた結果、ここを変えれば実現できそうですが、どう思いますか？」という提案ベースの相談ができるようになったことで、意思決定の質も上がっています。 そしてエンジニア側は、調査依頼に中断されることなく、メイン施策の開発に集中できるようになりました。 余談：世界では「コンテキストレイヤー」と呼ばれているらしい ちなみに、2026年3月にa16z（米国の大手VC）が公開した記事「 Your Data Agents Need Context 」では、こう述べられています。 データ・分析エージェントは適切なコンテキストなしでは本質的に役に立たない。曖昧な質問を解きほぐすことも、ビジネス定義を解読することも、散在するデータを横断して推論することもできない。 同記事では、この問題の解決策として「企業のデータを束ね、ビジネスロジックを理解できる層をエージェントに供給する基盤」を「コンテキストレイヤー」と呼んでいます。振り返ると、私がやっていたことはまさにこれでした。 この記事を知ったのは後からです。現場の課題を解決していたら、同じ構造にたどり着いていました。 まとめ AIがどれだけ賢くなっても、チーム固有の業務知識を構造化して渡さなければ正しくは動きません。 大げさなプラットフォームがなくても、Markdownとスキル定義を整備してzipで配るだけで始められます。「人に聞く」を「AIに聞く」に変えるだけで、チームの循環は確実に変わります。 次回は、このしくみの技術的な設計と具体的なファイル構成について詳しく書く予定です。 最後に、LIFULLではともに挑戦し成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 https://hrmos.co/pages/LIFULL/jobs/010 https://hrmos.co/pages/LIFULL/jobs/010-9998

こんにちは。広告・マーケティング業界を担当するソリューションアーキテクトチームです。いよいよ 6 月 25 日 (木)、26 日 (金) の 2 日間、千葉・幕張メッセにて AWS Summit Japan 2026 が開催されます。基調講演や数多くの事例セッションとともに、AWS Expo のエリアでは AWS サービス・ソリューションの最新活用事例や、実際に AWS に触れられるデモを、さまざまな角度から体験いただけます。 その AWS Expo エリア内には、製造、金融、自動車、そして私たちの担当する広告・マーケティングなど、業界別に特化したソリューションをご紹介する AWS Industries Zone が設けられます。各業界をリードするお客様の AWS 活用事例や、生成 AI をはじめとする最新テクノロジーの実用的なデモを通じて、業界固有の課題解決の方法をご覧いただける場です。業界に精通したエキスパートと、具体的な活用シナリオについてじっくりご相談いただけるスペースもご用意しています。私たち広告・マーケティング業界担当チームも、このゾーンに今年ならではのテーマで展示を出展します。本ブログでは、その展示内容を一足先にご紹介します。まだ登録がお済みでない方は、ぜひ下記のリンクから。 登録はこちら AWS 展示 A033：行動ログと AI による次世代パーソナライズ —  購買データだけでなく「顧客の迷い」を資産に、自律型顧客体験の実現へ 購買データという「結果」だけに頼ってパーソナライズしていませんか？閲覧、比較、カート放棄など、購入に至らなかった「顧客の迷い」にこそ本音が隠れています。この行動データを全量収集し資産化することで、顧客の真のニーズを捉えられます。本展示では、行動データの自社資産化基盤と、Agentic AI が最適なコンテンツ・タイミングを自律的に判断して届ける次世代の仕組みをご紹介します。 A035：すべての仮説を AI ペルソナで試す時代へ —  ふと浮かんだアイデアを、自社データで即検証 「この層はどう反応するだろう？」ふと浮かんだ仮説をコストや時間を理由に諦めていませんか？本ソリューションは自社の購買・顧客データから AI ペルソナを生成し、思いついたアイデアをその場で検証できます。試して、直して、また試す——このサイクルが数分で回るから、今まで捨てていた “小さな思いつき” すべてをぶつけられます。カスタムプロンプトで検証シナリオも自在に調整でき、ブースで実際にお試しいただけます。ソリューションのコードは aws-samples（GitHub） で公開中 です。 お客様展示 A034：株式会社電通, 株式会社電通デジタル — AI Agent を活用した広告効果分析の効率化 電通/電通デジタルのマーケティング領域における知見をもとに生まれた新たなエージェントサービスは、広告活動に関わる分析・検証業務を対話形式で支援します。広告データ活用において、課題整理から分析実行、結果の取りまとめまでを自然言語で支援することで、専門的知識や個別担当者への依存を抑え、業務効率化と意思決定の高度化に貢献します。AWS を活用した柔軟なエージェントシステムで広告業務全体を横断的に補助し、より多くの方が直感的に高度な判断を行える環境の実現を目指します。 A036：株式会社NTTドコモ — AI エージェント「SyncMe」の基盤に AWS を活用 あなただけのパーソナル AI エージェント 「SyncMe」 は、ユーザーひとりひとりに合わせた体験を提供するために、マルチエージェントアーキテクチャと独自の記憶管理を組み合わせています。本展示では、パーソナライズを行うため「d アカウント情報に基づいたパーソナライズ」と「エージェントとの会話を重ねることによって育まれるパーソナライズ」の 2 点の取り組みが、どのような工夫で実現されているかご紹介します。 あわせて聴きたい — 関連セッションのご紹介 ブース展示をご覧いただいたあとは、ぜひ関連セッションにも足をお運びください。広告・マーケティング業務に直結するセッション、AI エージェントやデータ分析の最新動向まで、いくつかピックアップしてご紹介します。 広告・マーケティング × AI AIM202｜あなたの新しいエージェンティックなチームメイト、Amazon Quick を知ろう （6/25 木 11:30–12:10） 私たちの多くは、情報を活用するよりも探すことに多くの時間を費やしています。Amazon Quick はそれを変えます。ドキュメント、データベース、メール、Slack のスレッド、ダッシュボード、Jira チケットなど、社内のあらゆるデータに横断的にアクセスし、検索、質問、そしてアクションの実行までを一つの場所で完結させます。Web、モバイル、Slack、Microsoft の各種ツールに対応し、マルチモデル AI を搭載。コンシューマー向けの使いやすさと、エンタープライズレベルのセキュリティおよびガバナンスを両立しています。ベンダーロックインも、ツールごとに分断されたコパイロットもありません。あなたがどこで働いていても、一緒に働いてくれる、たった一つの AI チームメイトです。 ANT310｜AWS Analytics MCP サーバーで実現するエージェント型データエンジニアリング （6/25 木 16:30–17:10） 本セッションでは、AWS Analytics Model Context Protocol (MCP) サーバーをご紹介します。Data Processing MCP Server と Amazon Redshift MCP Server を含むこれらのオープンソースツールにより、AWS Glue、Amazon EMR、Amazon Athena、Amazon Redshift を横断するエージェント型ワークフローが実現できます。AIエージェントとの自然言語による対話を通じて、複雑な分析オペレーションをどのように簡素化できるかをご説明します。MCPサーバーの実装戦略、実際のユースケース、デプロイメントのためのアーキテクチャパターン、そしてアナリティクス環境を理解し統制するインテリジェントなデータエンジニアリングワークフローを構築するための本番環境でのベストプラクティスを取り上げます。 AIM343｜生成 AI で「売れる製品」を作る — POC 止まりを突破する 6 つのプロダクトデザイン戦略 （6/26 金 13:00–13:40） 生成 AI への投資額は世界で急拡大し、2029 年には約 18 兆円規模に達すると予測されています。しかし現実には、AI プロジェクトの多くが POC から本番導入に至らず廃止されており、「技術は動くが、売上にはつながらない」という課題に多くの ISV が直面しています。本セッションでは、この「POC の壁」を突破し、生成 AI を持続的な収益成長エンジンに変えるための 6 つの AI プロダクトデザイン戦略を体系的に解説します。テクノロジードリブンではなくバリュードリブンで「ゴールから逆算」するアプローチを軸に、実際に収益化に成功した ISV の具体的な設計手法をご紹介します。 MAM241 ｜ 「統制された自由」の実現 －電通グループ 140 社を支える AI 時代の IT ガバナンス（6/26 木 14:30–15:00） 生成 AI 時代に拡大するクラウド投資とリスクをどう統制するか。電通グループが AWS のエコシステムで実践する、統制と自由を両立するグループ IT ガバナンスの具体例をご紹介します。 AI エージェント全般 AIM201｜本番展開を見据えて：エージェンティック AI に対する実践的アプローチ （6/25 木 11:30–12:10） AI 実証実験の 46 % は本番に届かず消滅する – 同じ経験をされた方も多いのではないでしょうか。本セッションでは、プロトタイプの壁を突破するために必要な 4 つの柱「運用」「データ」「信頼性」「堅牢性」を、これまで AWS が多くのお客様支援から得たナレッジをもとに体系的に解説します。既存サービスの活用判断から、オブザーバビリティ、データ整備、セキュリティ設計、評価の自動化まで、エージェントの価値を最大化するための近道をお伝えします。 AIM216｜エージェンティック AI におけるビジネスインテリジェンスの再構築と民主化 （6/25 木 12:30–13:10） ビジネスインテリジェンス（ BI ）は、AI の進化とともに大きな転換期を迎えています。構造化・非構造化データの統合活用、ワークフロー自動化が進む一方、エンタープライズ環境ではデータサイロや管理コストといった課題が依然として残っています。本セッションではエージェンティック AI を活用した Amazon Quick による BI の再構築について解説します。Amazon 社内での活用を一例として交えながら、誰もがデータから価値を引き出せる環境の実現に向けた具体的なアプローチをご紹介します。参加者は、自社の BI 戦略にエージェンティック AI を取り入れるためのヒントをお持ち帰りいただけます データ分析基盤 ANT209｜データウェアハウスのモダナイズ – 事例とデモで学ぶ Amazon Redshift マルチウェアハウスアーキテクチャ （6/25 木 15:30–16:10） 「ETL が走ると BI が遅くなる」「生成 AI ワークロードを追加したいがリソースが足りない」といった悩みを抱えていませんか？その課題、マルチウェアハウスアーキテクチャで解決することができます。エンタープライズ分析プラットフォームは、集中型で過負荷状態のデータウェアハウスから、分散型でガバナンスが効いた、生成 AI 対応のマルチウェアハウスアーキテクチャへと進化しています。データをコピーする必要もありません。本セッションでは、ビジネスニーズに応じてスケールするデータウェアハウスアーキテクチャの設計方法を学びます。モノリシックな Amazon Redshift クラスターから最新のマルチウェアハウスアーキテクチャへのモダナイゼーションを実事例で紹介し、ETL・BI・生成 AI それぞれを干渉なく動かすデモを通じて、具体的な実現ステップをお持ち帰りいただけます。 まとめ 広告・マーケティングブースでは、AWS 展示 2 つ、お客様展示 2 つの合計 4 ブースで皆さまをお待ちしています。行動ログ × Agentic AI による自律型パーソナライズ、AI ペルソナによる高速仮説検証、そして株式会社電通, 株式会社電通デジタル様・株式会社NTTドコモ様による最先端のお客様事例を学ぶことができます。ぜひエキスパートと直接お話しください。皆さまのご来場を心よりお待ちしております。 AWS Summit Japan 2026 への登録はこちら 著者について 小川　翔 アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 流通小売業界のお客様を中心にクラウド活用の技術支援を行っています。好きな AWS サービスは Amazon Bedrock と、Amazon Personalize です。

セガサミーホールディングス株式会社は、エンタテインメントコンテンツ事業、遊技機事業、ゲーミング事業の 3 つの事業領域を軸に展開する総合エンタテインメント企業グループの持株会社です。同社では、グループ会社であるサミー株式会社の基幹業務システム（販売、調達、生産、在庫管理）を支えるデータベースを、オンプレミスの Oracle Database から Amazon RDS for Oracle に移行しました。本ブログでは、移行の背景にあった課題、移行の取り組み、そして移行後に得られた効果についてご紹介します。 移行対象のシステム 今回の移行対象のデータベースは、サミー株式会社の基幹業務（販売、調達、生産、在庫管理）を支える複数の業務システムのバックエンドとして利用されていました。その大部分を占めるのが intra-mart を開発基盤とした基幹システムです。intra-mart の AP サーバーおよびデータベースはオンプレミス環境で運用されており、今回のプロジェクトで AP サーバーとデータベースの双方を AWS に移行しました。データベースには約 4,000 のテーブル、約 650 のマテリアライズドビュー、約 600 のプロシージャが存在し、データサイズは約 2TB に及びます。基幹系システムであるため、月次メンテナンス日以外は無停止での稼働が求められていました。 課題 当該システムをオンプレミスで運用する中で、大きく 3 つの課題がありました。 物理制約と調達遅延 オンプレミス環境では、リソース拡張にサーバーやストレージの事前購入が必要で、調達に時間がかかるため、事業や環境変化への即時対応が困難でした。初期投資の負担も大きく、突発的な負荷変動にも即座に対応できない状況でした。加えて、ハードウェア障害時には長時間のダウンタイムをともなうリスクがあり、DR/BCP 対策の強化も容易ではなく、基幹系システムとしての可用性に懸念を抱えていました。 運用負荷 監視ツールは自社で選定・管理する必要があり、開発・テスト環境の構築にもインフラ担当への依頼が必要でした。物理機器の保守やハードウェアのライフサイクル対応（リプレイス作業）にも工数を割かれ、月次メンテナンスなど業務時間外の対応も発生していました。こうした定型的な運用業務に時間を取られ、インフラ担当者が本来注力すべき高度な業務に集中しにくく、モチベーションの維持も難しい状況でした。 AI 活用を見据えた拡張性の確保 同社では、グローバルレベルでのデータ基盤強化とデータ利活用の促進、AI 活用による業務効率化を IT 戦略として掲げていました。将来的な AI 活用やデータ分析の推進を見据え、周辺サービスと柔軟に連携できる環境への移行も視野に入れていました。 ソリューション これらの課題を解決するため、オンプレミスのデータベースをクラウドへ移行する方針が決定されました。移行先として AWS に加え Oracle Cloud Infrastructure（OCI）やオンプレミスの継続も検討しましたが、以下の理由から AWS 上のマネージドサービスである Amazon RDS for Oracle を採用しました。 同一エンジン（Oracle）のマネージドサービスへの移行であるため、アプリケーション改修を最小限に抑え、移行コストを低減できる マネージドサービスの活用により、バックアップやパッチ適用などの運用負荷を軽減し、DR/BCP 対策の強化やリソースの柔軟な拡張が実現できる AWS 上にデータベースを配置することで、ETL、分析基盤、AI/ML など AWS の周辺サービスとの連携が容易になり、データ利活用の推進基盤として活用できる また、同社ではクラウドファーストを会社の方針として掲げており、コスト最適化およびマネージドサービス活用による運用効率の向上を推進していたことも、今回の移行を後押ししました。 移行スケジュール 移行は以下のスケジュールで実施しました。 プロジェクト計画フェーズ 移行に先立ち、2025 年 2 月中旬から 3 月末にかけてプロジェクト計画を策定しました。本プロジェクトは Oracle 11g から 19c へのバージョンアップも兼ねていたため、AWS Schema Conversion Tool（SCT）を使用してスキーマの互換性を事前に検証しました。これにより、DB オブジェクトの互換性に関する課題を早期に把握することができました。 また、Amazon RDS for Oracle に向けて対応が必要な箇所や影響範囲の洗い出しを行った結果、帳票出力や SQL Loader によるデータロードなどに影響があることが判明しました。帳票出力については、オンプレミス環境でファイルシステムにマウントして出力していた処理を変更する必要がありました。また、SQL Loader によるデータロードについても同様に影響がありました。いずれも Amazon RDS と Amazon S3 のインテグレーション機能を活用する方式に置き換えて対処しました。S3 インテグレーションへの切り替えは当初想定よりも対応範囲が広かったものの、方針が固まってからはスムーズに進めることができました。 加えて、オンプレミスからクラウドへの移行にあたっては、ネットワークレイテンシーの影響が懸念されました。検証ではデータ量に応じてレイテンシーが増加する傾向が見られましたが、最も遅延の影響を受けやすく、データ量が比較的小さい工場システムで問題がないことを確認し、移行可能と判断しました。 テストフェーズ 2025 年 8 月中旬から 11 月末にかけて、主要業務の SQL を対象としたシステムテストを実施しました。約 8 件の SQL でパフォーマンスの劣化が確認されました。原因は、移行先の Oracle バージョンでオプティマイザが生成する実行計画が最適ではなかったことにありました。この問題には OPTIMIZER_FEATURES_ENABLE パラメータのヒント句で対応しました。OPTIMIZER_FEATURES_ENABLE は、オプティマイザの動作を指定したバージョンの挙動に合わせるパラメータです。移行元のバージョンを指定することで移行前と同等の実行計画が生成されるようになり、性能劣化の大部分を解消しました。 移行実施 2025 年 12 月末に本番移行を実施しました。約 4,000 テーブル・約 2TB の基幹 DB を EXP/IMP で移行しました。本番切替後にも、事前テストでカバーしきれなかった一部の SQL でパフォーマンスの遅延が発生しましたが、テストフェーズで OPTIMIZER_FEATURES_ENABLE によるワークアラウンドを把握できていたため、同じ対処で速やかに改善することができました。それ以外に大きな問題は発生せず、基幹業務システムとしてスムーズに稼働を開始しました。DB が AWS 上に移行されたことでネットワーク構成が改善され、移行前と比較してパフォーマンスの向上も実感できる結果となりました。 導入効果 Amazon RDS for Oracle への移行により、以下の効果が得られました。 パフォーマンスの向上 移行により明らかにパフォーマンスが向上し、日次夜間バッチの処理時間も約 22% 短縮されました。高負荷時に遅くなる事象が解消され、サーバーダウンにつながるような負荷の問題もなくなりました。また、最適なリソース選択が容易になり、ワークロードに応じた適切なインスタンスサイズを柔軟に選択できるようになりました。 柔軟性の向上 AWS への移行により、数分でリソース拡張が可能になり、オンプレミス特有の物理制約や調達遅延が解消されました。突発的な負荷変動が発生した場合でも対処できる選択肢が確保され、事業や環境変化に対応できる安心感のある基盤を実現しました。初期投資についても、オンプレミスのようにサーバーやストレージを事前に大きく購入する必要がなくなり、利用量ベースで投資判断がしやすくなりました。さらに、別リージョンや別 AZ への設計を取り入れやすくなったことで、DR/BCP 対策の強化や事業継続性の向上にもつながっています。 運用効率の改善 監視は Amazon CloudWatch や Amazon CloudWatch Database Insights といった AWS のマネージドサービスに統合され、自社で監視ツールを選定・管理する必要がなくなりました。インフラ担当に頼らず、アプリ開発チームでも環境準備が可能になり、早期の環境構築が実現しました。月次メンテナンス時の再起動も不要になりました。オンプレミスの物理機器保守やハードウェアのライフサイクル対応（リプレイス作業）からも解放され、運用負荷が大幅に低下しました。こうした定型的な運用業務からの解放により、インフラ担当者のモチベーション向上にもつながっています。 データ利活用基盤としての拡張性 AWS 上にデータベースを配置したことで、ETL、分析基盤、AI/ML など AWS の周辺サービスとの連携が容易になりました。データベースを起点とした拡張性が高まり、IT 戦略として掲げるデータ利活用や AI 活用を推進するための基盤が整いました。 こうした効果を踏まえ、今回の AWS 移行についてセガサミーホールディングス株式会社の江田氏は以下のように振り返っています。 「移行により明らかにパフォーマンスが良くなりました。移行後は障害も発生しておらず、インフラ担当者が本来やるべき高度な業務に専念できる環境にシフトすることができました。」 – 江田 英昭 氏　セガサミーホールディングス株式会社 ITソリューション本部 ビジネスシステム部 部長 今後は、クラウドファースト方針のもと AWS のサービスや AI の活用を推進し、Amazon Redshift によるデータ分析をはじめ、グループ全体でのデータ利活用を拡大していく予定です。