AIエージェントに騙された？そんなあなたに、ディープエージェント入門

このブログは？

AI エージェントの宣伝文句に騙された！ と思っていた僕がやっぱりAIエージェントは便利だなと改宗した記録です。

そして、2025年12月17日 18:30 開催の「次世代AIエージェント Deep Agents 入門」というウェビナーでお話しさせていただきました。そのときのアーカイブも公開していますのでお役に立てましたら。

また、このブログの内容を10分でご紹介する動画も公開しています。こちらは、NotebookLMで生成したものです。

AIエージェントは、課題を与えられると解決のためにどんなタスクをどのような順序で処理すればよいのかを計画して、それを着実に実行してくれる、そんなとても自律的で頼りになる存在だと聞いていませんでしたか？

あるいは、「魔法少女リリカルなのは」の主人公・高町なのはの相棒ともいえるインテリジェントデバイス（魔法の杖）のレイジングハートは、なのはが突然攻撃を受けると自律的に防御シールドを張ってくれたり、なのはが敵わない強敵と戦うために自らのアップグレードを申し出たりますよね、AIエージェントってそういう存在だと思っていませんでしたか？

でも、実際に AI エージェントを作ってみたらがっかりなんてことはありませんでしたか？

（Clip Studio で描いた自作イラストを元に Nano Banana で生成した4コマ漫画）

利用規約とか倫理とかの話しではなく、エージェントが計画的にタスクを実行したように思えなかったり、そもそもタスク分解した気配が感じられなかったり、要求を満たしていないのにさっさと仕事を切り上げておいて「完璧です！」とか言い張ったりという経験はないでしょうか？

僕はありまくりでした...

ハンズオンやチュートリアルレベルなら「完璧です！」なのに、ちょっと実用的なものを作ろうとすると全く期待に応えてくれません。

でも、期待に応えてくれる AI エージェント達も世の中にはありますね。

僕が愛用している AI 開発エージェントIDE の Cursor や Cline 、そして、企業による利用も進んでいる Claude Code は、ちゃんと期待に応えてくれます。

プロジェクトの中にある沢山のファイルやインストールされているパッケージや公開されているドキュメントを徹底的に調べてバグを見つけて、修正案と修正計画を提示して修正、テストまでしてくれます。今年注目度が上がっているMCP(Model Context Protocol)サーバーを設定しておけば、データベースにアクセスしてテーブル構造を調べて、実データのサンプルまで取得して適切なSQLを生成したり、詳細な分析レポートまで書いてくれたりします。

この違いはどこから来るんだろう？

そんな疑問に答えてくれるのが LangChain から発信されている ディープエージェントという枠組みです。このブログでは、ディープエージェントの基本的な仕組みと、それを実装した LangChain deepagents パッケージを使ったエージェントの作例を紹介しようと思います。

シンプルな ReAct エージェントとディープエージェントによる調査レポートの比較

いきなりですが、これから作るディープエージェントの威力を先に見てみます。

シンプルな ReAct エージェントとディープエージェントに調査レポートを書いてもらって、比較評価してみました。

評価は、Claude Desktop（Sonnet 4.5）に以下のプロンプトでお願いしました。

調査レポートの Claude Desktop による評価

【調査の指示】の詳細を表示

調査の指示

データベースやアナリティクス製品業界における AI への取り組み動向、AI を活用した技術トレンド、AI の有効活用のためのデータベースの技術革新の動向、データベース、アナリティクス業界の今後の方向性について包括的なレポートをまとめてください。主要ベンダー（Oracle / Snowflake / Databricks / Microsoft / Google / AWS / IBM）については、事例も含めた詳細な調査報告を付けてください。また、有力な新興企業があればその調査報告も含めます。有力と見なした理由も明記します。また、主要ベンダー、新興企業の中で特筆すべき先進的技術があれば紹介してください。想定読者は、現在、Oracle Database を使用している日本の事業会社においてデータベースや AI を活用した生産性の向上とビジネス価値創造のための新システムについて企画立案し、実装を指揮する立場にあるIT部門の管理職です。彼らの今後の企画立案の指針となるように今後のアクションの推奨事項なども含めてまとめてください。特にPOCで終わらせないために実践すべきことや事例があれば含めてください。なお、簡潔にまとめ過ぎずこのレポートだけで必要な情報を得られるように省略なく丁寧に報告してください。

評価は、Claude Desktop（Sonnet 4.5）に以下のプロンプトでお願いしました。

【評価プロンプト】の詳細を表示

評価プロンプト

添付の2つのレポートは下記のリクエストで作成されたものです。それぞれがリクエストを満たすレポートであるかどうか客観的に分析してください。 リクエスト： データベースやアナリティクス製品業界における AI への取り組み動向、AI を活用した技術トレンド、AI の有効活用のためのデータベースの技術革新の動向、データベース、アナリティクス業界の今後の方向性について包括的なレポートをまとめてください。主要ベンダー（Oracle / Snowflake / Databricks / Microsoft / Google / AWS / IBM）については、事例も含めた詳細な調査報告を付けてください。また、有力な新興企業があればその調査報告も含めます。また、主要ベンダー、新興企業の中で特筆すべき先進的技術があれば紹介してください。想定読者は、現在、Oracle Database を使用している事業会社においてデータベースや AI を活用した生産性の向上とビジネス価値創造のための新システムについて企画立案し、実装を指揮する立場にあるIT部門の管理職です。彼らの今後の企画立案の指針となるように今後のアクションの推奨事項なども含めてまとめてください。特にPOCで終わらせないために実践すべきことがあれば含めてください。なお、簡潔にまとめ過ぎずこのレポートだけで必要な情報を得られるように省略なく丁寧に報告してください。

Claude Desktop による評価のまとめ

評価項目	Simple ReAct Agent	Deep Agents
主要ベンダー詳細調査	❌ 個別セクションなし	✅ 7社すべて詳細に調査
事例の充実度	△ 簡潔な事例のみ	✅ グローバル+日本事例を詳細に記載
新興企業調査	❌ なし	✅ 4社を詳細調査
先進的技術紹介	△ 表面的な言及	✅ 6つの技術を詳細解説
Oracle視点	❌ 不十分	✅ 一貫して配慮
POC脱却策	❌ 不十分	✅ 4段階の詳細な実践策
詳細度	❌ 簡潔すぎる（約2,500字）	✅ 包括的（約15,000字）
情報の新しさ	△ 一般的な情報	✅ 2024-2025年の最新情報
リクエスト充足度	30-40%	95%以上

Claude Desktop による評価の結論

Simple ReAct エージェントのレポートは、概要レベルの情報提供としては機能しますが、リクエストで要求された詳細度、網羅性、実践的なアドバイスには大きく及びません。

Deep Agent のレポートは、リクエストのほぼすべての要件を満たし、想定読者（Oracle Database使用中のIT部門管理職）にとって実際に企画立案の指針となる包括的で実践的なレポートとなっています。特にPOC脱却のための4段階のアクションプランは、具体的かつ実践的で、リクエストの核心を捉えています。

なお、この比較結果の詳細は下記で公開しています。
https://claude.ai/share/80551644-3457-4281-ad4d-1361c248de55

