はじめに
こんにちは、株式会社 Techouse でエンジニアをしている ReLU、AsagaKosho、miyatis、Kai です！ 2025年6月25日、26日に開催された AWS Summit Japan 2025 に参加してきました！
弊社からは、総勢 15 名のエンジニアが参加しました！ 日々の業務で利用している AWS の最新情報をキャッチアップするとともに、AWS コミュニティの熱気をダイレクトに体感してきました。
今回は特に印象に残ったセッションやブースを紹介します。
イベント概要
AWS Summit Japan は日本最大級の「AWS を学ぶイベント」で、AWS やそのパートナー企業が最新の活用事例やサービスについて、セッションやブースを通じて情報を共有するイベントです。
今年の来場者数はなんと 40,000 人超、AWS セッション・事例セッション・パートナーセッションをあわせて 160 以上、ブースの出展数は 270 以上 という、国内でも最大級の Tech イベントと言えるでしょう。
AWS セッションとパートナーセッションについては2025年7月11日まで期間限定でオンデマンド配信の視聴が可能です。参加出来なかった方や聞き逃したセッションがある方はぜひご確認ください！
会場・全体の雰囲気
会場は朝早くから非常に盛り上がっておりました。我々は朝から参加していたのですが、会場最寄りの海浜幕張駅は参加者で大賑わいとなっておりました。会場はオープン前から長蛇の列ができており、参加者の皆さんの熱い眼差しからAWSに対する並々ならぬ情熱を感じました。
会場にはスポンサーブースが所狭しと立ち並び、国内のスタートアップから大企業まで、多くの企業がサービスを出展していました。特に、初日の基調講演で日本拠点の設立を発表した Anthropic 社のブースはひときわ混雑しており、その注目度の高さがうかがえました。
そして何と言っても、QuizKnock さんの AWS 早押しクイズ対決が最高に盛り上がっていました！ 会場の一角に人だかりができ、正解が出るたびに歓声が上がる様子はスポーツ観戦のような熱狂ぶりでした！
展示ブース
展示ブースは各社趣向を凝らしたブースで大賑わいでした。 その中でも特に印象に残ったブースを取り上げさせていただきます。
山岡家のオペレーション
実は、ラーメンチェーン店の山岡家は AWS のサーバーレスサービスでオペレーションを組んでいるそうです。
素早い注文の提供と美味しさの秘訣は AWS にあったんですね。サーバーレスアーキテクチャを活用することで、コスト削減と運用負荷の軽減を実現しているそうです。
山岡家公式の X（旧 Twitter）アカウントが面白い投稿をしていたので取り上げさせていただきます。
AWS に障害が起きたら山岡家は麺が茹でられなくなるのでは、とご心配をおかけしております。 が、山岡家はそんなヤワじゃありません。日頃のトレーニングと代替手段で問題なく乗り切る体勢を構築しています。 公式ツイートより引用
実物の Graviton プロセッサ
AWS Graviton とは、AWS が独自開発した ARM ベースのプロセッサです。 Amazon Elastic Compute Cloud（Amazon EC2）で利用することができ、他のプロセッサと比べて処理性能が高くコストパフォーマンスが高いプロセッサです。
AWS のデータセンタで管理されているため、普段は絶対にお目にかかれないものですが、なんとブースの展示品として飾られていました。 普段はマネジメントコンソールでボタンをクリックするだけでインスタンスを起動できますが、実際に実物を見ると「これが実際に動いているんだ」という実感が湧き、少し感動しました。
ノベルティがいっぱい！！！
各企業ブースを巡るノベルティハンティングが最高に楽しかったです！
ステッカーや、ボールペン、オリジナルTシャツなど、各社のクオリティの高いグッズばかりでした。どれも「これ、本当にタダでもらっていいの？」と思うほど素晴らしいものでした。
また、AWS startupsのブースでは、「Energy Drink Bar」と称して、エナジードリンクの配布も行われていました。疲れた参加者にエナジードリンクを無料配布するという神サービスで午後の疲れも一気に吹き飛びました。
印象に残ったセッション・技術トピック
Amazon Connect 関連セッション
担当事業との関連性が高いことから、私(Kai)は Amazon Connect 関連セッションを重点的に聴講しました。本年はAWSセッションとスポンサーセッションを合わせ、Amazon Connectに関する3つのセッションが開催されました。本稿では、各セッションの概要を時系列でご紹介します。
かんぽ生命のコンタクトセンターを AWS 技術で刷新。安定した WebRTC を追求し、フルクラウド化に挑戦
本セッションでは、かんぽ生命保険様が年間400万呼・1000席規模のオンプレミスコンタクトセンターをAmazon Connectへ移行した事例が紹介されました。特に印象的だったのは、移行プロジェクトで直面した障害の原因調査と、大規模な負荷試験に関するエピソードです。
PoC段階で発生した「PC起動後の初回通話においてオペレーター側の音声が途切れる」という重大な障害は、OSやデバイスドライバに起因するものでした。WebRTCのコネクション確立時に特定のサービスがNICのミニポートドライバーを再起動させ、結果としてUDPポートが閉塞していたと報告されました。セッションでは数枚のスライドでの言及のみでしたが、原因特定が極めて困難な調査であったことがうかがえます。
また、1000同時通話を要件とするCRM連携の負荷試験についても非常に興味深い話をきくことが出来ました。EC2とLambdaを用いて顧客とオペレーター双方のトラフィックを模擬的に再現し、大規模な負荷テストを実施したとのことです。基幹システムのクラウド移行におけるテストの重要性と、その実現のためにクラウドネイティブな技術を駆使するアプローチに、改めてその規模の大きさを実感させられました。
詳しい内容についてはぜひ発表資料をご確認ください。
Amazon Connect で実現するカスタマーセルフサービスの新しいカタチ
こちらのセッションでは、Amazon Connectを活用した「カスタマーセルフサービス」の体験構築手法が解説されました。顧客が自己解決できるセルフサービスの需要は高まり続けており、企業にとってもコスト削減や顧客満足度向上といった大きなメリットがあります。
セッションでは、その実現手段としてAmazon Connectが紹介されました。特に、GUIベースのフローデザイナーは、専門的な知識がなくとも顧客ごとにパーソナライズされた体験を素早く構築できる点で、非常に強力なツールです。この俊敏性は改善サイクルを高速化し、継続的な顧客体験の向上に直結すると考えられます。
さらに、Amazon Q in Connectについても紹介がありました。顧客の利用状況や行動履歴を把握した上で対話を開始できるため、よりスムーズで質の高いサポートが期待できます。Q&Aの自動応答や一次対応の担い手として、十分に有用な手段であると感じました。
こちらも詳しい内容については発表資料をご確認ください。
コールセンターだけじゃない！エネルギー業界に学ぶ、Amazon Connect の活用パターン
本セッションでは、エネルギー業界におけるAmazon Connectのユニークな活用事例が紹介されました。特に興味深かったのは、「チェックリストの自動更新」と「アラートとオンコールシフト管理」の2つのユースケースです。
1つ目は、応対時のチェックリスト自動更新です。通話音声をAmazon Kinesis Data Streams経由でリアルタイムに連携し、DynamoDBに保存します。その後、LambdaがBedrockを呼び出して会話内容を解析し、チェックリスト項目が達成されていると判断された場合、対応するDynamoDBテーブルのステータスを更新します。これにより、オペレーターの手作業によるチェックリストの更新が不要になり、抜け漏れ防止と応対品質の向上が可能になります。
2つ目は、異常検知時のアラートとオンコール管理です。電力需給をAmazon EventBridgeによるLambdaのポーリングによって監視し、異常があればAmazon Connectのフローを起動します。フローはLambdaを介してDynamoDBに保存されたオンコールシフト表を参照し、担当者に自動で架電を行います。応答がない場合はリストの次の担当者に架電を繰り返すことで、異常検知時に確実に担当者をアサインすることが出来ます。Amazon Connectの持つ柔軟性の高さを示す好例であると感じました。
こちらもぜひ発表資料をご一読ください。
総括
3つのセッションを通じて、Amazon Connectが持つ多様なユースケースと、その適用範囲の広さを改めて認識することができました。 今回得られた知見を活かし、自社のコンタクトセンターにおけるさらなる顧客体験向上に繋げていきたいと考えています。
Amazon Aurora DSQL アーキテクチャー詳細
私(miyatis) は Amazon Aurora DSQLに関するセッションについて紹介します。自社で開催されている「エンジニア勉強会」でも学んだ楽観的トランザクションの話が興味深かったため、取り上げさせていただきます。
Amazon Aurora DSQLはサーバレスの分散型SQLデータベースです。従来のDBとの最も大きな違いは、アクティブ-アクティブ マルチリージョンで動作し、リージョン間で強い一貫性を保つことができる点です。
一般的にはトランザクションの分離性 (Isolation) を実現のためにはロックを使います。トランザクションの開始時に更新するテーブルに対してロックをかけることで、同時に実行している他のトランザクションがテーブルが読み取り/書き込みできなくなります。これにより、複数のトランザクションを同時に実行しても、データの整合性を担保することができます。
しかし、マルチリージョン環境でロックを取る場合、ネットワーク遅延が問題になります。トランザクション内の各ステートメントにおいてテーブルにロックがかかっているかどうかをチェックする必要があり、その度に他リージョンとのネットワーク遅延が発生し、クエリの実行時間が増大してしまいます。
これを解決するために、DSQLでは「楽観的トランザクション」という方針を採用しています。楽観的トランザクションとは、競合が起こっていない前提で処理を進め、コミットの直前だけ競合の有無をチェックするという「楽観的」な制御のことです。
DSQLのアーキテクチャを用いてこれを解説します。各リージョンにおけるDBは4つのコンポーネントから構成されます。
- Query Processor: クエリを処理する部分
- Adjudicator: 複数の書き込みトランザクション間の競合をチェック
- Journal: データベースの変更内容をストレージに書き込む前に記録するログファイル
- Storage: 実際のデータが格納されているストレージ
https://pages.awscloud.com/rs/112-TZM-766/images/AWS-43_Databases_AWS-Summit-JP-2025.pdfpages.awscloud.com
書き込みトランザクションが発生した場合、QueryProcessorでクエリを処理し、Adjudicatorによって競合のチェックが行われます。競合がなければ、Journalに変更差分を書き込み、コミットが完了します。この際、コミットの直前だけ競合チェックすればよいので、リージョン間のやりとりは1回で済み、ネットワーク遅延の影響を最小化できます。
では、競合チェックはどのように行なっているのでしょうか。DSQLでは開始時のタイムスタンプが早いトランザクションを優先しています。つまり、Adjudicatorはコミット前に他リージョンのAdjudicatorに対して、自身のタイムスタンプよりも早いトランザクションが存在するかを確認します。存在しなければコミットし、存在する場合はロールバックすることになります。
しかし、この方法を実現するには、マルチリージョン間で高精度の時刻同期が必要です。AWSはこれをどうやって実現しているのでしょうか。AWSはAmazon Time Syncというサービスにより、衛星接続の原子時計を使用することで、これを実現しています。さらに詳細を知りたい方は、AWSの公式リファレンスをご参照ください。
アーキテクチャ道場
Asagaが聴講したセッションで最も印象に残っているのが、「アーキテクチャ道場 2025 - 実践編！」です。 アーキテクチャ道場では、現実世界における問題解決の事例を2つ挙げて、優れたアーキテクチャ設計について紹介されました。
お題１ 〜ZOZOTOWNの在庫DB更新〜
まず1つ目は、ZOZOTOWNにおけるカート投入時の在庫引当てによる在庫DBの更新がお題でした。
サイトをオンプレミスからAWS Cloud上に移行するプロジェクトが進んでいましたが、在庫DBは業務上の制約もありクラウドへの移行が困難です。また、サイトの性質上、大量のリクエストが発生し、DBの過負荷が課題となっていました。
これらの課題を解決するため、まずはフェーズ１として、キューイングシステムを構築するとともに、通常商品と過熱商品でキューを分けることにより、負荷分離が実現されました。
フェーズ２では、在庫数のみをAWS上のキーバリューストアに切り出し、DBへの参照・更新による負荷の軽減が図られました。
これらの取り組みにより、従来の5倍以上のカート投入リクエストがあっても、安定してシステム稼働を続けることができるようになったそうです。
また、このお題を通しての実践知として、「進化できるアーキテクチャにする」ということが掲げられていました。これのポイントとしては、「変化しやすいこと」、「適した変化の⽅向性が判断できること」、「変化すべきタイミングが判断できること」があります。
私たちの業務の中でも、「進化できるアーキテクチャ」を意識して、設計をしていかなければなと改めて感じました。
お題２ 〜地方銀行の勘定系システムのAWS上での構築〜
2つ目は、地方銀行の課題を解決するための、複数の地方銀行が共同で利用できる次世代バンキングシステムの構築がお題でした。
高い信頼性の基準や、業界特有の通信方式もあり、単純にAWS上で同じシステムを構築すれば問題ないといったことはありません。このセッションでは特に大きなテーマとして、RTO（目標復旧時間）に対する課題解決について紹介されていました。
具体的には、ノードやAZ（アベイラビリティゾーン）の障害では1分以内の復旧、リージョン障害では1時間以内の復旧がRTOとして設定されています。 詳細な内容についてはここでは割愛しますが、実際にこれらの要件を満たすシステムが構築され、定期的に障害発生時の対応の訓練も実施されているとのことです。
常に高い信頼性が求められる金融システムならではの要件を満たすために、考え抜かれたシステム構成で感銘を受けました。
詳しい内容については、発表資料をご覧ください。
おわりに
今回 AWS Summit Japan に初めて参加して、改めて AWS エコシステムの広がりと技術の進歩を実感することができました。 今後も AWS Summit Japan のみならず様々な技術カンファレンスに現地参加したいと思います！
最後に、弊社参加者の集合写真で締めさせていただきます。
Techouseでは、社会課題の解決に一緒に取り組むエンジニアを募集しております。 ご応募お待ちしております。
