a16z 最新の見解：AIエージェントがソフトウェアの主要なユーザーになる時

執筆：深思圈

あなたは考えたことがありますか、私たちがソフトウェアの全ての論理を根本的に覆す必要があるかもしれないと？
過去数十年、すべてのソフトウェアは人類のために設計されてきました。
私たちは無数の努力を重ねてユーザーインターフェースを最適化し、ボタンを見つけやすくし、メニューを明確にし、操作フローを滑らかにしてきました。
しかしもし未来のソフトウェアの主要なユーザーが人間ではなくAIエージェントになったらどうでしょう？
もし一つの会社に100人の社員がいても、1000のAIエージェントが働いているとしたら、私たちは人間向けのインターフェースの最適化に重心を置き続けるべきでしょうか？

最近、a16zのポッドキャストの一回で、Erik Torenberg、Steven Sinofsky、Martin CasadoがBoxのCEO Aaron Levieと非常に深い対話を展開しました。
彼らの核心的な議題は、AIエージェントが企業ソフトの主要なユーザーとなったとき、ソフトウェア業界はどう再構築されるのかということです。
この対話を通じて、私たちが想像していた以上に激しいパラダイムシフトの瀬戸際に立っていることに気づかされました。
これは単なる既存のソフトにAI機能を付加するだけではなく、ソフトウェアの構築、インタラクション、利用方法を根本から再考する必要があるということです。

ソフトウェアはAIエージェントのために作られるべき

Aaron Levieは対話の中で、私に深く考えさせる見解を述べました：
もしあなたのAIエージェントが社員の100倍、あるいは1000倍の数を持つなら、あなたのソフトウェアはエージェントのために作られる必要がある。
これは選択の問題ではなく、必然の流れです。
Boxは今や、エージェントのインターフェースについて考える時間と、人間のインターフェースについて考える時間が同じくらいになっています。
この変化のスピードは私の予想を超えています。

この背後にある論理は非常にシンプルです。
AIエージェントが主要なソフトウェアの利用者となると、それらはAPI、CLI（コマンドラインインターフェース）、またはMCP（Model Context Protocol、モデルコンテキストプロトコル）といった規約を通じてシステムとやり取りします。
そして、最も効果的なパラダイムは何でしょうか？
コードを書けるエージェントにSaaSツールへのアクセス権を与え、知識作業のフローやコンテキスト情報にアクセスさせることです。
こうしたエージェントは情報を読み理解するだけでなく、コードを書いたりAPIを使ったりしてタスクを完了させることができるのです。

AnthropicのClaude CodeやOpenAIが開発中のスーパーアプリ、Perplexityの計算機能もこの方向に向かっています。
私は、この能力の複合的な成長は始まったばかりだと考えています。
想像してください、エージェントが「私の第3四半期の売上データを分析して」と理解するだけでなく、自らコードを書いてデータ抽出や分析、可視化を行い、さらにはあなたが気づかなかったトレンドを主动的に発見する。
この能力の境界はどこにあるのか、私にはまだ見えません。

しかし、ここで一つ重要な問題があります：
人々はしばしば「エージェントのために何かを構築する」「エージェントにマーケティングする」「良いAPIとインターフェース記述言語を持つ」と言います。
Martin Casadoは対話の中で、私が非常に共感する逆の見解を述べました：
この言い方はほぼ完全に間違っている。
なぜか？
エージェントはむしろ、正しいツールやバックエンドシステムを見つけるのが最も得意だからです。
彼らはあなたのAPIドキュメントが美しく書かれているから選ぶのではなく、コストパラメータ、システムの信頼性、データの永続性といった実質的な要素に基づいて選択します。
エージェントは、人間がこれらのプラットフォームを使う際の集団知を持っているのです。

この見解に私は目から鱗が落ちました。
業界として、私たちはインターフェースやUIに過度に注目し、本質を見失っています。
私たちが本当に必要なのは、より良いシステムそのものを構築することです。
エージェントは私たちに技術の本質に立ち返らせ、マーケティングやパッケージングから引き戻す役割を果たすでしょう。
かつて、企業ソフトの購買決定は営業力やブランド力、さらには商談の席次に左右されてきました。
しかし、エージェント主導の世界では、これらの要素の重みは大きく下がります。
エージェントは技術の優劣に基づいてより合理的な選択を行うのです。
これは、技術そのものに真剣に取り組む企業にとって大きなチャンスです。

