AIエージェントにおけるフレームワークの動向

x facebook hatena

目次


こんにちは、ARISE analyticsでデータ分析支援業務を中心に行う「データコンサルタント」というキャリアトラックに所属している徳元です。現在、AIエージェントを用いたアプリケーション開発に携わっており、AIエージェント周りの技術に触れる機会が多くなってきました。

近年、ChatGPTに代表される大規模言語モデル(LLM)の登場により、AIエージェントの活用が一気に広まりました。ユーザーからの質問や指示に応じて柔軟に対話し、必要に応じて外部ツールを使いこなす「エージェント」のアーキテクチャは、単純なチャットボット以上に高度な応用を可能にします。適切なエージェント開発フレームワークを選ぶことで、こうした対話システムを効率よく構築・運用できるようになります。

現在はまさに「AIエージェントSDK戦国時代」とも言われ、さまざまなフレームワークが次々と登場しています。代表的なLLMアプリ開発ライブラリであるLangChainを中心に発展したLangGraphが以前から人気でしたが、最近ではOpenAI・Googleといったモデル提供企業自身によるSDKの公開も相次いでいます。さらに2025年にはAWSからもオープンソースのStrands Agents SDKがリリースされ、この分野の競争は激化しています。

 

本記事の狙い

本記事ではAIエージェント開発向けに公開されている主要なフレームワークに注目し、各フレームワークの特色やメリット・デメリットを整理してみました。フレームワークの活用を想定している方々の一助になれば幸いです。

また各フレームワークでの記述方法の比較のため、対話形式でユーザーとレストラン予約の要望をヒアリングし、最終的にランダムな予約番号を発行するような簡易ケースの実装例も併せて紹介します。(※実行にはOpenAIのAPIキーの取得が必要になります。)

各フレームワークの概要と特徴

LangChain

LangChain社によって開発・オープンソース提供されており、Pythonを中心にTypeScript版も展開されている、エージェント構築の定番ライブラリ。LLM駆動アプリ開発のデファクトスタンダードとも言える存在です。

LangChainは言語モデル、プロンプト、ツール、メモリなどのコンポーネントを、「LCEL(LangChain Expression Language)」と呼ばれる仕組みを使って直感的な組み合わせが可能なのが特徴のひとつです。このLCELによって各コンポーネントをつなぎ合わせて処理の流れ(パイプライン)を記述でき、例えばプロンプトとLLMを組み合わせて翻訳や質問応答をさせることなども数行のコードで実装できます。
また、外部のAPI・データベース・ブラウザなど多様なツール統合が可能で、豊富な公式/コミュニティ製のラッパーが揃っています。

【メリット】

  • エコシステムとコミュニティが非常に充実しており、チュートリアルなどのドキュメントが豊富です。

  • 対話ボット、ドキュメントQ&A、推薦システムから研究支援まで、さまざまなユースケースの実装例が公開されているため、ゼロから作るよりも素早く開発に着手できます。

  • 柔軟性も高く幅広い応用にも対応できます。

【デメリット】

  • 大規模モデルや外部統合を多用したアプリはリソース消費が大きくなりがちで、LangChain自体も多くの依存関係を抱えるため実行環境の管理が煩雑になりやすいです。

  • 開発のスピードゆえに変更が頻繁に起きるため、「内部動作が見えにくい」「デバッグの困難さ」に悩まされるケースも報告されています。高度に抽象化されたフレームワークに依存しすぎると、問題発生時に内部で何が起きているか掴みづらい点は注意が必要です。

LangGraph

LangChainエコシステムから派生したフレームワーク。ステートフルなフロー制御で複雑なエージェントを構築可能。

LangGraphはLangChainチームが提供する拡張フレームワークで、LangChain単体でもワークフローは組めますが、LangGraphはより自然に有向非巡回グラフ(DAG)を設計でき、条件分岐やループ、マルチエージェントの並行実行など複雑な制御も可能です。つまりLangChainが比較的リニアなチェーン構造だったのに対し、LangGraphは高度なワークフローの実装にも対応できるよう設計されています。

【メリット】

  • エージェントの思考プロセスに対する微細なコントロールができ、信頼性や再現性を重視したAIシステムに適しています。

  • LangChainとの互換性が高く、既存のLangChain資産(ツールやメモリ機構など)を活かしつつ移行できる点もメリットです。

  • PythonだけでなくJavaScript SDKも用意されており、フロントエンド/バックエンド問わず統一的なアプリ開発が可能です。

