Amazon Connectを自社開発で移行。設計の要所を技術支援で支える

ユニフォームネクスト株式会社

システム部 部長 兼 執行役員 海﨑涼平 様
システム部システムグループ 沢崎佑樹 様
システム部システムグループ 山口諒也 様
ユニフォームネクスト株式会社
公開日:2026年9月1日
BEFORE
  • 電話基盤の障害でつながらない時間が生じていた
  • 自社の運用に合わせて柔軟に機能を作り込めなかった
  • 初めてのサービスで設計が最適か判断できなかった
AFTER
  • リリース後は障害なく年間12万件規模の問い合わせに対応
  • 現場に必要な機能を自社で作り込めるように
  • 専門家の知見と複数案の提示で設計に踏み込めた

業務用ユニフォームを全国の企業や店舗、個人へ販売するユニフォームネクスト株式会社。オフィス、クリニック、ワーク、フードと業種別に4つのECサイトを展開し、ユニフォーム通販で業界トップのシェアを持ちます。集客から受注、発送、そしてシステム開発まで、一連の業務を内製化しているのが同社の特徴です。

2026年2月、同社は事業の中核を担うコンタクトセンターの電話基盤をAmazon Connectへ刷新しました。開発は自社で進め、クラスメソッドはコールフローの設計やアーキテクチャの検討を技術面から支援しています。システム部の海﨑さん、沢崎さん、山口さんにお話をうかがいます。

4つのECサイトを支える年12万件の電話

注文の大半を受け付けるECサイト。ただし、商品を選んで終わりというケースばかりではありません。サイズや色の確認、返品交換の相談、刺繍の名入れ加工、そして「この現場に合うものが欲しい」という要望。多種多様な問い合わせが、日々寄せられます。

中でも大きな割合を占めるのが、加工の相談です。洗濯の頻度が高い現場であれば、プリントより刺繍を薦める。名入れの位置は右胸か、左袖か、背中に大きく入れるか。どのようなユニフォームにしたいかを聞きながら、最適な形を一緒に決めていきます。既製品を扱う以上、同じ商品は他社でも購入できる。そこにどう付加価値を出すかを、同社は重視してきました。

ユニフォームネクスト株式会社 ほかの相談も、一筋縄ではいきません。会社で全員が同じものを着る以上、1人だけサイズが合わなければ、見た目もブランドイメージも損ないます。現場では機能性が安全にも直結する。だからこそ、返品交換の相談は珍しくありません。長く使い続ける商材でもあるため、新入社員が加われば買い足し、季節に応じて入れ替える。「前と同じものが欲しいが、何だったか」という問い合わせにも履歴をたどって応えます。

在宅を含めた約50名のオペレーターが、年間およそ12万件の問い合わせに対応する。数をこなすだけでは務まらない仕事に、1つひとつ丁寧に向き合うことが、同社のコンタクトセンターの強みになっています。

そのコンタクトセンターも、同社が内製で運営する業務の1つ。集客のマーケティングから販売、受注、物流センター、刺繍加工、そしてシステム開発まで、一連の業務をすべて自社で担っています。

「外注に頼らず、自分たちで作って自分たちで届ける。そこでスピードと柔軟性を持って、競争優位性としていく考えです」(海﨑さん)

Amazon Connectを選んだ2つの理由

同社は2022年頃、自社の基幹システムを全面的にAWSへ移行しています。クラスメソッドとの関わりは、この頃から。請求代行サービスの利用に始まり、ECサイトのAWS移行にも携わってきました。

コンタクトセンターの電話基盤には、2つの課題が残っていました。

1つは可用性です。以前利用していたのは、パソコンに専用ソフトを入れて使うタイプのクラウドPBX。コンタクトセンターだけでなく、他部門の電話も代表電話も、すべて同じサービスでまかない、電話回線そのものも自社に引いていました。そのため障害の影響は広く及びます。サービス提供側のサーバーが停止した時はもちろん、自社側のネットワークに問題が起きた時も、電話がつながらない。特定の端末だけが使えないのではなく、コンタクトセンター全体で受けられなくなります。年に数回、そうした事態が起きていました。

もう1つが柔軟性です。専用ソフトの形で提供される以上、新しい機能を実装したいと考えても、対応できるのはサービスが用意した範囲まで。自社の運用に合わせて作り込む余地は限られていました。

