ほんだ｜Agentic CRM・Agentforce設計支援

Agentforceの検証メディア「クロスコム Agentic CRM Lab」を開設しました。 このメディアでは、Agentforce導入による業務変化と投資対効果に焦点を当てていますが、 「AI時代のCRM」を検証とデータから考えるメディアとして、CRMを活用されている企業さまにとって有益なメディアを目指してコンテンツを発信していきます。 🚩なぜこのテーマにしたか ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ CRMにAIエージェントを導入しても、 ・業務フローに合わない ・データが揃っていなくて精度が出ない ・出力の確認に想定以上の手間がかかる といった理由で、PoCから先に進まない企業が少なくないからです。 特に人員や時間が限られている企業にとって、AIエージェントがリソース不足を解決できる手段である一方で、最初のPoC段階で時間を割けないまま検証が止まってしまうケースを見てきました。 なので、自社でAgentforceを動かして検証してきたユースケースをコンテンツとして発信することで、みなさんの業務でそのままご活用いただけるのではないかと考えました。 当社は「100社100通りの購買体験を当たり前にする」のビジョンを掲げていますが、限られた人員でもお客様1人1人の異なる課題に向き合い、最適な解決方法を提案するために、AIエージェントの活用定着は欠かせないと考えています。 なかでも特に重要なのが「CRMデータ」です。 そこで、業務でAgentforceを使って検証を進めてきた当社だからこそ、CRMの側面から企業の業務課題を解決するために、このメディアを立ち上げました。 🚩主なコンテンツ内容 ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ ①導入効果の一次検証 ・・・実際に動かして業務がどれだけ変化したか ②業務別の導入ユースケース ・・・営業やマーケの担当・責任者それぞれの業務で何がどう変わるか ③導入事例や調査データの読み解き ・・・業務変化と投資対効果の観点で効果は出ているのか ーーーーーーーーーーーーーーーーー Agentforceの導入を検討している企業もすでに導入している企業も、ユースケースの参考情報としてご活用いただけると嬉しいです。

AIエージェントのテストについて調べていて「何を決定的に判定し、何を確率的に評価するか」と分けて考える基準は重要だなと感じています。 通常のシステムテストでは、入力に対して期待する出力が返るかを確認しますが、LLMを使うエージェントでは、同じ意図の質問でも表現が変わることがあります。 そのため、期待する文章と完全一致するかだけで品質を判断するのは適切ではありません。 以下３つ重要なことを整理しました。 🔵テストの判定を二層に分ける Agentforceのテストでは、例えば次のように評価対象を分けられます。 【決定的に判定するもの】 ・期待したサブエージェントが選択されたか ・期待したアクションが実行されたか ・数値が正しいか ・特定の文字列が含まれているか ・禁止した処理が実行されていないか 【意味的に評価するもの】 ・回答が質問の意図を満たしているか ・必要な情報が含まれているか ・指示に従っているか ・回答が簡潔で一貫しているか 前者は明確な期待値を設定できて、後者はLLMによる評価などを使い、意味や品質を判定する必要があります。 . . . 🔵合格率100%を目指すべき部分と、許容幅を設ける部分を分ける 例えば、権限チェックやアクションの選択など、業務上必ず守るべき処理は100%の合格を要求する。 一方、自然言語による応答品質は、複数回実行した結果や合格率を見て判断する。 調査では、各ケースを3回実行し、2回以上合格したら合格とする方法も提案されていますが、これは公式の合格基準ではなく、クレジット消費も増えるため、重要度に応じた使い分けが必要です。 . . 🔵テストが通ったことと、安全であることは違う さらに重要なのは、テスト仕様そのものの品質です。 例えば、期待するサブエージェントだけを確認しているテストでは、回答内容が誤っていても合格する可能性があります。 また、LLMによる評価を使うなら、意図的に間違った回答やガードレール違反を混ぜ、評価器が正しく判定できるかも検証する必要があります。 AIエージェントの品質管理では、テストを実行するだけでなく、テストが何を保証していて、何を保証していないのかを理解することが大切です。 「テストに合格したから安全」ではなく、「どのリスクを、どのテストで、どこまで確認できたのか」を説明できる状態にしたいですね。

やっぱり、業務変革のためには業務理解だ。 論理・構造・具体抽象の普遍的であり認知負荷のかかる作業を逃げずにやることだ。

