Amazon Web Services ブログ
テイツーが挑むリユース業界の店舗 DX – AWS で実現した POP 自動生成サービス「POP×THREE」
本ブログは、株式会社テイツー様とアマゾン ウェブ サービス ジャパン合同会社が共同で執筆いたしました。
AWS 上に既にあるリソースを別のシステムの一部として活用しよう、というアイデアを思いつくことは頻繁にあるかと思います。しかし実現に向けたアクションとなると、連携方式の選定や既存システムへの影響評価など検討すべきことが山積し断念、気がつくと巨大で複雑な連携システムが出来上がっていた･･･こんな経験はありませんか。テイツーはこの課題をクラウドの特徴を捉えたシンプルな設計判断で乗り越え、わずか約 3 ヶ月での新サービスリリースを実現しました。
このブログでは既存の AWS 資産を活用した新サービス創出までのアプローチと、リユース業界における店舗 DX の取り組みについてご紹介します。
株式会社テイツー（以下、テイツー）は、「古本市場」「ふるいち」「トレカパーク」などのリユース店舗を全国 180店舗（執筆時点）展開する東証スタンダード上場企業です。同社はトレーディングカードの読取査定機「TAYS」の開発・運用を通じて、 AWS の活用を進めてきました。テイツーはこの TAYS の AWS 基盤を活かし、店舗向け POP 自動生成サービス「POP×THREE」をわずか約 3 ヶ月で開発・リリースしました。
リユース業界における店舗運営の課題
テイツーは 1989 年の創業以来、書籍、家庭用テレビゲーム、トレーディングカード、ホビー、スマートフォン、CD、DVD、衣類など幅広いカテゴリのリユース品を取り扱い、「家族で楽しめる廉価な娯楽の提供」を事業の柱としてきました。近年はトレーディングカード市場の拡大に伴い、トレカ読取査定機「TAYS」を自社開発し、BtoB サービスとして外販するなど、テクノロジーを活用した事業展開にも積極的に取り組んでいます。
一方で、リユース業界特有の課題として、商品の買い取り価格が市場動向に応じて日々変動するという点があります。特にトレーディングカードの分野では、新タイトルの発売や大会の開催などによって価格が大きく変動するため、店舗に掲示する買い取り告知 POP を頻繁に更新する必要があります。
これまでは全店舗に配信する買い取り告知 POP の作成に、1 回あたり約 1〜2 時間の作業時間を要していました。主な作業内容はカードの価格変更やタイトルの入れ替えですが、告知を一から作成する場合にはさらに多くの時間がかかるケースもありました。全国の店舗に対してタイムリーに情報を届けるためには、この POP 作成業務の効率化が不可欠でした。
TAYS から POP×THREE へ – 既存 AWS 基盤を活かした新サービス構想
テイツーが運用するトレカ査定システム「TAYS」は、読み取りスキャナーと連携し AWS を中心としたクラウド上でAIによる判定、データ閲覧と編集を可能にした、トレカ買い取りに特化した基盤です。
TAYS の基盤では、Amazon Aurora MySQL を DB サーバとして採用し、Amazon EC2 上のLinux でアプリケーションを稼働させています。AWS WAFによるセキュリティ対策も施されており、全国の店舗からインターネット経由で安全にアクセスできる構成となっています。
TAYS 自身は元々、外販向けの構想や個店ごとの価格設定などを見据えて設計されていました。つまり、そのデータベースには買い取り以外にも店舗運営に必要な商品・価格情報が蓄積されており、新たなサービスを構築するためのデータ資産がすでに存在していたのです。
ここから生まれたのが「POP×THREE」です。TAYS のデータ資産とインフラ基盤を API 経由で活用し、その上にフロントエンドを構築するというアプローチで新サービスを開発できるのでは、という発想からスタートしました。実装内容をなるべく少なく、リリースを速くしたいという方針のもと、2025 年 9 月下旬に開発をスタートし、同年末には提供を開始しています。
POP×THREE のサービス概要
POP×THREE は、TAYS に蓄積された商品・価格データを活用し、店舗向けの買い取り告知 POP を効率的に作成するサービスです。商品データを一括投入し、テンプレートを活用して POP を量産するツールとして設計されています。画像認識には独自構築の画像認識モデルを用いており、カード画像の細かな違いを認識することでトレーディングカードにおけるバリアントの判定も可能となっています。
システムアーキテクチャ
POP×THREE はあくまでフロントエンドとして機能し、バックエンドは既存の TAYS 基盤との連携を前提に設計されています。ここでは、TAYS の既存基盤と POP×THREE の新規構成の両方をご紹介します。
TAYS + POP×THREE 基盤
TAYS POP×THREE 構成図（一部省略）
TAYS のシステム基盤は、以下の構成となっています。
- ネットワーク・アクセス: Amazon Route 53 による DNS 管理、Elastic Load Balancing (ALB) によるトラフィック分散
- コンピューティング: オートスケール構成のAmazon EC2
- データベース: Amazon Aurora MySQL をメインの DB サーバとして採用
- ストレージ連携:カード画像・スキャン画像・OCR ログなどのデータを各サーバ間で共有。画像処理や一括データ更新を実行
- セキュリティ: AWS WAF による Web アプリケーション保護
POP×THREE のワークロード増加に伴いオートスケール化とセキュリティ強化策を講じることで、TAYS は全国の店舗と本部を結ぶより堅牢なシステム基盤として安定稼働しています。
POP×THREE の構成
POP×THREE は、TAYS の資産を最大限に活かすことを念頭に、既存 AWSアカウントに同居する形で構築しました。東京リージョンの 2 つのアベイラビリティゾーンにまたがる構成で、高可用性を確保しています。
- ネットワーク・アクセス:共通 ALB によるトラフィック分散
- コンピューティング: Private Subnet 内に本番環境・検証環境で分離して配置
- キャッシュ: Amazon ElastiCache を本番・検証それぞれに配置し、パフォーマンスを最適化。スロークエリログおよびエンジンログを CloudWatch Logs で管理
- セキュリティ: WAF Charmと共通 AWS WAF による Web アプリケーション保護
- ログ管理: Amazon CloudWatch Logs と Amazon Data Firehose によるログの収集・S3 への転送（本番・検証それぞれ）。AWS WAF ログ、ALB ログも Amazon S3 に保管
- 設定管理: AWS Systems Manager パラメータストアによる構成情報の一元管理
設計上のポイント
POP×THREE の設計において最も重要な判断は、TAYS の既存データをどのように新サービスから利用するかという連携方式の選定でした。新システムを構築する際の一般的なアプローチとしては、①DB レプリカや DMS によるデータ同期、②既存システム側に専用 API を公開し新システムがそれを利用する、③既存 DB を直接参照する、といった選択肢が考えられます。
テイツーが採用したのは②のアプローチです。TAYS 側に POP×THREE 専用（連携アプリ用）の API を設置し、POP×THREE はその API を介して商品・価格データを取得する構成としました。この判断の背景には、TAYS と POP×THREE で保守を担当する開発ベンダーが異なるという事情もありました。①のレプリカ構成では DB 構造への依存が強くなり、スキーマ変更のたびに両ベンダー間で調整が発生します。DMS によるデータ同期についても、レプリケーションの複雑性と継続的なメンテナンス負荷を踏まえ、現在の運用体制では現実的ではないと判断しました。③は②の構成が取れれば必要ありません。
API を採用した最大の狙いは、システム間の責務を明確に分離し、将来的な変更や機能追加のスピードを確保することにあります。これを介することで、DB 構造変更時の影響範囲は TAYS 側に閉じ、POP×THREE 側は API の後方互換性さえ保たれていれば独立して開発・デプロイが可能です。保守ベンダーが異なっていても、調整コストを最小限に抑えながら利用者の要望に迅速に応えられる構成となっています。一方で、POP×THREE から見れば TAYS が稼働していなければデータ取得ができないという依存は残りますが、Aurora MySQL 自体の高可用性構成と、読み取りレプリカの追加による柔軟なスケーリングにより、実運用上のリスクは許容範囲と判断しました。
加えて年内リリースの方針のもと、各ベンダーがスケジュール遵守を前提に開発を進める必要がありました。API のインターフェース仕様を早期に確定させたことで、TAYS 側（API 公開）と POP×THREE 側（フロントエンド構築）の開発を並行して進められたことも、約 3 ヶ月という短期間でのリリースを支えた要因です。AWS という共通のクラウド基盤上で IAM やネットワーク設計が標準化されていたことで、異なるベンダー間の技術的な齟齬が生じにくかった点も大きく寄与しています。
導入効果
POP×THREEにより、テイツーでは以下の効果が得られています。
業務効率化
すでに POP×THREE を導入している外販先企業では、数時間単位での業務効率化につながっているとのことです。
テイツー直営店での本格利用はこれからですが、全店舗に配信する予定の買い取り告知 POP の作成業務において、運用次第では 1 枚あたり約 30 分程度の作業時間短縮が見込まれています。従来は 1 回あたり約 1〜2 時間を要していた作業であり、特に価格変更やタイトルの入れ替えといった定型的な更新作業での効率化が期待されます。
外販先での実績を踏まえ、さらなる効果が期待されています。
安定稼働とスケーラビリティ
POP×THREE はサービス開始以来システムダウンを経験していません。テイツーは「クラウドの恩恵として、マネージドサービスでインフラ管理コストを下げつつも、安定稼働している」と評価しています。
スケーラビリティの面では、直近でトレーディングカードのビッグタイトルが発売され大規模な負荷が発生した際、TAYS のオートスケール対応を実施しました。常時複数台のサーバを配置する構成へ移行し、今後のさらなるトラフィック増加にも対応できる体制を整えています。
AWS の活用メリット
テイツーが AWS を活用する中で特に評価しているのは、以下の点です。
- 複数ベンダーとの円滑な連携: POP×THREE の開発では複数の開発ベンダーに依頼しましたが、AWS という認知度の高い基盤があったことでスムーズに連携を行うことができました
- 適切なサービス選択の提案: AWS からの技術支援により、要件に合った適切なサービスの選択を行うことができました
- クラウドの安定性: お客様向けサービスの基盤として、高い可用性と安定稼働を実現しています
テイツー様からのコメント
「当社として本件は単なるシステム導入事例ではなく、AWS ならではのスピーディーな立ち上げとして対外的に発信できるテーマだと考えています。
トレカ査定システム TAYS の開発・運用を通じて培った AWS 基盤を最大限に活用することで、POP×THREE を約 3 ヶ月という短期間で立ち上げることができました。既存の RDS を活用し、フロントエンドの開発に集中するというアプローチは、実装をなるべく速く、少なくしたいという当社の方針に合致するものでした。また、AWS からの適切なサービス選択の提案により、限られたリソースの中でも最適なアーキテクチャを構築できたと感じています。
本取り組みは、既存データ資産を活用し小さく始めることで再現可能なモデルであり、AWS の各サービスの機能を利用して継続的に最適化できる点も大きな強みです。
システムの安定稼働はお客様へのサービス品質に直結するものであり、クラウドの恩恵を日々実感しています。今後も AWS の技術を活用し、リユース業界における店舗 DX をさらに推進してまいります。」
— 株式会社テイツー 情報システム部マネジャー 野口 義弘 様
今後の展望
テイツーでは、POP×THREE の展開をさらに加速させるとともに、AWS 基盤の強化を進めていく計画です。現在は TAYS が公開する API を介したデータ連携により運用していますが、導入先の拡大に伴うトラフィック増加に備え、Aurora の読み取りレプリカ追加やキャッシュ戦略の見直しも視野に入れています。さらに、中長期的には API の拡充やイベント駆動型の連携導入により、TAYS と POP×THREE それぞれが独立してスケール・進化できるアーキテクチャへの発展を段階的に進める方針です。直営店についてはこれから POP×THREE の利用を本格化させる段階であり、現場からのフィードバックを得ることで今後の展開を検討していく予定です。
テイツーの取り組みは、既存の AWS 基盤を活かして新たなサービスを迅速に立ち上げるという、クラウド活用の好例です。リユース業界における店舗 DX の推進に向けて、テイツーの挑戦は続きます。