Agentforceのサブエージェント(旧トピック)とアクションとは?役割の違い・設定の重要性から作り方、失敗時の対処法まで解説

公開日  reload 

この記事をシェアする

x facebook
Agentforceのサブエージェント(旧トピック)とアクションとは?役割の違い・設定の重要性から作り方、失敗時の対処法まで解説

この記事でわかること

  • Agentforceのサブエージェント(旧トピック)とアクションとは
  • AgentforceでAIエージェント作成時にサブエージェント(旧トピック)とアクションの設計が重要な理由
  • Agentforceのサブエージェント(旧トピック)とアクションの設計前に決めること
  • Agentforceのサブエージェント(旧トピック)とアクションの作り方
  • Agentforceのサブエージェント(旧トピック)とアクションでよくある失敗と対処法

執筆者 取締役 / CTO 内山文裕

Agentforceの導入や活用のお困りごとはプロにご相談ください

  • Agentforceのサブエージェントとアクションの役割分担が曖昧で、どこまでをサブエージェントとして切り分けるべきか分からない
  • サブエージェントやアクションの設計が原因で、意図しない会話や誤った処理が実行されてしまう
  • Agentforceを拡張するたびにサブエージェントやアクションが増え、管理・再利用・運用改善が難しくなっている
このようなお困りごとがありましたら、ぜひとも私たちStrhにご相談ください。Salesforceや営業・マーケティングに精通したコンサルタントが、御社に最適なソリューションをご提案させていただきます。まずはお気軽にお問合せください。 Salesforce活用についてまずは相談する

AgentforceでAIエージェントを設計する際、「サブエージェント(旧トピック)とアクションの違いが分からない」「どこまでをサブエージェントとして定義し、どこからをアクションとして切り分けるべきか判断できない」と悩む方は少なくありません。

実際サブエージェントとアクションの設計が曖昧なまま進めてしまうと、エージェントが想定外の会話を始めたり、必要な処理を適切なタイミングで実行できなかったりすることがあります。

特に複数の業務フローを1つのサブエージェントにまとめすぎたり、1つのアクションに役割を持たせすぎたりすると会話の分岐や処理結果が不安定になりやすくなります。その結果、運用開始後の修正や見直しに手間がかかるケースもあります。

そこで本記事ではAgentforceにおけるサブエージェントとアクションの違いや役割を整理したうえで、設計が重要な理由、作成前に決めておきたいポイント、具体的な作成方法、よくある失敗とその対処法までを詳しく解説します。

また、Agentforceについて振り返りたい方はこちらの記事を参考にしてください。

【最新】SalesforceのAgentforceとは?機能や価格などを徹底解説

目次

Agentforceのサブエージェント(旧トピック)とアクションとは

Agentforceではサブエージェントとアクションを適切に切り分けて設計することが重要です。これら2つの役割を混同したまま設計を進めると、会話の流れと業務処理の実行が不安定になることがあります。

サブエージェントは「どのような目的・テーマの会話か」を定義する要素です。ユーザーの発話をどの話題として扱うかを決める枠組みとして機能します。一方、アクションは「実際に何を実行するか」を定義する要素です。サブエージェントの中で必要となる処理を動かす役割を担います。

このようにサブエージェントとアクションは役割が明確に異なります。そのため、それぞれを別の設計要素として整理しておくことが大切です。

本章ではサブエージェントとアクションの違いと役割を具体的に解説します。

Agentforceのサブエージェント(旧トピック)とは

Agentforceのサブエージェントとはエージェントが「どのような相談を扱うのか」を定義するための枠組みです。ユーザーの発話をどの目的の会話として処理するかを判断する起点となるため、サブエージェントの設計はエージェントの応答精度に大きく関わります。

サブエージェントでは単に名前を設定するだけでは不十分です。どのような相談を対象とするのかを明確にしておく必要があります。具体的にはサブエージェント名や分類の説明、対応範囲、会話の進め方に関する指示などを整理して定義します。こうした内容が曖昧なままだと、似た内容のサブエージェントとの違いが分かりにくくなり、意図しないサブエージェントが選ばれる原因になります。

特に複数の目的を1つのサブエージェントに含めてしまうと、ユーザーの意図とは異なる会話に進みやすくなります。そのためサブエージェントは「1つの目的ごと」に分けて設計することが重要です。どの相談を扱うのか、反対にどの相談は扱わないのかを明確にすることでエージェントは適切なサブエージェントを選択しやすくなります。

Agentforceのアクションとは

