AIエージェントフレームワークとは？主要8種の比較・動作コード・選定基準【2026年9月版】

AIエージェントをゼロから実装すると、ツール呼び出しの制御・会話状態の保持・複数エージェントの協調といった共通処理を毎回自前で書くことになります。この共通部分を肩代わりする基盤がAIエージェントフレームワークです。本記事ではLangChain・LangGraph・CrewAI・AutoGen・Google ADK・Strands Agents・Mastra・OpenAI Agents SDKの主要8種を、2026年9月30日時点のPyPI・npm実測バージョンつきで比較します。対応言語やマルチエージェント対応といった選定基準に加えて、最小構成のエージェントを実際に動かすコード、受託開発の現場で「どの案件ならどれを選ぶか」「そもそも使わない判断」まで踏み込んで整理しました。

まとめ｜AIエージェントフレームワーク選定の結論

結論から示します。Pythonで複雑な分岐や状態制御まで見据えるならLangGraph、役割分担型のマルチエージェントを短期間で組むならCrewAI、AWS中心の本番運用ならStrands Agents、TypeScriptのWebアプリに組み込むならMastraが第一候補です。エコシステムの広さで選ぶならLangChain、Google Cloud前提ならADKが有力になります。

AutoGenは2026年9月時点でGitHubのREADMEに保守モード（新機能の追加なし）と明記されました。Microsoft系の技術で新規に組むなら、後継のMicrosoft Agent Frameworkを評価対象に置き換えてください。

逆に、決まった順序でLLMを数回呼ぶだけの処理にフレームワークは過剰です。各社のAPIを直接呼ぶ数十行の実装で足り、依存関係の更新負担だけが残ります。採用するかどうかの分岐は「実行時にLLM自身が次の行動を決める必要があるか」で判定してください。この判断基準の根拠と各候補の詳細、動かすためのコードを、以下で順に説明します。

AIエージェントフレームワークとは何か：役割と構成要素の基礎

AIエージェントフレームワークは、LLMに外部ツールの操作と自律的な反復判断をさせるための共通実装をまとめたライブラリ群です。エージェントという概念そのものや業務に組み込むかどうかの経営判断はAIエージェントの仕組みと導入判断の解説記事で扱っているため、本記事は実装者向けに技術面へ絞ります。

LLM単体とAIエージェントを分ける自律ループと外部ツール接続

LLM単体の呼び出しは「入力を渡して出力を受け取る」一往復で完結します。AIエージェントはこれと異なり、モデルの出力からツール呼び出しを解釈して実行し、その結果を再びモデルに渡す反復構造を持ちます。この反復が終了条件を満たすまで続く構造はエージェントループの設計解説で詳述している通り、実装の中核です。自前で書くと、ツール呼び出しのパース・例外時の再試行・無限ループ防止・トークン上限管理をすべて自分で設計することになります。フレームワークはこの反復構造を検証済みの形で提供し、開発者はツール定義とプロンプト設計に集中できます。

フレームワークが肩代わりする状態管理・オーケストレーションの実装

主要フレームワークが共通して提供する機能は次の通りです。

• ツール定義：関数のスキーマ化と引数の型検証
• 状態管理：会話履歴・中間結果の保持と永続化
• オーケストレーション：複数エージェント間の協調・委譲制御
• 観測性：実行トレースの記録と可視化
• ガードレール：入出力の検査と実行権限の制限

どこまでを標準機能として持つかは製品ごとに差があります。たとえば状態のグラフ制御はLangGraphの、役割ベースの協調はCrewAIの得意領域で、この差が後述の選定基準に直結します。

主要AIエージェントフレームワーク8種の特徴と実測バージョン比較

比較対象は、受託開発の技術選定で候補に挙がる頻度が高い8種に絞りました。バージョンは2026年9月30日にPyPIとnpmレジストリで実測した値を「x.y系」表記で示します。7月の初版時点から2か月で大半が版を進めており、採用時は必ず一次情報で再確認してください。

主要8種の開発元・対応言語・マルチエージェント対応の一覧比較表

まず全体像を一覧で示します。詳細は次のh3以降で系統ごとに解説します。

OpenAI Agents SDKの版はPython版で、TypeScript版の@openai/agentsは0.18系です。マルチエージェント対応は8種すべてが何らかの形で備えており、対応の有無ではなく「協調の表現方法」が違いになります。委譲型・グラフ型・役割型・メッセージ型のどれが案件の構造に合うかを見る必要があります。

