AIエージェントの種類を5分類で解説

AI エージェントの種類

AI エージェントの種類は、1 つの分類体系に基づきます。単純反射型、モデルベース反射型、目標ベース型、効用ベース型、学習型の 5 種類です。それぞれの名称は、エージェントがどの程度の情報を記憶し、行動する前にどこまで先を見通して計画するかを示します。マルチエージェントと階層型という 2 つの用語は、個々のエージェントがどのように判断するかではなく、複数のエージェントをどのように接続するかを示します。

この分類は、これまでに使用したどのモデルよりも古いものです。標準的な AI の教科書に由来し、大規模言語モデルの登場後も使われ続けています。これは、設計を決める問いを扱っているためです。その問いは、「この仕組みは行動する前に何を知る必要があるか」です。エージェントとチャットアシスタントの境界をまだ整理できていない場合は、先に AI エージェントとそれが実行する LLM の違いを読んでください。このページは、その説明の後から始まります。

単純反射エージェント: 1 つの条件、1 つのアクション

単純反射エージェントは、現在の入力をアクションに対応付けます。それ以前の情報は記憶しません。温度が 25 を超えたら、ファンをオンにします。仕組みはこれだけです。

皆さんも、ほぼ確実に実行したことがあります。フォーム送信を読み取り、データベースに行を書き込む n8n ワークフローを webhook で起動する処理は、単純反射エージェントです。途中で language model がその行のカテゴリを選んでいても、単純反射エージェントであることに変わりはありません。1 時間前に何をしたかを尋ねても、答えを保持しているものがないため、説明できません。

この種類は、予想以上に正しく動作します。実行コストが低く、失敗の原因も明確です。条件に一致したか、一致しなかったかのどちらかです。処理の内容が本当に「X が届いたら Y を実行する」である場合、メモリは誤動作の可能性を増やすだけで、得られるものはありません。webhook で起動する n8n エージェントは、この分類にユーザーインターフェースを加えたものです。

正しいアクションが履歴に依存する場合、この方式は機能しなくなります。スレッドの状態を持たない返信ボットは、3 通目のメッセージで自分の発言と矛盾します。最初の 2 通のメッセージが入力に含まれていなかったためです。

イベント間で状態を保持するモデルベース反射エージェント

モデルベース反射エージェントは、環境の内部表現を保持し、新しい入力を受け取るたびにその表現を更新します。ここでいう「モデル」は、ニューラルネットワークではなく、世界のモデルを指します。この用語は現在の意味より約40年前から使われており、初めて読む人のほとんどを混乱させます。

動きが20分間検出されなければ照明を消すホームオートメーションのルールは、モデルベースです。そうでなければ実現できません。単純な反射エージェントにとって、「現在動きがない」と「21:40 以降、動きがない」は同じ入力です。両者を区別できるのは、保存された状態だけです。

LLM の場合は、背後にメモリーストアを持つエージェントがこれに該当します。たとえば、会話の要約を順次保持する仕組みや、エージェントが実行開始時に毎回読み込む単純な markdown ファイルです。エージェント用のローカルメモリーサービスは、この考え方をパッケージ化したものです。仕組みは変わりません。エージェントが保持する世界の内部表現は、それを作成したイベントの後も残ります。

状態にはコストがあります。古い事実は、事実がないより悪い場合があります。エージェントが警告なしに、それを完全に正しいものとして扱って行動するためです。保存する情報には、有効期限を設けるか、再確認する仕組みを用意する必要があります。そうしないと、エージェントは3月に廃止したサーバーについて推論し続けます。

ゴールベースエージェント: 確認可能な状態に向けて計画する

ゴールベースエージェントは目標状態を受け取り、そこに到達する一連のアクションを探索します。最終的に到達すべき状態から逆算するため、経路が事前に決められているわけではありません。

自分で実行できる最も分かりやすい例はコーディングエージェントです。「失敗しているテストを成功させる」という指示には、ファイル名も手順も含まれていません。エージェントはテストを読み、計画を立て、何かを編集し、テストを実行し、エラーを読み取って再試行します。実行可能な確認でループが終了するため、この指示は機能します。一方、「このコードを改善する」では機能しません。エージェントが評価できるゴールなら、エージェントは到達できます。評価できないゴールは、費用だけが発生する無限ループになります。自分の VPS でコーディングエージェントを実行すると、そのループをノートパソコンを占有せずに実行し続けられる場所へ移せます。

費用が発生するのは、この行程です。計画の各ステップでは、それまでの履歴を含む追加のモデル呼び出しが発生します。そのため、10 ステップのタスクは 1 ステップのタスクの 10 倍の料金では済みません。重要なのは、ループの構造と停止条件を設計することです。これについては ループエンジニアリングで扱います。

ユーティリティベースのエージェント: 複数の適切な回答から選択する

目標は二値です。ユーティリティはスコアです。ユーティリティベースのエージェントは、許容できる結果が複数ある場合に、作成した関数で最も高いスコアになるものを選びます。

