AWS Summit Japan 2025 参加レポート

はじめに

こんにちは。WEARバックエンド部SREブロックの春日です。

6月25日、26日の2日間にわたって開催されたAWS Summit Japan 2025に、今年もZOZOのSREが多数参加しました。この記事では、現地の様子とSREのメンバーが各自選んだ面白かったセッションについてご紹介します。

はじめに
AWS Summit Japanとは
会場の様子
セッションレポート
おわりに

AWS Summit Japanとは

www.youtube.com

AWS Summit Japanは延べ4万人以上が参加する日本最大の「AWSを学ぶイベント」です。今年も幕張メッセで2日間にわたり開催され、160以上のセッション、270以上の展示が行われました。ライブ配信も行われ、2025年7月11日までの期間限定でオンデマンド配信が視聴可能です。

aws.amazon.com

会場の様子

多くの参加者で賑わう会場。

今年も先着4000名にお弁当引換券とクッションが配布されました。余ったお弁当は引換券がない方も先着で貰えたようです。

今回ラウンジはAWS認定者だけではなく、誰でも利用可能になっていました。場所はインフォメーションの周りと壁際に沿うように複数に用意されており、多くの人が利用できるようになりました。

1日目の18:10からは基調講演の会場でQuizKnockと直接対決できるAWSクイズ大会が開催されました。全員が参加可能なWeb上での予選を勝ち抜いた上位5人が登壇し、QuizKnockのメンバーと早押しクイズで対戦しました。結果は挑戦者チームの勝利でした。

AWS Builders' Fairでは1日ごとにブースの出展が変わりました。実際に体験可能な展示や動く展示などがあり、楽しみながら学ぶことができました。

サーバーレスで構築されたコーヒー注文システム。定期的に発行されるQRコードを読み取ることで実際に注文が可能でした。

「アーキテクチャ道場2025 - 実践編！」セッションではZOZOTOWNの話も。依存システムの関係ですぐにはDBをオンプレミスからクラウド移行できない制約の元、人気商品によるアクセス集中でもスケールできる設計事例が紹介されました。

誰でも書けるボード。ZOZOのロゴがどこに書かれているかぜひ探してみてください！

正解はここでした。

セッションレポート

ここからは現地参加したZOZOのSREが気になったセッションを紹介します。

生成 AI オブザーバビリティのベストプラクティス（AWS-49）

生産プラットフォーム開発部SREの塚本です。普段は、受注生産の仕組みを提供している、生産支援プラットフォーム「Made by ZOZO」の開発に携わっています。

生成AIを活用したシステムは、既に多くの商用環境で利用されるようになっています。私の部署内でも生成AIを活用したツールの開発が進んでいます。これらのシステムが単に機能するだけでなく、継続的に改善されていくためには、オブザーバビリティ（可観測性）に基づいた計測と分析が不可欠となります。このセッションでは、生成AIシステムを深く計測し、改善していくための階層型アプローチが説明されていました。

このアプローチは4つのレイヤーで構成されています。

コンポーネントレベルのメトリクス

システムの基盤となる各コンポーネントから発行されるメトリクスを活用します。セッションでは、サービスの呼び出しエラー、レイテンシー、リソース使用率などの基本的なメトリクスが紹介されました。また、Amazon CloudWatchの複合アラームを使用することで、集約されたレベルでアラームを設定し、アラートノイズを削減できる点が強調されていました。

RAG、エージェント、チェーントレース

RAG（検索拡張生成）やエージェントベースのアーキテクチャでは、一連のリクエスト処理全体を追跡するトレースが重要です。発表では、ユニークなTrace IDを設定することで、各サービス間での処理の流れを追跡する仕組みが説明されました。特に、OpenTelemetry (OTel) を用いたトレースの伝播がデモンストレーションで紹介されており、複雑なオーケストレーションレイヤーの可視化に有効であることが紹介されていました。

高度な指標と分析

より深いオブザーバビリティとして、高度な指標と分析が挙げられます。Amazon Bedrockのガードレール機能を利用した場合、ガードレールによって制限された結果をメトリクスとして出力し、可視化できます。これにより、設定したポリシーの遵守状況を監視し、必要に応じて調整できます。

エンドユーザーからのフィードバック

