※本記事は、Salesforceが開催したDreamforce 2026のアーキテクト基調講演「Architecture for the Agentic Future」の内容を基に作成されています。講演では、エージェンティック・エンタープライズの時代にAIを活用したシステムをどう設計・拡大・統治するかが語られました。動画の詳細は https://www.youtube.com/watch?v=bCopTUX3Oe0 でご覧いただけます。
登壇者は次の6名です。
- Miriam McCabe氏：Salesforce シニアディレクター（アドミン・アーキテクト エバンジェリズム担当）
- Leo Tran氏：ディスティングイッシュト・アーキテクト
- Shelley氏：リード・テクニカルアーキテクト
- Tim Breeden氏：新Well-Architected Frameworkの策定に携わったソフトウェアエンジニアリング・アーキテクト
- Daniel Vaninsberghe氏：テクニカルアーキテクト、アーキテクト・アンバサダー
- Lilith Van Bon氏：デモ担当
本記事は講演内容を要約したもので、原著作者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性があります。正確な情報については、オリジナルの動画をご覧ください。Agentforceの詳細は https://www.salesforce.com/agentforce/ をご参照ください。
1. 序章：エージェンティック時代のアーキテクトとコミュニティ（Miriam McCabe）
1.1 コミュニティの成長とアンバサダープログラム
Miriam McCabe： SalesforceでアドミンおよびアーキテクトのエバンジェリズムをリードしているMiriam McCabeです。アーキテクト基調講演へようこそ。今日は、エージェンティックな未来に向けたアーキテクチャについて、私たちのビジョンをお伝えします。
本題に入る前に、少しだけ皆さんと一緒に、この瞬間の大きさを噛みしめたいと思います。前回のDreamforceで、私たちはアーキテクト向けのプログラムを再始動させました。それから一年で、こうしてアーキテクトのための基調講演が開かれ、会場がアーキテクトの皆さんで埋まっています。これは本当に特別なことです。
まず、今日足を運んでくださった皆さん、そして再始動したプログラムを受け入れてくださった皆さんに心から感謝します。皆さんはビジョンを示し、積極的に参加し、私たちが課題にきちんと向き合っているかどうかを厳しく問いかけてくれました。そのおかげで、このプログラムは私たちとコミュニティが一緒に作り上げたものになりました。そう実感できることを、とてもうれしく思っています。
このコミュニティには毎日驚かされています。現在、アーキテクトのコミュニティグループは22カ国に63あり、そのすべてが皆さん同士の知識共有によって築かれてきました。そしてこれらはすべて、今回のDreamforceで20周年を迎えたTrailblazerコミュニティの一部でもあります。
新しいプログラムのもとで、最初のアーキテクト・アンバサダー51名が誕生しました。アンバサダーの皆さんの役割は、プログラムの活動やリソースがアーキテクトコミュニティのできるだけ多くの人に届くよう、その影響範囲を広げることです。
ここで強調しておきたいことがあります。このコミュニティに参加するのに、肩書きに「アーキテクト」が入っている必要はありません。作る前に設計をしているなら、それはもうアーキテクチャの仕事です。そういう方はこのコミュニティの一員であり、私たちのリソースはそうした方のためのものでもあります。
では、このコミュニティを実際に見てみましょう。すでにアーキテクト・アンバサダーのTシャツを着ている方を何人か見かけました。アンバサダーの方は立ち上がってください。ありがとうございます。そのまま立っていてください。せっかくなので、少し気まずい空気にしてみましょう。次に、アーキテクトのコミュニティグループに参加したことがある方、あるいは他のアーキテクトから何かを学んだことがある方も立ってください。……思ったより少ないですね。もっと知識共有を進める必要がありそうです。では最後に、ここに共有するため、成長するため、あるいは学ぶために来た方、全員立ってください。
周りを見回してください。これが皆さんのコミュニティ、アーキテクトのコミュニティです。もう座っていただいて大丈夫です。基調講演の間ずっと立たせておくつもりはありませんから。このコミュニティは、今ほど重要になったことはありません。
1.2 アーキテクトの価値と二つの新発表
Miriam McCabe： コミュニティがこれほど重要になっているのは、アーキテクチャそのものが、かつてないほど重要になっているからです。エンタープライズの全体像は急速に広がっています。私たちは確率的に振る舞う主体としてエージェントを組織に迎え入れています。MCPやA2Aを通じて新しい接続をいくつも作り、大規模言語モデルも取り込んでいます。動く部品があまりに多いのです。では、その全体を見渡しているのは誰でしょうか。それはアーキテクトです。
全体を見渡すことこそ、アーキテクトの仕事です。私たちはピースの組み合わせ方を知っていますし、新しい技術への高揚感には、それに見合った常識的な判断が必要だということも知っています。環境を止めずに動かし続けること、データを安全に保つこと、そしてイノベーションの中から自分たちの組織に本当に役立つものを選んで取り入れること。この考え方こそが、アーキテクトがもたらす価値です。
私たちはこの仕事を、Salesforceプラットフォームという道具を使って進めています。今回のDreamforceで何度もご覧になったスライドだと思いますが、ここに並ぶレイヤー、製品、機能のすべてが、エージェンティック・エンタープライズを構成する要素です。そして、それらを誰よりもよく理解しているのは皆さんです。こうした要素を各企業の固有の文脈にどう持ち込むかを決めているのも皆さんです。これは簡単なことではありません。技術の変化はますます速くなり、それに合わせて皆さんにも、より速い意思決定が求められているからです。
負担は確かに大きいです。だからこそ、信頼できるWell-Architected Frameworkに頼れることが非常に重要になります。そして今回のDreamforceで、私たちはこのフレームワークの史上最大の進化を発表します。新しいWell-Architected Frameworkです。
新しいフレームワークは、エージェンティック・エンタープライズのために設計された5本の柱で構成されています。アーキテクトがトレードオフを見極め、自分の設計にエージェンティック・エンタープライズの視点を当てはめられるように作りました。同時に、Salesforceプラットフォームのこれまでの基盤の上に築かれています。
とはいえ、ドキュメントを最初から最後まで読み通すのが好きな人はあまりいないことも分かっています。そこで、このガイダンスにもっと手軽にアクセスできるようにしました。それが本日二つ目の発表、Architect Agentです。Architecture Center上で動くAI搭載のアシスタントで、アーキテクチャに関するあらゆる質問に、アーキテクチャとして筋の通った形で答えます。回答は、Well-Architected Frameworkを含むArchitecture Centerのすべてのコンテンツに基づいています。
こうした進化は一夜にして実現したものではありません。コミュニティと一緒に作り上げてきたものであり、これからもコミュニティのニーズや技術の変化に合わせて進化させ続けます。多くの方が意見やフィードバックで力を貸してくださいましたが、その中に、期待をはるかに超える貢献をしてくれた方がこの会場にいます。テクニカルアーキテクトであり、コミュニティのオーガナイザーでもある方です。ステージにお迎えしましょう。
2. コミュニティと共に設計したフレームワーク（Daniel Vaninsberghe）
2.1 アーキテクトの三つの課題と新フレームワークの構造
Miriam McCabe： Daniel、ステージにようこそ。今日は二人ともゴールドを合わせてきましたね。それに、その靴がとても素敵です。会場から見える方は、Danielの靴にも拍手をお願いします。さて、Well-Architected Frameworkでのあなたの仕事について、いくつか伺いたいと思います。まず、今のアーキテクトが抱えている主な課題は何で、それがフレームワークにどう関わってくるとお考えですか。
Daniel Vaninsberghe： このエージェンティックな時代に、私たちアーキテクトが直面している課題は大きく三つあると思います。一つ目は、知っておかなければならないことがあまりにも多いことです。製品のこと、価格モデルのこと、挙げればきりがありません。二つ目は、以前よりもずっと短い時間で答えを出すよう求められていることです。とにかく速さが必要になっています。
三つ目は、エージェントという新しい主体、新しいステークホルダーが私たちのワークフローに入り込んできたことです。かつては、要件を文書にまとめたものが足りないことが問題でした。ところが今は、書かれたものが溢れています。書き手はエージェントのこともあれば人間のこともあります。読み手もエージェントのレビュアーだったり人間のレビュアーだったりします。しかも、その内容はエージェント型システムについてのものです。従来のWell-Architected Frameworkは、こうした側面についてはほとんど何も書かれていない状態でした。ですから、何か手を打つ必要があったのだと思います。
Miriam McCabe： どれも、会場の皆さんにとって身に覚えのある課題だと思います。そうした課題は、新しいフレームワークに対するあなたの期待にどう影響しましたか。
Daniel Vaninsberghe： 従来のフレームワークは、実によく設計されていました。「これは適切に設計されているか」と自分に問いかけるところから出発し、三つの観点に沿って深く掘り下げていく構造です。私はその姿勢が新しいフレームワークにも引き継がれることを強く望んでいました。
実際に完成したフレームワークでは、エージェントの次元と人間の次元が並行して走る構造になっています。従来の柱はそのまま残しつつ、この時代に特有の新しい柱で補強されています。結果として、とても優れた、良いものに仕上がったと感じています。このフレームワークは、私たちが人間として、そしてアーキテクトとして「何が良い状態なのか」というビジョンを育てる助けになります。それこそが私たちを導くものであり、私たちが常に求められているガイダンスでもあるのです。
Miriam McCabe： つまり、先ほど私がお話しした「土台」のことですね。Salesforceのベストプラクティスという土台があり、その上にエージェンティックなレイヤーが重なっているということですね。
2.2 日常での活用法とゴールデンフーディー授与
Miriam McCabe： では、会場の皆さんがWell-Architected Frameworkを日々の仕事で使いたいと思ったとき、どのように取り組めばよいでしょうか。何かアドバイスはありますか。
Daniel Vaninsberghe： 私がいつも最初に取り上げるのは、MVP仲間のShivaが提唱している考え方です。それは「何が良いのか」について自分なりのビジョンを育てることです。そして、ときには「良い」とは「十分に良い」という意味でもあります。
実際に問題を解決しようとするときは、一つの具体的な課題や要件を取り上げ、それを題材にして掘り下げていくところから始めるとよいと思います。組織全体をチェックリストに照らし合わせて、適切な設計かどうかの項目を一つずつ埋めていく、ということはできません。何か一つの課題に取り組むたびに一つずつ確認していくことはできても、組織全体に対して一度にそれをやるのは不可能です。そうではなく、目の前の課題について「これは適切に設計されているか」と問いかけ、その課題にフレームワークを当てはめていくのです。そうすれば必ずより良い解決策にたどり着けると、私は確信しています。それこそが、今の私たちに必要な監督の在り方です。
Miriam McCabe： そのとおりですね。つまり、いきなり全部をやろうとせず、一歩ずつ進めればよいということですね。それから、今の話を聞いて「フレームワークにはチェックリストがないのか」と心配された方のために補足しておくと、フレームワークにはちゃんとチェックリストも用意されています。最後の質問です。フレームワークの中で、あなたのお気に入りのリソースは何ですか。
Daniel Vaninsberghe： レビューにボランティアで参加し始めたとき、私が選んだのは一番好きな柱、Trustの柱でした。特に、エージェント型システムのガバナンスについてどんなガイダンスが示されるのかを、とても楽しみにしていました。この領域は、これから何が押し寄せてくるのか誰もはっきりとは分かっていないところです。それなのに、私たちはこうしたシステムに対して責任を負っています。だからこそガバナンスは極めて重要だと感じていますし、今回のDreamforceでこの分野について発表があったことをうれしく思っています。
Miriam McCabe： まさにそうですね。Trustは私たちの第一の価値であるだけでなく、優れたアーキテクチャの土台でもあるということです。ステージ上で、そしてフレームワークへの貢献を通じて、あなたの視点を共有してくれて本当にありがとうございます。
実は、まだ続きがあります。アーキテクト・アンバサダーとして、あなたがコミュニティのためにしてくれているすべてのことにも感謝を伝えたいのです。あなたは素晴らしい方で、皆の手本です。そのDanielに、ゴールデンフーディーを贈呈できることを光栄に思います。
Daniel Vaninsberghe： まったく予想していませんでした。
Miriam McCabe： 予想していなかったのですか。とてもよく似合っていますよ。Daniel、この瞬間を楽しんでください。本当にありがとうございます。席に戻るDanielに、皆さんもう一度大きな拍手をお願いします。
3. 第1章 エンタープライズ・イノベーションの解放（Leo Tran）
3.1 AIforce戦略とHeadless Toolkit
Miriam McCabe： それでは、エージェンティックな未来に向けたアーキテクチャのビジョンに話を戻しましょう。この基調講演は三つの章で構成しています。第1章は「エンタープライズ・イノベーションの解放」で、組織がAIのインターフェースを責任ある形で取り入れる方法を見ていきます。第2章は「エンタープライズ・インパクトの拡大」です。アーキテクトが既存のインフラやシステムをどう生かし、エージェンティックな未来に備えさせるかを取り上げます。最後の第3章は「エンタープライズ・トラストのガバナンス」で、適切なガバナンスのプロセスがどのように次のビジネス機会につながるのかをお見せします。まずは第1章からです。ディスティングイッシュト・アーキテクトとしてソフトウェアエンジニアリングを担当しているLeo Tranをお迎えしましょう。
Leo Tran： ユーザーの働き方は、誰の目にも明らかな形で変わりつつあります。ユーザーはエージェントと一緒に働きたいと考えています。エージェントを使えば、仕事をより速く終えられるからです。そこで生じるアーキテクチャ上の課題が「責任あるアクセス」です。企業のセキュリティと説明責任を損なわずに、ユーザーとエージェントが必要なデータとアクションだけにアクセスできるようにするには、どうすればよいのでしょうか。
その答えとなる今の時代の戦略が、AIforceです。AIforceは、ユーザーやエージェントがどこにいても、あらゆるエージェントがあらゆるインターフェース上でSalesforceと連携できるようにするための戦略です。Miriamが話したとおり、アーキテクトはまさにこの瞬間のために存在しています。この戦略を、あらゆる企業に実際に展開できる形に落とし込むのはアーキテクトです。アイデンティティ、接続性、アクセス制御といった重要な概念をどう実装するかを考え抜くのも、アーキテクトの役割です。アーキテクトの重要性は、これまでになく高まっています。
その実装を後押しするのがHeadless Toolkitです。Headless Toolkitには、すぐに使える機能が揃っています。エージェントをアイデンティティとして登録する機能、MCPによる接続、そしてエージェントにできることをさらに絞り込む追加のアクセス制御です。
ツールキットには、Headless Experience Layerも含まれています。エージェントとやり取りする人間が、テキストだけでなく視覚的に操作できるようにするための層です。さらに、ユーザーとエージェントのどちらがSalesforceを操作しているのかを区別できるよう、可観測性も強化しています。ユーザーがエージェントを使って素早く価値を得られるように、事前構築済みのスキルも用意しました。そしてAnthropicとの最近のパートナーシップにより、Salesforce and ClaudeプラグインでClaudeをSalesforceにつなぐことが、これまでになく簡単になりました。
3.2 私的エージェント利用の三つのリスク
Leo Tran： AIforceを企業にどう展開できるのか、デモ企業のRadiant Homesを例にご覧いただきます。Radiant Homesはスマートホームサービスのプロバイダーで、住宅や商業施設向けに自動化、セキュリティ、ウェルネスのサービスを提供しています。今はちょうど更新シーズンで、住宅向けのプランが次々と期限を迎え、商業向けの契約も再交渉の時期に入っています。営業担当者たちは必死に追いつこうとしていますが、仕事量との差は広がる一方です。
その中で、一部の営業担当者は自分の私的なエージェントを使い始めました。勝手なことをしようとしているわけではありません。生産性を上げるにはエージェントの助けが必要だ、という明確なサインを出しているのです。そこで、ユーザーとエージェントをSalesforceにつなぐアーキテクチャを考えるのが、Radiant Homesのアーキテクトの役目になります。ここからは私自身がRadiant Homesのアーキテクトになりきり、同じくRadiant HomesのアーキテクトであるLilithとRajieと一緒に、課題と解決策をお見せします。
まず、ある営業担当者が頼った私的なエージェントを画面に出します。目ざとい方はお気づきかもしれませんが、これは世界一のバナナブレッドのレシピを追究するのにも、2週間の休暇の計画を立てるのにも使ってきたエージェントです。今回はそれを、顧客へのメールの下書きに使おうとしています。
営業担当者はレポートから連絡先と契約情報をコピーしてエージェントに渡し、メールの下書きを頼みました。結果は、一応うまくいきました。ただ、内容はかなり一般的で、まだ手を入れる必要があります。そして今のやり取りで、私たちは三つの重大な企業リスクを目にしました。一つ目は、機密性の高い顧客情報が、統制されていないツールの中に置かれてしまったことです。二つ目は、手作業のコピー＆ペーストです。壊れやすく脆弱で、ユーザー体験としても劣っています。三つ目は、このエージェントが必要なデータのほんの一部しか持っていないことです。これでは、Radiant Homesの顧客が期待するような、一人ひとりに合わせた価値の高いメールは作れません。これが今回の課題です。
では、Radiant Homesのアーキテクトはこの課題にどう取り組むべきでしょうか。まずは設計図、つまりアーキテクチャを考える必要があります。そこで、architect.salesforce.comで公開された新しいWell-Architected Frameworkを開きます。これだけ状況が変わったのですから、当然新しい版を参照します。信頼が最優先なのでTrustの柱から読み始めると、読了まで27分と表示されています。内容は充実しています。私はアーキテクトとして責任を負う立場ですから、もちろん読みます。ただ、今は試行錯誤を重ねている最中で、もっと速く進めたいのです。
今の私にはエージェントがあります。Architect Agentに「ユーザーとエージェントをSalesforceに安全に接続するにはどうすればよいか」と尋ねてみます。エージェントは新しく充実したコンテンツ全体を処理し、設計図を返してくれました。アクセス制御の考え方、コンプライアンスのためにゼロデータ保持が重要であること、そして権限を伴うアクションに人間による監督をどう組み込むか、といった点を整理する手助けをしてくれます。このエージェントのおかげで、私は速く進められます。これで設計図の出発点ができました。
3.3 アイデンティティ・接続・アクセス制御
Leo Tran： ここから実装の詳細に入ります。最初に考えるのはアイデンティティです。Radiant Homesは、営業担当者が使うエージェントとしてClaudeを標準にすると決めました。では、ClaudeをSalesforceに安全に接続するにはどうすればよいでしょうか。これまでアーキテクトや開発者が外部システムをSalesforceにつなぐときは、External Client Appsを使ってきました。Salesforceはこのフローに大幅な改良を加え、エージェントを登録できるようにしました。これにより、ClaudeがSalesforceとやり取りするとき、それが単なる外部システムではなくエージェントであることをSalesforce側が認識できるようになります。
次は接続性です。エージェントがシステムに対して実際にアクションを起こすための事実上の標準は、MCPです。Salesforceでは、アーキテクトや開発者がカスタムのMCPサーバーを作れるようになっています。ただ、ここでお見せしたいのは少し違うもの、Headless 360 MCPサーバーです。これはSalesforceの多様な機能への唯一の玄関口となるもので、三つの主要なツールによって接続をシンプルにします。
一つ目はDiscoverツールです。エージェントが自分の意図から出発して、必要なスキルやアクションを絞り込めるようにします。二つ目はDescribeツールで、あるスキルについて、リクエストとレスポンスのパラメータをエージェントが理解できるよう手助けします。三つ目がDispatchツールで、エージェントが実際にアクションを実行するためのものです。Headless 360 MCPサーバーは現在オープンベータとして公開しているので、ぜひ試してみてください。Salesforceは今後も機能強化を続け、11月上旬に「Salesforce MCPサーバー」として一般提供を開始する予定です。
接続性が確保できたので、次はアクセス制御です。ユーザーとエージェントがSalesforceとやり取りする典型的なパターンでは、エージェントはそのユーザーが持つ権限とアクセス範囲をすべて引き継ぎます。しかし、それはユーザーにとってもアーキテクトにとっても本当に望ましい形ではありません。少なくとも最初のうちは、エージェントにできることを制限したいはずです。
そこで登場するのがScoped Access Definitionsです。ユーザーに許されている範囲に加えて、エージェントに対してさらに絞り込みのポリシーをかけることができます。これが機能するのは、先ほどClaudeを既知のエージェント・アイデンティティとして登録したからです。エージェント・アイデンティティがあるからこそ、そこに固有のアクセス制御としてScoped Access Definitionsを関連付けられます。しかもその設定は、どのユーザーが使う場合でも一貫して適用されます。
Radiant Homesの場合を見てみましょう。このScoped Access Definitionでは、Claudeにすべての取引先責任者へのアクセスを認めています。エージェントには顧客について把握し、文脈を理解してほしいからです。一方で、取引先責任者の作成、編集、削除の権限は与えていません。意図しない変更を避けるためです。これが「段階的な信頼」の実装方法です。最初はエージェントに必要最小限のアクセスだけを与え、時間をかけてより多くのことを任せられるよう、整備された道筋を用意しておくのです。
3.4 Claudeプラグインのデモ
Leo Tran： これでアイデンティティ、接続性、アクセス制御という土台が整いました。営業担当者の体験がどう変わったかを見てみましょう。こちらがClaudeです。営業担当者の環境には、Salesforce and Claudeプラグインが用意されています。これは成果を出すことに最適化し、パフォーマンスを調整した事前構築済みのプラグインです。営業担当者はこれまでどおり自然言語でエージェントとやり取りすることもできますが、スキルを使えば、より決定的な形で、素早く目的の成果にたどり着けます。
スキルの一つ、「アウトリーチの下書き」を試してみましょう。Meridian PropertyのCasey Henderson宛てのメールを作成してもらいます。今Claudeは、接続されたMCPサーバーを通じて取引先責任者の情報を調べ、取引先の履歴を確認し、一人ひとりに合わせたメールを作成しています。画面に表示されているウィジェットが、Headless Experience Layerです。テキストの塊は人間がすぐに理解するのが難しいので、Headless Experience Layerが視覚的に豊かなレスポンスを返し、何が起きたのかを人間がつかみやすくしています。
できあがったのは、まさに個別化されたメールです。拡大してみると、ClaudeはMeridian Propertiesの機器数がこの1年で36台から42台に増えたことを把握しています。ところが、新たに加わった6台については監視サービスが追加されていません。ですから、このメールをCaseyに送ることは、新しい機器に監視を追加するよう促す絶好の機会になります。営業担当者が求めているのは、まさにこうした支援なのです。
ここまでを振り返りましょう。私たちがお見せしたのは、アーキテクトが、意欲的ではあっても業務に組み込まれていなかったAIツールを、信頼できる企業のパートナーに変える方法です。Headless Toolkitで土台を築きました。エージェントを登録し、MCPで安全な接続を確保し、Scoped Access Definitionsで適切なアクセス制御を施しています。今回はClaudeで示しましたが、この土台はあらゆるエージェントで機能します。Customer 360やSalesforce Coworker、SlackbotといったSalesforceネイティブのエージェントも、拡大を続けるサードパーティのエージェントのエコシステムも対象です。
この土台があることで、ユーザーは自由に試行錯誤し、エージェントと一緒にどうすればより良く、より速く働けるかを探ることができます。だからこそ、これがエンタープライズ・イノベーションの出発点になるのです。では、次は何でしょうか。Radiant Homesのアーキテクトは、エンタープライズ・インパクトを拡大する準備が整いました。その続きを伺うために、リード・テクニカルアーキテクトのShelleyをお迎えしましょう。
4. 第2章 エンタープライズ・インパクトの拡大（Shelley）
4.1 要件の分解とゼロコピー・フェデレーション
Shelley： この素晴らしいアーキテクトコミュニティの一員であることを、とても誇りに思います。アーキテクトが大規模に価値を生み出す方法について話せることに、これまでにないほどわくわくしています。
まず、次のアイデアを形にするために今日使う道具を紹介します。一つ目はData 360で、ライブのデータを読み取るために使います。二つ目はAgent FabricのMCPサーバーで、これによって既存のAPIをエージェントから使えるようにします。三つ目はAgent Scriptで、次のアイデアにロジックを組み込むために使います。
では、その次のアイデアとは何でしょうか。Radiant Homesに戻りましょう。Radiant Homesは更新シーズンの真っ只中で忙しい状況ですが、今では個々の取引先について、根拠に基づいた回答を素早く得られる、会社公認の手段があります。私たちが考えたいのは、このアイデアを次の段階に引き上げるための一歩です。エージェントが更新提案書を自動で作成できたらどうでしょうか。
ゼロから始める必要はありませんし、そうすべきでもありません。契約データはすでに契約管理システムのIroncladにあります。スマートデバイスのデータはSnowflakeにあります。これらをまとめ上げたいのですが、どうすればよいでしょうか。Architect Agentに聞いてみましょう。「既存のエージェントがあり、それを既存のSnowflakeインスタンスと既存の連携レイヤーがある環境に持ち込みたい。何を考慮すべきか」と尋ねます。
エージェントは、検討すべき主要な判断事項をまとめて示してくれました。最初に挙がったのが、Data 360のゼロコピー・フェデレーションです。テレメトリーデータにライブでアクセスしたいので、素早く参照したい一方で、どこかに複製はしたくないからです。次は、契約管理システムのAPIにどうアクセスするかです。ここでは、統制されたAPIレイヤーの中で、トランザクションを伴う複数ステップの処理を扱う必要があります。リトライ機能も、全体を通じたポリシーの適用も欲しいところです。さらにエージェントは、ガバナンスについても非常に明確です。最小権限のアクセスと、エージェントのすべてのアクションに対する完全な監査可能性を求めています。
ここからは、頼もしいデモパートナーのLilithと私がアーキテクトの帽子をかぶります。皆さんには見えませんが、かぶったことにしてください。とてもエージェンティックで、とてもアーキテクトらしい帽子です。そして「Think Like an Architect」のプレイブックを参考にします。このシリーズを使っている方はいますか。手が挙がっていますね。まだの方はぜひご覧ください。素晴らしい内容です。プレイブックに倣って、設計を順に検討しやすくするために、全体をいくつかの大まかな要件に分解します。
一つ目の要件は、テレメトリーデータをエージェントが使える状態にすることです。二つ目は、Ironcladから契約条件を取り込むことです。三つ目は、あらゆるサーフェスでエージェントが一貫した推論を行えるようにすることです。
では一つ目の要件から始めます。Lilith、最初の前提は何でしょうか。そうです、データはすでにSnowflakeにあるという前提です。実際、スマートデバイスのテレメトリーデータは、現在すべてSnowflakeに格納されています。ここで自問する必要があります。優れたアーキテクトは自分にも周りにもたくさん問いかけるものですからね。データはSnowflakeに置いたままでよいのでしょうか。答えはイエスです。引っかけ問題ではありません。これはスマートデバイスのデータなので、ストリーミングで流れ込んできた瞬間に、すぐ参照できる必要があります。
この判断は簡単でした。そのうえでData 360に移り、ゼロコピーで範囲を設定します。デモ環境で詳しく見てみましょう。ご覧のとおり、Snowflakeとのゼロコピー接続がすでに作成されています。実データを一切コピーする必要はありません。ETLとは違い、データにライブでアクセスしています。クエリエディタに移ってライブクエリを実行すると、Snowflakeに直接データを取りに行き、すぐに結果が返ってきます。大規模な移行プロジェクトを立ち上げなくても、今まさにデータを参照できているのです。
4.2 MCPによるAPI活用とAgent Script
Shelley： 次の要件は、Ironcladから契約条件を取り込むことです。ここにも前提があります。数年前の買収の際に、B2Bの取引先をすべてIroncladに移行しました。ですから、APIを通じてそのデータにどうアクセスするかを決める必要があります。
APIはもちろんすでに存在します。Ironcladには APIがあり、私たちは毎日使っています。問題は、それをエージェントからどう使えるようにするかです。エージェントがそのAPIが何をするものなのかを理解できる仕組みが必要です。そこで、このAPIをツールとしてエージェントに公開することにします。ここで役立つのが、Agent FabricのMCP Bridgeです。APIをカスタムのMCPサーバーでラップし、ツールとしてエージェントに公開します。そうすれば、エージェントはそのデータの読み取り方を理解できるようになります。
MuleSoftの環境で詳しく見てみましょう。APIをMCPサーバーでラップしたことで、「契約の取得」や「契約の更新」といったツールが使えるようになっています。これでエージェントはこのデータをどう扱えばよいかを理解し、裏側で更新提案書を作成できるようになります。
最後の要件は、あらゆるサーフェスで一貫したエージェントの推論を実現することです。ここで自問すべき大きな問いは、このエージェントをどこに構築するかです。営業担当者は、顧客とのやり取りにさまざまなサーフェスを使っています。Claudeを使う人もいれば、Slackを使う人も、Salesforceを使う人もいます。どれを使っても構いません。私たちは、それぞれが最も働きやすい場所で働けるようにしたいのです。
もう一つ非常に重要なのが、確率的なロジックと決定的なロジックの両方を組み込むことです。エージェントには創造性を発揮してほしいと考えています。退屈なメールは要りません。かといって、エージェントが暴走して好き勝手に振る舞うのも困ります。ですから、いくつかのルールを与えたいのです。そこで、裏側にはAgentforceのエージェントを作成し、さらにAgent Scriptを使ってこちらのロジックを適用することにしました。
4.3 更新提案書の自動生成デモ
Shelley： では、営業担当者が実際に今使っている環境で見てみましょう。それはClaudeです。先ほどのLeoのデモと同じように、Meridian Towersの更新に先立って、Casey Henderson向けの更新提案書を作成するよう依頼します。
少し「調理」に時間をかけさせてください。「調理」と言ったのには理由があります。料理番組では、オーブンで焼き上がったケーキがどこかに用意されていて、それをさっと取り出しますよね。でも今は、皆さんの目の前でこのケーキを実際に焼いているのです。全部をまとめ上げるのに少し時間はかかりますが、ちゃんと動いています。
もう、これまで持っていなかった情報が得られ始めています。私たちはアップセルの機会を把握していませんでしたし、ハードウェアの交換が必要だということも知りませんでした。エージェントがそれを教えてくれています。
次のステップでは、更新提案書をまとめるために、裏側でいくつかのレコードを準備します。商談、商品明細、価格表を作成し、それらをすべて結び付けます。考えてみてください。これまでなら営業担当者がここに座って、いくつもの画面からデータを集め、コピー＆ペーストを繰り返していたかもしれません。今はもう、それを入力する必要はありません。代わりにエージェントが処理してくれます。場合によっては何時間もかかっていた作業が、今では数分で終わります。
最後のステップでは、更新提案書そのものを作成し、営業担当者が確認できるようにします。今まさに提案書がまとめられています。繰り返しますが、皆さんがご覧になっているのはライブの処理です。ライブデモとスライド資料の違いは、皆さんよくご存じですよね。これは本当に実行されています。改めて考えてみてください。皆さんの目の前で、ほんの数秒のうちにこれが起きました。そして今、SnowflakeのデータとIroncladのデータに基づいた、実際に使える提案書ができあがっています。
ここで強調したいのは、Radiant Homesがエージェンティックになるために、何年もかけて築いてきたインフラを捨てる必要はなかったということです。すでに持っていたものを、エージェントに対応できる形にしただけなのです。
先ほどのスライドに戻りましょう。私たちはここに並ぶ製品を組み合わせて、新しいビジョンへとまとめ上げました。その結果、新しいエージェントが本番環境で稼働し、営業担当者が実際に使っています。彼らは以前よりずっと速く動けるようになり、顧客にもより質の高い対応ができています。これが、アーキテクトとしてエンタープライズ・インパクトを拡大するということです。
それでは次に、エンタープライズ・トラストをどう統治するかを教えてもらいましょう。新しいWell-Architected Frameworkを支えた素晴らしいアーキテクトの一人、ソフトウェアエンジニアリング・アーキテクトのTim Breedenです。
5. 第3章 エンタープライズ・トラストのガバナンス（Tim Breeden、Lilith Van Bon）
5.1 稼働中を統治し、次を発見する
Tim Breeden： 皆さん、こんにちは。少しだけ、この光景を目に焼き付けさせてください。そうしようと自分に約束していたんです。客席は暗くて、こちらにはまぶしいライトが当たっています。そんな約束をしたのは、客席にいる多くの方と、このDreamforceで初めて直接お会いできるからです。それが本当にうれしいのです。
この半年間、私は新しいフレームワークに全力で取り組んできました。この会場にも貢献してくださった方がたくさんいます。まさにコミュニティ全体の取り組みでした。ですから、心からお礼を言わせてください。誰のことかはご本人が分かっていると思います。遠慮も妥協もないフィードバックを寄せてくださった皆さんです。Miriam宛てに送られた意見でさえ、まるで気送管で吸い込まれるように、まっすぐ私のところに届きました。ありがとうございます。そうした厳しい愛情こそがコミュニティだと思います。このフレームワークは、コミュニティのために作られただけではありません。コミュニティによって作られたものなのです。
とはいえ、これは大きな一歩の一つにすぎません。私たちはこのフレームワークの進化をとても喜んでいますが、この協力関係は続けていく必要があります。これからも一緒に取り組み、進化させ、機能し続けるようにしていかなければなりません。
「機能し続けるようにする」というのが、まさに私が今日お話ししたいテーマです。エージェントを立ち上げて動かすことは、ゴールではありません。エージェントのそばに居続け、信頼できる状態を保ち、エージェントが伝えてくることに耳を傾ける必要があります。それがガバナンスです。そしてガバナンスを正しく行えば、エージェントを健全に保てるだけでなく、それが成長の手段になり、次のビジネス機会を見つける手段にもなります。
では、具体的にどう進めればよいのでしょうか。Radiant Homesの状況を詳しく見る前に、全体の流れを簡単に説明します。まずArchitecture Centerから始め、もう一度あのエージェントの力を借ります。次にAgentforce Observabilityで、エージェントが実際の現場でどう振る舞っているかを確認します。消費量と利用状況については、Digital Walletを見ます。そして、これらすべてから得たシグナルを、Tableau Nextを通じてSlackに集めます。そうすることで、これからお話しするセンター・オブ・エクセレンス、つまりCOEのチーム全員が、リアルタイムで一緒に作業し、話し合い、足並みを揃えられるようにするのです。
この話を聞きながら、ぜひ一つの考え方を意識していてください。ここでお見せすることはすべて、すでに稼働しているものを統治するためのものであり、同時に次の機会を見つけるためのものでもあります。言葉にするなら、「稼働しているものを統治し、次に来るものを発見する」です。
Radiant Homesに戻りましょう。エージェントは稼働しています。初めてのAgentforceエージェントです。素晴らしいことです。これを統治しなければならないことに、異論はありません。これは真剣に取り組むべきことです。しかし、私たちにはその準備ができているのでしょうか。それは分かりません。では、どうやって確かめればよいのか。当て推量はやめて、ガイダンスがある場所に行きましょう。Lilith、どこにあるか分かりますよね。
5.2 ガバナンス指針と可観測性
Tim Breeden： Architecture Centerに行き、Architect Agentに私たちが考えていることをそのまま尋ねます。「私たちのCOEにエージェント型ワークロードを統治する準備ができているかどうかは、どうすれば分かるのか」。この回答がフレームワークに基づいているところが、私は気に入っています。この講演で「根拠に基づく」という言葉を何回聞いたでしょうか。エージェントはまず最初に、この仕事にふさわしいツールを示してくれました。先ほど挙げたAgentforce ObservabilityとDigital Walletです。
もう少し下にスクロールすると、「COEは最小権限のアクセスを徹底すべきである」と書かれています。私が何よりもよく目にする言葉かもしれません。最小権限のアクセス。Daniel、これがTrustの柱ですね。ありがとうございます。さらにエージェントは、ガバナンスのためのコミュニケーションと同期の頻度を上げるよう勧めています。これは私たちのCOEの運用でもお見せします。速く動かなければならないのは、エージェンティックな世界の変化が速いからです。しかもエージェント自身が、短時間で非常に多くのことを実行できます。それも統治しなければなりません。
最後に、ちょっとしたチェックリストもあります。データ品質の基準、技術の台帳、スキーマ変更の承認、そして文書化されたAIガバナンス・ポリシーです。最後のポリシーは、Radiant Homesにはまだありません。これで答えが得られ、最初に埋めるべきギャップが見つかりました。
では、そのギャップをどう埋めるか。エージェントから受けた推奨を実践に移していきます。その出発点は、COEがどう機能するかです。まずは手軽なところで、週次のスタンドアップ・ミーティングを設けます。開発者、管理者、アーキテクト、特にアーキテクトが集まって認識を揃えます。私たちの統治の仕方や加えている変更が、すでに現場で動いているエージェントと衝突していないかを確認するのです。
一方で、推奨された「同期の頻度を上げる」という点については、ぴったりのツールがありますよね、Lilith。常に開いているSlackチャンネルです。チームはいつでもリアルタイムで足並みを揃えられます。何かあればチャンネルに投稿し、他のツールから届くシグナルをもとに、そのチャンネルの中で一緒に作業し、行動に移します。実は今、私がこの基調講演で話している間にも、チームはチャンネルで変更作業を進めています。
これでプロセスは更新され、運用も始まりました。私はアーキテクトですし、これは初めてのAgentforceエージェントです。現場でどう振る舞っているのかを、どうしても見ておきたいところです。そこでLilithがAgentforce Studioに入り、セッションとインテントのタブからAgentforce Observabilityを開きます。
Lilith、あなたはいつも、必要な項目を入れて不要な項目を外し、見たいものが見えるように整えるのが好きですよね。私たちはアーキテクトとして、このエージェントがどうしているかを二人とも把握する必要があります。見事なカスタムビューができています。では見ていきましょう。何しろ初めてのエージェントですからね。
スクロールしていくと、最初はかなり健全に見えます。ところが、途中にエラーがあります。単なる注意喚起ではなく、エラーです。だから赤く表示されています。掘り下げる必要があるので、トレースまでたどって何が起きたのかを確認します。
ここで興味深いことが起きていました。営業担当者は確かに提案書を依頼し、更新提案書を受け取っています。しかしその内容は非常に一般的で、誰にでも当てはまるようなものでした。この顧客ならではのことは、ほとんど何も書かれていません。つまり、部分的にしか根拠づけられていない提案だったのです。
興味深いのは、エージェントが自分の仕事に自ら問題があると指摘していたことです。Radiant Homesの自社レコードには、先ほどShelleyが触れた機器の利用・消費に関するデータがすでにありました。しかし、エージェントはまだそのデータに基づいて回答できる状態になっていなかったのです。その結果、どの顧客が受け取ってもおかしくない提案書ができあがりました。それは私たちの最善の仕事ではありません。Radiant Homesには守りたい水準があるからこそ、これは単なる注意喚起ではなくエラーなのです。こうして弱点が見つかり、エージェント自身がその修正方法を示してくれました。私たちはそれに対処し、エージェントが適切なデータに基づいて回答できるようにします。
5.3 消費量と成果の分析、締めくくり
Tim Breeden： もう一つ関心があるのが、コストと消費量です。特にこれは初めてのAgentforceエージェントなので、その数字が事実上の基準値になります。Digital Walletを開いてもらえますか。ありがとうございます。今回が初めての計測なので、今後のエージェントはこの数字と比較することになります。
エージェント別の消費量を見てみます。と言っても、エージェントは一つだけですが。エージェントを現場に展開するのが初めてのアーキテクトとして見ると、良好に見えます。かなり忙しく動いていますね。Resource and Cost Optimizationの柱は、どんな人間よりも速くクレジットを食いつぶしてしまう「暴走的な繁忙」に注意するよう警告しています。しかし、これは健全な繁忙のように見えます。ですから、かなり安心しています。
状況を整理しましょう。品質については、弱点を見つけて修正しました。消費量についても、おそらく問題なさそうですし、営業担当者は実際にこのエージェントをよく使っています。それでも、これらすべてをどう解釈すればよいのか、まだ確信が持てません。私にはまだその経験がないのです。そこで考えました。こういう問題をあれこれいじって、物事がどこへ向かっているのかを見極めるのが好きな人といえば、皆さんもご存じのあの人、Lilith Van Bonです。Lilith、これをどう見ますか。
Lilith Van Bon： ありがとう、Tim。これは本当に興味深いですね。共有してもらえて良かったです。おかげで、エージェントがどう振る舞い、どう消費しているかは前よりよく見えるようになりました。ただ、まだ見えていないものがあります。成果です。このエージェントは、私たちが期待していた結果、つまり更新率の向上を本当にもたらしているのでしょうか。
そういうときに私が頼るのは、親友で頼れる相棒のSlackbotです。これらのインサイトがどう結び付いているのかを示して、更新率が上がっているかどうかが分かるようにしてほしいと頼んでみます。Slackbotに仕事をさせますが、皆さんをお待たせはしません。私はすでに焼き上がっているほうの料理番組なので、今朝のうちに焼いておきました。
こちらが、その美しいビジュアライゼーションです。SlackbotがTableau NextのMCPが持つ信頼できるセマンティクスを通じて接続されているので、質問にすぐ答えが返ってきます。エージェントが関与した更新と関与していない更新とで、更新率は上がっているか。答えは明らかにイエスです。エージェントは、期待どおりの役割を果たしています。
さらに興味深いのは、エージェントが関与して更新された契約では、追加される製品が増えていることです。つまりこのエージェントは、更新率を上げるだけでなく、アップセルにも貢献し、顧客の製品利用の拡大にもつながっています。この情報を私一人で抱えておくつもりはありません。チームと共有したいので、COEのチャンネルに投稿して、皆に見てもらうよう伝えます。
本当に素晴らしいのは、この情報をチャンネルに持ち込むことで、チームがそこから会話を続けられることです。Slackのチャンネルの中で、さらに深く掘り下げていけます。つまり、全員が会話を引き継いで深掘りし、必要なインサイトをすぐ手元で得られるのです。面白いと思いませんか、Tim。
Tim Breeden： とても面白いですね。チームにメモを送ってくれてありがとう。助かります。会場の皆さんに話を戻す前に、きちんと確認させてください。このエージェントが担当した取引先では、更新率が90%だったのですね。そして、エージェントが担当していない取引先と比べると、前年からの製品・サービスの追加が約4倍だった、ということですね。これはすごいことです。
ここでガバナンスが何をしたのか、考えてみてください。同じガイダンスが、顧客のロイヤルティと成長の両方を後押ししたのです。そうなると、次に自然と浮かぶ疑問があります。そもそも、なぜ更新シーズンを待ってから動く必要があるのでしょうか。Leoのデモでは、更新シーズンだからこそ営業担当者が慌ただしく動き回っていました。でも、そうである必要はありませんし、彼らはもっと生産的になれます。
こうしたデータを常に見守るエージェントがいれば、リアルタイムで知らせてくれるはずです。ある取引先が上位プランへの移行の準備ができているときや、別の取引先が静かに離れつつあるときに、赤信号の状態になる前に手を打てるのです。これは私にとって本当に素晴らしいことです。正しく行われたガバナンスは、守るためだけのものではありません。成長するための手段なのです。稼働しているものを統治し、次に来るものを発見する。それがエンタープライズ・トラストを統治するということです。Miriam、締めくくりをお願いします。
Miriam McCabe： 素晴らしいアーキテクトの皆さん、登壇者とデモ担当者の皆さんに、もう一度大きな拍手をお願いします。私たちはここまで、アーキテクトたちがエージェンティックな未来に向けたアーキテクチャのビジョンを語るのを見てきました。Leoはエンタープライズ・イノベーションを解放し、Shelleyはエンタープライズ・インパクトを拡大し、TimとLilithはエンタープライズ・トラストを統治しました。
これらすべてを可能にしたのはアーキテクトです。意思決定を下し、トレードオフを考え抜き、Well-Architected Frameworkが提供する知識と答えを、自分たちの状況に当てはめて解釈したアーキテクトです。アーキテクトこそが、エージェンティック・エンタープライズとエージェンティックな未来を解放し、拡大し、統治するのです。そしてその未来は、もう始まっています。
次にお願いしたいことがあります。フィードバックを寄せて、フレームワークの未来を一緒に形づくってください。画面のQRコードを読み取ってください。そして日々の仕事でフレームワークを使ってください。そうすれば、それをもとに次の版をさらに良いものにできます。これで、Dreamforceのアーキテクト基調講演は終わりです。楽しんでいただけたならうれしいです。最後までお付き合いいただき、ありがとうございました。残りのDreamforceも楽しんでください。