業務開始前にバックアップジョブを完了し、アップリンクを飽和させない必要がある場合、これはユーティリティの問題です。唯一の正解はなく、トレードオフだけがあります。価格と回答品質を比較しながら、どのリクエストをどのモデルで処理するかを決めるルーターも、同じ構造です。

難しいのはアルゴリズムではありません。誠実なユーティリティ関数を書くことです。コストだけで評価すると、すべてのリクエストで最も安いモデルが選ばれます。その中には、高価なモデルが必要だったリクエストも含まれます。システムは、測定した内容だけを正確に最適化します。測定しやすいという理由で指標を選んだ場合、これは問題になります。

学習エージェント: 多くの人がすでに持っていると思い込んでいるタイプ

学習エージェントは、過去の結果に対するフィードバックをもとに、自身の動作を変更します。結果を評価する仕組みと、その評価に応じてポリシーを変更する仕組みが必要です。

この条件を満たす self-hosted システムは、ほとんどありません。先週自分で書いたメモを読むエージェントは、メモリファイルを持つ model-based agent です。重みは変わっていません。ポリシーも変わっていません。Retrieval は学習ではありません。この違いは実務上重要です。メモリベースのシステムは、メモリを編集しない限り同じ誤りを永遠に繰り返します。一方、学習システムはその誤りを繰り返さなくなることが期待されます。

学習の部分が必要なら、まず評価を構築してください。スコア付きのテストセット、それに対して変更を実行する処理、そして変更を保持するか破棄するかの判断があれば、あなた自身が学習コンポーネントとなる閉ループを構成できます。これは聞こえる以上に時間がかかりますが、現在 self-hosted の構成要素で機能する唯一の方法です。eval harness を self-hosting することから始めます。

マルチエージェントシステムと階層型システム: 種類ではなく配置

これらは第6、第7の種類ではありません。エージェントの配置方法を表します。

マルチエージェントシステムでは、キューや git リポジトリなどの共有環境内で複数のエージェントを同時に実行します。環境を共有するため、エージェント同士がそこで競合します。2 つのエージェントが 1 つのファイルを編集するのが典型的な失敗であり、ロックまたは作業キューで対処します。プロンプトでは解決できません。

階層型システムでは、ワーカーの上位にスーパーバイザーを置きます。スーパーバイザーはタスクを分割し、各部分を割り当て、返された結果を統合します。人間の作業分担に近いため広く使われますが、読み取る報告ごとにスーパーバイザーのコンテキストが増えるため、コストが高くなります。マルチエージェントハーネスでは、実際の接続方法を示します。

ほとんど動く 4 つのエージェントより、動作する 1 つのエージェントの方が優れています。

情報が失われる可能性は、引き継ぎのたびにあります。まず 1 つのループから始めてください。ボトルネックになっている手順を特定できる場合にのみ、分割します。

ほぼすべての実システムがハイブリッドである理由

自分で運用する可能性のあるデプロイエージェントを考えてみます。Webhook がエージェントを起動する部分は、反射型です。エージェントは現在のリリース状態を読み取ります。これはモデルベース型です。実行中のバージョンから対象バージョンまでの手順を計画する部分は、目標ベース型です。現在の負荷からロールアウトの時間枠を選ぶ部分は、効用ベース型です。エージェントは自身のポリシーを編集しないため、学習型ではありません。

1 つのシステムが、分類体系の 4 つの分類に同時に該当しています。この分類体系は、完成した製品にラベルを付けるためではなく、設計チェックリストとして役立ちます。システムが想定外の動作をしたときに有用なのは、どの層に問題があるかを問うことです。誤ったイベントで発火したトリガー、古くなった状態、決して通過できない目標チェック、誤った結果を報酬するスコアは、それぞれ異なるバグであり、修正方法も異なります。

用途に応じたタイプの選び方

• 固定されたトリガーに固定された応答を返し、履歴が不要な場合: 単純反射型です。
• 適切な応答が、それ以前に起きたことに依存する場合: モデルベース反射型です。
• 最終状態は確認できますが、そこへ至る経路が事前には分からない場合: 目標ベース型です。
• 許容できる結果が複数あり、それらの間に実際のトレードオフがある場合: 効用ベース型です。
• 結果を時間とともに改善する必要がある場合: 評価ループを構築し、自分自身が学習コンポーネントになることを受け入れます。

これらのエージェントは自分でホスティングできますか。費用はいくらですか。

はい。費用は大きく2つに分かれます。オーケストレーションの費用は安価です。n8n のインスタンスや Python のエージェントループは、処理時間の大半をネットワーク呼び出しの待機に使うため、2 vCPU と 4 GB の RAM で動作します。費用の大部分を占めるのはモデルです。

エージェントがホステッド API を呼び出す場合、サーバーに必要なリソースはほとんどなく、請求額はトークン数に応じて増えます。目標ベースのエージェントでは、許可する計画ステップの数に応じて増えるため、ループ回数に上限を設定してください。