Agentforceのアクションとはサブエージェントの中で実行される具体的な処理のことです。フローやApexなどと連携し、実際の業務処理を実行する役割を担います。

アクションは会話の中で判断された内容をもとにデータの取得・更新・登録といった処理を行うための仕組みです。そのためアクションの設計が曖昧なままだと、どの条件で処理を実行するのか、どのような結果を返すのかが不明確になり、エージェントの安定性や信頼性に影響することがあります。

特に重要なのが「指示」「入力指示」「出力指示」を整理しておくことです。単に何をするアクションなのかを決めるだけでなく、実行に必要な情報は何か、結果をどのように返すかまで明確にしておくことでアクションの品質は大きく向上します。

こうした内容をあらかじめ定義しておくことで、エージェントは状況に応じて適切なアクションを実行しやすくなります。

Agentforceのサブエージェント(旧トピック)とアクションの役割

サブエージェントは「ユーザーの目的や相談内容」を定義する枠組みであり、アクションは「その中で実行する処理」を担う要素です。両者は役割が異なりますが、組み合わせて設計することで、エージェントの一連の動作が成り立ちます。

具体的にはユーザーの発話内容をもとに適切なサブエージェントが選ばれ、そのサブエージェントの中で必要なアクションが実行されます。こうして会話の開始から必要な処理の実行、回答や完了までの流れが構成されます。この流れが自然に機能することで、エージェントはユーザーの目的に沿った対応を行いやすくなります。

一方でサブエージェントとアクションの役割が曖昧なままだと、どの会話でどの処理を行うべきかが分かりにくくなります。その結果、意図しない処理が実行されたり、不自然な会話の流れになったりすることがあります。そのため両者の役割を明確に分けて設計することが重要です。

ここではAgentforceにおけるサブエージェントとアクションの関係性と、それぞれの役割の違いを解説します。

Agentforceのサブエージェント(旧トピック)で決めること

サブエージェントではまずユーザーの目的をできるだけ小さな単位で切り分けることが重要です。複数の目的が1つのサブエージェントに含まれていると、どのサブエージェントを選ぶべきかが曖昧になり、会話の精度が下がる原因になります。

またサブエージェントごとに対応範囲を明確にし、「できること」と「できないこと」をあらかじめ定義しておく必要があります。これにより意図しない案内や不要な処理の実行を防ぎやすくなります。合わせて会話の進め方を示す指示についても複雑に書きすぎず、短い手順で分かりやすく整理することが大切です。

こうした内容を整理しておくことでサブエージェントは単なる分類ではなく、会話の流れを安定して進めるための設計要素として機能します。

Agentforceのアクションで決めること

アクションは1つの機能に絞って設計することが基本です。複数の処理を1つにまとめてしまうと実行条件が複雑になり、意図しないタイミングで処理が動く原因になります。

またアクションでは入力情報を明確に定義しておく必要があります。どの情報が必須なのか、不足している場合にどのような追加質問を行うのかをあらかじめ決めておくことで、処理の安定性を高めやすくなります。合わせて出力の形式もできるだけ統一し、返す値や構造を一定にしておくことでユーザーにとって分かりやすい応答につながります。

このように入力・処理・出力を一貫して設計することが、安定したアクションの実装につながります。

AgentforceでAIエージェント作成時にサブエージェント(旧トピック)とアクションの設計が重要な理由

Agentforceでエージェントを設計する際はサブエージェントとアクションの設計が重要です。サブエージェントはエージェントの役割や対応範囲を定義し、アクションは目的を達成するために実行する処理を担います。これらが曖昧なままだと会話の流れと業務処理がうまく結びつかず、ユーザーの意図に沿わない応答や不正確な処理につながることがあります。

一方でサブエージェントとアクションを適切に設計できていれば、エージェントは単に会話を返すだけでなく、業務に沿った対応を行いやすくなります。会話の目的を適切に捉え、その目的に合った処理を実行しやすくなるためです。本章では設計が重要となる理由を3つの観点から整理して解説します。

エージェントの目的と会話の方向性を明確にするため

エージェントの目的が曖昧だったり、1つのサブエージェントに広すぎる内容を含めていたりするとどの会話として扱うべきかの判断がぶれやすくなります。その結果、本来選ばれるべきサブエージェントではなく別のサブエージェントやアクションが選ばれ、会話の方向性がずれてしまうことがあります。

例えば「注文について確認したい」という発話があった場合でもその内容が注文状況の確認なのか、返品の相談なのか、配送先変更の依頼なのかによって進めるべき会話は異なります。

