アプリ内ライブチャットとは何か、自社プロダクトへの導入方法

「アプリ内」が実際に意味すること（Webサイトのウィジェットとは別物）

このフレーズは曖昧に使われがちなので、きちんと定義しておく価値があります。アプリ内ライブチャットとは、公開マーケティングサイトではなく、ユーザーがすでに使っている認証済みプロダクトの内部に存在するチャット画面のことです。Webサイトのウィジェットは見込み客と話し、アプリ内チャットはログイン済みユーザーと話します。それも、すでに料金を払っている、あるいは検討中のものの内部で、作業の途中に。

Zendeskも自社のメッセージングページで同じ線引きをしており、「Webサイト」と「モバイルアプリ」を、企業が展開する一つの拡張された面としてではなく、別々の2つのチャネルとして位置づけています。Crispはさらに踏み込み、自社のSDKラインを明確に「モバイルおよびWebアプリ企業を支えるインフラ」として売り出しており、通常のWebウィジェットとは別のプロダクトだとしています。この違いは表面的なものではありません。Webサイトのウィジェットは通常JavaScriptのみで動き、ログインも不要で、リード獲得を狙ったものです。アプリ内チャットはネイティブSDKを通じてアクセスされ、ユーザーのセッションとアカウント状態を保持し（Zendesk自身のSDKドキュメントによれば）通常はJWT認証をサポートしているため、再訪したユーザーの履歴が訪問のたびについてきます。

だからこそ「自社アプリにライブチャットを追加する」ことと「Webサイトにチャットウィジェットを追加する」は、ほとんどのベンダーが同じダッシュボードから両方を販売しているにもかかわらず、まったく別のプロジェクトなのです。

チームがプロダクトの内部にチャットを置く理由

これは単なる「あればいい」機能ではなく、実際のギャップに突き動かされています。Zendeskは自社調査として、CXリーダーの84%が自社の応答速度を「優秀」と評価している一方、そう同意する顧客はわずか39%というデータを示し、アプリ内メッセージングはこの認識のギャップを埋めるものだと位置づけています。サポートがタブを切り替えた先にあるのではなく、アプリの内部で「クリック一つ」の距離にあるようにするという考え方です（Zendesk Messaging）。

繰り返し挙がる具体的な理由がいくつかあります。

• 文脈内サポート。 ユーザーはすでに作業の途中、決済中、エラーに遭遇中、設定変更中であり、サポート側は「今どの画面にいますか?」から始める代わりに、実際の画面やアカウント状態を確認できます（あるいは教えてもらえます）。
• コンテキストスイッチの削減。 アプリ内チャットがなければ、モバイルアプリ内でつまずいたユーザーはアプリを離れ、ブラウザを探し、正しいサポートページを見つけ、状況を説明し直さなければなりません。Tidio自身のモバイルSDKの訴求文はまさにこの点を前面に出しています。「アプリを離れることなく、即座にインテリジェントな応答を」。
• チャネルをまたいだ継続性。 モバイルで始めて後からWebアプリを開くユーザーは、そのスレッドがまだそこにあることを期待します。FreshchatのモバイルSDKドキュメントは、同じユーザー識別子を渡すことで、会話が「Android、iOS、Webなど対応するどのプラットフォームからでもシームレスに続きから再開できる」と説明しています。
• よりネイティブな体感、それがリテンションに表れる。 Crispはこれをプロダクト指標に直結させ、自社SDKがチャットを外部プラグインではなくアプリの一部として感じさせることで、まさに「ユーザーエンゲージメントとリテンションを高める」と説明しています（Crisp Chat SDK）。

自前で構築する道：SDKと、実際にひずみが生じる場所

従来の方法を選ぶ場合、主要なライブチャットベンダーはどこも、Webサイトウィジェットとは別に専用のモバイル/アプリ内SDKを提供しています。

ここで名前を挙げておくべき警告事例がDriftです。同社自身のライブチャットページは現在、Salesloftの新しいAIチャットエージェント製品にリダイレクトされており、あるG2レビュアーはその顛末をこう述べています。

