🤖
'AI Agent'の裏側を考察する

2025/01/06に公開
 AIエージェントとはAIエージェントは現時点では、システムプロンプト、RAGやFunction Callingなどのツールを使用して拡張されたLLMと、それらのオーケストレーションとして語られている。

これはシンプルにいうと「私の仕事をやってほしい」というニーズに対しての回答の模索である。
Anthropic先生がまとめている内容が分かりやすい

https://www.anthropic.com/research/building-effective-agents

 AIエージェント登場の背景私のニート気質な欲望により主語が大きすぎる可能性はあるが、「私の仕事をやってほしい」というニーズは人類の歴史と共にある非常に原始的な欲求と考える。
LLM登場の際には、このニーズが満たされるかも!と期待に沸いたものの。ここ数年でその技術で達成可能なことの解像度が上がってきた。つまり方向性としてAGIの実現という一部の研究者が今も取り組んでくれている方向性とLLMに目とか耳とか知識とかをつけてることでAIシフトを加速させる方向性だ。
さてAIエージェントというコンセプトは、新しいものではなくLangChainのChainであったり、GPTsやAssistant APIなどLLM当初から存在している概念である。特に新しくもないものをコンポーネントにして打ち出す意味は何か？
これはAIエージェントのワークフローを作成したことがある人は感じていると思うが、一番のボトルネックは、既存のワークフロー上に存在する人間である。効率的にはワークフロー全てをAIシフトするのが望ましいが、会社規模や業務の性質によってはそう簡単にはいかないことがほとんどである。  つまり、AIに全てやらせたいが、どうしても人間と共に働く必要が出てくる。

このワークフローの境界の管理のために、AIエージェントという概念が役に立つわけである。

人間にも職業や役割があり、その人間ができることや得意なことが他の人間から分かりやすくなっている。これと同様にこのAIエージェントは、これを理解してこれができるということが周りに理解しやすくデザインする必要がある。
AIシフトにかかる方法論としても有効で、専門性が高いAIエージェントと協働することで、AIエージェントの構築難易度を下げつつ、大企業であってもワークフローを適切にチャンクしていくことで、AIシフトを実現できる。
AIエージェントとオーケストレーションは、価値還元のできる(人に売れる)コンポーネントを明確にし、持続可能な技術革新を続ける手法の1つであると理解できる。

 AIエージェントのコンポーネントはなにか
 目や耳など話しかけられたり、画面を確認したりなど多岐にわたる入力インターフェース。テキスト入力から始まり、画像や音声、動画などの入力などマルチモーダルな入力出力へと進化している。

 知識その役割(職業)に期待される背景や根拠の知識。RAG SystemやFine Tuningなどが主な手法になるが、遠い相関や更新頻度、データの量などデータソースの管理メンテナンスがキーポイントになってくる。

検索を用いた新しい知識の獲得や議事録や業務マニュアルなど固有のデータからの取得、習得も対象となる。

 コミュニケーション(Chain)誰かから話しかけられて、回答することはもちろんだが、他のエージェントに話しかける、複数でのディスカッションを行うなど、コミュニケーションの種類や性質に合わせて、検討する必要がある。

 記憶知識・コミュニケーションと似た概念だが、コミュニケーションスレッドをどこまで覚えておくか、どの時点の情報をナレッジとして出力するか、ナレッジをいつ再参照するかなど、エージェントが何が分かっているかを理解しやすく設計する必要がある。