こうした違いを適切に捉えるにはサブエージェントを大きなくくりでまとめるのではなく、目的ごとに切り分けて設計することが重要です。目的単位でサブエージェントを分けておくことで、ユーザーの意図をより正確に捉えやすくなります。

つまりサブエージェントは単なる分類ではなく、会話の入口を定める重要な設計要素です。目的ごとに切り分けておくことが、Agentforceの精度を高めるうえで重要になります。

ビジネスプロセスを確実に実行するため

アクションは会話の中で必要になった処理を実行する要素です。そのため入力情報が不足したまま、あるいは誤った値のまま実行されると、業務に直接影響を与える可能性があります。例えば注文番号が不足した状態で注文情報を検索しようとすると、誤った結果が返ってくるだけでなくその後の対応までずれてしまうおそれがあります。

こうした問題を防ぐには「指示」「入力指示」「出力指示」を具体的に設計することが重要です。どのような処理を行うアクションなのかに加えて、何の情報が必要なのか、不足している場合にどのような確認を行うのか、どの形式で結果を返すのかまで明確にしておく必要があります。

これによりエージェントは実行前に必要な確認を行いやすくなり、不完全な状態で処理を進めてしまうリスクを減らしやすくなります。

業務で利用するエージェントでは会話が自然であることだけでは十分ではありません。必要な確認を行ったうえで、正しい処理を正しい順序で実行できることが重要です。その土台となるのが具体的なアクション設計です。

エージェントの柔軟性・再利用性・信頼性を高めるため

Agentforceを場当たり的に拡張していくと似たサブエージェントやアクションが増え、どれを使うべきか分かりにくくなります。その結果、管理が複雑になり誤った選択や重複した設計が起こりやすくなります。

こうした状態を防ぐには最初の段階で命名ルールをそろえ、目的ごとにサブエージェントを分け、あとから見直しやすい構造にしておくことが大切です。アクションについても1つの機能ごとに整理しておけば、別のサブエージェントでも再利用しやすくなります。

また定期的に棚卸しすることを前提に設計しておけば、不要になったサブエージェントや重複したアクションを見つけやすくなり、全体の品質も保ちやすくなります。

このようにサブエージェントとアクションを整理して設計することは目の前の実装を進めやすくするだけでなく、将来的な拡張や改善にもつながります。柔軟性や再利用性、信頼性を高めるためにも初期の段階から構造を意識して設計することが重要です。

Agentforceのサブエージェント(旧トピック)とアクションの設計前に決めること

サブエージェントやアクションをいきなり作り始めると後から構造が崩れやすくなり、修正に手間がかかりやすくなります。そのため実装に入る前に「何を実現したいのか」「どのような流れで処理されるのか」を整理しておくことが重要です。

ここで行うのは設計に入る前の準備です。利用者の目的を明確にし、その目的を達成するための業務フローを整理し、さらに実行する処理の単位まで分解していきます。こうした流れを踏むことでサブエージェントの指示やアクション設計に必要な材料がそろい、後の工程で迷いにくくなります。

本章ではAgentforce Builderで設定を始める前に整理しておきたい設計の前提について解説します。

利用者の目的を1つに定義する

Agentforceでは1つのサブエージェントに対して1つの目的を対応させることが基本です。そのため、最初にこの整理を行っておくことが重要です。

ポイントは会話のゴールを1文で言い切れる状態にすることです。例えば「修理依頼を完了したい」「注文状況を確認したい」といったように、ユーザーが最終的に達成したい状態を具体的に表現します。この定義が曖昧なままだとサブエージェントの範囲が広がりすぎたり、異なる目的が1つの中に混在したりする原因になります。

目的を1つに絞ることでサブエージェントの役割が明確になり、その後の設計も進めやすくなります。ここで「1つの目的に対して1つのサブエージェントを対応させる」という原則を明確にしておくことが、全体設計を安定させるうえで重要です。

目的達成までの業務フローを整理する

ポイントは実際の業務で人がどのような手順で対応しているかを書き出すことです。

例えば問い合わせ対応であれば、「ヒアリング→内容確認→案内→記録」といった形で処理の流れを順番に整理します。このように手順を可視化することで会話をどのように進めるか、どの場面で何を確認する必要があるかが明確になります。

この業務フローはそのままサブエージェントの指示を設計する際の土台になります。どの順番で質問し、どのタイミングで判断や処理を行うのかを具体化しやすくなるため、会話設計の精度を高めることにつながります。

