株式会社RightTouch

＜導入サービス＞

・Incident Lake

株式会社RightTouchは、エンタープライズ企業向けにAIプラットフォームを提供し、コンタクトセンター領域の変革を目指す、新進気鋭のスタートアップです。同社は、急成長に伴う障害対応リソースの逼迫や、システムの複雑化によって障害原因の調査に工数がかかるといった課題を抱えていました。そこで同社は、SIGQのAIエージェントプラットフォーム「Incident Lake」の導入を決定。組織の壁を越えた情報集約と自動レポーティングにより、障害対応の属人性を解消し、限られたリソースでより高い価値を生み出す体制の構築を目指しています。

■導入前の課題

• 障害発生時、カスタマーエンジニアが、技術情報を集約しながら、顧客への報告を行う作業に多大な工数がかかっていた

• 障害時のレポーティング品質が属人的なスキルやコンディションに依存しており、文面の粒度や表現にばらつきが生じていた

• 自社とグループ会社、それぞれのインフラやリポジトリが混在しており、障害発生時に原因を特定する作業が複雑化していた

■導入に期待する効果

• Incident Lakeによる情報集約と自動レポーティングにより、散在する技術情報の読み解きや文面作成の工数を削減し、より高付加価値な業務に集中できる体制へ

• AIによる標準化で、レポーティングの形式や表現を統一し、属人性を排した高品質な障害報告を迅速に行える状態へ

• Incident Lakeの組織を横断したナレッジベースによりサイロ化を解消、複雑なシステム情報を構造化し、障害原因の調査や迅速な意思決定を容易に
  

急成長するAIカスタマーサポートの裏側で、障害対応の負荷が急上昇

株式会社RightTouch は、2021年12月にPLAIDからスピンアウトして設立されたスタートアップです。Webサポートプラットフォームの「QANT Web」を中心に、VoC（Voice of Customer）に基づく顧客対応の改善を行う「QANT VoC」や、AIボイスオペレーター「QANT スピーク」など、AIをフル活用したコンタクトセンター変革のためのプロダクトを展開しています。

同社のシステム基盤は、GCP+AWSのマルチクラウド構成を採用しています。PLAIDからのスピンアウトという経緯から、基盤は大きく2つの層に分かれています。

1つ目は、PLAIDが提供するKARTE基盤です。Webサポートプラットフォームにおける、エンドユーザーのWeb行動トラッキングについては、このKARTE基盤を利用しています。

2つ目は、RightTouchが独自に構築した内製プラットフォームです。お問い合わせに関するカスタマーサポートデータ、たとえば電話対応におけるVoCの内容やお問い合わせの経緯、やり取りの詳細といった、Web行動では測れないデータについては、こちらに蓄積しています。アプリケーションについても、KARTE基盤上のアプリケーションと、独自インフラ上のアプリケーションが併存しているのが、同社の技術構成の大きな特徴です。

さらに同社はGeminiを中心としたプロダクトへのLLMの組み込みや、VoCなどのデータ解析へのAI活用、新規プロダクトのAIネイティブ開発など、AIについても先進的な取り組みを続けています。

そんな同社が、ビジネスの急成長に伴い直面した課題が、障害対応におけるリソースの逼迫と、システムの複雑性によるサイロ化でした。

1つ目は、障害対応のリソース逼迫です。障害が発生すると、カスタマーエンジニアが旗振り役となって、プロダクトチームやビジネスチームと協力しながら、障害の解決と顧客対応に当たります。しかしカスタマーエンジニアの人数が限られている中で、他のプロダクトのサポートと並行して、突発的に発生する障害へ対処するのは、大きな負担が掛かっていました。特に時間がかかるのが、様々なチャネルを飛び交う技術情報を読み解き、必要な事実を取捨選択したうえで、顧客向けの平易な言葉でレポーティングを行う必要がある点です。その結果、リソースが圧迫されることで、プロアクティブな顧客のサポートや拡大に向けたデリバリー体制の整備などが後回しになってしまうという悪循環に陥っていました。

2つ目は、システムの複雑性に起因するサイロ化です。前述のとおり、同社のシステムは複数の基盤にまたがる構成で、ソースコードのリポジトリやSlackのチャンネルも複数の組織に分散しています。そのため、障害発生時の原因の切り分けに手間がかかり、PLAIDと同社の両方の経験があるメンバーでなければ解決に時間がかかるケースも生じていました。システムと組織の両面における複雑性が、情報共有の妨げや、障害対応の属人化をもたらしていたのです。

こうした課題を踏まえ、同社 カスタマーエンジニア 川下 治城 氏は、目指すべき運用のあり方について、次のように語ります。

「カスタマーエンジニアは、技術とビジネスをつなぐ希少な人材です。限られたリソースを最大化するには、運用の自動化を推し進めることで、人が対応すべき領域に集中し、AIプロダクトの最適化支援や価値提供に注力しなければなりません」

散在する情報を集約し、顧客に伝わる言葉で報告する