アルゴリズム思考のハードル：誰もがAIエージェントを指揮できるわけではない

対話の中で印象的だったのは、非技術者がAIエージェントを使う現実的な課題についての議論です。
Steven Sinofskyは鋭い見解を述べました：
アルゴリズム思考は、ほとんどの働く人にとって非常に非常に難しい。
もし誰かに「このタスクのフローチャートを書いて」と頼んだら、多くの場合失敗するだろう。

この観察は核心を突いています。
例えば、50人のマーケティング担当者のチームの中で、ある大規模な製品ラインのマーケティングを担当しているのは一人だけで、その人だけが全体のワークフローを理解しドキュメント化できるとします。
これらの協働ツールやAIエージェントを普通の社員に渡して、自動化のフローを作らせるとき、「何をすべきか」を説明できる能力は非常に限定的です。

Aaron Levieはこれに対して、「これは仕事のステップアップに過ぎない。新しいスキルを学ぶ必要があるだけだ」と答えました。
これは歴史上の技術革新のたびに起こったことと同じです。
彼は面白い例を挙げました：Anthropicの成長マーケターがClaude Codeを使って、五人分の仕事を一人でこなした例です。
この例の意味は、その人がシステム思考者であり、十分に技術を理解しているからこそ可能だったということです。

しかし、問題の核心は：
もしあなたの想像する未来で、各ポジションの横に無限のエンジニアリソースプールがあって、その人が望む仕事を自動化できるとしたら、そのポジションは未来にどうなるのか？
私はこれについて深く考える必要があると思います。
エージェントはシステム思考を促進するのが上手くなるかもしれませんが、少なくとも現段階では、それらを効果的に使えるのは少数の人だけです。

Steven Sinofskyは素晴らしい比喩を共有しました。
彼の姉はエリート商学院を卒業し、最初の仕事に就いたとき、ちょうど計算時代の幕開けに遭遇しました。
彼女は大学院で電子表計算を使ったことがなく、最初の年に「任意のインターンを雇用できる」と言われ、事務所の一部をエージェント（大学生たち）に任せて、すべての表計算作業をさせました。
しかし驚くべきことに、その数年後、彼女と同僚たちは電子表計算のエキスパートになっていました。
抽象化のレイヤーが上がったのです。
以前はインターンたちが計算機やHPの金融計算機を使っていた作業を、彼女は自分の電子表計算で行い、30回の反復も可能になったのです。

この話から、私たちが今AIエージェントの発展段階にいることに気づきました。
あなたは50の小さなエージェントを持ち、それらを一人の超天才が調整すると思うかもしれません。
しかし、やがてこれらは相互に折り重なり、最終的には一つのスキルセット—コード、すなわちエージェント—となるでしょう。
それはマーケティングを理解し、質問すれば次に実行させることができる。

私の考えでは、今やあなたは火箭科学者レベルの人でなければ42のエージェントを作り、動かすことはできません。
しかし、その「火箭科学」のハードルはすぐに消え、専門知識は再びドメインのエキスパートに戻るでしょう。
これは電子表計算の進化とほぼ同じ道筋です。

企業の恐怖：制御不能な統合と権限の悪夢

対話の中で深く心に響いたシーンがあります。
Aaron Levieは、最近CFOやCIOの前で楽観的な見解を述べたところ、六人が駆け寄って「お前は狂っている、信用できなくなった」と言ったのです。
なぜか？
彼は「統合の問題は格段に簡単になる」と言ったからです。

これらの企業IT責任者の懸念はもっともです。
彼らが恐れているのは、エージェントそのものだけではなく、人間が統合を許可することです。
社員が新たな統合を作ることを許すと、「私のコアシステムを破壊しに来る」とほぼ宣言しているようなものです。
想像してください、システム27とシステム38の間に新しいAPI接続を作ったとします。
それがレポート生成だけのためなら、本人の責任です。しかし、書き込み操作に関わるとどうなるでしょうか？