2026年9月の実測で変わったAutoGen保守モード移行と各版の更新幅

7月の初版から最も大きく動いたのはAutoGenの位置づけです。AutoGenのGitHubリポジトリのREADMEには、保守モードに入り新機能や機能強化を受け付けず、今後はコミュニティ管理になる旨が明記されています。同じREADMEが新規ユーザーにはMicrosoft Agent Frameworkから始めるよう案内し、既存ユーザー向けにAutoGenからの移行ガイドを公開しています。PyPIの実測でもautogen-agentchatは2025年9月30日公開の0.7.5が最終で、1年間更新がありません。一方のagent-frameworkは1.19系まで進んでいます。

更新幅も確認しておきます。Strands Agentsは2か月で1.48系から1.57系へ、Mastraのコアは1.51系から1.71系へ、Google ADKは2.5系から2.10系へ進みました。月に数回のペースでマイナー版が出る製品が多く、要件定義の段階で「版を固定する期間」と「追随する頻度」を決めておかないと、保守見積もりが崩れます。版番号の最新値はPyPIのLangGraphページのような公式レジストリで確認するのが確実です。

LangChain・LangGraph：エコシステム最大の定番と状態グラフ制御

LangChainは2022年公開のLLMアプリケーション基盤で、2025年10月に1.0へ到達し、実測時点で1.4系です。モデル・ベクトルDB・外部サービスへの接続部品が数百規模で揃っており、接続先の多さでは他の追随を許しません。同じLangChain社のLangGraphは、エージェントの実行フローをノードとエッジのグラフで宣言する設計で、1.2系まで進んでいます。LangGraphの公式ドキュメントが示す通り、条件分岐・並列実行・人間の承認を挟むヒューマンインザループをグラフ上で明示でき、チェックポイントによる状態永続化も標準です。1.0以降は両者の役割分担が入れ替わっており、その経緯はLangChainとLangGraphの違いとv1.0で逆転した関係で整理しています。実行経路が複雑で「どこで止まり、どこから再開するか」を厳密に制御したい業務システムでは、2026年時点で最も実績のある選択肢です。学習コストは8種の中で高い部類に入る点だけ織り込んでください。

CrewAI・AutoGen：マルチエージェント協調に強い2系統の比較

CrewAIは役割・目標・背景を宣言してエージェントの「チーム」を組む設計で、1.15系まで更新が続いています。記述量が少なく、役割分担が明確な定型業務の自動化を数日で形にできる立ち上がりの速さが持ち味です。基本概念はCrewAIの公式ドキュメントにまとまっており、仕組みの詳細と採用判断はCrewAIのAgent・Task・Crew構造の解説記事にまとめています。一方のAutoGenはMicrosoft発の非同期メッセージ型で、エージェント同士の自由な対話・議論を通じた問題解決に向きますが、前述の通り保守モードに入りました。v0.4以降の構成と現在地はAutoGenの現在地とv0.4以降の選び方で扱っています。新規案件でMicrosoft系を選ぶなら、Semantic KernelとAutoGenを統合した後継をMicrosoft Agent Framework 1.0の解説記事で確認したうえで評価してください。

Google ADK・Strands Agents：クラウド事業者製SDKの強み

クラウド事業者製の2種は、自社クラウドの運用基盤との統合が売りです。Google ADK（Agent Development Kit）はPython版が2.10系まで進み、エージェント間通信プロトコルA2AやVertex AIへのデプロイ機構と組み合わせて使えます。公式ドキュメントは2026年9月時点でadk.devへ移っており、旧URLのgoogle.github.io/adk-docs/からも自動で転送される状態です。基本構造はGoogle ADKの概要解説記事で確認できます。AWSのStrands Agentsは「モデル駆動」を掲げるOSSで、プロンプトとツール定義を渡せばループ制御をモデル側の判断に委ねる薄い設計が特徴です。1.57系まで更新が続き、Strands Agentsの公式サイトの通りMCPサーバーをツール源として直接接続できます。使い方の実際はStrands Agentsの使い方解説記事を参照してください。既存インフラがGoogle CloudかAWSに寄っているなら、同じ事業者製SDKを第一候補に置くのが運用面で合理的です。

Mastra・OpenAI Agents SDK：TypeScript／軽量派の選択肢