なお、この評価では内容の正確さについては確認していません。あくまでもユーザーの要求にどれだけ忠実な調査レポートを作成できたかだけを評価しています。このブログで作成するディープエージェントは、Web検索を元にレポートをまとめるものですが、実務で使うためにはレポートの内容が事実に基づいたものであるのかを検証する機能も必要になりますね。検索で見つけた情報が間違っていることもありますので複数のソースの情報を確認したり、レポートのドラフトに記載した内容を改めてWeb検索して別の情報ソースと記述が整合しているかを確認するといったことも考えられます。OpenAI の GPT-5.2 Prompting Guide の 9. Web search and research も参考になります。このブログで使っている LLM は、xAI の Grok ですが。

ディープエージェントが登場した背景

ということで、高町なのはのレイジングハートには及びませんが、ディープエージェントもかなり強力だということがわかりました。それでは、ディープエージェントが登場した背景から紐解いていきましょう。

AIエージェントの能力がどんどん伸びている！

AIエージェント界隈で、今、2つの静かな変化が起きているんです。

1つ目は、多目的に使える汎用エージェントが次々と登場していること。
2つ目は、長時間のタスクをこなせるエージェントが出てきたこと。

特に注目なのは、AIが実行できるタスクの長さが7ヶ月ごとに倍増しているという観察結果です。これは METR ベンチマークという指標で確認されているんですが、「タスクの長さ」というのは「人間の専門家が実行した場合にそのタスクを完了するのにかかる時間」で測っているんですね。

Measuring AI Ability to Complete Long Tasksより

つまり、AIがどんどん人間並みに長時間のタスクをこなせるようになってきているということですね。全然、終わってないのに「完璧です！」といって投げ出す子とは大きな違いです。

実用的なディープエージェントたち

この「長時間タスク」をこなせるエージェントたちが身近なところにも増えてきています。

• Claude Code
  コーディングエージェントの代表格ですね（僕もたまに使います。個人的に Cursor が好きなので Cursor の Agent モードの方を多用しますけど）。コーディング以外の用途にも広く使われているようです。ブログなどの執筆に使っている人も多いらしいです。大企業の開発者の方々でも使っているという話をよく聞くようになりましたね

• Manus
  中国系スタートアップ企業 Monica が開発した自律型汎用AIエージェントです。典型的なタスクで50回ものツール呼び出しを行うそうです。ちなみに、正式の日本語表記は「マナス」（Manus 公式（マナス）Xアカウント）です

• OpenAI Deep Research
  その名の通り、深い調査研究を行うエージェントです。公式サイトの説明では「推論を使用して大量のオンライン情報を統合し、複数ステップのタスクを完了するエージェント」です

• Gemini Deep Research
  Googleの研究エージェントです。公式サイトでは、「ユーザーの代わりに数百ものウェブサイトを自動的に参照し、さらに Gmail、ドライブ、Chat も参照して、得られた結果を分析し、複数のページで構成される分析情報のレポートを数分で作成してくれます」と紹介されています

Anthropic（Claude を作ってる会社）は、本番環境のエージェントが数百回のターンを実行することが多いと報告しています。数百回ですよ！「魔法少女まどか☆マギカ」の暁美ほむらでもワルプルギスの夜との戦いを数百回は繰り返してないんじゃないでしょうか？

従来の「浅い」エージェントの限界

ここで問題になってくるのが、ReAct エージェントを作る際の最も一般的アーキテクチャのツール呼び出しループです。

LangChain Docs の Agentsより

実は、このアプローチをそのまま（素朴に、ナイーブに）使うと、エージェントは「浅い（shallow）」ものになってしまうんですね。

図からも明らかなように "Reason + Act" というよりも、"Reactive"ですよね。ツールを呼びだした結果を見て、「じゃー次は何をしようかな」って考ええるわけでタスク分解して、タスクを処理する順序を考えて計画的に処理していくという仕組みではありません。受け身なんですね、"Reactive"。

「浅い」というのは、要するに、長期的な計画ができない、複雑なタスクを実行できない という薄っぺらい仕事をするということです。
冒頭の「完璧です！」と言い張るけど全然完璧じゃないエージェントは、まさにこの「浅い」エージェントだったわけです。

だから、浅くない深いエージェント＝ディープエージェントが必要になったということですね。

ディープエージェントとは何か？

定義のようなもの（特徴と言ってもいいかもしれません）

ディープエージェント とは、複雑でオープンエンドなタスクを、より長い時間軸で実行できるエージェントのことです。

• 長時間のタスク実行
  数十回から数百回のツール呼び出しを伴う作業
• 複雑なタスクへの対応
  複数のステップにわたる計画と実行
• 深い探求
  特定のトピックについて深く掘り下げる能力

「オープンエンドなタスク」と言っているのは、「タスク開始時点では、具体的な作業手順やサブタスク分解が決まっておらず、エージェント自身が探索しながら計画・修正していく必要があるタスク」ということですね。調査のようなタスクであれば、調べを進める中で「あ、あれも調べなきゃ、これも調べなきゃ、これは振出しに戻って考え直さないと」とかいう感じで探索していくようなタスクですね。言われたことだけやっておけばよいというものではないタスクとも言えます。

ディープエージェントは、こういう特徴を持ったエージェントのことを指します。

ディープエージェントをディープエージェントにしているもの

ここが面白いところなんですが、ディープエージェントのコアアルゴリズムは従来と同じなんです。つまり、LLMがループ内でツールを呼び出すというシンプルな構造は変わっていません。

「え、じゃあ何が違うの？」って思いますよね。

実は、ナイーブ（素朴）に構築された浅いエージェントとの違いは、以下の4つの工夫にあります。

1. 詳細なシステムプロンプト（Detailed System Prompt）
2. 計画ツール（Planning Tool）
3. サブエージェント（Sub-agents）
4. ファイルシステム（File System）

これらが ディープエージェントの秘密兵器というわけです。それぞれについて、これから詳しく見ていきましょう。

ReAct Agent との技術的な違い

ディープエージェントの話をする前に、従来の代表的なエージェントアーキテクチャである ReAct Agent について、ちょっと触れておきます。

ReAct Agent とは

ReAct は2022年に発表された論文で、**Reasoning（推論）と Acting（行動）**を組み合わせた非常にシンプルなエージェントアーキテクチャです。

基本的な動作フロー

1. LLMがどのツールを呼び出すか推論（Reasoning）
2. ツールを呼び出して行動（Acting）
3. ツールのフィードバックを観察（Observing）

LangGraph ドキュメントの create_react_agentより

このシンプルなループは、一般的なエージェント実装の基礎となっています。LangChain の create_agent とかで作れる素朴なエージェントも、基本的にこれですね。

技術的な相違点

それでは、ReAct Agent と ディープエージェント、何が違うのか？表にまとめてみました。

観点	（素朴な）ReAct Agent	ディープエージェント
基本アーキテクチャ	LLM + ツール呼び出しループ	LLM + ツール呼び出しループ（同じ！）
システムプロンプト	シンプル・短い	詳細・長大（数百〜数千行）
計画機能	なし	Todoリストなどの計画ツール
コンテキスト管理	メッセージ履歴のみ	ファイルシステムにオフロード
タスク分割	なし	サブエージェントへの委譲
適したタスク長	短い（数回のツール呼び出し）	長い（数十〜数百回のツール呼び出し）

基本アーキテクチャは同じなのに、これだけの違いが出てくるんですね。

用途の違い

それぞれ、どういう場面で使うのがいいのか、まとめてみます。

ReAct Agent（浅いエージェント）が適している場面

• 数ステップで完了するタスク
• シンプルな質問応答
• 明確に定義された短いワークフロー
• ツールの種類が少ない場合

