8月3日、InfoQが「Architecting AI Systems for the Messy Reality of Enterprises: Why Agentic Compute is the Missing Layer」と題した記事を公開した。Deutsche TelekomでAIエンジニアリング責任者を務めるArun Joseph氏が、エンタープライズ環境でAIエージェントシステムを実際に機能させるための設計思想と実装上の課題を語ったプレゼンテーションの内容だ。

登壇者のArun Joseph氏は、2023年にヨーロッパ初のエンタープライズグレードなエージェントプラットフォームを立ち上げた人物だ。そのプラットフォームが**LMOS（Language Models Operating System）**であり、現在はEclipse Foundationのもとで複数国のDeutsche Telekomグループに展開されている。本プレゼンテーションは、その実戦経験をもとにしたエンタープライズAI設計論である。

エンタープライズAIプロジェクトが機能しない理由：「フォルトライン」という概念

Joseph氏が指摘する核心的な問題は、「フォルトライン（fault line）」の存在だ。同氏が引用する統計によれば、エンタープライズAIプロジェクトの大多数は本番環境への到達に失敗するとされており、その原因がこのフォルトラインにあると氏は説明する。

エンタープライズのシステムは本質的に、「ストレージ→変換→プレゼンテーション→送信（API/イベント）」という4つのレイヤーで構成される。そしてマイクロサービス環境では、各APIを異なるチームが管理しており、チーム間に無数のフォルトラインが存在する。

問題は、AIエージェントのプロジェクトチームがこのフォルトラインを無視しがちな点だ。TM Forum（テレコム業界のAPI仕様標準化団体）のProduct Ordering APIを例に挙げると、そのAPIの属性を本当に理解しているのは、既存チームの1〜2人だけという状況が珍しくない。そこに最新フレームワークとリサーチペーパーを武器にした新チームが乗り込んでも、APIのドキュメントは不完全、フロントラインの担当者にはアクセスできず、イテレーションが止まる。

「実際に顧客対応している現場の人間が、エンジニアより要件を理解している」——この事実から切り離れた技術チームは機能しない、と氏は断言する。

エンタープライズに「本当に効く」エージェントとは何か

Joseph氏はエージェントを理論的な定義ではなく、プログラミングパラダイムとして捉えることがポイントだと整理する。

通常のプログラムは「入力→変換→出力」の構造を持つ。氏が定義するLevel 1エージェントは、これに2つの性質を加えたものだ。受け付けられる入力の幅が広がること、そして計算の適応性が高まること。

具体例として挙げるのが「3都市の中で最も暖かい場所のホテルを探して予約して」というリクエストだ。従来のシステムなら、このユースケース専用のボタンとロジックをBFF（Backend For Frontend）に実装し、Jiraでチケットを切り、スクラムセレモニーを回す必要がある。エージェントなら「get_weather」「list_hotels」「book_hotel」という既存の関数を動的にオーケストレーションすることで対応できる。

「大規模なGodmodeエージェント」より、まずこのLevel 1から始めるべきだ、というのが同氏の主張である。大企業に散在する「Camundaで書かれたボットファーム」——決まったチケットを処理するだけの自動化ワークフロー群——を、このアプローチで置き換えるだけでも巨大な価値が生まれる。

Level 2エージェント：重機のダウンタイムを削減するMulti-Agent System

より高度なLevel 2エージェントの例として、重機オペレーション（Hitachi、John Deere等を想定）のユースケースが紹介される。

サービスオペレーションマネージャーが「中西部でこのエラーコードが急増している。何が起きているのか？」と問い合わせると、システムは以下を自動で実行する：

• IoTデータ、テレメトリ、SOP、インシデント履歴を横断して調査
• 「エラーの73%がエアフィルター管理の問題」と分類・集計
• 対処SOPを動的に生成（テキストだけでなく、エージェントのアクション＋ヒューマンインザループのプロセスが混在）
• 関連チケットの起票と他システムへのテレメトリ送信
• 「この2部品が過去1ヶ月この地域で継続的に故障している。倉庫にJP-100とシールキットを補充すべき」という次のアクションを提示

このシステムが内部でやっていることは、問いに対して複数の調査タスクを並列で生成し、それぞれをエフェメラル（使い捨て）エージェントとして実行、最後に合成するという構造だ。これは事前に固定したエージェントを定義するアーキテクチャでは対応できない。「何個エージェントを作るのか？」という問いに対し、エフェメラルエージェントを動的に生成できる基盤が必要だ、というのが氏の結論である。

なぜ「Agentic Compute」が欠けているレイヤーなのか

従来のエンタープライズスタックには、System of Record（SalesforceなどのDB層）とData OS層（Palantirなどのダッシュボード層）が存在する。Joseph氏はその上に「System of Outcomes」という新しいクラスが必要だと主張する。

重機のダウンタイム削減、都市インフラの最適化、産業オペレーション——これらの「アウトカム」にフォーカスするためには、既存の2層の上に、動的にエージェントを生成・実行できる計算レイヤー（Agentic Compute）が不可欠だ、という論旨である。同氏が現在構築中のプロダクト群（Masaic、Atlasなど）はこの思想に基づいている。

詳細はArchitecting AI Systems for the Messy Reality of Enterprises: Why Agentic Compute is the Missing Layerを参照していただきたい。