シェルツールはコンテキストエンジニアリングの万能薬ではありません

エージェントが備える最も重要なツールは、自前でコンテキストを構築するために使用できる検索ツールです。LlamaIndexとLangChainによる最近の投稿により、エージェントがコンテキストエンジニアリングに必要なのは、シェルツールとファイルシステムだけなのかという議論が巻き起こりました。残念ながら、この議論はすぐにファイルシステム対データベースという間違った方向に逸れてしまいました。

この投稿は、エージェントが独自のコンテキストを構築するために必要な、適切な検索インターフェースとは何かという問いに改めて焦点を当てるものです。まず、シェルツールと専用データベースツールのトレードオフについて論じます。それを基に、エージェントのニーズに合った適切なインターフェースを見つけるための実用的なフレームワークを提示します。

エージェントにとって「コンテキスト構築」が具体的に意味するもの

初期のRetrieval-Augmented Generation（RAG）パイプラインでは、開発者が肯定的な検索パイプラインを設計し、大規模言語モデル（LLM）はコンテキストを受動的に受け取るだけの存在でした。そしてこれが、根本的な制限となっていました。コンテキストは、必要かどうかにかかわらず、すべてのクエリで取得され、それが実際に役立つかどうかも確認されなかったのです。

エージェント型RAGへの移行により、エージェントは独自のコンテキストを構築するための一連の検索ツールを利用できるようになりました。たとえば、Claude Code [1]とCursor [2]は、タスクの必要に応じて、エージェントが異なる検索ツールを選択し、さらにはそれらを組み合わせてクエリーを連鎖的に実行することもできます。

コンテキストエンジニアリングに用いる検索インターフェースの種類

コンテキストは、ウェブ上、ローカルファイルシステム、データベースなど、さまざまな場所に存在します。エージェントは、これらのコンテキスト外の各データソースと、次のようなツールを通じてやり取りできます。

• シェルツールはシェルコマンドを実行でき、ローカルファイルシステムにアクセスできます。組み込みシェルツールの例としては、Claude APIのbashツール、OpenClawのExecツール、LangChainのシェルツールがあります。
• 専用のデータベースツール、たとえばモデルコンテキストプロトコル（MCP）サーバー（例：Elastic Agent Builder MCPサーバー）やカスタムツール（例：run_esql(query)、db_list_index()）などは、データベースをクエリできます。
• 専用のファイル検索ツールは、ローカル（またはアップロードされた）ファイルを検索し、読み取ることができます（ただし、シェルに完全にアクセスする権限はありません）。組み込みファイル検索ツールの例としては、 Gemini APIのファイル検索ツール や OpenAIのファイル検索ツールがあります。
• ウェブ検索ツールは、ウェブから情報を取得できます。
• メモリツールは、長期記憶に保存し、長期記憶から呼び出します（保存方法は任意です）。

ご覧のとおり、シェルツールは用途が多彩で、以下のようなさまざまなデータソースからコンテキストを取得するために使用できます。

• ファイルシステム：エージェントはディレクトリ構造を探索（ls、find）、関連コンテンツを検索（grep、cat）し、十分なコンテキストが構築されるまで繰り返します。
• データベース：エージェントは、データベース用のコマンドラインインターフェース（CLI）ツール（例：elasticsearch-sql-cli）を使用したり、curl経由でのHTTP APIを呼び出たり、スクリプトを実行したりできます。これは、再利用可能な文書化した例をエージェントのコンテキストに挿入して、ツールを適切に使用できるようにするようなエージェントスキル（例：Elastic Agent Skills for Elasticsearch）と組み合わせると特に役立ちます。
• ウェブ：エージェントは、検索プロバイダーのAPIを通じてcurlコマンドでウェブ検索を実行できます。

ただし、シェルツールはシステムに直接アクセスできるため、隔離されたサンドボックス環境での実行や、実行されたすべてのコマンドのログを取得するなどの安全対策が必要です。

いつ、どの検索インターフェースを使用すべきか

最適な検索インターフェースは、データ、クエリパターン、ユースケースによって異なります。このセクションは、実際に取りかかる際の出発点として役立ちます。

ファイルシステムによってデータベースが時代遅れになったわけではない

ファイルシステムかデータベースかという議論は、ストレージ層自体の話ではありません。たとえば、LangChainの説明によると、LangChainのメモリシステムでは、実のところファイルシステムにメモリを保存しているわけではありません。代わりに、メモリをデータベースに格納し、それをエージェントに対して一連のファイルとして提示します[3]。

ファイルシステムは、コーディングエージェントなど、ファイルを中心としたユースケースに最適です。また、一時的なスクラッチパッドや作業メモリとしても、同時実行が問題とならない単一ユーザーや単一エージェントのシナリオにも適しています。こうした場合、物理的なファイルシステム、またはデータをファイルシステムとして提示する方法により、目的に合わせてインターフェースを構築する前の段階において柔軟性を確保できます。

