顧客ポータル（顧客用マイページ）を開発したい｜契約情報・書類・問い合わせをまとめる設計

顧客に見せたいものが問い合わせの進み具合だけなら、サポート用SaaSの顧客ポータル機能で足りる可能性が高いです。kintone や Dynamics などに既にデータがそろっているなら、その製品の外部公開の仕組みや連携サービスを先に試してください。契約・請求書・問い合わせを顧客の会社ごと、契約ごとにまとめて見せたい場合や、今のCRM・請求の仕組みとつなぎたい場合は、連携部分の開発か個別開発を検討します。どの方法を選んでも、他社の書類が開けないことと、退職した人・委任期限が切れた人・契約が終わった顧客から見えなくなることを、完成条件として発注時に書いておく必要があります。

この記事は、法人向けに継続契約のサービス（保守・リース・SaaS・保証・物流・士業など）を提供していて、「契約内容を確認したい」「請求書をもう一度送ってほしい」「問い合わせはどうなったか」という顧客からの依頼を、担当者がその都度受けている事業責任者・CS責任者に向けて書いています。

既製品で足りるか、開発が要るかを先に確かめる

出典: SPIRAL 公式サイト

顧客ポータルには既製品があります。まず次の表で、自社がどちらに近いかを確かめてください。

確認すること	既製品・外部公開の機能で足りやすい	連携の開発・個別開発を検討する
顧客に見せたいもの	問い合わせの受付と進み具合、FAQ	契約内容・請求書・報告書・問い合わせを1か所にまとめたい
データの置き場所	1つの製品にまとまっている	CRM・請求・文書管理・Excelに分かれている
見せる単位	個人ごとに、本人の問い合わせだけ	会社単位・契約単位・本人単位を書類ごとに分けたい
顧客側の体制	担当者が1人で、交代はほとんどない	顧客側に管理者がいて、担当者の追加・退職を自分で管理したい
外部の人の閲覧	ない	代理店・顧問税理士などに、一部の契約だけ期限付きで見せたい
今のシステムとのつなぎ方	製品の標準連携で足りる	契約番号や顧客コードがシステムごとに違い、照合が要る

左側にほぼ当てはまるなら、開発会社に頼む前に既製品を試すほうが早くて安く済みます。右側に2つ以上当てはまる場合は、既製品の上に連携部分だけを作るか、個別に作るかを比べる段階です。既製品と個別開発の一般的な比べ方は「SaaSかカスタム開発か」にまとめています。

既製品の公式価格（2026-10-10 確認）

製品（種類）	公式の価格	顧客ポータルとして使うときの範囲
Microsoft Power Pages（社外向けサイトをローコードで作る基盤）	ログインする利用者向け 29,985円/サイト/月（100ユーザー/サイト/月、年払い、税別）	Microsoft のデータ基盤（Dataverse）のデータを社外に見せる形。料金ページ
Zendesk（サポート用SaaS）	エージェント1人あたり月額・年払い: Suite Team $55／Suite Professional $115（税表記なし）	顧客が自分の問い合わせを管理する「カスタマーポータル」は、比較表上 Suite Professional から。契約や請求書類の表示は主な用途ではない。料金ページ
SPIRAL（国内のローコード基盤）	初期 100,000円〜／月額 50,000円〜（データ量による従量。税区分の記載なし）	マイページ、顧客情報の変更、問い合わせフォーム、外部システム連携。開発代行は別見積、運用開始後の保守は別途有償。顧客専用サイト構築

公式価格から1年目の利用料を計算すると、次のとおりです（公式価格に基づく計算例。税・為替・追加ユーザーの課金は含みません）。

Power Pages（ログインする顧客側の担当者100人まで）: 29,985円 × 12か月＝ 359,820円/年（税別）
Zendesk Suite Professional（自社の対応担当3人）: $115 × 3人 × 12か月＝ $4,140/年
SPIRAL: 100,000円＋ 50,000円 × 12か月＝ 700,000円〜/年（従量分、開発代行、運用開始後の保守は別）

