ローコードメディア 業務効率を、もっと簡単に、もっと手軽に。ローコード専門メディア

注目キーワード

Salesforce CLI 中級編 – Agentforce 時代の AI 駆動開発入門

Salesforce CLI 中級編 – Agentforce 時代の AI 駆動開発入門

皆さんこんにちは、Salesforceエンジニアの森川です。
今回はSalesforce CLI 中級編です。
Salesforce CLI はいま、単なるコマンドラインツールから AI エージェント開発の中核基盤 へと変貌しつつあります。Agentforce DX の GA（一般提供）、Salesforce DX MCP Server の公開、Agentforce Vibes の急速な進化──2025〜2026 年にかけて起きたこれらの変化は、Salesforce 開発者の日常ワークフローを根本から変えようとしています。
本記事は三部作の中級編として、CLI の基礎を一通り身につけた読者が AI 支援ツールと Agentforce DX を実際に使い始める ための橋渡しを目的としています。初級編で扱ったデプロイやメタデータ操作の基本は前提知識とし、ここでは「なぜ今 AI なのか」という背景から始めて、Agentforce DX の最初のエージェント作成、Claude Code と DX MCP のセットアップ、Agentforce Vibes の実践的な活用法までを段階的に解説します。上級編では Agent Script 言語や 15 コマンド体系の深掘り、Claude API の統合パターン、CI/CD への AI 組み込みといった実践的な応用に進みます。

目次

この記事のポイント

  • Salesforce × Anthropic 提携の背景 – Claude が Agentforce の推論エンジンとして統合された経緯と、開発者にとっての 3 つの接点を整理します。
  • Agentforce メタデータの扱い方 – エージェント固有のメタデータタイプや依存関係の特徴を、通常の開発との違いに焦点を当てて紹介します。
  • Agentforce DX 入門 – agent-spec 生成からエージェント作成、テスト、プレビューまでの基本フローをハンズオン形式で解説します。
  • Claude Code + DX MCP の導入 – セットアップ手順と基本操作、ガバナンスルールを示します。
  • Agentforce Vibes の活用 – Plan / Act / Deep Planning の 3 モードと /test コマンドの使い方を具体的に紹介します。
  • AI 支援を組み込んだ開発ワークフロー – CLI・Claude Code・Vibes を統合した開発フローの全体像を描きます。

はじめに – なぜ今、Salesforce 開発者に AI が必要なのか

Salesforce と Anthropic の戦略的パートナーシップ

2025 年の Dreamforce で、Salesforce と Anthropic は戦略的パートナーシップの拡大を発表しました。この提携により、Anthropic の Claude は Salesforce のトラストバウンダリ内に完全統合された初の外部 LLM プロバイダ として位置づけられています。データが Salesforce の VPC から外に出ることなく、モデルトレーニングにも使用されないという安全性が確保されている点が、エンタープライズ利用における最大の特徴です。

この提携は開発者にとって、大きく 3 つの接点を生み出しました。第一に、Agentforce の推論エンジンとしての Claude（Setup 画面から選択可能）。第二に、Claude Code + Salesforce DX MCP によるローカル開発支援。第三に、Agentforce Vibes による VS Code 上での AI 支援開発です。

中級編ではこの第二・第三の接点──つまり 開発者が日常的に使うツールとしての Claude と Vibes にフォーカスします。第一の接点に関する詳細（AWS-Hosted オプションの設定手順、BYO LLM による Einstein Studio 統合、Einstein Requests の消費最適化など）は上級編で扱います。

CLI の進化の全体像──Agentforce DX の道のり

Salesforce CLI の進化を振り返ると、2024 年春に Ant Migration Tool が非推奨となり、sf CLI への移行が加速しました。2025 年にかけて Agentforce DX のベータ版がリリースされ、同年 5 月に @salesforce/plugin-agent が GA（一般提供）となりました。同時期に Salesforce DX MCP Server が公開され、2025 年末には Agentforce Vibes と AI 拡張が提供されています。その後も進化は続き、Winter ’26 では agent activate/deactivate や agent preview が追加され、Spring ’26（2026 年 2 月）では Agent Script 言語のベータ導入と Authoring Bundle ワークフローの確立という大きな転換点を迎えました。

こうした背景を踏まえ、本記事では CLI を使った AI 駆動開発の入り口を体系的に案内します。

