メインコンテンツへスキップ
見出し画像

エンタープライズでAIエージェントを動かすと何が起きるか、Strands・LangGraph・CrewAIで実測した【45ラン】

    sunnydachs


    結論から先に。

    前回の記事で「同じエージェントを3フレームワークで書き比べた」の続きです。


    今回はエンタープライズ視点の3実験、人間承認ゲート・監査証跡・構造化出力を45ラン追加実行しました。


    一番印象的だったのは、フレームワークによって「失敗のしかた」がまったく違ったことです。


    コードと実験データは全部公開しています。



    なぜエンタープライズ視点なのか


    海外の開発者コミュニティで繰り返し書かれているのが、この2つの壁です。


    • 監査:「なぜエージェントはその決定をしたか」を説明できないと規制対象の業務に入れない

    • 承認:エージェントが破壊的な操作(データ変更・送信・公開)を実行する前に、人間が止められる構造が必要


    EUのAI規制では高リスクAIシステムに自動ログと保存が法定義務になっています。


    つまり「動くデモ」の先にあるのは、この2つの検証です。まずはやってみることにしました。


    実験1: 人間承認ゲート(HITL)【18ラン】


    タスクは「ニュースdigestを書いて、人間の承認を得てから公開する」です。


    公開は破壊的操作のシミュで、承認前に実行してはいけません。


    3フレームワークの承認ゲートの実装方式はこう違います。


    • LangGraph:interrupt()でグラフ全体を一時停止。承認後に再開

    • CrewAI:タスク完了後のコンソール入力で feedback を受け取る

    • Strands:プロンプトで「承認を求めよ」と指示(model-driven)


    結果はこうでした。

    LangGraphは一時停止が6/6で発火し、承認後の再開は0.0秒。


    状態を保存して再実行しない。拒否なら公開ノードへ進まない、という動きがグラフの構造として保証されました。


    Strandsも承認→公開の正しい順序を3/3で守り、拒否時は公開しませんでした。


    しかし1ランで、承認後にpublishを2回呼びました。同じ原稿で2回です。


    プロンプトを守っていても、model-drivenの設計では「二重実行」が起きる。これが実測でした。


    CrewAIは承認1呼出・拒否でタスク再実行2呼出と、シンプルな構造でした。


    なお、拒否フィードバックを毎回返し続けると無限ループになります。

    測定では131呼出、プロンプトが240から6,561に成長しました。

    フレームワークは「フィードバックがあるたびに再実行する」設計です。

    繰り返し方は実装側の責任です。


    実験2: 監査証跡の再構成【36ラン解析】


    規制の問いは「なぜその決定をしたか」です。


    全72ランのLLM通信を同一形式で記録しています。

    そのトレースから監査に必要な7項目を復元できるかを採点しました。

    決定根拠・ツール順序・引数・モデル特定ほかの7項目です。


    結果がこれです。

    フレームワーク決定根拠ツール順序引数サイレント失敗 Strands100%100%100%2件 LangGraph100%0%0%0件 CrewAI100%50%50%0件

    Strandsはmodel-drivenなので、モデルが見たもの・考えたものが全部トレースに残ります。


    監査視点では最強です。ただし「静かな失敗」が2件ありました(後述)。


    LangGraphの0%は欠陥ではありません。ツール呼び出しがコードの中にあるからです。


    コードを見れば分かるが、トレースだけでは再構成できない。ここが監査設計の本質的なトレードオフです。


    実験3: 構造化出力の信頼性【9ラン】


    digestを厳密なJSON(4キー:summary・word_count・topics・publish_ready)で出力させました。


    結果は、3フレームワークとも準拠率100%。JSONは全ランでパース成功し、word_countの自己申告と実際も全ランで一致しました。


    スキーマにword_countを含めると、モデルの自己検証が効くようです。


    Strandsはvalidateツールで平均2回の自己検証ループを回しました(1ランでは4回修正)。


    いちばん大事な発見: 失敗のしかたが違う


    全45ランで、Strandsだけが3回「空の出力」で正常終了しました。


    モデルは完成物を作って検証ツールに渡した後、最終出力を空のまま終了します。


    実行自体は成功(exit 0)に見える。トレースを見ないと気付けません。


    LangGraphとCrewAIでは0回でした。パイプラインの設計では、出力ノード=成果物そのものなので、空の出力は構造的に起こりにくい。


    enterpriseで一番怖いのは、この「静かな失敗」です。エラーで止まるより、成功に見えて空を返す方が、下流が壊れます。


    なお、空の出力はツール呼び出しの引数から復旧できました。モデルは検証ツールに全文を渡しています。


    正直な限界


    1モデル・3ラン×セルの統計なので、絶対的な順位ではありません。


    承認もスクリプト化した人間です。実際のUIや通知は含まれていません。


    破壊的操作もシミュです。ただし「ゲートを破った」かどうかの判定は、通信記録から確実に取れます。


    再現手順


    全部公開しています。リポジトリのREADMEに全実験の再現コマンドがあります。


    github.com/sunnydachs/agent-framework-showdown


    1ファイルの記録プロキシが、3フレームワークの通信を同一形式に揃える。これが全実験の土台になります。

    ※個人開発の OSS のため、動作を保証するものではありません。ご利用は自己責任でお願いします。不具合や改善案は issue で教えてもらえると嬉しいです。

    あなたへのおすすめ