「Salesloftがドリフトを買収してから、カスタマーサービスは大幅に低下しました。8月には10日間サービスに影響が出た大規模なデータ侵害もありました…更新をキャンセルしようとしましたが、Salesloftの人が支払いを求めて何度も電話をかけてきました。」

認証済みユーザー、G2レビュー

これは見落とされがちなリスクです。チャットSDKが実際のプロダクトにインフラとして組み込まれた時点で、ベンダー側の買収や障害は些細な不便ではなく、逃げ場のないサポートチャネルの停止そのものになります。ベンダー危機がなくても、こうしたツールのアプリ内側はWebダッシュボードより機能追加が遅れがちです。あるCrispの長年のユーザーは率直にこう述べています。

「長年、Crispアプリの体験は、動いていたとしても、あまり良いものではありませんでした。今日では改善されましたが、それでもCrispがこの2年間で出荷した新機能のほとんどが欠けています。Hugoの会話をトリガーする方法もなく、アプリ内にAIはまったく実装されていません。」

Albert M.氏、G2レビュー

Freshchatのレビュアーも別のベンダーで同じパターンを指摘しています。「モバイルアプリの体験はデスクトップ版ほどスムーズでも一貫してもおらず、時折の通知遅延がメッセージの見逃しにつながることがある」（Siddharth O.氏、G2レビュー）。そもそもAI機能が理由でチャットを追加しようとしているなら、ベンダーのモバイルSDKがWebウィジェットだけでなく実際にそれらを提供しているか、確認する価値があります。

より軽い道：生のSDKの代わりにAIチャットレイヤーを使う

私はサポートチームがチャットSDKをつなぎ合わせ、後から別プロジェクトとしてAIレイヤーを上乗せする様子を何年も見てきました。まさにこの継ぎ目こそが、Webウィジェットが公開されてから数か月後にモバイルアプリが「あまり良くない」まま取り残される場所です。eeselはAIエージェントと埋め込み面を一つのものとして提供することで、この継ぎ目を丸ごとスキップします。配置したい場所に応じて3種類の形があります。

**チャットバブル**は、1つのスクリプトタグで追加できる、隅に浮かぶアイコンです。ログイン済みアプリの内部を含め、自分がコントロールできるどのページにも設置できます。eesel自身のドキュメントには「多くのチームがeesel AIチャットバブルを社内イントラネット、社内ポータル、従業員向けサイトに導入している」とあり、これはこの記事で扱っているアプリ内パターンと同じものを、顧客向けプロダクトではなく社内ツールに適用したものです。

**インライン埋め込み**は、「自社アプリの内部にチャットを置く」という要望に最も直接的に対応するものです。すべてのページに浮かぶのではなく、ドキュメントページの上部、プロダクトのオンボーディングフロー内、開発者ポータル上など、特定の場所に1つのHTMLスニペットで配置するコンポーネントです。eesel自身のFAQはこの線引きを明快に説明しています。「チャットバブルはすべてのページの隅に浮かびます。インライン埋め込みは特定のページの特定の場所に配置されます…よりネイティブに感じられ、ドキュメントやヘルプセンターに最も適しています」。プロダクト画面の上に浮かぶのではなく、その内部に住むAIエージェントを目指すなら、私が選ぶ仕組みはこちらです。

**公開チャットリンク**は埋め込み自体を丸ごとスキップします。メール、Slack、サポートチケットで送れる共有可能なブランド化されたURLで、コードには一切触れません。アプリのコードベースにアクセスできない（あるいはしたくない）場合の選択肢であり、エンドユーザーが使うためにeeselアカウントを持つ必要もありません。

この3つはすべて同じナレッジベース（ヘルプセンター、Notion、Confluence、Zendeskチケット、自社サイト）上で動作し、80以上の言語で回答し、確信度やトピックに応じて人間にエスカレーションします。表面が変わってもこの部分は変わりません。変わるのはチャットが物理的にどこに置かれるかだけです。

実際のセットアップ方法

SDKルートを選ぶにせよ埋め込みルートを選ぶにせよ、セットアップの形はおおむね同じ4ステップです。

