1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

エージェントビルダーとは?LLM・Tool・検索・ContextからAIエージェントの仕組みを理解する

1
Posted at

はじめに

最近のAIを使っていると、

「以前よりかなり正確になった」

だけではなく、

「関連するコードや資料まで自分から探してくれるようになった」

と感じることがある。

これは単純に「LLMの知識量が増えた」だけでは説明できない。

現在のAIエージェントでは、

LLM
+
Tool
+
検索
+
Context
+
Agentic Loop

を組み合わせて処理を進めることができる。

この記事では、

  1. LLMとは何か
  2. LLMはどこから情報を得るのか
  3. Toolとは何か
  4. なぜAIが資料を探せるのか
  5. Agentとは何か
  6. Agent Builderとは何か
  7. LLMの性能向上はどこに効くのか

という順番で整理する。


1. まずLLMとは何か

LLM(Large Language Model)は、大量のデータを使って学習された言語モデルである。

ここで重要なのは、

LLMの学習データと、現在LLMに渡されている情報は別物

という点である。

Anthropicの公式ドキュメントでは、Context Windowについて、

モデルがレスポンスを生成するときに参照できる情報

という位置付けで説明されている。

そして、これはモデルを訓練した大規模なデータコーパスとは異なる。

つまり、大きく分けると、

LLM
├─ 学習によって身につけた能力・知識
│
└─ 今回の処理で渡されたContext

という2つを区別する必要がある。


2. LLMは毎回答えをネットから検索しているわけではない

例えば、

REST APIとは?

と質問したとする。

この程度の一般的な質問なら、LLMはモデルが学習してきた情報をもとに回答できる。

質問
↓
LLM
↓
学習済みのパターンを使って推論
↓
回答

このとき、必ずしもWeb検索が発生しているわけではない。

AnthropicもTool Useの公式ドキュメントで、モデルがtraining alone(学習だけ)で回答できる場合にはTool Useが必要ないと説明している。


3. では、会社固有の設計書はどうやって知るのか

ここで問題になる。

例えばLLMに、

このシステムでopXXXXXが失敗する原因を調査して

と頼んでも、その会社固有のコードや設計資料は通常、モデルの学習済み知識には存在しない。

そこで必要になるのが、

Tool

である。


4. Toolとは何か

Toolとは、LLMから利用できる外部機能である。

例えば、

Web検索

ファイル検索

ファイル読み込み

DB検索

API呼び出し

コード実行

Bash

ブラウザ操作

などがToolになり得る。

Anthropicの公式Tool Referenceにも、

  • Web Search
  • Web Fetch
  • Code Execution
  • Tool Search
  • MCP Connector
  • Memory
  • Bash
  • Text Editor
  • Computer Use
  • Browser Use

などのToolが掲載されている。

つまり、

LLM自体がすべての処理能力を持っているわけではない。

LLMに外部の能力をToolとして与えることで、できることを増やしている。


5. LLMが直接ファイルを操作しているわけではない

ここはかなり重要だった。

例えばClaudeにファイル操作Toolを与えたとする。

イメージとしては、

Claude
 ↓
ファイルを直接操作

と思ってしまう。

しかし、厳密には少し違う。

Anthropicの公式ドキュメントでは、

モデル自身が操作を実行するわけではない

と明確に説明されている。

例えばClient Toolの場合、

Claude
 ↓
「このToolを、この引数で使いたい」
 ↓
tool_use
 ↓
アプリケーション
 ↓
実際に処理を実行
 ↓
tool_result
 ↓
Claude

となる。

つまりClaudeは、

何を実行するかを判断する側

である。

実際の処理は、アプリケーション側やAnthropic側のToolが担当する。


6. 「資料を探してくれる」の正体

ここまで理解すると、最近感じる

「AIが勝手に関連資料まで探してくれる」

という現象も理解できる。

例えば、

このAPIのテストがNGになる原因を調査して

と指示する。

LLMが、

APIだけでは原因が分からない

と判断したとする。

そこで、

ユーザー
   ↓
「テストNGの原因を調査して」
   ↓
LLM
   ↓
「関連コードを調べよう」
   ↓
検索Tool
   ↓
関連コード取得
   ↓
LLM
   ↓
「設定ファイルも必要そう」
   ↓
検索Tool
   ↓
設定取得
   ↓
LLM
   ↓
「テストデータも確認しよう」
   ↓
ファイル検索
   ↓
テスト資料取得
   ↓
LLM
   ↓
情報を比較
   ↓
原因候補を出す

という処理ができる。

つまり、

LLMが資料そのものを最初から知っているのではない。

必要な情報を判断し、

Toolを使って取得し、その結果を使って再び推論している

のである。


7. これはAnthropic公式ドキュメントにも書かれている

Anthropicの「Tool use with Claude」では、

