社内から始めるAI改革、Airbnbの事例を元に一般企業にも応用できる進め方を考える

「AIネイティブな会社になる」と言われても、何から手を付ければよいのかは見えにくいものです。MetaでLlamaの公開を率い、2026年1月にAirbnbのCTOになったAhmad Al-Dahle氏が、Latent Spaceのインタビューでその中身を具体的に話しています。インタビューの筆者は、この進め方を「inside-out」（社内から外へ）と呼んでいます。AIをまず社内の仕事に使って開発を速くし、同じ能力を顧客体験へ回すという順番です。

Airbnbは時価総額が約930億ドルと、一般的な企業とは規模が違います。それでも話の中には、人数や予算に関係なく真似できる部分がかなりあります。この記事では、インタビューの内容を決算説明会の記録などと突き合わせたうえで、自社の仕事に置き換えられる点を中心に整理します。

先に社内、次に顧客：順番の意味#

Al-Dahle氏は、Metaでは「モデルの能力を世代ごとに上げる流れ」がわかっていたと言い、次の難所は「モデルを大規模に展開すること」だと考えてAirbnbに移ったと話しています。Airbnbでの目標は、AIを理由に「人の働き方を変えること」と、AIを本番環境に載せて「中核の体験に価値を足すこと」の2つです。

具体的な順序は次のとおりです。

1. 社内の開発プロセスにAIを入れ、機能を出す速さを上げる
2. その過程で作った社内の仕組みを使って、顧客向けの新サービスを短期間で作る
3. 顧客向けの場面でも、AIで解決する範囲を段階的に広げる

順番を逆にすると、顧客に見える場所で試行錯誤することになります。社内なら失敗しても影響が小さく、学んだことを次の案件にも使えます。一般企業でも、最初の対象を「社内の仕事」に置く理由はここにあります。

成果の数字は、どこまで裏付けられているか#

インタビューで挙がった数字を、決算説明会の記録（Motley Foolの書き起こし）と照らすと、次のようになります。

• 機能・改善の出荷数が前年比で約80%増: 決算説明会でCEOのBrian Chesky氏が「前年の同じ6か月と比べて、出荷した機能と改善の数が約80%増えた」と述べています。インタビューの数字と一致します
• サポートの問い合わせの約45%がAIだけで解決: Al-Dahle氏は「約半分」と話しましたが、決算では「AIアシスタントで始まった問い合わせのうち約45%が、人の担当者なしで解決された」とされています。Customer Experience Diveによれば、第1四半期は40%でした。分母が「AIアシスタントで始まった問い合わせ」である点は、自社の数字と比べるときに揃えておく必要があります
• サポート費用: 1予約あたりのサポート費用は前年比で約16%減っています。決算では、AIアシスタントの改善が一因とされています。「一因」であって、すべてがAIの成果とは言っていません
• 構想から提供までの期間: 重要施策の一部で、最大60%短縮したと決算で述べられています
• AIが書くコードが約60%、エンジニア1人あたりのプルリクエスト処理量が約1.6倍: 筆者が確認できた範囲では、決算の資料にはなく、Al-Dahle氏の発言として書かれています。社内の集計方法も示されていないため、目安として読むのが適切です

出荷数や解決率のように外から確かめられる数字と、社内の自己申告でしか確かめられない数字は、分けて読んだほうがよさそうです。自社でAI活用の成果を報告するときも、同じ分け方が使えます。

成果物を文書からプロトタイプへ#

最初に挙げられたのは、組織の進め方の変更です。従来は、要件定義、Figmaでのデザイン、エンジニアリングの実装、本番での検証と、次の工程へ引き継ぎながら進めていました。Airbnbでは、プロダクト、デザイン、エンジニアリングのチームがプロトタイプを直接触りながら進めるように変えたと言います。

Al-Dahle氏は、要件定義書のような「成果物」を過剰に作る状態から、「コードとプロトタイプが、判断の材料になる成果物」という状態に移ったと話しています。引き継ぎごとの待ち時間を減らせたことが、時間短縮の大きな要因だったという説明です。

一般企業の業務に置き換えると、次のような読み替えができます。

• 企画書を書く前に、動くもの（簡単な画面や、AIに作らせた試作）を先に作って関係者に見せる
• 部門間で文書を回す前に、同じ画面や同じデータを見ながら話す場を作る
• 文書は、判断が済んだあとの記録として残す

AIがコードを書く速さが上がると、文書を書くコストとの差は縮まります。「文書を整えてから作る」順序のほうが、かえって遅くなる場面が増えるはずです。

AIに任せない問い合わせを、先に決める#

サポートは、顧客向けでAIを最初に入れた領域でした。Al-Dahle氏はここを「展開がいちばん難しい」領域と呼んでいます。間違いの影響が大きいためです。

進め方には、2つの特徴があります。

• 本番に出す前に、合成データでテストを重ねる: モデルとエージェントを作ったら、本番に入る前に大量の合成データを生成して試す、という順序です
• AIに任せない問い合わせを意図的に決める: 同氏は「約50%を解決している一方で、まだエージェントに任せないと決めた問い合わせにも意識的だ」と話しています。例として挙がっているのは安全に関わる問い合わせです

一般企業のヘルプデスクや社内問い合わせ窓口でも、最初に決めるのは「どこまでAIに任せるか」より「どこから先は人が受けるか」のほうが、安全に始められます。解決率の目標を先に置くと、人に渡すべき問い合わせまでAIに抱えさせる方向に引っ張られやすいためです。

AIアシスタントは50以上の言語で使えるとも、決算で述べられています。2026年の後半には音声（電話）対応の導入も予定されています。

新サービスの開発期間を縮める社内の知識基盤#