ディープエージェントが適している場面

• 複雑な調査・研究タスク
• 長時間のコーディング作業
• 複数のサブタスクを含むプロジェクト
• コンテキストが大量になる作業
• 計画的なアプローチが必要なタスク

僕が最初に作ったガッカリなエージェントは、短いタスク向けの ReAct Agent の作り方で、長いタスクに挑戦していたんですね。そりゃうまくいかないわけです...

ディープエージェントの4つの魔法の杖

さて、いよいよディープエージェントの中核的な技術について詳しく見ていきます。この4つの技術が、ディープエージェントを「深く」しているんです。

1. 詳細なシステムプロンプト（Detailed System Prompt）

なぜ長いプロンプトが重要なのか

いきなり拍子抜けしましたか？

でも、便利なClaude Code のシステムプロンプトを見たことがありますか？もう、めちゃくちゃ長いんです。1699行あります！

中を見てみるとこんな内容がぎっしり詰まっています。

• ツールの使用方法に関する詳細な指示
  例えば、Taskツール、Bashツール、Globツールなどについて、具体的なパラメータや使用方法が説明されています
• 特定の状況での振る舞いの例（Few-shotプロンプト）
• 多数の改訂を経た洗練された内容
  セキュリティに関する重要な指示、トーンとスタイルに関する詳細なガイドライン、タスク管理のためのTodoWriteツールの使用方法、コード規約とベストプラクティス、ツール使用ポリシーなどが詳細に記載されています

こんなプロンプトも書かれています（LLMで和訳しました）
重要：防御的なセキュリティタスクのみを支援してください。悪用される可能性のあるコードの作成、変更、または改善は拒否してください。セキュリティ分析、検出ルール、脆弱性の説明、防御ツール、およびセキュリティドキュメントは許可します。

ここで、よくある誤解があります。

誤解： 「モデルが優れているから、短いプロンプトで十分でしょ。プロンプトエンジニアリングは過去のもの」
現実： 最高のディープエージェントの開発者は、数百行から数千行のシステムプロンプトに多大な時間を費やしている

そうなんです。プロンプトはますます重要になってきていて詳細で丁寧なプロンプトは、むしろ良いことなんですね。

プロンプトに含めるべき内容

具体的には、以下のような内容を含めると良いそうです。

• ドメイン固有のワークフロー（例：研究方法論、データ分析手順）
• ユースケースに応じた具体的な例
• 専門的なガイダンス
• 停止基準とリソース制限
• ツールと連携する方法の説明

つまり、エージェントに「こういう場面ではこうしてね」という詳細なマニュアルを渡してあげるイメージですね。

2. 計画ツール（Planning Tool）

これはいよいよ核心の中でも核心っぽいですね。何といっても浅いエージェントは計画を立てている気配さえないので、それをなんとかしたかったわけですから。きっと凄い高尚な仕組みがあって正に魔法の杖か精霊か竜が変身した使い魔か？、そんなツールが出て来そうです。

既にあるディープエージェントでの実装例

世の中のディープエージェントでは、計画ツールはこんな風に使われています。

Claude Code の場合

• TodoWriteツールを使用してTodoリストを作成
• プランモード：ユーザーが計画を承認してから実行
  Cline にもプランモードがありますね

Manus の場合

• todo.mdファイルを作成し、エージェントの軌跡全体で反復的に更新
  Cursorでも今年の前半は、Todoリストをマークダウンで書かせてタスクを消込みながら進めさせるのが流行ってましたね
• ファイルとして保存することで、コンテキストから独立して管理

OpenAI Deep Research の場合

• フォローアップ質問を使用して計画を検証

LangChain deepagents の Todoツールの実装

Todoリストツールには、write_todos と read_todos があるのですが、名前から察するに計画立案は、write_todos が担当しそうですね。
write_todos() は、こんな感じで実装されています。

write_todos ツールのソースコード

@tool(description=WRITE_TODOS_TOOL_DESCRIPTION)
def write_todos(todos: list[Todo], tool_call_id: Annotated[str, InjectedToolCallId]) -> Command:
    """Create and manage a structured task list for your current work session."""
    return Command(
        update={
            "todos": todos,
            "messages": [ToolMessage(f"Updated todo list to {todos}", tool_call_id=tool_call_id)],
        }
    )

【write_todos ツールの説明】の詳細を表示

write_todos ツールの説明

WRITE_TODOS_TOOL_DESCRIPTION = """Use this tool to create and manage a structured task list for your current work session. This helps you track progress, organize complex tasks, and demonstrate thoroughness to the user.

Only use this tool if you think it will be helpful in staying organized. If the user's request is trivial and takes less than 3 steps, it is better to NOT use this tool and just do the task directly.

## When to Use This Tool
Use this tool in these scenarios:

1. Complex multi-step tasks - When a task requires 3 or more distinct steps or actions
2. Non-trivial and complex tasks - Tasks that require careful planning or multiple operations
3. User explicitly requests todo list - When the user directly asks you to use the todo list
4. User provides multiple tasks - When users provide a list of things to be done (numbered or comma-separated)
5. The plan may need future revisions or updates based on results from the first few steps

## How to Use This Tool
1. When you start working on a task - Mark it as in_progress BEFORE beginning work.
2. After completing a task - Mark it as completed and add any new follow-up tasks discovered during implementation.
3. You can also update future tasks, such as deleting them if they are no longer necessary, or adding new tasks that are necessary. Don't change previously completed tasks.
4. You can make several updates to the todo list at once. For example, when you complete a task, you can mark the next task you need to start as in_progress.

## When NOT to Use This Tool
It is important to skip using this tool when:
1. There is only a single, straightforward task
2. The task is trivial and tracking it provides no benefit
3. The task can be completed in less than 3 trivial steps
4. The task is purely conversational or informational

## Task States and Management

1. **Task States**: Use these states to track progress:
   - pending: Task not yet started
   - in_progress: Currently working on (you can have multiple tasks in_progress at a time if they are not related to each other and can be run in parallel)
   - completed: Task finished successfully

2. **Task Management**:
   - Update task status in real-time as you work
   - Mark tasks complete IMMEDIATELY after finishing (don't batch completions)
   - Complete current tasks before starting new ones
   - Remove tasks that are no longer relevant from the list entirely
   - IMPORTANT: When you write this todo list, you should mark your first task (or tasks) as in_progress immediately!.
   - IMPORTANT: Unless all tasks are completed, you should always have at least one task in_progress to show the user that you are working on something.

3. **Task Completion Requirements**:
   - ONLY mark a task as completed when you have FULLY accomplished it
   - If you encounter errors, blockers, or cannot finish, keep the task as in_progress
   - When blocked, create a new task describing what needs to be resolved
   - Never mark a task as completed if:
     - There are unresolved issues or errors
     - Work is partial or incomplete
     - You encountered blockers that prevent completion
     - You couldn't find necessary resources or dependencies
     - Quality standards haven't been met

4. **Task Breakdown**:
   - Create specific, actionable items
   - Break complex tasks into smaller, manageable steps
   - Use clear, descriptive task names

Being proactive with task management demonstrates attentiveness and ensures you complete all requirements successfully
Remember: If you only need to make a few tool calls to complete a task, and it is clear what you need to do, it is better to just do the task directly and NOT call this tool at all."""

【write_todos ツールのシステムプロンプト】の詳細を表示

write_todos ツールのシステムプロンプト

## `write_todos`