課題は以前から折に触れて議題に上がり、複数のソリューションを検討してもいました。ただ、すぐに刷新へ動いたわけではありません。転機となったのは、AWSが経営層向けに開催したプログラムです。

「代表取締役やコンタクトセンター部門の部門長とともに参加し、Amazon Connectについて詳しく紹介いただきました。その場で部門長が、『これなら本当にやりたいことができそうだ』という感触をつかんだのです」(海﨑さん)

2024年の秋、基盤を見直す話が正式に動き出します。2つの課題の両方に応えたのが、Amazon Connectでした。可用性を担保するのは、AWSの基盤の強さと、99.99%の稼働率を保証するSLA、そして自動的な冗長構成。柔軟性を支えるのは、Streams APIによる拡張と、他のAWSとの連携です。

「自分たちでもできそう」それでもプロの目を入れた理由

ユニフォームネクスト株式会社 Amazon Connectの検証は、山口さんが進めていました。すでにAWSを使っている環境です。新しいサービスを試すことに、特別な段取りは要りません。触ってみると、想像以上に多くのことが実現できそうでした。

自社で開発するか、ベンダーに依頼するか。議論の結論は、内製でした。ただし、すべてを自分たちだけで進めたわけではありません。

「Amazon Connectは初めて利用するサービスであり、社内でも重要度の高いシステムです。設計やアーキテクチャを誤った場合のリスクを考えると、プロの視点からも支援いただいたほうが、安心して導入できると判断しました」(海﨑さん)

判断の背景には、Amazon Connectというサービスの性質があります。従来のコールセンターシステムとは設計の考え方が異なり、他のAWSサービスと比べても、参照できる事例は多くありません。やりたいことをどう実装に落とすか、その最初のイメージを描くまでが最大のハードルでした。

実装を担う山口さんも、同じ壁に当たっています。Amazon Connectを拡張するStreams APIは、当時まだ事例が少なく、参照できるのは英語のドキュメントが中心。調べながら手を動かすことはできても、不安は残ります。

「キューやルーティングプロファイルといった用語は記載されていても、定義を読むだけでは実体がつかめません。触りながら理解するほかありませんでした」(山口さん)
ユニフォームネクスト株式会社 とりわけコールフローは、規模が大きくなるほど不確かさが増します。組み上げたフローが、最後まで問題なく着信に届くのか。自分の中だけで完結させては、品質を担保しきれない。

プロジェクトの推進を担う沢崎さんも、その局面に立ち会っていました。

「検証の段階では、山口が入念に技術調査を行っており、その点では安心感がありました。しかしコールフローに関しては、その山口でも判断がつかない場面が出てきた。どう進めるべきか、決めあぐねる状況だったのです。実装の確かな裏づけとなる存在が、必要でした」(沢崎さん)

支援を依頼する相手を、同社は比較しませんでした。4年来の取引で、すでに関係と信頼があったからです。

「以前と同じ」を実現するコールフローの設計

クラスメソッドの支援は、大きく2つに分かれます。実装を進める中で生じた疑問への回答と、実現したい機能に対してAmazon Connectと他のAWSサービスをどう組み合わせるのが最適かという、設計の提示。環境の構築も実装も、担ったのは同社です。

いずれの支援でも、軸になった要望があります。以前のシステムでできていたことを、そのまま再現してほしい——コンタクトセンター部門からの、その一言でした。電話の振り分け、着信時の画面、発信の仕組み。現場が日々使ってきた機能を、Amazon Connectでも変わらず使えるようにする。それが出発点でした。

なかでも支援が厚くなったのが、電話の振り分け、コールフローの設計です。かかってきた電話をどう案内し、誰につなぐか。その流れを定義する仕組みです。

「業務によって適切なルーティングが必要になります。加えて、習熟度という概念を使った特別なルーティングも、コールフロー上で作成しなければなりませんでした」(山口さん)

習熟度に応じて、電話をつなぐ相手を変える。オペレーターごとに得意な領域は異なります。さらにもう1つ、前回対応した担当者へ優先してつなぐという条件も加わりました。過去に応対した相手であれば、経緯を把握している分、話が早い。いずれも以前のシステムに備わり、日々の運用の中で使われてきた機能です。

Amazon Connectにも、習熟度に応じて優先度を変える機能は用意されています。ただし、条件が1つであればの話です。