【デメリット】

  • グラフ構造による表現力と引き換えに学習コスト・実装コストが高めです。特にシンプルな対話ボット程度であればオーバーエンジニアリングになりかねません。

  • LangChainよりもさらに新しいプロジェクトのため、トラブル発生時のコミュニティサポートや情報量は限定的です。

  • 初期化処理のオーバーヘッドが相対的に大きく、エージェントを大量に生成するようなケースではボトルネックとなる可能性があります。

■実装例

# pip install langgraph==0.6.7 langchain-openai==0.3.33 langchain==0.3.27

import random
import uuid
from typing import Annotated, Dict, List

from langchain.chat_models import init_chat_model
from langchain_core.messages import BaseMessage
from langchain_core.tools import tool
from typing_extensions import TypedDict

from langgraph.checkpoint.memory import InMemorySaver
from langgraph.graph import START, StateGraph
from langgraph.graph.message import add_messages
from langgraph.prebuilt import ToolNode, tools_condition

# =========================
# Config
# =========================
MODEL_NAME = "openai:gpt-4o-mini"

# =========================
# State Schema
# =========================
class State(TypedDict):
    """LangGraphのStateを定義。messagesは会話歴を保持する。"""

    messages: Annotated[List[BaseMessage], add_messages]

# =========================
# Tools
# =========================
@tool
def make_reservation_tool() -> str:
    """ダミーの予約コードを生成して返す。"""
    return f"R-{random.randint(1000, 9999)}"

# =========================
# Graph Builder
# =========================
def build_graph():
    """LangGraph のコンパイル済みグラフを生成して返す。"""
    llm = init_chat_model(MODEL_NAME)
    llm_with_tools = llm.bind_tools([make_reservation_tool])

    def chatbot(state: State) -> Dict[str, List[BaseMessage]]:
        ai_msg = llm_with_tools.invoke(state["messages"])
        return {"messages": [ai_msg]}

    graph_builder = StateGraph(State)

    # ノード定義
    graph_builder.add_node("chatbot", chatbot)
    graph_builder.add_node("tools", ToolNode(tools=[make_reservation_tool]))

    # 遷移定義
    graph_builder.add_edge(START, "chatbot")
    # chatbotの出力がツール呼び出しなら "tools" へ、なければ自動でENDへ
    graph_builder.add_conditional_edges("chatbot", tools_condition)
    # ツール実行後は再びchatbotへ戻す(Reason→Act→Observeのループ)
    graph_builder.add_edge("tools", "chatbot")

    # メモリ(チェックポイント)
    checkpointer = InMemorySaver()

    return graph_builder.compile(checkpointer=checkpointer)

# =========================
# CLI Runner
# =========================
def run_cli() -> None:
    """簡易CLIループ。'exit', 'quit', 'q' で終了。"""
    print("AIエージェントとの対話を開始します。終了するには 'exit' と入力してください。")
    print("レストラン予約についてお聞かせください:")

    graph = build_graph()
    thread_id = uuid.uuid4().hex

    while True:
        user_input = input("\\nYOU: ").strip()

        if user_input.lower() in {"exit", "quit", "q"}:
            print("対話を終了します。")
            break

        try:
            response = graph.invoke(
                {"messages": [{"role": "user", "content": user_input}]},
                config={"configurable": {"thread_id": thread_id}},
            )
            # レスポンスから最後のメッセージを取得
            last_message = response["messages"][-1]
            print(f"\\nAI: {last_message.content}")
        except Exception as e:
            print(f"エラーが発生しました: {e}")

if __name__ == "__main__":
    run_cli()

    

Google Agent Development Kit (ADK)

Googleが公開したAIエージェント開発フレームワーク。GeminiなどGoogle独自モデルを含む高度なLLM活用を想定。

Agent Development Kit (ADK) は、Gemini や Google エコシステムに最適化されながらも、LLM モデルやデプロイ先を問わない柔軟かつモジュール化されたAIエージェント開発用のフレームワークです。ソフトウェア開発に近い感覚でエージェントを作成・オーケストレーションでき、単純タスクから複雑なワークフローまで幅広く対応します。

