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

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

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• 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)
  • 13 (2025-09-13 (土) 22:25:48)
  • 14 (2025-10-03 (金) 13:14:50)
  • 15 (2025-10-08 (水) 14:52:00)
  • 16 (2025-12-15 (月) 14:21:24)
  • 17 (2025-12-16 (火) 02:23:45)
  • 18 (2025-12-16 (火) 10:37:29)
  • 19 (2026-01-01 (木) 15:56:48)
  • 20 (2026-01-04 (日) 02:41:07)
  • 21 (2026-01-04 (日) 13:59:48)
  • 22 (2026-01-04 (日) 15:34:53)
  • 23 (2026-01-04 (日) 18:39:51)
  • 24 (2026-01-05 (月) 01:20:08)
  • 25 (2026-01-06 (火) 13:24:55)

---

「.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は環境から情報を受け取りつつ繰り返し行動できる。
  • 大きな柔軟性：より複雑で広範な問題を扱える。
  • 予測不可能性：パス（時間、コスト）、出力（品質）が予測できない。
  • 対策として、モニタリングやガードレールを実装

エージェントの †

開発スタイル †

AIエージェントをどう作るか？

※ 上から下に、プリミティブ → ハイ・レベル。

パーソナライズ †

AIエージェントの業務特化性能（現場適応レベル）

※ Human-x-theLoop とは、業務特化型AI（現場適応型AI）において、人間（Human）がAIの自律的成長（theLoop）に、どの程度（x）介入（監督・判断）するかを表す。
※ フレームワークで実装したエージェントは、レベル2〜3を確実に実現し、レベル4の一部にも到達するが、プロダクションや企業の業務での導入はまだこれからとされている。

例と工夫 †

以下の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

詳細 †

構成要素 †

LLMエージェントは通常、以下のような構成要素を持つ

LLM本体 †

自然言語の理解・生成を担当する中核部分。タスクの実行や推論を行う。

メモリ †

• 会話履歴やタスクの進行状況などを保持。
• VDBやRDBを使用した長期的な記憶も可能。

ツール / プラグイン †

• Web検索、計算、コード実行、API呼び出しなど、外部リソースと連携して作業を遂行。
• Function callingやMCP、ACP、A2Aなどを使用できる。

コントローラー †

• プランナーとLLMのやりとりを制御。ループを回す。
• 別のエージェントに切り出せるが、単一エージェントのツールとしても実装できる。

プランナー †

• ゴールに向けタスクを分割し、順序立てて実行計画を作る。
• 別のエージェントに切り出せるが、単一エージェントのツールとしても実装できる。

アクション実行器 †

• LLMの計画した出力に従って具体的なアクションを実行するモジュール。
• 別のエージェントに切り出せるが、単一エージェントのツールとしても実装できる。

思考ループ（Reasoning Loop） †

• 多くのLLMエージェントは以下のような思考ループ（Reasoning Loop）で動作している。
• 与えられたインストラクションから以下のステップで動作するように設計・実装されている。
• 実装によって名称や粒度は異なるが、概念的にはほぼ同じ構造で動いている。

タスクの理解（Goal Recognition） †

ユーザーから与えられた指示や問いを分析し、何を達成すべきかを明確にする。

• 自然言語で書かれた曖昧な指示から「最終的な目的」を推測する能力が求められる。
• LLMエージェントは、文脈や過去の対話履歴も考慮して目的を解釈する。

プランの生成（Plan） †

目的を達成するための一連の手順や方針（プラン）を考案する。

• Web検索が必要 → 検索 → 情報要約 → 回答生成、のようなステップ分割。
• 単純なプランではタスク分割、複雑なプランには外部ツール（計算機、検索エンジン等）との連携も含まれる。

次のアクションの選択（Reason） †

• プランに基づき、今の状況において最も適切な次のアクションを選ぶ。
• 「今なにをするべきか？」という意思決定プロセスであり、状況に応じた柔軟な判断が求められる。
• ここでは推論（Reasoning）能力が重要となる。

アクションの実行（Act） †

• 選択したアクションを実行する。
• 実行対象は、ツールの呼び出し、情報取得、外部APIへのアクセス、またはユーザーへの返答など。
• 実行結果は次のステップに活かされる。

観測と反省（Reflect） †

• アクションの結果を観察し、目的に近づいたか、想定とずれがないかを評価する。
• 不十分な結果が出た場合は原因を考え、改善点を洗い出す。
• エージェントが「何がうまくいかなかったか」を自己評価する重要な段階。

再計画（Replan） †

• 反省の結果に基づき、プランの修正・更新を行う。
• 新たな情報や環境の変化に応じて、アクションの優先順位や順序を再構築する。

• その後、再び次のアクションの選択へとループが戻る。
  • 上記のステップを繰り返しながら、最終的な目標達成を目指す。
  • このループは、ユーザーが満足する結果を得るまで、あるいは明示的な停止条件が満たされるまで続く。
  • このような思考ループは、自律エージェントにおいて特に重要な「目的志向の行動」が可能となる基盤。

推論・行動戦略 †

推論・行動戦略（Reasoning & Acting Paradigms）」に関する代表的アプローチ

• 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でも利用可能とのこと。

デファクト標準 †

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?などと連携）

団体 †

• OpenAI
  Open Agents、Function calling APIの提案

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

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

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

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

プロトコル †

プロトコル †

MCP（Model Context Protocol） †

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

ACP（Agent Communication Protocol） †

• AIモデルと外部エージェントのやりとりを標準化するオープン・プロトコル
• 将来的に A2A に“統合される／継承される”方向。

A2A（Agent2Agent Protocol） †

• 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

     

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.076 sec.