AIエージェントの本番運用について調べていて、改めて重要だと感じたのが「リリース後の監視」です。 AIエージェントは、公開して動作確認ができたら終わりではありません。 むしろ、本番環境で利用され始めてから、想定していなかった発話やデータ、業務パターンに直面します。 🔵本番の挙動を観測できなければ、改善できない 🔵監視すべきなのは、エラー率だけではない 🔵本番の失敗を、次のテストに変える Agentforceには、Agent AnalyticsやAgent Health Monitoringなど、エージェントの利用状況や状態を把握するための仕組みがあります。 また、Session Tracingでは、入力、応答、推論ステップ、LLM呼び出し、ガードレールチェックなどを追跡できます。 こうした情報を活用すれば、単に「回答が悪かった」という結果だけでなく、どの処理で問題が発生したのかを調べやすくなりますが、一方で重要な注意点があります。 それは、「調査した仕様では分析できるのは監視を有効化した"後"の会話」ということです。 本番公開後に有効化するのではなく、公開前に監視の設定を確認しておく必要があります。 例えば、次のような指標が考えられます。 ・エラー率 ・応答までの遅延 ・人間へのエスカレーション率 ・会話の放棄率 ・サブエージェント別の成功率 ・アクションの実行失敗率 特に重要なのは、サブエージェント別の成功率です。 エージェント全体では問題なく動いているように見えても、特定のユースケースだけ分類精度が低下している可能性があります。 . . . 私が特に重要だと思うのは、本番で発生した失敗を回帰テストに追加することです。 設計時に想定したケースだけでは、現実の利用パターンをすべて網羅できません。なので、 ・本番で発生した誤分類や不適切な回答を記録し、再現できるテストケースに変える。 ・そして、次の変更時に同じ問題が再発していないか確認する。 このサイクルを回すことで、エージェントの品質を継続的に改善できます。 AIエージェントは、作って終わりの成果物ではなく、利用実績を通じて品質を高めていく運用対象だと考えています。

ソフトウェア開発では、Gitでソースコードの変更履歴を管理することが一般的です。 では、AIエージェントの開発でも、コードやメタデータをGitで管理していれば十分でしょうか。 私は、それだけでは足りないと思います。 . . 🔵AIエージェントは、何を変えたかだけでは挙動を説明できない 🔵Docs as Codeという考え方 🔵実装とドキュメントを別々に管理しない . . . 例えば、あるエージェントの分類説明を変更したとします。 Gitの差分を見れば、変更前と変更後の文章は分かりますが、なぜ変更したのかは分かりません。 ・誤分類が発生したからなのか ・新しいユースケースを追加したからなのか ・他のサブエージェントとの競合を解消するためなのか ・業務範囲そのものを変更したからなのか こうした背景が分からなければ、後任者は適切に変更を判断できません。 そこで重要になるのが「Docs as Code」です。 この「Docs as Code」は、設計や運用に関する文書もMarkdownやYAMLなどで記述し、ソースコードと同じGitリポジトリで管理します。 例えば、 ・ADR：なぜその設計にしたのか ・テスト仕様：何を保証するのか ・エージェントカード：何をするエージェントなのか ・依存関係マップ：どこに影響するのか ・リスク登録簿：どのリスクを認識しているのか ・リリースノート：何を変更し、何を検証したのか これらをメタデータの変更と一緒にレビューします。 しかし、ドキュメントを別の場所に保存していると、実装だけが変更され、文書が古くなることがあります。 一方、同じPRで実装と文書を確認する運用にすれば、変更内容と設計意図の整合性を保ちやすくなりますし、依存関係マップや台帳の一部をメタデータから自動生成すれば、更新漏れも減らせます。 . . . . 私は、AIエージェントの開発において、Gitは単なるソースコードの保管場所ではなく、組織の設計判断を蓄積する場所にもなると思います。 AIを継続的に改善するためには、AI自身の挙動だけでなく、人間が行った設計判断も再現可能な状態にしておく必要があります。