これらの課題を解決するために、RightTouchが導入を決めたのが、SIGQのAIエージェントプラットフォーム「Incident Lake」です。

川下氏がIncident Lakeに期待しているのは、以下の4点です。

• さまざまな場所やチャンネルに散らばった技術情報を集約し、事実を正確にピックアップすること

• その事実に基づいて顧客が理解できる言葉でレポーティングを行うこと

• 特定の人に頼らなければ原因を特定できない属人的な状況を防ぐこと

• 事後のポストモーテムを確実に作成して再発防止につなげること

「現状では、特に情報の集約や顧客への報告に多くの時間を要しています。ステータスページへの掲載や顧客への初動連絡にかかる時間をどこまで短縮できるか、さらにその正確性をいかに担保できるかが、信頼性の観点から極めて重要です」（川下氏）

これらの期待に対して、Incident Lakeはどのように応えるのでしょうか。

Incident Lakeは、複数の組織のデータソースをグループ化し、権限を設定したうえで、特定のインシデントに関連する情報だけを自動で収集・共有する仕組みを備えています。これにより、組織のサイロ化を超越えた情報集約と、必要な情報だけが関係者に届く権限管理を両立させています。その結果、SlackのワークスペースやGitHubのリポジトリが組織間で分かれているケースであっても、強力に情報を集約し、サイロ化を解消することができます。

もう1つの重要な特徴が、ナレッジベースによる知識の構造化と蓄積です。人間が手動でドキュメントを書かなくても、AIが属人的な暗黙知を吸い上げて、形式知に変換する仕組みが備わっています。例えば、Claude Code MCP経由でナレッジを直接保存したり、保存したナレッジをGitHub Actionsで定期的に更新する仕組みを作ることも可能です。このように、ナレッジの管理を人手を介さず自動化できることが、Incident Lakeの大きなメリットです。

同社は、Incident Lakeの導入を通じて、段階的に障害対応の変革を進めていく構想を描いています。まずは、必要なナレッジや過去のインシデント情報を投入し、チューニングを重ねながら、Incident Lakeを実際の障害対応に活用していきたいと、川下氏は語ります。あわせて、AIによるレポーティング品質の標準化や、初動における意思決定の迅速化にも取り組んでいく方針です。

「理想とする姿は、障害対応のオペレーション全体でIncident Lakeを活用し、各所のドキュメントを個別に参照しなくても、Incident LakeのAIとのやり取りだけで、新しく加わったメンバーでもスムーズに障害対応が行える状態を実現することです」（川下氏）

「自分たちで作る」という誘惑を超えて

RightTouchでは、Incident Lake導入に先立ち、内製による解決も検討していました。社内にはAIエンジニアチームが数名おり、GitHubからソースコードを取得してSlackで気軽に質問できる仕組みを構築するなど、すでにAIを活用した業務最適化を進めていたためです。

しかし川下氏は、内製化を選ばなかった理由を、次のように語ります。

「仮にAI駆動開発によってツールを内製できたとしても、その後に継続的なチューニングを行わなければ、実用には耐えません。さらに、運用の現場が求める機能を開発するには、障害対応の実務経験も不可欠です。その結果、エンジニアの稼働がかなり奪われてしまいかねません」（川下氏）

このように、実用性に耐えるツール開発に時間と人手を費やすよりも、障害対応の知見を持つ専門企業が磨き上げたプロダクトを導入したほうが、コストパフォーマンスが高いと判断したのが、Incident Lake導入の決め手となったと、川下氏は振り返ります。

少数精鋭組織を支える 無限のスケーラビリティ

川下氏は、同社カスタマーエンジニアの今後の展望について、AIプロダクトの価値を顧客に届けるための高度な支援に注力したいと語ります。具体的には、顧客の実務を深く理解した担当者により、顧客ごとに最適なチューニングを行い、顧客がAIプロダクトの価値を引き出すことを支援すること。その結果、ビジネスの成長だけでなく、プロダクトの洗練にも貢献していきたいというのが、川下氏が描く理想像です。そのために、希少性は高いものの、ビジネスと技術の両面に明るい高度な人材採用に注力していきたいと、川下氏は抱負を述べます。

最後に、同様の課題を抱える企業に向けて、川下氏はアドバイスを送ります。

「自分たちで運用の試行錯誤をするよりも、有無を言わずにSaaSを活用したほうがよいというのが率直な感想です。インシデント対応の流れは、どの企業でも共通している部分が多いと思います。一定のパフォーマンスが見込めるベストプラクティスに自社のやり方を合わせていくほうが効率的であり、より高い成果も期待できます」（川下氏）

人材の増加とビジネスの成長は、必ずしも比例しません。特に、指数関数的にビジネスが成長するスタートアップでは、無限のスケーラビリティを提供するSaaSは、人手不足を解消するうえで大きな武器になります。SIGQは、今後もIncident Lakeを通して、同社の急成長するプロダクトを支えてまいります。