1. Agentforce メタデータの特徴と開発の前提知識

初級編で学んだデプロイやテストの基本は、Agentforce 開発でもそのまま活きます。ただし、エージェント関連のメタデータには通常のカスタムオブジェクトやフローとは異なる特徴があり、知らずに扱うとつまずきやすいポイントがあります。ここでは、Agentforce 開発を始める前に押さえておくべきメタデータの特徴を整理します。

エージェント固有のメタデータタイプ

Agentforce では、GenAiPlanner（エージェント定義）、GenAiPlugin（トピック）、GenAiFunction（アクション）、AiEvaluationDefinition（テスト定義）など、従来の Salesforce 開発では馴染みのないメタデータタイプが登場します。これらは sf project deploy start で通常のメタデータと同様にデプロイできますが、相互の依存関係が複雑です。

たとえば、エージェント定義（GenAiPlanner）はトピック（GenAiPlugin）を参照し、トピックはアクション（GenAiFunction）を参照し、アクションはフローや Apex クラスを参照します。この多段階の依存関係のため、manifest にエージェント定義だけを含めてデプロイしようとすると、参照先のトピックやアクションが見つからずエラーになります。

manifest 設計のコツ──エージェント専用ファイルを分ける

エージェント関連のメタデータは、他の機能（承認フロー、レポートなど）とは別の manifest ファイルで管理することを推奨します。たとえば manifest/agent.xml に GenAiPlanner、GenAiPlugin、GenAiFunction、AiEvaluationDefinition と、それらが参照する Flow や Apex クラスをまとめて記述します。こうすることで、エージェント機能だけを独立してデプロイ・ロールバックでき、他の機能への影響を最小限に抑えられます。

統合ロジックテスト──エージェントが依存する Apex と Flow をまとめて検証する

エージェントは内部的に Flow や Apex を呼び出すことが多いため、エージェントをデプロイする前に関連するロジックが正常に動作するか確認する必要があります。Spring ’26 で導入された sf logic run test は、Apex テストと Flow テストを単一のコマンドで実行できるベータ機能で、この用途に最適です。

bash

# Apex と Flow の両方を同期実行し、JUnit 形式でカバレッジ付き出力
sf logic run test --test-level RunLocalTests \
  --test-category Apex --test-category Flow \
  --synchronous --result-format junit \
  --output-dir test-results --code-coverage

CI/CD パイプラインにこのコマンドを組み込むことで、「エージェントをデプロイしたら関連フローが壊れていた」という事態を防げます。非同期実行した場合は sf logic get test --test-run-id <ID> で結果を取得します。

エージェント公開用サイトの生成

エージェントを外部ユーザーに公開する場合、Experience Cloud サイトが必要になります。Spring ’26 で追加された sf template generate digital-experience site を使えば、LWR ベースのサイトテンプレートをコマンド一つで生成できます。

bash

sf template generate digital-experience site \
  --template BuildYourOwnLWR \
  --name "agent-portal" \
  --url-path-prefix "support" \
  --output-dir force-app/main/default

生成されたメタデータ（DigitalExperienceConfig、Network 等）は manifest に追加するまでデプロイ対象になりません。エージェント定義と合わせて agent-portal.xml のような専用 manifest で管理すると、サイトとエージェントをセットでデプロイ・ロールバックできます。

2. Agentforce DX で初めてのエージェントを作る

Agentforce DX は 2025 年にベータ版としてリリースされ、同年 5 月に @salesforce/plugin-agent が GA となったプロコード向けのエージェント開発ツールです。その後も機能追加が続き、2026 年 2 月の Spring ’26 では Agent Script 言語の導入と Authoring Bundle ワークフローの確立により、開発体験が大きく進化しています。VS Code と CLI を組み合わせて、エージェントの構築・テスト・プレビューをローカル環境で完結できるように設計されています。

@salesforce/plugin-agent プラグインは sf CLI の JIT（Just-In-Time）プラグインとして提供されており、初回の sf agent コマンド実行時に自動的にインストールされます。ここでは最小構成で「エージェントを作成→テスト→プレビュー」する流れを step-by-step で解説します。

Step 1：エージェント仕様の生成

