AIオーケストレーションフレームワークの選択が重要なセキュリティ判断である理由

LangChain、CrewAI、AutoGenを比較した記事は数多く見つかります。今年だけでも、開発者体験やエコシステムの成熟度、マルチエージェントワークフローをどれだけ簡単に組めるかといった観点で同じような内容を扱うガイドが何十本も出ています。しかし、私が本当に気になっている問いに答えているものは一つもありませんでした。それは、選んだフレームワークによってエージェントが侵害されやすさが変わるのか、という問いです。

そこで実際にテストしてみました。答えは「イエス」、しかもその差は大きく、一般に出回っている比較ガイドではまったく触れられていない事実でした。

この先の話に関わるので、簡単に定義しておきます。オーケストレーションフレームワークとは、AIモデル本体と外部世界の間に位置するソフトウェア層のことです。エージェントがどのように行動計画を立てるか、いつツールやAPIを呼び出すか、タスクをまたいでどのように情報を記憶するか、そして人間による確認を挟まずにどこまで自律的に動けるかを決めています。推論を行うのはモデルですが、その推論に何をどこまで許可するかを決めるのはフレームワークです。LangChain、CrewAI、AutoGenは、その代表的な例です。

検証の設計

私は、ツール呼び出しのハイジャック、クロスツールインジェクション、メモリポイズニング、委任された権限の悪用など、複数の攻撃カテゴリーにわたる敵対的ペイロード群を同一条件でAIエージェントに対して実行する評価ハーネスを構築しました。詳細を確認したい方のために、完全な手法とデータセットはGitHub上でオープンソース化してあります。何が実際に侵害率を左右しているのかを切り分けるため、モデルは常に固定しました。毎回同じモデルです。変えたのは、そのモデルをラップするオーケストレーションフレームワークだけでした。CrewAI、LangChain、AutoGen、SmolAgentsの4種類です。

もしフレームワークが、同じ基盤モデルを取り巻く単なる互換可能な配線に過ぎないのであれば、4つすべての侵害率はおおむね同じ範囲に収まるはずです。しかし、実際はそうなりませんでした。

実際に判明したこと

モデルを固定した状態で数千回に及ぶ敵対的テストを実施した結果、侵害率は最も耐性の高いフレームワークで11.9%、最も脆弱なフレームワークで31.1%となり、その差は2.6倍にも達しました。しかもこれは、フレームワークの選択という一点のみに起因する差です。この数字の間で、モデルに関する条件は何も変わっていません。攻撃の内容も変わっていません。変化したのは、エージェントのツール呼び出し、メモリ、複数ステップにわたる推論をどのフレームワークがオーケストレーションしていたか、それだけです。

これは誤差の範囲で片付けられる差ではありません。チームとして妥当に受け入れられるセキュリティ水準と、出荷前に真剣な議論を引き起こすべき水準との間にある、まさにその境界線に相当する差なのです。

図1は、このメカニズムを最もシンプルな形で示しています。同じモデルであっても、より厳格なフレームワークと緩やかなフレームワークとに分けると、有意に異なる侵害率に行き着く様子が、まさにこの数字によって裏付けられています。

Julie Brunias

なぜこうしたことが起きるのか

オーケストレーションフレームワークは、中立的な単なる配線ではありません。それぞれのフレームワークが、ツール呼び出しをどう検証するか、推論のステップ間でどれだけコンテキストを共有するか、タスクをまたいでメモリをどう保持するか、そしてエージェントが確認を挟まずにどこまでアクションを連鎖できるかについて、実質的なアーキテクチャ上の判断を下しています。こうした判断は基盤となるモデルではなくフレームワークの設計によって下されるものであり、それが攻撃者に与える余地の大きさを直接左右しています。

ツール呼び出しをより厳格に検証するフレームワークや、メモリをより保守的に分離するフレームワークは、どのモデルが推論を担っているかにかかわらず、より寛容なフレームワークでは大きく開いたままになっている攻撃経路を塞ぎます。判断を生成するのはモデルですが、その判断に基づいてエージェントがどこまで自律的に行動できるか、そしてその過程のどこにチェックを設けるかを制御するのはフレームワークなのです。

