AIエージェントのフレームワーク｜選ぶ5条件

AIエージェントのフレームワークを比較すると、機能名の一覧になりやすい。マルチエージェント、メモリ、ツール実行、トレーシング。丸が多い候補を選んでも、長時間処理が途中で止まったり、承認前に外部更新が走ったり、障害の再現に必要な記録が残らなかったりする。

選定で見るべきなのは機能数ではない。自社の業務フローを、どこまで安全に実装・再開・評価・運用できるかだ。

ここからは、OpenAI Agents SDK、LangGraph、Google Agent Development Kit（ADK）、Microsoft Agent Frameworkの公式資料を例に、AIエージェントのフレームワークを選ぶ5条件を整理する。製品の優劣を決めるランキングではなく、要件定義と技術検証で使う比較軸として読んでほしい。

AIエージェントのフレームワークとは

AIエージェントのフレームワークは、モデルへの指示だけでなく、ツール呼び出し、状態管理、複数エージェントの連携、人間の承認、実行履歴などをアプリケーションとして組み立てるための土台だ。

たとえばOpenAI Agents SDKは、エージェント、ツール、ハンドオフ、ガードレール、セッション、トレーシングを中心に構成される。LangGraphは、長時間・状態保持型のワークフローを低レベルに制御し、永続実行や人間承認を組み込みやすい設計を掲げる。

Google ADKは、LLMによる判断と決定的なワークフローを分けて構成でき、複数エージェントやグラフ型の流れを扱う。Microsoft Agent Frameworkは、順次、並列、ハンドオフ、グループチャットなどのオーケストレーションパターンを提供する。

共通しているのは、単発のチャットではなく「処理の流れ」を作ることだ。ただし、抽象度、状態の持ち方、承認の入れ方、評価方法、運用環境は異なる。名前の似た機能だけを横並びにしても、案件に合うかは分からない。

以下の比較は2026年8月7日に確認した公式Web資料を対象にする。OpenAI Agents SDKとLangGraphはPython向け資料、Google ADKはPythonを中心に言語横断の現行資料、Microsoft Agent FrameworkはPython/.NETを中心に確認した。ADK 2.0のグラフ機能やMicrosoftの言語別機能など、提供段階が異なる項目は採用時に対象言語・版・一般提供かプレビューかを再確認する。

選ぶ前に同じ業務シナリオを置く

比較表を作る前に、候補へ渡す共通シナリオを決める。営業会議後の処理なら、次のように書ける。

1. 議事録から顧客課題と次の行動を抽出する
2. CRMから会社と担当者の候補を探す
3. 同名会社が複数なら更新せず、人間へ確認を返す
4. CRM更新案とメール下書きを作る
5. 承認後だけCRMを更新し、メールは下書きのまま残す
6. 途中で失敗したら、完了済みの工程を二重実行せず再開する

ここまで書くと、必要なのは「CRM連携あり」ではなく、候補解決、停止、承認、冪等性、再開、証跡だと分かる。AIエージェントのオーケストレーションで決める5つの制御でも、入口、ルーティング、共有状態、権限、失敗時の扱いを仕様にする重要性を整理している。

同じシナリオを使わずに候補ごとのデモを見ると、各製品が得意な例を比べるだけになる。先に入力、期待結果、停止条件、禁止事項を固定しておけば、フレームワークの差を業務要件へ戻せる。

条件1：処理の流れを明示的に制御できるか

最初の条件は、エージェントが自由に考えられることではない。自由にさせる場所と、順番を固定する場所を分けられることだ。

たとえば「議事録から論点を抽出する」はモデルに任せやすい。一方、「会社を一意に特定できない場合は更新しない」「外部送信前に承認する」「金額が空なら停止する」は決定的なルールにした方がよい。

比較時には、次を確認する。

• 順次、並列、分岐、繰り返しをコードやグラフで表現できるか
• モデルが次の処理を選ぶ部分と、固定ルールで進む部分を分離できるか
• エージェント間で渡す情報を型やスキーマで制約できるか
• 最大ステップ数、時間、費用の上限を設定できるか
• 予想外の経路へ進んだときに停止できるか

Microsoft Agent Frameworkの公式資料は複数のオーケストレーション方式を示し、Google ADKもLLMエージェントとワークフローエージェントを分けて説明している。比較の焦点はパターン数ではない。今回の業務フローを無理なく表せるか、設計レビューで経路を説明できるかだ。

成果物としては、フロー図だけでなく「各工程の入力・出力・担当・停止条件」を表に残す。データフロー図の書き方のように、境界とデータの移動を明示すると、エージェント同士の受け渡しも検証しやすくなる。

条件2：状態を保存し、安全に再開できるか

業務用AIエージェントは、一度の応答で終わらない。API待ち、人間の承認待ち、夜間バッチ、外部サービスの一時障害などで処理が止まる。

そこで必要になるのが、現在地と処理済みの結果を保存する仕組みだ。LangGraphは永続実行を中核機能の一つとして説明している。OpenAI Agents SDKは会話セッションに加え、承認待ちの実行をRunStateへ保存して再開する仕組みを提供する。ただし、フレームワークの実行状態を戻せることと、CRM更新の二重実行を防ぐことは同じではない。業務トランザクションの冪等性はアプリケーション側でも設計する。