「前回対応した方に優先的にルーティングされる仕組みもあり、複雑な条件が何個か混じっていました。それを1つのコールフローにまとめる。そこが難しい部分でした」(山口さん)

習熟度を考慮しつつ、前回対応したオペレーターも優先する。両方の条件が同時に当てはまった時、どちらを優先するのか。企業ごとに異なるこうした振り分けを、そのまま設定できる機能は標準にありません。

クラスメソッドが示したのは、標準の機能をそのまま使うのではなく、細かな処理を1つずつ組み合わせて、目的の振り分けを作り上げるという方針でした。まず習熟度で候補を絞り、前回の対応者かどうかを照合し、条件が重なったときにどちらを優先するかを定める。この一連の流れを設計として描くことで、標準機能だけでは届かない要望に応えています。

着信画面と発信番号。現場の操作性を保つ

「以前と同じ」を求める声は、オペレーターが操作する画面にも向けられました。

以前のシステムでは、通話を操作するツールバーが常に画面の最前面にありました。電話が鳴れば、その場ですぐに出られる。ところがAmazon Connectはブラウザで動くため、他の画面を開いていると背面に隠れてしまいます。

「着信自体に気付けない、出るまでに時間がかかってしまう。現場としては、あまりよろしくない状態です。どうすれば着信に気付けるのか、以前と似た使用感で運用できるのか。そこから考えました」(山口さん)

答えが、Picture-in-Picture機能でした。ブラウザとは独立して常に最前面に表示されるツールバーを、山口さんが実装。以前と変わらない感覚で、着信に応答できる状態を取り戻しています。

発信も同じでした。同社は4つのショップを運営し、それぞれに電話番号があります。以前のシステムでは、発信時にどの番号を使うか選べました。しかしAmazon Connectの標準機能のままでは、その使い分けができません。

「4つの店舗を運営する中で、それができなくなると運用が回らなくなってしまう。ここもそのまま再現しました」(山口さん)

Streams APIを活用し、発信前に店舗を選択できる仕組みを組み込む。オペレーターは、どの店舗の番号からでも発信できるようになりました。

初めてのDynamoDBを支えた技術支援

クラスメソッドの支援は、Amazon Connectの実装にとどまりませんでした。

先ほどの「前回対応した担当者へつなぐ」仕組みは、コールフローを組むだけでは実現できません。誰がいつ応対したかを記録し、着信のたびに呼び出す。そのためのデータベースが必要でした。各種の設定や通話履歴の保存も同様です。

扱うことになったのはDynamoDB。NoSQLと呼ばれる種類のデータベースで、同社がこれまで使ってきたRDBとは、設計の考え方が根本から異なります。

「これまでRDBしか使ったことがなく、NoSQLの知見がありませんでした。これから作るアーキテクチャの中で、どのようにデータ構造を持てばいいのか。具体的にどう進めればいいのかを、クラスメソッドに相談させていただきました」(山口さん)

クラスメソッドは、RDBとNoSQLの考え方の違いを理解してもらうところから始めました。そのうえで、取り得る選択肢を、それぞれの利点とともに提示します。

支えていたのは、クラスメソッドの体制です。窓口となったエンジニアが、社内のデータベース専門家に確認し、その見解を持ち帰る。DynamoDBの相談には、DynamoDBに精通した者が答える。初めての領域に踏み込む同社にとって、確かな拠りどころになりました。

「開発を担う立場としては、相談できる相手がいることが、何よりも心強かったです」(山口さん)

日本一のコンタクトセンターへ

2026年2月、移行が完了しました。以降、障害は起きていません。運用の中で気付いた点も、自社ですぐに直せます。

現場の受け入れは、円滑に進みました。

「操作画面を従来のシステムに近づけたことで、あらためて操作方法を教える必要がほとんどありませんでした。現場は違和感なく移行でき、スムーズに使いこなしています。カスタマイズに取り組んだ意義を感じています」(山口さん)

そして、以前はできなかったことが始まります。通話の文字起こしです。

「従来のシステムでは音声ファイルを出力するのみで、内容を分析する手段がありませんでした。Amazon Connectでは通話が自動でテキスト化され、データとして蓄積されていきます。まずはVoC分析を通じて、自社のコンタクトセンターが抱える課題を明らかにし、改善へとつなげていきたいと考えています」(山口さん)

オペレーターの評価も変わります。これまではスーパーバイザーが通話を1件ずつ聴き、月に1件か2件を抜き出すのが精一杯でした。

