Airbnbが予約1件あたりのサポートコストを約16%削減——AIの効果を「単位あたり」で測るということ

AI開発・生成AI活用公開日:2026年8月9日
徐 聖博
徐 聖博

株式会社シンシア 代表取締役社長

Share
目次開く
  1. 要点 (出典の事実のみ)
  2. 「削減時間」ではなく「1件あたりコスト」で測る
  3. 45%という数字の読み方
  4. 開発会社の事業判断にどう効くか
  5. 誤読しやすい点

シンシアへのご相談

自社のAI活用・開発体制について相談する

AIをどこまで内製するか、どの業務から着手するか、体制をどう組むか。開発会社・SIer・事業会社の開発部門の方からのご相談を無料で承っています。同じ問題を自社でも解いている立場としてお話しします。

AI活用の進め方を相談する

まだ検討段階の方は 質問だけでもOK(電話番号は任意)

Airbnb の2026年第2四半期決算で、予約1件あたりのカスタマーサポートコストが前年同期比で約16%減ったことが公表されました。AIアシスタントの改善が要因の一つとされています。私がこの発表で重要だと考えるのは削減率そのものではなく、効果を「1件あたり」という単位で測って開示したという点です。AI導入の効果測定に悩んでいる会社にとって、ここは真似できます。

要点 (出典の事実のみ)

  • 2026年第2四半期の売上は36億ドルで前年同期比17%増。総予約額(GBV)は272億ドルで16%増、予約数は10%増と第1四半期から加速した。純利益は8億1,600万ドル、調整後EBITDAは13億ドルで21%増、マージンは35%へ拡大した。
  • カスタマーサポートの予約1件あたりコストが前年同期比で約16%減少。AIアシスタントの改善が要因の一つとされている。
  • AIアシスタントで始まった問い合わせのうち、約45%が人間のエージェントを介さずに解決している(第1四半期から上昇)。AIアシスタントは50言語以上に対応する。
  • 通期見通しを引き上げ、売上成長率を従来の「low〜mid teens」から「少なくとも mid-teens」へ、調整後EBITDAマージンを35%から35.5%以上へ変更した。
  • 第3四半期は売上46.9〜47.7億ドル(15〜17%増、うち約3ポイントは為替の追い風)を見込む。

「削減時間」ではなく「1件あたりコスト」で測る

AI導入の効果を社内で説明するとき、多くの場合は「月◯時間削減」「利用率◯%」という形で報告されます。私はこの測り方に前から違和感があります。事業が伸びているときに、削減時間は増えて当たり前だからです。逆に事業が縮めば削減時間も減る。事業規模の変動とAIの効果が混ざってしまい、投資判断の材料にならない。

Airbnb が出したのは「予約1件あたり」でした。分母を業務の単位に取ると、事業が伸びても薄まらず、縮んでも見かけ上よくならない。AIの効果だけが残る形になります。 そのうえで同じ四半期に売上が17%伸び、EBITDAマージンが拡大している。つまりこの16%は「人を減らして浮かせた」数字ではなく、取扱量が増えても人件費を比例で増やさずに済んだという数字です。

私が マイクロソフトの決算について書いたときの評価軸 — 増額を止めた状態で成果が伸びるか — と、見ている場所は同じです。規模も業種も違いますが、分母を固定して比べるという点で一致しています。

45%という数字の読み方

もう一つ具体的なのが、AIアシスタントで始まった問い合わせの約45%が人を介さずに解決している、という開示です。これは裏を返せば残りの55%は人に回っているということです。

私はこの割合を、達成度ではなく設計値として読みます。全件をAIで解こうとすると、解けない問い合わせが宙に浮き、体験としては最悪になります。先日書いたモノタロウの購買エージェントも同じ構造で、曖昧さを扱う部分だけをAIに渡し、確定的に処理すべき部分は既存の仕組みに残す設計でした。Airbnb のサポートも、AIが解ける種類の問い合わせを選別し、それ以外を人に渡す振り分けが効いているはずです。

45%を100%に近づけることが目標ではありません。振り分けの精度を上げ、人に回ったときの引き継ぎが滑らかであることのほうが、体験としてもコストとしても効きます。

開発会社の事業判断にどう効くか

三つ挙げます。

