Pandas創始者が語るAI・Apache Arrow・ソフトウェアエンジニアリングの未来 [YouTube]

• PandasとApache Arrowを作った経験を踏まえ、AI時代においても高性能なデータシステムとソフトウェアを設計する専門性・判断力・センスが中核だと見ている
• Apache Arrowは表形式データのための汎用インメモリ基盤レイヤーとして、システム間の転送と処理を標準化し、採用するシステムが増えるほど相互運用性の価値も大きくなる
• DuckDB・DataFusionのような洗練されたシステムは、LLMの平均的なコード生成だけで置き換えるのが難しく、オープンソースの競争力にはコードだけでなく長期にわたり蓄積された信頼と品質の実績も含まれる
• AIツールは主体性の高い開発者の生産性を大きく高めるが、何を作るかが明確でないと平均的な解法とコードが積み重なり、エージェントでも抜け出しにくい**エージェントの泥沼(agentic tarpit)**が生じうる
• 今後は言語文法や手書きコーディングよりも、アーキテクチャ、問題定義、コミュニケーション、結果を見極める力が重要になり、組織は増えた意思決定の負荷とトークンコストまで管理しなければならない

---

PandasからAI開発ツールへと続くキャリア

• Wes McKinneyは約18年前にPython Pandasを作り、2010年にオープンソースプロジェクトとして公開した
• 著書Python for Data AnalysisはPythonデータサイエンスのエコシステムで広く使われ、その後はオープンソース開発を継続できる会社と事業モデルを作る仕事にも関わった
• Clouderaで複数のオープンソース開発者とともにApache Arrowを立ち上げ、ArrowエコシステムとParquetの開発にも関与した
• Ursa Computingはその後Voltron Dataとなり、Voltron Dataの整理後もPositとの関係を維持している
• 現在はデータサイエンスライブラリよりAI開発者ツールとインフラに注力する新会社を設立し、AIでソフトウェアエンジニアリングの生産性を高める方法を模索している

Apache Arrowが普及するまで

• Arrowは表形式データのための汎用インメモリデータ基盤レイヤーであり、メモリ内処理とシステム間データ転送を高速化し、相互運用性を高める
• 初期はユーザーも利用側システムも少なく、採用のインセンティブが低かったうえ、複数のオープンソースコミュニティが単一フォーマットに合意するのは難しいという懐疑論もあった
  • 新しい統合標準を作ると既存13個の標準が14個になる、というXKCD的な問題が起こりやすい
  • Arrowは同じ問題を解く信頼できる代替がほとんどない状況で安定した実装を提供し、採用を待つ形で成長した
• 技術そのものはここ5〜6年で大きく変わっていないが、より多くのシステムが採用するにつれてネットワーク効果に近い価値の増大が生まれた
• DataFusionはクエリエンジンをゼロから作らずに製品向けへ拡張できるため、約30〜40社が内部コンポーネントとして活用しているとみられる
  • ストリーミングデータエンジンを作っていたArroyoはCloudflareに買収され、その後ArrowとDataFusionがCloudflareのストリーミングデータ基盤の一部で使われている
  • DataFusion CometはSpark高速化に活用されている

AIが容易には代替できないシステムソフトウェア

• DataFusionとDuckDBはバイブコーディングで代替品を素早く作るのが難しい種類のプロジェクトである
• LLMは既存コードや手法を平均化する性質が強く、最先端のクエリエンジンのように専門家が緻密に組み上げたシステムを近い将来に作り出すのは難しい
• こうしたプロジェクトは射出成形のプラスチック玩具というより、職人が組み立てた精密なスイス時計に近い
  • これはAIが永遠に作れないという意味ではないが、現時点では代替可能性が低い
• オープンソースプロジェクトの価値は実装物だけでなく、コミュニティが長年蓄積してきた信頼からも生まれる
  • メンテナーが共同体の利益を考えるという信頼
  • サプライチェーン攻撃を防ぎ、重大なバグを修正してくれるという期待
  • 一貫してよく設計され、信頼できるソフトウェアを提供してきた実績
• McKinneyは2013年以降Pandas開発に深く関与しておらず、現在は大規模な開発者グループがプロジェクトを維持している
  • そのため、実際のメンテナーに感謝と支援が向かうべきだと考えている
• AIで1日に1万行のコードを生成できても、過去に積み上げた品質基準に達しない成果物を公開することはできないため、生成量よりもレビューと品質維持が重要な課題になる

ゲームと数学からプログラミングへ

