エンタープライズ全体でのAIエージェントのスケーリング：Runtime入門

AIエージェントの可能性は、長らく開発者のIDEを中心に語られてきましたが、現代のエンタープライズにおける現実は、自動化のニーズがエンジニアリング部門をはるかに超えて広がっているということです。財務、営業、サポート、マーケティングに至るまで、あらゆるチームがAPI、CLI、データウェアハウスの複雑なネットワークを管理しています。課題は常に、これらのチームにコーディングエージェントの力を提供しつつ、彼ら（あるいはAI）に本番環境への無制限なアクセス権を与えないようにすることでした。

Runtime (YC P26) は、チームベースのエージェントに専用の「runtime」を提供することで、この課題に対処します。エージェントを単なるチャットボットとして扱うのではなく、Runtimeは、独自の環境、ツール、およびガバナンスレイヤーを備えたサンドボックス化された実体として扱い、非技術的なチームがテキストだけでなく、実際の業務を安全にデリバリー（ship）できるようにします。

エージェント・ワークフローのための統合インフラストラクチャ

エージェントの導入を試みるほとんどの企業は、サンドボックス、オーケストレーション、オブザーバビリティ、シークレット管理といった「配管（plumbing）」の構築に数ヶ月を費やしています。Runtimeは、このインフラストラクチャを抽象化し、ビジネスユニットの特定のコンテキストに合わせてエージェントをデプロイできる、準備済みの環境を提供します。

環境のカスタマイズとスピード

Runtimeは、チームが実際のワークフローを反映した環境を構築することを可能にします。これには以下が含まれます：

  • Tool Integration: npm, brew, mise, または GitHub を介して、あらゆる CLI、API、または MCP (Model Context Protocol) サーバーをインストールする能力。
  • Rapid Booting: 環境をスナップショット化できるため、すべての新しいセッションが数分ではなく数秒で起動します。
  • Broad Connectivity: Snowflake, BigQuery, Stripe, HubSpot, Zendesk, および GitHub を含む、重要なエンタープライズ・システムへの即時接続。

多様な役割のための専門化されたエージェント

単一の汎用AIではなく、Runtimeは特定のビジネス機能に合わせた専門化されたエージェントの作成を推奨しています。例として以下が挙げられます：

  • Incident Inspectors: #incidents チャンネルでタグ付けされ、アラートを調査する。
  • Sales Prospectors: #revenue の成長とリードジェネレーションに焦点を当てる。
  • Support Triagers: カスタマーインボックスの初期仕分けと回答案の作成を自動化する。

これらのエージェントは、チャンネルを監視することでプロアクティブに動作したり、Slack, Linear, GitHub, または Jira を介したメンションによってリアクティブに動作したりすることができます。

セキュリティ、ガバナンス、および「Human-in-the-Loop"

エンタープライズにおけるエージェント採用の主な障壁の一つは、AIが本番データベースで壊滅的なミスを犯すことへの懸念です。Runtimeは、このリスクを軽減するために、いくつかの保護レイヤーを実装しています。

サンドボックス化とデータプライバシー

エージェントは生の本番データを使用しません。代わりに、ミラーリングされた、あるいはサンプリングされたデータを使用するサンドボックス内で動作します。Runtimeは、PII（個人情報）の難読化と行レベルのスコーピングをサポートしており、エージェントが許可されたデータのみにアクセスできるようにします。

制御された本番環境への書き込み

不正な変更を防ぐため、本番環境への書き込みは制限されています。ライブシステムへの変更は、通常、レビューされたアクションまたはプルリクエスト (PR) を通じて行われます。これにより、本番環境に導入されるコードやデータの変更に対して、人間が最終的な決定権を持つことが保証されます。

オブザーバビリティとコスト追跡

プラットフォームチーム向けに、Runtimeはすべてのエージェント・セッションへのライブ・ビジビリティを提供します。これには、エージェントの「思考の連鎖 (chain of thought)」、ツール呼び出し、およびファイル変更が含まれます。さらに、エージェント、ユーザー、およびチームごとに、詳細なコスト追跡が可能であり、組み込みの支出制限と承認ゲートが備わっています。

デプロイの柔軟性

企業によってコンプライアンスのニーズが異なることを認識し、Runtimeは2つの主要なデプロイ・パスを提供します：

  1. Hosted Cloud: 迅速なデプロイのためのマネージド版。
  2. Self-Hosted: 最大限の制御を得るために、企業独自のクラウド内で Runtime を完全に実行し、独自のモデル、サンドボックス、およびストレージを利用する機能。

コミュニティの視点と検討事項

Hacker News での初期の反応は肯定的でしたが、コミュニティからは、このようなシステムの長期的な生存可能性に関して、いくつかの技術的および運用上の質問が提起されました。

「PR Fatigue」の問題

あるユーザー (@nilirl) は、非技術的なチームのワークフローに関する重要な点を指摘しました。もしマーケティング・エージェントがユーザーの好ましくない変更を行うプルリクエスト (PR) を生成した場合、そのエラーを修正するためのフローが直感的である必要があります。エージェントが非エンジニアに業務をデリバリー（ship）し始めるにつれ、「修正」するためのインターフェースが、エージェントがそもそもコードを生成する能力と同じくらい重要になります。

ライセンスとオープンソース

ライセンス・モデルについても質問が提起されました (@zuzululu)。具体的には、Runtime のアプローチを、完全にオープンソースの「エージェント・サンドボックス」と比較しています。厳格な FOSS (Free and Open Source Software) 要件を持つチームにとって、デリケートな判断が必要となるのは、著作権で保護された製品と、真にオープンソースのツールとの違いです。

統合の複雑さ

技術的なユーザー (@theahura) は、キー管理の具体例について質問しました。具体的には、 Runtime が、ディスクにキーを存储 (store) する必要があるツール（AWS CLI のようなもの）をどのように扱うのかという点です。これは、エージェント・インフラストラクチャにおける永続的な課題を浮出しさせています： 「ワンクリック」でのオンボーディングの容易さと、レガシー CLI ツールのセキュリティ要件とのバランスをとりながら、どのように管理するかという点です。n

Sources