このページでは、エージェントの用語集について説明します。用語集のすべての用語については、こちらをクリックしてください。
A
act
エージェントが理由ステージで選択したアクションを実行する、エージェント ループのステージ。たとえば、行動ステージで API リクエストを送信できます。
アクション
強化学習では、エージェントが環境の状態間を遷移するメカニズム。エージェントは、ポリシーを使用してアクションを選択します。
アクション空間
エージェントがタスクの実行に使用できるリソースのセット。アクション スペースには、エージェントが呼び出すことができるツールと API、エージェントが保持する権限が含まれる場合があります。一般に、行動空間はエージェントがタスクを実行するのに十分な大きさにする必要があります。アクション空間が小さすぎると、エージェントがタスクを実行するためのリソースが不足する可能性があります。行動空間が大きすぎると、エージェントはエラーを起こしやすくなります。
エージェント
ユーザーに代わってアクションを計画し実行するために、ユーザー入力を推論できるソフトウェア。
強化学習では、エージェントは ポリシーを使用して、環境の状態間の移行から得られる期待収益を最大化するエンティティです。
エージェントの/代理人の
エージェントの形容詞形。エージェント性とは、エージェントが持つ特性（自律性など）を指します。
エージェント ループ
エージェントが終了条件が満たされるまで繰り返すサイクル。通常、このサイクルは次の 4 つのステージで構成されます。
エージェント ワークフロー
エージェントが目標を達成するためにアクションを自律的に計画して実行する動的プロセス。このプロセスでは、推論、外部ツールの呼び出し、計画の自己修正が行われることがあります。
エージェントのオーケストレーション
複数のサブエージェントまたは LLM 呼び出しにわたるタスクの一元管理とルーティング。エージェント オーケストレーションは、複雑なタスクを小さなサブタスクに分解し、最も有能なサブエージェントに割り当てます。
自律型エージェント
複雑な目標を達成するために、計画、行動、適応を継続的な人間の介入なしに行うエージェント。
E
評価エージェント
結果が確定する前に、別のエージェントの結果を評価するエージェント。1 つのエージェントが製品を製造し、別のエージェント（評価エージェント）がリリース前にその製品をテストすると考えることができます。
批評家は、評価エージェントの同義語です。
F
フィードバック
エージェントが行動ステージで実行されたアクションを評価するエージェント ループのステージ。たとえば、エージェントが行動フェーズで API リクエストを送信した場合、フィードバック フェーズで API レスポンスが成功したかどうかを判断できます。
G
Gemini モデル
Google の最先端の Transformer ベースのマルチモーダル モデル。Gemini モデルは、エージェントと統合するように特別に設計されています。
ユーザーは、対話型ダイアログ インターフェースや SDK など、さまざまな方法で Gemini モデルを操作できます。
生成エージェント（シミュラクラ）
現実的な人間の行動をシミュレートする独自のペルソナ、記憶、ルーティンを備えたエージェント。
詳細については、Generative Agents: Interactive Simulacra of Human Behavior をご覧ください。
M
マネージャー エージェント
1 つ以上のサブエージェントを制御するエージェント。
マルチエージェント コラボレーション
複数の特化型 AI エージェントが相互にやり取りしたり、議論したり、タスクを渡したりして、複雑な問題を解決するフレームワーク。
O
観測
エージェントがエージェントの進捗状況の側面を調査または評価するエージェント ループのステージ。たとえば、act ステージでコードが生成されるとします。そのため、observe ステージで生成されたコードに対してテストが実行されることがあります。
P
plan-and-solve
モデルが最初に行動を実行する前に、明示的な複数ステップの計画を立案するエージェント戦略。
プラグイン
エージェントに簡単に接続して機能を拡張できる、標準化されたモジュール型のツール。たとえば、GitHub プラグインを使用すると、エージェントは GitHub の問題の読み取りや pull リクエストの作成などのアクションを実行できます。
手続き記憶
エージェントでは、何かを行う方法に関する知識。たとえば、エージェントがウェブ検索の方法の手続き記憶を開発し、上位 3 つのサイトを表示する場合があります。
R
reason
エージェントが何を行うかを決定するエージェント ループのステージ。たとえば、特定 API リクエストを送信する必要があると判断する場合があります。
reflection
ステップの出力を次のステップに渡す前に、その出力を検証（反映）することで、エージェント ワークフローの品質を向上させる戦略。
多くの場合、審査員は回答を生成したのと同じ LLM です（別の LLM の場合もあります）。回答を生成した LLM が、その回答を公平に判断できるのでしょうか？「コツ」は、LLM を批判的（反射的）な考え方にすることです。このプロセスは、クリエイティブな考え方で下書きを作成し、批判的な考え方で編集するライターに似ています。
たとえば、コーヒー マグカップのテキストを作成するエージェント ワークフローを考えてみましょう。このステップのプロンプトは次のようになります。
あなたはクリエイターです。コーヒー マグカップに適した、50 文字未満のユーモラスでオリジナルのテキストを生成します。
次の内省的なプロンプトを考えてみましょう。
あなたはコーヒーを飲む人です。上記の回答はユーモラスだと思いますか？
ワークフローでは、高い反射スコアを受け取ったテキストのみを次のステージに渡すことができます。
ルーター エージェント
ユーザー クエリを分類し、最も適切なエージェントを呼び出して処理するエージェント。
S
自己修正
エージェントが自身の出力のエラーを検出し、別のアプローチを試す能力。
state
強化学習では、エージェントがアクションを選択するために使用する、環境の現在の構成を表すパラメータ値。
状態マシン エージェント
厳格なルールによってワークフローが制約されているエージェント。一般に、ステート マシン エージェントは自律エージェントよりもミスが少ないですが、制約外の状況に適応する自由度がありません。
サブエージェント
マネージャー エージェントによって呼び出され、より大きな問題の特定のサブセットを処理する、狭い範囲に焦点を当てた特殊なモデル。通常、サブエージェントはエージェントよりもアクション空間が狭くなります。
T
終了条件
エージェント AI では、エージェントに反復処理の停止を指示する事前定義の条件。たとえば、次のような終了条件が考えられます。
- エージェントが目標を達成しました。
- エージェントがリソースを使い果たした。
- human-in-the-loopで問題が検出されました。
強化学習では、エージェントが特定の状態に達したときや、状態遷移のしきい値を超えたときなど、エピソードの終了条件を決定します。たとえば、三目並べでは、プレイヤーが 3 つの連続したスペースをマークしたとき、またはすべてのスペースがマークされたときにエピソードが終了します。