最初に sf agent generate agent-spec コマンドでエージェントの仕様（YAML ファイル）を生成します。このコマンドは会社情報やエージェントの役割、トーンなどをパラメータとして受け取り、エージェントの設計書にあたるファイルを出力します。

bash

sf agent generate agent-spec \
  --type customer \
  --role "カスタマーサポート担当" \
  --company-name "Acme Corp" \
  --company-website "https://acme.example.com" \
  --max-topics 3 \
  --tone formal \
  --output-dir specs/

--type には customer（外部向け）と internal（社内向け）の 2 種類があります。--max-topics はエージェントが扱うトピック数の上限で、最初は 3〜5 程度に絞ることを推奨します。--full-interview フラグを使えば、対話形式ですべてのパラメータを順に入力することもできます。

生成された YAML ファイルはプロジェクトの specs/ ディレクトリに保存され、バージョン管理の対象とします。このファイルがエージェントの「設計書」となり、以降のステップで参照されます。

Step 2：エージェントの作成

仕様ファイルからエージェントを Org に作成します。

bash

sf agent create \
  --spec specs/agentSpec.yaml \
  --target-org my-scratch

このコマンドは仕様に基づいてエージェント定義、トピック、アクションといったメタデータを Org に生成します。作成されたエージェントは Setup の Agentforce Agents ページから確認できます。

なお、Spring ’26 以降では Agent Script という新しい言語による Authoring Bundle ワークフロー（generate authoring-bundle → validate → publish）も提供されていますが、これは上級編で扱います。中級者はまず agent create による基本的な作成フローを押さえてください。

Step 3：テストの作成と実行

エージェントの動作を検証するために、テスト仕様を作成し実行します。テスト仕様には「発話（Utterance）」「期待されるトピック」「期待されるアクション」「期待される結果」を定義します。

bash

# テスト仕様の生成（対話形式）
sf agent generate test-spec --output-dir specs/

# Org にテスト定義をデプロイ
sf agent test create --spec specs/testSpec.yaml --target-org my-scratch

# テストの実行（最大 10 分待機、JUnit 出力）
sf agent test run \
  --api-name My_Agent_Test \
  --target-org my-scratch \
  --wait 10 \
  --result-format junit \
  --output-dir test-results

テスト仕様の YAML では、各テストケースに対して発話内容と期待結果を自然言語で記述します。たとえば「注文のステータスを教えて」という発話に対して「OrderStatusTopic が選択され、GetOrderStatus アクションが実行される」ことを期待値として定義します。--verbose フラグを追加すると、実行された Apex クラスやフロー、アクセスされたオブジェクトなどの詳細が確認できます。

テスト定義は AiEvaluationDefinition というメタデータタイプとして Org に保存されるため、sf project deploy start で通常のメタデータと同様にデプロイ・バージョン管理が可能です。

Step 4：CLI でのプレビュー

作成したエージェントの動作を CLI 上で対話的に確認します。

bash

sf agent preview \
  --name My_Support_Agent \
  --target-org my-scratch

プレビューにはシミュレーションモード（デフォルト）とライブモードの 2 種類があります。シミュレーションモードでは AI がアクションの結果を模倣するため、外部サービスへの実際の接続は不要です。--use-live-actions フラグを付けると本番相当の動作を確認できますが、Data Cloud や外部 API への接続が必要になります。

プレビューコマンドはスクリプトからも呼び出せるため、CI/CD パイプラインに組み込んで回帰テストを自動化することも可能です。具体的な CI/CD 統合パターンは上級編で扱います。

3. Claude Code + Salesforce DX MCP で開発を加速する

DX MCP とは何か

Salesforce DX MCP Server は、2025 年 5 月に Salesforce Developer Experience チームが公開した MCP（Model Context Protocol）サーバーの実装です。MCP は Anthropic が策定したオープンスタンダードで、AI アプリケーションとツール・データソースを標準的な方法で接続するためのプロトコルです。USB-C がデバイス接続を標準化したように、MCP は AI とツールの接続を標準化します。

DX MCP Server の設計思想について、Salesforce の公式ブログでは重要な点が強調されています。このサーバーは CLI コマンドの単純なラッパーではなく、開発者の成果（outcome）にフォーカスした設計 になっているということです。つまり、AI エージェントが CLI のシンタックスやフラグを逆引きする必要がなく、「メタデータを取得したい」「テストを実行したい」といった意図をそのまま実行できます。