【メリット】

  • Google提供という強みで、GeminiやVertex AIとの親和性が高く、コネクタを使えば、エージェントが社内システムや外部 API、クラウドサービスとシームレスにやり取りできます。

  • エージェントの評価用ツールも統合されており、テストやデプロイまで含めたライフサイクル管理が充実しています。

  • 特にGoogle Cloud上での最適化が図られており、Vertex AIのエージェントエンジンにデプロイすることでスケーラブルな運用ができます。

【デメリット】

  • 高機能ゆえに学習コストはそれなりに高く、セットアップにはGoogle Cloudプロジェクトの準備が推奨されるなど、Googleエコシステムへの依存度があります。クラウド外でも動くものの真価を発揮するにはGoogleサービス利用が前提となっており、中立的なクラウド環境での利用には制約がある点は注意が必要です。

  • リリースが比較的新しく、コミュニティや事例の蓄積はLangChainほど多くありません。

■実装例

# pip install google-adk==1.3.0 litellm==1.73.0

import asyncio
import random

from google.adk.agents import Agent
from google.adk.models.lite_llm import LiteLlm
from google.adk.runners import Runner
from google.adk.sessions import InMemorySessionService
from google.genai import types

# =========================
# Config
# =========================
MODEL_NAME = "openai/gpt-4o-mini"
APP_NAME = "ReservationApp"
USER_ID = "user123"
SESSION_ID = "session123"

# =========================
# Tools
# =========================
def make_reservation_tool() -> str:
    """ダミーの予約コードを生成して返す。"""
    return f"R-{random.randint(1000, 9999)}"

# =========================
# Agent
# =========================
reservation_agent = Agent(
    name="reservation_agent",
    model=LiteLlm(model=MODEL_NAME),
    description="Agent to answer questions about restaurant reservations.",
    instruction="I can help you with your reservation inquiries.",
    tools=[make_reservation_tool],
)

# =========================
# Setup / Runner
# =========================
async def create_runner(app_name: str, user_id: str, session_id: str) -> Runner:
    """InMemory セッションを作成して Runner を返す。"""
    session_service = InMemorySessionService()
    await session_service.create_session(app_name=app_name, user_id=user_id, session_id=session_id)
    return Runner(agent=reservation_agent, app_name=app_name, session_service=session_service)

# =========================
# CLI Runner
# =========================
async def run_cli():
    """簡易CLIループ。'exit', 'quit', 'q' で終了。"""
    print("AIエージェントとの対話を開始します。終了するには 'exit' と入力してください。")
    print("レストラン予約についてお聞かせください:")

    runner = await create_runner(APP_NAME, USER_ID, SESSION_ID)

    while True:
        user_input = input("\\nYOU: ").strip()

        if user_input.lower() in {"exit", "quit", "q"}:
            print("対話を終了します。")
            break

        try:
            content = types.Content(role="user", parts=[types.Part(text=user_input)])
            events = runner.run(user_id=USER_ID, session_id=SESSION_ID, new_message=content)
            for event in events:
                if event.is_final_response():
                    final_response = event.content.parts[0].text
                    print(f"\\nAI: {final_response}")
        except Exception as e:
            print(f"\\nエラーが発生しました: {e}")

# メイン処理
if __name__ == "__main__":
    asyncio.run(run_cli())

    

Strands Agents (AWS)

AWSが中心となって開発し、2025年5月にオープンソースとして公開したAIエージェント開発SDK。モデルのプランニング能力に依存したシンプルな構成が特徴。

モデル駆動型(Model-driven)のアプローチを採用している点がユニークで、開発者はプロンプトとツールのリストを用意するだけでよく、あとはLLM自らがプランニング(思考の連鎖)とツール実行を行います。いわばLLMの推論能力に極力任せる設計で、LangChain系のようにワークフローを細かく定義する必要がありません。その名の通りモデル(LLM)とツールを二重らせん(Strands)のように絡み合わせているのがコンセプトです。

【メリット】

  • セットアップが非常に簡単で、pip install strands-agents 後、数行のコードで基本的なエージェントを動かすことができます。

  • Amazon Bedrockに加えてAnthropicやMetaのLLM、ローカルのOllama、LiteLLM経由の他プロバイダなど幅広いモデルを利用できるため、ベンダーロックインを避けやすいのも利点です。

  • 軽量な割に柔軟性が高く、マルチエージェントや会話のコンテキスト管理、メモリ永続化なども必要に応じてカスタマイズ可能です。