最後に、エンドユーザーからのフィードバックをオブザーバビリティのループに組み込むことで、潜在的な問題を早期に発見し、ユーザー体験の改善に繋げます。ここでは、CloudWatch Embedded Metric Format (EMF) を活用し、フィードバックを含むログからメトリクスを自動的に抽出し、評価する方法が紹介されました。これにより、ユーザーの定性的なフィードバックを定量的な指標として捉えることが可能になります。

このセッションは、生成AIアプリケーションの改善アプローチの全体像から、各レイヤーでの具体的なオブザーバビリティの実装方法まで、デモンストレーションを交えながらとても明快に説明されていました。今後、オブザーバビリティによる継続的な改善サイクルを回し、より良いユーザー体験に繋がる生成AIアプリケーションの開発に取り組んでいきたいと改めて感じました。

責任あるAIに向けて: 生成AIアプリケーション評価のアプローチ（AWS-52）

EC基盤開発本部SRE部商品基盤SREブロックの佐藤です。私は「責任あるAIに向けて：生成AIアプリケーション評価のアプローチ」というセッションに参加しました。

セッションのテーマと課題

本セッションの主題は、生成AIアプリケーションを本番環境へ安全にデプロイする際、どのように評価と信頼性を確保するかという点でした。登壇者は、次のような課題を提示しています。

従来のAIモデルは特定ユースケースに最適化されていたのに対し、基盤モデル（FM）は複数ユースケースに対応できる反面、アプリケーション全体の複雑性が増している。
品質を確保しつつ開発速度（アジリティ）も維持する必要があるが、過度な分析や対策をとるとリリースが停滞し、本番環境のインシデント防止とのバランスを取ることが難しい。

これらの課題を解決し、品質とリスクの両面で自信を持つためには、本番デプロイ後も含めた一貫したテストと評価の仕組みを構築することが重要であると強調していました。

セッションのポイント1 生成AIアプリケーション自体の評価方法

生成AIアプリケーションには、従来のアプリケーションにはない「信頼性とリスクが許容範囲内に収まっているか」という評価観点があり、その評価手法として次の3つのアプローチが紹介されました。

アプローチ	概要	主なメリット	主なデメリット
1. 人間による評価（手動）	人間が直接出力を確認し、品質を判定する。	高い精度と信頼性が得られる。	時間とコストが多く、スケールしにくい。
2. 経験則に基づく評価（自動）	機械的に計算可能なスコアリングを用いる手法。	高速・スケーラブル・実行コストが低い。	人間の評価と結果が一致しない場合がある。
3. AIによる評価（LLM-as-a-Judge）	LLMを評価者としてプロンプトする手法。	柔軟に評価観点をカスタマイズできる。	評価モデルのバイアスや推論コストが課題。

経験則に基づく評価、AIによる評価のどちらを選ぶにしろ、人間による評価との整合性を定期的に確認し、キャリブレーション（補正）を行うことを推奨していました。

セッションのポイント2 生成AIアプリケーション構成要素の評価方法

次に、生成AIアプリケーションを構成する3つの要素（基盤モデル・RAG・エージェント）について、それぞれに適した評価手法が紹介されていました。

1. 基盤モデルの評価

評価方法	手法	補足
モデル比較	リーダーボードを利用する。	ベンチマークは自社ユースケースと必ずしも相関しない点に注意。
Bedrockでの評価	Bedrockの「モデル評価」機能を利用。	- 人手評価・経験則メトリクス・LLM-as-a-Judgeから選択可能。 - カスタムインポートモデルも評価可能。
SageMakerでの評価	OSSライブラリ「fmeval」を使用。	独自の評価セットを利用可能。

2. RAGの評価

評価方法	手法	補足
Bedrockでの評価	Bedrock Knowledge Basesの「RAG評価」機能を利用。	検索エンジン単体、または検索＋生成をまとめて評価可能。
高度なカスタム評価	OSSフレームワーク「Ragas」を使用。	Bedrockの評価を使用したうえでチューニングしたい場合に利用。

3. エージェントの評価

評価方法	手法	補足
ユーザーとエージェントとの対話テスト	「agent-evaluation」フレームワーク。	- YAMLでテストケース（ユーザー入力と想定結果）を記述。 - LLM-as-a-Judgeで対話成立を評価。 - CI/CDで実行可能。