これらは利用料だけの金額です。どの製品でも、誰に何を見せるかの設定と、今のCRM・請求の仕組みからデータを入れる作業は別途必要になります。この作業を自社で行うか、製品の販売会社や開発会社に頼むかで総額が変わります。各社の価格は確認日時点の公式サイトの記載です。最新の情報は各社に確認してください。

作らない方がよい場合

顧客数が少なく、書類のやり取りが年に数回しかない。メールや共有フォルダの運用を見直すだけで足りることがあります
顧客側で誰がログインするのかを決める人がいない。画面より先に、最初のアカウントを誰に渡し、担当交代を誰が連絡するかという運用を決める必要があります
顧客に見せたい情報が、社内でもまだ一つの台帳にまとまっていない。先に社内の管理を整えるほうが順序として正しいです（社内の顧客台帳については「自社に合う顧客管理システムを作りたい」を参照）
顧客に注文までしてもらいたい。主題が価格・発注単位・受注確定に移るので、「取引先専用の発注サイトを作りたい」が近い内容です

顧客ポータルを使う4つの役割と、それぞれに見せる範囲

この記事では、法人向けの顧客ポータルにログインする人の役割を次の4つに分けて考えます。次の表は説明用の構成例で、実在の案件の画面ではありません。

役割	誰か	主に使う画面	見える範囲（説明用）	できる操作（説明用）
顧客の利用者	契約先企業の担当者	契約一覧、書類一覧、問い合わせ	公開情報、自社（自分の会社）向けのお知らせ、閲覧権を持つ契約の書類、本人宛ての書類	書類のダウンロード、問い合わせの登録
顧客の管理者	契約先企業の窓口責任者	上記＋担当者管理	自分の会社の全契約の書類（他の担当者の本人宛て書類は除く）	担当者の追加・停止、契約ごとの閲覧権の付与、代理店などへの委任
自社の担当者	営業・CS担当	担当顧客の一覧、問い合わせ対応	担当している顧客の情報だけ	書類の掲載、問い合わせへの回答
自社の管理者	CS責任者・情報システム担当	全顧客の管理、操作記録	全件（誰がいつ何を見たか・変えたかを記録する前提）	顧客企業の登録・停止、担当の割り当て

この表で特に決めておくべきなのは、顧客の管理者に担当者の追加・停止を任せるかどうかです。任せれば自社の手間は減りますが、顧客側が退職者の停止を忘れるという危険が残ります。任せない場合は、担当交代の連絡を受けて自社で停止する手順が必要になります。

情報を「公開・会社・契約・本人」の4つに分けて考える

「顧客ごとに出し分ける」と一言で言っても、書類によって見せる単位が違います。次の記入例を自社の書類に置き換えて埋めてみてください（説明用の記入例）。

区分	誰に見えるか	書類の例	決めておくこと
公開情報	ログインした全員（ログイン前でもよい場合あり）	利用規約、FAQ、メンテナンスのお知らせ	ログイン前にも見せるか
会社単位	その会社の担当者全員	取引条件の変更のお知らせ、会社全体の利用状況	代理店など社外の委任先にも見せるか
契約単位	その契約の閲覧権を持つ人と顧客の管理者	契約書、請求書、作業報告書、保守の点検記録	同じ会社でも契約が違えば見せないか。終了した契約をいつまで見せるか
本人単位	本人だけ	研修の受講証、本人の申請履歴	顧客の管理者にも見せるか

ここで迷いやすいのが、請求書を「会社単位」にするか「契約単位」にするかです。部署ごとに別の契約を結んでいる顧客では、他の部署の請求額が見えてしまうと困る場合があります。どちらが正しいかは技術では決まりません。自社の契約の形と顧客の期待で決まります。

架空データで権限の判定を試した結果

上の表どおりに見える範囲が分かれるかを、架空のデータを使って確かめました（2026-10-10 実行）。架空データを使い、見せる・見せないを決める判定ロジックだけを試したものです。実案件のデータや画面ではありません。

設定（架空）