• 1990年代後半、Nintendo 64のGoldenEye 007に夢中になり、1997年末または1998年初頭にGeoCitiesでファンサイトを作ってスピードランコミュニティに参加した
• 当時はウェブサイトを手作業で管理していたが、競技プログラミングに長けたKismanがC++プログラムでサイト更新を自動化する様子を見て、優れたプログラマーが生み出す自動化の効果に触れた
• 高校では数学コンテストとコンピュータ活用に関心を持ち、MITでは幼少期からプログラミングしてきた同級生たちとの大きな実力差を感じた
• 純粋数学の学位を取りながら計算量やアルゴリズムなど理論計算機科学も一部学んだが、Javaに対する否定的な経験からプログラミング自体には強い興味を持てなかった
• プログラミングを問題解決と個人の生産性を増幅する道具だと認識してから、本格的に没頭し始めた

金融リサーチから始まったPandas

• 2007年、22歳でクオンツ系ヘッジファンドに入社し、予想していた数式中心の研究とは異なり、多くの分析がExcelスプレッドシートと手作業に依存していることを知った
• MATLABやRも使われていたが補助的手段に近く、MATLABコードをサーバーへデプロイするにはサーバーごとに高価なライセンスが必要だった
• リサーチから本番運用までつながる作業には、システム構築に適したオープンソース言語が必要だと判断した
• 同僚の勧めで2008年初頭にPythonと科学計算ライブラリを使い始め、既存の研究ツールをPythonで作り直す中で初期のPandasの形が現れた
• 生産性を高める道具を作り、他人がその道具でもっと効率よく働くのを見る過程に、ゲームのスピードランに似た没入感を覚えた

シンプルなユーザー体験と内部技術負債

• McKinneyは個人専用の複雑なAIツールより、他人にも理解され使えるシンプルで一貫したツールを重視する
• 過度に個人化されたツール群は構造が複雑になり、作成者以外には探索不能なWinchester Mystery Houseのような状態になりうる
• Pandas初期実装は内部アーキテクチャより、人が理解しやすく書きやすいAPIと使い勝手に重点を置いた
• 内部構造の混乱は長く保守負担を残したが、Pandasの成功はソフトウェアが完璧なアーキテクチャを持たなくても大きく成功しうることを示している

NumPyの役割と限界

• NumPyは、Jim Huguninが1990年代半ばに始めた多次元配列ライブラリNumericと、メモリマッピングなど大規模配列機能を追加したNumarray系をTravis Oliphantが2005〜2006年ごろ統合して生まれた
• 当時はMatplotlib・SciPy・統計および線形回帰ツールがNumPy配列を中心に動いていたため、新しいデータツールがエコシステムに参加するにはNumPy互換性が必須だった
• NumPyは数値と整数の大規模多次元配列に焦点を当てており、データベースや非数値データ向けの基盤として設計されたものではない
• 初期のPandasはNumPyを土台にしつつ、非数値データの制約を回避した
  • 数値やブール値でない値はNumPy配列内のPythonオブジェクトとして保存された
  • 文字列データではオブジェクトのオーバーヘッドや間接参照が発生し、効率が低かった
• こうした限界が、後にPandasのようなシステム向けの代替インメモリ基盤であるArrowを作る動機になった

Pythonデータサイエンス・エコシステムの成長

• ベンチャー投資を受けた複数の企業が、各社はGoogleのようなデータインフラを構築すべきだと売り込んだことで、ビッグデータ系オープンソースプロジェクトに莫大な投資が流れ込んだ
• すべての企業に同規模のインフラが必要だったわけではないが、この資金がなければArrowに必要な開発者を集めるのははるかに難しかった可能性がある
• 当時の業界では、データサイエンスやデータサイエンティストの意味、そしてビジネス・統計・ソフトウェア能力を兼ね備えた人材をどこで見つけるかを巡って競争していた
• Pythonは、プログラミング経験が多くなくても統計を理解している人がデータサイエンスに入れるようにした
  • Python for Data Analysisやscikit-learnのようなツールを学べば、2〜3週間以内に業務に役立つ分析を始められた
  • 先にScalaのような言語を学ぶ必要があれば、参入障壁は高く、学習期間ももっと長くなったと見ている

Pandas公開とArrow組織の形成

