tyoshikawa1106のブログ

- Force.com Developer Blog -

SFDC:Winter'27の複数のレコードタイプを含むリストビューでのインライン編集を試してみました

Winter'27の複数のレコードタイプを含むリストビューでのインライン編集を試してみました。この機能は設定のユーザーインターフェースで有効化することで利用可能になります。


画面内にある「複数のレコード種別を含むリストビューでインライン編集を行う」のチェックをONにして保存すると適用されます。レコードタイプではなくレコード種別という設定になっているので注意。


設定適用後のリストビューです。表示条件でレコードタイプの絞り込みを行なっていない状態でもインライン編集が可能となります。


例として選択リスト項目の値を変更します。


変更後の内容の保存ができました。

参考サイト

Lightning Experience のリストビューからレコードをインライン更新

https://help.salesforce.com/s/articleView?id=xcloud.customviews_edit_inline_listview_lex.htm&type=5


Lightning Experience でのリストビューのインライン編集の考慮事項

https://help.salesforce.com/s/articleView?id=xcloud.basics_customviews_lv_lex_considerations.htm&type=5

SFDC:Winter'27の開発者コンソールの再表示手順とWeb コンソールについて

Winter'27のアップデートで開発者コンソールが非表示となるアップデートがありました。本番環境とSandbox環境の両方に適用されます。(Developer Edtion組織は自動適用はありませんでした。)

Salesforceヘルプサイト

リリースノートに次のように紹介されています。

Salesforce Help


Salesforce Developer Blogでも紹介されていました。Web コンソール自体は前からありましたが、今回のWinter'27のアップデートでGAになったということです。

開発者コンソールを再表示する方法

設定→Web コンソールでアクセスできるページで有効化できます。


設定変更履歴では showDeveloperConsoleWithWebIdeOffOn と記録されます。


これで開発者コンソールを再度表示することができます。まだ現時点では開発者コンソール廃止といった情報は出ていないので必要に応じて再表示して段階的にWebコンソールへ移行するのが良さそうです。

Web コンソールでできること

Webコンソールの画面は次のようになっています。VSCode上で構築できるSalesforce開発環境のWeb版という感じです。ターミナルなどのWindowはありますが利用不可となっています。また、開発者コンソールでは開いたときに表示されるApexクラス等の情報は空の状態となっていました。

主に以下の機能があります。

  • Apexコードの編集
  • SOQLの実行
  • Anonymous Apexの実行
  • Apexテストの実行
  • デバッグログの確認
  • メタデータの取得・デプロイ


VSCodeのSF開発環境と同じくSalesforce CLIコマンドでできることが実行できます。nodeのインストールなど不要ですぐに利用できます。


Webコンソールの開発者ドキュメントはこちらです。


開発者コンソールとWebコンソールの違いについて記載がありました。Webコンソールでは開発者コンソールがサポートしていないかったLWC開発が可能になります。


類似機能となるAgentforce Vibes IDEとの比較もありました。Agentforce Vibes IDEの方はターミナルの利用も可能となっています。


WebコンソールつかうならAgentfove Vibes IDEの方がいいのではと思いましたが、以下のように使い分けする形とのことです。

Webコンソールを使用する場面: 
・既に組織内に所属しており、クエリの動作を検査する必要があります。
・特定のレコードが失敗した理由を確認するには、ログを精査する必要があります。
・小規模で的を絞った修正を行いたい。
・フル機能の開発スイートよりも、スピードとコンテキストを重視したい。

Agentforce IDE を使用する場面: 
・新しい機能や複雑なプロジェクトを開始する場合。
・複数のファイルまたはLightning Web Components(LWC)をまたいで作業しています。
・コードをリポジトリにコミットする必要があります。
・AIを活用した開発でコーディングを加速させたい。(AI機能なしでも使える)

Web コンソールでメタデータ情報を取得する方法

画面左側メニューの雲アイコンをクリックするとSalesforceのメタデータ情報が表示されます。


対象ファイルの右側のアイコンをクリックするとメタデータを取得できます。


取得後は最初に表示されたclassesフォルダの中などに配置されてすぐにアクセスできるようになります。これは一度ログアウト→再ログインしても引き継がれました。PC再起動まではチェックしていませんががSalesforceユーザー情報に紐つく形で管理されているようです。


保存処理はMacの場合は command + s キーのいつものショートカットと同じで実行できました。

Web コンソールでクエリを実行する方法

Macの場合は command + pキーでコマンドパレットを開きます。ここでクエリビルダーを選択します。


するとファイル名の記入欄がでてきます。クエリ実行の際にはファイルを生成して実行する形となります。