実際の開発では、Claude Code が古い sfdx コマンドや存在しないフラグをハルシネーション（幻覚）するという問題が以前からありました。DX MCP を通じることで、Claude Code は正確で最新の sf CLI コマンドを使用するようになり、この問題が大幅に軽減されます。

セットアップ手順

DX MCP の導入に必要な前提条件は、Node.js 18 以上、sf CLI（認証済み Org あり）、Claude Code のインストールです。Claude Code は npm install -g @anthropic-ai/claude-code でグローバルにインストールします。

設定はプロジェクトルートに .mcp.json ファイルを作成するだけで完了します。この設定方法は VS Code、IntelliJ、Cursor、Cline、Windsurf など主要な IDE で共通です。

json

{
  "mcpServers": {
    "salesforce DX": {
      "command": "npx",
      "args": [
        "-y", "@salesforce/mcp",
        "--orgs", "DEFAULT_TARGET_ORG",
        "--toolsets", "orgs,metadata,data"
      ],
      "env": {}
    }
  }
}

--orgs フラグではアクセスを許可する Org を指定します。DEFAULT_TARGET_ORG はプロジェクトのデフォルト Org を使う設定で、最も安全な選択です。ALL を指定するとすべての認証済み Org にアクセスできますが、本番環境への意図しない操作を防ぐため注意が必要です。

--toolsets フラグではどのツール群を有効にするかを選択します。DX MCP Server は 60 以上のツールを内包しており、all で全有効化できますが、LLM のコンテキストが膨らむため、実際に使うツールセットだけを指定することが推奨されています。主なツールセットは以下のとおりです。

  • orgs – Org の一覧表示、接続確認
  • metadata – メタデータのデプロイ・取得
  • data – SOQL クエリ、レコード操作
  • users – 権限セット割り当て
  • testing – Apex テスト実行
  • code-analyzer – 静的コード解析
  • aura-migration – Aura コンポーネント分析と LWC 移行

設定ファイル保存後、Claude Code を起動して /mcp と入力すると、接続されたサーバーの状態を確認できます。

基本的な使い方

DX MCP を介した Claude Code の操作は、自然言語でやりたいことを伝える だけです。

「デフォルト Org に接続されているか確認して」と指示すれば、Claude Code は内部的に sf-list-all-orgs ツールを呼び出し、認証状態を返します。「Account オブジェクトのメタデータを取得して」と指示すれば sf-retrieve-metadata が実行されます。「force-app ディレクトリのソースをデプロイして」と言えば sf-deploy-metadata が走ります。

より実践的なユースケースとしては、たとえば新しい Apex クラスを書いた後に「このクラスのテストを実行して結果を教えて」と指示すれば、DX MCP の run_apex_test ツールが呼び出され、テスト結果がそのまま返ってきます。「Account の最近のレコードを 5 件クエリして」と言えば SOQL が実行されます。

また、Claude Code 自身のコード生成能力と組み合わせることで、「Contact に新しいカスタム項目 Preferred_Language__c を作成して、Sandbox にデプロイして」という一連の作業を自然言語の指示だけで完結させることも可能です。Claude Code がメタデータ XML を生成し、DX MCP を通じてデプロイまで実行します。

ガバナンスルール──AI にやらせていいことの境界

AI による開発支援は強力ですが、無制限に任せてはいけません。以下のガバナンスルールをチームで明文化しておくことを強く推奨します。

第一に、デプロイ先の制限 です。AI が生成・デプロイするメタデータの先は Developer Sandbox または Scratch Org に限定し、本番環境や Full Sandbox への直接デプロイは人間による承認を必須とします。

第二に、レビューの義務化 です。AI が生成したコードは必ず人間がレビューします。特に Apex ではガバナーリミット準拠、CRUD/FLS セキュリティ、null チェック、バルク処理対応の確認が不可欠です。Claude Code は存在しないフィールド名や、Apex にない型（HashMap、ArrayList など）をハルシネーションすることがあります。

第三に、機密データの保護 です。MCP を通じてクエリ可能な範囲に個人情報や機密データが含まれる場合、--orgs フラグで対象 Org を限定し、--toolsets で data ツールセットを除外するなどの制御を行います。