セッションのポイント3 信頼性を高める評価戦略

「リスク評価」の観点でリリースの信頼性を上げるために、以下7段階の評価プロセスによる評価戦略が紹介されていました。

ステップ	内容
1. ユースケース定義	扱う情報（例：ヘルスケア、金融など）によって潜在リスクが異なるため、リリースへの影響度を整理する。
2. リスク評価	NIST AI Risk Management Framework に基づきリスクを洗い出す。次に、発生確率と影響度を掛け合わせたリスク評価マトリックスでリスクレベルを決定する。
3. メトリクス選定	評価の目的とリスクに対応するメトリクスを選定する。
4. リリース基準策定	リスク評価マトリックスを基に、どのレベルを満たせばデプロイ可能かを策定する。
5. 評価データセット設計／測定	自動評価と人間評価を組み合わせ、ユースケースに沿ったデータセットを作成して測定をする。
6. 結果の解釈	限られたポイントのメトリクスだけで判断せず、分布や信頼区間を確認し、過度な一般化を避ける。
7. リスク緩和戦略	入力・出力フィルタリングを実施する。Amazon Bedrock Guardrailsは、このフィルタリングを実現するツール。

Bedrock Guardrailsの日本語対応を確認する

セッションでも触れられていましたが、6月25日（AWS Summit初日）にAmazon Bedrock Guardrailsが日本語をサポートした旨がアナウンスされました。

Amazon Bedrock Guardrails announces tiers for content filters and denied topics

アップデート内容と留意点

日本語に対応した機能
- コンテンツおよびPrompt Attackフィルター
- 拒否トピック
日本語に未対応の機能
- ワードフィルター
- 機密情報フィルター
- コンテキストグラウンディングチェック
設定の留意点
- Content Filters tierはStandard Filters Tierを選択する必要がある。
- Standard Filters Tierはクロスリージョン推論が必須となるので、国内リージョン内に処理を閉じたい要件がある場合は留意する必要がある。

日本語フィルタリングの動作検証

クロスリージョン推論（Cross-Region inference）を有効化し、Standard Filtersを指定して「拒否されたトピック」の「定義」を日本語で設定します。

日本語プロンプトでテストを実行したところ、暴力表現を含む質問は「Violence」などのコンテンツフィルターにより拒否されました。

暴力表現を含む質問は「Violence」などのコンテンツフィルターにより拒否される

Prompt Attackや拒否トピックについても同様に、日本語入力でフィルタリングが成功することを確認しました。

まとめ

本セッションを通じて、モデルの精度だけではなく「責任あるAI」という視点が重要であると認識しました。また、評価そのものの信頼性をどのように担保するかについても多くの示唆を得ました。まずは自社サービスのユースケースを整理し、固有の課題を正確に把握したうえで、リスクを継続的に管理する評価戦略を実践する必要があります。弊社ではマイクロサービスをリリースする際に「プロダクションレディチェック」を実施していますが、今回学んだ知見を取り入れることで、生成AIアプリケーション向けの新しいチェックリストとして発展させられると感じました。

AI Agent 時代のソフトウェア開発の型〜 Everything as Code で叡智を伝える〜（AWS-57）

検索基盤SREブロックの花房です。普段はZOZOTOWNの検索関連マイクロサービスにおけるQCD改善やインフラ運用を担当しています。

弊社では現在、業務の効率化を目的とした生成AIの導入が進められています。私自身もソフトウェア開発やシステム運用の効率化のために生成AIの活用に取り組んでおり、その情報収集の一貫として本セッションに参加しました。本セッションで学んだ内容を以下にまとめます。

ソフトウェア開発におけるAIの進化

ソフトウェア開発においてAIは飛躍的な進化を遂げました。コーディング支援のレベルは下記の3つに分けられ、現在のAIはレベル3まで到達しています。

プログラムによるメソッドなどの補完、リファクタリング
AIによるインラインのコード補完、チャットでのコード生成
AI Agentによる自律的な探索、コード修正、テスト