顧客2社（K1、K2）、契約3件（K1 の CT-11 は継続中、K1 の CT-12 は 2026-06-30 に終了、K2 の CT-21 は継続中）
書類6件を、公開・会社単位・契約単位・本人単位のどれかに分類
利用者7人: K1 の管理者、K1 の利用者（CT-11 の閲覧権あり）、K1 の退職者（停止済み）、K2 の利用者、代理店（K1 から CT-11 だけを 2026-12-31 まで委任）、自社担当（K1 担当）、自社管理者
契約終了後に書類を見せる期間は 180日と仮定（実際の日数は会社ごとに決めます）

結果

確かめたこと	結果
役割と書類の組み合わせ17ケースが、期待どおりになるか	17ケースすべて期待どおり（不一致0件）
K1 の利用者が K2 の請求書の番号を直接指定した場合	「見つかりません」と表示。存在しない番号を指定したときと同じ応答
退職して停止された人	自社の契約の請求書も見えない
代理店	委任された CT-11 の請求書だけ見える。K1 の会社向けのお知らせと、委任されていない CT-12 は見えない
顧客の管理者	終了した CT-12 の請求書は閲覧期間内なら見える。他の担当者本人宛ての書類は見えない
自社担当	担当している K1 の書類だけ見える
基準日を 2027-01-10 に進めた場合（追加の2ケース）	CT-12 は終了から194日経っているため、顧客の管理者にも見えなくなる。代理店の委任も期限切れで見えなくなる

他社の番号を指定したときに「存在しない番号」と同じ応答を返すのは、「その番号の書類が他社に存在する」こと自体を伝えないためです。IPA「安全なウェブサイトの作り方」は、画面やURLから受け取った番号をそのまま使い、他人の情報を閲覧されてしまう問題を「認可制御の欠落」として挙げています。根本的な対策として、その番号がログイン中の利用者に許可されたものかを毎回確かめるよう求めています。OWASP Top 10:2025 でも、アクセス制御の不備が1位です。

作業中に起きた誤り

期待値の表を作る段階で、「K1 の利用者は、終了した CT-12 の請求書も閲覧期間内なら見られる」と誤って書きました。判定ロジックの結果は「見えない」でした。この利用者は CT-12 の閲覧権を持っていないので、ロジックの結果のほうが正しく、期待値を直しました。

この誤りは、会社単位で見せるか契約単位で見せるかという業務の判断を、期待値の表に書くときに取り違えたものです。受入試験の期待値は、開発会社やAIに任せきりにせず、顧客の契約の形を知っている業務側の担当者が確認する必要があります。

この検証で試していないこと

ログインの方式（パスワード、シングルサインオン、二段階認証）、ログイン状態の管理、書類ファイルのURLへの直接アクセス、一覧・検索・CSV出力からの漏れ、通知メールに他社名が載る経路、データベースやAPIの層での制限、表示速度は試していません。本番の受入試験では、これらも試験項目に入れます。

顧客の識別、最初のアカウント、退職・委任・契約終了の扱い

画面の設計より前に決めておかないと、開発が途中で止まる項目です。

項目	決めること	決めていないと起きること
顧客の識別	CRMの会社ID・請求先コード・契約番号のどれを正とするか。同じ会社が複数の請求先を持つ場合の扱い	同じ会社が2社として登録される。別の会社の書類がひも付く
最初のアカウント	招待メールを誰宛てに送るか（契約書の担当者か、請求先か）。本人確認をどの程度行うか	退職済みの人や、契約に関係のない人に招待が届く
担当者の追加・退職	顧客の管理者が行うか、自社が連絡を受けて行うか。年に1回の棚卸しを行うか	退職者のアカウントが残り続ける
委任（代理店・顧問税理士など）	委任できる範囲（契約単位か会社単位か）、期限、委任を誰が承認するか	委任先に全契約が見える。期限が切れても見え続ける
契約終了後	書類を何日間見せるか。終了後は問い合わせを受けるか	解約した顧客から過去の請求書の再発行依頼が担当者に戻ってくる
自社側の閲覧	自社担当は担当顧客だけにするか。全件を見られる人の操作記録を残すか	担当外の顧客情報を誰でも見られる

