エージェント型AI時代におけるSalesforce開発者の未来

※本記事は2026年3月10日に米国で公開された The Future of the Salesforce Developer in the Agentic AI Eraの抄訳です。本記事の正式言語は英語であり、その内容および解釈については英語が優先されます。

この記事のポイント

• AIは、Salesforce開発者の役割に取って代わるものではない。AIの登場によって、開発者の役割はシステム設計、品質エンジニアリング、システム横断的な思考という、より価値の高い3つの能力を発揮することに変わりつつある。
• AIを活用した開発ツールを導入すると、開発スピードはすぐには上がらず、最初はむしろ遅くなる。AI投資の意義は、単にツールを追加することではなく、ワークフローを再設計することにある。
• Salesforce開発の多くは、既存の環境に手を入れるブラウンフィールド開発で、意思決定の大半が文書化されていない、複雑なSalesforce組織を引き継ぐことになる。AIだけで、こうした組織固有の背景に対応することはできない。
• 2026年以降、Salesforce開発者のキャリアで評価される能力は、コードを速く書けることではなく、プラットフォームに関する深い知識と幅広いアーキテクチャーに関する判断力を兼ね備えていること。
• 勤め先がAIツールを導入しているかどうかにかかわらず、現在、最も重要であるスキルは、今日から身に付けていくことができる。

AI活用による開発を取り入れると、初めのうちはかえってスピードが鈍ることがあります。

これは、ツールに問題があるからでも、取り組み方が間違っているからでもありません。AIツールを導入したSalesforce開発チームに共通して見られるのが、J字型のカーブ（英語）です。AIを効果的に利用するには、タスクそのもの、つまりワークフロー、チームのプロセス、ソフトウェアの開発方法を見直す必要があります。こうした新手法では、開発を加速できるようになる前に、新たな種類のエラーが発生しがちです。

移行期の問題を解決しないまま突き進むと、よくない結果に行きつきます。質の低いコードがコードベースに大量に入り込むのではないかという懸念が生まれ、AIで本当に成果を向上できるのか、それとも開発者の生産性が向上したように見えるだけなのかという不安が広がります。

そう感じるのはもっともですが、それだけでは全体像が見えてきません。ここでは、Salesforce開発者の役割にどのような変化が起きているのかを、これまでの経緯、AIがもたらす変化、今後のキャリアパスという観点から見ていきます。

変化するSalesforce開発者の役割

Salesforceプラットフォームの歴史において、開発者の価値は明白でした。宣言型では実現できないことを実装するのが、開発者の役割だったのです。Flowだけでは不十分なとき、数式が限界に達したとき、あるいはビジネス要件が設定の範囲を越えたときには、開発者がApexを記述しました。Lightning Webコンポーネントを構築し、連携を設計し、コードでプラットフォームを拡張しました。

開発者に求められる主なスキルは、実装力でした。開発者は、要件を受け取り、実際に機能するソリューションを作成していました。その過程で、ガバナ制限、一括処理化パターン、トリガーの実行順序、マルチテナントアーキテクチャーの細かな特性に対処していました。優れた開発者は、Salesforceに関する深い知識を持っていました。プラットフォームの制約を理解しているだけでなく、その制約の中で効果的に開発する方法も熟知していました。

そうした時代が終わるわけではありませんが、流れは変わりつつあります。実装力は今も重要ですが、もう開発者の中心的な価値ではありません。開発者の価値は、システム設計、品質エンジニアリング、システム横断的な思考力へと移っています。

今起きている変化は、AIがコードを書くようになったことだけではありません。それは目に見える部分にすぎず、重要なのは、これまで見えなかった本質的な課題が浮き彫りになることです。 

AIは、Salesforce開発者に取って代わるのでしょうか？いいえ。AIが担うようになっているのは、業務の一部、とりわけ最初のコード案の生成です。Salesforce開発者の仕事全体がAIに置き換わっているわけではありません。むしろ、システム設計、品質検証、システム横断的な思考といった、今後も必要とされるスキルの需要は高まっています。開発者の役割がなくなるのではなく、再定義されているのです。

