Relevance AIが解いたのは、エージェント作成ではなく運用の詰まりだった

Relevance AIは、AIエージェントとマルチエージェントのチームを、コードを書かずに組み立てて運用するプラットフォームだ。

単体のチャットボットではなく、役割の違うエージェントを並べて一つの業務プロセスを任せる「AI Workforce」という考え方を掲げている。出典

2025年1月だけで、Relevance AIの上では4万個のAIエージェントが作られた。

その4か月後、会社はBessemer Venture Partners主導で$24MのSeries Bを発表する。

だがDaniel Vassilevがその資金の使い道として挙げたのは、作成機能の強化ではなかった。出典

シドニーで見ていた、自動化の天井

3人が会社を始めた動機は、既存の自動化ツールがルールで書ける仕事にしか効かないという認識だった。

判断や文脈の読み取りが要る仕事は、フローチャートの外側に残り続ける。出典

そこで置いたのが、エンジニアではない業務の専門家が自分でエージェントを作り、配れる土台という構想だった。

2024年4月のブログでVassilevは、人が毎回指示するコパイロットの先に、任せておけるオートパイロットがあると書いている。出典

2025年5月、需要が先に資金を呼んだ

Vassilevは調達の発表で、AIエージェントの領域は猛烈な速さで動いており、この資金は成長を加速するのに最適なタイミングで届いたと述べた（英語原文の要旨）。出典

同じ月、ローンチウィークで3つの製品が並んだ。

文章からエージェントを作るInvent、複数エージェントをキャンバスで並べるWorkforce、2,000以上の連携。

翌週には運用の枠組みAgentOSを発表している。出典 出典

作成が終わった後に残った問題

エージェントが増えると、ボトルネックは作成から維持に移った。

ある顧客は、エージェントがエラーを出すと再処理に1日の大半を使うと話したという。出典

テストを自分で設定した利用者は1%未満だったと会社は説明する。

壊れてから気づく運用が、そのまま放置されていた。出典

Invent 2.0で「管理」を製品にした

2026年9月のInvent 2.0は、この詰まりへの答えだ。

依頼を聞き取り、業務を分解し、テストを書き、公開後も品質の変化を監視する。

人が呼ばれるのは、判断が要る場面だけになる。出典

安全側の設計も明示した。

人が公開するまで反映しない、変更はバージョンで残して30秒程度で戻せる、テストが落ちる変更は出せない、権限は実行者と同じ範囲に限る、という4点だ。出典

作る道具を作る会社が、次に作ったのは管理する道具だった。

エージェントが増えるほど価値が立つのは、作る速さではなく、増えた後も同じ品質で回り続ける仕組みのほうだった。

Relevance AIが刺さるのは、AIで業務を回したいが、エンジニアの順番待ちと運用の崩れで止まっている企業だ。

業務の専門家が自分でエージェントを組み、配れる設計にすることで、企画から稼働までの待ち時間を削る。出典

2025年1月だけで4万個のエージェントが作られたという数字は、作成の敷居を下げたときに需要が一気に噴き出すことを示す。

同時に、作られた数だけ運用の負債も増えるため、管理機能の価値が後から立ち上がる。出典

示唆は、AI導入の詰まりは「作れないこと」ではなく「増えた後に回らないこと」にあるという点だ。

導入検討の場では、作成デモより運用の設計を見たほうが失敗しにくい。出典

参入障壁は、作成、実行、評価、統制を同じデータでつなぐ構造にある。

評価の結果がそのままモデル選択やプロンプトの修正に効くため、部分ごとの置き換えがしにくい。出典

加えて、業務別のテンプレートと2,000以上の連携が蓄積されると、最初の1体を作るまでの時間が短くなり、乗り換えの動機が下がる。出典

ネットワーク効果は中程度だ。

利用企業が増えても、他の企業のデータが直接価値を生むわけではない。

ただしマーケットプレイスに業務別のテンプレートが集まると、参加者が増えるほど最初の構築が速くなるという間接的な効果が生まれる。出典

外部連携の拡充も、連携先が増えるほど導入先の業務を覆いやすくなる点で弱いネットワーク効果を持つ。出典

対象は、人数を増やさずに処理量を伸ばしたい中堅から大企業の事業部門と、その業務を設計するOps人材。

営業、サポート、経理、人事の定型業務が入口になる。出典

公表顧客にはQualified、Canva、Databricks、Confluent、Autodesk、Lightspeed Commerce、Rakuten Advertising、Freshworks、AVEVAが並ぶ。出典

1つの定型フローを安く回したいだけの小規模チームには過剰になりやすい（意見）。出典

第一に、製品の重心を運用へ移したこと。

作成が簡単になるほど作成は差別化にならず、維持と評価が価値になる。出典

第二に、非エンジニアを主役に据えたこと。

専門家が自分で組み配れるため、IT部門の順番待ちという導入障壁を外せる。出典

第三に、ルーター、キュー、評価、トレース、権限を1つの基盤にまとめたこと。

運用の設計判断が1か所に集まる。出典

作成中心だった時期は、その後の運用を顧客に委ねていた。

テストを設定した利用者が1%未満だったという事実は、製品の導線側の問題でもある。出典

料金も一度失敗している。

単一クレジット制は説明が難しく、自分たちでも請求を説明できない状態だったとKohが認めている。出典

加えて、成果は顧客の業務定義とデータ整備に強く依存する。

業務が言語化されていない企業では、導入しても効果が出ない可能性がある（意見）。

成長は3層で設計されている。

1層目はブログと導入事例による比較検討層への到達で、顧客の具体的な数字を前面に出す。出典

2層目はマーケットプレイスとテンプレートによるプロダクト内の立ち上がり支援。出典

3層目はEnterprise契約で、評価、A/Bテスト、SSO、監査ログをまとめて売る。出典

トレードオフは、非エンジニア主導の導入が広がるほど、業務設計のまずさがそのまま解約理由になる点だ（意見）。

主要チャネル: content, community, marketplace, events, partners

自動化の価値は、作る速さではなく、作った後に安定して回るかに移る。

作成を簡単にする競争は、いずれ全員が同じ土俵に立つ。出典

非エンジニアに渡すなら、自由度より先に安全装置を用意する必要がある。

承認、バージョン、テスト、権限を初期装備にした判断はその順序を示している。出典

説明できない料金は、それ自体が解約理由になる。

原価を上乗せしない設計に振り切ったのは、請求の分かりにくさが信頼を削るという学びだ。出典

日本では、誰がエージェントの出力に責任を持つかを先に決める必要がある。

承認フローと監査ログを前提にした設計は、稟議と監査の文化とぶつかりにくい。出典

日本語の業務文書をナレッジとして読ませる精度が導入効果を左右するため、社内文書が整っている部門から始めるのが現実的だ（意見）。出典

拠点はシドニー、サンフランシスコ、バルセロナで、日本法人の有無は公式に説明されていない。

日本語サポートを前提にするなら契約前に体制を確認したい（要確認）。出典