大企業の顧客管理システム選びは、機能の多さではなく、数百名から数千名が同じ顧客データに触れる前提で破綻しないかで決まります。この記事では、大企業向けCRMに特有の要件を、部署と項目で閲覧範囲を分ける権限設計、連携処理が消費するAPI上限とデータ量、海外拠点と個人情報保護法の3つに分けて整理しました。グループ会社の取引先を法人番号で名寄せする方法や、Dynamics 365の24時間あたり要求数の実数も公式資料から示し、パッケージの設定で済む条件と導入支援を入れるべき条件まで判断を言い切ります。
まとめ：大企業の顧客管理システムは権限・データ量・海外拠点の3要件で選ぶ
大企業の顧客管理システムで中小企業と違うのは、利用者の数そのものより、部署・グループ会社・海外拠点という組織の層が顧客データに重なる点です。選定では、製品の機能一覧を比べる前に、自社の組織図をそのまま権限の階層として表せるかを確かめてください。
見落としやすいのは連携の量です。基幹システムやMAとの同期は、人が画面で操作するよりはるかに多くのAPI要求を使います。Dynamics 365では連携用アカウントがテナント全体で1つの上限枠を共有するため、事前の見積もりが要ります。海外子会社が日本の顧客データを見る運用は、個人情報保護法28条の確認対象です。
SalesforceやDynamics 365の標準機能で大半の要件は満たせます。導入支援や開発を入れるべきなのは、権限の例外が多い、連携が双方向、海外拠点を含めて段階展開する、のいずれかに当てはまる場合です。
大企業の顧客管理システムが中小企業向けと分かれる、利用者数と組織構造の違い
中小企業のCRMでは、入力の定着と月額費用が選定の中心でした。その論点は中小企業向けCRMの選び方と低コスト製品の判断基準で扱っています。大企業では、論点が「誰に何を見せないか」と「全社のデータをどう揃えるか」に移ります。
利用者が数百名を超えると重くなるライセンス費と専任管理者の体制
顧客管理システムの費用はユーザー単価×人数で増えるため、利用者が500名を超えると月額単価の数百円の差が年間数百万円の差になります。全員に同じエディションを配る必要はなく、閲覧中心の利用者には下位ライセンスを割り当てる設計で総額を抑えられます。Dynamics 365では、商談を扱う営業はSales Enterprise、参照だけの部署はTeam Membersという分け方が典型です。
もう一つの変化は管理の手間です。部署の新設、異動、退職のたびに権限を付け替える作業が週単位で発生し、兼務の情報システム担当では回りません。利用者300名前後を目安に、専任の管理者を最低1名置く前提で計画してください。単価と人数から総額を出す方法は顧客管理システムの費用相場と3年総額の試算にまとめています。
グループ会社と複数事業部が同じ顧客を別々に持つことで起きる重複
大企業では、ある取引先に対して事業部Aが製品を、事業部Bが保守を、グループ会社Cが別サービスを売っている状態が珍しくありません。それぞれが自分の顧客台帳を持つと、同じ会社が「株式会社〇〇」「〇〇（株）」「〇〇 東京支店」として3件登録され、取引の全体像を誰も把握できなくなります。
大企業が顧客管理システムを統合する目的の多くは、この重複の解消です。逆に言えば、統合後も事業部ごとに別のデータベースを持たせる設計では、導入費をかけても効果が出ません。取引先は全社で1件、そこに各事業部の商談と担当者がぶら下がる構造を最初に決めます。
大企業の顧客管理システムに要る権限設計｜部署・ロール・項目の3階層で考える
大企業の要件で最も設計の手間がかかるのが権限です。公式資料が詳しいDynamics 365の基盤（Dataverse）を例に、部署・ロール・項目の3階層で整理します。Salesforceにもロール階層、共有ルール、項目レベルセキュリティという同じ役割の機能があり、考え方は共通です。
部署の階層で閲覧範囲を区切るビジネスユニットとロール階層の設計
Microsoft Learnの所有権ベースのセキュリティの解説（2026年10月5日更新）では、ユーザーを必ず1つの部署（ビジネスユニット）に所属させ、セキュリティロールで「自分のレコードだけ」「部署内」「配下の部署まで」「組織全体」のどこまで読めるかを決めます。部署の木構造は組織図と一致させなくてもよい、とも明記されています。
設計で効くのは、同じ資料にある「権限は累積し、最も広いアクセスが勝つ」という規則です。あるロールで組織全体の閲覧を許すと、別のロールで特定の顧客を隠すことはできません。権限は狭いロールを足していく形で組み、広いロールを例外で削る形にしないでください。複数の事業部を兼務する社員には、部署ごとにロールを持たせる「複数部署の所有権」の設定を使います。
部署をまたぐ協業案件の共有設定と、例外の個別共有が増えすぎる失敗
事業部Aの商談に事業部Bの技術者が参加する、といった部署をまたぐ協業は、レコード単位の共有で処理します。ただし同じ資料は、共有はロールベースのアクセスより性能が低く原因調査も難しいため、例外にだけ使うよう求めています。個人ごとに共有するより、チームに共有するほうが効率的だというのも、同じ資料の説明です。
大企業の導入で起きる典型的な失敗は、部署の階層を細かく作りすぎ、その結果あらゆる案件で個別共有が必要になる状態です。共有の件数が増え続けるなら、階層の切り方を見直すべき合図です。営業の地域単位で見せたいならSalesforceのテリトリー管理のように、組織図とは別の軸を持つ機能で表すほうが運用は軽くなります。
個人情報の項目だけを隠す列レベルの制御と人事異動時の権限付け替え
同じ顧客でも、営業は連絡先と商談を見られるが、コールセンターの委託先は契約番号と対応履歴しか見られない、という要件は大企業でよく出るものです。Dataverseでは列レベルセキュリティを列ごとに有効にし、読み取りと更新を許す列セキュリティプロファイルをユーザーかチームに割り当てます。前提としてレコード自体の閲覧権限が要り、使いすぎると性能が落ちる点も公式資料に記載があります。
異動への備えも権限設計の一部です。Dataverseでは部署をMicrosoft Entraのセキュリティグループに対応づけられるため、人事システム側で所属グループを変えればロールの付け替えが済みます。ロールを個人に直接付ける運用は、異動が年数百件ある企業では管理しきれません。閲覧やエクスポートの操作ログ、顧客情報の保存期間と削除の要件は顧客情報管理システムに要る安全管理措置と削除の設計で解説しています。
大企業の顧客管理システムで見落としやすいAPI上限・データ量と基幹連携の設計
大企業の顧客管理システムは単体では動きません。基幹システム、MA、名刺管理、コールセンターと連携し、その処理が人の操作よりはるかに多くの要求を発生させます。契約前に確認するのは、この連携の量が製品の上限に収まるかです。
Dynamics 365の1人24時間4万要求と連携用アカウントのテナント上限
Microsoft Learnの要求の制限と割り当て（2026年9月8日更新）によると、Dynamics 365 Sales EnterpriseやProfessionalの利用者は24時間あたり40,000要求、Team Membersは6,000要求が上限です。人が画面で使う分には余裕のある数字ですが、注意すべきは連携専用のアカウントのほうです。
アプリケーションユーザーや非対話型ユーザーといった連携用のIDは、テナント全体で1つの枠を共有します。枠は基本500,000要求に、Dynamics 365のEnterpriseかProfessionalのライセンス1つにつき5,000要求が加わり、上限は10,000,000要求です。1,000名分のライセンスなら5,500,000要求で、使い残しは翌日に繰り越されません。数分おきの全件同期を複数の連携で走らせると、この共有枠を食い合います。Dynamics 365での連携設計はMicrosoft Dynamics 365の導入支援サービスでも相談を受けています。
グループ会社の取引先を法人番号で名寄せして顧客マスタの重複を防ぐ手順
取引先の表記揺れを機械で判定するキーには、国税庁が指定する13桁の法人番号を使うことが可能です。法人番号システムのWeb-APIでは、法人番号か法人名を指定して商号・所在地・法人番号の基本3情報を取得でき、期間を指定すれば商号変更や登記の閉鎖も追えます。利用には無料のアプリケーションIDが必要で、発行まで2週間から1か月程度かかるため、移行計画の初期に申請しておきます。
- 各事業部の顧客台帳から法人を抽出し、法人名と所在地で法人番号を引き当てる
- 同じ法人番号を持つレコードを1件の取引先にまとめ、各事業部の商談と担当者を付け替える
- 支店・事業所は取引先の子レコードとして持ち、法人番号を持たない単位として区別する
- 新規登録時に法人番号の入力か検索を必須にし、重複登録を入口で止める
法人番号は親会社と子会社の関係までは持ちません。グループの資本関係は、取引先どうしの親子参照として自社で管理する必要があります。
基幹システムと顧客マスタを同期するときに決める正の値の置き場所
受注・請求を持つ基幹システムと顧客マスタを同期する場合、請求先の会社名と住所は基幹側、見込み客と担当者の情報は顧客管理システム側を正とする分け方が一般的です。両方で書き換えを許すと、夜間の同期で値が上書きし合い、どちらが正しいか分からなくなります。
大企業では基幹システムが事業部ごとに複数あることも多く、その場合は取引先コードの採番規則の違いを吸収する変換表が連携の本体になります。片方向で済むか双方向が必要かの判断と方式の選び方は、MA・SFA・基幹をつなぐCRM連携の設計と選定基準で詳しく解説しています。
海外拠点を持つ大企業の顧客管理システムに要る多言語対応と越境移転の確認
海外子会社や現地法人まで同じ顧客管理システムに載せる場合、画面の言語だけでなく、通貨・時差・法令の3点で設計が変わります。海外製の製品でも日本語に対応しない画面や帳票が残ることがあり、現地と日本の双方の利用者で試用してから決めます。
多言語・多通貨・時差を前提にした入力画面と連結レポートの集計設計
多言語対応で問題になるのは、画面の表示言語より入力データの言語です。現地の担当者が英語や中国語で取引先名を登録すると、日本側では同じ会社と認識できません。取引先名は現地表記と英語表記の2項目を持たせ、検索は両方を対象にします。
通貨は、商談ごとに取引通貨で金額を持ち、レポートでは基準通貨に換算する形が基本です。換算レートを月次で固定するか日次で更新するかを経理部門と決めておかないと、営業の見込み額と会計の数字が合いません。締め日の時刻も、日本時間で切るのか現地時間で切るのかを全社で揃えます。
海外子会社に顧客データを見せる前に確認する個人情報保護法28条の要件
海外子会社は親会社とは別の法人です。日本で取得した顧客の個人データを海外子会社に閲覧させる運用は、個人情報保護法28条の「外国にある第三者への提供」に当たるかを確認する必要があります。個人情報保護委員会のガイドライン（外国にある第三者への提供編・令和7年12月一部改正）では、原則として本人の同意が要り、例外は日本と同等の水準と認められた国にある場合、相当措置を継続的に講じる体制を整えた第三者である場合、法27条1項各号に当たる場合です。
実務では、グループ内でデータの取扱いを定めた契約や規程を整え、相当措置の体制として説明できる状態にしてから海外拠点へ権限を開くのが一般的です。先に権限を開けて後から規程を作る順番は避けてください。法務部門の確認を、権限設計の工程に組み込んでおくのが確実です。
大企業がパッケージの設定で済む条件と、導入支援や受託開発を入れる条件
ここまでの要件を踏まえて判断を示します。大企業であっても、多くの要件は製品の標準機能と設定で満たせます。外部の力を入れるべきかは、次の条件で決めてください。
SalesforceやDynamics 365の標準機能と設定で足りる大企業の条件
次の3つがそろうなら、製品の設定だけで構築できます。部署の階層が組織図とほぼ一致し、部署をまたぐ共有が一部の案件に限られる。連携は基幹から顧客管理システムへの片方向で、1日数回のバッチで足りる。海外拠点は当面の対象外、または閲覧だけで個人データを扱わない。
製品の候補は、Microsoft 365を全社で使っているならDynamics 365、外部の連携アプリや導入パートナーの選択肢を重視するならSalesforceが軸になります。2製品の価格と選び分けは規模・業種別のおすすめタイプと代表製品の公式価格で比較しています。
全社一斉導入で入力が止まる失敗の型と、事業部単位で広げる段階展開
大企業の導入で最も多い失敗は、全事業部の要望を要件定義で集めきってから全社一斉に公開する進め方です。要望の数だけ必須項目と例外の権限が増え、公開時には入力の手間が現場の許容を超えています。結果として、営業が元のExcelに戻る事態が起きます。
初回は1事業部に絞り、取引先の名寄せと権限の階層だけは全社で使う前提で設計します。2〜3か月の運用で入力が定着したら次の事業部へ広げ、海外拠点への展開は国内の運用が固まってから進める方針です。標準機能で表せない商流が出てきた場合の方式選びは顧客管理システムの開発方式と要件の見極め方で扱っています。
導入支援会社に相談する前に社内で用意する権限表と連携先システムの一覧
相談の前に、部署ごとに「どの顧客の、どの項目を、読めるか・書けるか」を一覧にした権限表を作ってください。大企業の見積もりの差は、ほとんどがこの権限の複雑さと連携の本数から生まれます。あわせて、連携先システムの一覧と、それぞれを片方向にするか双方向にするかの希望、初回に展開する事業部と人数を用意すると、比較できる見積もりが揃います。
一創では、権限表と連携一覧をもとに設定で済む範囲と開発が要る範囲を切り分けるところから支援しています。Salesforceの場合はSalesforce導入支援とApex開発のサービスで、既存の組織設定を活かしたまま事業部単位で広げる進め方にも対応します。
大企業の顧客管理システムでよくある質問｜シェア・中小向け製品・期間・費用
大企業で顧客管理システムを検討する担当者から寄せられることの多い質問に答えます。
大企業で多く使われている顧客管理システムはどれですか？
国内の大企業ではSalesforceとMicrosoft Dynamics 365が主な候補になり、名刺管理を起点にする場合はSansanのような製品を組み合わせる構成も見られます。ただし、利用企業の多さは自社に合う理由になりません。部署の階層と兼務をそのまま権限で表せるか、連携の量が上限に収まるかを、自社の組織図と連携一覧で確かめてから選んでください。
中小企業向けの顧客管理システムを大企業で使っても問題ありませんか？
1つの事業部や営業所だけで使うなら問題ありません。困るのは全社に広げる段階で、部署の階層ごとの閲覧制御、項目単位の制御、連携用APIの上限、監査ログの保存期間といった機能が足りなくなります。将来の全社展開が見えているなら、最初から上位エディションに移れる製品を選ぶか、事業部ごとのデータを後で名寄せできるよう法人番号を項目として持たせておきます。
大企業が顧客管理システムを導入するまでの期間はどのくらいですか？
1事業部への初回展開で、要件定義から公開まで4〜6か月が一つの目安です。期間を左右するのは機能の数より、権限表の確定とデータ移行の名寄せです。全社展開は事業部ごとに2〜3か月の間隔で広げる計画にすると、例外の要望を反映しながら進められます。海外拠点を含める場合は、法務部門の確認期間を別に見込んでください。
大企業の顧客管理システムの費用はどのくらいかかりますか？
費用の中心はユーザー単価×人数のライセンス費で、利用者が数百名を超えると年間の総額は大きくなります。閲覧中心の利用者に下位ライセンスを割り当てると総額を抑えられます。初期費用をほぼ決める要因は、権限設計・データ移行・連携開発の量です。単価と人数から3年総額を出す計算の仕方は、顧客管理システムの費用相場の記事で解説しています。
海外拠点でも同じ顧客管理システムを使えますか？
使えます。SalesforceもDynamics 365も多言語・多通貨に対応しています。先に決めるべきなのは、取引先名を現地表記と英語表記の両方で持つかと、レポートの換算レートの扱いです。日本で取得した個人データを海外子会社に見せる場合は、個人情報保護法28条に沿って本人同意か相当措置の体制を整えてから権限を開いてください。
関連記事
- CRMとは？顧客関係管理の機能・SFA/MAとの違いと導入メリット：CRMの全体像とSFA・MAとの役割の違いを整理したピラー記事です。
- 顧客管理システムとは？機能・Excelとの違い・脱Excelの判断基準：顧客管理システムの基本機能を押さえたい方向けの基礎記事です。
- MA・SFA・CRM連携とは？データ所有の決め方と導入順序：複数ツールのどこに顧客データの正を置くかを決める手順を解説しています。
- 顧客管理システムの比較｜CRM・SFA・エクセルの違いと選び方：タイプ別・規模別に製品を比べる評価軸をまとめています。
- CRMシステム開発の費用相場：標準機能で足りない部分を開発する場合の費用の内訳と見積もりの読み方です。