業務フローを実作業に分解してアクション候補にする

整理した業務フローをもとに、次はアクションとして実装する処理を洗い出します。ポイントは各ステップを「Salesforceで何を行うのか」という観点で分解することです。

例えば「内容確認」の工程であればデータの検索、「条件判断」であれば判定処理、「対応実行」であればレコードの作成や更新といったように、具体的な処理単位に落とし込んでいきます。このように整理することでどの部分をアクションとして実装すべきかが明確になります。

ここで洗い出した処理がそのままアクションの候補になります。さらにそれぞれの処理をフローなどと連携させることで、Agentforce上で実行できるアクションとして設計しやすくなります。この段階で処理単位まで整理できていれば、後からの実装や調整も進めやすくなります。

Agentforceのサブエージェント(旧トピック)とアクションの作り方

実際の作成は思いついた要素を順番に追加していくよりもサブエージェントや必要に応じたフロー、アクション、テストという流れで進めたほうが手戻りを減らしやすくなります。特に会話の目的と実行する処理の関係が曖昧なまま作り始めると、後から修正が連鎖しやすくなるため注意が必要です。

Agentforceでは最初にサブエージェントの骨格を固め、その中で必要な処理をアクションとして組み込み、最後に実運用を想定した会話へ調整していく進め方が基本になります。この順番で進めることで会話設計と業務処理のつながりを保ちながら、無理なくエージェントを作りやすくなります。

本章ではAgentforceのサブエージェントとアクションを効率よく形にするための流れを整理します。

①作成前に押さえるポイント

作成前の段階では推論エンジンにどの情報が影響するのかをあらかじめ整理しておくことが重要です。サブエージェント名や分類の説明、対応範囲、アクションの指示などはそれぞれ役割が異なります。役割を十分に理解しないまま入力すると、似たサブエージェントとの違いが分かりにくくなったり、必要なアクションが適切に選ばれなかったりする原因になります。

そのため作成前には「どこに何を書くと、どの判断に影響するのか」を意識しておく必要があります。最初に設計の要点を押さえておくことで、後の工程で説明文や処理条件を何度も見直す手間を減らしやすくなります。

サブエージェント名・分類の説明は「目的が一言で伝わる」ように書く

サブエージェント名や分類の説明は見たときにどのような目的の相談を扱うサブエージェントなのかが分かる状態にしておくことが重要です。抽象的な表現を使うと似た内容のサブエージェントとの違いが分かりにくくなり、選択精度が下がる原因になります。

例えば「問い合わせ対応」のような幅広い表現ではなく、「注文状況の確認」「返品受付」「配送先変更」のように、想定される質問や主要な語句を含めた具体的な表現にしたほうが、意図は伝わりやすくなります。

また似たサブエージェントが複数ある場合は、どの相談を対象とするのかが一目で区別できるように書くことも大切です。名称と説明の具体性が高いほど推論エンジンは適切なサブエージェントを選びやすくなります。

サブエージェント(旧トピック)の範囲は「できる/できない」を先に決めて明記する

サブエージェントを設計する際は何を扱うのかだけでなく、何を扱わないのかまであらかじめ決めておくことが重要です。対応範囲だけを定義しても、対象外とする範囲が曖昧なままだと似た内容の相談まで同じサブエージェントで扱ってしまう可能性があるためです。

例えば注文状況の確認を扱うサブエージェントであれば、返品やキャンセルは別のサブエージェントで対応するのか、それとも有人対応へ切り替えるのかを明確にしておく必要があります。対応しない内容まで言語化しておくことで、誤ったサブエージェントの選択や案内を防ぎやすくなります。

このようにサブエージェントの範囲をあらかじめ定義しておくことが、会話の安定性を高めるうえで重要になります。

アクションは「指示・入力指示・出力指示」をセットで具体化する

アクションは処理名だけを決めて終わりにするのではなく指示や入力指示、出力指示まで含めて具体的に整理することが重要です。何を行うアクションなのかに加え、どの情報が必要でどの形式で結果を返すのかが曖昧なままだと実行結果が安定しにくくなるためです。

例えば注文情報を取得するアクションであれば、注文番号が必須なのか、不足している場合にどのように確認するのか、返却結果は一覧で返すのか要約して返すのかまで整理しておく必要があります。入力不足のときの確認ルールまで定義しておくことで、不完全な状態で処理が実行されるリスクを抑えやすくなります。

②サブエージェント(旧トピック)を作る

