AirbnbのAl-Dahleさんは、仕様書の代わりにプロトタイプで何を決めているか。

仕様書を減らしてプロトタイプで話すようにしたチームで、半年後に「これ、誰が決めたんだっけ」と聞かれて言葉に詰まったことはありませんか？

AirbnbのCTO、Ahmad Al-Dahleさんの発言を伝えた英語の記事を読むと、手放したのは「過剰な成果物づくり」で、代わりにエンジニア全員へ「作ったものを説明できること」を求めていました。仕様書が担っていた仕事のうち、プロトタイプが引き受けたものと、まだ誰も引き受けていないものを分けて読むと、自分の現場で何を残すべきかが見えてきます。

Inside-Out AI: Rebuilding Airbnb Behind the Scenes and Across the Guest Experience

After leading Meta’s Llama models, Ahmad Al-Dahle is now transforming Airbnb with AI — from how its teams develop products to how it serves guests.

www.latent.space

AirbnbのCTOがやめたのは、仕様書ではなく過剰な成果物

Al-Dahleさんは2026年1月からAirbnbのCTOを務めています。その前はMetaで生成AI部門を率い、2023〜2025年にLlamaモデルの公開を主導した人です。今回の発言は、2026年10月2日にLatent Spaceが掲載したRichard MacManusさんの署名記事で紹介されました。

記事によると、従来のソフトウェア開発は、プロダクト要件を書き、Figmaでデザインし、エンジニアが実装し、最後に本番でテストするという引き継ぎの連続でした。Airbnbではいま、プロダクト、デザイン、エンジニアリングの各チームが直接プロトタイプに取りかかります。その変化を、Al-Dahleさんはこう言い表しました（筆者訳）。

私たちは過剰な成果物づくりから離れ、コードそのものとプロトタイプを、考えるときの拠り所となる成果物にしました。 原文: We moved away from excessive artifact generation to the code being the artifact that we reason upon, and prototypes.

「仕様書をなくした」とは、ひと言も言っていません。削ったのは「過剰な」分です。「仕様書をやめた会社」として紹介したくなる話ですが、原文の線引きはもっと細かいと思います。

記事には数字も出てきます。ただ、話した人と出どころがまちまちなので、混ぜて引用しないよう整理しておきます。

公式のQ2決算リリースにも「60%」が出てきますが、こちらは主要な取り組みで構想から提供までの期間を最大60%縮めたという別の数字です。コードの60%とは混同しないほうが安全ですね。

仕様書は、いくつの仕事を兼ねていたのか？

Excel方眼紙の仕様書を長く書いてきた側から見ると、仕様書は1冊で次の仕事を兼ねていました。

1. 認識を合わせる。発注側と作る側が、同じ画面と同じ動きを思い浮かべるための台本です
2. 承認をもらう。押印欄に印がそろえば、そこから先は「決まったこと」として扱えました
3. 決定を残す。改訂履歴のシートに、いつ、誰の判断で、何を変えたかが書かれていました
4. 次の人に渡す。保守の担当が替わっても、仕様書を開けば前提が分かりました

どれも「仕様書」という1つの名前で呼ばれているので、別々の仕事だと意識されにくいですね。プロトタイプに置き換えるときも、どの仕事を置き換えたのかを決めないまま進みがちです。

あなたのチームでは、いま仕様書がどの仕事を一番担っているでしょうか？

プロトタイプが引き受けた仕事、まだ空いている仕事

認識合わせは、プロトタイプのほうが得意です。「検索結果を絞り込める」と文章で書くより、動く画面を触ってもらうほうがずれは早く見つかります。Airbnbが引き継ぎの往復を減らせたのも、要件、デザイン、実装の間で毎回訳し直す手間がなくなったからだと私は見ています。

承認も、プロトタイプを前に「これで行こう」と言える場があれば代わりが利きます。

