※本記事は2026年6月24日に米国で公開された Master the Agentic Development Lifecycle for Agentforceの抄訳です。本記事の正式言語は英語であり、その内容および解釈については英語が優先されます。
Agentforce（英語）を使った開発が、1回の作業で完結することはほとんどありません。AIエージェントの構成は、データモデル、アクション（FlowまたはApex）、AIエージェントの定義、権限にまで及ぶこともあります。各要素にそれぞれの設定画面があるため、クリック操作とはいえ、すべてを連携させるには時間がかかります。Salesforce Headless 360（英語）によって、こうした機能がすべて、アプリケーションプログラミングインターフェース（API）、Model Context Protocol（MCP）ツール、またはコマンドラインインターフェース（CLI）コマンドから利用できるようになりました。コーディングエージェントがプラットフォーム全体にアクセスできるため、開発者の意図をくみ取り、作業の大部分を担うことができます。これにより、AIエージェントを活用した新しい開発が可能になります。
Salesforce開発者の多くは、AIエージェントの開発に、設計ファーストで繰り返し実践できるライフサイクルを求めています。Headless 360のアプローチでは、Claude Code、Codex、Agentforce Vibes（英語）などのコーディングエージェントとエージェントスキル（英語）を組み合わせることで、自然言語による会話で設計、構築、デプロイ、テスト、デバッグを行えます。開発者が設計を主導し、実際の開発はコーディングエージェントが担当します。
この記事では、Salesforceエージェントスキルの設定、プロジェクトのひな型作成と組織への接続、構築前の設計、メタデータの生成、検証とテスト、トレースを使用したデバッグの方法を見ていきます。ここで取り上げる内容はすべて、オープンソースのSalesforceスキルライブラリ（英語）とSalesforce CLIを使って実践できます。
エージェントスキルを使って、コーディングエージェントにSalesforceを教える
エージェントスキルを使うと、コーディングアシスタントにSalesforceについて学習させることができます。スキルとは、ApexクラスやLightning Webコンポーネント（LWC）の構築、フローの構築、Agentforceエージェントの開発など、特定のタスクをアシスタントに教えるための指示とコマンドをまとめた、小さなパッケージです。スキルがなければ、アシスタントは推測に頼ります。スキルを利用すれば、適切な手順を踏み、必要なCLIコマンドやMCPツールを実行して、規約に従います。
Agentforce Vibes以外のコーディングエージェントでこれらのスキルを使用する場合は、グローバルまたはプロジェクトディレクトリ内にインストールしてください。Agentforce Vibesには、スキルがデフォルトで含まれています。Salesforceスキルライブラリには、Apex、LWC、Agentforce、Data 360、メタデータのデプロイに対応する数十種類のスキルが用意されています。
エージェントライフサイクルの中核を担うのは、次の3つのスキルです。
developing-agentforce– 設計、構築、デプロイ、デバッグ（ドキュメント（英語）を参照）testing-agentforce– テスト仕様の作成とバッチテストの実行（ドキュメント（英語）を参照）observing-agentforce– Data 360に保存された本番環境のトレースを調査（ドキュメント（英語）を参照）
インストールすると、ほとんどのコーディングエージェントでは、アシスタントに「/」と入力してスキルの一覧を確認できます。アシスタントが作業する際には、読み込まれたスキルが名前で表示されます。たとえば、エージェントのひな型作成を依頼すると、その時点でdeveloping-agentforceが有効になります。
また、事前にNode.jsとSalesforce CLIをマシンに用意しておく必要があります。不足しているものがある場合は、アシスタントにサポートを依頼できます。アシスタントに権限があれば、これらのツールをインストールさせることもできます。
Salesforceエージェントスキルをインストールするには、以下のコマンドをターミナルで実行するか、アシスタントに実行するよう依頼します。
1npx skills add forcedotcom/sf-skillsコマンドを実行したら、画面の案内に沿って、いくつかの設定項目を選択します。まず、ライブラリからアシスタントに組み込むスキルを選択します。次に、使用するコーディングエージェントを指定し、これらのスキルをすべてのプロジェクトで利用するか、現在のローカルディレクトリだけで利用するかを選択します。
プロジェクトのひな型を作成し、組織に接続する
すべてのSalesforceプロジェクトは、メタデータをファイルとして格納する基本的なフォルダー構造を作成するところから始まります。これは、普段Visual Studio Codeなどの統合開発環境（IDE）に取り込んでいるものと同じプロジェクト構造です。アシスタントはそれらのローカルファイルを操作し、その後、組織にデプロイします。
ここからが、これまでと違うところです。もうCLIフラグを覚えたり、コマンドの構文を調べたりする必要はありません。やりたいことを普通の言葉で説明するだけで、コーディングエージェントが適切なSalesforce CLIコマンドを実行してくれます。実際の処理を行うのはCLIですが、AIエージェントがどのコマンドを呼び出せばよいかを判断し、開発者の指示をコマンドに変換します。
たとえば、これまではプロジェクトを作成するために、正確なコマンドとフラグを入力する必要がありました。
1sf project generate --name agent-script-demoこれからは、次のように目的を自然言語で説明すれば、AIエージェントがそのコマンドを代わりに実行します。
「agent-script-demoという名前でSalesforceプロジェクトを作成してください」
AIエージェントが対象外のファイルを操作しないよう、プロジェクトごとにフォルダーを分けてください。その後の各ステップも同じ流れで進みます。たとえば、組織の設定を依頼すると、AIエージェントは現在のデフォルト組織を確認し、以下のコマンドを使用して、スクラッチ組織またはSandboxをこのプロジェクトのデフォルトとして設定します。
1sf config get target-org --json
2sf config set target-org agent-build --jsonコーディングエージェントに、デフォルト組織を開いてもらうこともできます。コーディングエージェントは以下のコマンドを使用して組織を開きます。
1sf org openベストプラクティスは、開発はスクラッチ組織やSandboxで行い、AIエージェントには本番環境へのアクセスを一切許可しないことです。また、パスワードなどの機密情報をプロンプトに貼り付けないでください。アシスタントを使用しない別のターミナルを開いておくと便利です。こうすることで、慎重に扱う必要があるコマンドは自分でコピーして編集し、実行できます。
構築する前に設計を固める
これが、ライフサイクル全体で最も重要な習慣です。AIエージェントに判断を委ねて構築を進めさせると、できあがったものをすべて破棄しなければならなくなる場合があります。ですから、構築を急がず、まずきっちりと設計することが大事です。
次の2つの方法を利用すると、設計が簡単になります。まず、アシスタントをプランモードに切り替えます（Claude Codeでは、Shift+Tabを押してモードを順に切り替え、「plan mode」を選択します）。プランモードでは、アシスタントがファイルに変更を加��ることなく、計画を提案します。次に、構築を始める前に、開発者への聞き取りを行うようアシスタントに依頼しましょう。次のようなプロンプトが効果的です。
「構築を始める前に、私に対してこのAIエージェントを設計するためのヒアリングをしてください。一度に1つずつ質問し、それぞれについて妥当なデフォルト案を提示してください。設計は意思決定ツリーとして扱ってください。私の回答によって新たな選択肢が生じた場合は、その分岐に沿って、必要な事項がすべて確定するまで質問を続け、その後で次の分岐に移ってください。データモデル、アクション、権限、AIエージェント構造をカバーしてください。AIエージェントの構築に必要な意思決定がすべて完了するまでは、ヒアリングを終了したり、構築を始めたりしないでください」
この1つの指示だけで、アシスタントは設計パートナーになります。アシスタントは意思決定ツリーのすべての分岐をたどり、回答から生じた追加の判断事項を順に掘り下げ、決めるべきことが何も残っていない段階になったら質問を終了します。これで、推測で何かが構築されることはなくなります。今回の例である従業員向けTo-Do Managerエージェントでは、アシスタントが次のようなアーキテクチャーの選択肢を順に検討しました。
- To-Doはどこに保存しますか。カスタムオブジェクトですか、それとも標準のTaskオブジェクトですか。
- AIエージェントには、どの項目とステータス値が必要ですか。
- AIエージェントは、ログインユーザーとして稼働するべきですか。
- 3つのフローアクションを1つのサブエージェントにまとめますか。それとも、タスクごとにサブエージェントを設けるハブ＆スポークモデルにしますか。
- 基盤となるロジックをSalesforce FlowとApexのどちらで実装しますか。
上記のプロンプトは一例です。組織のベストプラクティスに従って、設計を支援する独自のエージェントスキルを作成すれば、このようなプロンプトを毎回入力せずに済みます。
Claude Codeコーディングアシスタントは、開発者に1つずつ質問しながら、設計上の各判断についてデフォルト案を提示します。
AIエージェントをグラフ構造として図にすると、理解しやすくなります。各サブエージェントは、特定のドメインを表すノードとして機能します。各ドメインには専用の指示とアクションがあり、1つの作業に特化しています。最上位のルーターノードが、会話の内容に応じて各サブエージェントを指揮します。AIエージェントの設計とは、これらのノードを定義し、エージェントがユーザーの目標を達成できるように、明確な指示とツールを提供することを意味します。
つまり、サブエージェントを分ける基準は、タスクの難しさではなく、ドメインです。たとえば、よくある質問（FAQ）への回答やステータスの照会のように、作業全体が1つのドメインに収まる場合は、1つのサブエージェントを使用します。作業が複数のドメインにまたがり、それぞれに固有の指示、アクション、またはセキュリティゲートが必要な場合は、ハブ＆スポーク型で複数のサブエージェントを使用します。ほとんどのAIエージェントは、1～5個のドメイン別のサブエージェントを持つ構成になります。こうした判断は、コーディングエージェントではなく、開発者が下すことが重要です。自分でグラフ構造を設計することで、その構成に確信を得られます。
下の図は、この考え方をインフォグラフィックとしてAIで生成したものです。
生成してデプロイし、修正と再試行をAIエージェントに任せる
計画が承認されると、アシスタントはカスタムオブジェクトと項目、フロー、Agent Script（AIエージェントのサブエージェント、ルーティングロジック、指示、アクションバインディングを指定する宣言形式）で記述されたAIエージェント定義ファイルをすべて構築します。生成されるのはオーサリングバンドルです。これは、AIエージェントの完全な定義をローカルメタデータファイルとして含む、デプロイ可能なパッケージです。ファイルが作成される過程は、Visual Studio Code上で、リアルタイムで確認できます。
計画では、必ず作業範囲を明確に定めてください。公開する前に「構築、デプロイ、検証」まで行うように指示するのが一般的です。また、指定しなければアシスタントがスキップする可能性のあるステップをリマインダーとして追加できます。たとえば、「新しいオブジェクトに適切な権限が設定されていることを必ず確認し、権限セットを作成してください」と指示します。項目レベルセキュリティ（FLS）と作成・参照・更新・削除（CRUD）権限は重要であるため、明示してください。
特��的な挙動として、自動的な修正と再試行のループが挙げられます。デプロイに失敗すると、アシスタントはコンパイラーエラーまたはデプロイエラーを読み取り、原因となったメタデータを特定して修正を適用し、再デプロイします。デプロイが成功するまで、このサイクルを繰り返します。これは手作業で行う編集やコンパイル、デバッグの繰り返しと同じものですが、AIエージェントが実行してくれます。さらに高速化したい場合は、フローを1つずつ順番に構築させるのではなく、処理を分割して、複数のエージェントに各フローを同時に構築させることができます。作業を並列化する際は、依存関係を把握したうえで適切にグループ化し、互いに干渉しないように実行できるようにしてください。
この一連の処理は、自然言語で次のように指示できます。「Salesforce Flowを使用して、1つのサブエージェントで構成されるTo-Do Managerを構築し、検証し、デプロイしてください。新しいオブジェクト用の権限セットを作成してください」。このプロンプトを受けると、developing-agentforceスキルが定められた手順を正確に実行します。まずオーサリングバンドル（AIエージェントのひな型）を生成し、次にローカルで検証を行い、Agent Scriptがコンパイルできることを確認します。その後、アクションが参照する基盤のフローまたはApexをデプロイし、最後にオーサリングバンドルをデプロイします。この流れを理解しておくと、処理の進行を確認し、必要に応じて手を加えることができます。
1sf agent generate authoring-bundle --json --no-spec --name "To-Do Manager" --api-name To_Do_Manager
2sf agent validate authoring-bundle --json --api-name To_Do_Manager
3sf project deploy start --json --metadata Flow
4sf project deploy start --json --metadata AiAuthoringBundle:To_Do_Managerこのスキルには、2つのベストプラクティスが組み込まれていることに注目してください。すべてのコマンドには--jsonが付けられ、出力が機械で読み取れる形式になります。また、すべてのデプロイで対象のメタデータを明示的に指定しています。デプロイの対象を指定しないでsf project deploy startを実行すると、変更されたすべての内容がデプロイされます。デプロイごとに対象範囲を限定することで、AIエージェントのメタデータが誤ってデプロイされるのを防げます。
検証後、2つのモードでテストする
構築が完了すると、アシスタントがAIエージェントの動作の流れを自動で検証し、手作業のテストよりもはるかに多くの経路を確認します。検証はAIエージェントを公開する前に必須となるので、開発フローに組み込まれています。
とはいえ、必ず自分でもテストを行ってください。自動検証はあくまでセーフティネットで、人による判断に代わるものではありません。ここで、testing-agentforceスキルが役立ちます。このスキルでは、開発を繰り返しながら実行する簡易スモークテストと、回帰テストや継続的インテグレーションに使用する保存可能なバッチテストスイートという、2つのモードを利用できます。1つ目のモードで迅速に開発を進め、2つ目のモードでAIエージェントが拡張されても期待どおりの動作を保てるようにします。
プレビューセッションを使用した簡易スモークテスト
簡易モードは、リアルタイムのプレビューセッションです。セッションを開始し、実際の発話を送信して、テストが終わったらセッションを終了します。プレビューごとにトレースが生成され、後から内容を確認できます。3つ��サブコマンドすべてに--authoring-bundleを指定する必要があることに注意してください。
1sf agent preview start --json --authoring-bundle To_Do_Manager
2sf agent preview send --json --authoring-bundle To_Do_Manager --session-id SESSION_ID --utterance "「ブログを書く」というTo-Doを作成してください"\
3sf agent preview end --json --authoring-bundle To_Do_Manager --session-id SESSION_IDテスト仕様を使ったバッチ回帰テスト
同じテストを繰り返し実行する場合は、確認したいケースを記述すると、スキルがテスト仕様を生成します。テスト仕様は、各発話と、その発話に対して期待される動作を記載したYAMLファイルです。それぞれのケースで次の3つのアサーションが重要になります。
expectedTopic– 会話の振り分け先となるべきサブエージェントexpectedActions– 実行されるべきアクションexpectedOutcome– 期待する結果を自然言語で説明したもの
最後の項目は、大規模言語モデル（LLM）が判定役として、人と同じように応答を読み取って評価します。これは最も信頼性の高いアサーションであるため、すべてのケースに含めてください。
1name: To_Do_Manager_Tests
2subjectType: AGENT
3subjectName: To_Do_Manager
4testCases:
5 - utterance: "「ブログを書く」というTo-Doを作成してください"
6 expectedTopic: To_Do_Management
7 expectedActions:
8 - Create_To_Do
9 expectedOutcome: "「ブログを書く」という新しいTo-Doが作成され、作成完了がユーザーに通知されます。"続いて、そのテスト仕様をもとにテスト定義を作成し、バッチ実行して結果を待ちます。
1sf agent test create --json --spec specs/To_Do_Manager-testSpec.yaml --api-name To_Do_Manager_Tests --force-overwrite
2sf agent test run --json --api-name To_Do_Manager_Tests --wait 10テストケースが失敗すると、スキルはトレースをもとに、サブエージェントの選択ミス、アクションの未実行、根拠のない応答などの原因を診断します。その後、問題に的を絞った修正を適用し、数回にわたって再試行します。それでも解決しない場合は、開発者に支援を求めます。また、新しいAgentforce Builderでライブプレビューを実行し、システム管理者にもわかりやすい画面で確認できます。または、Visual Studio CodeのAgentforce DXパネルを使用して、テストセッションを開始できます。
注 – Salesforceは、複数ターンの会話や状態変数の注入に対応し、アクションを検証できるよう、自動テスト機能の強化を進めています。詳しくはリリースノートをご覧ください。
AIエージェントを公開して有効化する
AIエージェントが正常に動作するようになったら、公開して有効化します。公開すると、デプロイ済みのバンドルは、「無効」状態の実行可能なエージェントバージョンに変換されます。その後、有効化すると、ユーザーやテストからアクセスできるようになります。必要に応じて、先に公開し、後から有効化することもできます。以下は、公開と有効化のためにAIエージェントが実行するコマンドです。
1sf agent publish authoring-bundle --json --api-name To_Do_Manager
2sf agent activate --json --api-name To_Do_Manager作成し忘れたメタデータがある場合は、AIエージェントに作成を依頼するだけで済みます。要は、不足しているものを説明すれば、アシスタントがそれを補ってくれるのです。Agent Scriptと関連するメタデータをGitなどのソース管理システムにコミットし、変更履歴を残して、いつでも以前の状態を再現できるようにしてください。こうしておけば、必要なときに動作確認済みのバージョンへ戻せるため、開発環境の安定性と安全性を確保できます。
勘に頼らず、トレースを使ってデバッグする
AgentforceのAIエージェントをデバッグする際には、エージェントトレースが最も重要な判断材料になります。このトレースは会話の各ターン後に生成されるJSONファイルで、リクエストを処理したサブエージェント、LLMが受け取った内容、実行されたアクションを確認できます。AIエージェントが最初から完璧に仕上がることはまずないので、継続的に調整していくことになります。トレースは2か所で扱いますが、それぞれで見え方が少し異なります。
開発中のローカルトレース
開発中のトレースは、ローカル環境に保存されます。preview sendを実行すると、ランタイムが会話の各ターンにつき1つのJSONファイルを書き出します。各トレースには、処理を担当したサブエージェント、設定された変数、LLMが受け取った内容、呼び出されたアクションを含む、実行経路全体が記録されます。これらのファイルは、プロジェクト内で確認できます。
1.sfdx/agents/To_Do_Manager/sessions//traces/.jsonローカルトレースはすぐに生成され、完全な情報を含んでいますが、カバーされるのは開発者が実行したプレビューセッションのみです。修正手順はシンプルです。トレースを開いてアシスタントに貼り付け、期待した結果と実際の結果の違いを説明します。Agent DXパネルでは、同じトレースをワンクリックで取得できます。トレースには詳細な情報が含まれているため、通常、アシスタントは問題を特定して修正できます。「トレースを使用してセルフテ��トを行い、問題を修正してください」と依頼することもできます。これにより、AIエージェントをリリースする前に、問題の大半を解決できます。
observing-agentforceスキルを使った本番トレース
ユーザーが実際にAIエージェントを利用するようになると、別の視点が必要になります。それを担うのがobserving-agentforceスキルです。このスキルが照会するのは、1つのローカルファイルではなく、AgentforceがData 360に保存している本番セッションデータであるSession Trace Data Model（STDM）です。そのため、実際に交わされた大量の会話を通じて、AIエージェントの動作を確認できます。
このスキルは、観察、再現、改善という3つのステップを繰り返します。本番環境のセッションを照会し、サブエージェントへの誤ったルーティング、アクションエラー、指示の遵守度の低さ、処理の遅いアクション、ユーザーが途中で離脱したセッションなど、重要な問題を明らかにします。続いて、問題の可能性があるケースをローカルプレビューで再現し、根本原因を確認してから、AIエージェントを編集して修正します。たとえば、簡単な言葉で「過去1日で最もパフォーマンスの低かったセッションを見つけ、その理由を教えてください」と依頼すると、スキルが照会を実行し、結果を読み取ってくれます。
どちらのトレースでも、会話がどのサブエージェントへ振り分けられ、どのような経路をたどったのかを追いにくいときは、ビジュアル化ツールが役立ちます。AIエージェントはグラフ構造です。ルーターが各会話をサブエージェントに引き渡し、サブエージェントは変数とプロンプトを組み立ててLLMに送信し、回答を得るまでツールを呼び出します。AgentLens（英語）のようなツールを使うと、そのグラフ構造を順にたどりながら、サブエージェント間の引き継ぎ、LLMに送られたツール、フローを終了させた応答を確認できます。
注 – 本番環境のAIエージェントを大規模に可視化し、分析するには、Agentforceオブザーバビリティ（英語）でダッシュボードとメトリクスを設定することをお勧めします。
カスタムエージェントスキルでライフサイクルを拡張する
このライフサイクルを取り入れると、日々の作業が変わります。定型作業のたびにSalesforceの設定画面を操作する必要がなくなり、期待する結果を説明するだけで済みます。問題があるときは、プロンプト、コンテキスト、自作したツール、導入したスキルのいずれかを修正すれば、ほとんどの場合は解決できます。
特に重要なのがスキルの改善です。期待どおりのメタデータが生成されない場合は、スキルを改善して、ぜひその修正点をコミュニティで共有してください。修正を加えるたびに、その成果が全員に届き、アシスタントももっと効果的にSalesforceを扱えるようになります。スキルの改善と設計重視のヒアリングを組み合わせることで、開発者が主導権を維持し、じっくりと学びながら設計を自分のものにできます。
エージェンティック開発ライフサイクル – まとめ
エージェンティック開発ライフサイクルを取り入れることで、Agentforceエージェントをこれまで以上にすばやく、確実に構築できます。まずSalesforceスキルライブラリからエージェントスキルをインストールして、アシスタントがSalesforceを扱えるようにしましょう。次に、プロジェクトのひな型を作成して組織に接続し、プランモードを使って設計重視のヒアリングを行い、構築する前に設計を固めます。アシスタントにメタデータを生成させ、失敗したデプロイを修正して再試行させます。その結果を検証してテストし、問題がある場合はトレースを使ってデバッグします。開発をスピードアップしながら、常に設計の主導権を握ることができます。
さらに知識を深め、作成したものを共有してみませんか？Salesforce Developers Trailblazer Communityにぜひ参加してください。
関連情報
- Agentforce Developer Center（英語）
- GitHubのSalesforceスキルライブラリ（forcedotcom/sf-skills）
- Agentforce DX Visual Studio Code拡張機能（英語）
執筆者について
Mohith ShrivastavaはSalesforceのプリンシパルデベロッパーアドボケイトです。15年にわたってAgentforce 360 Platform（旧Salesforce Platform）でエンタープライズ規模の製品を開発してきました。Salesforce開発者が質問し合い、知識を共有できる開発者向けフォーラムのSalesforce Stack Exchangeでも積極的に活動しています。LinkedInのプロフィールはこちら。
