The a16z Show 解説: エージェント時代のソフトウェアと「ヘッドレス化」の本質（ゲスト: Sema Amble氏, Steven Sinofsky氏）
▶ 元動画: https://www.youtube.com/watch?v=Mxs4erDxOEE
2026年7月7日
概要
本エピソードは、a16zのエンタープライズ・チームのパートナーであるSema Amble氏と、同社のボードパートナーで元Microsoft幹部のSteven Sinofsky氏を迎え、Sema氏が執筆した「Is Software Losing Its Head?（ソフトウェアはその頭を失いつつあるのか）」という記事をきっかけに、AIエージェント時代のソフトウェアのあり方を議論した対談です。数ヶ月前にSalesforce($CRM)が「ヘッドレス」化を発表したことを起点に、UI(ユーザー・インターフェース)を介さずにエージェントがソフトウェアのデータやロジックに直接アクセスする世界がどんな意味を持つのかを掘り下げています。
議論の核心は、「ソフトウェアの価値はUIの上ではなく、その下にあるデータとビジネスロジックに宿る」という点にあります。Salesforceの「Headless 360」発表自体は、既存のAPIを再ブランドしただけで実質的な変化は乏しいものの、エージェントがシステム・オブ・レコード(記録の中核となるシステム)にどうアクセスするかという大きな潮流を象徴していると指摘されます。
さらに議論は、SAP($SAP)のような「究極の粘着性を持つソフトウェア」がなぜ簡単には置き換えられないのか、そしてエンタープライズ・ソフトウェアの本質が「例外処理(exception handling)」と、社員の頭の中にしか存在しない「コンテキスト」にあることへと展開します。「Postgresデータベースとの組み合わせでSAPを置き換えられる」という発想がいかに誤解であるかが強調されます。
最後に、この技術シフトの中でスタートアップにとっての最大の機会がどこにあるのか――既存カテゴリーに正面から挑むのではなく、「二つの既存プレイヤーの中間」を新しいやり方で狙うことの重要性が語られます。
ヘッドレス・ソフトウェアとは何か
Sema氏によれば、「ヘッドレス・ソフトウェア」という言葉自体は新しいものではありませんが、AIの文脈で急速に注目を集めるようになりました。従来のソフトウェアは「人間がアクセスすること」を前提に構築され、ワークフローを通じてデータを収集する設計になっていました。しかしエージェント時代においては、エージェントはUIを介してソフトウェアにアクセスしないため、UIそのものの重要性が問われることになります。
「ヘッドレス」であることの本質は、UIというワークフローの層ではなく、その下に蓄積されたデータ・ロジック・情報こそが価値の中心だという認識にあります。頭(ヘッド=UI)を失っても、価値はその下に残るというわけです。
Salesforceの文脈に限って言えば、Sema氏は「実質的には何も変わっていない」と見ています。同社の「360」プロダクトは、以前から公開されていたAPIをそのまま再ブランドしたものに過ぎず、APIはずっと前から存在していたからです。ただし、より広い潮流として、エージェントがCRM(顧客関係管理)のデータにアクセスする際、UI経由ではなくAPI経由で行う世界に向けて、各社が自社をどう作り替えるかを考え始めている点は重要だと指摘します。
より分かりやすい例としてSema氏はNotionを挙げます。Notionのユーザーはより技術に長けており、自らエージェントを構築する傾向が強いため、ヘッドレス・プロダクトを提供する意味がより大きいというわけです。
エージェントが「する」三つの動作
Sinofsky氏は、まず「定義の地獄(definitional hell)」にいる現状を軽妙に指摘します。「エージェント」という言葉は、今のところ「非常に長い時間かかって、しかも終わらないかもしれないプログラム」を指す新しい呼び名に過ぎず、昔なら「バグ」と呼んでいたものが「最高にクールな新機能」として売り出されている、と皮肉ります。
その上で、エージェントとAPIの違いを本質的に理解するには、「エージェントが実際に何をしているのか」を見るべきだと述べます。Sinofsky氏はこれを三つに分類します。
一つ目は「参照(look up)」。何かを調べるだけの軽い動作で、あらゆるシステムが得意とするものです。新たに発表されている「ヘッドレス・エージェントAPI」の多くは、実際にはこの参照機能に過ぎず、古い調べ方に新しいインターフェースを被せただけだと指摘します。
二つ目は「実行(do)」。何かを変更する動作で、ここには複雑な問題が伴います。特定の人物になりすます必要があり、その人の認証情報が必要になり、それが有料の別枠なのか同じ枠なのかといった、エンタープライズ・ソフトウェア特有の課題が一気に浮上します。
三つ目は「分析(analyze)」。複数のシステムをまたいで大量の情報を調べ上げる動作で、時間の制約がなく、異なるモデルに振り分けて答えを比較できるため、エージェントに非常に向いています。ただし、分析の各ステップが正しかったかを検証する手段が必要であり、ハルシネーション(AIがもっともらしい誤りを生成すること)が深刻な問題になる領域でもあります。
ソフトウェアの粘着性を生むもの
歴史的に何がソフトウェアを「粘着的(sticky)」にしてきたのか、という問いに対し、Sema氏は多くの要因が「人間の使い方」を中心に構築されていた点にあると答えます。UI、アクセス頻度、下流のワークフロー、SOP(Standard Operating Procedure=標準業務手順)といった、ソフトウェアの周辺で起きて筋肉記憶やプロセスに刷り込まれた事柄すべてが粘着性を生んできました。
さらに、組織には「単一の真実(single source of truth)」が必要であるという点も重要です。ERP(Enterprise Resource Planning=統合基幹業務システム)や給与計算のように、法的・コンプライアンス上の理由から、数値を正確に一箇所で追跡しなければならないケースも多く、これが粘着性と持続性を高めてきました。
Sinofsky氏はこれに、最も粘着的なのは「顧客から実際にお金を集めているソフトウェア」だと付け加えます。お金を払い続ける流れは止めるのが難しく、止めた場合どうすればいいか分からなくなるからです。粘着性の理由は誰に聞くかで変わり、コンプライアンス担当者、管理者、ユーザーそれぞれが違う答えを返します。Microsoft Outlookをメールから置き換えようとした人は皆、代理アクセスや複数人が所有するカレンダーといった、誰も設計会議で意図していなかった機能の粘着性を思い知ることになった、という逸話を語ります。
SAPという「究極の粘着性」
議論はSAPへと移ります。Sinofsky氏は、SAPよりも粘着的なソフトウェアは、保険会社が50年から75年前に書いた裏側のシステムくらいしかない、と述べます。Stripe($非上場)の最大の成功も、世界中の税法・管轄区域・通貨交換をまとめ上げ、二世代ぶりに「人からお金を集めるソフトウェア」を初めてコード化した点にあると評価します。
SAPが粘着的なのは、それが単に企業に使われているからではなく、企業のビジネスルールそのものを製品の中にコード化しているからです。大手自動車メーカーからSAPを取り除けば、自動車メーカーは消えてしまう。会社を定義しているのはソフトウェアの購入や使用ではなく、業務ルールをその製品に落とし込んだこと自体だ、というわけです。
Sema氏はここを深掘りします。現在の誤解は「PostgresデータベースとAPIがあればSAPを置き換えられる」というものですが、これは全くの誤りだと断言します。SAPに封じ込められたロジックこそが、「たまたまデータがこのデータベースに入っている」という事実よりもはるかに重要なのです。SAPの導入に数年かかるのは、システムインテグレーターが遅いからだけでなく、そのビジネスの実際の運営方法に合わせてカスタマイズされているからだと説明します。
例外処理こそがエンタープライズの本質
Sinofsky氏は、1990年代後半にOracle($ORCL)のLarry Ellison氏が「企業ソフトウェアは皆がカスタマイズするから愚かだ」「企業は80%の解決策で満足すべきだ」と長年主張していたことを振り返ります。しかし現実にはそうはならなかった、と指摘します。
自動車業界を例に、上位10社はどこも車を作っているものの、各社を差別化するのは「どう運営するか」「どの車をいくつ作るか」「どの通貨をヘッジするか」といった内部プロセスであり、それらはすべてSAPの中にある、と述べます。フォード($F)、Toyota($TM)、General Motors($GM)、Daimlerの違いは、同じ画面を見ているかではなく、どの画面を見るか、どのカスタマイズを選ぶかにあるのです。
さらにSinofsky氏は、Goldman Sachs($GS)の逸話を紹介します。かつてExcelを売り込みに行った際、Goldmanの担当者が「あなたたちより我々の方がExcelで稼いでいる」と言い、意味が分からなかったといいます。つまりGoldmanは、アドインを作り、コードを書き、独自の適用方法によってExcelを徹底的に差別化していたのです。「Vibe Coding(自分ではコードを書かずAIに指示して開発するスタイル)でエンタープライズ・ソフトウェアに到達できる」という発想は、この深さを著しく過小評価していると警告します。
Sema氏も、ある1000人超の企業のRevOps責任者が「フィールドは分かっているしデータもインポートできる」とSalesforceの内製再構築を語っていた例を挙げ、「難しいのはそこではない」と指摘します。何を捕捉するか、組織のルールをどう引くか、そして誰がそれを長期的に保守するのか――この点が抜け落ちてしまうのです。
AIが今できること――使いやすさの層
現在AIが最も使われているのは、SAPのようなシステムの情報を「会話的」に取り出し、より使いやすくする用途だとSema氏は述べます。SQLクエリを書いたり複数の画面を見たりせずに、自然言語で複数地域のテーブルを横断的に問い合わせたり、自分向けにカスタマイズされたレポートを自動生成したりする「使いやすさの層」です。
Sinofsky氏は、エンタープライズ・ソフトウェアで最も頻繁に使われる二つの機能――「Excelへのエクスポート」と「CSVあるいはPDFへのエクスポート」――は、どのエンタープライズ・ソフトウェアにも本来存在しない機能だという逆説を語ります。これらは、ソフトウェアが本来できないことをやるための「脱出弁」でした。言語モデルの登場により、20個のPDFをモデルに投入して、これまでコピー&ペーストの単純作業でしかできなかった分析を、はるかに容易に行えるようになったのです。
そして、こうした「その場限りのビジネスプロセス(ad hoc business processes)」こそが、次のプロダクト、次の会社の種になると指摘します。CRMもかつては単なるスプレッドシートで、SalesforceではなくSiebelがそれを最初に製品化しました。今見られる「SAPやSalesforceにチャットで話しかける」アプリは、言語モデルが得意とする「非構造化情報の統合とオーケストレーション」を活かそうとしているのです。
コンテキストと例外処理の壁
Sema氏は、Salesforceがゴー・トゥー・マーケット(市場開拓)チームにとっての「強制メカニズム」でもあると指摘します。必要な情報をすべて収集しているかを担保する仕組みです。エージェント時代には、アウトバウンドの架電やメッセージを行うエージェントがその情報を取得する必要がありますが、それに加えて必要になるのが「コンテキスト」です。
このコンテキストとは、例外・エッジケース・権限設定・各種ポリシーといった、Salesforceのフィールドには入っていない、誰かの頭の中にある情報のことです。「アジアの人にはこう対応するが、米国の人には別の対応をする」といった判断は、Salesforceには記録されていません。エージェントがこのデータの代理として動くには、このコンテキストが不可欠だと述べます。
Sinofsky氏も、営業担当者はどんな案件でもデフォルトが正解だとは決して思わない、と同意します。エンタープライズにおいて面白いことはほぼすべて「例外」であり、自動化とは結局のところ例外処理に他ならない、と断言します。McDonald's($MCD)のキオスクで注文を諦めて店員に頼む人を15分観察すれば分かる、というたとえを挙げ、エンタープライズの価格設定が「お問い合わせください」から始まるのも例外の典型だと語ります。
Amazonが示す例外処理の新しい形
Sinofsky氏は、Amazon($AMZN)が例外処理において最良の仕事をしていると評価します。Amazonは人間を介在させたくないという信念のもと、「顧客に有利に判断する」という中核原則を持っています。間違った商品が届いたとチャットボットに伝えれば、それだけで新しい商品が送られてくる。そして、そのデータを使って内部の配送・倉庫プロセスを改善していくのです。
Sinofsky氏は、この1.0バージョンを経た後、人々がAIに判断を任せることに慣れる新しいバージョンが訪れると予測します。AIが企業に予測可能性と再現性という価値を加えていることに気づくからです。ただし短期的には、これまで顧客に有利に自動判断されていたことが止まり、顧客サービスが一時的に悪化する可能性がある、と皮肉交じりに付け加えます。
生産性は新しいシナリオを生む
Sinofsky氏は、技術シフトにおいて人々が「指数関数を理解できない」だけでなく、生産性についても同じ誤りを犯すと指摘します。人々は既存の仕事量を固定的に捉え、それをどう楽にするかだけを考え、「すべてが自動化されれば仕事がなくなる」という恐れを抱きます。しかし実際には、生産性の向上は新しいシナリオを生み出すのです。
出張管理を例に、まず何もない状態から、スプレッドシートで管理し、システムで分析できるようになると、今度はマイルの活用、最安値へのルーティング、特典目的のクレジットカード活用といった新しい「出張分析」という仕事が生まれる、と説明します。長い尾(long tail)は短くならず、別の形でむしろ長くなるのです。
Sinofsky氏は、AIへの否定的な見方はすべて「やるべき仕事が固定的で、n人とmだけのソフトウェアで済む」という発想から来ると批判します。法律を例に、契約作成が速くなれば契約書はより長く洗練され、より多くのシナリオを網羅するようになり、それがさらなる訴訟のエコシステムを生む、と述べます。放射線科医がAIを愛用しながら、放射線科医の不足が起きているという(相関であって因果ではないものの)有名な例も引き合いに出します。
すべてを記録するという発想
Sema氏は、営業担当者が実際に飛行機で移動して対面で商談を成立させる世界は残り続けると指摘します。人々はSalesforceへのデータ入力に費やす時間を減らすかもしれませんが、オンラインとオフラインの両世界で人間の仕事は続き、そこから最適化のための「データの排気(data exhaust)」が生まれ続けるのです。
Sinofsky氏はこれに関連して、オープンソースのソフトウェア開発を例に挙げます。開発で最も難しいのは「どこかで完成させること」であり、コードを変更しないという長い尾の判断にはAPIが存在しない、と述べます。決算のための帳簿締めのようなビジネスプロセスも、実は同じメンタルモデルであり、多くの人が判断し、上司に説明し、何かあれば誰が何をしたかの証跡が必要になるのです。ビジネスの本質とは、結局のところ「人々が物事を決めること」であり、ソフトウェアはそれをレベルアップし、抽象化し、変えるだけだと語ります。
Sema氏は、これは「すべてを記録すること」の最良の論拠でもあると述べます。人々が飛んで対面で商談を成立させるなら、その場で起きるすべてを常にLLM(大規模言語モデル)が捕捉できるようにする。全面的な監視社会を推奨するわけではないものの、会話の記録、メールや文書の取り込みといった形で、世界はその方向に動いていると指摘します。
Sinofsky氏は、企業内の専門知識こそが現代最大の未活用資源だと述べ、Box($BOX)のAaron Levy氏が、社内に散らばるWordやExcel文書という資産について繰り返し雄弁に語ってきたことを紹介します。どの文書が重要でどれを信じるべきかを理解することが、企業文化の一部であり、AIはその非構造化情報に本当に手を届かせる最初の技術だと評価します。
MCPと「ミドルウェア」の歴史の反復
Sinofsky氏は、昨年MCP(Model Context Protocol=モデル・コンテキスト・プロトコル)サーバーの台頭に反応して書いた論考に触れ、これをかつてMicrosoftが司法省から受けた訴訟における「ミドルウェア」の議論と重ねて論じます。
MCPをめぐる状況の本質は、それが「エンジニアが考える良いソフトウェア・アーキテクチャ」の視点で駆動されており、現実世界がどう動きたいかという視点がほとんど反映されていない点にあると指摘します。どんなソフトウェアも、他の層によって「中抜き(disintermediate)」されたくはありません。「お前の仕事は経費精算のSQL形式を保存するだけで、あとは別のツールが分析する」と隅に追いやられたい企業など存在しないのです。それは衰退するビジネスに他ならないからです。
顧客もまた、複数のプロバイダーからシナリオを組み立てたいとは思いません。システムは最も不安定な部品と同じ安定性しか持てないため、経費精算会社が倒産すれば全体が止まってしまうからです。だからこそ、このミドルウェア層は、OSI(Open Systems Interconnection=開放型システム間相互接続)の階層図では美しく見えても、常に不安定なのです。
三つの選択肢とスタートアップの機会
Sema氏は、Salesforceやworkday($WDAY)がAPIを公開していても、実際にはすべてのデータをクリーンに抽出させないよう設計されている点を指摘します。彼らは自社を「背景の単なるデータベース」にされたくないため、そうする動機がないのです。その上で、企業の前には三つの道があると整理します。
一つ目は、Salesforceをバックエンドとして扱い、その上にエージェントを構築する道。一部はうまくいくものの、Salesforce側が「背景のデータ」でいることを望まないため、結果はまちまちになると見ています。二つ目は、完全に自前で構築する道。最も制御が効きますが、Fortune 500向けのCRMを再構築するのは膨大なビジネスロジックの捕捉を伴い、「生きた患者に開胸手術をする」ような困難を伴います。三つ目は、SAPなどと並走しながら、その上に可視化の層を重ね、既存データの上でエージェントを動かせるようにする道。音声エージェントや文書の取り込みによって新しいシステム・オブ・レコードを作り出しつつ、背景のロジックを捨てないアプローチです。
Sinofsky氏は、スタートアップにとって最も愚かなのは、既存カテゴリーに同じやり方で正面から挑むことだと述べます。技術シフトの最中、既存プレイヤーは自社の製品ラインを乱すことだけは絶対にせず、既存製品にAIを「後付け(bolt on)」して嵐をやり過ごそうとします。だからこそ機会は「二つの大手プレイヤーの中間」を、新しいやり方で狙うことにあります。正面から攻めないことで、20年前のフレームワークが生んだ無関係な要件のリストに答える必要がなくなるのです。その最良の例が、クライアント・サーバーができることを何一つ再現せず、まったく新しいやり方でその概念を実装したHTTPとHTMLだと語ります。
Sema氏は、機会は二つのレガシーベンダーの間だけでなく、組織内の二つの機能の間の「翻訳の層」にもあると付け加えます。ソフトウェアは常に営業や財務といった単一チームに売られてきましたが、その間の受け渡し(ハンドオフ)こそがコンテキストであり、そこに興味深い機会があるのです。
エンタープライズにおけるネットワーク効果
最後に、エンタープライズ・ソフトウェアでネットワーク効果が成立しうるかという問いに対し、Sinofsky氏は、コンプライアンスとセキュリティの理由から企業「外」のネットワーク効果は極めて難しいと答えます。しかし最大のネットワーク効果は企業「内」にあり、それがチャットによって今まさに起きていると述べます。
Sinofsky氏は、多くの企業で働く人々は実は自分の仕事を良くすることに強い関心はなく、ただ出勤して給料をもらって帰りたいだけだと指摘します。しかしGoldman Sachsのバンカーのように「どうすればより多くの案件を速く、賢いモデルで処理できるか」を考える少数の人々が存在します。1980年代後半、重いラップトップでExcelを使う人を満員のエレベーターの人々が覗き込んで興奮したという当時のCM同様、2025年にチャットで全く同じことが起きているのです。自身もSAPの友人のためにプロンプトでホワイトペーパーを書いて返したところ、そのチーム内で「仕事を良くする方法」が伝播していく一種のバイラルループを起こしたに違いない、と語ります。
そして、これまで話せなかった二つの機能をつなぐツールこそが「黄金(golden)」だと結論づけます。Figma($非上場)がデザインとプロダクト開発で行ったように、あるいはITと財務を予測でつないだIT予算管理ツールのように、AIを活用して普段はコミュニケーションを取らない組織の部分を結びつけるソフトウェアを作れれば、それは全く新しいカテゴリーになる――これが対談の締めくくりのメッセージです。
#AI #ポッドキャスト #a16z #Salesforce #CRM #SAP #Oracle #ORCL #Amazon #AMZN #Microsoft #MSFT #GoldmanSachs #GS #フォード #F #Toyota #TM #GeneralMotors #GM #McDonald 's #MCD #Box #workday #WDAY #生成AI #AIエージェント #エンタープライズソフトウェア #SaaS #米国株 #ヘッドレスソフトウェア #MCP #VibeCoding #NOTA