しかし、ファイルシステムストレージには、同時実行性、手動によるスキーマ適用、アトミックトランザクションなどの弱点があります。これらは、アプリケーションをスケールしたり、マルチエージェントシナリオに移行したりする必要がある場合に、いっそう顕著になります。これらの弱点を無視するならば、本番用データベースがすでに備えているような、トランザクションの安全性やアクセス制御を支える何十年もの技術的蓄積のない、劣化版のデータベースを苦労して再発明する羽目に陥ります。さらに、ほとんどのエンタープライズ環境では、データベースを使用するかどうかを選ぶ余地はありません。なぜなら、ビジネスクリティカルなデータを格納するデータベースはすでに存在しているからです。

シェルツール+ファイルシステム

ファイルシステム検索の出発点として、シェルツールは最適な選択肢です。現在、この分野において多くの発展を牽引しているのは、コーディングエージェントです。コーディングエージェントはローカルファイル内のコードを扱うため、必然的にファイル依存度の高いユースケースとなります。したがって、LLMはコーディングタスク用に、トレーニング後の段階で微調整されます。そのため、多くのLLMはコードを書くことだけでなく、シェルコマンドの使用やファイルシステム内の移動も得意です。

lsやgrepのような、組み込みCLIを備えたシェルツールでファイルを検索することは効果的です。grepでは「matplotlibをインポートしているすべてのファイルを検索」といったクエリを、高速かつ高精度に、しかも低コストで実行できます。しかし、エージェントが「アプリは失敗した認証をどのように処理しているか」といった概念的なクエリを処理する必要がある場合、grepによるパターンマッチングはすぐに限界に突き当たります。このギャップを埋めるために、jina-grepのような、コマンドラインにセマンティック検索機能をもたらす代替手段もいくつか登場しています。

ただしgrepと、その代替手段であるセマンティック検索の多くは、コーパス全体に対してO(n)で実行されます。コードベースを対象とするユースケースなら、これで問題ないかもしれません。しかし、データが増えるとレイテンシーが目立つようになります。この場合、パフォーマンスを維持するにはインデックス化されたデータストアが必要となります。

シェルツール+データベース

セマンティック検索やハイブリッド検索など、データに対する検索機能を追加する別の方法は、たとえばCursorのように、機能をデータベースに格納することです。さらに、データに複雑なリレーショナル結合や集計が必要な場合、データベースインターフェースは不可欠です。

データがファイルシステム上ではなくデータベース内にある場合、特定のユースケースでは、シェルツールを軽量なデータベースインターフェースとして利用できます。クエリがCLIやcurlコマンドで十分に実行できるほどシンプルな場合、専用のデータベースツールを使うとかえって不要な複雑さが増えることがあります。

このアプローチは、エージェントが実際にどのようなクエリパターンを生成するかまだわからない、初期の探索段階にも適しています。この場合、Agent Skillsは、目的に合わせて構築されたツールに頼ることなく、正しくクエリを実行するための十分な構造を提供できます。ただし、反復的なタスクについてデータベースへの適切なクエリを見つけ出すためにエージェントが何度も試行錯誤しなければならない場合、インターフェースとしてシェルツールを使うことによって生じる、トークンオーバーヘッドによるデメリットが、追加のツールを避けられるという単純性のメリットを上回ってしまいます。

専用のデータベースツール

特に、繰り返し現れるクエリパターンが構造化されていたり分析的なものであったりする場合は、専用のデータベースツールが必要になります。VercelとBraintrustのブログ記事では、カスタマーサポートチケットや営業電話の書き起こしなどの半構造化データに関する実際の検索タスクで、さまざまな検索ツールセットを持つエージェントを比較しました（「『セキュリティ』に言及している未解決の問題はいくつありますか？」や「バグが報告され、後に誰かがそれを修正したと主張するPRが提出された問題を検索してください」など）[4]。

その結果、専用のデータベースツールを使用するエージェントは、シェルツールとファイルシステムのみを使用するエージェントに比べて、トークンの使用数が少なく、処理速度が速く、ミスも少ないことが判明しました。ここから得られる教訓は、クエリが半構造化データに対する分析推論を必要とする場合、データベースを直接扱うツールが正しい選択肢であるということです。

検索インターフェースを組み合わせる

すべてのクエリを適切に処理できる単一の検索インターフェースはありません。たとえば、Cursorはシェルツール（grepによる検索用）とセマンティック検索ツールを組み合わせて、エージェントがユーザーのプロンプトに基づいて適切なツールを選択できるようにしています。Cursorによると、エージェントは特定のシンボルや文字列を照合するためにgrepを選択し、概念的または行動に関する質問にはセマンティック検索を選択し、探索的なタスクには両方を使用するとのことです。

