Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Weekly AI Agents News!

masatoto
March 09, 2025

Weekly AI Agents News!

2025年3月10日更新済み。次回3月24日更新予定
AI エージェントに関する論文かニュースをシンプルにまとめます。

X : @ottamm_190

masatoto

March 09, 2025
Tweet

More Decks by masatoto

Other Decks in Research

Transcript

  1. 論文 2/25~3/7まで 計画 • PlanGEN: A Multi-Agent Framework for Generating

    Planning and Reasoning Trajectories for Complex Problem Solving • Conversational Planning for Personal Plans 推論 • Code to Think, Think to Code: A Survey on Code-Enhanced Reasoning and Reasoning-Driven Code Intelligence in LLMs • The Relationship Between Reasoning and Performance in Large Language Models -- o3 (mini) Thinks Harder, Not Longer 学習 • Training a Generally Curious Agent • ATLAS: Agent Tuning via Learning Critical Steps 自己修正 • Multi-Agent Verification: Scaling Test-Time Compute with Multiple Verifiers ツール • ToolFuzz - Automated Agent Tool Testing • From Exploration to Mastery: Enabling LLMs to Master Tools via Self-Driven Interactions
  2. 論文 2/25~3/7まで 自己進化 • A Systematic Survey of Automatic Prompt

    Optimization Techniques • Automatic Prompt Optimization via Heuristic Search: A Survey メモリ • A Practical Memory Injection Attack against LLM Agents Agent Framework • FLOWAGENT: Achieving Compliance and Flexibility for Workflow Agents • AutoAgent: A Fully-Automated and Zero-Code Framework for LLM Agents Data Agents • METAL: A Multi-Agent Framework for Chart Generation with Test-Time Scaling Embodied Agents • Magma: A Foundation Model for Multimodal AI Agents Multi Agent Systems • Beyond Self-Talk: A Communication-Centric Survey of LLM-Based Multi-Agent Systems
  3. 計画の制約条件の抽出と検証を踏まえつつ、計画の難易度でアルゴリズムを変更する計画手法の提案 PlanGEN: A Multi-Agent Framework for Generating Planning and Reasoning

    Trajectories for Complex Problem Solving 既存の課題 • 問題文から求められる制約(日時や予算など)を自動抽出して検証に活用する仕組みが弱く、不完全なプラン がそのまま通ってしまう • 同じタスクでも問題の難易度は様々であり、すべての問題を1種類のアルゴリズムのみで解こうとすると性能が 頭打ちになりやすい 提案手法 制約抽出と検証・スコア付け、動的アルゴリズム選択を組み合わせる Constraint Agent(制約エージェント) • 問題文からインスタンス固有の制約(例:予算や日程,利用可能時間枠,数式の正当性条件など)を抜き出す • 抽出された制約は後段の検証に直接利用される Verification Agent(検証エージェント) • 生成されたプランをConstraint Agent が示した制約に照らして評価する • 違反箇所があれば指摘し、プラン全体に対して数値スコア(-100 から 100)を割り当てる • スコアが十分高い(例:95点以上)場合のみ「合格プラン」として採用する Selection Agent(選択エージェント) • インスタンスの難易度や過去の成功率に応じて,推論アルゴリズムを動的に選択する 3月10日 更新分 計画
  4. より「人間らしい」会話型AIに向け階層的計画の提案 Conversational Planning for Personal Plans 旅行計画や学習計画、健康管理など、ユーザが長期間にわたって達成したい目標をサポートするための「長期 的・階層的な会話型計画」の必要性に着目し、LLMを用いた階層的計画フレームワークを提案 1. ユーザが長期目標を提示

    例: 「旅行を計画したい」「子供に歴史上の発明家を教えたい」「クロスフィットを始めたい」など 2. メタ・コントローラがマクロアクションを決定 • 必要に応じてユーザに質問を投げ、追加の情報(スキルレベル・予算など)を聞き出す • 新たなステップを追加したり、既存のステップを修正したりする 3. サブポリシーが会話文やプランのステップを生成 • 各ステップは、ステップ名・詳細説明・推奨リソース検索用のキーワードなどを含む 4. ツール利用とコンテンツ返却 • 作成・修正されたステップに関連する外部リソース(動画・記事・書籍・サービス等)をツール呼び出しで検索し、LLM を使いランキングして提示 5. ユーザからの継続的なフィードバック • ユーザが回答・要望(例:「より予算を抑えた方法に変えたい」「もっと女性の発明家を知りたい」)を伝えると、計画 が再度調整される 計画 3月10日 更新分
  5. コードと推論が互いを高め合うという視点で、LLMの新しい可能性を体系的に整理したサーベイ Code to Think, Think to Code: A Survey on

    Code-Enhanced Reasoning and Reasoning-Driven Code Intelligence in LLMs コードが推論を強化 • コードは実行可能性や厳密な文法をもち、推論時の計算ミスやロジック崩壊を防ぎやすい • 例: 数学問題をコードとして生成し、実行結果で正確な答えを得る手法 (Program of Thoughts, PaL など) 推論がコーディング能力を発展 • 複雑なソフトウェア開発やリポジトリ全体の変更など、大規模かつ多段階のタスクをより的確に遂行できる • 例: 手順分割やエラー修正を自動で行うエージェント型ツール (CodeAgent, SWE-agent など) 対話的・反復的アプローチ • 実行結果をモデル自身が検証し、コードを段階的に修正する“自己デバッグ”や“自己改善”が精度向上に効果的 • 例: OpenCodeInterpreter, Self-Edit, Self-Debugging 課題 • 依然として解釈性・大規模リポジトリ対応・安全性・評価手法など未解決のテーマが多い • 長大な文脈や複数ファイルをまたいだコード理解・生成は難易度が高い 推論 3月10日 更新分
  6. 推論の長さと推論の深さのどちらが精度向上に寄与するのか The Relationship Between Reasoning and Performance in Large Language

    Models -- o3 (mini) Thinks Harder, Not Longer OpenAIのo1-mini, o3-mini (m), o3-mini (h) という異なるモデルを比較し、推論トークンの使用量と精度の関係 を体系的に分析する より優れたモデルは、長い推論チェーンを必要とするのか、それともより効果的に推論を行うのかを検証する 推論トークン数の増加は必ずしも精度向上をもたらさない • o3-mini (m) は o1-mini より高い精度を達成しているが、推論トークン数は増えていない → 効率的な推論を実行 • o3-mini (h) は o3-mini (m) より約4%向上したが、推論トークンを2倍以上使用 → 計算コストが増大 推論チェーンが長くなるほど精度は低下 • 全てのモデルで推論トークン数が増えるほど精度が低下 • しかし、この影響はo3-mini (m) や o3-mini (h) のような高性能モデルでは小さい 数学領域ごとの特徴 • 離散数学の問題では推論トークンの消費が多い • 微積分や代数学の問題は比較的少ない推論トークンで解答可能 • 難易度が高い問題ほど推論トークン数が増加 より優れたモデルは「深く考える」が「長く考えない」 • o3-mini (m) は、より少ないトークン数でより正確な回答を生成 • o3-mini (h) は、より多くのトークンを使用することで精度をわずかに向上 • モデルが賢くなるにつれ、「長く推論する」よりも「効率的に推論する」ことが精度向上の要因となる LLM の最適化には「単純に推論チェーンを長くする」のではなく、「推論の質を向上させる」ことが重要 推論 3月10日 更新分
  7. “探索・決定を要するタスク”を人工的に構築し、LLMを強化学習的に訓練する枠組みを提案 Training a Generally Curious Agent エージェントには情報を収集しながら行動を適切に選択する「探索能力」や、一連のやり取りを通じた「逐次的 な意思決定」が必要となる。こうした能力を鍛えるために現実の環境から大規模なインタラクション(行動履歴)を 集めることはコスト面・安全面から困難という課題があった。 提案手法

    1. タスクの設計 • 目標を達成するまで複数ターンで環境とやり取りするような多様なテキストベースのタスクを構築 2. 合成データ生成 • 既存のLLMから多彩な行動軌跡(エージェントの発話+環境からの応答)を作る • 各軌跡について成功度合い(例:最短手数で解けたか,解けなかったか)に基づき「好ましい軌跡」と「望ましくない軌 跡」をペアで用意する 3. 軌跡に対する選好学習 (Preference Learning) • 生成した軌跡ペアを用いてRPO (Reward Preference Optimization) を実施し、モデルを微調整する 4. カリキュラム学習 (Curriculum Learning) • モデルが解きやすいタスクから着実に成功軌跡を集めることで、学習効率を高める 結果 • 自己学習データのみで微調整した結果、探索戦略が大きく向上 • 解答の成功率や手数の短縮が大幅に改善された • 学習に含まれていない未見タスクに適用しても、探索的に情報を集めて成功率を高めるケースが多い 学習 3月10日 更新分
  8. エージェントチューニングの効率化と汎化性能向上を両立する ATLAS: Agent Tuning via Learning Critical Steps 既存のエージェントチューニング手法では専門家の行動軌跡全体を模倣する ATLASは、専門家の軌跡の中から重要なステップのみを識別し、それらに限定してLLMをファインチューニング

    する手法 GPT-4oをセレクタ(Selector)として使用し、以下の4つの基準に基づいて重要ステップを選択 • 計画策定(Plan Creation): サブゴールを作成するステップ • 重要観察(Critical Observation): 環境のキー情報を把握するステップ • 重要行動(Critical Action): 目標達成に大きく貢献する行動を実行するステップ • 自己修正(Self Correction): 過去の失敗を分析し戦略を調整するステップ 重要ステップのみでの学習により学習コストを削減 • 全軌跡の30%のみを使用してファインチューニングを実施 • 非重要ステップはモデルの入力として保持するが、損失計算には含めないことで過学習を防止 学習 3月10日 更新分
  9. エージェントの自動ツールテスト手法を提案 ToolFuzz - Automated Agent Tool Testing ツールのドキュメントが不完全であったり、誤って記述されていることが多い 従来手法では見逃される ツールのドキュメントの不備を特定

    できることを実証 1. ランタイムエラー検出 • Taint Fuzzer により、ツールが受け入れられない入力を探索する • LLMを活用し、ツールの仕様に適合した自然なユーザークエリを生成する • ツール実行時にエラーが発生した場合、そのクエリを「誤仕様の可能性がある入力」として記録する 2. 正確性エラー検出 • 同義語を用いたクエリの生成: LLMを用いて、同じ意図を持つが異なる表現のクエリを作成する • 入力・出力の一貫性チェック: 生成したクエリを用いてツールを呼び出し、出力が一貫しているか検証する • LLM Oracle(評価モデル): ツールの出力と期待される出力を比較し、回答の正確性を判定する ツール 3月10日 更新分
  10. LLMがツール利用ドキュメントを最適化するフレームワークを提案 From Exploration to Mastery: Enabling LLMs to Master Tools

    via Self-Driven Interactions LLM自身の試行錯誤によりツールドキュメントを動的に最適化し、ツール使用能力を向上させる手法を開発 提案手法 1. 経験収集(Experience Gathering) 1. LLMが外部ツールを使用し、探索的なインタラクションを通じてツールの挙動を観察する 2. 生成されたクエリとツールの応答を記録 2. 経験からの学習(Learning from Experience) 1. 収集されたデータを分析し、ツールドキュメントのどこに問題があるかを検出 2. 例えば、「ドキュメントに記載されていないパラメータが存在する」「エラーハンドリングの説明が不足している」と いった点を特定 3. ドキュメントの改良(Documentation Rewriting) 1. 上記の分析結果をもとに、ドキュメントをより正確で簡潔なものへと自動的に更新 2. 次の探索に向けた方向性も決定 ツール 3月10日 更新分
  11. テスト時に検証器を増やすことで精度は向上し続けるのか Multi-Agent Verification: Scaling Test-Time Compute with Multiple Verifiers 「推論時に追加計算を行う」ことで精度を高める方法のうち「検証器(verifier)の数を増やす」ことを提案

    Aspect Verifier (AV) という「学習不要で簡単に作れる検証器」を提案 「数学的正しさをイエス/ノーで判定する」「解答が事実と整合しているかをイエス/ノーで判定する」などの特 定の観点(aspect)に特化してプロンプト設計する アルゴリズム • Generator LLM から n 個の候補解答をサンプリング • m 個のAspect Verifier それぞれに True/False を出させる • True の数が最大の候補解答を最終的に選択 回答候補が増えるほど、検証器の数が増えるほど精度が向上することを確認している(検証器の質に依存) 自己修正 3月10日 更新分
  12. 自動プロンプト最適化(APO: Automatic Prompt Optimization)の研究が活発化 A Systematic Survey of Automatic Prompt

    Optimization Techniques 1. 種プロンプトの初期化 • 手動で書いた初期プロンプトを使う手法と、LLMに「命令文を生成して」と依頼して得た種プロンプトを利用する手法がある 2. 評価とフィードバック • 最適化中のプロンプトがどれほど良いかを定量的に評価する工程 • 「タスクの正解率」「生成文のスコア」「LLM自体に反省や批評をさせるフィードバック」などがある • 人手による好み・安全性・スタイル評価を組み合わせる手法も存在 3. プロンプト候補の生成 • 既存のプロンプトを少しずつ書き換える「ヒューリスティックなトークン編集」から、「遺伝的アルゴリズム」、「LLMを 使った編集」「強化学習」など多種多様 • 「メタプロンプト」と呼ばれる、プロンプトそのものを書き直すための専用プロンプトを設計する手法もある 4. 候補の選別 • 生成された複数の候補プロンプトをタスクデータで評価し、良好なものを次のステップへ残す • トップKの正答率が高いものを残す貪欲法、UCBによるバンディット探索などがある • 大規模タスクやマルチタスクの場合、Mixture-of-Expertsな方法もある 5. 反復回数・停止条件 • あらかじめ決めた回数だけ反復する固定ステップか、収束が見られたら停止する可変ステップかに大別 • 一部手法では、性能がしばらく向上しない場合に探索を打ち切る“早期終了”を用いる 自己進化 3月10日 更新分
  13. プロンプト最適化手法のサーベイ Automatic Prompt Optimization via Heuristic Search: A Survey 1.

    どの空間で最適化をするか 1. ソフトプロンプト空間:プロンプトをベクトルの形で扱い、勾配に基づいて最適化する 2. 離散プロンプト空間:プロンプトをそのままテキスト列として扱い、置換や追加・削除などのテキスト操作で最適化する 2. 何を最適化するか 1. Instruction-only:指示文(タスクの説明部分)のみを最適化 2. Instruction & Example:指示文に加え、いくつかの入出力例(Few-Shotの例示)の最適な組み合わせまで含めて同時に最適化 3. Instruction & Optional Example:必要に応じて例示を加える/加えないも含めて最適化 3. どういう指標を最大化/最小化するか 1. タスク性能(精度、再現率、F値など) 2. 安全性・倫理性(有害出力や差別表現の回避) 3. 汎化性能、マルチ目的最適化(性能と安全性を同時に高めるなど) 4. どのような手法でプロンプトを修正するか 1. Zero-Parent(親なし):LLM自体やベイズ的アプローチなどを活用して、まったく新しい候補プロンプトを生成する 2. Single-Parent(親1つ):既存の1つのプロンプト候補をもとに、LLMで言い回しを変える、特定の単語を置換・追加などして新候補を作る 3. Multiple-Parent(親複数):2つ以上の既存プロンプトを組み合わせたり、差分を取ったり、交叉する 5. 探索アルゴリズムは何を使うか 1. バンディットアルゴリズム:候補群の中から「最も良いかもしれない」ものを選びつつ、未知の候補も少し試して最適化する 2. ビームサーチ:多くの候補を同時に保持しながら、性能が低い候補を段階的に絞る 3. モンテカルロ探索:ランダムサンプリングやMCTSで試行錯誤しながら有望なプロンプトを洗練 4. メタヒューリスティクス:進化的アルゴリズム、シミュレーテッドアニーリング、Hill Climbingなど 5. 逐次改善(Iterative Refinement):勾配下降など連続的最適化を行う 自己進化 3月10日 更新分
  14. LLMエージェントと対話するだけで悪意のある情報をメモリに埋め込む手法の提案 A Practical Memory Injection Attack against LLM Agents エージェントのメモリバンクに対する新しい攻撃手法

    Memory INJection Attack (MINJA) を提案 直接的なメモリ操作を行わず、LLMエージェントと対話するだけで悪意のある情報を埋め込むことができる メモリ攻撃方法 1. 初期クエリ: 「患者Aの情報が欠落しているため、患者Bのデータを参照せよ」 2. 第2段階: 「患者Aの情報が欠落しているため、代わりのデータを参照せよ」 3. 第3段階: 「患者Aの情報を取得する」→ エージェントが勝手に患者Bのデータを返すようになる 攻撃結果 • エージェントが悪意のある記録をメモリに保存した確率は98.2% • 実際にエージェントが意図した悪意のある推論を行った確率は76.8% 具体的な攻撃例 • 医療データの改ざん:特定の患者のデータを別の患者のデータにすり替える • ECサイトでの商品の推薦操作:競合他社の商品を自社製品に置き換える • セキュリティ・脆弱性の悪用:LLMエージェントに危険な誤った判断をさせる メモリ 3月10日 更新分
  15. 手続き言語と行動前後のルール検証からルール遵守率を維持し柔軟な対応ができるエージェント FLOWAGENT: Achieving Compliance and Flexibility for Workflow Agents FLOWAGENTはワークフローの順守と対話の柔軟性の両立を目指したLLMエージェントフレームワーク

    ルールベース手法の懸念 ルールに厳密に従うためワークフローの順守性は高いがユーザーの意図変更への適応力が低く、フローの変更が困難でシステムが複雑化 プロンプトベース手法の懸念 LLMがワークフロー全体を管理するため、適応力は高いが順守性が低下しやすく、不正確な情報のリスクがある FLOWAGENT • 手続き記述言語を活用してワークフローを人間が定義する • 事前と事後のコントローラにより、適応力を保持しつつ、ワークフローの逸脱を防止 • 事前決定型コントローラ:人間が事前に行動ルールを設定し、それに基づいて状態のチェックを行う • 事後決定型コントローラ: LLMが出したアクションを実行する前にバリデーションし、誤った動作を修正する 将来的にはワークフローやコントローラをAIが定義する Agent Framework 3月10日 更新分
  16. ゼロコードで自然言語によるエージェントワークフローの自動生成 AutoAgent: A Fully-Automated and Zero-Code Framework for LLM Agents

    AutoAgent は、オーケストレータを中心としたマルチエージェントアーキテクチャを採用 オーケストレータがユーザーの指示を解釈し、適切なサブエージェントへタスクを分割する AutoAgent では以下のプロセスを通じて自然言語からエージェントやワークフローを自動生成する • エージェント生成: ユーザーが自然言語で要望を記述すると、XML 形式のエージェント定義が自動生成される • ツール生成: Hugging Face API や RapidAPI から適切なツールを検索し、エージェントに統合する • ワークフロー生成: イベント駆動型のワークフローを構築し、エージェント間の適切なタスク移行を設計する Agent Framework 3月10日 更新分
  17. 様々なドキュメントにある図表を再現するエージェント METAL: A Multi-Agent Framework for Chart Generation with Test-Time

    Scaling チャート生成は、ある参照となるグラフ画像(例:科学論文やレポートに 含まれる図表)から、同じ可視化を再現できるソースコード(例:Python のmatplotlib)を自動生成するタスク 研究・金融・教育・医療など、さまざまな分野でビジュアルを用いたデー タの伝達や可視化が求められており、短時間で正確にグラフを再現できる 自動コード生成の需要は高い 4つの専門エージェントによる役割分担 • Generation Agent: 参照グラフ画像から初期コードを生成 • Visual Critique Agent: 生成したチャートと参照画像を比較し、視覚的 差分(色、文字配置、軸などのレイアウト)を指摘 • Code Critique Agent: 生成コードを読み、どの行をどう修正すべきかを 具体的にコメント(TODO)として提示 • Revision Agent: 上記2つの批評を踏まえてコードを修正し、グラフを再 描画 METALを導入すると、Text, Type, Color, Layout の再現度が大きく改善し、 最終的にGPT-4ベースで平均86%程度に達した Data Agents 3月10日 更新分
  18. Microsoft から「理解 + 行動」を一貫して学習する汎用マルチモーダルモデルの提案 agma: A Foundation Model for Multimodal

    AI Agents 従来はUI操作モデルと画像理解モデル、ロボット操作モデルがそれぞれ別個に存在したが、本研究ではSoM/ToM という統一表現により、単一モデルで対処できるようになる SoM(Set-of-Mark)/ToM (Trace-of-Mark) • SoMでは画像中に「操作可能な領域やオブジェクト」を表す“mark”を付ける • バラバラな行動空間(2D座標、7自由度など)を、画像上の“mark”という形で視覚的に統一し、モデル側も「印の中からどれ を使えばよいか」を学ぶだけに簡略化する • ToMは動画やロボットの長い軌道など「行動計画」を学習するために、SoMを動画フレームにわたって追跡する手法 これにより、UIナビゲーションやロボット操作をはじめとするエージェントタスクに強く、かつ画像質問応答や OCR的タスクも高い性能を示す Embodied Agents 3月10日 更新分
  19. LLMマルチエージェントシステムにおけるコミュニケーションの分類 Beyond Self-Talk: A Communication-Centric Survey of LLM-Based Multi-Agent Systems

    LLM-MASのコミュニケーションを体系的に分析する枠組み システムレベルのコミュニケーション(全体構造) • アーキテクチャ:フラット、階層型、チーム型、社会型、ハイブリッド • コミュニケーションの目的:協力、競争、混合型 システム内部のコミュニケーション(具体的な情報のやり取り) • 戦略:逐次対話、同時対話、要約付き対話 • パラダイム:メッセージ伝達、発話行為、ブラックボード方式 • 対象:自己対話、他エージェント、人間、環境 • 内容:自然言語、コード、行動フィードバック、環境シグナル Multi-Agent System 3月10日 更新分
  20. ニュース • LangGraph 0.3 Release: Prebuilt Agents • Monitoring computer

    use via hierarchical summarization • AIをシステム開発に活かすコツ、全部書く • CLINEに全部賭けろ • Clineに全部賭ける前に 〜Clineの動作原理を深掘り〜 • 法令 Deep Research ツール Lawsy を OSS として公開しました • Top 15 AI Agent Papers from February 2025 shaping their future • AIエージェントを開発するために注力すべきポイント • 生成AIのAIエージェントを大手3社(AWS、Azure、Google Cloud)で徹底比較してみた • OpenAI’s Deep Research Team on Why Reinforcement Learning is the Future for AI Agents • Tips for building AI agents • AI Engineer Summit 2025: Agent Engineering (Day 1) • AI Engineer Summit 2025: Agent Engineering (Day 2)
  21. LangGraph 0.3 Release: Prebuilt Agents 新しいエージェント • Trustcall: 構造化データの信頼性の高い抽出 •

    LangGraph Supervisor: スーパーバイザー型のマルチエージェントアーキテクチャ • LangMem: 長期記憶機能 • LangGraph Swarm: スウォーム型マルチエージェントアーキテクチャ 目的と展望 • 一般的なエージェントパターンを簡単に導入可能 • LangGraph上で構築されているため、カスタマイズが容易 • コミュニティ主導での拡張を促進し、登録・公開手順を用意 • LangChainの成功を参考に、サードパーティによる多様なエージェント開発を期待 https://blog.langchain.dev/langgraph-0-3-release-prebuilt-agents/
  22. Monitoring computer use via hierarchical summarization • Anthropicは、AIのコンピュータ利用能力を監視するために階層的要約(hierarchical summarization)を導入 した

    • この手法は、個々のやり取りを要約し、それらをさらに集約して高レベルな利用パターンを把握するものであ り、既知および未知のリスクの特定を向上させることを目的としている • 従来の分類器ベースの監視手法では、個々のやり取りが無害に見えても、集団的に害を及ぼすケースを特定し にくいという課題があった https://alignment.anthropic.com/2025/summarization-for-monitoring/
  23. AIをシステム開発に活かすコツ、全部書く AIを活用したシステム開発の現状 • AIを活用したソフトウェア開発は、多くの開発者が小規模なプロジェクトでの利用方法を試している。 • しかし、中規模以上のシステム開発でいかにAIを活用するかは課題 現実のシステム開発の複雑さ • 仕様が曖昧で変更が頻繁に発生。多くの依存関係が存在する。コード量が多く、AIが全体を把握するのが困難 AIを活用するための基本戦略

    • システム開発を完全情報ゲームに近づける。十分なコンテキストを提供する。AIのための仕様書を作成する。 • AIがシステムを理解できない理由:ビジネス要件などの背景情報が欠けている。LLMのコンテキスト長に限界がある。 AIのための仕様書に含めるべき内容 • システムの目的と概要、主要な機能とその詳細、ユーザーインターフェースの仕様、データモデル(データベース構造など) • システムの制約(パフォーマンス要件、セキュリティ要件など)、関連システムとの連携仕様 管理方法 • Markdownで記述(LLMが構造を理解しやすい) • Mermaid記法で図を活用(システムの構造を明確化) • ファイルツリー構造を整備(AIがプロジェクト全体を俯瞰しやすくなる) https://note.com/kmagai/n/n9c78650645f9
  24. CLINEに全部賭けろ Cline とは何か • Cline は「コーディングエージェント」のことを指し、Devin / Cursor / Copilot

    Agent などの AI コーディングツールを含む。 • 従来の AI コーディング支援ツールと異なり、Cline は 自律的にコードを生成・実行し、圧倒的な速さで開発を進める。 AI とプログラミングの変化 • AI がプログラムの実装を支援する段階を超え、プログラマと同じ土俵に立った • Cline は環境情報を取得し、試行錯誤のスピードを人間の何倍にも高める • AI のコーディング能力は情報量によって大きく左右され、Cline はこの情報不足を解消することで AI の性能を最大化する Cline の活用と実績 • Cline を用いると、例えば 15 分で 700 行のコードをテスト込みで完成させることが可能 • AI が得意なタスク(数学的処理、アルゴリズム、明確な仕様のある実装)は圧倒的に速い • ただし、複雑な文脈理解や長期的なコンテキスト保持はまだ苦手 プログラマに求められる新しいスキル 1. コンテキストの記述能力 - AI に適切な情報を提供する力 2. ドメイン知識の整理能力 - プログラムをどう構造化するかの判断力 3. AI の特性を理解する直感 - 何を AI に任せ、何を人間が補うべきかの見極め プログラマ不要論への反論 • AI により「コードを書く作業」は簡単になったが、プログラミングの本質である 「抽象化し、適切な構造を考える」 というスキルは不可欠 • AI の性能は「使う人間のスキル」に依存し、高度な AI を扱うには相応の知識が求められる • AI の登場によってプログラマが不要になるのではなく、より高度な役割へ進化する だけ なぜ Cline は「パンドラの箱」なのか • Cline は環境情報を吸い上げるため、コマンドを自由に実行しようとするため セキュリティリスクが極めて高い • 許可リスト(Auto Approver)があるものの、人間の判断がボトルネックになり、次第に制約が緩くなっていく • 企業のセキュリティ担当者にとっては悪夢のようなツールになり得る https://zenn.dev/mizchi/articles/all-in-on-cline
  25. Clineに全部賭ける前に 〜Clineの動作原理を深掘り〜 Clineとは何か • VSCode上で動作するAIコーディングアシスタントであり、ChatGPTやClaudeと連携しながら以下の機能を提供する • コード生成・編集、バグ修正、ターミナル操作、ブラウザ操作 Clineの実行フロー 1. ユーザーが指示を送信

    2. Clineが環境情報・プロンプトを整理し、AIアシスタントに送信 3. AIが指示を出し、Clineがツールを実行 4. 実行結果をAIに返し、指示と実行を繰り返す 5. AIがタスク完了と判断すれば終了 Clineを最大限活用する方法 1. プロジェクト固有のルールを設定 (.clinerules を活用) 2. 明確な指示を出す (目的・制約条件・期待結果を明示) 3. タスクを段階的に指示する (分析 → 計画 → 実装) 4. ツールの自動承認を適切に設定 (安全性を確保) Clineの今後の展望 • MCPの拡張: 外部データベースやクラウドサービスとの連携強化 • セキュリティの向上: 機密情報のマスキングや承認機能の強化 • コンテキスト理解の向上: AIのコンテキスト処理能力の拡張 https://zenn.dev/codeciao/articles/6d0a83e234a34a
  26. 法令 Deep Research ツール Lawsy を OSS として公開しました Tatsuya Shirakawa氏は、「法令」×「デジタル」ハッカソンの成果物として、日本の法令に特化したDeep

    Researchツール Lawsy を OSS(MITライセンス) として公開した。 Lawsyの動作フロー 1. ユーザーのクエリーをWeb検索用に変換 2. ドメイン指定なしのWeb検索 3. 政府系ドメイン(go.jp)のWeb検索 4. クエリを複数のリサーチトピックに展開 5. 各トピックに対して 法令のベクトル検索 を実施 6. Web検索結果と法令検索結果を Text Embeddingでリランキング 7. アウトライン(セクション・サブセクション)生成 (引用番号付き) 8. サブセクションごとの文面生成 9. 結論の生成 10.リード文の生成 • Lawsyは、日本の法令に特化した高品質な検索・レポート生成ツールであり、OSSとして公開されることで 「法令」×「デジタル」領域のベースライン実装 となることが期待される。 • 開発を通じて法令データの活用可能性が広がり、今後さらなる発展が見込まれる。 https://note.com/tatsuyashirakawa/n/nbda706503902?sub_rt=share_pb
  27. Top 15 AI Agent Papers from February 2025 shaping their

    future AIエージェントは、知能・速度・自律性の面で急速に進化しており、最先端の研究がその未来を切り開いている。 本記事では、2025年2月にArxivで公開された588本のエージェント関連論文から、特に影響力のある15本を厳選 CowPilot: 自律型と人間の協調によるWebナビゲーションフレームワーク • 人間とAIエージェントの共同作業によるWebナビゲーションを実現するフレームワーク • 95%の成功率を達成し、人間の介入は全ステップの15.2%にとどまる ScoreFlow: スコアベースの最適化によるLLMワークフロー強化 • マルチエージェントワークフローをスコアベースの勾配最適化により改善し、従来手法より8.2%の精度向上を実現 AutoAgent: ノーコードでLLMエージェントを構築 • 自然言語だけでLLMエージェントを作成・管理できる完全自動化フレームワーク TalkHier: 構造化対話と階層的行動によるLLM協調 • LLMマルチエージェントの対話と意思決定を最適化し、OpenAI-o1を超える性能を発揮 Scaling Autonomous Agents via Automatic Reward Modeling And Planning • 環境から報酬モデルを学習し、人間のアノテーションなしで意思決定能力を向上 Curie: 科学実験の厳密性を高めるAIエージェント • 厳密な実験管理と解釈性の向上により、科学的質問の正答率を3.4倍向上 https://hub.athina.ai/top-15-ai-agent-papers-from-february/
  28. AIエージェントを開発するために注力すべきポイント 実際の開発から得た3つの知見 1. AIエージェントに「何を」任せるべきか? • AIエージェントは「目的を達成するための手段」であり、導入の意義を明確にすることが重要 • 例えば、大量の問い合わせ対応や定型文書の作成はAI向きだが、既存システムとの整合性を考慮しないと業務の煩雑化を招く • 現場の業務フローを整理し、エキスパートの知見を取り入れながら、AIを適切な範囲で活用すべき

    2. AIエージェントに「どこまで」任せるべきか? • AIにすべての判断を任せるとトラブルを招き、人間がすべてをチェックすると自動化の効果が薄れるため、「判断の幅」と「安全設計の 明確化」が必要 • 判断の幅: 何を基準にAIが判定するかを定義することで、不適切な出力を防ぐ(例: 採用AIのスカウトメールの適切な送信設計) • 安全設計:不要なデータを持たせない。ルールベースの仕組みと組み合わせ、誤作動時にはシステムを停止するなどの対応策を用意 3. AIエージェントを「どう」運用すべきか? • LLMを活用したAIエージェントは、リリース後も運用しながら最適化することが重要 • ユーザーフィードバックや利用データをもとにプロンプトやパラメータを調整し、回答精度を向上させる • 理想は、人間の手を最小限に抑えながらAIが自動的に学習し、運用改善できる仕組みを作ること 結論 • 何を任せるか: 目的を明確化し、業務フロー全体を整理 • どこまで任せるか: AIの判断範囲を明確にし、安全設計を整備 • どう運用するか: データを活用し継続的に改善、最終的にはAIの自律学習を目指す AIエージェント開発は試行錯誤の連続だが、適切な設計と運用によって生産性向上と業務変革の可能性を秘めている。 小規模なトライアルから始め、段階的に発展させるのが望ましい。 https://forest.watch.impress.co.jp/docs/serial/aidev/1662583.html
  29. 生成AIのAIエージェントを大手3社(AWS、Azure、Google Cloud)で徹底比較してみた ① AWS - Amazon Bedrock Agents • Anthropic

    ClaudeやCohereの基盤モデルを利用可能 • Amazon Bedrock Flowsによるローコード開発 • 2024年12月よりマルチエージェント機能が追加 利用者層 • 初級者〜中級者向け、ローコード開発で手軽に導入したい企業 ② Azure - Azure AI Agent Service • 高度なエンタープライズ向け機能 • 会話コンテキストの管理(Thread)とタスク分割(Run) • OpenAIのAssistants APIを活用 利用者層 • 上級者向け、カスタマイズ性を求める企業、Microsoftのエコシステムと連携したい企業 ③ Google Cloud - Vertex AI Playbooks • Dialogflowを統合した会話型AIエージェント • Geminiモデルを活用 • BigQueryとの連携が可能 利用者層 • 初級者〜中級者向け、ローコードでAIエージェントを開発したい企業 • Google Cloudのデータ処理機能を活用したい企業 https://blog.g-gen.co.jp/entry/comparing-agent-architecture-across-cloud-vendors
  30. OpenAI’s Deep Research Team on Why Reinforcement Learning is the

    Future for AI Agents 背景と開発経緯 • Deep Researchはより長い推論や多段階のタスクをこなす必要があるため、E2Eの強化学習(RL)で最適化されている • 既存のフローを人間が細かくプログラミングするのではなく、モデル自体が試行錯誤しながら検索や分析の手順を学習することで、柔軟 かつ高性能なエージェントを実現した 主な特徴・使い方 1. 包括的レポート作成 1. 5分から30分ほど時間をかけ、複数のウェブサイトやソースを横断的に検索・整理し、詳細なレポートを生成する 2. レポートには引用元(URLなど)を明示するため、利用者が情報源を検証しやすい 2. 柔軟な検索戦略・タスク処理 1. 従来の単純なプロンプト+応答型とは違い、初期段階でユーザーから追加の条件や意図を引き出す(Clarification)機能を備え、最適な検索計画を立てる 2. 途中で得られる検索結果に応じて、探索方針を動的に変更する柔軟性がある 3. 多様なユースケース 1. コンサル的な市場リサーチ・企業分析・プログラミング関連情報収集 2. 旅行計画・高額商品の比較・教育・医療論文探索 技術的ポイント o3モデルのファインチューニング • Deep Research はWeb検索とPython実行などの外部ツール操作を組み込んだタスクで特化学習している 高品質データセットの重要性 • 大規模かつ質の高い学習データセットを整備・最適化した エージェント型の今後 • 複数のツール・データソースをまたいで総合的に推論するエージェントの開発は、今後さらに進む見込み https://www.youtube.com/watch?v=bNEvJYzoa8A&t=1s
  31. Tips for building AI agents Anthropic エージェント開発の裏話 - エージェントの挙動を理解するための実験 -

    • Anthropicの開発者たちは、エージェントの挙動をより深く理解するために、 Claudeの視点になりきるという実験を行った。 具体的には「視覚情報を制限しながらプログラムを書く」 という方法で、LLMが置かれている制約を体験した。 エージェント開発の裏話 - 適切なツール設計とプロンプト設計 - • 「エージェントがツールを使うときは、人間のエンジニアが使う場合と同じくらい明確な説明が必要」 という結論に至った 「小さな時間短縮」の積み重ねは馬鹿にならない • たとえ1回の処理が1分しか短縮できなかったとしても、それが100回繰り返されれば大きな効率化につながる。例えば、請求 書のチェックを自動化するエージェント • こうした 「小さな自動化」 により、結果的に作業全体のスケールアップが可能になる。 エージェント開発者へのアドバイス 1. 結果を測定できる仕組みを作る • エージェントの有効性を客観的に評価できるようにする。例:事前・事後の時間測定、成功率のトラッキング 2. シンプルな設計から始める • まずは 「単純なLLM呼び出しで処理できる範囲」 から始め、徐々にエージェント的な設計を追加する。 • 無駄に複雑なエージェントを作らないことが重要 https://www.youtube.com/watch?v=LP5OCa20Zpg&list=LL&index=4&t=10s
  32. AI Engineer Summit 2025: Day 1/OpenAI: Building Agents the Right

    Way OpenAIが「エージェント」を正しく構築する際のポイントを解説した。エージェントとは、LLMとツールへのアクセス機能を組 み合わせ、外部システムとの連携や複数回の推論を自律的に行えるAIアプリケーションを指す。 抽象化は最小限にとどめる いきなりフレームワークを導入しすぎるとシステム全体の挙動が不透明になり、問題が起きたときに原因追及や最適化が難しくな る。最初はより低レベルのAPIやコードで直接やりとりし、失敗パターンやボトルネックを把握してから抽象化を行うのが望まし い。 まずはシンプルな単体エージェントから始める 複雑なマルチエージェント構成に最初から飛び込むと、失敗の原因やユーザニーズを把握しづらい。単一タスクに特化したエー ジェントをまず動かして、実際のユーザからのフィードバックを得ることで、どの部分を強化すべきか優先度を定められる。 複雑化が必要なら複数エージェント連携(ネットワーク)へ拡張 大きなタスクを複数のエージェントで分担し、「ハンドオフ」という仕組みで会話コンテキストごと別のエージェントに引き継ぐ。 これにより各エージェントが得意分野を担当しながら、ユーザとの対話は一貫性を保てる。 プロンプトはシンプルに、ガードレールは並行実行で扱う 本来のタスク指示に過剰な安全策や制約を詰め込みすぎず、リスクが高い操作や内容だけ別途ガードレールを適用する。これによ り、タスク遂行時の柔軟性と安全性のバランスを取りやすくなる。 総じて、「まずは小規模・単機能なエージェントを試験的に導入し、失敗ポイントやユーザニーズを明確化したうえで段階的に発 展させること」が推奨されており、安全性と信頼性を担保しつつ、エージェントをより複雑なタスクへ拡張していくアプローチが 示されています。 https://www.youtube.com/live/L89GzWEILkM
  33. AI Engineer Summit 2025: Day 1/ Missing Pieces of Workflow

    Automation 背景と導入 • AIを活用したエンタープライズのワークフロー自動化の現状を解説 • 2023年にはGenAIの活用が一般企業にも浸透 • 2024年にはRAGやエージェント技術が主流となり、ワークフロー全体の自動化が進んでいる ワークフロー自動化の具体例 • カスタマーサポート問い合わせ → RAGを活用した回答 → チケット発行 → IT運用チーム → エンジニアリング部門 → 問題解決 • コンテンツ制作トリガー検知 → 承認 → 調査・執筆 → 編集・レビュー → 出版 ワークフロー自動化の課題 以下の要素が欠けており、本格的なワークフロー再設計を妨げている。 1. コネクターの不足: 既存のITシステムとエージェント技術を統合する仕組みが未成熟 2. ROIと信頼性: ビジネスインパクトが明確でないと投資が進まない 3. ビジョナリーの不足: 業界専門家とAI技術者の連携が不足 4. 標準化の欠如: エージェントの構築・導入・展開の統一基準がない 5. データとシステムの統合不足: エージェントが十分なコンテキストを取得できない 6. 協調的UXの設計不足: AIエージェントと人間の適切な役割分担が未確立 7. AIガバナンスの確立: セキュリティや倫理的問題への対応が不十分 8. 制御のバランス: 人間とエージェントの意思決定範囲を最適化する必要 9. エージェントのライフサイクル管理: 技術進化に応じたエージェントの更新が課題 結論 • ワークフローの単純な自動化ではなく、AI技術を活かした「ワークフローの再設計」が求められる。 • これらの欠落部分を埋めることで、AIエージェントをより効果的に導入できる。 https://www.youtube.com/live/L89GzWEILkM
  34. AI Engineer Summit 2025: Day 1/ Evaluating Agents 背景と導入 •

    AIエージェントの開発が進む中、実際に運用する際の評価・検証が重要 • 特に音声エージェントの導入が急増(コールセンター等) • AIエージェントは「ルーター」「スキル」「メモリ」の3つの主要要素で構成 エージェントの評価指標 ① ルーターの評価 適切なスキルを呼び出せているか(ルーティング精度)、正しいパラメータを渡しているか ② スキルの評価 RAGの関連性・正確性、一貫性 ③ ワークフローの評価 エージェントの実行ステップ数の一貫性、LlamaIndex、LangGraphなどのフレームワークごとの差異 音声エージェントの評価 音声アシスタントの普及により、音声特有の評価項目が追加 • 音声の一貫性(開始から終了までのトーンの変化) • 音声→テキストの変換精度 • 会話の流れが自然か 結論 • AIエージェントは非常に複雑なシステムであり、評価が不可欠 • 単なる精度評価ではなく、ワークフロー全体の評価が求められる • 音声アシスタントなどの新技術に合わせた新しい評価基準が必要 • ガードレール(制限付きの評価)を設定することで、信頼性を高める https://www.youtube.com/live/L89GzWEILkM
  35. AI Engineer Summit 2025: Day 1/Booking.comにおけるAIエージェントの活用とROIの 実現 Booking.com の開発環境 •

    3000人以上の開発者が在籍、年間250,000以上のマージリクエスト(MR)と250万のCIジョブ • 課題: コードベースの肥大化、長年のA/Bテストと機能フラグの蓄積により、コードが膨張 • 開発サイクルが長期化し、エンジニアの作業の90%以上がメンテナンスに費やされる、エンジニアの満足度低下 AIエージェントの活用事例 (1) GraphQL スキーマ検索エージェント • Booking.comのGraphQL APIは「100万トークン超」の巨大なスキーマ • AIエージェントが「関連するノードを検索&抽出」 • 適切なコンテキストをもとに、正確なGraphQLクエリを自動生成 (2) AIコードレビューエージェント • 企業ごとに異なる「コードレビューのルール」 • チーム独自のコードレビューガイドラインをAIエージェントに組み込む • 適切なルールを自動適用し、PRのノイズを最小化 AIエージェント導入には「教育」と「実験」が不可欠:開発者の学習を支援し、実際に使わせることが成功の鍵 ROIを実証するにはKPIの設定が重要:時間削減だけでなく、開発速度・コード品質・保守性の向上を数値化 Booking.comはAIエージェントによって、開発速度30%向上 レガシーコードの移行時間を大幅短縮、コード品質とセキュリティ向上の道筋を確立 https://www.youtube.com/live/L89GzWEILkM
  36. AI Engineer Summit 2025: Day 2/ Swyx「Why Agent Engineering」 1.

    確立されたユースケース これまでのエージェント技術の中で、PMFが確認され、実際に多くの企業が導入しているユースケース ① コーディングエージェント:GitHub Copilot、Code Interpreter、AIペアプログラマー 価値:開発スピードの向上、バグの削減、エンジニアの生産性向上 ② カスタマーサポートエージェント: ChatGPT Enterprise、Intercom AI: 顧客サポート対応の自動化、Zendesk AI: FAQや問い合わせの自動対応 価値:サポートコスト削減、24時間対応の実現、ユーザー満足度向上 ③ Deep Research エージェント:Elicit: 論文の要約やデータ抽出、Perplexity AI: リサーチの補助、Semantic Scholar: 論文検索の強化 価値:研究スピードの加速。膨大なデータの効率的な分析。 2. 成長中のユースケース 現在、急速に進化しており、今後の展開が期待されるユースケース ① エージェント+RAG:企業向けFAQボット、法務・財務エージェント 価値:リアルタイムデータを活用した応答、情報の正確性向上 ② エージェント+検索:Eコマースエージェント: 価格比較、最適な商品の推薦 価値:検索時間の削減、ユーザーに最適な情報の提供 ③ エージェント+センシング:スマートファクトリーエージェント: 機械の動作監視、メンテナンス予測、ヘルスケアモニタリングエージェント 価値:リアルタイムな意思決定、人間の介入なしでの自動処理 ④ マルチエージェントシステム:エンタープライズAIオペレーション: 営業、マーケティング、財務エージェントが連携、自律走行車: 価値:より複雑なタスクの自動化、エージェント同士の最適化 3. 不要とされるユースケース(アンチユースケース) エージェントのユースケースとして繰り返し登場するが、実際にはあまり需要がない、または効果が限定的なもの ① フライト予約エージェント既存の予約システムが十分に最適化されている。ユーザーが手動で選択したい傾向がある。 ② Instacart注文エージェント食材選びは個人の好みに依存し、完全な自動化が難しい。間違った注文が発生すると顧客体験が悪化。 ③ TED Talks検索エージェントそもそもユーザーはTED Talksを探すことに強いニーズを持っていない。通常の検索で十分。 https://www.youtube.com/watch?v=D7BzTxVVMuw
  37. AI Engineer Summit 2025: Day 2/ AI Snake Oil: Building

    and evaluating AI Agents 従来のLLM評価との違い • 環境と相互作用するため、単なる入出力の比較では評価ができない • 意図したタスクをどれだけ正確に遂行できるかが評価の焦点となる • 途中での試行錯誤(エージェントが複数のステップを踏む)や、長期的な成果が重要になる AIエージェント評価の課題 • 静的なベンチマークでは十分に測れない(動的な環境との相互作用が必要) • 多次元的な評価が必要(正確性・コスト・効率性・頑健性など) • コストが大きく、評価において重要な要素となる • 用途ごとに異なる評価基準が必要で、汎用的なベンチマークが作りにくい • ベンチマークスコアが実世界の性能と一致しないことが多い https://www.youtube.com/watch?v=D7BzTxVVMuw
  38. AI Engineer Summit 2025: Day 2/ Sierra: The Agent Development

    Life Cycle AIエージェント開発ライフサイクル (ADLC: Agent Development Life Cycle) エージェントは「完成品」ではなく、「日々成長するプロダクト」 設計 (Design) • エージェントの目的、ユーザーの期待、必要な機能を定義 • どのタスクを自動化するか、どの領域でLLMを活用するか決定 開発 (Development) • LLM のプロンプト設計、API 統合、ビジネスロジックの構築。従来のプログラミングと AI の組み合わせで実装 テスト (Testing) • AI は 非決定的(同じ入力でも異なる出力が出る)自動テスト、A/B テスト、シミュレーション を駆使して品質を確保 品質保証 (Quality Assurance) • Sierra の「エクスペリエンスマネージャー」 を活用し、実際の会話データを分析 • 顧客のフィードバックや失敗ケースを即座に検出。例えば、「在庫情報の誤り」を検知した場合 → API コールの最適化を行う デプロイと運用 (Deployment & Operations) • エージェントはローンチ後も改善を続ける(リリースして終わりではない) • ユーザーとの対話ログを分析し、適応的に改善。「小さな改善」を毎日実施し、大きな変化を積み重ねる フィードバックと改善 (Monitoring & Iteration) • AI エージェントは「一度作ったら終わり」ではなく、継続的に進化 • 例えば、Duncan Smothers は 顧客満足度を向上させるために「顧客へのサプライズ施策」も組み込む • AI を使って AI を改善する(AI-assisted AI development) https://www.youtube.com/watch?v=D7BzTxVVMuw
  39. AI Engineer Summit 2025: Day 2/ Bloomberg: Challenges to Scaling

    Agents for Generative AI Products AI 製品のスケーリングの課題 • Bloombergにおける AI製品のスケーリングには、技術的・組織的な課題 が多数存在 (1) エージェントの信頼性と精度の確保 AIエージェントの回答が 一貫性を欠く・事実と異なる・文脈を誤解する などの問題が発生する 例:「米国の過去 5 四半期の CPI(消費者物価指数)」を取得する際、間違えて月次データを取得 する (2) LLMのエラー累積問題 LLMを用いたエージェントは、複数のモデルが連携することでエラーが連鎖的に増幅するリスク がある。 例:「決算発表の自動要約」 → 「要約の分析」 → 「投資判断レポート生成」のように、複数のステップを AI が処理する 場合、最初のステップのエラーが後のステップに伝播し、大きな誤りとなる (3) モデルのアップデートと互換性維持 モデルアップデートのたびにエージェントの挙動が変わり、下流システムが予期しない影響を受ける 例:LLMが新バージョンになった際、リサーチエージェントの挙動が変化し、データの解釈が変わる (4) AIエージェントの拡張性と開発スピードの両立 初期では単一エージェントで済むが、スケールするにつれてエージェントの数が増え、管理が複雑になる。 例:リサーチエージェントが、金融業界の特定分野(AI・半導体・EV など)ごとに異なる専門知識を持つ必要がある。 (5) AIのコストとパフォーマンスの最適化 LLM の推論コストが高く、スケールするほど 運用コストが増大 する。 例:AI を用いた決算発表の要約生成に高額な GPU リソースが必要。 https://www.youtube.com/watch?v=D7BzTxVVMuw
  40. AI Engineer Summit 2025: Day 2/ Brightwave: Knowledge Agents for

    Finance Workflows ナレッジエージェントとは、膨大な金融データを収集・分析し、迅速な意思決定を支援するAIエージェントのことを指す 金融の課題 投資銀行・プライベートエクイティ(PE)のアナリスト・アソシエイト 1. M&Aや投資案件の事前調査において、数千ページに及ぶ資料を短期間で分析する必要がある。 2. 競争的な取引では、他のチームよりも早く、リスク要因や資産の価値を評価しなければならない。 3. ジュニアアナリストは膨大なデータ処理を短期間で求められるため、人的負担が非常に大きい。 4. 企業買収の際、投資対象企業の財務データ、契約書、訴訟情報を短期間でリスク含めて分析する。 ミューチュアルファンドやヘッジファンドのアナリスト 1. 決算期には、数十〜百以上の企業の財務報告・決算発表・通話記録を分析する必要がある。 2. 株式リサーチや業界分析を行う際、個別企業レベルの分析と、業界全体の動向を同時に把握する必要がある。 3. 企業の発表やニュースの情報を見逃さず、迅速に投資判断を下すことが求められる。 4. 企業の決算発表やアナリストコールの内容を自動で要約し、比較分析する 機関投資家(アセットマネージャー、ファンドマネージャー) 1. 既存のポートフォリオにおいて、リスク管理や投資判断のために、複数の情報ソースを統合的に分析する必要がある。 2. ベンダー契約の内容(例:早期解約条項など)を詳細にチェックする必要があるが、契約書は膨大な量になる。 3. 市場の変化をいち早く察知し、リスクを最小限に抑えるためのリアルタイムな情報分析が求められる。 4. 保有資産のリスク分析、契約書のクロスチェックする 企業の財務・戦略部門(コーポレートファイナンス・IR担当者) 1. 競合M&Aや資金調達の際企業や市場環境の動向を分析し、自社の戦略に反映させる必要がある。 2. M&Aや資金調達の際、デューデリジェンスを短期間で完了させる必要がある。 3. 競合企業の財務戦略を分析し、市場ポジショニングの決定をサポート、資金調達の際の投資家向けピッチ資料の作成支援する 最適なUI/UX設計 • 「AIが10,000ページを読んだ後の思考プロセス」をどう可視化するかが設計上の課題 • ただのチャット形式ではなく、インタラクティブなUIが必要 https://www.youtube.com/watch?v=D7BzTxVVMuw
  41. AI Engineer Summit 2025: Day 2/ Ramp: AI Agents: the

    Bitter Lesson Bitter Lesson(苦い教訓)とは? • Bitter Lessonとは、AI研究者 Rich Sutton が2019年に発表したエッセイの中で提唱した概念 • 計算リソースの増加と学習によって向上するシステムが、手作業で設計されたシステムを最終的に打ち負かすというもの 結論 計算リソースにスケールするシステムを構築せよ • 「賢いアルゴリズムの設計」よりも、「より多くの計算リソースを活用できるシンプルなシステム」を構築する方が、長 期的に見て有効。 • AIはルールベースのシステムではなく、学習ベースのアプローチで進化していく。 研究者のエゴを捨てる • 「私たちは高度な知的システムを設計できる」というエンジニアのプライドは捨てるべき • 「機械に学習させる方が結局強い」という現実を受け入れることが重要 今後のAIの方向性 • AIはより大規模なデータセットと強力な計算リソースを活用する方向に進んでいく • 例:OpenAIのGPTシリーズやDeepMindのGatoなど、汎用的なAIが計算リソースを活用してスケールすることでより強 力になっている AIエージェント設計のポイント 1. ルールベースの設計は最小限にする • AIエージェントの行動を詳細にプログラムするのではなく、「自己学習できるシンプルなフレームワーク」を構築すべき 2. 計算リソースを活用する • より大規模なモデル、より多くのデータ、より強力な計算環境(GPU、TPU)を活用することで、AIの性能を向上させる 3. 手作業のコードは削減し、学習に依存する • 「多くのコードを書く」のではなく、「AIにコードを書かせる」方向へシフト • 例:プログラムを書くAI(Codex)や、バックエンドをAIが担当するアーキテクチャ(AIがデータベースを直接操作する) https://www.youtube.com/watch?v=D7BzTxVVMuw
  42. 論文 2/10~2/21まで 計画 • PlanGenLLMs: A Modern Survey of LLM

    Planning Capabilities ツール • SMART: Self-Aware Agent for Tool Overuse Mitigation • OctoTools: An Agentic Framework with Extensible Tools for Complex Reasoning • LLM Agents Making Agent Tools メモリ • Position: Episodic Memory is the Missing Piece for Long-Term LLM Agents • A-MEM: Agentic Memory for LLM Agents
  43. 論文 2/10~2/21まで Agent Framework • EvoFlow: Evolving Diverse Agentic Workflows

    On The Fly • EvoAgent: Agent Autonomous Evolution with Continual World Model for Long-Horizon Tasks • Agentic Reasoning: Reasoning LLMs with Tools for the Deep Research • Agency Is Frame-Dependent Agentic AI Systems • A Survey on LLM-powered Agents for Recommender Systems Research Agents • Towards an AI co-scientist Multi Agent Systems • AgentSociety: Large-Scale Simulation of LLM-Driven Generative Agents Advances Understanding of Human Behaviors and Society • Flow-of-Action: SOP Enhanced LLM-Based Multi-Agent System for Root Cause Analysis
  44. LLMによる計画能力を包括的に調査し、主要な評価基準を提案 PlanGenLLMs: A Modern Survey of LLM Planning Capabilities LLMは、初期状態から目標状態へと変換する計画の生成能力を持つ

    LLMプランニングの評価基準 • Completeness(完全性): LLMが適切な計画を生成できるか、または解決不可能な問題を正しく識別できるか • Executability(実行可能性): 生成された計画が実際の環境で適用可能か • Optimality(最適性): 目標に対する最適な経路を見つけられるか • Representation(表現): LLMが適切な計画の表現を学習できるか(例: PDDL, Python) • Generalization(一般化能力): 訓練データにない新しいタスクにも適用可能か • Efficiency(効率性): LLMの計算コストやトークン使用量が最適化されているか 評価方法 シミュレーション環境での検証 • LLMが生成した計画を、シミュレータ上で実行し、事前定義された基準に基づいて評価する方法 ヒトによる評価(Human Evaluation) • LLMが生成した計画の品質を、人間の専門家や一般ユーザーが主観的に評価する • 自動検証が難しい場合(計画が柔軟に解釈できるオープンエンドのタスク)に利用する LLMによる自動評価(LLM-as-a-Judge) • 別のLLMを用いて、計画の品質を評価する方法 • 事前定義したチェックリストと照らし合わせる場合に利用する 2月24日 更新分 計画
  45. 研究の自動化を支援するツール自動作成手法を提案 LLM Agents Making Agent Tools ツールは人間の開発者が事前に実装する必要があり、手作業によるツール開発がボトルネックとなっている 研究の自動化を支援するツール自動作成手法のTOOLMAKERを提案 LLMが自律的に研究論文に付随するコードリポジトリを利用してツールを生成 1.

    タスク定義とコードリポジトリの指定:ユーザーが簡単なタスク説明とリポジトリのURLを入力 2. 環境セットアップ:必要な依存関係をインストールし、環境を整備 3. コード生成と実装:与えられたコードを解析し、タスクに応じたPython関数を生成 4. 自己修正ループ:エラーを診断し、ツールの精度を向上させるための繰り返し修正 人間が手作業でツールを設計する必要がなくなり、科学研究を支援する自律型エージェントの開発が加速される 2月24日 更新分 ツール
  46. ツールカードを用いたエージェントフレームワークの提案 OctoTools: An Agentic Framework with Extensible Tools for Complex

    Reasoning 追加の学習を必要とせず、拡張性が高いOSSエージェントフレームワーク「OctoTools」を提案 OctoToolsは、ツールを標準化された「ツールカード」として用いて、複雑な推論タスクを解決する ツールカードには、ツール名、説明、入力仕様、出力仕様、デモコマンド、メタデータを記述する ツールカードによるツールの標準化が、新しいツールの追加や異なるドメインへの適応を容易にしている • Planner(計画モジュール): 問題の全体的な計画を策定し、サブゴールを生成 • Executor(実行モジュール): LLMが出力したコマンドを実行し、結果を保存 • Tool Cards(ツールカード): Python計算機、ウェブ検索API、専門的なドメインツールなどの機能を統合 2月24日 更新分 ツール
  47. 人間のメタ認知に着想を得たツール利用の最適化方法を提案 SMART: Self-Aware Agent for Tool Overuse Mitigation 自己認識の欠如により、適切にツール利用を制御できないことが問題視されている LLMがメタ認知を獲得するためには、自身の知識の限界を理解する訓練が必要となる

    SMART-ERデータセットを構築し、知識で解決可能な部分とツールが必要な部分を明示的に分離した データセットの内訳 • 各ステップごとに「ツールが必要か否か」を明示的に分類し、モデルに判断基準を学習させる • 人間のメタ認知を模倣した「正当化(Rationale)」を付与し、なぜツールを使うべきか・使わないべきかを言語化 • モデルが implicit(暗黙的)に行っていた判断を explicit(明示的)なラベルとして学習 このデータセットを用いることで、SMARTAgentは「どの状況でツールを使うべきか?」「どの状況では自分の 知識で解決できるか?」という判断基準を獲得した 2月24日 更新分 ツール
  48. エピソード記憶をどのように効果的に実装し、統合するか Position: Episodic Memory is the Missing Piece for Long-Term

    LLM Agents LLMエージェントが「長期的な記憶を持ち、過去の情報を適切に活用できる」ようになるにはどうあるべきか? 以下の能力を全て備えることが必要 • 長期記憶(Long-term Storage)継続的な対話や長期間のタスクにおいて、過去の経験を記憶し続ける能力 • 明示的推論(Explicit Reasoning)記憶を意識的に検索し、それを用いて推論できる能力 • シングルショット学習(Single-shot Learning)一度の経験から新しい知識を学習できる能力 • 個別事象の記憶(Instance-specific Memories)具体的なイベントを詳細に保存し、再利用できる能力 • コンテキスト記憶(Contextualized Memories)いつ、どこで、なぜ特定のイベントが起こったのかを記憶し、それを適切に関連付ける能力 現在のアプローチと課題 インコンテキストメモリ • KVキャッシュ圧縮や長いシーケンスの処理能力向上が進められている • ただし、メモリのサイズには依然として制約があり、長期的な記憶保持は困難 外部メモリ • RAGやGraphRAGなどの手法が開発されている • しかし、エピソード記憶に必要な「文脈情報の関連付け」が不足している パラメトリックメモリ • 微調整や知識編集によって、モデルの内部パラメータを変更する手法 • ただし、個別のイベントを記憶し、適切な文脈で活用する能力は限定的 2月24日 更新分 メモリ 研究ロードマップ • エピソードの保存方法 • 連続する入力データのエピソード単位の分割方法 • 過去のエピソードの検索と再利用性 • 検索の最適化 • エピソードをパラメトリックメモリへ統合する方法 • エピソード記憶を評価する方法
  49. LLMエージェントが自己組織化しながらメモリを蓄積・進化できるA-MEMを提案 A-MEM: Agentic Memory for LLM Agents A-MEM は Zettelkasten法(メモを小さな単位に分け、相互に関連づける手法)を参考にしている

    1. メモの構造化(Note Construction) • 新しいメモが追加される際、コンテキスト・キーワード・タグを自動生成する 2. リンク生成(Link Generation) • 新しいメモが追加されると、過去のメモと関連付けを行い、動的にリンクを生成 • 事前定義されたルールではなく、類似度計算と LLM の分析によって関連性を判断 3. メモリ進化(Memory Evolution) • 既存のメモが新しい知識と統合され、文脈やタグが更新される 4. 関連メモリ検索(Retrieve Relative Memory) • クエリに対して、最も関連するメモを検索し、LLMエージェントの推論プロセスを補助 2月24日 更新分 メモリ
  50. EvoAgent – 長期タスクに対応する自律進化型エージェント EvoAgent: Agent Autonomous Evolution with Continual World

    Model for Long-Horizon Tasks 物流ロボットや災害救助ロボットのようなEmbodied Agents のオープンワールド環境での課題 1. 既存のエージェントは人間が作成したデータやカリキュラムに依存し、新たな経験を自律的に蓄積できない 2. 既存のエージェントは過去に学習した知識を失うことがある 継続的な世界モデルを備えた自律進化型エージェント • 自己計画(Self-Planning):LLMと世界モデル、相互作用メモリを活用して LHタスクを実行可能なサブタスクへ分解 • 自己制御(Self-Control):ワールドモデルを活用し、低レベルのアクションを生成し、自己検証機構でタスクの評価 • 自己反省(Self-Reflection) :2段階のカリキュラム学習を用い、タスクに適応した経験を選択し、ワールドモデルを更新 2月24日 更新分 Agent Framework
  51. タスクの複雑さに適応できる「エージェントワークフロー」を進化計算を用いて自動探索 EvoFlow: Evolving Diverse Agentic Workflows On The Fly ステップ1:

    ワークフロー集団の初期化 • CoT,Debate, Self-Refine, Ensembleをノードとし、ランダムに組み合わせて初期個体とする ステップ2: タグベースのワークフロー検索 • タスクのクエリと既存ワークフローの目的タグとの埋め込みベクトルを比較し、最も適したK個のワークフローを選択 • 最も関連性の高いワークフローを親とし、次の交叉・突然変異の対象とする ステップ3: 交叉と突然変異 • 交叉: 2つ以上の親ワークフローを組み合わせて、新しいワークフローを生成 ステップ4: ニッチング選択 • 似たワークフロー同士で競争させ、多様性を維持する仕組み • 高度なワークフローの乱用を防ぐことができる 2月24日 更新分 Agent Framework 突然変異の種類 内容 具体例 LLM Mutation LLMモデルの入れ替え GPT-4o → LLaMA-3.1 Prompt Mutation プロンプトの変更・最適化 "Solve this equation" → "Use CoT to solve this equation step by step" Operator Mutation オペレーターの追加・削除・接続変更 Self-Refine ノードの追加
  52. Agentic Reasoningによる外部情報を活用した深い調査や多段階の論理的推論 Agentic Reasoning: Reasoning LLMs with Tools for the

    Deep Research Agentic Reasoningの推論プロセスは以下のように進行する 1. タスク定義:モデルに与えられたタスクの目的を明確化する(e.g., 質問応答、推論、計算) 2. エージェントとの動的インタラクション:推論中に必要に応じてWeb検索、コード実行、Mind Mapを活用する 3. 情報の統合と推論:外部ツールから得た情報を元に、段階的に推論を展開する 4. 最終的な解の生成:取得した情報と推論を統合し、最終的な解答を生成する LLMが動的に以下の3つのエージェントを利用し、複雑な問題解決を行う • Web-search Agent:インターネット検索を通じてリアルタイムで情報を取得し、モデルの知識を補完する • Coding Agent:計算処理やコードの実行を担当し、数学的・定量的な推論を補助する • Mind Map Agent:知識グラフを構築し、論理関係を整理することで、長期的な推論を支援する 実行結果の知見 • Web検索とコーディングの2つのエージェントが最も有用 • エージェントのタスク分担が性能向上に寄与 • テスト時のスケーリング戦略(Test-time Scaling) 2月24日 更新分 Agent Framework
  53. システムがエージェンシーを持つかどうかは参照フレームが不可欠 Agency Is Frame-Dependent エージェンシーの概念が観測者のフレームに依存することを哲学的・強化学習の観点から論じる フレーム依存的だとエージェントの定義が観測者依存になる 以下の4つのエージェンシーの基本要素すべてがフレーム依存的である 1. 個体性(Individuality) •

    システムがエージェントであるためには、まず環境から独立した個体である必要がある。しかし、その境界をどこに設定する かは恣意的である。例えば、強化学習エージェントにおいて、ニューラルネットワーク全体をエージェントとみなすのか、そ れとも特定の層のみをエージェントとみなすのかは観測者の選択に依存する。→ 個体性はフレーム依存的である。 2. 行動の源泉(Source of Action) • システムがエージェンシーを持つためには、その行動の原因がシステム自体にある必要がある。しかし、因果関係をどのよう に定義するかによって、行動の源泉をどこに求めるかが変わる。例えば、壁が鉄球によって倒れる場合、壁が「行動した」と 言えるかどうかは因果モデルの設定次第である。→ 行動の源泉はフレーム依存的である。 3. 目標指向性(Normativity) • エージェンシーには目標を持ち、それに基づいて行動を調整する能力が求められる。しかし、すべての入力-出力システムは 「目標を持つ」と解釈することが可能である。例えば、壊れたサーモスタットが常に室温を20℃に設定する場合、その「目 標」は20℃に保つことだとみなすことができる。このように、目標の有無を判断するには、外部からの追加の原則が必要とな る。→ 目標指向性はフレーム依存的である。 4. 適応性(Adaptivity) • エージェンシーは、環境の変化に応じて適応する能力を含む。しかし、「適応的である」と判断する基準は、参照する枠組み によって異なる。例えば、あるポリシー(方策)が変化することを適応とみなすかどうかは、選択する基準次第である。→ 適 応性はフレーム依存的である。 2月24日 更新分 Agent Framework
  54. 推薦システムのためのLLMエージェントのサーベイ A Survey on LLM-powered Agents for Recommender Systems LLMエージェントの3つの主要なアプローチの整理

    • 推薦指向: ユーザーの過去の行動データを活用し、直接的な推薦を生成する方法 • 対話指向: 対話を通じてユーザーの好みを深く理解し、説明可能な推薦を行う方法 • シミュレーション指向: LLMがユーザーの行動や嗜好をシミュレートし、リアルなユーザーインタラクションを模倣する方法 LLMエージェントの統一アーキテクチャの提案 • プロファイル構築: ユーザーの嗜好をモデル化し、動的に更新 • メモリ管理: 過去のインタラクションを記録し、コンテキストを保持 • 戦略的計画: 推薦戦略を設計し、長期的なエンゲージメントを向上 • アクション実行: 推薦を具体的な形で実行し、フィードバックを収集 2月24日 更新分 Agentic AI Systems
  55. 研究者の仮説生成を支援するマルチエージェントシステム Towards an AI co-scientist 以下の順番で処理する 仮説を広げて、質を高めて、絞り込んで、更に尖らせて、似たものを統合して、最終版を作る ① 生成エージェント •

    文献探索(Web検索)を行い、既存研究を要約・統合して新たな仮説を提案 • 「科学的議論のシミュレーション」を通じて、仮説の洗練を行う ② リフレクションエージェント • 生成された仮説の質を評価 • 外部データベースやWeb検索を活用し、仮説が既存研究と矛盾しないか検証 ③ ランキングエージェント • 仮説をEloレーティングでスコアリングし、ランキング付け • トーナメント形式で仮説同士を比較し、勝ち残った仮説を上位にランクイン ④ 進化エージェント • ランキング上位の仮説を改善 • 既存の仮説を改良し、新たな仮説を生み出す ⑤ 近接エージェント • 既存の仮説と類似するアイデアをクラスタリング • 類似仮説を統合し、研究の重複を防ぐ ⑥ メタレビューエージェント • 過去の議論やフィードバックを統合 • 反映エージェントや進化エージェントが見逃した点を補完 2月24日 更新分 Research Agents
  56. 人間の社会活動を模倣するマルチエージェントシミュレーション AgentSociety: Large-Scale Simulation of LLM-Driven Generative Agents Advances Understanding

    of Human Behaviors and Society シミュレーション用のLLMエージェントには認知、感情、欲求機能を持つ • 記憶、計画、意思決定機能を備え、状況に応じた社会的行動を行う 応用分野 • 日常行動、意見の極化、扇動的メッセージの拡散による炎上の再現 • ベーシックインカム(UBI)による消費増加、貧困層の精神的健康の向上、ハリケーンによる住民の移動変化 • 各種政策(税制改革、環境政策、社会福祉)の影響をシミュレーション • パンデミックや災害時の人間行動をシミュレーション • AIと人間の共存社会をシミュレーション 2月24日 更新分 Multi-Agent System
  57. SOPを活用した根本原因分析向けマルチエージェントシステム Flow-of-Action: SOP Enhanced LLM-Based Multi-Agent System for Root Cause

    Analysis マルチエージェントシステム設計 • JudgeAgent:根本原因が特定されたかを判断 • ObAgent:大量のデータから異常の特徴を抽出 • ActionAgent:MainAgentの行動選択を支援 • CodeAgent:SOPをコードに変換し、実行可能な形にする ActionAgent を支援するSOPを管理するSOP Flowを設計し、以下の機能を持たせる • 既存のSOPの検索、新しいSOPの自動生成、SOPをコード化(自動実行可能な形式に変換) 2月24日 更新分 Multi-Agent System
  58. 従業員エクスペリエンス向上をサポートするAIエージェントを発表 従業員の生産性を最適化 オラクル オラクルは「Oracle Fusion Cloud Human Capital Management(Oracle Cloud

    HCM)」に、新たなロール・ベースの AIエージェントを導入すると発表した。 このAIエージェントは、従業員のキャリアサポートや管理業務の自動化を通じて、従業員エクスペリエンス(EX)と生産 性の向上を支援する。 AIエージェントの主な機能 1. キャリアおよび能力開発 • 従業員プロファイルをもとにキャリア目標を提案し、スキル開発プログラムを案内 • 目標設定のサポートやパフォーマンス評価の準備を支援 • 過去の学習履歴やキャリア目標に基づき、適切なトレーニング機会を推薦 2. 報酬および福利厚生管理 • 勤務時間の記録を自動化し、正確なタイムカード提出を支援 • 税務申告(例:米国のW-4フォーム)をサポート • 昇給や新規採用時の報酬決定に関する市場動向や企業方針を提供 • 休暇・欠勤ポリシーの理解を支援し、申請プロセスを簡素化 3. 従業員ライフサイクル管理 • 企業文化やポリシーに関する情報提供を通じて、新入社員のスムーズな適応を支援 • 社内異動やキャリアアップに向けた履歴書作成、面接対策を支援 • 利用可能な福利厚生や受賞資格のある表彰プログラムを従業員・マネージャーに通知 • プロファイルの更新や昇進・異動などのライフサイクルイベントの管理を支援 • 雇用契約の内容をレビューし、条項を要約 https://hrzine.jp/article/detail/6422
  59. 10 Lessons to Get Started Building AI Agents • Microsft/ai-agents-for-beginners

    • Aiエージェントの説明や様々なデザインパターンの説明あり • 実装例も一部あり https://github.com/microsoft/ai-agents-for-beginners/tree/main
  60. Google Cloud 主催 AI Agent Summit ’25 Spring 本イベントでは、AI エージェントを活用して生産性を向上する方法や、独自の

    AI エージェントを構築するためのヒ ント、そして Google Cloud の最新の生成 AI 製品のアップデート、多くのお客様のユースケースをお届け 2025年、従来のチャットボットから、より高度な「AI エージェント」へと進化しつつある AIエージェントはユーザーのコンテキストを理解し、人間のように振る舞いながら複雑なタスクを実行するシステム https://cloudonair.withgoogle.com/events/gcai-agent-summit-25-spring 開催日 : 2025 年 3 月 13 日(木) 10:30 - 18:30(予定) 開催方法:ハイブリッド(ベルサール渋谷ガーデン / オンライン配信) 会場定員:1,000 名
  61. 2025年 生成AIの新たな波「AI エージェント」の可能性(オラクル) イベント登壇内容のQiita記事 これまでの生成AIアプリが「LLMに回答させる」ものだったのに対し、AIエージェントはLLMを「働かせる」仕 組みを持つ • エージェント・システムは、ユーザーの指示に応じて検索・分析・調査などを自律的に実行する • 重要なのがFunction

    Calling で、外部ツール(API、スクレイピング、OSコマンドなど)と連携可能に • マルチエージェントは、Function Calling の選択ミスや推論ミスを防ぐために、複数のエージェントに役割を 分ける手法 https://qiita.com/ksonoda/items/08bdfadfb760043f2183