LLMエージェントの性能を最大化！Sanityが実践する「コンテキスト設計」の秘訣

LLMエージェントのツール活用、その真の課題とは？

AIエージェント、特に大規模言語モデル（LLM）を活用したエージェントの構築において、しばしば「ツールをうまく使いこなせない」という問題に直面することがあります。多くの場合、開発者はこの問題を解決するために、より多くのツールを追加したり、既存のツールをさらに細分化したりしがちです。しかし、実はその根本的な原因は「ツールそのもの」にあるのではなく、「エージェントに与えるコンテキストの設計」にある、とSanityのコンテンツエージェント開発チームは提言しています。

本記事では、Sanityのリード開発者であるRosti氏が共有した洞察に基づき、優れたLLMエージェントを構築するための重要な3つの要素「Shape（形）、Detail on Demand（要求に応じた詳細）、Execution（実行）」に焦点を当て、特に「コンテキスト設計」がいかにエージェントの性能を左右するかを解説します。

Sanityとは？エージェント開発に最適な環境

LLMエージェントの具体的な設計に入る前に、Sanityというプラットフォームの理解が不可欠です。Sanityは、Anthropic、Figma、Linear、Mastraといった先進的な企業がウェブサイト、ドキュメント、Eコマース、アプリケーションのコンテンツを管理するために利用している「コンテンツオペレーティングシステム」です。

Sanityは主に以下の3つの要素で構成されています。

• Studio: スキーマ定義やコンテンツ編集を行う場所です。エディターはドキュメントを扱い、開発者はその背後にある構造を定義します。
• Content Lake: 構造化され、クエリ可能なJSON形式でコンテンツが保存される場所です。
• GROQ: JSONドキュメントのためのオープンソースのクエリ言語です。

エージェントの設計において、特にGROQは非常に重要です。エージェントがスキーマを理解できれば、正しいコンテンツを効率的に見つけることが可能になります。そして、コンテンツを確実に見つけられるようになれば、その上で様々な応用が可能になります。

Sanityがエージェントにとって理想的な環境である理由は、コンテンツが構造化されており、関係性が明示的で、クエリ言語が表現力豊かである点にあります。さらに、Sanityは10年近くにわたり公開で開発されてきたという実用的な優位性を持っています。ドキュメント、サンプル、多くのスキーマ、GROQクエリが公開されているため、モデルはSanityとGROQに関して豊富な学習データに触れてきました。この点が、全く未知のシステムを一からモデルに教え込む必要がないという大きなアドバンテージとなっています。

ツール数ではなく「ツール設計」の最適化

多くのエージェント開発者と同様に、Sanityチームも初期段階で共通の過ちを犯しました。それは、「ツールを追加すれば問題が解決するだろう」という発想で、次から次へとツールを増やしていったことです。

しかし、このアプローチはすぐに問題を露呈しました。ツールが多すぎると、エージェントはかえって一貫性を失い、何を行うべきかの判断に迷いが生じました。また、微妙に似たような機能を持つツールが増えることで、モデルはユーザーの本当の問題解決ではなく、どのツールを選択すべきかという「ツール選択」に多くの労力を費やしてしまうようになりました。

ここから得られた最大の教訓は、「機能を細かく刻んで小さなツールに分割するのをやめ、ツールをより広範な機能を持つものにする」ということでした。具体的には、以下の原則が重要です。

• ツールの境界を非常に明確にする: 各ツールが何をできるのか、できないのかを明確にします。
• 重複を排除する: 似たような機能を持つツールを統合するか、一方を削除します。
• より良い指示を書く: エージェントがツールを適切に利用できるよう、ツールの説明や指示を改善します。

つまり、**「より少ないツールでより多くのことをする（Do more with less tools）」**という考え方が、エージェントの効率と精度を向上させる鍵となるのです。

LLMエージェント性能向上の鍵は「コンテキスト設計」

ツール設計の最適化は表面的な教訓に過ぎず、より深いレベルでの学びは「コンテキスト」に関するものでした。コンテンツ操作の多くは、特定のコンテンツに対して非常に具体的なアクションを実行することを目的としています。

もし、あまりにも多くの生データをメインのコンテキストウィンドウに投入してしまうと、エージェントは動作が遅くなり、コストが増大し、多くの場合、単純に性能が低下します。これはモデルが本質的に悪いわけではなく、モデルに「間違ったもの」を「間違った解像度」で見させているためです。

Sanityチームは「どうすればモデルにすべてのデータを与えることができるか？」という問いを止め、「どうすれば最初にデータの『形（Shape）』を与えることができるか？」という問いに焦点を当てるようになりました。

この視点の転換は非常に重要でした。なぜなら、エージェントは最初に完全な詳細を必要としないからです。エージェントが必要とするのは、以下の点を判断できる程度の「粗い全体像」です。

• 正しいものをフェッチしたか？
• これは適切な種類のコンテンツか？
• 結果は大きすぎるか、小さすぎるか？
• これに基づいて行動しても安全か？
• さらに深掘りすべきか、ここで停止すべきか？

