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のときの設定は次のようになっていました。

設定タブ

ポリシータブ

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

参考情報

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

SFDC：MCP サーバーの設定を行いPostmanとの接続を試してみました

MCP サーバーの設定を行いPostmanとの接続を試してみました。

開発者ガイド

developer.salesforce.com

※ 設定の有効化
設定→インテグレーション→APIカタログ→MCPサーバーで設定ページにアクセスできます。Developer Edtionでも設定画面にアクセスできます。最初はすべて無効化の状態です。

一覧の中からsobject-readsを選んで詳細ページにアクセスします。

補足としてツールやプロンプトのタブはこのようになっていました。

右上の有効化ボタンから有効化できます。

これでSalesforce側のMCPサーバーの設定は準備OKです。

以下のように用途に合わせて有効化して利用の可否を管理できるようです。

有効化後に使用する大事な情報

サーバー URLのところは接続時に必要になる情報です。

Sandboxの場合は以下のようにsandboxという表記が追加されるみたいです。

https://api.salesforce.com/platform/mcp/v1/sandbox/platform/sobject-reads

外部クライアントアプリケーションの作成

まずは、接続できることを確認するためにPostmanとの接続を試します。外部クライアントアプリケーションを新規で作成します。

OAuth を有効化の設定を行います。ここにMCPサーバーへのアクセスが用意されています。リフレッシュトークンも必要です。

指名ユーザーの JSON Web トークン (JWT) ベースのアクセストークンを発行にチェックをつけて有効にします。他はチェック不要です。

作成ボタンをクリックして外部クライアントアプリケーション設定の作成完了です。

外部クライアントアプリケーションを作成するとコンシューマ鍵とコンシューマの秘密が取得可能になります。これでシステム連携に必要な情報が揃いました。

Postman側の設定

ワークスペースを作成します。

1. メニューをクリックしてMCPを選択します。

STDOと最初表示されているのでHTTPに変更します。

MCP設定時に表示されるURLを入力します。

Authorizationタブを選択します。Oahu 2.0を選びリクエストヘッダーが選ばれていることを確認します。

新しいトークンを作成します。

設定内容は次のとおり。外部クライアントアプリケーションのコンシューマ鍵は使いますが秘密の方は入力不要なのが注意点です。

画面の項目 設定値
Auth type OAuth 2.0
認可データの追加先 リクエストヘッダー
トークン名 Salesforce MCP DE ORG
Grant タイプ 認可コード（PKCE付き）
コールバック URL https://oauth.pstmn.io/v1/browser-callback
認可 URL https://login.salesforce.com/services/oauth2/authorize
アクセストークン URL https://login.salesforce.com/services/oauth2/token
clientId External Client AppのConsumer Key
クライアントシークレット 空欄
Scope mcp_api refresh_token
State 空欄
クライアント認証 リクエスト本文でクライアント認証情報を送信

新しいアクセストークンを取得をクリックします。

いつもの認証画面が表示されるので許可ボタンをクリック。

Use Toenボタンをクリックします。

これでひととおり準備OK。HTTPのURLを入力するところの右にある接続ボタンをクリックします。そうすると実行ボタンに切り替わります。Messageタブを選択すると、MCPの情報を使った操作ができると思います。

Query Records (SOQL)を選択し、適当なSOQLクエリを記載します。最後に実行ボタンをクリックします。これで取引先のデータのクエリが成功しました。

MCPの設定を有効化し、その情報を使ったデータ取得に成功しました。Postmanからの実行の場合はただ単にクエリ実行して終わりですが、実際にはCodexやClaudeなどの生成AIと連携することでAI × Salesforceの仕組みを構築することができます。

ちょっと気になるのが料金まわり。Developer Edtionで有効化できるので試して大丈夫だと思いますが、設定ページには気になるメッセージがありました。

接続がうまくいったので次はChatGPTあたりとの連携を試してみたいと思います。

設定ガイド

SFDC：CodexでLWCのVibeコーディングを試してみました

Codexを使ったVibeコーディングによるLWC開発を試してみました。過去にSalesforceのApex開発はプラットフォーム独自の開発言語なのでこうしたツールでの開発は難しいという話を聞いたことがあり、自分でもその認識だったのですが、AIエージェントはLWCやApexの開発についても正しく理解して対応してくれます。

環境構築

AIエージェントの開発にあたり、VSCodeでSalesforceプロジェクトを用意します。このプロジェクトとAIエージェントを紐つけることでメタデータファイルからSalesforceの設定情報を認識してくれるようになります。

AIエージェントとSalesforceプロジェクトの紐付けはCodexのデスクトップアプリの場合はこんな感じ。Claude CodeやGitHub Copilot、CLINEなどVSCode上でのターミナルや拡張機能で設定するやり方もあります。

また、AIエージェント用のSalesforceスキルがforcedotcomリポジトリで公開されているのでそちらをインストールするとApex開発の知識の理解度がより高まる感じです。