MastraはTypeScript製で、Zodスキーマによる型安全なツール定義とワークフロー機構を備え、コアパッケージの@mastra/coreは1.71系に達しています。Next.jsなどWebフロントエンドと同一言語で完結するため、Webシステムへのエージェント組み込みで開発体験が良く、Mastraの公式ドキュメントに加えてMastraのSkillsとワークフロー解説記事で詳細を扱っています。OpenAI Agents SDKは2025年3月公開の軽量SDKで、Python版の実測は0.22系です。handoffと呼ぶエージェント間委譲・ガードレール・トレーシングを最小限のAPIで提供し、OpenAIモデル中心の構成なら数時間で動く形になります。想定される利用場面はOpenAI Agents SDKの概要と利用場面の解説記事で紹介しています。抽象化が薄いぶんフロー制御の表現力はLangGraphに及ばないため、単一〜少数エージェントの範囲で使うのが現実的です。

主要3種のフレームワークで最小エージェントを動かす手順とコード比較

比較表だけでは書き味の差は分かりません。ここでは同じ「関数を1つ持つエージェント」をLangChainとOpenAI Agents SDKで書き、最後にどちらでも使い回せるツール層の切り出し方を示します。いずれもPython 3.10以上が前提で、実行には各モデル事業者のAPIキーを環境変数に設定します。

LangChainのcreate_agentでツール付きエージェントを動かす最小構成

LangChain 1.x系では、エージェントの生成がcreate_agent関数1つにまとまりました。LangChain公式のクイックスタートに沿った最小構成は次の通りです。

# インストール（2026年9月時点で1.4系が入る）
pip install -U langchain

# agent_langchain.py
from langchain.agents import create_agent

def get_weather(city: str) -> str:
    """指定した都市の天気を返す"""
    return f"{city}は晴れです"

agent = create_agent(
    model="openai:gpt-5.5",
    tools=[get_weather],
    system_prompt="あなたは簡潔に答えるアシスタントです",
)

result = agent.invoke(
    {"messages": [{"role": "user", "content": "大阪の天気は？"}]}
)
print(result["messages"][-1].content)

ポイントは、関数の型ヒントとdocstringがそのままツールのスキーマになる点です。create_agentの内部はLangGraphのグラフとして組まれているため、分岐や承認フローが必要になった時点でLangGraphの記法へ段階的に降りられます。状態管理から承認フローまでの実装手順はLangGraphでAIエージェントを実装する手順で続きを解説しています。

OpenAI Agents SDKの@toolで関数をツール登録する手順と実行

OpenAI Agents SDKは、AgentとRunnerの2つを覚えれば動きます。2026年9月時点の公式ドキュメントのツール解説では、関数ツールの登録にagents.decoratorsのtoolデコレータを使う記法が示されています。

# インストール（2026年9月時点で0.22系が入る）
pip install openai-agents
export OPENAI_API_KEY=sk-...

# agent_openai.py
from agents import Agent, Runner
from agents.decorators import tool

@tool
def get_weather(city: str) -> str:
    """指定した都市の天気を返す

    Args:
        city: 天気を調べる都市名
    """
    return f"{city}は晴れです"

agent = Agent(
    name="Assistant",
    instructions="あなたは簡潔に答えるアシスタントです",
    tools=[get_weather],
)

result = Runner.run_sync(agent, "大阪の天気は？")
print(result.final_output)

LangChain版との差は、実行の入口がRunnerに分かれている点と、エージェント間の委譲（handoff）をAgentの引数で宣言する設計にあります。コード量はほぼ同じで、違いが出るのは複数エージェントや分岐を足した段階です。基本の書き方はOpenAI Agents SDKの公式ドキュメントのクイックスタートで確認できます。

フレームワーク非依存のツール層を切り出して乗り換えに備える実装

上の2例は、どちらも「型ヒント付きの素の関数」をツールにしています。この性質を利用して、業務ロジックをフレームワークから独立したモジュールに置き、登録部分だけを製品ごとに書き分けるのが乗り換えに強い構成です。

# tools/weather.py（フレームワークを一切importしない）
def get_weather(city: str) -> str:
    """指定した都市の天気を返す"""
    # 実案件ではここで社内APIやDBを呼ぶ
    return f"{city}は晴れです"

# adapters/langchain_agent.py
from langchain.agents import create_agent
from tools.weather import get_weather

agent = create_agent(model="openai:gpt-5.5", tools=[get_weather])

# adapters/openai_agent.py
from agents import Agent
from agents.decorators import tool
from tools.weather import get_weather

agent = Agent(name="Assistant", tools=[tool(get_weather)])