この「Overview First, Detail on Demand（概要を最初に、要求に応じて詳細を）」というアイデアは、Sanityのシステム内で主に2つの場所で実践されています。

1. スキーマ表現の最適化

コンテンツエージェントにとって最も重要なことの一つは、もちろんスキーマを解釈できることです。しかし、実際のスキーマは非常に巨大になる可能性があります。多くのドキュメントタイプ、ネストされたオブジェクト、配列、参照、バリデーション、再利用可能なオブジェクトタイプなどが含まれています。これらのすべてをそのままコンテキストに投入すると、モデルは大量の詳細を目にしますが、明確さをほとんど認識できません。

そこでSanityは、スキーマを圧縮します。モデルには、まずスキーマの「概要」を与えます。すべての詳細ではなく、その「形」だけです。この概要は、以下のような情報を提供します。

• 存在するドキュメントタイプ
• 重要なトップレベルのフィールド
• 各参照タイプが何を参照しているか
• どのタイプがそれらを参照し返しているか

このように、巨大なJSONの塊をそのまま渡す代わりに、コンテンツモデルの「ぼやけた地図」や「グラフ」に近いものをモデルに提供します。

この変更は、多くの問題が実際には「関係性」に関するものであるため、非常に重要でした。具体的な例として、Sanity自身のStudioにある「ブログ投稿」「著者」「人物」というドキュメントタイプを考えてみましょう。Studioを知っている人間は「ブログ投稿」が「著者」を使用することを知っていますが、モデルにとっては「著者」と「人物」の区別がつきにくい場合があります。

もしユーザーがエージェントに「Samが書いたブログ投稿はいくつありますか？」と尋ね、エージェントが圧縮されたビューを見ずに「人物」ドキュメントタイプでSamを探し、それをブログ投稿に接続しようとすると、結果は「一致なし」となり、モデルは誤った回答を返すでしょう。

しかし、モデルがこの圧縮されたビューを最初に見ていれば、「ブログ投稿は『著者』を参照しており、『人物』ではない」と判断できます。「著者」は843件のブログ投稿からの参照がある、といった情報も得られます。この一つの圧縮ビューが、驚くほど多くの誤った挙動を修正しました。

つまり、パターンは「概要を最初に、そして要求に応じて詳細を」です。モデルがスキーマの正確な構造を本当に知る必要があるときに、初めて「ズームイン」することを許可します。

例えば、会社（Company）ドキュメントタイプが「連絡先（contacts）」の配列を持っているとします。モデルはまず、そこに興味深い構造があることを示唆する概要を見ます。次に、その部分が重要であれば、「連絡先」の配列とその中のキーを見ることができます。さらに深く掘り下げる必要がある場合は、さらにズームインして、「人物（person）.profile」とそのオブジェクトに紐づく関連キーを見ることができるのです。

2. 大規模なクエリ結果の扱い方：「セット」の活用

モデルがスキーマの適切な全体像を把握できたとしても、次の問題は通常、そのスキーマ自体ではなく、いかにそれをスケールさせるか、つまり「数十、数千、あるいは数十万ものドキュメントを、メインコンテキストにすべて投入することなく、モデルに扱わせるか」という点になります。

ここでの最も重要なアイデアは、「セット（Sets）によって、大規模なコンテンツを、そのコンテンツ自体をコンテキストにプッシュすることなく扱うことができる」というものです。

簡潔に言えば、「セット」とは「圧縮されたワーキングメモリ」のことです。これは完全なペイロードではなく、クエリ結果への再利用可能なハンドルであり、いくつかの有用なメタデータが付随しています。セットを作成する際に、Sanityは以下のような情報を自動的に収集・付与します。

• ドキュメントのカウント
• タイプの内訳
• 数値や日付の最小値と最大値
• 基になるクエリ自体

これにより、エージェントは詳細なコンテンツデータそのものを見ることなく、その集合に関する高度な情報を活用して、より賢明な判断を下すことができるようになります。

まとめ：より賢いLLMエージェント構築のために

本記事では、Sanityの事例を通して、LLMエージェントの性能を最大化する上で「コンテキスト設計」がツールの数以上に重要であることを解説しました。

主要な教訓は以下の通りです。

• ツール設計: 機能を細分化しすぎず、より広範な機能を持つツールにし、境界を明確にして重複を排除する。「より少ないツールでより多くのことをする」という原則が重要です。
• コンテキストの「形」を優先: 生データをすべて投入するのではなく、まずはデータの「形」や「概要」をモデルに提示し、必要に応じて詳細を「要求に応じて」提供する「Overview First, Detail on Demand」のアプローチが効果的です。
• スキーマと大規模コンテンツの効率的な扱い: 巨大なスキーマは概要から提示し、大規模なクエリ結果は「セット」という圧縮されたワーキングメモリで扱うことで、コンテキストの効率とモデルの判断精度を高めます。

これらの原則を実践することで、より賢く、より効率的で、より信頼性の高いLLMエージェントを構築することが可能になります。エージェント開発において、ぜひ「コンテキスト設計」の重要性を再認識し、その最適化に取り組んでみてください。

参考動画

If your agent is bad at using tools, you don't have a tool problem, you have a context problem