• Pandasは2009年の大晦日に公開することが決まり、2010年2月の最初のPyCon発表をきっかけにPythonコミュニティと本格的につながった
• McKinneyは2010年にDukeで統計学博士課程を始めたが、金融企業のPythonデータツールへの関心とPandasの成長可能性を見て休学した
• 当時のPandas 0.1は結合の種類すらすべては対応していないほど機能が限られており、プロジェクトの成長に集中するため大学院を離れた
• 金融向け技術事業を検討した後、Python for Data Analysisの執筆とBIスタートアップ創業へ進み、2013年にはBI市場でLookerと競うのは難しいと判断してClouderaに加わった
• ClouderaではImpala開発者たちとつながり、その後Iceberg・Databricksなどで活動した多くのエンジニアとも出会い、この経験が後のキャリアの土台になった
• Arrowプロジェクトは2016年初頭にClouderaで始まったが、当時のエンタープライズソフトウェア市場では実験的技術のための専任チーム予算を確保するのが難しかった
• 2016〜2018年には金融企業でArrowを実システムに適用してデータ処理ワークロードを高速化し、Parquetも改善した
• 2018年には複数企業がArrow開発への資金提供を望んだが、金融企業の規定上、外部資金を管理しにくかったため、企業スポンサーを受けられる独立組織を4月に設立した
  • Nvidiaを含むハードウェア企業や金融企業など約6社のスポンサーが参加した
  • 約8人規模の開発チームを組成した
• 商機を確認したのち、2020年のコロナ禍にUrsa Computingへ転換した

今も残るデータエンジニアリングの課題

• 今日でもデータ分野は、データをAからBへ移し、形式を変換し、メモリにロードし、クエリと変換を効率よく実行する問題を繰り返し解いている
• Pandasは予想をはるかに超える数の企業データフローを支える基盤となっており、現在では人間が過去に書いた量より多くのPandasコードをLLMが生成している可能性もある
• DuckDBは20年前の開発者には想像しにくかったほど強力なツールである
  • 無料でインストールでき、さまざまな環境で実行できる
  • 電話とウェブブラウザでも動作できる
  • 単一マシンで複雑なセットアップなしに高性能分析を提供する
• 長年の不便と試行錯誤を経て、DuckDBやArrowのような技術の必要性が明確になり、Parquetをはじめとする多くの解決策は、Googleのような大規模インターネット企業がコストと時間を削減するために作った技術の影響を受けている
• Parquetは最良のフォーマットではないが以前より大幅に改善され、ほぼすべてのシステムが対応している
  • VortexやLanceのような特化型代替があっても、十分に良い互換性のおかげで使われ続けている
• AIが業界の注目を集める一方で、データエンジニアリングの話題性は下がり、Databricksが新しいデータエンジンを発表しても以前ほど関心を集めにくくなっている
• 逆にデータツール開発者にとっては流行を追わず技術の完成度に集中する余地が生まれ、テスト作成のような反復的で面倒な作業にはAIを活用できる

データベース技術への収束

• ビッグデータ時代の最大の教訓は、データベース研究者の論文や学会成果をもっと早く活用すべきだったという点である
• TU Munich・CWI・MIT・CMU・Berkeleyなどのデータベース研究を読み、実装し、協力するアプローチが重要である
• NoSQLと非リレーショナルストレージ中心の時代には、スケーラブルなシステムが大きなオーバーヘッドを追加し、よくできた単一マシン・単一スレッド実装より遅くなる場合もあった
• Frank McSherryとMichael Isardらが関わったScalability! But at what COST?研究は、拡張性を得るために支払うコストの問題を扱っている
• 現代のデータスタックは再びデータベース技術とカラムナー処理を中心に収束している
  • Polars・Daft・DataFusionはArrowを使う
  • dbtの新エンジンはADBCを活用する
  • Databricks PhotonはArrow利用の有無とは別にカラムナー構造を採用している
• 主要システムが似たアーキテクチャと手法に収束するにつれ、今や中核処理方式そのものより、ソフトウェアを実際にどれだけ使いやすくできるかが重要な課題になっている

HadoopからDuckDBへ続く使いやすさの改善

• Hadoop時代にはJavaとXML設定ファイル、無数の調整項目のため、実作業を始める前に2日ほど設定に費やすこともあった
• Sparkは単語数カウントを1行で書ける点で大きな改善だったが、それでもインフラと設定ファイルの準備は必要だった
• DuckDBのインストールと実行の形は、データシステムがどこまでシンプルになれるかを示すユーザビリティモデルである
• 分散システムも妥当なデフォルト値と即座に動く設定を提供し、運用の複雑さを減らせるべきである
• DuckDBはクライアント・サーバー領域にも拡張しており、MotherDuckと緊密に協力している

生成AIのためのマルチモーダルデータレイヤー

• 従来のレイクハウスは表形式とParquet中心だが、生成AIや大規模モデルの学習・微調整には画像・映像・テキスト・文書・ログがまとめて必要になる
• LanceDBが扱うマルチモーダルデータレイクハウスは、現実のエンタープライズ課題に当たる
• 大規模な非構造化データから埋め込みを生成すると電力とGPU時間を消費するため、その生成済み埋め込み自体にも計算コストに基づく経済的価値が生じる
• 本番環境では元データと生成結果を安定して保存・管理・処理できるデータストアが必要である
• すべての企業が独自のマルチモーダルストレージを作れば、バグ、データ損失、性能問題を繰り返し経験しかねないため、専門ソフトウェアベンダーが共通解を提供するほうが効率的である
• Icebergテーブルを自前運用できたとしても、Databricks・Snowflake・AWSのような事業者に管理を任せれば運用複雑性を減らせるように、生成AI向けマルチモーダルデータにも同じ理屈が当てはまる
• 生成AIデータ市場には、文書ベクトル検索と高QPS処理からデータライフサイクル管理まで、異なる層を解く余地がまだ残っている

