【実機検証】Salesforce Builder Centralで問い合わせ管理アプリを作ってみた | 会話だけでどこまでできる?エラー対応も紹介
投稿日:
更新日:
#Salesforce #エラー #Salesforce Builder Central
目次
- 1. Builder Centralとは
- 2. Builder Centralを有効化する
- 2.1 「Builder Central にアクセス」権限を付与
- 2.2 Einsteinを有効化
- 3. Builder Centralを起動する
- 3.1 Builder Centralの画面構成とプロジェクト履歴
- 4. 日本語の会話形式で問い合わせ管理の仕組みを作成する
- 5. 自動で作成されたもの
- 6. Preview Orgで実際に動かす
- 6.1 実際に作成された画面
- 7. 初回生成ではFlowのエラーが発生
- 8. 新規作成画面にも不足があった
- 9. Previewのたびに異なるPreview Orgが開いた
- 10. メール通知まで動作確認
- 11. 生成されたFlowは内容確認が必要
- 12. Preview確認後はSandboxへ一括反映できる
- 13. Sandbox公開後に必要だった作業
- 14. 実際に使って分かったこと
- 14.1 Previewには時間がかかる
- 15. そのほかの検証
- 15.1 取引先に日付項目を10個まとめて作成
- 15.2 生成されたメタデータを確認し、ピンポイントで修正する
- 16. まとめ
- 17. 参考情報
日本語の会話形式で業務機能を作成・Preview・Sandbox反映まで検証
Salesforceでは2026年9月から、会話形式で要件を伝えながらオブジェクトや画面/自動化などを作成できる「Builder Central」がベータ提供されています。
Builder Centralは、Dreamforce 2026のAdmin Keynoteでも紹介された注目度の高い新機能です。従来の設定画面や各種Builderを個別に操作するのではなく、作りたいものを会話形式で伝えるところからSalesforceの構築を始められます。
今回は実際のSandboxでBuilder Centralを有効化し、日本語で要件を伝えながら、問い合わせ管理の仕組みを作成しました。作成だけでなく、Preview環境での動作確認、エラー修正、Sandboxへの反映まで確認しています。
Builder Centralとは
Builder Centralは、作りたいものを会話形式で伝えることで、Salesforce上の業務機能を作成できる機能です。今回の検証では、1つの要件から以下のような設定が作成されました。
- カスタムオブジェクト/カスタム項目
- Salesforceアプリ(ナビゲーション)/一覧ビュー
- Lightningレコードページ/ページレイアウト
- Flow
- 権限セット
単にカスタム画面を作る機能ではなく、Salesforce上で業務を動かすための設定をまとめて作成し、Previewで確認してSandboxへ反映するところまで進められます。
Builder Centralを有効化する
Builder Centralのベータ版は、Agentforceが有効な組織を対象に提供されています。Salesforceによると、すべての組織に使用量の上限付きで無料で含まれています。
ただし、Builder Centralの利用に伴ってAgentforceなど一般提供中のサービスが使われる場合、契約中のクレジットなどが消費されることがあります。利用前に、自社の契約内容や消費状況を確認しておくと安心です。
「Builder Central にアクセス」権限を付与
権限セットを作成し、システム権限の「Builder Central にアクセス」を有効化して、対象ユーザーへ割り当てます。

「Builder Central にアクセス」権限を有効化
今回の環境では、権限を付与する前でも設定画面の「Builder Central(ベータ)」自体は表示されていました。
Einsteinを有効化
Builder Centralの設定画面では、Einsteinが無効な状態だとBuilder Central本体を有効化できませんでした。そこで「設定 → Einstein設定」でEinsteinを有効化します。

Einstein設定を有効化
Einsteinを有効化した後、Builder Centralの設定画面を再読み込みすると「Builder Central(ベータ)を有効化」をONにできました。

Builder Central(ベータ)を有効化
Builder Centralを起動する
Builder Centralを利用するユーザーには、事前に「Builder Central にアクセス」権限を付与しておく必要があります。
今回の環境では、権限を付与していない状態でも設定画面から「Builder Central(ベータ)」の設定ページを開くことはできました。一方、アプリケーションランチャーからBuilder Centralを起動するには、「Builder Central にアクセス」権限を含む権限セットの付与が必要でした。
権限セットをユーザーへ割り当てると、アプリケーションランチャーに「Builder Central(ベータ)」が表示されました。

権限付与後、アプリケーションランチャーにBuilder Centralが表示
初回起動時は数秒の読み込み画面が表示され、その後Builder Centralのホーム画面が開きます。画面中央から、会話形式で作りたいものを伝えられます。