プロジェクトルートに CLAUDE.md というファイルを配置すると、Claude Code の動作ルールを定義できます。たとえば「本番 Org へのデプロイコマンドは実行しない」「テストクラスなしの Apex クラスは作成しない」「命名規則は〇〇に従う」といったルールを記述しておけば、Claude Code がそれに準拠した動作をします。

4. Agentforce Vibes で開発を加速する

Agentforce Vibes とは

Agentforce Vibes（旧 Einstein for Developers）は、Salesforce が提供する AI 駆動の開発支援ツールです。VS Code 拡張（Salesforce Extension Pack (Expanded)）またはクラウド IDE の Code Builder として利用でき、Apex・LWC・Flow のコード生成、テスト作成、リファクタリング、実装計画を支援します。

Vibes の技術的な特徴として最も重要なのは、MCP（Model Context Protocol）を基盤アーキテクチャとして採用している点です。これにより、単一の AI モデルに依存せず、xGen（Salesforce 独自モデル）、GPT-5、Claude 4、Gemini 2.5 といった複数のモデルを切り替えて利用できます。DX MCP Server がデフォルトで組み込まれているため、Vibes は Org のメタデータ、スキーマ、既存コードを認識した上でコードを生成します。汎用の AI コーディングツールとの最大の違いは、この Salesforce コンテキストの理解にあります。

インストールと基本設定

VS Code をお使いの場合は、Extensions マーケットプレイスから Salesforce Extension Pack (Expanded) をインストールし、Org を認証するだけで使い始められます。Code Builder をお使いの場合は拡張機能がプリインストールされています。

VS Code ではデフォルトで MCP サーバーが無効になっているため、左サイドバーの Agentforce アイコンからパネルを開き、MCP Tools で Salesforce DX MCP Server を有効化する必要があります。設定ファイル（a4d_mcp_settings.json）をカスタマイズすることで、有効にするツールセットを細かく制御できます。ただし、同時に動作するツールは約 20 が上限とされているため、作業内容に応じて適切なツールを選択してください。

3 つのモード──Plan / Act / Deep Planning

Vibes は 3 つのモード を提供しており、タスクの性質に応じて使い分けます。これが汎用 AI ツールにはない Vibes 固有の強みです。

Plan モード は、実行前にタスクを構造化し、手順を整理するモードです。要件がまだ確定していない段階や、複数のステークホルダーによるレビューが必要な場合に使います。たとえば「Account オブジェクトに新しいバリデーションルールを追加したい。既存のルールとの整合性を確認してから計画を立てて」と指示すると、Vibes は既存のバリデーションルールを走査し、競合の可能性を分析した上で、実装手順の概要を提示します。コードの生成や Org への変更は行いません。

Act モード は、要件が明確で即座に実行したい場合のモードです。計画フェーズをスキップし、直接コード生成や修正に入ります。「この Apex クラスにバルク処理対応の update メソッドを追加して」のような、スコープが明確なタスクに向いています。

Deep Planning モード は、複雑な機能実装に対して最も威力を発揮するモードです。Salesforce の公式ドキュメントによれば、このモードは 4 つのステップで動作します。

  1. 調査（Investigation） – Vibes がプロジェクト全体を静かに走査します。Apex クラス、トリガー、LWC、カスタムオブジェクト、バリデーションルール、自動化パターン、テストカバレッジの状況、設定ファイルなどを網羅的に分析します。この間、Vibes は質問や解説なしに黙々と調査を進めます。
  2. 要件の明確化（Clarification） – 調査結果に基づいて、Vibes が的確な質問を投げかけます。曖昧な要件の確認、複数の実装アプローチ間の選択、既存システムの動作に関する前提確認などです。回答は実装計画に直接影響するため、丁寧に答えることが重要です。
  3. 計画の生成（Planning） – 具体的なファイルパス、メソッドシグネチャ、実装順序を含む詳細な実装計画ドキュメントが生成されます。概要・データ型定義・ファイルマッピング・関数詳細・Apex パターン（FLS チェック、例外処理など）・依存関係・テスト要件・実装順序といったセクションで構成されます。
  4. タスクの作成（Task Creation） – 計画ドキュメントを参照する追跡可能なタスクが作成されます。各ステップの完了状況がリアルタイムで表示され、進捗を可視化できます。

