フレームワーク選定ガイド：LangChain / AutoGen / CrewAI / ADK / OpenAI Agents SDKで始めるAIエージェント開発

はじめに

こんにちは、次世代システム研究室のK.X.Dです。

ChatGPT などの大規模言語モデル（Large Language Model）を業務に使おうとすると、必ずぶつかるのが「AI エージェント（AI agent）をどのフレームワーク（framework）で実装するか」という問題です。
LangChain、AutoGen、CrewAI、ADK（Agent Development Kit）、OpenAI Agents SDK……名前はよく聞くけれど、実際にどこが違って、どんなケースでどれを選べばよいのかは、意外とわかりづらいところです。

特に最近は、単純なチャットボットを超えて、外部 API やデータベースと連携したり、RAG（Retrieval-Augmented Generation）で社内ナレッジを検索したり、複数のエージェントが協調して動くマルチエージェント（multi-agent）型のワークフロー（workflow）を組んだりと、要件はどんどん高度になっています。
その一方で、「まずは PoC を素早く作りたい」「でも将来の本番運用も見据えたい」という現場のニーズはシビアです。

本記事では、実務でよく名前の挙がる 5 つの AI エージェントフレームワーク：

• LangChain

• AutoGen

• CrewAI

• ADK（Agent Development Kit）

• OpenAI Agents SDK

を取り上げ、それぞれの実装コンポーネント（implementation components）・アーキテクチャ（architecture）・オーケストレーション（orchestration）の仕組みを比較していきます。

目次

1. フレームワークの概要

2. コンポーネント・仕組みの比較

3. 強み・弱み・導入メリット

4. 活用事例

5. まとめ

1. フレームワークの概要

1-1. LangChain（ランチェーン）

• 開発元: langchain-ai コミュニティ

• 主な言語: Python / JavaScript

• 位置づけ:

  • LLM アプリ・エージェントのための総合フレームワーク (general-purpose LLM framework)。

  • ツール (tools)、チェーン (chains)、エージェント (agents)、メモリ (memory)、RAG (retrieval-augmented generation) などを包括的に提供。

• 特徴:

  • create_agent によるツール呼び出しループ型 (tool-calling loop) のエージェント構築。

  • LangGraph と組み合わせることで、複雑なワークフロー (complex workflows) やマルチエージェントも構築可能。

1-2. AutoGen（オートジェン）

• 開発元: Microsoft Research

• 主な言語: Python

• 位置づけ:

  • マルチエージェント協調 (multi-agent collaboration) に特化したフレームワーク。

• 特徴:

  • 基本ユニットは ConversableAgent (会話可能エージェント)。メッセージの送受信と応答生成を担う。

  • エージェント同士がチャット形式で議論し、ツール・コード実行 (code execution)・人間参加 (human-in-the-loop) を組み合わせてタスクを解く。

  • 最近は Microsoft Agent Framework へのマイグレーションガイドも公開されており、将来的にはそちらが本命になる可能性もある。

1-3. CrewAI（クルーエーアイ）

• 開発元: CrewAI Inc.

• 主な言語: Python

• 位置づけ:

  • ロールプレイ型マルチエージェント (role-playing multi-agent automation) に特化したフレームワーク。

• 特徴:

  • 3 つの主要コンポーネント：

    • Agent：役割・ペルソナ・スキルを持つエージェント。

    • Task：ゴール・期待アウトプットを定義したタスク。

    • Crew：複数の Agent と Task を束ねる実行単位（プロジェクトチームのイメージ）。

  • プロセスは sequential / hierarchical などのプロセス制御 (process control) で定義。

  • YAML ベースのプロジェクトテンプレートもあり、ノーコード寄りの構成管理 (config-driven setup) も可能。

1-4. ADK（Agent Development Kit）

• 開発元: Google（Vertex AI Agent Builder の一部）

• 主な言語: Python / Go / Java

• 位置づけ:

  • ビルド・評価・デプロイ (build / evaluate / deploy) まで含めたエンドツーエンドなエージェント開発基盤。

• 特徴:

  • LlmAgent (LLM エージェント) と Tools (ツール) を軸に、
    Agent / Tools / Tasks / Orchestrators / Memory / Schemas / Evaluation / Deployment といったコンポーネントを提供。

  • Vertex AI Agent Engine へのデプロイと密結合しており、1 コマンドで本番エンドポイントに乗せる (one-command deployment) ワークフローがある。