Builder Centralのホーム画面
Builder Centralの画面構成とプロジェクト履歴
プロジェクトを作成すると、Builder Centralの作業画面は大きく3つのエリアに分かれます。
- 左側:Agentforceとの会話エリア。要件の追加や修正、Previewの依頼、エラー内容の共有などを会話形式で行います。
- 中央:Explorer。Builder Centralが作成したデータモデル、Flow、Flexi Page、権限セットなどのメタデータを確認できます(詳しくは15.2で紹介)。
- 右側:Project Details。Overview、Problem、Solution、Core Featuresなど、Builder Centralが整理したプロジェクトの要件を確認できます。

Builder Centralの作業画面。左から会話エリア、Explorer、Project Detailsが並ぶ
作成したプロジェクトは、ホーム画面左側の「PROJECTS」から再度開けます。今回の検証では、プロジェクト名は自動では付かず「Untitled」と表示されていたため、後から見分けられるように自分で名前を付けておくのがよさそうです。

ホーム画面左側の「PROJECTS」から作成済みプロジェクトを確認できる
また、ホーム画面上部には「During beta, return every 7 days to keep your builds and chats.」と表示されています。ベータ期間中は、作成内容や会話を保持するため、7日ごとにBuilder Centralへ戻るよう案内されています。
ホーム画面にはサンプルプロンプトも用意されており、「Recommended」「Apps」「Agents」「Sites」のタブから用途別の例を確認できます。
実際にAppsでは「Support Ticket Intake App」「Customer Onboarding App」、Agentsでは「Customer Support Agent」「Renewal Reminder Agent」、Sitesでは「Self-Service Help Center」「Order Tracking Portal」などが表示されていました。
今回の記事では問い合わせ管理の仕組みに絞って検証しましたが、サンプルを見る限り、アプリ構成だけでなくAgentやサイトまで幅広い用途が想定されています。次回は別の観点から、Builder Centralでどこまで実現できるのかを検証したいと思います。

Apps / Agents / Sitesに用意されたサンプルプロンプト
日本語の会話形式で問い合わせ管理の仕組みを作成する
今回は、以下の内容を日本語で入力しました。
入力後、Builder Centralは要件を整理し、Overview、Problem、Solution、Core Features、Non-Goals、Target Usersなどを含むProject Detailsを作成しました。すぐに設定を作り始めるのではなく、先に「何を作るのか」を整理したうえで構築に進みます。
自動で作成されたもの
今回の要件から、Builder Centralはデータモデル、Flow、レコードページ、権限セットなどをまとめて作成しました。最初の入力からここまでの生成には約2分かかりました。

生成後のExplorer。データモデル、Flow、Flexi Page、権限セットが確認できる
| 種類 | 今回作成された内容 |
|---|---|
| データモデル | 問い合わせオブジェクトと、件名・内容・優先度・ステータス・担当者などの項目 |
| Flow | 優先度が「高」で担当者が設定されている問い合わせが登録・更新された場合に、担当者へメール通知するレコードトリガーフロー |
| 画面 | 問い合わせ用Lightningレコードページ、ページレイアウト、一覧ビュー |
| 権限 | 問い合わせ管理アプリを利用するための権限セット |
| アプリ | アプリケーションランチャーから起動できる「問い合わせ管理」アプリ |
Preview Orgで実際に動かす
作成した内容は、そのままSandboxへ反映する前にPreviewできます。今回はBuilder Centralとの会話で「プレビューで動きを確認したい」と伝えました。
Previewを開始すると「Generating preview…」の進捗画面が表示され、実際に操作できる一時的なPreview Orgが用意されます。今回の検証では、Preview Orgを開けるようになるまで約3〜4分かかりました。

Preview Orgを準備している画面
実際に作成された画面
Preview Orgでは、「問い合わせ管理」のSalesforceアプリ(ナビゲーション)が作成され、問い合わせタブから一覧画面を確認できました。

「問い合わせ管理」アプリの問い合わせ一覧画面
初回生成ではFlowのエラーが発生
Preview Orgで問い合わせを登録すると、最初は「CANNOT_EXECUTE_FLOW_TRIGGER: 0 recipients」というエラーが発生しました。

初回Previewで発生したFlowエラー
エラー内容をそのままBuilder Centralへ伝えると、Builder Centralの説明では、通知先に担当者ユーザーのIDを渡していたことが原因とのことでした。担当者のメールアドレスを取得して送信するようFlowが修正され、約4分で修正が完了しました。