【デメリット】

  • 最新OSSゆえ情報や事例がまだ少なく、デフォルト設定の多くはAWS利用を前提にしています。とはいえ前述の通り他プロバイダも使えるため、AWSに縛られるわけではありません。

    モデル主導で動的にプランニングするという特性上、複雑なシナリオでは思考コストやトークン消費が読みにくい側面があります。エージェントの行動を人間が細かく制御・予測しづらいので、意図しないループや無駄なAPI呼び出しが発生しないよう十分テストする必要があります。

■実装例

# pip install strands-agents[openai]==0.2.1 strands-agents-builder==0.1.5 strands-agents-tools==0.1.8

import os
import random

from strands import Agent, tool
from strands.models.openai import OpenAIModel

# =========================
# Config
# =========================
MODEL_NAME = "gpt-4o-mini"

# =========================
# Tools
# =========================
@tool
def make_reservation_tool() -> str:
    """ダミーの予約コードを生成して返す。"""
    return f"R-{random.randint(1000, 9999)}"

# =========================
# Agent
# =========================
model = OpenAIModel(
    client_args={
        "api_key": os.getenv("OPENAI_API_KEY"),
    },
    model_id=MODEL_NAME,
)
agent = Agent(model=model, tools=[make_reservation_tool])

# =========================
# CLI Runner
# =========================
def run_cli():
    """簡易CLIループ。'exit', 'quit', 'q' で終了。"""
    print("AIエージェントとの対話を開始します。終了するには 'exit' と入力してください。")
    print("レストラン予約についてお聞かせください:")

    while True:
        user_input = input("\\nYOU: ").strip()

        if user_input.lower() in {"exit", "quit", "q"}:
            print("対話を終了します。")
            break

        try:
            print("\\nAI: ", end="", flush=True)
            agent(user_input)

        except Exception as e:
            print(f"エラーが発生しました: {e}")

if __name__ == "__main__":
    run_cli()

    

OpenAI Agents SDK

OpenAIが提供する軽量なエージェント開発フレームワーク。Python関数をそのままツール化でき、本番要件を意識したシンプルかつ拡張性のある設計が特徴。

OpenAI Agents SDK は、エージェント実装に必要な最小の要素(Agent/Tools/Handoffs/Guardrails/Session)に整理された Python 向けのフレームワークです。関数ベースのツール定義、ガードレールによる入出力検証、エージェント間ハンドオフ、会話セッションの継続、そしてイベント指向の実行(ストリーミング/最終結果)が標準機能として提供され、少ないコードで本番要件を見据えた構成を組み立てやすい設計になっています。

【メリット】

  • API設計がシンプルで学習コストが低い。

  • ガードレール/セッション/ハンドオフ/トレーシングが統合されており、安全性や観測性を含むエンタープライズ要件を満たしやすい。

  • Responses/Chat Completions両方の形式に対応し、実行時の設定上書き、Hosted ToolsやMCP(Model Context Protocol)との連携など拡張性も確保されています。

【デメリット】

  • 内部がイベント駆動設計のため、逐次返ってくるイベントを最終結果に集約するには
    軽いラッパー処理を自前で実装する必要があります。

  • 標準のセッション永続化はSQLiteが前提で小規模には十分ですが、スケーラブルな環境ではRedisやPostgreSQLなどのバックエンド実装が必要です。

  • 他社モデルを組み合わせる場合は、構造化出力やマルチモーダル、ツール実行の互換性といった機能差を踏まえた設計が求められます。

■実装例

# pip install openai-agents==0.2.4

import random
from typing import Optional

from agents import Agent, Runner, SQLiteSession, function_tool, trace

# =========================
# Config
# =========================
MODEL_NAME = "gpt-4o-mini"
USER_ID = "user_123"
THREAD_ID = "thread_123"

# =========================
# Tools
# =========================
@function_tool
def make_reservation_tool() -> str:
    """ダミーの予約コードを生成して返す。"""
    return f"R-{random.randint(1000, 9999)}"

# =========================
# Agent
# =========================
agent = Agent(
    name="reservation_agent",
    instructions="I can help you with your reservation inquiries.",
    model=MODEL_NAME,
    tools=[make_reservation_tool],
)