1-5. OpenAI Agents SDK

• 開発元: OpenAI

• 主な言語: Python / TypeScript

• 位置づけ:

  • Swarm の後継として設計された、軽量・少数プリミティブ志向のエージェント SDK (lightweight agent SDK)。

• 特徴:

  • コアプリミティブ：

    • Agent：LLM + instructions + tools + guardrails。

    • Tool：Python 関数・ホストツール (web, retrieval, computer use)など。

    • Runner：エージェントループを回す実行エンジン。

    • Session：会話履歴の自動管理 (session memory)。

    • Handoff：エージェント間のバトン渡し (handoff / sub-agent)。

  • トレース (tracing)、ガードレール (guardrails)、Temporal 連携による長時間ワークフロー (long-running workflows) など、実運用に必要な機能が標準で入っている。

3-1. LangChain

強み

• 圧倒的なエコシステム：RAG, vector store, retriever, tools など部品が豊富 (rich components)。

• LangGraph と組み合わせることで、高度な状態管理付きワークフロー (stateful workflows) / マルチエージェントも構築可能。

弱み

• 学ぶコンポーネントが多く、シンプルなユースケースにはオーバーキル (overkill) に感じることも。

• エージェント部分だけ欲しい場合、他の軽量 SDK（OpenAI Agents など）の方がスッキリ書けることもある。

導入メリット

• 既に RAG やツール群を LangChain で構築している場合。

• エージェントだけでなくLLM アプリ全体のパイプライン (end-to-end pipeline) を一つで揃えたいとき。

3-2. AutoGen

強み

• マルチエージェントによる協調問題解決 (collaborative problem solving) パターンが豊富。

• コード実行・ツール利用・人間参加を組み合わせた「実験的プロトタイプ」を作りやすい。

弱み

• エージェント間の会話設計やプロンプト設計が複雑になりやすい。

• Microsoft Agent Framework への移行ガイドが出ているため、将来のメインストリームがそちらに移るリスク (migration risk) がある。

導入メリット

• 研究・PoC で、**「エージェント同士が議論して解決する」**パターンを色々試したいとき。

• Microsoft エコシステムへの移行を視野に入れた実験環境として。

3-3. CrewAI

強み

• 「Agent + Task + Crew」というメンタルモデルが直感的で、業務プロセス (business process) をそのままモデリングしやすい。

• マルチエージェント自動化に特化しており、リサーチ・ライティング・要約などのパイプライン化が得意。

弱み

• LangChain や ADK と比べると、RAG / DB 連携 / 評価まわりは自前実装が多くなりがち。

• エコシステム規模はまだ LangChain ほど大きくない。

導入メリット

• マーケ・リサーチ・コンテンツ制作など、「役割ごとのメンバーで構成されたチーム作業」を自動化したい場合。

• コード量少なめでマルチエージェントを動かしたい場合。

3-4. ADK

強み

• ビルド〜評価〜デプロイまでカバーするエンタープライズ向け設計。

• Evaluation Framework により、ツール呼び出しの軌跡や最終出力を自動テスト (automated evaluation) できる。

• Vertex AI Agent Engine を使ったマネージド運用 (managed runtime) と、GCP セキュリティ機能との連携。

弱み

• GCP / Gemini 前提のドキュメントが多く、クラウド前提のセットアップ (cloud-first setup) になる。

• シンプルな PoC だけなら、OpenAI Agents や LangChain のほうがセットアップは軽い。

導入メリット

• 既に GCP / Vertex AI を採用している企業で、本番運用を見据えた大規模エージェントを作りたい場合。

• エージェントに対して自動テスト・品質保証 (QA for agents) をしっかり回したいとき。

3-5. OpenAI Agents SDK

強み

• プリミティブが少なく、学習コストが低い (low learning curve)。Agent と Runner と Tool を押さえればかなり戦える。

• Hosted tools（web 検索・retrieval・computer use）やガードレール、トレースなど、実運用に必要な機能が最初から入っている

• OpenAI 以外の LLM もサポートしており、プロバイダ非依存 (provider-agnostic) な設計。

弱み

• LangChain のような「RAG 用コンポーネント」「多様な外部連携」は自前で組む必要がある。

• 完全に自由なグラフワークフローを組みたい場合は、LangGraph や ADK のほうが記述力が高い。

