AI Control Planeから考える、エージェントを管理し続ける仕組み

AIエージェントを業務に導入する際は、利用目的と権限に加え、運用中の見直しや利用終了の担当も決めておく必要があります。

部署ごとに導入が進む場合には、個別の設定を管理するだけでなく、社内で何が動き、誰が管理しているかを共通の一覧で確認できるようにしておきたいところです。

Salesforceは2026年9月11日、企業向けAIの共通アーキテクチャ「Trusted Enterprise AI Harness」と、その管理基盤「AI Control Plane」を発表しました。

本稿では、この発表のうち、エージェントを継続的に把握・管理する部分を取り上げます。

各要素の技術的な実装方式や、個々の製品機能の詳細には踏み込みません。

ここでいう統制とは、利用ルールを決め、その適用状況を確認し、必要に応じて修正することを指します。

何が発表されたのか

Salesforceの発表によれば、Trusted Enterprise AI Harnessは、AIが企業の情報を理解し、計画・実行し、業務上のルールに従って動くための機能を組み合わせた共通アーキテクチャです。

Salesforceは、その構成要素を次の6つに整理しています。

要素	Salesforceの説明の要旨
Trusted Context	顧客情報、データ、知識、リアルタイムの情報などを統合し、業務の進め方の理解につなげる
Trusted Agency	推論、計画、状態の管理、記憶を備え、複数のエージェントの処理順序や連携を調整する
Trusted Action	アプリ、API、ワークフローなどへ安全に接続し、実際の処理を行う
Trusted Governance	データや管理ルールを整え、データの出所・加工経路・品質を把握する
Trusted Security	ID、権限、プライバシー、データ保護、実行時のセキュリティを適用する
Trusted Models	業務に適したモデルを選び、精度・性能・コスト・業務要件に応じて処理を振り分ける

6つの要素は、AIによる業務の理解、判断、実行と、それを支える管理・保護の仕組みを組み合わせたものです。

本稿では、そのうちエージェント全体を継続的に把握するAI Control Planeに注目します。

AI Control Planeは、エージェントの所在、設定、稼働状況などを横断的に把握・管理するための基盤です。

Salesforceの説明によれば、Salesforce製と他社製のAIを対象に、エージェントとAI機能の発見・登録、IDとポリシーの設定、ライフサイクル管理、パフォーマンスの評価、挙動と結果の観測、コスト管理を、個別に管理せずに行えるようにするものとされています。

ただし、登録されていないエージェントをどの範囲まで自動で見つけられるかといった具体的な条件は、発表本文からは確認できません。

「発見」という機能名から、社内のあらゆるAIを自動的に把握できると考えないことが大切です。

提供時期について、Salesforceは、土台となる技術の多くはすでに利用可能で、新機能と統合された利用環境はFY28、すなわち2027年2月に始まる会計年度の初期から、順次提供を始める予定としています。

価格や提供パッケージの詳細は、今後あらためて発表するとされています。

管理が難しくなるのは、作る人と変える人が分散したとき

エージェントの管理が難しくなる理由は、数そのものよりも、作成や変更に関わる人が分散し、その変化が共通の記録に反映されないことにあります。

例えば、各部署が業務用エージェントを導入していても、登録先や変更の報告先が決まっていなければ、全社の一覧と実際の稼働状況が一致しなくなる可能性があります。

個々の担当者が設定を把握していても、その担当者が異動したり、別部署との連携が増えたりしたときに、会社として確認できる記録が必要になります。

全体の管理責任者や共通の記録が定まっていなければ、個々のエージェントを丁寧に設計していても、会社として何が動いているかを答えられません。

AI Control Planeが「発見・登録」を機能の最初に挙げているのは、この問題への対応として読めます。

既存のエージェントを整理する場面では、まず何がどこで動いているかを調べることに意味があります。

一方、新規に導入する場面では、登録情報の整理と権限の設計を並行して進められます。

私たちは、個別の権限設計と全体の把握を、どちらかを先に済ませるものとしてではなく、あわせて維持するものとして考えています。

ライフサイクル管理は、1つ目のエージェントから必要になる

Salesforceの説明にあるライフサイクル管理は、エージェントの管理を導入時点で終わらせないという考え方だと私たちは受け止めています。

エージェントは、作った時点の業務や権限の前提に合わせて設計されます。

しかし業務は変わり、担当者は異動し、当初は必要だったアクセス範囲が、業務の変更によって不要・過剰になることがあります。

プロジェクト用に作られたエージェントが、プロジェクトの終了後も権限を持ったまま動き続けている、という状態も起こり得ます。

これらは、エージェントが1つであっても起こり得る変化です。

人のアカウント管理でも、異動した社員の権限が見直されずに残る、使われなくなったアカウントが放置される、といったことが起きてきました。

エージェントの管理も、同じように導入後の見直しと利用終了までを含めて考える必要があります。

継続的な監視と定期的な見直し、一覧の整備、安全な利用終了の手順は、米国国立標準技術研究所（NIST）のAI Risk Management Framework Playbookでも、AIシステムの管理の論点として扱われています。

見直しの周期を決めておく、最終確認日と最終稼働日を記録しておく、現在の管理責任者が分からなくなったエージェントを検知できるようにしておく、といった取り組みは、担当者の異動や利用終了の際にも、見直しを引き継ぎやすくします。

モデルの変更も、管理の対象に含めておく

Trusted Modelsは、業務に適したモデルを選び、処理を振り分ける仕組みとして説明されています。

モデルは今後も更新され、提供条件も変わっていきます。

モデルを変更すると、提案の内容、選択する操作、出力の形式などが変わる可能性があります。

これは再評価が必要になる理由ですが、承認が必要な操作を承認なしで実行できるようになる、という意味ではありません。

