9.6.9 フレームワーク選定ガイド

学習目標

熱量ではなく、タスク構造でフレームワークを判断できるようになる
すぐ使える選定軸をいくつか身につける
最小限の選定スコア例を読めるようになる
そもそもフレームワークを急いで使わないほうがいい場面を知る

なぜフレームワーク選定は本質的にアーキテクチャ判断なのか？

フレームワークを一度選ぶと、その後の多くのことがそれに引きずられるからです。

コードの組み立て方
チームの学習コスト
デバッグの方法
可観測性の組み込み方
リリースと保守の複雑さ

つまり、これは単なる小さな依存関係の選択ではなく、むしろ：

システムをどんな形で育てていくかを決めること。

だからこそ、「どれが一番流行っているか」は、たいてい最重要ではありません。

まず見るべき5つの重要な選定軸

タスクは複雑な状態遷移か？

システムに次のような要素があるなら：

はっきりした分岐
ループ
巻き戻し
明示的な中間状態

グラフ型ワークフローの抽象化に価値があります。

システムは知識 / 検索駆動か？

中心となる難しさが次のようなものなら：

ドキュメントの取り込み
インデックス化
検索
クエリの組み立て

知識志向のフレームワークのほうが自然です。

タスクはもともと役割分担型か？

タスクが次のような形に近いなら：

調査
執筆
レビュー

このようなチーム分業には、役割型のフレームワークが扱いやすいです。

チームは何を重視するか？

たとえば：

より高い制御性
より低い学習コスト
より速い試作スピード
より安定した長期保守

プロジェクトは今、デモか長期システムか？

この違いはとても重要です。

デモは「早く作れること」を重視
長期システムは「構造のわかりやすさ」と「保守性」を重視

最小限の選定スコア例

この例は「正解」を与えるためではなく、次の考え方を身につけるためのものです。

まずタスクの観点を並べてから判断する。

Agent フレームワーク選定決定図

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 を作る場合

より優先して考えるのは：

グラフ型 / ワークフロー型フレームワーク

なぜなら、次のようなものが必要になるからです。

明示的な状態
条件分岐の辺
巻き戻しと再試行

知識ベース / RAG が主軸の場合

より優先して考えるのは：

検索と知識整理に強いフレームワーク

なぜなら、重要なのは次の点だからです。

ドキュメントをどうシステムに入れるか
検索をどう組み立てるか

役割型のマルチ Agent プロトタイプを作る場合

より優先して考えるのは：

チーム / 役割協作型フレームワーク

この場合に重要なのは、次のことです。

分担を自然に表現できる
役割の関係がわかりやすい

いつ複雑なフレームワークを急いで使うべきではないか？

とてもよくあるのに見落とされがちなケース

もしプロジェクトが次のような単純なものなら：

1つのモデル
1つのツール
1本の直線的な流れ

多くの場合は、

手書き
軽量ラッパー

で十分です。

なぜそのほうがよいこともあるのか？

フレームワークには、次のコストがあるからです。

学習コスト
抽象化コスト
デバッグコスト

システム自体がまだ小さいなら、フレームワークはむしろ余計な負担になることがあります。

だから、まずは次を覚えておきましょう。

すべてのプロジェクトに「フレームワークらしさ」が必要なわけではありません。

なぜチーム要因を無視できないのか？

フレームワークは個人開発者だけのためのものではなく、チーム全体にも影響します。

新人がすぐ使えるか
コミュニティ資料が豊富か
問題が起きたときに調べやすいか
後から保守しやすいか

技術的には優れていても、チームに詳しい人がいなくて資料も少ないなら、実際のコストはかなり高くなることがあります。

だから「チームとの相性」は、選定ではとても現実的な軸です。

よくある選定ミス

いちばん流行っているものを見る

これは最もよくある間違いのひとつです。

デモが一番派手なものを見る

デモがかっこよくても、長期システムに向いているとは限りません。

タスク構造を考える前に、先にフレームワークを選ぶ

こうなると、後から「問題にフレームワークを当てはめる」発想になってしまい、「問題に合わせて抽象化を選ぶ」ことができなくなります。

ひとつのフレームワークに全部やらせようとする

現実のシステムは、次のように混在していてもおかしくありません。

検索層は別のスタイル
ワークフロー層は別のスタイル

より実用的な選定手順

「先にフレームワーク一覧を見る」より、次の順番をおすすめします。

まずタスクの主線を書く
状態遷移やワークフローの下書きを作る
知識・ツール・役割の3要素のうち、どれが重いかを整理する
そのうえで、合う抽象化を選ぶ

この順番なら、選定の根拠がかなりはっきりします。

残す証拠

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

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

まとめ

この節でいちばん大切なのは、「唯一の正解フレームワーク」を選ぶことではなく、次を身につけることです。

まずタスクの形を見て、そのあとでフレームワークの形を見る。

状態遷移、知識整理、役割協作、チーム制約といった軸で考え始めると、フレームワーク選定はもう流行追いではなくなります。

練習

今の自分のプロジェクトについて、「状態遷移 / 知識整理 / 役割協作 / 使い始めやすさ」の4つに重みをつけてみましょう。
考えてみましょう：なぜ小さいプロジェクトに複雑なフレームワークを無理に入れると、長期的には逆に遅くなることがあるのでしょうか？
自分の言葉で説明してみましょう：なぜフレームワーク選定は、ライブラリ選択ではなくアーキテクチャ判断なのか？
チームが特に制御性と可観測性を重視しているなら、どんなスタイルのフレームワークを優先しますか？

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

実用的な重みづけは、project の最大の不確実性から始めます。RAG 中心なら knowledge organization、長く動く Agent なら state flow、team simulation なら role collaboration が重くなります。
単純な project に複雑な framework を押し込むと遅くなります。学習者が business logic と framework abstraction の両方を debug する必要があり、余分な仕組みが本当の failure point を隠すからです。
framework selection は architecture decision です。state、observability、testability、team workflow、deployment、将来の migration cost に影響するため、単なる import ではありません。
controllability と observability を重視するなら、明示的な graph/workflow design、強い tracing、明確な state object を優先します。run loop を見えにくくする抽象は避けます。