Deep Planning は推論能力の高いモデル（GPT-5、Claude 4、Gemini 2.5 など）で最も効果を発揮します。小規模なモデルでは包括的な分析が難しいとされています。

/test コマンドによるテスト生成

Vibes のチャットパネルで /test スラッシュコマンドを使うと、開いている Apex クラスに対応するユニットテストを自然言語から自動生成 できます。

たとえば、AccountService.cls を開いた状態で /test このクラスの主要メソッドのテストを作成して。正常系・異常系・バルク処理のケースを含めて と入力すると、Vibes が Org のスキーマ情報を認識した上で、必須フィールドやデータ型に適合したテストデータを含む Apex テストクラスを生成します。

同様に /test は LWC テストの生成にも対応しています。LWC コンポーネントを開いた状態で実行すると、Jest テストが生成されます。

制限事項と付き合い方

Vibes を使う上で知っておくべき制限があります。

まず、リクエスト制限 です。Pro モデル（GPT-5 等の高性能モデル）は 1 日あたり 50 リクエスト/Org が上限です。複雑なタスクでは 1 つの会話で 4〜5 リクエストを消費することがあるため、Deep Planning は本当に必要な場面に絞って使い、単純な作業は Act モードで効率的にこなすのが賢い使い方です。制限に達すると Core（SFR）モデルにフォールバックしますが、性能差は体感できるレベルです。

次に、ハルシネーション です。Vibes も汎用 AI と同様に、存在しないフィールドの参照、誤った API バージョンの指定、コンパイルは通るが期待と異なる動作をする Apex コードを生成することがあります。特にドメイン固有のビジネスロジック（料金計算、コンプライアンスルールなど）については、AI が 60% 程度しかカバーできないという報告もあります。コードレビューは省略できません。

最後に、Focus Chain という機能についてです。Vibes のバージョン 3.3.0 以降で導入されたこの機能は、長い対話や中断したタスクの状態を保持し続けることを可能にします。さらにコンテキストウィンドウを手動でコンパクト化する機能もあり、大規模プロジェクトでのメモリ管理に役立ちます。作業が長時間に及ぶ場合は、Focus Chain を活用して文脈を維持しましょう。

5. AI 支援を組み込んだ開発ワークフロー

ここまで紹介した CLI 基礎、Agentforce DX、Claude Code + DX MCP、Agentforce Vibes を統合すると、従来の手動中心のワークフローから AI 駆動のワークフローへ移行できます。ここでは実務での運用を想定した全体像を示します。

フェーズ 1：設計と計画

機能要件が決まったら、Agentforce Vibes の Deep Planning モード で実装計画を立てます。Vibes がプロジェクトを走査し、既存コードとの整合性を確認した上で、ファイル単位の実装計画を生成します。これをチーム内でレビューし、計画に問題がなければ開発に進みます。

エージェント機能の場合は、sf agent generate agent-spec で仕様 YAML を生成し、これもレビュー対象とします。仕様 YAML と Vibes の実装計画の両方がバージョン管理下に入ることで、「なぜこの設計にしたか」のトレーサビリティが確保されます。

フェーズ 2：開発

日常的なコーディングは Vibes の Act モード と Claude Code + DX MCP を併用します。

Vibes は Salesforce コンテキストを活かした Apex・LWC の生成に強みがあり、/test コマンドでテストも同時に作成できます。Claude Code + DX MCP はメタデータ操作やデプロイの自動化に強みがあり、「この項目を作成して Sandbox にデプロイして」といった一連の作業を自然言語で完結できます。

それぞれの得意領域を使い分けるのがポイントです。Org のスキーマを活かしたコード生成は Vibes に、プロジェクト横断的なメタデータ操作とデプロイは Claude Code に任せるという棲み分けが効果的です。

フェーズ 3：テストと検証

テストは複数のレイヤーで実施します。

Apex・Flow の単体テストは sf logic run test でまとめて実行します。エージェントの動作テストは sf agent test run で、テスト仕様に基づく自動評価を行います。プレビューによる手動検証は sf agent preview で実施し、シミュレーションモードで素早く確認した後、必要に応じてライブモードで本番相当のテストを行います。

すべてのテスト結果は JUnit 形式で出力し、CI/CD ツール（GitHub Actions、GitLab CI など）で可視化できるようにしておきます。