技術検証では、正常終了だけでなく次の試験を行う。

「メモリ対応」という表示だけでは足りない。会話履歴、業務データ、チェックポイント、監査ログは別物だ。保存対象、保持期間、暗号化、削除、再開単位を分けて仕様化する。

条件3：権限・承認・停止を境界に置けるか

フレームワークが多くのツールへ接続できるほど、権限設計の重要性は上がる。検索だけを行うエージェントと、請求書の発行や顧客への送信を行うエージェントを同じ権限で動かしてはいけない。

確認するのは次の5点だ。

• 利用者またはサービス主体を実行ごとに識別できるか
• 読み取り、下書き、更新、送信を分離できるか
• 高影響操作の直前に人間の承認を挟めるか
• 入力不足、権限不足、矛盾、上限超過で安全に停止できるか
• 承認者、対象データ、実行結果を後から追えるか

OpenAI Agents SDKはガードレールと人間承認の仕組みを案内し、LangGraphやMicrosoft Agent Frameworkも人間を処理へ組み込む設計を扱う。ただし、承認機能が存在しても、どの操作を止めるかは利用企業が決める必要がある。

AIエージェントのセキュリティで決める5つの境界で整理した本人性、入力・データ、ツール・実行、承認・停止、証跡を、フレームワーク選定にも持ち込む。管理者権限を一つ渡してデモが動くことは、合格条件ではない。

条件4：同じテストで評価し、変更後も再実行できるか

AIエージェントは、最終回答だけ正しければよいとは限らない。誤った顧客を選び、たまたま自然なメールを作れたなら業務としては失敗だ。

Google ADKの評価資料は、最終応答と実行軌跡の両方を評価対象として説明する。フレームワーク比較でも、結果と経路を分けて採点する。

候補ごとに同じ20〜50件程度のテストセットを通し、モデル名、プロンプト、ツール定義、フレームワーク版を記録する。件数は固定の正解ではない。正常系、入力不足、権限不足、外部API失敗、対象の取り違えなど、今回のリスクを含めることが重要だ。

評価を後付けすると、フレームワークの変更やモデル更新のたびに品質を人手で見直すことになる。AIエージェントの要件定義は評価設計からで作った評価セットを、選定、PoC、受け入れテスト、運用回帰テストまで共通化すると判断履歴を残しやすい。

条件5：監視・デバッグ・引き渡しまで運用できるか

最後の条件は、開発者の手元で動くことではなく、運用担当へ渡せることだ。

OpenAI Agents SDKのトレーシングは、エージェント実行、ツール呼び出し、ハンドオフ、ガードレールなどを追跡する仕組みを提供する。他の候補でも、実行履歴や可観測性の機能は増えている。比較では画面の有無より、障害調査に必要な情報を取得・保管・検索できるかを見る。

運用テストでは、次を実演する。

1. 失敗した実行を業務IDから探す
2. 使用した入力、モデル、指示、ツール、版を確認する
3. 機密情報をログへ過剰に残していないか確認する
4. 原因を修正し、対象ケースだけ再実行する
5. 変更前後の評価結果を比較する
6. 利用量、遅延、エラー、費用の上限を監視する

さらに、特定フレームワークから移る場合に何を持ち出せるかも確認する。プロンプトだけでなく、ツールの入出力定義、状態スキーマ、評価セット、実行履歴、停止条件が社内資産として残るかを見る。AI内製化で残す4つの社内資産の考え方は、フレームワークの出口戦略にも使える。

4つの候補を同じ軸で整理する

公式資料から読み取れる主な設計上の特徴を、比較の入口として整理すると次のようになる。機能の網羅表ではなく、検証を始める位置を示す表だ。提供内容は更新されるため、採用時には各公式資料と実機で再確認してほしい。

どれか一つが常に正解ではない。単純なコード中心のエージェントに、複雑なグラフ基盤を選ぶと保守負荷が増える。長時間・多段階・承認待ちを含む業務を、軽量な実行ループだけで作ると、状態と復旧の独自実装が膨らむ。

RFPとPoCへ落とす比較表

最終的な選定資料は、製品名と点数だけで終わらせない。次の形式なら、RFP、PoC、受け入れテストへ引き継げる。

配点は案件ごとに変えてよい。ただし候補を見た後に都合よく動かさない。安全上の失格条件は、他の加点で相殺しない。

SIerが提案する場合は、顧客、SIer、フレームワーク提供者の責任も分ける。業務データの正しさ、ツール連携の不具合、モデルの挙動、基盤障害を全部「AIの問題」にまとめると、運用時の一次対応者が決まらない。比較の段階で、監視、問い合わせ、修正、再評価の担当を決める。

AIエージェントのフレームワーク選定は、人気製品を当てる作業ではない。業務シナリオを仕様にし、安全に止まり、再開し、評価し、運用できる土台を選ぶ作業だ。

株式会社Atsumellでは、対象業務の整理、権限・停止条件、評価セット、運用分担を含むAIエージェントの要件定義と構築を支援している。候補を触る前に比較条件を固めたい場合は、お問い合わせから相談してほしい。

関連記事

• AIエージェントのオーケストレーション｜5つの制御
• AIエージェントのセキュリティ｜5つの境界
• AIエージェントの比較で見る6つの条件
• AIエージェントの要件定義は評価設計から