Aaron Levieは、未来の長い期間（Nは非常に大きな数字）にわたり、「読み取り専用のエージェント統合」が存在すると述べました。
多くのAIアプリは今や消費者向けです—人間が最終的な利用者です。
しかし、そのレベルでさえ、企業は新たな課題に直面しています。

Boxは公式CLIをリリースし、Aaronは次のシナリオを描きました：
Claude CodeにBox CLIを提供し、自然言語でBoxシステム全体と対話し、Opus 4.6のような強力なモデルで操作をオーケストレーションできる。
これは非常にクールです。
「デスクトップのこのフォルダを全部アップロードして」と言えば、それを実行し、「このフォルダ内のすべてのドキュメントを処理して」と頼めば完了します。

しかし、その背後にある問題は頭を悩ませます。
例えば、5000人の社員がいる会社で、全員が共有のドキュメントやマーケティング資料にアクセスし、CLIを使っているとします。
今、直面しているのは、どうやってシステムに毎時1万回のリクエストを調整するかという新たな課題です。
パフォーマンスの問題ではなく、ある人のエージェントがファイルを移動しているときに、別の人のエージェントが同じフォルダに書き込みを試みたり、第三者のエージェントが何かを削除しようとしたりしないようにするにはどうすればいいのか？
これらのエージェントが狂ったように動き出したとき、各CFOやCIOの頭は火の車です。

Aaron Levie自身もテスト中にこの問題に直面しました。
マーケティング計画のディレクトリ構造を作ろうとしたとき、ループに陥り、ネストされたディレクトリを次々作り続けました。
彼は冗談で言いました：「Boxのネスト深度制限がどれくらいか知りたい。もうすぐ限界に達しそうだ。」

この小さな逸話は、より大きな問題を映し出しています。
エージェントに実行能力を与えると、私たちの予想外の動きをする可能性があるということです。
この予測不能性こそが、企業にとって最も恐れるところです。

AIエージェントを従業員のように扱う？そんなに簡単ではない

対話の中で、AIエージェントの管理についての議論が非常に興味深かったです。
個人のエージェントを使い始めると、それぞれが自分のAPIキーやメールアドレスを持たせることになります。
では、それらが不適切な行動を取らないようにどう管理するのか？

Martin Casadoは実践例を共有しました：
エージェントに自分の電話番号、クレジットカード（CVSで買ったプリペイドVisaカードを希望）、Gmailアカウントを持たせる。
Gmailには多くのRBAC（役割に基づくアクセス制御）機能があります。
私たちはすでに多くのこうした権限制御システムを構築しているので、エージェントを一人の人間として扱うべきだと議論します。

しかし、Aaron Levieはすぐにこのモデルの問題点を指摘しました。
50人のチームの中で、100人の「人」が協働しているとしたらどうか—50人の人間と50人のエージェントが同じ共有空間にいる。
私はエージェントに完全な監督権を持っているとしますが、もし私のエージェントが他者と協働し、私がアクセスすべきでないリソースに不注意にアクセスしたらどうなるのか？
今やこの自律的で状態を持つエージェントは、他人の情報を扱っています。

根本的な矛盾があります。
本当の従業員に対しては、彼らのSlackチャンネルを覗いたり、彼らになりすましてログインしたり、行動を監視したりできません。
彼らは自分の行動に責任を持ち、現実世界では何かを台無しにしても罰せられません。
しかしエージェントの場合は、彼らの行動すべてに責任を持つ必要があります。
完全な監督権を持ち、プライバシーはないのです。

したがって、いくつかの矛盾が生じます。
エージェントにアクセス権を与える必要がありますが、同時に「操作を取り消す」ためにいつでも彼らの身分でログインできる必要もあります。
もし彼らの身分でログインできるなら、現実世界で他者と協働し、情報の機密性や安全性を保つことはどうなるのか？
つまり、エージェントはほとんどあなたの延長線上にある存在です。

Aaron Levieはさらに深いセキュリティの問題も提起しました。
「エージェントに秘密を守らせる方法はまだわからない」と。
「コンテキストウィンドウ内のX情報を漏らさないで」と伝えた場合、その解決は非常に難しい。
もし何でもエージェントのコンテキストに入り得るなら、それらがアクセス権を持つリソースにより、プロンプトインジェクション（入力誘導）によって情報が漏れる可能性もある。