「その限られた数だけで、1人のオペレーターを評価せざるを得ませんでした。Amazon Connectであれば、AIによる通話評価を導入できます。すべての通話を対象とした評価に向けて、現在取り組んでいるところです」(山口さん)

一連のプロジェクトを、海﨑さんはこう振り返ります。

「コールフローの設計も、データベースの選択も、自分たちだけで進めていれば、ここまでの意思決定はできなかったと思います。複数の選択肢を根拠とともに示していただいたうえで、最も良いと考える案を提示してもらえた。納得感を持って前に進められたことが、何よりの成果でした」(海﨑さん)

同社が掲げる目標は、日本一のコンタクトセンターです。

「数年単位で計画を描き、日本一を目指して取り組んでいます。目標の達成に向けて、どのような施策を講じ、どう改善を重ねていくか。その手段として、Amazon Connectの多様な機能を活用していきたいと考えています」(沢崎さん)

その視線は、コンタクトセンターの先にも向いています。同社は基幹システムも顧客管理システムも、すでにAWS上で動かしています。

「基幹システムとAIエージェント、そしてAmazon Connectを連携させ、担当者がお客様対応により集中できる環境をいかに構築するか。まだ模索の段階にあります。他社での活用例や新たなアイデアをクラスメソッドから提供いただければ、それらを参考にしながら前進できると考えています」(海﨑さん)

1つひとつの電話に、丁寧に向き合う。その姿勢を支える基盤が整いました。クラスメソッドはこれからも、ユニフォームネクストのコンタクトセンターを引き続き支援してまいります。

クラウドコンタクトセンター導入をご検討のお客様へ

クラスメソッドではAWSのAIサービスAmazon Connectを活用したクラウドコンタクトセンターの環境構築・サービス設計をご支援します。導入や運用のコストを抑えて音声テキスト変換、チャットボット活用などを駆使するコンタクトセンター構築をご検討の際にはご相談ください。

Amazon Connect導入支援
Amazon Connect導入支援

お客様の業界・課題に合った事例や支援内容も個別にご提案可能です。
まずはお気軽にご連絡ください。

似ている事例

すべての事例へ
エレベーター・エスカレーターの安全と安心を支える技術 デジタルツイン実現のためのクラウド利用を支援
フジテック株式会社 エレベーター・エスカレーターの安全と安心を支える技術 デジタルツイン実現のためのクラウド利用を支援
AWSAWS請求代行クラスメソッドメンバーズ電機・精密
セガサミーグループ全体のセキュリティガイドライン作成、クラウドネイティブ時代の仕組みづくりを支援
セガサミーホールディングス株式会社 セガサミーグループ全体のセキュリティガイドライン作成、クラウドネイティブ時代の仕組みづくりを支援
AWSAzureGoogle Cloudガイドライン策定支援クラスメソッドメンバーズセキュリティ対策マルチクラウド活用支援ゲーム・エンタメ
ゲーム開発時のパッケージ作成環境をクラウド化し、開発の効率化と環境の強靱化を実現
株式会社カプコン ゲーム開発時のパッケージ作成環境をクラウド化し、開発の効率化と環境の強靱化を実現
AWSAWSコンサルティングゲームインフラ基盤開発ゲーム・エンタメ
トライベック株式会社 新規開発サービスのAWSインフラ設計支援、CI/CD導入から運用コスト最適化まで
AWSAWSインフラ構築AWSコンサルティングクラスメソッドメンバーズコスト削減IT・インターネット
データセンター利用者向けカスタマーポータルをAWSへ移行。より安定した稼働と今後の発展を支えるフレキシブルな対応が可能に
株式会社アット東京 データセンター利用者向けカスタマーポータルをAWSへ移行。より安定した稼働と今後の発展を支えるフレキシブルな対応が可能に
AWSAWSインフラ構築AWSコンサルティングAWS移行クラスメソッドメンバーズコスト削減IT・インターネット
共通ID連携基盤のAWS移行に向け、ベストプラクティスに沿ったアーキテクチャ設計を
日本デジタル配信株式会社 共通ID連携基盤のAWS移行に向け、ベストプラクティスに沿ったアーキテクチャ設計を
AWSAWSコンサルティングAWS移行広告・メディア

サービス

0120-991-668 平日9:00〜18:00 お問い合わせ