フェーズ 4：レビューとデプロイ

プルリクエスト作成時に、Vibes のデフォルトルール（LWC・Apex のベストプラクティス）で自動スキャンを実行します。SLDS 2 CLI Linter を併用すれば、Lightning Design System への準拠も自動チェックできます。

Claude Code を使ったレビュー支援も有効です。CLAUDE.md にチームの命名規則やセキュリティ要件を定義しておけば、PR の差分に対してルールに基づいたレビューコメントを自動生成できます。ただし、AI のレビューはあくまで補助であり、最終判断は人間が行います。

デプロイは sf project deploy start --manifest で機能単位の manifest を指定して実行します。事前に --dry-run で検証し、問題がなければ本番へ反映します。

ワークフロー全体を貫く原則

このワークフローを成功させるために、3 つの原則を意識してください。

AI は補助者であり、責任は人間が負う ──これはすべてのフェーズに共通する大前提です。AI が生成したコード、計画、レビューコメントのいずれも、最終的な判断と責任は開発者にあります。

Sandbox ファーストの運用 ── AI が生成・デプロイするメタデータの先は常に Sandbox または Scratch Org です。本番環境へのデプロイは必ず人間の承認プロセスを経由します。

すべてをバージョン管理に入れる ── エージェント仕様 YAML、テスト仕様、CLAUDE.md、.mcp.json を含むすべての設定ファイルをリポジトリで管理します。これにより、チーム全員が同じルールとツール設定で開発でき、再現性が担保されます。

まとめ

本記事では、Salesforce CLI 中級編として、Agentforce 時代の AI 駆動開発の入口を体系的に解説しました。

まず Salesforce と Anthropic の戦略的提携の背景を理解し、開発者にとっての 3 つの接点を整理しました。次に、Agentforce メタデータ固有の特徴と統合ロジックテストを確認し、Agentforce DX による最初のエージェント作成フロー（仕様生成→作成→テスト→プレビュー）を実践しました。Claude Code + DX MCP のセットアップでは、.mcp.json の設定からガバナンスルールまでを扱い、Agentforce Vibes では Plan / Act / Deep Planning の 3 モードと /test コマンドの具体的な使い方を示しました。最後に、これらを統合した AI 支援開発ワークフローの全体像を提示しました。

上級編では、ここで築いた基礎の上にさらに進みます。Agent Script 言語による宣言的エージェント開発、plugin-agent の全 15 コマンド体系、Anthropic Claude の BYO LLM 統合パターン、MCP の双方向連携、そして CI/CD パイプラインに claude-code-action を組み込んだ自動レビュー体制の構築まで、実践的な応用を深掘りします。

Salesforce CLI はもはやコマンドの集まりではなく、AI エージェント開発を支える 戦略的プラットフォーム です。まずは本記事の内容を手元の Scratch Org で試し、AI 支援開発の感覚を掴んでください。その経験が、上級編の高度なトピックを理解するための確かな土台になります。

本記事は三部作の中級編として、CLI の基礎から AI 駆動開発への橋渡しを担いました。

初級編 では、CLI の基本操作と GUI との使い分け、最初に覚えるべき 11 コマンド、Claude Code によるコマンド生成の入口を学びました。中級編の前提となる認証・デプロイ・テストの基礎体力がここで身につきます。

中級編（本記事） では、Agentforce DX で初めてのエージェントを作成し、Claude Code + DX MCP のセットアップと Agentforce Vibes の Plan / Act / Deep Planning モードを実践しました。CLI の基本コマンドが AI ツールとの連携でどう活きるかを体感できたはずです。

上級編 では、ここで築いた基礎の上にさらに進みます。Agent Script 言語による宣言的エージェント開発、plugin-agent の全 15 コマンド体系、Anthropic Claude の BYO LLM 統合パターンと MCP 双方向連携、そして CI/CD パイプラインに claude-code-action を組み込んだ自動レビュー体制の構築まで、実践的な応用を深掘りします。

お問い合わせ

現在Salesforceを効果的に活用できていない企業様や、これからSalesforceの導入を検討している企業様で、設定や運用、保守に関するサポートが必要な場合は、ぜひお気軽にご相談くださいませ！

    お問い合わせ目的

    Uncategorizedカテゴリの最新記事