
aptpod Advent Calendar 2025 12月1日の記事です。
みなさまお久しぶりです。アプトポッドで営業企画をしている神前(こうさき)と申します。
前回から1年ぶり、5年連続でAdvent Calendarのトップバッターです。甲子園でいったらそこそこ強豪ですね。
今年も懲りずにSalesforceネタで書いていきたいと思います。メインの業務がそれだから仕方ないね。
今年やったこと
この1年間でやったことのうち、大きなトピックとしては、「エンドユーザー向けマイページ」の公開でしょうか。

Salesforceには「Experience Cloud」という機能があり、社内で利用しているSalesforce環境と連携した外部ユーザー向けWebサイトをつくる事が可能です。
使い方は様々で、
- セールスパートナー企業向けのサイトをつくり、商談情報を直接パートナーに入力してもらう
- エンドユーザー向けのサイトをつくる、FAQやお問い合わせ機能をもたせ、エンドユーザーに直接ケースを起票してもらう
- 会員専用ページをつくり、いわゆるコミュニティを形成する
- 他
といったことが利用法として想定できます。
今回のケースは「エンドユーザーが当社製品の契約状況や、具体的な利用状況を(当社の営業等を介さずに)直接確認することができるサイト」となります。
そんな機能(ツール)があるのを知らなかった!知ってたけどどう使っていいかわからない!みたいな方がいたら本記事は少しは役に立てるかもしれません。
エンドユーザー向けマイページ作成の経緯
当社の主力製品である「intdash」をご利用いただくにあたり、いくつかのプランからお客様の用途に合ったものを提供しています。これまでも提供プランそのものについては何度か変更があったのですが、現時点での最新バージョンからは「瞬間的なデータ流量の最大値」から「1ヶ月間でのトータルのデータ流量」を元に提供をする形になっています。
必然的に、お客様からすると「月にどれだけ使えるプランにしたのか」と「今月はあとどれだけ使えるのか」を確認できないといけません。
そうした情報をどこでみれるようにするのかについてはいくつか候補はあったのですが、最終的にSalesforce上(=Experience Cloudで作成したサイト)でみれるようにすることとなりました。
ちょうど弊社が利用しているMVNO事業者の各SIMの利用状況を確認するサイトがSalesforceで作られていることがわかっていたので、そちらをベンチマークとして作成をすすめていきました。
設計
当社はBtoB企業ですので、エンドユーザーといっても一般消費者ではなく企業が対象となります。
どういった項目を見れるようにするのか、どういう風に見せるのか、といった内容については営業側、開発側と何度か打ち合わせをしながら詰めていきました。
特に、そもそものデータ(A社が◯月◯日に◯Gデータを消費した)の大元がSalesforce内にあるわけではないので、当社の場合は大元のデータがあるAWSからAPIでSalesforceへデータを流し込む部分については開発側におんぶにだっこの状態でした。
AWS側でどういう風にデータを持っているのか、どんなデータを持っているのか(逆に、どんなデータは持っていないのか)によってSalesforce側で追加で何をすることが必要なのかが変わってくるのでこのあたりは特に大変だったように記憶しています。
ただ、一回決まってしまえばやることは明確なので、AWS側からデータを流し込む先(=各項目)を用意して、AWS側では持っていないデータ(そのデータがどのエンドユーザーなのか、どういう契約なのか、等)についてはSalesforceで持っているデータと組み合わせて補完するためのフローを構築する形となります。そこの領域については自分の領域なのであーでもないこーでもないと頭を使いながら設計していきました。
さて、そういった「データをどこからもってくるのか」、「何を見せるのか」といった部分については割と大変というか、営業側(データを見るお客様に一番近い立場)と開発側(データを持っているシステムに一番近い立場)の両方と関わりながらすすめていくので結構おおがかりになるのですが、サイト自体はそれほど複雑だったり、特別なことをしているわけではありません。
サイト内に各種タブがあり、各タブ内で表示する情報や表現方法に違いはあるものの、基本は「ダッシュボード」と「レポート」を埋め込んでいるだけです。
つまり、日常的にこの2つを利用しているのであれば多少の工夫は必要なものの、おおよそ同様のものはつくれるものと思います。
ちょっとしたポイント
どんなデータをどう見せるのか、どこからデータを持ってくるのかといった点は各社さんが持っているデータやどういう目的でどういう属性の人に見せるのかでケースバイケースなのであまり参考になるお話は書けないのですが、どう見せるのかの部分についてはちょっとしたポイントが参考になると思うので書きたいと思います。
使っているのはダッシュボードとレポートの2種類とすでに記載していますが、普段から使っている方はご存知の通り、これらをそのまま使うだけでは「見る人によって見せるものを変える(=動的に見せる)」というのはできません。ですが、実はユーザー側にちょっとしたことをすると実現できるのです。
言葉だけで説明をすると複雑になるので、図をいれていきます。
以下のようなケースを想定します。
■レポートで、とあるレコードa(にある情報)をXさんにのみ見せるようにしたい
各レコードとオブジェクト、項目の関係を表したのが下記の図です。わかりやすくするためYさんも図にいれています(XさんとYさんは別の企業)。XさんとYさんは別々の企業なのでXさんに見せたいものはYさんには見えてはいけないですし、その逆も然りです。

そこで、オブジェクトAとユーザーにそれぞれ項目αと項目Zを作成します(ここでのユーザーは、設定画面から見る方のユーザーです)。 ※ユーザーXやYにアカウントの払い出しをしているという想定です。