レベル3では人間の詳細な指示が必要ですが、ドライバーをAIに交代できます。AIが進化を続けるとレベル3の先のレベル4に到達すると考えられます。レベル4ではAIのみで長時間の自動運転が可能になると予想されます。そのような未来に備えて、今からAIを中心としたソフトウェア開発の型を身に付けておく必要があります。

AIに自律的に意図通りに動いてもらうには

AIを活用した開発でよくある悩みは、AIが意図通りに動いてくれないことです。AIは確率的に行動を決定しているため常に期待通りの振る舞いをするとは限りません。AIの振る舞いの精度を高めるには指示や制約を言語化して与えておく必要があります。しかし、全ての意図を言語化することは困難です。そこで、言語化できない部分のコンテキストをAIへ伝えるためにコードを利用します。

ここで紹介されたものが「Everything as Code」です。

Everything as code is a software development practice that seeks to apply the same principles of version control, testing, and deployment to enhance maintainability and scalability of all aspects of the development lifecycle, including networking infrastructure, documentation, and configuration. Everything as code - DevOps Guidanceより引用。

人間がソフトウェア開発に関する全てをコードで表現しておくことによりAIが得られる情報は自然に増加します。コードはプレーンテキストであり、AIにも理解しやすい形式であるためです。意図した通りAIに動いてもらうには、上記のようにAIが自律的に必要な情報を探せる状態を作ることが重要です。

組織内でAIの価値を認識させるには

ビジネスの目的はユーザーに多くの価値を届けることです。組織内にAI活用の能力を獲得させることができれば、より多くの価値を届けることが可能になります。しかし、組織内でAI活用の価値を言葉で説明しても受け止め方は人によって様々です。説明を聞いて一部のタスクを完全にAI任せにできる人もいれば、AIを使いこなせていない人も現れます。

言語による説明だけでは価値が伝わらず、時間をかけてマスタして初めて気づく価値は存在します（例：Vimキーバインド、空手）。そのため、今は価値に気づかれないとしても基本の型を組織で続けておくことが重要です。AIを中心としたソフトウェア開発における基本の型は「Everything as Code」です。

感想

AIが意図通りに動かないのはそういうものだと少し諦めており、振る舞いの精度を高められる方法がもしあれば知りたいと思っていました。本セッションに参加したことで、その方法の1つである「Everything as Code」を知ることができました。コードの表現であればAIだけでなく人間同士でも意図を伝えられるため、非常に有用なプラクティスだと感じました。

私も生成AIの活用の推進している中で、口頭での説明だけだと生成AI活用の価値を伝えるには不十分だと感じていました。本セッションを通じて、今は価値を完全に理解されずとも、今後のためにAIを中心としたソフトウェア開発の型を組織で実践しておくことが重要だと認識を改められました。

引き続き、本セッションで得られたプラクティスやヒントを元に生成AIの活用を推進していきたいと思います。

GenU × Amazon Bedrock による実装への挑戦-オイシックス・ラ・大地が実現した 333 時間の工数削減の技術解説（CUS-38）

WEARバックエンド部SREブロックの春日です。普段はWEAR by ZOZOというサービスのSREとして開発・運用に携わっています。私からは「GenU × Amazon Bedrockによる実装への挑戦-オイシックス・ラ・大地が実現した333時間の工数削減の技術解説」というセッションをご紹介します。

メルマガ作成業務の課題

メルマガ作成業務の課題として、以下が挙げられていました。

1回のメルマガにかかる工数が大きい
作成者のスキルによって品質維持が難しい

メルマガを配信するまでにはメルマガ原稿の作成後、法務による表現の校正と原稿の修正作業が繰り返し発生します。表現の校正というのは例えば、「業界No.1」「ダイエットに効果的」といった、景品表示法や薬機法によって禁止されている表現がされていないか確認しているとのことでした。こういった校正作業により工数がかかるようです。

生成AIを活用したメルマガ作成PoCとそこで見えてきた課題

コンテンツ生成が得意である生成AIを活用し、メルマガ作成業務における工数を削減しつつ品質を維持できないかと考えます。生成AIを用いてメルマガを作成するPoCを行ったところ、生成AIが作成したメルマガの方がCVRが上がったとのことでした。PoCはGenerative AI Use Cases(GenU)を用いて行われました。GenUは生成AIを活用する環境構築を1クリックで行えるアプリケーションで、Web UIから簡単にAmazon Bedrockを使用できます。