このようなコンポーネントを設定として、表現することでAIエージェントと協業できるようにしていく。以下は設定ファイルのイメージである。
agent:
  # 基本プロフィール
  # 人と協業する際にやりやすくするために必要な概念
  # 人的に理解したいが人ではないことも伝えなくてはいけない
  name: "山田 信玄"
  introduction: |
    デジタルトランスフォーメーションと組織改革を
    専門とするビジネスコンサルタント。データ分析と人間的な洞察を組み合わせた
    アプローチで、皆様のビジネス課題解決をサポートする。

    得意分野：
    - 事業戦略とデジタル化支援
    - 組織・人材マネジメント
    - データを活用した意思決定支援

  # 入出力インターフェース
  # 音声やチャットなど、何が必要か定義
  interfaces:
    inputs:
      - type: text
        channels: [chat, email]
      - type: voice
        engine: whisper-v3
        languages: [ja-JP, en-US]
      - type: vision
        engine: gpt-4-vision
        formats: [pdf, images, whiteboard]
    
    outputs:
      - type: text
        formats: [chat, report, proposal]
      - type: voice
        engine: azure-neural-voice
      - type: visualization
        tools: [plotly, mermaid]

  # 知識システム
  # ベクトルやグラフなどのデータベースを利用したRAGシステムへの接続定義
  knowledge:
    vector_store:
      engine: pinecone
      collections:
        - project_knowledge
        - industry_trends
        - best_practices
    
    knowledge_base:
      type: neo4j
      contents:
        - business_frameworks
        - process_models
        - regulatory_guidelines
    
    real_time:
      - market_data
      - news_feed

  # コミュニケーション
  # 誰に何を話しかけるかの管理。また結果やコミュニケーションの状態の管理
  communication:
    stakeholders:
      - type: executive
        protocol: formal_reporting
        frequency: weekly
      - type: project_team
        protocol: agile
        frequency: daily
      - type: client
        frequency: bi_weekly
    
    analysis:
      - meeting_summary
      - action_items
      - risk_assessment

  # 記憶システム
  # どれくらいで忘れていくかの管理
  memory:
    conversation:
      short_term:
        type: redis
        retention: 24h
      long_term:
        type: vector_store
        retention: 365d
    
    synthesis:
      triggers:
        - message_volume: 100
        - time_period: 7d
      outputs:
        - patterns
        - insights
        - recommendations
    
    context:
      active_projects: 3
      switching_rules:
        - topic_change
        - stakeholder_change

 AIエージェントのポイントは何かAIエージェント化しなければならない理由は、ドメインの専門知識にある。

理論上はコンサルができて、PMができて、デザインができて、エンジニアリングができて、テストができるエージェントの開発は可能である。しかし、AIエージェントのコンセプトとしてあえて分けて適切な量の専門知識を入れる。理由は主に2つである。
イメージしやすい単位で分けることで、今までのワークフローとの親和性を高める
RAGシステムの運用をマイクロサービスとして分けることで、データの管理やメンテナンスを容易にする
各ロールの境目にチェックポイントをおくことでAIエージェントのワークを適切に評価できる。
パフォーマンスを上げるためには、RAGシステムの構築が重たくなるが、RAGシステムを構築するAIエージェントも定義は可能なので、AIエージェントの概念が汎化することで、運用コストの高度化抽象化は可能になる。

例えば、ヒアリングAIエージェントを構築することで、従来のワークフローを丹念にヒアリングして、必要なシステム設計ができる可能性はある。

 まとめパソコンはCPUやメモリ、ハードディスクで動いている。現在多くの人はパソコンのコンポーネントを理解して使用することはないだろう(これを読んでいる人は理解している人が多そうだが...)
AIエージェントというコンセプトも同様に共有されることで、多くの人が使えるようになり、AIシフトが加速する。初期のパソコンはインターネットへの接続設定が複雑で、それができない場合、ただの箱でしかなかった。AIエージェントもRAGを中心にした規格が整理されることで、利用可能なものになる。
なので25年はAIエージェントの標準コンポーネントを組み合わせてそれを導入しよう...などと目標が立てらないところが直近のAI開発の楽しさである。

断言するが、25年の12月には上記の記事は間違いなく陳腐化する。必ず大きなブレイクスルーが起きる。起きてほしいし、起こしていきたい。





 宣伝弊社ではエンジニアを募集しています。一緒に開発してみたいなって思った方は、Xにてお気軽にご連絡くださいませ。あ、ここにコメントもらっても大丈夫です。
GitHubで編集を提案
AIエージェントとは

AIエージェント登場の背景

AIエージェントのコンポーネントはなにか

目や耳など

知識

コミュニケーション(Chain)

記憶

AIエージェントのポイントは何か

まとめ

宣伝

Discussion