導入メリット

• 「まずは OpenAI モデルでエージェントをサクッと本番運用したい」というケース。

• Guardrails や Hosted tools を活用しつつ、ミニマルな構成で堅牢なエージェントを作りたい場合。

4. 活用事例

4-1. 代表的な活用事例と向いているフレームワーク

事例 A：社内ナレッジベース + RAG チャットボット

• 適したフレームワーク:

  • LangChain + LangGraph

• 理由（コンポーネント観点）:

  • Vector store、retriever、document loader など、RAG に必要な部品が最初から揃っている。

  • LangGraph で、検索 → 要約 → フォーマット整形などをステップごとのノードに分解可能。

事例 B：コード生成・レビューを行う AI ペアプログラマチーム

• 適したフレームワーク:

  • AutoGen または CrewAI

• 理由:

  • AutoGen：

    • Coder / Reviewer / Tester など複数エージェントが、チャット形式でコードを叩き合いながら改善できる。

  • CrewAI：

    • 「設計者」「実装者」「レビュアー」などを Agent + Task として定義し、Crew が順に実行するパターンが書きやすい。

事例 C：エンタープライズ向けカスタマーサポートエージェント（評価込み）

• 適したフレームワーク:

  • ADK + Vertex AI Agent Engine

• 理由:

  • エージェントの評価フレームワーク (evaluation framework) で、サポートフローをテストケース化できる。

  • Agent Engine でのマネージドデプロイにより、可観測性・スケーラビリティ・セキュリティを GCP ベースで確保できる。

事例 D：ツールを使って外部 API にアクセスしつつ、安全に実運用したい Web アプリ

• 適したフレームワーク:

  • OpenAI Agents SDK（＋ 必要に応じて LangChain/自前コード）

• 理由:

  • Hosted tools + function tools で、外部 API や DB を手軽に利用できる。

  • Guardrails・トレース・Temporal 連携などにより、安全性 (safety) と 運用監視 (observability) を最初から組み込める。

4-2. なぜその事例に向くのか（まとめ）

• LangChain：

  • 「RAG・ツール・ワークフロー」という広い面 (broad surface area) を一つで支えられるため、「社内知識 + 外部ツール」型のチャットボットに向く。

• AutoGen / CrewAI：

  • マルチエージェントを前提とした設計なので、「複数の専門家が議論して答えを出す」スタイルのワークに強い。

• ADK：

  • Agent、Tools、Evaluation、Deployment まで一気通貫で設計されているため、本番運用・品質保証まで含めて考えたいエンタープライズ案件に向く。

• OpenAI Agents SDK：

  • 極力シンプルなプリミティブで、Guardrails と Hosted tools を備えたミニマルだけど実戦的 (minimal yet production-ready) なエージェントが作れるため、Web アプリと組み合わせやすい。

4-3. サンプル実装

4-3-1. LangChain

• ツール(tool) を @tool で定義

• チャットモデル(chat model) を ChatOpenAI でラップ

• エージェント(agent) を create_tool_calling_agent で構成

• エージェント実行器(agent executor) が LLM＋ツールをまとめて実行

# langchain_langchain_agent_sample.py
import os
from langchain_openai import ChatOpenAI  # LLM ドライバ(driver)
from langchain_core.tools import tool    # ツール定義(tool definition)
from langchain_core.prompts import ChatPromptTemplate
from langchain.agents import create_tool_calling_agent, AgentExecutor

# 1. ツール(tool)層：LLMが呼び出す関数
@tool
def multiply(x: float, y: float) -> float:
    """Multiply x and y."""
    return x * y

# 2. プロンプト(prompt)層：エージェントの振る舞い
prompt = ChatPromptTemplate.from_messages(
    [
        ("system", "あなたは計算が得意なアシスタントです。"),
        ("human", "{input}"),
        ("placeholder", "{agent_scratchpad}"),  # 中間ステップ(history of tool calls)
    ]
)

tools = [multiply]

# 3. モデル(model)層：チャットモデル
llm = ChatOpenAI(
    model="gpt-4o-mini",
    temperature=0,
    api_key=os.environ.get("OPENAI_API_KEY"),
)

# 4. エージェント(agent)層：LLM＋ツール＋プロンプトを束ねる
agent = create_tool_calling_agent(llm, tools, prompt)