サブエージェントの骨格ができたら、次はその目的を達成するために必要なアクションを追加していきます。ここではサブエージェントの中でどのような処理が必要になるのかを整理し、フローや既存の処理と紐づけながら実装していくことになります。

重要なのは追加するアクションの役割がサブエージェントの目的に合っているかを確認することです。例えば注文状況の確認を目的とするサブエージェントに返品受付用のアクションを入れてしまうと、会話の目的と処理内容にずれが生じます。

アクションを追加する際は「このサブエージェントの中で本当に必要な処理か」という視点で見直すことが大切です。目的と処理の対応関係が明確であるほど、会話から実行までの流れは安定しやすくなります。

③会話で使える形にする

サブエージェントとアクションは作成しただけですぐに自然な会話になるとは限りません。実運用を見据える場合はユーザーに見せる情報と見せない情報を整理し、返答の仕方や確認質問の順序まで調整しておく必要があります。

例えば内部では複数の判定や処理が行われていても、ユーザーには必要以上の情報を見せないほうが分かりやすいことがあります。また確認質問の順番が不自然だと、処理自体は正しくても会話の体験は損なわれやすくなります。

そのため実際の対話を想定しながら、「どのように聞くか」「どのように返すか」「どの順番で確認するか」を整えることが重要です。こうした点まで丁寧に調整しておくことで、業務処理だけでなく会話全体の体験も安定しやすくなります。

④テストして直す

最後に作成したサブエージェントとアクションが想定どおりに動くかをテストしながら調整します。テストでは正常に進むケースだけでなく、失敗するケースや判断が分かれやすいケースも確認することが重要です。問題なく動く場面だけを見ていると、実運用で起きるずれを見落としやすくなるためです。

例えば入力情報が不足していたり似た内容の相談が来た場合、想定していない表現で質問された場合などを試しながら、どこでずれが生じるのかを確認します。問題が見つかったときは、アクションだけを修正するのではなくサブエージェントの説明や対応範囲、指示、入力条件、出力形式までさかのぼって見直すことが大切です。

このようにテストと修正を繰り返すことで、Agentforceは実運用でも安定して使える形に近づいていきます。

Agentforceのサブエージェント(旧トピック)とアクションでよくある失敗と対処法

実装初期では一見すると問題なく動いているように見えても、実運用に入るとサブエージェントの選択ミスやアクションの誤実行、出力内容のばらつきといった問題が生じることがあります。

こうした問題は設計段階での曖昧さが原因になっていることが多く、どこを見直すべきか分かりにくい点にも注意が必要です。本章ではAgentforceのサブエージェントとアクション設計で起こりやすい失敗と、その具体的な対処法を解説します。

サブエージェント(旧トピック)がズレるときは、目的単位で分けて説明を具体化する

サブエージェントが意図したとおりに選ばれない場合、その多くは「目的の粒度が大きすぎる」「説明が抽象的すぎる」といった設計上の問題にあります。

例えば複数の目的を1つのサブエージェントにまとめていると、ユーザーの発話に対してどのサブエージェントを選ぶべきかが曖昧になりやすくなります。また「問い合わせ対応」のような抽象的な表現では、似た内容のサブエージェントとの違いが分かりにくくなります。

このような場合はサブエージェントを目的ごとに分割し、「誰が、何をしたいのか」が伝わるように説明を具体的にすることが重要です。目的ごとに明確に切り分けておくことで、サブエージェント選択の精度を高めやすくなります。

アクションがズレるときは、単機能にして指示・入出力を明確にする

アクションの実行内容がズレる場合は、1つのアクションに複数の役割を持たせていないかを見直すことが重要です。

複数の処理を1つにまとめているとどの条件で何を実行するアクションなのかが曖昧になり、意図しない場面で選ばれたり、想定と異なる処理が実行されたりしやすくなります。

対策としてはアクションを1つの作業に絞ったうえで、「何をするアクションなのか」「実行に何の情報が必要なのか」「どのような結果を返すのか」を具体的に定義することが大切です。

あわせて入力が不足している場合にどのような確認を行うのか、どの形式で結果を返すのかまで整理しておくことで選択条件と実行内容のずれを抑えやすくなります。

変数が空になるときは、必須入力と不足時の質問を決める

変数が空のまま処理が進むとエラーや不正確な結果につながるだけでなく、その後の処理にも影響が及ぶことがあります。

この問題は「どの情報が必須なのか」が明確になっていないことが原因になる場合が多くあります。必要な入力が定義されていないと、エージェントが情報不足に気づかないまま処理を進めてしまうことがあります。

