エンタープライズ向けエージェント AI の環境構築に必要な要素
本文の状態
日本語全文を表示中
詳細モードで約9分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
MIT Technology Review AI
インテルはエンタープライズ向けエージェント AI の実装において、推論単体ではなくシステム全体の最適化が重要であると指摘し、vCPU 密度やレイテンシ監視などの具体的な運用指針を提示した。
AI深層分析を開く2026年8月4日 01:28
AI深層分析
キーポイント
システム全体としての課題認識
エージェント AI は推論能力だけでなく、ワークフローオーケストレーション、データアクセス、ガバナンスを含むシステム全体の課題であると定義している。
新しい評価指標の提案
LLM の評価に依存せず、タスク成功率、コスト、レイテンシ、スループット、vCPU 当たりエージェント密度などの6つの実用指標を提唱している。
ベンチマーク手法の改良
インテルは Terminal-Bench を拡張し、LLM の応答を記録・再生する決定論的な手法により、推論以外の部分でのパフォーマンスボトルネックを特定可能にした。
スケーリング戦略の指針
システムはデフォルトでスケールアウト(並列化)を採用し、特定の計算負荷やアーキテクチャ制約がある場合のみスケールアップ(垂直拡張)を予約するよう推奨している。
エージェント密度の設計原則
エージェント数を計算リソースで正規化した密度(vCPU あたりのエージェント数)が飽和の主要指標となる。インタラクティブなコパイロットは応答時間を重視して低密度に、バッチ処理は高密度に設定することでサービスレベルとコストを最適化する。
重要な引用
Agentic AI is a larger systems problem, not just one of inference.
Plan capacity is done using agents per virtual CPU (vCPU) density, not agent count.
Monitor agent task latency, not just average CPU utilization.
Agentic AI requires a new form of observability: Average compute (CPU) utilization is a weak primary performance monitoring signal for agentic workloads.
編集コメントを表示
編集コメント
インテルは、エージェント AI の普及における最大の障壁が推論そのものではなくシステム全体の設計にあると指摘し、実務的な解決策を提示している。これは単なる技術解説を超え、現場のアーキテクトが直面する具体的な課題に対する即効性のあるガイダンスとなっている。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
企業にとって、エージェント型 AI の真価は単なるチャットボットの改善にとどまりません。それは人々、ビジネスワークフロー、データ、システムを横断して業務タスクをエンドツーエンドで実行するソフトウェア・エージェントです。エージェントを実行するのに最も適したプラットフォームとは、適切な CPU 性能、耐障害性のあるデータアクセス、ポリシー対応型のツール利用、観測可能性(オバザビリティ)、メモリ管理、そして予測可能な計画とスケーリング能力を備えたものです。