具体的に言えば、すべてのツール呼び出しに対して実行前に明示的なスキーマ検証を必須とするフレームワークは、モデルが自ら生成したテキストから直接ツールを呼び出せてしまうフレームワークに比べて、攻撃者が悪意あるパラメーターを紛れ込ませる余地をはるかに小さくします。この一つの設計判断は、あなたのチームが手を付けるずっと前にフレームワークの開発者によって下されたものですが、それだけで、あなた自身のコードを一行も変えることなく2.6倍もの結果の差を生み出し得るのです。

市場に存在する空白

私が見つけたフレームワーク比較記事はどれも、セキュリティを数ある比較項目の一つとして軽く扱うにとどまっています。Bestarion、Atlan、Moxo、Cordum、Instinctoolsといったサイトのガイドは、LangChain、CrewAI、AutoGenをエコシステムの成熟度やメモリ処理、Human-in-the-Loop対応の観点で比較しており、それ自体は有用な情報です。しかし、実際に敵対的テストを実行し、測定された攻撃成功率の差を報告しているものは一つもありません。この視点は現在の一般的な比較議論には組み込まれておらず、「どのフレームワークを使うべきか」を調べているチームが今日検索上位に出てくるガイドの中に、このデータを見つけることはできないでしょう。

実務上何を意味するのか

新しいエージェント型システムのためにオーケストレーションフレームワークを選定しようとしているチームであれば、セキュリティの問題は開発者体験の問題と同じ重みで扱うべきであり、選定が終わった後に付け足しで考えるようなものであってはなりません。決定を下す前にやっておく価値があることをいくつか挙げます。

• フレームワークに関するセキュリティ上の主張は、ベンダーのマーケティング資料と同じ程度の懐疑心を持って受け止めてください。機能ドキュメントは、そのフレームワークが何をすると謳っているかを教えてくれますが、ツール呼び出しのハイジャックやメモリポイズニングに対して具体的にどこまで耐えられるかまでは教えてくれません。それを知るには、実際に自分たちで敵対的テストを実行するか、既に実施した誰かを見つけるしかありません。
• 使用するモデルの安全性トレーニングが、そのまま一様に引き継がれると考えないでください。十分にアラインメントされたモデルであっても、攻撃者により大きな行動の余地を与えるフレームワークにラップされていれば、より厳格なフレームワーク下にある同じモデルと比べて、実運用上の侵害率が有意に悪化することがあります。
• すでに本番運用している場合は、移行を検討中の候補ではなく、今使っているものをテストしてください。フレームワーク選定後にセキュリティを後付けで強化することは可能ですが、自分たちの現行構成がこのスペクトラム上のどこに位置しているかを把握して初めて、その対応がどれほど緊急性を要するかが分かります。

本質的な論点

AIエージェントをめぐるセキュリティの議論は、どうしてもモデルそのもの、つまりどのモデルが最も安全か、どのモデルがジェイルブレイクの試みを最も拒否するか、といった点に集中しがちです。しかし、それは不完全な見方です。モデルの上に載っているオーケストレーション層は、設計者がそう意図していたかどうかにかかわらず、実質的にセキュリティ上重要な働きをしています。にもかかわらず、私が見つけた一般的な比較ガイドは、その層が攻撃に対してどう振る舞うかについてのデータをチームに提供していません。

モデルは攻撃対象領域のすべてではありません。むしろ、モデルはもはや最も変動要因の大きい部分でさえなくなりつつあります。もしあなたのチームが今まさにフレームワークの選定中であったり、あるいはこうしたテストを一度も行わないまま既にフレームワークを出荷済みであったりするなら、それは次のインシデントが起きて否応なく突きつけられる前に、今週のうちに議論しておく価値のあるテーマです。