Rippling AI 構築で得た教訓 | Interrupt 26

エンタープライズ AI の真実：Rippling が「複雑なマルチエージェント」を捨てて得た 3 つの教訓

エンタープライズ向け AI アシスタントの開発において、多くのチームが陥りがちな罠とは何か。Rippling のエンジニアリングチームは、数百人のサブエージェントから成る複雑なアーキテクチャから脱却し、「単一のフラットエージェント」への移行と「評価駆動開発（EDD）」の導入によって、信頼性とコスト効率を劇的に向上させました。

本記事では、LangChain のイベント「Interrupt 26」で Rippling が発表した、複雑な企業環境における AI 構築の実践的な教訓を整理します。直感や理想論ではなく、統計とデータに基づいたアプローチがいかに重要かを解説します。

1. 複雑さを排除する：マルチエージェントからフラット構造へ

Rippling の AI プロジェクト初期には、各チームが独自のサブエージェントを構築し、それらをトップレベルのエージェントがオーケストレーションする「マルチエージェントアーキテクチャ」を採用していました。しかし、このアプローチはすぐに壁にぶつかりました。

「エージェント間でコンテキストをどう共有するか。引き継ぎをどう処理するか。割り込みをどう扱うか。」

複数のサブエージェントにまたがるクエリを処理する際、どの情報がどこにあるのかの把握が困難になり、システム全体が複雑怪奇なものへと変貌しました。結果として、パフォーマンスは低下し、維持コストは増大しました。

そこで Rippling が取った決断は、「フラットな構造」への完全移行です。現在は単一のトップレベルエージェントのみが存在します。ドメイン知識や業務ロジックは、コード上の複雑なサブシステムとして埋め込むのではなく、宣言的な「スキル」と「標準手順書（SOP）」を通じてエージェントに注入する形に変更しました。

この変更により、ユーザーが見るメッセージ履歴と LLM が内部で処理する情報が一致するようになり、不要な抽象化やコードが削除されました。その結果、パフォーマンスは大幅に向上し、システム全体の理解可能性が高まりました。

2. ツールカタログの縮小：汎用ツールと SQL 生成の威力

初期段階では、各チームが多様な専用ツールを構築し、膨大な「ツールカタログ」が形成されていました。しかし、LLM が適切なツールを選択する精度は極めて敏感で、間違った選択や見落としが起きると、システムは回答不能に陥りました。

Rippling はこれを解決するために、「汎用ツール」と「SQL 生成」という 2 つの戦略を採用しました。

まず、数百ある専用ツールの代わりに、パラメータを指定する単一の汎用的なデータ取得ツール（get-data）を導入しました。これは Unix の哲学、「単純なことを行い、それを良く実行し、組み合わせさせて複雑な結果を得る」という考え方に沿ったものです。

さらに重要なのは、生データを LLM に詰め込むのではなく、スキーマ（データの構造）を提示して SQL を生成させる点です。

「LLM にデータの形状を指定しました。これがスキーマ、そしてデータ、クエリです。LLM にこの問題を解決させるよう依頼します。」

例えば、「ある従業員の給付金控除が差し引かれなかった理由」のような複雑な問いに対し、複数のツールを連携させて情報を取得するのではなく、HRIS（人事情報システム）や給与計算のスキーマを LLM に渡し、SQL を記述させます。LLM は SQL 生成に非常に優れており、コンテキストウィンドウ内にデータそのものを含めずにスキーマのみで複雑なクエリを実行できます。

このアプローチにより、ハルシネーション（嘘の回答）のリスクを大幅に低減し、必要なツールの数を最小限に抑えることに成功しました。また、取得したデータをキャッシュすることで、同じデータへのアクセスコストと時間を削減し、ユーザー体験も向上しています。

3. 直感を捨てろ：評価駆動開発（EDD）とトレードオフの管理

AI システムの開発において最も難しいのは、「システムが正常に動作しているか」をどう判断するかです。Rippling はこれを解決するために、「評価駆動開発（Eval-Driven Development: EDD）」を徹底して導入しました。

コードの全行を知っていても、LLM の確率的な性質ゆえに挙動がどうなるかは予測できません。「直感に従う」ことは危険です。Rippling では、すべての変更に対して評価を行い、その結果が真実であると信じるスタンスを貫いています。

しかし、LLM は確率的であるため、「1 回実行してパスした＝100% 合格」とは言えません。統計的な信頼を得るためには、反復回数（試行回数）を増やす必要があります。Rippling ではウィルソンの信頼区間を用いて、必要な反復回数を科学的に算出しています。

「評価における反復回数を増やしていくことで、1 回だけ実行して勝利を宣言することはできません。」

例えば、1 回パスしても 95% の信頼区間では実際の合格率は最低 20% になる可能性があります。3 回連続でパスしても下限は 44% に留まるかもしれません。反復回数が増えるほど、真の合格率に収束し、確信が持てるようになります。

このアプローチには明確なトレードオフが存在します。「コスト」「不確実性（信頼度）」「検出遅延（ラグ）」の 3 つのうち、同時に満たせるのは 2 つだけです。

• 低コスト・低遅延: コミットごとに評価を実行する「スモーク評価」。ただし、不確実性は高くなります。
• 低コスト・低不確実性: 本番環境前のステージで実行する「ヘルスイベント」。ただし、検出に時間がかかります（ラグ大）。

Rippling はこれらのバランスを戦略的に使い分けています。すべてのコミットに対しては軽量なスモーク評価を行い重大な問題を検出し、本番展開前にはより厳格なヘルスイベントを実行して不確実性を下げます。

まとめ：AI 構築の未来への示唆

Rippling の実践が示すのは、複雑さを増幅させるアーキテクチャよりも、シンプルで統一的な構造こそがエンタープライズ AI の信頼性を支えるという事実です。また、直感に頼る開発から脱却し、統計的な評価に基づいてコストと品質のバランスを最適化することが、LLM ベースシステムの継続的改善には不可欠です。

モデルがさらに強力になる未来において重要なのは、複雑なグルーコードを LLM に任せるのではなく、原子レベルの基本部品（スキーマや汎用ツール）を整備し、評価を最優先する姿勢にあります。"評価が真実を語る"という原則は、これから AI を構築するすべてのエンジニアにとって、避けて通れない教訓となるでしょう。