# =========================
# CLI Runner
# =========================
def run_cli():
    """簡易CLIループ。'exit', 'quit', 'q' で終了。"""
    print("AIエージェントとの対話を開始します。終了するには 'exit' と入力してください。")
    print("レストラン予約についてお聞かせください:")

    session = SQLiteSession(USER_ID)

    while True:
        user_input = input("\\nYOU: ").strip()

        if user_input.lower() in {"exit", "quit", "q"}:
            print("対話を終了します。")
            break

        try:
            with trace(workflow_name="Conversation", group_id=THREAD_ID):
                result = Runner.run_sync(agent, user_input, session=session)
            print(f"\\nAI: {result.final_output}")
        except Exception as e:
            print(f"\\nエラーが発生しました: {e}")

if __name__ == "__main__":
    run_cli()

    

Agno

旧称Phidata。Python製の軽量エージェントフレームワーク。高速・低メモリでマルチモーダル対応が強み。

Agnoは2025年に登場したオープンソースのフルスタック・マルチエージェントシステム構築フレームワークで、メモリ・知識・推論機能を内蔵し、高速・軽量かつマルチモーダル対応を特徴とします。内部実装を極限まで効率化しており、エージェント生成にかかる時間はLangGraphより早く、メモリ消費もより効率的になると紹介されています。さらに初めからマルチモーダル対応が組み込まれており、テキストだけでなく画像・音声・動画もネイティブに扱えるよう設計されています。

【メリット】

  • 動作が速く低コスト。複雑なツール連携やベクトルDBを用いたメモリ、多数のエージェント並列実行といった高度なケースでも、オーバーヘッドが最小化されています。

  • モデル非依存(model-agnostic)でOpenAIやClaudeはもちろん、Google GeminiやローカルLLMまで好きなモデルを自由に組み合わせ可能。

  • エージェントのセッションや性能をリアルタイム観測できるダッシュボードも提供されており、開発・デバッグがしやすい工夫もなされています。

【デメリット】

  • 軽量化・抽象化が徹底されている分、例えばLangChainのような大量の組み込みツールやテンプレートは用意されていません。

  • 必要最小限の機能に絞ったミニマル設計であるため、目的によっては自分で周辺機能を書く必要があります。しかし実際にはDuckDuckGo検索やPython実行、DALL-E画像生成など主要なツールクラスは用意されており 、大半のユースケースはカバーできる印象です。

■実装例

# pip install agno==1.7.2 openai==1.95.1

import random

from agno.agent import Agent
from agno.models.openai import OpenAIChat
from agno.tools import tool

# =========================
# Config
# =========================
MODEL_NAME = "gpt-4o-mini"

# =========================
# Tools
# =========================
@tool(show_result=True, stop_after_tool_call=False)
def make_reservation_tool() -> str:
    """ダミーの予約コードを生成して返す。"""
    return f"R-{random.randint(1000, 9999)}"

# =========================
# Agent
# =========================
reservation_agent = Agent(
    name="ReservationAgent",
    model=OpenAIChat(id=MODEL_NAME),
    tools=[make_reservation_tool],
    show_tool_calls=True,
    instructions="ユーザーのレストラン予約に関する要望をもとに、適切な提案を行ってください。",
    add_history_to_messages=True,
    num_history_runs=5,
    markdown=True,
)

# =========================
# CLI Runner
# =========================
def run_cli():
    """簡易CLIループ。'exit', 'quit', 'q' で終了。"""
    print("AIエージェントとの対話を開始します。終了するには 'exit' と入力してください。")
    print("レストラン予約についてお聞かせください:")

    while True:
        user_input = input("\\nYOU: ").strip()

        if user_input.lower() in {"exit", "quit", "q"}:
            print("対話を終了します。")
            break

        try:
            print("\\nAI: ", end="")
            reservation_agent.print_response(user_input)

        except Exception as e:
            print(f"\\nエラーが発生しました: {e}")

if __name__ == "__main__":
    run_cli()


    

AG2 (AutoGen2)

MicrosoftのAutoGenを前身とするオープンソースフレームワーク(現在はTogether AIがホスト)。複数エージェントの協調対話に対応。

AG2は、2024年11月にAutoGen v0.2の主要コントリビュータらがmicrosoft/autogenリポジトリからフォークして誕生した、コミュニティ主導のOSSフレームワークです 。GitHub上のag2ai組織で管理され、Apache License 2.0の下で公開されています 。

