本動画は、BoxのCEOであるアーロン・レヴィ氏をゲストに迎え、AIエージェントが今後のソフトウェアアーキテクチャや企業システムに与える影響について深く考察した対談である。エージェントが自律的にツールを操作し、コーディングやシステム統合を行う未来において、SaaSや基幹系システム（ERP）がどのように適応していくべきかが議論される。また、開発者の計算リソース（トークンコスト）と人件費のトレードオフ、クラウドとエッジコンピューティングの歴史的なサイクルなど、技術的かつ経済的な視点から次世代のAIパラダイムを鋭く分析している。
AI能力の普及と企業システムの現実
シリコンバレーの人たちが考えているよりも、AIの能力が普及するのには時間がかかると思います。
バイブコーディングだけでSAPのようなシステムを作れると考えるのは、ただただ馬鹿げていますよ。そうしたドメイン知識のすべては、単によく整理されたデータ層に表現されているだけではないんです。
エンジニアリングの計算予算に関する議論は、今後数年間で最もクレイジーな話題になるでしょうね。
今一番大きな問題は、みんながこのすべての経済性を解明しようとしているのに、機会の大きさがどれほどかという点で少なくとも桁が1つずれていることなんです。もし人間の100倍、あるいは1000倍のエージェントが存在するなら、ソフトウェアはエージェント向けに構築されなければなりません。
抽象的に、これからはAPIのようにエージェントに向けてマーケティングをするんだ、と言う人たちがいますが、私はそれ、ほぼ完全に間違っていると思います。
おお、これはポッドキャストのビッグニュースですね。
もし私たちが皆、エージェント向けにソフトウェアを作らなければならないと想像し始めたら、その点についてはみんな明確ですよね。つまり、人間向けのインターフェースについて考えるのと同じくらいの時間を、ツールのエージェント向けインターフェースについて考えるのに費やすようになっている、というトレンドが起きています。
ええ、その通りです。
私たちがそうしている理由は、もし人間の100倍、あるいは1000倍のエージェントが存在するなら、ソフトウェアはエージェント向けに構築されなければならないという仮説があるからです。では、それらのエージェントはどのようにシステムとやり取りするのでしょうか。それはAPIやCLI、あるいはMCP（Model Context Protocol）などを通じて行われることになります。
そして、今まさに普及しつつあり、効果の面でもこれまでのところ非常に成功しているパラダイムは、コーディングエージェントにSaaSツールへのアクセスを与え、さらにナレッジワークのワークフローや文脈へのアクセスを与えるというものです。これが一種のスーパーパワーになりつつあります。エージェントは単にデータを読んだり情報を理解したりできるだけでなく、達成しようとしているタスクに応じて、実際にコードを書いたりAPIを使ったりできるのです。
それは、さらに複利的に成長し始めているパラダイムのように見えますね。そしてそれが、Claude Codeの現象であり、Perplexityのスーパーアプリやコンピューター操作などでOpenAIが企てていることでもあります。私は、これがこの技術の究極の現れとしてかなり理にかなっていると考えています。
理論的な意味では、あなたの言う通りで理にかなっていると思います。
ええ。
でも実用的な面では、本当に気をつけなければならないことがあります。言い換えると、アルゴリズム的思考というのは、仕事を持っている大多数の人にとって、本当に、本当に難しいことなんです。
確かにそうですね。
一番わかりやすい考え方としては、その辺の人を捕まえて、その人がやらなければならない特定の仕事のフローチャートを作ってくれと頼んだら、おそらく失敗するだろうということです。フローチャートを作ること自体にですね。
ええ、その通りです。
例えば、ある組織でマーケティング計画を立てていて、50人のマーケティング担当者が巨大な製品ラインに取り組んでいるとします。
はい。
おそらく、そのフローチャートを理解し、文書化できるのは1人くらいでしょう。
100%同意します。
ですから、これらのエージェントの1つ、あるいはこのようなコワーキングツールを人々の前に置いて何かを作らせようとしても、何をすべきかをツールに説明する能力は非常に限られているんです。
完全にその通りですね。
でも、もしそれがコンピューターとインターフェースを取るための新しい方法になり、そのサイクルを回さなければならなくなったらどうでしょうか。
まあ、そうなると基本的には、人々がどのように対話するかという次の抽象化レイヤーを開発する段階に戻るだけです。
歴史的に見て、抽象化レイヤーの各レベルを開発してきたのは、組織内の非常に高度なスキルを持った特定の個人でした。そして、彼らが構築した小さな部品が、特定のタスクをこなす人々の世界で小さなツールキットになります。それをうまく組み合わせられる人もいれば、できない人もいます。
でも、それは以前にもペーパークリップや画鋲で起きたことですし、次に私たちが何をしようとも同じことが起きるでしょう。
時代を超えて変わらないのは、仕事がはしごを一段上がり、新しいスキルセットを学ぶことになるという点だと思います。だからこそ、今回のことも何も違わないと私は思っています。ただ、今得られるレバレッジは明らかに桁違いに素晴らしいですよね。
Anthropicのグロースマーケターについて、バズっていたツイートがありましたよね。皆さんは見ましたか？基本的には1人の人間がいて、当時Claude Codeを使って、本来ならサイロ化された様々な仕事で5人から10人がかりでやるようなことを、ほぼ自動化していたという話です。
それがなぜ面白いかというと、それを成し遂げるにはシステム思考の持ち主でなければならなかったからです。つまり、彼はそれを引き起こせるだけの技術的な知識をすでに持っていたのは明らかです。しかし、それは「もし経済の中にあるXという仕事のすぐ隣に、その人が望むものを何でも自動化できる無限のエンジニアのプールがあったら、それぞれの仕事はどのようになるだろうか」ということを示していました。そして、その自動化が可能になった結果、将来その仕事はどうなるのか、ということです。
ええ、それを実現するには自分の仕事をシステムとして考える方法を見つけなければならないという点には同意します。もしかすると、エージェントは時間が経つにつれて、あなたをその方向に導くのがどんどん上手になるかもしれません。でも、例えばGoogle AdWordsでうまくいっているキーワードを取り出して、それをFacebookに移植し、複製されているか確認して、市場で起きていることから新しいシグナルを取り入れるといった、そうした仕事の多くを自動化しようとし始めるというのは、理にかなっているように思えます。
それは大きな飛躍ですね。まず一つ言わせてください。
もう少しで納得させられそうでしたよ。少し頷いていたのに、ちょっと行き過ぎたことを言ってしまいました。
そのAnthropicのグロースマーケターの話を例に挙げると、需要が無限で、率直に言って供給も無限である場合、残りの仕事は私にもできます。無限にあるわけですからね。これは難しい仕事ではありません。ですから、今オーストラリアでガソリンスタンドを経営している人は素晴らしいですよ。
ええ、その通りです。
だから、代わりに600ドルのPCを売るマーケティング担当者になってみて、ネオを相手にどこまでやれるか試してみてください。それこそが本当の仕事です。
わかりました、もっと良い例が必要ですね。
でも、これは本当に興味深い話です。ちょっと古い例、年配の人の例を挙げさせてください。私のいとこは、トップクラスのMBAスクールを出て最初の仕事に就きました。私より少し年上です。彼女はまさにコンピューター時代の転換期に就職しました。実は大学院ではスプレッドシートを使っていなかったのに、職場に行ったらスプレッドシートが現れたんです。でも彼女はスプレッドシートを使うようなタイプではなかったので、代わりにインターンを好きなだけ雇いなさいと言われました。それで就職して最初の1年間、彼女は基本的に部屋いっぱいのエージェント、つまりインターンを監督していたんです。
なるほど。
そして、私のような子供たちがやってきて、スプレッドシートの作業をすべてこなしました。
ええ。
でも、その後数年かけて魔法のように起きたのは、彼女もその同期も皆、スプレッドシートを使いこなす人たちになったということです。
ええ。
そして、銀行のマネージャーになったり、入社して2年経ったりすれば、スプレッドシートを扱うスタッフのチームを持てるという考え方はなくなりました。抽象化のレイヤー全体が上に移動したんです。
インターンがいた頃の古い仕事は、基本的にはHPの電卓を手元に置いて座り、M&Aなどの案件のモデルを計算するというものでした。ピッチ資料をまとめたり、顧客やクライアントのところへ行ったりするまでに、せいぜい2回くらいしか反復作業ができなかったのが、突然彼ら自身で30回も反復作業をするようになったんです。
今、エージェントを取り巻く状況もまさにこの段階にあると思います。50人必要だと思い込んでいて、抽象化のレイヤーとしては、非常に細かく分割されたタスクを1人の超優秀な人がすべて調整しているという状態です。でもすぐに、その全体が統合されて、マーケティング的なものを行うエージェントと呼べるような、一つのスキルセットやコードの塊になるでしょう。
そして、それにマーケティング関連の質問をできるようになるわけですね。
ええ。そして次のステップは、それに実際に行動を起こさせることです。AIのこの再現性のなさやランダムな要素がなくならない限り、実際に行動を起こさせることは非常にコストがかかるものになるだろうと、私は少し懐疑的です。だからこそ、人間をループに組み込むという議論になったりするわけです。
でも、私たちはまさにその転換点にいるのだと思います。何かをやろうとしている人たちと話していると、すでにスプレッドシートを使っている私が、入社して半年のいとこと感謝祭の夕食の席で話しているような気分になります。「なんでこれがこんなに難しいのかわからない。ただ使えばいいのに」って。
そして2年後には彼女も使っているわけですね。
ええ。そして今は、42個のエージェントを作成して一斉に起動し、これらすべてをこなすには、絶対的な天才であり、グロースマーケティングの専門家である必要があります。でも、その天才的な部分はすぐに消え去り、そこにある巨大なドメイン専門知識の塊がドメインエキスパートの手に戻っていくことになるでしょう。
コード生成からコンピューター操作への移行
今の発言の中に、私が反対の立場をとる部分があります。エージェントがコードを書いて何かを実行するようになると考えるのは非常に魅力的です。
ええ。
でも、私は逆の方向に進んでいると思っています。私たちが始めたのは、SaaSソフトウェアの一部を取り上げて、それにAIを追加するというアプローチでした。
ええ。
それが、新しいAI搭載型と呼ばれるものでした。それは、こうしたことにコードを使うという極端なバージョンです。でも、今実際に私たちがやっていることは何でしょうか。SaaSソフトウェアは依然としてSaaSソフトウェアであり、エージェントはそれをコンピューターとして使います。なぜなら、エージェントは実際それにとても長けているからです。
つまり、私たちはコードの生成から始まり、次にターミナルへと移行しました。これは実はコードを書くよりも少ない作業です。
ええ。
そして今年は、コンピューター操作の年になるでしょう。
そうです。だから、彼らがコードを生成するというよりは、人間がコンピューターを使っているのにずっと近い感じがします。そしてそれは、まさにこの中間段階であるように感じられます。
ええ。そして私は実際にコードを生成する世界から来ていますが、それは増えるどころか減っていると主張したいですね。
なるほど。私にとって、コンピューター操作であれ、APIの使用であれ、その場でコードを書くことであれ、それらすべてを一つの大まかなカテゴリーにまとめているのは、もしかしたら私の勘違いかもしれません。
それらは全く別物ですよ。
確かに別物です。でも、私たちが取り組んでいるエージェントでは、既存のスキルを使うべきか、Boxの既存のツールを使うべきか、それとも問題を解決するためにコードを書くべきかを自分で判断するんです。そして、その3つのどれかをいつでも実行できる能力は、信じられないほど役に立ちます。なぜなら、単にコードを書いて特定の操作を実行する方が速い場合があるからです。誰かが自分のドキュメントでやりたいと思うかもしれないすべてのことを、私たちが事前に計画することなど不可能ですから。
だからこそ、モデルがそのユースケースのためにその場でコードを書けるほど優秀であるという事実は、驚くべき特性となります。たとえ、モデルが行うことの90%は、既存の操作を使うだけだとしてもです。時間が経つにつれて、iPhoneには文字通り7つのアプリしか残らなくなり、7つのSaaSアプリを使うようになります。結局、時間の経過とともにこれらは統合される傾向があります。
しかし、iPhoneに7つのアプリしかないというのは、人間が同じことを何度も学びたくないという問題があるからです。人間である私には、それほど多くのアプリを学ぶ精神的な余裕がありません。しかし、ツールやAPIを使用し、コードを書くことができるエージェントには、私たちが抱えているような制約はありません。だから、私はどうなるかわかりませんし、気にしてもいません。
まあ、やらなければならないことが多すぎて、インターフェースを十分に汎用的にできると主張することもできるでしょう。
ええ、その通りですね。
あなたの言ったことには賛成です。話が戻りましたね。
戻りましたね。私たちの意見は一致しています。一致していますよ。
いや、でもここにすごく面白いことがあると思っていて、私はそれが本当に好きなんですが、ソフトウェアが進化してきた過程の話です。例えば、私は一日中SAPを使っています。財務の仕事をしていて、すべてのレポートを作成しなければなりません。そこに誰かがやってきて、「こういう視点で、こうスライスしたレポートが欲しい」と言われます。すると私は「ああ、どうやって作るのかわからない」と思いながら、SAPのヘルプシステムをかき分けて探そうとするわけです。
AIが非常に得意になり得ることの一つは、その表面領域を人間よりもはるかにうまくナビゲートできるということです。ヘルプはすべてそこにありますから、あとは言語をマッピングして見つけるだけです。過去25年間のソフトウェアの能力を活用する上で、人間がボトルネックになっていたんです。
私は人生の半分を、飛行機で隣に座った人に「PowerPointでこれをやるにはどうすればいいんですか」と聞かれて、「リボンを見てください」と答えることに費やしてきました。誰かがWordの箇条書きや段落番号で苦しんでいるのを見たり、Excelで2軸のグラフを作ろうとしているのを見たりするのは、物理的に苦痛でしたからね。Excelの2軸グラフなんて、ほとんど誰もできないロケットサイエンスみたいなものですが、同時に非常に一般的な要望でもあります。だから持たざる者がいて、そのギャップを生んでいたのが人間のユーザーインターフェースだったんです。
消費レイヤーについては完全に同意します。完璧に流動的なUIや消費レイヤーについては賛成です。ただ、バックエンド、つまり記録システムについては、おそらく何らかのデータベースや一般的なAPIのセットに収束し、そこに接続するようになるだろうと感じています。方向性としてはそうなっているように見えます。
同感です。まずは始める必要があります。ええと、私は週末ずっと、自分のNanoCloud botの実装に費やしました。最初に始める時は、あらゆるものへの統合を構築しているような状態です。OpenCloudはすべての統合を持っていますが、NanoCloudはほとんど持っていないので、独自のツールをすべて構築しているわけではありません。
でも、数日間これをやっていると、必要なツールの統合ができてきて…
ええ、でも私たちが話しているのは個人の生産性ですよね。自分の生活を整理するとか。
仕事の生産性ですよ。
わかった、仕事の生産性ですね。そこからSAPシステムの話になり…グローバルなサプライチェーンを持ち、30の異なるシステムにまたがる75の情報を扱っているような企業の複雑さは無限大です。エージェントには相当な処理能力が求められますが、これまでどのようなアーキテクチャを用いても、そこには到達できていません。
でも、あなたが今説明したことは、IT業界が過去50年間文字通りやってきたことであり、これからもやり続けることですよ。退役軍人省のCIOだった私の友人は、75のシステムをつなぎ合わせることにすべての時間を費やしていました。それはすべて統合の冗長性です。
ええ、統合には最適です。
これには完全に同意します。素晴らしい。
統合に関して言えば、これらのAIは最高です。しかし、それはあくまで統合ですよね。文字通り、これら2つのシステムをどうやって縫い合わせるかということです。
でも今起きていることだと思うのは、一種のオンデマンドの統合だということです。ITチームが事前に配線していなかった、システムに対する私の新しいクエリなんです。実行時にそれが必要になるんです。
エージェントの自律性とセキュリティの壁
よし、老害の戯言をやめましょう。先日、CFOやCIOがいっぱいいる部屋で、今みたいな話を少し楽観的にしたんですが、彼らは私を見つめて…ええ、現実主義でしたね。終わった後、6人が駆け寄ってきて「あなたは正気じゃない。私のあなたに対する信頼は完全に失われました」と言われました。
待って、何だって？具体的に何を言ったんですか？エージェントが統合を行うという点ですか？
統合という問題がずっと簡単になるだろうという話です。
ええ、彼らはそれに反対したんですね。
実用的なものに反対する人は誰もいませんが、彼らの恐怖は、エージェントだけでなく人間に統合を行わせることを解き放つことにあります。新しい統合を作成する権限を人に与えるということは、「どうぞ私の記録システムを壊してください」と言っているようなものだからです。
ああ、なるほど。
システム27とシステム38の間に新しいAPIを作成するようなアイデアは、レポートなら構わないでしょう。その人が間違えたところで自己責任ですから。しかし…
過去何年間もこれの読み取り専用バージョンは存在していたと思います。Nが非常に大きい場合ですね。
そしてその多くは消費レイヤーであり、消費者が人間である場合、今のところAIの多くは消費に使われていると感じます。
でも、ええ、私たちは実際に公式のBox CLIをリリースしたところです。それについてのツイートにいいねしてくれてありがとうございます。
私はそれを使いましたよ。いくつかフィードバックがあります。後で話しましょう。
すべてのフィードバックを受け入れますよ。でも、これは本当に興味深いことなんです。社内でもたくさんの議論がありました。「よし、Claude CodeにBox CLIを与えよう。これで自然言語を通じてBoxシステム全体と対話できるようになり、Opus 4.6の強力な処理能力を使って複数の操作をオーケストレーションできるぞ」と。それはもう、頭が吹き飛ぶような体験です。フィードバックはいただくとして、とにかく驚かされます。「デスクトップのこのフォルダー全体をBoxにアップロードして」と言うだけで動きますし、「このフォルダー内のすべてのドキュメントを処理して」と言えば動くんですから。
それは素晴らしいですね。
そこから私たちは考え始めました。たとえば、従業員が5,000人いる会社で、エンジニアリングのドキュメントやマーケティングのアセットなど、共有のリポジトリに誰もがアクセスできるとします。そして誰もがCLIでClaudeを動かしているとしたら。
うわあ。
そうすると、本当に興味深い新しい課題が生じます。パフォーマンスの観点からだけでなく、例えば1時間に10,000回もシステムにアクセスする可能性があるという事実をどう調整するか、ということです。他の人が書き込み操作をしようとしている間に、ある人が誤ってファイルをごっそり別のフォルダーに移動してしまったり、他の誰かが何かを削除しようとしたりするのをどう防ぐのか。エージェントが暴走しているわけですからね。これは、すべてのCFOやCIOが髪を振り乱して走り回り、解決しようとする新しい大きな問題になるでしょう。
まさに私がぶつかった問題ですよ。マーケティングプランのディレクトリを作るというあなたのビデオの例を試してみたんです。そうしたら、ディレクトリを作成するループに陥ってしまって…
可能な限り作り続けるでしょうね。
ええ。それで「入れ子になったディレクトリのBoxの制限はいくつなんだろう。そろそろ限界に達しそうだぞ」と思いました。
実は私たちもそれを知ることになりそうです。
ええ、ええ。でも、直感的には新しいコントロールのレイヤーなどを構築したくなりますが、実際に現場で起きていることはその逆のように感じます。
例を挙げましょう。私たちがこれらのパーソナルエージェントを使い始めたとき、APIキーを渡したり、メールアドレスを教えたりして、彼らがアクセスできるようにしました。すると「でも、どうやってそれを防げばいいんだ？」となりますよね。そこで今みんながやっているのは、エージェントに専用の電話番号を与えることです。
ええ。
実際、私は自分のNanoClawに専用のクレジットカードを渡しました。
CVSで買ったVisaのデビットカードだといいんですが。
お金は全額入っていますけどね。いやいや、その後、エージェントがログインできる専用のGmailアカウントを与えたんです。Gmailにはこれらのロールベースのアクセス制御権限がすべて組み込まれていますから、私たちはすでにこうした権限システムの多くを構築していると主張することもできます。
エージェントを別の人間の人間として扱い、別の認証レイヤーを構築する代わりに…
よし、今すぐその要素を取り下げてもいいですか？これからぶつかる問題についてです。
どうぞ。
それは個人の生産性にとっては素晴らしいことです。しかし、エンタープライズでこれからぶつかる問題は…簡単な例を挙げましょう。何かをする50人のチームがあるとします。基本的には、50人の人間と50人のエージェントが同じ共有スペースでコラボレーションすることになるのでしょうか。私は当然、自分のエージェントに対する完全な監督権を持っています。しかし、もし私のエージェントが他の誰かと協力し、その人との共有を理由に、本来アクセスすべきではないリソースに誤ってアクセスしてしまったらどうなるでしょうか。そして、この自律的でステートフルなエージェントが動き回り、他の人の情報を扱っているとしたら。
デフォルトのエンドツーエンドの議論では、彼らを人間と同じように扱うことになります。
でもそれでは機能しません。なぜなら、完全に人間として扱うことはできないからです。普通の人間が相手の場合、あなたと一緒に、あるいはあなたのために働いている人のSlackチャンネルを見ることはできませんよね。その人としてログインすることもできませんし、監視することもできません。彼らは現実世界での自分自身の実行に対して責任を持っています。
しかしエージェントの場合、彼らが失敗した方法についてあなたがペナルティを受けることはありませんが、彼らがしていることに対するすべての責任はあなたが負うことになります。あなたには完全な監督権があり、おそらくその完全な監督権を持つ必要があるでしょう。エージェントにプライバシーの権利はありません。
ですから、単に人間のように扱うというだけでは済まない破綻が生じます。なぜなら、私は彼らに何かへのアクセスを与えつつ、ある時点で彼らとしてログインし、「いやいや、お前は全体をめちゃくちゃにしたから、全部元に戻す必要がある」と言えなければならないからです。
しかし、もし私が彼らとしてログインできるのであれば、彼らはどのようにして現実世界で他の人々と協力し、機密性や安全性を保ちながら活動できたというのでしょうか。結局のところ、エージェントは依然としてあなたの拡張なのです。彼らがあなたの拡張であることを回避するのはほぼ不可能です。今私たちが考えているのは、すぐには実現できないようなことです。
論理的につながっていない気がします。
そうかもしれません。
でも、例えば私の従業員の場合、私は彼らとしてログインすることができますよ。
実際にはしないでしょう？
彼らのメールにアクセスすることはできます。
ええ、もし訴えられたりした場合にはね。でも、彼らが1通メールを送ったからといって、日常的に彼らとしてログインしているわけではありません。
エージェントの正しい運用モデルもそれと同じではないですか？
リスクが千倍も大きいんですよ。エージェントはいつでもあなたの情報を漏らします。プロンプトが出されれば、喜んで誰かにメールを送ってしまうでしょう。
最終的な状態でも、これらのものは依然として不完全なコンピューターであり、常にそうだとお考えですか？
不完全という言葉は好きではありません。日常的な意味で使っているなら別ですが。
情報を保持することが決してできず、決して…
つまり、コンテキストウィンドウの中にあるものを秘密に保つ能力、例えば「コンテキストウィンドウにあるXという情報を漏らさないでください」と指示したとしても、それは解決するのが非常に難しい問題だと思います。
なるほど。それでは、エージェントがリソースにアクセスできるため、何かがそのコンテキストウィンドウに入り得るなら、理論的にはコンテキストウィンドウからプロンプトインジェクションで引き出される可能性があると想定すべきですね。そして今のところ、それを解決する方法はわかっていないと。
そういうことです。だから、もし私があなたの新しいエージェントのメールアドレスを知っていて、それにアシスタントのようにメールを送った場合、人間を相手にするよりも10倍簡単にソーシャルエンジニアリングできてしまいます。そのエージェントがあなたのM&Aドキュメントなどにもアクセスできるようになっているなら、それを防ぐのは難しいでしょう。
でも、これって今のAIのほぼ全てに当てはまることではないですか？
どの部分がですか？
私たちが知能を使うための共有システムは、共有のコンテキストを持っているという事実のことです。
どういう意味ですか？
つまり、現在私たちが社内でAIやエージェントを使用する際、まさにそのように使用しているということです。
だからこそ、彼らは現在事実上「あなた」として機能しているのであり、彼らが「あなた」として機能しないようにする方法を私たちはまだ知らないのです。一つ例を挙げさせてください。問題は、エージェントを騙して情報を漏らさせることが簡単にできてしまうことなんです。だからこそ、完全に自分で意思決定できる独自のリソースへのアクセスを彼らに与えることは、私たちがまだ実現できていないことなのです。
でも、あなたの問題を解決する完璧な例がありますよ。私たちはすでにオープンソースでこれを経験しているんです。
はい。
オープンソースのモデルは、「すべてそこにあるから、好きなものを選んで使いなさい」というものでした。その頃は世界がはるかに小さく、私たちがXでポッドキャストをやりながら議論するような時代ではなかったので、誰も議論しませんでした。
しかし、すぐに誰もが先ほどあなたが話したような問題に気づきました。もし大きな会社を経営しているなら、従業員がオープンソースのソースコードを商用製品にそのままコピーするようなことは許されません。ライセンスの問題や品質の問題など、多くの問題がありました。そして、こうしたすべての規範が構築されていきました。
現在起こっている議論は、新しいテクノロジーがどのように発展していくかという、この非常に興味深い現代の現象にすぎません。これがすべてリアルタイムで起きているんです。オープンソースの時代には、このくらいの会議室に集まって、WindowsやOfficeでどれだけのオープンソースを使えるかを議論していました。インターネット上の誰も私たちがそんな議論をしていることなど知りませんでした。
私が非常に興味深いと思うのは、詳細についての議論だけでなく、「これがどこへ向かっているのか」という概念全体が非常に大々的に議論されており、皆が実際の到達点にたどり着くよりもはるかに早く、最終形態にたどり着こうとしているということです。だから本当に必要なのは、人々がただ作り続けることなんです。
基準が必要ですね。
え？
ただ何らかの基準が必要です。
最終形態に関する私たちの直感は少し異なっていると思います。私の直感を押し付けたくはありませんが…エンドツーエンドで考えれば、これらは最終的に人間と同じような信頼性に収束する、と主張することもできます。それは私たちが自動運転をどう見ているかと全く同じです。その場合、人間から身を守るために使うのと同じメカニズムを使います。内部の脅威を考慮し、人が買収される可能性を考慮し、人が間違いを犯すという事実を考慮してシステムを構築します。それが運用プロセスです。だから、一つの直感としては、それが最終形態になるということです。
ええ。
もう一つの直感は…
いや、私が言いたいのは、今の現状について話しているということです。最終形態について意見が合わないとは思いませんし、戦略的にも私たちはヘッジしています。なぜなら、私たちはエージェントユーザーを構築していくつもりだからです。OpenClawがBoxアカウントを持ち、それが運用されるなんて、アカウントが2倍になるわけで素晴らしいアイデアだと思います。
その通りです！2倍ですね。最高です。
私が言っているのは、今の時点では、M&Aのデータルームを安全に与える方法がまだ分かっていないということです。
でも実際にはもっと難しいですよ。脅威のベクトルははるかに洗練されたものになるからです。
彼は懐疑的ですね。
人間とエージェントの間でいたちごっこが起きているんです。エージェントが今日の人間と同じように振る舞うと想定することはできません。なぜなら、情報を漏らそうとする最も速く、最も思慮深く、最も狂った人間がプロンプトインジェクションを試みるようなものだからです。
ええ。
だから、これから起こることの一部は、企業顧客がこのすべてに何らかの正当性や安全性が確保されるまで、すべてを閉ざしてしまうフェーズを経るということです。しかし、その間にも個人、特に開発者たちは大きな進歩を遂げていくでしょう。
それが最もエキサイティングな緊張感を生むと思います。企業はこうした先進的な個人に取り残され、その個人たちはスタートアップのようになり、スタートアップは企業よりもはるかに速く動くようになるでしょう。なぜなら彼らにはこうした問題がないからです。
いや、スタートアップでエージェントが暴走して何かをしでかす可能性もありますよ。
ええ、でもそれはドラマのシリコンバレーの1エピソードになるくらいで、大したことではありません。
人間と同じリスクがあるという点には同意します。でもいくつか違いがあって、例えばClaude Codeに対して「電源を抜くぞ」と脅すことはできません。一方で普通の従業員に対しては、組織内で悪いことをしようとする人は95%以上いないという前提がありますから。
彼らは意図的にやろうとはしていませんが、不注意で悪いことをしてしまう可能性はあります。まだシステムが修正されていないというあなたの指摘に戻りますが。
私の意見では、今のエージェントに正しい指示を与えるよりも、人間の従業員が間違った方法で社外の人とファイルを共有しないようにする方がずっと簡単です。
それに、全く異なる抽象化レベルでそれを止めるツールもあります。
だからこそ、これをソフトウェアに組み込む必要があるんです。でも、あなたの最後のポイントをまとめるなら、これこそが、シリコンバレーの人たちが考えているよりもAIの能力の普及に時間がかかる理由なんです。
私たちが目にしているのは、私たちが話しているようなリスクを一切負わずにゼロから立ち上げることができるスタートアップです。彼らには失うものが何もないからです。私たちはそれを現在進んでいる軌道として見ています。しかし、JPモルガンのような大企業に行って「あなたのビジネスを自動化するためにNanoClawをどのように設定しますか？」と聞いても、「ああ、それは少しギャップがあるな」となるわけです。
ええ。
スタートアップと大企業、SaaSモデルの分断
皆さんはどう思いますか？これは非常に興味深い問題を提起していると思います。大企業、スタートアップ、エンタープライズの間の分裂です。
現在のSaaSベンダーは、私が完全に同意するわけではない「SaaSアポカリプス」の奇妙な状況に苦しんでいますが、彼らはこの問題に直面しています。彼らは業務データそのものを売っているわけではなく、システム全体のインテリジェンスと専門知識を売っているのです。
しかし、エージェント側は今やデータだけを買いたがっています。データをライセンスし、データに無制限にアクセスしたいと考えています。しかし、SaaSベンダーはそれをビジネスにしてきませんでした。WorkdayやSAPなどでは、APIアクセスをどれくらい許可するかについて長年の対立点がありました。
Salesforceは3回も大規模なプラットフォームの再設計を行いましたからね。ウォール街が経済性や問題について間違った見方をしているのとは別の理由で、これは特に興味深い問題だと思います。技術的な観点から見て、データをトレーニングや実行に使いたいという要求に直面したとき、記録システムとは何を意味するのでしょうか。
彼らは日々の業務の実行について話していると思います。ベンダーの懸念は、大口顧客のデータの上にトレーニングレイヤーを構築されることではなく…
実際には、トレーニングの段階に入らなくても彼らは懸念しています。UI内での利用に比べて、インターネット経由で少しデータを送信するだけでは、初期のマネタイズのレベルが全く異なるからです。
そのマネタイズの部分こそがウォール街の視点です。SAPを例に挙げると、彼らを非難するつもりはありませんが、彼らが消えてなくなることはありません。それは馬鹿げています。バイブコーディングだけでSAPのようなシステムを作れると考えるのは、ただただ馬鹿げています。
それらのドメイン知識のすべては、単によく整理されたデータ層に表現されているだけではないんです。彼らがどれほど努力してもね。UIの中にも、中間層にも、そして単にシステムをどう使うかという運用の中にも、たくさんの知識が詰まっています。だから、これがどう進化していくのか、私には本当に分かりません。SAPはなくならないからです。そうなると、何かを行うエージェントAIであれ、単にデータを読み取るだけのAIであれ、その特定のデータソースにおけるAIの普及を遅らせることになるでしょう。この先どうなると思いますか？
次に呼ばれなくなるようなことを言ってしまわないか心配です。良いことを言いますよ。私は「エージェントが欲しがるものを作れ」という考え方にすっかり染まっていると思います。
過去1年ほどでこのトピックについてPaul Graham的な用語が登場しましたが、基本的にはこうです。これを十分に反復すると、ある時点でエージェントは自身が実装し使いたいツールを大半において決定するようになります。
確かにエージェントがエンタープライズシステムを直接入れ替えることはできませんが、世代が進めば、エージェントが既存のソフトウェアの壁に何度もぶつかり、「そろそろこの古いHRシステムを捨てないと、このワークフローを自動化できませんよ」と告げるようになるかもしれません。
ええ。
だからこそ、非常に興味深い力学が働くのだと思います。先ほどの話に戻りますが、人間に比べて100倍、1000倍のエージェントがソフトウェアにアクセスするようになると想像してみてください。それを何度も繰り返せば、最終的にエージェントがアクセスするソフトウェアスタックは、エージェント向けに作られていなければならなくなります。
最後まで抵抗するERPシステムがいくつか残るかもしれませんが、それ以外の部分は、基本的にエージェントが仕事に必要な情報にどれだけうまくアクセスできるかにビジネスのパフォーマンスが相関するようになります。従って、企業のITスタックはそれをサポートするように設定されなければならず、実質的にエージェントが主導権を握ることになります。
ビジネスのソフトウェアはそのエージェントが効果的に働けるようにサポートしなければならなくなります。それはつまり、SaaSやソフトウェアビジネスを構築する全ての人にとって、本当に高品質なAPIを構築できるかどうかが勝負になるということです。
それをマネタイズする方法はありますか？エージェントのアイデンティティやアクセス制御を管理する方法は？ソフトウェア会社を立ち上げるなら、それが解決すべき新たな問題になります。
どのようにマネタイズするかについてですが、例えばWorkdayがHRレコードを引き出すたびに1ペニー請求するようになるのか、それはこれから解明されていくでしょう。
ビジネスによっては収益が減ることもあれば、はるかに増えることもあると思います。私たちがワクワクしているのは、すべてのエージェントがファイルを扱うのが本当に好きだという点です。ですから、おそらく未来には以前よりも多くのファイルが存在するようになるでしょう。
エージェントがそのデータを簡単に扱えるプラットフォームを構築できれば、私たちのビジネスモデルにとっては非常に楽観的な結果になると賭けています。
一方で、その未来のシナリオにおいて、ソフトウェアよりもエージェントの方がより多くの価値を生み出すため、制約が強くなるビジネスモデルもあるでしょう。そして、その中間のあらゆるケースが存在するはずです。
一つ反論してもいいですか？
反論するんですか？今の話は全然物議を醸すような内容じゃないと思っていました。
いやいや、私は概ね…私たちはここで議論するためにいるんですからね。ただ、Paul Grahamや多くの人が見落としていることが一つあると思います。彼らはインターフェースに焦点を当てて、「エージェントのために何かを構築する」と言いますよね。私はそれが完全に間違っていると思います。
なるほど。
公平を期すために言うと、Paul Grahamはエージェントについて語っていたわけではなく、私が彼の言葉をここに持ち出しただけですが。これは素晴らしいですね。
抽象的に「これからはAPIのようにエージェントに向けてマーケティングをするんだ。良いIDLを持つことが最も重要だ」と言う人がいます。しかし、私はそれがほぼ完全に間違っていると思います。
おお、これはポッドキャストのビッグニュースですね。
エージェントが本当に得意なのはたった一つです。
おお、何ですか？
それは、自分たちで道を見つけ出すことです。結局のところ、意味論の方がはるかに重要になるんです。私の経験上、エージェントは何をしているにせよ、正しいバックエンドを選ぶのが非常に得意です。彼らは「ああ、このインターフェースはとても良い」とか「ドキュメントが素晴らしい」とか、そういうことでは判断しません。コストのパラメーターや耐久性などを重視します。
つまり、彼らはクラウドプラットフォームなどのプラットフォームを使用してきた私たちの集合知を持っているのです。エージェントにプラットフォームを選ばせると、インターフェースではなく、実質的な中身に基づいて選びます。だから業界として「エージェントに向けてマーケティングしなければならない」とインターフェースにばかり注目していますが、実際には私たちはより良いシステムを構築することを迫られており、それが選ばれる基準になるのだと思います。
なるほど。それなら反論の余地はありませんね。私たちは完全に一致していると思います。反論の機会を台無しにしてすみません。私はこれをマーケティング的なものとして捉えているわけではなく、もしあなたのツールがエージェントに対して閉ざされていれば、エージェントは最終的にその企業のために別のより良いツールを見つけるだろう、という意味で言いました。
かつてはGartnerのような評価機関に「どうすればいいか教えてくれ」「どのシステムを使えばいいか教えてくれ」と頼んでいました。しかしある時点で、十分に反復されれば、エージェントが「この種の操作にはこのデータベースを使うべきです」と言うようになり、そこに組み込まれていなければ、初めから勝負になりません。
そして私たちはこれを歓迎すべきだと思います。なぜならエージェントは適切な技術を選ぶのがかなり賢いからです。過去には、人々が購入する理由は別のところにあることが多かったので…
でも心配しないでください。シリコンバレーでは、この実力主義をすぐにお金で台無しにするでしょう。「よし、お金を積もう」って。
エージェントにインセンティブを与えるAPIを用意するでしょうね。Workdayのマーケティングエージェントが、推奨事項を購入できるようになるかもしれません。
エージェント向けのステーキディナーを再現する方法を見つけるわけですね。
ええ。
システムの階層構造は消滅するのか
しかし、社内のウェブや社内サイトで実際に起きたことがあります。すべての企業には、部門や作業領域ごとに最高のドキュメント、最高のスライドショー、最高の財務モデルを共有するファイル共有サーバーがありました。人々はそれに慣れ親しんでいましたが、目当てのものが見つからないと新しいものを作成し、多くの組織がそのように運営されていました。それは事実上の自由市場でした。
Boxが登場する前の世界では、ファイルに入っていれば誰も気にしませんでした。SQLデータベースに入っているかどうかだけを気にしていたんです。
あなたが説明しているモデルのリスクの一つは、エージェント自身が事実上の新しい記録システムを立ち上げてしまうことです。
ああ、エージェントがシステムをめちゃくちゃに断片化してしまうということですね。
IT担当者がミドルウェアやエンドユーザーの領域だと思っているところでね。それは本当のリスクだと思います。ある意味で、マクロが企業を運営するようになってしまうということです。彼らはこの光景を見たことがあります。マーケティング部門がイベントのためにインターネット上のウェブサイトを勝手に購入し、それが巨大なセキュリティの脆弱性となってメーリングリストが漏洩し、会社全体が訴えられるといった事態です。だから、私たちが考える以上に現実世界での力学には強い緊張感があると思います。
ええ。しかし、これもまた組織によって進むスピードが異なる問題の一つだと思います。JPモルガンがこの取り組みで最も遅く、スタートアップが最も速いでしょう。その差は大きいですが、スタートアップであっても、ある時点では記録システムが必要になりますし、最初はSaaSから始めるので、すぐにそれを置き換えることはないでしょう。だからもう少し複雑だと思います。
この点については、2つの競合する見方があるように感じます。イーロン・マスクが言うように、「プロンプトを出すと機械語が吐き出される」という、レイヤーが崩壊するという見方です。過去に作られた既存のインターフェースやレイヤーはすべて消え去り、文字通りプロンプトから機械語へ直結するというものです。
もう一つの見方は、システムの歴史においてレイヤーが消えることは決してないというものです。ただ層が重なっていくだけだと。なぜならレイヤーの多くは、組織の境界や状態の境界、あるいは互換性のためにあるからです。
互換性のために残るんですよね。
そうです。だからもう一つの議論は、私たちが組織や人間の必要性から非常に意図的にこれらのレイヤーを進化させてきたのであり、それは変わることはなく、エージェントがそれに合わせてマッピングしていくというものです。私は後者の陣営に近いですね。システムは今後もかなり似たような方法で使われ続けると思います。エージェントがそれを使う頻度は増えるかもしれませんが、それほど進化するとは思えません。
イーロンは、あのAnthropicのグロースマーケターのカテゴリーにいるのかもしれません。何年にもわたって彼の会社のIT部門を見ていると…彼ならできるでしょうね。
彼ならできます。彼は最も自家製のシステムを作る人です。イーロンのAIならやるでしょう。
でも、一般の人々は「毎回同じように動くCRMシステムが欲しいだけなんだけどな」と思うわけです。
過去に試みられなかったわけではありません。ERPシステムを第一原理から見直すなら、1970年代にSAPが始まった当時は様々な前提がありました。今日、第一原理から始めれば、何が重要かについて全く異なる前提からスタートし、全く違う設計をするでしょう。しかし、それでも10年くらいしか持たず、「ああ、あの決断は間違っていた」と思うようになるんです。
だからレイヤーには意図があると思いますが、同時に第一原理の考え方も存在し、それは常に存在し続けます。なぜなら、任意の時点で第一原理に基づく決定が、多くの異なるものを必要とするからです。
だから10年前には完全に理にかなっていた決断を避けたとしても、そこから新しい正解にたどり着くには10年や15年かかります。そして今度は「うわ、これは全く違う方法でできたはずだ」と思うようなことが山ほど出てくるでしょう。
だからこれも結局のところ、終着点に向かって競争しようとする議論のように感じます。
ええ。でも、あなたが説明したようなことが起こる最初の例を見てみましょう。それが本当の指標になると思います。企業はこれをすべて解決し、最終的にはレイヤーやアーキテクチャのモデルに立ち返ると思います。なぜなら、それがポリシーやセキュリティについて私たちが考えるための唯一の方法だからです。
それに、システムを構築する唯一の方法でもあります。
ええ。
そうでなければ、ただアプリを作っているだけになってしまいます。一つのことだけをするアプリを作るなら、こんなものはすべて必要ありません。全く別のやり方があります。
私がかなり魅了されているのは、素晴らしいデータポイントや逸話があるわけではありませんが、純粋な第一原理アプローチからゼロから立ち上がるサービスカテゴリーの企業という概念です。マーケティングエージェンシーやエンジニアリングコンサルティング会社、あるいは法律事務所のためにやっている人もいるかもしれません。
建設設計とか。
ええ、まさに建設、設計、建築。情報バリアやアクセス権限の制約がなければ、会社の作り方が全く変わってくるからです。エージェントに仕事に必要なコンテキストをすべて与え、特定のことのためにその場でソフトウェアを書かせることができます。
大規模な既存企業がこの状況に適応するまでの間、それはある程度破壊的なものになると思います。そしてそれが、この新しい企業の形がどのようなものになるかという前例やケーススタディを生み出すでしょう。
しかし時間が経てば、彼らも他のすべての企業と同じ問題にぶつかることになります。
地理的な問題や市場セグメント、流通の課題などにぶつかるでしょうね。小さな壁の外に出れば、物理的な世界にぶつかりますから。
ええ。
今、新しいビジネスモデルが開拓されるという考え方は好きです。
もちろん、ええ。
「データへのアクセスに5セント払いたくない」とか「ツールを1回使うのに1ドル払いたくない」という理由だけで、経済的価値に対して100分の一しか活用されていない情報やソフトウェアがたくさんあるからです。でも、エージェントに予算とプロトコルを与えれば、突然「おお、彼らは深いリサーチタスクのためにオンザフライで医学研究を取得でき、私はそれに3ドル払うよ。そしてエージェントは取引できるんだ」となります。インターネットにとって全く新しいビジネスモデルの世界が開かれるようなものです。
ちょっと…おお、優しすぎましたね。もっと踏み込むかと思いました。
いや、それが最大の話ですよ。
コンピューティング予算とAIの経済学
今、空中に浮いている最大の問題は、誰もがこのすべての経済性を解明しようとしているのに、機会の大きさがどれほどかという点で少なくとも桁が1つずれていることなんです。
人々が思いつく新しいモデルが今の時点では誰にも分かりませんが、新しい技術には常に新しいモデルが伴います。今の議論を妨げているのは、基本的には金融やウォール街の人間が、まるで私たちが古い世界にいるかのようにGPUやトークンを正当化しようとしていることです。彼らは収益の世界を直線的な成長曲線として捉え、すべての費用を正当化しようとしています。
これはPCの時と同じ問題です。人々はMIPSの消費を有限なものとして捉え、PCを有限な市場だと考えていました。すべてのデスクトップにMIPSを置いたらどうなるかなど考えもしませんでした。特に、ソフトウェアはハードウェアに付属しているものだと考えられていて、ソフトウェアだけを販売しようなんて誰も思いませんでした。ある1人の男とポールを除いては。そして結果的にそれが非常に良いアイデアだったと判明したんです。
クラウドの時にも同じことが起きました。人々はクラウドを見て、「年間60,000台ほどのサーバービジネスを、他人のデータセンターに移すだけだ」と言いました。
ええ。
「そして価格を分割するんだ」と。誰も「クラウドに移せば、リソースが平準化されて1000倍も使われるようになる」とは考えませんでした。ウォール街のモデルが、この固定された収益のパイというゼロサム思考を持っていることが、私を本当にイライラさせます。
奇妙なゼロサム思考ですよね。企業の支出額は決まっていると考えている。
Salesforceが直面した問題もこれでした。マークが道を切り開いていた時、CRMビジネスの規模は年間20億ドルでした。サーバーを買い、Oracleのライセンスを買い、数年間のデプロイやコンサルティングに悩まされる必要がありました。しかし、営業担当者が個別にサインアップできるようにすれば、摩擦なしに皆がサインアップするようになるんです。AIでも間違いなくそれが起こるでしょう。
一例を挙げましょう。私は10年間投資に携わり、おそらく240社のポートフォリオを持っています。そのうち50社はインフラストラクチャー企業で、過去うまくいったところもあればそうでないところもあります。しかし、この6ヶ月間ですべての企業が劇的に成長しています。
「なぜだ？」と考えますよね。単純に、これまで以上に多くのソフトウェアが書かれているからです。
ええ。
エンタープライズ顧客を獲得したからではなく、現在インフラストラクチャー層の消費が圧倒的に増えているからです。より多くのソフトウェア、より多くのエージェントが存在することで、コンピューターリソースの消費はさらに増えるでしょう。ですから、コンピューターの側面においては間違いなく混乱が起こるでしょう。
皆のスマートフォンがAIの巨大な消費者になるという段階にはまだ達していませんからね。
すべてのスマートフォンやデバイス上でAIが消費されるようになれば、その量は数十億倍になるでしょう。
マイクロペイメントについてはどう思いますか？
すべての技術において、1ペニーの何分の一かで課金できると考えるマイクロペイメントの話が出てきます。しかし最終的に、特にエンタープライズ領域では、企業は単純にリソースを消費するだけになります。大量のライセンスを一括で購入する方が安くて簡単だからです。
ええ、ある程度の予測可能性が欲しいですからね。
予測可能性が欲しいですし、あれこれ考えたくないんです。
ただ、エージェントが少額の取引の摩擦を気にしないというのは、今回が初めてのことだと思います。ペイウォールの後ろにあるリソースに対して、何かが実際に喜んでお金を払ってくれる初めてのケースです。
世界はすでに、顧客やサービスのためにこれらの支払いを効率的に集約するインフラを構築しています。現在トークンが原価の大きな部分を占めているため、業界は従量課金制へと押しやられています。
永久ライセンスからサブスクリプションに移行した時のような大きな変化が必要です。今、私たちはまさに従量課金ベースへと向かう同じ変化を経験しています。従量課金制はかなり詳細で…AWSの時も経験しましたよね。
ええ。クラウドコンピューティングへの恐怖から、「一番安いところを見つけて調整してくれる仲介企業が必要だ」というフェーズがありました。
今度はこれにトークンが関わってくるわけです。
このエンジニアリングの計算予算に関する議論は、今後数年間で最もクレイジーな話題になるでしょう。エンジニアリング費用のうち、どれだけをトークンに割り当てるべきか。Twitterで誰の意見を読むかによって、1%だったり100%だったりします。
でも、CFOは文字通りその答えを知らなければなりません。
ええ、分かります。でもCFOは常に答えのないものの答えを知りたがるんです。
いや、ウォール街が彼らに答えを出させるんですよ。
そして何らかの数字を出させ、それに縛り付けられ、結果的にクビになる。
まあ、研究開発は上場テクノロジー企業の収益の14%から30%くらいを占めています。計算コストがエンジニアリングチームの2倍のコストになるか、それとも3%増えるだけかという違いは、EPSのすべてを左右します。
答えを知る必要があるのは分かります。
私はこの祭壇で数人のCFOが犠牲になることもいといませんよ。
それはいい切り抜き動画になりますね。でも理由は、私たちが今わからないことを知ろうとしているからです。
これはインターネットの帯域幅でも起きたことですし…
インターネットの帯域幅とは全く比べ物になりませんよ。
いやいや、真空管でもトランジスタでも起きましたし、あらゆるテクノロジーで起きたことです。「プログラマーがすべての企業を飲み込む」と言われた時代もありました。
ええ、それは私の生きている間に起きたことで、作り話ではありません。
でも、組織内のすべてのエンドユーザーが、自分のためにリソースを完全に弾力的に立ち上げられる時代など、今までなかったと思います。
確かに。彼らがそれを立ち上げるのは多くの場合、非常に正当な理由があります。
2000年代初頭にクラウドで起きたことと似ていますね。資本的支出から営業費用、そして無制限の支出へと移行した時と非常に似た議論を覚えています。
ええ、私たちのブリーフィングセンターでCFOたちが「私たちは農業の会社だから資本的支出しか知らないんだ」と言っていたのを覚えています。
あるいは「私たちは営業費用ベースの会社だからクラウドが大好きだ」とか。
ローカルのコンピュートエンジンが、これらすべての安全弁になることも軽視しないでください。
それはいつ起きるんですか？
問題は現在の技術観でそれがいつ起きるかではなく、どうやって突然起きるかです。
歴史上、そういう方向に向かったことはありますか？
ええ、逆に動いたでしょう？
いや、すべてクライアント側に移ったんです。80年代に戻ってみてください。
なるほど。今まで聞いた例の大半は…
真空管の話は不当でしたね。
反論しづらい例を出しているんです。
確かに。すべてが再びクラウドに移行してからは、まだ10年か15年しか経っていません。そして最近何が起きたかというと、朝起きて「重要だが静的なワークフローのいくつかをオンプレミスに戻そう」と言う人たちが出てきたんです。
AIでね。それは事実です。
あなたがブログ記事に書いたんじゃないですか。アーカイブを引っ張り出させないでくださいよ。
その件ではウォール街からたくさんの質問を受けましたからね。
それはデータセンターを自分で作るという話で、私が言っているエッジコンピューティングとは全く別物です。
私はクラウド至上主義の陣営にいますが…あなたはエンジニアリングチームの計算予算を管理するリーダーとして、それが問題になるとは一瞬たりとも思わないんですか？
もちろん重要です。ただ長期的には…
長期的な話ならどうでもいいです。ポッドキャストすら必要ありません。基本法則としてはこうです。スタートアップはそれが問題でないかのように資金を燃やし尽くすでしょう。大企業は恐怖のあまり凍りついて何もしないでしょう。そしてその中間で、財務状況が許す限り賭けに出ようとする人たちが現れ、彼らがスペースをリードするようになるでしょう。
特定のアプリーケーションや使用領域においてそうするかもしれません。しかし、CFOがクビになるのを恐れて誰も参入しないなんてことはあり得ません。
ええ。間違えを犯すCFOもいるでしょう。全員が少しずつ…
もしそうするなら完全に失敗ですね。エンジニアには今、計算予算のことなど考えさせたくないはずです。私たちはまだ技術を開発している最中ですから。
クラウドの時も15年間同じ議論をしてきたように感じます。これは全く新しいことです。クラウドインフラについて考えなければならなかったのはエンジニアリングの10%だけでした。
2016年から2018年頃にかけて、クラウドの支出やAPIの支出が制御不能になっていたため、FinOpsのダッシュボードのような企業がたくさんありました。
ええ。でもこれはかなり違いますよ。YouTubeのコメントで批判されるのを待つことにしますが…これまでは会議室に入って「あのアルゴリズムを少し効率化して、夜間にクラスターをあまり使わないようにしてくれないか」と頼めば解決しました。
しかしこれは、エンジニアが行う一つ一つのプロンプトについての話なんです。「長く走らせるプロンプトにしたいか？」「並列化したいか？」「無駄なトークンに対する許容度はどれくらいか？」など。私自身は今、「新しいことを試しているんだから、トークンはたくさん無駄にすべきだ」と考えています。
10個の実験を並列で実行して90%のトークンを無駄にしても、1つの成功ルートを選べればエンジニアリングのトップは満足するべきでしょうか。それとも「実行する前に、完璧なシステムを設計するように」とチームに伝えるべきでしょうか。現在、Claude CodeのMaxプランで3回のプロンプト後にブロックされてパニックになっている人がいるように、データセンターのキャパシティを構築する方法を見つけるまで、これは非常にリアルな問題になります。
それはまた別の問題ですね。キャパシティが増えれば価格は下がりますし、今の価格は限られたキャパシティに基づいているだけです。これは最終的に解決される問題です。今週トークンをもらえない17人を誰にするか、昼休みの列に並ぶたびにトークンカードに穴を開けるような状況で決断を迫られている人たちには同情しますよ。
でも間違いなく、これはすべて消え去る問題です。
10年単位の枠組みではね。
消え去る最大の理由は、ベニオフ的な計算をしなければならないからです。エンタープライズの営業担当者に年間100万ドルを支払っているなら、そのツールの価値はいくらかを問わなければなりません。
ええ。
エンジニアに年間Xドルを支払っているなら、ある時点でそのツールの価値は…
絶対にそれに見合う価値があります。
もはや問題にすらならなくなります。
ええ、ええ。
短期的なキャパシティの問題があるにせよ、それは価格を押し上げる別の問題であって、永遠に予算編成の課題に縛られ続けるわけではありません。
大数の法則がこれを解決すると思います。最終的には十分な数のエンジニアがいて、十分な計算能力を使うようになります。私たちは今移行期にあり、多くの人が2年前のAIへの支出レベル、つまりチャットボット程度で考えていましたから。
ええ、でも彼らは間違っていました。
彼らは間違っていました。警告はしたんですけどね。
彼らが間違っていたのは、AIを特定のユースケースとして見ていたからです。あなたがからかった真空管の例ですが、ダコタ州全体が真空管の倉庫で覆われ、第二次世界大戦を戦うためにローラースケートを履いた人々が通路を走り回って真空管を交換する時代が来ると考えられていた時期がありました。それが当時の考えだったんです。
そこに誰かが「トランジスタはどうだい？」と言い出した。私たちも、このすべてにおいて「トランジスタの瞬間」を迎えることになります。単に供給が増えるというだけでなく、アルゴリズムの根本的な変化やハードウェアの変化かもしれません。この特定の瞬間を変えるような様々なことが起こり得ます。
誰もが「トークン」という単位に執着しているのは特に奇妙だと思います。IBMとメインフレームの時と同じです。当時はMIPSで取引されていましたが、ある日IBMが年々低価格でより多くのMIPSを販売していることに気づきました。彼らは自分たちがどれだけ速くMIPSを作れるかに気づかず、依然としてMIPS単位でメインフレームの価格設定をしていたんです。
それが間違いなく起こるでしょう。
いいですね。
今、かなりハードコアに言い切りましたね。
素晴らしい。自分が何を作っているか分かっているように聞こえますからね。
間違いありませんよ。
実際のところ、私もおそらくそう信じています。
コメント