重要な操作の許可を、モデル自身の判断だけに依存させないことが前提です。

例えば「送信には承認が必要」という制限を送信機能の側に設けておけば、新しいモデルが送信を提案しても、承認がなければ実行されません。

実行を受け付ける仕組みの側で権限を確認するという考え方は、OWASPのLLMアプリケーション向けリスク資料が「過剰な権限」への対策として挙げている内容とも沿うものです。

そのうえで、モデルを変更する際は、出力の品質やツールの使い方、承認が必要な操作の扱いが、業務上の条件を満たしているかを確認します。

使用するモデルと構成、評価結果、変更の承認者を記録し、問題がある場合の変更の切り戻しや、エージェントの停止方法も決めておきます。

条件を満たさない場合の選択肢は、別のモデルで続行することだけではありません。

以前の構成へ戻す、人の作業へ切り替える、一時停止する、といった判断もあります。

MIFは、モデルの変更も、接続先や権限の変更と同じように管理対象へ含めることを勧めます。

これはMIFの運用上の提案であり、Trusted Modelsがこの一連の管理を自動で行うという意味ではありません。

台帳に記録しておきたい項目

エージェント個々の権限設計とあわせて、社内のエージェントをどう一覧・管理するかという台帳の型を決めておくと、部署やエージェントが増えても把握を保ちやすくなります。

以下はMIFの提案としての一例です。

Salesforceの製品の項目や、全社共通の必須様式を示すものではありません。

自社の規模、業務、適用されるルールに合わせて過不足を調整してください。

項目	記録すること
識別情報・目的	名称、区別できる管理ID、利用目的、稼働する環境（本番用か検証用か）
管理責任者	現在の担当者・責任部署・連絡先、異動時の引き継ぎ先
モデル・構成・接続先	使用モデル、確認可能な版や設定、接続するシステム・他のエージェント
実行アカウントと権限	誰の権限で、どのデータを参照し、どの操作を実行できるか
承認条件	人の承認が必要な操作、承認者、その条件を適用する設定の参照先
稼働状況	開発中・利用中・停止中・利用終了などの状態、最終稼働日
見直し	最終確認日、次回予定、確認担当者、変更時に再確認する条件
停止・利用終了	停止・利用終了の判断者、停止方法、取り消す権限、それらを実施したことの確認記録
設定・評価・ログの参照先	実際の設定、テスト結果、操作記録を確認できる場所

作成者ではなく「現在の管理責任者」を記録するのは、誰が作ったかと、今誰が更新・停止・引き継ぎに責任を持つかが別だからです。

見直しの欄に次回予定だけでなく最終確認日を入れるのは、予定どおり確認が行われたかを後から確かめられるようにするためです。

情報をすべて台帳へ転記する必要はありません。

既存の設定や記録への参照先をまとめる形にすれば、二重管理を増やさずに済みます。

また、最終稼働日が古いことだけで不要と判断せず、用途や次回の利用予定もあわせて確認することをお勧めします。

台帳を、実際の設定とつなげる

台帳は、作っただけでは未登録のエージェントを見つけられません。

登録されなかったものは、台帳をいくら見直しても載っていないからです。

そのため、新規導入時の登録だけでなく、変更や利用終了も記録へ反映します。

そのうえで、定期的に実際の配備状況やアカウント・権限の設定と照合し、未登録の利用や、台帳と設定の食い違いがないかを確認します。

また、台帳に「閲覧のみ」と書かれていても、接続先のシステムがそのエージェントにデータの更新を許可していれば、意図した制限にはなりません。

権限は、実際に処理を受け付けるシステムの側で適用されている必要があります。

私たちが勧めるのは、一覧を作る、実際の設定と照合する、変更時に更新・再確認する、不要になったエージェントの利用を終了し、不要な権限を取り消す、という流れを一続きの運用として回すことです。

この照合をAI Control Planeがどの環境でどこまで自動化できるかは、今回の発表からは確認できていません。

製品を使う場合も使わない場合も、照合の手順と担当者は自社で決めておく必要があります。

まとめ——個別の権限設計を、継続的な管理につなげる

AIエージェントを業務で使う際は、許可する操作を決めることと、その設定や責任者を継続的に確認できることを、あわせて考える必要があります。

MIFが重視するのは、用途、責任者、モデル・構成、権限、稼働状況を共通の記録で把握し、変更や利用終了を実際の設定へ反映することです。

部署やエージェントの数が増えても、その対応関係を維持できる仕組みを目指します。

まずは利用中・導入予定のエージェントについて、誰が管理し、何が変わったら見直し、不要になったらどう終了するかを整理する。

本稿の台帳項目を、その出発点として活用してください。

情報確認について

本記事は2026年9月26日確認時点で、Salesforceが2026年9月11日に公開したプレスリリース「Salesforce Introduces the Trusted Enterprise AI Harness」を主要な参照元として作成しています。

6つの要素の説明、AI Control Planeの機能、提供時期の見込みは、いずれもSalesforceによる発表時点の説明です。

FY28はSalesforceの会計年度（1月31日終了）で、2027年2月1日から2028年1月31日までに当たります。

新機能の提供時期・提供範囲・価格は今後変更される可能性があるため、導入を検討する際はSalesforceの公式情報で最新の状況をご確認ください。

製品の構成・機能・提供予定に関する記述は、Salesforceの公表資料に基づきます。

台帳項目と運用方法はMIFによる分析・提案であり、MIFが製品の検出範囲や制御の有効性を独立に検証したものではありません。

継続管理の考え方については、米国国立標準技術研究所（NIST）の「AI Risk Management Framework Playbook」、OWASPの「OWASP Top 10 for LLM Applications」も参照しています。