これらの依存関係をより深く理解するため、インテルは数千回に及ぶエージェント型 AI の負荷実験を行いました。その初期の知見から、企業リーダーが押さえるべき 5 つの実践的な教訓を導き出しました。
- エージェント型 AI は推論だけでなく、システム全体の課題である。
- 既存のエージェント型 AI ハーネスの多くは機能に限界があり、システム全体の性能を評価できていない。
- 容量計画はエージェント数ではなく、仮想 CPU(vCPU)あたりのエージェント密度に基づいて行うべきだ。
- CPU 利用率の平均値だけでなく、エージェントのタスク遅延も監視する必要がある。
システムホスティングではデフォルトでスケールアウトを採用し、1 エージェントあたりの計算負荷が重いワークロードやアーキテクチャ上の制約がある場合にのみ、スケールアップを確保すべきだ。
推論を超えて:エージェントによるワークフロー自動化
エージェント型 AI は、単なる大規模言語モデル(LLM)の推論を超えたものです。その企業価値は、システム全体、タスクのオーケストレーション、データアクセス、ツール実行、レイテンシ管理、ガバナンス、そしてスケーラブルなインフラストラクチャに依存します。エージェントとは、目標指向の自動化された企業ワークフロープロセスであり、多段階のタスクを計画し、ツールを呼び出し、結果を読み取り、何かが失敗した場合は再試行を行います。したがって、企業のエージェントは推論の問題だけでなく、システム全体の課題なのです。
良い状態の定義
現在、多くのエージェント型 AI の指標は、使用される LLM の評価に焦点を当てています。しかし、プラットフォームチームには、タスクの実行にかかる時間、ファームがサポートできるエージェントの数、実行プロセスの最終段階でユーザーがどのような体験をするか、そして複数のエージェントが同時に動作した際の費用変化についても把握する必要があります。
より有用な企業視点では、以下の 6 つの指標を重視します。
- タスク成功率
- タスクあたりのコスト
- タスクあたりの時間
- タスクスループット
- エージェント密度(vCPU あたりのエージェント数)
- レイテンシ
これらを組み合わせることで、企業 AI 運用担当者が関心を持つ以下の問いに答えることができます。システムは期待通りに動作しているか?システムが持続できるエージェント数はどれくらいか?より多くのエージェントをサポートするためにどのようにスケールすべきか。
堅固な基盤の上に構築する
エージェント型 AI のワークロードパフォーマンスについてより深い洞察を得るため、Intel はオープンソースのベンチマークハッチである Terminal-Bench を拡張しました。これには、AI エージェントの評価に加え、プロファイリング、テレメトリ、再生機能が含まれています。この拡張により、LLM 推論以外の部分でエージェントが時間を費やしている箇所を特定することが可能になりました。
ベンチマーク拡張では、LLM の応答を決定論的な記録再生(record-replay)的方式で利用し、エージェントの性能と LLM のばらつきを分離しました。LLM の応答は一度だけ記録され、その後のすべての実行で同一の内容が再生されるため、実行ごとの変動が抑えられ、比較のためのより信頼性の高い基盤が構築されます。
Terminal-Bench で採用されたタスクミックスは、あえて広範囲に設定されました。コンパイル、テスト、データベース操作、ブール論理、解釈処理、レイ tracing、圧縮、線形代数、動画トランスコード、機械学習のトレーニングなどが含まれています。こうした多様なタスク群が、実務の企業環境における発見の妥当性を高めています。
エージェント AI の 3 つの次元
エージェント AI の導入は、以下の 3 つのフェーズで進めるべきです。
エージェント数ではなく密度を計画する: 最初の規模設計ルールは、利用可能な計算リソースに対してエージェント数を正規化することです。エージェント密度(vCPU あたりのエージェント数)が飽和状態を示す最も重要な指標となります。例えば、8 vCPU のシステムで 10 エージェント、16 vCPU のシステムで 20 エージェントというように、密度が同じであれば両者は同様の挙動を示します。これにより、アーキテクトはインスタンスサイズやプロセッサ世代を超えて、キャパシティを比較する汎用的な方法を得られます。
適切な密度はビジネス目標にも依存します。対話型コパイロットやユーザー向けアシスタントでは応答時間が重要となるため、低密度の構成が望ましいです。一方、IT ワークフローなどのバッチ処理ワークロードであれば、より高密度で実行できるケースが多いでしょう。これにより、チームはサービスレベル目標(SLO)と総所有コスト(TCO)を踏まえて、ファーム全体の調整を実践的に行うことができます。
エージェント型 AI には、新しい形の観測性が求められます。平均計算リソース(CPU)利用率は、エージェントワークロードにおける主要なパフォーマンス監視指標としては弱すぎます。エージェントは通常、モデルからの応答を待機する時間と、短時間の計算集約的な作業を交互に繰り返すためです。この「バースト型」のパターンにより、バーストが発生してキューが形成され、ユーザーエクスペリエンスが遅延しているにもかかわらず、平均利用率は許容範囲内に見えることがあります。
より良い先行指標となるのはタスクレイテンシ(P95)です。これは、平均的なタスク処理時間が実際に悪化する前に、ワークフローが待ち状態に入り始めていることを示してくれます。実用的な運用モデルとしては、まず P95 レイテンシでアラートを発令し、その後、持続するタスク処理時間を確認して問題の特定を行うのが効果的です。
デフォルトではスケールアウトを推奨します。スケールアウトはシステム数を増やすことで総エージェント容量を増やし、一方、スケールアップは計算集約的なバーストが発生するエージェントに対して、単一システムの CPU コア数やメモリを追加するものです。
テストデータによると、スケールアウトの方が通常はデフォルトとして優れています。これは、エージェントが一般的に半独立しており、1 エージェントあたりのバースト負荷も限定的であるという事実と合致しています。また、全体のパフォーマンス向上、高可用性のサポート、コスト削減の可能性、そしてプラットフォームが成長しても目標のエージェント対 vCPU 比を維持しやすくするという利点があります。
ただし、エージェントが並列計算をより多く必要とする場合や、共有状態の制約によりパーティショニングが困難な場合、メモリの局所性が重要となる場合、あるいはライセンス上の制限がある場合は、スケールアップを検討する必要があります。
ビジネスへの影響をどう捉えるか。エージェント型 AI が最初にビジネス価値を生み出すのはどこか。すでにコード化されたルールと測定可能なサービスレベルを持つワークフローに自動化層を付加することで、本番環境での成果を出している組織があります。その対象は、コード作成、回帰テストファーム、チケットの選別、市場分析、セキュリティレビューといった領域です。
したがって、エージェント型 AI にとって理想的な企業内の役割とは、新奇性を追う実験的なユーザーではありません。サイクルタイムと生産性の向上、サービスの品質保護、ポリシーの遵守、そしてコストを考慮した導入拡大を担わなければならない責任あるリーダーです。
エージェント型 AI の価値は、チーム、システム、データ、プロセスにまたがる実務の完了を支援することにあります。企業にとって重要なのはモデル性能の向上だけではありません。AI エージェントがビジネスワークフローを支え、生産性を高め、ガバナンス要件内で運用され、導入拡大に合わせてスケールできる信頼性の高い環境を構築することが最優先課題です。
実際には、エージェント型 AI の成功は、一貫した成果の提供、コスト管理、コントロールの維持、そしてパイロットから本番環境への確実な移行を実現する適切な基盤にかかっています。
この記事は Intel によって制作されました。MIT Technology Review の編集チームが執筆したものではありません。
原文を表示
For the enterprise, the promise of agentic AI is much more than just a better chatbot. It is software agents that execute business tasks end-to-end across people, business workflows, data, and systems. The platform best-suited to run agents is built with proper CPU capacity, resilient data access, policy-aware tool use, observability, memory management, and the ability to predictably plan and scale agents.

