エージェントがコンテキストエンジニアリングのためにファイルシステムを活用する方法
LangChain Blog は、AI エージェントの信頼性を高めるために、コンテキストエンジニアリングにおけるファイルシステムアクセスの重要性と、その活用方法について詳述している。
キーポイント
コンテキストエンジニアリングの定義と課題
エージェントがタスクを遂行するために必要な情報を正しく取得・提供することが重要だが、現在のシステムでは情報不足や文脈の欠落により失敗するケースが多い。
ファイルシステムの役割
ディープエージェントはファイルシステムツールを通じて、ファイルの読み書き、編集、リスト表示、検索を行うことで、限られたコンテキストウィンドウを超えた情報を活用できる。
失敗要因の分析
エージェントの失敗は、モデル能力不足か、必要な文脈（コンテキスト）へのアクセス権がないかのどちらかに起因し、ファイルシステムはこの「文脈の欠落」を解消する鍵となる。
重要な引用
Context engineering is the 'delicate art and science of filling the context window with just the right information for the next step'
Deep agents can use these tools to read, write, edit, list, and search for files in their filesystem.
If the context that the agent needs is not in the total context, the agent cannot succeed.
影響分析・編集コメントを表示
影響分析
この記事は、LLM エージェントの設計思想において「コンテキストウィンドウの制約」を超えるための具体的なアーキテクチャ（ファイルシステム活用）を提示しており、実務レベルでのエージェント構築における重要な指針となる。特に、RAG（検索拡張生成）やツール使用が不完全な場合に陥りがちな文脈不足の問題に対し、永続的なストレージへのアクセスという解決策を示すことで、業界のベストプラクティスを更新する内容である。
編集コメント
エージェントの信頼性を高める上で、モデルの性能だけでなく「いかに必要な文脈を動的に取得するか」という設計思想が重要であることを示唆する良質な技術記事です。
By Nick Huang
ディープエージェントの重要な機能の一つは、ファイルシステムツールセットへのアクセス権を持つことです。ディープエージェントはこれらのツールを使用して、ファイルシステムの読み取り、書き込み、編集、一覧表示、および検索を行うことができます。
この投稿では、なぜファイルシステムがエージェントにとって重要だと考えているのかを解説します。ファイルシステムがどのように役立つかを理解するためには、まず現在エージェントが抱える課題について考える必要があります。エージェントの失敗は、(a)モデルの性能が不十分であるか、(b)適切なコンテキストにアクセスできないかのいずれかに起因します。コンテキストエンジニアリングとは、「次のステップに必要な情報を正確に特定し、コンテキストウィンドウに充填するという繊細な芸術および科学」を指します。コンテキストエンジニアリングの仕組み、そしてそれがどのように失敗しうるかを理解することは、信頼性の高いエージェントを構築する上で不可欠です。
コンテキストエンジニアリングの視点
現代のエージェントエンジニアの仕事は、コンテキストエンジニアリングのレンズを通して捉えることができます。エージェントは一般的に多くのコンテキスト（すべてのサポートドキュメント、すべてのコードファイルなど）へのアクセス権限を持っています。着信する質問に答えるために、エージェントは重要なコンテキスト（その質問に答えるのに必要な情報を含む）を必要とします。そして、その質問への回答を目指しながら、エージェントはあるコンテキストの塊を取得し（それをコンテキストウィンドウに取り込みます）。
この視点から眺めると、エージェントにとってコンテキストエンジニアリングが「失敗」する可能性は数多く存在します：
- エージェントが必要とするコンテキスト（文脈）が総コンテキストに含まれていない場合、エージェントは成功できません。例：カスタマーサポートエージェントがある質問に答えるために特定のドキュメントページへのアクセスを必要としていますが、そのページがインデックスされていない場合です。
- エージェントが取得したコンテキストが必要とするコンテキストを包含していない場合、エージェントは正しく回答できません。例：カスタマーサポートエージェントがある質問に答えるために特定のドキュメントページへのアクセスを必要としており、そのページは存在してインデックスされていますが、エージェントによって取得されません。
- エージェントが取得したコンテキストが必要とするコンテキストよりも大幅に大きい場合、エージェントはリソース（時間やトークン、あるいはその両方）を浪費することになります。例：カスタマーサポートエージェントが単一の特定のページのみを必要としており、エージェントが100ページの情報を取得した場合です。
エージェントエンジニアとしての私たちの仕事は、「赤を緑に合わせる（つまり、エージェントが取得するコンテキストが必要情報として可能な限り小さな上位集合になるようにすること）」です。
適切なコンテキストを特定しようとする際、いくつかの具体的な課題が生じます。
- トークン数が多すぎる（取得したコンテキスト ＞ 必要なコンテキスト）ウェブ検索などの一部のツールは、大量のトークンを返すことがあります。数回のウェブ検索を行うだけで、会話履歴内に数万トークンに達することもあります。最終的には厄介な「400 Bad Request」エラーに遭遇するかもしれませんが、その前に LLM の利用料金が高騰し、パフォーマンスが低下します。
- 大量のコンテキストが必要（必要なコンテキスト ＞ 対応可能なコンテキストウィンドウ）場合によっては、エージェントが質問に答えるために多くの情報が必要になることがあります。この情報は通常、単一の検索クエリで返すことができないため、「エージェント検索（agentic search）」という考え方に多くの人が注目しています。つまり、エージェントが検索ツールを繰り返し呼び出すことを許可するものです。この手法の問題点は、コンテキストの量が急速に増加し、すべてをコンテキストウィンドウに収められなくなることです。
- 専門的な情報の発見（取得したコンテキスト ≠ 必要なコンテキスト）エージェントが入力に対応するために、数百または数千のファイルに埋もれた専門的な情報を参照する必要がある場合があります。エージェントはどのようにしてその情報を確実に見つけることができるでしょうか？もし見つからない場合、取得されたコンテキストは質問に答えるために必要なものとはなりません。セマンティック検索（semantic search）の代替案（または補完手段）はあるのでしょうか？
- 時間経過に伴う学習（総コンテキスト ≠ 必要なコンテキスト）場合によっては、エージェントが質問に答えるために必要なコンテキスト（保有するツールや指示内）にアクセスできないことがあります。エンドユーザーは、エージェントとのやり取りの中で、そのコンテキストが何であるかを示唆する手がかり（暗黙的または明示的に）を頻繁に提供します。エージェントがその情報をコンテキストとして追加し、今後の反復処理で活用する方法はあるでしょうか？
これらはすべて一般的な障壁であり、私たちの多くは以前にこれらの異なるバリエーションに直面したことがあります！
エージェントがファイルシステムをどのようにしてより良くするか？
最も単純な言葉で言えば：ファイルシステムは、エージェントが無限量のコンテキストを柔軟に保存、取得、更新するための単一のインターフェースを提供します。
上記の各シナリオでこれがどのように役立つかを見てみましょう。
トークン数が多すぎる（取得されたコンテキスト >> 必要なコンテキスト）
ツール呼び出しの結果やメモを会話履歴に保持する代わりに、エージェントはこれらをファイルシステムに書き込み、必要に応じて*関連情報*を selectively（選択的に）検索することができます。Manus はこのアプローチについて最初に公に語ったものの一つです こちら をご覧ください。以下の図は彼らのブログ記事からのものです。
最初のウェブ検索ツールの例を取り上げてみましょう。私はウェブ検索を実行し、ツールから 10k トークンの生コンテンツを取得します。その内容の大部分は、常に必要とは限りません。もしそれをメッセージ履歴に格納すると、10k トークンすべてが会話全体を通じてそこに留まり、Anthropic の請求額を押し上げてしまいます。しかし、その大きなツール結果をファイルシステムにオフロードすれば、エージェントは特定のキーワードでインテリジェントな grep 検索を行い、必要なコンテキストのみを会話に読み込むことができます。
この例では、エージェントはファイルシステムを大規模なコンテキストのための仮のメモ帳（スクラッチパッド）として効果的に使用しています。
大量のコンテキストが必要（必要なコンテキスト < 対応可能なコンテキストウィンドウ）
場合によっては、エージェントが質問に答えるために多くのコンテキストを必要とすることがあります。ファイルシステムは、LLM（大規模言語モデル）が必要に応じて情報を動的に保存したり取得したりすることを可能にする優れた抽象化を提供します。これの例としては以下が挙げられます：
- 長期にわたる回答の場合、エージェントは計画を立ててそれを実行する必要があります。その計画をファイルシステムに書き込むことで、後でエージェントが何を行うべきかを確認するために、この情報をコンテキストウィンドウ内に再読み込みすることができます（例：「暗唱を通じて注意を操作する」）
- このコンテキストすべてを処理するために、エージェントはサブエージェント（下位エージェント）を起動することがあります。これらのサブエージェントが作業を行い、何かを学ぶ際、単にメインのエージェントに対して学習結果を返信するのではなく、代わりにファイルシステムに知識を書き込むことができます（例：電話ゲームの伝言遊びによる情報の劣化を最小限に抑える）
- 一部のエージェントは、物事のやり方に関する多くの指示を必要とします。これらの指示をすべてシステムプロンプトに詰め込んでコンテキストを肥大化させるのではなく、ファイルとして保存し、エージェントが必要に応じて動的にそれらを読み込ませることができます（例：Anthropic のスキル）
ニッチな情報の発見（取得されたコンテキスト ≠ 必要なコンテキスト）
LLM（大規模言語モデル）の波が到来した当初、セマンティック検索はコンテキストを取得するための最も人気のあるアプローチの一つでした。これは特定のユースケースでは効果的ですが、ドキュメントの種類（例えば技術的なAPIリファレンスやコードファイルなど）によっては、テキスト内にセマンティックな情報が不足しているため、セマンティック検索が非常に不適切な結果をもたらすことがあります。
ファイルシステムは、エージェントがls、glob、grepツールを使ってコンテキストをインテリジェントに検索することを可能にする代替手段を提供します。最近Claude Codeを使用したことがある方なら、それが適切なコンテキストを見つけるためにglob検索とgrep検索を強く依存していることをご存知でしょう。この手法が成功するのには、いくつかの鍵があります。
- 現在のモデルは、ファイルシステムをたどることを理解するように特別に訓練されています
- 情報はすでに論理的（ディレクトリ）に構造化されていることが多い
- globとgrepを使用することで、エージェントは特定のファイルだけでなく、特定行や特定文字を隔離することも可能
- read_fileツールを使用することで、エージェントはファイルから読み込むべき行を指定できます
これらの理由から、ファイルシステムを使用し（そしてファイルシステムの使用によって得られる検索機能を活用することで）、より良い結果を生み出す状況が存在します。
セマンティック検索が依然として有用であり、ファイルシステム検索と組み合わせて使用できることに注意してください。Cursorは最近、両方を併用する利点を強調したブログ記事こちらを投稿しました。
時間経過による学習（総コンテキスト ≠ 必要なコンテキスト）
エージェントが失敗する大きな理由の一つは、関連するコンテキスト（文脈）を見落としていることです。エージェントの性能を向上させるための優れた方法は、通常、適切なコンテキストにアクセスできるようにすることです。場合によっては、データソースを追加したりシステムプロンプトを更新したりすることがそれに該当します。
システムプロンプトを更新する一般的なプラクティスは以下の通りです：
- エージェントが適切な指示を欠いていた例を確認する
- 専門分野のエキスパートから関連する指示を取得する
- その指示でプロンプトを更新する
多くの場合、エンドユーザーこそが最適な専門分野のエキスパートとなります。エージェントとの対話を通じて、ユーザーは適切な関連指示が何であるかについて、暗黙的または明示的に重要な手がかりを提供することがあります。そこで考えたいのは、上記の3番目のステップ（指示でプロンプトを更新する）を自動化する方法があるかどうかです。
私たちは、エージェントの指示（またはスキル）は、他のコンテキストと同様のものであり、ファイルシステムがエージェント自身の指示を保存・更新するための場所として機能できると考えています。
ユーザーからのフィードバックが与えられた直後、エージェントは自身のファイルに書き込み、重要な情報を記憶することができます。これは、特にユーザー固有の名前、メール、その他の好みなど、クイックで一回限りの事実に対して非常に有効です。
これは完全に解決されたわけではなく、まだ浮上しつつあるパターンですが、LLM が時間とともに独自のスキルセットや指示を成長させ、将来の反復処理において必要なコンテキストにアクセスできるようにするという、エキサイティングな新方式です。
ディープエージェントがファイルシステムをどのように活用するかを見る
Deep Agents というオープンソースリポジトリ（Python、TypeScript）があり、これによりファイルシステムにアクセスするエージェントを迅速に構築できます。ファイルシステムを使用するこれらのコンテキストエンジニアリングのトリックの多くが組み込まれています！おそらくさらに多くのパターンが登場するでしょう - Deep Agents を試して、ご意見をお聞かせください！
関連コンテンツ
エージェントアーキテクチャ
LangSmith
オープンソース
LangSmith と LangChain OSS が EU AI Act の要件を満たすのをどのように支援するか
J. Talbot,
B. Weng
2026 年 4 月 27 日
7 分
ケーススタディ
LangSmith
クレジット・ジーニーがInsights Agentを活用してAI金融アシスタントを改善した方法
D. Li,
J. Ngai,
G. Lozano Palacio,
C. Yuan
2026年4月20日
5分
観測可能性と評価（Observability & Evals）
LangSmith
LangSmithにおける再利用可能な評価者（Evaluator）と評価テンプレート
C. Qiao,
J. Talbot
2026年4月16日
4分
エージェントの実際の動作を確認する
LangSmithは、当社のエージェントエンジニアリングプラットフォームであり、開発者がすべてのエージェントの意思決定をデバッグし、変更の評価を行い、ワンクリックでデプロイすることを支援します。
原文を表示
By Nick Huang
A key feature of deep agents is their access to a set of filesystem tools. Deep agents can use these tools to read, write, edit, list, and search for files in their filesystem.
In this post, we’ll walk through why we think filesystems are important for agents. In order to understand how filesystems are helpful, we should start by thinking through where agents can fall short today. They either fail because (a) the model is not good enough, or (b) they don’t have access to the right context. Context engineering is the “delicate art and science of filling the context window with just the right information for the next step”. Understanding context engineering - and how it can fail - is crucial for building reliable agents.
A view of context engineering
One way to view the job of a modern day agent engineer is through the lens of context engineering. Agents generally have access to a lot of context (all support docs, all code files, etc). In order to answer an incoming question, the agent needs some important context (which contains the context needed to answer the question). While aiming to answer said question, the agent retrieves some body of context (to pull into it’s context window).
When viewed from this lens, there are many ways that context engineering can “fail” for agents:
- If the context that the agent needs is not in the total context, the agent cannot succeed. Example: a customer support agent needs access to a certain documentation page to answer a question, but that page hasn’t been indexed.
- If the context that the agent retrieves doesn’t encapsulate the context that the agent needs, then the agent will not be able to answer correctly. Example: a customer support agent needs access to a certain documentation page to answer a question, that page exists and is indexed, but is not retrieved by the agent.
- If the context that the agent retrieves is far larger than the context that the agent needs, then the agent is being wasteful (with time, tokens, or both). Example: a customer support agent needs a single specific page, and the agent retrieves 100 pages.
Our job as agent engineers is to fit red to green (to make sure that the context the agent retrieves is as small of a superset of the needed information as possible)
A few specific challenges arise when seeking to isolate the appropriate context
- Too many tokens (retrieved context >> necessary context) Some tools, like web search, can return a lot of tokens. A few web searches can quickly build up to tens of thousands of tokens in your conversation history. You might eventually run into a pesky 400 bad request error, but well before that, your LLM bill balloons and performance degrades.
- Needs large amounts of context (necessary context > supported context window)Sometimes an agent may actually need a lot of information in order to answer a question. This information usually cannot be returned in a single search query, which is why many have leaned into the idea of “agentic search” - letting an agent call a search tool repeatedly. The issue with this is that the amount of context quickly grows to a point where it can’t all fit into its context window.
- Finding niche information (retrieved context ≠ necessary context)Agents may need to reference niche information buried in hundreds or thousands of files in order to handle an input. How can the agent reliably find that information? If it cannot - then the retrieved context will not be what is needed to answer the question. Are there alternatives (or complements) to semantic search?
- Learning over time (total context ≠ necessary context)Sometimes the agent may just not have access to the necessary context for answering a question (either in the tools or instructions it has). The end user may often provide clues (implicitly or explicitly) in their interactions with the agent what that context may be. Is there a way for the agent to add that to its context for future iterations?
These are all common hurdles, and most of us have faced different flavors of these before!
How can a filesystem make an agent better?
In the simplest terms: a filesystem provides a single interface through which an agent can flexibly store, retrieve, and update an infinite amount of context.
Let’s see how this can help in each of the scenarios listed above.
Too many tokens (retrieved context >> necessary context)
Instead of using the conversation history to hold all tool call results and notes, an agent can write these to the filesystem, and then selectively look up *relevant information* when necessary. Manus was one of the first to publicly talk about this approach - the below diagram is from their blog post.
Let’s take that first example with the web search tool. I run a web search, and I get back 10k tokens of raw content from the tool. Most of that content is probably not necessary all the time. If I put that in my messages history, all 10k tokens are going to sit there for the entire conversation, driving up my Anthropic bill. But if I offload that large tool result to the filesystem, the agent can then intelligently grep search for certain key words, and then read only necessary context into my conversation.
In this example, the agent is effectively using the filesystem as a scratch pad for large context.
Needs large amounts of context (necessary context < supported context window)
Sometimes agents require a lot of context to answer the question. Filesystems provide a nice abstraction for letting LLMs dynamically store and pull in more information as needed. Examples of this include:
- For long horizon answers, agents need to make a plan and then follow it. By writing that plan to the filesystem, the agent can then pull this information back into the context window later on, to remind the agent what it’s suppose to be doing (eg “manipulate attention through recitation”)
- To pour through all this context, the agent may spin up subagents. As these subagents do work and learn things, rather than just replying to the main agent with their learnings, they can write their knowledge to the filesystem instead (eg minimize the game of telephone)
- Some agents require a lot of instructions on how to do things. Rather than just stuff all these instructions into the system prompt (and bloat context) you can store them as files and let the agent dynamically read them as needed (eg Anthropic skills).
Finding niche information (retrieved context ≠ necessary context)
Semantic search was one of the most popular approaches to retrieving context early on in the LLM wave. It can be effective in some use cases, but depending on the type of document (e.g. technical API reference, code files), semantic may be very poorly placed due to a lack of semantic information in the text.
Filesystems provide an alternative to allow agents to intelligently search for context with ls, glob, and grep tools. If you’ve used Claude Code recently, you’ll know that it heavily relies on glob and grep search to find the right context it needs. There are a few keys to why this technique is successful.
- models today are specifically trained to understand traversing filesystems
- the information is often already structured logically (directories)
- glob and grep allow the agent to not only isolate specific files but also specific lines and specific characters
- The read_file tool allows the agent to specify which lines to read in from a file
For these reasons, there are situations where using filesystems (and the search capabilities you gain by using a filesystem) can create better results.
Note that semantic search can still be useful! And can be used in conjunction with filesystem search. Cursor recently wrote a blog highlighting the benefits of using both together.
Learning over time (total context ≠ necessary context)
A big reason agents mess up is they are missing relevant context. A great way to improve agents is usually to make sure they have access to the right context. Sometimes this can look like adding more datasources or updating the system prompt.
A common practice for updating the system prompt is:
- See an example where the agent was lacking appropriate instructions
- Get the relevant instructions from a subject matter expect
- Update the prompt with those instructions
Often times, the end user is actually the best subject matter expert. Through conversation with the agent, they may provide important clues (implicitly or explicitly) as to what the right relevant instructions are. So with that in mind - is there a way to automate the third step above (updating the prompt with those instructions)?
We think an agent’s instructions (or skills) are no different than any other context they might want to work with. A filesystem can serve as the place for agents to store and update their own instructions!
Immediately after user feedback is given, an agent can write to its own files and remember an important piece of information. This is great for quick, one-off facts, especially things that might be custom to a user like their name, email, or other preferences.
This hasn’t been fully solved and is still an emerging pattern, but it’s an exciting new way that LLMs can grow their own skillsets and instructions over time, making sure that for future iterations they have access to the necessary context.
See how a deep agent can make use of its filesystem
We have an open source repo called Deep Agents (Python, TypeScript) that lets you quickly build an agent that has access to a filesystem. A lot of these context engineering tricks that use the filesystem are baked in! There are almost certainly more patterns that will emerge - try Deep Agents out and let us know what you think!
Related content
Agent Architecture
LangSmith
Open Source
How LangSmith and LangChain OSS Help You Meet EU AI Act Requirements
J. Talbot,
B. Weng
April 27, 2026
7
min
Case Studies
LangSmith
How Credit Genie used Insights Agent to improve their AI financial assistant
D. Li,
J. Ngai,
G. Lozano Palacio,
C. Yuan
April 20, 2026
5
min
Observability & Evals
LangSmith
Reusable Evaluators and Evaluator Templates in LangSmith
C. Qiao,
J. Talbot
April 16, 2026
4
min
See what your agent is really doing
LangSmith, our agent engineering platform, helps developers debug every agent decision, eval changes, and deploy in one click.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み