―最先端AIモデル（Software 2.0）時代の出社文化を考える
ソフトウェア開発は、リモートワークと相性がよい仕事だと見られてきた。 コードを書き、GitHubで管理し、SlackやZoomで議論し、チケット管理ツールで進捗を追えば、必ずしも全員が毎日同じオフィスにいる必要はないようにも思える。
それなら、最先端のAIモデルを開発する企業ほど、オフィス需要は軽いのではないか。AIを作る企業なら、なおさらデジタルに完結した働き方をしているのではないか。 ところが、足元のニューヨークやサンフランシスコでは、OpenAI、Anthropic、Harvey、Hebbia、BlossomのようなAI関連企業が、むしろオフィス需要の新しい担い手として目立ち始めている。
これは、日本で不動産業界の人と話していても、意外に受け止められることがある。少なくとも、ソフトウェア開発会社であれば、リモートでも仕事ができるはずだという感覚は強い。 しかし、実際の記事を読むと、最先端AIモデルを開発する企業、あるいはAIを実務に組み込む企業が、ニューヨークやサンフランシスコでオフィスを確保し、拡張している。
今回の記事では、AI関連企業によるオフィス需要を手がかりに、「AI企業なのに、なぜオフィスが必要なのか」という違和感について考えてみたい。
記事の紹介――AI関連企業は、どれだけオフィスを借りているのか
2026年6月のWSJ記事“Manhattan’s Red-Hot Office Market Poised for Its Best Year Since 2000”は、マンハッタンのオフィス市場が2000年以来の強さに向かっていると報じた。
記事によれば、マンハッタンでは2026年第1四半期だけで、AI関連企業が約100万平方フィートのオフィスをリースしたという。これは、2025年通年のAI関連企業によるリース面積を上回る水準である。テックセクター内でも、AI関連企業の存在感は大きくなっている。WSJによれば、2026年第1四半期のマンハッタンにおけるテックセクターのオフィスリースのうち、AI関連企業が占める割合は56%に達した。これは2024年通年の2倍超にあたる。
具体的な企業名も挙げられている。 OpenAIは、ニューヨークのPuck Buildingに拠点を構え、SoHo周辺がAI関連企業の集積地になりつつあると紹介されている。AnthropicはHudson Squareで約50万平方フィートのリースに近づいているとされる。HarveyはOne Madison Avenueで18万5,000平方フィートへ拡張する予定と報じられている。
記事では、オフィスの面積だけでなく、AI関連企業の働き方についても描写されている。 Blossomでは、従業員が週5日オフィスに来て、朝から夜まで働いていると紹介されている。Hebbiaについても、週末にもオフィスに人がいるという描写がある。
WSJ記事は、Colliersのデータとして、2025年にAI関連企業がリースした面積は、マンハッタンのオフィスストック全体から見れば2%にとどまるとも紹介している。（筆者補足：ここでいう2%は、一定期間中に締結された新規リース契約に占める割合ではなく、マンハッタンの賃貸可能オフィスストック全体に対する割合）
一方で、この動きはニューヨークだけの話でもない。WSJ記事によれば、サンフランシスコでは2026年第1四半期のリース活動の58%をAI関連企業が占めた。Anthropicによる40万平方フィート超のリースも、市場の動きを押し上げたとされる。
別のWSJ記事“Why AI Startup Offices in NYC Are Flashy but Mostly Empty”は、ニューヨークのAIスタートアップが、現在の人員数よりも大きなオフィスを借りている事例も紹介している。
10xはSoHoで約3,000平方フィートのオフィスを借りたとされる。Blossomは約5,000平方フィートのスペースを借り、FazeshiftはPark Avenueのコワーキングスペースを利用している。Adonisは25人の時点で2万5,000平方フィートを契約し、その後社員数を85人に増やしたと紹介されている。記事では、現地従業員がまだ数人しかいない企業であっても、ニューヨークにオフィスを構えることが、クライアントに対する重要な信用力になるとの発言も紹介されている。Fazeshiftの事例では、顧客から、同社が対面で働いているのかをデューデリジェンスで確認されたという。
TIMEの記事“AI Is Pushing Some Workers Back to the Office—and Others Out of It”は、LinkedInがAIを組み込んだチーム専用空間、Pod Work Areasを試していると紹介している。これは、6〜10人のエンジニア、プロダクトマネージャー、デザイナーが専用空間を使い、AIエージェント、プロジェクト管理、GitHub、Claudeなどを組み合わせる取り組みである。 TIMEによれば、LinkedInの11週間のパイロットでは、生産サイクルが15〜20%速くなり、短い会話、他メンバーの作業状況の認識、ブレインストーミングも改善したとされる。
AIモデル開発企業にとって、オフィスは何のためにあるのか
今回参照する記事が直接示しているのは、AI関連企業によるオフィス需要の拡大である。そこには、OpenAIやAnthropicのような最先端AIモデル開発企業だけでなく、AIを法律、金融、医療などの実務に組み込む企業も含まれている。また、OpenAIやAnthropicがニューヨークで確保するオフィスが、どの部門によって、どのような開発工程に使われるのかも、参照記事だけでは明らかではない。 したがって、これらの記事だけから、最先端AIモデル開発の技術的な性質がオフィス需要を生み出している、あるいは「最先端AIモデル開発には出社が必要だ」と結論づけることはできない。 そのうえで本稿では、AI関連企業のオフィス需要という現象を手がかりに、最先端モデル開発の仕事の構造が、対面で働くことにどのような意味を与え得るのかを考えてみたい。
A 従来型ソフトウェア開発と、最先端AIモデル開発は何が違うのか
まず、従来型ソフトウェア開発と最先端AIモデル開発の違いを整理したい。
従来型ソフトウェア開発にも、複雑な分散システム、インフラ障害、セキュリティ対応など、複数の専門領域をまたぐ問題は存在する。
そのうえで比較すれば、多くのソフトウェア開発では、機能やサービスごとに責任範囲を定め、仕様、コード、テストを通じて作業を分担する設計が発達してきた。GitHub、チケット管理、コードレビュー、ドキュメント化された仕様は、こうした分業と非同期の連携を支えている。
一方で、最先端AIモデル開発は、少し性質が違う。人間がすべてのルールをコードとして明示的に書くのではなく、大量のデータと計算資源を使い、モデルに能力を獲得させる。そこでは、モデル設計、学習データ、評価方法、GPUクラスター、分散処理、安全性検証が同時に絡む。 性能が想定より伸びない場合、その原因がどこにあるのかは簡単には分からない。モデル構造の問題なのか、学習データの問題なのか、データの混ぜ方の問題なのか、学習率などの設定の問題なのか、評価方法の問題なのか、それとも計算基盤側の問題なのかを切り分けなければならない。
この違いを単純化すると、次のように整理できる。
| 観点 | 多くの従来型ソフトウェア開発 | 最先端AIモデル開発 |
| 作業の分解 | 機能・サービス単位で責任範囲を設計しやすい | モデル、データ、評価、計算基盤の結果が相互依存しやすい |
| 問題の原因 | コード、仕様、サービス境界に沿って調査できる場合が多い | 同じ性能変化について複数領域の仮説を並行して検証する必要が生じやすい |
| 重要な知識 | 仕様、コード、設計、運用履歴 | 仕様やコードに加え、実験履歴、評価の読み方、データ構成、学習上の失敗パターン |
| チーム連携 | 非同期分業が成立する領域が比較的広い | 研究・実験・評価・インフラ間で高頻度の調整が必要になる局面が多い |
この表はかなり単純化している。Software 1.0/Software 2.0の考え方や、GPUクラスター、分散学習、モデルの重みについては、知識ボックスで補足している。 ここで重要なのは、従来型ソフトウェア開発と最先端AIモデル開発では、仕事の重心が違うという点である。従来型ソフトウェア開発が、比較的「仕様を分解して担当者が実装する」仕事として進めやすかったのに対し、最先端AIモデル開発では、研究、実験、評価、インフラ、安全性を横断して、失敗原因を短いサイクルで切り分ける必要がある。
では、この違いは、AIモデル開発企業にとってのオフィスの意味をどう変えるのか。
B 最先端AIモデル開発企業にとって、オフィスは何のためにあるのか
最先端AIモデル開発企業が対面環境を重視するとすれば、オフィスには単なる勤務場所とは異なる意味が考えられる。 少なくとも、①研究・実験・評価に関する判断を速める場、②暗黙知を共有する場、③研究、評価、計算インフラを担当する人々の組織的な距離を短くする場としての意味である。 加えて、機密性の高い研究開発を一定の管理下で行う拠点として、一定の役割を持つ可能性もある。
第一に、最先端AIモデル開発では、一回の大規模学習に必要な費用と時間が大きいため、学習結果を評価し、次の実験条件を決めるまでの判断速度が競争力になりやすい。
モデルを一度作って終わるのではなく、学習結果を見て、データの選び方、学習設定、評価方法、安全性検証を修正し、次の実験へ進む必要があるからである。 ここで重要なのは、判断が一人の担当者だけで完結しにくいことである。性能が想定より伸びない場合、原因はモデル構造にあるのか、データにあるのか、学習設定にあるのか、評価方法にあるのか、それともGPUクラスターや分散処理の側にあるのかを切り分けなければならない。 そのため、研究者、データ担当、評価担当、分散処理エンジニア、インフラ担当が、同じ実験結果や異常を共有し、短いサイクルで次に何を試すかを決める必要がある。 こうした連携は、技術的にはリモート環境でも可能である。ただし、原因が特定されておらず、複数領域の判断を同時並行で必要とする局面では、対面環境によって、確認、相談、意思決定までの時間を短くしようとする組織設計には合理性がある。 この点については、知識ボックス②で、OpenAIのGPT-4 Technical Reportに触れながら補足している。
第二に、明文化しにくい実験上の判断が多い。
最先端AIモデル開発では、すべての判断がマニュアル化されているわけではない。どのデータをどう混ぜるとモデルの挙動が変わるのか。評価結果のどこを疑うべきか。学習が不安定になったとき、最初に何を見るべきか。安全性上の違和感をどう扱うべきか。 こうした知識は、ドキュメントとして整理できる部分もあるが、実験を重ねる中でチームに蓄積される経験知の部分も大きい。失敗した実験のログを一緒に見る。シニア研究者の判断を横で聞く。短い会話の中で、別チームの失敗例や成功例が伝わる。 暗黙知については定量的に証明しにくいが、だからといって軽い論点ではない。むしろ、不確実性が高く、失敗原因の切り分けが難しい領域ほど、横で見ること、短く話すこと、その場で違和感を共有することの価値が残りやすい。 この点については、知識ボックス⑤で、Metaの初期分析や実務経験との近さも含めて補足している。
第三に、計算インフラを運用するチームとの連携と、機密性の高い開発環境の確保が重要になる。
大規模AIモデル開発では、GPUクラスター、分散学習、学習データ、評価環境、モデルの重み、安全性評価が中核資産になる。これらの多くはクラウドやデータセンター上に存在し、監視や操作もリモートで行われる。 ただし、リモート操作が可能であることと、自宅を含むあらゆる場所からアクセスできることは同じではない。機密性の高いモデル、データ、評価環境を扱う一部の業務では、アクセス元の端末やネットワークを厳格に管理する必要がある。こうした管理の方法として、企業が一部の業務を限られた物理環境で行わせることは考えられる。ただし、参照資料から、現在のAI企業のオフィス需要がこうした運用によって生じているとまでは確認できない。 学習が不安定になったとき、それがモデル設計やデータ、学習設定の問題なのか、分散処理の設定やGPUノード、ネットワーク、メモリ、ストレージといった計算基盤側の問題なのかを切り分ける必要がある。つまり、最先端AIモデル開発では、問題がソフトウェアの中だけで完結せず、ハードウェアを含む計算インフラの運用・改善と結びつきやすい。
もちろん、GPUクラスター自体が都心のオフィスに置かれているという意味ではない。計算基盤はデータセンターやクラウド環境にあり、監視や操作もリモートで行われる。ここで問題となるのは、研究者とGPUの物理的な距離ではなく、研究、評価、インフラ、安全性を担当する人々が、異常を共有し、原因を切り分け、次の判断を下すまでの組織的な距離である。 この点については、知識ボックス③と④で、GPUクラスター、分散学習、モデルの重み、セキュリティの観点から補足している。
以上から、最先端AIモデル開発企業が対面環境を重視するとすれば、その理由は単なる勤務管理よりも、研究、実験、評価、計算基盤の間で判断を往復させる速度にあると考えられる。オフィスは、その組織的距離を短くする一つの開発基盤になり得る。
C AI活用企業には、別のオフィス需要がある
ここまで見てきたのは、主にOpenAIやAnthropicのような最先端AIモデル開発企業のロジックである。もっとも、参照記事に登場する企業のすべてが、モデルそのものを一から開発する企業というわけではない。Harvey、Hebbia、Blossom、Fazeshiftのような企業は、AIを法律、金融、医療、請求管理などの実務に組み込むAI活用企業に近い。LinkedInのPod Work Areasも、最先端モデルの学習ではなく、AIを使ったプロダクト開発やチーム作業の設計に近い例である。
この場合、オフィス需要を考える際の論点は少し違う。中心にあるのは、GPUクラスターやモデルの重みではなく、まだ利用方法が確立していないAIを顧客業務へ組み込み、顧客理解、UX、実装、営業、プロダクト改善の間で仮説を高速に修正することである。
AIを顧客業務にどう組み込むか。どの画面なら実際に使われるのか。AIの回答をどこまで信用させるか。どの業務フローに入れると価値が出るか。こうした問いは、エンジニアだけで完結しない。プロダクトマネージャー、デザイナー、営業、カスタマーサクセス、顧客接点を持つメンバーが、短い会話を重ねながら仮説を修正していく必要がある。 つまり、AI活用企業にとってのオフィスは、顧客業務への実装、UX、営業、プロダクト改善を短いサイクルで結ぶ場として機能する可能性がある。
ここで重要なのは、AI関連企業のオフィス需要を一括りにしないことである。 モデル開発企業では、研究・実験・評価・計算インフラを結びつける場として、オフィスが意味を持ち得る。また、機密性の高いモデル、データ、評価環境を扱う一部の業務では、自宅からのリモートアクセスではなく、管理された物理環境で作業することが求められる可能性もある。 一方、AI活用企業では、顧客理解、UX、実装、営業、プロダクト改善を短いサイクルで結ぶ場として、オフィスが意味を持ち得る。
AI活用企業にとっては、オフィスが顧客に対する信用のシグナルになる場合もある。Fazeshiftの事例では、顧客がデューデリジェンスの中で、同社が対面で働いているかを確認していた。特に顧客の重要業務や機密情報を扱う若い企業では、オフィスが会社の実在性や統制を示す意味を持つ可能性がある。 モデル開発とAI活用では、開発構造が異なる。したがって、AI関連企業のオフィス需要も、この二つを分けて考えた方が分かりやすい。詳しくは、知識ボックス⑥で整理している。
若手金融マンへの示唆 ―「AIモデル開発だからオフィスが意味を持つ」
本稿の出発点は、「ソフトウェア開発はリモートワークと相性がよいはずなのに、なぜ最先端AIモデル開発企業はオフィスを重視しているように見えるのか」という違和感だった。
従来型ソフトウェア開発では、機能やサービスごとに責任範囲を定め、仕様、コード、テストを通じて作業を分担する設計が発達してきた。複雑な開発や高度なインフラ運用は存在するものの、非同期コミュニケーションやリモートワークが成立する領域は比較的広かった。 一方、最先端AIモデル開発では、モデル、データ、評価、計算インフラが相互に関係する。性能が伸びない原因について、モデル設計、学習データ、学習設定、評価方法、計算基盤など、複数領域の仮説を短いサイクルで検証しなければならない。
つまり、最先端AIモデル開発では、オフィスが単なる「出社場所」とは異なる意味を持つ可能性がある。研究、実験、評価、計算インフラを担当する人々の組織的な距離を短くし、次の判断までの時間を縮める開発基盤になり得るからである。もちろん、ここまでの分析は、OpenAIやAnthropicによる個別のオフィス拡張の原因を直接証明するものではない。オフィス需要の背景には、将来の人員拡大への備え、採用競争、企業文化、顧客に対する信用力など、複数の理由がある。
それでも、「研究、実験、評価、計算インフラをまたぐ判断を短いサイクルで繰り返す、最先端AIモデル開発の構造は、これらの企業が対面環境を重視しているように見えることと整合的」である。
若手金融マンにとっての示唆は、ここにあると思う。 新しいテーマを見るとき、最初に使われるラベルはどうしても粗くなる。「AI企業」「テック企業」「ソフトウェア企業」といった言葉は便利だが、そのラベルだけでは、企業の実態を見誤ることがある。 今回も、「AI企業ならリモートでよいはずだ」というラベルだけで見ると、オフィス需要は奇妙に映る。しかし、最先端AIモデル開発の仕事の構造を知ると、同じ現象の見え方は変わる 記事を読むときに大事なのは、違和感をすぐに消さないことだと思う。
知識ボックス
① Software 2.0とは何か：人間がコードを書く世界から、モデルに能力を獲得させる世界へ
従来型のソフトウェア開発では、人間が仕様を決め、人間がコードを書く。
たとえば、画面表示、データ処理、認証、決済、検索、通知などの機能を分解し、それぞれの担当者がコードを書き、テストし、統合する。もちろん大規模なSaaS開発にも複雑な設計や高度なインフラ運用はあるが、基本的には「人間がルールを記述する」世界である。
これに対し、最先端AIモデル開発では、人間がすべてのルールを明示的に書くわけではない。大量のデータと計算資源を使い、モデルに能力を獲得させる。 AI研究者のAndrej Karpathy氏は、この違いをSoftware 1.0とSoftware 2.0の違いとして説明している。 Software 1.0では、プログラムは人間が書いたコードである。
Software 2.0では、プログラムに相当するものは、学習によって得られたニューラルネットワークの重みである。 つまり、最先端AIモデル開発では、人間が一つひとつの動作をコードとして記述するだけでなく、データを選び、学習方法を設計し、結果を評価しながら、モデルの挙動を改善していくことが仕事の中心になる。この違いは、働き方を考えるうえでも重要である。
従来型ソフトウェア開発が、比較的「仕様を分解して、担当者が実装する」仕事として進みやすかったのに対し、最先端AIモデル開発では、モデル、データ、評価、計算資源、安全性が同時に絡む。 その具体的な違いは、次の②と③で見ていく。
もっとも、現実のAI製品がSoftware 2.0だけで構成されているわけではない。学習基盤、データ処理、評価システム、API、プロダクト画面などには、従来型のソフトウェア開発も大量に必要となる。Software 1.0／2.0は両者を完全に分ける分類ではなく、仕事の重心の違いを理解するための考え方である。
② なぜ最先端AIモデル開発は、研究・実験・評価の高速反復になるのか
最先端AIモデル開発は、単に大きなプログラムを書く仕事ではない。
むしろ、研究、実験、評価、修正を何度も繰り返す仕事に近い。
大規模モデルでは、本番サイズの学習を何度も簡単にやり直すことはできない。学習には莫大な計算資源、時間、電力、エンジニアリング能力が必要になる。そのため、開発チームは小さいモデルや過去の実験結果から、より大きなモデルの挙動を予測し、どのデータを使うか、どの学習設定にするか、どの評価指標を見るかを決めていく。
OpenAIのGPT-4 Technical Reportでも、GPT-4の開発では、スケールをまたいで予測可能に振る舞うインフラと最適化手法を整えることが重要だったと説明されている。これは、最先端AIモデル開発が「とりあえず巨大なモデルを一度作れば終わり」という仕事ではなく、実験、予測、評価、改善を積み重ねる仕事であることを示している。
このため、問題が起きたときの切り分けも複雑になる。
モデルの性能が想定より伸びない場合、その原因はモデル構造にあるのか、学習データにあるのか、データの混ぜ方にあるのか、学習率などの設定にあるのか、評価方法にあるのか、それとも計算基盤側にあるのかを見極めなければならない。 この切り分けは、単独のエンジニアが自分の担当コードだけを見れば済む話ではない。研究者、データ担当、評価担当、分散処理エンジニア、インフラ担当、安全性担当が、短いサイクルで状況を共有し、次の実験に反映する必要がある。 その意味で、最先端AIモデル開発は、研究室、実験室、インフラ運用、プロダクト開発が重なった仕事である。
③ GPUクラスターと分散学習：モデル開発はコードだけでは終わらない
最先端AIモデル開発では、GPUクラスターが競争力の中核になる。
大規模モデルを学習させるには、多数のGPUを高速メモリや高速ネットワークでつなぎ、巨大な計算基盤として動かす必要がある。NVIDIAのGPU、HBMと呼ばれる高速メモリ、InfiniBandなどの高速ネットワークは、AIインフラを語るうえで頻繁に登場する言葉である。
ここで重要なのは、AIモデル開発では、問題の原因がコードだけにあるとは限らないという点である。
学習が不安定になる、想定より性能が伸びない、処理が遅くなる、途中でエラーが出る。こうした問題は、モデル設計、データ、学習設定、分散処理、GPU、ネットワーク、メモリ、ストレージのどこに原因があるのかを切り分ける必要がある。
従来型ソフトウェア開発でも、インフラ障害や分散システムの問題は当然存在する。
しかし、最先端AIモデル開発では、モデルの挙動と計算基盤の挙動がより密接に絡む。学習ジョブが大きくなればなるほど、一部の障害や不安定性が全体の進行に影響しやすくなる。
そのため、ここで必要になるのは、単なる「コードレビュー」だけではない。
大規模学習でトラブルが起きたとき、それは単純なコードのバグとは限らない。データの前処理、学習率、分散処理の設定、GPUノード、ネットワーク、メモリ、ストレージ、チェックポイント処理など、複数の要因が絡む可能性がある。
重要な学習ジョブの局面では、研究者、分散処理エンジニア、インフラ担当が同じログやダッシュボードを見ながら、原因を短時間で切り分ける必要がある。これは、通常のSaaS開発における「担当者が自分のコードを直す」作業とはかなり性質が違う。
もちろん、これが「全員が常に同じ部屋にいなければならない」という意味ではない。ただし、大規模な学習や重要な実験の局面では、オフィスや専用のウォールームのような場が、問題の切り分けと意思決定を速くする可能性はある。
④ モデルの重みとセキュリティ：AI企業の中核資産はどこにあるのか
AIモデル開発企業にとって、モデルの重み（model weights）は極めて重要な資産である。 モデルの重みとは、学習によって得られたニューラルネットワークのパラメータであり、モデルの能力を実質的に支える中核部分である。従来型ソフトウェア企業においても、ソースコードや顧客データは重要である。しかし、フロンティアAI企業では、モデルの重み、学習データ、評価環境、チューニング方法、安全性評価の結果が、競争力そのものに近い。
RAND Corporationは、米国の政策・安全保障分野で影響力を持つ非営利のシンクタンクである。同機関は2024年の報告書で、フロンティアAIモデルの重みを守るためのセキュリティ対策を論じている。RANDは、モデルの重みを、巨額のデータ・計算資源・開発投資の成果を内包する重要資産として位置づけ、その窃取や流出を安全保障上のリスクとして論じている。
OpenAIも、強力なモデルを外部に提供する際、モデルの重みを配布するのではなく、API経由でアクセスさせることを安全上の選択肢として説明している。Anthropicも、モデル能力が一定の閾値を超える場合には、より厳しい安全・セキュリティ上の基準を適用する枠組みを示している。
この点は、AIモデル開発企業のオフィス需要を考えるうえでも重要である。
出社の理由を、単に「社員を管理したいから」と見ると、見落とすものがある。AIモデル開発企業では、機密性の高いモデル、データ、評価環境、顧客情報をどう扱うかが、企業価値と安全性に直結する。
もちろん、セキュリティは物理的なオフィスだけで完結するものではない。
アクセス権限、ネットワーク分離、監査ログ、内部統制、クラウド環境、端末管理など、論理的・技術的な管理が中心になる。しかし、重要な研究・評価・安全性判断をどこで、誰が、どの環境で行うかは、組織設計上の大きな論点になる。
モデルの重みや学習環境を守る中心的な手段は、アクセス権限、ネットワーク分離、監査ログ、端末管理などの技術的・組織的統制であり、物理的なオフィスだけではない。
そのうえで、重要な研究・評価・安全性判断を、誰が、どの端末とネットワークから行うかを管理する一環として、企業が一部の業務を管理された物理環境で行わせる可能性はある。オフィスは、こうしたセキュリティ管理の一要素になり得る。
⑤ 暗黙知と若手エンジニア：なぜ横で見ることに価値が残るのか
暗黙知は、証明が難しい論点である。
数値で完全に測ることは難しく、企業ごとの文化やチーム構成にも左右される。したがって、「対面でなければ暗黙知は共有できない」と断定するのは強すぎる。 しかし、実務経験の長い人ほど、この論点にうなずくことは少なくない。
その理由は、仕事の中には、ドキュメントやマニュアルだけでは移りにくい知識があるからである。
最先端AIモデル開発でも同じことが起きる。
どのデータをどの比率で混ぜるとモデルの挙動が変わるのか。評価結果のどこを疑うべきか。学習が不安定になったとき、まず何を見るべきか。安全性上の違和感をどう扱うか。顧客が求める性能と、ベンチマーク上の性能のズレをどう読むか。こうした判断は、完全に明文化された手順だけでは進みにくい。
MetaのMark Zuckerberg氏は、2023年に公表した「Year of Efficiency」の更新文で、同社の初期分析として、対面で入社したエンジニアは、その後リモート勤務へ移った場合も対面勤務を続けた場合も、リモートで入社したエンジニアより平均的にパフォーマンスが高かったと述べている。また、キャリア初期のエンジニアは、週3日以上チームメイトと対面で働く場合の方が、平均的にパフォーマンスが高いという分析も紹介している。ただし、これはMeta自身も初期分析として位置づけており、確定的な一般法則として読むべきではない。
それでも、この話はAIモデル開発企業の出社文化を考える手がかりになる。
若手がシニアの議論を横で聞く。失敗した実験のログを一緒に見る。評価結果に対する違和感をその場で共有する。短い雑談から、別チームの失敗例や成功例が伝わる。こうした知識の移転は、Slackやドキュメントだけでは再現しにくい場合がある。
この点は、投資銀行やPE、法務、会計、商社の実務にも近い。
若手はマニュアルだけで育つわけではない。上席の判断、資料の直し方、顧客との会話、違和感の拾い方を横で見ながら覚える部分がある。AIモデル開発でも、対象は技術であっても、組織内で暗黙知が移る構造は残っている。
ここでのポイントは、「リモートワークは機能しない」という話ではない。
そうではなく、最先端AIモデル開発のように不確実性が高く、失敗原因の切り分けが難しく、経験知が価値を持つ領域では、横で見ること、短く話すこと、その場で違和感を共有することの価値が残りやすいということである。
⑥ AI活用企業のオフィス需要：モデル開発企業とは違うもう一つの出社ロジック
この記事では、AIモデル開発企業を中心に扱っている。
しかし、参照記事に登場する企業のすべてが、OpenAIやAnthropicのようなフロンティアAIモデル開発企業というわけではない。
たとえば、Harvey、Hebbia、Blossom、Fazeshiftのような企業は、AIを法律、金融、医療、請求管理などの実務に組み込むAIアプリケーション企業に近い。LinkedInのPod Work Areasも、最先端モデルそのものを学習するための場所というより、AIを使ったプロダクト開発やチーム作業をどう設計するかという例である。
この違いは重要である。
OpenAIやAnthropicのようなモデル開発企業について対面環境の意味を考える場合、モデル、データ、GPUクラスター、評価、安全性、セキュリティの相互関係が論点になる。つまり、研究とインフラと安全性をどのように連携させるかという問題である。
一方、AI活用企業についてオフィスの意味を考える場合、中心となる論点は少し異なる。
中心にあるのは、UX、顧客理解、プロダクト化、実験サイクルである。AIを業務にどう組み込むか、顧客が本当に使う画面は何か、AIの回答をどこまで信用させるか、どの業務フローに入れると価値が出るかは、まだ不確実性が高い。エンジニア、プロダクトマネージャー、デザイナー、営業、顧客接点を持つメンバーが短い会話を重ねながら、仮説を修正していく必要がある。
TIMEが紹介したLinkedInのPod Work Areasは、この後者の例として読むと分かりやすい。
6〜10人のエンジニア、プロダクトマネージャー、デザイナーが専用空間を使い、AIエージェント、プロジェクト管理、GitHub、Claudeなどを組み合わせる。これは、GPUクラスターを監視するための部屋というより、AI時代のプロダクト開発を高速化するためのチーム空間である。
参照記事
2026年6月9日 The Wall Street Journal
“Manhattan’s Red-Hot Office Market Poised for Its Best Year Since 2000”
2026年4月28日 The Wall Street Journal
“Why AI Startup Offices in NYC Are Flashy but Mostly Empty”
2026年6月2日 TIME
“AI Is Pushing Some Workers Back to the Office—and Others Out of It”
知識ボックスの主な参照資料
Andrej Karpathy, “Software 2.0” OpenAI, “GPT-4 Technical Report” RAND Corporation, “Securing AI Model Weights: Preventing Theft and Misuse of Frontier Models” OpenAI, “OpenAI’s Approach to Frontier Risk” OpenAI, “OpenAI’s Comment to the NTIA on Open Model Weights” Anthropic, “Responsible Scaling Policy” Meta, “Update on Meta’s Year of Efficiency”
※本稿は、米国の金融コラム・業界記事を素材に、背景となる考え方や論点を整理することを目的とした考察です。本文中で紹介している参照記事には、有料媒体のものも含まれています。 本稿は生成AIを活用して下書き・構成整理を行い、筆者が検証・加筆修正の上で公開しています。
