Delight.ai の AI/ML チームの舞台裏：Claude Code を活用した社内ツールの構築

Delight.ai は、エンタープライズ企業向けに月間 70 億件の会話を処理する Sendbird のメッセージング、音声、動画基盤の上に、カスタマーサポート向け AI エージェントを構築しています。Claude を主要モデルとして使用する同社の AI コンシェルジュは、小売、旅行、B2B SaaS、マーケットプレイスなどの分野で、これまで人間へのエスカレーションを必要としていた複雑で重要度の高い顧客対応を解決しています。

Sendbird の AI/ML チームに所属するソフトウェアエンジニアである Clara Park 氏に話を伺いました。彼女は Claude Code を使用して、すべてのお客様のエージェントを本番環境で利用可能な状態にするための社内ツールを構築しています。

Anthropic：Delight AI をご存じない方のための質問として、この製品はどのようなものですか？また、Claude Code はチームのどのような業務に活用されますか？

Clara Park 氏（Sendbird）：私たちは、Mixpanel のような企業や、小売・旅行業界のオンデマンドサービス向けに AI エージェントを導入し、サブスクリプションの変更、注文サポート、以前は人間へのエスカレーションが必要とされていた例外的なケースなど、大量の顧客対応を処理しています。Claude は、これらのエージェントを支える主要モデルの 1 つです。AI/ML チームでは、Claude Code を使用して、すべての Delight AI の導入を本番環境で利用可能な状態にするための社内ツールを構築しています。基本的に、デバッグと回帰テストのワークフロー全体を Claude Code 上に構築しました。これにより、エージェントを大規模にテストし、顧客に届く前に問題を検出できるようになりました。これは以前は実現できなかったことです。

Claude Code の導入後、本番環境の AI エージェントの問題を修正するまでの時間は、約 1 週間から 1～2 日に短縮。変わった点は何か。

Park：AI エージェントの会話は完璧なものではなく、誤った料金案内や不正確な法的表現などのエラーは、すぐに修正する必要があります。以前であれば、エージェントが本番環境にリリースされた後、問題の修正、テスト、導入までに約 1 週間かかっていました。今では最長でも 1～2 日で完了します。その週に行う業務のほとんどが手作業によるものでした。AI エンジニアは皆、それぞれ独自の Python ノートブックを使って、テスト用の会話を生成し、ラベル付けを行っていましたが、これは非効率なことでした。エンジニア全員が利用する 1 つのツールにすべてを統合したことで、対応時間が短縮されました。現在では、本番環境で問題のある会話を発見した場合、直接修正できます。

11月に Claude Code を導入して以来、週あたりのプルリクエスト作成数と PR のマージ件数は約 2 倍に増加しました。11 月初めには週に約 700 件の PR が作成され、600 件がマージされていましたが、5 月には PR 作成数が約 1,600 件、マージ件数は 1,300 件に増えました。この増加は、Claude Code のトークン使用量の伸びとも一致しています。

Delight.ai の AI に対するアプローチは、現在の形に至るまでどのように進化してきましたか？

Park 氏：初期の段階では、当社のエージェントは単純な RAG チャットボットでした。その後、業界はディフレクションの時代へと移行しました。目的は、人間のエージェントに回されるチケット数を減らし、AI が簡単な問い合わせを解決することでした。モデルがツール呼び出し、より長いコンテキスト処理、複数ステップの問題の推論において向上するにつれて、当社のエージェントも進化し、問い合わせのライフサイクル全体を処理できるようになりました。たとえば、ある顧客がプランを変更するために問い合わせを開始し、その途中で先月過剰請求されていたことに気付き、支払い方法の更新も希望したとします。エージェントは、1 回の会話の中でこの 3 つすべてに対応できます。

Anthropic：マルチモデルアーキテクチャを採用しています。どのモデルが何を処理するか、どのように決めていますか？

Park 氏：タスクによって基準は異なります。サポートとの会話中には、たとえば「有料メンバーシップは無料だ」と虚偽の主張をするようなプロンプトインジェクションに対して、保護措置を講じています。会話終了後には、トピックの分類、センチメントの分析、ハルシネーションのチェックという別の分析処理を実行します。

トレードオフはタスクに応じて変化します。要約生成では速度が重要です。一方、ハルシネーション検出は処理速度が多少遅くても構いませんが、その分、精度がより重要になります。当社は、ハルシネーション、対象範囲外の問い合わせへの対応、意図分類のエッジケースなど、私たちが重視している挙動の実際の例から構築された社内テストセットを維持しています。特定のタスクで最高のパフォーマンスを発揮するモデルを採用しています。

本番環境での会話から問題を分類し、修正すべき事項について AI の提案を顧客に提示するシステムを構築しました。その用途に Claude Opus を選んだ理由は何ですか？