AIエージェントのガバナンスについて調べていて、改めて考えたことがあります。 ガバナンスというと、監査部門や情報システム部門が導入後に確認するルールのように捉えられがちですが、本来はエージェントを設計する段階から組み込むべきものではないでしょうか。 例えば、AIエージェントを業務に導入するとき、次のような問いに答えられる必要があります。 ・何のために存在するエージェントなのか ・どの業務を担当し、何を担当しないのか ・誰の権限で動作するのか ・どのデータを参照できるのか ・どの処理を自律的に実行できるのか ・どのような条件で人間に引き継ぐのか ・どのようなテストを実施したのか ・問題が発生した場合、どう停止・復旧するのか これらは、導入後にルールを追加すればよいという話ではなく、エージェントの目的や責務、権限、処理方式を決める時点で設計しておくべき内容です。 また、とある調査では、NIST AI RMF、ISO/IEC 42001、AI事業者ガイドラインなども確認しました。 それぞれ位置づけや適用範囲は異なりますが、共通して重要になるのは、AIシステムの目的、リスク、テスト、変更、監視、インシデントなどを適切に記録・管理することです。 これをAgentforceの運用に置き換えるなら、 ・エージェント台帳 ・ADR ・テスト仕様と実行結果 ・リスク登録簿 ・権限台帳 ・変更記録 ・リリースノート ・インシデント記録 といった成果物になると考えられます。 私は、こうしたガバナンスを開発のブレーキにしてはいけないと思っていません。 変更の理由を残す。 変更の影響範囲を確認する。 必要なテストを実施する。 承認が必要な処理には人間を介在させる。 こうした仕組みがあれば、むしろ安心してエージェントを増やして改善できるようになります。 AIエージェントのガバナンスとは、利用を制限するための仕組みというより、組織がAIを継続的に活用するための基盤なのだと考えています。

データ設計には、目的によって異なるアプローチがあることを学びました。 特に、 ・業務システム向けの正規化 ・分析システム向けの次元モデリング の違いは勉強になりました。 . . 🚩業務システム（OLTP） ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ 日々の注文、契約、顧客情報などを正確に登録・更新することが重要です。 そのため、データの重複や不整合を抑える正規化が重視されます。 . . 🚩 分析システム（DWH・BI） ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ 売上や受注件数などを、顧客、商品、地域、時間といった切り口で集計・分析することが重要です。 そのため、ファクトテーブルとディメンションテーブルを組み合わせる次元モデリングが活用されます。 代表的な構造は「スタースキーマ」で、中心に売上金額や数量などの数値を持つファクトテーブルを置き、その周囲に顧客、商品、店舗、日付などのディメンションテーブルを配置します。 このとき、分析システムでは、あえてデータの重複を許容する非正規化が行われます。 . . . このように、 業務システムでは整合性を重視し 分析システムでは分析のしやすさや処理効率を重視する。 つまり、データ設計に絶対的な正解があるわけではなく、何のためにデータを使うのかを明確にすることが重要なのです。 CRMにデータを登録する設計と、そのデータをBIで分析する設計を同じ考え方だけで進めてはいけない理由も、ここにあるのだと思います。

アジャイル開発だから詳細なデータ設計は後から考えればよい という考え方は危険だと思います。 確かに、最初から完璧な設計を行おうとすると、開発スピードが落ちる可能性がありますが、 データ構造は一度大量のデータが蓄積されると、変更に大きなコストがかかります。 テーブル構造を変更する場合、既存データの移行や整合性の確認、関連システムへの影響調査などが必要になるからです。 そこで重要になるのが「ジャスト・イン・タイム・モデリング」という考え方です。 書籍では、データモデルを次の2層に分けて考えています。 . . 🚩 コアモデル（安定層） 業務の根幹となる、基本的な情報や概念のつながりを定義します。 🚩 拡張モデル（流動層） 業界固有の要件や新しい機能など、変化に合わせて段階的に追加します。 . . つまり、 ・変化しにくい部分は先に設計し、 ・変化しやすい部分は開発サイクルに合わせて拡張していく という考え方です。 最初からすべてを決める、または何も決めずに開発することではなく、 どこを安定させどこに変更の余地を残すのかを判断することが重要になります。 AIエージェントのように進化の速い領域でも、業務の根幹となる顧客、契約、商品、取引などのデータ構造まで場当たり的に変更してよいわけではありません。 スピードと品質を両立するには、変化を前提としたデータ設計が必要なのだと思います。

