top of page
検索

AIが「完全に」書いたディープラーニング基盤ソフト──VibeTensorが示す開発の未来

更新日：1 日前


シリーズ: 論文渉猟


◆今回の論文：Bing Xu et al., "VibeTensor: System Software for Deep Learning, Fully Generated by AI Agents" (arXiv, 2026年1月21日）

  • 概要：VibeTensorは、大規模言語モデルを活用したAIエージェントによって生成された、オープンソースの深層学習システムソフトウェアです。PyTorchスタイルのテンソルライブラリをC++20で実装し、Python/Node.jsのフロントエンドからCUDAメモリ管理まで、一貫したランタイムを提供します。人間は高水準の設計指針のみを与え、コードの生成と検証はエージェントが自律的に行いました。NVIDIA H100およびBlackwell世代のGPUで動作検証が行われ、小規模な学習タスク（系列反転、CIFAR-10、ミニGPT）でエンドツーエンドの学習が完了しています。研究チームはこれをAI支援ソフトウェア工学における一つの里程標と位置づけています。



プログラマーがコードを書かなくなる日は、いつかやってくるのでしょうか。2025年2月、OpenAI共同創業者のアンドレイ・カルパシー氏が「バイブコーディング（vibe coding）」という言葉を生み出しました。自然言語でAIに指示を出し、生成されたコードを細かく確認せずに受け入れて開発を進めるスタイルです。週末のちょっとしたプロジェクトや試作品づくりには便利ですが、本格的なシステム開発には向かないとされてきました。


ところが2026年1月、NVIDIAの研究チームがこの常識を揺さぶるプロジェクトを発表しました。「VibeTensor」と名づけられた深層学習の実行環境は、PythonやJavaScriptのインターフェースからGPUのメモリ管理まで、C++/CUDAのコアだけで約6万3千行、テストコードを含めると20万行を超えるコードがAIエージェントによって生成されたものです。人間は大まかな設計方針を伝えただけで、コードの差分を一つ一つ確認することはしませんでした。開発期間はわずか2ヶ月ほどだったといいます。


本記事では、富良野とPhronaの対話を通じて、この挑戦的な実験が投げかける問いを探っていきます。AIはシステムソフトウェアという「骨格」までつくれるようになったのか。そして、人間とAIの協働はどこへ向かうのか。技術的な詳細と社会的な含意の両面から考えてみましょう。




バイブコーディングって何だったのか


富良野：システムソフトウェアをAIがほぼ全部書いた、という話、正直なところ驚きました。


Phrona：バイブコーディングという言葉自体は去年あたりから聞くようになりましたよね。アンドレイ・カルパシーさんが名づけたもので、コードに没入するんじゃなくて、ノリに身を任せてAIに書かせるという。


富良野：そうそう。彼の最初の説明では「コードが存在することすら忘れて」みたいなことを言っていて、僕は最初ちょっと皮肉なのかと思ったんです。熟練したプログラマーが週末に遊びでつくるときの話だろうと。


Phrona：でも実際にはスタートアップの中に、コードの95%がAI生成というところも出てきていますよね。Yコンビネーターの2025年冬のバッチで25%くらいがそうだったという報道がありました。


富良野：その話、興味深いんですけど、一方でセキュリティの穴だらけだったというレポートも出ていて。スウェーデンのLovableというアプリで生成されたウェブアプリの一部に、個人情報が誰でも見られるような脆弱性があったとか。


Phrona：つまり、書けるけど信頼できるかどうかは別の話、という段階だったわけですね。


富良野：まさにそこなんです。VibeTensorが面白いのは、そういう「週末の試作品」レベルではなく、システムソフトウェアという、いわばコンピュータの骨組みにあたる部分に挑んでいる点なんですよね。



システムソフトウェアをAIが書くということ


Phrona：システムソフトウェアというのは、具体的にはどのあたりを指すんでしょう。


富良野：深層学習でいえば、テンソル——多次元の数値配列ですね——をメモリ上でどう管理するか、GPUにどう計算を割り振るか、勾配を自動で計算する仕組みをどうつくるか、といった層です。ふだんPyTorchやTensorFlowを使うとき、その裏で動いている部分。


Phrona：そこは人間が何年もかけて最適化してきた領域ですよね。バグがあると学習結果がおかしくなったり、メモリリークを起こしたり。


富良野：そうなんです。だからこそ、AIが書いたコードを一行ずつ人間が確認しないで大丈夫なのか、という疑問が当然出てくる。


Phrona：論文ではそこをどう担保しているんですか。


富良野：彼らの言葉を借りると「最小限の介入」という方針で、人間は高水準の目標と制約を伝えるだけ。コードの差分を一つ一つ見るのではなく、ビルドが通るか、テストが通るか、既存の実装——たとえばPyTorch——と比較して正しい結果が出るか、というチェックをエージェントに任せた。


Phrona：テストが仕様書代わりになっている、という感じでしょうか。


富良野：まさにそうで、テストを書く作業自体もエージェントのループの中で行われています。何か壊れたら、最小限のリグレッションテストを追加して再実行する、という流れ。論文では「テストを仕様として扱う」と明記されていますね。


Phrona：でも、そのテスト自体がどこまで網羅的かは、結局人間が判断しないといけないんじゃないですか。


富良野：鋭いですね。論文でも「自動テスト合成ではない」と明言していて、テストの設計と維持は依然としてコストがかかると認めています。APIの規模が大きくなればなるほど、その負荷は増していく。



開発の流れと発見されたバグたち


Phrona：約2ヶ月で6万行以上のコードを生成したというのは、かなりの速度ですよね。


富良野：そうですね。開発のサイクルは単純なループで、まずスコープを絞った目標と制約を設定して、コードを生成・適用して、テストを実行して、検証範囲を広げていく、という繰り返しだったそうです。


Phrona：その過程でどんな問題が見つかったんでしょう。


富良野：論文に具体的なエピソードが載っていて、面白いんですよ。たとえばアテンションのカーネル——注意機構を計算するGPUのプログラムですね——を移植したとき、カーネルのパラメータ数が多すぎて起動時にクラッシュしたり、共有メモリの要求が48キロバイトを超えてコンパイルが通らなかったり。


Phrona：そういう低レベルの制約って、知らないと引っかかりますよね。


富良野：もっと厄介だったのは、数値計算の微妙なずれです。安定化のための数式で、自然対数と2を底とする対数を取り違えていたとか。一回のテストでは通っても、学習を何ステップも回すと損失が発散してしまう。


Phrona：単発のテストでは見つからない、構成したときに初めて現れる問題。


富良野：そうなんです。あと印象的だったのは、GPUバッファの初期化漏れ。勾配を累積するバッファがゼロ初期化されていなくて、何回も学習を回すうちに前の値が残ってしまう、という。


Phrona：それは怖いですね。正しい答えが出ているように見えて、実は汚染されている。


富良野：彼らはそれぞれの問題に対して、リグレッションテストを追加して再発を防いでいます。マルチステップの学習をテストに含める、クロスストリームの挙動をチェックする、といった工夫ですね。



動くけど速くはない、という現実


Phrona：実際に動かしてみた結果はどうだったんでしょう。


富良野：三つの小規模なワークロードで検証しています。系列反転という合成タスク、CIFAR-10という画像分類、それからシェイクスピアのテキストを学習するミニGPTスタイルのモデル。


Phrona：どれも深層学習の定番ですね。


富良野：ええ。NVIDIA H100とBlackwellという二世代のGPUで、学習曲線がPyTorchと同じように収束することを確認しています。損失が下がって、精度が上がる。基本的な動作としては正しい。


Phrona：ただ、速度は違うんですよね。


富良野：そこが正直なところで、PyTorchと比べて1.7倍から6倍くらい遅いと報告されています。彼らが「フランケンシュタイン効果」と呼んでいる現象があって、個々のコンポーネントはちゃんと動いていても、組み合わせるとグローバルに最適化されていない。


Phrona：怪物のように、パーツを継ぎ接ぎしている。


富良野：具体的には、自動微分のエンジンにプロセス全体をロックするゲートがあって、同時に複数のバックワード計算が走れないようになっているんです。安全性のためにそうしたんでしょうけど、結果としてGPUが遊んでしまう時間が生まれる。


Phrona：正しさを優先した設計が、性能のボトルネックになっている。


富良野：人間のエンジニアリングって、そういう「全体を見ながら調整する」ところに多くの知恵が詰まっていますよね。ローカルには正しい選択でも、グローバルには問題になる。AIがそこまで到達するのはまだ先なのかもしれない。


Phrona：でも逆に言えば、「動く」という段階まではもう来ている、ということでもありますね。


富良野：そこが今回の一番のメッセージだと思います。研究用のプロトタイプとしては使える。本番環境には持っていかないでね、というのが彼らのスタンスです。



カーネルの性能——勝つところと負けるところ


Phrona：カーネルレベルでは、PyTorchと比べてどうだったんでしょう。


富良野：これが面白くて、勝つ場面と負ける場面がはっきり分かれています。たとえばRMSノルム——正規化の一種ですね——やロータリーエンベディングでは、Tritonで書かれたカーネルがPyTorchの5倍から6倍速い。


Phrona：それはかなりの差ですね。


富良野：一方でアテンション、つまり注意機構の計算では、設定によって結果が変わります。バッチサイズ32、系列長2048というNanoChat向けの設定では、順伝播で1.5倍、逆伝播で1.3倍くらいPyTorchより速い。


Phrona：でも別の設定だと？


富良野：小さいバッチでグループクエリアテンションというやり方を使うと、FlashAttentionに負けるそうです。0.67倍とか。カーネルの特殊化と、ツールチェーンの成熟度次第だと彼らは分析しています。


Phrona：万能ではないけれど、場面によっては競争力がある。


富良野：そうですね。カーネル自体もAIが生成していて、合計で5万5千行くらいあるそうです。TritonとCuTeDSLという二つの方法で書かれている。



人間はどこにいるのか


Phrona：この開発プロセスで、人間は結局どんな役割を担っていたんでしょう。


富良野：大まかに言うと三つですね。最初のアーキテクチャの設計方針を決めること、テストと検証の基準を設定すること、そして最終的な判断——たとえば、これで良しとするかどうか——を下すこと。


Phrona：コードを書く作業からは手を引いているけれど、意思決定からは手を引いていない。


富良野：そうですね。論文には「私たちはエージェントをブラックボックスとして扱った」と書いてあるんですが、その入力と出力の境界を設定しているのは人間です。


Phrona：なんだか、建築家と施工業者の関係に似ている気もします。設計図は人間が引いて、実際にレンガを積むのは別の存在が担う。


富良野：ただ、従来の建築との違いは、施工業者がレンガの積み方をその場で考え出すところでしょうか。人間は「こういう家が欲しい」とだけ言って、細部は任せる。


Phrona：その「任せる」が怖くもあり、魅力的でもある。


富良野：怖いというのは？


Phrona：たとえば、なぜそういうコードになったのか、という説明責任の問題です。バグが見つかったとき、誰がどう直すのか。AIが書いたコードを人間が読んで理解するのは、場合によっては一から書くより大変かもしれない。



技術的負債と理解可能性


富良野：そこはサイモン・ウィリソンさんが鋭く指摘していますね。AIが書いたコードを自分で全部レビューして理解したなら、それはバイブコーディングじゃなくてAI支援開発だ、と。


Phrona：つまり、バイブコーディングの定義自体に「理解しないまま受け入れる」という要素が含まれている。


富良野：そうなんです。で、VibeTensorの場合は、テストで正しさを担保しているから人間がコードを逐一理解しなくても大丈夫、という設計思想になっている。


Phrona：でも、テストをパスしても予期しない振る舞いが潜んでいる可能性はありますよね。


富良野：あります。論文でも「エージェントが生成したコードは、ローカルな単体テストには通っても、繰り返し構成されたときに失敗することがある」と書いています。状態を持つ相互作用、初期化されていないバッファ、偶発的なグローバル同期、といった原因で。


Phrona：だからこそマルチステップのテストが必要だ、と。


富良野：ええ。それでも本番に持っていくなら、人間がコードを読み込んで、必要なら書き直す必要がある。彼ら自身が「本番利用には警告を発する」と明記していますから。


Phrona：その書き直す作業が、結局は人間の仕事として残る。AIが生成したものを「翻訳」して、人間が保守できる形にする、という。


富良野：面白いですよね。AIが書いたコードを人間がメンテナンスできるかどうかが、今後のソフトウェア開発の大きな問いになりそうです。



ソフトウェア工学の未来像


Phrona：この研究が示唆しているのは、ソフトウェア開発のどんな未来なんでしょう。


富良野：一つは、プロトタイピングの速度がさらに上がるということ。アイデアから動くものまでの距離が縮まる。


Phrona：それは良い面ですよね。試行錯誤のサイクルが速くなる。


富良野：もう一つは、開発者の役割が「書く人」から「設計する人」「検証する人」へとシフトしていく可能性。コードを書く技術よりも、何をつくるべきかを明確にする能力が問われるようになるかもしれない。


Phrona：でも、その「明確にする」ためには、技術の深い理解が要りませんか。何ができて何ができないかを知らないと、良い指示は出せない。


富良野：おっしゃるとおりで、カルパシーさん自身が最近、手書きでコードを書くプロジェクトを公開しているんですよ。バイブコーディングの提唱者が、やっぱり自分で書くこともある、と。


Phrona：それはなんだか安心しますね。道具として使うけど、頼り切りにはならない。


富良野：アンドリュー・ングさんも「バイブコーディングは楽じゃない」と言っていて、実際には計画や設計にかなりの労力がかかる、と。言葉のイメージほど気楽ではない。


Phrona：「ノリで書く」という響きとは裏腹に、頭は使っている、と。


富良野：そうですね。むしろ、使う頭の種類が変わっている、という表現のほうが正確かもしれません。


Phrona：VibeTensorの挑戦を見ていて、私が一番気になるのは、こうしたAI生成のコードが増えていったとき、技術コミュニティ全体の知識がどうなるか、という点です。


富良野：といいますと？


Phrona：コードを読んで学ぶ、という経路が細くなるんじゃないかと。オープンソースの良さの一つは、他人のコードを読んで勉強できることですよね。でも、AIが書いたコードが読みやすいとは限らない。


富良野：たしかに。VibeTensorのリポジトリを見ても、「AIが生成した」という注釈はあっても、なぜそういう設計になったかの説明は限られています。


Phrona：人間が書いたコードなら、コミットメッセージやプルリクエストの議論を追えば意図がわかることもあるけれど、AIが一気に書いたものにはそれがない。


富良野：ドキュメントをどう残すか、という課題は今後大きくなりそうですね。AIが書いたコードに、人間が読める解説をつける、という逆転現象。


Phrona：なんだか不思議な気持ちになりますね。人間がAIの通訳をする、という。


富良野：でも、考えてみると、複雑な数式やアルゴリズムを「解説する」という作業はずっとあったわけで、それがコードにも及んできた、ということかもしれません。


Phrona：理解を伝える仕事は、なくならないどころか、むしろ重要になる。


富良野：そうかもしれませんね。コードを書く能力と、コードを理解して伝える能力は、同じようでいて違う。後者がより希少になる可能性はある。



 

ポイント整理


  • VibeTensorの概要

    • NVIDIAの研究チームが開発した、AIエージェントによって生成された深層学習システムソフトウェア。約6万3千行のC++/CUDAコアに加え、プラグイン1万7千行、Pythonオーバーレイ9千行、テストコード5万4千行、AIカーネルスイート5万6千行を含む大規模なコードベース。

  • 「完全に生成」の意味

    • コードの変更はすべてエージェントが提案・適用し、人間は差分レビューを行わない。正しさの検証はビルド、テスト、PyTorchなど既存実装との差分比較によって自動化された。開発期間は約2ヶ月。

  • 開発手法

    • 以下のループを繰り返す

      • ①スコープを絞った目標設定

      • ②コード生成と適用

      • ③テスト実行

      • ④検証範囲の拡大

    • 二つのガードレールが重要：テストを仕様として扱うこと、リファレンス実装との差分チェック。

  • 技術的構成

    • PyTorchスタイルの即時実行モデルを採用。テンソル/ストレージ管理、スキーマライトディスパッチャー、逆モード自動微分エンジン、CUDAランタイム（ストリーム/イベント/グラフ）、ストリームオーダードキャッシュアロケータを含む。PythonとNode.jsの二つのフロントエンドを持つ。

  • パフォーマンスの限界

    • PyTorchと比較して1.7〜6.2倍遅い。「フランケンシュタイン効果」として、ローカルに正しいコンポーネントがグローバルには最適でない構成を生み出す問題が観察された。例として、プロセス全体をロックするバックワードゲートがGPUの飢餓状態を引き起こす。

  • カーネル性能のばらつき

    • RMSノルムで6.3倍、ロータリーエンベディングで5.3倍とPyTorchを上回る場面がある一方、小バッチのアテンションではFlashAttentionに0.67倍で負ける。カーネルの特殊化とツールチェーンの成熟度に依存。

  • エンドツーエンド検証

    • 系列反転（2層Transformer）、CIFAR-10（ViT、深さ6）、シェイクスピア（miniGPT、6層）の三つのワークロードでH100とBlackwell GPUにて学習が完了。学習曲線はPyTorchと同様の収束挙動を示す。

  • 発見されたバグの類型

    • カーネルパラメータ過多によるクラッシュ、共有メモリ48KB制限超過、対数の底の取り違え（ln vs log2）、GPUバッファの初期化漏れなど。マルチステップテストと差分チェックで再発防止。

  • 人間の役割

    • 高水準の設計方針と制約の設定、テスト基準の確立、最終的な品質判断を担う。コード実装からは離れるが、意思決定からは離れない。エージェントはブラックボックスとして扱われた。

  • 研究上の位置づけ

    • 本番利用は推奨されず、AI支援ソフトウェア工学の研究基盤として公開。Apache 2.0ライセンスでGitHubにて利用可能。生成されたコードには一貫性のない規約、冗長な抽象化、微妙な正確性・セキュリティ問題が含まれうると警告。



キーワード解説


【バイブコーディング（vibe coding）】

自然言語でAIに指示を出し、生成されたコードを詳細にレビューせずに受け入れる開発スタイル。2025年2月にアンドレイ・カルパシー氏が命名。「コードが存在することすら忘れる」というフレーズで知られる。


【システムソフトウェア】

アプリケーションを動かすための基盤となるソフトウェア。OSカーネル、ドライバ、ランタイムライブラリなど。深層学習ではテンソル管理やGPU制御を担う層を指す。


【テンソル】

多次元配列のこと。ベクトル（1次元）や行列（2次元）を一般化した概念で、深層学習のデータ表現の基本単位。


【自動微分（autograd）】

関数の勾配（微分）を自動的に計算する仕組み。ニューラルネットワークの学習に不可欠。VibeTensorでは逆モードの自動微分エンジンを実装。


【ディスパッチャー】

関数呼び出しを適切な実装に振り分ける機構。CPU用とGPU用のコードを切り替えるなどの役割を担う。VibeTensorではスキーマライト方式を採用。


【CUDAランタイム】

NVIDIAのGPUでプログラムを実行するための基盤システム。メモリ管理、ストリーム制御、カーネル起動などを担当。


【キャッシュ型メモリアロケータ】

メモリの確保と解放を効率化するため、使用済みメモリを再利用可能な状態で保持しておく仕組み。VibeTensorではストリームオーダードセマンティクスに対応。


【DLPack】

異なる深層学習フレームワーク間でテンソルデータをコピーなしで共有するための標準規格。VibeTensorはCPU/CUDA両方のインポート・エクスポートに対応。


【リグレッションテスト】

新しい変更が既存の機能を壊していないかを確認するテスト。VibeTensorではマルチステップの学習ループを含むテストが重視された。


【LLM（Large Language Model）】

大規模言語モデル。大量のテキストデータで学習し、自然言語の生成や理解を行うAIモデル。コード生成にも利用される。


【Triton】

NVIDIA GPU向けのカーネル記述言語およびコンパイラ。Pythonライクな構文でGPUプログラムを書ける。VibeTensorのカーネルスイートで使用。


【CUTLASS】

NVIDIAが提供するCUDA向けの線形代数テンプレートライブラリ。高度に最適化された行列演算カーネルを提供。


【フランケンシュタイン効果】

VibeTensor論文で名づけられた現象。個々のコンポーネントは正しく動作しても、組み合わせるとグローバルに最適でない構成が生まれること。



本稿は近日中にnoteにも掲載予定です。
ご関心を持っていただけましたら、note上でご感想などお聞かせいただけると幸いです。
bottom of page