9.6.2 Agent フレームワークの全体像

学習目標

Agent プロジェクトでなぜフレームワークがよく使われるのかを理解する
さまざまなフレームワークの抽象レベルの違いを整理する
フレームワークが何を省いてくれるのか、逆に何を失わせるのかを知る
フレームワーク選定の初歩的な視点を身につける

Agent フレームワークの位置づけマップ

この図はトレードオフの地図として読むとわかりやすいです。低レベルのフレームワークほど制御しやすく、高レベルのフレームワークほど立ち上げやすく、検索寄りのフレームワークは文書と知識を中心にしたシステムで強みを発揮します。

なぜ Agent フレームワークが必要なのか？

フレームワークがないと、自分で書くときに何が大変なのか？

少し複雑な Agent システムでは、通常、次のようなことを自分で扱う必要があります。

状態管理
ツール呼び出し
メッセージの受け渡し
失敗時の再試行
トレース
複数 Agent の協調

もちろん手書きでもできますが、すぐに次のような問題にぶつかります。

定型コードの重複が多い
プロジェクトごとに構成がバラバラになる
デバッグや拡張がどんどん難しくなる

フレームワークは本当に何を解決してくれるのか？

まずは一言で覚えておきましょう。

フレームワークは、あなたの代わりに製品を作るものではなく、よく使う構造を先に整えてくれるものです。

たとえば、次のようなものです。

グラフ構造の状態フロー
ツール登録の仕組み
Agent 間協調の抽象化
実行と観測のインターフェース

フレームワークの大きな違いは、たいてい「できるかどうか」ではなく「どうやるか」にある

とても大事な視点：抽象レベル

多くのフレームワークは、次のようなことができます。

ツールを接続する
ワークフローを実行する
マルチ Agent を扱う

でも、抽象しているレベルは違います。

あるものは「低レベルで積み木を組む」感覚に近い
あるものは「高レベルで役割を編成する」感覚に近い
あるものは検索やデータ整理により強い

たとえ話

さまざまなフレームワークは、いろいろな種類のキッチンだと考えるとわかりやすいです。

鍋や皿を渡されて、自分で料理するタイプ
半完成のセットを渡されて、説明どおりに組み合わせるタイプ
特定の料理が得意な専門タイプ

つまり、フレームワークの違いは「誰が強いか」よりも、むしろ

今のタスクとチームのやり方に、誰がより合っているか。

という点にあります。

まずは大まかな地図を見よう

以下の図は正確な順位づけではなく、直感をつかむためのものです。

フレームワークの方向性	得意なこと	よくある印象
グラフ / ワークフロー型	複雑な状態フロー、明確な制御	柔軟だが、よりエンジニアリング寄り
検索 / ナレッジ型	文書、インデックス、RAG	データ志向が強い
役割 / チーム型	複数 Agent の役割分担と協調	すぐ始めやすいが、抽象度が高い
汎用実験型	デモを素早く作る	柔軟だが、工程面は自分で補う必要がある

この図でいちばん大事なのは、次の考え方です。

まず「どれが一番いいか」を聞くのではなく、「自分の問題はどのタイプに近いか」を考えること。

フレームワークは一般的に何を省いてくれるのか？

状態フローとノード管理

たとえば、次のようなことです。

今のタスク状態をどこに持つか
次にどこへ流すか
失敗したときにどう戻すか

ツール接続とメッセージ構造

たとえば、次のようなことです。

ツール登録
呼び出し結果のラップ
エラー処理

実行と観察

たとえば、次のようなことです。

トレース
ステップの記録
中間状態の可視化

つまり、フレームワークのよくある価値は「モデルが賢くなること」ではなく、

システムの構成をよりわかりやすくしてくれること。

にあります。

フレームワークにはコストもある

抽象化が高いほど、低レベルの制御は失いやすい

フレームワークは便利ですが、同時に次のようなコストもあります。

フレームワーク自体を学ぶ必要がある
フレームワークの制約を受ける
デバッグ時に内部抽象を理解しないといけない

よくある問題

多くの初心者は、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': "['返金ポリシー'] をもとに回答を生成する"}

なぜこのコードに「フレームワーク感」があるのか？

これはすでに次のようなものを抽象化しているからです。

ステップ
state
フローの組み立て

本物のフレームワークは、この方向をもっと完全に、もっと複雑にしたものにすぎません。

どんなときはフレームワークを使わないほうがよいのか？

次のようなシステムなら、手書きでも十分なことがあります。

小さな実験
単一 Agent
ツールが少ない
状態フローがとても単純

このような場合は、手書きのほうが悪くないどころか、むしろ良いこともあります。

本質を理解しやすい
フレームワークが抽象負担になることがある

なので、「フレームワークを使うこと」自体を、成熟の唯一の証拠だと思わないでください。

とても実用的な選び方

まず、次の質問を自分に投げかけてみてください。

自分のシステムはどれくらい複雑か？
状態フローは明らかに複雑か？
複数 Agent の協調が中核か？
検索 / 文書機能が主軸か？
チームは低レベルの制御を重視するのか、それとも早く始めることを重視するのか？

これらに答えられるようになると、フレームワークを見たときの判断がかなりしやすくなります。

初心者がよくはまる落とし穴

先にフレームワークを学んでから、システムを学ぶ

この順番だと、「API は使えるけれど、アーキテクチャの判断ができない」という状態になりやすいです。

流行っているからそのまま選ぶ

流行しているフレームワークが、今のプロジェクトに合うとは限りません。

フレームワーク自体を能力だと思い込む

フレームワークはあくまで組み立て方であって、システム品質の保証ではありません。

残す証拠

このページを終えたら、この証拠カードを残します。

問題の形: ワークフローグラフ、検索アプリ、役割チーム、または実験
フレームワーク選択: どの抽象化を追加し、何を隠すか
追跡記録: state、node、tool call、message、または run id
失敗確認: フレームワークの魔法が状態、再試行、または権限を隠す
判断: シングルエージェントのループが明確になってからフレームワークを選ぶ

まとめ

この節で最も大事なのは、フレームワーク名をたくさん覚えることではなく、次を理解することです。

Agent フレームワークの本質は、高頻度で出てくる状態フロー、ツールフロー、協調構造を先に抽象化し、システムをより速く組み立てられるようにすること。

これがわかると、今後は具体的なフレームワークを見たときに、流行を追うのではなく、「どんな組み立て方なのか」を比較する目で見られるようになります。

練習

自分のプロジェクトの場面をもとに、「グラフ / ワークフロー型」と「役割協調型」のどちらが向いているか判断してみましょう。
なぜ、複雑度が高くないプロジェクトでは、手書きのほうがよい場合があるのか考えてみましょう。
自分の言葉で説明してみましょう。フレームワークが本当に省いてくれている仕事は何でしょうか？
チームが特にコントロール性を重視するなら、どんなスタイルのフレームワークを選びたくなりますか？

プロジェクト参考とレビュー観点

難所が状態、分岐、retry、observability なら graph/workflow 指向が向いています。専門 role への分担とレビューが難所なら、role-collaboration 指向が向いています。
複雑度が低いプロジェクトでは、手書きコードのほうがよいことがあります。抽象が少なく、隠れたデフォルトも少なく、デバッグ経路が短いからです。
framework が省くのは、message passing、state container、tool binding、trace、retry、memory hook、よくある workflow pattern といった反復的な配管です。システム設計の理解までは代替しません。
controllability を重視するなら、明示的な workflow / graph 型 framework、または小さな手書き orchestration layer を優先します。状態遷移と失敗経路を確認しやすいからです。