データモデリングには「概念・論理・物理」という3つの階層があります。 最初はただの「設計工程の違い」だと思っていましたが、それぞれが異なる問いに答えるものだと理解すると重要性がよく分かります。 🚩 概念データモデル：何を管理するのか？ 顧客、注文、商品、発送など、ビジネス上の主要な情報と関係性を整理します。 🚩 論理データモデル：どのようなルールで管理するのか？ 必要な項目、データ同士の関係、必須条件、制約などを具体化します。 🚩 物理データモデル：どのシステムに、どのように実装するのか？ データ型、主キー、外部キー、索引など、特定のデータベースを前提に実装レベルまで落とし込みます。 この3階層を分ける意味は、ビジネス上の要求と技術的な実装を切り離して考えられることです。 例えば、ビジネス部門が「顧客ごとに複数の契約を管理したい」と考えているとします。 この段階では、どのデータベースを使うか、どの項目を何文字にするかは決める必要がありません。 まずは、顧客と契約の関係を合意することが先です。 その後、契約に必要な情報や管理ルールを決め、最後に実装方法を決定します。 この順序を守らず、最初から画面やテーブルを作り始めると、システムの都合がビジネスの構造を決めてしまう可能性があるので、 「設計の抽象度を段階的に下げる」プロセスは、ビジネスとITの認識を揃えるためにも重要なのではないでしょうか。

最近、データアーキテクチャについて学び直しています。 そこで改めて重要だと感じたのが、 データ設計は単にデータベースの構造を決める作業ではない ということです。 データアーキテクチャの役割は大きく3つあります。 . . ①データの配置 どのデータを、どのシステムで管理するのか。 ②データの流れ データはどこで生まれ、どこで加工され、どこへ渡されるのか。 ③データの標準 全社で共通して守るべき構造やルールは何か。 例えば、ECサイトで注文が入った場合、注文情報は受注管理システムへ、発送情報は物流システムへ、売上情報は財務システムへと流れていきます。 このとき、個々のシステムが正常に動いているだけでは十分ではなく、「注文」という情報が、システムを横断しても同じ意味で扱われていることが重要です。 個々の建物を立派に建てても、道路や上下水道、電気などのインフラが適切につながっていなければ、都市全体として機能しません。 企業のシステムも同じで、個別のシステム導入を繰り返すだけでは、全体としての整合性は保証されません。 データがどこに存在し、どのようにつながり、どのようなルールで管理されているのか。 この全体像を設計することがデータアーキテクチャの役割なのだと理解しました。 AIエージェントが複数のシステムを横断して業務を実行する時代には、データアーキテクチャがますます重要になるのではないでしょうか。

企業のデータ活用を考えるうえで、エンタープライズ・データモデル（EDM）は非常に重要な概念だと思いました。 企業には次のような情報が存在します。 ・顧客：個人顧客、法人顧客、取引先 ・製品：商品、サービス、部品、価格表 ・販売：受注、契約、見積、請求 ・組織：部署、従業員、拠点 これらの情報を個別に管理するだけでなく、企業全体でどのような関係にあるのかを整理する。これがなぜ、重要なのか？ 例えば、営業部門では「顧客」を取引先として捉え、マーケティング部門ではリードやコンタクトとして捉え、サポート部門では問い合わせを行った契約者として捉えているかもしれません。 それぞれの部門では合理的な管理方法でも、企業全体で見ると「顧客」という言葉の意味が揃っていない可能性があります。 こうした状態では、データを横断的に活用しようとしても、同じ意味の情報を特定するところから始めなければなりません。 EDMは、企業にとって何が顧客で、何が製品で、何が契約なのかを定義し、それらの関係性を共有するためのものです。 私は、データ活用が進まない原因の一つに、データが不足していること以上に「組織内でデータの意味が統一されていない」問題があると考えています。 データを統合する前にまず「意味を統合する」。 EDMは、データ構造の設計図ではなく、組織が共通の言葉でビジネスを理解するための基盤なのではないでしょうか。

エンタープライズアーキテクチャを考えるとき、システム構成図やデータ連携図を作ることにまず意識が向いてしまうが、 私はAIエージェントを活用するうえでは、システムだけでなく「業務上の判断」を整理することが先だと考えています。 例えば、営業活動における見込み顧客の優先順位付けのユースケースでも、 システム上では、顧客情報や商談履歴、活動履歴を管理できるが、 それだけでは、営業担当者がなぜ特定の企業を優先したのかまでは分かりません。 ・どの情報を重視したのか ・どのような課題仮説を立てたのか ・何を受注可能性の判断材料にしたのか ・なぜ別の企業を後回しにしたのか こうした判断の構造が明確になって初めて、AIに判断を支援させる仕組みができます。 私が考えているRevenue Reasoning（売上を生み出す営業判断の仕組み化）という概念も、この問題意識につながっています。 データを管理するだけでなく、データを使ってどのような判断を行うのかまで設計する。 AI時代のEAでは、業務プロセスやシステム構成に加えて、企業固有の意思決定の仕組みも重要な設計対象になるのではないでしょうか。