【メリット】

  • マルチエージェント会話フレームワークを高レベル抽象化で提供し、Assistant・Executor・Criticなど異なる役割のエージェントが協調してタスクを遂行できます。

  • ConversableAgentやUserProxyAgentなどの組み込みエージェントクラスにより、コーディングAIとユーザー代理エージェント間でコード実行や検証を含む複雑なワークフローを少ないコードで構築可能。

  • RAG、外部ツール連携、コード実行、自律・ヒューマンインザループのワークフローなどを組み合わせた高度なユースケースにも対応しています。

【デメリット】

  • コミュニティ主導のプロジェクトのため、プラグインやサンプルリポジトリは増加中ですが、エンタープライズ水準の包括的なエコシステムや公式サポートは今後の整備が必要な状況。

  • オーケストレーションロジックについては、エージェント本体に強く結合している部分があり、動的なエージェント追加やカスタマイズには追加の労力を要する場合があります。

■実装例

# pip install ag2[openai]==0.9.9

import random

from autogen import ConversableAgent, LLMConfig

# =========================
# Config
# =========================
API_TYPE = "openai"
MODEL_NAME = "gpt-4o-mini"

llm_config = LLMConfig(api_type=API_TYPE, model=MODEL_NAME)

with llm_config:
    # ユーザーと会話するLLM(人を呼ばない=NEVER)
    my_agent = ConversableAgent(
        name="helpful_agent",
        system_message=(
            "You are a helpful assistant for restaurant reservations.\\n"
            "If the user asks to make a reservation or needs a reservation code, "
            "call the tool make_reservation_tool and include the returned code."
        ),
        human_input_mode="NEVER",
        max_consecutive_auto_reply=1,
    )

    # 実行専用(ツールだけ動かす、しゃべらない)
    executor = ConversableAgent(
        name="executor",
        human_input_mode="NEVER",
        llm_config=False,
        default_auto_reply="",
    )

    # ツール登録:my_agent に“使えるよ”と知らせ、executor が実行
    @my_agent.register_for_llm(description="Generate and return a dummy reservation code.")
    @executor.register_for_execution()
    def make_reservation_tool() -> str:
        """ダミーの予約コードを生成して返す。"""
        return f"R-{random.randint(1000, 9999)}"

# =========================
# CLI Runner
# =========================
def run_cli() -> None:
    """簡易CLIループ。'exit', 'quit', 'q' で終了。"""
    print("AIエージェントとの対話を開始します。終了するには 'exit' と入力してください。")
    print("レストラン予約についてお聞かせください:")

    while True:
        user_input = input("\\nYOU: ").strip()

        if user_input.lower() in {"exit", "quit", "q"}:
            print("対話を終了します。")
            break

        try:
            # 人の入力を毎ターン渡す(内部で必要ならツールを呼ぶ)
            response = executor.initiate_chat(
                recipient=my_agent,
                message=user_input,
                max_turns=3,
                clear_history=False,  # 履歴を保持して継続
                summary_method="last_msg",
            )

            # helpful_agent の最新発話だけ拾って表示
            msg = None
            for m in reversed(response.chat_history or []):
                if m.get("name") == "helpful_agent" and m.get("content"):
                    msg = m["content"]
                    break
            print(f"\\nAI: {msg or response.summary or '(no response)'}")
        except Exception as e:
            print(f"エラーが発生しました: {e}")

if __name__ == "__main__":
    run_cli()

    

PydanticAI

Pythonのデータバリデーションライブラリ「Pydantic」の作者によるエージェント開発フレームワーク。型安全性や検証機能を備え、プロダクション品質に着目しているのが特徴。

Pythonのデータバリデーションライブラリ「Pydantic」を中核に据えたエージェントフレームワークです。OpenAIやLangChainなど主要LLMライブラリの内部でもPydanticが使われていることから着想を得ており、Pythonicな型定義と検証でLLM出力を扱いやすくし、「テストしやすく保守しやすいAIエージェント」を作るのに適したフレームワークです。

【メリット】

  • Pythonエンジニアにとって馴染み深い文法・思想で設計されています。

  • OpenAIやAnthropic、Cohere、Mistralなど主要モデルを統一的にサポートし、他モデルの追加もシンプルなインターフェースで可能です。

  • 出力をPydanticモデルで構造化・バリデーションできるため、LLMの応答を検証してから次の処理に渡すといった厳密な制御が行えます。

  • 依存性注入によってツールやデータソースをエージェントのシステムプロンプト等に供給する仕組みや、応答のストリーミング処理、型ヒントでエージェント同士のグラフを定義できるPydantic Graph機能など、ユニークな機能が揃っています。

