AI ガバナンスアーキテクチャ: v2 で延期されたケイパビリティ

概要

このドキュメントは、v1 の AI ガバナンスルールエンジン（AI ガバナンスアーキテクチャ: Persistent Tool Rules Engine）から延期されたケイパビリティを追跡します。

これらは投機的な機能ではなく、初期のデリバリーをコアのガバナンスモデルと階層的解決に集中させるために v1 のスコープから外された、既知のニーズです。

1. Glob と Regex の引数マッチング

何か: ai_tool_rules の match_type カラム。tool_arguments をどのようにマッチさせるかを制御します。0 = 完全一致（v1、現状）、1 = glob、2 = regex。

なぜ延期したか: v1 では tool_arguments をテーブルに保存しますが、解決には使用しません。glob と regex は、リゾルバ（特異性に基づく優先順位 — 項目 6 を参照）と UI（ユーザーがマッチングのセマンティクスを理解する必要がある）の両方に複雑さをもたらします。

いつ優先するか: 「/src/* 以下のすべてに read_file を許可」や「rm -rf.* にマッチする run_command を拒否」のようなルールがユーザーに必要になったとき。

スキーマ追加:

t.integer :match_type, default: 0, limit: 2  # 0: exact, 1: glob, 2: regex

2. tool_arguments への GIN インデックス

何か: tool_arguments JSONB カラムに対する PostgreSQL の GIN インデックス。

なぜ延期したか: GIN インデックスは包含演算子（@>、?、?|）をサポートします。これらは glob/regex マッチングにおいて、リゾルバが指定された引数を含むか重複する引数パターンを持つルールを見つける必要がある場合に役立ちます。v1 では tool_arguments は保存されますが、解決には使用されません。

いつ優先するか: glob/regex マッチング（項目 2）と同時にリリース。

スキーマ追加:

add_index :ai_tool_rules, :tool_arguments, using: :gin

3. 監査専用モード

何か: ai_tool_rules の audit_only boolean カラム。true の場合、ガバナンスの判断はログに記録されますが、強制はされません。ツールはルールが存在しないかのように進行しますが、監査証跡には何が 起こるはず だったかが記録されます。

なぜ延期したか: 意味のあるものにするためには、監査ロギングパイプラインとの統合が必要です。また、慎重な UX 設計も必要です。監査専用ルールが自分を保護しているわけではないことをユーザーが理解する必要があります。

いつ優先するか: セキュリティチームが、開発者のワークフローを妨げずに本番で新しいポリシーをテストする機能を要求したとき。大規模なコンプライアンスプリセットのロールアウト（項目 5）の前に必要になる可能性が高いです。

スキーマ追加:

t.boolean :audit_only, default: false, null: false

4. コンプライアンスプリセット

何か: 管理者が組織全体にわたって特定のツールに対する deny ルールを即座に作成するために適用できる、事前構築されたルールテンプレート（例えば SOC2、HIPAA）。

なぜ延期したか: バルクミューテーション（項目 1）と、安全なロールアウトのためにおそらく監査専用モード（項目 4）が必要です。また、プリセットがフレームワークの要件を正確に反映していることを確認するために、法務／コンプライアンスレビューも必要です。

いつ優先するか: エンタープライズ顧客が AI ツールガバナンスのためのワンクリックコンプライアンス態勢を要求したとき。これは項目 1 と 4 を結びつけるキャップストーン機能です。

5. 特異性に基づく優先順位

何か: 複数のルールが同じツールに適用される場合（例えば、/etc/* 用の glob ルールと、より特定的な /etc/passwd のルール）、リゾルバは階層ロジックを適用する前に、最も特異な引数マッチを優先します。

なぜ延期したか: glob/regex マッチング（項目 2）がサポートされている場合のみ意味があります。v1 では引数マッチングがないため、ルールはツール名にマッチするかしないかのいずれかであり、解決すべき曖昧さはありません。

いつ優先するか: glob/regex マッチング（項目 2）と同時にリリース。リゾルバのロジックはマッチングのセマンティクスと一緒に設計する必要があります。

6. 拒否されたツールのプロンプトフィルタリング

何か: ツールが deny ルールでブロックされた場合、LLM に送られるツールリストから完全に除外します。モデルは使用できないツールを一切目にしません。

注記: v1 では、拒否されたツールは DWS が LLM にツールを提示する前に、すでにツールセットから取り除かれています。モデルは拒否されたツールを目にしません。この項目は、ツールセットレベルではなく DWS 内のプロンプト組み立てレベルでのフィルタリングのより深い統合を追跡します。

なぜ延期したか: プロンプトレベルのフィルタリングには、LLM のシステムプロンプトを構築するツールリスト組み立てパイプラインとの統合が必要です。これは現在のツールセットレベルのフィルタリングよりも深い統合です。

いつ優先するか: 現在のツールセットレベルのフィルタリングが、特定のサーフェスやワークフロータイプに対して不十分であることが判明したとき。

7. ユーザーレベルの自動承認オプトイン

何か: 個々のユーザーが特定のツールに対する自動承認をオプトインできるようにし、明示的に事前承認したツールについては承認プロンプトをバイパスします。これには、ai_tool_rules にスコープカラムとして user_id を追加し、ネームスペースとプロジェクトのルールの後に 3 回目の解決パスを追加する必要があります。

なぜ延期したか: 主なユースケースは IDE/Editor Extensions です。ローカルワークフローで特定のツールを承認するよう頻繁にプロンプトされるユーザーが、そのツールに対する自動承認をオプトインできるようにすることです。ガバナンスの観点からは、ユーザーは管理者が設定した HITL の強制をバイパスできるべきではありません。意図したモデルは、管理者がユーザーレベルの設定をアンロックでき、ユーザーは管理者ポリシーの範囲内で自身の好みを設定できる、というものです。これは GA 後のスコープです。

いつ優先するか: Editor Extensions がユーザーレベルのオプトインメカニズムを正当化するユーザー向けの HITL 摩擦を表面化させたとき。

スキーマ追加:

t.references :user, null: true, foreign_key: { on_delete: :cascade }

8. インスタンスレベルのルール

何か: トップレベルグループ（TLG）の上、インスタンスレベルで設定されるルール。セルフマネージドインスタンス上のすべてのグループに単一のポリシーを適用します。

なぜ延期したか: 現在の TLG レベルのルールはすでにグループ内のすべてのプロジェクトにカスケードしており、ほとんどのエンタープライズユースケースをカバーしています。インスタンスレベルのルールは、インスタンス上のすべてのグループに単一のポリシーを設けたいセルフマネージド顧客に必要です。GA 後のスコープです。

いつ優先するか: セルフマネージド顧客が、個々のグループオーナーに委譲できないインスタンス全体のガバナンスポリシーを必要としたとき。

9. Traversal IDs による単一クエリ最適化

何か: GitLab の traversal_ids（ネームスペース上のマテリアライズドパス）を使用して、祖先階層全体にわたるすべてのルールを単一のクエリで取得し、現在の 2 クエリアプローチ（ネームスペースとプロジェクトのルールに対する個別のクエリ）を置き換えます。

なぜ延期したか: 現在の 2 クエリアプローチはクリーンで理解しやすいです。ルールテーブルとツールレジストリの現在のスケールでは、これは効率的です。この最適化が正当化されるかどうかを判断するには、本番データが必要です。

いつ優先するか: 本番のクエリ頻度や深いグループ階層が、2 クエリアプローチがパフォーマンスのボトルネックであることを示したとき。

ページのソースコードを見る - ページの編集 - please contribute.