AIエージェントの導入が進むほど企業には「EA（エンタープライズアーキテクチャ）」の考え方が必要になると考えています。 従来のシステムは、基本的に人間が画面を操作し、必要な情報を確認しながら業務を進めていましたが、 AIエージェントは複数のシステムやデータを横断し、情報を取得して判断し、場合によっては業務を実行する。これが一般化しています。 つまり、AIエージェントに業務を任せるということは、業務の進め方そのものを再設計することにつながります。 例えば、営業エージェントに見込み顧客の優先順位付けを任せる場合、 CRMの顧客情報だけでなく、過去の商談履歴、問い合わせ内容、企業情報などを参照するかもしれません。 そこで必要になるのは ・どのデータを参照してよいのか ・どの情報を信頼するのか ・どの基準で優先順位を付けるのか ・どこまでAIが判断してよいのか ・どの操作には人間の承認が必要なのか といった設計部分です。 これらはAIのプロンプトだけで解決できる問題ではありません。 データ、業務、システム、権限、ガバナンスを横断して考える必要があります。 AIエージェントの導入が進むほど、個々のツールの機能よりも、それらを企業全体の中でどう位置付けるかが重要になるのではないでしょうか。

中堅企業がEAに取り組む場合、最初から全社の業務・データ・システムを網羅的に整理する必要はないと思います。 むしろ、最初から全体を把握しようとすると、調査やドキュメント整備に時間がかかり、実際の業務改善にたどり着けない可能性があります。 私なら、まず1つの業務プロセスから始めます。 例えば「営業活動」」です。 顧客情報の収集から、アプローチ先の選定、商談準備、提案、受注後の引き継ぎまでを整理します。 その過程で、次のような問いを明らかにします。 ・どの業務を誰が担当しているのか ・どのシステムに情報が存在するのか ・どのデータを正として扱うのか ・どの場面で人間が判断しているのか ・例外が発生した場合、誰が対応するのか ここで得られた知見を、別の業務プロセスにも活用していきますが、最初の業務プロセスをシステム導入案件として終わらせないことが重要です。 そこで発見したデータの管理責任、判断基準、例外処理、権限などを記録し、次の業務設計に再利用できる状態にすることです。 全社最適は、最初に完成させるものではなく、個別の業務を設計・改善する過程で段階的に実現していくものではないでしょうか。

中堅企業のシステム環境を考えると、最初から全体最適を目指して構築されたものばかりではないと思います。 事業の成長に合わせてCRMを導入し、マーケティングツールを追加し、会計システムや問い合わせ管理ツールを連携する。 それぞれの導入時点では合理的な判断だったとしても、時間が経つにつれてデータの重複や業務の分断が発生することがあります。 さらに厄介なのは、各システムが個別には正常に動いていることです。 例えば、 ・顧客情報はCRM ・問い合わせ情報は別のツール ・営業活動はスプレッドシート ・提案資料は個人のフォルダ ・売上実績は会計システム という状態でも、担当者が手作業で補完すれば業務は回ります。 しかし、AIエージェントに業務を任せようとすると、 ・どの情報を正とするのか ・データ同士をどう関連付けるのか ・どの情報を判断に使うのか が問題になります。 つまり、人間が暗黙的に補完していたシステム間で生まれていた情報やデータの齟齬が、AI活用によって顕在化するのです。 EAの考え方は、こうした部分最適を否定するものではありません。 個別のシステム導入を続けながらも、全体としてどのような構造になっているのかを把握し、将来の変更に耐えられる状態をつくることが重要だと考えています。

