HashiCorp元CEO、9年務めた後、企業向けAIエージェントの壁取り除く意欲表明

従来のエンタープライズアプリケーションに顧客の住所や今日の売上高を尋ねると、大まかな流れは予測可能です。開発者が事前に設計したルートに従い、ユーザー認証を行い、適切なシステムからデータを照会し、結果を返すという一連の流れです。同じ基盤データであれば、毎回同じ答えが得られます。

一方、AI エージェントに同じ質問をすると、その経路は予測が困難になります。あるシステムを参照した後、別のシステムから追加の文脈が必要だと判断し、十数回のツール呼び出しを行い、言語モデルを通じて情報を処理した上でようやく回答を生成します。同じリクエストを再度実行しても、全く異なるルートを通る可能性があります。

そして企業環境において、その経路で何が起こるかという点も、最終的な答えと同じくらい重要です。エージェントがアクセスするシステム、閲覧するデータ、実行するアクション、そして消費されるコストなどです。

「事前に決定されたソフトウェア」と、「その場で確率的な判断を下すアプリケーション」の違いは、新しいインフラの世代に秩序をもたらすことに精通した創業者によって設立された新会社の核心にあります。

AI エージェントのガバナンスは難しい

imageDome Systems の共同創設者であるデビッド・マジャンネット氏は、HashiCorp を 2025 年 8 月に離れました。

デーム・システムズは、クラウド時代の最盛期に Terraform の生みの親である HashiCorp を 10 年近く率い、2021 年の大成功を収める IPO や 2025 年に IBM による 64 億ドルの買収へと導いたデヴィッド・マジャンネット氏によって、今年初めに共同設立されました。同社の経営陣には、HashiCorp で 6 年以上首席マーケティング責任者（CMO）を務めたマーク・ホームズ氏が加わっています。

The New Stack のインタビューで、マジャンネット氏は AI エージェントのガバナンスに関する自社の考え方を明らかにしました。企業は現在、クラウドインフラと同様の課題に直面しているというのです。まず普及が進み、その後でセキュリティ、運用、財務にわたる適切な制御を確立するという本格的な作業が始まるのです。

「これは非常に異なるアーキテクチャであり、これが新しい [エージェント型] アプリケーションの力を解き放つ鍵となります。」

マジャンネット氏によると、課題の一部は、エージェントが従来のエンタープライズアプリケーションとは全く異なって構築されている点にあります。企業は何年もかけて、これらの既存アプリを制御する方法を学んできました。

「これは非常に異なるアーキテクチャであり、これが新しい [エージェント型] アプリケーションの力を解き放つ鍵となります」とマジャンネット氏は説明します。

同氏が例として挙げたのは自動運転車です。モデルはリアルタイムの入力を受け取り、状況の変化に応じて車両システムと相互作用します。なぜなら、開発者が道路上で遭遇するあらゆる状況を事前にすべてプログラムすることは現実的に不可能だからです。

「歴史地図を参照して判断を下すのではなく、その場で判断を下していくのです」とマクジャネット氏は続けます。

エンタープライズ・エージェントも同様の振る舞いをします。あるツールを呼び出し、結果を評価し、別のツールが必要だと判断してさらに進み、タスクが完了するまでこれを繰り返します。この柔軟性により、事前に細かくスクリプト化するのが難しい業務にも対応可能ですが、その反面、企業がエージェントの行動を統制するのは難しくなります。

これがマクジャネット氏が Dome で目指している核心です。

エージェント時代の必須条件

同社は昨年 4 月、シークレット状態から脱却し、1,400 万ドルのシード資金を獲得しました。マクジャネット氏は、IBM による移行が完了した前年の 8 月に HashiCorp を退社しています。

Dome の出発点は、エージェントは「コード」「モデル」、そしてそれらが相互作用する「バックエンドシステムやツール」の 3 つを組み合わせるものだという点です。マクジャネット氏によれば、これら 3 つを一つのプラットフォームで統合することは、「エージェントが何ができるかに意味のある制約を課すための必須条件（table stakes）」だと述べています。

「統合されたプラットフォームを持たなければ、エージェントが行うすべてのことに対して統制を適用することはできません」とマクジャネット氏は言います。

