AWSは、目的、識別、制約、観測を重ねてエージェントを管理するTrust in Depthを紹介しました。明確に定義できるルールには、自動推論による検証を組み合わせる考え方です。 すべての操作を人が承認する運用では、確認の負担が拡大します。自動検証できる条件と人の判断が必要な場面を分け、許可範囲をシステム側で維持する設計が焦点です。 承認の量が増える問題を多層の統制で扱う AWSは2026年10月15日、Trust in Depthというエージェント管理の考え方を紹介しました。企業がAIへ多くの仕事を任せたい一方、毎回正しく動くとは信頼しきれないという課題を扱います。原文は、すべてを人が承認する運用では、確認が滞り、見落としも増える可能性を指摘しています。その上で、検証できる行動は自律的に進め、判断を要する場面に人の注意を振り向ける構成を示しました。単独のフィルターや公開前のテストだけに依存せず、複数の統制を重ねる発想です。新しい製品の提供開始ではなく、業務へエージェントを導入するための設計原則の説明です。自律性を高めるほど、何を許可するかを事前に明確にする必要があるとしています。 誰が許可した操作かを後からたどれるようにする 原文は、実行前の目的と禁止事項、配備時の識別、実行中の境界、実行後の観測を主な問いとして挙げています。組織の代理として動くエージェントを把握し、権限と操作の関係を説明できることが重要です。影響を受けるのは、社内業務を自動化する開発部門、運用管理者、承認を担当する業務部門です。明確な規則で表せる条件には、自動推論で、定めた範囲と仮定の中で規則が成立するかを調べる考え方を示しています。一方、配慮が必要な会話など、文脈に応じた判断を要する場面も残ります。数学的な確認が扱える条件と、人が判断すべき品質を分ける必要があります。検証の対象となった範囲を越えて、すべての行動が保証されたと解釈しないことが重要です。 証明の前提を変える更新を管理する 実務上は、どの規則を検証するかより前に、業務が守るべき条件を定義する作業が論点になります。たとえば承認の順番や操作できる対象が曖昧なら、形式的な検証も意図とずれる可能性があります。ツールの追加や権限変更で前提が変わる場合は、検証内容も更新する必要があると見られます。費用には、実行ログの収集、規則の保守、例外対応、担当者による定期確認が含まれます。承認を減らすこと自体を成果にせず、誤操作と確認負荷を合わせて測る設計が重要です。障害時には、エージェントの識別情報から、許可した人や設定、実行した操作へたどれることが判断材料になります。段階的に権限を広げる場合も、停止条件と復旧手順を事前に確かめる必要があります。原文が示す保証の範囲は、定義した規則と仮定に依存します。権限に付随して意図せず使える操作が増えていないかを確認すれば、目的の記述だけでは見えない範囲を整理しやすくなります。