1. ナレッジソースを接続する。 ヘルプセンター、ドキュメント、Google Drive、Notion、Confluence、自社サイト、あるいは既存のヘルプデスクを、1行ずつ手作業で入力するのではなく、自動でインポートし同期させ続けます。
2. ウィジェットをカスタマイズする。 名前、アバター、色、位置を、設定パネルを掘り返すのではなく平易な言葉で指定し、公開前に実際の質問でテストします。
3. 1つのスニペットを貼り付ける。 チャットバブルなら<script>タグ、インライン埋め込みならHTMLスニペット、公開チャットリンクなら何も貼り付ける必要はありません。
4. アプリ内で稼働する。 ネイティブバイナリの出荷は不要で、真のモバイルSDKではなく埋め込みを使っているならアプリストアの審査待ちも不要です。

OSレベルのプッシュ通知でアプリを起こす必要がある、あるいはネイティブUIとの深い連携が必要など、プロダクトが本当にネイティブのiOS/Android SDKを必要とする場合は、CrispのiOS SDKやFreshchatのAndroid SDKのようなベンダーが真価を発揮する場面です。その場合は、それらのSDKが送り込むチケットデータの上に、接続されたヘルプデスクを介してeeselのAIを重ねることになります。Webアプリ、ブラウザ拡張機能、社内ポータルであれば、埋め込みはネイティブビルドという工程全体をスキップできます。

料金：実際にかかるコスト

従来型のライブチャットベンダーは、アプリ内SDKへのアクセスを、より広いシート課金プランに組み込んで提供します。CrispとTidioのモバイルSDKは標準プランへのアドオンであり（Crispの料金とTidioの料金を参照）、特にTidioはSDKを公開価格ではなく問い合わせフォームの後ろに置いています。

eeselはその逆の考え方で価格を設定しています。使用量ベースで、シート料金なし、セルフサーブプランにプラットフォーム料金もありません。

具体例として、月500チャットセッションなら200ドルで、セッション内のメッセージ量による追加料金はなく、人間のエージェントが対応した会話に対して課金されることもありません（eeselの料金）。ダッシュボードにアクセスする人が1〜2人を超えた時点で、これはシート課金型のSaaSライブチャットプランとは大きく異なる請求額になります。

避けるべきよくある間違い

• モバイル側を後回しにする。 上記のG2の声は例外ではなくパターンです。AI機能や新機能はWebウィジェットに真っ先に投入され、ネイティブアプリには数か月後、あるいは全く投入されないことが日常的に起きています。契約前に、ベンダーのモバイルSDKに何が欠けているか直接確認してください。
• ベンダーリスクの検討を省く。 チャットが交換可能なWebサイトウィジェットではなく、プロダクト内部のインフラになった時点で、買収、障害、価格変更の影響はより重くのしかかります。深くアプリに組み込む前に、ベンダーが過去2年間どう対応してきたかを確認してください。
• AIレイヤーを別プロジェクトとして構築する。 生のチャットSDKを別のボットフレームワークに接続すると、保守面が二重になります。最初から自社のドキュメントで学習済みのエージェントをチャットバブルやインライン埋め込みにそのまま組み込めば、この工程は丸ごと不要になります。
• エスカレーションを忘れる。 何を埋め込むにせよ、確信度の低い回答がトピックや確信度スコア、明示的なリクエストに応じて人間にルーティングされることを確認してください。AIが推測すべきでない場面で推測させたままにしないでください。

eeselで自社プロダクトの内部にAIチャットレイヤーを追加する

私は十分な数のチームが、チャットSDKをアプリに組み込んでから、それを賢くするための第二のプロジェクトに時間を費やす様子を見てきました。だからこそ、2段階のやり方の方が難しい道だと分かります。eeselのインライン埋め込みは、ヘルプドキュメント、過去のチケット、プロダクトデータですでに学習済みのAIエージェントを、オンボーディングフロー、ドキュメントページ、サポートパネルなど、自社アプリ内のページに直接配置します。ネイティブSDKの保守も、第二のベンダーとの統合も不要です。確信が持てない場合は人間にエスカレーションし、80以上の言語で動作し、プラットフォーム料金やシート料金なしで1会話あたり0.40ドルで課金されます。自分で構築するか埋め込むかを検討しているなら、1行もSDKコードを書く前に、自社のドキュメントでeeselを試してください。