9.6.2 Agent フレームワークの全体像
Agent の段階に入ると、多くの人がすぐに別の落とし穴にはまります。
「フレームワークが多すぎる。いったいどれを学べばいいの？」
この講義の目的は、どれかに肩入れすることでも、フレームワーク名を暗記することでもありません。まずは、次のような判断の地図を作ることです。
それぞれのフレームワークは、何を抽象化し、何を手放し、どんな場面に向いているのか。
学習目標
- Agent プロジェクトでなぜフレームワークがよく使われるのかを理解する
- さまざまなフレームワークの抽象レベルの違いを整理する
- フレームワークが何を省いてくれるのか、逆に何を失わせるのかを知る
- フレームワーク選定の初歩的な視点を身につける
なぜ Agent フレームワークが必要なのか？
フレームワークがないと、自分で書くときに何が大変なのか？
少し複雑な Agent システムでは、通常、次のようなことを自分で扱う必要があります。
- 状態管理
- ツール呼び出し
- メッセージの受け渡し
- 失敗時の再試行
- trace
- 複数 Agent の協調
もちろん手書きでもできますが、すぐに次のような問題にぶつかります。
- 定型コードの重複が多い
- プロジェクトごとに構成がバラバラになる
- デバッグや拡張がどんどん難しくなる
フレームワークは本当に何を解決してくれるのか？
まずは一言で覚えておきましょう。
フレームワークは、あなたの代わりに製品を作るものではなく、よく使う構造を先に整えてくれるものです。
たとえば、次のようなものです。
- グラフ構造の状態フロー
- ツール登録の仕組み
- Agent 間協調の抽象化
- 実行と観測のインターフェース
フレームワークの大きな違いは、たいてい「できるかどうか」ではなく「どうやるか」にある
とても大事な視点：抽象レベル
多くのフレームワークは、次のようなことができます。
- ツールを接続する
- ワークフローを実行する
- マルチ Agent を扱う
でも、抽象しているレベルは違います。
- あるものは「低レベルで積み木を組む」感覚に近い
- あるものは「高レベルで役割を編成する」感覚に近い
- あるものは検索やデータ整理により強い
たとえ話
さまざまなフレームワークは、いろいろな種類のキッチンだと考えるとわかりやすいです。
- 鍋や皿を渡されて、自分で料理するタイプ
- 半完成のセットを渡されて、説明どおりに組み合わせるタイプ
- 特定の料理が得意な専門タイプ
つまり、フレームワークの違いは「誰が強いか」よりも、むしろ
今のタスクとチームのやり方に、誰がより合っているか。
という点にあります。
まずは大まかな地図を見よう
以下の図は正確な順位づけではなく、直感をつかむためのものです。
| フレームワークの方向性 | 得意なこと | よくある印象 |
|---|---|---|
| グラフ / ワークフロー型 | 複雑な状態フロー、明確な制御 | 柔軟だが、よりエンジニアリング寄り |
| 検索 / ナレッジ型 | 文書、インデックス、RAG | データ志向が強い |
| 役割 / チーム型 | 複数 Agent の役割分担と協調 | すぐ始めやすいが、抽象度が高い |
| 汎用実験型 | demo を素早く作る | 柔軟だが、工程面は自分で補う必要がある |
この図でいちばん大事なのは、次の考え方です。
まず「どれが一番いいか」を聞くのではなく、「自分の問題はどのタイプに近いか」を考えること。
フレームワークは一般的に何を省いてくれるのか？
状態フローとノード管理
たとえば、次のようなことです。
- 今のタスク状態をどこに持つか
- 次にどこへ流すか
- 失敗したときにどう戻すか
ツール接続とメッセージ構造
たとえば、次のようなことです。
- ツール登録
- 呼び出し結果のラップ
- エラー処理
実行と観察
たとえば、次のようなことです。
- trace
- step の記録
- 中間状態の可視化
つまり、フレームワークのよくある価値は「モデルが賢くなること」ではなく、
システムの構成をよりわかりやすくしてくれること。
にあります。
フレームワークにはコストもある
抽象化が高いほど、低レベルの制御は失いやすい
フレームワークは便利ですが、同時に次のようなコストもあります。
- フレームワーク自体を学ぶ必要がある
- フレームワークの制約を受ける
- デバッグ時に内部抽象を理解しないといけない
よくある問題
多くの初心者は、Agent が作れないのではなく、
- まだタスクをちゃんと整理できていないのに
- 先にたくさんのフレームワーク API を学んでしまう
という状態に陥ります。
その結果、最後に身につくのはフレームワークの使い方であって、Agent の本質ではありません。
なので、正しい順番はたいていこうです。
まずシステムを理解し、それからフレームワークで速度を上げる。
最小限の「フレームワーク感」の例
次の例は、特定の実在フレームワークではなく、「フレームワーク的な抽象化の感覚」を示す最小例です。
class MiniWorkflow:
def __init__(self):
self.steps = []
def add_step(self, name, fn):
self.steps.append((name, fn))
def run(self, state):
for name, fn in self.steps:
state = fn(state)
print(name, "->", state)
return state
def retrieve(state):
state["docs"] = ["返金ポリシー"]
return state
def answer(state):
state["answer"] = f"{state['docs']} をもとに回答を生成する"
return state
wf = MiniWorkflow()
wf.add_step("retrieve", retrieve)
wf.add_step("answer", answer)
wf.run({"query": "返金ポリシーとは何ですか"})
想定出力：
retrieve -> {'query': '返金ポリシーとは何ですか', 'docs': ['返金ポリシー']}
answer -> {'query': '返金ポリシーとは何ですか', 'docs': ['返金ポリシー'], 'answer': "['返金ポリシー'] をもとに回答を生成する"}
なぜこのコードに「フレームワーク感」があるのか？
これはすでに次のようなものを抽象化しているからです。
- step
- state
- フローの組み立て
本物のフレームワークは、この方向をもっと完全に、もっと複雑にしたものにすぎません。
どんなときはフレームワークを使わないほうがよいのか？
次のようなシステムなら、手書きでも十分なことがあります。
- 小さな実験
- 単一 Agent
- ツールが少ない
- 状態フローがとても単純
このような場合は、手書きのほうが悪くないどころか、むしろ良いこともあります。
- 本質を理解しやすい
- フレームワークが抽象負担になることがある
なので、「フレームワークを使うこと」自体を、成熟の唯一の証拠だと思わないでください。
とても実用的な選び方
まず、次の質問を自分に投げかけてみてください。
- 自分のシステムはどれくらい複雑か？
- 状態フローは明らかに複雑か？
- 複数 Agent の協調が中核か？
- 検索 / 文書機能が主軸か？
- チームは低レベルの制御を重視するのか、それとも早く始めることを重視するのか？
これらに答えられるようになると、フレームワークを見たときの判断がかなりしやすくなります。
初心者がよくはまる落とし穴
先にフレームワークを学んでから、システムを学ぶ
この順番だと、「API は使えるけれど、アーキテクチャの判断ができない」という状態になりやすいです。
流行っているからそのまま選ぶ
流行しているフレームワークが、今のプロジェクトに合うとは限りません。
フレームワーク自体を能力だと思い込む
フレームワークはあくまで組み立て方であって、システム品質の保証ではありません。
まとめ
この節で最も大事なのは、フレームワーク名をたくさん覚えることではなく、次を理解することです。
Agent フレームワークの本質は、高頻度で出てくる状態フロー、ツールフロー、協調構造を先に抽象化し、システムをより速く組み立てられるようにすること。
これがわかると、今後は具体的なフレームワークを見たときに、流行を追うのではなく、「どんな組み立て方なのか」を比較する目で見られるようになります。
練習
- 自分のプロジェクトの場面をもとに、「グラフ / ワークフロー型」と「役割協調型」のどちらが向いているか判断してみましょう。
- なぜ、複雑度が高くないプロジェクトでは、手書きのほうがよい場合があるのか考えてみましょう。
- 自分の言葉で説明してみましょう。フレームワークが本当に省いてくれている仕事は何でしょうか？
- チームが特にコントロール性を重視するなら、どんなスタイルのフレームワークを選びたくなりますか？