ClaudeはユーザーのリクエストとToolの説明をもとに、いつToolを呼び出すかを判断する

と説明されている。

例えばWeb Search Toolの場合、

ユーザー
 ↓
Claude
 ↓
検索が必要か判断
 ↓
Web Search
 ↓
検索結果
 ↓
Claude
 ↓
回答

となる。

Web Searchの公式ドキュメントでも、

  1. ClaudeがPromptをもとに検索するか判断
  2. APIが検索を実行
  3. 検索結果をClaudeに提供
  4. 必要ならこれを複数回繰り返す
  5. Claudeが最終回答

という流れが説明されている。

つまり、

LLM → 検索 → 情報取得 → LLM → 必要なら再検索

という動きは、AIエージェントの実際の仕組みとして存在する。


8. Agentic Loopとは

この、

考える
 ↓
Tool
 ↓
結果
 ↓
考える
 ↓
Tool
 ↓
結果

という繰り返しが非常に重要になる。

Anthropicは公式ドキュメントでこれを、

Agentic Loop

として説明している。

例えば、

while (まだ解決していない) {

    LLMが次の行動を判断

    ↓

    Toolを要求

    ↓

    Tool実行

    ↓

    結果をLLMへ

}

というイメージになる。

従来の単純なチャットは、

質問
↓
LLM
↓
回答

だった。

Agentでは、

質問
↓
LLM
↓
Tool
↓
LLM
↓
Tool
↓
LLM
↓
Tool
↓
最終回答

までできる。

この違いはかなり大きい。


9. 取得した資料はどこに入るのか

そこで出てくるのが、

Context Window

である。

Context Windowとは簡単に言えば、

LLMが現在の回答を考えるときに参照できる情報の範囲

である。

例えば、

Context

├─ System Prompt
├─ ユーザーの質問
├─ 過去の会話
├─ 読み込んだコード
├─ Toolの実行結果
├─ 検索結果
└─ その他の入力

などがLLMの判断材料になる。

したがって、

Tool
 ↓
資料取得
 ↓
Context
 ↓
LLM
 ↓
推論

という関係になる。


10. ただし資料を全部入れればいいわけではない

ここも重要である。

例えばプロジェクトに、

10,000ファイル

あったとする。

それを全部LLMに渡せばよいかというと、そうではない。

関係ない情報まで大量に渡すと、

  • Contextを大量に消費する
  • コストが増える
  • 必要な情報を見つけにくくなる
  • Tool選択が難しくなる

といった問題が発生する。

そこで、

必要な情報だけを探してContextへ入れる

という考え方が重要になる。


11. Tool Searchという仕組みもある

Anthropicには、

Tool Search Tool

という仕組みもある。

例えばエージェントに、

GitHub
Slack
DB
Grafana
Sentry
ファイル検索
メール
カレンダー
Web検索
...

と大量のToolが接続されているとする。

すべてのTool定義を最初からLLMへ渡すと、Contextが膨大になる。

そこで、

ユーザーの要求
↓
Claude
↓
必要なToolを検索
↓
必要なToolだけロード
↓
Tool実行

ということができる。

Anthropicの公式ドキュメントでは、Tool SearchによってClaudeが必要なToolをオンデマンドで発見・ロードできると説明されている。


12. Web検索でも「必要な情報だけ残す」が進んでいる

さらに最近のClaudeでは、Web検索結果についても、

Web検索
↓
大量の検索結果
↓
関連情報をFilter
↓
必要な情報
↓
Context
↓
Claude

という処理ができる。

AnthropicのWeb Search公式ドキュメントでは、Claude 4.6以降でDynamic Filteringが利用でき、検索結果がContext Windowへ入る前に関連情報へ絞り込めると説明されている。

つまり、

とにかく大量の情報をLLMに入れる

方向ではなく、

必要な情報を探し、必要なものだけContextへ入れる

方向へ進んでいる。


13. ではLLMの性能向上は関係ないのか?

もちろん関係する。

むしろ非常に重要である。

例えば同じToolを与えられても、

LLM A

「とりあえずコード検索しよう」
 ↓
関係ないコード
 ↓
迷子


LLM B

「このエラーなら、
まず呼び出し元→設定→DB状態を確認しよう」
 ↓
適切なTool選択
 ↓
必要な資料
 ↓
原因特定

となる可能性がある。

つまりLLMが高性能になることで、

  • 何を調べるべきか
  • どのToolを使うべきか
  • どんな検索語を使うべきか
  • Toolの結果をどう解釈するか
  • 次に何を調べるべきか
  • いつ調査を終了するか

といった判断の質も上げられる。

実際、AnthropicのTool定義に関する公式ドキュメントでも、複雑なToolや曖昧な問い合わせでは高性能なモデルを使用することが推奨されている。

したがって、

「最近のAIが資料を探してくれるようになった = LLMだけが進化した」