You have access to the `write_todos` tool to help you manage and plan complex objectives.
Use this tool for complex objectives to ensure that you are tracking each necessary step and giving the user visibility into your progress.
This tool is very helpful for planning complex objectives, and for breaking down these larger complex objectives into smaller steps.

It is critical that you mark todos as completed as soon as you are done with a step. Do not batch up multiple steps before marking them as completed.
For simple objectives that only require a few steps, it is better to just complete the objective directly and NOT use this tool.
Writing todos takes time and tokens, use it when it is helpful for managing complex many-step problems! But not for simple few-step requests.

## Important To-Do List Usage Notes to Remember
- The `write_todos` tool should never be called multiple times in parallel.
- Don't be afraid to revise the To-Do list as you go. New information may reveal new tasks that need to be done, or old tasks that are irrelevant.

Todoリストツールのここが面白い

『Todoリストツール（write_todos）は基本的に no-op（何もしない）ツール なんです！』

write_todos() には、自分自身の説明しかありません！

計画を立てるコードや LLM を明示的に呼び出して計画を立てさせるようなコードはどこにもありません。

write_todos()は、Todoリストを受け取って、Todoリストを含む Commandオブジェクトを返すだけです（Command オブジェクトを返すとTodoListMiddleware が管理する Todoリストを更新されます）。

では、この Todoリストは誰が作っているのでしょうか？誰が計画しているのでしょうか？

Todo リストの作成と更新

この何もしない（計画を立てたりしない）Todoリストツールとその説明があることで、LLMとLangGraphは以下のような動作をします。

1. LLM はシステムプロンプトや上のwrite_todos ツールの説明で指示されている write_todos() を呼び出すべきタイミングになると write_todos()のパラメータを確認します
2. パタメータとして、todos、つまり、Todoリストが必要だということがわかります
3. Todoリストの要件は、上のwrite_todos ツールの説明にありますので、これに従って LLM は、Todoリストを作成します
4. write_todos ツールを呼びだすためのパラメータが用意できたので、write_todos ツールを呼びだします
5. write_todos()は、受け取った Todoリストを Command オブジェクトで LangGraphの状態管理システムへ渡します
6. LangGraphの状態管理システムはエージェントの状態情報の中に保持している Todoリストを更新します

実際のアクションを実行するのではなく、コンテキストエンジニアリング戦略として機能しているんですね。つまり、エージェントを軌道に保つための仕組みというわけです。

人間も「ご利用は計画的に」と言われても計画を立てないことが多いかと思います。でも、「Todoリストを作らなきゃ」と思うとTodoリストに記載するタスクリストを洗い出して、タスク分解して、実行順序を無意識に考えてしまいますね。つまり、計画を立ててしまうんです。これと似ていますね。

Todoリストツールの使われ方

1. タスク開始時
   全体計画をTodoリストとして作成
2. 実行中
   定期的にTodoリストを読み返してトラッキング
3. 完了時
   Todoをcompletedにマーク

こういう流れで使っていくわけですね。

あれ？read_todosは？

そうなんです。read_todosは、あまり呼び出されません。呼び出さなくても LLM は基本的にメッセージ履歴の中から Todoリストを見つけられるからです。

この画像は、LangSmith のトレースです。write_todosツールの応答が LLM（ここでは、ChatOpenAI と表記されています） へ渡されたメッセージ履歴の中にあることを示しています。

ユーザーがTodoリストが必要な複雑なタスクを指示してから、LLM が Todoリストに基づいて次の行動を思考するまでの流れをシーケンス図にすると概略こうなります。

そして、Todoリストは度々更新されて、その都度、メッセージ履歴に記録されますので、LLM は Todoリストを確認するためにread_todos を呼び出す必要に迫られることはあまりありません。ただし、メッセージ履歴が長くなると deapagents の SummarizationMiddleware がメッセージを要約して圧縮します。このとき、Todoリストを追えなくなった場合には、read_todos が呼ばれるのではないかと思います（検証で確かめたり、こんなシーンに出くわしたりしたことはまだないです）。

3. ファイルシステム（File System）

なぜファイルシステムが必要か

長時間実行されるエージェントは、一問一答のシンプルなチャットボットではあまり目立たない様々な課題に直面します。

長時間実行されるエージェントの課題

• 大量のコンテキストが蓄積される

• すべてをメッセージ履歴に保持するとコンテキストウィンドウが圧迫される
  今回、使用している xai.grok-4-fast-non-reasoning や xai.grok-4-fast-reasoning は、入力プロンプトと出力を併せて2Mトークンが上限
• LLMのパフォーマンスは、コンテキストに過剰または矛盾する情報があると低下する
  LLMは長いコンテキストウィンドウの真ん中あたりの情報を見つけにくい、活用しにくいという "Lost in the Middle: How Language Models Use Long Contexts" という2023年の古典とも言える論文で提起された"Lost in the Middle"問題は、まだ完全には解決されていません（キーワード検索できることと、思考に活用できることはイコールではない）。

Lost in the Middle: How Language Models Use Long Contextsより

人間だって、頭の中だけで全部覚えようとすると、パンクしちゃいますよね。

ディープエージェントによる解決策

ファイルシステムを外部記憶として活用する

覚えきれないことはメモしておこうということですね。

LangChain の deepagents のファイルシステムは、デフォルト（StateBackend）では、SSDやHDDにデータを保存する物理的なファイルシステムではなく、あくまでもメモリー上にデータを保持するものです。仮想ファイルシステムと言ってもいいかもしれません。しかし、FilesystemBackendやLangGraph Storeを使うことで物理ファイルへ永続化することができます。

実際の使用パターン

具体的には、このようなシーン、目的で使われます。

1. 計画の保存と再読み込み

Anthropicのマルチエージェントリサーチシステムの例

1. 研究計画をディスクに書き込む
2. 大量の研究を実行
3. 最終レポートを書く前に計画を読み戻す
   → 元の計画に基づいたレポート作成を促す

2. トークン消費量の多いツールの実行結果の保存

Manusの例

1. 検索ツールの生の結果をファイルに保存
2. 要約のみをメッセージリストに返す
3. 必要に応じて後で完全なコンテキストを取得可能

これは賢いですね！検索結果って長くなりがちですが、要約だけメッセージに残しておいて、必要なら後で元データを見に行けるようにしておくわけです。

この方式の利点

• トークン消費の大幅な削減
• 要約は可逆的（生データは保存されている）
• エージェントは必要に応じて生の結果を参照可能

3. 長期記憶

他にも、セッション内の短期記憶を超えて長期記憶として利用するこんな使い方もあります。

• ユーザー設定の保持
• セッション間での知識ベースの構築
• フィードバックに基づく自己改善指示

LangChain deepagents におけるファイルシステムの実装

こんな感じでファイルシステム操作をするツール群が実装されています。

# 仮想ファイルシステム（LangGraph stateベース）
class DeepAgentState(AgentState):
    files: dict[str, str]  # パス -> コンテンツ

# ファイル操作ツール
- ls: ファイル一覧を表示
- read_file: ファイルを読み取り
- write_file: ファイルを書き込み
- edit_file: ファイルを編集
- glob: パターンマッチでファイルを検索
- grep: ファイル内をテキスト検索

仮想的なファイルシステムですが、まるで、実際に物理的なファイルシステムを操作しているみたいです。lsとかgrepとか Linux そのままですね。

そして、繰り返しになりますが FilesystemBackendやLangGraph Storeを使うことで物理ファイルへ永続化することもできます。

