セキュアなヘッドレスエクスペリエンスを構築する
学習の目的
この単元を完了すると、次のことができるようになります。
- AI エクスペリエンスのガバナンスと監視における自らのロールについて説明する。
- Salesforce のヘッドレスインタラクションを保護する、目に見えるレイヤーと目に見えないレイヤーを特定する。
- 「オープンアクセスであって、オープンバイパスではない」という原則について説明する。
すべてのヘッドレスエクスペリエンスに信頼を組み込む
ヘッドレス機能を使用すると、従来の Salesforce インターフェース以外からも Salesforce のデータやプロセスにアクセスできるようになります。この柔軟性により、ユーザー、アプリケーション、エージェントがこれまでとは異なる場所からアクセスを要求できるようになります。この場合、適切なガバナンスが整備されていなければ、コントロールを手放すことに不安を感じるかもしれません。けれども、システム管理者がセキュリティエンジニアやガバナンスのエキスパートになる必要はありません。日頃から Salesforce のアクセス管理で行っているように、「誰にどのレベルのアクセス権を付与し、何をできるようにする必要があるか?」と問いかけます。このバッジでは、ヘッドレスエクスペリエンスにおける AI のセキュリティとガバナンスの概念、アクセス権の決定方法、アクティビティの監視方法について説明し、最後に対応計画を作成します。
ヘッドレスセキュリティにおける各自のロール
ヘッドレス機能の世界では、Salesforce の従来のロールが変化しており、システム管理者を自認するユーザーをはじめ、どのユーザーもその気になれば構築者になることができます。システム管理者が構築を担う場合、ヘッドレスエクスペリエンスのあらゆる部分を自らコーディングしたり調査したりする必要はありませんが、どのユーザーも適切な問いを立て、ガバナンスと監視のプロセスを確立し、問題が生じた場合に対処する必要があります。各自のロールに関係なく、(個人用と業務用のどちらのユースケースでも) セキュアで信頼性の高いヘッドレスエクスペリエンスを支えるしくみとツールを理解しておくことをお勧めします。
ガバナンスと監視
では、ガバナンスと監視を定義していきましょう。ヘッドレスユースケースにおけるガバナンスと監視とは、分離されたフロントエンドアプリケーションとバックエンドサービスの管理、追跡、セキュリティ保護に使用する一連のルールやツールのことです。ガバナンスは、データへのアクセスや、誰 (人間またはエージェント) がアクセスするのかに関するポリシーを定めます。監視はプロセスを観察し、問題をすばやく見つけて修復します。ここで、シンプルなアプローチをご紹介します。
-
タスクを把握する: ユースケース、所有者、ユーザー、データ、アクションを明確にします。
-
アクセスを制限する: ユースケースまたはタスクに必要なアクセス権のみを付与します。
-
監視する: タスクを注視し、通常の状態を把握したうえで、確認が必要なクリティカルなステップを特定します。
-
問題を阻止する: タスクを停止する方法、連絡する相手、必要に応じてアクセスを遮断する方法を認識しておきます。
丈夫な木を育てる
AI や AI セキュリティについて考えるときにまず思い浮かぶのは、ツールのインターフェース、応答、ユーザーに代わってエージェントが実行するアクションなど、「目に見えるもの」ではないかと思います。目に見える要素はセキュリティのほんの一部にすぎません。ヘッドレスアーキテクチャを、植えたばかりの木に例えてみましょう。一見健康そうな木も、根が弱ければ強風に耐えることはできません。丈夫な木を育てるためには、枝や葉、頑丈な幹、根など、あらゆる部分を考慮することが重要です。木と同様に、ヘッドレスアーキテクチャでも、エクスペリエンスのあらゆる部分に注意を向ける必要があります。
-
目に見えるサーフェス (枝や葉): Slack、会話型のチャットインターフェース、目に見えるユーザーアクションなど、ユーザーとのタッチポイントは、日常業務が安全に行われる外側の樹冠にあたります。
-
Trust Layer (幹): Einstein Trust Layer は全体の支柱となるもので、そこを通過するすべてのトラフィックにデータマスキングを適用し、サーフェスレベルのリクエストが目に見えないポリシーに基づいて安全に実行されるようにします。
-
地中の基盤 (根): ロールベースのポリシー、アクセスルール、基本的なユーザー権限といったバックエンドのセキュリティコントロールが、地中でシステム全体を支え、データを確実に管理してコンプライアンスを確保します。
この地中の基盤は、目に触れることのないさまざまな要素で構成されています。具体的には次のことを確認します。
-
ID と認証 — コール元は誰で、どのように本人確認を行ったか
-
アクセスコントロールと権限 — ユーザーが参照または更新のみ可能なデータは何か
-
項目レベルセキュリティ (FLS) — レコード内のどの特定の項目が表示されるのか
-
ロールベースのアクセスコントロール (RBAC) — ロールが実行できるアクションは何か
-
コンプライアンスと監査履歴 — 規制上の目的で、あらゆるアクセスイベントを記録したもの
-
データ系統とトレーサビリティ — データの発生元を追跡する機能
-
リアルタイムの監視 — 異常なアクセスパターンの検出
-
ネットワークセキュリティ — 転送中の暗号化、ネットワーク分離
-
データ損失防止 — 機密データが承認された境界の外部に流出することを防ぐコントロール
こうした要素が欠けていると、障害や問題が積み重なり、予期せぬ形で表面化することがあります。たとえば、エージェントが本来認められていないデータを共有あるいは削除してしまうといったケースです。自社開発 (DIY) のインテグレーションで外部の AI ツールを Salesforce データに接続すれば、美しい木を育てることができます。その一方で、力強く健やかな根を張るためには、セキュリティやガバナンスのコントロールも構築する必要があります。DIY で根を張ることも可能ですが、その根の 1 本が欠けていたり、浅すぎたりしたらどうなるでしょうか? Salesforce Platform には、アクセスとコントロールを重視した 2 つの原則に基づいて、Salesforce の従来型実装とヘッドレス実装に対応する機能が用意されています。では、1 つ目の原則から見ていきましょう。
原則 1: オープンアクセスであって、オープンバイパスではない
ヘッドレスアーキテクチャを定義する原則は、「オープンアクセスであって、オープンバイパスではない」というものです。 Claude Code など、任意の外部エージェントからのヘッドレス呼び出しに、従来の Salesforce 呼び出しとまったく同じガバナンスが適用されます。接続方法やサーフェスが変わっても、セキュリティモデルや認証情報のチェックに変わりはありません。Salesforce Hosted MCP Server はデフォルトで無効になっています。システム管理者は、エージェントがアクセス可能なサーバーを明示的に有効にします。システム管理者が意図的に公開しない限り、外部に公開されることはありません。エージェントが Salesforce Hosted MCP Server を呼び出して顧客レコードを取得するときは、Salesforce ユーザーが UI のボタンをクリックする場合と同様に、ID 検証や項目レベルのセキュリティチェックが行われ、ガバナンスが適用されます。
技術的な点にも少し触れておきましょう。Salesforce の MCP サーバーは、接続アプリケーションではなく、専用の mcp_api OAuth 範囲を設定した External Client Apps (ECA) を使用します。認証フローには、Proof Key for Code Exchange (PKCE) を用いた OAuth 2.0 認証コードを採用しているため、システム管理者はヘッドレスアクセス向けに構築されたシンプルなコントロールサーフェスを利用できます。こうした MCP サーバー経由でエージェントがアクセスできる対象を厳密に管理するために、次の 3 つのツールが用意されています。
-
参照のみサーバー: 更新操作を許可せずにデータを公開して、エージェントのエラーによる影響の範囲を最小限に留めます。
-
名前付きクエリ: エージェントが必要とする範囲に限定した、パラメーター化されたクエリ式です。
-
カスタム Apex アクション: @InvocableMethod として定義された特定の操作のみを公開し、エージェントがシステムで実行できる操作をきめ細かく管理します。
詳細は、MCP サーバーのセキュリティに関するベストプラクティスを参照してください。
次のステップ
この単元では、AI のセキュリティとガバナンスの概念、「オープンアクセスであって、オープンバイパスではない」という原則、DIY インテグレーションにリスクが伴う理由を見てきました。次の単元では、ガバナンスの概念から実践的なセキュリティへと進み、最小権限の原則や、ヘッドレスエージェントの権限範囲の設定方法について説明します。
リソース