はじめに 株式会社セガは、家庭用ゲーム機、PC、スマートフォン向けゲームの企画・開発・販売・運営を軸に、各種コンテンツや商品を全世界へ届けています。同社では、比較的新しい技術も積極的に取り入れる文化のもと、複数タイトルで AWS を活用してきました。 本記事では、同社が開発・運用する『ソニックランブル パーティ』のバックエンドに Amazon DynamoDB と Amazon ElastiCache Serverless for Valkey を採用した経緯・技術的な工夫・得られた効果を、開発チームの声を交えて紹介します。 ※本画像は株式会社セガの許諾を得て掲載しています 『ソニックランブル パーティ』は、Dr.エッグマンが作り出したおもちゃの世界で、「ソニック」シリーズの人気キャラクターたちがスリリングな障害物コースや競技アリーナで競い合うマルチプレイパーティーゲームです。スマートフォンと PC のクロスプレイに対応し、2024 年初頭に一部地域でソフトローンチを行い、2025 年 11 月にグローバルローンチを迎えました。 解決したかった課題 グローバルに展開する Games as a Service（GaaS）のバックエンドを、少人数のチームで開発・運用できるようにすること。これが本タイトルの大前提であり、データベース選定でも最優先の要件でした。マネージドサービスを最大限活用し、インフラ運用の負荷を極力排除する方針のもと、データベースには次のような要件がありました。 グローバル規模でスムーズにスケールできること ：需要が読みにくいグローバル展開では、トラフィックの伸びに安定して追従できることが必要でした。Amazon Aurora では、API サーバーを増やすほど、各サーバーが保持するコネクションプールの分だけ DB への接続数が積み上がり、DB の接続数の上限が API サーバーのスケールの制約になりやすい構造がありました。 リソースのサイジング・管理からの解放 ：ストレージ容量・CPU 性能のサイジングや、ユーザー分割（シャーディング）に伴う複数クラスターの運用といった、リソースを自分たちで管理し続ける作業そのものをなくし、キャパシティを気にせず開発に集中したいという要望がありました。 データ量が増えても安定したレイテンシー ：数千万人規模のデータを持っても、応答性能（レイテンシー）が変わらないことが求められました。 稼働の波・スパイクへの対応 ：ローンチ時のトラフィックが読みにくく、また「最初は大きく構え、後から縮小できるようにしておきたい」というゲーム業界特有の事情に、無駄なく追従できることが重要でした。 なぜ DynamoDB / ElastiCache Serverless for Valkey を選んだのか DynamoDB 採用の決め手 複数のデータベース／クラウドサービスを比較検討したうえで、DynamoDB を採用しました。前述の課題を踏まえ、次の点が決め手となりました。 サーバーレスで、実質無制限のスケーラビリティを持つこと メンテナンスウィンドウやバージョン管理を意識せず、運用し続けられること 接続数・ストレージ・CPU といったリソース管理から解放されること ElastiCache Serverless for Valkey 採用の決め手 メインデータベースである DynamoDB への読み取り負荷を抑え、レイテンシーとコストを最適化するために、インメモリのキャッシュ／データストアとして ElastiCache を採用しました。ElastiCache は当初 Redis OSS エンジンのノードベース構成で構築を開始し、その後 Redis OSS 互換の Valkey エンジンによる Serverless 構成へ移行しました。Serverless を選んだ決め手は次の点です。 ノードベースのクラスターモードで必要だったシャードやクラスターの構成・管理から解放され、少人数チームでも運用できること 「立ち上げ時は大きく構え、ローンチ後は規模に合わせて縮小・最適化していく」というゲーム特有の需要変動にキャパシティが自動で追従し、過剰なリソースを抱えずに済むこと 冗長化構成を自分たちで設計・管理しなくても、高可用性が標準で備わること アーキテクチャ概要 主要なコンポーネントと役割は次の通りです。 Amazon DynamoDB（メインデータベース） ：主要なゲームデータを格納する永続データストア。ユーザーデータ（プロフィール・所持アイテム・進行状況等）とログデータ（行動ログ）を、基本的にシングルテーブル設計で管理しています。 Amazon ElastiCache Serverless for Valkey（キャッシュ／リーダーボード） ：ユーザーデータのキャッシュ、マッチメイキング処理の作業データ、リーダーボード（Sorted Set）などに利用。用途別に汎用の Common とリーダーボード専用の Ranking の 2 つに分けています。 Amazon ECS on EC2（API サーバー） ：API・マッチメイク・行動ログ集計加工の各アプリを配置しています。 Amazon EKS Auto Mode + Agones ：専用ゲームサーバーを管理しています。なおこちらの詳細は別記事 「株式会社セガ、グローバル展開タイトル『ソニックランブル パーティ』を少人数チームで支える Amazon EKS Auto Mode × Agones 活用事例」 にてご紹介しています。 技術的に工夫した点 1. シングルテーブル設計とキー設計 チームはこれまでリレーショナルデータベース（RDB）の Aurora が中心で、DynamoDB の知見はほぼゼロからのスタートでした。DynamoDB は RDB のように join や任意条件での柔軟なクエリができません。RDB でもインデックス設計は行いますが、DynamoDB では、想定するアクセスパターンに合わせてキーや GSI（グローバルセカンダリインデックス）、データを非正規化してどう持つかまで含めて先に設計する必要があり、アクセスパターンがデータモデルそのものを規定します。本タイトルはユーザーデータ・アカウント・フレンド・ギルド（クルー）・ランキングなどエンティティが多く、かつ各エンティティに複数の検索軸（ユーザー ID・アカウント ID・フレンドコードなど）が必要でした。 そこで、全エンティティを 1 つのテーブルに集約するシングルテーブル設計を採用しました。各アイテムのキーに「エンティティ名」の接頭辞を付けて名前空間を分離し、検索軸は汎用的な GSI をエンティティ横断で使い回す設計としています。 たとえばアカウントデータのキー設計は次のようになっています。 キー 型（命名ルール） 具体例 用途 PK {エンティティ名}#U{ユーザーID} AccountDataEntity#U0001 ユーザー ID で引く（基本アクセス） GSI1 {エンティティ名}#A{アカウントID} AccountDataEntity#A5555 アカウント ID で検索 GSI2 {エンティティ名}#F{フレンドコード} AccountDataEntity#F9999 フレンドコードで検索 GSI3 {エンティティ名}#T{引き継ぎID} AccountDataEntity#T1234 引き継ぎ ID で検索 ※「具体例」は実際の値のイメージです。 参照時は、同じ GSI に対してエンティティ名付きのキーを指定するだけです。たとえば GSI1 は、アカウント検索にもギルド（クルー）検索にも同じ 1 本を使い回します。 例 1：アカウント ID 5555 のアカウントを引く Query (index = Gsi1, P1 = "AccountDataEntity#A5555" ) 例 2：同じ GSI1 で、今度はギルド（クルー）”Dragons” を引く Query (index = Gsi1, P1 = "CrewEntity#Dragons" ) このように、少数の汎用 GSI をエンティティ横断で使い回すことで、インデックスの本数を抑えつつ、多様な検索軸に対応できます。RDB 中心だったチームにとっても、移行そのものは想定より円滑に進みました。一方で、GSI を使いこなせるようになるまでには数か月を要し、負荷試験時に GSI のキャパシティ不足に気づきにくいといった学習コストもありました。 2. トランザクションを使わず楽観ロック中心の設計 コストと性能を考慮し、トランザクションは採用せず、楽観ロック中心の設計としました。実装には、AWS SDK のオブジェクト永続化モデルが備えるバージョン属性による楽観ロックを利用し、必要な場面では SkipVersionCheck（バージョンチェックの無効化）を使い分けられるよう、データアクセス層を設計しています。 一方、ギルド（クルー）機能のように複数ユーザーが同一データを同時に更新する機能では整合性の担保が重要になるため、そうした箇所では Valkey によるロックを用いて競合を防いでいます。 3. リーダーボードのホットキー対策 ランキングは、ElastiCache（Sorted Set）でライブに集計・配信する一方、スコアはユーザーデータとして DynamoDB にも永続化しています。この DynamoDB 側のランキング用 GSI では、同一のランキング（単一のパーティションキー）に多数のプレイヤーの書き込みが集中し、特定のパーティションがホットになりやすいという課題がありました。 そこで、ランキング用 GSI のパーティションキーにユーザー ID の下 4 桁によるシャード分割（P1 = …#Shard{ユーザーID下4桁}）を導入し、書き込みを複数のパーティションに分散しています。ランキング全体の参照時は、集計タスクで各シャードを集約する構成です。 一方、キャッシュ側の ElastiCache Serverless にも同種の考慮が必要でした。ElastiCache Serverless は常にクラスターモードで動作するため、同一スロット制約を踏まえ、マルチキー操作は関連するキーを同一ハッシュスロットに寄せる（ハッシュタグを使う）キー設計が求められます。その分キーが偏る（ホットスロット化）リスクもあるため、トレードオフを意識する必要があります。本タイトルでも、設計当初にこの点を意識しておくとよいという気づきがありました。 4. グローバルローンチの急なトラフィックへの対策 2025 年 11 月のグローバルローンチは、トラフィックが読みにくい最大の山場でした。事前の暖機（ウォームアップ）として、次の対応を行いました。 DynamoDB ：Warm Throughput を利用し、マネジメントコンソールから必要なスループットを引き上げるだけで暖機が完了しました。手動でのプロビジョンドスループット調整（引き上げ後にオンデマンドへ戻す運用）と比べ、手間を大きく削減できました。 ElastiCache Serverless ：ローンチ前に最低 ECPU を設定するだけで事前に暖機できました。ローンチ後は通常運用に戻すのみで、キャパシティ調整の手間は最小限で済みました。 結果として、読みにくい急なスパイクにも問題なく追従できました。 AWS の技術支援 本タイトルの設計・実装にあたっては、AWS の技術支援プログラムである DynamoDB Immersion Day と、DynamoDB DCAD（Database Clinic in A Day）を通じて、数日間にわたる DynamoDB の勉強会・ハンズオンを実施しました。あわせて、Solutions Architect による設計相談・アーキテクチャレビュー・キー設計レビューも行っています。 特に効果が大きかったのは、次の点でした。 勉強会に社内の複数部署が参加したことで、「シングルテーブル設計」について複数の視点から比較・議論でき、設計の方向性を確かめられたこと 「TTL は設定時刻に必ず消えるわけではない」といった実運用上の注意点を事前に把握でき、誤った設計・運用のままサービスインすることを回避できたこと 実運用でのスケールの仕組みを聞けたことで、運用イメージを持てたこと 開発・運用面で得られた効果 開発・運用負荷を軽減し少人数運用を実現 現在、データベースを含むバックエンドを実質 1 名で開発・運用・保守できています。キャパシティ設計が不要なため、少人数でもアプリケーション開発に集中できています。 さらに、パーティショニングやシャーディングが透過的に扱えることで、開発環境と本番環境で構成を変えずに運用できる（dev/prod parity）点も大きなメリットでした。過去のプロジェクトで Aurora を利用していた際は、書き込み負荷を 1 クラスターで捌ききれず、ユーザー単位で複数クラスターにシャーディングしていました。どのクラスターにアクセスするかはアプリケーション側の振り分け（ディスパッチ）処理で制御していましたが、開発環境ではコスト都合で本番と同じクラスター構成を再現できないため、この振り分けを開発と本番で作り分ける必要がありました。一方、DynamoDB のパーティショニングや ElastiCache のシャーディングは透過的に行われ、キャパシティやシャード数の管理も不要です。そのため、アプリケーションはクラスターへの振り分けや分割を一切意識する必要がなく、同じコード・同じテーブル設計・キャッシュ構成が開発から本番までそのまま動作します。サーバーレスのため開発環境をコストのために縮小する必要もなく、本番との構成差が生じないことから、「開発で確認したものが本番でもそのまま通用する」状態になりました。 DynamoDB 移行後は、アラートが来たときを除いてほとんど監視画面を見る必要がなくなり、DB 周りの日常的な運用がほぼなくなりました。Aurora 利用時に気を配っていた、大規模テーブルのパーティション運用や肥大化に伴うパフォーマンス劣化への対処、API サーバーのスケール時のコネクション数（コネクションプール）といった懸念からも解放されています。 性能面の効果 DynamoDB のレイテンシーは、全 DynamoDB API の平均で 10 ミリ秒以下（CloudWatch の DynamoDB レイテンシー値）で安定しています。データ量が増えても応答性能が変わらないため、一貫して低いレイテンシーを維持できています。複雑なクエリを組まない（組む必要のない）設計になっていることも、クエリが重くなりにくい要因の 1 つです。 ElastiCache for Valkey については、従来利用してきた Redis と遜色ない性能を維持できています。頻繁に参照されるユーザーデータやランキングを ElastiCache でキャッシュすることで、低レイテンシーで応答しつつ、DynamoDB への読み取りアクセスも抑えられています。アクティブ・上位ユーザーほど参照頻度が高いため、限られたキャッシュ量でも高いヒット率が得られ、効率よく読み取り負荷を軽減できています。 コスト面の効果 最も実感しているのは、運用・管理まで含めたトータルでのコストメリットです。DynamoDB では、クラスター分割した Aurora での試算と比べて、開発・ステージング・QA 環境あわせて 95%、本番環境で 40〜50% のコストを削減できています。また、インフラの利用料金そのものに加え、これまで DB の運用・管理にかけていたコストまで含めて、負担が大きく下がりました。 ElastiCache Serverless については、開発環境ではノード構成と比べて大幅に低コストで運用できています。本番環境でも、スパイクに備えた過剰なプロビジョニングやリザーブドノードの事前購入が不要になり、負荷が読みにくいなかで容量を先に見込んで確保する必要がなくなりました。 可用性・耐障害性 最初のローンチ以降、無停止で安定稼働しており、サービスに影響するような障害は発生していません。 さいごに 『ソニックランブル パーティ』で得られたこうした成果を踏まえ、DynamoDB と Valkey は今後、部門の標準アーキテクチャとして後続タイトルでも採用していく予定です。なお、ElastiCache for Valkey を Serverless とノードベースのどちらで構成するかは、リザーブドノードの活用可否を踏まえて各プロジェクトで選択できるようにしています。 株式会社セガ 第4オンライン研究開発プログラム部 副部長の上園 政雄氏は、次のように話しています。 「DynamoDB と ElastiCache Serverless for Valkey は、少人数でグローバル展開を支えるうえで欠かせない基盤になりました。今後のタイトルでも標準的なアーキテクチャとして活用していきたいと考えています。」 株式会社セガ 第4オンライン研究開発プログラム部 副部長 上園 政雄 氏

