マルチエージェントのフレームワークは自作か既製か？Google ADK・Claude Agent SDKの使い分けと、エンジニアが学ぶべき範囲

2026.10.23公開
株式会社Laboro.AI　システムエンジニアリング部 シニアSYSPM　神山 龍
株式会社Laboro.AI　システムエンジニアリング部 部長　光岡 駿
株式会社Laboro.AI　機械学習エンジニアリング部 シニア機械学習エンジニア　田本 篤喜

概要

マルチエージェントの開発を始めようとすると、最初にぶつかる問いの1つが「フレームワークを何にするか」です。Google ADKやClaude Agent SDKなど、選択肢は増え続けています。一方で、既製のものを使うか、自分たちで作るかという選択は、実はそれ以前の「どこまでをLLMに任せるか」という設計思想と深く結びついています。

本記事では、私たちLaboro.AIがマルチエージェントの案件で、独自のフレームワークから既製ツールへと比重を移してきた経緯と、その使い分けの判断軸を紹介します。

マルチエージェントシステムの全体像は、以下のコラムで整理しています。

【関連】マルチエージェントシステムとは？仕組み・メリット・活用事例と、開発現場で見えた設計の要点

目次

・マルチエージェントの開発で、フレームワーク選びが問われる理由
・過去の案件で、独自フレームワークを作った理由
・既製フレームワークが進化し、使い分けが変わった
・自作と既製を分ける判断軸
・エンジニアが向き合うべき学習範囲

マルチエージェントの開発で、フレームワーク選びが問われる理由

フレームワークの違いは、機能の多さよりも「制御の流れをどこまで自分の手に置けるか」に表れます。マルチエージェントでは、司令役がどの専門エージェントを呼ぶか、何回やり取りするか、どの段階で打ち切るかといった制御が、システムの品質を左右します。

主要なフレームワークの一覧は、すでに多くの記事で整理されています。私たちのコラムでも、AIエージェントの作り方の中で代表的なライブラリを紹介しています。

本記事は一覧の比較ではなく、「本番運用に耐える制御を実現するには何が必要か」という観点で選び方を掘り下げます。

【関連】AIエージェントの作り方とは？基本から実践的な活用事例までを徹底解説

過去の案件で、独自フレームワークを作った理由

案件によっては、Google ADKやClaude Agent SDKといった既製のフレームワークを使っています。ただし、過去の案件ではマルチエージェント構築用の独自フレームワークを開発して使っていました。

理由は、本番運用に耐えるには、すべての判断をLLMに任せるべきではないと考えたためです。

LLMの判断にはばらつきがあります。呼び出すたびに応答時間とコストもかかります。そこで、ルールで確実に決められる部分はルールベースで処理し、LLMは柔軟な判断が必要な箇所に絞って使う設計が、精度と速度の両面で重要になります。

たとえば、「この問い合わせは必ず専用の窓口に回す」「やり取りが一定回数を超えたら強制的に打ち切る」といった処理は、LLMに判断させるより、ルールで確実に実行したほうが安定します。

ところが当時の既製フレームワークは、制御の流れが内部に隠れていることが多く、こうしたルールベースの処理を任意の位置に差し込みにくい場面がありました。やり取りの回数を制御する仕組みも十分ではありませんでしたし、更新が速く、仕様変更の影響を受けやすい点も、長期運用では気がかりでした。

こうした事情から、カスタマイズ性の高い仕組みを自分たちで用意することになりました。

既製フレームワークが進化し、使い分けが変わった

状況は、ここ最近で大きく変わりました。Google ADKやClaude Agent SDKなどでも、コールバックやフックと呼ばれる仕組みで、LLMの判断の前後に独自の処理を差し込めるようになっています。

これにより、現在の私たちの進め方は、既製のフレームワークをベースにして、ルールで制御すべき部分だけを拡張機能で補う形が中心です。自作が必要になるのは、既製ツールではどうしても実現できない制御が求められる場合に限られると考えています。

とはいえ、自作にも既製にも、それぞれ負担があります。自作は保守の手間がかかりますし、既製は仕様変更への追従が必要です。そのため最終的には、案件の特性に合わせて判断しています。

自作と既製を分ける判断軸

私たちが判断で見ているのは、次の3点です。

1つ目は、ルールベースで制御したい処理の量と、その差し込み位置です。差し込みたい処理がフックの範囲に収まるなら、既製ツールで足ります。

2つ目は、運用期間の長さです。長く運用する案件ほど、フレームワークの更新に追従する手間と、自作を保守する手間を、天秤にかけて考えます。

3つ目は、チームがどこまで制御の中身を把握しておく必要があるかです。既製ツールの内部が見えない部分に、障害の原因が潜む可能性もあるためです。

判断の入口としては、「まず既製ツールで試し、どうしても実現できない制御が出てきたときに、拡張か自作かを検討する」という順序をおすすめします。

エンジニアが向き合うべき学習範囲

抽象化とパッケージ化が進むなかで、エンジニアは何を深く学ぶべきでしょうか。

マルチエージェントの仕組みを構築する場合、Transformer※1 のようなLLMそのものの内部構造以上に、次のような概念をしっかり学んでおく必要があります。

• 「Temperature」や「Reasoning Effort※2」などのLLMの各種パラメータと、コンテキスト長とコストの関係
• エージェントのメモリと、ツール呼び出しの考え方
• 「Agent as a Tool※3」やハンドオフといった、マルチエージェント特有の設計パターン

これらは、どのツールにも共通する土台です。この土台があれば、新しいフレームワークが登場しても、どこを拡張すれば必要な制御を実現できるかを判断できます。ツールの使い方そのものは数か月で変わりますが、土台の知識は長く使えます。

※1 Transformer：現在の大規模言語モデルの基盤となっている、文章中の語どうしの関係を捉えるニューラルネットワークの構造
※2 Reasoning Effort：モデルが回答の前に行う推論の深さを調整するパラメータ
※3 Agent as a Tool：エージェントを、別のエージェントが呼び出すツールとして扱う設計

監修者

システムエンジニアリング部 部長　光岡 駿

東北大学理学部物理学科卒業後、仙台のアプリ・システム開発会社に入社。自身が主催する勉強会が宮城大学との共同研究へと発展。「仙台X-TECH イノベーションアワード2023」最終プレゼンター選出など、幅広い活動を通じてシステム開発の実践を積む。2023年、Laboro.AIに1人目のシステム開発エンジニアとして参画し、「AI×システム開発」の領域をリード。2025年9月期エンジニアリング部MVP受賞。2026年よりシステムエンジニアリング部 部長。