# カスタマーサポートは AI で最も厄介な問題だ - 番組: [The Stack Overflow Podcast](https://ai-curator.jp/podcasts/shows/cmv3z5c1l00105o106qjscjap)（The Stack Overflow Podcast） - 元のタイトル: Customer support is the gnarliest AI problem - 配信日: 2026年11月10日 - 長さ: 29分 - 要約作成日: 2026年11月10日 - トピック: [#AI エージェント](https://ai-curator.jp/topics/AI%20%E3%82%A8%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88) [#カスタマーサポート](https://ai-curator.jp/topics/%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%9E%E3%83%BC%E3%82%B5%E3%83%9D%E3%83%BC%E3%83%88) [#LLM評価（eval）](https://ai-curator.jp/topics/LLM%E8%A9%95%E4%BE%A1%EF%BC%88eval%EF%BC%89) [#AIコーディング](https://ai-curator.jp/topics/AI%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0) [#開発生産性](https://ai-curator.jp/topics/%E9%96%8B%E7%99%BA%E7%94%9F%E7%94%A3%E6%80%A7) [#Airbnb](https://ai-curator.jp/topics/Airbnb) - URL: https://ai-curator.jp/podcasts/cmwa8ltm000005s10spgdxpxx ## 要約 Stack Overflow Podcast のホスト Ryan Donovan が、Airbnb の CTO Ahmad Al-Dahle に、同社の AI 開発の進め方を聞いた回。二者間の紛争を仲介するカスタマーサポートを最難関の題材として選び、評価（eval）を軸に精度とレイテンシのバランスを取っていると語る。後半は AI コーディングツールの活用で、判断力・責任・品質管理・生産性の測り方をどう考えるかが議論された。 ## ポイント - Airbnb は検索ランキングやレコメンドの機械学習資産を土台に、生成 AI のエージェントをオフライン・オンライン双方で展開し、最難関としてカスタマーサポートを最初に選んだ。 - サポートが難しい理由は、ホストとゲストの二者間の解決を仲介する多者間問題であり、宿泊料金が高く判断の影響が大きく、多言語で正確さも求められる点にある。 - 評価データは固定の「ゴールデンセット」ではなく動く的と捉え、飽和したら難しい事例を集め直す。95% など高い数字を誇る評価は見直すべきだという考え。 - 自社モデルを特化させることでレイテンシ・コスト・性能の Pareto 曲線そのものを作り替えられると説明している。 - AI が生成した成果物でも作った本人が説明責任を負うべきで、使いこなせるかは判断力を働かせるかで決まるという立場。 - トークン使用量ではなく成果と実行速度を重視。今年は昨年比で 80% 多い機能を出荷し、本番の欠陥率は線形増加に抑えているという。 ## 章立て - [00:00] **Ahmad のキャリアと Airbnb の AI** — ウィニペグ育ちでゲームがきっかけで技術の道へ進み、Apple や Meta を経て Airbnb へ。検索・推薦中心だった ML プログラムが生成 AI に広がった経緯を語る。 - [02:06] **サポートが最難関な理由** — 二者間の仲介という多者間問題、高額な宿泊料金による高いリスク、規制や多言語対応で高い正確性が求められる点を説明する。 - [06:14] **精度とレイテンシの両立** — 本番トラフィックに基づく評価で Pareto を見極め、自社モデルを特化させる戦略を紹介する。 - [08:22] **動く的としての評価設計** — 固定データセットではなく飽和したら難問を集め直す考え方と、人に任せる領域も評価に含める姿勢、弱点の発掘手法を述べる。 - [13:37] **AI コーディングと判断力** — AI が生む長大な文書やスロップ PR の問題、成果物への責任、上級と初級エンジニアの差、context graph の試みを議論する。 - [19:43] **スキル乱立とトークン効率** — 社内で大量のスキルが作られる状況を活用度の表れと捉えつつ、トークン効率や標準スキルへの収れんを論じる。 - [21:52] **生産性・品質の測り方** — トークン使用量は指標にせず、成果と速度、ヒューマンタックスの低減を重視。欠陥率の管理や大規模マイグレーションの高速化にも触れる。 ## 解説記事 Stack Overflow Podcast の今回の回では、ホストの Ryan Donovan が Airbnb の CTO である Ahmad Al-Dahle に話を聞いた。長年の機械学習資産を持つ企業がエージェント AI をどう実装しているのか、そして AI コーディングツールが開発組織に何をもたらすのかが主題である。 #### 検索・推薦から生成 AI エージェントへ Ahmad は、Airbnb の機械学習プログラムがもともと検索ランキングとレコメンドに集中していたと説明する。物件探しは画像やテキストなど複数のモダリティを扱うため、AI と相性のよい問題が多いという。現在はそこに生成 AI を取り込み、ゲスト体験だけでなくホスト支援やマーケットプレイスの健全性、カスタマーサポートまで対象を広げている。 エージェントはオフラインとオンラインの両方で稼働しており、オフラインではマーケットプレイスの最適化を支援している。同社は、評価が最も難しく、確実に機能しなければならない問題を先に選び、エンジニアリングの規律という「組織の筋力」を鍛える方針をとった。その題材がカスタマーサポートだった。 #### なぜカスタマーサポートが最も厄介なのか Ahmad が挙げる理由は複数ある。第一に、Airbnb は両面市場であり、サポートは企業と顧客の一対一ではなく、ホストとゲストという二者の間の解決を仲介する多者間問題になる。多くのモデルは単独プレイヤー向けのタスクで訓練されるが、ここでは複数の当事者を前提にしなければならない。第二に、平均日額料金（ADR）の高い案件が多く、解決の影響が大きい。第三に、規制が絡む複雑な事業で、多言語のグローバル展開でもある。単純な情報検索に見える場面でも、RAG を入れるだけでは済まず、高い正確性が必要だと述べている。 Ryan が「交渉ボット」のようなものかと尋ねると、Ahmad は会社のポリシーに沿って解決を促す段階で、業界全体としてもまだ初期だと答えた。さらに、Airbnb らしさとして品質と仕上げへのこだわりがあり、最大級の遅いモデルに頼るわけにはいかず、待たされない速い応答が求められるとも語っている。 #### 評価（eval）が中心にある レイテンシと精度のトレードオフについて、Ahmad は「機械学習は eval、eval、eval から始まる」と答える。サポートは本番トラフィックがあり、何について問い合わせが来るかも分かるため、慎重に設計した評価を作りやすい。評価の仕組みがあれば、知能・コスト・レイテンシの Pareto を見渡して最適点を選べる。さらに自社でモデルをホストできるため、既存の Pareto に従うだけでなく、デコード速度が適したモデルを用途に特化させ、Pareto 自体を作り替えられるという。そのため自社のサポートエージェントは業界最高だと考えているが、第三者評価の裏づけはあるものの個人的な見方だと断っている。 評価の考え方も特徴的だ。固定のゴールデンセットは古い発想で、現在は「動く的」だと言う。飽和したらより難しい事例を集め直し、複雑さの分類（タクソノミー）で評価を分割する。単一の数字に丸めると改善の手がかりが失われるからだ。95% と 92% といった高スコアが出たチームには評価の作り直しを求める。サポートでは人間に委ねる領域を意図的に残しており、それも評価に含めるべきで、90% の達成を祝うより、強みと弱みが分かる 50% のほうがよいと述べた。100% は統計的に不可能で、到達したら何かおかしいとも言う。弱点の発掘には、人間のラベラー、敵対的テストやレッドチーミング、模擬エージェント、本番データの標的サンプリングなどがあり、フロンティアラボでも応用 AI でも同じ発想が通用するとしている。 #### AI コーディングで問われる判断力 後半は社内での AI 活用に移る。「エージェント型コーディングは個人の生産性を上げるがチームの一貫性を損なう」という指摘に対し、Ahmad は、協働のよい作法は AI 以前から変わらないと答える。能力が指数的に伸びたことで悪い振る舞いも増幅された、という見方だ。たとえば 42 ページの文書を一人で生成して共有し、受け手も AI で要約するような状況である。 その対策は、自分が作ったものを説明できるという文化的な期待だという。「エージェントが書いた」は言い訳にならず、責任は使った本人にある。コーディングエージェントを上手く使うか下手に使うかの差は、判断を働かせたかどうかに尽きると述べている。 また、新人のほうが AI ネイティブで有利だという見方には異を唱える。上級エンジニアは本番を壊した経験などで培った判断力があり、同じ手法でも欠陥の少ないコードを出せるが、経験の浅い人は欠陥が増えがちだという。刀鍛冶の徒弟と、機械が刀を量産する工場の比喩を使い、これが今後のソフトウェア開発に何をもたらすかはまだ分からないと認めた。取り組みの一つとして、組織の規範や知識を共有記憶として符号化する context graph を試しているが、決定打ではないと言う。 #### スキルの乱立、指標、品質 社内に大量の「スキル」が作られる状況について、Ahmad は良い面と悪い面の両方を認める。大規模な実験は AI を積極的に使っている証拠で、「月間アクティブ利用者 99%」より利用の強度と下流への影響が重要だという。悪い面はトークン効率で、同じダッシュボードを皆が AI で作り直すのは無駄になり得る。ただし一時的な問題で、データサイエンス用スキルのように 300〜400 人が使う標準が自然に浮上する。課題は発見よりも、どれを選ぶかという選択だと述べている。 生産性指標としてトークン使用量は一度も使っていない。ゼロなら警戒信号だが、それ以上は気にしないという。重視するのは成果と実行速度、そして調整コストである「ヒューマンタックス」を低く保つことで、目標の明確化と自律的なポッドが鍵になる。その結果として、今年は昨年より 80% 多い機能を同程度の複雑さで出荷したと語った。 品質面では、信頼性の目標を厳格に管理し、基準を超えると code yellow、code red を宣言する仕組みや、障害（SEV）の振り返りを徹底している。エージェント型コーディングの利用が指数的に伸びる一方、本番の欠陥は線形の増加にとどまっているという。DORA 指標のような従来指標については、法務やマーケティングが絡む機能では速度の測り方が難しいと認め、純粋なソフトウェア開発であるインフラの大規模マイグレーションでは速度を直接測れると述べた。 #### まとめ 今回の議論が示すのは、生成 AI の本番導入では、モデル選定よりも評価設計と組織の規律が成否を分けるという点だ。難しい題材を最初に選んで評価の仕組みを鍛え、飽和に応じて作り直すという姿勢は、サポート領域に取り組む日本の企業にも参考になる。また、AI が書いたコードにも書いた人が責任を負い、トークン量ではなく成果と欠陥率で見るという考え方は、AI コーディングを導入する開発組織が運用ルールを考える際の手がかりになるだろう。なお、自社サポートが業界最高だという主張は本人の見立てであり、数値などの根拠は番組内では示されていない。 > この要約・解説記事は、元の音声の文字起こしをもとに AI（Claude）が日本語で作成したものです。出典: The Stack Overflow Podcast「Customer support is the gnarliest AI problem」