ファイルの配置場所も指定できます。デフォルトは scripts/soqlとなっています。



ここまで操作すると sample.soqlのようなファイルが生成されてビルダー画面が表示されます。


ビルダーの操作イメージです。


SELECTのALL FIELDSは便利でした。


クエリの実行は画面右上のRun Queryボタンから。これでクエリ実行できます。


実行結果は次のように表示されました。実行結果にあるcsv出力とjson出力機能がけっこう便利です。


このようにクエリ実行結果を必要なファイル形式で補完できます。


今までの開発者コンソールの使い方と大きく変わるので慣れるまで時間が必要そうですが、確かにクエリ実行が可能で、機能も追加された形となりました。

クエリビルダーの補足

Salesforce CLIあたりの機能なのでVSCodeで用意したSalesforce開発環境でも利用できます。

匿名Apexの実行方法

開発者コンソールにあるこの機能のことです。


Webコンソールでは一度スクリプトファイルを生成します。手作業で作成できますが、コマンドパレッドからも作成できます。


ファイル名を指定して保存フォルダを指定します。



これでapexのスクリプトファイルが生成されます。開発者コンソールと違いファイル生成を挟むのが手間ですが、画面更新しても残り続けるのはメリットかと思います。


スクリプトファイルを開いて右クリックするとでてくるメニューから匿名Apexを実行できます。


実行結果です。

まとめ

Web コンソールの使い方はこのようになっていました。開発者コンソールとお作法は変わりますが、これから使っていく機能としては慣れていくのが良さそうです。開発者コンソールのときにはできなかった便利機能も増えていくのかと思います。

関連記事

SFDC:Winter'27で強制有効化されるプロファイルの絞り込み設定について

2026年10月11日(日)にWinter'27へのメジャーアップデートがありました。


今回のメジャーアップデートで、プロファイルの絞り込み設定が強制的に有効化されます。


この機能が有効化されると一般権限のユーザーは他ユーザーのプロファイルを参照できなくなります。見れなくなるのは他ユーザーのプロファイル情報のみで自分自身のプロファイル情報は参照可能です。

https://successjp.salesforce.com/article/NAI-001297


この仕組み自体はSpring'21のころからありました。セキュリティアップデートに関するものなので基本的には有効化して追従するようにした方が良いものとなります。


Salesforce Help


有効化された際の挙動についてです。一般権限ユーザーは自分のプロファイル情報までは参照可能です。(設定定義の参照権限までは付与している状態で確認しています。)


他ユーザーのプロファイルは次のように参照不可となります。


上記のように有効化されたことで他ユーザーのプロファイルが参照できなくなると以下のような制御への影響が考えられます。

  • Apex
  • ルックアップ検索
  • 数式
  • 入力規則

※ルックアップ項目に指定されたユーザーのプロファイルが〇〇のとき〜という制御をしていれば影響があります。大半はログインユーザーのプロファイルがという制御となっていると思います。


セキュリティに関するアップデートなので原則適用するのが望ましいですが、まだ準備ができていないという場合は以下のように手動でオフに切り替えできます。


予期せぬエラーが発生した場合などは一度機能をオフにして調整後に再度有効化を進めるという対応が可能となっています。

SFDC:Codexでメタデータ取得スクリプトの開発を試してみました

Codexを使ってSalesforceのメタデータを取得するスクリプトの開発を試してみました。


Salesforceのメタデータはpackage.xmlファイルに取得したい情報を定義してVSCodeのSalesforce Extension Packの仕組みを使ってSalesforce組織から取得できます。


メタデータは無制限に取得できるわけではなく、一度に最大10,000ファイルまでとなっています。Apex開発に必要なメタデータ取得のみであれば気にする必要はほぼありませんが、組織の様々なメタデータを取得したい場合は分割して実行する必要があります。


次のように種別ごとにXMLファイルを用意するイメージです。


これで各XMLファイルに定義されたメタデータを取得できますが、1ファイルずつ取得処理を実行するのは現実的ではないためスクリプトファイルを用意しました。

スクリプト実行時の流れ

スクリプトはNode.jsで実装されており、npmコマンドで呼び出せるようになっています。コマンドはpackage.jsonで定義されています。

npm run sf:retrieve


VSCodeで設定しているtarget-orgを対象に処理を実行します。実行時には組織情報を表示して別組織と間違えて実行していないかをチェックします。


実行すると各種類のXMLファイルを使って順番に処理していきます。

取得対象のメタデータファイルが多い場合、処理に時間がかかるのですが、何も表示されないと、フリーズしているのか処理中なのかわかりづらいため、30秒間隔で経過時間を表示するようにしました。また、取得できたファイルの件数やwarningを表示することで、取得結果を確認しやすくしています。


