AIエージェントを自分で組むなら、複雑な分岐や状態管理が必要なときはLangGraph、役割分担で素早く形にしたいならCrewAI、Gemini／Google Cloud連携が強いのがGoogle ADK。最初に押さえるべき結論はこの3択です。3つとも「LLMにツールを使わせ、複数ステップの判断を自動で進める」という同じゴールを目指しますが、その達成方法がまるで違います。だから「どれが優れているか」ではなく「何を作りたいか」で選ぶのが正解。
AIエージェント構築フレームワークとは、自律的に判断・行動するAIをコードで組み立てる土台のこと。
- ・LangGraphは状態をグラフで管理し、分岐・ループ・人間の承認を挟む処理に強い
- ・CrewAIは「役割を持つエージェントの分業」を直感的に書け、学習コストが低い
- ・Google ADKはGemini／Vertex AIとの連携が強く、開発から本番デプロイまで一気通貫で扱える（LiteLLM経由で他モデル、Cloud Run／GKE等の他インフラにも対応）
この先で各フレームワークの最小コードと向き不向きを並べていきます。ひとつ先に断っておくと、本記事に出てくるコマンドやコードは仕組みを理解するための最小例です。料金・対応モデルID・正確なAPI名・システム要件は本記事は2026年6月時点の各公式ドキュメントに基づく概説です（フレームワークは更新が速いため、確認時点で各公式の最新版・破壊的変更の有無を必ず確認してください）。更新が速いため、実際に手を動かすときは各公式ドキュメントで最新情報を確認してください。本文では出典の名前だけを添え、リンクは末尾の参考資料にまとめています。
AIエージェント構築フレームワークとは何か（3つの違いを一望）
AIエージェントとは、ゴールを与えると自分で手順を考え、必要なツールを呼び出しながら複数ステップの作業を進めるプログラムです。チャットボットが「1回の質問に1回答える」のに対し、エージェントは「調べる → 結果を見て次の行動を決める → さらに調べる」というループを自分で回します。この自律的なループを安全に・再現性をもって動かすための足場が、エージェント構築フレームワークです。
素のLLM APIを直接叩くだけでも簡単な自動化はできます。ただ、実用的なエージェントを組もうとすると、すぐに3つの壁にぶつかります。フレームワークはこの壁を肩代わりしてくれる存在だと考えるとわかりやすい。
エージェント開発で詰まる3つの壁（状態保持・協調・ツール呼び出し）
最初の壁が状態の保持です。エージェントは「さっき何を調べたか」「今どの段階にいるか」を覚えていないと、同じ作業を繰り返したり、前提を忘れて的外れな行動を取ったりします。LLM自体は基本的に1回の呼び出しごとに記憶がリセットされる仕組み。だから「前のステップの結果」を次のステップへ持ち回す仕掛けを、開発者が自前で用意する必要があります。これを手書きで管理すると、処理が増えるほどコードがすぐ破綻してしまう。
次の壁が協調です。1体のエージェントに全部やらせると、プロンプトが肥大化して指示が曖昧になりがち。現実の業務でも「調べる人」「書く人」「チェックする人」と分けたほうが質が上がるように、エージェントも役割を分けたほうが扱いやすくなります。ただし複数のエージェントを連携させると、誰がいつ動くか、結果をどう受け渡すかという制御が一気に複雑になります。
3つめの壁がツール呼び出しです。エージェントが価値を出すのは、Web検索・計算・社内DB照会といった外部ツールを使えるから。ところがLLMに「このツールをこう呼べ」と正しく指示し、返ってきた結果を解釈させ、失敗したらやり直させる、という一連の段取りは想像以上に骨が折れます。引数の渡し方ひとつで意図通りに動かないことも珍しくありません。
LangGraph・CrewAI・Google ADKは、いずれもこの3つの壁を別々のアプローチで解決します。どれを選んでも壁そのものは越えられる。違うのは「越え方の思想」と「書き味」です。
4つの比較観点をそろえる（この観点で各章を統一）
3つを公平に見比べるために、本記事では次の4観点で各フレームワークを評価します。章をまたいでも同じ物差しを使うので、読み進めるうちに自分の用途に合う1本が浮かび上がってくるはずです。
1つめが状態管理。処理の途中経過をどれだけ細かく制御でき、分岐やループ、長時間の中断・再開にどこまで耐えるか。2つめがマルチエージェントの組みやすさ。複数の役割をどれだけ自然に分業させられるか。3つめが学習コスト。初めて触る人がどのくらいの手間で最初の1体を動かせるか。最後が本番運用のしやすさ。検証で終わらず、実サービスへデプロイして監視する段階まで面倒を見てくれるか。
この4観点でいうと、LangGraphは状態管理が際立って強く、CrewAIは学習コストとマルチエージェントの手軽さが光り、Google ADKは本番運用までの導線がエコシステム内で完結する点に特徴があります。次の章から、それぞれを最小コードとともに見ていきましょう。
LangGraph：状態をグラフで制御する
LangGraphは、エージェントの処理を「グラフ」として描くフレームワークです。グラフといっても折れ線グラフのことではなく、ノード（処理のかたまり）とエッジ（処理から処理への矢印）で構成された流れ図のこと。「調査ノード → 判断ノード → 条件に応じて執筆ノードか再調査ノードへ」というように、処理の道筋を目に見える形で組み立てられます。LangChainという広く使われているLLM開発ライブラリの周辺から生まれたツールで、その資産をそのまま活かせる点も初心者には心強い。
最大の持ち味が、状態（State）を明示的に持ち回せること。グラフ全体で共有する1つの状態オブジェクトを定義しておき、各ノードがそれを読んで更新する、という仕組みです。「今までの会話履歴」「収集済みのデータ」「次に進むべき分岐」を状態に詰めておけば、どのノードからでも参照できます。先ほど挙げた「状態保持の壁」を、設計の中心に据えて正面から解いているのがLangGraphの方針です。
StateGraphの最小構成イメージ（ノード・エッジ・条件分岐）
まずはインストールから。一般的には次のコマンドでパッケージを導入します。
pip install langgraph 最小構成のイメージは、状態の型を決めて、ノードを関数として書き、それらを矢印でつなぐ、という3手順です。骨格だけを示すと次のようになります。実際のクラス名・引数は版によって変わるため、ここでは概念をつかむための擬似コード水準と捉えてください。
from langgraph.graph import StateGraph, END
from typing import TypedDict
# グラフ全体で共有する状態を定義する
class State(TypedDict):
topic: str
notes: list
# ノードは「状態を受け取り、更新した状態を返す」関数
def research_node(state: State):
result = f"{state['topic']} の調査結果"
return {"notes": state["notes"] + [result]}
# グラフを組み立てる
graph = StateGraph(State)
graph.add_node("research", research_node)
graph.set_entry_point("research")
graph.add_edge("research", END)
app = graph.compile()ポイントは、各ノードが状態の一部だけを返すと、それが全体の状態にマージされる点です。research_nodeはnotesしか触っていませんが、topicの値は保持されたまま次へ渡ります。これにより、ステップが増えても「どの情報がどこで更新されるか」を追いやすくなります。
LangGraphが本領を発揮するのが条件分岐です。「調査結果が十分なら執筆へ、不十分なら再調査へ」といった判断を、エッジに条件をぶら下げる形で表現できます。分岐の判定を行う関数を用意し、戻り値（次に進むノード名）に応じて行き先を切り替える、というのが基本の書き方。ループも同じ要領で、あるノードから前のノードへエッジを戻せば「条件を満たすまで繰り返す」処理になります。素のコードでif文とwhile文を散らかすより、流れが図として整理されるのが利点です。
状態の永続化と人間の介入を挟む使い方
LangGraphにはチェックポイントと呼ばれる、状態を保存しながら実行を進める仕組みがあります。これがあると、長い処理を途中で止めて後から再開したり、エラーで落ちても直前の状態から続きを走らせたりできます。1回のリクエストで完結しない、数時間〜数日にわたるような長期タスクを組むときに効いてくる機能です。
もうひとつ実務で重宝するのが、人間の介入（human-in-the-loop）を挟める設計。エージェントが「この内容で外部にメールを送ってよいか」と判断する手前で処理を一時停止し、人間の承認を待ってから続行する、といった流れを自然に組み込めます。完全自動だと怖い操作を、節目だけ人がレビューする半自動運用にできるわけです。
向くケース・避けたいケース
向いているのは、処理の分岐が多い・状態を長く持ち回したい・途中で人間のチェックを挟みたい、といった作り込み重視のエージェントです。カスタマーサポートの一次対応で「内容に応じて担当部署へルーティングし、難しい案件は人間にエスカレーションする」ような、条件次第で道筋が枝分かれするワークフローと相性が良い。
一方で、「入力を受けて1回LLMに投げて返すだけ」のような単純な逐次処理には、グラフ定義の手間がかえって重く感じられます。状態やノードの設計に最初のひと手間がかかるぶん、シンプルな自動化にはオーバースペックになりがち。とりあえず動くものを最速で作りたい段階では、次に紹介するCrewAIのほうが立ち上がりは速いでしょう。
CrewAI：役割分担でマルチエージェントを組む
CrewAIは、エージェントを「役割を持ったチームメンバー」として組み立てるフレームワークです。crewは英語で「乗組員・チーム」の意味。リサーチ担当、ライティング担当、校正担当といった具合に、人間の組織を模した形で複数のエージェントを定義し、それぞれにタスクを割り振って協力させます。この発想がとにかく直感的で、プログラミングの経験が浅くても「誰が何をやるか」をイメージしながら書ける点が初心者向きです。
設計の中心にあるのは3つの部品。役割を持つAgent、こなすべき仕事を表すTask、そしてそれらをまとめて動かすCrewです。「マルチエージェントの協調をどう書くか」という先述の壁を、組織図のメタファーで解いているのがCrewAIの方針だと言えます。1体のエージェントに巨大なプロンプトを詰め込む代わりに、役割ごとに小さく分けることで、それぞれの指示がシンプルになり結果も安定しやすくなります。
Agent・Task・Crewの最小構成イメージ
導入は一般的に次のコマンドです。
pip install crewai 最小構成は、エージェントを役割つきで定義し、タスクを割り当て、Crewにまとめて起動する、という流れになります。次の骨格を見ると、人間のチーム編成にそっくりだとわかるはずです。
from crewai import Agent, Task, Crew, Process
# 役割・ゴール・背景を持つエージェントを定義する
researcher = Agent(
role="リサーチャー",
goal="与えられたテーマの最新情報を集める",
backstory="情報収集を得意とする担当者",
)
writer = Agent(
role="ライター",
goal="集めた情報を読みやすい記事にまとめる",
backstory="文章作成を担当するメンバー",
)
# それぞれに具体的なタスクを割り当てる
research_task = Task(description="テーマXを調査する", expected_output="主要論点を箇条書きで返す", agent=researcher)
write_task = Task(description="調査結果を記事化する", expected_output="記事本文をMarkdownで返す", agent=writer)
# チームを編成して実行する
crew = Crew(
agents=[researcher, writer],
tasks=[research_task, write_task],
process=Process.sequential,
)
result = crew.kickoff()注目したいのが、エージェントにrole（役割）とgoal（ゴール）、backstory（背景設定）を与えている点です。「あなたはリサーチャーで、目的は情報収集です」と人格を与える感覚で書けるので、プロンプトを一から設計するより心理的なハードルが低い。kickoff()を呼べばチームが動き出し、リサーチャーが集めた情報をライターが受け取って記事にする、という連携が裏側で進みます。LangGraphのようにノードやエッジを設計しなくても、役割とタスクを並べるだけで分業型のワークフローが立ち上がるのが手軽さの源です。
sequentialとhierarchicalプロセスの違い
CrewAIには、チームの動かし方を決めるプロセスという設定があります。代表的なのがsequential（順次）とhierarchical（階層）の2つ。先ほどのコードで指定したProcess.sequentialは、タスクを定義した順に1つずつこなしていくシンプルな進め方です。「調査 → 執筆 → 校正」のように工程が一直線に並ぶ作業に向いています。
もう一方のhierarchicalは、管理役のエージェントが他のメンバーに仕事を振り分ける階層型の進め方です。hierarchicalを使うにはCrew作成時に manager_llm か manager_agent の指定が必須で、この管理役はworkerのagents一覧には含めません。マネージャーが状況を見ながら「次は誰にやらせるか」を判断するため、工程が一本道でない、もう少し動的な分担が必要な場面に対応できます。最初はsequentialで全体の流れをつかみ、複雑になってきたらhierarchicalを検討する、という順序が無理のない学び方でしょう。
得意な業務自動化シーン
CrewAIが力を発揮するのは、人間の分業にきれいに置き換えられるタイプの自動化です。たとえば「市場のニュースを集める担当」「要点を要約する担当」「日報の形に整える担当」を組んで、毎朝のリサーチ業務を自動化するような使い方。それぞれの役割が明確で、工程が順番に流れる作業との相性が抜群です。
細かい状態制御や複雑な条件分岐という点では、グラフで作り込めるLangGraphに一歩譲ります。逆に言えば、作り込みより「とにかく動く分業チームを今日中に立ち上げたい」というスピード重視の場面では、CrewAIの手軽さが大きな武器になります。プロトタイプを素早く形にして、感触を確かめながら育てていく進め方に向いた1本です。
Google ADK：Geminiエコシステムで組むエージェント
3つ目はGoogle ADK（Agent Development Kit）。Googleが公開したエージェント開発用のキットで、同社のGeminiやVertex AI（Google Cloud上の機械学習プラットフォームのこと）との連携が強い一方、公式にはLiteLLM経由でOpenAIやAnthropic等の他モデルも、コンテナ化して任意のインフラへのデプロイにも対応するよう設計されています。LangGraphが「制御の細かさ」、CrewAIが「分業の手軽さ」を強みにしているのに対し、ADKの軸は「Googleのクラウド環境のなかでエージェントの開発からデプロイまでを一気通貫で扱える」点にあります。
LangGraphやCrewAIは特定のクラウドに縛られず、どのLLMでも使える中立性が魅力です。ADKはGoogle CloudやGeminiとの連携が最も滑らかですが、設計上はモデル非依存・デプロイ先非依存も意識されています。Googleの公式レールに乗れば、認証・スケール・運用といった本番で面倒になりがちな部分を扱いやすい一方、LiteLLM経由の他社モデルやコンテナベースの別環境も選択肢に入ります。すでにGoogle Cloudで他のシステムを動かしている人なら、追加の連携作業が少なく済む構成といえます。
LlmAgentとツール定義の最小構成イメージ
ADKでエージェントを作るときの中心になるのが、LLMを頭脳として持つエージェントの定義です。エージェントに「どんな役割か」「どのモデルを使うか」「どんなツールを呼べるか」を渡してやると、あとはユーザーの入力に応じてエージェント自身が「ツールを呼ぶか、そのまま答えるか」を判断してくれます。
最小の骨格は、おおよそ次のような書き方になります。
from google.adk.agents import LlmAgent
def get_weather(city: str) -> str:
return f"{city}は晴れです"
agent = LlmAgent(
name="weather_agent",
model="gemini-2.x", # 実際のモデルIDは公式で確認
instruction="ユーザーの質問に天気ツールを使って答える",
tools=[get_weather],
)注目したいのは、ツールがただのPython関数として渡せる点。関数名と引数、戻り値の型、そして関数のすぐ上に書いた説明文を手がかりに、エージェントが「この質問なら天気ツールを呼べばいい」と判断します。つまり関数の説明をきちんと書くことが、そのままエージェントの精度に効いてくるわけです。CrewAIやLangGraphでもツールの扱い方は似ていますが、ADKはGoogle製モデルとの相性がよく、このあたりが整理されています（他モデルもLiteLLM経由で利用可）。
Vertex AI・Cloud連携と本番デプロイの流れ
ADKのもう一つの顔が、開発から本番公開までの導線です。手元で動きを試す段階では、開発用のローカルUIを立ち上げて、エージェントとチャットしながら挙動を確認できます。adk web のようなコマンドで簡易的な画面が立ち上がり、どのツールがいつ呼ばれたかを目で追える仕組み。エージェントは内部で何度もLLMとやり取りするため、この「動きが見える」状態は初心者がデバッグするときに助かります。
ある程度形になったら、Google Cloud上のサービスにそのまま載せられます。コンテナ実行基盤のCloud Runや、エージェント運用に特化したAgent Engineといった選択肢が用意されていて、ローカルで動いたものを本番のスケールする環境へ移す段差が小さく設計されています。アクセスが増えても自動でスケールする、認証はGoogleの仕組みに乗る、ログは既存のクラウド監視に流れる。こうした本番運用の土台が最初から視野に入っているのがADKの持ち味です。
Googleエコシステム前提という制約
ADKはGoogle環境との相性が高く、GeminiやGoogle Cloudを主軸にすると最も自然に使いやすい設計です。一方で、LiteLLM経由の他社モデルや、Cloud Run／GKE・任意のコンテナへのデプロイにも対応します。Google公式ドキュメントでも他モデルとの接続に触れられており、純正の組み合わせが最も滑らかではあるものの、Google専用に縛られるわけではありません。
この前提が合うかどうかが、ADKを選ぶかの分かれ目になります。すでにGoogle Cloudを業務で使っている、社内の認証がGoogle Workspaceで統一されている、といった環境なら、追加の連携コストが小さく大きな武器に。逆に、特定のクラウドに縛られたくない、複数のLLMを自由に差し替えたい、という方針ならLangGraphやCrewAIのほうが身軽です。「自分たちのインフラがどこにあるか」から逆算して判断するのが現実的な選び方になります。
用途別の使い分けと比較表
ここまで見てきた3つは、どれが優れているという話ではなく、向いている仕事が違う道具です。同じ4つの観点（学習コスト・状態管理・マルチエージェント・本番デプロイ）でそろえて並べると、違いがはっきりします。
4観点でそろえた比較表
| 観点 | LangGraph | CrewAI | Google ADK |
|---|---|---|---|
| 学習コスト | やや高い | 低い（直感的） | 中程度 |
| 状態管理 | 得意（グラフで明示） | 標準的 | 標準的 |
| マルチエージェント | 細かく制御 | 役割分担が得意 | 階層構成に対応 |
| 本番デプロイ | 自前で構築 | 自前で構築 | GCPで一気通貫 |
| 向いている人 | 複雑な制御が要る人 | 素早く形にしたい人 | Google環境の人 |
| 提供形態 | OSS | OSS | OSS |
表のセルは大づかみの傾向で、数値や順位ではありません。読み取れるのは、LangGraphが「作り込みの自由度」、CrewAIが「立ち上げの速さ」、ADKが「本番までの導線」と、それぞれ別の強みに振り切っているという構図。3つを同じ土俵で点数化しようとすると本質を見失います。大事なのは「自分が作りたいものに、どの強みが効くか」です。
「作りたいもの」から逆算する選び方
複雑な分岐や長期的な状態の保持、途中で人間の承認を挟むような作り込みが必要なら、LangGraphが第一候補になります。処理の流れを自分の手で設計できる自由度は、業務の細かい要件に合わせ込むときに効いてくるでしょう。
役割分担型のワークフローを、とにかく早く動く形にしたい場合はCrewAI。「調べる人・書く人・整える人」を組むイメージで作れるので、最初のプロトタイプを今日中に立ち上げる、といったスピード重視の場面で力を発揮します。細かい制御が後から必要になったら、その時点でLangGraphへ移すという段階的な進め方も取れます。
GeminiやGoogle Cloudをすでに使っていて、検証で終わらせず本番デプロイまで見据えているならGoogle ADK。開発から公開までを同じエコシステム内で完結できる強みは、運用フェーズで効いてきます。
導入の規模でも選び方は変わります。個人の検証なら、まずは学習コストの低いCrewAIで「エージェントが動く」感覚をつかむのが無理のない入口。チームで再現性のある仕組みを作るならLangGraphの明示的な状態管理が安心材料になり、組織で本番運用まで持っていくならADKのデプロイ導線が候補に挙がる、という具合です。
よくある質問
Q. 初心者は3つのうちどれから始めるべきですか？
役割分担の発想がそのままコードになるCrewAIが、最初の1本としてはとっつきやすい構成です。「エージェントが自律的に動く」という感覚をつかんでから、より細かい制御が要るLangGraphや、本番運用前提のGoogle ADKに広げていくと無理がありません。
Q. 3つを併用することはできますか？
用途ごとに使い分けるのが現実的です。たとえばプロトタイプはCrewAIで素早く作り、本格運用で複雑な制御が必要になったらLangGraphで組み直す、といった移行はよく取られます。1つのプロジェクト内で無理に混在させるより、適材適所で選ぶ考え方が扱いやすいでしょう。
Q. 日本語で使えますか？
フレームワーク自体は日本語の入出力を問題なく扱えます。実際の応答の自然さは、裏で動かすLLM（Geminiやその他のモデル）の日本語性能に左右されます。日本語を多く扱うなら、日本語に強いモデルを選ぶことが体感の質を決めます。
Q. 料金はかかりますか？
3つのフレームワーク本体はいずれもオープンソースで、ソフトウェア自体に利用料はかかりません。費用が発生するのは、エージェントが呼び出すLLMのAPI利用料や、ADKでGoogle Cloudにデプロイした場合の実行リソース分です。
Q. プログラミング未経験でも使えますか？
3つともPythonでコードを書いて使うため、基本的なPythonの読み書きは前提になります。完全な未経験からだと最初のハードルは高めですが、まずは公式のサンプルを動かしながら、関数定義や変数といった基礎を並行して学ぶ進め方が現実的です。
まとめ
3つのフレームワークは、それぞれ別の悩みに答える道具でした。複雑な分岐や状態の保持、人間の承認を挟む作り込みが要るならLangGraph。役割分担型のワークフローを素早く形にしたいならCrewAI。Gemini／Google Cloudで本番運用まで一気通貫したいならGoogle ADK（他モデル・他インフラにも対応）。この対応関係を押さえておけば、「どれが正解か」で迷う時間はぐっと減ります。
最初の一手としておすすめなのは、いちばん気になった1つを選んで、ツールを1つだけ持たせた最小のエージェントを動かしてみること。役割を与え、質問を投げ、ツールが呼ばれる様子を見るだけで、エージェント開発の手触りが一気につかめます。3つを比較する前に、まず1つを最小構成イメージで触ってみると、表の言葉だけでは伝わらない各フレームワークの個性が”実感”としてわかってくるはずです。
参考資料
- LangGraph 公式ドキュメント
- LangGraph 公式GitHubリポジトリ
- CrewAI 公式ドキュメント
- CrewAI 公式GitHubリポジトリ
- Google ADK 公式ドキュメント
- Google ADK 公式GitHubリポジトリ
- Google Cloud 公式: Vertex AI ドキュメント