AIエージェント時代の企業アーキテクチャについて調べていると、クロスコムが何を提供すべきかについても考えさせられます。 たとえば、AIを使った顧客調査、商談準備、提案書作成、営業活動の支援など、 これらは、営業担当者の負担を減らすうえで有効なユースケースになり得るんですが、 機能を提供するだけなら、今後は多くの製品やサービスが同様のことを実現する可能性があると思っています。 だから、営業業務の中で行われる判断そのものを、どこまで設計できるかまで考えていきたい。 例えば、商談準備を支援するなら、顧客情報を集めて要約するだけではなく、 ・どの情報を重要とみなすか ・どの過去案件を参考にするか ・どの条件から課題仮説を立てるか ・どの段階で人間に判断を求めるか ・判断結果をどう記録し、次の案件に活かすか まで設計対象にできる。 この仕組みが整えば、AIは単に情報を提示するだけでなく、自社の営業方針に沿って仕事を進めるための支援を担えるようになる可能性がある。 私は、この領域をレベニュー推論として体系化したいと考えている。 CRMが顧客や商談の事実を記録する基盤だとすれば、レベニュー推論は、「売上に関わる判断の基準、権限、根拠、結果を設計し、再利用するための方法論」という位置づけです。 ただし、これが既存のEAやオントロジー、コンテキストグラフと完全に独立した新しいレイヤーだと断定するつもりはなくて、むしろ、それらの考え方を営業領域に適用し、具体的な成果物と運用方法に落とし込むことに価値があると考えています。 クロスコムが目指すのは、AIエージェントを導入する支援だけではなくて、営業の判断を設計し、その判断をAIが利用できる形に整え、実際の業務成果につなげる支援です。

エンタープライズアーキテクチャという言葉から、大企業の全社システムを統括する大規模な活動をイメージしやすいが、 AIエージェントの導入を考えるなら、中堅企業にも応用できる考え方があると思う。 . . 例えば、50〜300名規模の企業でSalesforceを利用しているとする。 マーケティング、営業、カスタマーサクセスが顧客情報を扱い、案件の進捗や対応履歴を共有している。 この環境にAIエージェントを追加する場合、モデルの選定や機能設定だけでは済まない。 ・どの部門の情報を参照させるのか。 ・顧客情報のどこを正とするのか。 ・営業とカスタマーサクセスで判断基準が異なる場合、どう扱うのか。 ・AIに許可する操作は何か。 ・例外が発生したとき、誰が責任を持つのか。 こうした問題は、企業規模にかかわらず発生し得るし、もちろん、中堅企業に大企業と同じ規模のEA組織や文書体系を導入する必要はない。 ただ、「目的に応じた最小限の構造化」は必要だと思う。 例えば、業務プロセス、重要なデータ、判断基準、権限、例外処理を整理し、AIを導入する業務から順番に整備する方法が考えられる。 大規模な全社変革を最初から目指すより、特定の営業プロセスで実証し、得られた知見を他の業務へ展開するほうが現実的な場合もある。 「EAを大企業だけの専門活動と捉えず、AIを安全に業務へ組み込むための設計原則として活用する。」 中堅企業には、その規模に合ったEAの実践方法が必要なのではないか。

SalesforceのAI関連で Agentforce Data 360 Slack Semantic Layer オーケストレーション など、多くの概念が登場しているんですが それぞれの機能を個別に理解することよりも「全体の役割分担」として捉える必要性を感じています。 . . . まず、「個別機能を理解すること」と「企業アーキテクチャを理解すること」は違います。 例えば、 データを蓄積する仕組み＝そのデータをAIが業務上の意味に沿って理解できる とは限りません。 AIが情報を理解できても、業務のどこで判断し、どの処理を実行するのかが決まっていなければ、成果にはつながらないからです。 さらに、実行できる機能があっても、権限や承認条件が適切に設計されていなければ、企業業務に組み込むことは難しいでしょう。 つまり、データ、意味、推論、オーケストレーション、実行、ガバナンスは、互いに関係するが同じ役割ではないということです。 SalesforceのAgentic Enterprise ITアーキテクチャを理解する際も、層の名前を覚えるだけでは不十分だと思っていて、 それぞれの層がどんな問題を解決し、どの層と情報や制御を受け渡すのか。全体として何を可能にするのかを考えていく必要がある。 そして、Salesforceのアーキテクチャが整っていることと、導入企業の業務設計が整っていることも別問題なので、 機能同士の役割とアーキテクチャの視点を理解することが、AI時代のSalesforceを学ぶうえでも、欠かせないと考えています。