Builder Centralが原因を説明し、Flowを修正
新規作成画面にも不足があった
初回Previewでは必要な項目が表示されていましたが、Flow修正後に再度Previewした別のPreview Orgでは、新規問い合わせ画面に「件名」しか表示されませんでした。そこで、内容・優先度・ステータス・担当者も表示するよう依頼しました。
Builder Centralの説明では、カスタム項目を作成した際に画面レイアウトを用意していなかったことが原因とのことでした。なお、初回Previewでは必要な項目が表示されていたため、なぜPreviewごとに表示が異なったのかまでは確認できていません。Builder Centralはページレイアウトを修正しました。

Builder Centralが原因を説明し、レイアウトを修正
修正後のPreviewでは、必要な項目がすべて表示されました。

修正後の新規問い合わせ画面
Previewのたびに異なるPreview Orgが開いた
今回の検証では、Previewをやり直すたびに、開いたPreview Orgの組織識別子が異なっていました。少なくとも今回の実機確認では、Previewごとに別の環境が用意されていました。
また、各Preview Orgでは前回のテストレコードが引き継がれず、確認できるようになるまで毎回数分かかりました。
メール通知まで動作確認
修正後のPreview Orgで、件名・内容・優先度・ステータス・担当者を入力し、優先度を「高」にして保存しました。
今回開いたPreview Orgではメール送信設定が「システムメールのみ」だったため、「設定 → 送信 → メールを送信するためのアクセス権」の「アクセス権」を「すべてのメール」へ変更しています。変更後に再度問い合わせを作成すると、担当者へメールが届きました。
メールの件名や本文もBuilder Central側で作成されており、件名、ステータス、内容などが含まれていました。

Builder Centralが生成したFlowから届いた通知メール
生成されたFlowは内容確認が必要
今回生成されたFlowは、レコードトリガーフローとして作成されていました。トリガーは「レコードが作成または更新された」、エントリ条件は「優先度が『高』」「担当者が設定されている」の2点です。

Builder Centralが作成したレコードトリガーフロー
一方、更新されたレコードでフローを実行するタイミングは「レコードを更新し、条件の要件に一致するたび」に設定されていました。この設定では、すでに優先度が「高」で担当者が設定されている問い合わせで別の項目を更新した場合にも、そのたびに担当者へメールが送信されます。
Builder Centralは構築計画の段階でも、登録/更新された際に通知する構成を示していたため、生成後に初めて分かる内容ではなく、計画を確認する段階で気づけるポイントです。今回の要件は「登録された場合に通知」だったため、実運用では「条件の要件に一致するようにレコードを更新したときのみ」に変更するか、トリガーを「レコードが作成された」にする方が安全です。
Builder Centralが提示する計画や生成されたFlowが実際の業務ルールに合っているかは、公開前に確認しておく必要があります。
Preview確認後はSandboxへ一括反映できる
Previewで基本動作を確認し、その後の修正も含めてSandboxへ反映しました。Builder Centralとの会話から公開を進めることも、画面右上の「Publish to Sandbox」ボタンから直接公開することもできます。

「Publish to Sandbox」から公開先を確認して反映
今回の環境では13コンポーネントが反映され、公開処理は1分かからず完了しました。

13コンポーネントがエラーなくSandboxへ反映
Sandbox公開後に必要だった作業
Sandboxへの公開後、生成された権限セット自体は存在していましたが、公開処理だけではユーザーへ自動割り当てされませんでした。公開後の会話では、Builder Centralから権限セットの割り当ても行うか提案されており、会話から依頼するか、Salesforceの設定画面から手動で割り当てることができます。
一方、生成されたFlowは有効化された状態で反映されていました。今回は設定画面から権限セットを手動で割り当て、公開した問い合わせ管理の機能を利用できることを確認しました。
実際に使って分かったこと
今回試した範囲では、Builder Centralは単にFlowや画面を作る機能ではありませんでした。日本語で業務要件を会話形式で伝えるだけで、データモデル、画面、自動化、権限、Preview、Sandbox公開までまとめて進められます。
便利だったのは、Previewで発生したエラーをそのままBuilder Centralへ伝えると、原因を確認して設定を修正できた点です。
一方で、検証中にはFlowやページレイアウトに不備が発生しました。また、今回のFlowの再通知条件のように、要件の意図と異なる設定になっている場合もあるため、計画や生成結果は公開前に確認が必要です。
Previewには時間がかかる
もう1つ気になったのが、Previewにかかる時間です。今回の検証では、Previewをやり直すたびに開いたPreview Orgの組織識別子が異なり、準備が完了するまで毎回3〜4分程度かかりました。
また、今回の各Preview Orgでは前回作成したテストレコードが引き継がれなかったため、修正内容を再確認するたびにテスト用レコードを作り直す必要がありました。
そのため、軽微な修正を繰り返す場合でも一定の待ち時間が発生します。現時点では「完成した業務機能を一度で自動生成する機能」というより、「業務機能のたたき台を作り、Previewしながら修正していく機能」と捉えるのが分かりやすそうです。
そのほかの検証
取引先に日付項目を10個まとめて作成
問い合わせ管理アプリとは別に、既存の取引先オブジェクトへ項目を一括で作成できるかも試しました。
Builder Centralは、日付項目を10個(日付A〜日付J)作成しました。項目レベルセキュリティについては、プロファイルではなく、参照・編集権限を付与する権限セット「取引先 日付項目A-J アクセス」を作成しました。あわせて、項目アクセスは権限セットで管理するのが現在のベストプラクティスだと説明し、プロファイルに直接設定したい場合は対象のプロファイル名を伝えれば反映するとのことでした。