ではない。

より正確には、

AIエージェントの性能

 ↓

LLMの推論能力
×
Tool Use
×
検索能力
×
Context管理
×
Agentic Loop

くらいに考えると分かりやすい。


14. Agentとは結局何なのか

ここまでをまとめると、AI Agentは、

LLMを中心として、Toolを利用しながら複数ステップの処理を進め、目的を達成する仕組み

と考えることができる。

User
↓
┌─────────┐
│ LLM │
└────┬────┘
│
判断・計画
│
┌─────────┼─────────┐
↓ ↓ ↓
Search API Files
│ │ │
└─────────┼─────────┘
↓
Result
↓
LLM
↓
次の行動を判断

これを繰り返す。


15. ではAgent Builderとは?

ここでようやくAgent Builderにつながる。

Agent Builderとは、

このようなAI Agentの処理を組み立てるための開発環境・仕組み

である。

例えば、

[User Input]
      ↓
[Agent]
      ↓
[File Search]
      ↓
[判断]
   ↙ ↘
成功 不明
 ↓ ↓
回答 Web Search
         ↓
         再度Agent

のようなWorkflowを設計する。

つまり、

LLM

だけではなく、

LLM
+
Tools
+
Workflow
+
Context
+
State

を組み合わせてシステムとして作るのがAgent Builderの役割になる。


16. バックエンドの知識ともつながる

この仕組みを見ると、AI Agentは意外と従来のバックエンド開発と近い。

例えば、

Agent
 ↓
Tool
 ↓
REST API
 ↓
Spring Boot
 ↓
Service
 ↓
PostgreSQL

という構成も普通に作れる。

さらに、

Redis
→ State / Cache

Kafka
→ 非同期処理

Docker
→ 実行環境

REST / RPC
→ ToolとServiceの通信

Observability
→ Agentが何を実行したか追跡

Retry
→ Tool失敗時の再試行

Timeout
→ Agentの暴走防止

認証・認可
→ Agentが実行できる操作の制限

など、バックエンドで学ぶ概念がそのまま登場する。

だからAI Agentを学ぶことと、バックエンド・システム設計を学ぶことはかなりつながっている。


17. 今回一番理解しておきたいこと

最初は、

「最近のモデルは賢くなったから資料まで知っているのかな?」

と思っていた。

しかし実際には、

LLM
↓
「この情報が必要」
↓
Toolを選択
↓
検索・ファイル取得
↓
結果をContextへ
↓
LLM
↓
結果を解釈
↓
「まだ情報が足りない」
↓
別のTool
↓
...
↓
回答

という仕組みがある。

つまり、

LLMがすべての情報を持っているのではなく、LLMが必要な情報を判断し、Toolを利用して外部情報を取得し、その結果を使って推論できる。

これが現在のAI Agentを理解するうえで非常に重要なポイントである。

そしてモデル自体の性能が向上すると、

「何を探すか」「何を読むか」「次に何をするか」

というAgent側の判断も改善する可能性がある。

そのため最近感じる、

「以前より資料をちゃんと探してくれる」

という変化は、

LLMだけではなく、LLM・Tool・検索・Context管理・Agentic Loop全体の進化

として捉えると理解しやすい。


参考:Anthropic公式ドキュメント

ClaudeでのTool Use

Claudeがユーザーの要求とToolの説明から、いつToolを呼び出すか判断する仕組み。

Anthropic公式:
https://platform.claude.com/docs/ja/agents-and-tools/tool-use/overview

Tool Useの仕組み

モデルが直接処理を実行するのではなく、Toolの呼び出しを要求し、実行結果を再びClaudeへ返すAgentic Loopについて説明されている。

Anthropic公式:
https://platform.claude.com/docs/ja/agents-and-tools/tool-use/how-tool-use-works

Tool Search Tool

大量のToolを最初からContextへ読み込まず、Claudeが必要なToolを検索してオンデマンドで読み込む仕組み。

Anthropic公式:
https://platform.claude.com/docs/ja/agents-and-tools/tool-use/tool-search-tool

Context Window

モデルがレスポンス生成時に参照できる情報と、モデルの訓練データとの違いについて確認できる。

Anthropic公式:
https://platform.claude.com/docs/ja/build-with-claude/context-windows

Tool Reference

Web Search、Web Fetch、Code Execution、Tool Search、MCP、Memory、Bash、Text Editor、Computer Useなど、Anthropicが提供するToolを確認できる。

Anthropic公式:
https://platform.claude.com/docs/ja/agents-and-tools/tool-use/tool-reference

Web Search Tool

Claudeが検索の必要性を判断し、検索結果を受け取って回答する流れやDynamic Filteringについて説明されている。

Anthropic公式:
https://platform.claude.com/docs/en/agents-and-tools/tool-use/web-search-tool

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?