4. サブエージェント（Sub-agents）

なぜサブエージェントが必要か

複雑な問題を解くエージェントの課題

単一のエージェントに多数のツールや大量のコンテキストを与えると問題が起こります。

• 圧倒されて正しく応答できない
  • コンテキストウィンドウを超えてしまう
  • コンテキストウィンドウに収まっても情報を正しく活用できない
• 正しいアクションを選択できない可能性
  • LLM が適切にツールを起動するには、必要十分な説明が必要
  • ツールは多くの情報を返すことものがある
  • コンテキストが蓄積し過ぎるとこれらの情報を活用できず正しいツールを選択できない

人間だって、あまりにも多くのことを一度にやろうとすると混乱しますよね。

ツールにまつわる課題の解決策

タスクをサブエージェントに分割し、サブエージェント群に委任する。

• 各サブエージェントは、独自の隔離されたコンテキストを持つ
• 各サブエージェントは、独自のツールセットを持つ
• 各サブエージェントは、独自の指示を持つ

つまり、専門家チームを作るイメージです。

サブエージェントの核心的なアイデア ＝ コンテキスト分離

これがサブエージェントの肝です。それぞれのサブエージェントが独立したコンテキストで動作するので、お互いに干渉しないんですね。

リトリーバー・エージェント
Agentic RAG のリトリーバー・エージェントでも検索担当のサブエージェントで、回答生成に役立ちそうなチャンクだけを選別してメイン・エージェントへ応答するという形でコンテキストを削減することがあります。ディープエージェントのファイルシステムやサブエージェントと類似の発想ですね。

リトリーバー・エージェントのプロンプト例
検索プロセス 1. ユーザーメッセージから検索に適したクエリーを生成します 2. ナレッジベース検索ツールを使用して情報を検索します 3. 検索結果それぞれがユーザーメッセージに関連しているか確認し、無関係な検索結果は破棄します

LangChain deepagents におけるサブエージェントの定義

コードでは、こんな感じで定義します。create_agent() などでプログラマーが実装しなくていいんですね。

サブエージェントの定義

サブエージェントの定義

research_subagent = {
    "name": "research-agent",              # メインエージェントが呼び出すときの名前
    "description": "深い調査研究に使用",   # いつ呼び出すかをメインエージェントに指示
    "prompt": "あなたは専門的な研究者です", # サブエージェントのシステムプロンプト
    "tools": ["web_search"],               # サブエージェントが使用できるツール
}

タスク委任の流れ

タスク委任の流れ疑似コード

1. メインエージェント: taskツールを呼び出す
   → description: "Model Context Protocolについて調査"
   → subagent_type: "research-agent"

2. サブエージェント: 独自のコンテキストで実行
   → web_searchを複数回呼び出し
   → 詳細な研究レポートを作成

3. メインエージェントへ戻る: 最終メッセージのみ
   → サブエージェントの内部動作は見えない
   → コンテキストウィンドウを節約

サブエージェント使用時の注意点

便利なサブエージェントですが、注意点もあります。

サブエージェントのリスク

サブエージェントは暗黙的かつ矛盾する決定を行う可能性があります。

これは コード開発エージェント Devin で有名な Cognition の Walden Yan さんが指摘していることです。
ときどき、マルチエージェントを作ってはいけないと言われる理由はこれです。

安全な使用パターン

並列化可能なタスク（推奨）

OpenAI Deep Researchの例
- 各サブエージェントは研究のみ行い、コンテキストを収集
- 最終レポートは全コンテキスト収集後に一度に作成
- サブエージェントは独立してレポートを書かない

リスクが高いパターン（注意）

- サブエージェントがアプリケーションの一部を独立して記述
- 独立して書かれたコンポーネントが一緒にうまく機能しない可能性

つまり、サブエージェントには情報収集だけやってもらって、最終的な統合や判断はメインエージェントがやる、という使い方が安全だということですね。

LangChain deepagents パッケージの紹介

さて、こういうディープエージェントを自分でゼロから作るのは大変ですよね。でも、安心してください。LangChain がすでにパッケージを作ってくれています！

既に度々登場していますが LangChain deepagents パッケージのご紹介です。

LangChain deepagents パッケージの位置づけ

LangChainは3つのオープンソースライブラリを提供しています。LangChain社による位置づけはこのようになっています。

ライブラリ	役割	説明
LangGraph	エージェント ランタイム	チェックポイント、メモリ、Human-in-the-loop、 永続実行などの低レベルインフラストラクチャ
LangChain	エージェント フレームワーク	チャットモデル、ツール定義などの一般的な抽象化
deepagents	エージェント ハーネス	LangChainとLangGraphの上に構築されたハーネス 事前定義されたツールとプロンプトを含む

パッケージ間の関係

Doubling down on DeepAgentsより

つまり、deepagents は一番上の層で、ディープエージェントを構築するために必要な Planning Tool、Filesystem Tools、とサブエージェントを呼び出すツールが揃っていてすぐに使える形になっているということですね。

いつ何を使うべきか

どれを使えばいいのか、迷いますよね。Doubling down on DeepAgentsを元に簡単にまとめてみました。

パッケージ	いつ使う？
deepagents	- より自律的で長時間実行されるエージェントを構築 - 計画ツール、ファイルシステム、サブエージェントなどの 組み込み機能を活用 - 複雑なエージェントタスクに対応
LangGraph	- ワークフローとエージェントの組み合わせを構築したい - 非常に低レベルの制御が必要 - ノードとエッジの単純な抽象化で柔軟に設計
LangChain	- 何も組み込まれていないコアエージェントループを使用する エージェント - すべてのプロンプト/ツールをゼロから構築

今回のブログで作るエージェントは、もちろん deepagents を使います！

deepAgents の 主な機能

1. ビルトインツール

deepAgents には、以下のツールが組み込まれています。