「統合されたプラットフォームを持たなければ、エージェントが行うすべてのことに対して統制を適用することはできません」

Dome のプラットフォームは、この 3 つの要素を中心に構築されています。エージェントレジストリが各エージェントを管理し、MCP ゲートウェイが呼び出せるツールを制御します。さらにモデルブローカー/ルーターが使用可能なモデルとリクエストのルーティング方法を統括します。

セットアップではまず、エージェントを登録して ID を付与し、誰が呼び出し権限を持つかを定義し、バックエンドのツール（この例では Zendesk など）への接続を設定します。

imageDome はエージェントを登録し、呼び出し元を検証して利用可能なツールを接続します。

次に Dome はモデルプロバイダーを接続し、利用可能なモデルをルーティングやフェイルオーバールールに基づいてプールにグループ化します。その後、エージェント、そのツール、そしてモデルを単一のゲートウェイの背後に統合します。このゲートウェイが、エージェントの行動を規制するポリシーを適用するためのポイントとなります。

imageDome はモデルプロバイダーを接続し、モデルプールを作成してエージェントをゲートウェイの背後に配置します。

これらの要素が接続されれば、チームは各呼び出しに対して権限を設定したり、レスポンスを検査するガード機能を使ったり、支出上限を設けるクォータを適用したりできます。また、エージェントの活動全体にわたる共通の監査証跡も維持可能です。

現在、McJannet 氏は企業들이自らこれらの仕組みを組み立てていると指摘します。コスト管理のためにスタンドアロンのモデルブローカーを導入し、セキュリティや運用上の課題には別のツールゲートウェイを設けるケースが少なくありません。さらに、それらのシステムをつなぐために独自のエージェントレジストリを開発する企業も出てきています。

しかし、これらの機能を個別に購入すると、新たな統合問題が発生します。エージェントの活動の一部をモデルルーターが管理し、別の部分をツールゲートウェイが担当する場合でも、エージェント自体はそれらを行き来し続けることになります。

「ツールゲートウェイやモデルルーターだけを単独で提供しても、こうした統制システムを実現することはできません」と McJannet 氏は語ります。

まさにここが Dome の最新施策の狙いとなる部分です。初期アクセス期間を数ヶ月過ごした後、同社はついにセルフサービスユーザー向けにプラットフォームを公開しました。これにより、企業は通常の大変なエンタープライズ販売プロセスを経る必要なく、クレジットカード情報を入力するだけで簡単に登録できるようになりました。

Dome がセルフサービスへ

この種のエンタープライズインフラ製品において、セルフサービスモデルを採用するのは比較的珍しいケースです。Dome は価格を公開し、無料枠を用意して販売プロセスを経ずに利用者がすぐに始められるようにしました。一方で、大規模顧客向けには従来のエンタープライズルートも引き続き提供しています。

マクジャネットが想定する製品のユーザー像も、この考え方の一部です。すでに調達プロセスの深い段階にある購入者にアクセスを限定するのではなく、セルフサービス化によって、個人の実務者が自らプラットフォームを発見し、試し、利用できるようになります。

「参入障壁を可能な限り低くして、多くの人に参加してほしい」とマクジャネットは語ります。また、ローンチ前からすでに多くのセルフサービスによる登録があったことも付け加えています。

一方、価格設定には、この市場で最終的にどこに価値が生まれるかという信念が反映されています。マクジャネットは、モデルのルーティングやツールの接続性を基盤機能と捉えており、より付加価値が高いのは、エージェント全体を統制する機能——権限管理、データ削除、支出制限など——だと考えています。

また、Dome の主なターゲットユーザーは大企業内のプラットフォームエンジニアリングチーム（通常は運用およびセキュリティ部門と連携）ですが、セルフサービス化によって新たな利用層も生まれます。それは、エージェントを開発して企業向けに販売しようとする小規模な企業、あるいはたった数人のチームです。これは、AI 界隈で多くの人が約束する「一人のユニコーン」が実現するようなシナリオとも合致しています。

実際、マクジャネット氏は、開発者がアプリケーション自体の構築には成功しても、見込みのある企業顧客がセキュリティや運用レビューを開始した瞬間に壁にぶつかることがあると指摘します。アイデンティティはどのように強制されるのか？エージェントがアクセスするデータを誰が見られるのか？他のエージェントを呼び出した場合どうなるのか？その活動事後に再構成できるのか——といった疑問です。