ツール層のテストはフレームワークなしで書けるため、単体テストがLLMの応答揺れに左右されません。外部システムとの接続が多い場合は、ツール層をさらにMCPサーバーとして切り出す選択肢もあります。規格の全体像はModel Context Protocolの公式サイト、具体的な接続設計はAIエージェントにMCPで外部ツールを接続する実装手順で扱っています。

用途・言語・マルチエージェント対応で決めるフレームワーク選定基準

8種を横並びで悩むより、消去法で候補を2〜3種まで絞ってから深く検証するほうが選定は速く終わります。判断の順序を3段階で示します。

対応言語とチームスキルを起点に候補を絞り込む消去法の第一段階

最初の分岐は開発言語です。TypeScriptで完結させたいならMastraかOpenAI Agents SDKのJS版、それ以外の6種は実質Python前提になります。チームにPython経験者がいない状態でLangGraphを選ぶと、フレームワークとPythonの二重学習になり立ち上がりが遅れがちです。なお本記事の8種は自律ループを主眼に置いた枠組みで、検索と生成のパイプラインを明示的に配線したい案件ではHaystackとは？3.0の破壊的変更・パイプライン設計・LangChainとの選び分けのようなRAG寄りの選択肢も候補に入ります。既存システムがTypeScript中心の企業では、言語をまたがないだけで実装・運用の引き継ぎコストが目に見えて下がります。次の分岐はモデルとクラウドの制約です。契約上OpenAIモデルに限定されるならOpenAI Agents SDK、AWS内で完結させる要件ならStrands Agents、Vertex AI前提ならADK、Azureと.NETの資産が中心ならMicrosoft Agent Frameworkと、インフラ制約だけで候補は2種程度まで絞れます。

マルチエージェント構成とMCP対応の要否で分かれる本命の候補群

次に、単一エージェントで足りるか複数の協調が必要かを見ます。調査・執筆・検証のように役割が明確に分かれるならCrewAIの役割型が素直に書け、承認フローや条件分岐が絡む基幹業務ならLangGraphのグラフ型が向きます。エージェント同士の自由対話で解を探索する研究的な用途はAutoGen系の領分ですが、新規なら後継のMicrosoft Agent Frameworkで組むのが筋です。もう1つの軸が外部ツール接続の標準規格MCP（Model Context Protocol）への対応で、2026年時点では8種いずれも接続手段を持ちますが、Strands AgentsやMastraのようにMCPサーバーを第一級のツール源として扱う設計だと接続実装がほぼ不要になります。社内システムとの接続点が多い案件ほど、MCP対応の深さを比較項目に含めてください。

本番運用まで見据えた観測性・評価基盤とベンダーロックインの点検

PoCでは差が出ないのに本番で効くのが観測性と評価の基盤です。エージェントは同じ入力でも実行経路が揺れるため、トレースを記録して失敗パターンを特定できないと障害対応が成立しません。LangGraphはLangSmith、MastraはCloudやObservability機構、ADKは評価ツールを純正で持ち、Strands AgentsはOpenTelemetry準拠のトレースを出せます。純正基盤は便利な反面、商用SaaSへの依存がベンダーロックインの入口にもなります。点検すべきは「フレームワークを替えるとき、何を書き直すことになるか」です。前章のコードで示したようにツール定義とプロンプトを独立モジュールに分離しておけば、乗り換え時の書き直しはループ制御部分に限定でき、この構造はどのフレームワークを選んでも保険として機能します。

受託開発の現場で判断するフレームワーク採用条件と見送るべき場面

ここからは、開発を請け負う立場で案件に向き合うときの判断を条件つきで言い切ります。一般論の比較表だけでは決まらない部分です。

フレームワーク導入を見送るべき場面：単純ワークフローは過剰投資

処理の順序が事前に固定できるなら、フレームワークは使わない判断を推します。たとえば「問い合わせメールを分類し、テンプレートに沿って返信案を生成する」処理は、LLM呼び出し2回と条件分岐だけで書けます。ここにエージェント基盤を入れても、得られるのは使わない抽象化と、依存パッケージの更新追随という継続コストだけです。実測した8種のうち半数は公開から2年未満で、2か月で10以上のマイナー版を重ねた製品もあります。AutoGenのように主力製品が保守モードへ移る事態も起きました。この変化の速さは「実行時にLLMが行動を選ぶ必要がある処理」でだけ払う価値があるコストです。逆に、ツールの組み合わせが入力ごとに変わる・試行錯誤の反復回数が読めない処理は自前実装のほうが高くつくため、採用に切り替えます。