AIエージェントへのLWCの作成指示

”Vibeコーディングとは、AIに自然言語で「こんなものを作って」「ここを直して」と伝え、細かいコードを自分で書くよりも、生成・実行・修正のサイクルをAI中心で進める開発スタイルです。” となっておりざっくりした指示でも大丈夫です。今回は次のように指示を出しました。

取引先を作成するフォームのLWCを開発してください。

実際の開発ではここまでざっくりした指示は出しませんがとりあえず勉強用に動作するLightning Web Componentsを実装してほしい場合はこれで十分です。できあがったものを見ながらさらにやりたいことを相談していく形で進めていけます。

AIエージェント側で開発にあたり情報に不足があれば質問してくれるので、それに回答していけば実装が進められます。今回は、Salesforceプロジェクト内に既に開発されていた別の機能を参考に開発を進める判断をしてくれていました。指示を受けたAIエージェントの対応はこのようになりました。

だいたい5分ほどで開発してくれました。AIエージェントのルールに記載しておくことで、Code Analyzerや、ESLint、SLDS Linterのチェックを実行し、不適説な実装がないかも確認して品質を高めてくれます。Salesforce開発では動くけど書き方がめちゃくちゃでメンテナンスできないような実装にならないように構文チェックの仕組みがいろいろ用意されています。このあたりの環境構築もAIエージェントに相談すればいい感じで構築してくれます。

AIエージェントの開発基本ローカル上で動作チェックする形で進みます。なので開発完了となっていてもSalesforceの組織へのデプロイはまだの場合があります。次のように指示して、デプロイすることではじめてSalesforce側に反映されます。（デプロイの操作の際には意図せぬ接続先の組織に注意して進める必要があります。）

Codexが開発してくれた取引先作成フォームのLWCがこちら。ホームの画面に表示してという指示を出しました、空いているすべスペースに配置というのはAIエージェントの判断です。適切な判断をしてくれていると思います。また、LWCはSalesforce上で動作するように考えられて作られているのでCSSまわりを一から考えたりしなくてもSalesforceスタイルのUIで実装できます。

エラーチェックのやり方とかInputタグのものをそのまま使ったりしているのはもう少しSalesforceスタイルに寄せたいという感じ。その他細かい実装まわりは見直しポイント結構あると思います。それでも実際に動かすことができるものを作ってくれれば次のアクションが取りやすいです。

AIエージェントはルールやチャット指示する形でドキュメント作成まで任せることができます。プロジェクトのコードファイルの役割などはこうしたドキュメントを作成しておくと便利です。

その他のLWC開発

他にVibeコードで試してみたLWCについてです。Codexに指示を出すだけでこうした機能を形にしてくれました。

データボード

各オブジェクトのレコード件数を表示する機能。

クリックすると検索ページに切り替えるというような動作をするところまで開発してくれました。

ケース情報

ケースの取引先先責任者の情報を元に問い合わせ顧客のプロフィールを表示。取引先責任者と取引先に紐付く他のケースデータ一覧の表示。メールログの表示といったケースページをより見やすくできるLWC開発を任せるといったことができました。

大量レコードに対応するページネーションまわりの実装は複雑ですがApex開発のドキュメントを参照して適切に実現してくれます。

次のメールを読み込むボタンをクリックしたときの挙動です。メッセージが表示されて51件目以降のデータが新たに画面に表示されました。

Codexを使ったVibeコーディングによるLWC開発はこんな感じです。Salesforce独自の開発言語だからAIが理解できないというようなことはなく、適切な実装と不適切な実装を判断して開発を進めてくれます。

AIエージェントのモデルや種類によってはときどき間違った実装で突き進んでしまうことがあります。そのあたりは動作確認しながらルールの追加や指示の出し方の改善で対処していくといった付き合い方になるようです。

おまけ

開発してみたLWCの削除を依頼してみたときのCodexの対応。最初にいろいろチェックポイントを考えて検討が動きます。

最終的に必要な情報のみを整理して回答してくれます。

このように順番に変更作業が進んでいきます。

無事に削除完了です。

SFDC：Salesforce DXプロジェクト開発とAIエージェントのルールの設定方法

Salesforce DXプロジェクト開発とAIエージェントのルールの設定方法についてです。Salesforce DXプロジェクト開発用というよりはそれぞれのAIエージェントの製品ごとのルールの書き方の話です。

とりあえず調べてみたのは以下のAIエージェントとそのルールファイルです。

