まずAIエージェントとは、AI(LLM)が目的達成の為に、処理の計画や処理自体を自律的に判断の上、実行する技術を指します。
例えばシンプルな例ですが、以下の図のようなイメージです。

図1 AIエージェントの処理イメージ

1つの処理を細かく段階的に実施するように区切る点は、LLMに質問をする際の手法（プロンプト手法）であるCoT(Chain-of-Thoughts)や、モデルの内部で段階的な処理を行う推論モデル(Reasoning Model)と近しい考え方です。

人によっては「外部ツールを活用して処理を行えるもの」や「複数の役割を持ったAIが相互に影響を与えるもの（マルチエージェント）」という印象を持っている方もいるかもしれません。
この考え方も誤りではありません。
「エージェント設計パターンカタログ」と呼ばれる論文(※)には、AIエージェントに関する18個の設計パターンが記載されており、外部ツールを扱って処理を行う為のパターンである「ツール/エージェントレジストリ」「エージェントアダプタ」や、複数の役割を持ったAIを活用する為の協調パターン(投票型・ロールベース型・議論型)もあげられています。
※ https://arxiv.org/abs/2405.10467

「他AIとの協調」観点では、場合によっては特定の専門知識やタスクを教え込んだファインチューニング済の専門モデルとやり取りを行う場合もあります。

「外部ツールを活用する」点については、例えば前述の例でいえば「8月の京都の気温確認」タスクは、情報をどこからとってくるかを考えた上で、情報を取得する必要があります。
また、昨今注目度が高いコード生成型エージェントについても以下のような構成とすることで、高い精度に繋げる事ができるでしょう。

図2 コード生成エージェントの実現例

「ツールの活用」は情報の取得だけでなく、他システムの操作（登録など）も含みます。

図3 登録処理を含んだAIエージェントの例

これまでの図では「Agent」とまとめてしまっていました。
Agent自体の構造は、以下の図のようになります。

図4 AIエージェントの仕組みイメージ

ポイントとしてはアプリケーションを経由してツールを呼び出す点です。
LLMにはユーザから質問を受け付けるアプリケーションからLLMに使えるツールなどの情報を共有して、ツールを使うか判定してもらうイメージです。
ツールの実行後、結果をまたLLMに渡すことで、次の処理に進んでもらう、というようにアプリとLLMでのやり取りが複数回内部で発生する形となります。

LLMにて情報の取得先や取得方法を検討・判断するという観点では、第6回で触れたSelf-Routeなどと何が違うのか？と疑問に思う方もいるかもしれません。
これらは事前に決められた選択肢とルートがあり、LLMの判断の上で処理を変えるものでした。
AIエージェントは事前に決められたルートがない状態から、自身でルートを作って処理を行っていくようなイメージとなります。

図5　WorkflowとAgentの違い

この違いはWorkflow(ワークフロー)とAIエージェントの違いともいえます。
第1回や第6回で取り上げたハンズオンでは、動作前に処理の流れ(Workflow)を定義していました。
これらの例のようにWorkflowは決められた処理のなかで動作する為、柔軟性は限定的ですが、期待する回答との乖離やブレがあっても影響は小さく、精度を高くしやすい傾向があります。

対してAIエージェントは、使い勝手や対応力は柔軟で優れていますが、計画や判断をAI任せにしている分、結果のブレも大きくなりがちです。
その為、小さいタスクで結果が安定しやすいWorkflowや精度の高いRAGを部品として組み込まれることがあります。

図6 AIエージェントが連携するツールの例

また「回答の妥当性判定ロジック」を組み込むことも良いでしょう。

図7 精度向上に向けた改善案(妥当性判定ロジックの組み込み)

このようにRAGやWorkflow、ファインチューニングされたモデルなど、これまで紹介してきた様々な要素がAIエージェントを作るうえで関係する可能性があります。
また仕組みを作るうえでは、これまでの仕組み作りと同様にプロンプトも重要です。
したがってAIエージェントの作成は、各要素を組み合わせた総合格闘技のようなイメージと言えるかと思います。

なお、AIエージェントというと全てを自動で処理するものというイメージもあるかもしれません。
前述の「エージェント設計パターンカタログ」では、精度の判定に人を関与させる「ヒューマンリフレクション」と呼ばれるアプローチも示されています。
最近ではブラウザ操作やファイル操作もAIに任せる技術も登場していますが、全てを無理に自動化する必要はありません。
例えば「操作の前に人の確認を挟む」といった、従来のLLM活用と同様に「人を巻き込む」設計も依然として重要です。

ここからはDifyを使ってシンプルなAIエージェントを動かして、AIエージェントの動作イメージをより鮮明にしていきましょう。
図4のアプリケーションの役割をDifyが受け持つ、というイメージです。
Difyの基本的な使い方は第1回や第3回を参照ください。

Difyトップページから アプリを作成する > 最初から作成 > エージェント を選択しましょう。
すると第3回で扱った「チャットボット」作成画面と似た画面が表示されます。

ここで利用するモデルやコンテキスト(RAG)として登録したドキュメントや利用可能な外部ツールなどを設定します。
利用モデルはこれまで同様Ollama上で動作するgemma3としました。
また、今回はシンプルなケースで実施する為、第3回で登録したドキュメントのみをコンテキスト(RAG)として利用できるように指定しました。

設定画面と「デバッグとプレビュー」の結果が以下となります。

図8 DifyによるAIエージェント機能とその動作について

結果をもう少しよくみてみましょう。

図9 動作結果の詳細

図の内容から、これまで扱ってきたWorkflowのように事前にルートを定義していないにもかかわらず、質問に応じて処理を変えて回答を生成していることが見て取れるかと思います。
具体的には、1つ目の質問（NTTテクノクロスについて）はRAGの情報を活用する事を判断した上で回答し、2つ目の質問(日本の首都について)は特に外部情報を使う事なく回答しています。
このように質問内容に応じて、動作を変化する為、質問に対する高い柔軟性を備えていると言えます。

なお、推論（計画作成や回答作成・判断など）と実行処理（外部ツールやRAG活用）を繰り返す枠組みをReActフレームワークと呼びます。
プロンプト手法にもReActプロンプトと呼ばれる手法がありますが、これは質問文の書き方であり、処理の流れを表す言葉ではない為、別物と考えると良いかと思います。
ただし計画をたてて行動の上、回答を作る、という考え方自体は似ています。

図10 ReActについて

ReActフレームワークによる処理は、場合によって無限ループしてしまう可能性があります。
その為、ユーザの質問から回答までの時間制限や内部処理の実行回数上限などを決めておけると良いでしょう。

最後に、利用するモデルについて補足します。
（要件にもよりますが、）基本的にはAIエージェントの特性上、高精度・大規模なモデルを採用することが望ましいといえます。
LLMを用いたアプリケーションは、利用モデルによって精度が左右されることがありますが、AIエージェントも同様の考え方となることをおさえておきましょう。