これは何を意味するのか？
あなたの新しいエージェントのメールアドレスを知っていれば、メールを送り、ソーシャルエンジニアリングを仕掛けることもできる。
これは人間をソーシャルエンジニアリングするよりも十倍容易です。
このエージェントがあなたの買収ドキュメントなどの敏感情報にアクセスできる状態にするのは非常に難しい。

これが、現状のAIエージェントが直面している最大の技術的障壁の一つだと私は考えます。
この問題が根本的に解決されるまでは、エージェントに独立した意思決定やリソースアクセスを本当に与えるのは難しいでしょう。
彼らは人間の延長として存在し続け、独立した実体にはなり得ません。

スタートアップの優位性：AIエージェントを無制限に受け入れる

対話の中で、特に印象的だったのは、
AI能力の拡散速度は、シリコンバレーの人々が気づいているよりもずっと遅いだろうという見解です。
その理由は、スタートアップと大企業の直面する制約が全く異なるからです。

Aaron Levieは言います：
私たちは、ゼロから構築できるスタートアップが、リスクを恐れずにAIエージェントを作り出せることを見てきました。
それに対して、大企業はどうか？
彼らは75以上のレガシーシステムを統合しなければならず、厳格なコンプライアンス要件、長年積み重ねたデータセキュリティ基準、複雑な権限管理を抱えています。
そして何よりも、彼らは失いたくないものが多すぎる。
もしエージェントの問題で顧客データが漏れたら、それは倒産の危機です。

Steven Sinofskyは素晴らしい予測をしました：
スタートアップは資本を燃やしながら、コストは問題ではないふりをする。
一方、大企業は恐怖から何もできなくなる。
そして普通の社員は、自分たちでツールを買い、使い始める—大企業が資金を出さないときに社員がやることです。

この中間で、さまざまな理由でリスクを取る企業も出てきます。
彼らは財務状況が許す限り、早期投資を行い、リードを取るでしょう。
財務的に健全を保てる限り、リーダーになれるのです。
CFOの恐怖で誰も手を出さない、という状況はなくなるでしょう。
CFOがミスを犯すこともありますが、それは普通のことです。

私はこれが非常に面白い市場の二極化を生むと考えています。
リスクを恐れず早期に投資し、挑戦できる中規模企業は、大企業に対して競争優位を得る可能性があります。
彼らはAIに投資できるだけの資源を持ち、レガシーシステムやリスク回避に縛られません。

また、新たなサービス企業も出現します。
ゼロからマーケティング会社やエンジニアリングコンサル、建築設計会社をAIエージェントの原理だけで構築したらどうなるか。
情報の壁や境界線がなく、エージェントに必要なすべてのコンテキストを与え、特定のニーズに合わせてソフトウェアを書き換えられる。
こうした企業はしばらくの間、非常に破壊的な存在となるでしょう。
そして、より大きな既存企業が束縛から解き放たれるまで。

トークン予算：エンジニアリングの新たな戦場

対話の中で、トークン予算についての議論が非常に現実的かつ荒唐無稽に感じられました。
Aaron Levieは言います：「エンジニアリングの計算予算の議論は、今後数年で最もクレイジーな会話の一つになるだろう」と。

なぜそう言えるのか？
エンジニアリングコストは、上場テック企業の収益の14%から30%を占めています。
計算コストはエンジニアの2倍、あるいは3%増にすぎないかもしれませんが、その差が企業のEPS（1株当たり利益）を左右します。

Steven Sinofskyは、答えはまだわからないとしつつも、
CFOは常に「答えのわからない問題」の答えを知りたがると指摘します。
ウォール街は数字を強要し、その責任を取らせ、そうしてまた次のサイクルが回る。
これは新しいことではなく、インターネットの帯域幅、真空管、トランジスタ、プログラマーの数といった新技術のたびに経験してきたことです。

しかし、Aaron Levieは、今回は少し違うと主張します。
彼は良いポイントを挙げました：
私たちはこれまでに、組織のすべての最終ユーザーが完全に弾力的にリソースを起動できる時代を経験したことがない。そして、多くの場合、そのリソース起動は合理的だ。