受託開発で採用する条件：PoCから本番までの移行パスで決める

案件でフレームワークを採用する条件は3つあります。第一に、PoCで作った資産が本番実装でそのまま生きること。CrewAIで検証しLangGraphで作り直す二度手間は、最初からLangGraphの最小構成で始めれば避けられます。第二に、納品後に顧客側で保守できること。発注側の情シスにPython経験者がいなければ、TypeScript製のMastraを選ぶか、マネージドなデプロイ先まで含めて設計に織り込みます。第三に、モデル切り替えの自由度が要件に合うこと。特定モデル前提の薄いSDKは初速が出る一方、モデル選定を後から変える案件では抽象層のある製品が安全です。この3条件を満たさない候補は、機能が魅力的でも外します。加えて、保守モードに入った製品は新規案件の候補から外すのが原則です。

内製と外部委託の分岐点：AIエージェント開発を外注する判断基準

フレームワークの習熟には、選定を含めて実務で数週間から数か月を要します。社内に機械学習やLLM実装の経験者がいて、エージェントを継続的に育てる体制を作れるなら内製が本筋です。逆に、初回リリースまでの期間が優先される・要件定義の段階から設計支援が必要という状況なら、実装経験のある開発会社への委託が総コストで有利です。一創ではAIエージェント開発の受託サービスとして、フレームワーク選定から実装・運用設計までを一貫して請けています。自社で作る場合の進め方はAIエージェントの作り方の3ルート解説が判断材料になるはずです。どちらのルートでも、本記事の選定基準はそのまま要件定義のチェック項目として使えます。

よくある質問

AIエージェントフレームワークの選定で、実装者からよく受ける質問に答えます。

フレームワークを使わずLLMのAPIを直接呼ぶ実装ではだめですか？

処理順序が固定ならAPI直接呼び出しで十分ですし、むしろ推奨です。フレームワークが必要になるのは、実行時にLLM自身がツール選択や反復回数を決める処理に限られます。その場合も、まず1エージェント＋ツール2〜3個の最小構成で始めて、協調が必要になった時点でマルチエージェント機構を足す段階的な導入が失敗しにくい進め方です。

2026年に初めて学ぶならどのフレームワークがおすすめですか？

目的次第です。エージェントの構造を理解する学習目的ならコード量の少ないCrewAIかOpenAI Agents SDKが向きます。業務システムへの組み込みまで見据えるなら、遠回りでもLangGraphを推します。状態管理・分岐・再開の概念は他のフレームワークにも通じる基礎になり、学んだ内容が製品を替えても無駄になりません。AutoGenは保守モードに入ったため、これから学ぶ対象には選ばないでください。

マルチエージェント構成はどの案件でも必要ですか？

必要ありません。実務の大半は単一エージェントで足り、複数化はプロンプトが肥大して役割を分けたくなった時点で検討すれば間に合います。早すぎるマルチ化はデバッグ対象を増やし、失敗原因の特定を難しくします。分割の目安は「1エージェントのツールが10個を超える」「性質の異なる責務が同居する」の2つです。

MCP対応はフレームワーク選定でどの程度重視すべきですか？

外部システムとの接続点が多い案件ほど重視してください。MCPは接続実装を規格化するため、対応が深いフレームワークなら社内DBやSaaSへの接続を既存のMCPサーバーで済ませられます。接続先が1〜2個で固定なら、対応の深さより開発言語や状態管理の適合を優先したほうが選定を誤りません。

フレームワークの乗り換えコストを抑える設計はありますか？

あります。ツール定義（外部システムを操作する関数群）とプロンプトをフレームワーク非依存のモジュールに分離し、フレームワーク固有のコードをループ制御と協調定義だけに限定する構造です。この分離ができていれば、乗り換え時の書き直しは全体の2〜3割に収まります。逆にツール定義を製品固有の記法で直書きすると、乗り換えはほぼ全面改修です。AutoGenからMicrosoft Agent Frameworkへ移る案件でも、この分離の有無が工数を大きく左右します。

関連記事

• マルチエージェントオーケストレーションとは：本記事で比較した協調制御の仕組みとパターンを深掘りしています。
• マルチエージェントとは：複数エージェント構成の類型と採用判断を実装者視点で整理しています。
• AIエージェントにMCPで外部ツールを接続する実装手順：選定基準で触れたMCP接続の具体的な設計を解説しています。