一つ目。効果測定の分母を、業務の単位に取る。 顧客にAI導入を提案するとき、KPIを「削減時間」で置くと、公開後に「本当に効いているのか」の議論が必ず起きます。問い合わせ1件あたりの対応コスト、案件1件あたりの工数、受注1件あたりのリードタイム。分母を業務の単位にして、導入前の数字を先に取っておく。 これは提案段階でやるべきことで、後から遡って測ることはできません。

二つ目。「AIが解ける割合」をKPIとして明示し、残りの導線を設計に含める。 45%という数字が公表できるのは、AIが解いた件と人に回った件を分けて計測しているからです。この計測ができていない導入は、効果も説明できず改善もできません。振り分け率と、人に回ったときの引き継ぎ品質。この2つを最初から要件に入れます。

三つ目。提案の価値を「人員削減」ではなく「成長しても人を比例で増やさないこと」に置く。 前者は社内の抵抗を生み、導入自体が止まります。後者なら、増員が難しい状況にある会社ほど価値が伝わる。実際 Airbnb は売上を伸ばしながらこの数字を出しています。削減した時間をどこに使うかが本当の問いだと以前書きましたが、答えの一つは「増えた分を捌く」です。

誤読しやすい点

16%はAIだけの成果ではありません。 出典でも「AIアシスタントの改善が要因の一つ」とされており、他の施策や構成の変化も混ざっているはずです。「AIを入れれば1件あたり16%下がる」と読むのは誤りです。

もう一つ、Airbnb のAIアシスタントは50言語以上に対応しています。これは同社の事業特性から来る前提条件であって、規模の小さい会社が同じ削減率を期待する根拠にはなりません。参考にすべきは測り方と振り分けの設計であって、削減率そのものではないと考えています。

なお、この種のコスト側のレバレッジは、利益率の薄い事業ほど大きく効きます。BtoBのカスタマーサポートで基幹システムとのAPI連携を核に据えたミスミの事例と並べて読むと、何を繋ぐと解決率が上がるのかが見えてきます。

出典: Airbnb shares gain as investors cheer revenue forecast raise, AI payoff (Reuters、2026年8月7日)

※本文中の数値は Airbnb 公式の第2四半期決算発表 で確認した値を採用しています。

Share

シンシアへのご相談

自社のAI活用・開発体制について相談する

AIをどこまで内製するか、どの業務から着手するか、体制をどう組むか。開発会社・SIer・事業会社の開発部門の方からのご相談を無料で承っています。同じ問題を自社でも解いている立場としてお話しします。

AI活用の進め方を相談する

まだ検討段階の方は 質問だけでもOK(電話番号は任意)

徐 聖博のプロフィール写真

この記事の書き手に直接相談する

徐 聖博株式会社シンシア 代表取締役社長

記事の内容について、より具体的に自社のケースで聞きたいことがあれば、徐 聖博を指名してご相談いただけます。営業担当ではなく、 実際に手を動かしている本人が回答します。

シンシアの開発事例

株式会社Atsumell様|サービスを止めずにデータ基盤を刷新したBPマッチングプラットフォームの開発事例

