8月12日、Omri Bruchimが「Building monday.com Sidekick: Why Capable Agents Need More Than Just Tools」と題した記事を公開した。monday.comのAIアシスタント「Sidekick」を本番運用する中で発見した「ツールを増やすほど性能が落ちる」という問題と、それを解決するために再設計したマルチエージェント・アーキテクチャについて詳しく紹介されている。
ツールを増やすほど、エージェントは劣化した
多くのAIエージェントの開発者が同じ道をたどる。最初はシンプルな構成で始め、機能を拡充するたびにツールを追加していく。monday.comも例外ではなかった。
V1のSidekickは、1つの汎用エージェントと、増え続けるツールリストという構成だった。プロトタイプ段階では十分に機能した。プロジェクトの要約、ボードの更新、ファイル分析、ブロッカーの検出といった機能を確認できた。
しかし本番環境に移行すると、問題が次々と顕在化した。著者がまとめた失敗パターンは以下のとおりだ：
- ツール選択の精度が低下：説明が似ているツールが増えるほど、モデルが正しいものを選べなくなった
- コンテキストの圧迫：ツールのスキーマ定義が増えるほど、ユーザーの要求や実際の作業データに使えるコンテキストウィンドウが減った
- プロンプトの肥大化：リサーチ、コンテンツ生成、データ分析、ボード操作、ファイル処理…すべてを1つのプロンプトに詰め込まざるを得なくなった
- 長いワークフローの脆弱性：中間ステップの失敗が推論ループ全体を崩壊させた
- デバッグ困難：失敗の原因がプランニングなのか、ツール選択なのか、コンテキスト取得なのかを切り分けられなくなった
- コストとレイテンシの増加：エージェントが不要なツールを探索したり、同じツールを繰り返し呼び出したりした
- テストの組み合わせ爆発：ツールを1つ追加するだけで、無関係に見えるワークフローまで壊れるようになった
「ツールを増やすほど、紙の上では能力が上がっていた。しかし実際には下がっていた」
これがV1から得た最大の教訓だ。
なお、ツール数の増加がLLMの性能に与える悪影響は、monday.com固有の現象ではない。ToolLLMをはじめとする先行研究でも、利用可能なツール数が増えるほどモデルの選択精度が低下する傾向が報告されており、本番規模での運用がこの問題を鮮明に浮かび上がらせた格好だ。
再設計の核心：「境界を引く」こと
V2の本質的な変化は「複数エージェントへの移行」ではなく、プランニング・ドメイン固有の推論・ツール使用・実行それぞれの責任範囲を明確に分離することだった。
新アーキテクチャは以下の層で構成される：
- プロダクトコンテキスト層：ユーザーがどのボード・ダッシュボード・ドキュメントからSidekickを開いたかという情報を起点にする
- コンテキスト＆パーミッション層：エージェントに渡す前に、アクセス権限を考慮したうえで必要な情報だけを取得する。これはオプションの安全フィルタではなく、基盤要件として設計されている
- オーケストレーションエージェント：ユーザーの意図を解釈し、シンプルなリクエストは直接処理、複雑なものはサブエージェントやサンドボックスに委譲する
- サブエージェント：コンテンツ生成エージェントはボード管理ツールを必要としない、という発想で、タスクごとに専門化された小さいエージェント
- ツール：bounded（境界が明確）な操作に使う。さらに3段階の分類システムを導入し、エージェントがツールを明示的にアクティベートしないと完全なスキーマを参照できない設計にした。「キッチン全体を投げつけるのではなく、メニューを渡す」という表現が秀逸だ
- サンドボックス：ファイル処理、コード実行、反復的な変換など、単一ツール呼び出しでは収まらない作業のための独立した実行環境
- オブザーバビリティ＆評価層：モデル呼び出し、ツール呼び出し、委譲、サンドボックス活動、レイテンシ、トークン使用量、失敗をすべてトレースする
サンドボックスという「作業場」の発想
このアーキテクチャで特に重要な概念がサンドボックスだ。
ツール呼び出しは、「ボードを読む」「アイテムを更新する」「ドキュメントを検索する」といった境界が明確な操作に向いている。しかし、「3つのCSVをボードデータと突き合わせて異常値を探し、グラフを作成する」といったタスクは、ツール呼び出しの連鎖では対応できない。
サンドボックスはエージェントに独立した作業空間を与える。ファイルを保存し、コードを書いて実行し、パースエラーが出れば修正し、チャートを生成する。これらの中間状態はすべてサンドボックス内に留まり、メインエージェントのコンテキストウィンドウを圧迫しない。メインエージェントが受け取るのは最終結果と処理サマリーだけだ。
著者はこれを「アナリストにスプレッドシートの問題を解かせるとき、列操作ごとに別のAPIを呼ばせたりしない。作業スペースと権限と明確なゴールを渡す」と説明している。
ツール・サブエージェント・サンドボックスの使い分け
| 操作の性質 | 使う仕組み |
|---|---|
| 境界が明確で監査可能な操作（ボード読み取り、アイテム更新など） | ツール |
| 専門的な推論が必要（リスク分析、コンテンツ生成など） | サブエージェント |
| 中間状態があり、ファイルやコードを伴う作業 | サンドボックス |
実際の例として、「3つのボードと添付CSVからプロジェクトデータを分析し、主要なリスクを特定して、エグゼクティブ向けアップデートを作成する」というリクエストでは、ツール・サブエージェント・サンドボックスの3つすべてが1つのワークフロー内で使われるという。
LangChainの役割
LangChainはオーケストレーション・エージェントランタイム層で使われている：
- LangGraphとDeep Agents：ステートフルな実行、委譲、プランニング、マルチステップワークフロー
- **LangSmith**：トレーシング、デバッグ、評価、データセット管理、エージェント実装の比較
- サンドボックス：ファイル・コード・中間状態を伴う独立実行環境
ここで登場する「Deep Agents」はLangChainが提唱する概念で、複数のエージェントが階層的に連携し、長時間・多段階のタスクをステートフルに処理するアーキテクチャパターンを指す。LangGraphのドキュメントでは、このようなマルチエージェント構成の実装方法が詳しく解説されている。
著者が評価するのはLangChainが「独自の巨大な抽象レイヤーを強制しない」点だ。ステートフルな実行、明示的な委譲、統合されたトレーシング、そしてmonday.com独自のツール・取得層・モデル・権限制御をそのまま使い続けられる柔軟性が決め手だったという。
「フレームワークがシステム設計の必要性をなくすわけではない。重要な決定のほとんどはプロダクト・ドメイン固有のまま残る。LangChainの価値は、汎用エージェントランタイムの再構築ではなく、monday.com固有のコンテキスト・権限・ツール・評価・UXに工数を集中できることだ」と述べている。
本番稼働から数ヶ月が経過した現在、クロスコンテキストのプロジェクトレポート生成やファイル処理といったユースケースで、このアーキテクチャが機能していることが確認されているという。フラットなエージェント設計の限界にぶつかっている開発者にとって、参考になる実録だ。
詳細はBuilding monday.com Sidekick: Why Capable Agents Need More Than Just Toolsを参照していただきたい。
