ここで重要な疑問が生じます。
ビジネスワークフロー全体において「信頼」が機能している場合、それをどのようにして可視化すればよいのでしょうか？
その答えは、トラストマッピングフレームワークから始まります。
信頼のマッピングが重要である理由
Salesforceのビジネスワークフローにおいて、単一のユーザーが単一のアプリケーションとだけやり取りすることは滅多にありません。
典型的なワークフローには、従業員、顧客、AIエージェント、自動化プロセス、統合機能、API、外部プラットフォーム、および複数の情報ソースが含まれており、これらが連携してビジネス目標を達成します。各参加者は、他者が期待通りに動作することを前提とし、信頼されたメカニズムを通じて情報を交換し、アクションを実行して、後続の作業における信頼できるインプットとなる成果を生み出します。
組織が Agentforce、Headless 360、MCP、および相互接続が深まる Salesforce エコシステムを導入するにつれて、これらの関係性は数と複雑さの両面で拡大し続けています。
通常、組織はアーキテクチャ図、アイデンティティプラットフォーム、統合ドキュメント、セキュリティツールなどを通じて自社環境のさまざまな部分を把握しています。これらはいずれも重要な視点を提供しますが、コンポーネント間の相互依存関係をワークフローのレベルで明確に可視化できるとは限りません。
トラストマッピングフレームワークは、まさにそのギャップから出発します。その目的はテクノロジーを分類・目録化することではなく、信頼を可視化することにあります。
トラストマッピングフレームワークとは
すべての信頼マッピングの取り組みは、ビジネスワークフローから始まります。OAuth、API、Agentforce、MCP といった個別のテクノロジーから始めるのではなく、よりシンプルな疑問からスタートします。
作業はどのように実行されているか？
ワークフローが特定されたら、相互に補完し合う5つの信頼ドメイン（Trust Domains）を通じてそれを検証します。これらが一体となることで、ワークフローに対する多様な視点が提供され、意味のある依存関係がどこに存在しているかを明らかにすることができます。
5つの信頼ドメインは以下の通りです。
- エンティティ – 誰が、あるいは何がワークフローに参加しているか？
- 情報 – どのような情報が信頼・依存されているか？
- 接続 – 信頼はどのように確立または拡張されているか？
- アクション – 信頼はどのように行使されているか？
- システム成果 – ワークフローはどのような結果を生み出すか？
1. エンティティ
誰が、あるいは何がワークフローに参加しているか？
エンティティドメインでは、ワークフローに関与する人間および非人間の参加者を検証します。これらは情報の提供や消費、意思決定、アクションの実行、相互作用の有効化などを行い、ワークフローの動作に影響を与えます。
具体的には以下のようなものが含まれます。
- Salesforceユーザー
- AIエージェント
- 自動化プロセス
- サービスアカウント
- 接続アプリケーション
- サードパーティサービス
- ベンダー
- 顧客
現代のワークフローが人間のユーザーだけに依存することは滅多にありません。エージェント、自動化プロセス、外部サービス、接続されたプラットフォームのすべてが、ワークフローが依存する「参加者」となり得ます。そのため、エンティティドメインでは人間と非人間の参加者の両方を意図的に含めています。
2. 情報
どのような情報が信頼・依存されているか？
すべてのビジネスワークフローは、意思決定を行い、作業を実行し、成果を生み出すために情報に依存しています。
顧客レコード、商談、サポートケース、ナレッジ記事、プロンプト、AIが生成した要約、メタデータ、レポートなど、これらすべてがワークフロー全体における意思決定に影響を与えます。
重要な疑問は、単に「どのようなデータが存在するか」ではなく、「人やシステムが実際にどのような情報に依存しているか」です。顧客レコードがエージェントの推奨事項を形成し、ナレッジ記事がサポートの回答に影響を与え、AIが生成した要約がその後の意思決定のインプットになる場合があります。
そのため、正確性と同様に「文脈（コンテキスト）」も重要となります。情報は技術的には正確であっても特定の用途には不適切である場合があり、一方で顧客が送信したコンテンツやAIが生成したコンテンツは、ワークフローの別の部分がそれを「信頼できるもの」として扱うだけで大きな影響力を持つようになります。
3. 接続
信頼はどのように確立または拡張されているか？
信頼は、それが最初に確立された関係の範囲を超えて拡張されることがあります。接続とは、そうした信頼関係が確立または拡張されるための技術的または組織的な経路を表します。
例として以下が挙げられます。
- OAuth
- APIs
- MCP
- Agentforce
- 指定ログイン情報
- パートナー関係
- 委任管理者
- Webhooks
パートナー関係や委任管理が単なる組織的な取り決めにとどまらないのと同様に、OAuth認証も単なる技術的な統合にとどまりません。それぞれが、参加者と彼らが依存するリソースとの間で情報、権限、および信頼を拡張するための経路となります。
4. アクション
信頼はどのように行使されているか？
アクションとは、ワークフロー内で実行される振る舞い・操作です。人、システム、エージェント、自動化プロセスが情報を取得し、意思決定を行い、レコードを更新し、プロセスをトリガーし、その他作業を実行する際、信頼がどのように行使されるかを示します。
例として以下が挙げられます。
- 顧客リクエストの承認
- 顧客情報の取得
- AI推奨事項の生成
- 他プラットフォームとのレコード同期
- 自動ワークフローの起動（トリガー）
これらの振る舞いを特定することで、信頼がビジネス運用に直接影響を与える箇所が明確になります。各アクションは1つ以上の信頼関係を行使するものであり、それを支える前提条件が現在も有効であるかどうかを明らかにします。
5. システム成果
ワークフローはどのような結果を生み出すか？
ビジネスワークフローは、サポートケースの解決、契約の承認、顧客への通知といった「直接的な成果」だけでなく、さらなる作業の信頼できるインプットとなる「アウトプット」も生み出します。AIが生成した推奨事項が意思決定に影響を与え、更新されたCRMレコードが別の自動化プロセスを起動し、生成された要約が顧客への回答の基礎となる場合があります。
「成果」を「アクション」と区別して考えることが重要です。なぜなら、プロセスの正常な実行が、意図したビジネス結果を保証するとは限らないからです。ワークフローが設計通り正確に動作したとしても、誤った情報、誤解を招く結果、あるいは有害な成果を生み出してしまう可能性があります。
5つのドメインを通じた信頼の理解
5つのドメインの価値は、単に5つのカテゴリを埋めることにはありません。異なる視点を活用することで、これまで暗黙的であった依存関係を表面化させることにあります。それらの関係性が可視化されれば、「テクノロジー、アクセス権、権限のインベントリ」を超えた議論が可能になります。つまり、ワークフローが実際に何に依存しているのか、なぜその依存関係が存在するのか、それを支える前提条件は何か、そしてその前提条件が変わった場合に何が起こるのかを問うことができるようになります。
単なるセキュリティコントロールにとどまらないフレームワーク
信頼マッピングは、既存のセキュリティ、ガバナンス、アーキテクチャのプラクティスに代わるものではありません。関与する人々、システム、情報、サービスを結び付ける依存関係と前提条件を「ワークフローレベルの視点」として追加することで、既存の取り組みを補完します。
このフレームワークは、特定のテクノロジーに依存しない設計になっています。ワークフローに Salesforce、Agentforce、API、MCP、サードパーティアプリケーション、あるいは将来のテクノロジーが含まれているかどうかにかかわらず、特定の製品やプロトコルではなく「信頼関係」に焦点を当てているため、同じドメインを適用することができます。
今後の展望
フレームワークを理解することは、始まりに過ぎません。
次のステップは、このフレームワークを実際のワークフローに適用することです。次回の記事では「トラストマッピングディスカバリー」を取り上げ、5つのドメインを使用して信頼関係を特定し、それを支える前提条件を表面化する方法について解説します。