目標ベース・エージェントとは

エージェントの複雑性に関する5段階の階層構造において、目標ベース・エージェントはちょうど真ん中に位置します。単純な反射エージェント（あらかじめ定義されたルールに従う）やモデルベース反射エージェント（世界の内部モデルを追加する）よりも複雑です。しかし、ユーティリティーベース・エージェント（いわゆるユーティリティー関数を用いてトレードオフを計算できる）や学習エージェント（多くの場合、強化学習やディープラーニングによって、時間とともに適応し、改善することができる）よりは複雑ではありません。

目標ベース・エージェントは、将来の状態を考慮した計画機能を追加することで、より単純な反射型エージェントを上回りますが、より洗練されたエージェントのような動的なアセスメントを採用することはできず、その代わり目標を達成するためにあらかじめプログラムされたストラテジーや決定木に依存しています。

目標ベース・エージェントの一例は、ロボット工学、特に倉庫の自動化の領域から来たものであります。特定の棚から特定の商品を選ぶ必要がある倉庫ロボットは、掃除機が壁にぶつかってしまうような、目の前の障害物に反応するだけで済みます（純粋に「反応型エージェント」）。ただし、遠回りを最小限に抑え、既知の障害物を避ける経路を計画する方が効率的です。例えば、最新の倉庫のような動的な環境では、計画モジュールはナレッジベースを参照し、現在の状態を観察し、将来の状態をマッピングできる（他のチャットボットの計画された動きを認識するなど）ことで、目的の結果を効率的に達成することができます。

目標ベース・エージェントは、次の4つの段階で動作します。

1. 目標の定義
2. 計画
3. アクションの選択
4. 実行

まず、エージェントには成功の正確な定義が与えられます。ユーティリティーベース・エージェントとは異なり、目標ベース・エージェントは二値的な論理的条件下で動作します。しかし、目標ベース・エージェントは、ビットをある状態から別の状態に反転することを成功と定義する場合がありますが、そのようなエージェントの単一の「目標」が、中程度に複雑な提案論理や一次論理のセットであるのを妨げるものはありません。例えば、ロボットは「現在緊急マークが付けられている各荷物について、それぞれの在庫場所から出荷ドックに配達する」という目標を設定する場合があります。この目標は基本的に二者択一（この目標で成功するか失敗するかのいずれか）ですが、複数のコンポーネントがあり、複雑さが増す可能性があります。

人間が目標を正確に定義するのは素晴らしいことですが、より曖昧な目標（「休暇の学習を最適化する」）を入力し、LLMがそのギャップを埋めて、より正確な目標または一連の目標（例：「システムの毎日のスループットを推定する」、「Pパッケージを最優先順位として定義する」、「24時間以内にPパッケージを配信するという目標を設定する」）に定義することも可能です。

目標を設定した目標ベース・エージェントは、実行に移る前に、いくつかの計画を立てます。例えば、倉庫の例では、エージェントは現在の状況と潜在的な状況をモデル化するのに時間を費やし、最も優先度の高い注文を時間内に処理する最適な経路を選択します。例えば、在庫棚から出荷米までの移動をどのくらいの頻度で行うべきかを決定するなどです。

もちろん、計画の良し悪しは、それが遭遇する現実と同じくらいです。一部の目標ベース・エージェントは「保守的」で、文字通り不可能になるまで計画を維持することを好みますが、より柔軟なアプローチは「日和見的」エージェントで、計画の障害に遭遇した場合に、より良い次の行動を柔軟に計算します。例えば、Googleマップが予期せぬ交通渋滞を回避するようにルーティングされたときです。

倉庫ロボットの場合、機械上のセンサーは状況をリアルタイムで監視し、重要なデータを計画モジュールにフィードバックするのに役立ちます。例えば、サブ目標の「荷物をつかむ」が何らかの理由で失敗したことをセンサーが検知した場合、目標ベース・エージェントは原因の診断を試み、代替アプローチを計画したり、バックアップを呼び出したりすることができます。

どのタイプのAIエージェントを使用するかは、どのような問題を解決しなければならないかによって決まります。特定の目標が与えられている限り、目標ベース・エージェントの基盤となるAIモデルは情報に基づいた意思決定を行い、複雑なタスクを処理できますが、成功の基準は単純なもの（多くの場合、二者択一）でなければなりません。

しかし、リアルタイムの適応性が重要な場合や、複数の目標を最適化する必要がある場合、企業は目標ベース・エージェントからユーティリティーベース・エージェントのようなより高度な選択肢へと移行したいと考えるかもしれません。ここでの典型的な例は自動運転車です。乗客が自動運転車を運転する場合、持続時間、価格設定、交通回避、安全性という複数の目標のバランスを取る必要があります。最高の顧客体験を提供するために、AI搭載の車両は複雑な意思決定プロセスを経て、可能な行動のさまざまなトレードオフを検討する必要があります。結果として得られるユーティリティー関数は、エージェントのアクションを指示します。

エージェント型システムはエージェントの種類を「組み合わせてマッチさせる」ことはできず、各エージェントは手元の問題の複雑さに合わせて調整されています。例えば、医療の一例として、ワークフローを実行するために目標ベース・エージェントだけでなく、他の4つのタイプのエージェントを採用している病院を想像することができます。

最も単純なレベルでは、Vitals Monitorという名前の反射型エージェントは、すべての患者のバイタルサインを単純にモニタリングするだけで済みます。その具体的な目的は、例えば患者の心拍数が一定のレベルを下回ったときにアラームをトリガーすることです。医師や看護師に人間の介入を求める方が良いでしょう。このようなエージェントは、単純なif/thenアルゴリズムに頼ることができます。

1つ上のレベルでは、「在庫エージェント」というモデルベースの反射型エージェントが、病院の医薬品や物資の在庫を管理することがあります。現在の在庫、過去の使用パターン、サプライチェーン・パートナーの応答時間に関する内部モデルを維持し、再注文を効率化するのに役立ちます。

3つ目は、退院プランナーと呼ばれるより高いレベルの目標ベース・エージェントで、患者の退院という単純な二者択一の目標から逆算して取り組む可能性があります。将来の状態を考慮しながら、事前にプログラムされたストラテジーと決定木に依存し、必要なすべてのサブタスクを含む研究室、医薬品、専門家の承認を調整します。ステップが遅れた場合、その計画モジュールが再実行され、新しい計画が策定されます（目標ベース・エージェントは、これらのほとんどのエージェント同様、大規模言語モデルに基づいてファイン・チューニングされる可能性があります）。

4番目に、Bed Assignment Optimizerと呼ばれるユーティリティーベース・エージェントは、安全性、満足度、スループットの最大化を図りながら、患者をさまざまな部屋に割り当てることができます。複数の商品と複雑なトレードオフを管理する必要があるため、エージェントはユーティリティー関数を使用して、伝染力、人員配置レベル、病気の重症度などの変数を評価します。

最高レベルの5つ目は、Intake Assistantと呼ばれる学習エージェントで、機械学習を採用し、トリアージの質問を改善し、高リスクの患者にフラグを立て、冗長な手順を減らすために、過去の経験からパターンを探します。下層エージェントとは異なり、この学習エージェントは進化するデータセットを継続的に評価し、人間には見えない可能性のある深いパターンを求める必要があります。

5人のエージェントは、複雑な問題を解決するためにバーチャル・アシスタントの集合体として協力します。適切なオーケストレーションと、自然言語処理（NLP）や生成AIからコンピューター・ビジョンやAPIツールの呼び出しまで様々な機能の統合により、マルチエージェント・システムはシンプルであるべきところはシンプルに、複雑であるべきところは複雑になります。