Adaは「自走性」の思想が強いが、「引き継ぎ境界」の開示は薄い

AI窓口の失敗は、たいていAIの賢さの問題ではありません。詰まった会話をどこで、どんな条件で人へ渡すかという「出口の設計」が甘いところで起きます。Adaはこの出口の設計を、公式サイトだけでどこまで見せているのか。読み比べる限り、他の主要プレイヤーほど厚くは開示していない、というのが私の見立てです。

私はこのブログでSierra、Intercom、Ada、Forethought、Kustomerの5社をそれぞれdeep-diveし、5社を横断して読み比べる記事も書きました。

この5社を書き終えてAdaに戻ったとき、見方が変わった点が一つあります。最初にAdaの公式サイトだけを読んだときは、「ノーコード」という言葉を、他社と大差ない販促表現として軽く見ていました。ところがSierraとIntercomのdeep-diveで、SierraのTrust and reliability・Agent Studio、IntercomのProcedures・Simulationsのように、各社が引き継ぎと検証の設計思想を具体的な機能名で開示している厚みを読んでから、Adaの創業者インタビューを読み返すと、「ノーコード」は販促文句ではなく、運用担当がエンジニアを待たずに会話設計を直せるという一貫した思想として語られていることに気づきました。5社を横断して読み比べる記事を書く過程で得たこの気づきが、本記事の見立て、自走性の思想の一貫性と開示の厚みの薄さが同居しているという読みの出発点です。

断っておくと、これは5社を本番環境で並行運用して比較した結果ではありません。根拠にしているのは各社の公式情報と、deep-dive記事を書く過程で読み比べた一次情報です。

“

本記事は主に2026年4月時点の公式情報を中心にまとめています。料金・画面構成・公開イベントでの語り口は変わりやすいため、導入前に必ず公式ページで最新情報を確認してください。

前提: 「引き継ぎ境界」と「開示の厚み」を定義する

以前、5社を比較する記事で「人の戻し先」という軸を使いました。AIが誤答したり、想定外の問い合わせに当たったとき、誰が、どの画面で引き取り、何を最終的に確定させるかという運用上の受け皿です。Sierraのdeep-diveでは、これをさらに踏み込んで「outcome境界」と呼び、どの結果をAIの成果と定義し、どこから人間へのescalationとして線を引くかを定義しました。

本記事は、この2つの延長線上にAda固有の論点として次の2つを置きます。

引き継ぎ境界: どの条件を満たしたらAIが会話を手放し、人が引き取るかを、運用画面とドキュメントの両方で明文化した線です。反論可能な具体性まで踏み込むなら、(1) どの条件で止まるか、(2) 誰が引き取るか、(3) 引き取った後に何を確定させるか、(4) その受け渡しが機能しているかをどう確認できるか、の4点まで含みます。たとえば問い合わせは大きく3つに分かれます。定型の返答で前に進められる反復的な問い合わせ、注文や契約など社内情報に寄る文脈依存の問い合わせ、そして交渉や例外判断が要る、人が握るべき問い合わせです。引き継ぎ境界とは、このうちどこまでをAIに渡すかという設計そのものです。

開示の厚み: 買い手が公式サイトだけで、この引き継ぎ境界と、その検証手段を確認できる度合いです。厚い会社は公式ページの機能名やドキュメント名を名指しできます。薄い会社は創業者インタビューや導入事例、報道記事から組み立てる必要があります。この違いは製品の優劣そのものではなく、購買プロセス上のシグナルです。公式ページだけで判断できるか、商談で仕様開示を求める必要があるかを分けるからです。

この記事が5社比較記事に加えるのは、Adaという1社について、この非対称——自走性の思想の一貫性と、開示の厚みの薄さが同居している、という観察です。

Adaの成り立ちは「自走性」の思想を裏づける

Adaは2016年、トロントでMike MurchisonとDavid Haririによって設立されました。二人は前身プロダクトのVolleyを運営する中で、会社が伸びるほど顧客との会話が減っていく矛盾を問題として捉えた、と創業の経緯を語っています。