しかし、デフォルトのGenUを使用するだけでは、いくつか課題が見つかりました。

メルマガの内容は毎回変わるためメルマガ生成プロンプトの作成難易度が高く、結局人間が原稿を作成するのと同じくらいの時間がかかる
景品表示法や薬機法にかからないような、メルマガ専用の校正機能が必要

これらの課題を解決するために、GenUをカスタマイズすることになりました。

GenUのカスタマイズ

GenUにメルマガ作成機能とメルマガ校正機能を追加します。メルマガの文章構成はある程度決まっていることから、動的部分だけを入力すれば自動でプロンプトが生成されるようになっています。また、過去のメルマガのサンプルを複数用意して参考にするようにプロンプトで指示することでも構成を踏襲させているようです。ここのサンプルの選定に偏りがあると、おせちの内容でも夏を感じる文章になってしまうなど意図しない出力がされてしまう課題があったようでした。これはサンプルの選定を季節に依存しないものへすることで改善されたとのことです。

メルマガ校正機能も生成AIを用いて実装されています。社内ドキュメントで管理されている表現チェックリストを用いて、プロンプトにNG表現や言い換えを組み込むことで検出します。NG表現に似たニュアンスの問題ない表現もNGとして検出されてしまうことがあったため、チェックリストに「完全一致する場合のみ」指摘するようにプロンプトを調整することで改善されたとのことでした。

フロントエンドもデフォルトのものからReactで自前実装されています。動的な入力事項の必須項目化や、追加項目の折りたたみ表示、NG表現とOK表現の色分けなど、UI/UXの改善が行われています。手間をかけてでもユーザ体験を向上させたい場合は、追加実装がおすすめとのことです。

結果

結果として、1か月あたりのメルマガ作成工数が133時間、校正の工数が200時間削減され、合計333時間の工数削減に成功したようです。また、人が作成したメルマガに比べてCVRが200％向上したとのことでした。品質の担保や特定社員の負荷軽減も成功したとのことでした。

セッションの感想

人が作成したメルマガに比べ、生成AIによって作成された方が200％もCVRが向上したというのは驚きでした。また、メルマガ生成部分と校正部分の2軸でそれぞれ生成AIを活用するという部分が特に印象的でした。一度で完璧なメルマガを生成するよりも、それぞれで特化したプロンプトを用意する方が効果的なのかもしれません。プロンプトチューニングのTipsもあり、非常に参考になりました。今回学んだ内容を業務にも活用していきたいと思います。

AIを使う？ AIに使っていただこう。AI が考えた次の⾏動と実アクションの実践的Agent アプローチ（AWS-55）

フロントSREブロックの江島です。ZOZOTOWNのエンドユーザーに近い部分（フロントエンド、BFF等）を担当領域としています。また、全社のAWS管理者としての役割も担っています。

内容

今年のAWS Summitも昨年度に引き続いて生成AIに関するセッションが盛り沢山でした。一方で、私自身は生成AIの技術に関するキャッチアップが十分に出来ていないと感じていました。そこでこの2日間は生成AI関連のセッションに注力する姿勢で臨みました。

その中でも今回は「AIを使う？　AIに使っていただこう。AIが考えた次の⾏動と実アクションの実践的Agentアプローチ」というセッションについてまとめたいと思います。

LLMには最新情報にアクセスできないという課題があります。LLMは大量の学習によって過去に何が起きたのかは知っていますが、学習後に生じた最新情報にはアクセスできません。一方で、LLM単体では直接回答できない情報であっても、答えに辿り着くためのアプローチは提案できます。そこで、LLMの持つ課題を解決するために、LLMにツールを持たせるという考え方が生まれました。

しかし、LLMにツールを持たせる際には、以下のような課題が発生します。

ハルシネーション（ツールを使用していないにもかかわらず、使用したかのように応答すること）
ツールの情報漏洩（LLMが利用可能なツールを漏洩し、悪用される可能性があること）
不定な応答フォーマット（LLMの応答テキストの中からツール実行に必要な情報を正確にパースすることが難しいこと）

これらの課題を解決するために、Tool Use専用の構文を使うアプローチが採用されました。Amazon Bedrockではこの機能がTool Useとして提供されており、以下の3つの特徴を持っています。