AIによって、ボトルネックが変わりました。何十年もの間、最も困難な作業は実装でした。作るべきものは明確でしたが、問題は、それをコードとして形にすることでした。今、実装には時間もコストもかかりません。Agentforce Vibes（英語）、Claude Code、Salesforce Extensions（英語）と組み合わせたCursorといったAIコーディングアシスタントを使えば、Apexクラスの生成、Lightning Webコンポーネントのひな型作成、テストスイートのドラフト、連携処理の骨組みの作成が数秒で完了します。品質にはばらつきがありますが、生成のスピードは一貫しています。

AIがコードを生成するようになって明らかになったのは、本当のボトルネックはシステム設計だったということです。何を作るのか、なぜそのように作るのか、それをシステム全体にどのように組み込むのかを理解することが課題だったのです。実装に時間がかかっていたときは、この課題は表面化していませんでした。コードの記述に費やしていた時間は、思考のための時間でもありました。コードを書きながらエッジケースを発見し、アプローチを見直し、複雑さを理解していたのです。

AIによって実装にかかる時間がほぼゼロまで短縮されると、これまで自然に確保されていた、思考のための時間がなくなります。その分、設計や分析に意識して時間をかけないと、リリースは速くなっても、理解は浅くなってしまいます。ここから問題が生じるのです。

AIはただのコード生成ツールではありません。開発者にとって、AIはこれまでにないほど強力な学習ツールです。馴染みのないコードベースについて質問し、プラットフォームの挙動をリアルタイムで調べ、設計上の判断について即座にフィードバックを得ることができます。AIによって、生産性の効率だけではなく、学習の効果も変わります。ここが重要なポイントです。学習ツールとしてのAIについては、後ほど取り上げます。

既存のSalesforce組織がAIにとって最大の課題である理由

もう1つ、AIのデモでは見落としがちな現実があります。世界のソフトウェアの大半は、ゼロから構築されるものではありません。デモでは、白紙の状態から数分で新しいアプリが構築されます。しかし、多くのSalesforce開発者が毎日向き合っているのは、既存のSalesforce組織です。こうした組織には、何百ものカスタムオブジェクトが存在します。複数のリリースにわたって構築された、自動化のレイヤーが積み重なっています。複数の管理パッケージが相互に作用していますが、誰も全体像を完全には把握していません。構築した人物が退職した後も、文書化されないまま設定に残っているビジネスロジックもあります。

これがブラウンフィールド開発です。Salesforce開発の大多数は、こうした環境で行われています。

Salesforceのエコシステムでは、数百万人の開発者が、長年にわたって進化してきたさまざまなSalesforce組織で開発に携わっています。こうした環境では、システム自体が仕様です。コード、メタデータ、属人的な知識、これまでSalesforce組織に関わったすべての人の判断の中に、仕様が蓄積されています。AIは、構造的なレイヤーの分析には長けています。しかし、その背後にある「なぜ」には到達できません。なぜそのデータモデルが選ばれたのか、特定の顧客層に対応するためにどのようなトレードオフが行われたのか、どのような制約がアーキテクチャーを形作ったのかといった理由です。そうしたコンテキストは、コードの中ではなく、人の頭の中にあるからです。

ブラウンフィールド環境でAI活用による開発を実践するためのフレームワーク

1. 構築する前に全体像を把握する。既存のSalesforce組織でAIを使ってコードを生成する前に、現在のアーキテクチャーを理解しましょう。トリガーの実行順序、自動化の依存関係、共有ルール、インテグレーションの境界を確認してください。
2. 暗黙の前提を明文化する。現在のデータモデルの背後にあるトレードオフ、特定の設計パターンが存在する理由、大規模運用でのみ表面化するガバナ制限のリスクを文書化します。
3. コンテキストを入力情報として扱う。AIツールに与えるシステムのコンテキストが多いほど、出力の質が向上します。Salesforce組織の実際のアーキテクチャーにもとづいたプロンプトなら、そのままリリースできる成果物が得られます。汎用的なプロンプトからは、作り直しが必要な成果物しか生まれません。

例 – AIアシスタントに、取引先の更新後に実行され、子レコードである取引先責任者を照会してステータス項目を同期するトリガーを生成させるとします。コードがコンパイルされ、テストをパスします。しかし、取引先にはすでに2つのトリガーが設定されています。1つはテリトリーの割り当てを再計算するトリガーで、もう1つは外部ERPにプラットフォームイベントを発行するトリガーです。3つのトリガーを合わせると、データの一括ロード時に、SOQLクエリーのガバナ制限である100回を超過します。AIは、既存のトリガー、実行順序、累積クエリー数を把握していませんでした。システムの背景情報を理解している開発者であれば、デプロイ前にこの問題に気づけたはずです。システム設計の有無が、こうした違いを生みます。

