Skip to Content
Docs03. 実装フレームワーク選定ガイド
中級framework-selection更新: 2026-09-10この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

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

この記事の目的

Agent 開発のフレームワークを「名前」ではなく「選定軸」で評価できるようになります。個別フレームワークの機能は変化が速いため、本記事は評価の枠組み(いつ選ぶか・何を見るか)を提供し、具体的な製品比較は行いません。

対象読者

  • Agent 開発の技術スタックを決める立場のエンジニア・テックリード
  • 「フレームワークを使うべきか、生の API でいくか」を迷っているチーム

前提知識

本文

概要: 選定の前に「生 API で小さく作る」

フレームワーク選定は、要件が見える前に行うと失敗します。まず生の LLM API と自前の最小ループ(Agent ループ の数十行)でプロトタイプを作ってください。得られるものは 2 つあります — (1) 抽象の下で何が起きるかの理解(フレームワークのデバッグに必須)、(2) 自分のタスクに本当に必要な機能の一覧(= 選定基準)。

詳細: フレームワークの 3 つの抽象度

層提供するもの向く状況
薄い SDK・エージェントランタイムAPI クライアント + ループ・ツール実行の基本制御を握りたい。要件が独自
オーケストレーション複数の LLM 呼び出しや Agent の実行順序とデータの流れを制御すること。直列・並列・ルーティングなどの定番パターンがある。フレームワークグラフ・ステート管理・分岐の宣言的定義複雑な Workflow 構成(オーケストレーションパターン)を宣言的に管理したい
フルスタック / ローコードUI・デプロイ・監視込みの統合環境標準的な構成で速く出したい。カスタマイズ要求が弱い

上に行くほど自由度が高く実装量が多い、下に行くほど速いが枠から出にくい、という通常のトレードオフです。

詳細: 選定軸チェックリスト

個別製品は変化が速いため、軸を固定して比較します。

  1. 可観測性トレース・メトリクス・ログといった外部出力から、システム内部で何が起きたかを説明できる性質。Agent では技術メトリクスに加えて品質シグナルの設計が必要になる。 — ループの中身(各ステップの入出力・トークン・レイテンシ)をどこまで見られるか。デバッグ可能性はここで決まります
  2. 状態管理と再開 — チェックポイント長時間タスクの「ここまで完了した」を再開可能な形で永続化したもの。ツール実行の完了やフェーズ境界などの意味のある単位で切る。信頼性とトークンコスト制御の両方の仕組み。・中断からの再開(メモリと状態管理)を自前で作らずに済むか
  3. Human-in-the-Loop人間の判断(事前承認・事後レビュー・エスカレーション・監視と中断)を Agent の実行フローに組み込む設計。 支援 — 承認待ちの永続化・再開(Human-in-the-Loop 設計)の一次サポートがあるか
  4. ツール接続 — MCPツールやデータソースを LLM アプリケーションに接続するための標準プロトコル。概要は ツール使用、接続の実務は ツール接続標準(MCP とエコシステム) 対応(ツール接続標準)、ツール定義の書きやすさ
  5. マルチエージェント複数の Agent ループが、それぞれ独立したコンテキストを持って分担・協調する構成。 — 必要な場合のみ。並列・委譲・統合のプリミティブ
  6. ロックインの形 — ベンダー(特定 LLM 専用か)とフレームワーク(抽象が独自すぎて移行不能にならないか)の両方
  7. 成熟度と保守 — 更新頻度、破壊的変更の履歴、コミュニティの厚さ。この領域のフレームワークは若く、メジャーバージョンで API が大きく変わることが珍しくありません
  8. 評価・テストとの統合 — 評価ハーネスAgent の評価を繰り返し実行可能にする仕組み一式。データセット・実行系・採点系・レポートの 4 点で構成される。(Agent 評価の基礎)を組み込みやすいか

設計判断: 「フレームワークなし」も正式な選択肢

自前ループ + 薄い SDK は、次の条件では合理的な最終形です。

  • Workflow 構成が単純(直列 + せいぜいルーティング)
  • 制御・監査・権限チェックの要件が強い(抽象の下に隠れてほしくない)
  • チームが仕組みを理解していることを重視する

逆に、複雑なグラフ・再開可能な長時間タスク・HITL を複数箇所で使うなら、フレームワークの状態管理を自前で再発明するコストの方が高くつきます。

詳細: 移行可能性を設計しておく

どれを選んでも、ビジネスロジックとフレームワークの境界を保つことが保険になります。ツールの実装・プロンプト・評価データセットをフレームワーク非依存のモジュールに置き、フレームワークには「配線」だけをさせる構成なら、乗り換えのコストは配線の書き直しで済みます。

統合後の提供段階を確認する例

Microsoft Agent Framework 1.0 は 2026-04-03 に .NET / Python の production-ready 版として発表され、安定 API と長期サポート方針を示しています。AutoGen の maintenance 方針と後継フレームワークの提供段階を別に記録します。既存コードを単に改名せず、状態・ツール・監査・再開の契約を代表タスクで比較し、採用機能の安定性を確認します。

実務での注意点

アンチパターン

  • デモの豪華さで選ぶ → デモは最良ケースの見せ方であり、可観測性・再開・保守性というつらい部分は映らない → 8 軸チェックリストで自分の要件と照合する
  • 抽象の下を理解しないまま本番へ → 不具合時にフレームワークの内部を初めて読む羽目になり、障害対応が長期化する → 先に生 API で最小ループを書き、抽象が何を隠しているかを知っておく
  • 移行コストをゼロか無限大かで考える → 「一度選んだら終わり」と構えて選定が進まない、または安易に選んで密結合する → ロジックと配線を分離し、移行を「高いが可能」に保つ

チェックリスト

  • 生 API での最小プロトタイプを作り、必要機能の一覧を得た
  • 8 つの選定軸で候補を比較した(機能表の再確認日も記録した)
  • 可観測性(各ステップの入出力の追跡)を実際に試した
  • ビジネスロジック(ツール・プロンプト・評価)がフレームワーク非依存に分離されている
  • バージョン固定と更新の運用(破壊的変更への追従)を決めた

関連トピック

参考資料

TODO・未確認事項

ストリーミングと Agent の UX 実装パターンモデル選定ガイド