People Mattersも、Chesky氏が「純粋なピープルマネジャー」や新しい技術への適応を拒む働き手は取り残されるリスクがあると警告したと報じている 。つまり、Airbnbの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の出力を信頼できるプロダクトに変える力へ移っている 。

People Mattersも、Chesky氏が「純粋なピープルマネジャー」や新しい技術への適応を拒む働き手は取り残されるリスクがあると警告したと報じている 。つまり、Airbnbの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の出力を信頼できるプロダクトに変える力へ移っている 。