これからのSalesforce開発者にとって最も重要なスキル

以下の各セクションでは、それぞれのスキルを深く掘り下げ、実務でどのような役割を果たすのかを見ていきます。

システム設計 – これからのSalesforce開発者にとって中核となるスキル

これからのSalesforce開発者にとって最も重要な仕事は、新しいコードを書くことではありません。システムを設計し、既存のシステムを理解し、その進化の方向性を定め、AIを動かすための構造とガードレールを作ることです。

先に紹介したブラウンフィールド開発のフレームワークは、その手順を示しています。さらに難しいのは、このフレームワークを実行するには何が必要で、なぜそれがAIではできないのかを明らかにすることです。なぜトリガーは特定の順序で実行されるのか。現在のデータモデル、どのようなトレードオフによって作られたのか。負荷が高まったとき、連携はどのように動作するのか。セキュリティモデルは何を前提にしているのか。実際のガバナ制限のリスクはどこにあるのか。必要なのは、現状を文書化するだけでなく、その先を設計することです。

この仕事には、高度な技術力と創造的な判断力が必要です。AIは構造分析が得意です。コード分析からドキュメントの下書きを生成し、メタデータ全体からパターンを見つけ、依存関係のつながりを可視化できます。しかも多くの場合、人間よりも速く行えます。しかし、設計上の判断では、「なぜ」なのかを理解する必要があります。なぜそのパターンが存在するのか、なぜそのトレードオフを受け入れたのか、なぜその制約がビジネス上重要なのか。そうした判断の根拠は、コードベースではなく、人間関係や組織に蓄積された記憶の中にあります。

実務では、文書化されていない複雑なSalesforce組織を分析し、アーキテクチャーの全体像を明確に描ける開発者が、チーム全体（そこで使われるAIツールも含む）が効果的に働ける環境を作ります。その能力は、Apexを書くスピードよりもはるかに重要です。アーキテクチャーの観点から考えられる人が、チームメンバーの生産性を引き出します。コードを速く書くという仕事は、AIがすでに習得しつつあります。

Agentforceの導入に向けてSalesforce組織を準備するときも、Flowで新たな自動化を構築するときも、AIのコーディングアシスタントを開発ワークフローに取り入れるときも、この点は変わりません。どの場合でも、成果物の品質を決めるのは、システム設計にもとづく思考です。あいまいなプロンプトからは、あいまいな出力しか得られません。組織のアーキテクチャーを明確に理解していれば、リリース可能な成果物を生み出せます。

AIを活用したSalesforce開発における品質エンジニアリング

AIがコードをスピーディに生成するようになると、リスクはコードが誤っていることではありません。コードがすぐに生成され、もっともらしく見えるために、開発者が質の低いコードを受け入れてしまうことです。質の低い成果物が生まれる原因は、モデルではなく、人が確認を怠ってしまうことにあります。

開発者の日々の仕事の中心は、生成ではなく、検証へと移っています。検証とは、AIが生成したクラス、フロー、テストスイートのすべてを、編集の判断が必要なドラフトとして扱うということです。内容を厳密に確認してください。構文がコンパイルできるかだけでなく、そのアプローチが既存のアーキテクチャーに適合しているかどうかも見極める必要があります。コミットする前にリファクタリングしてください。

AIが生成したテストには、特に注意を払う必要があります。こうしたテストでは、コードが記述どおりに動作することは確認できますが、意図どおりに動作することまでは確認できません。AIにコードとテストの両方を書かせると、意義のある検証をすることなくパスしてしまうテストが生成されやすくなります。テストにも、本番用のコードと同じ水準の厳密さが求められます。

既存のSalesforce環境では、判断を誤ったときの代償が大きくなります。検証が不十分なトリガーは、一括データ処理の障害を引き起こす可能性があります。適切なガードレールが設定されていないAgentforceエージェントからは、エンドユーザーを混乱させる出力が生成されます。レコードの同時更新を想定したテストを行っていないフローは、データ整合性の問題を引き起こし、修正に数週間かかることがあります。妥協のない検証チェックポイント（テストの合格、静的解析で問題がないこと、手動確認の完了など）を設ける開発者こそが、システムの健全性を長期間維持できます。スピードが優先され、整合性がないがしろになりそうな場合に歯止めをかけることも、開発者の役目です。この役割は、AIの登場前より今の方が重要です。

