ディスカバリーとガバナンスでは、それぞれ異なる問いに対応します。
ディスカバリーが扱う問い:
- どのような信頼関係が存在するか？
- それらの信頼関係を支える前提条件は何か？
ガバナンスが扱う問い:
- ガバナンスによる対処を必要とする信頼関係について、十分かつ最新の可視性を確保できているか？
- 誰がその信頼関係とレビューの実施に対して責任を負うのか？
- なぜそれに依拠しているのか、そしてその目的、スコープ、および境界は依然として適切か？
- 信頼関係、その前提条件、または根拠となる証拠に変更があった場合、それを把握できるか？
- 入手可能な証拠は依然としてその信頼関係を正当化しているか。そして維持、変更、撤回のいずれを行うべきか？
ディスカバリーの目的はワークフロー内の重要な信頼関係を可視化することであり、ガバナンスはビジネス上の重要性やリスクに応じて対処の優先順位を決定します。この原則は脆弱性管理に似ています。すなわち、可視化は広範に行う一方で、重点的な対処は最も重要な部分に絞って実施します。
これらのステップを組み合わせることで、トラストマッピングが単なる可視化から証拠に基づく意思決定へとどのように移行するかを示します。
5つのトラストドメインを通じたガバナンス
ディスカバリーで使用されたものと同じ 5 つのドメインが、ガバナンスでも使用されます。これにより、信頼関係がその参加者、情報、接続、アクション、および成果にわたって、現在も意図通りに機能しているかが検証されます。
これらのドメインは、信頼関係を評価するための多様な視点を提供します。利用可能な証拠と組み合わされることで、ガバナンスの決定に役立つ情報をもたらします。ドメインは特定のテクノロジーに依存しないため、Salesforce ユーザー、AI エージェント、各種連携機能、およびその他のテクノロジーが混在するワークフローに対しても同様のアプローチを適用できます。
Agentforce ワークフロー例のガバナンス
前回の記事において、ディスカバリーによってカスタマーサポートワークフローの例の中にいくつかの信頼関係が明らかになりました。
そのうちの 1 つは次のようなものでした。
- 信頼関係: サポート担当者が顧客に依拠する
- 責任: サポートに必要な情報を提供する
- 支えとなる前提条件: 送信されたコンテンツは、サポートワークフローおよび Agentforce が処理する上で安全である
ガバナンスにおいてこの信頼関係を評価する際、議論は次のように進められます。
新たな証拠
顧客アカウントが侵害され、通常のサポートワークフローを通じて悪意のあるコンテンツの送信が開始されました。ワークフローは想定通りそのコンテンツの処理を継続しており、「送信されたコンテンツはワークフローおよび Agentforce が処理する上で安全である」という前提条件を脅かしています。影響を受けたケースの情報が後にナレッジコンテンツの更新に使用された場合、その影響は将来のサポートワークフローにも拡張する可能性があります。
ガバナンス評価
トラストドメインに基づく問いには以下が含まれます。
- 送信されたコンテンツが安全であるという前提条件は、今も成り立つか？
- 顧客が送信したコンテンツを、引き続き同様の信頼できる入力として扱い続けるべきか？
- 影響を受けたケース情報が、下流のワークフローにおける信頼された入力となる可能性があるか？
- どのような検証、監視、またはコントロールを変更すべきか？
ガバナンス決定
Agentforce の使用は継続するが、以下の方法によって信頼関係を変更する。
- 顧客からの送信コンテンツが Agentforce で処理される前に、悪意のあるコンテンツや操作的な入力がないかスキャンする。
- 予期しない影響がないか、Agentforce の挙動および下流の成果を監視する。
- ケース情報をナレッジコンテンツの作成または更新に使用する前に、その内容を検証する。
回答が送信される前に、人間による確認を保持する。
ガバナンスは Agentforce を単体で評価しているわけではありません。信頼関係、それを支える前提条件、および情報が下流のプロセスへと流れる方法が、組織の意図と今も合致しているかどうかを評価しているのです。
信頼関係のライフサイクルにおけるトラストマッピング
信頼関係は、ワークフロー、テクノロジー、参加者、およびビジネス目標の進化に伴って変化します。時間の経過とともに、新たな証拠によって、それらを支える前提条件への信頼度が強まることもあれば弱まることもあります。
AI システムが新たな機能を獲得したり新しいコンテキストで稼働したりする際、権限、アイデンティティ、あるいは基盤となるテクノロジーが変更されていない場合であっても、新たな証拠によってこれまで信頼関係を支えていた前提条件が揺らぐことがあります。同時に、連携機能が進化し、ワークフローが拡大し、パートナーが新しいシステムへのアクセス権を取得し、情報が新しい経路を通って流れ始めます。
これらの発展は必ずしもセキュリティインシデントを示すものではありませんが、信頼関係が本来の目的、スコープ、境界、および支えとなる前提条件の範囲内で今も運用されているかどうかに影響を与える可能性があります。
したがって、トラストマッピングは一回限りの取り組みではありません。ディスカバリーとガバナンスの双方が定期的に再検証され、またワークフロー内に新たな証拠や変更が生じた際には再評価が行われます。
十分な監視、可視性、および説明可能性は、信頼関係を支える前提条件が今も成り立っているかどうかを判断するために必要な証拠を提供するため、非常に重要です。
その評価は、信頼が最初に特定・確立されたときから、運用、そして最終的な廃止に至るまで、関係の全ライフサイクルを通じて継続します。
目的は、信頼を排除することではありません。なぜなら、企業の運営は信頼に依存しているからです。むしろ、信頼が引き続き組織の意図する成果を支え続けることを確実にするのが目的です。
トラストマッピングの立ち位置
トラストマッピングは、既存のセキュリティ、アーキテクチャ、リスク、およびガバナンスの慣行を置き換えるものではなく、それらを補完することを目的としています。それらの慣行も、同じアイデンティティ、アプリケーション、連携機能、権限、および情報の多くを検証する場合がありますが、開始点や視点が異なることがよくあります。トラストマッピングは、ビジネスが何に依拠しているか、なぜその依拠が存在するのか、そしてどのような前提条件がそれを支えているかという、ワークフローレベルの視点を追加します。
これらのアプローチは相互に情報を補い合うことができます。既存の慣行によってコントロール、証拠、および専門的な視点が提供され、トラストマッピングはそれらの発見事項を支援対象のビジネスワークフローへと結び付けるのに役立ちます。
テクノロジーのインベントリは、アプリケーション、エージェント、または連携機能が存在することを示してくれますが、それがさまざまなワークフロー内でどのように依拠されているかまでは必ずしも示してくれません。同じテクノロジーであっても、コンテキストに応じて異なる目的をサポートし、異なる境界内で動作し、異なる前提条件に依存する場合があります。
たとえば、ある連携機能が安全に設定され、適切に監視され、意図された権限の範囲内に制限されているとします。しかし、ワークフローがもはやそれを必要としていないか、あるいはその依拠を支える前提条件が成立しなくなっている可能性があります。逆に、あるアクセスや挙動がその信頼関係の存在する目的から逸脱していることをワークフローが示している場合、セキュリティ上の発見事項はより大きな意味を持つようになります。
まとめ
フレームワーク、ディスカバリー、およびガバナンスが一体となることで、信頼を可視化する段階から、時間の経過に伴ってそれらの関係が変化しても適切であり続けているかを評価する段階へと移行するための方法論が提供されます。
エンタープライズ AI が進化し続ける中、議論の多くがエージェント型システムの構築、AI モデルの保護、エンドポイントの保護、アイデンティティガバナンスの強化、および新たな攻撃手法への対応に集中することは当然と言えます。これらは引き続き重要ですが、それぞれ異なる問いに対応するものです。
トラストマッピングは、それらを補完する以下のような問いを投げかけます。
「各種ビジネスワークフローが依拠している信頼関係を、組織はどのように特定し、管理していくべきか？」
この問いは、新しい機能やアーキテクチャを設計する際に特に実践的な意味を持ちます。現代の Salesforce アーキテクトにとって、その問いは「これを作成できるか？」というだけでなく、ますます次のような問いへと変化しています。
これは実現できるでしょうか？
また、
これによりどのような新たな信頼関係が生まれるのか、そしてそれらが今後も私たちの信頼に値し続けるかどうかを、どうすれば判断できるのでしょうか？