Vercelの実験レポートでも同じ結果が報告されています。シェルツールと専用データベースツールの両方にアクセスできるハイブリッドエージェントが、まず専用のデータベースツールを使用し、次にファイルシステムをgrepで検索して結果を確認するという方法を用いることにより、テストした全エージェントの中で最高のパフォーマンスを達成しました。しかし、このアプローチでは、ツールの選択と検証について検討するためにより多くのトークンと時間がかかります。

どちらの例でもパターンは同じです。インターフェースを組み合わせればどんな単一のインターフェースにも勝りますが、コストと遅延の増加というトレードオフも伴うということです。

適切なツールセットを見つけるための実践的な推奨事項

適切な検索インターフェースの組み合わせとは、小さく、目的が明確で、エージェントの実際のクエリパターンに即したものです。現在のベストプラクティスは、エージェントが何百ものMCPツールを備えるのではなく、備えるツールの数を最低限に抑えるということです。これは、利用可能なすべてのツールを事前に開示すると、コンテキストウィンドウが肥大化し、エージェントが実際にどのツールを使用すべきか混乱してしまうからです。たとえば、Claude Codeが備えているツールは約20個にとどまると報告されています。

その代わりに、段階的開示の考え方では、最小限のツールセットから始め、必要になったときにのみエージェントが追加機能を探すようにします。Anthropic [5]とCursor [6]の研究によると、このアプローチで47%–85%のトークンを節約できます。たとえば、Claude Codeはこの方法を直接実装しているため、エージェントはLLMを呼び出すたびにコンテキストを消費することなく、APIやデータベースにクエリする方法を段階的に発見できます。

エージェントのクエリパターンを把握できたら、エージェントがデフォルトでアクセス可能な検索ツールセットを見直すと良いでしょう。採用すべきツールを決定するにあたり、のトレードオフを考えるのに便利なのが、「敷居を低く、限界を高く」という原則です。限界の高いツールはエージェントの可能性を制限しません。たとえば、汎用的なシェルツールを使用すると、エージェントは曖昧なものを含めて完全なデータベースクエリを作成できますが、推論オーバーヘッド、遅延の増加、そして信頼性の低下を伴います。

敷居の低いツールはその逆です。これは、特定のクエリをラップし、最小限の推論オーバーヘッドでエージェントに即座にアクセスできる専用のツールであり、低コストと高い信頼性を実現します。ただし、事前のエンジニアリングが必要で、あらゆるクエリをカバーできるわけではなく、エージェントが適切なツールを選びにくくなる可能性もあります。

それぞれのツールは一長一短です。敷居の低いツールは、エージェントが正しく使用するのは簡単ですが、適用範囲は限定的です。限界の高いツールは多用途ですが、使いこなすにはより多くの推論が必要となります。

ほとんどのエージェントは、さまざまな検索ツールを組み合わせる必要があります。ただし、どのツールも、追加するに見合うだけの価値が求められます。まずは汎用的な検索ツール（たとえば search_database()ツールやシェルツール）から始めることをお勧めします。そして、セキュリティ目的で既に保持しているコマンドログを活用して、ツールの呼び出し、再試行、およびユーザークエリごとの呼び出し回数などを含め、エージェントが実際に何をしているかを追跡しましょう。そして、あるクエリパターンが繰り返されたり失敗したりすることを把握できたなら、それが専用ツールを作るべき合図です。

まとめ

ファイルシステム対データベースという議論は、エンジニアが問うべき実際の問題から目をそらしています。「エージェントが独自のコンテキストを構築するために必要な、適切な検索インターフェースとは何か」という問いの答えはおそらく、「単一のものではない」でしょう。

シェルツールは、さまざまな文脈外の情報源とやり取りするための汎用性の高いツールであり、良い出発点となります。しかし、構造化された分析クエリを使用するユースケースでは、専用のデータベースツールほど効率的で正確ではありません。

目標は、エージェントの実際のクエリパターンをうまく処理できる最小限の検索ツールを見つけることです。まずはシェルツールから始めて、エージェントが実際に何をしているかをログに記録しましょう。繰り返している、または失敗しているクエリパターンを把握できたら、専用なツールを設計すべき時です。

参照資料

1. Thariq（Anthropic）。Lessons from Building Claude Code: Seeing like an Agen（2026年）。

2. Cursor：Documentation。セマンティック検索とエージェント検索（2026年）。

3. Harrison Chase (LangChain)。How we built Agent Builder’s memory system（2026年）。

4. Ankur Goyal（Braintrust）とAndrew Qu（Vercel）。Testing if "bash is all you need"（2026年）。

5. Anthropic。Introducing advanced tool use on the Claude Developer Platform（2025年）。

6. Cursor。動的コンテキスト検出（2026年）。