AIエージェント フレームワーク: 2026年、マーケターはどう選ぶか
要約
AIエージェント フレームワークは、モデルにツールを使わせ、状態を保持し、作業を引き渡すコードの層です。マーケターの選択は自作か購入かです。LangGraphは長期の状態管理、CrewAIは役割ベースのパイプライン、OpenAI Agents SDKは薄い出発点に向きます。どれも連携、支出上限、ガバナンスは含みません。エンジニアと独自のロジックがないなら、オーケストレーション層は買い、最後の1マイルだけを作ってください。
AIエージェント フレームワークとは、言語モデルがツールを呼び出し、状態を保持し、作業を別のエージェントへ引き渡すためのコードの層です。マーケティングチームにとって本当の問いは、どのフレームワークが流行っているかではありません。その層を自分で持つ必要があるかどうかです。エンジニアがいて、誰も売ってくれない独自のワークフローがあるなら、LangGraphやCrewAIで組み立てます。来週ではなく今週中にキャンペーンの配分を組み替えたいなら、オーケストレーターを買います。
判断の基準は単純です。残りの本文で、その読み方を示します。
フレームワークが実際に与えてくれるもの
ブランドの装飾を取り除くと、フレームワークは4つのものを提供します。モデルが次の一手を決めるループ、ツールを呼び出す仕組み（メール配信基盤、広告アカウント、CRM）、ステップをまたいで残るメモリ、そしてエージェント間で作業を受け渡すルールです。
これは配管であって、マーケティング戦略ではありません。グロースリードが月曜の朝に開いて使える製品でもありません。フレームワークには、Meta広告へのコネクタも、ブランドセーフティの考え方も、顧客獲得単価の視点も含まれていません。それらは誰かが作る必要があります。
この違いが重要なのは、「フレームワーク」という言葉が2種類のものを指すからです。開発者向けフレームワークはライブラリです。マーケティング向けオーケストレーターは、同じ配管の上に載った完成品のシステムです。両者を混同すると、金曜までにキャンペーンを走らせたかったのに、6か月のエンジニアリング案件を抱えることになります。
4つのフレームワーク、4つの思想
2026年の候補リストは、ほぼ同じ名前が並びます。違いは1つの問いへの答えにあります。経路をどこまで自分で制御したいか、です。
LangGraph は、エージェントを状態を明示したグラフとして扱います。公式ドキュメントでは自らを低レベルのオーケストレーションフレームワーク兼ランタイムと位置づけ、プロンプトやアーキテクチャは抽象化しないとしています。障害後にエージェントを再開できる持続的な実行と、人が途中で介入できるチェックポイントを備えています。制御を得る代わりに、セットアップの時間を払うことになります。
CrewAI は、作業をチームとして組織します。その設計では、Flowが工程の骨格を定義し、Crewが実作業を担います。目標とツールを持つ役割ベースのエージェントが、Flowから呼び出される形です。リサーチ、執筆、レビューを担当する3者は、コンテンツ制作のパイプラインにそのまま対応するため、マーケターにとってイメージしやすい設計です。
OpenAI Agents SDK は、最も薄い層です。中核はagent、handoff、guardrailの3つです。agentは指示とツールを持つLLM、handoffは別のagentへの委譲、guardrailは入出力の検証を担います。すぐに始められますが、それ以外はすべて自分で配線する必要があります。
AutoGen は注意すべき例です。Microsoftのリポジトリはプロジェクトを保守モードにあると説明し、新規プロジェクトにはMicrosoft Agent Frameworkを推奨しています。ベンダーの提案書や古いチュートリアルがAutoGenを指していたら、日付を確認してください。
フレームワークの人気比べは飛ばしてください。GitHubのスター数は、キャンペーン基盤との適合性を測る指標にはなりません。
どのフレームワークがどのマーケティング業務に合うか
アーキテクチャは、タスクに合わせて選びます。順序を逆にしないことが大切です。多くのマーケティングチームは、次の3つのケースのどれかに当てはまります。
担当者1人が回す定例業務。 週次レポート、リードのデータ補完、受信トレイの振り分けなどです。薄いSDKやノーコードのエージェントビルダーで十分です。グラフ型ランタイムで作り込むと、コストが増えるだけで精度は上がりません。
役割が明確なパイプライン。 リサーチがブリーフを生み、ブリーフが下書きを生み、下書きがレビューを通ります。役割ベースのチームが合い、CrewAI型の構造は組織図のように読めます。
障害に耐えて数週間走り続けるキャンペーン。 メール、有料広告、SNSにまたがる製品ローンチは数週間続きます。Webhookは失敗し、APIはレート制限にかかります。チェックポイントを備えたグラフ型ランタイムなら、失敗したステップを最初からやり直す代わりに再開できるため、学習コストに見合います。
3つのケースすべてで、フレームワークは簡単な部分です。難しいのは最後の1マイルです。各チャネルへの認証、支出上限、承認ルール、そしてエージェントがなぜその行動を取ったかの記録がそれにあたります。
見えないコスト: フレームワークに含まれないもの
フレームワークから始めたチームは、同じ不足に、同じ順番でぶつかります。
まずコネクタです。チャネルごとに認証、レート制限への対処、エラーのマッピングが必要です。次に評価です。エージェントの再配分が顧客獲得単価を改善したのか、単に予算を動かしただけなのか、誰も教えてくれません。3つ目はガバナンスです。閾値を超える予算変更を誰が承認し、どこに記録するのか。4つ目は保守です。モデルもAPIも変わり、3月に機能していたプロンプトは6月には劣化しています。
コンサルタントによるbuildかbuyかの議論は、ハイブリッドに収束します。Pedowitz Groupの指針は、セキュリティ、ガバナンス、連携といった基盤は買い、差別化される最後の1マイルだけを作ることです。これはコンサルティング会社の経験則であって法則ではありませんが、運用の実態とも合っています。配管の部分に競争優位があることは稀です。
実践的な判定基準があります。自社の強みが、ベンダーが提供しない独自のデータソースや判断ロジックなら、その部分を作ってください。強みが単にキャンペーンをうまく回すことなら、その下の層を作るのは遠回りです。
代わりに買う: マーケター向けにフレームワークを包んだツール
フレームワークを組み立てる代わりに、完成した製品を使う方法があります。それぞれ、コントロールの度合いが異なります。
Lindyは、定期的な業務フローのためのノーコードビルダーです。小さな常駐エージェントを一度設定し、メール、カレンダー、CRMを接続すると、同じ業務を繰り返し実行します。前述の「1つの業務を1人が持つ」ケースに合います。
Manusはその対極にあります。目標を与えると、ウェブ上で自律的に作業を進める汎用エージェントです。調査や単発の制作には向きますが、ブランドルールと支出上限を毎時守る必要があるキャンペーンには、やや物足りません。
3つ目は、プラットフォームに組み込まれたエージェントです。HubSpotのBreezeエージェントはCRMの中に組み込まれ、成果に応じて課金されます。例えば見込み客の開拓エージェントは、認定リード1件につき$1.00と掲載されています。データがすでにHubSpotにあるなら、連携の作業は済んでいます。限界は、そのプラットフォームの壁の内側に留まることです。
4つ目は、従来型の自動化プラットフォームです。ActiveCampaignはメール、SMS、WhatsAppの視覚的なワークフローを構築でき、現在はAIキャンペーン機能も加わっています。根本はルールベースで、引かれた経路をそのままたどります。予測可能性が欲しいときには長所ですが、条件が途中で変わると天井になります。
メール単体ではKlaviyoの方が多くのオーケストレーターより優れています。一方、チャネルをまたぐルーティングは、マルチチャネルのオーケストレーターの方が得意です。どちらを選ぶかは、キャンペーンのどこで時間を失っているかによります。
多くのフレームワークが空白にしている層: オーケストレーション
自動化は計画に従います。オーケストレーションは計画を修正します。この違いこそ、調整をフレームワーク選びの副産物ではなく独立した層として扱うべき理由です。
48時間走っているローンチを想像してください。メールの開封率は18%で頭打ちになり、計画が想定していた24%には届きません。自動化ツールはスケジュール通りに送信し続けます。オーケストレーションするエージェントは頭打ちを読み取り、次の送信時間帯を変え、コンバージョンしている広告セットへ予算を移し、変更内容を人間のレビュー用に記録します。
その振る舞いには、プランナー、チャネルごとの実行役、公開前の検証役、そしてエージェント同士が発見を共有する共有メモリが必要です。どのフレームワークや製品が提供していても、マルチエージェントシステムが必要とする4つの役割は同じです。より詳しいアーキテクチャは、マルチエージェントシステムとは何かで各役割を解説しています。
最初の30日で測るべきもの
どの経路を選んでも、計測機器を事前に設定しておかなければ、試用には意味がありません。大半のシグナルを運ぶのは、次の3つの指標です。
施策前後の顧客獲得単価。 1つのキャンペーンでエージェントを動かし、同程度のキャンペーンは従来の方法で続けてください。比較がなければ、良い月は単なる良い月にすぎません。
シグナルから行動までの時間。 開封率が頭打ちになってから、変更が反映されるまでに何時間かかるかです。人手のプロセスでは1日から2日かかることが多いです。エージェントが分単位まで短縮しても顧客獲得単価が動かないなら、速さは見た目だけです。
取り消し率。 人間がエージェントの行動を元に戻す頻度を数えてください。取り消しがほぼゼロで承認もないなら、誰も確認していないということです。取り消しが多いなら、上限が緩すぎるか、古いデータで動いています。いずれにせよ、この数字が締め直すべき場所を示します。
3つの数字は1週目に書き留めてください。30日目には、所有する価値のあるフレームワークか、更新する価値のあるツールかが分かります。
今週使える判断ルール、そして航路の定め方
4つの問いを順番に確認してください。最初に「はい」となったところで止まります。
ノーコードのエージェントで、この1つの業務をこなせるか。 こなせるなら使う。作らない。
すでに支払っているプラットフォームがエージェントを提供しているか。 そこから始め、1か月計測する。
支出上限の内側で、チャネルをまたぐ再配分が必要か。 そのために作られたオーケストレーターを買う。
独自のロジックがあり、それを保守するエンジニアがいるか。 この時点で初めて、フレームワークに価値が生まれる。
ほとんどのチームは、1〜3のどこかで止まります。野心が足りないからではありません。独自のエージェント層を保守することは恒常的なコストであり、それを持つことで得をするチームは、その具体的な優位性を一文で言えるものです。
4に進むなら、機能より障害時の振る舞いで選んでください。14ステップのうち9番目でツール呼び出しが失敗したとき、何が起きるかを問うのです。チェックポイントから再開できるフレームワークなら、状態を作り直すのに費やすはずだった1週間を節約できます。
専任のエージェントエンジニアがいない会社でマーケティングを担当するなら、推奨されるのは、オーケストレーション層は買い、自社のデータとルールを持つ部分だけを作ることです。エンジニアがいて、どのベンダーもカバーしないワークフローがあるなら、長時間の状態管理にはLangGraph、役割ベースのチームにはCrewAIが現実的な出発点です。AutoGenはレガシーとして扱ってください。
フレームワークは戦略ではありません。航路こそが戦略です。次のキャンペーンを、証拠に基づいて再配分できる選択肢を選んでください。そして、その層を持つことで何が得られるかを一文で言えるようになったら、buildの問いを改めて考えてください。