# 5. エージェント実行器(agent executor)層：入出力を統一
agent_executor = AgentExecutor(
    agent=agent,
    tools=tools,
    verbose=True,  # 思考過程やツール呼び出しログを表示
)

if __name__ == "__main__":
    result = agent_executor.invoke({"input": "3 と 5 の掛け算をしてください。"})
    # AgentExecutor は {"output": "..."} の dict を返す
    print("=== LangChain Agent Result ===")
    print(result["output"])

@tool で「外界にアクセスする手」となるツール

ChatOpenAI でモデル層

create_tool_calling_agent でエージェント層

AgentExecutor で実行と状態管理

4-3-2. CrewAI

• エージェント(Agent) → 振る舞いと役割

• タスク(Task) → やるべき仕事の定義

• クルー(Crew) → それらを束ね、順序を制御するオーケストレータ(orchestrator)

# crewai_arch_sample.py
import os
from crewai import Agent, Task, Crew

# 1. エージェント定義(agent definitions)
math_agent = Agent(
    role="Math Specialist",
    goal="ユーザーの数値計算を正確に行うこと。",
    backstory="あなたは計算が得意な数学の専門家です。",
    llm="gpt-4o-mini",  # CrewAI はモデル名を文字列で受け取るスタイル
)

# 2. タスク定義(task definition)
calc_task = Task(
    description="2 と 5 の掛け算結果を日本語で説明してください。",
    expected_output="自然な日本語で計算過程と答えを説明するテキスト。",
    agent=math_agent,
)

# 3. クルー定義(crew = orchestration)
crew = Crew(
    agents=[math_agent],
    tasks=[calc_task],
)

if __name__ == "__main__":
    result = crew.kickoff()
    print("=== CrewAI Result ===")
    print(result)

アーキテクチャとして

Agent：ロール(role)＋ゴール(goal)＋バックストーリー(backstory)

Task：仕事内容の粒度

Crew：どのエージェントがどのタスクを担当するか、という「舞台監督」

4-3-3. OpenAI Agents SDK

• Agent(エージェント) クラスに

  • instructions(命令)

  • tools(ツール)

  • 必要なら handoff(ハンドオフ) を設定

• Runner(ランナー) がエージェントを起動・実行し、ツール呼び出しなどをよしなに扱う

# openai_agents_arch_sample.py
import os
from agents import Agent, Runner, function_tool  # Agents SDK のメインコンポーネント

# 1. ツール(tool)をデコレータで定義
@function_tool
def multiply(x: float, y: float) -> float:
    """Multiply x and y."""
    return x * y

# 2. エージェント(agent)定義
math_agent = Agent(
    name="math_agent",
    instructions="あなたは計算が得意なアシスタントです。ユーザーの数値計算を手伝ってください。",
    tools=[multiply],
    model="gpt-4.1-mini",  # Responses API 互換モデルを指定
)

if __name__ == "__main__":
    # 3. Runner(ランナー)でエージェントを実行
    runner = Runner(
        agents=[math_agent],
        api_key=os.environ.get("OPENAI_API_KEY"),
    )

    # シンプルな1プロンプト実行
    result = runner.run_sync(
        agent=math_agent,
        input="2 と 5 の掛け算をしてください。",
    )

    print("=== OpenAI Agents SDK Result ===")
    print(result.output_text)

アーキテクチャとして

Agent：モデル＋ツール＋指示を1つの単位にまとめる

function_tool：ツールを JSON スキーマ付きで公開(function-calling tool)

Runner：Responses API への問い合わせ・ツール実行・ハンドオフ管理などの共通処理

4-3-4. Google ADK

• Agent クラスにツール群を渡して「ルートエージェント(root agent)」を定義

• ADK の Runner(ランナー) / Dev UI や API Server がこのルートエージェントを実行

• 「コードファースト(code-first)」で、関数＝ツール(function tool) を直に渡すスタイル

# adk_arch_sample/multi_tool_agent/agent.py
import datetime
from zoneinfo import ZoneInfo
from google.adk.agents import Agent  # ADK のエージェントクラス

# 1. ツール(tool)関数 定義

