LLMエージェント のバックアップ(No.12)

[ トップ ]   [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• LLMエージェント へ行く。
  • 1 (2025-07-09 (水) 10:51:14)
  • 2 (2025-07-09 (水) 10:57:13)
  • 3 (2025-07-10 (木) 12:30:01)
  • 4 (2025-08-15 (金) 16:12:08)
  • 5 (2025-08-22 (金) 17:44:41)
  • 6 (2025-08-25 (月) 23:17:40)
  • 7 (2025-08-26 (火) 18:09:47)
  • 8 (2025-08-26 (火) 18:52:10)
  • 9 (2025-09-04 (木) 17:55:32)
  • 10 (2025-09-10 (水) 08:38:11)
  • 11 (2025-09-10 (水) 12:09:24)
  • 12 (2025-09-13 (土) 18:42:25)

---

「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

• 戻る > チューニング、拡張系
  • LLMのPE
  • LLMのRAG
  • LLMのFT
  • LLMエージェント

目次 †

概要 †

• 情報の収集・解析・意思決定・アクション実行を行うシステム

• あるサーベイ論文では、AIエージェントを「脳」「知覚」「アクション」という3つの要素で整理。
  入力を「知覚」し「アクション」を計画的に実行する「脳」としてAIが機能することで、タスクを代行する。

• LLMエージェントについて「タスクを代行するもの」であるとして、最も原始的な実装であれば
  • 入力に対応したワークフローを代行するようなものでも、エージェントと呼ぶことはできる。
  • ただし、単一の呼び出しや、都度アドホック・プロンプト入力が必要なChatはエージェントとは呼べない。

詳細 †

エージェントの定義 †

エージェントらしさ †

最近の、LLMエージェント研究や実装では、次の要素が増えるほど「エージェントっぽい」とされる（≒ 自律性）。

• LLMでタスク分解（大きな問題を理解し、個々の実行ステップに分割）
• LLMでアクションの選択・実行（ツール利用、Function calling、構造化出力）
• 状態管理（メモリや履歴を使って文脈を保持）
• LLMで自己評価・再試行（出力が不十分なら修正を試みる）
• エージェントが協働できるエージェント環境

デザインパターン †

Anthropic社が提示するデザインパターンが適用されている。

• ワークフローを持つエージェント・システムの5つのデザインパターン
  • プロンプト・チェイニング：固定された一連のサブタスクに分解し、LLM呼び出しを連鎖させる方式
  • ルーティング：LLMが入力を分類し、専門性の異なる複数のLLMの中から最適なものを選択
  • パラレライゼーション：「コードが」タスクを複数に分割し、複数のLLMで同時処理、結果を束ねる。
  • オーケストレーター・ワーカー：「LLMが」複雑なタスクを複数に分割し、複数のLLMで同時処理、結果を束ねる。
  • エバリュエーター・オプティマイザー：生成LLM と 評価LLM の二段構えのフィードバックループ

• ワークフローの対局、オープンエンド型のエージェントデザインパターン
  • 固定パスがない：一連のステップに従うのではなく、動的で流動的。
  • 継続可能でフィードバックループがある：LLMは環境から情報を受け取りつつ繰り返し行動できる。
  • 大きな柔軟性：より複雑で広範な問題を扱える。
  • 予測不可能性：パス（時間、コスト）、出力（品質）が予測できない。
  • 対策として、モニタリングやガードレールを実装

構成要素 †

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 †

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

• 核となるアイデアは「プランナー」と「実行」のエージェント
• https://github.com/assafelovic/gpt-researcher

シミュレーション †

Generative Agents

• 25人のAIエージェントを仮想的な街で生活させるシミュレーション
• Memoryの工夫が有名、最新性・重要性・関係性のあるものを検索して使用
• https://github.com/joonspk-research/generative_agents

ゲーム †

• Voyager
  • できるだけ多様な発見をすることを最終目標として行動するMinecraftを自動プレイするAIエージェント
  • Minecraftのクライアントライブラリ (JavaScript)を使った「スキル」を生成して使用

• PokéLLMon
  • 過去のターンのフィードバックやポケモンの技などの外部知識をプロンプトに含めることで、不利な選択をしないように制御
  • 相手が強力なポケモンだとパニック状態になってポケモンの入れ替えを繰り返すのを防ぐよう、Self-Consistency (自己整合性) プロンプティングを使用

ソフトウェア開発 †

• GPT-Engineer
  • 自動でプログラムを実装するという分野で話題になったエージェント
  • 「こういう機能を開発して」と記述しておくと、自動でプログラムを実装してくれる
  • https://github.com/gpt-engineer-org/gpt-engineer
  • https://apt-engineer.readthedocs.io/en/latest/index.html

• ChatDev?
  • プログラマー・テスター・デザイナーなど、様々な役割のAIエージェントに共同作業させて、自動でソフトウェアを開発させる

汎用のコンピュータ操作 †

• Open Interpreter
  • 自然言語の指示でコンピュータを操作するツール
  • https://github.com/KillianLucas/open-interpreter/

• OS-Copilot
  • OSの操作を提供するエージェント
  • https://github.com/OS-Copilot/FRIDAY

標準化・プロトコル †

対象 †

• Function calling API
  ツール/関数をLLMに呼ばせる標準仕様（OpenAIやAnthropicなどが実装）

• Tool Registry / Metadata
  ツールや機能の定義情報（引数、用途など）を共有するためのスキーマ

• Agent-to-Agent Protocols
  複数エージェントがやり取りする際の通信仕様（メッセージ構造や状態管理）

• Observability
  エージェントの動作トレース、ログ記録の標準フォーマット（OpenTelemetry?などと連携）

団体 †

• OpenAI
  Open Agents、function calling APIの提案

• LangChain
  LangGraph、LangServe?で標準的な構成提供

• Anthropic, Google, Meta
  独自API提供＋相互運用性の議論に参加（例: AI Alliance）

• W3C / ISOなど
  将来的な正式標準化の議論も一部で始動

• Agent Protocol Community
  自主的なコミュニティ駆動の標準仕様作成

Function calling †

LLMに特定のAPIや関数を呼び出させ外部タスクを実行する仕組み。

• LLMが何をどう呼び出すかを自動的に決定
• LLMが自然言語から適切な関数名と引数を構造化出力（JSON）。
• 関数をLLMに「使わせる」ことで、外部のツール・APIと接続可
• 高精度なツール選択と使い分けが可能

MCP（Model Context Protocol） †

• AIモデルと外部システムのやりとりを標準化するオープンプロトコル

• MCP が注目される理由は
  • 入り口に過ぎない「単純なローカルツール統合以上」の将来性を期待されている。
  • 将来 SaaS クライアントが MCP サーバーとして公式対応する世界を見据えている。
  • 関心の本丸はSaaS「法人向けの重量級機能」の利用「統一的なアクセスポイント化」にある。

• ホストがクライアントとサーバーを使用して実装
  • ホスト：アプリケーション、クライアントを通じて外部データやツールにアクセス。
  • クライアント：サーバとの接続を確立し、リソース、ツール、プロンプトなどの機能を利用するためのリクエストを送信
  • サーバー：クライアントからのリクエストを処理し、必要なデータ（データソース）や機能（ツール）を提供へのアクセスを提供

• MCPでなければ実現しづらいこと

• シンプルさ、低レイテンシ、依存最小を優先する小規模・短期の用途なら、requests を直接ツール化する方法が手軽。

• セキュリティ分離、標準化、運用・監査・ガバナンス、再利用性を重視するなら MCP 経由の fetch が適している。

• プロセス分離
  ・最小権限・責務分離、ポリシー一元適用がし易い。
  ・シークレットをMCP 側に閉じ込めることでLLMからの漏洩を防止できる。

• 標準化・相互運用性
  ・ツールの発見、スキーマ、エラー、リソース等のやり取りがプロトコルで標準化されている。
  ・モデルやランタイムが変わっても同じ MCP ツールを再利用し易い（多言語・多環境での再利用）。

• 運用・ガバナンス
  ・ツールは独立したサーバとしてデプロイ・バージョン管理でき、
  ・ローテーションやロールバック、レート制限、監査ログの集約が容易。
  ・組織のネットワーク制御や DLP と統合しやすい（同様にサーバ側で統制）。

• 可観測性・監査
  ・ツール呼び出しのログやメトリクスが明確な境界で記録・計測される。
  ・拡張性・機能発見 ツールが自己記述的に機能や引数スキーマを公開するため、エージェントが動的に能力を発見し易い。

• MCPをサポートするプロダクト
  • OpenAI Agents SDKにMCP（Model Context Protocol）が統合された
  • LangFlowは、ホスト/クライアント/サーバーをサポートする。
  • MCPクライアントの機能を持つCursorは、LangflowのMCPサーバ機能と連携する項の説明で取り上げられている。
  • Autogen などのエージェント・フレームワークもMCPの機能を持つらしい。
  • 他のフレームワークでもMCPクライアント/サーバがサポートされるものと思われる。

ACP（Agent Communication Protocol） †

マルチエージェントで、エージェント同士（またはエージェント⇔人間⇔ツール）の通信インタフェースや意味論を標準化するプロトコル。

• RESTベースの通信：シンプルで明確なRESTエンドポイントを使用し、標準的なHTTPパターンに沿った通信を実現。
• 非同期通信の優先：長時間のタスク処理に適した非同期通信を主にサポートし、同期通信も可能。
• セキュリティ：能力ベースのセキュリティモデルを採用、リソース、操作、期限をエンコードしたトークンを使用。

マルチエージェント †

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 †

OpenAIによって2024年夏に発表された新SDK

• Function Callingの進化系で、LLMがタスクに応じて自動的にツール呼び出し・ワークフロー制御を行う。
• MCP (Model Context Protocol) をベースに、エージェントと外部ツール・データソースを標準化して接続できる。
• 「公式エコシステム標準」になりやすく、今後のOpenAI製品と高い互換性を持つ。
• ツール連携の標準化、公式GPTsの外部拡張、社内アプリなど実用的なエージェント開発、

CrewAI †

「複数エージェントが協力してプロジェクトを進める」チーム型エージェント

• LLMに加えて、人間をチームメンバーに組み込むことも可能。
• リサーチ・記事執筆・コード開発など「分業タスク」に強い。

LangGraph †

• LangChainベースの実装で、エージェント処理を「状態遷移グラフ」として構築する。
• LangChainのチェーン型と比べてワークフロー型（エージェントを状態遷移グラフ（workflow graph）として設計）
• 循環処理、条件分岐、中断と再開を扱い易く「再現性のあるエージェント実行」が強み。

AutoGen †

• マルチ・エージェント・フレームワークの先駆けで、複数のエージェント（LLM・人間・ツール）を会話で協調させる。
• CrewAIの思想に似ているが、「会話のやり取りを通じて計画・分担・実行」を行う仕組みは、より研究・プロトタイプ寄り。。

参考 †

https://speakerdeck.com/os1ma/imakosoxue-bullmbesunoaiezientoru-men-ji-ben-de-nasikumi-slash-kai-fa-turu-slash-you-ming-naossyalun-wen-noshao-jie

     

Site admin: TechInfoOfMicrosoftTech

PukiWiki 1.4.7 Copyright © 2001-2006 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji. Powered by PHP 5.3.3. HTML convert time: 0.059 sec.