これらの項目のデータ型はなんでもよいのですが、テキストが無難です(一意にできるのであれば数値とかでも可)。
その後に、オブジェクトAにのみ項目βを作成し、データ型を「数式」、数式の戻り値のデータ型を「チェックボックス」にして以下のような数式を設定します。
[項目α] = $User.[項目Z]

あとはそれぞれ項目αと項目Zに一意になるような値を入力すればOKです(もちろんαとユーザーXの項目Zは同じ値にするようにする)。
最後にレポート側の「検索条件」に「項目β=true」としてあげれば全て完了です。

仮に、レコードaの項目αに「AAA」という値をいれ、ユーザーXの項目Zに同様に「AAA」、ユーザーYの項目Zには「BBB」という値をいれます。 ※項目α、項目Zには管理者側からしか値をいれることができないようにしてあります。
ユーザーXがサイトにログインをすると項目βに入力した数式が成立し、チェックボックスがはいるためレポートを閲覧した時にレコードaの情報を閲覧できます。一方で、ユーザーYがサイトにログインしても項目βの数式は成立しないのでチェックボックスは入らずレポートでレコードaの情報を閲覧することはできません(そもそもでてこない)。


これで、同じサイトに同じレポート、同じダッシュボードを貼り付けたとしてもユーザーによって見せたいデータを変えるという動的な見せ方が可能になります。
補足
上記のやり方で動的にレポートをみせることはできるのですが、当社の場合は運用面を考慮して少しゆるくしています。
例えば、今回ユーザーXとユーザーYは別々の会社という設定にしていますが、同じ会社に所属していて、XとY両方に同じ情報をみせる必要がある場合を考えてみましょう。その場合、ユーザー側の項目Zが完全に一意であってはXかYのどちらかにしか情報をみせられません。こうした状況を想定しなくてよい場合(レコードaは常に一人のユーザーにしか見せる必要がない)であればもっと機械的にシンプルにすることも可能でしょう。
また、当社の場合、オブジェクトA内のレコードは毎日毎日増えていきます(毎日のデータ使用量のデータなので当然ですね)。レコードが増えるたびに項目αに手作業で値をいれていくことはできないのでフローを活用しています。詳細は省きますが、さらに大元となるデータをもっておいて、オブジェクトAにレコードが作成された際に、キーとなる値を使って大元から項目αにいれるべき値をもってきて上書きする、という感じです(テキストだとわかりにくいですが・・・)。これもオブジェクトA内のレコードそのものがそんなに増えないような運用であればそこまでしなくてもよいので、どこまでやるか、というのは運用次第という感じですね。
見せ方について
ここまでできたらあとは事前に決めていた通りにダッシュボードやレポートを調整していけば完成です。
どの情報をどのように見せるのか、グラフにするのか、グラフでも棒グラフなのか円グラフなのか、あるいは表形式にするのかといった点は見せたいデータによって変わるので最適と思われる表現方法にしてもらえればよいと思います。
当社の場合は日々のデータ使用量の推移を見せたいので、棒グラフとしています。

期間やそれ以外の項目である程度絞り込んだり、グラフの表現形式をある程度ユーザー側で調整できるのはよいですね。
それとは別に、トップページでは表形式にすることで複数のデータを網羅的に見れるようにしたり、トップページなのでお知らせの枠や当ページの操作マニュアルへのリンクを掲載しています。

作ってみてよかったこと
今年の4月に本サイトをオープンし、徐々にお客様にも使っていただいています。まだまだ改善の余地はありますし、実際に社内からも改善要望もあったのでそこは対応をしつつ、もっと便利に、もっと使いやすくしていければと考えています。
個人的にやってよかったなと思った点を最後に記載したいと思います。
当社では年に数回イベントに出展をしています。
【参考】
- メンテナンス・レジリエンス TOKYO 2025 見学レポート
- 片手サイズ × 高速起動 ── EDGEPLANT R1 & CAN FD USB Interface[人とくるま展2025展示レポート]
ブース内でデモを展示することもあるわけですが、その際に、どれだけ実際に通信量を消費するのかを本サイトの社内向けのものを使ってその場で営業メンバーが確認していました。デモとはいえ、こういう風にintdashを使って、これぐらいの時間使うとこれぐらいの使用量になるのか、というのを開発側の手を煩わせることなくその場ですぐに確認できるというのは、地味ではあるものの自分がなにがしかに貢献できたのではないかと感じました。
普段の仕事柄、あまり派手な何かをするというよりも、こうした地味な改善の積み重ねが業務の大半なので、実際に使ってもらってるシーンを見れてよい経験でした。
まとめ
長くなってきたのでそろそろ締めたいと思います。
昨年とは違いTips寄りの記事を今年は書いてみました。細かい注意点(項目ごとのアクセス権限の設定とか)は書ききれないほどあるのですが、マニアックになるので今回は省きました。
そういった点よりも、Salesforceで普段使っているレポートやダッシュボードとExperience Cloudを組み合わせればこんなこともできるんだ、ということをおわかりいただければ幸いです。
現在は何をしているかと言うと、Salesforceの提供している自立型AIエージェント「Agentforce」の活用を試みています。
とはいえ、いきなり使えるというとそういうわけでもないので、まずはSalesforceに社内のいろんな情報を集約できるように地ならしをやっています。
来年にはAgentforceを活用してこんなことができるようになったよ!みたいな記事を書けるようにやっていきたいと思います。
本記事が少しでも参考になっていると幸いです。
それではまた1年後にお会いしましょう!