本記事は、株式会社セガとアマゾンウェブサービスジャパンが共同で執筆しています。 はじめに 株式会社セガは、家庭用ゲーム機、PC、スマートフォン向けゲームの企画・開発・販売・運営を軸に、各種コンテンツや商品を全世界へ届けています。同社では、比較的新しい技術も積極的に取り入れる文化のもと、複数タイトルで AWS を活用してきました。 本事例の対象は、同社が開発・運用する『ソニックランブル パーティ』の専用ゲームサーバー基盤です。『ソニックランブル パーティ』は、Dr.エッグマンが作り出したおもちゃの世界で、「ソニック」シリーズの人気キャラクターたちがスリリングな障害物コースや競技アリーナで競い合うマルチプレイパーティーゲームです。スマートフォンとPCのクロスプレイに対応し、2024 年に一部地域でソフトローンチを行い、2025 年 11 月にグローバルローンチを迎えました。 ※本画像は株式会社セガの許諾を得て掲載しています 本記事では、この専用ゲームサーバー基盤で、ゲームサーバーのオーケストレーションに Agones を用い、その基盤に Amazon EKS (Elastic Kubernetes Service) Auto Mode を採用した経緯と効果を、お客様の声を交えて紹介します。 EKS Auto Mode の採用により、開発環境では「ゼロインスタンス運用」によるコスト削減を実現、本番環境ではグローバルローンチ以降、インフラ起因の停止はなく安定稼働を続けています。加えてその運用負荷削減効果により、運用が軌道に乗ってからは API サーバーやデータベースも含めた全環境を 1 名のエンジニアで運用できています。 解決したかった課題 グローバルに展開するマルチプレイヤーゲームの専用ゲームサーバー基盤を、少人数のチームで開発・運用することが、本プロジェクトの大きな前提でした。マネージドサービスを活用する観点では Amazon GameLift Servers も選択肢ですが、選定当時はコンテナに未対応だったことに加え、技術のオープン性も重視した背景から、本プロジェクトでは Agones によるセルフホストを選択しました。Agones はオープンソースの専用ゲームサーバーホスティング製品で、Amazon EKS 上で利用でき、専用ゲームサーバーの構成を簡素化できます。しかし Kubernetes 基盤の運用は避けられず、Agones の運用には次のような負荷が存在します。 ノード管理・Amazon Machine Images (AMI) 更新： ノードのプロビジョニング、AMI のバージョン管理とセキュリティパッチ適用のための更新作業 スケーリング設計： 需要変化に対してノードを迅速にスケールアウト・スケールインさせる仕組みの構築と運用 各種アドオンのバージョン管理： AWS Load Balancer Controller や kube-proxy 等のバージョンアップ対応 かつ本タイトルでは API サーバーに Amazon Elastic Container Service (ECS) を採用しており、Agones のためだけに Kubernetes の運用負荷を抱えるという課題がありました。 なぜ Agones on EKS Auto Mode を選んだのか 上記の課題の解決のため、Agones の基盤に Amazon EKS Auto Mode を採用しました。Amazon EKS Auto Mode は、2024 年 12 月の AWS re:Invent で一般提供が開始された機能で、Kubernetes クラスタのコンピューティング・ストレージ・ネットワーキングの管理を自動化します。Karpenter をベースとしたノード管理、Bottlerocket による最適化された OS、各種アドオンのマネージド管理により、ノード管理・AMI 更新・スケーリング・アドオンのバージョン管理が AWS の責任範囲となり、専用ゲームサーバー基盤の運用をシンプルにできる点が決め手でした。 アーキテクチャ概要 なお、本タイトルのデータベースに関する事例の詳細については、別記事 “ 株式会社セガ、グローバル展開タイトル『ソニックランブル パーティ』を少人数チームで支える Amazon DynamoDB / Amazon ElastiCache Serverless for Valkey 活用事例 ” にて紹介しています。 安定運用を実現するための設計 専用ゲームサーバーという特性上、EKS Auto Mode の採用における最大の検討事項は、 EKS Auto Mode によるノードの自動中断と、Agones のゲームサーバーライフサイクル管理の競合 でした。 EKS Auto Mode は、コスト最適化のための集約 (Consolidation)、設定変更や AMI 更新への追従 (Drift)、一定期間経過したノードの入れ替え (Expiration) など、様々な理由でノードを自動的に中断します。中断時には対象ノード上の Pod へ終了シグナル (SIGTERM) が発行されるため、対策をしないとプレイ中のゲームサーバーが強制終了されるリスクがありました。専用ゲームサーバーには「プレイ中のゲームセッションを中断させない」という強い制約があるため、この競合の解消が採用の鍵でした。 本プロジェクトでは、AWS の技術支援を受けながら、次の設計パターンを組み合わせてこの課題を解決しました。 猶予期間の設計： ノードが強制削除されるまでの猶予 ( terminationGracePeriod ) と、Pod が終了しきるまでの猶予 ( terminationGracePeriodSeconds ) を、ゲームの最大持続時間より長く設定します。ノード中断が発生してもプレイ中のゲームが終わるまで待ってから安全に停止できます。 シグナルハンドリングの実装： ゲームサーバーアプリが終了シグナルを受け取ったとき、進行中のゲームは終了を待ってから停止し、待機中のサーバーは新規割り当てをブロックして速やかに退去します。 ノード自動最適化の有効化 ( spec.eviction.safe: Always )： Agones のデフォルト設定はノードの退去をすべてブロックし、EKS Auto Mode のコスト最適化やセキュリティパッチ適用を妨げます。この設定を変更することで、上記の猶予期間とシグナルハンドリングでプレイ中のゲームを守りつつ、EKS Auto Mode の自動最適化を活かします。 NodePool の分離： 特性の異なる Agones のコントローラ系とゲームサーバー本体を別々のノードグループ (NodePool) に配置し、それぞれに適した猶予期間等を設定します。 可用性の確保： ゲームサーバーの割り当てを担うコンポーネント (agones-allocator 等) に PodDisruptionBudget (PDB) を設定し、ノード中断時にも機能を維持します。 これらの設計により、EKS Auto Mode の運用自動化のメリットを享受しながら、プレイ中のゲームを守る安定運用を実現しています。各設定の具体的な内容は、別記事 “ Amazon EKS Auto Mode 上で Agones を安定稼働させる設計のポイント “で実装例を交えて解説しています。 導入して得られた効果 コスト：「ゼロインスタンス運用」により開発環境コストを大幅に削減 長期間の開発、目的別に多数の環境を維持する必要性、といった背景から、開発環境のコストは無視できません。本タイトルでは、EKS Auto Mode への移行により実現された Karpenter の高速スケーリングを活かし、開発者がいない時間帯は ゲームサーバーが起動するノードを 0 台にし、マッチメイキング中に起動する「ゼロインスタンス運用」を実現しました。これにより、常時起動が必要ない開発環境の EKS ノードのコストを大幅に削減しました。 運用：日常的な運用作業からの解放 EKS Auto Mode への移行で、ノード管理や AMI 管理といった作業の大部分を任せることができ、EKS の運用設計における考慮事項を大きく減らせたとともに、運用工数も削減できました。例えばセキュリティパッチ適用のための AMI 更新作業では、通常は担当者のアサイン、スケジュール調整、影響確認、適用計画の作成、適用実施と、多くの場合に一週間以上かける作業が、本タイトルではほぼ対応不要と判断できています。またノードプールを yaml で定義・管理できるため、kubectl を中心とした kubernetes 標準の運用フローに統一できました。ノードプールの追加・変更もコードベースで管理できるため、設定変更や構成管理が容易になり、運用性・保守性の向上につながったと感じでいます。グローバルローンチ後は、一定期間 3 名体制で運用整備し、その後はAPI サーバーやデータベースも含めた全環境を 1 名のエンジニアで運用できています。 パフォーマンス：迅速なスケールイン・アウトでリソース利用効率向上 EKS Auto Mode はノードのスケールアウト・スケールインともに応答性が高く、Pod 需要の変化に対してクラスタが迅速に追従できました。その結果、ゲームサーバーがリソース不足で待機する時間を短縮できただけでなく、需要減少時には不要なノードも速やかに解放されるため、リソース利用効率も向上しました。また、本タイトルで独自に実装した Pod AutoScaler とも高い親和性を示し、Pod の需要変化に応じたスケーリング戦略をインフラ側へ迅速に反映でき、ピーク時の応答性と平常時の効率性を高いレベルで両立できています。 可用性：本番環境でもスムーズに移行、グローバルローンチ後も無停止で安定稼働 本タイトルでは、2024 年 12 月の一般提供開始と同時に EKS Auto Mode の検証を開始し、2025 年 1 月に開発環境へ、同年 3 月にはソフトローンチ済みの本番環境への導入が完了と、わずか 4 ヶ月でスムーズな移行を実現できました。2025 年 11 月のグローバルローンチ以降、専用ゲームサーバー基盤は安定稼働しており、インフラ起因のサービス影響のある障害は発生していません。 AWS による支援について EKS Auto Mode と Agones の共存における安定運用のための設計にあたっては、AWS の SA (ソリューションアーキテクト) が支援しました。株式会社セガの担当者は、「EKS Auto Mode 導入時は既に一部地域でソフトローンチ済みで、運用中の環境に手を入れるリスクもありましたが、AWS 社員と直接密にやり取りできる形で随時技術支援をいただきながら進めることができ、対応も早く、安心して進めることができました」と語っています。 今後の展望 EKS Auto Mode と Agones を組み合わせた設計・本番運用は世界的にも先進的な取り組み事例となりました。本アーキテクチャは今後、部門のスタンダードアーキテクチャとして後続タイトルでも主要な選択肢となる見込みです。 まとめ 株式会社セガは『ソニックランブル パーティ』の専用ゲームサーバー基盤で利用する Agones を動作させる基盤として Amazon EKS Auto Mode を採用しました。Agones の柔軟性を活かしつつ EKS Auto Mode で運用管理をシンプルにすることで、グローバル規模のタイトルの少人数チームでの安定運用とコスト最適化を両立しました。 株式会社セガ 第 4 オンライン研究開発プログラム部の穂園氏・松崎氏は、次のように振り返っています。 「以前はノードや AMI の管理、スケーリング設定に常に気を配っていましたが、EKS Auto Mode への移行後は日々の運用からほぼ解放されました。インフラを気にせず開発に向き合えるようになったことが、何よりの変化です。」 著者 穂園 智哉 株式会社セガ 第 4 オンライン研究開発プログラム部 松崎 大 株式会社セガ 第 4 オンライン研究開発プログラム部 西坂 信哉 アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト

! この記事で使うもの Claude Code — Anthropic社が提供するターミナル上で動くAIコーディングアシスタント。チャット形式でファイル操作・コード生成・分析などができる カスタムエージェント — Claude Codeに「専門家の人格」を与える仕組み。Markdownファイル1つで、名前・得意分野・使えるツール・AIモデルを定義できる この記事では、このカスタムエージェントを10体作って「仮想チーム」にした話をする QAチームが1人しかいない問題 自分はビットキーでソフトウェア品質戦略を担当している。品質データの分析、Qase[1]の運用設計、ダッシュボー