AirbnbのAIコードシフト：コードの約60%をAIが書く時代に、人間の価値はどこへ移るのか

AI活用はソフトウェア開発だけに閉じていない。The Motley Foolが公開したAirbnbの2025年第4四半期決算説明会の書き起こしによれば、同社の独自AIサポートエージェントは北米でサポート課題の3分の1を解決し、チケットの約30%を処理した。今後はグローバル展開や音声対応も計画されている 。同じ書き起こしでは、旅行計画を支援し、会社がより効率的に運営できるようにする「AIネイティブ」な体験づくりも語られている 。

エンジニアの仕事は「書く」から「成立させる」へ

AIが実装の初稿を大量に作れるようになっても、エンジニアの仕事が消えるわけではない。むしろ、人間の仕事はより監督的で、設計的で、プロダクトに近いものになる。

これから重要になるのは、単にコードを書く量ではなく、良いソフトウェアが生まれる条件を整える力だ。具体的には、次のような能力の比重が高まる。

• 問題を正しく切り出す力。 目的、制約、期待する挙動、前提条件を明確にできるほど、AIの出力は使いやすくなる。
• システム文脈を与える力。 生成されたコードは、既存のコードベース、データ前提、権限境界、プロダクト要件に合っていなければならない。
• 出力を読む力。 生成されたコードを理解し、トレードオフを見極め、安全にリリースできるか判断する必要がある。
• エッジケースを潰す力。 初稿が速く出ることと、信頼できる品質になることは別問題だ。テスト、デバッグ、障害時の想定は引き続き不可欠になる。
• アーキテクチャを守る力。 生成コードが増えれば、保守すべきコードも増える。境界設計、依存関係、長期的な単純さはむしろ重要になる。
• 本番環境の結果に責任を持つ力。 信頼性、保守性、ユーザーへの影響について、最終的な責任を負うのは人間のチームだ。

この変化によって、エンジニアの強さの定義も変わる。スピードは引き続き重要だが、手で書いたコード量だけでは価値を測りにくくなる。差がつくのは、AIに何を作らせるか、何を却下するか、どこをリファクタリングするか、そもそも何を作らないかを判断する力だ。

レビュー能力が、より高価なスキルになる

AIコーディングは、初稿を安く速くする。だからこそ、使える初稿と危うい初稿を見分ける人の価値が上がる。

強いエンジニアは、プロンプトを入力して出てきたコードをそのまま受け入れる人ではない。むしろ、編集者、システム設計者、運用責任者を兼ねたような存在になる。生成されたコードがプロダクトの意図に合っているか、隠れた前提を壊していないか、既存アーキテクチャに収まるか、別のチームが将来保守できるかを確認する力が問われる。

チームが速くコードを生み出せるようになるほど、ボトルネックは「コードを書くこと」から「どのコードを存在させるべきかを決めること」へ移る。AI時代にシニアな技術判断が軽くなるどころか、より重くなる理由はここにある。

マネジャーも「技術から離れる」余地が小さくなる

Chesky氏の発言で見逃せないのは、マネジャーへの要求だ。Airbnbでは、マネジャーもコードを書いたりAIコーディングツールを使ったりすることが求められつつあると報じられている 。またPeople Mattersは、「純粋なピープルマネジャー」へのChesky氏の警告を報じており、調整だけを担う管理職には圧力がかかり得る 。

これは、すべてのマネジャーがチーム内で最強の個人開発者でなければならない、という意味ではない。だが、技術的な理解を避けたままマネジメントすることは難しくなる。

AI活用が進んだチームのマネジャーには、少なくとも次の力が必要になる。

• AIツールに何ができ、何が苦手なのかを理解する。
• 進捗確認だけでなく、技術的なトレードオフを評価する。
• 見積もり、設計、生成コードに含まれる弱い前提を問い直す。
• レビュー、テスト、セキュリティ、信頼性の品質基準を明確にする。
• 手作業の量ではなく、リリースされた価値とシステムの健全性でチームを見る。

採用、育成、優先順位づけ、チームの健康状態を保つことは、今後もマネジャーの重要な仕事だ。ただしAirbnbのような方向へ進む企業では、それらに加えて、ツールと技術作業への実感を持つことが求められる。

圧力がかかるのは「肩書」ではなく「狭すぎる役割」

リスクが高いのは、「エンジニア」や「マネジャー」という肩書そのものではない。危ういのは、仕事が定型的なアウトプットに狭く閉じている場合だ。

特に圧力を受けやすいのは、次のような働き方だ。

• システム全体を理解せず、目の前のコードだけを書く。
• AI生成物を十分にレビューせず受け入れる。
• プロダクト価値ではなく、処理したタスク量で成果を語る。
• 技術的な中身を理解せず、調整だけを行う。
• チームの標準になりつつあるAIツールの学習を避ける。

逆に安全度が高いのは、AIで速度を上げながら、品質、アーキテクチャ、運用結果に責任を持てる人材だ。言い換えれば、強い判断力を持つ技術的オペレーターである。

今、エンジニアとマネジャーが取るべき構え

エンジニアにとって現実的な対応は、AIを無視することでも、盲信することでもない。AI支援の開発に熟達しつつ、結果への責任を手放さないことだ。仕様を明確に書く、文脈を十分に与える、差分を丁寧に読む、テストを厚くする、アーキテクチャ・信頼性・セキュリティ・プロダクト感覚を磨く。こうした地味な力が、むしろ価値を増す。

マネジャーにとっては、現場の技術から遠ざからないことが重要になる。自分でもツールを使い、得意不得意を体感する。設計やレビューの会話に参加する。品質基準を明文化する。手で打ったコード量ではなく、長く使えるプロダクト成果を評価する。

ただし、Airbnbはシグナルであって市場全体ではない

Airbnbの約60%という数字は、あくまでAirbnbの事例であり、すべてのソフトウェア組織が同じ段階にいることを意味しない。

Chesky氏自身も、AIについては加速と時間の両方を見ている。2024年には、AIは多くの人が思う以上に世界を変える一方で、多くの人が予想するより時間がかかるとも述べていた 。この見方は、今回の変化を理解するうえで重要だ。AIはソフトウェアの仕事を大きく変え得るが、その移行は一様ではない。

結論として、AIはエンジニアやマネジャーを単純に置き換えているのではない。人間の貢献単位を変えている。エンジニアは、機械が生成した成果物のディレクターでありレビュアーである必要がある。マネジャーは、AIを日常的に使うチームを率いるだけの技術的な解像度を持たなければならない。Airbnbの事例で見えてくる持続的な優位性は、手作業の量ではなく、判断力、所有責任、AIの出力を信頼できるプロダクトに変える力へ移っている 。