AI・暗号資産ニュース&分析

Salesforce Headless 360、業務ロジックをエージェント機能へ

Salesforceが統制された業務機能をMCP経由で公開。課題はAPI連携から、発見・委任・実行をどう制御するかへ移ります。

読了目安 5分

Salesforceが発表したもの

Salesforceは8月25日、Headless 360を同社プラットフォーム全体へ拡張すると発表しました。オープンベータのHeadless 360 MCP Server、一般提供中のData 360 MCP Server、100以上の一般提供中のエージェントスキル、一般提供中のSlackbot MCPクライアントに加え、主要クラウドのヘッドレス機能が含まれます。

Salesforceによると、Agentforce、Claude、ChatGPT、Cursorなどの認可済みエージェントは、既存のID、権限、メタデータ、検証ルール、ワークフロー、ガバナンス、業務ロジックを引き継ぎながら、機能を動的に発見・実行できます。Data 360サーバーは約200のAPIを公開し、セマンティックモデル作成、変換、IDグラフ確認、セグメント作成、アクティベーションなどを扱えるとしています。

連携単位がAPIより上位へ移る

重要な変化はMCP接続そのものではありません。Headless 360は単なるエンドポイントではなく、業務上の振る舞いを発見可能な機能としてまとめます。複数のエージェントが同じCRM、サービス、コマース、データ処理を使う際、ポリシーやオーケストレーションの重複実装を減らせます。

本番環境では、モデルの推論と基幹システムの間に「機能レイヤー」が生まれます。各機能には、限定された目的、型付きの入出力、明示的な副作用、決定論的な検証、バージョニングという安定した契約が必要です。これらがなければ、動的発見はAPIの乱立を機能の乱立へ置き換えるだけです。

権限継承だけでは十分ではない

SalesforceのIDとガバナンスを再利用すれば、プロンプトやエージェントごとの連携にアクセスポリシーを再実装せずに済みます。ただし、機能へ到達する権限は、その呼び出しが安全であることを保証しません。正しく認証されたエージェントでも、注入された指示、古い情報、曖昧な顧客ID、重複リクエストによって誤動作し得ます。

重要操作には、実行時の最小権限スコープ、取引・情報持ち出しポリシー、承認閾値、冪等キー、頻度・金額上限が必要です。監査記録では、人の委任、エージェントID、モデル判断、機能呼び出し、実際の状態変更を結ぶべきです。キャッシュ済みセッションや実行中処理に対する権限取消もテスト対象になります。

Ineezaの見解

Headless 360は、企業向けプラットフォームが統制された業務ロジックを再利用可能なエージェント基盤として公開し始めた点で重要です。持続的な設計パターンは、ポリシーを継承した機能の再利用です。一方、発見可能性と認証を操作レベルの認可と取り違えることが運用リスクになります。発見される各機能を特権的な実行境界として設計すべきです。

Ineeza ホーム