AI エージェントを企業の権限境界内で動かす方法
企業に必要なのは、AI エージェントをスーパー管理者にすることではありません。ユーザー権限を継承し、危険な操作は承認へ回し、すべてを監査できる制御されたエージェントです。
企業が AI エージェントを検討するとき、最初によく出る質問はこうです。
CRM、ERP、チケット、契約、注文などの実業務システムに接続できるのか？
しかし本当に問うべきことは少し違います。
どのユーザーの身元でアクセスするのか。何を読めるのか。何を変更できるのか。問題が起きたとき、何が起きたかを追跡し、すぐ止められるのか。
これらが不明なままでは、強力なエージェントは新しいセキュリティの死角になります。システム横断でデータを読み、ツールを呼び、レコードを変更できるのに、実在するユーザーの職務権限には縛られません。
企業向けエージェントの目的は、AI に特権を与えることではありません。明確な境界の中で、ユーザーの仕事を進めることです。
エージェントはユーザー身元を継承する
エージェントは万能アカウントやデータベース管理者権限で動くべきではありません。
ログイン中のユーザーを代表して動くべきです。営業担当が自分の顧客だけを見られるなら、エージェントも同じ顧客だけを見ます。サポート担当が自分のキューのチケットだけを扱えるなら、エージェントもその範囲に留まります。
このルールにより、退職、異動、権限変更がそのままエージェントの能力に反映され、監査ログも実ユーザーに結びつきます。
これはプロンプトに任せるべきではありません。モデルに「越権しないで」と伝えるだけでは不十分で、ランタイムの権限システムが強制する必要があります。
権限はオブジェクト、レコード、フィールド、アクション単位で必要
企業の権限は「CRM にアクセスできる」だけでは粗すぎます。
安全なエージェントには、オブジェクト権限、レコード権限、フィールド権限、アクション権限が必要です。
- オブジェクト権限: 顧客、注文、チケット、契約などにアクセスできるか。
- レコード権限: 自分の顧客、地域の注文、チームのキューなど、どの具体的なレコードを見られるか。
- フィールド権限: 契約金額、原価、個人番号、内部メモなどを見られるか。
- アクション権限: タスク作成、ステージ変更、チケット終了、見積送信、割引変更、権限変更ができるか。
多くの AI プロジェクトは、権限モデルが粗すぎるために失敗します。「顧客を検索できる」ことは分かっていても、すべての顧客を見てはいけないこと、機密フィールドを読めないこと、高リスク操作を実行できないことを表現できません。
ObjectOS は業務オブジェクト、フィールド、アクション、権限を宣言的メタデータとして扱います。エージェントは生のテーブルや任意 API ではなく、その境界内の制御されたツールを通じて動きます。
まず読み取り、次に提案、最後に実行
初日からエージェントに業務データを更新させるのは、通常よい出発点ではありません。
安全な導入は三段階です。
読み取り専用: SLA 超過チケットの検出、顧客課題の要約、遅延しそうな注文の一覧化など。書き込みや外部アクションは行いません。
提案: 「これらのチケットを優先度高にする」「この顧客にフォローアップタスクを作る」などを提案し、人が確認してから保存します。
制御された実行: 低リスクで境界が明確、かつ戻せる操作だけを自動実行します。高リスク操作は承認が必要です。
この段階設計により、企業は「使わない」か「完全自動化」かの二択ではなく、徐々にエージェントの範囲を広げられます。
高リスク操作には承認とロールバックが必要
削除、顧客・注文・契約・在庫・財務データの一括変更、金額や割引の変更、外部メールや契約の送信、権限変更、有償外部サービスの呼び出しは高リスクです。
これらはモデルの判断だけに任せられません。実行前に影響範囲、理由、対象レコードを表示し、権限を持つ人の承認を待つべきです。
また、実行前後の状態を記録し、失敗時に取り消し、補償、手動復旧ができる必要があります。500 件を変更しようとする、機密顧客に触れる、金額上限を超える場合は、ランタイムが停止して人にエスカレーションすべきです。
承認は AI を遅くするためではなく、AI を本番環境に入れるための条件です。
読み取りと書き込みはすべて監査可能にする
エージェントの行動は、データ読み取り、分析、提案、ツール呼び出し、確認待ち、レコード更新という連鎖です。問題が起きたとき「このレコードが変わった」だけでは足りません。
監査では、誰がタスクを開始したか、どのオブジェクトとレコードを読んだか、どのフィールドが隠されたか、どのツールを呼んだか、何を提案したか、誰が承認したか、データがどう変わったかを説明できる必要があります。
監査は責任追及のためだけではありません。チームが安全にエージェントの範囲を広げるための根拠です。
制御されたユーザーか、影の管理者か
企業向けエージェントを評価するなら、次の質問をします。
- 実ユーザーとして動くか。
- オブジェクト、レコード、フィールド、アクション権限を継承するか。
- データベース全体ではなく、制御されたツールでアクセスするか。
- 読み取り、提案、実行の段階を分けられるか。
- 高リスク操作に承認、ロールバック、自動停止があるか。
- 読み取り、提案、書き込みを監査できるか。
答えが多く否定なら、それは企業向けエージェントではなく、新しいセキュリティ盲点です。
ObjectOS の立場
ObjectOS は、価値ある AI が業務システムに入っていくという現実から出発します。
AI は顧客、注文、チケット、契約、承認を読み、業務オブジェクト間の関係を理解し、許可された範囲で仕事を進める必要があります。
しかし、企業ガバナンスを迂回してはいけません。
ObjectOS はオブジェクト、フィールド、ワークフロー、権限、アクションを一つのメタデータ層に置きます。エージェントはその層を通じて働きます。AI は実業務に近づきますが、すべてのステップに身元、境界、証拠が残ります。