本人確認を厳密にする必要がある業種（金融など）では、オンライン本人確認サービスとの連携が別途必要になります。どこまでの確認が必要かは、業界の規制と自社の判断で決めてください。

今のCRM・請求・文書管理とのつなぎ方

出典: kintone 公式サイト

顧客ポータルは、今あるシステムの情報を顧客に見せる窓口として作るのが基本です。つなぐ相手ごとに、どちらの情報を正とするか、情報をどちら向きに流すかを決めます。

つなぐ相手	ポータルに流す情報	ポータルから戻す情報	つなぎ方の候補
CRM・顧客台帳	会社・担当者・契約	顧客側で更新した連絡先（反映前に自社で確認するか決める）	公開API、CSVの定期取り込み
請求の仕組み	請求書PDF、支払状況	なし（ポータル側では変更させない）	請求書発行時のPDF保存とひも付け、CSV
文書管理・共有フォルダ	契約書、報告書	顧客から受け取る書類	フォルダの規則に沿った取り込み、API
問い合わせ管理	受付番号、状態、回答	顧客の新しい問い合わせ	Webhook（更新を即時に知らせる仕組み）、API

問い合わせの状態（受付・対応中・完了）を社内でどう管理するかは、「問い合わせ対応の履歴を共有するシステムを作りたい」で扱っています。顧客台帳が Excel のままの場合は「Excel業務のシステム化」が参考になります。顧客から書類を集める業務が中心の場合は「資料回収の自動化」も参照してください。

書類を渡すときに社内で確認すること

技術の問題ではありませんが、公開前に社内で確認しておく項目が2つあります。ここで挙げるのは確認項目であり、法的な判断は顧問税理士・弁護士などの専門家に確認してください。

請求書などをポータルで渡すと、電子取引として扱われる: 国税庁の「電子帳簿保存法一問一答【電子取引関係】令和8年7月版」問2は、インターネット上にサイトを設けてそのサイトを通じて取引情報を受け渡す取引を、電子取引に挙げています。問7は、クラウドにアップロードして双方で共有する方法も電子取引に当たるとしています。書類を出す自社と受け取る顧客の双方で保存の要件が関わるため、顧問税理士に確認してください
他社の情報が見えてしまった場合の報告: 法人顧客であっても、担当者の氏名や連絡先は個人データです。個人情報保護委員会の通則ガイドライン 3-5-3 は、要配慮個人情報が含まれる場合、財産的被害のおそれがある場合、不正の目的によるおそれがある場合、本人の数が1,000人を超える場合などを報告の対象としています。報告の期限は、速報がおおむね3〜5日以内、確報が30日以内（不正の目的によるおそれがある場合は60日以内）です。自社の書類がどれに当たり得るかを公開前に担当部署と確認しておくと、万一のときに慌てずに済みます

自社でAIを使って進められること、開発会社に頼むこと

今は ChatGPT や Claude などを使えば、事業部門でも画面の試作やデータの整理を進められます。顧客ポータルの場合の分担は次のようになります。

自社でAIを使って進めやすいこと	開発会社に頼む価値が大きいこと
顧客に見せたい書類と情報の棚卸し（上の4区分の表を埋める）	他社の情報が見えない権限を、画面・ファイル・検索・CSV・通知メールのすべてに適用する実装と試験
架空データを使った画面の試作と、社内・顧客数社への見せ方の確認	CRM・請求・文書管理との連携と、顧客IDの照合
問い合わせの種類と月の件数の集計	最初のアカウント配布、退職・委任・契約終了の処理
受入試験の期待値表の下書き	本番環境の構築、操作記録、障害時の復旧手順

受入試験の期待値表はAIで下書きできますが、上の検証で起きたように、会社単位か契約単位かの取り違えは表の見た目では気付きにくいものです。最終確認は業務側の担当者が行ってください。AIで作った試作が既にある場合は、それを生かし、ログインと権限・試験・復旧・運用を見たうえで残す部分と作り直す部分を分ける進め方もできます。

費用の目安

AI革命の受託開発の公開価格は次のとおりです（すべて税別）。

