AI Agent開発フレームワークの選び方：本番運用まで比較

「AI Agent開発フレームワークの選び方」で迷ったら、まず処理の決定性と状態の複雑さで候補を3種類に絞り、その後にツール呼び出し、拡張性、本番運用を比較してください。単一Agentで処理できる案件に多Agent構成を持ち込まず、本番投入前には追跡、復旧、権限境界を同じ失敗シナリオで検証するのが最短ルートです。

この記事は、新しいAgentプロジェクトの技術選定を進める開発者、PoCを本番環境へ移行したい技術責任者、フレームワークが重すぎたりツール呼び出しが不安定だったりして作り直したチーム向けです。

そもそもAgentフレームワークは必要ですか？

最初に確認するのは、どのフレームワークが優れているかではありません。対象業務が本当にAgentを必要としているかです。

次のような処理なら、通常の関数や決定的なワークフローで十分な可能性があります。

• 入力形式と出力形式が固定されている。
• 実行順序が毎回同じである。
• 利用するAPIやデータベースが決まっている。
• 失敗時の分岐をコードで明確に書ける。
• 人間による判断や追加質問が不要である。

一方、利用者の依頼内容に応じて検索、照合、計算、承認などの手段を選ぶ場合は、Agentの実行ループが役立ちます。処理途中の判断を保存し、後から人間が承認して再開するなら、状態管理を備えたワークフローフレームワークを検討します。

ここでいうAI Agent Frameworkは、単にモデルを呼び出すライブラリではありません。モデル、ツール、状態、実行制御、監視を一つの実行単位として扱うための仕組みです。軽い対話処理だけなら、低レベルAPIを直接使う方が依存関係も少なく、デバッグもしやすい場合があります。

開発難易度と状態管理で候補を絞る

フレームワークの抽象化には、設定ファイル中心、コード中心、グラフ中心という違いがあります。設定式は初期構築が速い反面、複雑な分岐や例外処理の追跡が難しくなりやすいです。コード式はチームの既存テストに組み込みやすく、グラフ式は実行順序と状態遷移を可視化しやすいという特徴があります。

たとえば、問い合わせAgentが検索ツールを1つ使い、回答を返すだけなら軽量SDKで始められます。検索、在庫確認、返金申請、担当者承認を順番に実行し、途中で停止・再開するなら、状態を中心に設計できるワークフレームが適します。

LangGraphの公式ドキュメントでは、チェックポイントによって状態を保存し、障害後の再開、人間による確認、過去状態の調査を実現する設計が説明されています。特に長時間実行や状態を持つ処理では、実行ロジックだけでなく「どこから再開するか」を選定基準に含める必要があります。詳しくはLangGraphの状態保存に関する公式ドキュメントを確認してください。 (docs.langchain.com)

軽量Agent SDKとワークフレームはどちらを選ぶべきですか？

軽量SDKとワークフレームの比較では、機能数よりも失敗時の責任範囲を見ます。

軽量SDKを選びやすい条件は、次の通りです。

• 1回の実行が短く、途中状態を長期間保持しない。
• ツールの数が少なく、実行順序も限定されている。
• 既存のキュー、ログ、データベースをそのまま使いたい。
• チームがPythonやTypeScriptなどの既存言語で制御したい。
• フレームワーク固有の状態モデルを導入したくない。

ワークフレームを選ぶべき条件は反対です。処理が複数段階に分かれ、外部APIの失敗、利用者の承認、再試行、タイムアウトを別々に扱うなら、実行状態を標準化できる構成の方が後から安全です。

公式のOpenAI Agents SDKのツールとガードレールの資料では、関数をツールとして登録し、引数のスキーマ検証、タイムアウト、エラー処理、承認ゲートを設計する考え方が示されています。また、実行履歴を追跡するTracingの公式資料では、モデル生成、ツール呼び出し、Agent間の引き継ぎ、ガードレールなどを記録できます。 (openai.github.io)

