LLMを計算資源とせよ：エンタープライズAIの泥臭い真実

「またしても、プロンプトの微調整で週末が潰れた――。」LLMを既存のエンタープライズシステムに組み込もうとしたことのあるエンジニアなら、この絶望感に深く共感してくれるはずだ。LangChainやLlamaIndexを駆使して構築した「自律型エージェント」が、本番環境で無限ループに陥り、API利用料金を爆食いした挙句、使い物にならない回答を出力する。この「泥臭い現実（Messy Reality）」こそが、現在のエンタープライズAIが直面している最大の壁であると私は考える。我々エンジニアが直面しているのは、PoC（概念実証）の華々しい成功と、本番運用の冷酷なギャップだ。

元Deutsche TelekomのAIエンジニアリングヘッドであり、現在はMasaicの共同創業者兼CEOを務めるArun Joseph氏は、InfoQ Dev Summit Munichにおいて、この課題に対して極めて明快なアーキテクチャ論を提示した。彼が主導した「LMOS（Language Models Operating System）」は、ヨーロッパ最大級の通信キャリアで実際に稼働し、現在はEclipse Foundationに移管されている。Joseph氏が主張するのは、現在のAIブームがもたらした「チャットボット」や「単純なタスク自動化」という「Level 1」の段階から、企業の意思決定と実行を担う「Operational Intelligence Systems（運用インテリジェンスシステム）」、すなわち「System of Outcomes（成果のシステム）」への脱却である。

例えば、HitachiやJohn Deereのような重機運用企業を考えてみよう。現場で発生するエラーコードの急増に対し、IoTデータ、テレメトリ、過去のSOP（標準作業手順書）、インシデント履歴を統合的に分析し、「どの部品をどこの倉庫に補充すべきか」を自動で判断・実行するシステムが求められている。これを実現するには、固定的なプロンプトチェーンではなく、必要に応じて一時的なエージェント（Ephemeral Agents）を動的に生成・並列実行し、その結果を合成する「新しい計算基盤」が必要不可欠なのだ。単なるおしゃべりボットの構築に終始している限り、我々はエンタープライズの真の課題を解決することはできない。

この「既存のレガシーシステムを活かしつつ、新しい自律性を組み込む」というアプローチは、ソフトウェアの世界だけに閉じた話ではない。例えば、医療分野におけるPicard Medical / SynCardiaの「Emperor Total Artificial Heart（全人工心臓）」のアーキテクチャ設計（IEEE EMBC 2026で発表）を見てほしい。彼らは、2,100人以上の患者を救ってきた実績ある信頼性の高いコンポーネントを厳格に維持しながら、新しい制御アーキテクチャを融合させている。また、製造・物流分野におけるIMTS 2026で議論される「相互運用可能なAMR（自律移動ロボット）エコシステム」も同様だ。工場の床（Shop Floor）の物理的な物流と、機械のスループットのギャップを埋めるためには、既存の生産設備を破壊することなく、自律的なロボット群を協調動作させるアーキテクチャが不可欠となる。

エンタープライズAIエージェントの設計も、これと全く同じ思想で臨むべきだと私は確信する。すでに企業内には、Salesforceや基幹データベースといった「System of Record（記録のシステム）」や、Palantirに代表される「Data OS」が厳然として存在している。これらを「スパゲッティコード」のようなアドホックなAPI連携で繋ぐのは、システムのデッドロックを引き起こす自殺行為に等しい。既存の信頼されたコンポーネントを維持しつつ、いかにして新しい自律レイヤーを滑り込ませるか。ここにアーキテクトの腕の見せ所がある。

Joseph氏が提案するマルチエージェント・システムは、既存の投資とチームをレバレッジしながら、その上に「System of Outcomes」を構築する。重機のダウンタイム削減のデモで示されたように、エラー検知時に「一時的なリサーチエージェント」を並列で立ち上げ、データをクランチし、人間が介在する（Human in the Loop）動的なSOPを生成するプロセスは、まさにAMRが工場の床で障害物を避けて最適なルートを再計算するプロセスや、人工心臓が患者のバイタルに合わせて拍動を制御するプロセスと本質的に同じである。信頼性と自律性の高度な融合こそが、我々が目指すべきシステム設計の極致なのだ。

では、我々エンジニアは明日からどう行動すべきか。Joseph氏が率いるMasaicが提唱する「Agentic Compute (AGC)」と「Agent Definition Language (ADL)」は、この混沌に対する強力な処方箋となる。AGCは、知識労働のための新しい計算基盤（Computing Substrate）であり、オープンな設計で既存のエンタープライズスタックと統合される。これは、個々のLLMの性能向上に依存するフェーズの終わりを告げている。モデルが賢くなればすべてが解決するという「LLM万能論」は、エンタープライズの泥臭い現場においては幻想に過ぎない。

必要なのは、LLMを単なる「賢い脳」としてではなく、オペレーティングシステムにおける「CPU（計算資源）」として再定義することだ。CPU単体ではアプリケーションが動かないように、LLM単体ではエンタープライズの業務は回らない。スレッド管理、メモリ割り当て、プロセス間通信に相当する「エージェント制御レイヤー（Agentic Compute）」をアーキテクチャとして確立しなければならない。以下に、従来のシステム設計とAgentic Computeがもたらすパラダイムシフトを比較する。

ここで私は、読者であるあなたに痛烈な問いを投げかけたい。我々はいつまで、プロンプトの微調整や、特定のLLMフレームワークのAPI仕様変更に一喜一憂する「その場しのぎのパッチ当て」を続けるつもりなのか？

明日からの実務において、まずは「エージェントのライフサイクル管理」を意識的に設計に組み込んでほしい。エージェントを永続的なオブジェクトとして定義するのをやめ、タスクの発生と同時に生成され、処理が終われば消滅する「一時的なプロセス」として抽象化すること。そして、既存のSystem of Recordに対する「読み書きの権限と境界線」を厳格に定義すること。このアーキテクチャシフトこそが、AIを「おもちゃのチャットボット」から「企業の神経系」へと進化させる唯一の道なのだ。