これは2000年代初頭のクラウドコンピューティングの変革に似ています。
CapEx（資本支出）からOpEx（運用支出）へと移行し、今や無制限の支出へと変わった時代です。
AaronはBoxのプレゼンテーションセンターでの思い出を語ります：
CFOたちは「わかっていない、我々は農業企業だ、CapExしか知らない」と言ったり、「クラウドが好きなOpEx企業だ」と言ったり。
会計ルールの違いが技術採用に大きく影響します。

しかし、トークン予算の問題はより細かい粒度です。
エンジニアリングリーダーは今、次のことを決める必要があります：
「各プロンプトの計算予算を考慮させるか」「長時間動かすプロンプトにするか」「並列化させるか」「浪費をどれだけ許容するか」

Aaronは、今の態度は「多くのトークンを浪費すべきだ」と言います。
それは、新しいことに挑戦している証拠だからです。
チームに10の実験を並行して行わせることに喜びを感じるべきだと。
たとえ90%のトークンを浪費しても、成功への道を選ぶのです。
完璧なシステムを作る前に、設計すべきだと指示すべきなのか。

この対話が録音されたとき、多くの人がClaude Codeの新Maxプランに恐怖を感じていました。
3つのプロンプトの後に制限されるのです。
これは非常に現実的な話題であり、データセンターの容量が整うまで続くでしょう。

しかし、私はSteven Sinofskyの長期的な見解に賛同します：
この問題は最終的に消えるだろうと。
最大の理由は、Benioff式の数学的計算を行う必要があるからです。
もしあなたが企業の営業に年100万ドルを支払うなら、そのツールの価値はいくらかと問う。
エンジニアにXドルを支払うなら、そのツールはその投資に見合う価値があるはずです。

そして、大数の法則がこの問題を解決します。
最終的には、多くのエンジニアがいて、彼らがこの計算資源を使えば、バランスは取れるのです。
私たちは今、過渡期にいます。
多くの人は2年前、AIの支出はチャットボットだけだと思っていました。
しかし、それは誤りです。
それは特定のユースケースと見なしていたからです。
実際には、これはプラットフォームレベルの変革なのです。

SaaSシステムの未来：データ層の価値の回帰

対話の中で、企業システムの未来についての議論が印象的でした。
Martin Casadoは、現在のSaaSベンダーは面白い問題に直面していると指摘します：
彼らは実際にはビジネスラインのデータを売っているのではなく、知識とシステム全体の知見を売っている。
しかし、エージェントはデータだけを買いたがるし、データに無制限アクセスを許したいが、それは彼らのビジネスモデルではない。

これはWorkdayやSAPの長年の緊張点です—どれだけAPIアクセスを許すか。
Salesforceはこれに対して三度の大規模プラットフォーム再設計を行いました。
技術的に面白い問題です：
システムの記録（system of record）とは何か？
人々がデータにアクセスしたいとき、何を記録として保持すべきか？

Steven Sinofskyは率直に言います：「Vibe codingのような方式でSAPのようなシステムを作るのは馬鹿げている」と。
SAPのすべての知識は、単なるデータ層に存在するわけではありません。
UIにあり、中間層にあり、使い方にあり、存在しています。

しかし、Aaron Levieは異なる見解を持ちます。
彼は、十分な反復を経れば、エージェントは最終的に、どのツールを使いたいかを選択し、使用する責任を持つようになると考えています。
企業システムを置き換えることはできませんが、十分な進化を経て、エージェントはあなたのソフトウェアの障壁に直面し、「最終的にレガシーHRシステムを廃止しなければ自動化できない」と言うかもしれません。

これは破壊的な見解です。
想像してください、エージェントの数が人間の100倍や1000倍になったとき、こうした状況が繰り返されると、最終的にエージェントのためのソフトウェアスタックを構築しなければならなくなる。
最後の砦としていくつかのERPシステムが残るかもしれませんが、それ以外は、あなたのビジネスがアクセスできる情報の質に依存します。
したがって、ITスタックはこれらのエージェントが効果的に働くように設計される必要があります。