ただし、SDKに追跡機能があることと、業務全体を復旧できることは同じではありません。ログが残っていても、データベース更新の直後にプロセスが停止した場合、同じ更新を再実行して二重登録にならない設計が必要です。

ツール呼び出しの再試行を追加する前に、その操作が冪等か確認してください。決済、注文登録、権限変更のような副作用を持つ処理では、リクエストIDや重複チェックを用意しない再試行は障害を拡大させます。

ツール呼び出しを制御できるか確認する

ツールの接続数を競うより、誤った呼び出しを止められるかを確認してください。評価すべき項目は、次の5つです。

1. 引数スキーマを検証できるか。
2. タイムアウトと再試行条件を個別に設定できるか。
3. 高リスク操作の前に承認を挟めるか。
4. 呼び出し、結果、失敗理由を追跡できるか。
5. 同じ要求を再実行しても二重処理にならないか。

特にツールが増えると、Agentが「使えるツール」ではなく「今使うべきツール」を選べるかが問題になります。検索、社内データ取得、更新処理をすべて同じ階層に並べると、モデルが権限の強いツールを誤って選ぶ可能性があります。

そこで、読み取り専用のツールと変更系ツールを分離し、変更系には承認や追加の入力検証を設けます。Agentに渡すツール一覧を常に固定せず、処理段階に応じて有効化する設計も有効です。

多Agent構成では、専門Agentへの引き継ぎ自体がツール呼び出しの一種になります。中央の管理Agentが専門Agentをツールとして呼ぶ方式と、専門Agentへ処理を引き渡す方式では、最終回答の責任者とログの追跡方法が変わります。公式のAgentオーケストレーションに関する資料でも、この2つの構成は異なる用途として整理されています。 (openai.github.io)

拡張性は「差し替え可能な境界」で判断する

「モデルを変更できる」「プラグインに対応している」と書かれていても、実際にはフレームワーク本体を修正しなければ使えないことがあります。拡張性を確認するときは、宣伝文句ではなく、次の境界を実装例で確かめます。

• モデルを別の提供元へ差し替えられるか。
• メモリや状態保存先を変更できるか。
• ツールを登録、無効化、条件付き有効化できるか。
• 実行前後に独自ミドルウェアを挿入できるか。
• 既存のキュー、認証、監視基盤と接続できるか。
• フレームワークを使わない関数処理と混在できるか。

最初から全機能を抽象化する必要はありません。モデル呼び出し、ツール実行、状態保存、監査ログの境界だけを自分のコード側で明確にしておくと、後からフレームワークを交換しやすくなります。

実務では、拡張ポイントが多いことより、標準機能を使わない場合の逃げ道があることが重要です。フレームワーク独自のデータ型がアプリケーション全体に広がると、移行時にテスト、ログ、データ変換を同時に作り直すことになります。

多Agentフレームワークはいつ導入する価値がありますか？

多Agent構成が有効なのは、専門性、権限、責任範囲が明確に分かれている場合です。たとえば、調査Agent、計算Agent、承認Agentが別々の入出力契約を持ち、最終判断を人間または管理Agentが行う構成です。

反対に、単一Agentで順番にツールを呼べば完了する処理を、複数Agentへ分割するのは避けてください。通信、コンテキストの受け渡し、再試行、監視対象が増え、失敗した場所を特定しにくくなります。

次の条件を満たす場合だけ、多Agent構成を候補に残します。

• 各Agentの担当領域を一文で説明できる。
• Agent間の入力と出力を構造化できる。
• どのAgentが最終責任を持つか決まっている。
• Agent単位で権限と監査ログを分けられる。
• 1つのAgentに集約するより、分割による効果を測定できる。

判断に迷う場合は、単一Agentを基準実装にしてください。その基準実装より、分割後の構成が正確性、処理時間、監査性のどれを改善したのか説明できなければ、採用理由としては弱いです。

本番環境へのデプロイ前に何を検証するべきですか？