AIエージェント	主なルールファイル
Codex	AGENTS.md
Claude Code	CLAUDE.md
Gemini CLI	GEMINI.md
GitHub Copilot	.github/copilot-instructions.md
Cline	.clinerules/*.md

この形でAIエージェントに守らせたいルールを書くことができます。例えばCodexに守らせたいルールがあったので、AGENTS.mdにまとめました。「mainに直接コミットしない」「IssueやPR作成次にSalesforceユーザーIDなどは記載しない」とかそういう感じです。

AGENTS.mdはAIエージェントが最初に読み込むファイルで、それぞれの作業ごとのルールファイルは別に用意し、必要に応じて読み込みさせる使い方もできるようです。

主なルールファイルは各AIエージェントごとに分かれていますか全てのファイルに同じルールを書いていくのは現実的ではなさそうです。一番のメインをAGENTS.mdとし、他のAIエージェントのルールファイルはAGENTS.mdを参照するようなルールの指定の方法が通るようでした。

Claude Code

GitHub Copilot

CLINE

Gemini CLI

AIエージェントを後から追加する場合はこのような形で管理する使い方ができそうでした。本当にちゃんと読み込まれているか気になる部分もありますが、やりとりしている感じでは問題なく認識してそのとおりに作業してくれていそうでした。

けっこうルールを無視して動いてしまうときもあるのでGitのバージョン管理の組み合わせて意図せぬ変更をしていないか、この内容で問題ないかをチェックしながら使っていく形にはなりますが、ルールがあれば無い場合よりもおかしな挙動を防止できるので使いながら気になるところはルール追加していく流れとなります。

Agentforceのルールファイル

Agentforceのルールファイルは以下のような感じになるらしいです。今度ちゃんと確認してみる予定。

SFDC：SalesforceのVibeコーディング用スキルを試してみました

SalesforceのVibeコーディング用スキルを試してみました。GitHubのSalesforceのリポジトリ「forcedotcom」にある「sf-skills」をインストールする形で利用可能となります。

GitHub - forcedotcom/sf-skills: Salesforce's curated collection of agent skills for building applications. Optimized for Agentforce Vibes, compatible with all AI tools. · GitHub

使い方

Agentforce Vibesは自動で読み込みされるそうです。CodexなどのAIエージェントツールの場合は以下のコマンドでインストールします。

npx skills add forcedotcom/sf-skills

インストールまでの流れ

ターミナルからインストールコマンドを実行します。

Ok to proceed? (y) と確認メッセージが表示されるので、 y を入力します。すると画面が次のように表示されます。

一覧表示されているのはインストール対象とするスキルです。スペースキーを押すことで、インストール対象として選択できます。プロジェクトに不要なものは除外することもできますが、特にどちらでもよければいつ必要になってもいいように最初から全てを選択してインストールしておきます。

ちなみにわかりくいですが、 search のところは フィルタ機能です。特定名称で絞り込みができます。

全部選択したらエンターキーを押します。そうすると次にAdditional agentsという表示が出ます。

これはどのAIエージェントを対象にするかです。例えばClaude Codeを選択すると.claude/skillsの中にインストールできます。

 Additional agents ─────────────────────────────
│  Search:  
│  ↑↓ move, space select, enter confirm
│
│ ❯ ○ AiderDesk (.aider-desk/skills)
│   ○ AstrBot (data/skills)
│   ○ Autohand Code CLI (.autohand/skills)
│   ○ Augment (.augment/skills)
│   ○ IBM Bob (.bob/skills)
│   ○ Claude Code (.claude/skills)
│   ○ OpenClaw (skills)
│   ○ CodeArts Agent (.codeartsdoer/skills)
│  ↓ 47 more

デフォルトでは.agentsにインストールされます。そのため何も選択せずにエンターキーで次に進みます。

次に表示されるのはProjectとGlobalです。これはプロジェクト用にインストールするか、ユーザー環境全体にインストールするかです。Projectを選んで進めます。

Proceed with installation?と表示されます。これは指定した内容でインストールを実行するかの確認です。Yesを選んでエンターキーを押すインストール処理が実行されます。

これでインストールが実行されました。.agents/skillsという形でファイルが用意されます。

インストール後の使い方

スキルファイルはAIエージェントごとに配置場所が決まっていて、Codexの場合は.agentsにあると自動で読み取ってくれます。そのため、スキルをつかうなどの指示は不要でやりたいことを依頼するだけです。

コーディング知識だけでなく、開発者ガイドの参照などのWeb上のドキュメントチェックのスキルも用意されていました。

主な用途はApex開発だと思います。開発系のスキルも用意されています。

スキルのインストールがなくてもAIエージェントはSalesforce開発の知見を十分持っているようでした。ただ、スキルがあることでその知識の精度がより高くなる..的な効果が得られると思います。

スキルのGit管理

外部からインストールしたスキルファイルはGit管理に含めずローカル上で各開発者ごとにインストールする管理が良いという考え方があるみたいです。

いまのところ、その管理の方法が良さそうに思えます。ただし、バイブコーディング中にAIエージェントがスキルファイルの中身をこちらの指示なく上書きする動作に遭遇したことがあります。

Git管理していない場合、意図せぬ上書きをされても気づけないのでAIエージェントのルールにスキルファイルを上書きしないこと。参照のみといったルールを追加しておくと安心です。