Skip to content
プロダクト

10から11へ:ガバナンススタックにツール承認ゲートを追加した理由

JieGouのガバナンススタックはツール承認ゲートの追加により10層から10層に成長しました。何が変わったか、なぜ重要か、各レイヤーがAIデプロイメントをどう保護するかを解説します。

JT
JieGou Team
· · 1 分で読めます

JieGou has evolved.

Since this post was published, JieGou has pivoted from an AI automation platform to an AI-powered operations company delivering managed marketing and operations services. Learn about our managed services →

10層スタックは既にカテゴリ最深でした

先月ガバナンススタックを出荷した時点で、AI自動化カテゴリで最も包括的でした。ID、データ保護、人間の監視、コンプライアンス、オブザーバビリティをカバーする10層。競合他社にはこれに近いものはありませんでした。

しかし10層スタックにはギャップがあります。ワークフローを実行するを制御できます。ワークフローがアクセスするデータを制御できます。ワークフロー実行前に人間の承認を要求できます。制御できなかったのは、実行中にエージェントが呼び出す特定のツールです。

ギャップ:ツールレベルのガバナンス

Slack、Gmail、SalesforceのMCPサーバーを使用するワークフローを考えてみてください。ワークフローは実行が承認されています。エージェントは正しい権限を持っています。しかしそのエージェントが明示的な承認なしにGmail経由でメールを送信できるべきでしょうか?Salesforceレコードを自律的に更新できるべきでしょうか?

n8nはこのギャップを認識し、個々のツールコールレベルでヒューマンインザループを追加しました。彼らの実装では個々のユーザーが実行中にツールコールを承認できます。しかしユーザー制御であり、管理者制御ではありません。組織ポリシーレイヤーがありません。

私たちは異なるアプローチを取りました。

ツール承認ゲート:第10層

ツール承認ゲートは、実行前にどのツールが人間の承認を必要とするかについて管理者にきめ細かな制御を提供します。これはワークフローレベルの一時停止ではありません。ツールレベルのゲートです。

仕組みは以下の通りです:

  1. 管理者が承認必須ツールを設定します(MCP ACL設定で)。アカウントのMCPサーバーカタログ内の任意のツールにフラグを立てられます。
  2. ワークフロー実行中、エージェントがフラグ付きツールを呼び出そうとすると、実行が一時停止します。
  3. 承認リクエストが作成され、ツール名、エージェントが送信しようとする入力パラメータ、エージェントIDコンテキストが表示されます。
  4. 承認者がレビューして決定します — 承認して進行、拒否してスキップ、またはタイムアウトで自動拒否。
  5. 実行が再開され、決定が監査証跡に記録されます。

n8nのアプローチとの主な違い:承認ポリシーは個々のユーザーではなく管理者によって設定されます。承認者はエージェントのスポンサー、最小ロール以上の任意のユーザー、または特定の指名ユーザーとして設定できます。タイムアウトと通知設定はユーザーごとの設定ではなく組織ポリシーです。

完全な10層スタック

各レイヤーの機能:

| # | レイヤー | ガバナンス対象 | |---|---------|--------------| | 1 | ロールベースアクセス制御 | 誰が何をできるか(6ロール、24権限、部門スコーピング) | | 2 | エージェントID | エージェントごとの権限、レート制限、監査コンテキスト伝播 | | 3 | 監査ログ | 280以上のアクションタイプ、不変、エクスポート可能なエビデンス | | 4 | PII検出 + トークン化 | 機密データの自動検出と可逆トークン化 | | 5 | 段階的自律性 | 4信頼レベル(手動から完全自動)、ポリシー駆動エスカレーション | | 6 | ツール承認ゲート | 管理者制御のツールごと承認(実行前) | | 7 | データレジデンシーコントロール | HIPAA、GDPR、PCI-DSS、SOX、FedRAMPコンプライアンスプリセット | | 8 | エンベロープキー暗号化 | BYOKのためのHKDF-SHA256鍵導出付きAES-256-GCM | | 9 | コンプライアンスダッシュボード + SOC 2 | 21ポリシー、17 TSCコントロール、エビデンスエクスポート、Vanta統合 | | 10 | EU AI Actコンプライアンスエンジン | 10条項マッピング(Art. 9-17, 52)、リスク分類、エビデンス生成 | | 10 | ガバナンス準備度評価 | 全ガバナンスレイヤーにわたるセルフサーブスコアリングと推奨事項 |

各レイヤーは独立して動作しますが他のレイヤーと統合されています。エージェントID(レイヤー2)はツール承認ゲート(レイヤー6)を通じて伝播し、承認者はどのエージェントがツールアクセスを要求しているか正確に確認できます。監査ログ(レイヤー3)はすべての承認決定を記録します。コンプライアンスダッシュボード(レイヤー9)は組織全体のツール承認コンプライアンスを追跡します。

深さが広さより重要な理由

Microsoft、OpenAI、Anthropicはすべてガバナンスに投資しています。MicrosoftのAgent Frameworkは基本的なロール割り当てを追加。OpenAI FrontierにはエージェントごとのID。Anthropicはエンタープライズ管理コントロールを提供。

これらは重要な第一歩です。しかしガバナンスの深さはフィーチャーではなくレイヤーで測定されます。ロールベースアクセスがあるがPII検出がないプラットフォームにはガバナンスギャップがあります。監査ログがあるがツールレベルのコントロールがないプラットフォームにはガバナンスギャップがあります。コンプライアンスプリセットがあるがEU AI Actマッピングがないプラットフォームにはガバナンスギャップがあります。

10層は10の潜在的な障害点がカバーされていることを意味します。10という数字を選んだからではなく、エンタープライズAIデプロイメントには少なくとも10の異なるガバナンス要件があるからです。

次は何か

ガバナンス軍拡競争は加速しています。すべての主要プラットフォームがガバナンス機能を出荷しています。問題はもはやAIエージェントをガバナンスするかどうかではなく、どれだけ深くです。

新しいガバナンス要件が出現するたびにレイヤーを追加し続けます。スタックは成長するよう設計されています。

ガバナンススタックを探索 | ガバナンス準備度評価を試す

governance tool-approval enterprise compliance ai-agents
この記事をシェアする

この記事はお役に立ちましたか?

ワークフローのヒント、製品アップデート、自動化ガイドをメールでお届けします。

No spam. Unsubscribe anytime.