AI時代の開発者の競争力

• McKinneyはかつて自分にもソフトウェアエンジニアとして未来があるのか悩んだが、AIは人を主体性のレベルによってより明確に分けると見ている
• 主体性の高い人は、何を作るかを熟考し、良い結果を見極めるセンスと判断力を土台に、AIから大きな生産性増幅を得られる
• LLMは大半の問題に対し平均的で無難なB+レベルのアプローチを提供するが、ユーザーの代わりに経験・センス・判断力を作ってはくれない
• 良い判断なしに生成コードを追加し続けると複雑な泥沼が形成され、エージェントも文脈と構造の重さに押されて作業を続けにくくなる
• かつては自分で実装しながら技術と判断力を同時に育てたが、今後は手書きコーディング時間が減るぶん、システム理解と設計能力を別途育てる必要がある

AI時代に学ぶべきこと

• 新しい開発者はPython・Javaの文法だけを覚えるのではなく、ソフトウェア設計とアーキテクチャ、データシステムの構造を学ぶ必要がある
• データエンジニアリングではLambdaアーキテクチャやKappaアーキテクチャのように、異なるシステムがどう動き、どんな問題に適しているかを理解しなければならない
• エージェントに望む結果を正確に伝え、誤った方向へ進んだときにそれを見抜ける必要がある
• 利用者がAとBのどちらが良いか判断できなければ、エージェントも正しい選択を代わりに保証できない
• ソフトウェアエンジニア・データエンジニア・データサイエンティストのいずれも、コード記述より問題定義とコミュニケーションに多くの時間を使うようになる可能性が高い
• 欲しいものを説明できなければAIでも望む結果は得られず、単に組織へAIを追加しただけで生産性や経済的成果が自動的に高まるわけではない
• 経験と判断力が不足した人にAIを与えると、有用な成果物よりも他人が後始末すべき負債を大量に生み出す**スロップキャノン(slop cannon)**になりうる

増えた意思決定と組織のAI投資

• 今後2〜5年の間、開発者採用や技術面接、役割分担は混乱しながら急速に変わる可能性がある
• 以前は会議・スプリント計画・プランニングポーカーを通じて、チームが作業への共通認識を作ったうえで実装を分担していた
• いまや従来のアジャイル計画プロセスはClaudeの計画モードの中へ圧縮され、開発者1人が膨大な選択を1人で下さなければならない状況が生まれている
• 1日に以前の10倍の意思決定を迫られる開発者は、決定疲れと曖昧さによって立ち止まりうる
• 素早く判断して効率的な経路を定められる人はAIの生産性を活かせるが、何をすべきか確信できない人に対してAIはその問題を解決してくれない
• 企業はAnthropicやOpenAIへ多額を支払いながらも、AI投資の収益を確認しにくいかもしれない
  • 一部の肯定的成果とともに、無駄、低品質な成果物、それらを片付けるコストも発生する
  • AIモデル提供者はトークン販売が続く限り利益を得るが、顧客企業はより厳格なトークン予算を適用する可能性がある

オープンウェイトモデルとトークン経済性

• McKinneyはオープンウェイトの中国製モデルGLM 5.2を物理インフラ上で実行し、結果は良好だったと評価している
• GLM 5.2は小型モデルではなく、適切に動かすにはB200 GPUが約8基必要である
  • B200 1基の価格は約3万〜5万ドルと見積もられる
  • ハードウェア全体のコストは約25万〜40万ドルに達しうる
• 長期的には、オープンウェイトモデルの品質が向上し、ハードウェアが安価になれば、外部AI企業へ継続的に費用を払わず、個人サーバーの電気代だけを負担する形が可能になることを期待している
• 直近30日間に使用したトークンをAPI定価で計算すると約3万7千ドルだったが、実際にモデル提供者へ支払った金額はそれよりかなり少なかった
• 現在のトークン価格には大規模な補助が含まれている可能性があり、長期的にどのようなコスト構造が持続可能なのかは不透明である
• AI導入率も業界の注目度ほど一様ではなく、一部企業は取締役会やCTOレベルで議論しているだけで、実運用はまだ始めていない長いテールの領域にとどまっている