本動画は、AIエージェント時代において企業が本当に向き合うべき課題は、見栄えのよいAI機能を載せることではなく、企業そのものをエージェントが読み書きできる構造へと作り替えることであると論じる内容である。McKinseyの予測する巨大市場を引き合いに出しつつ、今後は検索最適化や広告よりも、整備されたデータ構造、明確なスキーマ、取引可能な基盤こそが競争力になると指摘する。AIエージェントに読めない企業は、たとえ優れた商品を持っていても存在しないのと同じになりかねず、その変化はすでに始まっている、という強い警鐘が中心テーマである。
- AIエージェント時代に、企業は読めて書ける存在でなければならない
- 未来の注意の99％はAIの注意であり、しかもエージェントの注意になる
- OpenClawが真価を発揮するには、何千もの企業が変わらなければならない
- ベンダーは本当はそれを望んでいない
- 大手はまだボットを締め出したいが、それは負け戦である
- McKinseyの1兆ドル予測と、すでに始まっているエージェント商取引
- エージェントに読めなければ、最高の商品でも存在しないのと同じになる
- 企業全体をagent readable writableにするには、内部データ基盤の大改造が必要
- マーケティングで曖昧さをごまかす時代は終わる
- Amazonの配送約束は、agent readable化の好例である
- 大企業が恐れているのは、顧客がサイトに来なくなること
- Stripeの例――MCPサーバーを出すだけでは足りない
- SAPの例――一部にAI機能があることと、全体が読めることはまったく別
- 経営陣が抱きがちな四つの誤解
- 誤解その一――検索最適化の延長で考えればよい
- 誤解その二――構造化スキーマは単純な商品にしか効かない
- 誤解その三――人はエージェントに取引を任せない
- 誤解その四――とりあえず様子を見る
- 真に重要なのは、商品そのものの高次の意味までデータ化すること
- B2B SaaSでも、表面的な事例紹介だけでは足りない
- これまでのソフトウェアスタックは、エージェントを締め出すために作られてきた
- まずは競合と自社を、ClaudeやChatGPTで実地検証すべきである
- agent firstで作れば、人間向け体験もむしろ良くなる
AIエージェント時代に、企業は読めて書ける存在でなければならない
私たちが20年かけてボットを締め出すために築いてきた柵こそ、いま最も価値ある顧客を締め出しているものになっています。
OpenClawが週末の個人プロジェクトからGitHubで25万スターを集める存在へと変わったとき、それはJensen Huangが言うところの未来のOSになりました。個人向けAIのためのOSです。
いまや誰もがその流れに飛び乗っていますよね。Nvidiaはエンタープライズ向けプラットフォームを構築し、その上でいろいろ発表しています。誰もがそれを語っています。でも誰も、構造的な前提条件については語っていません。要するに、その土台にあるものであり、これらすべてが本当に機能するかどうかを決めるものです。
別の言い方をすれば、open clawという考え方、パラダイムが成立するのは、私たちのあらゆるシステムがagent readableかつagent writableである場合に限る、ということです。
ここで言うのは個人のシステムではありません。企業のシステム、製品のシステムのことです。チャットボットの話をしているわけではありません。ほかのメッセージングプラットフォームから自分のボットやopen clawやclawにメッセージできるか、といったAI機能の話ですら、実はそこまで本題ではありません。
私が言っているのは、実際の取引インフラです。誰かが商品やサービスを見つけて、評価して、購入する、あるいは見つけて、評価して、利用する、そのためのシステムそのものが、根本から中核としてagent readableかつagent writableである必要がある、ということです。まるでそれが最初で最重要のユースケースであるかのように、そう設計されていなければなりません。
未来の注意の99％はAIの注意であり、しかもエージェントの注意になる
ここで、Andrej Karpathyが言っていた考えに戻ります。未来の注意の99％はAIの注意になる、という話です。そして実際、その多くは特にエージェントの注意になるはずです。
エージェントには、その注意を向けて、実際に何かを行う場所が必要です。つまり、企業そのものが読めて書ける存在でなければならないということです。まさにそうです。
会社全体がagent readableかつagent writableでなければいけません。
私たちがXでよく見かける未来像がありますよね。WhatsAppで何かがテキストを送ってきて、エージェントがあなたのカレンダーを管理し、フライトを予約し、あれこれやってくれる、というような話です。デモではみんなそういうものが大好きです。
でも、そうしたことのすべては、世界中の多くの企業がagent readableかつagent writableであることを前提にしています。
そして誰も語っていないのは、それが膨大な作業だということです。簡単ではありません。そして、あまりに自明でない含意がたくさんあります。私たちはそれを話題にしていません。なぜ話していないのか。
理由はわかっています。私たちはOpenClawと個人の生産性というアイデアに熱狂しすぎているのです。その結果、この構想全体が機能するには、企業レベルでの巨大な変化が必要だということを忘れてしまっています。
OpenClawが真価を発揮するには、何千もの企業が変わらなければならない
OpenClawのようなエージェントが本来の力を最大限に発揮するには、何千もの企業にまたがるエコシステムレベルの大規模な変化が必要です。
いまのあなたのopen clawでも、呼び方は何でもいいですが、実際にclawでやっている人もいれば、本物のopen clawでやっている人もいるし、Perplexity Computerでやっている人もいます。何を選ぶにせよ、その仕組みが機能するのは、エージェントが読んだり書いたりできるデータの質に依存しています。
そして、私たちが十分に語っていないのは、まさにそこです。
私がこのことに本格的に向き合うようになったのは、Prime Videoにいたころでした。データを使ってタイトル体験をどうパーソナライズするかを考えていたのです。
そこでわかったのは、基盤となるデータがスタックの奥深くまできちんと整っていないと、顧客の最終体験はひどいものになるということでした。なぜなら、役に立つカスタマイズ体験は、きれいなデータなしには提供できないからです。
しかもそれは、エージェント以前の話でした。単にデータがどれほど重要かを学んでいた段階です。
では、そのデータをエージェントが大規模に消費できるようになったとき、どれほど重要になるかを考えてみてください。見た目のよいタイトルだけでなく、製品やサービス全体を、まず最初にエージェントが消費できるインターフェースとして提供できなければなりません。
OpenClawが本当に示したのは、人々が求めているもの、いや切望しているものは、私たちの代わりにデジタル世界のあらゆるものと会話できる、統一されたエージェントだということです。
ベンダーは本当はそれを望んでいない
正直に言えば、ベンダー側はこれを望んでいません。本当に望んでいません。
Peter Steinbergerが、私たちが製品の周囲に築いてきた壁を次々とハックし、command line first、chat firstなエージェントを実現しようと強く押し進めなければ、ベンダーはこれを提供する圧力すら感じなかったでしょう。
WhatsAppは、agent readableではないものの典型例です。Peterは、それをOpenClawで動かすだけでも相当な作業をしなければなりませんでしたし、Metaは長年にわたり、ボットを締め出す方法を考え続けてきました。
けれど今や、OpenClawがこれほど成功しているために、企業はその姿勢を見直さざるを得なくなっています。市場がその方向へ動いているのを見ているからです。
私たちがプロダクトの世界で学んできたことの多くが、いま根本からひっくり返されています。なぜなら、これまで私たちは、ボットは悪いものだと教えられてきたからです。ボットは本物の人間の体験を汚すものだと考えられていました。だから排除すべきだったのです。
ところが突然、ボットは悪ではない、むしろボットこそが人間がウェブと関わる方法なのだ、という時代になっています。
私が子どものころ、親からは、知らない人の車には乗るなと言われました。でも今では、Uberに乗るとき私は知らない人の車に乗っています。もっと理想を言えば、運転手すら乗っていない車に乗ります。Waymoだからです。
物事は変わります。技術は私たちの行動を変えます。そして私たちは、15年以上にわたって作ってきたanti-botアーキテクチャを反転させ、今度はpro-botアーキテクチャを作らなければならない、という課題に直面しています。
大手はまだボットを締め出したいが、それは負け戦である
しかもこの流れは、争いなしには進みません。
Googleはひそかに、Googleの製品やサービスを使うOpenClaw系のボットを止めたり制限したりしようとしてきました。ほんの数日前には、AppleがApp StoreでReplitを含むバイブコーディング系アプリを制限、あるいは停止しようと動きました。
大手プレイヤーには、なお壁を高く保ちたい動機があります。でも、私ははっきり言います。それは負け戦です。人々はすでに意思表示をしました。そして人々が望んでいるのは、agent readableかつagent writableな世界です。
皮肉なことに、Appleは何十年も前、Napsterをめぐる人々の意思表示から利益を得ました。人々は、ウェブ上のどこでも自由にストリーミングできる音楽を望んでいて、Napsterはそれを見抜いていました。
もちろんNapster自体は訴訟で徹底的に叩かれました。でもNapsterというパラダイムは生き残り、それがiTunesになりました。そして皮肉にも、それはAppleがiPhoneを普及させる一助になったのです。
いまAppleは、openclawを前に自分自身のその瞬間を迎えています。そして、かつての旧勢力と同じように振る舞っています。Appleは自由に使えるagent readable writableなエコシステムを望んでいません。Googleも同じです。
でも、人々はそれを望んでいます。そしてそのことが、新しいタイプのスタートアップに道を開いています。彼らは、注意の99％がどこへ向かうかを理解し、既存勢力を破壊できると言っているのです。
McKinseyの1兆ドル予測と、すでに始まっているエージェント商取引
McKinseyは、2030年までにアメリカのB2C小売市場だけで、AIエージェントによって調整される売上が最大1兆ドルに達する可能性があると予測しています。しかも、それは保守的な見積もりかもしれません。
そして皮肉なことに、あのGoogle自身が、Universal Commerce Protocolを立ち上げました。エージェントに商品を発見させ、カートを構築させ、自律的にチェックアウトまで完了させるためのものです。
ShopifyのTobi Lütkeは、agentic shoppingを一生に一度の変革だと呼びました。Shopifyでは、その言葉は間違いなく現実になるでしょう。100万を超えるShopify加盟店が、エージェント仲介型の取引を可能にする方向へ進んでいます。
ですから、これをただの誇張だと思っている人のために、今日すでに可能な具体例を挙げましょう。
AIアシスタントに、木曜までに届いて、120ドル未満、サイズ10で、返品条件が柔軟なブランドのランニングシューズを探して、と打ち込めます。すると検索の連鎖が起き、条件に合った靴の候補が返ってきます。
その回答がどれほど正確で有用か、そしてそのままエージェントがどこまで取引できるかは、agent readable writableであるかどうかにかかっています。
顧客として、いらいらするような買い物体験をしたくないなら、企業は本腰を入れなければなりません。エージェントが必要な情報を見つけ、その情報をもとにあなたの代わりに取引できるよう、実際に使える状態にしなければならないのです。
エージェントに読めなければ、最高の商品でも存在しないのと同じになる
そしてこれは、やがて生き残りの問題になります。買い物の多くがこの形で行われるようになるからです。私たちの注意の多くが、ますますチャットボットへ移っていくからです。
NShiftの調査はこの点を非常に率直に述べていますし、私は彼らが正しいと思います。配送期間、送料、返品条件が不明確なら、そして私はまだ商品スキーマの話すらしていませんが、それも明確でなければなりません。そうした情報のどれか一つでも不明確なら、エージェントは人間に一度も見せることなく、そのオファーを飛ばしてしまいます。
世界で最高の商品を持っていたとしても、それがagent readableでなければ、ただ消えるだけです。存在しないのと同じになります。小売業者はその売上を失います。
そしてこれは、今後インターネット取引全体のうち、ますます大きな割合に影響していくことになるでしょう。
企業全体をagent readable writableにするには、内部データ基盤の大改造が必要
ここからが、誰も話していない部分です。
会社全体をagent readable writableにしたいなら、内部のデータスタックに対して巨大な変更を強いることになります。ただやってみて、うまくいくことを祈る、というわけにはいきません。ただやって、内部は何も変えず、表面にAPIを一枚貼るだけ、というやり方でも駄目です。
なぜ誰もそれを話題にしないのか。安い解決策が好きだからです。
何か一つをMCPサーバーで包めば、以前はAPIだったけれど今はagent readable writableになりました、ありがたい、これで次へ進めます、という話なら誰もが大好きです。
でも、そんなふうには機能しません。
商品カタログ全体をエージェントにとって完全に読解可能なものにするとはどういうことかを、最初から最後まで本気で考えなければなりません。そしてそれは、一般に非常に大きな作業になります。
人間が主にデータとやりとりしていた時代には、その労力に見合わないと考えられてきました。人間は寛容だからです。人間は一般化して理解します。細部は飛ばします。
その結果、顧客とのやりとりにおいて、多少雑でも何とかなるシステムをたくさん作ってきました。でもエージェント相手には、それは通用しません。
むしろ私は、マーケティングの多くは、人間が製品と接するときに生じる問題を上塗りして隠すために存在してきた、とさえ思っています。
マーケティングで曖昧さをごまかす時代は終わる
異論はあるかもしれませんが、私たちは皆知っています。プロダクトマーケットフィットがある製品を売るマーケターは、何をやってもうまくいきます。逆に、プロダクトマーケットフィットのない製品を売るマーケターは、顧客にその製品を気にかけてもらうだけでも上り坂を押し上げるような苦労をします。
つまり、製品の欠陥を何か追加の仕掛けで覆い隠す必要がある、という発想自体が、これから消えていくのです。
これから考えるべきなのは、ひとつには、どうすれば本当にすばらしい製品を人間と結びつけて、人々が名前で指名して求めるほど好きになってもらえるか、ということです。
もうひとつは、agent readableなアーキテクチャをどれだけ清潔で明快に作れるか、ということです。そうすれば、そもそも欠陥を抱えずに済みます。なぜこれがないのかと誰かに文句を言われることもなくなりますし、製品そのものが内部で曖昧だったり、その製品を支えるデータが不明瞭だったりするせいで、わざわざ人に理由を作って考えさせたり気にかけさせたりする必要もなくなります。
Amazonの配送約束は、agent readable化の好例である
具体例を出しましょう。
Amazonで買い物をするとき、いまではウェブ全体の多くの購入でもそうですが、配送予定日が表示されます。その日数は、その商品について、あなた個人に対してなされる具体的な約束です。あなたの居住地や、Amazon内部でその体験の表示を左右する何百もの要因に基づいています。
その内部データがすべて整合していなければ、そもそもその約束を提示できる地点にたどり着けません。
そしていまAmazonが向き合うべき課題は、これまで消極的だったとはいえ、その配送約束という概念をどうagent readableにするか、ということです。複数の商品を横断して比較し、その違いの一つとして配送約束を見たいときに、どうやってそれをエージェントが理解できるようにするのか。
今日届く。明日届く。必要性によって価値判断は変わります。
しかしAmazonのUIでは、それを属性として使って簡単に見比べるのは容易ではありません。かなり深く掘らないといけません。でもエージェント相手なら、それは簡単であるべきです。
今日届くランニングシューズがほしい。その中でもNew BalanceかNikeで、特定のアーチサポートがあり、必要なモデルのものがほしい。エージェントはそれらすべてを、agent readableな形で処理できるべきなのです。
皮肉なのは、こうしたことに対応するための最良のデータを持っている企業、たとえばAmazonは内部的にはすばらしいデータを持っていますが、そういう企業ほど抵抗することです。なぜなら、顧客との関係を失うことを恐れているからです。
大企業が恐れているのは、顧客がサイトに来なくなること
大企業がこれを嫌がる理由はそこです。
彼らが望まないのは、私は気持ちよく買い物できればAmazonかどうかは別に気にしない、ただ正しい靴を買えればいい、とユーザーが言うことです。商人からすれば、それは恐ろしい話です。顧客との関係を失うからです。もう自社サイトに来てくれなくなる。代わりにClaudeやChatGPTと話すだけになる。
でも実際、私たちはますます、エージェントにメッセージするだけで欲しいものを手に入れたいと思うようになっています。人間である私たちは、わざわざChatGPTを開かなくても、WhatsAppのような小さなチャット欄で、ねえエージェント、ランニングシューズを探してくれる、と打ち込めるだけで十分に快適だと知ってしまいました。
そのことが、GitHubの25万スターという顧客の検証結果なのです。そして、それこそが大企業を不安にさせているものです。
だからこそ、未来の企業は、自社のデータをエージェントにとって深く利用可能な形にどう向け直すかを真剣に考えるようになる、という考えを重く受け止めるべきです。
Stripeの例――MCPサーバーを出すだけでは足りない
この問題を両端から挟み込むような、実例を二つ挙げます。どう機能するか、どこで機能しないかを説明するための本物の例です。
まずStripeです。多くの人は、彼らこそ初期採用組であり、この流れを正しく理解している、agent economyを読み切っている会社だと言うでしょう。そして確かに、そう言える点は多くあります。
ただ、ここであえて指摘したいのは、あまり語られていない製品上の難しさです。スタックの奥深くでこれを難しくしているものです。
StripeはMCPサーバーを出しました。それ自体はとてもよいことに思えます。顧客を検索でき、返金処理ができ、サブスクリプション管理もできる。チャットから顧客がやりたいことをエージェントが実行できるからです。
でも、MCPサーバーを出しただけでは十分ではありません。問題は、さらに深い層のデータにアクセスすることが実際には非常に難しいという点です。
StripeにはSigmaという、より深い分析レイヤーがあります。クエリを投げると、大量のデータを含むCSVを完全な形で返せます。CSVのサイズに実質的な制限はありません。取引量によって制約されるだけで、クエリの観点では事実上無制限です。
問題は単純です。APIとしてはうまく機能していたそのデータソース、つまりSigmaを、そのままMCPで包んだだけでは、コンテキストウィンドウがあふれてしまいます。
現実のビジネスデータを扱うときは、データがどこへ着地するかまで考えなければならず、同じようにはいきません。以前はCSVとして出力し、顧客が好きな場所へ保存できました。ローカルに保存する、ドライブへ入れる、それでよかったのです。
でも今は、それをネイティブにコンテキストウィンドウへどう読み込むかを考えなければならない。明らかに無理があります。
実際には中間機能が必要です。データベースが必要なのです。これは、私がopen brainとして話してきた考え方と同じです。データはまず流れ込み、どこかのデータベース内でテーブル構造に格納され、そのうえでチャットからアクセスでき、各要素がagent readableかつagent writableにならなければなりません。
ところがStripeにとって、それは非常に難しい課題です。Stripe規模で、しかも扱うデータが極めてセンシティブである以上、agent securityを本気で考えなければなりません。
そのへんのデータベースを適当に立てて、はい、これで動きます、というわけにはいかないのです。どのデータなら、ある特定のビューを特定の安全なデータベースに安心して配置できるのか。そのデータに対する正しい認証をエージェントにどう保証するのか。エージェントが必要に応じてその断片を引き出せるようにどうするのか。
これは難問です。ただ別のAPIをMCPで包むだけの話ではありません。そしてこれは、エージェント志向の会社ですら、自社データをよりagent readableにしようとするときに直面する複雑さをよく表しています。
ここには私も共感があります。会社をagent readableかつagent writableにすれば簡単ですよ、と言っているわけではありません。むしろ、かなり難しいと言っています。ただし、それをうまくやった企業は、莫大な利益を得るはずだとも言っているのです。
SAPの例――一部にAI機能があることと、全体が読めることはまったく別
もう一つはSAPです。これは反対側の例です。
正直に言って、SAPはデータを外へ出したいときに扱いづらいことで有名です。なぜならSAP全体のインセンティブは、データを中に閉じ込めておくことにあるからです。
SAPのような会社にとっても、agent readable writableは未来です。しかし、彼らはまだその準備ができていません。たしかにSAPはCommerce Cloud向けのMCPサーバーを発表しました。
しかし、SAP全体のポートフォリオのほんの小さな断片にAI機能がある、という話と、すべてのSAP導入環境がデフォルトでagent readableになっている、という話のあいだには、グランドキャニオン級の隔たりがあります。
現実に動いている大半のSAP環境について言えば、システムを本当にagent readableにするのは、よくて複数四半期にまたがる取り組みです。しかも現時点でSAPには、それを強く進める動機があまりありません。
これから6〜8か月の間に、どれだけ多くの企業が自社のスタックを下から見直すようになるかは非常に興味深いところです。自社のデータベース構造やクラウドDBプロバイダー、データがどこに存在しているかを見下ろしながら、私たちが持っているデータは本当にエージェントが読み書きできる形式なのか、それを実現するには何が必要なのかについて、ベンダーと率直に話し合う必要がある、と考える企業がどれだけ出てくるか。
顧客がどこへ向かっているかを見ている企業から、そのベンダーへとかかる集団的な圧力こそが、SAPのようなベンダーをよりagent readableかつagent writableな方向へ押し出していくでしょう。
これは、OpenClawほど派手な見出しにはならないかもしれませんが、2026年でもっとも興味深い物語の一つになるはずです。
経営陣が抱きがちな四つの誤解
ここで、私が実際に経営幹部たちから何度も聞いてきた四つの誤解を取り上げたいと思います。どれも本物の誤解です。私と同じ部屋の中で、実際に彼らが口にしたものです。
率直に言いますが、これらは誤解です。agent readable writableな未来がどう機能するかについての間違った考え方です。何が間違っていて、代わりに何をするべきなのかを明確にしておきたいのです。agent readable writableになると言いながら、間違った道を進むのは簡単だからです。
誤解その一――検索最適化の延長で考えればよい
一つ目の間違いは、agent readable writableにはなるだろうが、エージェントによる発見の最適化は、検索最適化と同じようにやればよい、という考えです。
違います。違います。まったく違います。これは非常に高くつく誤りです。
検索エンジンは順位づけされたリストを返し、人間に選ばせます。そこにはポジショニング、ブランド認知、広告クリエイティブ、有料検索結果にお金を払っているかどうかが影響します。
でもエージェントは、検索結果ページを眺めません。リストを眺めません。明示された制約に対して構造化データを評価し、そのうえで結果を返します。
エージェントにとっては、above the foldのような概念は存在しません。だから勝つ企業は、広告予算が最大の企業ではありません。もっともきれいなスキーマを持ち、もっとも摩擦の少ないデータの読み書きポイントを持つ企業です。それがAPIであれMCPであれ同じです。
誤解その二――構造化スキーマは単純な商品にしか効かない
二つ目の大きな誤解です。これは最初は小声でささやかれ、その後で堂々と言われるようになるタイプのものです。
Nate、君が言うような構造化スキーマは単純な商品にしか効かない。うちの事業は複雑だ。うちの商品は特別だ。そんなものは合わない。顧客もそんなものは望まない。
私はこれを、ラグジュアリーを重視する企業からも、本物らしさを重視する企業からも、自社の見せ方に強くこだわる企業からも聞いてきました。あたかもそれが特別で唯一無二であるかのように。
でも、これはエージェントが世界とどう相互作用するかに対する根本的な誤解です。
あなたの事業が複雑であればあるほど、agent readableにするメリットは大きくなります。実際には逆なのです。複雑さこそが、いま顧客が自分にとって最適な購入判断をできない原因だからです。変数が多すぎて評価しきれないので、多くの顧客は十分に良さそうなところで妥協しています。
だからこそ、創造的に考え、エージェントに構造化されたアクセスを与え、最適解を見つけられるようにすべきなのです。
たとえば私はコーヒー好きですが、コーヒーにおける本物らしさとは何でしょうか。どこの農園で作られたのか。どう焙煎されたのか。どう調達されたのか。どう精製されたのか。そうしたものはすべて、エージェントが読めるスキーマにできます。
もちろん、本物らしさは人間的で曖昧な概念だと言うこともできます。でも最後まで分解していけば、それは一連のデータの読み書きに行き着きます。ソフトウェアとはそういうものです。
画面上に表現できるものなら、エージェントがそれに対して読み書きできるべきなのです。それは、honey processedのEthiopia Yirgacheffe coffeeのようなものにまで当てはまります。
誤解その三――人はエージェントに取引を任せない
これも多くの人から聞きます。顧客側から、私はエージェントに購入を任せたりしないよ、冗談でしょう、という形で聞くこともありますし、企業側から、うちの顧客は商品が特別すぎるから、エージェントに取引を任せるなんて信用しないと思う、という形で聞くこともあります。
でも、実際に起きていることを見ましょう。人々が言っていることではなく、起きていることです。
agent commerceは、AIに好きなものを勝手に買わせるところから始まるわけではありません。たいていの人はそういうふうに話を枠づけますが、実際は違います。
始まりは、長い時間軸をもった意図の委任です。たとえば私がサウンドシステムを買ったときのように、複数の候補を比較検討していて、何を買うべきか確信がない。部屋の構成が条件で、予算はこれくらいで、前の機種でうまくいっていた点はこれで、再生したいロスレス音源はこういうものだ、といった具合です。
つまり、その瞬間に購入判断のすべてを丸ごと委任しているわけではありません。まずエージェントと会話をしながら、何が正しい選択なのかを一緒に考えていくのです。
だから信頼は二値ではありません。信頼はスペクトラムです。最初は狭い範囲から始まり、個人としてエージェントを信頼するにつれて、より広く、より大きく委ねられるようになります。
これを単なるオンオフのスイッチとして扱ってしまうのが、多くの人が見落としている大きな点です。
企業としての目標は、その信頼のスペクトラム全体にわたって、自社製品をより多く利用可能にしていくことです。そのためには、エージェントがあなたの提供しているものとその価値を正しく理解できるようにする、あの泥臭いデータ整備が必要になります。
それから、もし私が消費者向け商品ばかり例に出していて、あなたがB2B SaaSの人で、これは自分には関係ないと思っているなら、残念ですが関係あります。
検討ファネルそのものが、エージェントの世界へ移っていきます。エージェントは、あなたの製品に登録すべきかどうかを検討できなければなりません。特にB2Bの世界では、私のエージェントはあなたのSaaSアプリケーションを読めて、操作できるのか、と人々が明示的に尋ねるようになります。
ですから、これは間違いなく注目すべきテーマです。
誤解その四――とりあえず様子を見る
そして四つ目、もっとも魅力的に聞こえる誤解は、こうです。様子を見よう。
これは企業を殺します。遠回しには言いません。
データをきれいにする作業は簡単ではありません。何か月もかかります。場合によっては複数四半期にわたります。データをagent readableに整えること自体が一つのプロジェクトです。インターフェースを実際に使えるようにするのはその先です。
深い思考が必要ですし、Stripeのように積極的な企業でさえ、まだ全部を解けてはいません。
もしあなたが様子見をしているなら、それは会社として自分に死刑宣告を書いているようなものです。エージェント・エコシステムの構成要素を全部理解し、よし準備ができたと言うころには、流れはすでにあなたを追い越しています。顧客とのやりとりの大半の場面で、あなたの会社は見えなくなっているでしょう。
世界はそんなに速く変わらない、と言うなら、OpenClawの25万GitHubスターは、ほんの数週間のうちに積み上がったという事実を思い出してください。変化はその速さで起きています。
真に重要なのは、商品そのものの高次の意味までデータ化すること
この話全体は、いまのagent momentについて私たちがまだ十分に語れていない洞察の一つにつながっています。言葉にしにくいからこそ語られていないのだと思いますが、データをreadableかつwritableにするうえで、おそらく最もレバレッジの大きい瞬間かもしれません。
バスケットボールがあって、重さはこれくらい、色はこれ、ロゴはこれ、はい終わり、というところから始めるのは簡単です。
難しいのは、そのバスケットボールの、より高次の属性をどうreadableにするかを理解することです。
たとえば、そのバスケットボールがNBAファイナルで使われたものとまったく同じタイプだとします。バスケットボールファンにとって、それは重要です。あるいはMarch Madnessで実際に使われたものかもしれません。コート上で使われたという事実に意味があるのです。あのサイズ、あの色、あのデザイン、そのものだということに。
では、顧客がエージェントに、バスケットボールがほしい、と言ったときに何が起きるかを考えてください。顧客のその高次の意図まで、agent readableになっていてほしいはずです。
試合を見ていて、March Madnessでコート上にあったものみたいなバスケットボールがほしい、と顧客が言ったとき、エージェントはその曖昧な意図を受け取り、現実の商品を見つけ出さなければなりません。
もしあなたのデータが、これは2026年のMarch Madnessトーナメントで使われたボールと同じです、と言える状態になっていなければ、困ることになります。人間が実際にそう尋ねるからです。
ですから、曖昧さや人間の意図について話すとき、企業側の課題の一つは、この製品について顧客が気にしそうな典型的な言い回し、従来のメタデータには入っていなかった関心事は何かを見つけ出すことです。
これまでは怠けていても何とかなりました。広告で、これは2026年のMarch Madnessトーナメントで使われた製品です、と言えば済んだからです。
でもこれからは、広告で済ませるわけにはいきません。実際にデータに入れなければなりません。ではどうやるのか。その情報を、エージェントが読み書きできる持続的なデータ属性として、どう組み込むのか。
B2B SaaSでも、表面的な事例紹介だけでは足りない
これを何万もの商品に広げて考えてみてください。
さらに、B2B SaaSの複雑さに置き換えてみてください。1万人規模の顧客を本当に支えられる実績がある製品がほしい、と言われたとします。そのとき、それをエージェントが読めて信頼できる属性として表現しなければなりません。しかも適切な根拠つきで。あなたのブログに載せた一つのケーススタディだけでは駄目です。
技術的なスケーリング実績を通じて、はい、この製品は1万人の顧客を支えられますと、信頼可能なかたちで示さなければならないのです。エージェントはだまされません。ブログ記事を一つ読んで、ああ十分だね、とは言いません。
私たちが作るエージェントは、曖昧な人間の意図を受け取って、かなり深くまで掘り下げ、現実はどうなのかと問い直せるほど洗練されていきます。私たちのデータも、その深さに耐えられる状態でなければなりません。
私は、この問題の多くがtribal knowledgeにあると思っています。つまり、人の頭の中にはある知識です。あるいはマーケティングコピーには存在していても、データ構造の中には存在していない知識です。
その結果、私たちは、いわば80対20問題の逆のような状態に陥っています。製品についてのデータのうち、データ構造として表現されているのは20％程度で、その20％ですらagent readableかつagent writableにするのは大変です。
ところが、製品の意味の80％は別の場所にあります。たとえば、そのコーヒーが小規模農家によって生産され、エチオピアの地元学校を支援しているという話。そうしたものはマーケティングコピーの中にあって、agent readableな形式にはなっていません。
そして今、私たちはそれを広告文から拾い出し、商品のパッケージから拾い出し、agent readableな形式に変換しなければならないのです。これは大きな仕事です。
しかも、それこそが人間が商品について尋ねるときに気にする意味の80％なのです。私のコーヒーが学校建設のような大事な仕事を支援していることを確かめたい、と顧客が言えば、エージェントはそれを探しに行きます。そのとき、あなたの商品がそこに存在しているかどうかが問われます。
そして、その売上を逃したくはないはずです。
これまでのソフトウェアスタックは、エージェントを締め出すために作られてきた
見てください。2010年代のソフトウェアスタック全体は、エージェントを締め出すために作られていました。CAPTCHAはエージェントを締め出すためのものです。制限されたAPIもそうです。JavaScriptが重いインターフェースでさえ、間接的にはエージェントを締め出す方向に働いていました。
すべては、ボットは悪い、という前提で設計されていたのです。
でもこれからの3年間で、あなたのビジネスにとって最も価値のあるトラフィックはボットになります。人間の代わりに、何がほしいかを理解し、製品を見つけ、比較し、最終的には取引までしてくれるAIシステムです。
自社のシステムを本当に読みやすく、書き込みやすくした企業こそが、この瞬間に勝ちます。
そのためには、先ほど話したあらゆるtribal knowledgeを含めて、データアーキテクチャを完全なものにし、スタックの奥深くまで本当にきれいにすることが避けられません。ベンダーと話し合い、エージェントが簡単に消化できる形でデータを表現できるようにする必要があるかもしれません。
そして断言しますが、それは既存のAPIをそのままMCPサーバーで包むだけの簡単な話ではありません。それでカバーできるのは、ユースケースの数％です。役には立ちます。出発点にもなります。取りやすい低い果実です。
でも、それで話は終わりではありません。Stripeがまさにそう気づき始めています。
まずは競合と自社を、ClaudeやChatGPTで実地検証すべきである
では、どうすればいいのか。
少し汗をかくような実験を一つお勧めします。
上位3社の競合を見に行ってください。そしてClaudeでもChatGPTでもいいので、実際に意味のある会話をしてみてください。その企業相手にどこまで取引まで進めるのかを確かめるのです。
彼らが何をしているかをテストしてください。どれだけagent readabilityとwritabilityを備えているか、掘ってみてください。そして、そのあと自社でも同じことをやってください。
ベンチマークを始めるのです。データを外へ出すのはどれくらい時間がかかるのか。どれくらい大変なのか。簡単につなげられるMCPコネクタはあるのか。本当にそれで十分なのか。少なくとも出発点にはなるのか。競合の中には、それをすでに備えている会社があるのか。
もし競合がこの領域でひどい状態なら、自社が先行できる可能性はあるのか。逆に競合が優れているなら、どこまで速く追いつけるのか。
この世界で勝つ企業は、agent attentionを第一に考える企業です。自社の事業構造も、データのあり方も、エージェントの注意を起点に組み立てていく企業です。
agent firstで作れば、人間向け体験もむしろ良くなる
そして実は、もし人間を取りこぼしたらどうするのかと思っているなら、心配はいりません。人間も取りこぼしません。
なぜなら、このようにきれいなデータは、人間向けにもすばらしい体験を作るのがとても簡単だからです。
考えてみてください。これまでマーケティングコピーの中にしか存在しなかった複雑なtribal knowledgeが、きちんとデータになっていたら、ウェブ上で人間向けにダイナミックで、しかもパーソナライズされた体験を生み出すのは非常に簡単です。
たとえば、その特別なコーヒーについて、あの農家やエチオピアの学校にまつわるパーソナライズされたランディングページを作ることもできます。しかもエージェントは、顧客にそのページを見るよう提案することができます。
それは、データが正しければ簡単にできることです。
だから、まずはエージェントのために作ってください。そうすれば人間は後からついてきます。健闘を祈ります。
コメント