すべての処理が終わるとメッセージが表示されて内容を確認できるという形です。

取得時の注意点

一部のメタデータは、関連するメタデータを一つのファイルに一緒に定義することで取得できるものがあります。プロファイル関係や翻訳関係などです。また、標準オブジェクトは*指定では取得できないため、取得対象を個別に定義する必要があります。


レポートやダッシュボード、メールテンプレートなど * も取得がサポートされていません。取得対象を一つずつ宣言する必要があります。

組織で取得可能なメタデータのファイル名をチェックしたい場合

以下のコマンドを実行すると、組織に存在するメタデータをもとにpackage.xmlを生成できます。*を使えないものについても具体的なメタデータ名を確認できるため、manifestを作成するときに利用できます。

sf project generate manifest --from-org <org>

メタデータとGitバージョン管理

メタデータを取得することで設定情報のバージョン管理が可能になります。ただし、メタデータ取得はしたいが、Git管理には含めたくないものもあります。

その場合は .gitignoreで指定します。Developer組織やTrailheadのハンズオン組織の場合は「force-app/main/default/assignmentRules/」あたりにはメールアドレスが含まれていたりするので除外しておいた方が良さそうです。

そもそも取得対象から除外したい場合は.forceignoreに指定します。


取得したメタデータでできること

メタデータを変更してデプロイすることで、Salesforceの設定を変更することもできます。今だとAIエージェントに調査、分析してもらう用途での利用が便利です。


権限セットなどのメタデータも読み込ませることで、設定内容を確認してもらうことができます。

参考リンク

GitHub:salesforce-platform-playground


Salesforce CLI:project retrieve start


Salesforce Developers:Metadata APIの制限


Salesforce Developers:package.xmlでのMetadata Typeの指定

developer.salesforce.com

SFDC:Salesforce開発リポジトリのGitHub Pages設定

Salesforce開発リポジトリのGitHub Pages設定についてです。リポジトリ内にdocsフォルダを用意すると、開発に必要なドキュメントをまとめて管理できて便利です。


ただ、メニューバーなどが表示されてこれだけだと見づらいです。GitHub Pagesを有効化してドキュメントを参照できるようにすると使い勝手が良くなります。


表示例です。


リンクをクリックして次のページに切り替えた時の内容です。


注意点としては公開先です。個人リポジトリなど、インターネットへの公開を前提とした用途ではそのまま利用できます。一方、業務用リポジトリでは公開範囲に注意が必要です。

  • GitHub Enterprise Cloudを利用
  • Organization所有のPrivateリポジトリ
  • PagesのVisibilityをPrivateに設定
  • 閲覧対象者とリポジトリのRead権限者が同じ
  • 用途は設計書、仕様書、開発手順などの静的なDocs
  • 機密値や個人情報は掲載しない

設定方法

1. Organizationオーナー側の利用許可

  • Organizationオーナーが次の画面を開きます。
  • Organization → Settings → Access → Member privileges → Pages creation

 ここで許可する公開範囲を選択します。

今回の用途では、次の設定が安全です。

  • Private Pages:許可
  • Public Pages:不許可

これにより、Organization内のメンバーがPrivate Pagesを作成できるようになります。
この設定はOrganization全体への利用許可で、特定リポジトリだけを選択する設定ではありません。

OrganizationのPages公開設定

docs.github.com

2. リポジトリ側のPages設定

上記の設定ができたらリポジトリ側でGitHub Pagesの設定を行います。
Pagesを利用したいリポジトリごとに、管理権限を持つユーザーが設定します。

Repository → Settings → Code and automation → Pages

今回の構成なら、次のように設定します。

  • Source:Deploy from a branch
  • Branch:main
  • Folder:/docs
  • Visibility:Private

この設定を行ったリポジトリだけにPagesサイトが作成されます。
Private Pagesは、そのリポジトリにRead権限を持つユーザーだけが閲覧できます。

その他の考慮点


設定画面

GitHub Pagesの設定画面です。


ブラウザの翻訳機能で日本語表示した例。

GitHub Pagesのスタイルの設定

_config.ymlファイルを用意してJekyllテーマを適用すると見やすい形に指定できます。

docs/
├── _config.yml
├── index.md
└── その他のMarkdownファイル


内容の例です。urlとbaseurlはPublic PagesとPrivate Pagesで設定が異なるため、共通例では省略しています。


title: Salesforce DX Project
description: Salesforce DX / Apex / Salesforce metadata の学習用ドキュメント
theme: jekyll-theme-primer