これは、開発者のスキルを引き上げることにもつながります。これまで数時間かかっていたドラフトが数秒で得られるようになれば、人間の判断が最も重要となる作業、つまりアーキテクチャー上の判断やトレードオフの分析、AIの出力を採用するか否かの見極めに時間をかけられるようになります。

とはいえ、すべての開発者がアーキテクト（英語）になるということではありません。すべての開発者が、システムのコンテキストを深く捉える力を身に付けるということです。多くの場合で、開発者の役割は、実装を担うAIエージェントを監督し、リリースされる成果物に責任を負うことへと変わります。フレームワーク、コーディングパターン、コードレビュー、慎重なテスト設計は、これからも人が担う仕事です。企業のリーダー層はスピードだけを評価しがちですが、品質基準を守る開発者がいなければ、AIによって技術的負債と脆弱性が拡大することになります。

Salesforce開発者の新たな強みとなるシステム横断的な思考

開発者に深い専門性が欠かせないことに変わりはありません。AIがまだ理解していないプラットフォームの内部構造を理解している人は必要です。しかし、さらに重要なのは、深い専門性と幅広い視点を兼ね備え、自分の専門領域とシステム全体とのつながりを理解できる開発者です。

Salesforceは、アーキテクチャーを構成する要素の1つです。ApexとFlowがどのように連携するか。Flowがプラットフォームイベントとどのようにつながるか。プラットフォームイベントが外部のミドルウェアとどのようにやり取りするのか。一連の連携がエンドユーザーにどのような価値をもたらすのか。こうしたつながりを理解している開発者は、全体を見ずに1つのレイヤーだけを深く掘り下げる開発者よりも、はるかに価値の高い存在です。

構築している機能だけを見るのではなく、製品全体を把握すること。データモデルや連携の全体像、セキュリティアーキテクチャー、そしてこれらの要素を結びつけるビジネスロジックを理解すること。さらに、技術的な影響をビジネスの観点から説明し、開発が遅くなるとしても、早い段階でリスクを明らかにすることが求められます。

Salesforceのプラットフォームでは、この変化がすでに現れています。Agentforceには、コードだけでなく、AIエージェントの設計、ガードレールの設定、データアーキテクチャー、ユーザー体験を理解している開発者が必要です。リリースを重ねるたびに、クリックベースの設定とコーディングの境界はあいまいになります。SalesforceとAIサービス、データプラットフォーム、外部アプリとの接続が増えると、インテグレーションのパターンも複雑になります。これらのレイヤー全体を俯瞰し、コードを使うべき箇所を適切に判断できる開発者が、チームから頼られる存在になります。

エージェント型AI時代のSalesforce開発者へのキャリアアドバイス

この記事を読んで、この変化を重く受け止めているとしても、同じように感じている人はほかにもいます。そう感じるのは当然のことで、開発者という職業に求められるものが変わりつつあるのです。その役割は小さくなるのではなく、さらに広がるのです。

すでにワークフローでAIツールを使っている場合は、どうすればよいですか？

スピードを最優先の指標にするのはやめましょう。AIが動作するためのシステム設計、ガードレール、フレームワークを構築し、ワークフローを作り直すことに注力すべきです。これには時間がかかり、エラーも起こります。しかし、新しいパターンが定着すれば、これまで実現できなかったレベルで仕事ができるようになります。AIの出力はドラフトとして扱い、厳密に検証してください。早くリリースするように求められても、仕事の質を高める判断力を手放してはいけません。

勤め先がまだAIツールを導入していない場合は、どうすればよいですか？

取り残されるのではないかと不安になるかもしれませんが、大丈夫です。企業への導入と個人の学習は、分けて考える必要があります。企業がAIツールをいつ導入するかは個人には決められませんが、いつ学び始めるかは自分で決められます。

今すぐAIアシスタントを使って、コードベースを調べ、システム設計の思考法を実践し、ドキュメントのドラフトを生成してみましょう。チームが正式に採用しているツールに関係なく、この記事で紹介した習慣を身に付けることは可能です。システムを深く理解し、暗黙の前提を明文化し、アーキテクチャー全体を捉えるというシステム設計の作業そのものが、今行っている仕事の質を高めます。また、勤め先がAIツールを導入した際に、すばやく対応できるようにもなります。