マクジャネット氏によると、一部のビルダーからは「インフラ要素を満たせるまで、私のエージェントはデプロイできない」という理由で、Dome 上でエージェントの認証を取得できるかどうかを尋ねる声もあるといいます。マクジャネット氏は慎重に付け加えていますが、現時点で Dome がそのような認証プログラムを実行しているわけではありません。しかし、これは同社が今後取り組む可能性のある明確な道筋の一つです。

「もしそのエージェントを Dome に登録すれば、すべてのインフラ要素は自動的に処理されます」とマクジャネット氏は述べています。

『AI エージェントの壁を取り払う』：クラウド時代からの教訓

「リリースしたがる開発者」と「事後のリスクを懸念する企業チーム」の間にあるこの隔たりこそが、マクジャネット氏が HashiCorp での長年の経験と最も強く重なる部分だと捉えています。

マクジャネット氏の在任中、HashiCorp は大規模組織がクラウドインフラのプロビジョニング、セキュリティ、接続をどのように標準化するかを支援することに重点を置くようになりました。これには、2020 年に発表された HashiCorp Cloud Platform（HCP）も含まれます。これは同社のインフラツールを管理型クラウドサービスとして提供するものです。

より広く見れば、McJannet 氏が語るクラウド初期の普及は、開発者がクレジットカードをスワイプして直接 Amazon にデプロイするところから始まります。クラウドインフラが実現したことで、以前は現実的ではなかったアプリケーションを構築できるようになったのです。これらのアプリケーションの魅力は絶大で、運用やセキュリティチームからの抵抗にもかかわらず、企業はクラウドを採用しました。

その後に訪れたのが第 2 のフェーズです。組織全体にクラウドを定着させるためには、プロビジョニング、認証情報、ネットワーク、その他の制御機能において、共通のサービスが必要だと企業が気づいたからです。

この二つの要求を調整する役割を担うようになったのが、プラットフォームエンジニアリングチームです。開発者がアプリケーションを構築できる環境を提供しつつ、セキュリティ、運用、財務部門が十分なコントロール権限を持ち、そのアプリケーションを生産環境へ展開することを許可できるようにするのです。McJannet 氏は、今や AI エージェントが同じような緊張関係を生み出していると信じています。

「開発者が作る魅力的なアプリの列ができあがり、運用チームやセキュリティチームはそれらを自社の環境で育むことに不安を感じています」と McJannet 氏は語ります。「そのため、必然的にプラットフォームエンジニアリングチームが『はい』と許可する道筋を見つける必要があります。それはまさに先ほどのクラウド普及と同じ方向性です。」

Dome の戦略は、エンタープライズが最終的にゲートウェイ、ルーター、セキュリティ製品を寄せ集めたような散発的なシステムではなく、エージェント全体を跨ぐ単一のプラットフォームを好むようになるという前提に基づいています。McJannet 氏によれば、この共通の制御層こそが、エージェントに自律的な行動を許容しつつ、その活動範囲を制限する手段を提供する鍵となります。

「新しいタイプのアプリケーションアーキテクチャに対して、振る舞いを制約できる『回廊』のような制御層が必要不可欠です」と McJannet 氏は語ります。「なぜなら、そのような制御がなければ、AI アプリケーションの展開を阻害してしまうからです」

「私たちが答えようとしているのはまさにこれです。どうすればエージェントを大規模に展開できるのか？」

Dome にはまだ証明すべき点が残っています。同社は現時点で顧客名を公表していません。McJannet 氏によると、これまで協業してきたエンタープライズ企業は公の場で名前を明かすことに慎重な姿勢を示していますが、過去 8 ヶ月間にわたり数十社と協議を重ねてきたといいます。

結局のところ、McJannet 氏はクラウド時代の教訓として、新しいアプリケーションが普及するには、企業がそれを導入するための制御手段を整備する必要があると考えています。Dome はまさにその課題をエージェントの領域で解決しようとする試みです。

「私たちが答えようとしているのはこれです。どうすればエージェントを大規模に展開できるのか？」

この投稿は元々 The New Stack に掲載されたものです。