本番環境へのデプロイでは、正常系のデモより失敗後の復旧を先に確認します。ワークフレームを使う場合も、チェックポイントが保存されるだけで業務処理が安全に戻るとは限りません。

たとえば、状態を保存した後に外部APIだけが成功し、Agent側が失敗した場合、再開時に同じAPIを呼ぶのか、結果を照合して次へ進むのかを決める必要があります。LangGraphの公式資料でも、割り込み後にノードが再実行されるため、割り込み前の副作用は冪等にするよう説明されています。 (docs.langchain.com)

本番前は、候補を2つ以内に絞り、同じ故障シナリオで比較してください。

• [ ] モデルAPIのタイムアウトを発生させ、再試行回数と最終状態を確認する。
• [ ] ツールが不正な引数を返した場合、実行前に検証できるか確認する。
• [ ] 書き込み系ツールの直後にプロセスを停止し、二重処理を確認する。
• [ ] 人間承認の途中で停止し、後から同じ状態を再開する。
• [ ] キューに同じジョブを複数投入し、同時実行数を制御できるか確認する。
• [ ] Agent、ツール、引数、結果、エラーを一つの実行単位で追跡する。
• [ ] 権限のないツールを呼び出した場合に拒否できるか確認する。
• [ ] 手動で停止、再開、キャンセル、担当者への引き継ぎができるか確認する。

状態の保存、再試行、タイムアウト、エラー処理を個別に設定できるワークフレームでは、障害をコード上の分岐として扱いやすくなります。公式のLangGraph障害耐性ドキュメントでは、ノード単位の再試行、タイムアウト、エラーハンドラーを組み合わせる例が示されています。 (docs.langchain.com)

Kvmjetのような継続稼働向けのMac環境を検証先にする場合は、実行時間、同時ジョブ数、ログ保存先、SSH接続、手動介入の方法を先に整理してください。環境の確認にはインフラ構成の案内を参照し、必要な接続条件が不明な場合はヘルプセンターで確認できます。

最終的な選定を条件で決める

選定結果は、次のように条件で出すと判断がぶれません。

• 処理が短く決定的で、状態を保持しないなら軽量Agent SDK。
• 分岐、承認、再試行、長時間実行があるならワークフレーム。
• 複数の専門領域と異なる権限を分離し、分割効果を測れるなら多Agent構成。
• 本番で復旧、監査、手動介入が必要なのに、その機能を自前で実装できないなら候補から外す。
• チームが読めない抽象化や、テストできない設定式が中心なら採用しない。

現在の構成が単純なAPIサーバーと決定的なジョブ処理で済むなら、無理にAgentフレームワークへ移行する必要はありません。逆に、処理途中の状態、承認、再開、ツール権限をすでにコードで個別実装しているなら、ワークフレーム導入による整理効果を検証する価値があります。

多Agent化を先に進めるより、まず単一Agentと1つの失敗シナリオを完成させてください。その後、専門Agentを追加しても監査ログと復旧手順が維持できるかを確認する順番が安全です。

自前の開発環境だけで検証すると、長時間実行、接続切断、手動復旧、同時処理の確認が後回しになりがちです。ローカル環境は短いPoCには便利ですが、継続稼働の確認、環境を占有した試験、実機依存の開発では準備と保守の負担が増えます。

そのため、現在の環境で不足しているのが、安定した稼働時間、遠隔からの接続、チームで共有できる検証環境のいずれかなら、KvmjetのMac環境を一時的なAgent検証先として比較する意味があります。長期の固定負荷や物理インターフェースが必要な案件では自社設備が適しますが、フレームワーク選定と本番前の復旧試験が目的なら、必要な期間だけ借りて条件を揃える方が判断しやすいです。

次に進むなら、Agent運用環境の相談窓口で接続方法と検証条件を確認し、本文のチェック項目を使って、選んだフレームワークが失敗後も復旧できるかを確かめてください。