依頼の形	価格	顧客ポータルで当てはまりやすい場面
既存システムの改修	100万円〜	既に動いている顧客向けの画面や、既製品の外部公開の仕組みに、機能や画面の追加、権限の見直し、他のシステムとのデータ連携をしたい
PoC（本格開発の前に、一部で実際に動かして確かめる段階）	300万円〜	一部の顧客・一部の書類に絞って、識別・権限・連携が成り立つかを試したい
本開発	個別見積	全顧客に公開する本番の窓口を作り、CRM・請求・文書管理とつなぎたい

PoC の300万円〜は試行段階の開始価格で、全顧客に公開する本番システムの完成価格ではありません。クラウドの利用料、メール送信サービス、既製品のライセンス、本人確認サービスなどの外部利用料は、上の価格とは別にかかります。既製品を使う場合も、前に示した利用料に加えて、設定と連携の作業費が発生します。業務システムの費用の内訳は「業務システム開発の費用」で整理しました。

AI革命では、Webの業務システムの新規開発・既存システムの改修、CRMや請求の仕組みとのAPI・CSV連携、社外の利用者を会社ごとに分けるログインと権限の設計、他社の情報が見えないことを確かめる試験までを開発範囲に含められます。既製品を使うか作るかの段階からでも相談できます。

顧客に見せたい情報と、今の管理システムを相談する

初回相談は無料・30分（オンライン）です。要件が決まっていなくても大丈夫です。顧客に見せたい情報と今の管理システムを伺い、依頼範囲の候補と費用の目安を相談メモでお返しします。

公開できる関連事例

顧客ポータルの開発事例ではありません。 権限の分け方という近い論点の参考として紹介します。

AI革命の受託開発の公開事例に、薬局の複数店舗・数千人分の記録を管理するシステムがあります。成果物は、記録管理システム、店舗・担当者ごとの権限設計、確認工程の整理です。社外の顧客向けの窓口ではありませんが、「誰がどの範囲の記録を見られるか」を先に決め、その範囲が守られているかを確認するという考え方は、顧客ポータルの権限設計と共通します。詳しい公開範囲は受託開発のページに掲載しています。

相談の前に揃えておくと早いもの

顧客に見せたい書類・情報の一覧（上の4区分の表に途中まで書き込んだもので構いません）
顧客企業の数と、ログインしそうな顧客側の担当者のおおよその人数
今使っているシステム・ツールの名前（CRM、請求、文書管理、問い合わせ管理、Excel など）
書類を今どうやって作り、どうやって送っているか
顧客からの依頼の種類と月の件数（「請求書の再送」「契約内容の確認」「問い合わせの状況確認」など）
顧客側の担当交代がどのくらいの頻度で起きるか、代理店や顧問税理士などに見せる必要があるか
AIで作った画面の試作や既存のコード、仕様書があればその有無

相談の申込みフォームには、実際の顧客データ・本番のパスワードやAPIキーなどの認証情報・秘密情報を書かないでください。

よくある質問

顧客に本当にログインしてもらえるでしょうか

ポータルを作っても、書類が引き続きメールで届くなら顧客はログインしません。新しい書類はポータルにだけ置くことにして、メールでは「掲載しました」とだけ知らせるなど、送り方を変える時期をあらかじめ決めておく方法があります。最初は協力的な顧客数社に絞って公開し、使いにくい点を直してから広げると、全顧客での混乱を避けられます。

スマートフォンでも見られるようにする必要はありますか

会社のパソコンで見る顧客もいれば、現場の担当者が外出先で作業報告書を確認する業種もあります。誰がどこで見るかを、顧客数社に聞いてから決めるのが確実です。スマートフォン対応を後から加えると画面の作り直しが増えるため、必要かどうかは最初に決めておきます。

取引先のアカウントで自社のポータルにログインさせる（シングルサインオン）ことはできますか

顧客企業が使っているログインの仕組みとの連携は、技術的には設計できます。ただし、顧客ごとに設定が必要になり、相手の情報システム部門との調整も発生します。対応する顧客の範囲と費用を最初に分けて検討してください。まずはメールアドレスとパスワードに二段階認証を加える形で始め、要望の多い顧客から順に対応する進め方もあります。