def get_current_time(city: str) -> dict:
    """Dummy current time tool."""
    if city.lower() == "tokyo":
        tz = ZoneInfo("Asia/Tokyo")
        now = datetime.datetime.now(tz)
        return {
            "status": "success",
            "report": f"Tokyo 現在時刻は {now.strftime('%Y-%m-%d %H:%M:%S %Z')} です。",
        }
    return {
        "status": "error",
        "error_message": f"{city} の時刻情報はありません。",
    }


def multiply(x: float, y: float) -> dict:
    """Simple multiply tool."""
    return {
        "status": "success",
        "result": x * y,
        "report": f"{x} × {y} = {x * y}",
    }


# 2. ルートエージェント(root_agent) 定義
root_agent = Agent(
    name="time_and_math_agent",
    model="gemini-2.0-flash",
    description="時刻と簡単な計算に答えるエージェント。",
    instruction="ユーザーの質問に応じて、必要に応じてツールを呼び出してください。",
    tools=[get_current_time, multiply],  # Python 関数をそのまま tools として渡す
)

アーキテクチャとして

root_agent が「アプリケーションエントリの定義」

Runner / Dev UI / Agent Engine が別コンポーネントとしてこの定義を読み込み実行

ツールは Python 関数(function tool) そのもの

4-3-5. AutoGen

• ユーザープロキシエージェント(UserProxyAgent) と アシスタントエージェント(AssistantAgent) の対話

• それ自体が ワークフロー(workflow) になっているのが特徴

• マルチエージェント(multi-agent) を前提にした設計

# autogen_arch_sample.py
import os
from autogen import AssistantAgent, UserProxyAgent  # v0.2 系の典型クラス

# 1. LLM 設定（llm_config）
llm_config = {
    "config_list": [
        {
            "model": "gpt-4o-mini",
            "api_key": os.environ.get("OPENAI_API_KEY"),
        }
    ],
    "cache_seed": None,  # キャッシュ無効化（毎回違う応答）
}

# 2. アシスタントエージェント(assistant agent)：タスク実行担当
assistant = AssistantAgent(
    name="assistant",
    llm_config=llm_config,
    system_message="あなたは親切なAIエージェントです。ユーザーの質問に丁寧に答えてください。",
)

# 3. ユーザープロキシエージェント(user proxy agent)：
#    人間の代わりに会話を開始し、終了条件を管理
user_proxy = UserProxyAgent(
    name="user_proxy",
    human_input_mode="NEVER",  # 自動実行モード
    code_execution_config=False,
    is_termination_msg=lambda msg: (
        msg.get("content") is not None and "TERMINATE" in msg["content"]
    ),
)

if __name__ == "__main__":
    # 4. エージェント間の対話(orchestration)を開始
    user_proxy.initiate_chat(
        assistant,
        message=(
            "2 と 5 の掛け算の結果を教えてください。"
            "最後に 'TERMINATE' と書いて会話を終了してください。"
        ),
    )

    print("=== AutoGen Conversation Finished ===")

アーキテクチャとして、

AssistantAgent（タスク実行）

UserProxyAgent（ユーザの代理＋停止条件管理）

initiate_chat が「会話フロー」をドライブ

5. まとめ

• 設計の柔軟さとエコシステムを重視するなら LangChain (+ LangGraph)。

  • 公式ページ：https://www.langchain.com/

• マルチエージェント協調に集中したいなら AutoGen / CrewAI。

  • 公式ページ
    • AutoGen：https://microsoft.github.io/autogen/stable//index.html
    • CrewAI：https://www.crewai.com/

• エンタープライズでの評価・デプロイまで込みのライフサイクルを考えるなら ADK。

  • 公式ページ：https://google.github.io/adk-docs/

• OpenAI モデルを中心に、軽量な実運用エージェントを作るなら OpenAI Agents SDK が現状かなりバランスが良い選択肢です。

  • 公式ページ：https://platform.openai.com/docs/guides/agents-sdk

実際のプロジェクトでは、

• 「今どのクラウド／モデルを使っているか」

• 「PoC か、本番運用か」

• 「単一エージェントか、マルチエージェントか」

あたりを軸に、この記事の比較表をマッピングしながら選ぶのが現実的だと思います。

宣伝

次世代システム研究室では、アプリケーション開発や設計を行うアーキテクトを募集しています。アプリケーション開発者の方、次世代システム研究室にご興味を持って頂ける方がいらっしゃいましたら、募集職種一覧 からご応募をお願いします。
皆さんのご応募をお待ちしています。