Park 氏：本番環境での会話の分析は、本当に複雑な作業です。私たちエンジニアリングチームは、数千件に及ぶ会話データから課題をトピックごとに分類し、修正提案を生成しています。単発の修正案ではなく、お客様が実際に実行できる、より本質的な改善提案です。その成果はお客様に直接届くため、正確なものでなければなりません。まずは低価格モデルをテストしました。それらは同じようなラベルを繰り返し生成し、軽微な問題ばかりを取り上げていた一方で、重大な問題を見逃していました。このような複数段階のパイプライン（分類、統合、改善提案）では、その最終結果を顧客が見て行動に移すことになるため、全体をまとめられるモデルが必要でした。そのため Opus 4.8 が採用されたのです。

チームが Claude Code を活用して構築した社内ツールについて教えてください。

Park 氏：1 つ目は会話デバッガーです。 エージェントに本番環境で問題が発生した場合、ツールが会話ログを取得し、システムプロンプトを表示し、期待される動作と実際の動作を並べて表示できるようにします。そして Opus を通じて分析を実行し、修正すべき箇所を特定します。2 つ目は回帰テストツールです。ユーザーペルソナとテスト用のシナリオを指定すると、自動的に会話を生成し、大規模に実行します。私たちはこれを使って、すべてのお客様のエージェントを本番環境へ投入する前に検証しています。その後は、お客様側の QA チームがそれを一通り確認し、リリースの承認を出します。

ツール以外の面で、Claude Code はエンジニアとしての日常業務にどのような変化をもたらしましたか？

Park 氏：主に作業量です。以前は、1 日に対応できるチケットは 1〜2 件程度でした。今では、Claude Code に作業を任せて席を離れ、完了した頃に戻ってくることができます。また、アーキテクチャに関する意思決定への向き合い方も変わりました。以前は、そのような判断をマネージャーやシニアエンジニアに直接相談していました。今ではまず Claude Code を使ってそれらを検討し、複数の選択肢を整理したうえで相談に臨むようになっています。これは本当に役立っています。

Delight のインフラストラクチャは舞台裏でどのような構成になっていますか？

Park 氏：私たちは Claude を Amazon Bedrock 経由と Anthropic API 直結の両方で並列経路として稼働させています。リアルタイムのレイテンシー、エラー率、容量に基づいて、1 リクエストごとに社内プロキシがどちらへ送るかを判断します。より高速かつ安定して応答している経路が選ばれます。私たちにとって、レート制限エラーは非常に重要な問題です。お客様は 24 時間 365 日のサポートを期待して AI エージェントを導入しているため、そこでサービスの途切れが発生すれば、製品としての欠陥になります。

Bedrock が有用なのは、エンタープライズ対応のインフラストラクチャ、リージョンの柔軟性、一部の顧客に必要なコンプライアンス要件への対応、そして信頼性向上のための追加容量経路を提供してくれるためです。

両方の経路を運用することで、信頼性は 2 つの面で向上します。プロバイダーレベルの冗長性を確保できるため、一方の経路で速度低下やスロットリングが発生しても、その影響がそのまま顧客に及ぶわけではありません。また、単一の経路のみで運用するよりも、リージョンやインフラストラクチャの選択肢が広がります。統合面については、一度モデルの接続が完了していれば、新しいバージョンを追加するのは簡単です。モデル名を更新し、拡張思考のような新機能向けのパラメータを設定すれば、そのまま利用を開始できます。

最近リリースされた Claude Platform の機能の中で、特に印象に残ったものはありますか？

Park 氏：先月リリースされた Claude のアドバイザーツールです。より高速で安価なモデルが、最初から最後まで作業を処理します。自力では解決できない複雑な問題に直面したときだけ処理を一時停止し、Opus に相談し、計画や修正案を受け取った後、再び処理を続行します。つまり、Opus が介入するのは難しい場面だけで、すべての応答に関与するわけではありません。

これこそ、まさに私たちが構築しようとしていたものです。より軽いタスクでは、毎回 Opus を使う必要はありません。しかし、本当に複雑な問い合わせには Opus の推論能力が必要であり、私たちはその違いを自動的に判断できるシステムを求めていました。この機能は、まさに私たちが取り組んでいた課題を解決してくれるものです。

今後の展望は？ 今後の展望を教えてください。チームが目指す先はどこですか？

Park 氏：最も大きなテーマは、私たちが 「Zero-Touch Improvement（ゼロタッチ改善）」 と呼んでいるものです。これは言わば、「AI が AI を改善する」仕組みです。エージェントは継続的に学習し、顧客は何が問題でその原因が何なのかを把握でき、人間が介在しなくても修正が行われます。現在は、問題を特定して修正を行うために顧客が私たちに依頼する必要があります。しかし将来的には、それらを顧客自身が行えるようにしたいと考えています。

もう 1 つの重点分野は「音声」であり、レイテンシは単なる指標ではなく、製品そのものです。わずかな遅延でも、自然な会話をしている感覚が損なわれてしまいます。

そして最後がメモリです。市場に出回っているエージェントの大半は、今でも会話のたびにゼロから対応を始めています。しかし、顧客が再び問い合わせてきたときには、エージェントはその顧客の履歴や過去に解決した内容を把握しているべきです。それこそが、単なるサポート対応からブランドとの継続的な関係性への転換点です。