この「航空宇宙DNA」は単なる経歴の話ではない。同社の技術思想そのものを説明するものだ。ロケットの打ち上げソフトウェアは、厳格な検証の下で、決められた手順を確定的に実行しなければならず、即興で手順を変えることは許されない。創業者たちは、このメンタルモデルをそのまま企業AIの世界に応用したのである 。
結果として、多くの産業企業はAIエージェントを評価段階では試すものの、本番環境にデプロイするには至っていない。デモでは強力に見える技術も、工場の現場ソフトウェアが何十年にもわたって守ってきた信頼性の基準を満たせないのだ 。
1. コンパイル・フェーズ:ユーザーが自然言語で業務プロセスを記述する。するとLLMが、完全に構造化され、実行可能な「Plan(計画)」、つまり本質的には決定論的なコードを生成する。このPlanは、実際に実行される前に検証される。LLMが使われるのは、この「作成時」の一度だけであり、実際の取引(トランザクション)実行時ではない 。
2. 実行フェーズ:検証済みのPlanは、LLMを再び呼び出すことなく、INXMのOrchestratorエンジン上で実行される。エンジンは企業の既存システム(ERP、PLM、MES、メール、承認ツール)間を横断的に調整し、毎回まったく同じ手順を同じ順序で実行する 。
その技術的な違いは明確だ。標準的なエージェントが各ステップでLLMを呼び出す(非決定的であり、トークンコストが高く、監査が難しい)のに対し、INXMは一度だけ「コンパイル」し、その後は固定されたプログラムとして実行する。アウトプットは再現可能、テスト可能になり、ランタイム時のハルシネーションから解放される。同社はこれを、「自然言語の柔軟性と、従来のコードの信頼性の融合」と呼ぶ 。
この概念を具体的にすると、たとえば工場での品質検査ワークフローを考えてみよう。エンジニアが必要な承認ステップとデータチェックを平易な言葉で記述する。するとOrchestratorがそれを固定された順序にコンパイルし、管理者が一度だけ承認する。その後ワークフローは、関連するイベントが発生するたびに、建物の外にデータを一切送信することなく、またモデルが即興で手順を変えるリスクもなく、毎回同一に実行される 。
Orchestratorは企業自身のインフラ、すなわちオンプレミス(自社運用サーバー)またはプライベートクラウド上で稼働するため、生産データが建物の外に出ることはない。このアーキテクチャは、設計上GDPRやEU AI法への準拠を保証する。また、クラウド専用の自動化ツールでは物理的にアクセスできない工場内のソフトウェアにも、リーチできるようになる 。
同社が明確に標的としているのは、産業機械メーカーやドイツのミッテルシュタントだ。レガシーなオンプレミスシステムを抱え、規制上の義務を負い、そして再現性を厳しく要求する企業群である。これは水平分業型の自動化ツールではない。本番環境で信頼できないという理由で、すでに汎用AIエージェントを拒絶した企業のために、明確な目的をもって構築されている 。
57百万ユーロの新たな資金、ミッションクリティカルなソフトウェアを世に送り出してきた創業チーム、そして企業AIを「会話」の問題ではなく「コンパイラ」の問題として捉え直す技術的アプローチ。INXMの賭けは、産業界におけるAI導入のボトルネックが「能力」ではなく、「信頼性」にあるということだ 。
Comments
0 comments