9.6.9 フレームワーク選定ガイド
一通りフレームワークを学んだあと、いよいよ本当に大事な問いが出てきます：
結局、どれを選べばいいの？
これは「答えを暗記する」問題ではなく、「タスク構造に応じて判断する」問題です。
このレッスンでは、その判断のしかたをはっきりさせます。
学習目標
- 熱量ではなく、タスク構造でフレームワークを判断できるようになる
- すぐ使える選定軸をいくつか身につける
- 最小限の選定スコア例を読めるようになる
- そもそもフレームワークを急いで使わないほうがいい場面を知る
なぜフレームワーク選定は本質的にアーキテクチャ判断なのか？
フレームワークを一度選ぶと、その後の多くのことがそれに引きずられるからです。
- コードの組み立て方
- チームの学習コスト
- デバッグの方法
- 可観測性の組み込み方
- リリースと保守の複雑さ
つまり、これは単なる小さな依存関係の選択ではなく、むしろ：
システムをどんな形で育てていくかを決めること。
だからこそ、「どれが一番流行っているか」は、たいてい最重要ではありません。
まず見るべき5つの重要な選定軸
タスクは複雑な状態遷移か？
システムに次のような要素があるなら：
- はっきりした分岐
- ループ
- 巻き戻し
- 明示的な中間状態
グラフ型ワークフローの抽象化に価値があります。
システムは知識 / 検索駆動か？
中心となる難しさが次のようなものなら：
- ドキュメントの取り込み
- インデックス化
- 検索
- クエリの組み立て
知識志向のフレームワークのほうが自然です。
タスクはもともと役割分担型か？
タスクが次のような形に近いなら：
- 調査
- 執筆
- レビュー
このようなチーム分業には、役割型のフレームワークが扱いやすいです。
チームは何を重視するか？
たとえば：
- より高い制御性
- より低い学習コスト
- より速い試作スピード
- より安定した長期保守
プロジェクトは今、デモか長期システムか？
この違いはとても重要です。
- デモは「早く作れること」を重視
- 長期システムは「構造のわかりやすさ」と「保守性」を重視
最小限の選定スコア例
この例は「正解」を与えるためではなく、次の考え方を身につけるためのものです。
まずタスクの観点を並べてから判断する。
フレームワークを選ぶときは、まず「どれが一番流行っているか」ではなく、タスクがどのタイプに近いかを考えます。複雑な状態遷移、知識検索、役割分担、すばやいデモ、長期保守性のどれが中心かを見るのが選定の出発点です。図の分岐が、その判断材料です。
frameworks = {
"langgraph": {"stateful_flow": 9, "knowledge": 6, "role_collab": 6, "ease_of_start": 6},
"llamaindex": {"stateful_flow": 5, "knowledge": 9, "role_collab": 4, "ease_of_start": 7},
"crewai": {"stateful_flow": 5, "knowledge": 5, "role_collab": 9, "ease_of_start": 8}
}
weights = {
"stateful_flow": 0.35,
"knowledge": 0.25,
"role_collab": 0.20,
"ease_of_start": 0.20
}
def score(framework_info, weights):
return sum(framework_info[k] * weights[k] for k in weights)
for name, info in frameworks.items():
print(name, "->", round(score(info, weights), 3))
想定出力：
langgraph -> 7.05
llamaindex -> 6.2
crewai -> 6.4
このコードで本当に大事なのは点数ではない
本当に大事なのは、次のような問いを持てるようになることです。
- 自分のシステムは、何をいちばん重視しているのか？
- なぜこの軸の重みが高いのか？
これこそが、選定の考え方そのものです。
典型的なタスクごとの直感的な選び方
複雑な状態遷移を持つ Agent を作る場合
より優先して考えるのは：
- グラフ型 / workflow 型フレームワーク
なぜなら、次のようなものが必要になるからです。
- 明示的な状態
- 条件分岐の辺
- 巻き戻しと再試行
知識ベース / RAG が主軸の場合
より優先して考えるのは：
- 検索と知識整理に強いフレームワーク
なぜなら、重要なのは次の点だからです。
- ドキュメントをどうシステムに入れるか
- 検索をどう組み立てるか
役割型のマルチ Agent プロトタイプを作る場合
より優先して考えるのは：
- チーム / 役割協作型フレームワーク
この場合に重要なのは、次のことです。
- 分担を自然に表現できる
- 役割の関係がわかりやすい
いつ複雑なフレームワークを急いで使うべきではないか？
とてもよくあるのに見落とされがちなケース
もしプロジェクトが次のような単純なものなら：
- 1つのモデル
- 1つのツール
- 1本の直線的な流れ
多くの場合は、
- 手書き
- 軽量ラッパー
で十分です。
なぜそのほうがよいこともあるのか？
フレームワークには、次のコストがあるからです。
- 学習コスト
- 抽象化コスト
- デバッグコスト
システム自体がまだ小さいなら、フレームワークはむしろ余計な負担になることがあります。
だから、まずは次を覚えておきましょう。
すべてのプロジェクトに「フレームワークらしさ」が必要なわけではありません。
なぜチーム要因を無視できないのか？
フレームワークは個人開発者だけのためのものではなく、チーム全体にも影響します。
- 新人がすぐ使えるか
- コミュニティ資料が豊富か
- 問題が起きたときに調べやすいか
- 後から保守しやすいか
技術的には優れていても、チームに詳しい人がいなくて資料も少ないなら、実際のコストはかなり高くなることがあります。
だから「チームとの相性」は、選定ではとても現実的な軸です。
よくある選定ミス
いちばん流行っているものを見る
これは最もよくある間違いのひとつです。
デモが一番派手なものを見る
デモがかっこよくても、長期システムに向いているとは限りません。
タスク構造を考える前に、先にフレームワークを選ぶ
こうなると、後から「問題にフレームワークを当てはめる」発想になってしまい、「問題に合わせて抽象化を選ぶ」ことができなくなります。
ひとつのフレームワークに全部やらせようとする
現実のシステムは、次のように混在していてもおかしくありません。
- 検索層は別のスタイル
- ワークフロー層は別のスタイル
より実用的な選定手順
「先にフレームワーク一覧を見る」より、次の順番をおすすめします。
- まずタスクの主線を書く
- 状態遷移やワークフローの下書きを作る
- 知識・ツール・役割の3要素のうち、どれが重いかを整理する
- そのうえで、合う抽象化を選ぶ
この順番なら、選定の根拠がかなりはっきりします。
まとめ
この節でいちばん大切なのは、「唯一の正解フレームワーク」を選ぶことではなく、次を身につけることです。
まずタスクの形を見て、そのあとでフレームワークの形を見る。
状態遷移、知識整理、役割協作、チーム制約といった軸で考え始めると、フレームワーク選定はもう流行追いではなくなります。
練習
- 今の自分のプロジェクトについて、「状態遷移 / 知識整理 / 役割協作 / 使い始めやすさ」の4つに重みをつけてみましょう。
- 考えてみましょう：なぜ小さいプロジェクトに複雑なフレームワークを無理に入れると、長期的には逆に遅くなることがあるのでしょうか？
- 自分の言葉で説明してみましょう：なぜフレームワーク選定は、ライブラリ選択ではなくアーキテクチャ判断なのか？
- チームが特に制御性と可観測性を重視しているなら、どんなスタイルのフレームワークを優先しますか？