その後、複数の会社の窓口業務そのものを実地で観察する中で、二人が学んだのは、反復的な問い合わせが大量に存在する一方で、人が見るべき例外処理は別に残るという構造だったとDavid Haririは振り返っています。

この成り立ちを読むと、Adaの核は、機械に渡す範囲と人が握る範囲を設計する道具として組み立てられている、と読めます。実際、Adaの「ノーコード」という訴求は、窓口チームがエンジニアを介さずに会話設計を直せるようにするための思想として読むほうが筋が通ります。会話分岐の修正、文言調整、根拠文書の更新、そして例外時の引き継ぎ条件の明文化——これらの担当を現場側に寄せられるかどうかが、Adaが「ノーコード」で本当に売りたいものです。現場が自力で回せない仕組みは、導入直後は動いても、問い合わせの中身が変わるたびに止まりやすいからです。

公開事例は「どの詰まりを解いたか」で読む

Adaを理解するには、仕分け・ナレッジ参照・引き継ぎ・計測という4つの視点で運用を分解すると見えやすくなります。重要なのは、会話を運用可能な単位に切り分けられるかどうかです。

IPSY、Loop Earplugs、Monday.com、Pinterestといった名前は参考になりますが、そこに出るROIや自動化率は、その会社がその時点で公開したcase studyの数値です。数値の大きさより、どの視点の詰まりと結びついていたかを拾うほうが再利用しやすいと私は考えています。

開示の非対称: Sierra・Intercom・Forethoughtとの読み比べ

以前5社を比較する記事で書いた通り、実際に読み比べて一番差を感じたのは機能ページの文言ではなく、handoffやTrust関連ドキュメントの厚みでした。SierraはTrust and reliabilityページでsupervisor modelsやPII maskingまで踏み込み、Agent Studioではsimulationとregression testingを検証の中心に据えています。Intercomも同様に、Fin 3のProceduresとSimulationsという機能名でhandoffと検証の設計思想を開示しています。ForethoughtはIntegrationsページで70以上の連携先を明示し、役割分担を細かく説明しています。

一方でAdaのdeep-diveを書く過程では、公式の機能ドキュメントよりも創業者インタビュー、Loop Earplugsの導入事例、BetaKitの報道から組み立てる部分の方が多くありました。

この記事と5社比較記事、両方の参考リソースを並べてみると、この厚みの差がそのまま出典の構成に表れています。ここまでAda公式について本記事が実際に引用できているのは、トップページ、Series Cを公表した公式blog記事、Loop Earplugsの導入事例の3点で、いずれも機能名を持つ独立したtrust・verificationのドキュメントではありません。これに対しSierraはTrust and reliability、IntercomはProcedures・Simulationsという、それ自体が製品ページの名前として存在するドキュメントを持っています。Adaの公式サイトについてこの記事がそこまで名指しできていないのは、単なる書き漏らしではなく、引き継ぎの発動条件や検証手順を独立した機能名で公開しているページを、5社比較記事とこのdeep-dive、どちらの執筆過程でも見つけられなかったことの反映だと私は考えています。

私はここに、5社の中でも特にAdaに固有の非対称を見ています。Adaは、運用担当がエンジニアを介さずに会話設計を回せるという自走性への思想は一貫していますが、その自走性が引き継ぎ境界のどこで止まるかを裏づけるhandoff条件を運用画面でどこまで明文化しているかの公開ドキュメントは、KustomerとならびSierra・Intercom・Forethoughtの3社ほど厚くない、というのが私の読みです。 これは5社を本番で並行運用して比較した結果ではなく、deep-dive執筆で一次情報を読み比べた範囲の判断です。だから私は、公式ページの情報だけでAdaの導入を判断することはできないと考えていて、商談の場でhandoff条件の仕様開示を具体的に求められる会社にだけ、Adaの検討を勧めます。

批判が集まりやすいのは「AIの弱さ」より「引き継ぎ」

