スキーマゲーティングとは、禁止されたツールへの呼び出しを実行時に遮断するのではなく、モデルに渡すスキーマにどのツールを含めるかを制御することでエージェントを制約するプラクティスである。ターミナル向けの効果的な AI コーディングエージェントの構築：スキャフォールディング、ハーネス、コンテキストエンジニアリング、そして得られた教訓 はこの対比を、ガードレールと存在しない道路の違いとして述べている。スキーマの中に危険なツールが見えているモデルは、それを呼び出すことについて推論し、なぜ許可されるべきかを主張し、パーミッションのロジックのエッジケースを探ることができる。これに対し、モデルは存在を知らない機能について推論することはできない。
用法
この用語は新しいメカニズムではなく、配置に関する判断を表している。同じ制限は、スキーマからツールを省くことでも、呼び出しを拒否することでも表現でき、前者の配置のほうが堅牢だというのがその主張である。OpenDev では、これは 5 つの独立した安全レイヤーの 1 つとして現れ、エージェントの計画モードにおける読み取り専用ツールのホワイトリスト、サブエージェントごとの許可ツールのリスト、そして外部から発見されたツールのうちどれがそもそもコンテキストに入ってよいかのゲーティングとして実現されている。同じレポートは、計画エージェントのスキーマから書き込みツールを除外できるようにするために、まさに計画と実行の役割を別々のエージェントとしていると説明している。
適用される場面
これは、使用を単にレビューするのではなく防がなければならないツールをエージェントが持っており、かつ差し控えるべきツールの集合がターンの開始前に分かっている場面に適用される — 書き込みを行うべきでない計画フェーズや、シェルを呼び出すべきでないサブエージェントなどである。ツールの集合がグローバルに固定されるのではなく、エージェントごと・モードごとに組み立てられることを前提としており、これは呼び出し時に後付けできるものではなく、スキャフォールディングの段階の性質である。
これは他のレイヤーを置き換えるものではなく、レポートもそのようには提示していない。人間が目にすべき操作には依然として承認システムが必要であり、正当ではあるがその細部において危険な呼び出しには依然としてツール内部での検証が必要である。また、エージェントが持つべきツールを誤用する場合については何も言わない。レイヤーを独立に保つことについてのレポートの論拠は、1 つのレイヤーのバグが別のレイヤーを弱めるべきではない、というものである。
証拠としては、これは単一のシステムの設計上の根拠であり、測定結果ではなくアーキテクチャ上の決定を提示すると明言している技術レポートの中で、その作者によって報告されたものである。スキーマゲーティングが実行時のパーミッションチェックよりも堅牢だという主張は、モデルが見えているものについて推論できるという点から論じられており、比較評価に基づくものではない。