ユーザーメッセージやシステムプロンプトと分離したTool専用の引数：ツールを漏洩したり、ハルシネーションを防いだりするのに役立つ
Tool利用時は通常のテキストレスポンスとは分離された出力：ツール使用時のパースが容易になる
Tool実行結果も分離して入力：Tool実行結果のLLMによる解釈が容易になる

このTool Useは以下のようなフローで処理が実行されます。大まかには、利用可能なツールとその使い方をあらかじめLLMに定義しておき、LLMがツールの実行を指示しなくなるまでツールの実行とその結果のモデルへのフィードバックを繰り返すという流れです。

このセッションのタイトル「AIを使う？AIに使っていただこう」に関連して、発表者からは、エンジニアの視点ではAIを直接使うというよりも、AIにツールを使ってもらうための「下準備」（ツールの開発や説明など）をすることが重要であるという点が強調されました。これは最近話題となっているMCP等の技術にも共通する考え方です。

さらに、ツールを用いることで生成AIアプリケーションをエージェントとして動作させる上で、どこまでをエージェントに任せるか（人間の介入度合い）を検討することが非常に重要であると説明されました。介入の度合いは、「必ず人間が介入」「部分的にAgent」「全部Agent」の3段階で考えられ、ユースケースに応じて適切なバランスを見つけることが推奨されます。

このようなエージェント開発をより容易にするため、AWSはAmazon Bedrock Agentsという機能を提供しています。Amazon Bedrock Agentsは、LLM、ツール、Knowledge Basesの間でオーケストレーターとして機能し、開発者の負荷を低減します。

感想

このセッションを聴講することで、まずLLMが不得意とすること（特に最新情報へのアクセスと推論の精度）を深く理解できました。また、それらに対してツールという解決策が提唱され、そこから様々なことをAIにやらせようというエージェント化の流れに繋がっているんだということが整理できました。

AWSが提供しているBedrockのTool Use機能を用いた実装の流れを知ることで、Agentとして働く生成AIアプリケーションが思考を繰り返す流れを具体的に理解できました。今回学んだ内容を通じて、実際の業務でも生成AIアプリケーションを使った業務改善に取り組んでいきたいと感じました。

SmartNews における1000+ ノード規模 K8s 基盤でのコスト最適化 – Spot・Graviton の大規模導入への挑戦（CUS-33）（CUS-33）

フロントSREブロックの徐です。ZOZOTOWNのエンドユーザーに近い部分（フロントエンド、BFF等）を担当領域としています。

SREにとって、インフラの信頼性を守ることと同じくらい重要なのが、持続可能なコスト管理です。日々の運用の中で、どこまで効率的に、そして大胆にコスト削減に挑めるかは常に意識すべきテーマだと感じています。今回ちょうどスマートニュース社がこのテーマで登壇するセッションがあったため、その取り組みを知りたいと考え、参加しました。

背景：成長とともに増大したインフラコスト

スマートニュースでは、大規模なEKSクラスター上にFlink、Kafka、ClickHouseなどのプラットフォームを構築し、機能開発を重視してきました。しかしその結果、ユーザー数の増加以上のスピードでコストが増大し、体系だったコスト管理が必要なフェーズに突入しました。リソース使用量が全体の50％以上に達していたことを受けて、インフラとプロダクトを横断する形でコスト最適化プロジェクトが立ち上がりました。

戦略：動的かつ柔軟なリソース運用へ

Reserved InstanceやSaving Planといった固定的なコスト対策だけでは、トラフィックの変動や将来的な成長に対応するには不十分でした。スマートニュースでは、柔軟性と機動力を重視したアプローチとして、スポットインスタンスの活用を全社的に推進し、Gravitonアーキテクチャの導入を段階的に拡大しています。また、EKSクラスターのスケジューラーにはKarpenterを採用し、要件に応じて改修を加えることで、高速かつ安定したスケーリングを実現します。これらの取り組みの効果を定量的に把握するため、コストやリソース使用状況を可視化するダッシュボードも構築されています。

技術課題と解決アプローチ

