AIエージェントのための新たなインフラストラクチャスタックが急速に形成されつつあるが、その実態を理解している者は少ない。本動画では、過去のクラウド移行やマイクロサービス化と同様の構造的転換が進行中であることを示し、エージェントが実際に機能するために必要な6つのレイヤー(コンピュート、アイデンティティ、メモリ、ツール、課金、オーケストレーション)を詳細に解説する。各レイヤーの成熟度は大きく異なり、現時点ではレゴブロックのような互換性は存在しない。特にオーケストレーションレイヤーは未開拓の巨大市場であり、次世代のKubernetesに相当する企業が誕生する可能性が高い。ビルダーにとって重要なのは、信頼性の複利的低下、過渡期のロックイン、エージェントの無秩序な拡散というリスクを理解し、スタックリテラシーを獲得することである。
AIエージェントのための新しいインフラストラクチャ
今まさに、AIのための新しいインフラストラクチャスタックが公の場で組み立てられているのですが、私たちのほとんどはそれに注意を払っていません。その背後には何十億、何百億という資本があります。これはソフトウェアではありません。エージェントでもありません。その両方の下にあるレイヤーなんです。エージェントが実際に世界で何かをするために必要なレイヤーです。
そして今の問題は、このカテゴリーの外側にいる人のほとんど誰もが、何が本物で何が誇大広告なのかを見分けられないということです。この動画は、そのすべてを解きほぐし、エージェントのために作られているこの新しいインフラストラクチャカテゴリーを理解する方法を提供し、このカテゴリーの主要な要素が何であるか、そしてあなたのエージェントやデプロイメントに何が必要かをどう考えるべきかを理解する手助けをするためのものです。
はっきりさせておきたいのですが、私たちは以前にもこの映画を見たことがあります。実際、2回見ています。2006年から2010年の間、コンピューティングインフラストラクチャはオンプレミスサーバーからクラウドへと移行しました。EC2、S3、Lambdaといったクラウドコンピュートインターフェースです。新しいスタックを理解したビルダーたちは、今では支配的な企業、例えばAWSのような会社を立ち上げました。
そして2012年から2016年の間、私たちは再びその映画を見ました。モノリシックなアプリケーションは急速に分解されたアプリケーションへと道を譲り、それらの間にAPIが配置され、私たちがマイクロサービスアーキテクチャと呼ぶものになりました。今、私たちはまた別のシフトを目撃しています。人間優先のツールからエージェント優先のプリミティブへと移行しているのです。
クラウド移行と同等の構造的転換
これはクラウドへの移行が基礎的だったのと同じように基礎的なものだと私は信じています。インフラストラクチャの新しい顧客はエージェントになるでしょう。ちょうど2010年代にコンピュートの新しい顧客がデータセンターからコンピュートをレンタルする企業になったのと同じようにです。私たちはエージェント的プリミティブへの移行について話しているのですが、これは少なくともクラウドと同じくらい大きなシフトです。
しかし、あまりにも新しく、スタートアップのほとんどが非常に小規模であるため、この分野のノイズと実際のシグナルを区別することが本当に、本当に難しくなっています。だから私はここでこのカテゴリーをあなたのために分解していきます。そしてまず、警告の言葉を。
私はレゴが大好きです。ご存知ですよね。でもこれらはエージェント用のレゴブロックと同じものではありません。同じであってほしいんです。それが希望です。彼らはエージェント用のレゴブロックとして売り込んでくるでしょうが、今のところ、レゴの比喩で得られるような同じ程度の組み合わせ可能性と予測可能性は持っていません。これらはすべて同じサイズのノブを持ったブロックで、ただ叩きつければ小さな壁ができるというものではありません。
今の状況は、レゴと木のブロックがあって、それらがすべてレゴとして自分たちをマーケティングしているようなものです。どれがどれか分からないし、どうやって組み合わせるかも分かりません。そしてそれが今この分野で最も大きな問題の一つです。今私たちがいる場所について、より信頼できる比喩は、システムコールのようなものだと思います。
エージェントのための6つのレイヤー
エージェントには、アイデンティティ、コンピュート、メモリと永続性、コミュニケーション、支払いを理解するのに役立つ、定義された信頼できるインターフェースが必要です。そしてそれらのシステムコールを構築している企業は、本質的に、エージェントが新しい経済で仕事をするために必要なオペレーティングシステムを構築しているのです。
私はそのスタックを分解して、エージェントがどのように見えるか、そしてエージェントプリミティブがこの経済でどこに向かっているのかを、レイヤーごとに説明したいと思います。
第一に、レイヤー1、コンピュートとサンドボックスです。これはおそらくスタックの中で最も本番環境に対応しているものです。すでにエージェントの負荷を支えています。
前提は何でしょうか。本当にシンプルです。エージェントにはコードを安全に実行する場所が必要です。あなたのラップトップで実行すべきではありません。本番環境で実行すべきではありません。そして無監視で実行すべきではありません。隔離された、サンドボックス化された、監査可能な実行が必要なのです。この層には現時点で最も成熟した競争があると思います。
E2Bは約3200万ドルの資金を調達しています。Firecracker microVMを使用しています。AWS Lambdaと同じ技術を持っています。そして各エージェントに専用のカーネルを持つセッションを提供することを目的としています。でもそれだけではありませんよね。Daytonaは最近2400万ドルのシリーズAを調達し、異なるアーキテクチャに賭けました。彼らは共有カーネルを持つDockerコンテナを採用していて、スピードに最適化されています。
彼らは90ミリ秒のコールドスタートを主張していると思いますが、これは驚くほど速く、また永続的な状態も持っています。Modalは、GPU負荷の高いワークロードをターゲットにしているスタートアップです。Browser BaseはシリーズB後に3000億ドルの評価を受けており、ヘッドレスブラウザ自動化に焦点を当てていて、エージェントが人間のユーザーであるかのようにウェブページと対話できる能力を提供しています。そして、この分野には新しい参入者もいます。AlibabaのOpen Sandboxは良い例です。
この分野での興味深い分裂は本当に哲学的なものです。エージェントでエフェメラル(一時的)になるのか、それとも永続的になるのか。E2Bはサンドボックスを使い捨てとして扱います。一つを立ち上げ、コードを実行し、シャットダウンします。Spritesはこれらのスペースを長寿命として扱い、エージェントが依存関係をインストールできる、ファイルを作成できる、そしてエージェントがある意味で後で戻ってくることを前提としています。彼らはある程度のエージェント的永続性を前提としています。
これはスタイルの好みではありません。あなたが考えることをオプションではありません。これは、新しい経済におけるエージェントセッションがどれくらいの期間実行されるか、そしてそれらのエージェントセッションにとって状態が重要かどうかについての、これらのスタートアップによるアーキテクチャ的な賭けなのです。アジア経済がそれほど大きくなるので、両方の陣営がおそらく生き残るでしょう。
しかし、あなたのワークロードが何を必要としているかを考える必要があります。スタックのこの部分を見たい場合、これは本当に高い耐久性のあるコンポーネントです。永続的エージェントに賭けたいか、使い捨てエージェントに賭けたいかに関わらず、エージェントにはコードを安全に実行する場所が必要です。
そして彼らがそれを行うための仮想ボックスを持つことは完全に理にかなっています。今後1年ほどでこの問題を解決しようと取り組むスタートアップはもっと多くなるでしょう。しかし、これは現在比較的成熟している分野であり、複数のオプションがあり、仮想コンピューティング環境でエージェントをデプロイしたい場合は、どれを使いたいかを考える必要があります。
アイデンティティとコミュニケーション
コンピュート部分の上にあるレイヤー2は何でしょうか。レイヤー2はアイデンティティとコミュニケーションです。これは奇妙な空間にあります。過渡期であり、この分野で何を基本と考えるべきかについて、私たちは思慮深くある必要があると思います。今のところ、エージェントはインターネット上のエンティティとして存在する必要があることは分かっています。何らかのメッセージを送受信する必要があります。
サービスで認証する必要があります。他のシステムが認識できる何らかの検証可能なアイデンティティを保持する必要があります。そして今日、それに対する実用的な答えの一つは、まあエージェントにはメールアドレスが必要だということです。
Agent Mailは数週間前にGeneral Catalystから600万ドルのシード資金を調達しました。そしてPaul GrahamとHubSpotのCTO、Dharmesh Shahの両方がAgent Mailのエンジェル投資家です。
このAPIを使用すると、エージェント用のメール受信箱をプログラム的に作成できます。実際のアドレス、完全なスレッド機能、添付ファイル、ラベル、検索。オンボーディングAPIは、エージェントが自分自身をサインアップすることさえ可能にします。ここまでは順調です。論文は非常にシャープです。Agent MailのCEOは、メールをコミュニケーションツールとしてではなく、基本的なアイデンティティレイヤーとしてフレーミングしています。
そして彼だけではありません。この分野にはメールを追求している半ダースほどのスタートアップがあります。メールは今日、インターネットへの普遍的な鍵です。すべてのSaaSサービスはサインアップ時にメールを必要とします。すべての検証フローはメールにコードを送信します。エージェントにメールアドレスを与えると、そのアイデアは、本質的にアイデンティティを与えることになります。
しかし、もしそれがシムだったらどうでしょうか。メールが今日機能しているのは、それがどこにでもあるからであって、エージェントにとって正しいプロトコルだからではなく、インターネットを構築した人間にとって正しいプロトコルだからです。そして今、私たち全員が人間としてメールに問題を抱えていますよね。スレッド機能は脆弱です。スパムや自動エージェントを防ぐために設計されたレート制限があります。
エージェントのコンテキストウィンドウにとって、シグナル対ノイズ比はひどいものです。メールの表面的な必要性の下にある本当の必要性は、エージェントにアイデンティティとコミュニケーションプロトコルを与える必要性です。人間のふりをする必要がないものです。そして複数のチームがこれに取り組んでいます。オンチェーンエージェントアイデンティティのオプションがあります。
専用のエージェント間通信標準があります。MCPベースのサービスディスカバリーがあります。この分野ではまだ勝つ権利が明確に定義されているものはありません。もしあなたがこの分野にいるなら、エージェントネイティブなプロトコルがどのようなものかについて思慮深くあってください。ところで、私はメールに対して賭けをする人ではありません。メールは多くの革命を生き延びるゴキブリのような能力で有名です。
ただ生き残り続けるようです。だから、エージェントが決してメールを使わないとは言いません。しかし、エージェントメールに賭けている場合、あなたは実用的な賭けをしているのであって、必ずしもアーキテクチャ的な賭けをしているわけではないことを認識しておくべきです。
メモリとステートフルネス
さて、エージェントにはコンピュートが必要です。そのレイヤーはかなり成熟しています。エージェントにはアイデンティティとコミュニケーションが必要です。それは本当に流動的です。エージェントにはメモリとステートフルネスが必要です。これは初期段階です。これは本物です。そしてプラットフォームリスクも同じくらい本物です。
必要性は明確ですよね。エージェントは、多くの場合、セッション内だけでなく、多くのセッション、多くのタスク、多くの日にわたって、何が起こったかを記憶できる必要があります。Mem0はここでの明確なリーダーです。
彼らは2400万ドルを調達し、GitHubスターを4万1000個獲得し、1400万ダウンロードを達成し、AWSによってそのエージェントSDKの独占メモリプロバイダーとして選ばれました。当然、彼らのAPIは非常に好調です。コール量は5倍に増加し、すべてがうまくいっています。
Mem0が正しく理解しているのは、メモリは会話を保存するためにあるのではないという洞察です。それは古いチャット方式のやり方です。実際には、メモリは能動的なキュレーションの行為なのです。したがって、彼らのシステムは重要な情報を保存します。古くなった矛盾する詳細を意図的に忘れ、LLMクエリで推論する際に関連するコンテキストのみを想起します。
だから、アーキテクチャは非常にハイブリッドなデータストアです。ネットワークグラフがあります。ベクトルデータベースがあります。そしてキーバリューストアもあります。これら3つの異なる形式により、Mem0はメモリを、モデルに単にボルトで固定された機能ではなく、管理されたインフラストラクチャとして扱うことができます。そしてより良い結果が得られます。
Locomoベンチマークでは、OpenAIの組み込みメモリを精度で26%上回り、レイテンシーは91%速く、トークン使用量は90%削減されています。これは明らかな勝利です。
しかし、すべてのフロンティアラボがメモリをモデルに組み込むことに夢中になっていることを覚えておいてください。OpenAIはすでに長期メモリに大きな投資をしており、それを続けるつもりです。Anthropicはメモリをclaudeに組み込んでいます。メモリが、検索がChatGPTに組み込まれて別の機能ではなくなったのと同じように、ラボが構築するモデルレベルの機能になった場合、これらすべての独立したメモリ企業はリスクにさらされます。なぜなら、モデルメーカーがそれらを単に奪い取ることができるからです。
Mem0側にいる場合の反対論は、ポータビリティですよね。そして私たちはこれについて話してきました。誰もあなたのメモリを所有すべきではないという考え。それは本当に重要な概念で、あなたは自分のメモリを所有できるべきです。私はOpenAIがAWSと行っているFrontierプロジェクトに関連してこれについて話しました。
あなたのコンテキストレイヤー、これはメモリより一段上のものですが、それが企業が所有するものであって、あなたが所有するものではないということに自信を持っていますか。だから、ここでの質問は本当に、どちらの論文が勝つかという質問だと思いますし、私は非常に不確実な見通しだと思います。
市場が、ハイパースケーラーに属さないメモリソリューションを望むと決定する状況になるでしょうか。それとも、ハイパースケーラーが提供する利便性があまりにも魅力的で、市場全体がただそれを採用し、メモリをハイパースケーラーに投げつけて、あなたたちが問題を解決してくれと言い、2年後に振り返って、Mem0のような企業を見て、ええ、彼らは十分に便利ではなかったから生き残れなかったと言う状況になるのでしょうか。
分かりません。少しコイントスのように感じますし、私たちが何を要求するかによってそれを形作ることができると思います。
ツールと統合
さて、コンピュートとサンドボックスについて話しました。アイデンティティとコミュニケーションについて話しました。エージェントのメモリと状態について話しました。エージェントのツールと統合について話しましょう。このレイヤーは爆発的に急速に成長しており、実際の即座の痛点を解決します。
エージェントは仕事をするためにツールと対話する必要がありますよね。SlackやJira、Salesforce、GitHub、Google Workspaceといったものと対話するにしても、これらはすべて統合です。あるいは、Unixを実行している、Pythonを実行しているなどの基本的なプリミティブと対話するにしても、エンタープライズレベルで仕事をするにはこれらのツールが必要で、これらの統合が必要です。それを簡単にするものは何でもコインになるでしょう。
そしてCompose.ioは、Lightspeedから2900万ドルの資金を調達し、エージェント向けのマネージド統合レイヤーを提供しています。複雑なOAuthフローなしで認証処理を提供します。
数百のソリューションへの事前構築されたコネクターを提供します。そしてすべてのツールコールに対する可観測性を提供します。彼らは必ずしもエージェントを構築しているわけではありません。彼らがやっているのは、エージェントがエンタープライズ環境を成功裏かつ安全にナビゲートするために必要な配管をエージェントに装備することだけです。
問題は古典的なN×M統合の悪夢です。ミドルウェアがなければ、すべての個々のエージェントビルダーが独立して、エージェントが触れるすべてのツールに対して、認証情報、OAuthフロー、レート制限、エラー処理、APIスキーマの変更を管理しなければならず、これは単に巨大な組み合わせ問題です。小規模では持続不可能です。それがN×Mである理由ですよね。ミドルウェアの数×無限です。
そしてエンタープライズ規模では、エージェントがCRM、チケッティング、メール、カレンダーに触れる必要があるかもしれない場合、追いつくことは不可能です。だから私は、この分野が構築するには非常に耐久性のある分野だと主張します。ツールのエコシステムが断片化したままである限り、そして何か起これば、企業が独自のものを構築するにつれてさらに断片化するでしょうし、エージェントは統合レイヤーが必要になります。
ここでの長期的なリスクは標準化です。もしMCPが本当に普遍的なものになれば、マネージド統合の価値は減少し始めるでしょう。だから、Compose.ioのようにこの分野で構築している場合、本質的に賭けているのは、エージェントが長い間、すべての大規模なエンタープライズ統合タッチポイントを処理する何かを必要とし続けるだろうということです。なぜなら、これらの企業の多くがMCPを展開するのが遅く、それからこれらのツールを持つ企業の多くがそれらのMCPを採用するのが遅いからです。そしてそのギャップこそが、あなたがCompose.ioであるなら、あなたの会社の論文全体が存在する場所なのです。
それは当分の間存続するでしょう。私は大規模なエンタープライズが急速に変化するとは信じていません。多くのエンタープライズは恐竜のように動くと思いますし、それは存続するでしょう。
プロビジョニングと課金
さて、コンピュートとサンドボックスは完了、アイデンティティは完了、メモリは完了、ツールアクセス、それについては話しました。エージェントのレイヤー5、プロビジョニングと課金。これは全く新しいもので、信頼レイヤーです。そして今まさに到着し始めたところです。
エージェントは本質的に、サービスを取得してそれらに対して安全に支払うことができる必要があります。そしてここにStripe Projectsが適合します。先週ローンチされました。エージェントからサービスへのトランザクションのための最初の信頼できる信頼レイヤーです。
エージェントは人間と同じCLIコマンドを使用し、独自のデータベースをプロビジョニングできます。ホスティングティアをアップグレードできます。Stripeはそのエージェントのために支払い認証情報をトークン化できます。そして開発者の生のカード詳細はStripeのボールトから出ることはありません。
問題は非常にシンプルです。今年の初めから、エージェントはプロジェクトを立ち上げる際にほぼすべてのことができるようになっていますが、アカウントを作成してインフラストラクチャをプロビジョニングする必要がある部分だけは例外でした。なぜなら、それは常に認証のために人間を必要としていたからです。そしてそれがStripeがここで埋めているギャップです。
彼らのデータベースは約350ミリ秒、つまり1秒の3分の1で準備完了します。開始は無料です。非アクティブ時にはゼロにスケールします。すべての設計選択は、エージェントが構築しているものをどれだけ迅速にプロビジョニングできるかに最適化されています。人間のスピード、ダッシュボードクリックのためではありません。
ここではターミナルアクセスを前提としています。ここにはまだいくつかの欠けている部分があると思います。エージェント間決済の周りで成長が見られるでしょう。エージェントコンピュートパターンにマッピングされる従量制課金の周りで成長が見られるでしょう。動的な予算配分の周りで成長が見られるでしょう。エージェントAは人間の承認なしでこれだけのドルを使うことができ、エージェントBは人間の承認ありでこれだけのドルを使うことができるというような。
構築する可観測性レイヤーがたくさんあるでしょう。これは、Stripeがいつものように優れた製品決定を下したケースだと思います。彼らはそれで知られていますし、これは存続するものです。これは、エージェントがウェブ上で構築する方法にとって、すぐに基本的なインフラストラクチャのように見えます。
この分野にはもう少しプレーヤーが出てくると思いますが、基本的には人間の可読性優先ではなく、エージェントの読みやすさとエージェントの構築可能性に焦点を当て、その上に人間の可観測性を載せるというものになるでしょう。しかし、いずれにせよ、エージェント経済の未来のようなものでは、プロビジョニングと課金が必要になります。だから、それは新しく到着したばかりですが、ここに留まるものです。
オーケストレーションと調整
さて、最後のレイヤーはオーケストレーションと調整です。これは、複数のエージェントのパワーを活用できるため、スタックの中で最大の機会です。また、現在大きなギャップでもあります。エージェントは、フォールバック処理、監査証跡、コスト管理を伴って、大規模に他のエージェントと確実に作業する必要があります。そしてそれを正しく行うことは非常に重要です。
そしてこれについて上手くできていることは本当に少ないのです。そしてそれは関心の欠如のためではありません。Gartnerは、2024年第1四半期から2025年第2四半期の間にマルチエージェントシステムの問い合わせが1,445%急増したと報告しました。14倍の急増ということですよね。2026年はまた上昇するでしょう。
率直に言って、現在のツールはフレームワークレベルにあり、インフラストラクチャレベルにはありません。
LangChainを使えばマルチエージェントワークフローを立ち上げることができます。しかし、ノートブックで3つのエージェントを立ち上げることができることと、障害回復、コスト管理、監査ログ、人間へのエスカレーションパスを持つエンタープライズシステム全体で50のエージェントを確実に実行できることの間のギャップ。その後者の部分、私たち全員が必要としているものは、私たちが今すべて手作業でローリングしているものです。
個々のエージェント能力は、私たちがほぼ解決したものです。欠けているのは、それらの能力を組み合わせ可能で並列で信頼できるものにするレイヤーです。だから、この分野で構築している場合、ここにまだ存在していないが存在する必要があるものがあります。
第一に、エージェントのスケジューリングとライフサイクルレイヤーが必要です。
コンテナの意味ではありませんよね。Kubernetesコンテナだと言っているわけではありません。エージェントの作成、割り当て、ヘルスチェック、スケーリング、終了をマネージドサービスとして処理する何かが必要だと言っているのです。
第二に、並列エージェント作業のために一から構築されたマージと調整インフラストラクチャが必要です。
5つのエージェントが関連するタスクに同時に取り組む場合、マージキューが必要で、競合検出が必要で、解決プロトコルが必要です。そして今日、これは一束のダクトテープと一束のGitワークツリーのようなものです。もっともっと良くできます。
第三に、監督階層が必要です。他のエージェントを監視、評価、コース修正するメタエージェント。
自分でコーディングしなければならないフレームワークパターンとしてではなく、私たちの多くが今やらなければならないように、設定できるインフラストラクチャとして必要です。
財務可観測性が必要です。複数のエージェントワークフロー全体で、このエージェントは何を使ったか。結果の品質はどうだったか。成功したタスクあたりのコストは。これはエージェント向けのFinOpsのようなもので、全く新しいです。ほとんど存在しません。
最後になりましたが、標準的な障害パターンと標準的な回復パターンが必要です。エージェントのツールコールが失敗した場合、個々のチームベースでそれを作り上げるのではなく、何が起こるかについての標準的なプロビジョニングが必要です。ツール、フレームワーク、そしてPMがランチに何を食べたかに依存して、エージェントが回復したかどうかを決めるべきではありません。
次世代インフラストラクチャ企業が生まれる場所
見てください、このレイヤー、このオーケストレーションレイヤー、これは次のインフラストラクチャを定義する企業が構築されるレイヤーです。エージェントのオーケストレーション問題は、Kubernetesが解決したコンテナオーケストレーション問題と構造的に類似しています。コンピュート自体ではなく、スケジューリング、スケーリング、ヘルスチェック、エンタープライズ規模でコンピュートを使用可能にするライフサイクル管理です。
だから、インフラストラクチャグレードでオーケストレーションを解決する人は、エージェントスタックの中で最も価値のあるポジションを所有することになります。そして勝者を呼ぶには早すぎます。
ビルダーへの3つの教訓
では、これはすべて何を意味するのでしょうか。スタックの6つのレイヤーを見てきました。今日エージェントスタック上で構築しているビルダーにとって、これは何を意味するのでしょうか。2026年に取るべき3つの教訓を提供したいと思います。
今年は大きく変わらないと思います。スタックは大幅に進化しなければなりません。
第一に、今のところ、信頼性は間違った方向に複利計算されています。エージェントが5つの異なるプリミティブに依存している場合、エンドツーエンドの信頼性は5つの異なる信頼性の積です。各々が99%のアップタイムを提供する場合、システムは95%しか提供しません。
各々が97%の場合、86%です。お分かりでしょう。本質的に、あなたは今、すべてのエージェントプリミティブの負債を積み重ねています。なぜなら、この層の多くを手作業で構成しなければならないからです。信頼性を設計するのは最近本当に難しいです。
第二に、過渡期のロックインは今年実際のリスクです。アイデンティティとしてのメールのようなシム上で構築すると、ネイティブプロトコルが到着したときに移行コストが発生します。
採用するすべてのシムは、それが標準になるか、喜んで交換するものになるかという賭けです。だから、あなたの選択について考え、何が本当にエージェントネイティブで、何が実用的な賭けなのかについて戦略的に考え、今後2、3年で何が正しいと思うかについて選択してください。
私たちは皆、これを一緒に生きています。メールが素晴らしいゴキブリのように永遠に生き残るのか、それとも実際にメール後の真のエージェント間通信を得るのかは言えません。
第三に、これは大きなものですが、エージェントの無秩序な拡散が来ています。これは2018年にマイクロサービスを悩ませたのと同じ問題です。文字通りAmazonやMicrosoftのような場所からスタートアップに人々が入ってきて、このスタートアップが小さなコードベースを持っていて、ただシップしたいだけなのに、彼らが最初にやったことは、まあ、すべてマイクロサービスアーキテクチャである必要があると言うことでした。
必要でしたか。いいえ、必要ではありませんでした。モノリスです。速くシップしてください。同じように、人々はエージェントを見て、すべてがエージェントである必要があると言っており、それがエンタープライズ全体に無秩序に拡散しており、予期しない行動を取っており、可観測性がなく、オーケストレーションレイヤーがないため、ただ推測してバイブでやっているだけです。
それは、人々が今オーケストレーションレイヤーに投資しない限り、2026年を通してますます大きな問題になるでしょう。はい、手作業でローリングしなければならないでしょう。
スタックリテラシーの重要性
見てください、新しいビルダースキルが何だと私が考えているかについて話しました。ここでそれらを繰り返すだけです。コンテキストエンジニアリングは最近非常に重要です。なぜなら、エージェントに何を供給するかが、駆動する結果にとって重要だからです。
評価駆動開発は重要です。なぜなら、人間がレビューするコードから生じるボトルネックの多くを避けるために、エージェントが自律的に結果に対して駆動できるようにする必要があるからです。そしてスタックリテラシーは本当に重要になるでしょう。スタックのどのレイヤーがあなたの競争優位性であり、その理由を知り、それに対して容赦なく構築する必要があります。
エージェントの世界では、生き残るビルダー、あなたが起業家としてこの分野で構築しているかどうか、個人としてオープンClaudeで構築しているかどうか、リーダーとして構築していてスタック上で構築してエージェントを実装する必要があるかどうかに関わらず、生き残る人は、スタックリテラシーを持たなければなりません。
これらの6つのレイヤーがどのように機能するかを理解する必要があります。スタックのどの部分が変化していて、それらがあなたのビジネスにどう影響するかについて注意深く見守る必要があります。スタックリテラシーの欠如に対する言い訳はありません。そしてこれが重要な理由の一部、私がこのチャンネルでこれについて話している理由の一部は、あなたがそれを持っていなければ、ビジネスリーダーとしてさえ、CTO以外、非技術リーダーとしてさえ、大変なことになるからです。
なぜなら、エージェントは非常に多くのビジネス成果とビジネスレバレッジを駆動するようになっており、それはスタックのこれらの部分に非常に依存しているからです。だから、カスタマーサクセス全体に膨大なブラスト半径を持つエージェントを持ちたいなら、それを駆動しているものを理解する必要があります。スタックのどの部分が実際に機能しているのか。スタックのどの部分を手作業でローリングしているのか。あなたのシムは何で、何に賭けているのか。
その詳細な理解がなければ、あなたはただエージェントが機能することを望んで祈っているだけです。
それは長期的には良い戦略ではありません。だから、私たちはより良いスタックリテラシーを持つ必要があります。そしてそれがこのビデオが重要な理由です。だから、エージェントスタックを理解していない誰かとこれを共有してください。なぜなら、LinkedInのバズワードをたくさん頭の中に持っているが、エージェントスタックを理解していない人がたくさんいることを保証するからです。
そしてそれは多くの苦しみと痛みにつながるでしょう。率直に言って、多くのICエンジニアリングチームにとって、彼らは意味をなさないものを構築するよう求められるでしょう。頑張ってください。それでは。
コメント