To better understand some of these dependencies, Intel performed thousands of agentic AI workload experiments. Our initial findings create and support five practical lessons for enterprise leaders:
Agentic AI is a larger systems problem, not just one of inference.
The majority of existing agentic AI harnesses are limited and do not measure overall system performance.
Plan capacity is done using agents per virtual CPU (vCPU) density, not agent count.
Monitor agent task latency, not just average CPU utilization.
Default to scale-out for systems hosting agents. Reserve scale-up for workloads with heavier per-agent compute or architectural constraints.
Beyond inference: Agents as workflow automation
Agentic AI is more than LLM inference. Its enterprise value depends on the full system, task orchestration, data access, tool execution, latency management, governance, and scalable infrastructure. An agent is a goal-driven automated enterprise workflow process: It plans a multi-step task, calls tools, reads results, and retries when something fails. Enterprise agents are therefore not just an inference problem; they are a systems problem.
Defining what good looks like
Most agentic AI metrics focus on evaluating the LLM used. Platform teams also need to know how long the tasks take, how many agents a fleet can support, what users experience at the end of the execution process, and how costs change as more agents work simultaneously.
A more useful enterprise view looks at six metrics:
Task success rate
Cost per task
Time per task
Task throughput
Agent density (agents per vCPU)
Latency
Together, these answer the questions enterprise AI operators care about: Is the system performing as expected? How many agents can the system sustain? How should it scale to support more agents?
Building on solid foundations
To gain a deeper insight into agentic AI workload performance, Intel extended Terminal-Bench, an open source benchmarking harness for evaluating AI agents with profiling, telemetry, and replay capabilities. This made it possible to understand where the agents spent time beyond LLM inference.
The benchmark extension used a deterministic record-replay of LLM responses to separate agent performance from LLM variability. LLM responses were recorded once and replayed identically across runs, reducing run-to-run variance and creating a more reliable basis for comparison.
The Terminal-Bench task mix used was intentionally broad. It included compilation, testing, database operations, Boolean logic, interpretation, ray tracing, compression, linear algebra, video transcoding, and machine learning training. That wide variety made the findings more relevant to real enterprise environments.
Agentic AI in three dimensions
Deploying agentic AI should be approached in three phases:
Plan in terms of agent density, not agent count: The first sizing rule is to normalize agent count by available compute. Agent density, measured as agents per vCPU, is the leading signal for saturation. For example, 10 agents on an 8-vCPU system and 20 agents on a 16-vCPU system behave similarly if the density is the same. This gives architects a portable way to compare capacity across instance sizes and processor generations.
The right density also depends on the business goal. Interactive copilots and user-facing assistants should favor lower density because response time matters. Batch workloads such as IT workflows can often run at higher density. This gives teams a practical way to tune fleets around service-level objectives and total cost of ownership.
Agentic AI requires a new form of observability: Average compute (CPU) utilization is a weak primary performance monitoring signal for agentic workloads. Agents often alternate between waiting for model responses and then doing short bursts of compute-intensive work. Because of that “bursty” pattern, average utilization can look acceptable even when those bursts are creating queues and slowing down the user experience. Task latency (P95) is a better leading metric. It shows when workflows are starting to wait, even before average task duration meaningfully degrades. A practical operating model is to alert on P95 latency first, then confirm the issue by looking at sustained task duration.
Scale out by default: Scaling out adds more systems, increasing total agent capacity, while scaling up adds cores or memory to a single system for agents with heavier compute bursts.
Our testing data showed that scale-out is usually the better default. That aligns with the fact that agents are typically semi-independent and have modest per-agent bursts, it improves overall performance, supports high availability, often lowers cost, and makes it easier to preserve the target agents-per-vCPU ratio as the platform grows.
Scale up when agents require heavier parallel compute, shared state limits partitioning, memory locality matters, or licensing constraints apply.
Consider business implications: Where will agentic AI create business value first? The organizations getting production-grade results are wrapping an automation layer around workflows that already have codified rules and measurable service levels: code creation, regression test farms, ticket triaging, market analysis, and security review.
The ideal enterprise persona for agentic AI is therefore not the experimental user chasing novelty; it is the accountable leader who must improve cycle time and productivity, protect service quality, enforce policy, and scale adoption with cost in mind.
Agentic AI’s value comes from helping businesses complete real work across teams, systems, data, and processes. For enterprises, the priority is not just better model performance; it is creating a reliable environment where AI agents can support business workflows, improve productivity, operate within governance requirements, and scale as adoption grows.
In practice, success with agentic AI depends on the right foundation to deliver consistent outcomes, manage cost, maintain control, and move confidently from pilots to production.
This content was produced by Intel. It was not written by MIT Technology Review’s editorial staff.
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み