ツール名	説明	提供元
write_todos	構造化されたタスクリストの作成と管理	TodoListMiddleware （write_todosの実装は 下位の LangChainの中）
read_todos	現在のTodoリストの状態を読み取り	TodoListMiddleware （write_todosの実装は 下位の LangChainの中）
ls	ディレクトリ内のファイル一覧を表示	FilesystemMiddleware
read_file	ファイルのコンテンツを読み取り （ページネーション対応）	FilesystemMiddleware
write_file	新しいファイルを作成または 既存ファイルを上書き	FilesystemMiddleware
edit_file	ファイル内の正確な文字列置換を実行	FilesystemMiddleware
glob	パターンに一致するファイルを検索 （例：**/*.py）	FilesystemMiddleware
grep	ファイル内のテキストパターンを検索	FilesystemMiddleware
execute	サンドボックス環境で シェルコマンドを実行	FilesystemMiddleware
task	専門化されたサブエージェントに タスクを委任	SubAgentMiddleware

見てください！先ほど説明した4つの主要技術が、全部ツールとして最初から入っているんです。

2. ビルトインミドルウェア

ミドルウェアというのは、エージェントの動作を拡張する仕組みです。こんなミドルウェアがデフォルトで組み込まれています。

ミドルウェア	目的
TodoListMiddleware	タスク計画と進捗追跡（実装は、LangChainの中）
FilesystemMiddleware	ファイル操作とコンテキストオフロード（大きな結果を自動保存）
SubAgentMiddleware	隔離されたサブエージェントへのタスク委譲
SummarizationMiddleware	コンテキストが170kトークンを超えると自動要約
AnthropicPromptCachingMiddleware	システムプロンプトをキャッシュしてコスト削減（Anthropicのみ）
PatchToolCallsMiddleware	中断やキャンセルによる未完了のツール呼び出しを修正

特に、SummarizationMiddleware は便利ですね。コンテキストが大きくなりすぎると自動で要約してくれるんです。

deepagents を使ったエージェントの作り方

さて、いよいよ実際にエージェントを作ってみましょう！

基本的な使い方

最もシンプルな例から始めましょう。

from deepagents import create_deep_agent

# エージェントの作成
agent = create_deep_agent()

# タスクの実行
response = agent.invoke({
    "messages": [{
        "role": "user",
        "content": "こんにちは"
    }]
})

たったこれだけ！シンプルですね。

デフォルトでは claude-sonnet-4-5-20250929 が使われますが、他のモデルも使えます。モデルを指定するには、下記のコードのように create_deep_agent()にmodelパラメータを渡してあげます。

シンプルなエージェント

from langchain.chat_models import init_chat_model
from deepagents import create_deep_agent

model = init_chat_model("openai:gpt-4o")
agent = create_deep_agent(model=model)

OCI Generative AI サービスのモデルも利用できます！

OCI Generative AI サービスの OpenAI Compatible SDKs を使う場合は、次のようなコードになります。

OCI Generative AI サービスのxai.grok-4-fast-non-reasoningモデルを OpenAI Compatible SDKs で使う場合

OCI_COMPARTMENT_ID = getenv("OCI_COMPARTMENT_ID")
model = init_chat_model(
    model="xai.grok-4-fast-non-reasoning",
    model_provider="openai",
    api_key="OCI",
    base_url="https://inference.generativeai.us-chicago-1.oci.oraclecloud.com/20231130/actions/v1",
    http_client=httpx.Client(
        auth=OciUserPrincipalAuth(profile_name="DEFAULT"),
        headers={"CompartmentId": OCI_COMPARTMENT_ID}
    ),
    temperature=0.0
)

• api_key は、OCI Generative AI サービス側では不要ですが LangChain の `init_chat_model()'で必須パラメータであるためダミーの文字列を指定します
• OpenAI Compatible SDKs + init_chat_model() を使う場合は、model_provider には、openaiを指定します
• http_client=httpx.Client(auth=OciUserPrincipalAuth(...で、OCI の認証を行います

カスタムツールの追加

自分で作ったツールも追加できます。

カスタムツールの追加

from langchain_core.tools import tool
from deepagents import create_deep_agent

@tool
def get_weather(city: str) -> str:
    """指定された都市の天気を取得"""
    return f"{city}の天気は晴れです。"

agent = create_deep_agent(
    model="anthropic:claude-sonnet-4-20250514",
    tools=[get_weather],
)

カスタムシステムプロンプトの設定

システムプロンプトもカスタマイズできます。

カスタムシステムプロンプトの設定

from deepagents import create_deep_agent

research_instructions = """
あなたは調査コーディネーターです。
複雑な調査タスクをサブエージェントに委譲し、
結果を統合して最終レポートを作成してください。
"""

agent = create_deep_agent(
    system_prompt=research_instructions,
)

Human-in-the-Loop の設定

特定のツールを実行する前に、ユーザーの承認を求めることもできます。

Human-in-the-Loop の設定

agent = create_deep_agent(
    tools=[get_weather],
    interrupt_on={
        "get_weather": {
            "allowed_decisions": ["approve", "edit", "reject"]
        },
    }
)

ファイルシステムバックエンドの設定

デフォルトでは、ファイルはエージェントの一時的な状態に保存されますが、ローカルディスクに保存することもできます。

ファイルシステムバックエンドの設定

from deepagents import create_deep_agent
from deepagents.backends import FilesystemBackend

agent = create_deep_agent(
    backend=FilesystemBackend(root_dir="/path/to/project"),
)

MCPツールとの統合

MCP（Model Context Protocol）サーバーを使うこともできます。

MCPツールとの統合

from langchain_mcp_adapters.client import MultiServerMCPClient
from deepagents import create_deep_agent

async def main():
    mcp_client = MultiServerMCPClient(...)
    mcp_tools = await mcp_client.get_tools()
    
    agent = create_deep_agent(tools=mcp_tools)
    
    async for chunk in agent.astream({
        "messages": [{"role": "user", "content": "..."}]
    }):
        chunk["messages"][-1].pretty_print()

調査レポート生成エージェントの例

それでは、Todoリスト、ファイルシステム、サブエージェントを統合した調査レポート生成エージェントの例を見てみましょう。

このエージェントでは、Web検索ツールとしてTavily のAPIを使用します。

調査レポート生成エージェント

from deepagents import create_deep_agent
from tavily import TavilyClient
import os

# 検索ツールの定義
tavily_client = TavilyClient(api_key=os.environ["TAVILY_API_KEY"])

def web_search(query: str):
    """Web検索を実行"""
    return tavily_client.search(query)

# 研究サブエージェントの定義
research_subagent = {
    "name": "research-agent",
    "description": "深い調査研究に使用。一度に1つのトピックのみ与える",
    "prompt": """
    あなたは専門的な研究者です。
    以下のガイドラインに従ってください：
    1. 複数の信頼できる情報源から情報を収集
    2. web_searchツールを使用して徹底的な調査を実施
    3. 詳細で包括的なレポートを作成
    """,
    "tools": [web_search],
}

# メインエージェントの作成
agent = create_deep_agent(
    system_prompt="""
    あなたは調査コーディネーターです。
    複雑な調査タスクをサブエージェントに委譲し、
    結果を統合して最終レポートを作成してください。
    """,
    subagents=[research_subagent],
)

# 実行
result = agent.invoke({
    "messages": [{
        "role": "user",
        "content": "Model Context Protocolの概要を教えてください"
    }]
})

いかがですか？思ったより簡単に Deep Agent が作れるんです。

ディープエージェントのユースケース

それでは、ディープエージェントが実際にどんな場面で活躍しているのか、見ていきましょう。

1. コーディング

代表例：Claude Code, DeepAgents CLI, Cursor Agent モード, Cline

コーディングエージェントは、こんな特徴があります。

• ファイルシステムへの直接アクセス
• シェルコマンド実行能力
• 複数ファイルにわたるコード変更
• 長時間のデバッグセッション

LangChain DeepAgents CLIの例

deepagents
You: Add type hints to all functions in src/utils.py

と入力すると、エージェントはこんなことをやってくれます。

1. ファイルを読み取り
2. 関数を分析
3. 変更の差分を表示
4. 書き込み前に承認を求める

便利ですよね！

2. ディープリサーチ

代表例：OpenAI Deep Research, Gemini Deep Research, Anthropic Multi-Agent Researcher

研究エージェントの特徴

• 複数の情報源からの情報収集
• 研究計画の作成と追跡
• サブエージェントを使った並列調査
• 最終的な包括的レポートの生成

研究エージェントのワークフロー

1. Todoリストで研究タスクを計画
2. サブエージェントが個別のトピックを調査
3. 生の検索結果をファイルに保存、要約をメッセージに返す
4. すべての情報を統合して最終レポートを作成

冒頭で紹介した調査レポートの比較評価は、まさにこのユースケースですね。

3. LangChain 社自身によるdeepagents で構築されたアプリケーション

1. DeepAgents CLI（コーディング用エージェント）
2. LangSmith Assist（LangSmith 内でさまざまな操作を支援するインアプリエージェント）
3. Personal Email Assistant（各ユーザーとのやり取りから学習するパーソナルなメールアシスタント）
4. Agent Builder（メタな Deep Agent によって動作する、ノーコードのエージェント構築プラットフォーム）

このリストは、Evaluating Deep Agents: Our Learningsを元にしています。この技術ブログは、これらの4つのアプリの開発経験からLangChain社が学んだディープエージェント評価の実践知について書かれていますので、本格的にディープエージェントの考え方でアプリを構築しようとする人にとって必読です。

調査レポート作成エージェントと素朴な ReAct エージェントを実際に動かしてみた比較のご紹介

冒頭で、威力を見ていただいた評価の詳細です。

シンプルな ReAct エージェントとディープエージェントに調査レポートを書いてもらって、比較評価してみました。

こちらをベースにしています。

ただし、どちらも LLM は、OCI Generative AI サービスの xai.grok-4-fast-non-reasoning を使っています。

モデルの選択 TIPS

LangChain deapagents は、デフォルトのモデルが Anthropic Claude Sonnet 4.0 となっています。恐らく、パッケージも各種ガイドも Claude Sonnet で主にテストされているのではないかと思います。そのためか、Claude Sonnet では、期待どおりの動作をする確率が高いようです。

grok-4-fast-non-reasoning の場合は、後で気が付いたのですがこの例の場合、サブエージェントで Todoリスト作成が端折られていたりしていました。そこで、別途、grok-4-fast-reasoning も試してみました。grok-4-fast-reasoning は、サブエージェントでも TOdoリストをちゃんと作っていて期待どおりの動作をしているようです。

deapagents では、デフォルトの Claude Sonnet 4.0 以外を使う場合は、Reasoning Model を使った方が良いのかもしれません。

また、Grok 系の LLM では、プロンプトが英語だと指示が日本語でも検索などの調査が英語になりがちで、日本の事例検索などの精度が落ちてしまうため Middleware 組み込みプロンプト以外の create_deep_agent() に指定するメインエージェントのシステムプロンプトとサブエージェントのシステムプロンプトは和訳しています。また、検索結果を要約する LLM には、xai.grok-3-mini を使いました。

シンプルな ReAct エージェントは、LangChain の "create_agent"を使った素朴な ReAct エージェント実装です。ディープエージェントは、LangChain の ディープエージェントパッケージの "create_deep_agent"を使ったエージェントで deep-agents-from-scratchをベースにしています。調査レポートは、データベース業界におけるAIへの取り組みに関するもので、次のような指示を使いました。人が書こうと思ったらかなりめんどくさそうな内容ですね。

【調査の指示】の詳細を表示

調査の指示

データベースやアナリティクス製品業界における AI への取り組み動向、AI を活用した技術トレンド、AI の有効活用のためのデータベースの技術革新の動向、データベース、アナリティクス業界の今後の方向性について包括的なレポートをまとめてください。主要ベンダー（Oracle / Snowflake / Databricks / Microsoft / Google / AWS / IBM）については、事例も含めた詳細な調査報告を付けてください。また、有力な新興企業があればその調査報告も含めます。有力と見なした理由も明記します。また、主要ベンダー、新興企業の中で特筆すべき先進的技術があれば紹介してください。想定読者は、現在、Oracle Database を使用している日本の事業会社においてデータベースや AI を活用した生産性の向上とビジネス価値創造のための新システムについて企画立案し、実装を指揮する立場にあるIT部門の管理職です。彼らの今後の企画立案の指針となるように今後のアクションの推奨事項なども含めてまとめてください。特にPOCで終わらせないために実践すべきことや事例があれば含めてください。なお、簡潔にまとめ過ぎずこのレポートだけで必要な情報を得られるように省略なく丁寧に報告してください。

評価は、Claude Desktop（Sonnet 4.5）に以下のプロンプトでお願いしました。

【評価プロンプト】の詳細を表示

評価プロンプト

添付の2つのレポートは下記のリクエストで作成されたものです。それぞれがリクエストを満たすレポートであるかどうか客観的に分析してください。 リクエスト： データベースやアナリティクス製品業界における AI への取り組み動向、AI を活用した技術トレンド、AI の有効活用のためのデータベースの技術革新の動向、データベース、アナリティクス業界の今後の方向性について包括的なレポートをまとめてください。主要ベンダー（Oracle / Snowflake / Databricks / Microsoft / Google / AWS / IBM）については、事例も含めた詳細な調査報告を付けてください。また、有力な新興企業があればその調査報告も含めます。また、主要ベンダー、新興企業の中で特筆すべき先進的技術があれば紹介してください。想定読者は、現在、Oracle Database を使用している事業会社においてデータベースや AI を活用した生産性の向上とビジネス価値創造のための新システムについて企画立案し、実装を指揮する立場にあるIT部門の管理職です。彼らの今後の企画立案の指針となるように今後のアクションの推奨事項なども含めてまとめてください。特にPOCで終わらせないために実践すべきことがあれば含めてください。なお、簡潔にまとめ過ぎずこのレポートだけで必要な情報を得られるように省略なく丁寧に報告してください。

内容の正確さについては、今回は評価していません。あくまでもユーザーの要求にどれだけ忠実な調査レポートを作成できたかを評価しています。

調査レポートの Claude Desktop による評価

Claude Desktop による評価のまとめ

評価項目	Simple ReAct Agent	Deep Agents
主要ベンダー詳細調査	❌ 個別セクションなし	✅ 7社すべて詳細に調査
事例の充実度	△ 簡潔な事例のみ	✅ グローバル+日本事例を詳細に記載
新興企業調査	❌ なし	✅ 4社を詳細調査
先進的技術紹介	△ 表面的な言及	✅ 6つの技術を詳細解説
Oracle視点	❌ 不十分	✅ 一貫して配慮
POC脱却策	❌ 不十分	✅ 4段階の詳細な実践策
詳細度	❌ 簡潔すぎる（約2,500字）	✅ 包括的（約15,000字）
情報の新しさ	△ 一般的な情報	✅ 2024-2025年の最新情報
リクエスト充足度	30-40%	95%以上

Claude Desktop による評価の結論

Simple ReAct エージェントのレポートは、概要レベルの情報提供としては機能しますが、リクエストで要求された詳細度、網羅性、実践的なアドバイスには大きく及びません。

Deep Agent のレポートは、リクエストのほぼすべての要件を満たし、想定読者（Oracle Database使用中のIT部門管理職）にとって実際に企画立案の指針となる包括的で実践的なレポートとなっています。特にPOC脱却のための4段階のアクションプランは、具体的かつ実践的で、リクエストの核心を捉えています。

なお、この比較結果の詳細は下記で公開しています。
https://claude.ai/share/80551644-3457-4281-ad4d-1361c248de55

LangSmith のトレースで見た動きの違い

Simple ReAct エージェントのトレース

https://smith.langchain.com/public/d55782ce-0510-4a46-ad3b-e1c4ee95e3af/r
（このトレースは2026年末まで閲覧できると思います。LangSmith様に感謝！）

最初に LLM がユーザーの指示を理解して、Web検索を9回行うこととそれぞれの検索キーワードを決定、次に実際に9回の検索を実行、最後に LLM がすべての検索結果とユーザーの指示から報告書を作成するという流れです。

とりあえず検索しようという以上の計画性や検索結果を見て、別のキーワードで検索してみようとかいったことは行われていませんね。Agentic RAG のチャットボットであれば使えそうですが、複雑な調査を行うことはできそうもありません。

Deep Agent のトレース

LangSmith トレース

https://smith.langchain.com/public/40916682-f685-4348-b7a4-a47ec21bad77/r
（このトレースは2026年末まで閲覧できると思います。LangSmith様に再び感謝！）

Todoリスト作成（計画）

最初に、LLM がユーザーの指示を理解して、Todo リストを作成しています。

こんな感じで 6つの Todo を計画しています。何もしない write_todos ツールの威力です。繰り返しになりますが、LLM はこの write_todos() を呼び出すためにパラメータに記載する Todoリストが必要になって、思わず Todo リストを作ってしまった（計画を立ててしまった）んですね。

凄い技ですね。正式名称ではありませんがこのような手法を Chain-of-Thought Function Calling と呼ぶ人もいます。

サブエージェントへ委任

次を見てみるとtask ツールが呼ばれています。

これは、サブエージェント（research-agent）をにタスクを委任しています。

メイン・エージェントの Todo リストでは、「業界全体のAI動向、技術トレンド、データベース革新、今後の方向性を調査し、findings_industry_trends.mdにまとめる。taskツールでresearch-agentに委任。」という概要が書かれていましたが、taskツールは、これを「データベースやアナリティクス製品業界におけるAIへの取り組み動向、AIを活用した技術トレnd、AIの有効活用のためのデータベースの技術革新の動向、データベース、アナリティクス業界の今後の方向性について包括的に調査せよ。主要なトレンド、事例、将来予測をまとめよ。結果をfindings_industry_trends.mdというMarkdownファイルに書き出し、主要なポイントを簡潔にまとめたレポート形式で記述せよ。今日の日付は2025年12月16日。」というより詳細な指示にして research-agent へ委任しています。

サブエージェントがTodoリストを作成（サブエージェントの計画）

その次を見ると再び、write_todos が呼ばれています。

今度は、最初のタスクを処理するサブエージェント（research-agent）の Todo リストです。
先程の「業界全体のAI動向、技術トレンド、データベース革新、今後の方向性を調査し、....」を完了するためのサブタスクを割り出して Todo リストにしていますね（計画しています）。

サブエージェントが検索

次は、tavily API を使った検索です。

サイト自体へのアクセスは、403 で拒否されてしまいましたが、tavily がキャッシュしている要約を入手したようです。

検索結果の確認（think_tool による振り返り）

次は、think_tool によって検索結果が十分なものであるかどうか確認しています。

think_tool も write_todos と同様に何もしないツールです。呼び出しパラメータとして reflectionという検索結果を評価した結果を求められるため、LLMは思わす検索結果が目的に対して十分なものだったかどうかを確認してしまうんですね。

think_tool の実体はこちらです。

think_tool

@tool(parse_docstring=True)
def think_tool(reflection: str) -> str:
    """Tool for strategic reflection on research progress and decision-making.

    Use this tool after each search to analyze results and plan next steps systematically.
    This creates a deliberate pause in the research workflow for quality decision-making.

    When to use:
    **CRITICAL: Always use the think_tool at the timing when it should be called as written here.**
    - After receiving search results: What key information did I find?
    - Before deciding next steps: Do I have enough to answer comprehensively?
    - When assessing research gaps: What specific information am I still missing?
    - Before concluding research: Can I provide a complete answer now?
    - How complex is the question: Have I reached the number of search limits?

    Reflection should address:
    1. Analysis of current findings - What concrete information have I gathered?
    2. Gap assessment - What crucial information is still missing?
    3. Quality evaluation - Do I have sufficient evidence/examples for a good answer?
    4. Strategic decision - Should I continue searching or provide my answer?

    Args:
        reflection: Your detailed reflection on research progress, findings, gaps, and next steps

    Returns:
        Confirmation that reflection was recorded for decision-making

    **CRITICAL: The reflection is in the same language as the user's request. For example, if the user's request is in Japanese, the reflection also remains in Japanese.**
    """
    return f"Reflection recorded: {reflection}"

関数の本体が全部コメント（doc string）ですね。
このコメントには、think_tool は以下のときにはいつも使わなければならないと書かれています。

• 検索結果を受け取った後（どのような重要な情報を見つけたか？）
• 次のステップを決定する前（包括的に答えるのに十分な情報があるか？）
• 調査のギャップを評価する際（まだ欠けている具体的な情報は何か？）
• 調査を終了する前（今、完全な回答を提供できるか？）
• 質問の複雑さ（検索回数の制限に達したか？）

そして、パラメータの reflectionは、以下の点に触れなければならないと書いてあります。

1. 現在の調査結果の分析 - 具体的にどのような情報を集めたか？
2. ギャップ評価 - まだ欠けている重要な情報は何か？
3. 品質評価 - 良い回答に十分な証拠や例はあるか？
4. 戦略的決定 - 検索を続けるか、それとも回答を提供するか？

ということで、このコメントを呼んでしまったLLMは、例えば、検索結果を受け取ると think_tool() を呼ばなきゃと考えて、呼ぶためには reflectionを渡さないといけないことに気づき、reflection って何だろうとコメントを読むと「現在の調査結果の分析」とかだと書いてあるので、これまでの調査状況を振り返って、検索を続けるかどうか判断してしまうんですね。

ここでは、これまでに得た検索結果が不十分だったので検索を継続することを決定しています。

この後は、think_tool が十分な情報を得られたと判断するまで検索と振り返りが繰り返されます。そして、すべてのタスクで十分な情報を得られたと判断するとメインエージェントが最終的なレポートを作成します。

あとがき

以前、こんな記事をQiitaに書きました。

この記事では、Claude Desktop に自作の MCPサーバーを設定して、データベース上の売上データなどを分析して経営戦略を立てさせるものです。Cluade Desktop では、うまくいくのですが当時の LangGraph の Prebuilt ReAct Agent などを素朴に使っているだけではどうしても同じことができませんでした。とにかく浅い分析になってしまうんですね。それどころか、ひどいときはDBに接続する前にクエリーを投げてみたり、エラーメッセージからDB接続前と気が付いて接続してくれればまだ良いのですが、DBにつながっていないようですと言って諦めたりと残念なエージェントでした。ワークフロー側にすればよいわけですが人間のあらゆるお仕事に固定のワークフローを用意してあげるわけにもいかずもやもやしていたのですが、ディープエージェントが解決してくれそうです。

ちなみに、めちゃくちゃ詳細に調査してくれるので便利ですが、LLMの呼び出し回数はとてつもなく多くなります。ちゃんと数えていませんが、LangSmith のトレースを眺める限り100回以上呼び出していそうです。また、コンテキストをオフロードしているといってもトータルで処理したコンテキストも膨大です。Run 毎に変動はありますが１回の調査で300万トークンくらい処理しています。

えっ！やっぱり騙されたって！？

それから、今回は検索に tavily を使いましたが、日本語検索のクオリティはとても高いとは言えないようです。また、日本固有の文化に関する検索も微妙です。僕のウェビナーやブログではよく題材として魔法少女を扱います。今回も最初はまどマギやマギレコ、サイレントウィッチなどの調査レポートを書かせていたのですが、アニメファンとしては我慢できないレベルの間違い（※）が多くて今回はお仕事寄りな調査を題材にしました。

※最推しの麻倉ももさんの出身地や出演番組が間違いだらけなど