マイクロソフトがPython向けAgent Framework 1.25.0を公開した。今回は、外部ツールサーバーとの通信規約であるMCPを通じて読み込むカタログ、つまりツール一覧をまとめた資料のサイズを制限する。また、あるユーザーのワークフロー実行器とセッションが別の権限スコープで再利用されないよう変更した。複数のユーザーが同じエージェントサービスを使う場合、開発者は探索設定とワークフローの生成方法を併せて点検する必要がある。
1. MCPカタログ探索に上限を設ける
リリースノートによると、agent-framework-coreとagent-framework-declarativeは、MCPツールとプロンプトのカタログ探索量、およびフレームワークが管理するリクエスト時間を次のように制限する。
表：MCP探索・リクエストの既定設定
条件：MCPツール・プロンプトの探索と、フレームワークが所有するリクエストに適用する既定値
単位：ページ、項目、秒
| 設定 | 既定値 | 適用対象と条件 |
|---|---|---|
| 探索ページ数の上限 | 100ページ | ツール・プロンプトのカタログごとに適用 |
| 探索項目数の上限 | 1,000項目 | ツール・プロンプトのカタログごとにページ数とは別に適用 |
| リクエストのタイムアウト | 30秒 | フレームワークが管理するリクエストに適用 |
カタログの更新に失敗すると、既存のスナップショット、つまり更新前の状態を保存したコピー全体を保持する。
大規模なカタログを使う開発者は、ページ数や項目数の上限を増やせる。信頼するMCPサーバーに限り、該当設定にNoneを指定すればその上限を解除できる。より多くの一覧を読み込む必要があれば、サーバーの信頼性と必要な探索範囲を併せて検討して設定する。
リクエストの待機時間は別途調整する。MCPツールにrequest_timeout=Noneを渡すと、リクエストのタイムアウトを無制限に戻す。独自に作成したクライアントは、自身のトランスポートとタイムアウトのポリシーを維持する。
探索の承認ポリシーに、呼び出し可能な関数を使用できるようになった。ツール名と読み取り専用かどうかを基準に許可範囲を定め、呼び出し元が明示したオーバーライド、つまり設定値の再指定を反映できる。保有するツールのポリシー更新にも対応する。
2. ワークフローの実行器とセッションを権限スコープに紐づける
ワークフローを実際に動かす実行器とセッションは、1つの権限スコープ、つまりアクセスを許可する対象の境界に紐づけられる。ある権限で使っていた実行器とセッションを別の権限のリクエストに渡すと、モデル呼び出し前に拒否する。リクエストを受ける接続点であるAG-UIエンドポイントでは、ワークフローエージェントをツールでラップした実行も拒否する。
対応方法は、呼び出しごとに新しいワークフロー、実行器、セッションを作る関数であるファクトリを渡すことだ。リリースノートが案内する指定形式は次のとおり。
AgentFrameworkWorkflow(workflow_factory=...)スコープを超えた再利用はWORKFLOW_SCOPE_CONFLICTとして報告する。未対応のワークフローエージェントツールはWORKFLOW_AGENT_TOOL_UNSUPPORTEDとして報告するため、エラーを受けた開発者はファクトリを使ってワークフローを直接提供する形に変更する必要がある。
3. 呼び出しごとにMCPプロトコルセッションを新たに開く
リリースノートに併記されたagent-framework-declarative 1.5.0のセキュリティ修正は、呼び出し間のMCP状態共有を防ぐ。従来は初期化済みのプロトコルセッション、つまりサーバーとの対話単位をキャッシュし、次の呼び出しで再利用していた。今後はツール実行と一覧取得を含むハンドラーの呼び出しごとに、セッションを新規作成して閉じる。
その結果、呼び出し間のサーバーセッションの継続性は失われる。承認待ちや、作業の中断状態を保存したチェックポイントからの再開後も、前の呼び出しのセッション状態は引き継がれない。継続した状態が必要な開発者は、サーバーに残した状態を指す識別子であるリモート状態ハンドルを明示的に使うか、自らスコープを定めたMCPToolHandlerを用意する必要がある。チェックポイントと承認の検証自体は変わらない。
ハンドラーの生成コードも調整が必要だ。async withで作っていた方式から通常の生成方式に切り替え、aclose()の呼び出しを削除する。
従来のキャッシュサイズ引数cache_max_sizeは引き続き渡せるが、検証されずに無視される。値がNoneでない場合は非推奨警告が出る。この引数を省略すれば警告をなくせる。
4. 探索量の制限と権限分離では設計対象が異なる
100ページは探索するページ数の上限で、1,000項目はカタログから読み込む項目数の上限だ。ページ数の上限だけを増やしても項目数の上限は残るため、大規模なカタログを扱うサービスでは両方の設定を確認する必要がある。リクエストのタイムアウトは、これとは別にリクエストの待機時間に境界を設ける。
一方、実行スコープの検査は取得量ではなく、誰が実行器とセッションを再利用するかを制限する。探索量はサーバーの信頼性とカタログの規模に合わせて設定する。権限分離には、別のユーザーのリクエストへ同じ実行器とセッションを渡さないオブジェクト生成構造で対応する必要がある。
5. インストール環境と共有オブジェクトから点検する
今回のリリースから、インストールに必要なPythonの最小バージョンは3.11となる。Python 3.10環境なら、まず実行環境をアップグレードする必要がある。
探索上限を公開する既定のMCPハンドラーと、ワークフローの所有権検査を使うAG-UIはCore 1.25を要求するため、関連する依存関係も併せて確認する必要がある。
マルチユーザーサービスの移行作業は、共有オブジェクトを探すことから始められる。実行器とセッションを保持する箇所を確認すれば、呼び出しごとに新しいオブジェクトを作るファクトリへ変更すべき部分を特定できる。
設定に応じてオブジェクトを構築するツールである共有ビルダーは、キャッシュ対象を無効にしても実行器を再利用するため、呼び出しごとの生成の代わりにはならない。シングルユーザー設定は、すべての呼び出し元が同じ主体である場合にのみ使用する。
権限スコープの検査は実行中の実行器とセッションの同一性を対象とし、共有ストレージから読み込んだ状態や、ワークフローを直接呼び出すカスタムツール関数は対象外となる。
探索量の設定を調整することと、権限の境界を超えるオブジェクトの再利用をなくすことは、別々の移行課題だ。