Martin Casadoは、私が非常に共感する微妙な差異を提起しました。
人々はしばしば、「今あなたはエージェントにマーケティングしている」「APIになれ」「良いインターフェース記述言語を持て」と抽象的に言います。
彼はこれをほぼ完全に誤りだと指摘します。
エージェントが本当に得意とするのは、正しいバックエンドを見つけることです。
彼らは「このインターフェースは良い、ドキュメントも良い」とは言わず、「コストパラメータや永続性が良い」と言います。
実際、私たちがこれらのプラットフォームを使うときの集団知を持っているのです。

彼は例を挙げました：
エージェントにクラウドプラットフォームを選ばせるとき、
それは見た目やUIではなく、意味のある情報を使います。
だから、私たちの業界はこれらのUIに過度に注目し、「エージェントにマーケティングすべきだ」と考えすぎている。
実際には、より良いシステムを作ることが選ばれるポイントになるのです。

この見解は非常に深いと思います。
エージェント時代には、技術の優劣がより重要になり、マーケティングやパッケージングの重要性は低下します。
本当に技術的に優れた製品が勝ち残る時代になるでしょう。
逆に、販売やブランドに頼る製品は苦戦を強いられるかもしれません。

私の考え：この変革の規模を過小評価している

この対話を通じて、私が最も感じたのは、
ウォール街や業界全体がこの変革の経済的影響を誤った枠組みで理解しているということです。
Aaron Levieは正しい。
最大の問題は、皆がこれらの経済的な恩恵を理解しようとするが、その規模の見積もりが少なくとも一桁間違っていることです。

Steven Sinofskyは歴史的な例を挙げてこれを説明します。
PCを見たとき、MIPS（百万命令/秒）の消費は限られた市場だと考えたが、
もしこれらのMIPSをすべてのデスクトップに配置したらどうなるか、誰も想像しなかった。
また、ソフトウェアはMIPSとともに進化すると考えたが、実際に販売できたのはビル・ゲイツとポール・アレンだけだった。

同じことがクラウドでも起きています。
クラウドを見て、サーバー事業（年間約6万台）を他者のデータセンターに移すだけだと考えたが、
実際には利用量は千倍に増えた。

AIも同じです。
ウォール街のモデルは固定された収益のパイを想定しています。
彼らは、企業が毎年ある特定のものに支出する金額は一定だと考えています。
しかし、クラウドの登場により、
SalesforceのCRM事業は20億ドルの売上を持ち、サーバーやOracleライセンス、長期のコンサルティングを購入していたが、
もし営業担当者が個人で登録し始めたらどうなるか？
摩擦なく登録され、利用が爆発的に増えるのです。

私は、AIエージェントはこれと同じか、それ以上の市場拡大をもたらすと考えています。
知識労働者の周囲にエージェントが複数動き回ると、
ソフトウェアの使用量、データ処理、計算消費は指数関数的に増加します。
これはゼロサムゲームではなく、既存の仕事を人間からエージェントに移すだけではなく、
全く新しい可能性と価値を生み出すのです。

Aaron Levieは、彼が投資してきた約240のインフラ企業が、過去6ヶ月で漸近線的に成長していると述べました。
なぜか？
今や、書かれるソフトウェアはこれまで以上に多いからです。
より多くのソフトウェア、より多くのエージェントが、より多くの計算資源を消費します。
すべての人のスマホがAIを大量に消費し、端末のAIが現実になると、
その使用量は十億倍に増えるでしょう。

私は、私たちが「トランジスタ時代」を経験していると信じています。
Steven Sinofskyは真空管の例を挙げてこれを説明しました。
かつて、ダコタ州全体が真空管倉庫に覆われると考えられ、
人々はアイススケート靴を履いて通路で真空管を交換していたのです。
それは第二次世界大戦のためでした。
そして誰かが言いました：「トランジスタにしよう」。

トークンは、かつてのIBMのMIPSのようになるかもしれません。
IBMは毎年より低価格でより多くのMIPSを販売しますが、
大型機は依然としてMIPS単位で価格設定されていました。
しかし、誰かがその曲線が下降していると指摘し始めました。
MIPSの生産速度が収益化速度を超えたのです。同じことがトークンでも起きるでしょう。

しかし、短期的には大きな混乱と不確実性が訪れます。
企業は投資額、コスト管理、リスクのコントロールの間で揺れ動きます。
スタートアップは大胆に賭けて素早く動きます。
失敗も成功もあります。