第3章：フレームワークの4つの型
— 名前は違っても、構造は4種類しか存在しない
AIエージェントを語るとき、Dify、LangGraph、LangChain、AutoGen、CrewAI、Flowise、Assistants API──とにかく名前が多い。
だが、これは「名前の多さ」に惑わされているだけだ。
実際には フレームワークのアーキテクチャは4つの型に還元できる。どんな製品やOSSも、このどれか・もしくは混合型でしかない。
これを知らないと、「製品比較」「技術選定」「実装設計」すべてが迷走する。
3.1 エージェントフレームワークは4つの"型"に分類できる
- ノーコード・ワークフロー型（Dify / Flowise / LangFlow）
- 状態機械型（LangGraph / LCEL）
- 会話型マルチエージェント（AutoGen / CrewAI）
- タスクルータ型（AgentEngine / A2A / Assistants API）
これ以外の分類は不要。すべてのフレームワークは、この4つの掛け合わせで表現できる。
3.2 各型の詳細
① ノーコード・ワークフロー型（Dify / Flowise / LangFlow）
構造的特徴
- GUIでフローを並べる
- 「実行ステップ」を可視化して制御する
- LLMの推論と実行が混ざりやすい
強み
- PoCが最速で作れる
- 現場の非エンジニアに最適
弱点（核心）
- 文脈がGUIにリークする
- プロンプトにタスク手順が混ざりがち
- LLMが「実行まで抱える」ため破綻しやすい
つまり、構造的に安定しない。エージェントOS思想とは最も相性が悪い。
② 状態機械型（LangGraph / LCEL）
構造的特徴
- グラフで「状態遷移」を定義
- LLMは「思考する場所」だけに閉じ込められる
- 実行ステップはコード側で固定される
強み
- 破綻しない
- 脱線しない
- 自律タスクに圧倒的に強い
弱点
- 柔軟性が低い
- 創発は弱い（人間との往復が必須）
非創発 × 自律 の領域では最強。だが 創発 × 伴走 には設計しづらい。
③ 会話型マルチエージェント（AutoGen / CrewAI）
構造的特徴
- Agent同士がメッセージで会話してタスクを進める
- 「役割を複数持たせる」構造が発生しやすい
- 文脈が汚染されやすい
強み
- デモは派手
- 創発的なやり取りが可能
弱点
- 実務では99%破綻する
- 文脈の純度が保てない
- ループしやすい
- コスト爆発しやすい
Devin問題の縮図。「創発を自律で回そう」とすると地獄を見る。
④ タスクルータ型（AgentEngine / A2A / Assistants API）
構造的特徴
- LLMはタスク選択だけ行う
- 実行はすべて MCP / API / 外部ワーカーに逃がす
- 「推論と実行の完全分離」を実現しやすい
強み
- エージェントOS思想と完全一致
- 文脈純度を保てる
- 安定性が高い
- プロンプトが薄くてすむ
弱点
- ツール設計の質に性能が依存する
- 所有するツールが弱いとエージェントも弱い
最も「OSとしてのエージェント」を成立させる形式。
3.3 「名前ではなく構造」で理解する方法（写像ルール）
どんなフレームワークでも、次の4問に答えれば この4型のどれか に分類できる。
- LLMをどこで呼んでる？（推論層 or 文脈層）
- 実行をどこに置いてる？（タスク層 or 推論層）
- 文脈（役割・価値観）をどこで保持してる？
- フロー制御は誰が担当してる？（LLM or 外部）
これで、
- Flowise → 型①
- CrewAI → 型③
- OpenAI Assistants → 型④
- Vertex AI Agents → 型④＋RAG内蔵
- LangChain → ②＋④の混合
全部読み解ける。
3.4 読者が何を学ぶべきか
- 製品名ではなく構造で見ろ
- 「型」を理解すると技術選定が一瞬で終わる
- エージェントOSを支えるのは ②と④ の組み合わせ
- デモではなく安定性と純度で選べ
この章だけで、読者は「二度とフレームワーク選びで迷わない」状態になる。
3.5 次へのブリッジ
次章は 「OSとしての文脈制御」 に入る。
第4章：エージェントOS実装—文脈、役割、価値観、ルールの「持ち方」を具体化する
Last Updated: 2025-12-07