創業者インタビューや公式事例だけを見ると、Adaは一方向にきれいな成功物語に見えます。ここで見えている批判の多くは、AI窓口全般に共通する構造だと私は考えています。Ada固有の弱点として読むと見誤ります。AI窓口の失敗は、問い合わせを受け、根拠文書を選び、その場で進めるか人へ渡すかを決め、会話ログを見直して次の分岐を直す、という一巡のどこかで起きます。詰まった会話をどう抜けるかという設計が弱いことが、その失敗の中心にあります。

実際に外部レビューを見ると、Adaに対する不満はある程度具体的な形で見つかります。VoiceflowのブログとG2のレビューには、Adaのチャットボットが有用な回答を返せず「終わりのないループ」に陥るケースや、担当者が引き継いだはずの内容を把握できていない、ボットのシナリオが不安定で対応が遅い、といった利用者の声がまとまって見つかります。ただし、私はこの5社すべてを同じ基準でレビューサイトまで横断して調べたわけではないため、この評価だけをもってAdaが他の4社より劣っていると結論づけることはできません。ここから言えるのは、Ada固有の弱点というよりも、詰まった会話の出口設計が甘いと、この種の不満としてレビューサイトに表れやすいという、AI窓口全般に共通する構造だということです。

だからこそ、導入前に見るべきは「AIが賢いかどうか」ではなく、次の点です。

• どの条件で人へ渡すのかが明文化されているか
• 返答に使う根拠文書の担当が決まっているか
• 会話ログを見直す担当者と頻度が決まっているか

時点メモ

恒久的な会社像として固定してよいのは、資本政策やイベントの語り口ではなく、次の結びで並べ直す「引き継ぎ境界を設計する」という根の部分だけです。

結び: 材料を2列に並べ直す

ここまでの材料を、判断のために2列に並べ直します。

公式ページだけで確認できること

• Adaが2016年にトロントで創業し、窓口業務の詰まりを起点にしていること
• ノーコードのビルダー画面で、運用担当が会話設計を直接触れる設計になっていること
• Loop Earplugsなど公開事例が、どんな業種・問い合わせの型で使われているか

商談で開示を要求すべきこと

• 引き継ぎ境界がどの条件で発動し、運用画面のどこで確認できるか
• 引き継いだ後、誰が何を最終的に確定させるか
• 会話ログを見直す頻度と担当を、自社の運用に合わせてどう設定できるか

この線引きについて、私自身の意見を述べておきます。私が勧めるとしたら、ノーコードで運用改善のサイクルを自走させたいチームで、かつ商談の場でhandoff条件の仕様開示を具体的に求められる会社だと考えています。勧めないのは、公式ページに書かれた情報だけで導入を決めようとしている会社です。この境界は、5社比較記事で整理した「Adaが向いている体制はノーコード運用を進めたいチームで、まず確認すべき論点は改善サイクルの自走性と多言語品質管理」という位置づけから導ける範囲の意見であり、実際の商談や支援でこの基準を使った経験から述べているものではありません。

私自身の結論は単純です。自走性という思想は評価していますが、開示が薄い製品を公式ページの情報だけで導入判断するのは危ういと考えています。この2列のうち後者を商談の場で埋められるかどうかが、Adaを検討してよいかの分かれ目です。

---

参考リソース

公式

• Ada公式サイト
• AdaがSeries Cを公表した公式blog
• Loop Earplugs Case Study

創業者・背景

• Ada CEO Mike Murchison is using AI to 'make customer service extraordinary'
• Bessemer is proud to back Toronto-native, Ada Support
• David Hariri on co-founding Ada, the pivot that created a unicorn

外部レビュー

• Is Ada AI Chatbot Your Best Choice? | Voiceflow
• Ada Reviews | G2

周辺文脈

• How Ada piggybacked Zoom and Shopify's growth during the pandemic to become a Canadian unicorn
• Report: Ada's Business Breakdown & Founding Story | Contrary Research

---

本記事はネクサフローのAI研究シリーズの一部です。