GitHub Pagesを有効化し、既存のdocs/index.mdに加えてdocs/_config.ymlを用意すると、指定したJekyllテーマが適用されます。GitHub上で公開するだけなら、追加のソフトウェアをインストールする必要はありません。

GitHub Pagesを有効化したドキュメントページ作成についてはこのような感じです。

SFDC:Salesforce開発リポジトリのGitHubブランチ保護設定

Salesforce開発リポジトリのGitHubブランチ保護設定についてです。

ブランチの保護

Settings → Code and automation → Branches → Branch protection rulesという操作で設定ページにアクセスできます。


新規作成の方法

Add Ruleボタンでブランチのルールを作成できます。


設定できる情報はこちら。

mainブランチの設定について

Protect matching branches

以下の設定を有効にしておくと良さそうです。

  • Require a pull request before merging(マージする前にPull Requestを必須にする)
  • Require status checks to pass before merging(マージ前にステータスチェックの成功を必須にする)
  • Require branches to be up to date before merging(マージ前にブランチを最新の状態にする)
  • Require conversation resolution before merging(マージ前にレビューコメントの解決を必須にする)
  • Do not allow bypassing the above settings(管理者を含めて設定の回避を許可しない)

ステータスチェックを必須にする場合は、事前にGitHub ActionsなどのCI設定が必要です。そのため、最初はステータスチェック関連の2項目を除いた3項目を有効にするのが良さそうです。

ルールを追加することで以下のような制御が追加されます。

  • 誤ってmainへ直接pushしてもGitHub側で拒否され、Pull Request経由の変更に限定できます。
  • 未解決のレビューコメントがあるPull Requestはマージできません。レビューワーの指定有無ではなく、レビューコメントが解決済みかどうかで判定されます。
  • 管理者を含め、ブランチ保護設定の回避を禁止できます。
Rules applied to everyone including administrators

このブロックにあるAllow force pushesとAllow deletionsは、通常はチェック不要です。


ブランチルールはこのように設定します。今回有効にしていない項目についても、リポジトリの運用方針に応じて追加します。

SFDC:MCP サーバー設定でSalesforceとChatGPTの接続に関する調査メモ

MCP サーバーの設定を行い、SalesforceとChatGPTとの接続を試してみました。前回の記事の続きの話となります。


最初に、この接続を行う場合はChatGPTのプランがBusiness/Enterprise/Eduでないと設定できませんでした。また、デスクトップアプリではなくWebページ版から設定する必要があるようでした。自分の環境では設定と有効かを最後まで確認できませんでしたが確認できた範囲で記録しておきます。

ChatGPT側の設定

最初にプロフィールアイコンメニューから設定ページにアクセスします。


メニューからプラグインを選択します。画面の一番下にある開発者モードを選択します。


開発者モードをONに切り替えます。

開発者モードでCSPを適用するはオフのままで進められます。

CSPは Content Security Policy(コンテンツセキュリティポリシー) の略で、開発中のアプリがブラウザーからアクセスできる外部ドメインを制限する仕組みです。

・オフ:CSPを宣言していない開発用アプリは、外部ネットワークへ広くアクセス可能
・オン:本番環境と同じ制限付きの標準CSPを適用し、許可されていない通信や外部リソースをブロック

”これは主に、ChatGPT内に独自画面を表示するアプリ向けです。今回のSalesforce Hosted MCPは独自画面を持たないため、基本的には影響しません。初回設定では問題の切り分けを簡単にするため、CSPはオフのままで進めて大丈夫です。開発者モード本体だけオンにしてください。”とのことです。


開発者モードを有効化すると「作成」または「カスタムアプリを作成」というメニューが追加できるようになり、そこからChatGPT側のSalesforceと接続するためのアプリが作成できるようになります。


ただし、プランが対象外だったのでここから先の設定は確認できませんでした。ビジネス用で設定する際にはこのような手順でChatGPT側の設定を行い、コールバックURLに指定するURLの発行を行う流れとなりそうです。

Salesforce側のMCPサーバーの設定

設定メニューのMCP サーバーが有効化されていることを確認します。レコードを読み込むsobject-readsを有効化している状態にします。


次に外部クライアントアプリケーションの作成を行います。コールバックURL以外は前回の記事でPostmanと設定したときの流れと同じです。Postmanのときの設定は次のようになっていました。

設定タブ


ポリシータブ


今回は設定有効かまでは進められませんでしたが、設定操作の流れは確認できました。最後に開発者モードはオフに戻しておいて確認終了です。

参考情報

設定可能なプランについての情報はこちら。