NAME
agentic-infrastructure-stack — エージェントインフラストラクチャと新しいバックエンド
SYNOPSIS
cat agentic-infrastructure-stack.md
DESCRIPTION
私たちはエージェントのフレームワークについてよく話してきました。 LangGraph、CrewAI、AutoGen、さまざまな SDK、ループ、ツール呼び出し、メモリ、プランナー、批評家、スーパーバイザー。役に立つ言葉ばかりです。しかし、実際に使用されているエージェントを見れば見るほど、興味深い部分はフレームワーク レベルの下に移動しているように思えます。
問題はもはや、「ステップ モデルに思考をさせるにはどのライブラリを使用すればよいか?」というだけではありません。
本当の疑問は、このエージェントがデモ活動をやめた後、どこに住むのかということです。
深刻なエージェントはモデルを呼び出してテキストを返す関数ではないためです。小規模な分散システムです。コンテキストを読み取り、ツールを使用し、コードを実行し、ファイルを操作し、決定を記憶し、許可を求め、うまく失敗し、再起動し、ログを残し、予算を浪費せず、本番リポジトリ内でブルドーザーに変わってはなりません。
骨組みはハンドルです。インフラとは、道路、ブレーキ、ガレージ、保険、そして鍵の所在を知っている人です。
今話題になっているので
2023 年と 2024 年の会話は非常にモデル中心でした。どのLLMですか?コンテキストはどれくらいですか?いくらかかりますか？彼はプログラミングがどれくらい得意ですか?
2025 年と 2026 年になると、話は変わります。モデルは実際の作業を実行するには十分に優れていますが、だからこそ、ランタイム、セキュリティ、コネクタ、ID、可観測性、コード実行、デプロイメント、ロールバックなどの退屈な部分が目に見えるようになります。
それは魔法から工学への自然な移行です。
エージェントが応答を生成する必要があるだけの場合は、チャットで十分です。プル リクエストを開いたり、データベースにクエリを実行したり、CRM を呼び出したり、ジョブを開始したり、サイトを移動したり、Slack を読んだり、コードをコンパイルしたり、ドキュメントを更新したりする必要がある場合、オペレーティング システムが必要です。
文字通りの意味ではありません。組織的な意味で。
最初の部分: エージェントが持続できるランタイム
エージェントは多くの場合、段階的に作業します。状態を見て、アクションを選択し、ツールを使用し、結果を観察し、計画を更新し、これを繰り返します。
このループが 1 つの HTTP リクエスト内に存在すると、すぐに問題が発生します。一部の動作が遅いです。人間の入力を待っているものもあります。いくつかは失敗し、再試行する必要があります。一部は展開またはタイムアウトを乗り越える必要があります。
ここで、耐久性のあるワークフロー、キュー、ジョブ バックグラウンド、ステート マシンが活躍します。これらは魅力的ではありませんが、デモでは賢く見えるエージェントと、コーヒーを飲みに行く間仕事をしておいても大丈夫なエージェントとの違いです。
私にとって、エージェント ランタイムは非常に具体的な質問に答える必要があります。
- あるステップと別のステップの間の状態をどこに保存すればよいですか?
- プロセスが途中で停止した場合はどうなりますか?
- 一時停止して承認を求めてもいいですか?
- 彼がなぜその選択をしたのかを理解するために、ランを再生してもいいですか?
- 期間、メモリ、ツール、コストを制限できますか?
Vercel は、Web アプリケーション内でエージェントを構築するための AI SDK、機能、ワークフロー、ツールを使用して、この分野に力を入れています。しかし、重要なのはヴェルセルだけではない。重要なのは、エージェントには単一のエンドポイントではなく、動作可能なホームが必要であるということです。
2 番目の部分: サンドボックス。エージェントは壊れることなく汚れることができなければならないため
エージェントがコードを作成したりコマンドを実行したりするとすぐに、サンドボックスが必要になります。
専門的な言葉のように思えますが、アイデアは国内的なものです。彼に作業台を与えるのです。ファイルを開いたり、依存関係をインストールしたり、テストを実行したり、実験を行ったり、出力を生成したりできます。もし彼が間違っていたとしても、あなたは被害を食い止めたことになります。うまくいった場合は、その結果を宣伝します。
エージェント サンドボックスにはいくつかのプロパティが必要です。
- 分離されたファイルシステム。
- CPU、メモリ、時間制限。
- 制御されたネットワーク;
- シークレットは必要な場合にのみマウントされます。
- 完全なログ;
- アーティファクトをエクスポートする可能性;
- 必要に応じて、実行の間にクリーン リセットを実行します。
Vercel Sandbox はまさにこの方向に進んでいます。つまり、メイン アプリケーション ランタイムですべてを実行することなく、コードの実行、依存関係のインストール、ファイルの操作、アーティファクトの生成を行うための分離された環境です。
このことは思っている以上に重要です。多くのエージェント プロトタイプは、モデルから実際のシステムに直接ジャンプします。モデルはツールを呼び出すことができます。ツールは何かを行うことができます。最初の間違ったコマンド、最初の依存関係が間違った場所にインストールされ、最初のトークンがログに記録されるまでは、すべてがエレガントに見えます。
サンドボックスとは、大人の言い方です。「先に進んでください、ただしここにあります」という意味です。
3 番目の部分: MCP とコネクタの問題
モデル コンテキスト プロトコルは、エコシステムの最も興味深い部分の 1 つとなっています。これは、モデルが外部ツールを検出して使用する方法など、すぐに管理できなくなるものを標準化しようとするためです。
標準がなければ、それぞれの統合は小さな島になってしまいます。 GitHub 用のコネクタはある方法で実行され、Slack 用のコネクタは別の方法で実行され、1 つは異なるセマンティクスを持つデータベース用で、もう 1 つは何もないように見えるブラウザ自動化用です。
MCP は、クライアントとサーバー間の共通言語 (ツール、リソース、プロンプト、承認、トランスポート、ディスカバリー) を提案します。これはガバナンスとセキュリティを魔法のように解決するものではありませんが、文法を与えてくれます。
そして文法も重要です。エージェントが多くのツールに接続できる場合、問題は単に「できるか?」ということではありません。問題は、「彼は自分に何ができるのか、どのような制限があるのか、誰に代わって、どのような痕跡を残せるのかを理解しているのか？」ということだ。
私にとって、MCP は「ツール呼び出しを行う」ため誇大広告ではありません。すでにそれを行っています。これが誇大広告であるのは、重心が単一の統合からツールの運用カタログに移るからです。
優れたエージェント アーキテクチャでは、MCP は一種のパッチ パネルになります。
- コードと問題については GitHub にアクセスしてください。
- 会話のコンテキスト用の Slack。
- 計画された作業の場合は Linear または Jira。
- 分析用の読み取り専用データベース。
- 外部サイト用に制御されるブラウザまたはスクレイパー。
- 文書保管場所。
- 分離された実行環境。
- 内部システムは厳格な権限で公開されます。
難しいのは、ポリシーフリーのツール カタログは、混乱を生み出すためのより洗練された方法にすぎないということです。
4 番目の部分: ID と権限
これは多くのデモが見て見ぬふりをしている分野だ。
エージェントは誰かの代わりに行動します。したがって、アクションの主体が誰であるかを明確にする必要があります。
ユーザー権限を使用しているのでしょうか?サービスアカウントですか？ワークスペースのこと？一時的または永続的なアクセス権はありますか?すべてのリソースを読むことができますか、それとも一部のリソースだけを読むことができますか?書いてもらえますか？キャンセルできますか？彼は実際の人にテキストメッセージを送信できますか?
これらの質問にうまく答えられないと、遅かれ早かれ、家の鍵を誰に渡したのか覚えていないアシスタントを作成することになります。
私が気に入っている経験則は次のとおりです。エージェントは人間以上のことはできず、人間以下のことができる必要があります。そして、より危険なことをしなければならないときは、立ち止まって尋ねなければなりません。
これは、OAuth、トークン スコープ、シークレット管理、監査ログ、ツール ポリシー、ホワイトリスト、承認ステップを意味します。あまりロマンチックなものではありません。必要なもの。
5 番目の部分: メモリとコンテキスト、ただしゴミは蓄積しない
エージェントには記憶力が必要ですが、屋根裏部屋になると記憶力は危険です。
メモリには少なくとも 3 つのタイプがあります。
- 実行メモリ: この実行で何が起こったのか。
- プロジェクトの記憶: 慣例、決定、制約。
- 個人またはチームの記憶: 好み、口調、儀式、プロセス。
プロンプトにすべてを入力するのが近道です。機能しなくなるまで機能します。有用なメモリは、インデックス付け、更新、期限切れ、検証、引用可能にするなどの処理を行う必要があります。
覚えが悪いエージェントは、覚えていないエージェントよりも悪いです。自信を持って話しているからです。
したがって、インフラストラクチャには、検索、指示ファイル、知識ベース、必要な場合の埋め込みだけでなく、クリーニングも含める必要があります。私たちには記憶の文化が必要です。何が入ってきて、誰がそれを承認し、いつ衰退するのか、どうやって修正するのか。
6 番目の部分: 可観測性、評価、リプレイ
エージェントが間違いを犯した場合、「モデルを呼び出した」ログだけでは十分ではありません。
ルートを見たいのです。彼はどのような文脈を受け取ったのでしょうか?どのようなツールが利用可能でしたか?どのツールを選びましたか?どのような引数で?どのような反応が得られましたか?費用はいくらかかりましたか?どこで詰まってしまったのでしょうか？人間は何かを承認しましたか？エラーはモデル、ツール、プロンプト、データ、または権限のエラーですか?
ここでのエージェントは、チャットボットというよりも分散システムに似ています。
テキスト ログだけでなく、判読可能なトレースが必要です。実行をリプレイできる必要があります。既知のタスクに関して同じエージェントの 2 つのバージョンを比較する必要があります。私たちは回帰を測定する必要があります。「応答が良くなる」だけでなく、「要求されていないファイルに触れることなく適切なチケットを閉じる」ことができます。
エージェント評価はアクションが含まれるため、テキスト評価よりも困難です。期待される文字列を比較するだけでは十分ではありません。シーケンス、副作用、成果物の品質、時間、コスト、人間の介入の数を考慮する必要があります。
面白いことに、私たちは常にソフトウェア エンジニアリングに戻ってきます。テスト、環境、トレース、ロールバック。ただし、コードによって次に何を行うかが決定される点が異なります。
7 番目の部分: ヒューマン インターフェイス
エージェントはチャットに参加するだけである必要はありません。
一部のエージェントはボードを必要とします。その他、ステータスとログのページ。その他「承認」ボタン。インラインコメントの追加。 CLI のさらに別の例。
UI の動作が変わります。エージェントを制御する唯一の方法が長いメッセージを書くことである場合、ユーザーはエージェントに曖昧な指示を与えることになります。しかし、計画、差分、ソース、リスク、次のアクションを理解していれば、正確に介入することができます。
適切なエージェント インフラストラクチャには、コントロール サーフェスが含まれます。
- 現在のステータス。
- 編集可能なプラン;
- 生産された人工物。
- 差分;
- 承認リクエスト。
- 年表;
- 停止ボタン;
- 再試行ボタン;
- 表示される権限。
些細なことのように思えますが、そうではありません。 「不気味な AI」と「信頼できるアシスタント」の違いは、多くの場合、後者がその役割を示すかどうかだけです。
精神的なスタック
今日これを描くとしたら、最小エージェント スタックは次のようになります。
- モデル: 推論、生成、ツール呼び出し、必要に応じてマルチモーダル。
- オーケストレーション: ループ、ステップ、プランナー、ポリシー、人間参加型。
- 耐久性のあるランタイム: ワークフロー、キュー、再試行、一時停止、再開。
- サンドボックス: コードの実行、分離されたファイル システム、制限、アーティファクト。
- ツール層: MCP、内部 API、ブラウザ、データベース、リポジトリ。
- ID レイヤー: OAuth、スコープ、シークレット、監査、ポリシー。
- メモリ層: プロジェクトのコンテキスト、取得、指示、有効期限。
- 可観測性: トレース、リプレイ、評価、コスト、品質のメトリクス。
- 製品の表面: 十分な場合はチャット、必要な場合はダッシュボード、重要な場合はレビューします。
エージェント フレームワークは主にポイント 2 とポイント 1 の一部をカバーします。残りが実際の作業です。
実際にやること
チームが私に「本番環境にエージェントが欲しい」と言ったとしても、私は 10 人のエージェントから始めるつもりはありません。
私なら、小規模で反復的で観察可能なワークフローから始めます。たとえば、メンテナンス PR をオープンし、クローズされた問題からドキュメントを更新し、週次レビューを準備し、重複したバグを優先順位付けし、影響を受けるファイルのテストを生成します。
次に、非常に明確な制限を設定します。
- ブランチまたはサンドボックスなしで書き込みを行うことはできません。
- プロンプトに秘密はありません。
- ホワイトリスト内のツール。
- 外部アクションに対する人間の承認。
- 必須のログとトレース。
- 実行ごとの予算。
- 出力は常に検査可能。
そうして初めて私は拡張することができます。
モデルが間違えたからといってエージェントが失敗するわけではありません。それらが失敗するのは、わかりにくい許可や演劇的な期待を伴う曖昧な環境に置いたためです。
私の読書
エージェントのインフラストラクチャは良い意味で退屈です。
デモで拍手するような部分ではありません。これは、月曜日の朝に、実際の人々、実際のデータ、実際の結果を使用してデモを実際に使用できるようにする部分です。
エージェントの将来は、誰が最良のロールモデルを持っているかだけで決まるわけではありません。それは、彼を働かせるのに最適な場所を構築する人によって決まります。実験するときは孤立し、必要なときに接続され、常に観察可能で、基準に基づいて権限が与えられ、分からないときは立ち止まるほど謙虚です。
そこでエージェントはおもちゃではなくなり、インフラとなるのです。
ソース
METADATA
- date: 2026-06-30
- reading: 2 min
- author: Filippo Spinella
- tags: AI, Agents, Infrastructure, Developer Tools, Vercel