MAF 1.0の5つのバグ — MSエージェントフレームワークのエラー回避術

AutoGenとSemantic Kernelを統合し、Microsoftが満を持してリリースした「Microsoft Agent Framework (MAF) 1.0」が、正式リリースと同時に大きな波紋を呼んでいます。厳格なコードベースのグラフ実行方式として期待を集めていましたが、実際に本番環境へ適用した開発者たちは、予期せぬ致命的なバグに頭を抱えています。現場で開発者を苦しめているシステムエラーとは何か、そしてそれらをどのように回避しているのか、重要なポイントをわかりやすく解説します。

正式リリースされたMAF 1.0、何が変わったのか？

MicrosoftがAutoGenとSemantic Kernelを統合してリリースした「Microsoft Agent Framework (MAF) 1.0」の核となるのは、予測可能性です。かつての不安定でランダムなプロンプトベースのループから脱却し、コードで明確に制御されるグラフ実行構造へと完全に刷新されました。

この構造を支える2つの主要なオーケストレーション手法が「ハンドオフ（Handoff）」と「マジェンティック（Magentic）」です。ハンドオフは、エージェントがツール呼び出しを通じて他の専門エージェントへ対話制御権を明確に譲渡する手法です。一方、マジェンティックは1つの管理者エージェントが状況に合わせて全体的な計画を立て、下位エージェントを動的に配置して複雑なタスクを処理します。

このような精巧な設計により、マルチエージェントシステムのちぐはぐな挙動は大幅に減少すると期待されていました。しかし、実際の本番環境へ適用した開発者の間では、予期せぬ同期エラーや動作停止バグが続出しています。

ユーザーを困惑させる「人間による介入（HITL）」エラー

エージェントが重要なタスクを処理する前に人間の最終確認を受けるプロセスを「人間による介入（HITL: Human-in-the-Loop）」と呼びます。送金や予約など、取り返しのつかないミスを防ぐための安全装置ですが、Microsoft Agent Framework 1.0では、この段階で不可解なエラーが相次いで発生しています。

代表的なのがGitHub issue #8577に登録されている二重承認バグです。例えば予約作業を承認する際、同じ承認要求が同時に2回表示される現象です。開発者が片方を選んで承認しても、実行終了後に最終失敗エラーが返されます。実際のデータベース予約は完了しているのにシステムが失敗と認識するため、自動リトライコードが動作すると二重予約という大惨事に繋がります。

承認を終えた後にエージェントが迷子になるissue #8247も頭の痛い問題です。本来なら承認を求めたエージェントが制御権を再び受け取って次のステップへ進むべきですが、なぜか最初のエージェントに制御権が戻ってしまいます。その結果、次のエージェントへ制御権が正しく伝わらず、プロセス全体が停止してしまいます。

メッセージの混乱とデータ消失 — マルチエージェントエラー

複数のエージェントが協力して動作する際にも、MAF 1.0は深刻な構造的欠陥を見せています。GitHubコミュニティで最も活発に議論されている残りの3つのエラーは、この協調プロセスに集中しています。

まず、GitHub issue #6223として報告されている「マジェンティック経路探索バグ」が代表的です。マジェンティック方式では、管理エージェントが下位専門家たちを調整してタスクを分配します。本来なら前任の専門家が処理した回答を次の専門家が受け取り、コンテキストを引き継ぐべきですが、肝心の回答が抜け落ち、誤った指示だけが伝わってしまいます。結局、会話の文脈が完全に断ち切られ、的外れな結果となってしまいます。

ループが無限に回るissue #6173も悩みの種です。作業が終わればエージェントが自ら判断して会話を終了すべきですが、終了フラグが異常動作する問題です。エージェントが出口を見つけられずその場でループし続け、貴重なAPIトークンを浪費した末に、最大ラウンド超過メッセージを出して停止してしまいます。

最後に、ハンドオフ過程で発生するissue #1850「ツール紛失バグ」があります。エージェント間で対話制御権を譲渡する際、各自が持つ機能が自然に組み合わさるべきですが、新しいツールが入ってくると既存のツールリストを上書きしてしまうバグです。決済やデータ照会など特定の役割を持つ専門家が制御権を受け取った瞬間、本来必要な自身のツール権限をすべて奪われてしまい、何もできなくなるという不可解な現象です。

現場の開発者はどうバグを回避しているのか？

公式パッチが出るまで手をこまねいているわけにはいかないため、現場の開発者たちはすでに様々な回避策を共有し、バグを乗り越えています。

まず、承認の二重発生エラーを防ぐために、ミドルウェア層で重複排除機能を実装しています。固有のセッション識別子に基づきロックをかけることで、同時に承認要求が2回来ても1つだけが実行されるようセーフティネットを張る手法です。承認後に別のエージェントに戻ってしまう経路逸脱エラーについては、実行主体を強制指定するルーティングコードを直接組み込んで解決しています。

しかし、最も確実で少し苦い解決策は、結局アーキテクチャを簡素化することです。データが絡み合う並列処理を極力避け、エージェントたちが順序通りに一列に動くよう、単方向パイプラインへとグラフ構造を調整しています。スマートな動的協調を望んでいた開発者が、システムの安定性のためにエージェントの活動範囲をわざと制限しているわけです。

それでもMAF 1.0に注目すべき理由

どんなフレームワークであれ、最初の正式バージョンは常に高い注目を集めると同時に成長痛を伴うものです。現在のMAF 1.0も手動での回避コードが多く手間がかかりますが、開発者に示した方向性は明確です。予測困難な自然言語ループから脱却し、コードで精密に制御するグラフベースのエージェント設計が主流になりつつあることを、よく示しているからです。

全てのシステムをすぐに移行するのではなく、Microsoftの公式パッチ更新を落ち着いて見守りつつ、まずは軽いワークフローから段階的に実験してみることをお勧めします。骨組みはしっかり設計されたフレームワークであるだけに、今後、慢性的なバグがどのように改善されていくか注目に値します。