Builder Centralの回答
今回は権限セットでの設定をそのまま採用し、Previewを省略してSandboxへ公開したところ、数分で10項目の作成が完了しました。項目の作成と権限設定を1つずつ繰り返す必要がないため、管理者の定型作業の効率化にも使えそうです。なお、作成された権限セットは、使用するユーザーへの割り当てが必要です。

オブジェクトマネージャーで作成された項目
生成されたメタデータを確認し、ピンポイントで修正する
Builder Centralでは、生成された内容を会話の履歴だけでなく、Explorerからメタデータ単位で確認できます。データモデルでは項目のAPI名とデータ型、Flowでは各要素の設定内容、権限セットではオブジェクト権限や割り当てられたアプリを、設定画面を開かずに確認できました。

Flowの要素ごとの設定内容(取得条件など)を確認できる

権限セットのオブジェクト権限と割り当てられたアプリ
修正したい箇所がある場合は、「Select to Edit」から対象の要素を選択し、変更内容を入力して送信できます。今回は、問い合わせオブジェクトの担当者項目を選択し、「項目API名をAssign_Toに変更して」と依頼したところ、API名が「Assign_To__c」に変更されました。Builder Centralの説明では、この項目を参照しているレコードページ、通知Flow、ページレイアウト、一覧ビュー(2件)、権限セットもあわせて更新されており、Flowの設定が新しいAPI名に変わっていることも実際に確認できました。

対象の項目を選択して変更を依頼

API名変更時のBuilder Centralの回答

API名が「Assign_To__c」に変更された
また、Builder Centralは、API名の変更は項目の削除と再作成に相当するため次回のPreviewは一から作り直しになること、公開済みのSandboxに反映するには改めて公開が必要なことも案内していました。削除と再作成に相当する以上、公開済みの環境で項目のAPI名を変える場合は、既存データへの影響を確認してから進める必要があります。
会話で一から説明し直さなくても、対象を指定してピンポイントで修正を依頼できるため、細かな調整がしやすくなっています。
まとめ
今回、Builder Centralを使って問い合わせ管理の仕組みを作成しました。日本語の会話形式で要件を伝えるだけで、オブジェクト、項目、Salesforceアプリ(ナビゲーション)、Flow、画面、権限セットまで作成できました。既存オブジェクトへの項目の一括作成のような、日常的な管理作業にも活用できそうです。
また、Preview Orgで実際に動作確認し、問題があればBuilder Centralとの会話から修正できます。生成されたメタデータは画面上で確認でき、修正したい箇所を選んでピンポイントで依頼することもできます。最後は「Publish to Sandbox」で、作成した内容をSandboxへまとめて反映できました。
一方で、初回生成だけでそのまま利用できるとは限りません。Flowの条件やページレイアウトなど、実運用を想定した確認は必要です。
ベータ版ではありますが、Salesforceの構築作業を会話形式から始め、Previewと修正を繰り返してSandboxへ反映できる点は、従来の設定画面中心の構築とは異なる体験でした。
次回は、ホーム画面に用意されているApps、Agents、Sitesのサンプルプロンプトも参考にしながら、今回とは別の観点でBuilder Centralがどこまで実現できるのかを検証してみたいと思います。
参考情報
Salesforce Admins: Dreamforce 2026 Product Highlights for Admins
Trailhead: Builder Central Quick Look
<Salesforce>
弊社ではSalesforceをはじめとするさまざまな無料オンラインセミナーを実施しています!
>>セミナー一覧はこちら
また、弊社ではSalesforceの導入支援のサポートも行っています。ぜひお気軽にお問い合わせください。
>>Salesforceについての詳細はこちら
>>Salesforceの導入支援実績はこちらからご覧いただけます!
医療業界に特化した営業支援、顧客管理(SFA/CRM)のコンサルティングも提供しております。こちらもぜひお気軽にお問い合わせください。
>>顧客管理(SFA/CRM)のコンサルティングの詳細はこちら


