Deutsche TelekomのLMOS: エンタープライズAIチームがプラットフォームに求めるもの

アルン・ジョセフがInfoQで説明しているように、実運用されているエージェント型コンピューティング層には、短命なエージェント、ADL、および中央機能カタログが含まれる。

簡単に言えば。Arun JosephがInfoQで発表したように、Deutsche TelekomのエンタープライズAIプラットフォーム（LMOS）は、多数のツールが散在する状況（"tool sprawl"）を、コアとなる抽象化のセットで置き換えるレイヤーであり、エフェメラルなエージェントを導入するエージェント定義言語（ADL）を備えています。フレーミングとしては、エージェント型コンピューティングが、クラウドプロバイダーがデフォルトで提供していない「足りないレイヤー」であると述べられています。

事実

InfoQは2026年8月3日に、Deutsche TelekomにおけるArun JosephによるLMOSに関する発表を公開しました。3つの主張があります：

1. 企業は、適切に管理されていない多数のLLM/エージェントツール（"tool sprawl"）に悩まされている
2. 企業が必要としているのは、共通の抽象化を持つ「エージェント型コンピューティング」のレイヤーである
3. LMOSは、エージェント定義言語（ADL）と永続的なサービスではなくエフェメラルなエージェントを提案している

我々の解釈

Josephの主張は目新しいものではありません。QCon AI Boston（記事#1211）やCloudflare Agents Week（記事#1766）でも同様のストーリーが語られています。しかし、何十年にもわたるレガシービジネスコードを維持しなければならないテレコム事業者からの視点である点が興味深いです。LMOSはベンダーの基調講演ではなく、実運用の経験に基づくレポートです。

このパターンがアーキテクチャに与える示唆

• 永続的ではなくエフェメラルに。エージェントはセッション間で状態を持たず、状態はデータプレーン（ベクトルDB、ビジネスDB、イベントログ）に保持されます。これにより「長時間の会話によるコンテキストの漏出」という落とし穴を回避し、水平スケーリングを容易にします。認知コストとしては、各エージェント呼び出しを純粋関数呼び出しのように扱い、生きたオブジェクトのように扱わないことです。
• ADLを契約として。エージェントを、与えられるプロンプトではなく、入力と出力で記述します。これにより、異なる2つのチームが相互運用可能なエージェントを作成できます。これはMCPの真の約束を内部で実現したものであり、より強力な型付けが可能です。
• ツールの散在ではなくコアプラットフォームを。各チームがLangChainやLlamaIndexなど異なるツールを使うのではなく、中央で管理された機能カタログを共有し、監視とポリシーを一元化します。これはアプリケーションではなく、プラットフォームの仕事です。

内部構造

LMOSはまだ公開されていません。最も近いオープンソースの類似例は、MCP + レジストリ（Anthropic MCP hub、Cloudflare AI Gateway、Portkey）の周辺で出現しているものです。構造的な違いは、Deutsche Telekomがデータプレーン（電話、請求、内部CRM）をコントロールしている点です。これは米国のクラウドプロバイダーがアウトソーシングできないユースケースであり、プラットフォームの内部化が構造的に必要とされるケースです。

結論

「今月のエージェントフレームワーク」と真のプラットフォームの違いを整理するためのテストは以下の通りです。もしあなたのエージェントレイヤーが、Pythonコードを書かずにエージェントを定義し、サービスを再デプロイせずにデプロイできないのであれば、それはプラットフォームではなくSDKです。LMOSは、真のプロダクションプラットフォームがLangChainよりもAirflowに近いものであることを示唆しています。

見逃せないポイント

LMOSまたはそのコンポーネント（ADL）のオープンソース化の可能性、運用メトリクス（プロダクションのエージェント数、レイテンシ、タスクあたりのコスト）の公開、DMA/データ主権の下での他の欧州テレコム事業者による採用。