共有状態から生じる問題
プラグインが受け取るツール管理オブジェクトは、複数のリクエストで再利用されます。以前のフィルター処理はこの管理オブジェクトをリクエスト固有のものとして扱い、可変リストからツールをその場で削除していました。そのため、先に実行されたリクエストの可視範囲が、異なるグループポリシーを持つ後続リクエストにも残っていました。
発生条件は実行順序に依存します。狭い許可リストの後に広い設定を実行しても、後者は短くなったコンテナを受け取ることがあります。一種類のポリシーだけを調べるテストでは通過し、異なる設定を連続させたときに欠落が見えます。共有してよいのは登録状態であり、可視範囲は一つのリクエストだけが所有する、という境界が必要でした。
ポリシー適用前にコピーする
修正後は、許可、拒否、プラグイン範囲の規則を適用する前にコンテナを浅くコピーします。同時に tools または func_list の新しい配列を作るため、コピー側を絞り込んでも元の管理オブジェクトの一覧は短くなりません。新しい完全ツール集合 API を持たない旧形式の管理オブジェクトも、互換分岐で同じコピー関数を利用します。
コピーを作った後、リクエスト固有の可視名を計算し、ローカルコンテナだけをフィルターして現在の実行時へ渡します。共有登録とセッションポリシーが別の所有範囲に置かれるため、後続処理へ変更が残りません。
独立した機能を分けて扱う
今回の整理では、混同しやすかった信号も分けました。ツールのリマインダーは専用のプロンプト注入設定で制御されます。Step Image の参加可否は画像設定から計算されます。一般の関数ツールは、許可名、拒否名、プラグイン範囲の規則を引き続き使います。
同じ返信に関係する仕組みでも、役割は異なります。リマインダーは文脈に案内を加えるかを決め、画像設定は画像機能が参加するかを決め、可視範囲ポリシーは登録済み関数の利用範囲を決めます。信号を分けることで、一つの設定が別機能の状態を暗黙に変えることを防げます。
分離をテストで確認する
対象を絞ったテストでは元の管理オブジェクトを保持し、対応する二種類のコンテナをコピーし、コピーへ可視名フィルターを適用した後も元のツール一覧が初期値のままであることを確認します。互換分岐がフィルターより先にコピー関数を呼ぶこと、リマインダー処理が可視範囲の計算後に独立して行われることも確認します。
これは完全な二セッション実行を再現するテストではありません。以前変更が起きていた所有境界を検証し、コピーが別オブジェクトであること、コピーの一覧だけを変更できること、共有一覧が保たれることを確認するものです。
この境界がもたらすもの
ツール状態をリクエスト固有にすると、ポリシーの挙動を追いやすくなります。ある設定を調べる際に、それ以前にどのグループが動いたかを再構成する必要がありません。現行 API と互換分岐が同じ所有規則を使うため、保守テストもコピーとフィルターの境界へ限定できます。
後から機能を追加する場合も、各ツール種別が固有の設定と可視範囲規則を持ちながら、共有レジストリはリクエスト処理中に変化しません。運用上の識別情報や非公開設定を記載せず、設計上の判断を再利用できる形で残せます。