Airbnbのグロサリー配送と空港送迎は、2026年の初めに投入された新しいサービスです。Al-Dahle氏によれば、どちらもパートナー企業とのAPI連携という「似た種類の」サービスで、社内の組織の文脈を扱う仕組み「Everest」が開発を支えました。Everestは、大規模言語モデル、埋め込み、AIによる検索を使ってグラフを作り、問い合わせる仕組みです。

先に作ったグロサリーの知見をEverestに蓄積したことで、空港送迎のチームは同じ作業を大幅に短縮できた、というのが同氏の説明です。決算説明会でも、Chesky氏が「グロサリーは8か月、9か月かかり、空港送迎は約6週間で作れた」と述べています。ただし、決算の発言はEverestとの関係には触れていません。「Everestのおかげ」という因果は、Al-Dahle氏の説明として読むのが妥当です。

この仕組みのもう1つの効果として、同氏は「コードベース全体に文脈のグラフがあるおかげで、ジェネラリストが専門性の高い部分でも作業できる」と話しています。

一般企業で、Everestのような仕組みをいきなり作る必要はありません。次のような小さな形でも、考え方は使えます。

• 1つ目の案件で決めたこと、つまずいたこと、連携先の仕様を、検索できる形で残す
• 2つ目の案件では、それをAIに読ませてから始める
• 似た案件が続く領域（外部サービスとの連携、定型の申請など）から試す

効果が出やすいのは、このように似た案件が続く領域です。1回きりの案件で知識基盤を作っても、元が取れない可能性があります。

モデルは用途ごとに評価して選ぶ#

Airbnbは「マルチモデルの会社」だと説明されています。frontierモデル（各社の最先端のモデル）とオープンモデルを併用し、追加学習や強化学習は主にオープンモデルで自社で行っています。本番用途にカスタマイズしたモデルは、少なくとも10個あるそうです。

選ぶ基準は、コスト、性能、遅延のバランス（Paretoフロンティア）で、用途ごとに別の点を選びます。

用途	選ぶモデルの傾向	理由（Al-Dahle氏の説明）
コーディング	使える最強のfrontierモデル	遅延は許容でき、欠陥1つあたりの損失が大きい
検索	小さく専門化したモデル	利用が大規模で、遅延に敏感

評価も用途別です。検索なら本番から抽出した検索クエリの集合、サポートなら、エッジケースを含めて重要な本番の問い合わせの集合を使って測っています。同氏は、狭い用途では小さなモデルを追加学習して「frontierを超えるところまで」持っていけたことがあると話しています。これは同氏の主張で、外部の検証は示されていません。

オープンモデルの追加学習まで自社でやる必要はありません。応用できるのは、次の2点です。

• 「どのモデルが賢いか」ではなく、「自社の業務のサンプルで、どのモデルが十分か」で決める
• 評価用の質問集を、実際の業務の記録から作る

評価用のサンプルが手元にあれば、新しいモデルが出るたびに入れ替えの判断ができます。

夜間対応を非同期エージェントに任せる#

次の変化としてAl-Dahle氏が挙げたのは、コンテナの中で動き、イベントをきっかけに起動する非同期エージェントです。Airbnbには、社内向けの対話エージェント「AirChat」があり、組織の文脈をMCP経由で扱えます。それに加えて、チームの多くがオンコール（障害の一次対応）の自動化を始めているそうです。

流れは次のとおりです。

1. 監視ツール（例としてGrafana）のしきい値を超える
2. エージェントが起動して、一次対応の切り分けを行う
3. 修正案があれば、プルリクエストとして出す。人間のエンジニアがそれをレビューする
4. 誤検知（flaky）だと判断したら、エージェントがインシデントを閉じることもある

同氏は、将来はマーケットプレイス全体で、不正、信頼違反、品質、ソフトウェアの欠陥の監視にも広げたいと話しています。

ここでも、人間のレビューが残っている点が参考になります。一般企業なら、ログの異常検知の一次切り分けや、定型の障害報告の下書きのように、影響の小さい領域から始められます。

AIが書いたものを説明できる人を残す#

最後の話題は、若手エンジニアの育成です。Al-Dahle氏が懸念しているのは、AIが多くの作業をこなすなかで、若手が技術の勘どころと判断力を身に付けられるかどうかです。シニアのエンジニアは、本番で何年もシステムを動かし、失敗も重ねて判断力を得てきたからです。

対策として同氏が強く求めているのは、「AIが生成したプルリクエストであっても、作った内容をエンジニア自身が説明できること」です。この前提が守られれば、若手もインターフェース設計やアーキテクチャ、単体テストや統合テストの重要性を学べる、という考えです。

この規則は、ソフトウェア開発以外にも当てはまります。AIが作った資料、集計、メールの文面も、提出した人が「なぜそうなったか」を説明できることを条件にすると、確認の責任が曖昧になりません。

あわせて同氏は、機能ごとではなく、目標や成果ごとにチームを組む組織のほうがAI時代に向いていると話しています。

読むときの注意#

インタビューは、会社のCTOが自社の取り組みを説明した内容です。成果の数字には、決算で裏付けられるものと、社内の発言だけのものが混在しています。なお、米国証券取引委員会（SEC）の決算資料の原文は筆者の環境では取得できず、決算の数字は書き起こしと報道で確かめました。

自社に当てはめるときは、6つすべてを一度に始める必要はありません。まず1つ選ぶなら、次の問いから始めるのが現実的です。

• 次の企画は、文書の前にプロトタイプを1つ作れないか
• AIに任せない問い合わせを、先に書き出せないか
• 評価用のサンプルを、実際の業務の記録から20件集められないか