モデルを自分のハードウェアで実行する場合、何を実行できるかは RAM 容量で決まります。以下の数値は、2026 年 8 月時点で一般に公開されている 4-bit 量子化済み重みの代表的なファイルサイズと、計画時に必要となる総 RAM 容量です。コンテキストウィンドウとランタイムには、重み以外の領域も必要になるためです。

[
  {
    "label": "3B model",
    "weights_gb": 2,
    "ram_needed_gb": 6
  },
  {
    "label": "8B model",
    "weights_gb": 4.9,
    "ram_needed_gb": 10
  },
  {
    "label": "14B model",
    "weights_gb": 9,
    "ram_needed_gb": 16
  },
  {
    "label": "32B model",
    "weights_gb": 20,
    "ram_needed_gb": 32
  },
  {
    "label": "70B model",
    "weights_gb": 43,
    "ram_needed_gb": 64
  }
]

4-bit の 8B モデルの重みは約 4.9 GB で、10 GB の RAM を搭載したマシンならスワップなしで実行できます。同じ量子化方式の 70B モデルの重みは 43 GB で、約 64 GB の RAM が必要です。ただし、これらの数値には速度が含まれていません。GPU のない VPS では、4-bit の 8B モデルは 1 秒あたり1桁台のトークンしか生成できません。夜間にキューを処理するエージェントなら問題ありませんが、人が応答を待つ用途では遅すぎます。ローカル推論はバッチ処理に限定し、対話的な処理には GPU または API を使用してください。自分でホスティングできる AI エージェントの候補では、ディスク容量を割く価値のあるプロジェクトを説明し、2026 年のエージェント学習ロードマップでは、何をどの順番で学ぶべきかを説明しています。

分類が役に立たなくなるところ

ツールや権限については何も述べていません。教科書に登場するエージェントは、知覚して行動します。その章を書いた人は、エージェントが本番環境の API token を保持する事態を想定していませんでした。shell access を持つ目標ベースのエージェントと、読み取り専用の database connection を1つだけ持つ目標ベースのエージェントは、表では同じ行に分類されます。しかし、実際のリスクは大きく異なります。エージェントがどこにアクセスできるかを決めてから、どれほど高度にするかを決めてください。credential を渡す前に、AI エージェントから Secret を除外する方法を読んでください。

また、ステップが失敗したときの動作についても何も述べていません。実際のエージェントは、実行時間の大半をエラー処理に費やします。rate limit に達する場合もあれば、tool が model の想定外の値を返す場合もあります。そのコードによって、システムが実用になるかどうかが決まります。しかし、分類のどの行にもその説明はありません。

FAQ

AI エージェントにはどのような 5 つの種類がありますか？

単純反射型、モデルベース反射型、目標ベース型、効用ベース型、学習型の 5 種類です。エージェントが行動する前に持っている情報量の順に並んでいます。単純反射型エージェントは、現在の入力だけを見ます。モデルベースエージェントは、環境の状態を保持します。目標ベースエージェントは、目標状態に向けて計画を立てます。効用ベースエージェントは、許容できる複数の結果を評価し、最も高いものを選びます。学習型エージェントは、フィードバックに基づいて自身のポリシーを変更しますが、実際にこれを行う self-hosted 環境はほとんどありません。

単純な自動化には、どの種類の AI エージェントを使うべきですか？

単純反射型エージェントです。実際には、固定された一連の処理を起動する webhook またはスケジュールを意味します。正しい応答が直前に到着した入力だけで決まるなら、メモリを追加しても障害要因が増えるだけで、機能は増えません。過去に何が起きたかを把握しなければならない判断を 1 つでも挙げられるようになった時点で、モデルベース設計に移行します。

VPS 上で独自の AI エージェントを実行できますか？

はい。オーケストレーション層は軽量なので、2 vCPU と 4 GB の RAM があれば、ワークフローエンジンやエージェントループを無理なく実行できます。実際に判断すべきなのは、モデルをどこで実行するかです。ホスト型 API を使うとサーバーを小さく保てますが、コストはトークン使用量に応じて発生します。ローカルモデルには、パラメーター数に比例した RAM が必要です。GPU がなければ、生成速度は 1 秒あたり 1 桁のトークンになるため、チャット画面よりもキューに入れたバッチ処理に適しています。

大規模言語モデルは、それだけで AI エージェントですか？

いいえ。モデルは入力テキストを出力テキストに変換して停止します。モデルを、外部環境に対して操作を実行し、その結果を再び入力できるループでラップすると、エージェントになります。そのためには、呼び出し可能なツールと、ループを停止する条件が必要です。エージェントに当たるのはラッパーです。モデルはその内部の 1 コンポーネントです。

マルチエージェントシステムは必要ですか？

通常は必要ありません。複数のツールを備えた単一のループで、ほとんどの処理に対応でき、デバッグもはるかに容易です。複数のエージェントが有効なのは、タスクの各部分が本当に独立していて同時に実行できる場合や、ある部分だけ別のモデルが必要な場合です。その代わり、共有状態の管理や、各ワーカーの報告を読むたびにコンテキストが増える supervisor の運用が必要になります。処理の遅いステップを具体的に示せるようになった時点で、2 つ目のエージェントを追加します。