Salesforce開発者としてのキャリアパスで、どのようなスキルが強みになりますか？

文書化されていない複雑なSalesforce組織を分析し、アーキテクチャーの全体像を明確に描くことができますか？単独では機能するAIの提案が、全体のコンテキストでは問題を引き起こす可能性を見抜くことができますか？システムの境界をまたいで、アーキテクチャー全体を考慮した判断ができますか？

AIが実装を担うようになるほど、こうした能力の価値が高まります。

Salesforce開発について学習中、あるいはSalesforce開発者としてのキャリアがまだ浅い場合は、どうすればよいですか？

今こそ、学び始めるのに最適なときです。重要性の高いスキルを身に付けるうえで、AIは最も強力なツールです。

Salesforce開発の経験が浅くても、AIを活用して馴染みのないコードベースを調べ、プラットフォーム内部の仕組みをリアルタイムで学び、システム設計上の意思決定をシミュレーションし、コードについてすぐにフィードバックを得ることができます。こうした学習方法は、2年前には存在していませんでした。今だからこそ、システム思考は以前より早く身に付けることができます。

とはいえ、表面からは見えない内部の仕組みも理解する必要はあります。外国語の学習と同じで、聞いて意味は理解できても、自分で話したり書いたりしなければ、その規則は身に付きません。AIを使えば、習得をスピードアップできます。

専門性を深める前に、まず広い視野を持ちましょう。学習した内容を記録することを習慣にしてください。Trailheadでプラットフォームの基礎をしっかり学びましょう。Salesforce認定Platformデベロッパーなどの認定資格は、基礎知識があることを証明しますが、ここで説明したスキル（システム思考、アーキテクチャー上の判断力、品質を徹底する姿勢）は、試験では測りきれない価値があります。

SalesforceコミュニティがAIへの移行を後押し

AIを活用した開発に移行するなか、エコシステムではかつてない速さで新たな知見が生まれています。しかし、その知見は、均等に行き渡っているわけではありません。AIを日常的に試している開発者がいる一方で、勤め先がまだAIの導入に乗り出していない開発者もい��す。両者の差は才能ではなく、AIを実際に活用した人の率直な経験や知見に触れられる機会があるかどうかです。

今、このコミュニティの誰もができる最大の貢献は、それぞれが得た学びを共有することです。包み隠さず、正直に、取り繕うことなく共有してください。成功体験だけではなく、行き詰まりや失敗、AIによって一時的に苦労が増えた局面も共有してください。「導入して3か月間は、かえって作業が遅くなった」といった率直な経験談は、最も有益な情報の1つです。こうした情報が共有されれば、移行に伴う負担は当たり前に発生するものとわかり、他のメンバーが計画を立てやすくなります。

Trailblazer CommunityやGitHubのディスカッション、コミュニティカンファレンス（英語）、Salesforceユーザーグループ（英語）、社内チャネルで経験を共有することで、ほかの人が導入を進める助けになります。Salesforce開発者コミュニティに蓄積された率直な知見は、この移行を進めるうえで役に立つ最大の資産です。ぜひ活用し、経験を共有してください。コミュニティの重要性はますます高まっています。

これからのSalesforce開発者に求められるもの

これからは、もっと多くのSalesforce開発者が求められるようになります。必要とされるのは、システムを実装するだけでなく、設計できる開発者です。製品全体を頭の中で把握できる人です。的確な判断でAIをガイドし、スピード重視で健全性が損なわれそうなときには異議を唱え、エコシステム全体の成長につながるように学びを共有できる開発者です。

新しいツールで、可能性は大きく広がっています。重要なのは、かねてから優れたエンジニアが備えていた力、つまり判断力、文脈を捉える力、システム全体を理解しようとする姿勢なのです。

関連資料

• 開発者初級（Trailhead）
• Agentforce開発者ガイド（英語）
• Apex開発者ガイド
• Lightning Webコンポーネント開発者ガイド

執筆者について

René Winkelmeyer
開発者アドボカシーチームのリーダーとして、Agentforce、Data 360、Agentforce 360 Platformを担当。業務外でもコーディングを趣味とし、GitHubでコードを公開。LinkedInでのフォロー歓迎。