対策としては必須項目を明確にし、不足している場合は追加で確認するルールをあらかじめ決めておくことが重要です。合わせてフロー側の入力変数と出力変数の設定も確認し、データの受け渡しに問題がないかをチェックします。入力条件を整理しておくことで、処理の安定性を高めやすくなります。

出力がズレるときは、出力形式を固定して参照データを見直す

出力の形式が毎回異なるとユーザーにとって分かりにくくなるだけでなく、エージェント全体の品質にも影響します。

このような問題は出力形式があらかじめ定義されていない場合や参照しているデータの範囲や内容が適切でない場合に起こりやすくなります。特にどの情報をもとに回答しているのかが曖昧だと、結果に一貫性が出にくくなります。

対処としては「結論→理由→次の案内」のように出力の型を決め、どのような構成で返すのかを明確にしておくことが重要です。また参照するナレッジやデータの範囲が、そのサブエージェントの目的に合っているかを見直すことも欠かせません。出力のルールをそろえておくことで応答の品質は安定しやすくなります。

まとめ

Agentforceにおけるサブエージェントとアクションはそれぞれ役割が明確に異なります。サブエージェントは、ユーザーの相談をどの目的の会話として扱うかを定義する枠組みであり、アクションは、その中で実際に必要な処理を実行する要素です。

この切り分けが曖昧なままだと会話の方向性と業務処理がうまく結びつかず、エージェント全体の精度が不安定になりやすくなります。そのため設計段階で両者の役割を明確に分けておくことが重要です。

設計のポイントとしてはまず目的をできるだけ小さな単位でサブエージェントに分けることが挙げられます。あわせて、アクションは1つの機能ごとに整理し、入力と出力を明確にしておくことも大切です。さらに最初から複雑な構成を目指すのではなく、小さく作ってテストを重ねながら改善していく進め方が適しています。

これらを意識して設計を進めることでAgentforceは会話への応答だけでなく、業務処理まで含めて一貫して対応できるエージェントとして機能しやすくなります。実運用で安定した成果につなげるためにもまずはシンプルな構成から始め、段階的に精度を高めていくことが重要です。

またAgentforceを始め、自社でSalesforce製品を上手く使っていけるか、全体最適化についてご相談をしたいというご担当者様は、ぜひ一度弊社ストラへお問い合わせくださいませ。

ストラでは、各社様が実現したい業務フローや体制をヒアリングした上で、Salesforce製品を活用していくその先のゴールまでを踏まえ、適切なSalesforceの環境設定や運用を支援いたします。

ストラのSalesforce導入支援や定着化支援、開発支援についてさらに詳しく知りたい方はこちらのページで紹介しています。

Salesforce、Sales Cloud、及びその他はSalesforce, Inc.の商標であり、許可のもとで使用しています

Agentforceの導入や活用のお困りごとはプロにご相談ください

  • Agentforceのサブエージェントとアクションの役割分担が曖昧で、どこまでをサブエージェントとして切り分けるべきか分からない
  • サブエージェントやアクションの設計が原因で、意図しない会話や誤った処理が実行されてしまう
  • Agentforceを拡張するたびにサブエージェントやアクションが増え、管理・再利用・運用改善が難しくなっている
このようなお困りごとがありましたら、ぜひとも私たちStrhにご相談ください。Salesforceや営業・マーケティングに精通したコンサルタントが、御社に最適なソリューションをご提案させていただきます。まずはお気軽にお問合せください。 Salesforce活用についてまずは相談する

執筆者 取締役 / CTO 内山文裕

青山学院大学卒業後、株式会社ユニバーサルコムピューターシステムに入社。
大手商社のB2B向けECサイトの構築にて会員登録、見積・注文機能、帳票出力などECにおける主要機能のフロント画面・バックエンドの開発に従事。 その後アクセンチュア株式会社に入社。デジタルコンサルタントとしてWebフロントエンド・モバイルアプリの開発やアーキ構築を主に、アパレル・メディア・小売など業界横断的にシステム開発を支援。また、ビッグデータを活用したマーケティング施策の策定やMAツールの導入・運用支援にも従事。
2022年2月にStrh株式会社の取締役CTOに就任。デジタルプロダクト開発の支援やMAツール導入・運用支援を行っている。

▼保有資格
Salesforce認定アドミニストレーター
Salesforce認定Java Scriptデベロッパー
Salesforce 認定Data Cloudコンサルタント

この記事をシェアする

x facebook
To Top