「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
- 情報の収集・解析・意思決定・アクション実行を行うシステム
- あるサーベイ論文では、AIエージェントを「脳」「知覚」「アクション」という3つの要素で整理。
入力を「知覚」し「アクション」を計画的に実行する「脳」としてAIが機能することで、タスクを代行する。
- LLMエージェントについて「タスクを代行するもの」であるとして、最も原始的な実装であれば
- 入力に対応したワークフローを代行するようなものでも、エージェントと呼ぶことはできる。
- ただし、単一の呼び出しや、都度アドホック・プロンプト入力が必要なChatはエージェントとは呼べない。
エージェントの定義 †
エージェントらしさ †
最近の、LLMエージェント研究や実装では、次の要素が増えるほど「エージェントっぽい」とされる（≒ 自律性）。
デザインパターン †
Anthropic社が提示するデザインパターンが適用されている。
- ワークフロー型エージェント
ワークフローを持つエージェント・システムの5つのデザインパターン
- プロンプト・チェイニング：固定された一連のサブタスクに分解し、LLM呼び出しを連鎖させる方式
- ルーティング：LLMが入力を分類し、専門性の異なる複数のLLMの中から最適なものを選択
- パラレライゼーション：「コードが」タスクを複数に分割し、複数のLLMで同時処理、結果を束ねる。
- オーケストレーター・ワーカー：「LLMが」複雑なタスクを複数に分割し、複数のLLMで同時処理、結果を束ねる。
- エバリュエーター・オプティマイザー：生成LLM と 評価LLM の二段構えのフィードバックループ
- オープンエンド型エージェント
ワークフローの対極、オープンエンド型のエージェントデザインパターン
- 固定パスがない：一連のステップに従うのではなく、動的で流動的。
- 継続可能でフィードバックループがある：LLMは環境から情報を受け取りつつ繰り返し行動できる。
- 大きな柔軟性：より複雑で広範な問題を扱える。
- 予測不可能性：パス（時間、コスト）、出力（品質）が予測できない。
- 対策として、モニタリングやガードレールを実装
エージェントの †
開発スタイル †
AIエージェントをどう作るか？
| タイプ | 特徴 | 代表的なツール／例 |
| コーディング型 | LangGraph等のライブラリやPythonなどのプログラミング言語を用いてエージェントを実装する。柔軟性が高く、細かな制御やカスタマイズが可能。 | LangGraph、LangChain、OpenAI Agents SDK等 |
| ローコード・ワークフロー型 | GUIやノーコード環境で複数のアクションをつなぎ、チャットフローやツール呼び出しを組み立てる。業務担当者でも扱いやすいが、複雑なロジックは実装しにくい。 | Dify、n8nなど |
| プロンプト・エンジニアリング型 | MS Copilot Studioのようなツールでプロンプトやルールを記述し、LLMが内部的にエージェントを組み立てる。素早く試作できるが、動作のブラックボックス化に注意。 | MS Copilot Studio、LibreChat?、Watsonx Orchestrator |
※ 上から下に、プリミティブ → ハイ・レベル。
パーソナライズ †
AIエージェントの業務特化性能（現場適応レベル）
| レベル | 概要 | 対応ツール・技術 |
| Human-in-theLoop | １ | 人の詳細な指示と知識DBからの情報を生成AIに入力し、その結果出力して要求に対応 | RAG+LangGraph等 |
| ２ | 事前に人が定義した計画(フロー)に即して生成AIや知識DB、ツール等活用し要求に対応 | Dify等、AIエージェント開発ツール上で作成 |
| Human-on-theLoop | ３ | 要求理解・計画立案・行動/ツール活用にも生成AIを活用し、自律的に要求に対応 | Agent Creator等、ユーザの要求からAgentを作成 |
| ４ | レベル3に加え、利用者に応じたパーソナライズした要求理解や要求対応を実施 | Text-to-LoRA等、コンテキストを踏まえた回答生成容易化 |
| Human-out-of-theLoop | ５ | レベル4に加え、継続的な自己改善の能力を持ち、成長し続けることが可能 | Agentの外部・内部の振舞いの可視化を通じた自己改善 |
※ Human-x-theLoop とは、業務特化型AI（現場適応型AI）において、人間（Human）がAIの自律的成長（Loop）に、どの程度（x）介入（監督・判断）するかを表す。
詳細 †
構成要素 †
LLMエージェントは通常、以下のような構成要素を持ちます：
LLM本体 †
自然言語の理解・生成を担当する中核部分。タスクの実行や推論を行う。
メモリ †
会話履歴やタスクの進行状況などを保持。長期的な記憶も可能。
ツール / プラグイン †
Web検索、計算、コード実行、API呼び出しなど、外部リソースと連携して作業を遂行。
コントローラー †
プランナーとLLMのやりとりを制御。ループを回す。
プランナー †
ゴールに向けタスクを分割し、順序立てて実行計画を作る。
アクション実行器 †
LLMの計画した出力に従って具体的なアクションを実行するモジュール。
思考ループ（Reasoning Loop） †
多くのLLMエージェントは以下のようなエージェント・ループで動作
タスクの理解（Goal Recognition） †
ユーザーから与えられた指示や問いを分析し、何を達成すべきかを明確にする。
- 自然言語で書かれた曖昧な指示から「最終的な目的」を推測する能力が求められる。
- LLMエージェントは、文脈や過去の対話履歴も考慮して目的を解釈する。
プランの生成（Plan） †
目的を達成するための一連の手順や方針（プラン）を考案する。
- Web検索が必要 → 検索 → 情報要約 → 回答生成、のようなステップ分割。
- 単純なプランではタスク分割、複雑なプランには外部ツール（計算機、検索エンジン等）との連携も含まれる。
次のアクションの選択（Reason） †
- プランに基づき、今の状況において最も適切な次のアクションを選ぶ。
- 「今なにをするべきか？」という意思決定プロセスであり、状況に応じた柔軟な判断が求められる。
- ここでは推論（Reasoning）能力が重要となる。
アクションの実行（Act） †
- 選択したアクションを実行する。
- 実行対象は、ツールの呼び出し、情報取得、外部APIへのアクセス、またはユーザーへの返答など。
- 実行結果は次のステップに活かされる。
観測と反省（Reflect） †
- アクションの結果を観察し、目的に近づいたか、想定とずれがないかを評価する。
- 不十分な結果が出た場合は原因を考え、改善点を洗い出す。
- エージェントが「何がうまくいかなかったか」を自己評価する重要な段階。
再計画（Replan） †
- 反省の結果に基づき、プランの修正・更新を行う。
- 新たな情報や環境の変化に応じて、アクションの優先順位や順序を再構築する。
- その後、再び次のアクションの選択へとループが戻る。
- 上記のステップを繰り返しながら、最終的な目標達成を目指す。
- このループは、ユーザーが満足する結果を得るまで、あるいは明示的な停止条件が満たされるまで続く。
- このような思考ループは、自律エージェントにおいて特に重要な「目的志向の行動」が可能となる基盤。
応用研究 †
- LLMベースのAIエージェントの5つの実装方法
- 「ReAct?」が有名だが他にも多くの手法がある。
MRKL †
MRKL（Modular Reasoning, Knowledge and Language）
- 概要：AIエージェントが複数のツールを統合的に使うためのモジュラー・アーキテクチャ。
- 特徴：モデルが入力を解析し、適切なツールにタスクを振り分けて実行。LLMは「どのツールを使うべきか」を推論する役割。
- MRKLは、OpenAIの論文「ReAct?: Synergizing Reasoning and Acting in Language Models」などでも言及されている。
ReAct?（Reasoning + Acting）
- 概要：思考（Reasoning）と行動（Acting）を交互に繰り返すことで、LLMがより柔軟かつ強力な問題解決を行うフレームワーク。
- 特徴：推論と行動を逐次的に交互に行う。例：検索 → 仮説立て → 電卓使用 → 結論。
- 論文：Yao et al., 2022（例：「Let's think step by step」のようなプロンプト技法を拡張）
- エージェントはActだけでも実装できるが、Reason（思考過程を言語化）してからAct（実行内容を言語化）させる「ReAct?」の精度がよかったという論文
- Reasonなし・Actなし
- Reasonあり・Actなし (CoT)
- Reasonなし・Actあり (WebGPTのようなもの)
- Reasonあり・Actあり (ReAct?)
Plan-and-Solve †
- 概要：問題を解く前に、まず全体の計画（Plan）を立て、それに従ってステップごとに解決するプロンプト設計手法。
- 特徴：「まず計画を立ててから解く」→ 思考の整理ができ、正確な回答率が上がる。CoTのような技法と組み合わせて使用される。
LLMCompiler †
- 概要：タスクの自然言語仕様をプログラム的な実行計画やコードに「コンパイル」するLLMベースの手法。
- 特徴：LLMが自然言語からタスクグラフや関数構成などを生成。プログラムのような表現を通じて複雑なタスクを実行可能にする。
- 応用：マルチステップの意思決定やエージェントプランニングなど。
※ LlamalndexやLangGraphでも利用可能とのこと。
例と工夫 †
以下の5つの分野の有名なAIエージェントとその工夫
リサーチ †
GPT Researcher
シミュレーション †
Generative Agents
ゲーム †
- Voyager
- できるだけ多様な発見をすることを最終目標として行動するMinecraftを自動プレイするAIエージェント
- Minecraftのクライアントライブラリ (JavaScript)を使った「スキル」を生成して使用
- PokéLLMon
- 過去のターンのフィードバックやポケモンの技などの外部知識をプロンプトに含めることで、不利な選択をしないように制御
- 相手が強力なポケモンだとパニック状態になってポケモンの入れ替えを繰り返すのを防ぐよう、Self-Consistency (自己整合性) プロンプティングを使用
ソフトウェア開発 †
- ChatDev?
- プログラマー・テスター・デザイナーなど、様々な役割のAIエージェントに共同作業させて、自動でソフトウェアを開発させる
汎用のコンピュータ操作 †
規約 †
Function calling †
- LLMに特定のAPIや関数を呼び出させ外部タスクを実行する仕組み。
- OpenAI Function calling
- Anthropic tool use
- Gemini tool calling
- LLMが自然言語から適切な関数名と引数を構造化出力（JSON）。
- 関数をLLMに使わせる事で、外部のツール・APIと接続可
- 高精度なツール選択と使い分けが可能
Structured Outputs †
- LLMの出力形式を厳密な構造（JSON等）に制約する仕組み。
- OpenAI Structured Outputs
- JSON Schema
- Pydantic model
- 事前定義したスキーマ（型・必須項目・制約）に適合させて出力させる。
- 出力の型安全性・検証可能性が高く、後段処理（パース・保存・検証）が安定。
- 関数実行を伴わず、データ抽出・要約・分類・設定生成などに適する。
... †
標準化 †
対象 †
- Tool Registry / Metadata
ツールや機能の定義情報（引数、用途など）を共有するためのスキーマ
- Agent-to-Agent Protocols
複数エージェントがやり取りする際の通信仕様（メッセージ構造や状態管理）
- Observability
エージェントの動作トレース、ログ記録の標準フォーマット（OpenTelemetry?などと連携）
団体 †
- Anthropic, Google, Meta
独自API提供＋相互運用性の議論に参加（例: AI Alliance）
- W3C / ISOなど
将来的な正式標準化の議論も一部で始動
- Agent Protocol Community
自主的なコミュニティ駆動の標準仕様作成
プロトコル †
AIモデルと外部システムのやりとりを標準化するオープン・プロトコル
- AIモデルと外部エージェントのやりとりを標準化するオープン・プロトコル
- 将来的に A2A に“統合される／継承される”方向。
- AIモデルと外部エージェントのやりとりを標準化するオープン・プロトコル
- ACPより上位の次世代標準だが実装複雑性/パフォーマンスでは劣る。
マルチエージェント †
LLMマルチエージェントは、LLMを用いた複数のエージェントが連携・協調・競合しながらタスクを遂行するシステムや枠組みのことを指す。
利用例 †
- ソフトウェア開発支援：プロジェクトの要件を受けて、複数のエージェントが設計、実装、レビュー、テストを分担。
- 複雑な意思決定支援：複数の視点から情報を収集・分析し、意見を統合して提案を生成。
- 教育やチュータリング：異なる学習スタイルや領域に対応した複数のエージェントが、個別に支援。
役割分担 †
各エージェントは専門性を持たせ、以下のような役割に分かれることが多い
- プランナー（Planner）：全体の戦略やステップを立案
- リサーチャー（Researcher）：外部情報を収集・分析
- エンジニア（Coder）：コードを生成・検証
- レビュワー（Reviewer）：他エージェントの出力を評価・改善提案
- メタ・エージェント：全体を制御する「指揮官」的エージェント（オーケストレーター、マネージャーなど）
PE技法 †
Self-Consistency, GKP, Self-Ask, ToT, AoTといったPEの推論促進技法の構造やアイデアを、明示的または暗黙的にシミュレーションしている。
- Self-Consistency（自己整合性）
- 関係性：マルチエージェントが独立に推論を行い、それらの出力から最も整合的なものを選ぶという点で一致。
- シミュレーション性：高い。各エージェントを一つの「自己実行のバリエーション」と見なすことで、Self-Consistencyの仕組みと同様の効果が得られる。
- GKP（Generated Knowledge Prompting）
- 関係性：あるエージェントが生成した知識を別のエージェントが利用するという点で、GKP的。
- シミュレーション性：中〜高。知識共有や知識ベースのプロンプティングが実装されていれば、かなり近い。
- Self-Ask
- 関係性：タスク分解や質問の生成→他エージェントに解決させるプロセスが、Self-Askの「質問して自分で答える」構造に似る。
- シミュレーション性：高。特に質問応答・サブタスク分担型のマルチエージェントシステムでは、Self-Askに近い設計になる。
- ToT（Tree of Thoughts）
- 関係性：各エージェントが「思考の分岐」や「候補生成」に相当する役割を担うことで、ToTの木構造探索を模倣。
- シミュレーション性：中〜高。特に評価・選択メカニズムを持つマルチエージェント構成では、ToT的な探索が可能。
- AoT（Algorithm of Thoughts）
- 関係性：タスク解決を「アルゴリズム」として明示的に分解し、各部分をエージェントに割り当てることで、AoTに似た形になる。
- シミュレーション性：高。構造化された役割分担とステップ的な思考展開はAoTそのものに近い。
実装例 †
- Generative Agents
- 架空の町（例: Smallville）に複数のエージェントが暮らし、日常生活を送る。
- 各エージェントは「観察」「記憶」「計画」「行動」などのモジュールを持つ。
- GPT-4などのLLMで内面の思考・対話・行動を生成。
- ChatDev?：
- 開発プロセスを企業のようにモデル化（例: CEO、CTO、プログラマー、テスターなどの役割）。
- 各役職に対応するLLMエージェントが協調してコードを設計・実装・レビュー。
- 各フェーズでチャットを通じて議論・意思決定。
繋がり方 †
- 同期的チャット：エージェント同士がリアルタイムで交互に発言。
- 非同期メッセージパッシング：あるエージェントがメッセージを送信し、他のエージェントが後から反応。
- ブラックボードアーキテクチャ：共通の「知識ベース」や「ワークスペース」を全エージェントが読み書き。
- メモリ共有と再利用：各エージェントが記憶や知識を共有する仕組み。
- オーケストレーション（制御）：マスターエージェントやタスクマネージャが全体の進行を制御。
フレームワーク †
全体比較（要点）
| 観点 | OpenAI Agents SDK | CrewAI | LangGraph | AutoGen |
| 思想 | 制御・安全 | 人的分業 | 状態遷移 | 会話駆動 |
| 抽象度 | 低〜中 | 高 | 中 | 中 |
| 再現性 | 高 | 中 | 非常に高 | 低〜中 |
| 本番向き | ◎ | △ | ◎ | △ |
| 研究向き | △ | △ | ○ | ◎ |
参考 †
https://speakerdeck.com/os1ma/imakosoxue-bullmbesunoaiezientoru-men-ji-ben-de-nasikumi-slash-kai-fa-turu-slash-you-ming-naossyalun-wen-noshao-jie
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