**約11ヶ月・のべ4名のリレーで、機能開発を止めることなく基盤の刷新を完了しました。** 参画時期の重なりは最大2〜3名で、メンバーは1ヶ月の短期集中から5ヶ月の継続稼働までさまざまです。それでも積み上げが効いたのは、**先に入ったメンバーが構造を残していたから**でした。2025年7月に導入された Repository 層の上で、半年後に別のメンバーが移行作業を進めています。認可条件はコード上の仕様コメントとして、スナップショット方式はアーキテクチャドキュメントとして残り、いずれも「引き継いだ人が読んで分かる」形になっています。 この期間に手掛けた業務機能は、協力会社のラベル分類機能、パートナー企業管理画面、CSV による一括招待とデータ出力、案件辞退フロー、ステータス変更通知メールなど多岐にわたります。基盤刷新と機能開発は、どちらかを止めて行ったものではありません。 > 大規模な基盤刷新は「一度止めて作り直す」以外にも方法があります。呼び出し側を壊さない層を挟み、テーブル単位で少しずつ移し、移行と改善を混ぜない。この3つを守れば、リリースを止めずに土台は入れ替えられます。事業を止められないプロダクトほど、この進め方の価値が出ます。 ### この事例からの示唆 **稼働中のサービスでも基盤は入れ替えられる。** 前提は、呼び出し側の契約(戻り値の形)を保つ中間層を挟むこと、移行単位をテーブルや画面まで小さく割ること、そして移行と機能改善を同じコミットに混ぜないことの3点です。この3つが崩れると、不具合が出たときに原因が移行なのか改善なのか切り分けられなくなり、結果として一度止めるしかなくなります。 **メンバーが入れ替わる前提の体制では、成果物より「残る構造」が価値になる。** 短期参画のエンジニアを増やしても積み上がらないプロジェクトは、設計判断が個人の記憶に閉じていることが原因であるケースが多いです。この事例では、認可条件をコード上の仕様コメントとして、データ設計をアーキテクチャドキュメントとして残す運用を徹底しました。開発体制の失敗パターンについては[システム開発の失敗から立て直す方法](https://blog.xincere.jp/articles/system-development-failure-patterns)でも整理しています。 **要件が固まりきらない領域ほど、データ設計で制約を表現する。** 「協力会社が人材情報を編集したら応募内容が変わってしまう」といった問題は、運用ルールやUIの注意書きでは再発します。スキーマとトリガーで表現すれば、アプリ側の実装漏れがあっても壊れません。要件を仕様に落とす工程そのものについては[要件定義の進め方](https://blog.xincere.jp/articles/requirements-definition-process)を参照してください。 ### よくある質問 **Q. 稼働中のサービスを止めずに基盤刷新はできますか。** A. できます。この事例では約11ヶ月にわたり、機能リリースを継続しながらデータアクセス基盤の移行と主キー変更まで実施しました。ただし「一斉に切り替える」やり方では現実的に困難で、呼び出し側を壊さない中間層を用意して段階移行する設計が前提になります。 **Q. 途中でメンバーが入れ替わる体制でも品質は保てますか。** A. 設計判断がドキュメントとコードに残っていれば保てます。この事例では参画時期の重なりが最大2〜3名、1ヶ月だけの参画者もいる体制で、前任の導入した層の上に後任が半年後の移行作業を積み上げています。 **Q. どのくらいの規模・期間の支援ですか。** A. 約11ヶ月、のべ4名(同時稼働は最大2〜3名)です。プロジェクトの規模や費用感の考え方は[システム開発とは](https://blog.xincere.jp/articles/what-is-system-development)で解説しています。 ### 関連する支援領域 - [システム刷新の進め方|検討・計画から移行までの方法](https://blog.xincere.jp/articles/core-system-renewal-guide) — 稼働中システムを止めずに刷新する判断基準 - [業務システム開発の要件定義とは?進め方・手順を7ステップで解説](https://blog.xincere.jp/articles/business-system-development-requirements-definition-steps) — 要件を仕様に落とす工程 - [システム開発の失敗から立て直す方法](https://blog.xincere.jp/articles/system-development-failure-patterns) — 体制・引き継ぎで詰まったときの選択肢 同じように「稼働を止められないプロダクトの基盤を作り替えたい」という課題をお持ちでしたら、[開発のご相談](https://blog.xincere.jp/contacts)からお問い合わせください。現状のコードとデータ構造を確認したうえで、段階移行の設計からご一緒します。

株式会社Atsumellの事例を読む →

この記事が役に立ったら、Google で優先表示を

Google 検索の「優先するソース」に blog.xincere.jp を追加すると、シンシアの新着記事がトップニュースなどで見つけやすくなります。

Google で優先ソースに追加

著者について

徐 聖博のプロフィール写真
徐 聖博
株式会社シンシア 代表取締役社長

株式会社シンシア(Xincere, Inc.)代表取締役。中国生まれ・3歳から日本で育ち、日本語・中国語・英語を操るトリリンガル。大学院でコンピュータサイエンス(進化型ニューラルネットワーク)を研究し、GREE・メドレー・カウンティア・Indeed Japan などで検索エンジン開発やスタートアップの立ち上げ・グロースを経験。2020年に「人の価値をテクノロジーで最大化する」という想いでシンシアを創業した。エンジニア歴15年以上、代表でありながらほぼ毎日コードを書く現役エンジニアとして、基幹システム開発からAIエージェント活用まで顧客の事業成長に並走している。創業に込めた思いはnoteの創業ストーリーに綴っている。

人気記事

    お問い合わせ

    システム開発やAI推進についてのご相談はこちらから

    無料相談を予約する