空きやすいのは残りの2つです。プロトタイプは「いまどう動くか」を見せてくれますが、「なぜこの動きにしたのか」「捨てた案は何だったか」は残しません。仕様書を書かなくなると、誰が何を決めたかの記録が一番に消えるんですよね。

ここはLatent Spaceの記事には書かれていない、私の読みです。ただ、Al-Dahleさんが置いた歯止めを見ると、同じ穴を別の方法でふさごうとしているように見えます。

AirbnbのCTOが置いた歯止めは、説明できること

Al-Dahleさんが気にかけているのは、若手エンジニアの育ち方です。シニアは何年もシステムを出荷し、本番を運用し、失敗からも学んで判断力を身につけてきました。AIに多くを任せる若手が、同じ力を得られるのか。そこへの答えが次の発言です（筆者訳）。

私が強く推し進めていることの1つは、たとえAIがPRを生成したとしても、すべてのエンジニアが自分の作ったものを説明できなければならない、ということです。

この前提が守られれば、若手もインターフェース設計やアーキテクチャ、単体テストや結合テストの大切さを身につけていける、と発言は続きます。

私はこの「説明できること」を、仕様書の「決定を残す」仕事の口頭版として読みました。説明できる人がいる限り、なぜこの動きなのかを聞けば答えが返ってきます。

とはいえ、口頭の説明はその人が異動すれば一緒にいなくなります。説明を、誰かが後から読める形で置いておく仕組みがもう1つ要るはずです。

AIが書いたコードについて「なぜこう書いたのか」と聞かれたとき、あなたの現場で答える人は決まっていますか？

AirbnbのEverestは、仕様書の記憶の置き場所なのか？

記事には、その仕組みに近いものが出てきます。LLMと埋め込み、AIによる検索を使って社内の文脈をグラフにし、必要なときに引けるようにしたもので、Airbnbでは「Everest」と呼ぶ組織のコンテキストグラフです。

例に挙がっているのが食料配達と空港送迎でした。Cheskyさんが決算説明会で話したところでは、食料配達の開発には8〜9ヶ月かかり、空港送迎は約6週間でした。記事によると、先に作った食料配達の学びがEverestに入り、空港送迎のチームはそれを使ってずっと速く進められたそうです。

ただしAl-Dahleさん自身が、2つはどちらもパートナー企業のAPIと連携する似たサービスだと説明しています。6週間をEverestだけの成果と読むのは言い過ぎで、2回目だから速かった面も大きいと思います。

このグラフがコードベース全体にあるおかげで、ジェネラリストのエンジニアでもとても専門的なコードの領域で仕事ができる、ともAl-Dahleさんは話しています。私はこれを、仕様書の「次の人に渡す」仕事を、文書の代わりにグラフで引き受けようとする動きとして読みました。Everestに「誰がなぜ決めたか」まで入っているのかは、記事からは分かりません。

プロトタイプ会議で、まず決めておきたいこと

Everestのような社内基盤がなくても、仕様書の仕事を取りこぼさない工夫は会議の運用で始められます。プロトタイプ会議をこれから始めるなら、次の3つから試してみてください。

1. 決定を1行だけ残す。「誰が、何を、なぜ」の3点を、プロトタイプのリンクと同じ場所に書きます。改訂履歴のシートを1行に縮めたものだと思えば十分です
2. プロトタイプごとに説明役を決める。AIが書いた部分も含めて「なぜこう動くのか」に答える人を、作った時点で1人決めておきます
3. 捨てる成果物と残す成果物を分ける。会議資料、画面遷移図、議事録のうち、プロトタイプがあれば要らないものを「過剰」として外し、決定の記録だけは残します

記事から読み取れる範囲では、Airbnbがプロトタイプで決めているのはどう動かすかで、なぜそうしたかは作った人の説明に預けています。その説明をどこに残すかが、仕様書を減らすチームの次の宿題だと思います。

あなたのチームのプロトタイプには、説明できる人の名前が付いていますか？