スイッチパネルは、配線されたとおりにしか動きません。スイッチを入れれば、毎回決まった1つの応答が返ってくるだけです。その回路の外にあることを求めても対応できません。扱えるのはばらつきではなく、配線だけだからです。
オペレーターは違います。「フロントにつないでください」という依頼を受けると、オペレーターはその方法を自ら考えます。どの回線を使うか、話し中ならどうするか、依頼そのものが曖昧だったらどうするか。単に信号を中継するのではなく、それを解釈し、行動に移すのです。
Maven Appsはスイッチパネルではなく、オペレーターです。App基盤を支えるフレームワークの構築に着手したとき、私たちは意図的な賭けに出ました。新たな統合レイヤーをつくるのではなく、本物のアプリケーションプラットフォームをつくり、その上でAIエージェントを第一級の存在として扱う、という賭けです。
現在、私たちのフレームワーク上では数千ものアプリが稼働しています。もちろん、Salesforce、Zendesk、Notionといった主要なサードパーティシステム向けのアプリも含まれますが、本番環境のエージェント上で稼働する数百ものカスタムアプリも含まれています。
基本的な連携では不十分な理由
「Salesforceと連携できる」が自社製品にとって何を意味するのかを10社のベンダーに尋ねれば、10通りの答えが返ってくるでしょう。Salesforce、Zendesk、Frontのようなシステムは、決して1つの役割だけを持つものではないからです。たとえば次のような役割があります。
- エージェントが情報を探しに行く場所（ナレッジベース、ケース履歴）
- エージェントがアクションを実行しに行く場所（チケットの作成、レコードの更新、返金処理）
- エージェントが姿を現すべき場（サポートチームが日常的に使っているコンソール内のエージェントアシスト型コパイロット）
記事のことしか把握していない「Salesforce連携」は、ケースも起票できる連携とは別の製品ですし、コパイロットとしてエージェントコンソール内に常駐できる連携とも別の製品です。しかし、これらはしばしば1つのマーケティング用語でひとくくりにされ、その違いは導入段階になって初めて明らかになります。
いわば自動販売機の問題です。メニューは固定で、宣伝どおりに動作しますが、必要なものがリストにないと分かったときには、すでに契約済みというわけです。私たちはMaven Appsをそのような仕組みにしたくありませんでした。そこで、汎用的な「コネクター」ではなく、実際に問われていること（ナレッジ、機能、チャネルのどれか）を軸にフレームワークを設計しました。
Maven Apps：単なる連携を超えて
Maven Appsはさまざまな形をとりますが、多くはいくつかの共通パターンに基づいています。アプリでできることの例をご紹介します。
- ナレッジアプリは、外部システムのコンテンツを読み取ってインデックス化し、エージェントがそれをもとに回答できるようにします。読み取り専用で、バージョン管理され、対象者別のタグ付けも可能です。
- 機能アプリは、エージェントがそのシステム内で実際に操作を行えるようにします。実際のAPI呼び出しをマルチステップのワークフロー（注文を照会し、返品ポリシーを確認し、返金を処理し、顧客に完了を伝える）として連結し、すべてを1回の会話の中で完結させます。ATMが固定メニューから台本どおりの取引を1つ実行するのに対し、機能アプリはむしろ専属の銀行担当者のように振る舞います。メニュー項目ではなく求める結果を受け取り、例外への対応も含め、そこに到達するために必要なことを実行します。
- チャネルアプリは、顧客やサポートチームがすでにいる場所にエージェントを届けます。埋め込みウィジェット、電話、受信トレイ、あるいはエージェントが毎日使うコンソール内のコパイロットパネルなどです。
ディレクトリにある構築済みアプリは、通常数分でインストールできます。顧客のシステムがカタログにない場合でも、開発者は同じフレームワーク、同じSDK、同じライフサイクルフック、同じセキュリティモデルを使ってカスタムアプリを構築できます。
当社のエンジニアだけが使う別枠の「エンタープライズグレード」版フレームワークは存在しません。アプリ構築のための開発者プラットフォームであるApp Studioも、まったく同じアーキテクチャで動いています。本物のTypeScript、本物のSDK（@mavenagi/mavenagi）、本物のデプロイパイプラインを採用しており、当社のためだけに習得が必要な独自スクリプト言語ではありません。
MCPを使った開発経験がある方なら、Maven Appは同様の考え方をフルマネージドで提供するものとお考えください。標準的なMCPサーバーでは、立ち上げ、登録、稼働維持、スケーリングをすべて自分で行う必要があります。Maven Appは、自動登録・自動スケーリングされるMCPエンドポイントに近く、そうしたインフラを自社で抱える必要は一切ありません。ロジックを書くだけで、エンドポイント、認証、ホスティングはすべて当社が担います。
Appsを強力にする設計
Maven Appは、安全に分離された環境内で動作し、定義されたSDKを通じてMavenプラットフォームと通信するサーバーレスアプリケーションです。具体的には次のとおりです。
マルチテナント型です。 1つのアプリを一度構築すれば、異なる組織やエージェントにまたがって何度でもインストールできます。各インストールには固有のスコープ付きコンテキスト（組織ID、エージェントID、ランタイム設定）が与えられますが、基盤となるコードは共通です。そのため、Salesforceアプリに改善を加えれば、それを利用しているすべての顧客が恩恵を受けられます。「自社専用」に手作りされた古いバージョンの連携に取り残されることはありません。
後付けではなく、分離されています。 各アプリは安全な環境内で独立した関数として動作し、Mavenのコアバックエンドからも、他の顧客のアプリからも切り離されています。お客様のカスタムロジックが、共有のモノリスの中で他社のロジックと隣り合わせで動くことはありません。基幹システムへの接続には、VPN、VPCピアリング、OIDC、またはIP許可リスト付きの通常のHTTPSを利用できます。選ぶのは当社ではなく、お客様です。
ポーリングのスケジュールではなく、実際のイベントに反応します。 夜間の同期ジョブの代わりに、アプリはトリガーと呼ばれるイベントフックを実装できます。会話が作成された、フィードバックが届いた、ナレッジベースが更新された――そうしたイベントが発生した瞬間に、プラットフォームがアプリに通知します。これは、皆さまがすでにご存じの自動化ツールとは異なる仕組みです。Mavenのトリガーは受動的です。プラットフォーム自体が状態の変化を監視し、関心のあるすべてのアプリにプッシュします。イベントを引き起こしたアプリと、それに反応するアプリの間に結合はありません。実際には、メール返信アプリとまったく別のSalesforce同期アプリが、同じ「会話更新」イベントにそれぞれ独立して反応し、互いの存在を知らないまま、それぞれの処理を行えるということです。
これはアリのコロニーと同じ協調の仕組みです。コロニーの行動を計画するアリは1匹もおらず、アリ同士が直接メッセージを送り合うこともありません。1匹のアリが共有環境の何か（フェロモンの道筋）を変えると、他のすべてのアリがそれぞれのシンプルなルールに従い、その変化に独立して反応します。コロニー全体としての知性（最適化された採餌ルート、負荷分散、さらには巣の移転といった集団的意思決定）は、そこから創発します。中央の調整役はおらず、計画を把握しているアリもいません。Maven Appsも同じように協調します。イベントが共有状態を変え、関心を持つすべてのアプリが自律的に反応するのです。
本格的なライフサイクルを備えています。 すべてのアプリは、少数のライフサイクルフックを実装します。
preInstall：本番稼働前に認証情報と設定を検証します。APIキーが誤っていれば、3週間後に気づかないうちに失敗するのではなく、この段階で明確にインストールが失敗します。postInstall：インストールが成功した時点で、アプリのアクションを登録し、必要なリソースをプロビジョニングします。executeAction：エージェントから依頼された実際の処理を実行します。注文の照会、ケースの作成、返金処理、口座残高の確認など、顧客には機能として提供されます。
ほとんどの連携は照明のスイッチのようなもので、オンかオフのどちらかしかありません。Maven Appsは、インストール、検証、実行、ティアダウンという完全なライフサイクルを実行します。2つの状態しかないスイッチというより、コンテキストを読み取って適応する一連の手順（何が開いているかを確認し、何が安全かを確かめてから実行する）に近いものです。これはまさに本番運用のソフトウェアに求められる規律であり、Maven Appsはまさにそうしたソフトウェアなのです。
Appsと連携の違い
一般的な連携は、「データをAからBへ移せるか」という狭い問いに答えるだけで、それをゴールとみなします。Maven Appは、より難しく、より有用な問いに答えるために構築されています。AIエージェントが、システム内で今何が事実なのかを確実に把握できるか。そして、必要なときにお客様に代わって行動することを任せられるか、という問いです。
多くのエンタープライズプラットフォームは、「標準で用意がなければ自社で構築できます」という選択肢を提供しています。しかし、あまり語られないのは、自社で構築するということは、自社のインフラ上でサーバーの運用、スケーリング、セキュリティレビューをすべて自前で行うことを意味する、という点です。その結果、コネクターカタログのちょっとした欠落が、人員配置の判断に変わります。エンジニアリングとインフラの予算を確保するか、構築済みのものだけで我慢するか。Maven Appsなら、お客様が「よりましな選択肢」を強いられることはありません。お客様や開発者が構築したカスタムアプリは当社のインフラ上で動作し、ディレクトリ内のすべての構築済みアプリと同じ監視、スケーリング、セキュリティ体制が適用されます。コードを書くのはお客様、運用するのは当社です。
だからこそ、このアーキテクチャは、単純なWebhookでは気にする必要のない点にもこだわっています。
- 構造化され、サイズが制限されたレスポンス。 アプリが実行するすべてのアクションは、明確なレスポンスと、エージェントが推論に使える構造化データを返します。中身を推測しなければならない、無制限の生データではありません。
- 署名付きの相互認証。 プラットフォームはアプリへのすべてのリクエストに署名するため、アプリは呼び出し元が本当にMavenであることを検証できます。また、アプリも独自の認証情報でプラットフォームに対して認証を行います。どちらの側も、ネットワークだけを信頼する必要はありません。
- 本番環境に届く前に設定を検証。
preInstallはアプリの本番稼働前に実行されるため、無効な認証情報や設定漏れは、顧客が初めてそれに頼った時点ではなく、インストール時に検出されます。 - 単なる関数呼び出しではなく、本物のインフラが基盤に。 アプリは完全なアプリケーションであるため、ステートレスなリクエストとレスポンスだけでなく、キャッシュ、レートの集計、小規模なデータベースといった実際の状態を保持できます。これにより、特定ドメインの解決率が直近24時間で10%以上低下したかを追跡し、低下した場合にチームへ通知する、といったことが可能になります。単なるAPI呼び出しでは、こうした記憶を保持できません。本物のアプリケーションなら可能です。1匹1匹のアリは知らなくても、コロニー全体としては餌のありかを記憶しているのと同じです。
- 機密データをモデルに渡さない。 AIをまったく経由すべきでないステップもあります。顧客がカート内の商品を購入する準備ができたら、エージェントがアプリのチェックアウトを起動し、アプリが独自の安全なインターフェースを通じて、支払い情報や個人情報を顧客から直接収集します。エージェントはフローを統括しますが、カード番号などの機密情報がAIとの会話に入ることはありません。
- 1つのコードベースで全顧客に対応し、影響範囲は分離。 マルチテナントにより、修正や改善は一度リリースすれば全員に届きます。一方で分離により、ある顧客のカスタムロジックが他の顧客に影響を及ぼすことはありません。
お客様にとっての意味
Mavenをご検討中の方にとって、実務上のポイントはこうです。エージェントが質問に答え、それに基づいて行動できると当社が言うとき、そのアクションの背後には本物のアプリケーションがあります。それはバージョン管理され、認証され、分離されており、当社チームが提供したものでもお客様のチームが構築したものでも、同じフレームワーク上に構築されています。それが、システムについて話せるだけのエージェントと、実際にシステムに組み込まれたエージェントとの違いです。
私たちがMaven Appsを構築したのは、それこそが本来「連携」が意味すべきものだったと考えているからです。
自社の会話でお試しください。
無料の個別デモをお申し込みください。