デメリット】

  • 型定義や検証を多用する分、初期セットアップに手間がかかるケースもあります。例えば期待する応答フォーマットをPydanticのBaseModelクラスで設計する必要があり、プロンプトエンジニアリングとは別の知識も要求されます。

  • 動的なエージェント対話というよりは決められた入力・出力形式を持つタスク指向のワークフローに向いているため、雑多なフリーフォーム対話にはオーバーヘッドになる可能性があります。

  • 登場して間もないフレームワークなので機能拡充も続いており、安定稼働させるには開発者側での検証が必要です。

■実装例

# pip install "pydantic-ai-slim[openai]"==0.7.4

import random

from pydantic_ai import Agent, RunContext
from pydantic_ai.messages import ModelMessage

# =========================
# Config
# =========================
MODEL_NAME = "openai:gpt-4o-mini"

# =========================
# Agent
# =========================
reservation_agent = Agent(
    MODEL_NAME,
    system_prompt=(
        "あなたはレストラン予約を手伝うアシスタントです。"
        "ユーザーの要望(日付・時間・人数・ジャンル・特別要望)を確認し、"
        "必要なら予約コード発行ツールを呼び出して応答してください。"
    ),
)

# =========================
# Tools
# =========================
@reservation_agent.tool
def make_reservation_tool(ctx: RunContext) -> str:
    """ダミーの予約コードを生成して返す。"""
    return f"R-{random.randint(1000, 9999)}"

# =========================
# CLI
# =========================
def run_cli() -> None:
    print("AIエージェントとの対話を開始します。終了するには 'exit' と入力してください。")
    print("レストラン予約についてお聞かせください:")

    history: list[ModelMessage] = []  # 会話履歴を保持

    while True:
        user_input = input("\\nあなた: ").strip()
        if user_input.lower() in {"exit", "quit", "q"}:
            print("対話を終了します。")
            break

        try:
            result = reservation_agent.run_sync(user_input, message_history=history)
            print(f"\\nAI: {result.output}")

            # この会話ターンで増えた分だけ追記
            history.extend(result.new_messages())
        except Exception as e:
            print(f"\\nエラーが発生しました: {e}")

if __name__ == "__main__":
    run_cli()

    

最後に

「最適なフレームワーク」はユースケース次第というのが正直な結論です。それぞれに強みがあり一概に優劣はつけられませんが、最後に用途別の選択指針をまとめます。

  • 社内システムに統合する対話エージェント:自社のクラウド戦略に合わせて、Google Cloud中心ならADK、AWS環境ならStrandsを検討すると良いでしょう。ADKは既存のデータベースやAPI群との統合がしやすく 、エンタープライズ機能も豊富です。

  • 外部ツール連携が肝になるエージェント:複雑なツールチェーンを組むならLangChain/LangGraphやPydanticAIが候補です。LangChainは既成ツールが豊富 で、検索・計算・DB操作など色々試せます。PydanticAIはツールを型安全に扱える利点があり 、テスト駆動でしっかり作り込みたい場合に向いています。

  • マルチエージェントによる問題解決:複数のAIに役割分担させたいなら、AG2などが最適です。特に協調作業が重要なケース(例:異なる専門知識を持つAI同士の対話)では実装が比較的楽になる印象です。

  • 高性能・大規模なエージェントシステム:パフォーマンス最優先ならAgnoが有力です。大量のエージェントを同時稼働させるような場合でもボトルネックになりにくく 、リソース効率で群を抜きます。逆に多少のオーバーヘッドより開発生産性を重視するなら、多少重めでもLangChain系やAutoGen系の方が開発が楽なこともあります。

「小規模PoCならAgno/PydanticAI」「本番運用ならADK/OpenAI SDK」「研究開発ならLangChain/LangGraph」などのおすすめはあるものの、自分のプロジェクトに必要な要素(スピードなのか制御性なのか、はたまた将来の拡張性か)を見極めることが重要です。場合によっては「あえてフレームワークに頼らず」基本となる設計パターンを自前で実装してみることも、エージェント開発力を高める良い経験になります。本記事の比較が、読者の皆様が最適なツールを選び出す一助となれば幸いです。

参考📖

 

 

 

ご質問・お問い合わせは
こちらよりお送りください
採用
ARISE analyticsとは

PAGE TOP