スマートニュースが直面した技術的課題は、成長に伴うインフラコストの増加に加え、スポットインスタンスやGraviton導入に対する開発側の不安、そして複雑なスケジューリング設計への対応でした。この課題に対し、スマートニュースではインフラチームとプロダクトチームが連携し、社内セッションによる知識の底上げを行うとともに、サービスごとのSLAや中断対応方針の整理を進めました。加えて、Karpenterの改修によってスケーリング性能の最適化を図り、可視化ダッシュボードの整備を通じてコスト構造の把握と運用判断の精度向上にも取り組んでいます。

Karpenterのカスタマイズでスケーリング最適化

スポットインスタンスの活用には、柔軟かつ高速なスケジューリングが不可欠です。Karpenterの導入にあたり、スマートニュースでは複数のカスタマイズを施しました。具体的には、CPU使用率が閾値を下回った場合にスケールインを行う制御や、処理済みのペンディングポッドが存在する場合には一定時間スケールアウトを抑制する仕組みを実装。また、スポットインスタンスの中断通知をトリガーとして即座に新しいノードを立ち上げることで、スケールアップにかかる時間を6分から3分へ短縮することに成功しました。

可視化による納得感の醸成

コスト最適化を組織として進める上では、関係者全員で納得できる透明性が欠かせません。スマートニュースでは、リアルタイムに利用状況とコスト構造を把握できるダッシュボードを構築しています。サービスごとのスポットインスタンスとオンデマンドインスタンスの使用比率やコスト推移をはじめ、スポットの中断発生やキャパシティ不足の頻度、各インスタンスタイプのリソース利用効率なども可視化されており、運用判断や改善サイクルの精度向上に貢献しています。

スポットの安定運用に向けた仕組み

スポットインスタンス利用時にオンデマンドインスタンスへ自動的にフォールバックしてしまう課題に対応するため、スマートニュースでは安定運用を実現するための仕組みを構築しました。まず、PreferSpotというラベルを導入することで、Podが可能な限りスポットインスタンスで起動されるよう明示的に指定しています。

仮にスポットインスタンスのキャパシティが確保できず起動に失敗した場合でも、一時的にオンデマンドノードで代替的に起動させることで可用性を担保します。そのうえで、一定時間が経過するとオンデマンドノードは自動でシャットダウンされ、再度スポットインスタンスでの起動を試行するように設計されています。このようにして、コストと可用性のバランスを取りつつ、スポットの安定活用を促進しています。

プロダクトチームとの連携による推進力

単なるインフラ最適化にとどまらず、プロダクトチームと密に連携しながら推進力を高めてきました。まず、VPの支援のもとで専任のタスクフォースを設置し、役割と権限を明確化することで迅速な意思決定を可能にしました。

また、ダッシュボードを通じてサービス単位や技術レイヤ単位でのコスト構造を可視化し、関係者全体のコスト意識を醸成しました。さらに、Javaのバージョン変更やシャットダウン処理の最適化など、比較的短期間で効果が見込めるQuick Win施策を積極的に展開したことで、主要コンポーネントにおいてスポット利用率が90％を超える成果を上げることができました。

最適化の成果

モニタリングシステム：100％スポットインスタンスへ移行
ランキングシステム：80％以上スポット化
MLインファレンス：100％スポット + 100％ Graviton
全体のGraviton使用率：40％以上

まとめ

今回の発表を通じて、スポットインスタンスやGravitonの導入、Karpenterの柔軟な活用が、単なるコスト削減にとどまらず、組織全体の技術成熟度を高めることにつながると実感しました。

特に可視化やSLAの整備によって、現場の納得感と判断の質が大きく向上していたのが印象的です。コストはSREにとって避けては通れないテーマであり、今後も技術と仕組みの両輪で継続的に向き合っていきたいと感じました。

おわりに

オンラインでもセッションの視聴は可能ですが、実際に身体を動かすデモや現地のエンジニアとの交流など、現地参加ならではの体験もAWS Summitの魅力の1つです。今回得たたくさんの知見を今後の業務にも活用していきたいと思います。

ZOZOでは来年開催されるAWS Summit Japan 2026に一緒に参加してくれるエンジニアを募集しています。ご興味のある方は、ぜひ以下のリンクからご応募ください。

corp.zozo.com

それではまた来年のAWS Summitでお会いしましょう！

TECH BLOG